A Comparison of IP Datagrams Transmission using MPE and ULE over Mpeg-2/DVB Networks

Size: px

Start display at page:

Download "A Comparison of IP Datagrams Transmission using MPE and ULE over Mpeg-2/DVB Networks"

Gilbert Williamson
5 years ago
Views:

1 A Comparison of IP Datagrams Transmission using MPE and ULE over Mpeg-2/DVB Networks Teh Chee Hong 1, Wan Tat Chee 2, Rahmat Budiarto 3 Network Research Group School of Computer Science Universiti Sains Malaysia 11800, Minden, Penang, Malaysia chteh@nrg.cs.usm.my 1, tcwan@cs.usm.my 2, rahmat@cs.usm.my 3 Abstract Digital Video Broadcasting (DVB) defines the carriage of multimedia and internet information to client by means of MEPG-2 Transport Stream. The DVB standards also allow the same system to transmit Internet Protocol (IP) data. This data broadcasting technology enables the broadcast of large amount of data to the personal computer over satellite or other broadcasting network. This allows the MPEG-2 TS bearer become a hop in IP network. The intention of this paper is to compare the existing Multiprotocol encapsulation and Ultra Lightweight encapsulation methods for IP transmission over DVB networks. Keywords DVB, MPEG-2 TS, MPE, ULE, DSM_CC I. INTRODUCTION The rapid development of the military communication satellites has brought up the commercial communication satellite systems. In other hand, the evolution of video compression giving a picture quality of data rates of 2Mbit/s at least as good as that received on the average domestics PAL television set or played back from a video recorder, created great interest and provided a strong market drive for broadcaster to implement a complete Direct-To-Home (DTH) satellite program delivery infrastructure having a capacity in excess of 100 channels from a single satellite. For such a system, leading to mass market of receivers of public, standardization of the technical specification was essential. This task was taken up by the Digital Video Broadcasting (DVB) project in 1993 [1]. In the early 1991s, at that time it was called the European Launching Group (ELG) for DVB. Developments in DVB enabled packet data services over DVB, i.e., Internet/World Wide Web (WWW), providing high speed transmission using a DVB satellite hub station to transmit packet data to the same small satellite dish as used for TV distribution. II. Digital Video Broadcasting DVB is a set of standards that define digital broadcasting using existing satellite, cable, and terrestrial infrastructure. This body was officially inaugurated in September 1993 [2]. Today, the DVB projects consist of a voluntary group of currently more than 220 organizations which have joined forces to make possible the development of standards for DVB in all parts of the world. DVB systems are developed through consensus in the working groups of the Technical Module. Members of the groups are drawn from the general assembly of the project. Once the standards published, DVB will publish the standards through European Telecommunications Standards Institute (ETSI), they are available at a nominal cost for anyone, worldwide. In fact there are several DVB standards for different transmission media. Some of these are [3]: a) Digital Video Broadcasting- Satellite (DVB-S) b) Digital Video Broadcasting- Cable (DVB-C) c) Digital Video Broadcasting- Terrestrial (DVB-T) The DVB-S system is directly compatible with MPEG-2 coded TV signals. The modem transmission frame is synchronous with the MPEG-2 multiplex transport packets. The video, audio, control data and user data are all inserted into fixed length MPEG-2 transport packets (MPEG-2 TS). III. MPEG-2 Transport Stream MPEG-2 is the newly formed standard for high quality video and audio compression which applicable to high quality realtime conferences. The MPEG-2 standard defines two ways for multiplexing different elementary stream types to form a program: Program Stream and Transport Stream. The MPEG-2 Transport Stream (MPEG-2 TS) was designed for transporting MPEG-2 over a noisy environment or transmission channels where error occurs. The TS is a stream that consists of consecutive and relatively short fixed-length TS packets. The MPEG-2 TS packet length is 188 bytes. Each TS packet structure is starting with fixed length of 4 bytes TS header, followed by 184 bytes adaptation field as a header extension and payload (data section). Another field in the TS header, which plays the important role in the operation of the TS, is the 13 bit Packet Identifier (PID). The PID determines, to which program a TS packet belongs to and the PID is also unique for each programs. The format of the MPEG-2 TS is described using the Figure 1.0 below: 1

2 to form a series of MPEG-2 TS packets. Figure 2.0 illustrates the packet format of MPE encapsulation method. Figure 1.0 Transport Stream and structure IV. IP Transmission over DVB Network On top of common IP network and transport layer, many powerful application layer standards support popular Point-to- Point or Unicast application like the WWW, File Transfer Protocol (FTP) and others. In the year 1993, the Moving Picture Expert Group (MPEG) standards body had came out with MPEG-2. The MPEG-2 protocol has became the major digital video compression standard, can be used for variety of applications. Along with the work done for MPEG-2, it enables the Internet protocol packets to be carried over an MPEG-2 TS. IP packets can be carried over an MPEG-2 TS network and data is already being sent over DVB networks using MPEG-2 TS. These TS have traditionally been oriented to containing MPEG-2 Video and Audio. This allows the MPEG-2 TS bearer network to become a hop in an IP network. Data broadcasting is seen as an important extension of the MPEG-2 based DVB-S. In an effort to standardize these services, the DVB specification has identified four different application areas with different requirements for the data transport. Data maybe sent using one of four profiles [4]: a) Data piping ( using Ultra Lightweight Encapsulation) b) Data streaming c) Multi-protocol encapsulation d) Data carousels Figure 2.0 MPE packet format VI. Ultra Lightweight Encapsulation (ULE) An ULE is layered direct on transport stream. This approach is known as Data Piping and it is a new encapsulation method or mechanism for the transport of IPv4 and IPv6 datagrams and other network protocol packets directly over ISO MPEG-2 TS as TS Private Data [6]. The encapsulation is also suited to transport of the protocol packets and bridged Ethernet frames. Other that that, ULE also supports DVB architecture, the Advanced Television Systems Committee (ATSC) system and other similar MPEG-2 based transmission systems. In future, satellite networks should support IPv6 in an efficient and standard way. But using satellite capacity is a very expensive resource, so using ULE encapsulation can save the satellite resources. ULE encapsulation doesn t add a lot of overhead for encapsulation, and it is different with the MPE encapsulation. ULE places packets directly into the MPEG-2 transport stream. The characteristic of ULE is it has a simple header with only a few fields and it makes ULE packet easy for processing. This header is significant smaller and less complex than MPE header. Besides that, ULE header also contains 2 bytes Type Fields that allows the receiver to identify the protocol being transported. Figure 3.0 illustrates the packet format of ULE encapsulation method. V. Multi-Protocol Encapsulation (MPE) The MPE method provides a mechanism for transporting data network protocols on top of the MPEG-2 Transport Streams in DVB networks. Besides that, it also can be used for transportation of any other network protocol by using the LLC/SNAP encapsulation. It covers unicast, multicast and broadcast. The 48-bit MAC addresses are used for addressing receivers. However, DVB does not specify how the MAC addresses are allocated to the receivers. Using MPE, each IP packet arriving at an MPEG Encapsulator Gateway has an MPE header attached to form a Protocol Data Unit (PDU). The entire PDU is then fragmented Figure 3.0 ULE packet format 2

3 VII. Comparison of MPE and ULE a) Transporting IP packets The DVB MPE format is compliant with the Digital Storage Media Command and Control (DSM_CC) section format for private data. In order to carry IP datagram or packets in MPEG-2 TS, DSM_CC defines a type of section called the datagram section. This is compatible with the normal DSM_CC private section format, but it extends it to make it easier for receivers to filter packets based on MAC address using hardware section filters. The Datagram section is suitable for any kind of OSI layer 3 networking protocol, but DVB has optimized the section format to make it easier to use MPE encapsulation with IP datagrams. But for ULE, the process to fit the IP datagram into MPEG-2 Ts is different because ULE is not compliant with the DSM_CC. The Protocol Data Unit (PDU) or also known as IP packets or Ethernet frames from other network are encapsulated to form a Subnetwork Data Unit (SNDU) by adding a SNDU header to the PDU [6]. The SNDU can be transmitted over MPEG-2 transmission network by placing it either in the payload of a single TS packet or in case that the SNDU size is to large, it may be fragmented into a series of TS packets. b) MPE/ULE header fields and size The packet format for MPE and ULE are different and both of these encapsulation methods carry different overhead bytes. For MPE, the basic header format is carrying a MAC destination address and has no payload type field [5]. In this case, the most current Receiver driver software will assume that the payload is IPv4. But if the payload uses other protocol instead of IPv4 like IPV6 packets or IPv4 ARP message, the payload type field is needed to demultiplex the received packet. So in order to allow payload to uses a protocol other than IPv4, it require LLC/SNAP field. For ULE, the payload can carry any type of protocol in a SNDU. The Type field in ULE indicates the type of payload being carried or the presence of a Next-, and it does not require any optional LLC/SNAP header [6]. The set of values that may be assigned to this field is divided into two parts to indicate the Next- exists and via-versa. The Destination Address Present Field, D-bit is optional for SNDU, but it must be carried for IP unicast packets destined to routers that are sent using shared links. When the D-bit value indicates the presence of Destination Address field, a Network Point of Attachment (NPA) field wills directly follows the SNDU Type field. The NPA addresses are 6 bytes number and it used to identify the Receivers in a MPEG-2 transmission network that should process a received SNDU. Table 1.0 illustrates the summary of the MPE and ULE header field and size. Overhead (Bytes) Encapsulation Fields and Function 16 MPE MPE, No LLC/SNAP No Ether type-assume IPv =24 MPE MPE, with LLC/SNAP Ether type allows use of other protocols-ipv6,arp 8 ULE ( D=1 ) ULE, omitting destination receiver address 8+ 6 =14 ULE ( D=0 ) ULE, including destination receiver address facilitating routing and L2 filtering 8+14 =22 ULE ( D=1 ) ULE, containing Ethernet bridging header, but excluding Ethernet FCS. Table 1.0 Summary of MPE/ULE overhead c) MPE/ULE Flexibility The ULE Type Field was designed to allow transmission of all types of frames supported by IEEE Ethernet. The values of Type Field lesser than 1536 was specified by IANA and these values indicate a next-layer-header. All values above 1535 follow the IEEE/DIX type assignment for Ethernet and are assigned from separate IANA registry for ULE [6]. Compared to MPE, ULE provides a greater flexibility, as no modification required to the protocol to support new protocol. For MPE, it needs LLC/SNAP for transporting other network protocol. Besides that, the ULE has reserves a set of undefined code point value to be use in future. These code point values may be used for testing, operator-specific packet types or for futures specification of new standards-based encapsulation, such as the development of Ethernet bridging, packet encryption and header compression. But for MPE, its flexibility is limited because the encapsulation process is depending on the LLC/SNAP. In ULE, the further use of code-point has been proposed, to allow the encapsulation to provide optional extension headers a flexible and future proof method for extension of SNDU header. As a summarization of this section, we can conclude that the strength of MPE is depending on its compatibility to the DSM_CC control plane and the strength of ULE is depending on its efficient support for a range of network protocol.. d) MPE/ULE Transmission efficiency The transmission efficiency of both MPE and ULE encapsulation is depending on the IP packet size. The term transmission efficiency is defined as: Encapsulated Payload Bytes Transport Efficiency = Total Bytes Transmitted 3

4 MPE Vs ULE:TCP Performance Over Satellite Link Traffic Type= TCP with FTP, Encapsulation Timer=20ms Throughput (Kbps) Packet Size (Bytes) Graph1.0 Transmission Efficiency MPE vs. ULE (Refer from Study of Encap. and Protocol Performance [7]) According to the graph above, it has shown that ULE provides transmission performance improvements and significant functional benefit over MPE, allowing the encapsulation of a different of packet types using a standard encapsulation header. MPE provides optional packing, whereas ULE is being developed with TS Packet Packing as the default mode of operation. Packing is a method that allows a single TS packet to carry more than one SNDU if the TS packet has a sufficient space. Packing can provide a significant benefit for IP traffic because it can reduce the encapsulation overhead from 8-80% to 1-30%-largest gain for the smallest packets. Besides that, the performance of ULE transmission efficiency still can be further improved, it is because the ULE header is small if compare with MPE. The transport efficiency graph for MPE and ULE is indicated in Graph1.0. e) Analysis of MPE/ULE performance with Ns2 A set of measurement and simulation for MPE and ULE were run using Ns2 simulation tools. The MPE and ULE encapsulation source code is adopted from the version given out by European Space Agency (ESA). The simulation computes the number of packets sent to the application, the number of bytes transmitted, the throughput and the delay. The following section presents the results of the comparison: i. Throughput Comparison The network throughput is defined as the average number of packets successfully received by their intended receivers in a time slot. In the following throughput comparison, we compared the throughput between the MPE and ULE under the same parameter. Second, we investigated the effects of the encapsulation timer on the throughput for both encapsulations. Throughput (Kbps) Multi-Protocol Encapsulation Ultra Lightweight Encaspulation Graph 2.0: Throughput MPE vs. ULE, Timer=20ms MPE Vs ULE:TCP Performance Over Satellite Link Traffic Type=TCP with FTP, Encaspulation Timer=40ms From the Graph , the interesting observation from both two graphs is that with the same physical parameter, the throughput for ULE was significant higher than MPE in the case for Timer = 20ms. It can be seen that the timer had an impact on the performance of the encapsulation. It is because when packing is occurring, the encapsulator may wait for the incoming data to pack. So waiting for data could bring the problems to the data stream. The choice of timer will allow optimizing the encapsulation for a certain application or application type. ii. Overhead Comparison Packet Size (Bytes) Multi-Protocol Encapsulation Ultra Lightweight Encaspulation Graph 3.0: Throughput: MPE vs. ULE, Timer=40ms The amount of overhead is a function of the size and timing of the IP packets being sent. For small packet size, ULE has a major advantage over MPE as many small packets can be packed in a single cell. But the advantage of ULE becomes less when large packets size present. It is because its gain is loss to cell padding. The overhead is: Overhead = ( PDU SNDU _ H + CRC) + Padding PDUlenght PDU X100% 4

5 Graph 4.0: UDP Packet size 512B Graph 7.0: Average Delay for packet 1500B Graph 5.0: UDP Packet size 1500B iii. Average Delay Comparison MPE is significantly more complex than ULE and incurs very significant overhead. As predicted, for small packet, the average delay for MPE is significantly higher that ULE. It is because of the significant overhead of MPE; packing of small packet in MPE will added a little delay, The Graph shown the Average delay for MPE and ULE on different size of packet. Graph 6.0: Average Delay for packet 512B 5 VIII. Conclusion This paper has discussed the existing of MPE encapsulation method and new ULE encapsulation method. As a conclusion, ULE has provided significant benefits such as native support for new protocol and application. Currently, some existing header compression schemes have been investigated to use with ULE, in order to improve its flexibility and efficiency over MPEG-2 DVB networks. IX. References [1] Ulrich Reimers, Digital Video Broadcasting, Communications Magazine, IEEE, Volume: 36, Issue: 6, June 1998 Pages: [2] J.R.Forrest, The Commercial Prospects for Digital Video Broadcasting, DVB The Future for Television Broadcasting?, IEEE Colloquium on (Digest No.1995 /142), 27 Jun 1995 Pages:7/1-7/7 [3] J Sesena, Commonalities and peculiarities of DVB-S, DVB-C and DVB-SMATV systems (COMM's and PEC's of DVB systems), Broadcasting Convention, IBC 95., International, Sep 1995, Pages: [4] European Telecommunications Standards Institute, Digital Video Broadcasting (DVB); DVB specification for data broadcasting, European Telecommunications Standards Institute, Jun 2004, Pages: 7/ 78-8/78 [5] Dr.Gorry Fairhurst and Alastair Matthews, A comparison of IP transmission using MPE and a new lightweight encapsulation, University of Aberdeen, 2003 [6] Gorry Fairhurst, Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG- 2/DVB networks,internet Engineering Task Force, Internet Draft, May 2004 [7] Marie-Jose Montpetit, Michael Schmidt, Study of Encapsulation and Protocol Performance- Final Report, European Space Agency, March 2004

Ultra Lightweight Encapsulation for Efficient IPv6 Transport

Ultra Lightweight Encapsulation for Efficient IPv6 Transport Bernhard Collini-Nocker, Hilmar Linder, Wolfram Stering Department of Scientific Computing Paris-Lodron University of Salzburg, Austria Email: