ITU-R BT 1887-2011 Carriage of IP packets in MPEG-2 transport streams in multimedia broadcasting《多媒体广播MPEG-2传送流中IP数据包的传输》.pdf

《ITU-R BT 1887-2011 Carriage of IP packets in MPEG-2 transport streams in multimedia broadcasting《多媒体广播MPEG-2传送流中IP数据包的传输》.pdf》由会员分享，可在线阅读，更多相关《ITU-R BT 1887-2011 Carriage of IP packets in MPEG-2 transport streams in multimedia broadcasting《多媒体广播MPEG-2传送流中IP数据包的传输》.pdf（13页珍藏版）》请在麦多课文档分享上搜索。

1、 Recommendation ITU-R BT.1887(03/2011)Carriage of IP packets in MPEG-2 transport streams in multimedia broadcastingBT SeriesBroadcasting service(television)ii Rec. ITU-R BT.1887 Foreword The role of the Radiocommunication Sector is to ensure the rational, equitable, efficient and economical use of t

2、he 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 World and Regi

3、onal 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 for the subm

4、ission 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. Series of ITU-R R

5、ecommendations (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, radiodetermination, amat

6、eur 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 Satellite news ga

7、thering 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, 2011 ITU 2011 All rights reserved. No part of this publication may be

8、 reproduced, by any means whatsoever, without written permission of ITU. Rec. ITU-R BT.1887 1 RECOMMENDATION ITU-R BT.1887 Carriage of IP packets in MPEG-2 transport streams in multimedia broadcasting (Question ITU-R 45-2/6) (2011) Scope This Recommendation deals with carriage of IP packets in MPEG-

9、2 transport streams in digital multimedia broadcasting. Specifications are given for encapsulation techniques and IP header compression techniques. The ITU Radiocommunication Assembly, considering a) that various kinds of signals for multimedia services may be delivered in digital broadcasting; b) t

10、hat ITU-T Recommendation H.222.0 (MPEG-2 systems) is adopted as service transport and service multiplex methods of most digital broadcasting systems; c) that an IP packet has become another transport method for various kinds of signals with the increasing growth of IP-based telecommunication network

11、s; d) that there is a growing demand to harmonize broadcasting services with telecommunication services; e) that for existing digital broadcasting systems that only support MPEG-2 transport stream as their input stream format, it is desirable to have the capability of carrying IP packets into an MPE

12、G-2 transport stream; f) that it is desirable to limit the number of different encapsulation schemes across different broadcasting systems, recommends 1 that for carriage of IP packets in MPEG-2 transport streams in multimedia broadcasting, the encapsulation schemes described in Annex 1 should be us

13、ed; 2 that compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (e.g. to ensure interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall” or

14、 some other obligatory language such as “must” and the negative equivalents are used to express requirements. The use of such words shall in no way be construed to imply partial or total compliance with this Recommendation. 2 Rec. ITU-R BT.1887 Annex 1 Carriage of IP packets in MPEG-2 transport stre

15、ams in multimedia broadcasting References Normative references 1 ITU-T Recommendation H.222.0 (2006) Information technology Generic coding of moving pictures and associated audio information: Systems. 2 ISO/IEC 13818-6 (1998) Information technology Generic coding of moving pictures and associated au

16、dio information Part 6: Extensions for DSM-CC. 3 Recommendation ITU-R BT.1869 (2010) Multiplexing scheme for variable-length packets in digital multimedia broadcasting systems. 4 ETF RFC 3095 (July 2001): Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed.

17、 This IETF standard is available at the following address: http:/www.ietf.org/rfc/rfc3095.txt 5 IETF RFC 4326 (December 2005): Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS). This IETF standard is available at the following addres

18、s: http:/www.ietf.org/rfc/rfc4326.txt 6 ATSC Doc. A/90 (July 2000): ATSC Data Broadcast Standard. 7 ATSC Doc. A/92 (January 2002): ATSC Standard: Delivery of IP Multicast Sessions over ATSC Data Broadcast. 8 ETSI EN 301 192 v1.5.1 (2009-11): Digital Video Broadcasting (DVB); DVB specification for da

19、ta broadcasting. 9 IETF RFC 791 (September 1981): Internet Protocol. This IETF standard is available at the following address: http:/www.ietf.org/rfc/rfc791.txt 10 IETF RFC 2460 (December 1998): Internet Protocol, Version 6 (IPv6) Specification. This IETF standard is available at the following addre

20、ss: http:/www.ietf.org/rfc/rfc2460.txt 11 ISO/IEC 8802-2 (1998): Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements Part 2: Logical link control. 12 ISO/IEC TR 8802-1 (2001): Information technology Telecommuni

21、cations and information exchange between systems Local and metropolitan area networks Specific requirements Part 1: Overview of Local Area Network Standards. 13 ITU-T Recommendation J.122 (2007) Second-generation transmission systems for interactive cable television services IP cable modems. 14 ITU-

22、T Recommendation J.222.2 (2007) Third-generation transmission systems for interactive cable television services IP cable modems: MAC and Upper Layer protocols. Rec. ITU-R BT.1887 3 Abbreviations ATSC Advanced Television Systems Committee CRC Cyclic Redundancy Check DSM-CC Digital Storage Media-Comma

23、nd and Control DVB Digital Video Broadcast ESP Encapsulating Security Payload ETSI European Telecommunications Standards Institute HCfB Header Compression for Broadcasting IEC International Electrotechnical Commission IETF Internet Engineering Task Force IP Internet Protocol ISO International Organi

24、zation for Standardization LLC Logical Link Control MAC Media Access Control MPE Multi-Protocol Encapsulation MPEG Moving Pictures Experts Group PDU Protocol Data Unit PES Packetized Elementary Stream RFC Request For Comment (IETF standard) ROHC Robust Header Compression RTP Real-time Transport Prot

25、ocol SNAP SubNetwork Attachment Point SNDU SubNetwork Data Unit TS Transport Stream UDP User Datagram Protocol ULE Unidirectional Lightweight Encapsulation 1 Introduction Many of the already deployed digital broadcasting systems transfer an MPEG-2 TS 1 as their input stream format. There are two pos

26、sible procedures for carrying IP packets in an MPEG-2 TS in such broadcasting systems: one is encapsulation into a private stream of an MPEG-2 TS, as depicted in Fig. 1, and the other is encapsulation into a section of an MPEG-2 TS, as depicted in Fig. 2. Because IP header information is not necessa

27、ry over broadcasting channels, it can be compressed before encapsulation, increasing the efficiency. 4 Rec. ITU-R BT.1887 FIGURE 1 Protocol stack of encapsulation of IP packet into private stream of MPEG-2 TS 1887-01Multimedia broadcastingIP packetVideo and audioIP header compressionPrivate dataSect

28、ionChannel coding and modulationPhysical layer (terrestrial/satellite)Data andcontrolPESStreamMPEG-2 TSFIGURE 2 Protocol stack of encapsulation of IP packet into section of MPEG-2 TS 1887-02Multimedia broadcastingIP packetVideo and audioIP header compressionSectionChannel coding and modulationPhysic

29、al layer (terrestrial/satellite)Data andcontrolPESStreamMPEG-2 TS2 Techniques for encapsulating IP packets into an MPEG-2 TS 2.1 Encapsulation of IP packets into a private stream of MPEG-2 TS Unidirectional Lightweight Encapsulation (ULE) specified in IETF RFC 4326 5 is an encapsulation technique fo

30、r IP packets and other network protocol packets over an MPEG-2 transport stream as private data. A transferred packet such as an IP packet is called a Protocol Data Unit (PDU). Each PDU is encapsulated into a SubNetwork Data Unit (SNDU) by adding an encapsulation header and an integrity check traile

31、r. Table 1 indicates the syntax of SNDU. An SNDU is fragmented into a series of one or more MPEG-2 TS packets. Rec. ITU-R BT.1887 5 TABLE 1 Syntax of SNDU Syntax No. of bits Mnemonic SNDU destination_address_absent_flag 1 bslbf length 15 uimsbf type 16 uimsbf if( destination_address_absent_flag=“0”)

32、 destination_address 48 uimsbf if( type=0x0800 ) IPv4_packet () else if ( type=0x86DD ) IPv6_packet () else if (type=T.B.D ) compressed_ip_packet () else if (type=T.B.D ) compressed_ip_packet_ROHC () CRC_32 32 rpchof destination_address_absent_flag This indicates the absence of a destination_address

33、 field. A value of “0” indicates the presence of the destination_address field. A value of “1” indicates that a destination_address field is not present. length This indicates the length, in bytes, of the SNDU counted from the byte following the type field to and including the CRC_32 field. type Thi

34、s indicates the type of payload carried in an SNDU, or the presence of a next-header. destination_address This identifies the receiver(s) that process(es) a received SNDU. IPv4_packet () This indicates an IPv4 packet, which has an IPv4 header defined in RFC791 9. IPv6_packet () This indicates an IPv

35、6 packet, which has an IPv6 header defined in RFC 2460 10. compressed_ip_packet () This indicates an IP packet having compressed headers presented in 3.1 of this Recommendation and 4 of Recommendation ITU-R BT.1869. compressed_ip_packet_ROHC () This indicates an IP packet having compressed headers u

36、sing Robust Header Compression (ROHC) 4 shown in 3.2 of this Recommendation. CRC_32 This field complies with ITU-T Recommendation H.222.0. The SNDU is assigned into a series of TS packet payloads. There are two assigning procedures: padding and packing. The overviews of the packing and padding proce

37、dures are shown in Figs 3 and 4, respectively. The packing procedure is optional and may be determined on a per-session or per-SNDU basis. 6 Rec. ITU-R BT.1887 In the padding procedure, after one SNDU is encapsulated into a series of MPEG-2 TS packets, another SNDU is not encapsulated immediately ev

38、en if space is available in a partially filled TS packet. This procedure trades decreased efficiency for improved latency. FIGURE 3 Encapsulation of an SNDU into MPEG-2 TS packets using padding procedure 1887-03Payload Payload PayloadTSPhdrTSPhdrTSPhdrTSPhdrPayloadTSPhdrPaddingAn SNDUMPEG-2 TS packe

39、tsPP*PP: Payload pointer * TSP : TS packet header hdrOn the other hand, in the packing procedure, when more SNDUs are waiting to be transferred, and an MPEG-2 TS packet has sufficient space remaining in the payload, a previously encapsulated SNDU is followed with another SNDU using the next availabl

40、e byte of the TS packet payload. FIGURE 4 Encapsulation of SNDUs into MPEG-2 TS packets using packing procedure 1887-04MPEG-2 TS packets*PP: Payload pointer * TSP : TS packet header hdrAn SNDUAn SNDUPayloadTSPhdrPPPayloadTSPhdrPayloadTSPhdrPP Payload PayloadTSPhdrTSPhdr2.2 Encapsulation of IP packet

41、s into a section of MPEG-2 TS The following two schemes are available for encapsulating IP packets into a section of an MPEG-2 TS. 2.2.1 Multi-Protocol Encapsulation 6; 7 An IP packet is encapsulated into a DSM-CC addressable section. The syntax of the DSM-CC addressable section for encapsulating IP

42、 packet is indicated in Table 2. The mapping of the section into MPEG-2 TS packets is defined in ITU-T Recommendation H.220.0. Rec. ITU-R BT.1887 7 TABLE 2 Syntax of DSM-CC_addressable_section Syntax No. of bits Mnemonic DSMCC_addressable_section () table_id 8 uimsbf section_syntax_indicator 1 bslbf

43、 error_detection_type 1 bslbf reserved 2 bslbf section_length 12 uimsbf deviceID7.0 8 uimsbf deviceID15.8 8 uimsbf reserved 2 bslbf payload_scrambling_control 2 bslbf address_scrambling_control 2 bslbf LLC_SNAP_flag 1 bslbf current_next_indicator 1 bslbf section_number 8 uimsbf last_section_number 8

44、 uimsbf deviceID23.16 8 uimsbf deviceID31.24 8 uimsbf deviceID39.32 8 uimsbf deviceID47.40 8 uimsbf if (LLC_SNAP_flag=“1”) LLC_SNAP() else for (j=0; jN; j+) IPv4_packet ( ) if(section_number = last_section_number) for(j=0; jN; j+) stuffing_byte 8 bslbf if (error_detection_type=“1”) checksum 32 uimsb

45、f else CRC_32 32 rpchof 8 Rec. ITU-R BT.1887 table_id This field identifies the DSM-CC section type to which the section belongs. It is set to “0x3F” in the case of a DSM-CC addressable section. section_syntax_indicator This is a 1-bit flag. When set to “1”, it indicates the presence of the CRC_32 f

46、ield. When set to “0”, it indicates the presence of the checksum field. error_detection_type This is a 1-bit flag. When set to “1”, it indicates the presence of the checksum field. When set to “0”, it indicates the presence of the CRC_32 field. reserved This 2-bit field is set to “11”. section_lengt

47、h This field specifies the number of remaining bytes of the section immediately following the section_length field up to the end of the section including the checksum field or CRC_32 field. deviceId This 48-bit field identifies the intended receiver device. The deviceId field is reconstructed from t

48、he in order concatenation of the deviceId4740, deviceId3932, deviceId3124, deviceId2316, deviceId158, and deviceId70 fields, representing bit number 47 to 40, bit number 39 to 32, bit number 31 to 24, bit number 23 to 16, bit number 15 to 8, and bit number 7 to 0, respectively. payload_scrambling_co

49、ntrol This field defines the scrambling mode of the payload. This includes the payload that starts after the deviceId4740 byte and excludes the checksum or CRC_32 field. address_scrambling_control This field defines the scrambling mode of deviceId. LLC_SNAP_flag This a 1-bit flag. If this flag is set to “1”, the payload carries an LLC/SNAP encapsulated datagram followin