1、 Recommendation ITU-R BT.1869(03/2010)Multiplexing scheme for variable-length packets in digital multimediabroadcasting systemsBT SeriesBroadcasting service(television)ii Rec. ITU-R BT.1869 Foreword The role of the Radiocommunication Sector is to ensure the rational, equitable, efficient and economi
2、cal use of the radio-frequency spectrum by all radiocommunication services, including satellite services, and carry out studies without limit of frequency range on the basis of which Recommendations are adopted. The regulatory and policy functions of the Radiocommunication Sector are performed by Wo
3、rld and Regional Radiocommunication Conferences and Radiocommunication Assemblies supported by Study Groups. Policy on Intellectual Property Right (IPR) ITU-R policy on IPR is described in the Common Patent Policy for ITU-T/ITU-R/ISO/IEC referenced in Annex 1 of Resolution ITU-R 1. Forms to be used
4、for the submission of patent statements and licensing declarations by patent holders are available from http:/www.itu.int/ITU-R/go/patents/en where the Guidelines for Implementation of the Common Patent Policy for ITU-T/ITU-R/ISO/IEC and the ITU-R patent information database can also be found. Serie
5、s of ITU-R Recommendations (Also available online at http:/www.itu.int/publ/R-REC/en) Series Title BO Satellite delivery BR Recording for production, archival and play-out; film for television BS Broadcasting service (sound) BT Broadcasting service (television) F Fixed service M Mobile, radiodetermi
6、nation, amateur and related satellite services P Radiowave propagation RA Radio astronomy RS Remote sensing systems S Fixed-satellite service SA Space applications and meteorology SF Frequency sharing and coordination between fixed-satellite and fixed service systems SM Spectrum management SNG Satel
7、lite news gathering TF Time signals and frequency standards emissions V Vocabulary and related subjects Note: This ITU-R Recommendation was approved in English under the procedure detailed in Resolution ITU-R 1. Electronic Publication Geneva, 2010 ITU 2010 All rights reserved. No part of this public
8、ation may be reproduced, by any means whatsoever, without written permission of ITU. Rec. ITU-R BT.1869 1 RECOMMENDATION ITU-R BT.1869 Multiplexing scheme for variable-length packets in digital multimedia broadcasting systems*(Question ITU-R 45/6) (2010) Scope This Recommendation deals with multiple
9、xing schemes for variable-length packets over broadcasting channels. Specifications are given for schemes for transporting IP packets over broadcasting channels: encapsulation format, header compressed IP packet format, and transmission control signals. The ITU Radiocommunication Assembly, consideri
10、ng a) that various kinds of signals for multimedia services may be delivered in digital broadcasting; b) that multimedia services have also been introduced in telecommunication networks where IP packets including IPv4 and IPv6 packets are used; c) that those IP packets are variable-length in essence
11、 with a maximum length of 65 535 bytes; d) that an IP-friendly transport mechanism is desirable for multimedia broadcasting services to enable harmonization between broadcasting services and telecommunication services; e) that an MPEG-2 transport stream has been adopted for digital broadcasting as a
12、 means of transporting various kinds of signals; f) that the MPEG-2 transport stream consists of short fixed-length packets of 188 bytes including a 184-byte payload; g) that a multiplexing scheme which enables more efficient transport and less complex reception of variable-length packets is desired
13、 for multimedia broadcasting, recommends 1 that for transport of variable-length packets in digital multimedia broadcasting systems, the multiplexing scheme described in Annex 1 should be used; 2 that compliance with this Recommendation is voluntary. However, the Recommendation may contain certain m
14、andatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall” or some other obligatory language such as “must” and the negative equivalents are used to express requirements.
15、The use of such words shall in no way be construed to imply partial or total compliance with this Recommendation. *This Recommendation should be brought to the attention of ITU-T Study Groups 9 and 16. 2 Rec. ITU-R BT.1869 Annex 1 Multiplexing scheme for variable-length packets References Normative
16、references 1 IETF RFC 791: Internet Protocol. This IETF standard is available at the following address. http:/www.ietf.org/rfc/rfc791.txt 2 IETF RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. This IETF standard is available at the following address. http:/www.ietf.org/rfc/rfc2460.txt 3
17、 IETF RFC 768: User Datagram Protocol. This IETF standard is available at the following address. http:/www.ietf.org/rfc/rfc768.txt 4 ETSI TS 102 606 v1.1.1(2007-10): Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol. 5 ETSI EN 301 192 v1.4.2(2008-04): Digital Video Broadc
18、asting (DVB); DVB specification for data broadcasting. Informative references 6 ITU-T Recommendation H.222.0, 2006: Information technology Generic coding of moving pictures and associated audio information: Systems. Abbreviations ACM adaptive coding and modulation AMT address map table ATM asynchron
19、ous transfer mode CID context identification CRC cyclic redundancy check DVB digital video broadcast ETSI European Telecommunications Standards Institute GSE generic stream encapsulation IETF Internet Engineering Task Force IGMP Internet Group Management Protocol INT IP/MAC notification table IP int
20、ernet protocol MAC media access control Rec. ITU-R BT.1869 3 MLD multicast listener discovery MPE multi protocol encapsulation MPEG Moving Pictures Experts Group NIT network information table ONU optical network unit PES packetized elementary stream RFC Request For Comment (IETF standard) SN sequenc
21、e number TLV type length value TS transport stream UDP user datagram protocol VCM variable coding and modulation 1 Introduction Various multimedia broadcasting services are expected to be made possible by adopting the multiplexing schemes for fixed-length MPEG-2 TS packets and that for variable-leng
22、th packets as depicted in Fig. 1. FIGURE 1 Protocol stack BT.1869-01Multimedia broadcastingReal-time services IP-based servicesVideo and audio Data and control A/V file ControlPES Section IP packet Signalling packetMPEG-2 TS Multiplexing scheme for variable- length packetsTransmission slot (channel
23、coding and modulation)Physical layer (terrestrial/satellite)2 Requirements for multiplexing scheme for variable-length packets Because broadcasting services use radio spectrum, which is a finite resource, and similar services using the Internet have been launched, a multiplexing scheme for variable-
24、length packets should support the following requirements: a) variable-length packets of various formats including IPv4 and IPv6 packets can be multiplexed; b) a maximum 65 535-byte-long packet can be multiplexed without fragmentation; c) the overhead needed to transmit packets should be small; d) th
25、e receiving process should be simple enough to process received packets at a high packet rate. 4 Rec. ITU-R BT.1869 3 Encapsulation scheme for variable-length packets 3.1 Format of type-length-value container The type-length-value (TLV) multiplexing scheme is shown in Fig. 2 and Table 1. This scheme
26、 can multiplex variable-length packets of any format unless packet filtering and fragmentation are needed. The type of packet is indicated by the packet_type field, and the length of the packet is indicated by the length field. Header compressed IP packets and transmission control signals can also b
27、e encapsulated into TLV containers. This scheme enables multiplexing a maximum 65 535-byte-long packet without fragmentation. The transmission overhead is small and the TLV multiplexing scheme efficiently uses transmission capacity. FIGURE 2 Format of TLV container BT.1869-02Packet_type= 0 01 Length
28、01Reserved_future_use26816Order of transmissionIPv4_packet816816816IPv6_packetPacket_type= 0 02 LengthPacket_type= 0 03 LengthPacket_type= 0 FE Length816Packet_type= 0 FF LengthCompressed_ip_packetSignalling_packetNULL(0 FF) 8 N TABLE 1 TLV container Syntax No. of bits Mnemonic TLV 01 2 bslbf reserv
29、ed_future_use 6 bslbf packet_type 8 bslbf length 16 uimsbf if (packet_type=0x01) IPv4_packet ( ) Rec. ITU-R BT.1869 5 TABLE 1 (end) Syntax No. of bits Mnemonic else if (packet_type=0x02) IPv6_packet ( ) else if (packet_type=0x03) compressed_ip_packet( ) else if (packet_type=0xFE) signalling_packet (
30、 ) else if (packet_type=0xFF) for(i=0;iN;i+) NULL 8 bslbf reserved_future_use This indicates that the value may be used for future extensions. Unless otherwise specified within this document, all reserved bits are set to “1”. packet_type This indicates which type of packet is encapsulated. It is cod
31、ed according to Table 2. TABLE 2 Packet type assignment values Value Description 0x00 Reserved 0x01 IPv4 packet 0x02 IPv6 packet 0x03 IP packet with header compression 0x04 0xFD Reserved 0xFE Signalling packet 0xFF NULL packet length This field specifies the number of bytes immediately following the
32、 length field to the end of the TLV container. IPv4_packet ( ) This indicates an IPv4 packet, which has an IPv4 header defined in RFC 791 1. IPv6_packet ( ) This indicates an IPv6 packet, which has an IPv6 header defined in RFC 2460 2. compressed_ip_packet ( ) This indicates an IP packet having comp
33、ressed headers presented in 4. signalling_packet ( ) This indicates the transmission control signals presented in 5. NULL These are the fixed 8-bit stuffing bytes with the value “0xFF”. 6 Rec. ITU-R BT.1869 3.2 Format of Generic Stream Encapsulation packet The Generic Stream Encapsulation (GSE) spec
34、ified in ETSI TS 102 606 4 is able to encapsulate variable-length packets, such as IP packets. Each GSE packet may have a label field and a CRC field. Receivers can filter packets they receive by using the label field of each packet. When GSE packets are fragmented into pieces to be set into transmi
35、ssion slots, the integrity of the restored packets can be ensured by checking the CRC. The GSE protocol has been devised as an adaptation layer to provide network layer packet encapsulation and fragmentation functions over Generic Stream. GSE provides efficient encapsulation of IP packets over varia
36、ble-length layer 2 packets, which are then directly scheduled on the physical layer into baseband frames. GSE maximizes the efficiency of IP packet transport reducing overhead by a factor of 2 to 3 with respect to MPE over MPEG-TS. This is achieved without any compromise of the functionalities provi
37、ded by the protocol, due to the variable-length layer 2 packet size, suited to IP traffic characteristics. GSE also provides additional features that increase the protocol flexibility and applicability. Some key GSE functions/characteristics are: 1 Support for multi-protocol encapsulation (e.g. IPv4
38、, IPv6, MPEG, ATM, Ethernet, and VLANs). 2 Transparency to network layer functions, including IP encryption and IP header compression. 3 Support of several addressing modes: In addition to the 6-byte MAC address (including multicast and unicast), it supports a MAC addressless mode, and an optional 3
39、-byte address mode. 4 A mechanism for fragmenting IP packets or other network layer packets over baseband frames to support ACM/VCM. 5 Support for hardware filtering. 6 Extensibility: additional link protocols can be included through specific protocol type values (e.g. layer 2 security, IP header co
40、mpression, etc.). 7 Low complexity. 4 IP packet header compression (Header Compression for Broadcasting: HCfB) When IP packets are to be conveyed as variable-length packets, it is convenient for broadcasting services to have much compatibility with various services using telecommunication networks.
41、Each IP packet generally has at least 20 bytes of IPv4 header or 40 bytes of IPv6 header, besides 8 bytes of UDP header. Based on these headers, routers in telecommunication networks need to decide which way each packet is to be transferred. Hence, these headers are very important in telecommunicati
42、on networks. On the other hand, they are never necessary in broadcasting channels, since all packets in broadcasting channels are just transferred to receivers. Transfer throughput can be increased if this unused header information is compressed. The format of a header compressed IP packet is shown
43、in Fig. 3 and Table 3. This reduces IP and UDP headers to 3 or 5 bytes of compressed header for most packets. When content is transferred on IP packets, most fields in these headers are constant during connection. Once an uncompressed header is sent, these fields with the same values in the followin
44、g packets may not necessarily be sent. Based on this principle, IP and UDP headers with all the information are sent at long intervals, and the compressed headers are sent for almost all packets. The compressed headers are restored at a receiver by filling them with the header of a preceding packet
45、that has all the information. Rec. ITU-R BT.1869 7 FIGURE 3 Format of header compressed IP packet BT.1869-03CID SN412Data byte8Ipv4_header_wo_length32128Data byteIdentification16Data byte323048888 NOrder oftransmissionCID_header_type= 0 21CID_header_type= 0 60CID_header_type= 0 20CID_header_type= 0
46、61Ipv6_header_wo_lengthUDP_header_wo_length8 N8 N8 NUDP_header_wo_lengthData byteTABLE 3 Header compressed IP packet Syntax No. of bits Mnemonic compressed_ip_packet ( ) CID 12 uimsbf SN 4 uimsbf CID_header_type 8 uimsbf If (CID_header_type=0x20) IPv4_header_wo_length ( ) UDP_header_wo_length ( ) fo
47、r(i=0;iN;i+) packet_data_byte 8 bslbf else if (CID_header_type=0x21) Identification 16 bslbf for(i=0;iN;i+) packet_data_byte 8 bslbf else if(CID_header_type=0x60) IPv6_header_wo_length ( ) UDP_header_wo_length ( ) for(i=0;iN;i+) 8 Rec. ITU-R BT.1869 TABLE 3 (end) Syntax No. of bits Mnemonic packet_d
48、ata_byte 8 bslbf else if(CID_header_type=0x61) for(i=0;iN;i+) packet_data_byte 8 bslbf CID Context IDentification This indicates the IP flow, which is identified by the combination of the following fields. For IPv4, this is source IP address, destination IP address, protocol, source port number, and
49、 destination port number. For IPv6, this is source IP address, destination IP address, next_header, source port number, and destination port number. SN Sequence Number This is a 4-bit field incrementing with each packet with the same CID. The SN wraps around to 0 after its maximum value. CID_header_type This field indicates which type of header the packet has. It is coded according to Table 4. TABLE 4 CID_header_type assignm
