"that's a few radio hops away from anywhere. And that's one reason why per-hop latency is all-critical"
To put things in context... from what we have seen typical latency between radios (for a single link) are between 1ms to 2ms... The Moto Canopy are an exception they have much higher latency....because of what they do and how they do it.... so even if you are going thru 20 radios.. you are talking about 15-20 ms .... Unless of-course the link is saturated or performing poorly due to poor signal. Faisal Imtiaz Snappy Internet& Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: [email protected] On 6/18/2010 8:27 PM, Fred Goldstein wrote: > At 6/18/2010 07:21 PM, Greg Ihnen wrote: > >> Are you seeing benefits from the mesh approach that you wouldn't get >> > >from backhaul/APs? Doesn't the mesh gear usually have > >> omni-directional antennas which can be problematic in an RF polluted >> environment. >> > There's more than one type of "mesh" out there, and I may need to be clearer. > > The first generation "WiFi" mesh, with the same frequency used for > access and meshing, was a bad joke. It reminded me of the AX.25 > digipeater networks that we played with in the 1980s. They > demonstrated, in slow motion, what didn't work! The early Trangos, I > think, were like that. They could "mesh" about one hop from the > injection point. At that point in time I discounted "mesh networks" > as a bad idea. > > Then came multi-frequency meshes. These do the backhaul on one > frequency and access on another. (Okay, SkyPilot can use the same > frequency for both, but it's layer 1 synchronous. That works > too.) This is what I'm talking about. > > >> Probably a better way would be to use a standard back haul with >> access point network and if you want redundancy put in extra back >> hauls and extra access points. The back hauls could switch over >> automatically, and the AP's would just need be commanded on or off. >> > Well, that's what the hardware might look like. A typical box would > have three radios, two for a backhaul chain and one for access, or > maybe more access radios if sectorized. We can't use "standard" > one-hop backhaul because the customers are in a tough location > (basically wedged between a rock and a wet place) that's a few radio > hops away from anywhere. And that's one reason why per-hop latency > is all-critical. I could put a chain of back-to-back radios there, > but would run out of frequencies and room on the poles/towers before > I got a few hops in... I need to extract some of the signal at > several stops along the chain. I've been playing with RadioMobile > and while I think its land cover forest-loss computations are *way* > optimistic (even pushing it to 180%), it has helped identify the only > possible ways in and out. > > I call that a mesh... but it has nothing in common with urban meshes, > LAN meshes, or those awful home-router toys. > > Aaron added, > > ..> and layer 3 meshing gets the job done. > >>> Why layer 3? Because you don't want it all to be a single layer 2 >>> >> broadcast area :) >> > I don't want a layer 2 broadcast mesh, actually. I'm thinking more > in terms of Carrier Ethernet, if I can make that work. It's > switched, not bridged. Huge difference. I've got some > bridged-network horror stories to tell myself, and I don't like > bridging. But suffice to say that the project in question is not > exactly a pure IP network. That's a story for another time though. > > >>> Your spectrum is just too valuable to send every broadcast >>> >> message to all others in the network. >> >>> Combine that with BGP/OSPF/whatever backbone links which are >>> >> built point to point (or point to a few multipoints) >> >>> with high capacity and you are set. >>> This way you can even have layer 2 meshes interoperating with >>> >> different meshes or OSPF/BGP/IS-IS/whatever protocol >> >>> backbone networks. >>> > HMWPplus seems to be doing an SPF protocol among nodes, at a layer > below IP. That seems right to me. BTW I'm pretty familiar with SPF > routing concepts. Way back in 1986 or so, I started writing RSPF, an > SPF routing protocol for IP over radio. A couple of guys implemented > it, more or less, in Linux, in the 1990s. But it's pretty much > forgotten. I've moved past IP; it's just so T.C. > > So I am really open to suggestions, and I hope I've made my > requirements clearer. This is a challenge to serve the most > impossible place we know of; our second expected project area some > miles away looks to be just a bit easier. (Still convex beach and > wooded hills, but it doesn't look as steep.) > > -- > Fred Goldstein k1io fgoldstein "at" ionary.com > ionary Consulting http://www.ionary.com/ > +1 617 795 2701 > > > > -------------------------------------------------------------------------------- > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------------------------- > > WISPA Wireless List: [email protected] > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
