WHITE PAPER Canopy Wireless Broadband Platform · 2009-08-17 · Motorola Canopy is a Broadband...

WHITE PAPER

Canopy Wireless Broadband Platform ®

Issue 1 August 2006

Canopy Video Surveillance Architecture White Paper

Canopy – Video Surveillance Architecture – White Paper

Issue 1, July 2006

Notices

The vendor data in this White Paper derive from the Motorola Canopy® System User Guide and HotZone User Guides. Motorola provides this vendor data for Canopy user’s information only and does not provide any recommendations.

Please refer to the Canopy System User Guide, posted at www.motorola.com/canopy for:

Personal safety guidelines in Preventing Overexposure to RF Energy

Important regulatory and legal notices

Trademarks, Product Names, and Service Names MOTOROLA, the stylized M Logo and all other trademarks indicated as such herein are trademarks of Motorola, Inc.

® Reg. U.S. Pat & Tm. Office. Canopy and MOTOMESH are

trademarks of Motorola, Inc. All other product or service names are the property of their respective owners.

© 2006 Motorola, Inc. All rights reserved.

http://www.motorola.com/canopy

Canopy Video Surveillance

PTMP, PTP Backhaul & Mesh Solutions


Issue 1, July 2006

Table of Contents

Table of Figures .....................................................................................................................................4

New in This Issue...................................................................................................................................5

Using This Canopy – Video Surveillance Architecture White Paper..................................................5

Searching This White Paper .................................................................................................................5

Getting Additional Help..........................................................................................................................5

Canopy – Video Surveillance Architecture White Paper.....................................................................6

1.0 Abstract ........................................................................................................................................6

2.0 Business Case for Video Surveillance .......................................................................................6

2.1 Canopy/HotZone-based Surveillance Business Opportunities ................................................8

3.0 Video Surveillance Terminology .................................................................................................9

4.0 Span of Video Surveillance Applications .................................................................................11

4.1 Overview of Video Codec’s .......................................................................................................11

4.2 Special Outdoor Surveillance ...................................................................................................14

4.3 Example Cameras .....................................................................................................................15

4.4 Example Video Recorders ........................................................................................................16

4.5 Video Command Center............................................................................................................17

4.6 Video Packet Statistics..............................................................................................................18

5.0 Overview of Canopy for Video Surveillance ................................................................................19

5.1 Canopy PMP ..............................................................................................................................21

5.2 Canopy PTP...............................................................................................................................22

5.3 Canopy HotZone WI-Fi Mesh ...................................................................................................22

5.4 Canopy PMP Specific Multicast Video Considerations...........................................................23

6.0 Summary and Conclusion.............................................................................................................24

Additional Resources...........................................................................................................................25


Issue 1, July 2006

Table of Figures

Figure 1: Canopy Supporting Video Surveillance...............................................................................7

Figure 2: Example QVGA at various FPS and throughput. .............................................................12

Figure 3: Example PAL CIF capture at very low bit-rate..................................................................14

Figure 4: Example ANPR cameras and illuminators – Extreme Surveillance. ...............................14

Figure 5: Three example outdoor and ruggedized IP cameras.......................................................15

Figure 6: Example of same camera in indoor and outdoor versions – D-Link DCS. .....................15

Figure 7: Example Sony SNC-RZ30N Pan-Zoom-Tilt in outdoor enclosure. .................................15

Figure 8: Illustration of “Siamese” RG59 coax with two 18-gauge wires for power. ......................16

Figure 9: Typical 16-camera DVR – Dedicated Micro BX2. ............................................................16

Figure 10: Example NVR Video Server – Boundless Security System. .........................................16

Figure 11: Generic Video Surveillance Command Center – Uptime Business Products. .............17

Figure 12: Example of defining motion detection “zones” – ZoneMinder. ......................................17

Figure 13: Release 8 AP Option 1 “Block SM destined packets from being forwarded”...............23

Figure 14: CMMmicro Uplink/VLAN Port Configuration section......................................................24


Issue 1, July 2006

New in This Issue This document is Issue 1 of the Canopy – Video Surveillance Architecture White Paper. This section is a placeholder where changes will be listed in future issues.

Using This Canopy – Video Surveillance Architecture White Paper This document should be used with following Motorola Canopy™ documentation:

- Canopy Video Surveillance Marketing Collateral www.motorola.com/canopy/solutions/videosurveillance

- Canopy System User Guide • Important: Visit the Canopy Support Web Site to download the latest Canopy software and

Canopy User Guides. http://www.canopywireless.com/support_home.php

Searching This White Paper

To search this document, look in the Table of Contents for the topic. To find information based on any expression used in this document, open the document in an Adobe Reader

® session and

Use the page numbers at the bottom of the screen and in the thumbnails. These match the page numbers in the Table of Contents.

Use the Edit Search command (or Ctrl+F) to find a word or phrase.1

Getting Additional Help To get information or assistance as soon as possible for problems that you encounter, use the following sequence of action:

1. Search this document, the user manuals that support the modules, and the software release notes of supported releases

a. in the Table of Contents for the topic.

b. in the Adobe Reader® search capability for keywords that apply.

1

2. Visit the Canopy systems website at http://www.motorola.com/canopy.

3. Ask your Canopy products supplier to help.

4. Gather information such as

the IP addresses and MAC addresses of any affected Canopy modules.

the software releases that operate on these modules.

data from the Event Log page of the modules.

the configuration of software features on these modules.

Run Gather Customer Support Tool within CNUT

5. Escalate the problem to Canopy systems Technical Support (or another Tier 3 technical support that has been designated for you) as follows. You may either

send e-mail to [email protected].

call 1 888 605 2552 (or +1 217 824 9742).

1 Reader is a registered trademark of Adobe Systems, Incorporated.


Issue 1, July 2006

For warranty assistance, contact your reseller or distributor for the process.

Go to page 25 for Additional Resources

Canopy – Video Surveillance Architecture White Paper

1.0 Abstract

Motorola Canopy is a Broadband Wireless Access (BWA) technology intended for the fixed and nomadic (“portable”) market and employing unlicensed electromagnetic spectrum over metropolitan distances. The customer edge of Canopy is an Ethernet cable to a local Internet typically consisting of one or more computers and/or IP routers. Historically the customer’s network is intended for “data”. Additionally the Canopy “edge” used with Canopy HotZone (2.4GHz WI-Fi Mesh) can be extended to include another tier of wireless access, namely outdoor WI-Fi.

Increasing video surveillance is seen as a data application based upon a streaming IP packet flow. The video camera is often termed an “IP camera”. Hence video surveillance cameras “stream” compressed video to a centralized Surveillance Control center or a centralized Network Video Recorder (NVR).

Of course the network bandwidth for video, even compressed video, is substantial. One way to minimize real time wireless network throughput needs is to employ a remote “digital video recorder” (DVR). In this case the video is recorded at a high resolution and frame rate but only fewer frames and a lower resolution are sent to the centralized Surveillance Control center in real time.

This new surveillance video service opportunity has Canopy operators wondering if and how Canopy-based BWA plays a role in the resulting video surveillance deployment.

This White Paper documents the general surveillance business, classifies the variations possible, indicates the range of video equipment, and then focuses on how Canopy Broadband Wireless Access (BWA) and associated Canopy HotZone outdoor WI-Fi Mesh may be used for video surveillance.

All non-Motorola vendor examples and their characteristics are derived from publicly available material, and are included only to represent possibilities.

2.0 Business Case for Video Surveillance

In this section a short review of the Canopy BWA architecture is provided for setting the stage for a video surveillance discussion.

Figure 1 shows the Canopy operator’s network with Canopy Base Stations and customer Subscriber Modules. Note the carrier’s network consists of links between packet switches, usually IP routers. In addition the carrier’s network is interconnected to one (or more) other Internet Service Providers to attain global Internet connectivity for the carrier’s BWA customers.


Issue 1, July 2006

Figure 1: Canopy Supporting Video Surveillance.

Historically this network architecture is for “data”, which excludes applications which have extraordinary performance requirements like the bandwidth usually associated with video. Now, however, steaming “IP video” and remote video surveillance have become big business and growing rapidly.

Figure 1 also shows how Canopy BWA and Canopy HotZone (2.4GHz WI-Fi Mesh) support outdoor video surveillance. Of course indoor video surveillance is also big business but is often supported via wired network infrastructure

One scenario is on the left of Figure 1, namely directly attaching an IP camera via RJ45 cable to a Canopy SM. In this case the various cameras are using Canopy in a Point to MultiPoint (PTMP) mode.

The middle scenario in Figure 1 shows a Canopy SM directly RJ45 cable attached to a Canopy outdoor WI-Fi Media Gateway Access Point; this is Canopy HotZone. Thus a second tier of wireless communication is maintained, with the WI-Fi GW in communication with a set of WI-Fi-based IP cameras. In this case the “WI-Fi” GW could also communication via “mesh” to other Canopy APs. As is always the situation the aggregate throughput of the set of WI-Fi-based IP cameras is the limiting factor. If required the Canopy backhaul could alternately a Canopy PTP deployment.

The scenario on the right of Figure 1 shows a remote DVR directly attached to a Canopy SM. In this case four Closed Circuit TeleVision (CCTV) video cameras (not IP cameras) are shown directly attached to the remote DVR. As indicated the CCTV cameras employ RG59 coax plus copper power combined into one so-called “siamese” cable; each cable can be up to 600 feet in length. The remote DVR is directly RJ45 attached to a Canopy SM or high capacity BH. The advantage of this third scenario is that the video is recorded in high resolution and frame rate but is stored locally (that is, at the remote site). In real time the DVR is also transmitting back a lower resolution lower frame rate equivalent to the Surveillance Command center. Only during “off peak” times (in the middle of the night for example) is the full quality video “uploaded” to the central site.


Issue 1, July 2006

In this latter scenario the illustrated remote DVR is also sometimes termed a remote multi-stream video server.

An important network architecture point is making a decision as to whether the video surveillance wireless backhaul network is dedicated (to surveillance) or whether the network also supports non-video surveillance applications.

In general, video surveillance is very “uplink” bandwidth biased, particularly as video clarity (resolution) expectations are rising constantly. To better accommodate this uplink bandwidth need time division duplex (TDD) systems like Canopy are often configured for 20% downlink/80% uplink. This is opposite the usual Canopy “duty cycle”, meaning that video surveillance and the usual client/server computing are largely incompatible. Thus, in general, any significant video surveillance complex can easily warrant a dedicated wireless backhaul network.

Consequently, in context, the Canopy complex is assumed to be dedicated to the IP-based video surveillance task. We assume that the IP video cameras are “remote”, that is, off Canopy SMs. Further we assume that one “Surveillance Command Center” is a centralized facility only indirectly (via the Internet) connected to the Canopy complex.

This Whitepaper does not address the casual use of video surveillance in an otherwise ordinary Canopy “data” context. Additionally, this Whitepaper does not discuss a dedicated IP-multicast video surveillance context in which multiple Surveillance Command Centers each receive identical video streams.

Given this assumption the dedicated wireless backhaul network does not need explicit QoS-related configuration, as all traffic is the same priority and all the network’s resources are available. Thus IP DiffServ or Ethernet VLAN tagging are unnecessary and inappropriate as Canopy configuration settings. Additionally, Canopy’s Committed Information Rate (CIR – a lower bound on throughput) and Maximum Information Rate (MIR – an upper bound on throughput), are also not needed in a dedicated Canopy-based wireless backhaul video surveillance application.

This paper discusses significant video surveillance business opportunities possible for a Canopy BWA operator in which a dedicated Canopy-based wireless backhaul infrastructure is assumed. In particular we discuss the terminology and how Canopy BWA and Canopy HotZone WI-Fi Mesh can reduce surveillance costs.

2.1 Canopy/HotZone-based Surveillance Business Opportunities

In many instances video surveillance cameras must be located at sites without a cost effective wired infrastructure being available. This leaves wireless video backhaul (PMP or PTP) as the only alternative.

A Canopy operator has several business opportunities in this new emerging industry.

1. Canopy operator is a wireless backhaul provider for some other third party’s deployment of video surveillance equipment. This might be a private business or a local government.

2. Canopy operator owns, deploys, and operates all the video surveillance equipment except the centralized video Surveillance Command center (which remains in third party entity).

3. As in opportunity above but the Canopy operator additionally owns, deploys, staffs, and operates the centralized video Surveillance Command center.


Issue 1, July 2006

In effect in Case 1 the Canopy operator remains in the specific and historic wireless access business, just providing the necessary Point to Multipoint (PMP) or Point to Point (PTP) backhaul for a new distinct application.

In Cases 2 and 3 the Canopy operator necessarily adds a new line of business to the historic Canopy-based network.

In the latter the “learning curve” and capital necessary is a large challenge as well as opportunity.

The remaining part of this White paper is devoted to:

1. Informing the historic Canopy operator of the video surveillance terminology and technology with the idea of lessening the otherwise steep learning curve.

2) Overview of Canopy for Video Surveillance

3.0 Video Surveillance Terminology

In this section some of the surveillance industry’s terminology is presented, followed subsequently by more specifics of surveillance technology. Unfortunately the terminology is so specialized and distinct from ordinary wireless vocabulary these meanings are necessarily situated here.

• CCTV Cameras – Closed Circuit TeleVision cameras; standard analog video cameras with coaxial cable output.

• Digital TV – Ordinary television is digitized to about 250Mbps (720x480 resolution), whereas High Definition TV is digitized to about 1.5Gbps. Ordinary TV has resolution of 720x486 (D1 NTSC) or 720x576 (PAL).

• DVR - Digital Video Recorder takes CCTV camera input and records the video stream for storage and retrieval. The necessary coaxial cabling necessarily limits the proximity of the CCTV cameras.

• NVR – Network Video Recorder; unlike a DVR a NVR, is an Ethernet-port device that accepts an IP-based video stream from the network. Cameras are not directly attached to a NVR and so can be anywhere on the worldwide Internet assuming the throughput necessary is achievable.

• IP Camera – A video camera embedding a codec sending an IP-based steam of video packets toward a NVR. The link is either wired RJ45 Ethernet cable or wireless; the latter may be proprietary or increasingly common based upon IEEE 802.11 WI-Fi technology. Note the Internet is used to backhaul a real time video stream of some quality for remote viewing and storage. The IP camera is really a “video server” and is “IP managed”.

• Sensor technology – The visual image is captured by a camera either through a Charge Coupled Device (CCD) or the newer Complementary Metal Oxide Semiconductor (CMOS) sensors. The latter is the senor of choice. Sensors are classified in pixels but sensor pixels and display pixels have no direct correspondence.

• Interlaced display – Ordinary TV overlays two “screens” by interlacing the scans of two successive “pictures” taken 1/60 of a second apart. Note a “picture” then consists of a “frame” every 1/30 of a second. This is unlike computer monitors, in which only one non-interlaced “screen” is show at any instant.


Issue 1, July 2006

• Non-interlaced display – Computer monitors display a single “picture” frame at so rate, typically stipulated in Hz. This type of frame rate is adjustable to whatever level of “motion” clarity is desired. While computers normally show 60Hz frames per second (the same rate as ordinary TV scans) the rate may be configured to be much lower, as in the surveillance “situation awareness” context.

• Resolution – The spatial quality of a picture; usually expressed as “pixels” (picture elements). Higher resolution means more pixels and hence for storage. Most computer displays today are 1280x1024 pixels but are always “improving”.

• Color depth – Each pixel needs to store three colors; each color needs some level of granularity. For example 8-bits permit 256 levels of color granularity. If so then the three colors need 24-bits so provides “16 million colors”.

• Color – Ordinary TV is YUV (“luminance/chrominance/color” with many variations) but computers use Red/Blue/Green displays (RBG, with some variations).

• Bits per Frame – The total number of bits needed is the product of the number of pixels (resolution) and the “color depth”; for example 1280x1024x24 bits per single frame. This repeated at the frame rate, say 60Hz.

• Network throughput – the bits/second resulting from a given resolution, color depth, and frames per second; for example 1280x1024x24x60 = 1,887,436,800 bps. Note this 1.9Gbps rate is impractical to send over the internet. Note also that this is higher even than HDTV.

• Video compression – Given that digital video bit rates are impractical to store or send over a network much technical work has gone into compressing the bit rate need. If the original picture must be recovered exactly the compression is said to be “lossless”; otherwise the compression is “lossy”. Most video compression is “lossy” but still yields surprisingly good quality. Note a 1000:1 lossy compression will reduce 1.9Gbps to 1.9Mbps, still quite high. Consequently, in practice, either the resolution, or the color depth, or the frame rate must be reduced, and possibly all three in combination.

• Codec – Contraction of “compression decompression” or “coder decoder”; the vehicle of actually producing and recovering a compressed video stream.

• Fourcc – an industry “standard” 4-character code stipulating a particular codec type. See www.fourcc.org for details.

• File type extension – Some computer applications rely on a “file type extension” (e.g. “txt” or “exe”) to indicate the file content. In the video realm common “file types” are AVI, MOV, RM, MPEG, etc. However these do not indicate the codec used in a video context, but are only “wrappers”. Consequently any particular “file type” (say AVI) can embed many different codec videos; an internal “fourcc” code indicates which. All video applications actually query the included “fourcc” code.

• MJPEG (Motion JPEG) and MPEG4 (MP4) – Mentioned as the most common surveillance codec’s, each of which has variants. In particular MPEG4 “part 10” Advanced Video Coding (AVC), also known as H.264, is the going forward video surveillance codec of choice. There are several “profiles” within the MPEG4/AVC/H.264 standard, with the “baseline profile” BP probably sufficient. The “extended profile” XP is the streaming video with is more robust against packet discard, etc.


Issue 1, July 2006

• MPEG-4/AVC/H.264, while an international standard, requires the payment of license fees for obtaining professional implementations or selling media. Consequently several “open source” implementations exist, namely “x264”, “libavcodec”, Nero Digital, Apple QuickTime 7.0, and others. DivX appears to be a “H.264-like” implementation but does not claim anything beyond being the “MP3 of video”.

• CBR, VBR – Constant Bit Rate, Variable Bit Rate. Video is nominally CBR but some codec’s are “smart enough” to lower the bit rate if the video scene changes very slowly. VBR is essentially another form of compression.

• ISO, ITU, JPEG, MPEG – International Standards Organization, International Telecommunications Union, Joint Photographic Experts Group, Motion Picture Experts Group. Some of the many standardization entities defining video formats.

• PTZ – Pan, Tilt, Zoom; a camera controllable in real time by a human operator or motion detector.

• KB, MB, GB, TB, PB, EB, ZB, YB – Kilo Bytes (1000B), Mega Bytes (1000 KB), Giga Bytes (1000 MB), Tera Bytes (1000 GB), Peta Bytes (1000 TB), Exa Bytes (1000 PB), Zetta Bytes (1000 EB), Yotta Bytes (1000 ZB). A large video surveillance application needs storage measured in at least TB.

4.0 Span of Video Surveillance Applications

There are many levels of video surveillance need:

• Monitoring – typically 320x240x30fps

• Situation Assessment – typically 320x240x5fps

• Emergency Response – typically 160x120x10fps

• Investigations – typically 640x480x5fps

4.1 Overview of Video Codec’s

Currently the two most common codec’s used in video surveillance are Motion JPEG (MJPEG) and MPEG-4. Often a modern video surveillance camera provides both codec capabilities.

JPEG is a still image technology, and Motion JPEG (MPEG) is a variant. It has advantages in the video editing area and is used extensively in the ordinary interlaced television industry. In particular MJPEG allows the video to be “stopped” on exactly one frame. This is advantageous in forensic surveillance as well, as the “motion” can be stopped on one frame providing superior identifiable features, for example.

Low quality 10fps MJPEG consumes about 183Kbps using 20pps with each packet about 1200 octets. High quality 10fps MJPEG consumes about 418Kbsp using 40pps with each packet about 1300 octets.

While MJPEG is widely employed in video surveillance the newer standard is technically superior; consequently we confine further discussion to MPEG-4. The primary advantage of MPEG-4 is its reduced bandwidth demands on the intermediate packet network, a key property for any wireless deployment.

Unlike MJPEG, MPEG is designed explicitly for motion video. Over time MPEG-1 became MPEG-2 became MPEG-3. Now MPEG-4, dating from about 2003, is starting to


Issue 1, July 2006

become widely deployed. However, even MPEG-4 has variants in the form of “parts” and “profiles”. Nevertheless MPEG-4 is seen as the going forward technology for many applications including video surveillance.

In particular the MPEG-4 variant called “part 10” has been additionally codified as ITU-T H.264, and as ISO/IEC 14496-10. To distinguish other variants of MPEG-4 it is always sufficient to state H.264 when meaning exactly MPEG-4 part 10. Alternately this same technology is termed Advanced Video Coding (AVC).

Some video camera vendors make fine distinctions. For example the SONY SNC RX550 camera specification has “JPEG/MPEG-4” and “H.264” as separate attributes. The distinction here is that the former is capable of up to 30fps at its highest resolution (640x480) whereas the latter only 10fps at the same resolution.

Note for video surveillance 10fps is very adequate so the reduced bandwidth of H.264 is reason enough to select this codec.

One might think that stipulating the camera’s resolution and frames per second (FPS) would exactly result in a bandwidth throughput need. However, even stipulating the resolution and FPS the IP camera may be configured for a particular bandwidth within some bandwidth range. That is the codec algorithm is capable of meeting a resolution, FPS, and BW stipulation. An example of this is shown in Figure 3, which shows screen captures of the properties of five H.264 data streams as presented by Apple’s QuickTime 7.0.

In Figure 2 the only important point is the title, which indicates 320x240, the FPS, and the bandwidth. Note the top three are all 128Kbps but the FPS vary from 8, to 15, and finally to 30 FPS. The bottom two indicate the same resolution and FPS but at two very different bandwidth requirements.

Figure 2: Example QVGA at various FPS and throughput.

Frames per second (FPS) is the number of “snapshots” of the video scene in one second. Recall that motion pictures are 24 FPS, and National Television Standards


Issue 1, July 2006

Committee (NTSC) television 30 FPS (although really 60 interlaced FPS). Video surveillance cameras can be configured for a range of FPS. Generally surveillance can be few FPS that “quality video” as situation assessment is the primary application. Storage costs are directly correlated to FPS as well. Often about 8 FPS is sufficient.

Resolution is the number of “pixels” (picture elements) within each picture frame. For example NTSC television is 720x486 (non-square pixels) or 720x540 (square pixels); sometimes these are termed D1. In the DVD context NTSC television is 720x480. All these have an aspect ratio of 4:3; non-square pixels can make this “wide screen” 16:9 aspect.

The resolution issue is complicated by the distinctions between computer monitor resolutions and video teleconferencing screen resolutions.

In video cameras used for surveillance, video-teleconferencing, and VoIP video the notation of Common Intermediate Format (CIF) at 352x240 resolution is the NTSC norm. Alternatives are Quarter CIF (QCIF) 176x120, 4CIF 704x480, and 16CIF 1408x960. An alternate Standard Intermediate Format (aka “SIF”) is at 352x240.

In all the above there are minor differences in the PAL-based (European television Phase Alternating Line) television environment.

By comparison computer resolution is slightly distinct from CIF as shown in Table 1. Additional resolutions are defined going all the way to WHUXGA at 7680x4800 with a 16:10 aspect ratio.

Table 1: Common Computer Screen Resolutions

Standard Resolution Aspect Ratio

QVGA 320x240 4:3

VGA 640x480 4:3

SVGA 800x600 4:3

XGA 1024x768 4:3

XGA+ 1152x864 4:3

SXGA 1280x1024 5:4

The point is that video cameras and computer screens are distinct. Even so the impact of computer screens on generic video will be profound, as seen by large screen home television screens now capable of operating as a computer monitor.


Issue 1, July 2006

Figure 3: Example PAL CIF capture at very low bit-rate.

In a wireless surveillance environment it is very important to minimize the traffic load on the network. Figure 3 shows a PAL CIF (352x288), 8 FPS, screen capture that produces slightly less than 64Kbps. The resulting video is surprisingly good as might be appreciated from the screen capture.

4.2 Special Outdoor Surveillance

In addition to the usual outdoor surveillance need there are two specialized surveillance systems, namely “night surveillance” and “license plate surveillance” that are primarily CCTV. The latter is also known in the trade as Automatic Number Plate Reading (ANPR). Figure 4 shows an example ANPR system; Canopy is not explicitly shown but of course can be the backhaul component.

Figure 4: Example ANPR cameras and illuminators – Extreme Surveillance.

Night surveillance requires infrared (IR) technology which sees infrared “heat”. If necessary the surveyed scene may be further illuminated by an infrared “light” source.

ANPR use special cameras and associated infrared (IR) illumination. General the license plate needs to be no more than 75 feet from the ANPR camera so purposeful and proper siting is necessary. A set of example ANPR cameras and illuminators is shown in Figure 4; these happen to be from vendor Extreme Surveillance.


Issue 1, July 2006

4.3 Example Cameras

Evaluation of actual third party IP cameras or CCTV cameras suitable for any particular surveillance task is beyond the scope of this white paper. However we enumerate a list of parameters that might be considered before any video camera and provide illustrations of a representative set of cameras by a variety of vendors.

Camera checklist parameters:

1. Number of effective pixels 2. Lens type 3. Zoom ratio 4. Pan/Tilt/Zoom 5. Image resolution 6. Codec supported 7. Audio support 8. Night filter (in B/W mode) 9. Analog and RJ45 video output 10. Size & Weight 11. Power consumption and input type (AC/DC) 12. Operating temperature 13. Ruggedized for outdoor deployment

Figure 5: Three example outdoor and ruggedized IP cameras.

Figure 6: Example of same camera in indoor and outdoor versions – D-Link DCS.

Figure 7: Example Sony SNC-RZ30N Pan-Zoom-Tilt in outdoor enclosure.


Issue 1, July 2006

4.4 Example Video Recorders

As defined previously Digital Video Recorders (DVR) directly connect via coaxial cable a set of CCTV video cameras. Typically the connecting cable is RG59 coax, often termed “Siamese” because the cable also includes two copper conductors for powering the camera as shown in Figure 8. The maximum cable length is about 600 feet.

Figure 8: Illustration of “Siamese” RG59 coax with two 18-gauge wires for power.

A typical 16-camera DVR is illustrated in Figure 9. The CCTV cameras are terminated via BNC connectors. Note that, unlike some IP-cameras, DVR’s can’t be powered via Power-over-Ethernet (PoE) as they consume too much power.

Figure 9: Typical 16-camera DVR – Dedicated Micro BX2.

Network Video Recorders

As previously stated the distinction between a DVR and a Network Video Recorder (NVR) is that the latter has an IP connection toward a core network. The IP connection toward the network is the Internet backhaul of the various CCTV cameras.

The advantage of a NVR is that the CCTV cameras may be “remote” from the perspective of the wireless backhaul network. This allows for high resolution, high FPS “remote recording” but to backhaul a low resolution, low FPS IP-based video streams back to the video command center.

An example of a ruggedized NVR is shown in Figure 10. This unit, by Boundless Security Systems, can be mounted outdoors, say at a road intersection. Four CCTV cameras may be pointed down each of the four streets.

Should a situation require the high resolution, high FPS “forensic” recording may be retrieved over the network at a later time (say during the night) or even retrieved by physically accessing the remote NVR. Meanwhile “situation assessment” continues in “realtime”.

Figure 10: Example NVR Video Server – Boundless Security System.


Issue 1, July 2006

4.5 Video Command Center

This is a large and complex topic well beyond the scope of this paper. However we include Figure 11 showing a typical flat-panel-based Video Command Center.

A Video Surveillance Command Center (VSCC) has computers that process incoming video streams. Typically multiple video flows can be displayed on a single monitor, with a “mouse click” enlarging a particular video for better human observation if the scene warrants.

Figure 11: Generic Video Surveillance Command Center – Uptime Business Products.

The computer program, typically purchased software, can also “motion detect” by noting differences between time-adjacent video frames. If a change is detected the computer program may generate and log an “alarm” into a database. This operational mode allows fewer human operators and allows reviewing the alarms at a later time; say in the morning if the VSCC is un-manned during the night.

Further portions of a video may be defined for motion detection purposes, allowing “expected motion” to be ignored and so not generating alarms. Only when motion is in a stipulated portion of the video scene will an alarm be generated.

For example Figure 12 shows, in a home video surveillance context, the definition of a set of particular “zones” for motion detection purposes. In this case the movement of a small animal will not generate an unwanted alarm, for example. In the right-side video capture the motion detection is displayed visually.

Consequently a recent trend in video surveillance is to off load as much “observation” from human operators to computer generated alarms.

Figure 12: Example of defining motion detection “zones” – ZoneMinder.


Issue 1, July 2006

4.6 Video Packet Statistics

Critically for wireless links packet size and packet frequency (packets per second – PPS) is usually significant. Note that any particular packet flow rate in kbps can have very many different packet size/packet frequency combinations.

IP video packet size, headers, and overhead ratio

The overhead of encapsulating a video stream into a packet stream is rather substantial. How substantial depends upon the exact encapsulation.

In general the encapsulation will be MPEG4 “frames” encapsulated in Realtime Transport Protocol (RTP), RTP encapsulated in User Datagram Protocol (UDP), and UDP encapsulated in Internet Protocol version 4 (IPv4). Additionally IP is encapsulated into some Data Link Layer protocol, which in the usual case of any RJ45-cable-conneced IP camera, is Ethernet.

The overhead sum of Ethernet/IP/UDP/RTP is 18+20+8+12 = 58 octets, plus the video payload.

This is why overhead is such an issue with VoIP as the compressed 20ms of speech is not many octets; fortunately for video the per-packet payload is significantly higher. This means that, for video, the overhead ratio is not nearly so significant.

IP video packets per second

While the bandwidth in kbps is often stated for various video camera/codec combinations it is important, particularly in the wireless backhaul context, to additionally know the size of the resulting encoding and the packets per second. In general, video camera bandwidth setting is an upper bound, with the camera typically actually consuming less bandwidth.

A definitive answer is impossible but at least an example can be provided here. For a MPEG4 Part2 (visual) codec set at CIF (352x240), 30 FPS, and 731Kbps the Ethereal packet capture tool was used to determine packet size and rate. In this example the packet flow was 977 octet packets at a rate of 94.456 packets per second.

Ethereal packet captures of MPEG4 streams show that, for a particular FPS and bandwidth configuration, variable sized packets result and that the packet frequency varies. Apparently the codec is very clever and minimizes throughput given a changing video scene. The point is, for an actual determination of bandwidth consumption, a packet capture tool must be employed.

Interestingly the Ethereal packet capture described above definitively shows the Ethernet/IP/UDP overhead; however the remainder of the packet is “data”, that is, either encrypted or is a proprietary protocol. Ethereal can’t recognize RTP as it doesn’t have a “well known” protocol number; however Ethereal can be configured to interpret the “data” as RTP (not shown here).

This relatively large packet size is well suited to wireless transport via Canopy PMP, PTP Backhaul and Canopy HotZone WI-Fi Mesh; as indicated earlier packets larger than 576 octets enable the full throughput of Canopy to be utilized.


Issue 1, July 2006

5.0 Overview of Canopy for Video Surveillance Canopy BWA supports any “packet data” application which includes streaming IP-based surveillance video. In this section we assume that each IP camera is associated with a single Canopy SM.

Canopy Video Surveillance Solutions:

- Point-to-Multipoint (PMP) – Available in six unlicensed frequencies o Canopy Classic AP & SM (7Mbps) o Canopy Advantage AP & SM (14 Mbps)

- Point-to-Point (PTP) o Canopy 10/20 Mbps Backhaul (Line-of-Sight up to 35 miles) o Canopy 30/60/150/300 Mbps Backhaul (near & Non Line-of-Sight)

- WI-Fi Mesh o Canopy HotZone Duo (Dual Radio 2.4GHz & 5.8GHz)

- Canopy Prizm (Network Management Platform) o Element Management o Bandwidth and Authentication Management

Diagram of Canopy Video Surveillance Solutions


Issue 1, July 2006

Pictures of Canopy Video Surveillance Deployments

Point-to-Multipoint – Canopy Advantage Access Point and Subscriber Module

Point-to-Point – Canopy Line-of-Sight 10/20 Mbps Backhaul

Point-to-Point – Canopy near and Non Line-of Sight 30/60 and 150/300 Mbps Backhaul


Issue 1, July 2006

5.1 Canopy PMP

Canopy point-to-multipoint (PMP) operates in a six-sector mode, in which each sector has a usable bandwidth of either 7Mbps (2FSK modulation – longer range) or 14Mbps (4FSK modulation – shorter range). Thus the set of Subscriber Modules (SMs) within a sector can collectively consume that much bandwidth.

To compute the approximate number of video surveillance cameras per sector one must stipulate the bandwidth consumed by each camera and the particular TDD duty cycle configured.

Consider the case where Canopy is configured for 20/80% downlink/uplink duty cycle. Then, for:

- Canopy Classic - approximately .8*7Mbps = 5.6Mbps of video uplink is available for long range SM consumption.

- Canopy Advantage - approximately .8*14Mbps = 11.2Mbps of video uplink is available for short range SM consumption.

Also for example, if a video camera was configured to produce an uplink traffic load of say, 112Kbps (.112Mbps), then any particular Canopy sector can handle up to 50 cameras (long range SMs) or up to 100 cameras (short range SMs). Of course if circumstances require an appropriate mix of cameras in the short and long range capability are possible.

One might be tempted to further skew the duty cycle, say to 10% downlink /90% uplink. This can be done but it is necessary to provision enough downlink bandwidth to manage and control the IP cameras, particularly if they are the pan-zoom-tilt variety.

However, the duty cycle (“Downlink Percentage” setting) is not precise as it must be mapped to Canopy’s proprietary protocol. The latter is based upon a Motorola proprietary “frame” consisting of “slots”. Some slots are dedicated to necessary overheads, but typically 33 “data slots” are available. The most asymmetric allocation of these data slots is two slots in one direction, with the remainder in the other direction. Thus, regardless of the Downlink Percentage configuration 2/33 is the lowest the downlink allocation can be, or about 6%.

One caveat to this computation and consequence expectation is that Canopy throughput also depends upon packet size; short packets (say less that 576 octets long) limit the throughput. In general for maximum throughput configure the IP cameras to produce packets of approximately 500 octets. A packet capture tools such as Ethereal can be used to determine packet size.


Issue 1, July 2006

5.2 Canopy PTP In general Canopy point-to-point can be utilized for video surveillance in three ways.

1) Backhaul a full Canopy base station cluster (the six sectors).

2) Establish a long-range point to point link.

3) Backhaul a Canopy HotZone “mesh cloud” consisting of a set of HotZone WI-Fi Access Points supporting wireless IP cameras; the latter is discussed in the following section.

Canopy high capacity and low latency backhauls provide approximately two-thirds of aggregate bandwidth for backhauling video surveillance traffic.

o 10/20 Mbps Line-of-Sight Backhaul

Up to 35 miles (56km) Available in five unlicensed frequencies (2.4, 5.1, 5.2, 5.4 & 5.7GHz)

o 30/60/150/300 Mbps OFDM Backhaul (Integrated and Connectorized Versions)

Near Line-of-Sight up to 25 miles (40km) Non Line-of-Sight up to 6 miles (10km) Line-of-Sight up to 124 miles (200km)

Recall if a Canopy base station (BS) cluster is dedicated to supporting anywhere from 5 to 10 IP cameras per sector then, in aggregate, the BS is supporting anywhere from 30 to 60 IP cameras. Any backhaul network, wired or wireless must be capable of transporting this aggregate load of the IP video surveillance traffic.

5.3 Canopy HotZone WI-Fi Mesh Canopy PMP or PTP can also backhaul IP camera video surveillance via Canopy HotZone WI-Fi Mesh; please reference www.motorola.com/mesh. In this context the IP cameras have built-in WI-Fi wireless capability. HotZone can also connect IP cameras directly to a mesh node and can be powered via Power over Ethernet (PoE).

The range of WI-Fi is “local”, that is much shorter than Canopy’s “metropolitan” range. Consequently a set of relatively near IP WI-Fi cameras communicate to a Canopy HotZone Intelligent Access Point (IAP - not to be confused with Canopy’s use of the term).

A set of Canopy HotZone APs also communicate amongst themselves, effectively performing a backhaul function within a so-called “mesh island”. In the “mesh island” there is a special IAP termed the “gateway IAP” which is connected to a Canopy PMP or PTP backhaul to provide Internet connectivity to the “mesh”.

Note that the WI-Fi “cloud” throughput capability is employed for two tasks: connecting to WI-Fi customer devices (e.g. laptops, PDAs, or IP cameras) and for backhaul traffic relaying to the special gateway IAP.

In many contexts the gateway IAP is connected to wired infrastructure; in the Canopy backhaul context the gateway IAP is connected to a Canopy SM or a Canopy BH unit.

Sizing a Canopy HotZone WI-Fi Mesh complex with the appropriate Canopy wireless backhaul is a difficult task yet crucial for successful video surveillance performance.


Issue 1, July 2006

5.4 Canopy PMP Specific Multicast Video Considerations

IP Multicast – If multiple Video Surveillance Command Centers are to receive video streams from the various cameras then the network must be capable of IP multicast and the command centers and the camera-edge points must “join” the IP multicast “group”.

A consequence of IP multicast is the camera application embeds the IP multicast-addressed IP packet into a corresponding Ethernet multicast frame. Canopy treats such Ethernet frames as if they would broadcast-addressed, that is re-transmits them to all other edge points on the Canopy “layer 2 cloud”. In general Canopy must be administered to prevent this type of “layer 2 switching” by a radio software feature called SM Isolation that is employed in Release 8 or later. The point is to get the Ethernet multicast-addressed frames to the core IP router only.

SM Isolation – In Canopy software Release 8 or later, the AP Configuration page tab General has a “SM Isolation” feature with a default and two options in a drop down box menu. If set to one of the two options the AP will not re-transmit Ethernet multicast or broadcast frames back out to all edge points of the “layer 2 cloud”. In the IP multicast video surveillance context set Option 1 “Block SM destined packets from being forwarded”. See Figure 13.

Figure 13: Release 8 AP Option 1 “Block SM destined packets from being forwarded”.

In addition Ethernet multicast must be blocked from exiting the CMMmicro toward other Canopy APs which is the default circumstance. This is accomplished on the CMMmicro software Release 2.2 Configuration page in the Uplink/VLAN Port Configuration section.

As shown in Figure 14 for all ports facing APs uncheck the Ports the APs and check only those ports facing the core WAN network. For the ports facing the core WAN network check all ports. These points are now explained in greater detail.

In Figure 14 the CMMmicro Port 7 and Port 8 are assumed to connect to the core WAN network. Note all the checks for these two ports. All other CMMmicro ports, namely Ports 1 through 6, have the “AP ports” unchecked. The effect of this is to force all Ethernet multicast (and broadcast) packets to the core WAN network (and eventually to an IP router with multicast capability. The reference here to “VLAN” is for the internal use of the CMMmicro only.

Basically these two configurations, in the AP and CMMmicro, disable the Canopy’s Ethernet switching capability, changing Canopy into a “wire” between the customer’s IP interface (in this context an IP camera) and a core IP router. Thus all packet switching is forced to be layer 3 IP. For completeness, outside this video context, note this still permits SM to SM communication based upon IP packet switching (as distinct from Ethernet “direct” packet switching).


Issue 1, July 2006

Figure 14: CMMmicro Uplink/VLAN Port Configuration section.

Note on Video Performance.

While not directly a Canopy issue it is necessary to state that video “performance” may be unsatisfactory even though Canopy is configured properly and performing properly. This has been observed in the field and is sometimes “blamed” upon Canopy. Users are requested to note the CPU utilization on the viewing computer, as it may be close to 100%.

Experience has shown that even eight MPEG4 IP cameras, in factory default settings, producing in aggregate 4.6Mbps (easily handled in one Canopy Advantage sector), will seemingly “not work”. The cause is that an ordinary PC just can’t handle the real time play-out of eight relatively high quality video streams thus a user should follow the recommendations of the video surveillance software vendor to optimized the PC configuration. (i.e. RAM, Video Card, Processor, etc.) Without the correct PC configuration, the video “breaks up” yielding unacceptable performance; the “fix” is to have a computer capable of the necessary “horse power”.

6.0 Summary and Conclusion

In this white paper an overview has discussed many basic aspects of deploying Canopy PMP, PTP and HotZone for a dedicated unicast video surveillance service. In particular the video surveillance business scenarios open to existing Canopy operators was highlighted.


Issue 1, July 2006

Additional Resources

Canopy provides two additional resources where you can raise questions and find answers:

Canopy User Community http://motorola.canopywireless.com/support/community/ This resource facilitates communication with other users and with authorized Canopy experts. Available forums include General Discussion, Network Monitoring Tools, and Suggestions.

Canopy Knowledge Base

http://motorola.canopywireless.com/support/knowledge/ This resource facilitates exploration and searches, provides recommendations, and describes tools. Available categories include

− General (Answers to general questions provide an overview of the Canopy system.)

− Product Alerts

− Helpful Hints

− FAQs (frequently asked questions)

− Hardware Support

− Software Support

− Tools

Sending Feedback

We welcome your feedback on Canopy system documentation. This includes feedback on the structure, content, accuracy, or completeness of our documents, and any other comments you have. Please send your comments to [email protected].

WHITE PAPER Canopy Wireless Broadband Platform · 2009-08-17 · Motorola Canopy is a Broadband...

Documents

Transcript of WHITE PAPER Canopy Wireless Broadband Platform · 2009-08-17 · Motorola Canopy is a Broadband...