3.1.37 Hyper Text Mark-up Language HTML coding language used to create Hypertext documents for use on the World Wide Web 3.1.38 Hypertext Transfer Protocol HTTP connection oriented pr
Terms and definitions
For the purposes of this document, the following terms and definitions apply
Adaptive jitter buffering is essential for managing packet queuing in switched networks that experience unwanted signal variations This technique ensures continuous video transmission by dynamically adjusting the size of the jitter buffer according to the measured jitter levels in the network.
EXAMPLE If the jitter increases, the buffer becomes larger and can store more packets; if the jitter decreases, the buffer becomes smaller and stores fewer packets
The NIST encryption standard, known as Rijndael, is an unclassified and publicly disclosed symmetric encryption algorithm It features a fixed block size of 128 bits and supports key sizes of 128, 192, or 256 bits, as outlined in the Federal Information Processing Standards Publication 197.
ASCII (American Standard Code for Information Interchange) de-facto world-wide standard for the code numbers used by computers to represent all the upper and lower- case characters
Asymmetric algorithms are essential in asymmetric cryptography, utilizing a pair of keys—a private key and a public key—to encrypt and decrypt messages, thereby ensuring the privacy of communications.
3.1.5 authentication process where an operators or systems identity is checked within a network
EXAMPLE In networks, authentication is commonly done using logon passwords
3.1.6 authentication server device used in network access control which stores the usernames and passwords that identify the clients logging on or which may hold the algorithms for access
To access specific network resources, servers may store user permissions and company policies or provide access to directories containing this information Authentication servers implement protocols like RADIUS, Kerberos, TACACS+, and 802.1x to facilitate user authentication.
3.1.7 authenticity integrity and trustworthiness of data or an entity; validity and conformance of the information, or identity of a user
NOTE The authenticity can be secured and verified using cryptographic methods
3.1.8 authorization approval, permission, or empowerment for a user or a component to do something
3.1.9 backbone high-speed line or series of connections that forms a major pathway within a network
The backbone layer is a larger transmission line that efficiently carries data from smaller interconnected communication lines, such as those connecting local area networks This setup enables effective data transmission over long distances, for example, between buildings.
3.1.12 bridge device used to connect two networks including passing data packets between them using the same protocols
3.1.13 certificate authority issuer of security certificates used in SSL connections
3.1.14 client component that contacts and obtains data from a server
3.1.15 client/server communication system providing services like video streams, storage, logon access, data communication management and clients (workstations) bscribing these services
NOTE A Hub is a communication device that contains multiple ports
3.1.16 codec compression-Decompression or enCOder/DECoder process
Common Gateway Interface (CGI) standardized method of communication between a client, e.g web browser, and a server, e.g web server
3.1.18 compression delay delay caused by the compression of data
3.1.19 congestion situation in which the traffic presents on the network exceeds available network bandwidth/ capacity
3.1.20 core layer part of the network providing optimal transport between sites or system functionality e.g recording
Data Encryption Standard (DES) cryptographic algorithm method developed by the US National Bureau Standards
Dynamic Host Configuration Protocol (DHCP) protocol by which a network component obtains an IP address (and other network configuration information) from a server on the local network
3.1.23 distribution layer part of the network providing policy-based connectivity
Domain Name System (DNS) system that translates Internet domain names into IP addresses
3.1.25 dual homing single device offering two or more network interfaces
3.1.26 dynamic Jitter buffer collecting and storing video data packets for processing them in evenly spaced intervals to reduce distortions in the display
3.1.27 encryption type of network security used to encode data so that only the intended destination can access or decode the information
Fail-over capability refers to an application's ability to automatically switch to a surviving instance in the event of a failure, ensuring no loss of data or continuity This process, often termed "run-time failover," is crucial for maintaining operational resilience and reliability.
3.1.29 forensics field of science of applying digital technologies to legal questions arising from criminal investigations
3.1.30 frame data structure that collectively represents a transmission stream including headers, data, and the payload and provides information necessary for the correct delivery of the data
3.1.31 gateway hardware or software set-up that translates between two dissimilar protocols
ITU video coding standard originally designed for ISDN lines and data rate with multiples of 64Kbit/s using RTP
ITU standard supporting video compression (coding) for streaming video via RTP based on and replacing the H.261 codec
The ISO ITU-T MPEG-4 Part 10 standard, known as Advanced Video Coding (AVC), facilitates video compression suitable for a range of applications, from low bit-rate network streaming to high-definition video This standard enables near-lossless coding, ensuring a network-friendly representation of video content.
Host computer on a network that is a repository for services available to other components on the network
3.1.36 hot-swap property of controller which allows circuit boards or other devices to be removed and replaced while the
Hyper Text Mark-up Language (HTML) coding language used to create Hypertext documents for use on the World Wide Web
Hypertext Transfer Protocol (HTTP) connection oriented protocol for transmitting data over a network or protocol for moving hyper text files across the Internet
Hypertext Transfer Protocol Secure (HTTPS) encrypts and authenticates communication between server and clients
Internet Control Message Protocol (ICMP) error protocol indicating, for instance, that a requested service is not available or that a host or router could not be reached
ID identification machine-readable character string
IEEE 802.1x method for authentication and authorization in IEEE-802 networks using an authentication server e.g RADIUS server
Institute of Electrical and Electronics Engineers (IEEE) professional association of engineers for the advancement of technology
Internet Group Management Protocol (IGMP) communications protocol used to manage the membership of IP multicast groups
The Internet Protocol (IP) is a crucial layer 3 protocol in the OSI model, responsible for addressing and controlling information that facilitates the routing of data packets within a network It serves as the primary network layer protocol in the TCP/IP protocol suite, as defined by IETF RFC 791.
IP Address (Internet Protocol Address) unique number consisting of 4 parts separated by dots, e.g 196.162.245.2, of a device attached to an IP network
Each device on an IP network is assigned a unique address, ensuring that every IP data packet includes both a source address (the sender) and a destination address (the recipient) An IP address is composed of 32 bits, organized into four 8-bit segments known as "octets" in the format x.x.x.x.
IP addresses range from 0.0.0.0 to 255.255.255.255
IP Internet Protocol main protocol used in conjunction with TCP (Transfer Control Protocol) (see TCP/IP)
IPS Images per Second measurement or unit for the rate of pictures transmitted or displayed to create a video stream
Internet Protocol, version 4 (IPv4) most widely used version of the Internet Protocol (the "IP" part of TCP/IP.)
Internet Protocol Version 6 (IPv6) successor to IPv4
NOTE Already deployed in some cases and gradually spreading, IPv6 provides a huge number of available IP Numbers
- over a sextillion addresses IPv6 allows every device on the planet to have its own IP Number
Institute of Radio Engineers (IRE) unit or measurement of the analog video amplitude that divides the area from the sync level to peak white level into 140 equal units
NOTE 140 IRE equals 1Volt peak-to-peak The range of active video is 100 IRE
KBit/s Kilobits per second unit of data transmission rate
3.1.53 latency time that elapses between the initiation of a network request for data and the start of the actual data transfer
OSI (Open Systems Architecture) data link layer device responsible for transmitting data across the physical links in a network
OSI device that determines network addresses, routes and quality of service for information transport
EXAMPLE A router is a Layer 3 device; switches can also have Layer 3 capability
Local Area Network (LAN) communications network serving users and devices within a limited geographical area, such as a building or a protected area
3.1.57 local-access layer part of the network bringing edge devices into the network and providing operator access
A login account name is essential for accessing a component, typically used alongside a password It involves connecting to a system by providing valid credentials, which usually consist of a "username" and "password."
3.1.59 managed switch switch that can be monitored and administered in the network via its own IP address
Management Information Base (MIB) structured collection of information for remote servicing using the SNMP protocol
Multipurpose Internet Mail Extensions (MIME) standard for defining the type of payload streamed from a server to a client
EXAMPLE "video/h264" is used for streaming H.264 encoded video
MJPEG (Motion JPEG) digital video encoding standard, where each video frame is separately compressed into a JPEG image
Motion Pictures Experts Group (MPEG) standard
ISO/IEC video and audio encoding standard
MPEG-4 digital video encoding and compression standard that uses interframe encoding to significantly reduce the size of the video stream being transmitted compared to intraframe only encoding
In interframe coding, a video sequence consists of key frames, or I-frames, that capture the complete image, while delta frames encode only the incremental differences between these key frames This method significantly enhances compression, as surveillance video sequences typically exhibit minimal pixel changes from one frame to the next.
3.1.66 multicast bandwidth-conserving technology that reduces bandwidth usage by simultaneously delivering a single stream of information, here video content, to multiple network recipients
N+1 fail-over fail-over capability of N identical applications in operation by automatically switching over to 1 unused application instance
N+n redundancy capacity of a parallel redundant system with N representing the number of applications needed to meet the critical load and n is the number of extra applications for redundancy purposes
3.1.69 network connectivity physical (wired or wireless) and logical (protocol) connection of a computer network or an individual device to a network
3.1.70 network design way of arrangement of the various clients and servers in a network for the purposes of connectivity, performance, and security
3.1.71 network layer layer 3 of the OSI Reference Model, controlling communication links and data routing across one or more links
3.1.72 network management administrative services performed in managing a network, such as network topology and software configuration, monitoring network performance, maintaining network operations, and diagnosis and troubleshooting problems
3.1.73 network performance to stream data in accordance with requests from the security application
NOTE Since video streaming is mostly real-time, it is critical to be delivered within a specific time QoS guarantees are especially important if the video network capacity is limited
3.1.74 network topology pattern of connection between nodes in a network, e.g hierarchical topology
3.1.75 node communication device attached to a network or end point of a network connection such as a device attached to a network such as a workstation, ip video device, printer etc
3.1.76 node devices any peripheral devices or computer that is connected to a network
Network Time Protocol (NTP) standard for synchronizing computer system clocks in packet-based communication networks
NOTE NTP uses the connectionless network protocol UDP (see UDP) for enabling time to be reliably transmitted over networks with variable packet runtime
3.1.78 packet loss loss of data packets during transmission over a network
3.1.79 packet switching method used to transmit data in a network from many different sources on the same connection, directed along different routes to many different sinks at the same time
3.1.80 packets data structures that collectively represent the transmission stream including headers and data associated with the network layer when the communication protocol is connection-oriented
3.1.81 physical topology physical layout of the network i.e how the cables are arranged and how the components are connected
3.1.82 port number or identifier for a particular service on a server, mostly standardized for certain services like RTSP, UPnP, HTTP, etc
NOTE Protocols are used in all levels of communication There are hardware and software protocols
Protocol data unit (PDU) unit of data equivalent to the frame which is passed between protocol layers
Quality of Service (QoS) is a crucial mechanism for managing network resources and prioritizing specific types of traffic, particularly in video streaming It involves control mechanisms that assign different priorities to various components, users, or data flows, ensuring a consistent level of service QoS encompasses a broad range of network performance parameters that influence an operator's perception of service quality, including availability, errors caused by noise, congestion, or component failures, as well as delay, jitter, bandwidth/throughput, and packet loss.
NOTE Performance and QoS are closely related.
Remote Authentication Dial-in User Service (RADIUS) protocol using an authentication server to control network access
The Rapid Spanning Tree Protocol (RSTP) is a link layer network protocol designed to maintain a loop-free topology in bridged Local Area Networks (LANs) Its primary function is to prevent network loops, thereby enhancing multicast functionality and overall network performance.
Request For Comments (RFC) are proposed internet standards that undergo review by the Internet Engineering Task Force (IETF), which serves as a consensus-building body to facilitate discussions This process ultimately leads to the establishment of new standards (STD).
A router is a device that facilitates the routing of information between interconnected networks It determines the most efficient path for a message by identifying the next network point to which a data packet should be forwarded, ultimately guiding it to its final destination.
Abbreviations
For the purposes of this document, the following abbreviations apply
CCTV CCTV Surveillance and Recording System
CIF Common Intermediate Format (352 pixels by 288 lines)
DHCP Dynamic Host Configuration Protocol
DSCP Differentiated services code point
H.264-CBP ISO/IEC 14496-10 and ITU H.261 Reduced complexity Baseline Profile
H.264-BP ISO/IEC 14496-10/ITU H.264 Baseline Profile
H.264-CBP ISO/IEC 14496-10/ITU H.264 Constraint Baseline Profile
H.264-HP ISO/IEC 14496-10/ITU H.264 High Profile
H.264-MP ISO/IEC 14496-10/ITU H.264 Main Profile
H.264SVC-BP ISO/IEC 14496-10/ITU H.264 Scalable Video Codec (SVC), Baseline Profile H.264SVC-MP ISO/IEC 14496-10/ITU H.264 Scalable Video Codec (SVC), Main Profile
H264-RCDO H.264 reduced-complexity decoding operation
HTML Hyper Text Mark-up Language
HTTPS Secure – Hyper Text Transfer Protocol
IANA Internet Assigned Numbers Authority
ICMP Internet Control Message Protocol
IEEE Institute of Electrical and Electronics Engineers
IESG Internet Engineering Steering Group
IETF Internet Engineering Task Force
IGMP Internet Group Multicast Protocol
IPv6 Internet Protocol Version 6IPsec IP
ISMA Internet Streaming Media Alliance
ITU-T International Telecommunication Union- Telecommunication Standardization
JFIF JPEG File Interchange Format
MD 5 Message Digest Algorithm Version 5
MIME Multipurpose Internet Mail Extensions
MISB RP Motion Imagery Standards Board Recommended Practice
MPEG Moving Pictures Experts Group
MPEG4-ASP ISO/IEC 14496-2 MPEG-4 Advanced Simple Profile
MPEG4-MP ISO/IEC 14496-2 MPEG-4 Main Profile
MPEG4-SP ISO/IEC 14496-2 MPEG-4 Simple Profile
MTBF mean time between failures
MTTR mean time to repair
NTSC National Television Standards Committee (television format)
OASIS Organization for the Advancement of Structured Information Standards
PAL Phase Alternation Line (television format)
PKCS Public-Key Cryptography Standards
RFC (Request for comment) IETF Standards Draft
RTCP Real Time Control Protocol
RTP Real-time Transport Protocol
RTSP Real Time Streaming Protocol
SMI Structure of Management Information
SMPTE Society of Motion Picture and Television Engineers
SNMP Simple Network Management Protocol
SNTP Simple Network Time ProtocolSOAP
Simple Object Access Protocol SPOF Single Point of Failure
SRTP Secure Real-time Transport Protocol
TCP/IP Transmission Control Protocol / Internet Protocol
UPnP Universal Plug and Play
UTF-8 8-bit Unicode Transformation Format
WSDL Web Services Description Language
This video transmission standard meets the diverse needs of security applications, including embedded systems, PC-based solutions, and operator workstations It encompasses various digital encoding and decoding devices, CCTV client workstations, video storage solutions, NVRs, and DVRs, each offering unique functionalities for video streaming and network connectivity.
Due to the nature of non-analog video transmission, especially video IP networks, using shared connections, compression and streaming techniques, following requirements shall be applied
General
Different applications necessitate varying performance levels for Virtual Test Devices (VTDs) Consequently, this standard establishes multiple performance classes, beginning with a lower class 1 and increasing with higher class numbers.
Network time services
The video transmission device will require network time services for a real-time clock, eventing, logging and for the video transport stream (TS)
The VTD must not begin streaming video for recording unless it can ensure accurate time stamping of video frames, particularly after startup or power loss Failing to meet this requirement risks corrupting the integrity of the stream recordings, which can hinder the correct replay of both the affected frame sequences and other recordings This issue is especially critical for images intended for evidential purposes.
The real time clock in the Video Transmission device should be synchronized with a time normal using RFC
By 2030, the Simple Network Time Protocol (SNTP) Version 4 will support both IPv4 and IPv6, as well as OSI SNTP servers will derive their addresses from the Time Server DHCP option (4) The default system time will prioritize higher accuracy, with SNTP achieving a best accuracy of 0.25 seconds, in contrast to the "Time Server" specified in RFC868, which provides a maximum accuracy of 1 second.
5.2.3 Accurate time services for the transport stream
For accurate time services ranging from 1 ms to 50 ms, it is recommended to implement Network Time Protocol (NTP) Version 3 as specified in RFC 1305 The IP addresses of time servers should be obtained through the Network Time Server DHCP option (42) NTP should be prioritized, and Simple Network Time Protocol (SNTP) should only be utilized if NTP fails A null DHCP option (42) indicates the unavailability of a time server, necessitating the use of SNTP.
Table 1 – Time service accuracy for video transport stream
Time service accuracy for transport stream 80 40 5 1
In the Real Time Protocol (RTP) header, NTP timestamps must consistently increase across consecutive packets in the RTP stream, aligning with local time and adjusted as needed to maintain this order Following a VTD restart, system time re-synchronization may experience delays of up to 10 seconds for SNTP and up to 15 seconds for the NTP time server protocol.
Video transmission timing requirements
Video transmission devices and their interconnections shall be designed in accordance with the system requirements EN 50132-1 as part of the CCTV system
The connection time required to start transmitting a stream from a source to a receiver is crucial, particularly in systems that involve camera roundtrips, sequencing, or guard tours among various cameras It is essential that this initial connection time is significantly shorter than the dwell time of the camera sequence.
Video transmission devices shall have a maximum Class
Initial connection time for every new video stream request of 2 000 m s 1 00 0 ms 500 ms 250 ms NOTE In RTSP Multicast streams an I-Frame request optimizes this connection time
When designing a CCTV video transmission network, it is crucial to ensure that the configuration allows for multiple video transmission receiver devices to request video images simultaneously If the total requests from all receivers exceed the network's available capacity, the video transmission device must provide solutions as outlined in the accompanying table.
Table 3 – Video transmission network requirements
Video transmission devices in a shared network shall offer means to configure Class
The maximum bandwidth for video streams is crucial for each video channel, ensuring optimal performance Additionally, it is important to consider the maximum bandwidth for all available video streams on a single device Furthermore, the overall bandwidth or the number of video streams accessible to all client devices within the network plays a significant role in maintaining a seamless viewing experience.
Table 4 – Video transmission network requirements
Video transmission devices in a shared network shall offer means to Class
P1 P2 P3 P4 prioritize certain streams over others, e.g streams for recording or alarms over live image streams X X prioritize certain users over others, e.g for PTZ control X X
At no time the video transmission receiver shall allow the opening and initializing of connections to new video
At no time the video transmission receiver shall allow the display of live streams on cost of the video streams recorded, in order to avoid frame loss
For optimal performance, a video transmission device must provide at least two streams with varying quality settings, ensuring that the video quality for live viewing by an operator differs from that used for recording.
For optimal performance, a video transmission device must provide an additional stream when the quality settings for continuous recording and event-based alarm recording differ.
Performance requirements on streaming video
Video streams are sensitive to accumulated delay, which is known as latency The network contributes to latency in several ways:
Transmission delay refers to the duration it takes for a video packet to traverse a specific medium This delay is influenced by both the speed of the transmission medium and the size of the video packet.
forwarding delay—the length of time an internetworking device (such as a switch, bridge, or router) takes to send a packet that it has received;
Processing delay refers to the time a networking device takes to look up routes, modify headers, and perform other switching tasks This delay can be influenced by the need to manipulate the packet header, such as changing the encapsulation type Each of these steps contributes to the overall processing delay experienced in network communication.
Coding and decoding delay refers to the time needed to encode or decode an image within a video stream, which is affected by the performance of the Video Transmission Device (VTD) and the specific codec type, profile, and level used For example, the H.264 "Main" profile has a coding delay of 350 ms, while the "Baseline" profile has a delay of 120 ms In comparison, MPEG4 typically offers a delay of 110 ms, and MPEG2 Low Delay achieves a delay of less than 180 ms.
display delay—the time required by the presentation unit to change the appearance of a picture element, usually not to be considered
A CCTV network transmitting video data with variable latency can experience jitter To mitigate this issue, a common solution is to utilize a buffer that temporarily stores incoming video data before display This buffering technique acts as a shock absorber, effectively minimizing the impact of jitter on video playback.
The overall need is that even when video traffic has a jitter, the operator watching the video images shall not
One way to provide minimized jitter and packet loss is to increase network speeds to assure that sufficient bandwidth is available during event- and peak-traffic times
Network packet loss can occur due to various factors, including network congestion from over-utilization, interference from other traffic, and issues with network infrastructure equipment Additionally, misconfigurations such as duplicate IP addresses can also contribute to packet loss.
Packet loss in IP video streaming significantly affects video quality, leading to issues such as frame blocking, image distortions, and unclear visuals It can result in artifacts, pixelation, blurriness, flickering, reduced frame rates, and frozen images Furthermore, packet loss contributes to increased latency and delays, which may ultimately cause VTD stream disconnections.
In the broadcast industry, a packet loss of 100 parts per million (ppm), equating to one lost packet per minute for 2CIF MPEG-4 real-time streams, is deemed un-viewable According to the DVB standard, a loss of 2 ppm, or one lost packet per hour, is considered unacceptable for users.
Packet loss significantly affects video streaming, influenced by factors such as the percentage of loss, its temporal distribution, and the capabilities of Video Transmission Devices (VTDs) to manage it In differential encoded video streams, each frame relies on predictions from previously transmitted frames, making video packets interdependent If earlier packets are lost, the current packet becomes ineffective, a phenomenon known as loss propagation This issue is mitigated with the arrival of intra coded frames (I-Frames), which reset the dependency chain.
The VTD must effectively detect and compensate for packet loss to ensure a satisfactory experience for both operators and users, maintaining video quality during disruptions Minimizing visual artifacts from stream delivery is essential for retaining end-users It is crucial that the visual impact of packet loss is masked to meet surveillance objectives The VTD should incorporate advanced error and loss concealment techniques, utilizing packet information from neighboring macroblocks and adjacent frames to accurately estimate the current frame's video content.
When addressing performance needs of streaming-video traffic, the following requirements apply:
Table 5 – Performance requirements video streaming and stream display
Max Loss 240 ppm 120 ppm 60 ppm 30 ppm
Max One-way latency live stream (incl encoding, networking, decoding, display) 600 ms 400 ms 200 ms 100 ms
Max Trick play (pause, single step, ) reaction time 400 ms 200 ms 200 ms 100 ms Round-trip latency incl visualisation & control like PTZ 700 ms 500 ms 300 ms 200 ms
Round-trip latency incl visualisation & control like PTZ, when moving objects need to be monitored and tracked 650 ms 450 ms 250 ms 150 ms
Streaming video archives and recordings have less stringent performance requirements, as they can tolerate delays and are generally not affected by jitter due to application buffering However, when streaming video includes critical content, such as security applications, it necessitates performance guarantees to ensure reliability.
To ensure optimal video streaming performance, it is crucial to assess and verify display performance parameters The primary goal is to provide a seamless visual experience for the end-user, with display jitter limited to no more than one-tenth of the frame rate interval.
The maximum peak-to-peak RTP packet jitter refers to the variation in delay between the source of the RTP stream and the receiving device This peak-to-peak jitter, denoted as J, indicates that the network delay deviation, d, is constrained within the range of -J/2 to +J/2 For a clearer understanding, a technical comparison and example can be provided.
Transmission device according to Class M4 shall comply with the Real Time Interface Specification of
ISO/IEC 13818-9 with jitter of 20 ms
Table 6 – Video stream network packet jitter
Class M0 ms M1 ms M2 ms M3 ms M4 ms
Maximum peak-to-peak RTP packet jitter - 160 80 40 20
The VTD receiver must provide a buffer to compensate for specified jitter, necessitating larger buffers to effectively receive and decode video frames affected by increased jitter This delay accumulates in the VTD receiver buffer, which needs to be sufficiently large to accommodate variations in inter-arrival times.
Table 7 outlines the maximum allowable duration for an interconnection or signal to be down If an IP video connection for streaming, health checks, or eventing fails and surpasses this maximum period, a tamper or fault signal will be triggered, as detailed in EN 50132-1.
Maximum permitted duration of device unavailability 180 30
Maximum detection time for live signal loss 8 s 4 s 2 s
The requirement aims to determine the feasibility of communication by observing the video transmission to check if it can effectively convey a signal or message This monitoring process may involve detecting jamming when a video transmission device interacts with other devices or applications through shared connections.
6 IP video transmission network design requirements
General
To ensure optimal performance of an IP video surveillance network, it is essential to select and configure standardized components while also establishing a suitable network structure Following a recommended design procedure will help meet the performance requirements for video transmission outlined in previous sections.
This clause details the design requirements for the CCTV installation, focusing on IP connections and communications.
Overview
The key design elements in video streaming systems are the number of video streaming servers and sources, such as IP video encoding devices, as well as the number of receivers or clients, including user interfaces, workstations, recording devices, and decoders These factors are interrelated and significantly influence the system's load, which can vary greatly A successful system design hinges on the effective combination of these two elements.
Digital network planning
For a proper network design follow these steps:
1 map the necessary logical connections of the planned physical network infrastructure;
2 define a topology that matches the required connectivity;
4 define baseline network traffic data based on continuous video stream recording and display;
5 simulate Video Stream traffic to verify this baseline data;
6 define a figure for the average and maximum simultaneity of streaming sources, the so-called selective factor;
7 define capacity needs on average and peak video stream data based on user requested video to workstations, continuous video stream recordings and motion or alarm video recordings;
8 identify each network link's bandwidth requirement in access-, distribution- and core layer;
9 identify potential bottlenecks WAN links can be IP Video traffic bottlenecks;
10 examine thoroughly the network hardware infrastructure to ensure support for immediate and future expansion in surveillance or Video Streaming capacity needs;
11 accurately document the network's topology, actually used capacity and maximum capacity
6.3.2 QoS - A critical requirement for IP video streaming performance
In a packet-based network, the quality of service (QoS) assigned to video transmission applications is crucial for optimal performance Key factors influencing QoS include bandwidth, latency, jitter, and packet loss, which are essential for ensuring acceptable video streaming quality While dedicated protocols like Differentiated Services Code Point (DSCP) and Class of Service (CoS) markings exist, they are not mandatory for video and audio applications Instead, a standardized QoS approach emphasizes the importance of effective network design and system management to maintain high-quality video streaming without the need for specific QoS priority assignments.
An essential aspect of safeguarding critical CCTV systems and operator traffic is the fifth factor known as "alternative routing" or "protection switching." The Quality of Service (QoS) outlined in this standard is not tied to any specific vendor implementation; rather, it pertains to a comprehensive mechanism within a system, network, or device that ensures the reliable delivery of the necessary video stream.
• Bandwidth - "The size of the possible video stream pipe" (for example, 1Mbps up through 10 Gbps)
ITU-T recommended codec algorithms can significantly reduce the bandwidth required for an IP video circuit, making it much more efficient than traditional Coax cable, which is typically dedicated to a single camera.
Latency, often referred to as delay, is the time it takes for a packet to traverse the network This is particularly critical for live video, which is sensitive to delays The maximum allowable latency should align with the performance requirements specified Generally, the network itself is not the primary factor contributing to the overall latency.
Jitter, or delay variation, refers to the inconsistency in the arrival time of packets at their destination, often described as "the received flow variation or pumping of stream." To mitigate jitter, jitter buffers can be employed to temporarily delay incoming packets; however, they can only address certain levels of delay variation It's important to note that these buffers have limitations, and excessive buffering may lead to increased latency Therefore, the maximum allowable jitter must align with the specified performance requirements.
Packet loss, often referred to as "the leak in the stream," occurs when data packets are lost due to factors such as LAN collisions or overloaded network links Even a small percentage of packet loss can significantly degrade video quality It's important to note that IP video streams utilize the User Datagram Protocol (UDP), which does not allow for packet retransmission like TCP does in non-streaming applications Therefore, the maximum allowable packet loss must align with the specified performance requirements.
• Redundancy, Alternative Routing and Protection switching - "Identifying and replacing a broken link or stream" to enable a reliable video transmission, alternative traffic-protection schemes like
Rapid Spanning Tree (RSTP), etc shall meet or exceed the requirements of the primary route
Before deploying video traffic on a network, it is crucial to ensure sufficient bandwidth for all required applications Start by calculating the minimum bandwidth needs for each major video node, as the total will indicate the minimum requirement for any specific link This total should not exceed 75 percent of the link's total available bandwidth, allowing for necessary overhead traffic such as routing protocol updates, keep-alives, and management traffic from additional applications like CCTV systems.
6.3.2.3 Quality of service: streaming performance and stream management
To successfully deploy IP video, it is essential to provide a service quality that matches or exceeds that of traditional analogue CCTV over Coax, ensuring higher video bandwidth and quality The perceived video quality in a digital packet network is highly sensitive to three critical performance factors: delay, packet loss, and achievable bit rate, which affects compression levels, artifacts, resolution, and frame rate.
IP inherently offers a best-effort service without guarantees on key performance criteria, making it essential to implement an appropriate Quality of Service (QoS) solution when oversizing cannot meet surveillance objectives and operational needs This solution aims to prioritize video recording streams over live streams and other data, ensuring that video services remain unaffected by unexpected network traffic While QoS protocols from voice over IP and video conferencing are typically used in WAN environments, they are not commonly applied in IP video security networks, as a video surveillance LAN within a secure site generally provides greater capacity In video surveillance networks, the quality of service for video streams is ensured through proper network design.
Traditional analogue CCTV coax cabling offers exceptional reliability, achieving 6-Sigma or five-nines reliability (99.999%), which translates to less than five minutes of downtime per year This system effectively manages an analogue composite video stream.
8 MHz wide frequency band of about 200 Mbits/sec bandwidth An IP video network needs to achieve similar levels of reliability at a much better scalability
To ensure reliability and scalability in an IP video network, it is essential to implement redundant and load-balancing equipment and networks Key components such as video encoders, access gateways, trunk gateways, and network video recorders must be designed for fault tolerance Common functionalities employed to achieve this fault tolerance include various redundancy and load-sharing techniques.
fail-Over Capability for all components,
N+1 Fail-Over Capability for one out of N identical components,
no single point of failure, except cameras and encoding,
dual network port video source devices like IP cameras or encoders,
configuration, Software and firmware that can be changed and upgraded without loss of service
Alternative network traffic-protection schemes such as RSTP according to IEEE 802.1w shall provide a spanning tree convergence after a topology change or network failure within 1 s STP shall respond within
Additional architecture principles
The architecture shall be based on the following principles:
1 separate functional components of the system to provide reliability and redundancy;
2 ensure a controlled environment for reliability of devices and the comfort of operators;
Understanding the design parameters during normal operations and in alarm or peak situations is crucial, especially when event response times exceed expectations As the size of the CCTV installation increases, peak loads tend to average out over time and across different sites.
Network design
The diagram illustrates a Local Area Network (LAN) featuring three video surveillance workstations (A, B, and C), a video server (D), a network video printer (E), and a router (F) This setup is designed to facilitate a compact surveillance system capable of supporting multiple video feeds.
Figure 4 – Small network 6.5.2 Small multicast video network
The diagram illustrates a Local Area Network (LAN) featuring three fixed workstations, a video server, a network multicast switch, and over 30 cameras This setup facilitates a compact multicast surveillance system, accommodating more than 30 IP video channels, with multiple operators and clients frequently monitoring the same video sources.
Figure 5 – Multicast network 6.5.3 Hierarchical CCTV network
A hierarchical network design includes the following three layers:
the backbone layer or core layer that provides optimal transport between sites or system functionality e.g recording;
the distribution layer that provides connectivity;
the local-access layer that brings video transmission devices into the network and provides operator access
Larger IP video networks shall be based on the hierarchical network model This model divides a network into three layers: core, distribution, and access layer
The access layer plays a crucial role in network connectivity by linking devices to the network It is typically characterized by high port density and the capability to address physical edge device or "last mile" challenges effectively.
The distribution layer is crucial for applying policies, including access-lists and Quality of Service (QoS), as well as making CPU-intensive routing decisions beyond just default routes This layer is designed to aggregate access devices into high-processing resource components, enabling effective policy implementation.
The core layer serves as the essential backbone of the network, responsible for efficiently transferring large volumes of video stream packets from various sources (A) to the video receiver (B) with minimal manipulation and maximum speed.
In smaller IP video environments, a single switch often handles both core and distribution tasks, unlike larger networks where these functions are typically divided across different switches.
6.5.4 Effective video IP network capacity planning
Network capacity, as defined by IP video and network professionals, refers to the volume of traffic a network can manage, particularly in terms of simultaneous video streams The concept of "peak load" is crucial, representing the maximum number of video streams the network is expected to support This peak load serves as the foundation for effective capacity planning, which must take various factors into account.
number of encoders/cameras on the network;
existing data traffic on the network;
decentralized or centralized recording and video content analysis;
connectivity to network storage, video recorders, video motion detectors;
number of streams of the encoders are provided and the number of clients each one supports;
number of users and video operator clients in the network;
existing local area network (LAN) and/or wide area network (WAN) designs;
existing and or selected network's hardware infrastructure;
spare bandwidth available in the network
When wireless interconnections are employed the factors below shall be considered:
(1) siting of antennas to ensure reliable communication with other system components;
(2) possibility of other RF equipment interfering with CCTV system interconnection equipment;
(3) proximity of large metal objects to the equipment antenna;
(4) possibility of intruders to interfere or block the interconnection.
Replacement and redundancy
Redundancy provides alternate routes around single points of failure (SPOF)
Redundant network designs enhance network availability by duplicating essential links and interconnectivity devices, effectively eliminating single points of failure The primary objective is to replicate any critical component whose failure could disrupt vital applications, including analog video matrix switches, core routers, cameras, video encoders or decoders, power supplies, network trunk lines, and digital video recorders.
Redundant topologies should only be implemented when necessary, as they can be costly to deploy and maintain The level of redundancy chosen must align with operational requirements for both availability and affordability While redundancy can increase the complexity of network topology, it can be effectively managed in surveillance systems by using PTZ cameras that can cover multiple static cameras or by strategically positioning cameras so that the field of view of one overlaps with another, albeit at a lower quality.
A single point of failure in a CCTV system refers to any device, interface, or link that, if it fails, can disrupt surveillance tasks Hierarchical network models often exhibit multiple single points of failure due to their focus on summarization points and entry points between layers In a strictly hierarchical network, as illustrated in Figure 6, each device and link represents a potential single point of failure.
To ensure redundancy in the core layer, various designs can be implemented In scenarios where the entire core network is housed within a single building or a small secure site, each router is linked to two high-speed LANs, as illustrated by Router A and B in Figure 7.
If the core routers are not all in one building or within one protected site the options become more limited
The two most common methods for providing redundancy at the distribution layer are dual homing and backup links to other distribution layer routers
Dual homing access layer devices are widely used to ensure redundancy at remote locations within a protected site Additionally, interconnecting access layer devices can also enhance redundancy.
In Figure 7 Router G and Router H are access layer routers that are dual-homed with the backup circuit connected to different branches of the distribution layer:
Figure 7 – Redundant network 6.6.2 Availability/reliability
Operational requirements (OR) assuredly demand a level of availability and reliability of the video network
When designing a network, it is crucial to consider the mean time between failures (MTBF) and the mean time to repair (MTTR) of its components Incorporating logical redundancy is equally important as ensuring physical redundancy According to IEC/TR 62380, IEC 61709, and IEEE 1413.1-2002, the CCTV assembly should achieve a minimum MTBF of 16,000 hours.
Centralized and decentralized network recording and video content analytics
The choice between centralized and decentralized recording and Video Content Analysis (VCA) is influenced by various factors, such as the network's coverage across multiple buildings, which necessitates local recording in each location However, centralized environments simplify the viewing and evaluation of recorded video data Centralized recording occurs when storage devices are linked to the core switch, facilitating efficient data transport across the network for analysis.
Decentralized recording, also known as Video Content Analysis (VCA), occurs when storage devices are linked to the Access layer switch, creating distinct "traffic zones" within the network This setup ensures that recorded or analyzed video data remains within specific subnets, preventing network congestion To effectively implement decentralized recording or VCA, Access switches must be engineered to handle the anticipated traffic levels.
From an IT perspective, centralized solutions are preferred due to their ease of management, backup, and scalability, with all software and hardware concentrated in a control center However, they require powerful core switches, and if one fails, the entire system can halt without failover In contrast, decentralized solutions provide greater stability, as failures in one segment do not impact others, though they face scalability challenges when adding new cameras While centralized systems allow for simple upgrades to storage, decentralized setups necessitate multiple smaller storage devices, which can be more costly than a single large unit.
A disadvantage of centralized VCA is that analysis is performed on the transmitted video stream, which is compressed in the given resolution and frame rate including artefacts
General
This clause outlines essential network requirements and protocols, emphasizing the use of established and widely accepted standards It serves as a minimal interface specification for video streaming and the necessary protocols between VTD servers and clients.
IP – ISO Layer 3
All components of a video transmission device must support Internet Protocol (IP) as the Layer 3 protocol To guarantee compatibility with current TCP/IP networks, these components are required to implement IPv4 as specified in RFC 791, while support for IPv6, as outlined in RFC 2460, is optional.
NOTE In the remainder of this text all references to IP (only ´IP´) should be interpreted as IPv4.
Addressing
IP addressing is fundamental to networking, as each Virtual Terminal Device (VTD) must have a Dynamic Host Configuration Protocol (DHCP) client that searches for a DHCP server upon initial network connection In the absence of a DHCP server in an unmanaged network, the device will self-assign an IP address If the device receives a domain name during the DHCP process, either from a DNS server or through DNS forwarding, it should utilize that name for future network operations; otherwise, it will rely on its assigned IP address.
This clause defines the EN 50132-5-1 IP configuration compliance requirements on VTDs The main requirements are listed below
The video transmission device must include a minimum of one network interface to ensure IP network connectivity, facilitating the exchange of video and data between devices, such as between a video transmission server and a client.
It shall be possible to make static IP configuration on the video transmission device using a network or local configuration interface
The video transmission device should support dynamic IP configuration of local-link address according to RFC
The video transmission device may support any additional IP configuration mechanism
A video transmission device that supports IPv6 shall support stateless IP configuration according to RFC 4862 or shall support stateful IP configuration according to RFC3315 or both
The video transmission device shall support dynamic IP configuration according to RFC 2131
According to RFC 2131, the recommended approach for assigning IP addresses is through DHCP Each node that supports this layer must be capable of obtaining address configuration information from a DHCP server For optimal operation, it is strongly advised to implement a DHCP server within an IP video network.
This standard does not specify any dynamic IP address setting method other than DHCP.
Internet Control Message Protocol (ICMP)
ICMP messages are utilized in various scenarios, such as when a datagram fails to reach its destination, when a gateway lacks the necessary buffering capacity to forward a datagram, and when a gateway advises the host to redirect traffic along a more efficient route.
To enhance troubleshooting capabilities, system entities must implement the PING command in accordance with ICMP (RFC 792) As specified in RFC 1122, every host is required to accept an echo request and respond with an echo reply.
Any network host shall be able to send ICMP “echo request” packets to the video transmission target and listen for ICMP “echo response” replies This provides a valuable diagnostic capability
All video transmission clients shall be compliant to RFC 1122, that any host shall accept an echo-request and issue an echo-reply in return
According to RFC-792, every host must implement an ICMP Echo server function that processes Echo Requests and sends back corresponding Echo Replies An ICMP Echo Request is directed to a specific destination.
IP broadcast or IP multicast address shall be silently discarded
The IP source address in an ICMP Echo Reply shall be the same as the specific-destination address (defined
Diagnostics
To facilitate the diagnosis and maintenance of the video transmission network and its devices, the VTD will indicate the basic network connection status through indicators, such as LEDs located next to the network connector These indicators will display the operating status and signal any potential failures or malfunctions.
The indicator colors for a VTD's network connection status are as follows: a steady green light indicates a 10 Mb connection, green and orange signify 100 Mb, and an orange light represents 1 Gb A blinking indicator every second shows ongoing data transmission, while no light indicates a failed connection A steady red light indicates the VTD is starting up, and during a firmware upgrade, the indicator blinks red rapidly Additionally, a blinking red light every second signals a VTD failure or defect, which may include issues like a broken power supply, malfunctioning fans, or corrupt configuration or firmware.
IP multicast
A VTD that supports multicast must adhere to RFC 1112, while those that do not must explicitly state that "VTD is not supporting multicast." All multicast devices are required to support Source Specific Multicast (SSM) extensions as outlined in RFC 4607, and the use of Any-source multicast, which does not specify the source IP address, is discouraged Additionally, the addressing scheme for source-specific multicasting must conform to RFC 4607, specifically within the range of 232/8.
7.6.2 Internet group multicast protocol IGMP requirements
VDTs should be capable of generating IGMP messages to join/leave a multicast group The minimum version of IGMP implemented should be version 3 according to RFC 3376
Layer 2 devices, such as network switches, must support IGMP snooping as specified in RFC 4541 They should avoid flooding multicast traffic across all interfaces when an IGMP querier is present.
General
Despite the existence of standards, numerous incompatible video streaming and stream control implementations are prevalent today This section outlines the general requirements for applying existing standards in video streaming.
This clause outlines the requirements for video stream transport in VTDs, organized into a main subclause addressing common requirements across all video transports, along with additional subclauses that specify requirements for particular video transport protocols, including RTP and others.
Video transmission clients and servers shall support an IP-based network interface for the transport of session control and video data
Control and video data will be transmitted via TCP/IP as specified in STD 7 RFC 793, or through UDP/IP in accordance with STD 6 RFC 768 For a visual representation of the protocol stack, please refer to Figure 2 of this standard.
Transport protocol
Video transmission devices must support either UDP or TCP, with the option to support both If a VTD encoder or decoder is compatible with both protocols, users can manually select the protocol, or the device may automatically switch between them for optimal stream delivery In cases where a transmission device supports only one protocol, UDP is the preferred choice, although TCP can still be utilized.
NOTE prEN 50132-5-2 defines a protocol on how a VTD requests streams in the selected mode UDP or TCP
Video transport necessitates real-time performance, which is facilitated in IP networks by real-time protocols (RTP) The RTP/UDP profile is the most straightforward and commonly supported choice in contemporary network streaming video systems For reliable transport, RTSP/RTP over TCP is available, allowing for seamless traversal of Network Address Translators and Firewalls.
A VT device shall support at least one of the following transport protocols
The IETF RTP standard, outlined in RFC 3550 and RFC 3551, facilitates the transmission of real-time or streaming data over UDP Encoded video is packaged within RTP packets using video-specific RTP payload formats defined by the IETF Additionally, RTP includes a protocol known as RTCP, which offers feedback on transmission quality.
The IETF documents outline the transport of video content over IP, highlighting their significance for standard video transmission devices Support for the User Datagram Protocol as specified in IETF RFC 769 and the Real-time Transport Protocol (RTP) detailed in IETF RFC 3550 is essential.
UDP as defined in RFC 768 shall be used The checksum in the UDP header shall be used
The VTD shall use the Real-time Transport Protocol (RTP) over UDP as transport protocol as defined in:
RFC 3550 ‘RTP: A transport protocol for real-time applications;
RFC 3551 ‘RTP: Profile for audio and video conferences with minimal control
The IETF TCP standard ensures reliable data transport over IP networks, although it does not guarantee delays, making it the preferred method for transmitting still images To effectively manage this transfer, an application protocol is necessary, which is provided by the IETF HTTP standard RFC2616.
VT devices shall follow the syntax rules for HTTP headers defined in RFC2616 (HTTP 1.1)
All VT Clients and Servers must utilize HTTP 1.1 as specified in RFC 2616, ensuring support for HTTP Keep-Alive to facilitate long-lived connections that enable the exchange of multiple request and response pairs over a single network connection.
If a VTD supports RTP over Transmission Control Protocol (TCP), it shall be based on RFC 4571
NOTE On network paths with IP address translation TCP may be better suited since it is state-full compared to UDP
If TCP transport is implemented, the framing shall be done according to RFC 4571 for "RTP over connection oriented transport"
JPEG over RTP follows the guidelines set by RFC 2435, which outlines the RTP payload format for JPEG-compressed video This implementation is restricted to using default Huffman tables, supports aspect ratios of only 1:1 and 1:2, and limits image sizes to a maximum of 2040 x 2040 pixels due to the constraints of the RTP/JPEG header's bit field.
JPEG images with different aspect ratios, like PAL or NTSC, and those from 4 megapixel image sensors or higher, must include an RTP extension header following the standard header as specified in RFC 3550 VTDs that do not support these features will disregard the header extension, which may lead to incompatible VTD receivers decoding the stream incorrectly, potentially resulting in an incorrect aspect ratio.
If a VTP supports JPEG over HTTP it shall be in accordance with RFC793
HTTP streaming delivers images as separate HTTP responses, while RTP streaming transmits packets containing a sequence of JPEG images for VTD clients A specific MIME type, `multipart/x-mixed-replace;boundary=`, indicates to the VTD that multiple parts will be sent as responses, separated by a defined boundary The TCP connection remains active as long as the VTD receiver requests new frames and the VTD server supplies them.