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/
