Re: [WISPA] The nanostation thing....
I can't say whether I'm interested in your ideas yet or not. But unless you wanted to develop syncronization or some specific function of a centralized server for the base stations I don't see the point of adding the additional complexity. Canopy for example has synconization without the need for additional 'controllers'. Mikrotik's RB433AH have a *LOT* of extra cpu(from our expereinces) and they're only $150ea! Have you thought of using 802.11n/MIMO on the downstream with dual polarized setup? It's too bad we didn't have an FDD spectrum allocated to WISPs where there were channels dedicated to upstream and downstream. Almost exlusively we use FDD for PTPs as opposed to HDX for a handfull of reasons. Similar benefits exist in PTMP situations... Jon Langeler Michwave Tech. Doug Ratcliffe wrote: > But the control point would be at the tower, not remote. I know some WISPs > operate in remote areas, but this is more for a high density urban > deployment, similar to what you would use AirSpan or Alvarion for. > > The reasoning behind the FDD style deployment would be to help compete > against 10Mbps+ cable connections. Right now a 6 AP deployment usually has > about 10Mbps for each AP (Canopy, Trango). My thought is to transmit-sync a > 50Mbps (40mhz turbo-mode) signal, with the vision that you could give fiber > speeds wirelessly. Or, with 50Mbps of bandwidth (per sector) it would give > you the ability to serve thousands of subscribers in a high density > deployment. The other though would be to be able to multicast MPEG4 video > over it. > > My vision is to keep us being able to compete with cable & DSL for years to > come without spending a fortune. If an open source system could interface > with 6 NS5's ($600) plus a rackmount PC ($1000), that's a Wimax-style QOS > deployment for less than the price of a single Canopy unit. The other > thought is that single NS5's are 802.11 and have no ability to transmit sync > (i.e. share frequencies) like other systems do. By giving it the ability to > do that, you have an inexpensive hardware platform with $1 per AP > features. > > - Original Message - > From: "Charles Wyble" <[EMAIL PROTECTED]> > To: "WISPA General List" > Sent: Monday, July 21, 2008 1:57 PM > Subject: Re: [WISPA] The nanostation thing > > > >> Doug Ratcliffe wrote: >> >>> My thoughts on this I've even mentied on the Mikrotik forum a while ago >>> were >>> to have a 2 part system: >>> >>> An outdoor wireless unit (like a Nanostation) that does nothing but act >>> as a >>> raw wireless interface, that connects to a master station inside the >>> tower >>> control room that is the "intelligence", like Wimax-style QoS, polling, >>> VOIP >>> control etc. >>> >> Isn't that how the Cisco solution works with a Wireless Lan Controller? >> This works great in campus >> environments which usually have a 100mbps or gigabit wired backbone, but >> not necessarily in >> WISP type deployments. >> >> In the case of a WISP you may have an exclusive wireless network >> (wireless link between CPE and aggregation point with WiMAX or other RF >> back haul ). >> or a hybrid model (wireless link between CPE and aggregation point with >> DSL/T1 back haul). Having the additional network infrastructure >> overhead on networks carrying customer traffic may or may not saturate >> your pipe. >> >> If you have the money to build separate control and data paths great! >> >> >>> The outside part could be connected via network switch to >>> allow a failover master control unit. >>> >>> >> Certainly. You want a reliable core. >> >>> I would think the inside part would be a rack mountable Intel/AMD server >>> or >>> even an inexpensive workstation (since even a $250 computer has 20x the >>> CPU >>> power of a Nanostation). >>> >> Certainly. Perhaps something like a mini ITX server. >> >> >>> It would also allow the ability to sync AP >>> broadcast, and maybe even include GPS sync capability. That would allow >>> the >>> outdoor unit to be minimal in flash and CPU speed but still allow high >>> speed >>> communications. Taken further into a 6x60 deg NS2/NS5 AP tower, combine >>> that with mesh for tower to tower communications and have a Skypilot >>> system >>> on steroids (tower to tower routing with n
Re: [WISPA] The nanostation thing....
Doug Ratcliffe wrote: > But the control point would be at the tower, not remote. I know some WISPs > operate in remote areas, but this is more for a high density urban > deployment, similar to what you would use AirSpan or Alvarion for. > Right. Makes sense. I re read the original post. My apologies. :) > The reasoning behind the FDD style deployment would be to help compete > against 10Mbps+ cable connections. Right now a 6 AP deployment usually has > about 10Mbps for each AP (Canopy, Trango). My thought is to transmit-sync a > 50Mbps (40mhz turbo-mode) signal, with the vision that you could give fiber > speeds wirelessly. Or, with 50Mbps of bandwidth (per sector) it would give > you the ability to serve thousands of subscribers in a high density > deployment. The other though would be to be able to multicast MPEG4 video > over it. > Yes that makes sense. > My vision is to keep us being able to compete with cable & DSL for years to > come without spending a fortune. If an open source system could interface > with 6 NS5's ($600) plus a rackmount PC ($1000), that's a Wimax-style QOS > deployment for less than the price of a single Canopy unit. The other > thought is that single NS5's are 802.11 and have no ability to transmit sync > (i.e. share frequencies) like other systems do. By giving it the ability to > do that, you have an inexpensive hardware platform with $1 per AP > features. > Indeed. I think you are onto something here! :) -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] The nanostation thing....
But the control point would be at the tower, not remote. I know some WISPs operate in remote areas, but this is more for a high density urban deployment, similar to what you would use AirSpan or Alvarion for. The reasoning behind the FDD style deployment would be to help compete against 10Mbps+ cable connections. Right now a 6 AP deployment usually has about 10Mbps for each AP (Canopy, Trango). My thought is to transmit-sync a 50Mbps (40mhz turbo-mode) signal, with the vision that you could give fiber speeds wirelessly. Or, with 50Mbps of bandwidth (per sector) it would give you the ability to serve thousands of subscribers in a high density deployment. The other though would be to be able to multicast MPEG4 video over it. My vision is to keep us being able to compete with cable & DSL for years to come without spending a fortune. If an open source system could interface with 6 NS5's ($600) plus a rackmount PC ($1000), that's a Wimax-style QOS deployment for less than the price of a single Canopy unit. The other thought is that single NS5's are 802.11 and have no ability to transmit sync (i.e. share frequencies) like other systems do. By giving it the ability to do that, you have an inexpensive hardware platform with $1 per AP features. - Original Message - From: "Charles Wyble" <[EMAIL PROTECTED]> To: "WISPA General List" Sent: Monday, July 21, 2008 1:57 PM Subject: Re: [WISPA] The nanostation thing > Doug Ratcliffe wrote: >> My thoughts on this I've even mentied on the Mikrotik forum a while ago >> were >> to have a 2 part system: >> >> An outdoor wireless unit (like a Nanostation) that does nothing but act >> as a >> raw wireless interface, that connects to a master station inside the >> tower >> control room that is the "intelligence", like Wimax-style QoS, polling, >> VOIP >> control etc. > > Isn't that how the Cisco solution works with a Wireless Lan Controller? > This works great in campus > environments which usually have a 100mbps or gigabit wired backbone, but > not necessarily in > WISP type deployments. > > In the case of a WISP you may have an exclusive wireless network > (wireless link between CPE and aggregation point with WiMAX or other RF > back haul ). > or a hybrid model (wireless link between CPE and aggregation point with > DSL/T1 back haul). Having the additional network infrastructure > overhead on networks carrying customer traffic may or may not saturate > your pipe. > > If you have the money to build separate control and data paths great! > >> The outside part could be connected via network switch to >> allow a failover master control unit. >> > > Certainly. You want a reliable core. >> I would think the inside part would be a rack mountable Intel/AMD server >> or >> even an inexpensive workstation (since even a $250 computer has 20x the >> CPU >> power of a Nanostation). > > Certainly. Perhaps something like a mini ITX server. > >> It would also allow the ability to sync AP >> broadcast, and maybe even include GPS sync capability. That would allow >> the >> outdoor unit to be minimal in flash and CPU speed but still allow high >> speed >> communications. Taken further into a 6x60 deg NS2/NS5 AP tower, combine >> that with mesh for tower to tower communications and have a Skypilot >> system >> on steroids (tower to tower routing with no hop loss). >> > > > Interesting. Didn't quite follow all that, but I will research it. > > >> I had taken the idea to a second level having a FDD-style system with a >> separate transmit unit and recieve unit outdoors where the CPE would >> simply >> switch frequencies or polarities to recieve their packets, and switch >> again >> to transmit. > > Seems like a massive amount of overhead. What would the reasons and > advantages/disadvantages for such an approach be? > >> >> That could allow for a 40mhz-turbo mode broadcast (GPS synced) with 5mhz >> channel upstream. My thoughts were having the capability of sending out >> 50Mbps+ downstream to clients (assuming a "dumb" wireless driver would be >> very light on CPU usage compared to, say, a Mikrotik unit that does >> everything but cook your breakfast). >> > > mmhmm. >> I tried some concept stuff using MadWifi but without CSMA/CD disable, >> 5/10 >> mhz channel support, etc it was kinda pointless. The separate TX/RX >> channels came as a crutch idea for CSMA/CD because you could tell the >> unit >> that it is recieving on a disconnected antenna for the transmitter uni
Re: [WISPA] The nanostation thing....
>> Right. Madwifi ( http://madwifi.org/ ) is pretty good but having >> trouble keeping up with new Atheros models. >> > > MadWiFi is a sort of reverse engineering.Atheros knows how the chipsets > work and you can buy the documentation, raw code, the secrets of the HAL, > everything, by licensing. Certainly. You are correct it's reverse engineering, and having access to the engineering data would result in a better product. > You also have to agree to certain levels of > confidentiality, etc.This is why MADWIFI isn't "official" Atheros code, > why the HAL for open source doesn't actually belong to Atheros. Of course. :) > Last I > knew, the cost of this was around $25K + the lawyers fees, etc... But this > strict arm's length development of MADWIFI is part of the reason why it > performs so poorly... > H define poor performance? As compared to what? Also 25k is very cheap many IP cores sell for over a million dollars. Naturally that's relative haha. :) > The people with the access to the engineering information CAN build almost > anything they want, since the Atheros radios are actually software defined. Ah now you have my attention even more... I have been getting into SDR recently: GNURadio http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html and http://openpattern.org/ Obviously serious assembly required. > > Once you get into the core of how it works, you have the ability to build a > whole new original MAC, sort of. > > Right. -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] The nanostation thing....
- Original Message - From: "Charles Wyble" <[EMAIL PROTECTED]> To: "WISPA General List" Sent: Monday, July 21, 2008 10:17 AM Subject: Re: [WISPA] The nanostation thing > > Right. Madwifi ( http://madwifi.org/ ) is pretty good but having > trouble keeping up with new Atheros models. MadWiFi is a sort of reverse engineering.Atheros knows how the chipsets work and you can buy the documentation, raw code, the secrets of the HAL, everything, by licensing. You also have to agree to certain levels of confidentiality, etc.This is why MADWIFI isn't "official" Atheros code, why the HAL for open source doesn't actually belong to Atheros. Last I knew, the cost of this was around $25K + the lawyers fees, etc... But this strict arm's length development of MADWIFI is part of the reason why it performs so poorly... The people with the access to the engineering information CAN build almost anything they want, since the Atheros radios are actually software defined. Once you get into the core of how it works, you have the ability to build a whole new original MAC, sort of. The money is what you pay for the license to use the information that Atheros gives you under confidentiality agreements. Now, YOU HAVE TO KEEP CONFIDENTIAL what you get, and the people using the GPL license run into some grief with that. BSD frees you from much of those constraints, makes a better system for closed/open source mix. Basically, you have to have to have seriously legally bound writers for the closed part of the code, and everyone else has no access to it. Probably end up with either closed source LKM's or a userland app or a daemon to accomplish this. Nice thing about it, is there's a LOT of hardware that has BSD licensed kernels... > >> I got several interested parties including developers and WISP's, but the >> obstacle is the funding. >> >> The reason you need substantial funding: The wireless driver holds the >> key >> here. You need the license from Atheros, and that alone is a serious >> chunk >> of money. We came up with a couple of viable methods of making the idea >> work. The driver development has to keep the Atheros sources closed, >> and >> like other people have done, fundamental adjustment of the MAC would be >> the >> ultimate function. >> > > So what exactly are you referring to here which requires a license? The > IP core? The HAL? Specifically, the HAL, but also a lot of engineering information they pass on to you. YOu learn how the radio works and how it can be changed... and you keep it a secret :) WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] The nanostation thing....
Doug Ratcliffe wrote: > My thoughts on this I've even mentied on the Mikrotik forum a while ago were > to have a 2 part system: > > An outdoor wireless unit (like a Nanostation) that does nothing but act as a > raw wireless interface, that connects to a master station inside the tower > control room that is the "intelligence", like Wimax-style QoS, polling, VOIP > control etc. Isn't that how the Cisco solution works with a Wireless Lan Controller? This works great in campus environments which usually have a 100mbps or gigabit wired backbone, but not necessarily in WISP type deployments. In the case of a WISP you may have an exclusive wireless network (wireless link between CPE and aggregation point with WiMAX or other RF back haul ). or a hybrid model (wireless link between CPE and aggregation point with DSL/T1 back haul). Having the additional network infrastructure overhead on networks carrying customer traffic may or may not saturate your pipe. If you have the money to build separate control and data paths great! > The outside part could be connected via network switch to > allow a failover master control unit. > Certainly. You want a reliable core. > I would think the inside part would be a rack mountable Intel/AMD server or > even an inexpensive workstation (since even a $250 computer has 20x the CPU > power of a Nanostation). Certainly. Perhaps something like a mini ITX server. > It would also allow the ability to sync AP > broadcast, and maybe even include GPS sync capability. That would allow the > outdoor unit to be minimal in flash and CPU speed but still allow high speed > communications. Taken further into a 6x60 deg NS2/NS5 AP tower, combine > that with mesh for tower to tower communications and have a Skypilot system > on steroids (tower to tower routing with no hop loss). > Interesting. Didn't quite follow all that, but I will research it. > I had taken the idea to a second level having a FDD-style system with a > separate transmit unit and recieve unit outdoors where the CPE would simply > switch frequencies or polarities to recieve their packets, and switch again > to transmit. Seems like a massive amount of overhead. What would the reasons and advantages/disadvantages for such an approach be? > > That could allow for a 40mhz-turbo mode broadcast (GPS synced) with 5mhz > channel upstream. My thoughts were having the capability of sending out > 50Mbps+ downstream to clients (assuming a "dumb" wireless driver would be > very light on CPU usage compared to, say, a Mikrotik unit that does > everything but cook your breakfast). > mmhmm. > I tried some concept stuff using MadWifi but without CSMA/CD disable, 5/10 > mhz channel support, etc it was kinda pointless. The separate TX/RX > channels came as a crutch idea for CSMA/CD because you could tell the unit > that it is recieving on a disconnected antenna for the transmitter unit (so > it would never detect carrier). In theory, it's basically like piping the > raw wireless data directly into the eth0 interface. Nothing else on the > outdoor part, all of the intelligence is in the indoor portion of the unit. > Interesting what kind of network stack tuning did you do? What packet classifer? etc etc etc. > Anyone like it? > > It certainly warrants further discussion and investigation. -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] The nanostation thing....
My thoughts on this I've even mentied on the Mikrotik forum a while ago were to have a 2 part system: An outdoor wireless unit (like a Nanostation) that does nothing but act as a raw wireless interface, that connects to a master station inside the tower control room that is the "intelligence", like Wimax-style QoS, polling, VOIP control etc. The outside part could be connected via network switch to allow a failover master control unit. I would think the inside part would be a rack mountable Intel/AMD server or even an inexpensive workstation (since even a $250 computer has 20x the CPU power of a Nanostation). It would also allow the ability to sync AP broadcast, and maybe even include GPS sync capability. That would allow the outdoor unit to be minimal in flash and CPU speed but still allow high speed communications. Taken further into a 6x60 deg NS2/NS5 AP tower, combine that with mesh for tower to tower communications and have a Skypilot system on steroids (tower to tower routing with no hop loss). I had taken the idea to a second level having a FDD-style system with a separate transmit unit and recieve unit outdoors where the CPE would simply switch frequencies or polarities to recieve their packets, and switch again to transmit. With the NS2/NS5 dual polarity antennas that's something that would be doable vs. my original idea of using the 2ft dishes and dual polarity LNBs. That could allow for a 40mhz-turbo mode broadcast (GPS synced) with 5mhz channel upstream. My thoughts were having the capability of sending out 50Mbps+ downstream to clients (assuming a "dumb" wireless driver would be very light on CPU usage compared to, say, a Mikrotik unit that does everything but cook your breakfast). I tried some concept stuff using MadWifi but without CSMA/CD disable, 5/10 mhz channel support, etc it was kinda pointless. The separate TX/RX channels came as a crutch idea for CSMA/CD because you could tell the unit that it is recieving on a disconnected antenna for the transmitter unit (so it would never detect carrier). In theory, it's basically like piping the raw wireless data directly into the eth0 interface. Nothing else on the outdoor part, all of the intelligence is in the indoor portion of the unit. Anyone like it? - Original Message - From: "Charles Wyble" <[EMAIL PROTECTED]> To: "WISPA General List" Sent: Monday, July 21, 2008 1:17 PM Subject: Re: [WISPA] The nanostation thing > [EMAIL PROTECTED] wrote: >> >> In short, it was to create a open source platform for WISP use. I >> called >> it WISP-OS. All the functions of routing, firewalling, dhcp client and >> server, and all the other networking functions are out there and >> consistently being improved in the open source community. > > Very true. See http://www.zeroshell.org/ for a fantastic turn key > solution. > > >> What, however, >> is needed is not another implementation of routing or firewalls, > > Amen to that. :) > >> but deep >> down fundamental efforts to improve the drivers for the common, cheap >> chipsets. >> > > Right. Madwifi ( http://madwifi.org/ ) is pretty good but having > trouble keeping up with new Atheros models. > >> I got several interested parties including developers and WISP's, but the >> obstacle is the funding. >> >> The reason you need substantial funding: The wireless driver holds the >> key >> here. You need the license from Atheros, and that alone is a serious >> chunk >> of money. We came up with a couple of viable methods of making the idea >> work. The driver development has to keep the Atheros sources closed, >> and >> like other people have done, fundamental adjustment of the MAC would be >> the >> ultimate function. >> > > So what exactly are you referring to here which requires a license? The > IP core? The HAL? > >> I saw this coming down the road when then software companies were moving >> toward becoming a closed hardware/software platform. The idea was to >> produce a licensable driver that could be integrated into any new >> hardware >> that might come down the pike, and put research into development of >> features >> that could be universally shared. >> > > Right. Like a large majority of open source projects solving horizontal > market problems. :) >> Right now, each developer has created their own 'non interoperable' >> feature >> set. So you want WiMax? Great. Only the basic feature set is >> interoperable among all. >> > > Yep. >> Anyway, the purpose was to let WISP's guide the direction of development. >> So, you want to use
Re: [WISPA] The nanostation thing....
[EMAIL PROTECTED] wrote: > > In short, it was to create a open source platform for WISP use. I called > it WISP-OS. All the functions of routing, firewalling, dhcp client and > server, and all the other networking functions are out there and > consistently being improved in the open source community. Very true. See http://www.zeroshell.org/ for a fantastic turn key solution. > What, however, > is needed is not another implementation of routing or firewalls, Amen to that. :) > but deep > down fundamental efforts to improve the drivers for the common, cheap > chipsets. > Right. Madwifi ( http://madwifi.org/ ) is pretty good but having trouble keeping up with new Atheros models. > I got several interested parties including developers and WISP's, but the > obstacle is the funding. > > The reason you need substantial funding: The wireless driver holds the key > here. You need the license from Atheros, and that alone is a serious chunk > of money. We came up with a couple of viable methods of making the idea > work. The driver development has to keep the Atheros sources closed, and > like other people have done, fundamental adjustment of the MAC would be the > ultimate function. > So what exactly are you referring to here which requires a license? The IP core? The HAL? > I saw this coming down the road when then software companies were moving > toward becoming a closed hardware/software platform. The idea was to > produce a licensable driver that could be integrated into any new hardware > that might come down the pike, and put research into development of features > that could be universally shared. > Right. Like a large majority of open source projects solving horizontal market problems. :) > Right now, each developer has created their own 'non interoperable' feature > set. So you want WiMax? Great. Only the basic feature set is > interoperable among all. > Yep. > Anyway, the purpose was to let WISP's guide the direction of development. > So, you want to use the cheap NanoStation? No problem. The open source > community has almost everything needed. And each hardware platform could > have any/all advanced features. > > So, instead of Star-OS having great performance, but only with itself, same > with MikroTik, any hardware platform could share a full feature set. > Well to a certain extent software controls a lot of things, but hardware certainly plays a part. Better antennas, more ram/cpu, FPGA etc. > This would require considerable funding, to do this development, but that > funding would be obtained from per-unit licensing scheme... something not > expensive per unit. Also, since it mostly would be comprised of open > source software, the development for each new board or cpu could be done by > individuals or even small g roups or companies, and only the licensed, > closed wireless driver would have to be "paid" development. > > The initial cost for this could be born by 50 wisp's and be relatively > small. > > The largest initial obstacle is the Atheros license cost... > > But, this would spur movement toward much greater interoper Again not sure what license cost you are referring to. Any links or information you could provide would be of interest. Thanks! -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
[WISPA] The nanostation thing....
A year or two ago I had this idea that's related to our discussions... In short, it was to create a open source platform for WISP use. I called it WISP-OS. All the functions of routing, firewalling, dhcp client and server, and all the other networking functions are out there and consistently being improved in the open source community. What, however, is needed is not another implementation of routing or firewalls, but deep down fundamental efforts to improve the drivers for the common, cheap chipsets. I got several interested parties including developers and WISP's, but the obstacle is the funding. The reason you need substantial funding: The wireless driver holds the key here. You need the license from Atheros, and that alone is a serious chunk of money. We came up with a couple of viable methods of making the idea work. The driver development has to keep the Atheros sources closed, and like other people have done, fundamental adjustment of the MAC would be the ultimate function. I saw this coming down the road when then software companies were moving toward becoming a closed hardware/software platform. The idea was to produce a licensable driver that could be integrated into any new hardware that might come down the pike, and put research into development of features that could be universally shared. Right now, each developer has created their own 'non interoperable' feature set. So you want WiMax? Great. Only the basic feature set is interoperable among all. Anyway, the purpose was to let WISP's guide the direction of development. So, you want to use the cheap NanoStation? No problem. The open source community has almost everything needed. And each hardware platform could have any/all advanced features. So, instead of Star-OS having great performance, but only with itself, same with MikroTik, any hardware platform could share a full feature set. This would require considerable funding, to do this development, but that funding would be obtained from per-unit licensing scheme... something not expensive per unit. Also, since it mostly would be comprised of open source software, the development for each new board or cpu could be done by individuals or even small g roups or companies, and only the licensed, closed wireless driver would have to be "paid" development. The initial cost for this could be born by 50 wisp's and be relatively small. The largest initial obstacle is the Atheros license cost... But, this would spur movement toward much greater interoperability - or at least the possibility of greater interoperability. So, while each hardware platform developer is re-inventing the wheel... It would no longer need to be done...simply license a great set of features that are driven by the WISP's who guide the development... As WiMax modules become more available, the same kind of driver/licensing system could be done for it, too. The same economies of scale and competitive production could apply to WIMAX as they have done for the 802.11 platform - specifically Atheros... This empowers individual wisp's to become legal integrators, like the modular fcc approval has done for Star-OS and others. Like I said, this idea is an old one for me, one I gave up on because nobody seemed to be interested, but it IS a viable notion and if this had been started back then, it would now be the key solution to much of the consternation now . WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
