Posted: Sun Jul 23, 2006 15:38 Post subject: Setting up a Townwide wi fi network
HI All,
I am loooking for help on setting up a 2 sq mile wi fi hotpsot network. The town will have 10 internet adsl gateways (4MPBS each) and around 25/30 WRT54G nodes. Any client devices (PC , laptops, Voip phones) connecting to 25 nodes should be routed properly and must use available internet gateways dynamically. The internet access gateways should be used for load balancing and fallback to make system 100% available.
Here are some detailed guidelines ...
1. The service will provide MESH of interconnected points creating a WiFi cloud within which WiFi enabled mobile users and static connections (e.g. laptops) can connect to back end services, and also receive internet based services and VOIP telephony.
2. This should use low power antennas, and conform to 802.11 standards. The infrastructure should be weatherproofed and capable of external and internal fitting into appropriate street facing or street located positions, e.g. Street furniture, advertising columns, lamp-posts, bus shelters, external walls etc
3. A proposed WiFi system should be a self-organising structure, able to pass the data from box to box in multiple low-power hops. The data should then travel further, around obstructions and interference, taking the best possible route to the final destination (another node). An intelligent service architecture is fundamental; it should 'discover' many potential routes through the network, and it will select the most suitable route based upon the shortest distance to reach the other node. Other criteria, such as the quality of the connection, can influence the 'decision', but ultimately the router decides on the routes itself. Should one route become unworkable then the node will automatically seek out another. Each node will be autonomous providing self-healing structure and removing the reliance on single points of potential failure.
4. A back office management suite will provide system status and usage statistics.
5. The system must encrypt all inter-WiFi Node: traffic point-to-point using a certificated address allocation and cryptographic validation system with certificated AES. Last hop traffic can be encrypted with a VPN connection to the local node. Full support for 'always on' connections, single use tickets, encrypted PPTP connections and VPN pass thru for IPSEC and PPTP is required.
6. The content services provided should be constructed to accommodate a range of mobile devices taking account of their limitations; for example in screen size. Solutions should be provided for content adjustment to assist in navigation of the planned network services based on Internet connectivity.
7. The solution should provide an open interface for XML/SOAP services integration and should be able to accommodate any web services integration.
Joined: 08 Jun 2006 Posts: 59 Location: Pittsburgh, PA
Posted: Sun Jul 23, 2006 18:29 Post subject:
Sounds like you've got your ducks in a row. Whereabouts is your town? _________________ PittMesh, a Meta Mesh Wireless Communities project.
Mi parolas Esperanton.
Hi There,
Please see my attached setup for covering most part of town & it's around 2 Square miles.
I need your help for finding right solution
1. My major problem is, How to get multiple internet access points communicate with each other over wireless? As shown in the diagram we will have around 10 units X 4MBPS= 40 MBPS bandwidth available at any given time. This should be shared evenly between all wireless access points and devices connected to them.
2. How handover of client devices like Voip Phones, PDAs or Laptops will be done from one AP to another.
3. How do you encrypt data between one wireless node to another
Hi Rich-M,
It is very much like that but it will be funded by town council for the community. They want to encourage local businesses and users to use wireless or some other form of internet to meet aggressive government target.
What you are looking for is quite a complex setup.
I would take a look at the WISP forum over at BroadbandReports.com.
Are you working from the city-government side, or are you the potential contractor? All the requirements for high-grade encryption for example will conflict with need to support PDA's and other "basic" client devices which frequently out in The Real World(tm) drive us to no encryption or at most WEP. Money and client-base are usually much more of driving factors in WiFi systems design, than building a gold-plated idealized network.
Joined: 07 Jun 2006 Posts: 980 Location: Coal Creek Canyon, Colorado
Posted: Mon Jul 24, 2006 22:07 Post subject:
I would think you'd need another layer between the dd-wrts and the ISPs in your diagram with some pretty smart core routing functions on the upstream side.
if you had that, the wrts could all be mostly simple APs and would not then have to also mesh over wifi.
If you couldn't wire or fibre them back to the smart router with the 4 ISP uplinks, then you could do dedicated wireless backhauls to each with seperate radios (maybe using another RF band).
Let us know what you find out... _________________ linksys GSv2, Gv4, Gv2, GLv1, G-TM, Buffalo wbr2, whr, whr-hp, whr-g125, wli-tx4-g54hp, Moto wr850gp, Alix.3C2
Hi There,
I work with local council on their small software requirements and this is how I am now involved into this project.
First the installation can’t be wired one. It is almost impossible for us to run a 2 mile long cable and join these access points together. I feel that also beats the main purpose, wireless internet. As shown in the diagram we can have as many internet nodes as we like for backbone wired network facing internet. The challenge is, how to route traffic between these multiple internet nodes?
I believe the reason people pointed you towards WIRED backhauls is it's frequently cheaper and more reliable to lease some copper phone-wires to transport data.
This idea you can just configure a WRT unit to both service local clients, and also handle 2-mile point-to-point links is a world of trouble for a bunch of reasons. Most WISP use dedicated units, preferably NOT in the 2.4 GHz band for backhaul between sites. 900 MHz and 5 GHz are popular choices in the cheap seats. A tenuous 2.4 GHz link can easily be destroyed when a bunch of folks with private AP's and cordless phones and what-not pop up right along your backhaul path.
There's a lot more to architecting a large network than what type of antennna to buy and how to configure the software. Most of the pro's would start with a copy of Radio Mobile Deluxe, which is free software that lets you model radio propagation over mapped terrain. Then they'd probably do some site surveys to see if their model matches reality. The numbers would drive the architecture, not the preferences and navel-gazing of netizens.
As I said up there a bit higher, some browsing of the WISP forum over at BroadbandReports.com can keep ya busy for quite a while. There is also the excellent free online book "Wireless Networking in the Developing World" linkage http://wndw.net/ As well as some good NutShell books. I bring this up because even drilling down at the level of OLSR versus this or that other routing technology stirkes me as premature given the state of your plan, at least as presented. A lot of people don't use tools like those because automagical self-healing mesh mumbo-jumbo sounds great when it works. It can also be deucedly difficult to debug when it breaks down.
In answer to one of your questions, you asked about "handoff" which implies the AP's play some role, which isn't the case.
WiFi client devices decide what AP they will associate with, and what will trigger a change of that association
The client device implementation of the WiFi driver is very commonly this simple:
If signal is entirely lost with AP I have been associated with, then
trigger new association attempt.
It is what it is, because nobody every expected anyone with a VoIP phone riding a motor scooter. The original minimal design just expected a user to shutdown laptop in office, walk to conference room and wake it up whereupon it would reassociate. For now most devices quite frankly suck at "roaming" in the sense of constant signal in rapid motion like people expect from cellphones, and this is not the fault of the AP. Typical cheap implementations will show the behaviour that signal goes to 1 megabit and your ability to use network goes to zero, then some amount of time passes for the device to recognize it needs to reassociate and pick a new AP. If you are imagining that client devices constantly assess strongest AP and pick a new one every millisecond you will be sadly disappointed by the reality. Actually given the long amount of time it takes to complete an association with current software and protocols, having it make this decision too often would be to your detriment if it kept flailing back and forth between 2 roughly equal AP signals. Some products and drivers do a better job than others. 802.11r is supposed to address client roaming implementations and improve on the current situation, so whenever that gets done I would recommend looking for 802.11r-compliant devices. Until then you are kind of on your own.
Muni-WiFi is a very popular topic these days. Many cities are toying with it and even spending money on it. A simple search of the news will show you dozens of stories of cities attempting it. You would do well to contact some of these cities and follow-up on how their rollout has actually gone, and get some INDEPENDENT assessment of it's success rather than testimony of the city wonk who approved it or the contractor.
