1、 TIA-1077 February 2011BCMCS Codecs and Transport ProtocolsNOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assistin
2、g the purchaser in selecting and obtaining with minimum delay the proper product for their particular need. The existence of such Standards and Publications shall not in any respect preclude any member or non-member of TIA from manufacturing or selling products not conforming to such Standards and P
3、ublications. Neither shall the existence of such Standards and Publications preclude their voluntary use by Non-TIA members, either domestically or internationally. Standards and Publications are adopted by TIA in accordance with the American National Standards Institute (ANSI) patent policy. By suc
4、h action, TIA does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Standard or Publication. This Standard does not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the resp
5、onsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. (From Project No. 3-0212, formulated under the cognizance of the TIA TR-45 Mobile (b) there is no assurance that the Document will
6、 be approved by any Committee of TIA or any other body in its present or any other form; (c) the Document may be amended, modified or changed in the standards development or any editing process. The use or practice of contents of this Document may involve the use of intellectual property rights (“IP
7、R”), including pending or issued patents, or copyrights, owned by one or more parties. TIA makes no search or investigation for IPR. When IPR consisting of patents and published pending patent applications are claimed and called to TIAs attention, a statement from the holder thereof is requested, al
8、l in accordance with the Manual. TIA takes no position with reference to, and disclaims any obligation to investigate or inquire into, the scope or validity of any claims of IPR. TIA will neither be a party to discussions of any licensing terms or conditions, which are instead left to the parties in
9、volved, nor will TIA opine or judge whether proposed licensing terms or conditions are reasonable or non-discriminatory. TIA does not warrant or represent that procedures or practices suggested or provided in the Manual have been complied with as respects the Document or its contents. If the Documen
10、t contains one or more Normative References to a document published by another organization (“other SSO”) engaged in the formulation, development or publication of standards (whether designated as a standard, specification, recommendation or otherwise), whether such reference consists of mandatory,
11、alternate or optional elements (as defined in the TIA Engineering Manual, 4thedition) then (i) TIA disclaims any duty or obligation to search or investigate the records of any other SSO for IPR or letters of assurance relating to any such Normative Reference; (ii) TIAs policy of encouragement of vol
12、untary disclosure (see Engineering Manual Section 6.5.1) of Essential Patent(s) and published pending patent applications shall apply; and (iii) Information as to claims of IPR in the records or publications of the other SSO shall not constitute identification to TIA of a claim of Essential Patent(s
13、) or published pending patent applications. TIA does not enforce or monitor compliance with the contents of the Document. TIA does not certify, inspect, test or otherwise investigate products, designs or services or any claims of compliance with the contents of the Document. ALL WARRANTIES, EXPRESS
14、OR IMPLIED, ARE DISCLAIMED, INCLUDING WITHOUT LIMITATION, ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE CONTENTS, ITS FITNESS OR APPROPRIATENESS FOR A PARTICULAR PURPOSE OR USE, ITS MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS. TIA EXPRESSLY DISCLA
15、IMS ANY AND ALL RESPONSIBILITIES FOR THE ACCURACY OF THE CONTENTS AND MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE CONTENTS COMPLIANCE WITH ANY APPLICABLE STATUTE, RULE OR REGULATION, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT OR SERVICE REFERRED TO IN THE DOCUMENT OR PRO
16、DUCED OR RENDERED TO COMPLY WITH THE CONTENTS. TIA SHALL NOT BE LIABLE FOR ANY AND ALL DAMAGES, DIRECT OR INDIRECT, ARISING FROM OR RELATING TO ANY USE OF THE CONTENTS CONTAINED HEREIN, INCLUDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING DAMAGES
17、 FOR LOSS OF BUSINESS, LOSS OF PROFITS, LITIGATION, OR THE LIKE), WHETHER BASED UPON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES IS A FUNDAMENTAL ELEMENT OF
18、THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. 3GPP2 C.S0070-0 v1.0 Revision History Revision Description of Changes Date Rev 0 v1.0 Initial publication January 2011 3GPP2 C.S0070-0 v1.0 Table of Contents i 1. Introduction. 1 1 1.1 Scope. 1
19、 2 1.2 Document Convention 1 3 2. References 1 4 2.1 Normative References. 1 5 2.2 Informative References. 4 6 3. Definitions, Symbols and Abbreviations. 4 7 3.1 Definitions. 4 8 3.2 Symbols and Abbreviations 4 9 4. BCMCS Media Types (CODECS). 5 10 4.1 General requirements 5 11 4.2 Speech. 5 12 4.3
20、Video. 5 13 4.4 Audio. 6 14 4.5 Text . 6 15 4.6 Timed Text 7 16 4.7 Synthetic Audio 7 17 4.8 Still Image. 7 18 4.9 Bitmap Graphics . 7 19 4.10 Vector Graphics 7 20 4.11 3GPP2 File Formats. 7 21 5. BCMCS Transport Protocols 8 22 5.1 Protocol Reference Model 8 23 5.2 Overview. 8 24 5.2.1. BCMCS Downlo
21、ad Delivery Method. 8 25 5.2.2. BCMCS Streaming Delivery Method. 9 26 6. Service and Session Description 9 27 6.1 XML Schema 10 28 7. Download Delivery 10 29 7.1 Base protocol ALC, FLUTE 10 30 3GPP2 C.S0070-0 v1.0 Table of Contents ii 7.1.1. Content Encoding 10 1 7.1.2. File Descriptions . 11 2 7.1.
22、3. File Versioning 11 3 7.1.4. Indication of End of File and End of Session . 11 4 7.1.4.1. Determining End of File Delivery 11 5 7.1.4.2. Signaling End of File Delivery Session 12 6 7.1.5. Signaling of Parameters 12 7 7.1.5.1. Signaling of Parameters with Basic ALC/FLUTE Headers . 12 8 7.1.5.2. Sig
23、naling of Parameters with LCT Extension Header 12 9 7.1.5.3. Signaling of Parameters with FLUTE Extension Headers . 13 10 7.1.5.4. Signaling of Parameters with FDT Instances 13 11 7.1.6. FLUTE FDT Instance XML Schema 14 12 7.1.6.1. XML Schema (Normative) . 14 13 7.1.6.2. XML Instance Example (Inform
24、ative) 14 14 7.2 FEC . 14 15 8. Streaming delivery 15 16 8.1 Transport Protocol 15 17 8.1.1. Speech. 16 18 8.1.2. Video. 16 19 8.1.3. Audio. 16 20 8.1.4. Timed Text 16 21 8.1.5. Synthetic Audio 16 22 Annex A FLUTE FDT XML Schema (normative) 17 23 3GPP2 C.S0070-0 v1.0 iii Figures 1 Figure 1 BCMCS Pro
25、tocol Stack in the MS and the BCMCS Content Server 8 2 Figure 2 Building Block Structure of File Delivery in BCMCS 9 3 3GPP2 C.S0070-0 v1.0 iv Foreward 1 (This foreword is not part of this specification.) 2 This technical specification recommends codecs as well as protocols for Broadcast Multicast 3
26、 Services (BCMCS). 4 3GPP2 C.S0070-0 v1.0 1 1. Introduction 1 1.1 Scope 2 This specification recommends media types and protocols to support delivery of broadcast 3 multicast services. 4 1.2 Document Convention 5 “Shall” and “shall not” identify requirements to be followed strictly to conform to thi
27、s document 6 and from which no deviation is permitted. “Should” and “should not” indicate that one of several 7 possibilities is recommended as particularly suitable, without mentioning or excluding others, 8 that a certain course of action is preferred but not necessarily required, or that (in the
28、negative 9 form) a certain possibility or course of action is discouraged but not prohibited. “May” and “need 10 not” indicate a course of action permissible within the limits of the document. “Can” and 11 “cannot” are used for statements of possibility and capability, whether material, physical or
29、12 causal. 13 2. References 14 The following standards are referenced in this text. At the time of publication, the editions 15 indicated were valid. All standards are subject to revision, and parties to agreements based upon 16 this document are encouraged to investigate the possibility of applying
30、 the most recent editions 17 of the standards indicated below. ANSI and TIA maintain registers of currently valid national 18 standards published by them. 19 2.1 Normative References 20 1 3GPP2: C.S0014-D “Enhanced Variable Rate Codec, Speech Service Options 3, 68, 70, 21 and 73 for Wideband Spread
31、Spectrum Digital Systems“, January 2010. 22 2 ITU-T: Recommendation H.264 “Advanced video coding for generic audiovisual 23 services“, March 2005. also available as ISO/IEC 14496-10: “Information technology - 24 Coding of audio-visual objects - Part 10: Advanced Video Coding“, 2009. 25 3 ITU-T: Reco
32、mmendation H.263: Video coding for low bit rate communications, January 26 2005. 27 4 ITU-T: Recommendation H.263 Annex X: Profiles and Levels Definition, April 2001. 28 5 IETF: RFC 3984, S. Wenger et al., “RTP Payload Format for H.264 Video”, Feb 2005. 29 6 3GPP TS 26.401: “General audio codec audi
33、o processing functions; Enhanced aacPlus 30 general audio codec; General description“. 31 7 W3C: “ XHTML 1.0 The Extensible HyperText Markup Language (Second Edition) “, 32 August 2002, http:/www.w3.org/TR/2002/REC-xhtml1-20020801/ 33 3GPP2 C.S0070-0 v1.0 2 8 The Unicode Consortium: “The Unicode Sta
34、ndard“, Version 3.0 Reading, MA, Addison-1 Wesley Developers Press, 2000, ISBN 0-201-61633-5. 2 9 ISO/IEC: 10646:2003 “Information technology - Universal Multiple-Octet Coded 3 Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane“, 2003. 4 10 3GPP: TS 26.245: “Transparent end-to-e
35、nd Packet switched Streaming Service (PSS); 5 Timed text format“. 6 11 3GPP2: C.S0050-B: 3GPP2 File formats for multimedia services, June 2007. 7 12 MIDI Manufacturers Association: “Scalable Polyphony MIDI Specification”, Version 8 1.0, RP-34, Los Angeles, CA, February 2002. 9 13 MIDI Manufacturers
36、Association: “Scalable Polyphony MIDI Device 5-to-24 Note 10 Profile for 3GPP”, Version 1.0, RP-35, Los Angeles, CA, February 2002. 11 14 MIDI Manufacturers Association: “Standard MIDI Files 1.0“, RP-001, in “The Complete 12 MIDI 1.0 Detailed Specification, Document Version 96.1“, Los Angeles, CA, U
37、SA, 13 February 1996. 14 15 MIDI Manufacturers Association: Mobile DLS, MMA specification v1.0, RP-41 Los 15 Angeles, CA, USA. 2004. 16 16 MIDI Manufacturers Association: Mobile XMF Content Format Specification, MMA 17 specification v1.0, RP-42, Los Angeles, CA, USA. 2004. 18 17 ITU-T: Recommendatio
38、n T.81 (1992) | ISO/IEC 10918-1:1993: “Information technology 19 - Digital compression and coding of continuous-tone still images - Requirements and 20 guidelines“. 21 18 Eric Hamilton, C-Cube Microsystems: “JPEG File Interchange Format“, Version 1.02, 22 September 1992. Available at: http:/www.jpeg
39、.org/public/jfif.pdf 23 19 CompuServe: “GIF Graphics Interchange Format: A Standard defining a mechanism for 24 the storage and transmission of raster-based graphics information“, CompuServe 25 Incorporated, Columbus, OH, USA, 1987. See at 26 http:/www.dcs.ed.ac.uk/home/mxr/gfx/2d/GIF87a.txt. 27 20
40、CompuServe: “Graphics Interchange Format: Version 89a“, CompuServe Incorporated 28 Columbus, OH, USA, 1990. 29 21 IETF: RFC 2083, T. Boutell, “PNG (Portable Networks Graphics) Specification Version 30 1.0“, March 1997. 31 22 W3C: April 2005: “Scalable Vector Graphics (SVG) Full 1.2 Specification“, 3
41、2 http:/www.w3.org/TR/SVG12/. 33 23 W3C: December 2009: “Scalable Vector Graphics (SVG) Tiny 1.2 Specification“, 34 http:/www.w3.org/TR/SVGTiny12/. 35 24 ECMA: Standard ECMA-327 (June 2001): “ECMAScript 3rdEdition Compact Profile“. 36 25 IETF: RFC 1952, P. Deutsch, “GZIP file format specification ve
42、rsion 4.3“,.May 1996 37 3GPP2 C.S0070-0 v1.0 3 26 3GPP2: X.S0022-A, “Broadcast and Multicast Service in cdma2000 Wireless IP 1 Network, February 2007. 2 27 IETF: RFC 5775, M. Luby et al., “Asynchronous Layered Coding (ALC) Protocol 3 Instantiation”, April 2010. 4 28 IETF: RFC 3926, T. Paila et al.,
43、“FLUTE - File Delivery over Unidirectional Transport”, 5 October 2004. 6 29 IETF: RFC 5052, M. Watson et al., “Forward Error Correction (FEC) Building Block”, 7 August 2007. 8 30 IETF: RFC 5651, M. Luby et al., “Layered Coding Transport (LCT) Building Block”, 9 October 2009. 10 31 IETF: I-D, M. Luby
44、 et al., “RaptorQ Forward Error Correction Scheme for Object 11 Delivery”, draft-ietf-rmt-bb-fec-raptorq, August 2010. 12 Editor Note: The above document is a work in progress and should not be referenced unless and 13 until it is approved and published. Until such time as this Editors Note is remov
45、ed, the inclusion 14 of the above document is for informational purposes only. 15 32 IETF: RFC 5445, M. Watson, “Basic Forward Error Correction (FEC) Schemes“, March 16 2009. 17 33 IETF: RFC 4566, M. Handley et al., “SDP: Session Description Protocol”, July 2006. 18 34 OMA BCAST: “File and Stream Di
46、stribution for Mobile Broadcast Services”, version 19 1.0, February 2009. 20 35 OMA BCAST: “Service Guide for Mobile Broadcast Services“, version 1.0, February 21 2009. 22 36 OMA BCAST: “Broadcast Distribution System Adaptation 3GPP2/BCMCS“, version 23 1.0, February 2009. 24 37 IETF: RFC 3550, H. Sc
47、hulzrinne et al., “RTP: A Transport Protocol for Real-Time 25 Applications”, July 2003. 26 38 IETF: RFC 5188, H. Desineni and Q. Xie, “RTP Payload format for Enhanced variable 27 Rate wideband codec EVRC-WB and media subtype updates for EVRC-B Codec”, Feb 28 2008. 29 39 IETF: Z. Fang, “RTP payload f
48、ormat for Enhanced Variable Rate Narrowband-Wideband 30 Codec”. draft-zfang-avt-rtp-evrc-nw-02, November 2010. 31 Editor Note: The above document is a work in progress and should not be referenced unless and 32 until it is approved and published. Until such time as this Editors Note is removed, the
49、inclusion 33 of the above document is for informational purposes only. 34 40 IETF: RFC 4629, J. Ott et al., “RTP Payload format for ITU-T Rec. H.263“. January 35 2007. 36 41 IETF: RFC 3640, F. de Bont et al., “RTP Payload format for transport of MPEG-4 37 Elementary Streams“, November 2003. 38 3GPP2 C.S0070-0 v1.0 4 42 IETF: RFC 4396, J. Rey and Y. Matsui, “RTP payload format for 3GPP2 Timed Text“, 1 February 2006. 2 43 IETF: RFC 4695, J. Lazzaro and J. Wawrzynek, “RTP Payload format for
