Before we can go on to look at testing IPTV systems, it would be useful to provide an overview of the technologies involved.
Figure 3 shows an example of a typical IP network structure. Content is first delivered into the video headend; this can be done in a variety of formats over a number of different delivery mechanisms (e.g. satellite and terrestrial). From here, the data are encoded, packetised, and multiplexed appropriately for receipt by the consumer premises equipment (normally in the form of an MPEG Transport Stream) and are then sent to the Core Network which is used for the transmission of services at a national (or even global) level. The system services (voice, video and data) are then passed to the Access Network for distribution over the “last mile” to the consumer.
A variety of access network technologies (such as xDSL, HFC and FTTx) can be used to reach the subscriber; the type of technology used will depend on what sort of connectivity is required at the subscriber site. All of these additional technologies add complexity to the distribution models, and bandwidth may need to be carefully managed to ensure good QoS and QoE for the subscribers.
Video Compression Technologies
Earlier in the series we explained that insufficient bandwidth over an IPTV network can lead to “bursty” video delivery. One way to alleviate bandwidth restrictions is to use video compression technologies.
MPEG-2 encoding, H.264/AVC and VC-1
MPEG-2 encoding compresses the video frames into three different types of frames: I-frames, B-frames, and P-frames. An I-frame contains all the information in one frame of the video stream such that an MPEG decoder can recreate the original frame using only the information from the I-frame. To achieve the required video compression, special spatial and temporal encoding techniques are used to create B- and P-frames that contain partial information associated with the I-frame. The picture is recreated using the I-frame and the compressed information in the B and P-frames
These I-, B- and P-frames are carried across the network in 188 byte MPEG Transport Stream (TS) packets which are encapsulated in IP packets (a single IP packet contains approximately seven TS packets). Dropping any packet (particularly those containing I-frames) can lead to serious QoE issues.
The use of new compression technologies such as H.264/AVC or VC-1 can further reduce bandwidth usage; H.264, for example, can offer up to a 50% reduction in bandwidth utilisation for the same picture quality compared to existing MPEG-2 compression. These new technologies can, however, render video streams more susceptible to dropped packets (as each packet effectively contains more information). Clearly this will have a greater impact on the viewing experience.
Transmission across an IP Network
There are many different protocols used in modern IPTV systems to govern the transmission of voice, video and data services across the network. In this article we will consider four:
UDP and RTP (IP transmission protocols)
RTSP and IGMP (signalling protocols)
First, however, we should look at the basic structure of an IP packet.
IP Packets / Datagrams: Structure
The term ‘datagram’ or ‘packet’ is used to describe a chunk of IP data. Each IP datagram contains a specific set of fields in a specific order so that any receiver knows how to decode the data stream. Many protocols can be encapsulated within the IP packet.
UDP (User Datagram Protocol)
UDP is one of the core protocols of the IP protocol suite. The datagram headers contain:
- 16 bit source port address.
- 16 bit destination port address.
- 16 bit length field.
- 16 bit checksum.
UDP requires a relatively small overhead compared with the amount of data in the payload. This simplicity is one of the main advantages of UDP, however it can also cause difficulties. For example its stateless form means there is no way to know whether a sent datagram ever arrives, and there are no reliability or flow control guarantees which can identify lost packets and re-send them as necessary.
UDP has been described as a ‘fire and forget’ protocol because it is difficult to discover if a packet has been lost before the subscriber does. In an IPTV environment, where it is essential that the video data is delivered reliably and in the correct sequence, the use of UDP can be precarious.
RTP (Real Time Protocol)
RTP describes a packet-based format for the delivery of audio and video data. RTP actually consists of two closely linked parts:
Real Time Protocol provides time stamping, sequence numbering, and other mechanisms to take care of timing issues. Through these mechanisms, RTP provides end-to-end transport for real-time data over a network. Use of sequence numbering also enables lost or out of order packets to be identified.
Real Time Control Protocol is used to get end-to-end monitoring data, delivery information, and QoS.
It should be noted however that while RTP allows lost packets to be identified, it does not define any mechanisms for recovering from such packet loss.
RTSP (Real Time Streaming Protocol)
RTSP describes a set of VCR-like controls for streaming media. Typically, RTSP messages are sent from client to server, although some exceptions exist where the server will send to the client.
In IPTV systems, RTSP is used in VoD applications for the consumer to access and control content stored at the VoD servers. VoD is essentially a one-to-one communication established using unicast.
IGMP (Internet Group Management Protocol)
IP multicasting involves the simultaneous delivery of an IP datagram to a set of subscribers who wish to receive a particular program (a “host group”).
IGMP is the protocol used to handle channel changes in an IPTV system. In response to remote control commands, a series of IGMP commands to leave the current multicast and join a different service are issued. The time that it takes to execute these commands has a direct impact on channel change times.
Multicasting, using IGMP, allows control of which content goes to which users and therefore controls the amount of data being sent across the network at any one time.
This article gives only a brief overview of some of the technologies involved in the delivery of IPTV services; however even this “bird’s-eye view” plainly demonstrates the degree of complexity inherent in IPTV systems. Clearly, this complexity will present many technical challenges for service providers when trying to meet the stringent QoS and QoE requirements needed for successful IPTV delivery.
In the next part, we will begin to discuss how we can test IPTV systems.