In many deployments, it is convenient to use
point-to-(multi)point wireless links to stream IP cameras from remote locations
back to a central network video recorder (NVR).
Sizing these wireless links is
critical to the performance of the camera recordings. The number of cameras per link depend on
several factors, but at its simplest, it is the ratio of the average bandwidth available
on the wireless link over the average bandwidth consumed by each camera.
Specifying an appropriate wireless link:
The available bandwidth of the link depends on numerous factors, including the technology being used (i.e. 802.11n, 802.11ac, proprietary), the frequency and channel size, and the distance. For most video surveillance applications, the link distances are very short (<< 1000 feet), so it is generally convenient and economical to use WDS links in the unlicensed 5 GHz spectrum for such applications.
There are, of course, numerous vendors in this space offering a wide range of products at a wide range of prices. One product that I have successfully deployed on several video surveillance applications is the EnGenius EnStation5 (MSRP of $240 per pair), which is a point-to-(multi)point radio based
on 802.11n 5 GHz with 2x2:2 MIMO streams. It is quite reliable, very easy to configure, very easy to mount, and has a measured sustainable throughput of just over 80
Mbps (1000' shot, 40 MHz channel, no interference).
Whatever brand, frequency, and capacity of wireless link you choose, it should always be measured for the actual average throughput under sustained load once the links are mounted and online. I generally recommend designing to use only a 50%
average load across each wireless link. This is to leave margin for several sources of variation, including:
- Instantaneous camera bandwidth consumed due to image compression ratio variations
- Instantaneous link bandwidth available due to external interference
- Accommodation of those “last minute additions” of a few cameras to the link, which always seems to happen on camera projects
It is also not uncommon for large and complicated
properties to have multiple links in parallel as well as multiple links in series. Thus,
when creating a network of point-to-point and point-to-multipoint links, the load across the entire path between the demarc (where the NVR server is located) and the cameras must be taken into account.
Specifying the average load per camera:
The amount of data streaming from each IP camera depends on
several factors, including:
- Image size
(i.e. number of pixels per frame) - Color depth
(i.e. the number of bits per pixel) - Frame rate
(i.e. number of images per second) - Video Compression Ratio
(i.e. dependent upon technology such as H.264, MPEG-4, or MJPEG and the image itself) - Duty cycle
(i.e. for cameras that only stream data when motion occurs)
Obviously, the lower the image quality (fewer pixels, lower
duty cycle, lower frame rate, lower color depth), the less bandwidth required per
camera, but the worse the quality of the image. Make the image quality too low, and the recorded video will not be useful for the desired application. Make the image quality too high, and you are consuming a lot of bandwidth that is not necessary.
For a typical video surveillance application, I use H.264 compression with an average compression ratio
of 100:1, 10 frames per second, assume a full duty cycle (though generally use the motion detection capabilities of the camera), and high color depth. With these parameters, the average data per camera and number of cameras per 802.11n 2x2:2 40 GHz channel link are as follows:
-
1.0 MPixel / 720P HD: 1.92 Mbps (up to 21 cameras per link)
-
2.0 MPixel / 1080P HD: 3.84 Mbps (up to 10 cameras per link)
-
3.0 MPixel:
5.2 Mbps (up to 8 cameras per link)
-
5.0 MPixel:
6.4 Mbps (up to 6 cameras per link)
-
10.0 MPixel:
14.4 Mbps (up to 3 cameras per link)
These numbers need to be scaled upwards and downwards appropriately
based on the parameters you are using for number of frames per second, duty
cycle, and image quality.
Why not just deploy the cameras wirelessly?
I'm often asked
about deploying remote IP cameras wirelessly by deploying access points
and using the camera's built-in Wi-Fi capabilities. I am usually very
resistant to such plans. First and foremost, you still need to get power
to the camera, so a wire (typically a CAT5e cable with a PoE injector)
always needs to be run to the camera. More importantly, even for
high-end and expensive IP cameras, the vendors usually incorporate the cheapest 2.4 GHz
only chipsets they can find. Thus, in addition to being very poor Wi-Fi clients, the 2.4 GHz band is generally extremely crowded with a lot of external interference, making it quite unsuitable for any real-time streaming video applications.
Hence, for remote camera applications, always deploy point-to-(multi)point links and use the wired Ethernet link on
the camera to provide both power and data. When the remote location has
two or more cameras, deploy a PoE switch to power both the
cameras and the remote end of the point-to-(multi)point link, so as to
get full data communication and only use one electrical outlet. For a
location with only one camera, cross-connecting PoE injectors is
generally more efficient and economical, even though two electrical
outlets are required.
No comments:
Post a Comment