Digifort UK helps to reduce bandwidth issues in IP CCTV.

It includes live viewing, reviewing and recording, as well as data used for network system communications. As the camera count in a system increases, so too does the amount of data being transmitted, creating network bandwidth bottlenecks. This has an adverse impact on the efficiency of the CCTV system, causing it to under-perform.

In this article, Paul Scott, Technical Director at Digifort UK, considers the common network bandwidth restrictions encountered in IP CCTV systems. Paul also explores how a well-designed, IT infrastructure and deployment, using an intelligent video management software (VMS) solution, can contribute to reducing negative bandwidth effects and dramatically increase system performance for users.

System bandwidth:

The system bandwidth requirements of an IP CCTV system are easy to calculate and are submitted with the system design for Digifort, open-platform, VMS solutions. They can be split into three prime categories:

• Camera live viewing bandwidth. This is the total bandwidth required for live camera viewing and is typically assumed to be D1 resolution, as viewing is usually in multi-screen formats. The Digifort calculator suggests a “worst case” figure based on a fully unicast system: one where every camera in the system will be viewed simultaneously by a combination of clients. In real applications, this amount of traffic is rarely so high.
• Recording bandwidth. This is the total bandwidth required for the camera video recording streams. A typical 2MP IP camera, operating in real-time (25 IPS) and producing good quality video, generates around 3 Megabits of data per second (Mbps).
• Client reviewing bandwidth. This is the total bandwidth needed by each client when reviewing the system. It assumes concurrent live display and play back of HD video from multiple cameras. Each client viewing the IP CCTV system, from a PC or central monitoring position, will typically demand 30Mbps of data.

The total system bandwidth comprises the sum of all three bandwidth types.

As an example, a system of 100 x 2MP cameras operating in real-time (25FPS) for 31 days and viewed by 4 concurrent clients would demand the following:

• Camera live viewing bandwidth = 100Mbps
• Recording bandwidth = 300Mbps
• Client reviewing bandwidth: 4 x Clients (max 30Mbps each) = 120Mbps
  

Total system network bandwidth requirement = 520 Mbps

Total required storage (Approximately) = 100TB

Bandwidth usage

A network does not reserve 100% of its available bandwidth for video data. Some bandwidth is required for protocol and communication demands. As a result, a Gigabit connection will normally offer just over 90% of its bandwidth for the actual data payload.

Most networks use copper Ethernet cabling, capable of transmitting up to 1 Gigabit of data per second (Gbps) or 1000 Megabits per second (Mbps).

Using the example system above, bandwidth usage would be nearly 60% of what is available. If the system uses variable bit rate (VBR) compression, to ensure the best detail and quality, the actual bandwidth requirement will feature peaks and troughs of higher and lower bandwidth demand.

Data bottlenecks: Ethernet cables and connections

The simplest way to reduce bandwidth bottlenecks is to create more routes, larger capacity routes, or alternative routes for data within the network but also in creating different networks for different purposes.

When it comes to Ethernet connectivity then the more available NIC ports the better, allowing teaming and virtual LAN (VLAN) support.

VLANs offer a good method of segregating video traffic so that all data is not transmitted across the entire network. For instance, separate VLANs can be used for recording traffic, live traffic, and client access, thus reducing the possibility of bottlenecks.

Fibre host cards can be used to create an additional fibre optic link between the server and storage array, with link speeds of up to 32 Gbps. The fibre host cards are no longer prohibitively expensive and offer an effective way of increasing data capacity

PCI or PCI Express cards also enable fast server and storage connections. However, the PCI card shares data pathways with the communication bus of the server, restricting its benefit. Direct attached storage (DAS) options rely on PCI or PCIE host cards. If this type of storage is used, care must be taken to ensure that enough storage and playback bandwidth are available through the card and PC bus.

Data bottlenecks: communication protocols

The type of protocol used to communicate between the network devices in an IP CCTV system, including between cameras, servers and storage, has a surprisingly large influence on data bottlenecks and system performance. As video storage is raw data and not requiring a multi access filing system, some architectures are not suited performance wise, with NAS being the prime example.

Network attached storage (NAS) protocol, commonly used in IT-based client / server applications, is far too slow for larger IP CCTV systems. NAS protocol requires “transactions” between network devices before data is transmitted or stored. In communications terms, the camera, storage array and server must first recognize each other, open a session, transmit the data and then close the session. This is ideal for normal IT applications, but hampers IP CCTV systems due to the large amounts of data flowing continuously and in bursts.

iSCSI is another standard protocol option available in the Windows’ operating systems used on most servers and storage arrays. It is well-suited to the data characteristics of IP CCTV applications. iSCSI provides a Storage Area Network (SAN), whereby an open-data path is created between the server and storage, so it appears local to the server, minimising wasteful transactions and sessions.

Data bottlenecks: storage

Storage bottlenecks occur when the IP CCTV system transmits data faster than the storage system hard disc drives (HDDs) can record it. There are a number of options available to help address this problem:

• Using servers with built-in storage instead of servers with separate storage arrays. This is becoming an increasingly favourable option, as server prices are reducing all the time. Locating the storage in the server, or across a number of servers, is probably the most cost-effective storage solution available at the moment. Many branded servers have embedded RAID controllers with cache, the cache being important for concurrent read / write functions - typically when video is being played back from storage. A typical 2U server has at least eight drive bays. Two are normally reserved for the operating system (OS), set up as a RAID1 pair of fast SAS drives or SSD. This leaves six available bays for storage. Even with cost-effective, 6TB SATA HDD drives in all six bays, the server will have 36TB of raw storage, or 30TB in RAID5. 30TB will easily handle a 40 camera, Full HD CCTV system, recording in real time for a month. In larger systems, the data processing demands can be spread across a number of servers. Failover options also become available, whereby cameras can record to an alternative server, should the primary server fail. SATA HDDs are now available off-the-shelf, at up to 10TB each. So servers with built-in storage are becoming even better all-round options.
• CCTV applications using large megapixel cameras, such as multi-sensor cameras or 4k (8MP) technology, have huge data transmission and storage demands. Traditionally, storage arrays with ultra-fast, but expensive, SAS HDDs would have been used. However, multiple servers using the cheaper SATA HDDs are more cost-effective, if bandwidths are sufficient.
• The majority of the advanced VMS solutions allow storage arrays to be coupled to a specific server. Each camera’s recording path is connected directly to a server or coupled array. This set-up keeps the video traffic local and avoids flooding the entire network with data. VMS set up will allow ambient, live recording to be directed to the array and event-driven recording to the server, where there is more immediate processing available for analytics and motion detection.
• LUN (logical drive unit) size has a large influence on storage performance.

There is a lot to be said for using more, smaller drives as opposed to fewer larger drives. A LUN size of 16TB is considered to be the maximum for efficient disc and storage operations. This means that when creating disc groups, such as RAID, the overall size of each group is a maximum of 4 x 4TB HDDs with a single volume of 16TB. As HDDs become larger this issue will become and more important in terms of storage architecture design.

Data bottlenecks: servers

Servers with RAID cache memory allow video data to be stored temporarily in the local cache memory. Cache, usually available in very fast SSD media, allows the server to process peaks of data locally, at speed, before transmission and storage on HDD media in a more controlled and uniform manner. RAID cache memory provides larger systems with a visibly more fluid playback and highly responsive search capabilities.

Summary

The purpose of this document is to identify and highlight the potential pitfalls regarding networks and storage. These are the most common causes of IP CCTV system under-performance and poor stability, but can often be prevented. VMS systems require sound IT planning, so as to perform at their optimal level from the start.

As a guideline, it is helpful to consider the following questions when designing and commissioning an IP CCTV system:

• What is the overall size of the initial system deployment?
• Will the system grow and if so by how much?
• How many concurrent users are there likely to be?
• What types of viewing devices will be used?
• Will video analytics or other processor intensive applications be added?

All of these questions allow the network and hardware requirements to be calculated for the initial deployment and will allow for system growth. Clear “price points”, where another server, storage array, switch, network circuit etc. are necessary, become apparent.

By attending to network requirements at the design stage, installers are able to future proof an IP CCTV system; ensure the networks will cope with the data demands; and deliver a reliable, stable, high performance system, with minimal bottlenecks.