This isn’t a how-to article on video surveillance since even my neighbor, the non-technical guy, installed his own system. Most of us have an understanding of how an IP based video surveillance network works. What we want to cover is why all this phenomenal bandwidth we are creating takes video surveillance to another level and why that may or may not be a good thing.
Video surveillance cameras used to use terms like CIF (352x288 pixel resolution) and 4CIF (702x576). Computers used resolutions like VGA (640x480) and SVGA (1024x768). The common denominator in all these is the 4x3 screen ratio. Movie makers marched to their own drums with 16:9 ratios until the standard today is the 1080 level (1920x1080).
With the integration of computers and movies, it was obvious that compression methodology needed to be applied due to the limits of CD-ROMs and bandwidth. Various JPEG and MPEG compressions were developed until MPEG-2 became the most universally used compression method for DVD. However, bandwidth and storage limitations along with increased processor power drove compression through MPEG-4 (still one of the most popular) and others to the current standard of H.264.
So how does this relate to wireless? In the past and all around the country, cameras over wireless were either a very low resolution (CIF), high-compression (blocky or blurry), or had a low frame-rate (5-10 frames per second or fps). A lot of systems with remote locations, like SCADA locations, didn’t even try to move video over the wireless system. Instead they stuck an analog recorder locally with digital output, and then only monitored 1 or 2 of the cameras at a time remotely, regardless of how many were on site, due to bandwidth limitations. Keeping in mind all the bandwidth we have proven we can deliver over wireless systems from the past few articles, the question becomes, what can we now do in the real world? 3 years ago, we deployed a video analytic system with 48 cameras across 100 square miles in North Las Vegas and Boulder City, Nevada using a Puretech PureActiv system and SkyPilot 4.9GHz mesh system, so it’s not a new concept. These cameras deliver CIF resolution at about 12fps due to storage limitations. Since multi-megapixel cameras are the next hottest thing and since I’m involved in one of these projects right, I can tell you where we are going next.
Start with the idea that multi-megapixel IP cameras are now on the market and are cost-effective. For example, a 1080i outdoor camera from Axis like the 3334 or 1755 cost around $1500 or less. There are many other products out there that are even less expensive but I would test them to make sure they can deliver the frame rates you expect under similar conditions. We found that in a couple of the less expensive cameras, they could deliver no more than 12fps even though they were rated at 30fps in that particular resolution mode.
The biggest issue is, how do you use all that video quality? For live displays, we are probably going to have to limit live viewing to CIF resolutions to get 16 cameras on a single display. With 50 cameras, you might need 5 displays, for reduced size images and one for a full size image might be one way to set it up. This kind of negates having HD video. You can use whatever variation you want from this, even if you want a whole wall of monitors. No matter what you do with a few cameras, there will be point where there are too many screens for anyone to look at simultaneously or the real-time images are too small to have value. In reality, there is no realistic way to cost effectively display and watch 50 high-resolution cameras. So where is the value?
In addition to broadcasting a 1920x1080 video stream or higher, the newer cameras can also capture video at up to 5Megapixels. That makes for some fairly impressive images and opens up all sorts of possibilities if you can get it back to a central location for processing. That’s where our big wireless pipes start having value. Imagine the camera shooting snapshot every 20 seconds to augment the high-quality video stream for forensic evidence at trial and dumping these images on a central server.
Currently most people use this much resolution for forensic use. Usually an accident is going to look the same in HD as well as CIF on video. In fact, the higher frame rate has more value than the resolution. However, the higher image quality might tell us who was driving in case there was question of that or reveal a detail such as a braking point based on a car nosing down that the lower resolution may not. In reality, most of the mega-pixel cameras can deliver both high-frame rates and HD quality.
I’m finishing our first deployment right now where all the cameras are HD quality on the fixed and 4CIF or better on the PTZ cameras (HD PTZ cameras weren’t available from Axis when we started the project). With the cameras set to 1920x1080, 20fps, 30% compression, using H.264, we are seeing about 7-8Mbps.
There are two areas where the higher resolution system has much more of an advantage. The first is in the use of forensic evidence at trial. If the subject actually has features that are discernible, then there is a higher chance of prosecution. With CIF cameras, that means either very short ranges or very small viewing areas.
The second and more important use is in the field of Video Analytics. Video Analytics uses a computer to analyze a video stream and look for specific types of activity. It basically turns video surveillance from a forensic device into a pro-active tool. Video analytics have been used in airports and depots to look for loiterers or abandoned luggage. More expensive analytic systems obviously have more features such as license plate recognition and facial recognition. Some video analytic systems can tell the emotional level of the subject or look for abhorrent behavior.
The limitation on analytics has always been resolution, processing power, and algorithms. Lower resolution can’t make out enough details for facial recognition or license plates at any distance and higher bandwidth over wireless (remember, this is a wireless series, not a wired series)has always been a challenge. At the same time, as the resolution increases, the processing power needs increase. For example, it take 4 times as much processing power to handle a 4CIF resolution video stream as it does a CIF vide stream. Expand that up to 1080HD resolution and now an older Dual-Xenon server that could handle 8 CIF streams 3 years ago can’t even handle one HD stream.
Fortunately, between Intel and the gaming industry, the answer is just right before us. Newer Intel processors using the I7 core have some pretty massive power. Jump into the Xenon version of that processor series and its running 6 cores with 6 virtual cores. Double up the Xenon processor and you have more than sufficient horsepower to do any type high-level video analytics.
Since video analytic processing isn’t any different than game processing in terms of the type of hardware needed, the gaming industry has pretty much handed us the answer. High power video cards or GPU’s (Graphic Processing Units as they are generally referred to), can be stacked to multiply the processing power. In fact, it’s possible to use 4 GPU’s in the same computer that’s capable of cracking weak AES encryption in minutes or hours. Maximum PC built a 3 card version of this exact computer. Obviously you want a different hard drive storage combination, but if the software supports the GPUs, here’s the answer.
Improved analytic engines also have the ability to do object recognition. Imagine an Amber Alert that can have every camera in the city scanning for a specific, make, model, and color of a vehicle in real-time in addition to license plates to try to find a child. All of this advanced capability requires 3 things, lots CIF cameras at very short distances for clarity, fewer cameras with very high-definition, and lots of bandwidth to get this data back to a central location. If it’s wireless, that historically has been even more difficult.
The traffic surveillance system design we used in the Town of Sahuarita was based on three things:
1)Budget
2)Capability, currently and in the future
3)System Expansion
7-8 Mbps per camera meant that there needed to be a lot of capacity. Originally the design involved 4 APs with sector antennas covering 360 degrees and up to 400Mbps or more (I told you we would get back the wireless part of the equation eventually). Although the capacity was sufficient when it was originally installed, the RF environment changed while we were finishing the system. I covered the interference issues with the local WISP in an earlier article and after my experience with Atlanta, I decided to change this design over also. With an equipment change of less than $2000, we expanded the capacity out to 800Mbps and simultaneously reduced noise figures from -75 to -92dB or better. Most lights are now PTP links to either City Hall or between each other. Since the use of highly directional antennas on the main building means my beam patterns are now 6 degrees or less, frequency reuse isn’t an issue. I haven’t used the building as my antenna isolation shield yet but that’s coming next as we add more traffic lights.
Uneven terrain also meant AP hopping wasn’t an option. Since budget was an issue and we already had some of the infrastructure in place already, we stayed with the Ubiquiti equipment. Technically this is now a combination PTP/PTMP design. I didn’t use WDS since I needed security features that won’t work with WDS on the Ubiquiti products. And because the Rockets and Nanostations cost less than $100, the highest cost would be a pole with a Rocket M5 with an MTI dual-polarity 5.8GHz flat panel antenna for about $350. However, as the deployment went in, we made some changes and are now using Powerbridges in place of the Rocket/MTI antenna combinations as they have become available. The end result of this design is that every light has an MCS(15) 2x2 MIMO link either directly back to City Hall or in a hop path between lights using the Rockets, Nanostations, and Nanostation Locos. The total cost of all the radio and antenna equipment for 13 traffic lights and 800Mbps of total capacity at City Hall will be less than $10,000 including the 2.4GHz WiFi system that went in simultaneously.
The capability of the system, although it’s still being installed, will provide some excellent prosecutorial evidence when needed. In the case of accidents, the combination of the resolution of the cameras along with the PTZ cameras that are paired with them will allow traffic and public safety the information they need to respond appropriately. In the case of a hit-and-run, the runner is going to have a much harder time getting away with high-resolution images of the vehicle and the plate, when available. If the driver leaves the vehicle, the planned video analytic software with virtual tracking with the PTZ’s are going to keep the driver, now the runner, in camera view much longer for police and give a better picture for recognition.
One other side note is that many of these cameras have audio capability. We already apply analytics to gun-shot detection and window breakage applications. Throw in some audio clues for a crash to support a video analytic rule of two objects trying to occupy the same area at the same time (crash), and false alerts drop.
There is no real growth limit to the system. On the bandwidth side, each traffic light has the capacity to hop several lights if necessary or add additional cameras. On the image side, as computer processing power continues to increase, the resolution and bandwidth is already in place to take advantage of it. This means more sophisticated surveillance tools for traffic, law enforcement, and wireless bandwidth for mobile vehicles. Video analytics are the best way to use the increased resolution an image quality that increased bandwidth capacity can provide.
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 skypilot. Show all posts
Showing posts with label skypilot. Show all posts
Monday, October 18, 2010
Sunday, March 7, 2010
Chapter 3 - Share and Share Alike
Although this was the week that we were going to discuss putting APs on the poles, an incident occurred last week that I think is worth discussing before we go any farther. Always keep in mind that unlicensed bandwidth is a shared commodity. It’s also a good idea to have a relationship with your competitors or anyone in the area that is using unlicensed bandwidth. Sometimes that’s a little hard to do, but it’s definitely in your best interest to try.
Traffic lights and cameras are a perfect application for 4.9GHz or 5.8GHz radios where fiber isn’t installed. For example, we connected several traffic lights in Glendale, AZ a month before the city hosted the 2007 SuperBowl. The entire network consisted of 5.8GHz SkyPilot equipment with Pelco cameras. The system is used to monitor the intersections and also as the SCADA system for the traffic lights. This allows the city to manually adjust the traffic lights before and after events to optimize traffic flow. The city just recently closed on a bid that ADOT managed for the next phase. For some reason that I still can’t explain, they removed the compatibility clause with the existing system and simply went for low bid. Due to the cost of the SkyPilot equipment, it was obvious that low bid would not be SkyPilot or a compatible system but something else. This means the city will now be supporting multiple mesh networks along with the extra long term costs. He who controls the funding; writes the rules but apparently doesn’t have to support it.
That led to another project to connect 13 traffic lights with 50 High-Definition cameras at resolutions up to 1600x1200 pixels. We settled on Axis cameras for this project. The ideal cameras, fixed and PTZ, would be 1080p, 24 frames per second, and H.264. The project came close with most of these specs, but there were some compromises. We either got PTZ and H.264 at 720p, or we got 1600x1200 at reduced frame rates with MPEG-4. Future intersections may get 1080p cameras. This was sufficient to meeting the system requirements for the application which was traffic light management, license plate recognition, video analytics, and future facial recognition software.
Either way, we needed a lot of bandwidth at the City Hall to make this work. There were no other antennas on City Hall. A quick site survey showed additional equipment in the area with fairly low signal levels. The AP chosen was Ubiquiti 802.11N Rockets with 90 degree, 20dBi dual-polarity sector antennas. The system has 4 APs and sector antennas on City Hall for 360 degree coverage. Each light depending on distance to City Hall gets either a Nanostation 5M (integrated antenna) or Rocket 5M (external flat panel sector antenna). We are also adding 2.4GHz 802.11N to all the intersections for future use. It only adds $200 to the cost of each intersection and has an 800’ range to a laptop.
The first AP was turned on about 6 months ago and covered one 3-way intersection with 3 cameras and a second client station for data backhaul to one of the City Parks. The park had maintenance staff and a camera for the skate area. The second AP was scheduled to be turned on this week to cover the next 90 degrees off City Hall. That was when we discovered that between the time we turned on the first base AP and then went back to turn on the second base AP a couple of months later, the IT department had a local WISP put a Motorola Canopy radio on the roof without notifying the traffic department. Even more fun, it was in the 5.8GHz band.
Our traffic system was designed to use all 100MHz of the 5.8GHz band and was designed with signal levels for each link between -50 and -65dBm. Since the general rule is at least 10dB headroom on the link path and the minimum signal for APs with an MCS15 link (130-144Mbps modulation rate), 2x2 MIMO is -75dBm, you try to design for your worst signal at the receiver to be -65dBm. At those signal levels with directional antennas on the client side at 2 miles or less, it’s fairly hard to interfere with this system.
As a courtesy to the vendor, I thought that giving them a call and asking if they could change the Canopy to 5.1-5.4GHz before I turned on any more APs would be the professional thing to do. Unfortunately, when you run into inexperienced WISP technical support staff who think that whatever product they use is significantly better than whatever product you use, there is a problem. The conversation started with me asking if there was any chance that they had other frequency options. The technician asked me what equipment I was using. I replied. He then made the comment, “Our equipment will stomp all over your equipment.” I quickly established that this wasn’t the person to which I needed to speak to resolve this issue.
Every wireless product handles interference in different ways. Better filtering, multiple polarity, diversity, beam-forming, better firmware and many other techniques are utilized to improve the quality of a connection. Obviously some equipment works better than others in high-interference environments. However, 802.11n doesn’t always play very well with 802.11 b/g or 802.11a radios. In addition, physics are physics. Throw in a 2x2 MIMO signal with very a high gain antenna and a total EIRP of 42dBi minimum on both polarities, and there is going to be interference. This is especially true if the competitor’s base station is 1000’ away and their system is based on a 30dBm EIRP signal level from the APs. Since the traffic system was designed with a very high level signal path with multi-polarity 2x2 MIMO, there wasn’t much concern that the local WISP was going to interfere with the traffic system. On the other hand, it was clear that the traffic system was going to cause some interference to the WISP operation. I was wondering if that was already the case.
The last thing I wanted to do was start a war between a city government and a local WISP. Since the WISP was already serving some of the registered voters, this was probably not a good idea. The ego in me wanted to turn the remaining two sector antennas directly at the WISP base station across the street, program the two radios with a channel width of 40MHz to cover most of the 5.8GHz band, turn on 802.11N mode only, start multicasting “Transformers 2” in UDP mode to my other laptop and phone, and crank the power to 48dBm EIRP. I felt there might be a lesson to teach on RF, signal-to-noise ratio, and how to be polite when other companies are trying to do the right thing. Instead, I called back and talked to upper level management to arrange a meeting to see what can be done. That’s when I found out as I had suspected, that the traffic system’s first AP possibly might already been causing some interference issues. Unfortunately that traffic system AP also serves the City Park and has been running for several months. As a courtesy, the best I could do was to turn the power down until we plan out a more cooperative strategy with the WISP.
Now we can come back to our design. The AP combo we are considering will have an EIRP of up to 36dBm and will be 802.11 b/g/n compatible in 2.4GHz. That is far more powerful than most indoor systems. There are ways to limit the interference and everyone sharing those bands should consider this. It’s good policy to always engineer for the least amount of power that you need. Also, you should consider using the least amount of bandwidth. If you don’t need a 40MHz channel, don’t use it. You gain 3dB on the receiver side with no more power if you use a 20MHz channel. Drop to 10MHz and you pick up 3dB more, etc… The tighter the channel, the better chance you have of getting a signal through.
There are many of you that may not even want b/g compatibility. If the system is only used where you control both the APs and the client radios, then you have some options. In that case, using 802.11N only is the best way to go. This results in fewer APs and better performance. It’s also possible in this same scenario to get as many as 100 users on an AP or as many as 300-400 on a single pole. If all the equipment is the same manufacturer, consider a 5-10MHz channel which will still deliver 12-25Mbps per AP. Running 2x2 MIMO doubles the throughput to 25-50Mbps in a 5MHz channel. This is probably more than most of us need for a link. With a 5MHz channel, there are 6 channels to work with in 2.4GHz instead of just 3.
Whatever gets installed will probably interfere with other existing systems. We have to be cognizant of the fact that nearby systems might be critical for hospitals, voice systems, video surveillance, office networks, etc. For example, a few years ago, we saw an outdoor AP in Scottsdale stadium take down a wireless voice system at a nearby hospital. Since we put our phone number in the SSID, they could contact us quickly. We adjusted our antennas and resolved the issue. Site surveys have to be done everywhere to understand the ramifications of the install in addition to understanding your own coverage zones.
Based on all this, if I saw a little Motorola Canopy radio on the roof and thought it was a good idea to possibly contact that vendor, what was the installer thinking when he saw all the Ubiquiti equipment along with a Motorola PTP600 radio? He obviously didn’t do any kind of site survey. The reality is that this is standard procedure for most companies.
Many companies that rent roof space for APs do it from some type of property management company. There is usually no bandwidth management on the roof. When someone finally overlaps frequencies, an avalanche of problems will start. For example, administrators may turn up power to overcome the interference if they have no other options which causes even more problems (this gets into noise and channel filtering). The responsible thing to do would be to notify all parties involved and see if there is a way to work together. Obviously this sentiment is not shared by everyone, or some field installers aren’t trained well enough to watch for this situation. Then again, they just may not have cared.
Unless I run into another tech support person who hasn’t been taught the concept of cooperation and I need to vent, we will get back on our project next article. I’m still working on some FCC equipment certification issues with the design. Not that we can’t do it but I want maximum performance and the equipment I need isn’t quite yet available. I’m also waiting for new products to test that may enhance the system. Anybody can build a system with unlimited budget. The fun is creating a carrier class dependable system on a shoestring budget; since, that’s what most cities have in their coffers these days. Any new products that have the potential to help preserve that coffer is going to get their attention. Next article, we get back to work.
Subscribe to:
Comments (Atom)