City Mesh Wireless Surveillance RFP Examined

In this update, we examine a US city's RFP for a city-wide video surveillance system including a public safety mesh network. The RFP includes a large list of performance specifications, with no specific products being mentioned, leaving the actual system design up to each individual respondant.  The municipality will then potentially create a “short list” which may require one week trials of systems to be installed at no charge.

Review the full video surveillance RFP document [link no longer available].

Let's first examine the city’s current system and needs:

• The Radio Communications Department of the city runs multiple tower sites currently used for wireless connectivity.
• Currently 28 pole mounted surveillance cameras are installed throughout the city.  The cameras are recorded to a local DVR, with Pelco Net350 (a discontinued model) used for viewing and control. Video is accessible via a “non-standard access point”. These cameras shall be integrated over new mesh wireless network.
• The city is looking for a major addition to the wireless network to provide service for: “video surveillance, Advanced Metering Infrastructure (AMI), applications used by public safety agencies, public service agencies, Web access, e-mail access, and other portable computing applications.”
• "In addition to mobile clients, , the dense service area must support at least 70 surveillance cameras streaming 1Mbps through the network. The sparse service area must support at least 10 surveillance cameras streaming 1 Mbps through the network. These cameras may be relocated to any place within the service area, mounted 10-30 feet above street level."
• The network is to be highly available, fault tolerant, and resilient: "High availability. Delivers more than 99.99% availability within the mesh network coverage area. Fault tolerant and redundant. Provides automatic fail-over protection at multiple levels, including at the wireless link and the connection to the wired network. Interference resilient. Offers protection against local environmental disrupters and resiliency for interference." and "Offers fully redundant coverage over 95% of the center-line street mileage that can be navigated by a car in the proposed dense mesh service area and 95% in the proposed sparse mesh service area"
• “The Digital Network Video Recording (NVR) system must be capable of recording a minimum of 100 video cameras without adding any additional software licenses and/or server hardware and storage. The recording system shall be capable of recording and storing up to 30 days of video for all cameras. The system shall also incorporate a data archive system for optional off-line storage of video data for up to three months.”
• 2.4 GHz, 4.9 GHz and 5.8 GHz frequency ranges are allowed.
• Requirement to integrate to a long (relatively speaking, for the surveillance industry) list of third-party analog DVR’s and NVR’s.
• Rigorous validation: "End-to-end throughput testing from spot locations within the coverage area; Verification of security and VPN functionality; 14 day reliability test; Validation of link and network fail-over mechanisms"

The RFP is quite lengthy, and generally well-written and clear.  As is noted, “The purpose and intent of this solicitation is to establish contract(s) with qualified responsive and responsible proposer or proposers, whose proposal responses are advantageous to Metro, taking into consideration the evaluation factors set forth in this RFP.”  Overall, the city’s intent is good, but some requirements may be difficult to meet.

Our observations:

• Well Written, Open RFP: Unlike most RFPs we see, this document avoids the common problems of hard spec'ing, secretly requiring a specific product or asking for conflicting requirements. While the requirements are challenging, this is likely to be a fair bid.
• Expensive Complex System: With the extremely high reliability, redundancy and coverage requirements, this is going to be a very expensive, complex system to design and deploy. In wireless equipment cost alone, we would anticipate a few hundred thousand dollars cost assuming approximately $2,000 per mesh wireless node. In addition, the planning and on-site optimization will need to be extensive to overcome vegetation, buildings and other obstacles.
• Good Validation Process: The city's plan to do a variety of tests over multiple weeks will put healthy pressure on vendors to ensure that the network is robust. While availability specifications are sometimes hard to prove up front (e.g., 99.99%), the validation / commissioning tests should help prove that the system is robust.
• Multiple applications: The RFP states that the mesh network and associated backhaul to be built out as part of this project will be used not only for video surveillance, but for Advanced Metering Infrastructure and other services required by public agencies.  This is a good move on the City’s part, and extends the network’s usefulness, and provides them better return on investment.  We would guess that more grant funding would be available for networks serving multiple purposes, as well.
• Old equipment: The city would like to reuse whatever possible from their existing 28 camera locations. The current cameras, assuming they provide usable image quality, should be reusable via encoders. The existing encoder, the Pelco NET350, is discontinued, and not supported by all VMS’s. Integrators supplying Milestone, for example, would be at an advantage, since this encoder is supported by XProtect, and could be reused.
• VMS Server/Storage: Given the scalable nature of IP video, we question why the system should be licensed for a minimum of 100 cameras from the start.  By our count, there will be 38 cameras recorded during this phase (28 existing plus ten additional).  This seems an added up-front expense that is not required if they are not deploying 100 cameras immediately.  Additionally, storage costs could be drastically lowered by providing only the storage needed for the initial deployment.  Occasionally, however, front-loading costs in the initial phase is done simply because the money is available now, and given the volatile nature of funding for projects such as this, this may be a smart decision, if it is the case.
• Bandwidth Concerns: The RFP states that the network should support a minimum of 1Mbps bandwidth per each camera.  It further goes on to state that cameras will be streaming MPEG-4 or H.264, 640x480 resolution, typically 8 IPS, with 30 IPS “burst speeds” required.  An 8 IPS MPEG-4 stream, by our calculations, may take 1Mbps or more, with 30 IPS streams coming in over 2Mbps.  This will lead to one of two problems: First, the link will simply not support the bandwidth required and frames will be dropped, or second, the integrator chosen will reduce the quality of camera streams to fit within the given parameters.
• Imaging range concerns: The RFP states: “For street and land cameras, Image quality should be high enough to be able to identify cars and personnel at distances up to 1,000 feet. For bridge and waterway cameras: Image quality should be high enough for monitoring the waterways both upstream and downstream for a minimum distance of at least .5 miles and a potential maximum distance of up to 2 miles.” As we found in our report "How far can a PTZ see?", range of PTZ cameras is routinely believed to be greater than it actually is.  We found that identification was unlikely beyond about 600’, and at half a mile, only monitoring-quality video would be provided, enough to see that a subject is present.  In order to even hope to achieve these extreme distances, pan/tilt positioning systems would be required (such as a Pelco Esprit [link no longer available]).  These units add substantial additional cost and much slower movement speed.  Alternatively, the city may be satisfied with detecting people and cars rather than identifying individual people (i.e., it's a tall man rather than the subject has brown eyes, a mustache, a scar on his left cheek, etc.).
• Integration to third party systems: The RFP provides a long list of integrations they would like, to be accomplished via software only.  The list includes GE, Exacq, Pelco, and Honeywell.  We know of no product currently supporting all of these recorders.  The most probable choice for this integration is a PSIM product, which would drive the cost of the project through the roof.  Additionally, while maintaining existing hardware is often seen as the least cost path to integration, it brings additional complications in the form of ongoing support and maintenance.  Attaching existing analog cameras to a new encoder is often a lower-cost method.
• Backup power requirements: No requirement is given for backup power of cameras or mesh equipment.  In the list of possible mesh node locations, it does list whether the location has existing UPS (presumably for traffic signal equipment).  Not all locations have this capability currently, and the lack of a requirement for backup power will leaves future equipment to be installed as part of this RFP susceptible to power failure. However, given the 99.99% general requirement, responders will essentially have to provide backup power to have any chance of delivering such high availability.
• Vendor Selection: The city has laid out a good framework for selection of vendors, including a possible one-week pilot program at no cost to them, from each of the “shortlisted” vendors.  This allows the city to get a better idea of what they will realistically see and how it will perform. Integrators may be wary of this practice, however, as it exposes certain intellectual property, and obviously requires a fair amount of labor on their part.