Our network is pretty inexpensive but suffers from first generation bandwidth problems of losing ½ the bandwidth capacity every hop. Patton wouldn’t settle for a partial victory and neither will we since we can do it for very little additional cost. It’s possible to virtually eliminate bandwidth loss per AP for up to $400 for the Gateway points ($100 for every direction it has to backhaul) $200 for midpoints and $100 for the end point. Keep in mind you don’t need to do this at every AP, just the links that have a higher load or to extend the network further. This is also something that can easily be added later as capacity increases.
We currently have the AP cost at about $200 and each AP can handle 30-50Mbps of traffic. However, 2 hops down from the gateway point or backhaul point, we are now down to about ½ of that. Go another hop and its ¼ of that using single radio WDS functionality. WDS has 3 other problems that we can’t get around with Ubiquiti’s Bullet 2M HP’s. The first is that we lose the client isolation function. The second is we lose a proprietary function that we will later cover called AirMax. The third is that we lose advance WPA encryption methods and we are limited to the evermore useless WEP. It’s easy to get around this though. Keep in mind the motto, “it’s not a problem if it can be fixed with money”.
Ubiquiti sells a little radio called a Nanostation Loco M5. It’s available in both 2.4GHz and 5.8GHz versions. We will focus on the 5.8GHz version since that limits the interference for our backhaul and as we discuss later, opens up new options for our network for PTMP. This little fellow only costs $70 and provides a 2x2 MIMO signal that can support up a total of around 100Mbps of total throughput with a 20MHz channel. I’m going a little conservative on throughput numbers since different types of IP traffic can test between 60-150Mbps. Put 2 of them on the pole with the Bullet M2 and your backhaul can now support all that bandwidth across several hops with a loss of about 1Mbps and about 2-3ms of latency added on each hop. However, you have just added another $200 per AP to do this with a switch. If you have two 5.8GHz radios on the pole along with the Bullet, you will need a switch.
The most cost effective switch I have found that is designed to handle reasonable temperatures is the Linksys SD205 unit. Although they are rated for 122 degrees, I have never seen one fail and I have had them in temperatures far in excess of 140 degrees for years. For around $25, they are the best little units for sealed outdoor installations and there is an SD-208 version if you need more ports. Compared to an industrial switch which starts at $250 (cheapest ones I have seen), the Linksys units are a steal. If you need a managed switch, then you are looking at industrial switches and the cost is going to start around $450.
The other good part of adding the Nanostation Loco M5 to our system is now if we have to add more AP’s in the middle of our network, we don’t have worry about the 1/n issue. We can also use WPA or AES security on the 2.4GHz network and 5.8GHz backhaul hops. This solves the wireless security issue. If we have to go around corners or Y off an AP, we can add up to 4 Nanostation Loco M5’s per pole if we use a 20MHz wide channel. Yes, I know that theoretically you can do 5 channels but that leaves no buffer between channels. With 4 channels, you get a 5MHz buffer which although not ideal, it’s not bad.
The drawback to the Nanostation Loco M5 is that to get maximum throughput or MCS (15) rates, you will be limited to 17dBm output with a 13dBm antenna or a total of 30dBm EIRP. If there are any tree obstructions or you need more power, the big brother, the Nanostation M5 has a 16dbi antenna and 21dBm of output for an extra $20. Keep in mind that these radios will go to a much higher power level if necessary but it comes at a reduction in throughput which we discussed in article 2. It does however, leave some room for increasing power if interference or obstructions start to cause issues later.
The Nanostation Loco M5 radios can also do one other thing. If we get back to the idea of a PTMP hybrid system, that means that users that are within the beam pattern of the Nanostation Loco M5’s can actually connect directly to the 5.8GHz backhaul. I suggest this stay reserved for truck rolls and trained technicians. 5.8GHz is a lot more sensitive to LOS which makes it more difficult for clients to install themselves. We are going to extend this concept further later also.
If the goal is that clients are going to install their own CPE’s, either indoors or out, it’s best if clients use a 2.4GHz product, preferably a Nanostation 2M or the upcoming Nanostation Loco 2M for indoor use with a window/wall mount. There is also some new indoor equipment from Ubiquiti, the WiFiStation, with directional and omni-directional antennas that support 802.11N and only cost around $30. The range is obviously lower but it also lowers the cost for clients.
Although our network also doesn’t support 2x2 MIMO on 2.4GHz yet, it is now supporting it on 5.8GHz so things are moving along. We have a couple options coming upon the 2.4GHz 2x2 MIMO solution coming up. There is also a way to customize the firmware on these units so that the CPE can be fixed only on your network with the proper settings and would allow you access to manage settings on the client side to optimize their connection quality. Imagine the client connecting to the system and then you get to remotely upgrade firmware on every client device simultaneously, monitor their connection quality, and manage the connection all way to the computer. That is the advantage to having all the radios from a single vendor. Tech support calls would go way down and staff wouldn’t have to fudge their way through 100 different products. Taking this a step further, if all the devices were Ubiquiti M series radios, you could also use the AirMax feature with polling for the clients. Of course, you sort of kiss off the legacy devices, or do you?
Rory Conaway is one of the finest Wi-Fi brains in the world today. I have had the pleasure of meeting with him in 2007 in the town of Surprise,AZ. He has started penning down his experiences with Wi-Fi and the pitfalls/challenges and how to avoid these. I am posting these articles in my effort to spread Wi-Fi awareness and education in India.
Showing posts with label WDS. Show all posts
Showing posts with label WDS. Show all posts
Friday, June 18, 2010
Sunday, May 9, 2010
Chapter 5 - Reality, what a Concept
In the last article, AP’s got hung, WDS links were set up for hopping, and we were ready to attach to Internet. Although TriadLand is ready to rock, we now need to connect the users. First we need to attach connect the network to some type of Internet service and then come up with a way to authenticate the users that want to use it. After that we will cover the details on some of the system management and how to overcome them.
WISP operators are typically forced to work with local bandwidth providers who typically have some type of monopoly for the area. A WISP can’t resell most of the business services over DSL or Cable due to the local provider not allowing that. WISPs are generally resigned to T-1 circuits or more expensive business options. Assuming that you order a T-1 for your system, you now have 1.5Mbps of bandwidth for your network. If you plan on using cable or DSL services, check with your local provider to see if that is allowed. Other bandwidth options are also available but you will have to check for each area.
Assume that one of the 4 center APs out of 16 are the Internet connection point. We will set up the WDS links so that now end point is no more than 4 hops (meaning we may have to skip one) which will keep the last AP with around 5Mbps at the end point. If we can skip more than one AP, we can keep the hops to 3 or even 2 if we have LOS between the AP’s. We have enough signal to hold very high modulation rates with ½ mile links between APs. Keep in mind that APs between the end point and the egress point will be handling users while simultaneously passing WDS backhaul for other APs down the chain. This will directly affect throughput for users down the chain. It is one of the limits of this design but no different than any of the other earlier mesh designs. The end result is that the entire square mile will eventually be routed through one AP.
One key issue I received a couple of emails on involved security. The drawback of inexpensive radios is that you may have to give up something in return for the reduced price point. This system provides no encryption over the WDS links. This problem gets resolved with additional hardware as part of an upgraded system. The system can run security between the laptop and the AP but there isn’t much use if the AP hops aren’t secure. If you plan on upgrading later with more bandwidth, then it might be a good idea to get the users to use WPA2 on the APs from day one so they won’t be confused later. Just make sure your EULA clearly states that the system is not secured over the wireless link.
The second problem with this network is that it only supports a single SSID. I do not know if that is going to change in the future. There is third party firmware that will run on the Bullets that may offer more options but that typically comes with additional costs which gets away from the original premise. If you need security, then VPN tunnels are the only option with the basic system. Phase 2 resolves most of the security issues.
There are many good products out on the market for authentication of users. Our sites use Patronsoft Firstspot for user authentication and management. FirstSpot runs on Microsoft Windows XP or Windows Server, can support SQL Server for extending site deployment and centralized user management, uses PHP for the web pages, and can run fail-over servers for offline management. Since our company has years of experience with Windows, it works for us. Those of you with more experience with Linux have many other options. We ran tens of thousands of users through our servers over 5 years so I’m pretty comfortable with it. However, it’s not CALEA compliant yet but they are looking at it now.
Triadland is up and running. Users attach to the broadcast SSID, get a login page, diligently read the EULA word for word in which they agree to follow the rules, and then they get online. Now what happens? This is stuff normally planned out in advance but the article focus was determining the basic wireless technology first. It’s time to deal with the actual functionality of operating the system.
This is where every WISP’s worst nightmares start. It begins with the Federal government getting access to your system in the name of Homeland Security and ends with junior making it his personal mission in life to download the entire Sony movie collection. Your first job is to file your CALEA paperwork. CALEA is an entire article by itself and I may cover it much later. Go to http://www.wispa.org/?page_id=2022 for more information. After that, you need to figure out how you are going to keep control of junior. You are also going to have to deal with the users that move large amounts of spamware or spyware without even knowing it. These same users can get you disconnected from your Internet circuit if it’s bad enough.
Let’s move on to the first issue which is keeping control of your network. Several things will stress both you and your network. Let’s start with junior’s desire to fill up that new 2 Terabyte hard drive he just got for his birthday. File-sharing is one of the biggest problems faced by most ISP’s. Fortunately or unfortunately, depending on which side of the equation you are on, recent rulings by the FCC allow operators to limit file-sharing. There are 2 basic ways to handle this. You can use either an authentication server that keeps track of bandwidth used or a web application firewall that allows you to block file-sharing applications. Limiting users to 10GB – 20GB per month is a good start.
Early on, we had an incident where some users on our network had been infected and turned into spam servers. The bandwidth provider started blocking Internet for the entire system until we got it resolved. With 200 plus users and some of them still running Windows 98, the battle to keep viruses and spam under control is difficult at best. We purchased a Barracuda Web Application server which not only blocked the offending users, it redirects them to run spam removal software and won’t let them on Internet until the computer is cleaned. A Web Application filter also allows blocking of specific websites that might cause unwanted legal attention and file-sharing applications.
Now that we have built our 1 square mile network in Triadland, our next step is to make either make it profitable or find a way to give it purpose. We will cover those ideas next article.
Sunday, February 7, 2010
Chapter 2 - Access Point Secrets You Didn’t Share with your Parents.
Continuing the discussion of the budget Muni-Wireless network requires analyzing the front line component - the Access Point (AP). There are many variations of APs. They all have features and capabilities that provide enhancements in certain environments. Some of the APs break the practical limit of 20-30 users by using multiple radios in a single enclosure, proprietary polling systems (not compatible with other vendors), and advanced beam-forming techniques. However, the focus is from a budget standpoint and that means this design will start with a single 2.4GHz radio with an omni-directional antenna. Later articles will cover upgrading the design to support more users and a larger coverage area. The beauty of this design is that it’s cheap to get in the game and scalable.
The ideal inexpensive AP was covered in the first article. This article will next cover what protocol it should support. Obviously if it supports 802.11n, that’s huge. 802.11n can provide up to twice the range of 802.11 b/g with the same single AP, single antenna design. This is due to a combination of a more efficient transmitting modulation scheme and better receiver design than 802.11b/g/n. In 802.11n, this would be considered a 1x1 MIMO. If the world was perfect and everybody had 802.11n devices, theoretically it would take only ½ to ¼ as many APs per square mile for the basic system. Unfortunately, the expansion of WiFi phones and their lack of support of 802.11n means keeping legacy 802.11b/g compatibility, range, and load in mind. If the network doesn’t need to support 802.11b/g the savings are huge. The reality is though, if the network was built today for the general public, the system should still support 802.11b/g equipment.
Taking the AP design a little further, figure out what the client connectivity area is. If the goal is to connect to Joe or Jill Teenager, who lives in suburbia with maple trees covering the sky and every home is built like the Windsor Castle (brick), while he/she is lounging on the couch with his/her iTouch which doesn’t support 802.11n; then even with 16dBi omni antennas, the AP will have to have to be within a couple hundred feet. If they live in Stuccoville, Arizona, (yes, stucco attenuates signal, but go with me on the flora thing) the range will be much greater since trees are 60’ tall with leaves starting at 55’ (palm trees). The only other vegetation is 2’ tall and is considered a lethal weapon (cacti for the Northerners). This is a slight exaggeration, but the basic physics stand. If the clients are outdoor only such as surveillance cameras, mobile hot spots for police, utilities, etc…, then the number of APs is reduced significantly. In fact in Arizona, there are places where 2 APs per square mile are all that’s needed for mobile coverage or every traffic light corner.
The really interesting thing concerning small deployments, parks, mobile home parks, etc…, is that the back end Internet bandwidth options are rarely as fast as the radio capacity for cost reasons, access, or End-User-License-Agreements. For example, one park that Triad manages is really only under heavy use for two months during the year (Spring Training) in addition to 2-4 high-use specialty events. Bandwidth options are a T-1 for a whopping 1.5Mbps ($450 monthly), DSL for 12Mbps ($100 monthly), or cable for 4Mbps ($200 monthly). Assuming 12Mbps is enough (it can be expanded with multiple DSL circuits as needed), users are limited to 2Mbps, the radios support up to 20Mbps in 802.11g, and there is only 2 hops maximum meaning no need for multi-radio APs. Even at 2 hops, bandwidth is still 10Mbps on the perimeter. There are 11 radios total to cover about ½ square mile with 2 high-density cluster areas. The 2 high-density areas are each comprised of 4 separate radios at the perimeter locations. The remaining areas are covered by 3 other radios. Using high-gain omni-directional antennas, laptops can connect at 800-1200 feet. All radios are in AP+WDS mode for relay and coverage. The total cost for all the radio equipment and antennas for this deployment was $2300, not counting the tower mounting brackets. The system has been up for over 2 years and is scheduled for a planned 802.11n upgrade in the next month or so. The omni-directional antennas will stay, meaning that the 2 hop system will now deliver about 20-30Mbps on the second hop.
The project utilizes four vertical assets up to 150’ that also include a 5.8GHz PTMP system. The 5.8GHz PTMP system has a range up to several miles in a 360 degree pattern. Each vertical asset consists of one radio with a standard vertical polarity sector antenna. When the PTMP system is upgraded, it will consist of 5.8GHz 802.11n, 2x2 MIMO equipment. The cost of the upgrade will be approximately $250 for the radio and antenna and will support up to 100Mbps per radio. Throw in another $100 per pole for backhaul and the system has now expanded from a simple hot-spot project to a 100 square mile 400Mbps infrastructure for an additional $1400.
It’s time to step back and discuss the unadvertised secrets of 802.11n since it affects the expectations of the design. Here’s a big shocker - the processor and firmware of the AP affects the radio performance. For example, the AP manufacturer claims 300Mbps. That’s modulation, not real-world throughput. That number is also rounded up from the real number which is between 270-288Mbps, depending on what’s called the guard scheme (not within the scope of this article and makes my head hurt). Keep in mind that many of the 802.11n radios also have 100Mbps Ethernet jacks because manufacturers know that communication is half-duplex. The Ethernet port is full-duplex so they consider 100Mbps up and 100Mbps down, 200Mbps total, not 200-300Mbps in one direction. Strike one.
The second issue is that 300Mbps is only achievable by running 40MHz wide channels. That works great in the living room for 50’. It doesn’t work so well when the AP is perched on a light pole with 200 houses in range. It would be difficult at best to go 500’ in 2.4GHz and get maximum theoretical modulation rates with a 40MHz wide channel. Multi-radio APs typically use the 5GHz bands for backhaul for that reason. That means the real-world useable 2.4GHz bandwidth is 20MHz which translates to 150Mbps. Strike two.
The 5.8GHz band is the most commonly used with 40MHz channels. 5.1GHz to 5.3GHz is usable with some manufacturers, but the EIRP drops significantly. However, for 500’ and no vegetation, that is reasonable. There should be very little interference in those bands. Of course, many of the radios that are already in those bands are probably set up by a local WISP. Although most WISPs are knowledgeable and legal, there are a few WISPs that either have no clue about the rules or are intentionally broadcasting illegally due to congestion in the 5.8GHz band. There are manufacturers who have certified equipment in those bands, but because of the limited EIRP in those bands, the equipment isn’t as popular. 5.8GHz also isn’t supported by most laptops and smartphones.
Assume that there isn’t interference in whatever band with a 40MHz wide channel. Then the next question is how far can a 300Mbps modulation level be maintained? Well, here is the second problem. To quote a good friend of mine, “speed, distance, reliability, cost - pick 3”. The first 2 are the most critical. For just the radio, it should be “speed, distance - pick one”. Basically, to get the 300Mbps modulation rate, receiver sensitivity drops to around -72- to -74dBm and the power output of the radio drops from the fabled 26-30dBm to around 24-26dBm or less for outdoor equipment and 15-18dBm for the retail $30-$200 equipment. To get the magical 300Mbps speed in a 360 degree coverage pattern from a single radio with an omni-directional antenna, there should be total LOS, no interference, and at maximum distances of around 500’ or less with the 40MHz channel. Most multi-radio AP manufacturers recommend directional antennas but one could argue that defeats the concept of ubiquitous mesh architecture. Strike three.
I have not done testing with most of the new 802.11n APs so some of you can jump in here with some real-world values. I’m also not going to get into sector antennas here for pole installations because the size of the antennas which makes it difficult to get through city zoning. I’m going to also get some grief here from the beam-forming guys; but realistically, none of the beam-forming systems in 2.4GHz can match a 28” tall sector antenna in performance. It’s a simple matter of physical capture area. However, newer sector antennas also support multi-polarity which gives them even more advantage.
Although baseball doesn’t have a strike four, here it comes. 300Mbps modulation rates are a real-world throughput of 150Mbps through one radio under absolutely ideal conditions. This typically doesn’t exist in most suburban realities. In addition, the processor is also a bottleneck for the AP. On some 802.11n devices, a straight ftp transfer from one computer to another computer with a 20MHz wide channel (much more realistic) will result in a transfer of about 35Mbps. Put two computers on each side, and then do the same transfer computer to computer, and the throughput jumps to about 60Mbps with each stream about 30Mbps. Do a 3x3 transfer, bandwidth goes up to 72Mbps, and each unit drops to around 24Mbps. Further testing up to 10x10 transfers demonstrates 85Mbps maximum. All of these numbers are perfect signals at short range in the lab. So what happened?
Basically, some processors/chipsets get more efficient as multiple transfers of data occur but are fairly limited for a single transfer. For example, using a 20MHz channel and MCS7 modulation rates (65-72Mbps depending on guard scheme), will result in a 60Mbps with 65% CPU overhead with UDP video traffic from a single camera. However, change that to TCP/IP and the rate drops to 35Mbps and CPU processor overhead jumps to 100%. This test was done with a 400MHz Atheros processor and chipset in the radio. Other manufacturers also use the 300Mbps but really add in the combined throughput of 2 radios, not a single data transfer rate. Keep in mind that this isn’t for every single product out there, but it shows that real-world testing is definitely required before a design is signed off on for the particular application.
802.11 a/b/g APs exhibit this same behavior when compared to the marketing material so it’s not a new phenomenon. In some cases, manufacturers used UDP traffic numbers instead of TCP/IP real-world traffic. In other cases, manufacturers were using 40MHz channels for their specifications which again, aren’t realistic for most installations. In many cases, when 40MHz channels were used, the CPUs capped out so that the result was not a doubling of the transfer rate but maybe 80% more over a 20MHz channel. For example, 20Mbps at 20MHz translated to 35Mbps at 40MHz.
Another problem with processor overhead is how many packets per second (PPS) that can be jammed through at one time. A user opening up a web-site usually has a fairly low PPS requirement, thus low CPU overhead. Open up a file-sharing application and the number of sockets and PPS can go through the roof. Low-cost APs trying to handle this kind of traffic typically slow down drastically. More expensive and faster processors along with better firmware scale better under load.
There are many reasons that one AP costs $100 and another costs $6100. More expensive APs will use 2, 3, 4 or sometimes more radios within a single AP enclosure. The rest of the costs come in the form of firmware, management tools, and capabilities. Many of the outdoor units have firmware designed to optimize video transmission quality, fast-handoff between AP radios while vehicles are moving, mesh implementation, beam-forming, multiple SSIDs, multiple frequency, channel bonding, and many other advanced WiFi technologies. 802.11n radios are also start with a better specification foundation.
Switching back to the budget system, WDS communication is built in to almost all the chipsets and supported in firmware. This allows APs to connect to each other through Layer 2. It’s simple, sometimes not compatible between manufacturers, and requires manual setup with MAC addresses of each device. Mesh firmware, with a basic setup, simply finds all other units in an area, then sets up either a layer 2 and/or a layer 3 network between the radios dynamically, as part of its underlying mapped infrastructure. Mesh firmware is always proprietary between APs.
The goal of Tales from the Towers is to create a budget, scalable, municipal WiFi system. It will probably never have many of the capabilities that more expensive systems can do. The budget WiFi system will not initially and probably may never support fast handoff for moving vehicles, optimized video traffic, or possibly multiple SSIDs. Therefore it’s important to understand what its capabilities are before deciding that price is the most important factor. In some cases, its inexpensive nature, flexibility, and scalability allow the network to get around many of the advanced features that some of the more expensive APs have. In others cases, it simply isn’t going to happen and the proper design should be Motorola, SkyPilot, Firetide, Tropos, MeshDynamic, Ruckus, BelAir, Meraki, Meru, or whatever product fits the needs and budgets of the municipality. Every one of these companies has features and benefits that make them ideal for specific applications. I have designed and installed systems using many of these products.
However, the focus here is a starter system the meets the cost and scalability of really tight budgets. This makes it deployable in areas that can’t justify the ROI of more expensive equipment and can bring Internet to areas that may not be able to justify a large investment. The next article will cover the actual AP deployment design.
"Rory Conaway"
"Rory Conaway"
Labels:
40MHz,
802.11n,
AP,
broadband,
muni wireless,
omni antenna,
WDS,
wi-fi
Thursday, January 7, 2010
Chapter 1 – Building a Muni-Wireless system from scratch
Several people have asked about the concept of a lower cost municipal WiFi system. The questions covered systems from very small areas to several hundred miles. To be honest; we haven’t yet deployed a multi-hundred mile Muni-WiFi system. As a Wireless Internet Service Provider (WISP), our smallest system is 15 clients and the largest system is about 270. I have designed and managed systems that handled up to 3000 users per day and supported about 30,000 users per year through pay per use servers. My designs are based on systems installed and deployed over the last several years that typically didn’t follow the standard cookie-cutter models. Since then I have engineered mesh systems for public safety and municipal utilities for video surveillance/analytics over 100 square miles, Major League spring Training baseball facilities, traffic systems, airports, city facilities, Point-to-Multipoint (PTMP) WISP systems, and PTP links up to 1Gbps. The proposal for a city-wide system is based on my experience and lessons learned with these systems and concepts.
A municipal wireless system is basically a bunch of hot spots connected through some type of wired or wireless backhaul system using a cluster of Access Points (APs). The system eventually funnels all traffic back to a central location which may utilize an authentication system to allow various users on the system. It’s pretty simple stuff with the devil in the details. However, the details are the difference between whether this system is financially and technically feasible or not. We are not going to cover that in one article. However, we will show how we developed and deployed different techniques over the last few years to create the foundation for a low cost, scalable Muni-Wireless system.
Before designing a system, determine the following basic issues:
Determine the rules for deliverable product.
Evaluate potential upgrade path for future growth
Calculate costs/income if applicable
Let’s take the first case which is the simple idea of providing Internet in a building. I’m going to spend a little time on it because it’s a microcosm of a very large system. Consider it a miniature Muni-Wireless system in terms of number of users and the foundation for one of our industries. It’s also where we came up with the concept of eliminating fiber by using VDSL converters and using WDS for backhaul for AP to AP hopping. Later, we decided that Wireless Distribution System (WDS) was also preferable to mesh for our outdoor designs due to cost issues, the fact that mesh radios typically only connected to the radios before and after them meaning no change in the mesh structure, and that some of the mesh manufacturers weren’t using load balancing to determine mesh paths, only signal level and modulation.
Inside of a building or in a heavily populated area, there are two basic problems, density and connectivity. The inside of a building is basically a controlled environment. Outside in a populated area, you also have interference, but we will deal with that in a later article. We will also introduce a central server managed design based on these same concepts that will also greatly reduce the cost of in-building WiFi systems.
The first building we did, the Stratosphere Hotel in Las Vegas, was a pay system. Keep in mind that this was before WDS or mesh was any type of standard. At the time, we realized that we needed at least 50 APs to cover 2500 rooms on 24 floors with the ability to support about 200 users simultaneously. Due to building codes, all Ethernet cable for each radio would have to be in conduit. In addition, the cable runs from each AP would be well over 300’. One hallway alone was 270’ long. Conduit and cabling costs would run several hundred thousand dollars. The only existing asset we had was a few pairs of telephone wires in a vertical riser conduit that we could use. The vertical riser conduit was already full and there was no way additional cable could go in there.
The vertical asset problem was the easiest. We used Ethernet VDSL converters to push bandwidth from the data room several hundred feet away to a single Access Point to every other floor. These units support 10-15Mbps half-duplex for distances up to a mile across a twisted pair of wires with current versions supporting up to 100Mbps. VDSL also eliminated fiber which would have raised the cost significantly because of the fiber switches. That’s more than enough bandwidth for an 802.11b AP. Basically we traded $250,000-$500,000 worth of conduit work and fiber equipment for about $4000 worth of VDSL converters, a VDSL switch, and WDS which we discuss later. We eventually did the World Market Center in Las Vegas about a mile away with many of the same ideas.
Now that we had bandwidth on every other floor to 1 AP, the second problem was that the hallways were sequential meaning end-to-end. The hotel is in the shape of an S when seen by planes that fly over. That’s when we came up with the idea of using WDS hops from AP to AP while using the same radios in AP mode simultaneously. Since there were 2 radios in each AP, the WDS path went in one radio and out the other, thus minimizing the 1/n problem. There were 5 radios on every other floor. On each radio, we used custom directional antennas to aim down the hallways for greater range and better room penetration. At the time, the Vivato APs were the only units we could find that could support AP and WDS mode on the same radio simultaneously and were reasonably inexpensive at $350 per radio. Total cost of equipment for the entire installation was less than $40,000 with labor at about $10,000. It cost $3000-$4000 per month for bandwidth and tech support. We generated over a million dollars worth of revenue over the next 4 years from that system. The reason I use this example is because the techniques we learned became the foundation for almost every future system.
There was a book written called “All I really need to know I learned in Kindergarten” written by Robert Fulghum. We found that the Stratosphere was our Kindergarten. The VDSL units we used later saved another client $100,000 in their initial installation. The roaming spammers gave us the opportunity to test various methods of blocking them and handling high volumes of traffic. Hackers scanning through the system forced us to micromanage connectivity and to be proactive instead of reactive. The system was later upgraded to go from 200 simultaneous users to over 1000 over the next few years by simply adding more radios and VDSL entry points.
However, this is also where we learned the hard lesson as to what we believe caused many of the problems of future industry municipal systems. Our APs were 200mw. Our antennas were directional and approximately 12dBi. Laptops are 30-100mw. Because we couldn’t get approval to bring in more AP’s, there were some areas where clients could see us but couldn’t connect. They weren’t happy. Before I get hammered on why we didn’t have closer AP’s, the first radios that went in were at the end of the halls for coverage and backhaul. We were going to add additional radios later to cover poor signal areas but a change in management at the Stratosphere held up the second phase of the installation. Therefore, we had to live with hitting laptops at distances up to 135’ through several rooms for quite a while.
Nobody designs a Point-to-Point (PTP) system with 2 radios with dissimilar power levels, but that is how Municipal WiFi is implemented. Outdoor WiFi AP’s are typically 100mw to 1W. The end result is users thinking that if they saw bars on their computer, they should be able to connect. This differential caused huge problems for Muni-Wireless deployments with AP’s several hundred feet away trying to pick up laptop through brick, trees, and other obstacles. The patch for Muni-Wireless was to ask users to purchase high-power indoor units to fix that differential. That dampened enthusiasm and created additional interference issues. Another option would be a truck roll of an outdoor radio installed by a technician but that idea was never adopted by any of the bigger companies.
Adapting this idea to a Muni-Wireless model means that early 2.4GHz single radios systems should have been designed with the highest gain aesthetically pleasing antenna connected to APs set to about 100mw. That design would have been more productive, lower cost, and would have reduced the number of connection problems for clients. Ideally, the simplest, least expensive, and best AP would be about 20dBm with a 16dBi omni-antenna. This will deliver the longest range and best penetration bi-directionally with low power clients. Keep in mind I’m not addressing radios specifications, density, interference, or any of the higher tech ideas currently being deployed, just a basic single AP setup. Since we are after a cost effective system, that’s where our focus will be.
Muni-Wireless systems, like any other wireless network are made up of 3 parts:
AP
Transport
Ingress/Egress
We are going to analyze each one of these for the cost/performance benefits of each phase over the next few articles and mix in some of our other installations to demonstrate real-world applications of these components in action. The goal is to demonstrate that it’s cost-effective for almost every city to have some type of system in place. Not every city needs a system that can do everything and with budgets where they are, it may not be realistic. However, defining the needs and expectations before the project will help the project stay within the financial scope of most cities.
With the Google offer demonstrating that hundreds of cities are interested in better bandwidth options, and this design capable of scaling up to 100Mbps per home, it’s evident that there is still a huge amount of interest in municipalities upgrading their infrastructure. Yes, fiber everywhere would be the ultimate option, but as an intermediate and realistic step, and considering Verizon is backing away from FIOS, not only can this system fill that need, but it can be built starting at about $3000 per square mile for a Muni-Wireless deployment. It can also be deployed as a PTMP system for less than $300 per AP location and $150 per household for more remote areas while integrating with the Muni-Wireless system later. The ultimate design is an integrated Muni-Wireless/PTMP structure.
What’s really funny is that cell phone companies that clearly can’t get enough bandwidth on a tower to support all the new smart phone applications, haven’t jumped on this concept nationwide to offload some of the bandwidth needs. In some cities, the cable companies are doing that. In others, the cell phone companies are supporting hot-spot integration. However, they can do 25 square miles with Gigabytes of capacity for less than it costs to put up 1 tower. That’s a discussion for a future article, however.
"Rory Conaway"
"Rory Conaway"
Subscribe to:
Comments (Atom)