I



1
    3GPP2 C.S0046-0


    Version 1.0
    Date: February 21, 2006




2                     3G Multimedia Streaming...
C.S0046-0 v1.0



1                                         PREFACE
2   This document defines content types, media formats...
C.S0046-0 v1.0




 1   1 Contents

 2   1      Contents ....................................................................
C.S0046-0 v1.0


 1   10        Pseudo Streaming.............................................................................
C.S0046-0 v1.0




 1   2 List of Figures
 2   Figure 7-1 Multimedia Streaming Service ......................................
C.S0046-0 v1.0




1   3 List of Tables
2   Table 8-1 Summary of non-UAProf defined Attributes for MSS CE ...................
C.P0046-0 v1.0



1   4 Scope
2   The objective is to define and standardize the functionality of Multimedia Streaming
3  ...
C.P0046-0 v1.0



 1   5 References
 2

 3   5.1 Normative References

 4   This section provides references to other spec...
C.P0046-0 v1.0


 1   18.    IETF RFC 3558: "RTP Payload and Format for Enhanced Variable Rate Codecs
 2          (EVRC) a...
C.P0046-0 v1.0


 1   38.    3GPP TS 26.234: "Transparent End-to-End Packet Switched Streaming Service
 2          (PSS) P...
C.P0046-0 v1.0


1


2   5.2 Informative References

3   This section provides references to other documents that may be u...
C.P0046-0 v1.0




 1   6 Definitions and Abbreviations

 2

 3   6.1 Definitions

 4   For the purposes of the present do...
C.P0046-0 v1.0




1   6.2 Abbreviations

2   For the purpose of this document, the following abbreviations apply:

    3G...
C.P0046-0 v1.0



    MPEG                    Motion Picture Expert Group
    MS                      Mobile Station (same...
C.P0046-0 v1.0



 1   7 Multimedia Streaming Services Structure
 2   This service is defined as a point-to-point service....
C.P0046-0 v1.0


1



                                Multimedia Streaming Service Terminal Functions


           Visual ...
C.P0046-0 v1.0




 1   8 Call procedures for Multimedia Streaming

 2   Streaming of continuous media using RTP/UDP/IP (s...
C.P0046-0 v1.0


 1   Mobile-Type =             "MNT" "=" 1*CHAR
 2   Guaranteed-BW =           "GBW" "=" 1*DIGIT       ; ...
C.P0046-0 v1.0


 1   Example 2:
 2   Mobile-Link-Char: url=" rtsp://server.foo.com/presentation.3g2"; MNT=3GPP2-HRPD-
 3 ...
C.P0046-0 v1.0


 1   in the methods SETUP, PLAY, OPTIONS, and SET_PARAMETER.
 2   The entry of the "avcrtpinterleaving" f...
C.P0046-0 v1.0


 1   for MSS:

 2   •   "a=X-predecbufsize:<size of the hypothetical pre-decoder buffer>"
 3       This g...
C.P0046-0 v1.0


 1   attributes as described in [38]. The "alt" attribute is used to replace or add an SDP line
 2   to t...
C.P0046-0 v1.0


 1   enabling the MSS servers to provide tailored content suitable for a particular MSS
 2   terminal. An...
C.P0046-0 v1.0



       PssVersion or                     "3GPP2-MSS-0"               "3GPP-R4","3GPP-R5","3GPP-
        ...
C.P0046-0 v1.0



     VideoPreDecoderBufferSize                                    Integer value equal to or
            ...
C.P0046-0 v1.0



         CcppAccept-Language                                        List of preferred document
         ...
C.P0046-0 v1.0


 1   8.5 Data Channel Setup

 2   The IP bearer for carrying the multimedia streaming traffic shall be se...
C.P0046-0 v1.0


1                    Figure 8-1 Data Channel Set-up (SO 33/66, 60 and 61)

2   8.6 Session Termination
3 ...
C.P0046-0 v1.0



 1   9 Transport Protocol
 2   The MSS client shall support packetization and transport via both RTP [11...
C.P0046-0 v1.0


 1   For the EVRC speech coder, the payload format shall be as defined in "RTP Payload and
 2   Format fo...
C.P0046-0 v1.0


 1       NADU APP packet shall not contain any other data format than the one described in
 2       Figur...
C.P0046-0 v1.0


 1       4194304 with a field value 0xffff.
 2       • Reserved (11 bits): These bits are not used and sh...
C.P0046-0 v1.0



    URI                           M     URI to the 3GPP2 CMF file.
                                     ...
C.P0046-0 v1.0




 1   10 Pseudo Streaming

 2   Transfer of dynamic media content (Video, Speech, Audio, Timed Text) to ...
C.P0046-0 v1.0


 1          message-header
 2          CRLF
 3          CRLF
 4
                Item              M/O    ...
C.P0046-0 v1.0



                     Item               M/O                         Value
    Status Code               ...
C.P0046-0 v1.0



1
2   Pseudo Streaming Session Representation Example (Informative).


3   10.3 FFMS Usage in MSS

4   T...
C.P0046-0 v1.0




 1   11 Media Types (Codecs)

 2

 3   11.1 General Requirements
 4   Support for all media types is no...
C.P0046-0 v1.0


 1   11.3.1 "Narrow Band Speech"

 2   The MSS terminal shall support at least one of the following media...
C.P0046-0 v1.0


1   11.6 "Timed Text"

2   The MSS terminal should support the media type "Timed Text". If timed text is
...
C.P0046-0 v1.0




 1   12 Rate Adaptation of Streaming Media

 2


 3   12.1 Introduction

 4   The goal of multimedia st...
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
3G Multimedia Streaming Services
Upcoming SlideShare
Loading in...5
×

3G Multimedia Streaming Services

2,963

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,963
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
39
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "3G Multimedia Streaming Services"

  1. 1. I 1 3GPP2 C.S0046-0 Version 1.0 Date: February 21, 2006 2 3G Multimedia Streaming Services 3 4 COPYRIGHT 3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at secretariat@3gpp2.org. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information. 5 6
  2. 2. C.S0046-0 v1.0 1 PREFACE 2 This document defines content types, media formats, codecs, and delivery support for 3 Multimedia Streaming Service (MSS). 4 3G Multimedia Streaming Services 2
  3. 3. C.S0046-0 v1.0 1 1 Contents 2 1 Contents ............................................................................................................................................3 3 2 List of Figures ...................................................................................................................................5 4 3 List of Tables ....................................................................................................................................6 5 4 Scope.................................................................................................................................................7 6 5 References.........................................................................................................................................8 7 5.1 Normative References ........................................................................................................8 8 5.2 Informative References.....................................................................................................11 9 6 Definitions and Abbreviations ........................................................................................................12 10 6.1 Definitions ........................................................................................................................12 11 6.2 Abbreviations....................................................................................................................13 12 7 Multimedia Streaming Services Structure.......................................................................................15 13 8 Call procedures for Multimedia Streaming.....................................................................................17 14 8.1 Control Protocol (RTSP) ..................................................................................................17 15 8.1.1 Mobile Link-Char Header 17 16 8.1.2 The 3GPP-Adaptation Header 19 17 8.1.3 The "Avc-rtpinterleaving" Header 19 18 8.2 Session Set-up (SDP)........................................................................................................20 19 8.2.1 Session Capability Exchange (SDP) 20 20 8.2.2 Session Video Buffering (SDP) 20 21 8.2.3 Additional Attributes (SDP) 21 22 8.2.4 Session 3GPP-Adaptation-Support (SDP) 22 23 8.2.5 Session HE AAC Support (SDP) 22 24 8.3 Capability Exchange (CE) ................................................................................................22 25 8.3.1 Overview 22 26 8.3.2 Description 23 27 8.4 Presentation/Layout Description ......................................................................................26 28 8.4.1 SMIL Usage in MSS 26 29 8.5 Data Channel Setup ..........................................................................................................27 30 8.5.1 Header Compression 27 31 8.6 Session Termination .........................................................................................................28 32 9 Transport Protocol ..........................................................................................................................29 33 9.1 RTP/UDP..........................................................................................................................29 34 9.1.1 RTCP extension (NADU APP packet) 30 35 9.2 HTTP/TCP and Container Formats ..................................................................................32 36 9.2.1 Transport of CMF Over HTTP 32 3G Multimedia Streaming Services 3
  4. 4. C.S0046-0 v1.0 1 10 Pseudo Streaming............................................................................................................................34 2 10.1 Session Description ..........................................................................................................34 3 10.2 Transport Options .............................................................................................................34 4 10.2.1 Request 34 5 10.2.2 Response 35 6 10.3 FFMS Usage in MSS ........................................................................................................37 7 11 Media Types (Codecs) ....................................................................................................................38 8 11.1 General Requirements ......................................................................................................38 9 11.2 "Video" .............................................................................................................................38 10 11.3 "Speech" ...........................................................................................................................38 11 11.3.1 "Narrow Band Speech" 39 12 11.3.2 "Wide Band Speech" 39 13 11.4 "Audio".............................................................................................................................39 14 11.5 "Text in SMIL" .................................................................................................................39 15 11.6 "Timed Text" ....................................................................................................................40 16 11.7 Other media ......................................................................................................................40 17 12 Rate Adaptation of Streaming Media..............................................................................................41 18 12.1 Introduction ......................................................................................................................41 19 12.2 Rate Adaptation ................................................................................................................41 20 12.2.1 Link Characteristics 41 21 12.2.2 Adaptation of Transmission Rate 42 22 12.2.3 Receiver Buffer Level Feedback 42 23 Annex A Call Flow Example (Informative).....................................................................................44 24 Annex B Sample Scenario of a Session (Informative).....................................................................46 25 Annex C Buffering of Video (Normative).......................................................................................49 26 C.1 Introduction ......................................................................................................................49 27 C.2 MSS client buffering requirements...................................................................................52 28 Annex D Pseudo Streaming Session Representation Example (Informative)..................................53 29 D.1 XHTML Presentation Description Format .......................................................................53 30 D.2 <object> Element..............................................................................................................54 31 Annex E Pseudo Streaming Example (Informative) ........................................................................57 32 E.1 Live encoding ...................................................................................................................57 33 E.2 Random positioning..........................................................................................................58 34 E.3 Choosing bitrate................................................................................................................58 35 36 3G Multimedia Streaming Services 4
  5. 5. C.S0046-0 v1.0 1 2 List of Figures 2 Figure 7-1 Multimedia Streaming Service ....................................................................................................15 3 Figure 7-2 Multimedia Streaming Services Terminal Function ....................................................................16 4 Figure 8-1 Data Channel Set-up (SO 33/66, 60 and 61) ...............................................................................28 5 Figure 9-1 Protocol Stack for Multimedia Streaming Service ......................................................................29 6 Figure 9-2: Generic Format of an RTCP APP packet. ..................................................................................30 7 Figure 9-3: Data format block for NADU reporting .....................................................................................31 8 Figure 10-1 Basic Sequence of Pseudo-streaming ........................................................................................34 9 Figure E-1 Block diagram for live pseudo-streaming ...................................................................................57 10 Figure E-2 moof -> moov conversion in the server ......................................................................................57 11 Figure E-3 HTTP request for the random positioning ..................................................................................58 12 Figure E-4 Movie file reconstruction for random positioning service ..........................................................58 13 Figure E-5 Protocol enhancement for choosing bitrate.................................................................................59 14 Figure E-6 Generation of movie file for pseudo-streaming from multirate movie file .................................59 15 16 3G Multimedia Streaming Services 5
  6. 6. C.S0046-0 v1.0 1 3 List of Tables 2 Table 8-1 Summary of non-UAProf defined Attributes for MSS CE ...........................................................25 3 Table 8-2 Summary of UAProf (HardwarePlatform) defined Attributes for MSS CE .................................25 4 Table 8-3 Summary of UAProf (SoftwarePlatform) defined Attributes for MSS CE ..................................26 5 Table 9-1 CMF parameters for HTTP GET ..................................................................................................33 6 Table 10-1 Pseudo-streaming HTTP GET request parameters .....................................................................35 7 Table 10-2 Pseudo-streaming HTTP response options .................................................................................36 8 Table 10-3 Example of pseudo-streaming message header range parameters ..............................................36 9 3G Multimedia Streaming Services 6
  7. 7. C.P0046-0 v1.0 1 4 Scope 2 The objective is to define and standardize the functionality of Multimedia Streaming 3 Services (MSS) that can be incorporated into the operations of wireless 4 telecommunications networks. Audio-only streaming and video-only streaming are 5 special cases of MSS. This document defines the functional characteristics and 6 requirements of the MSS. Features and system requirements are defined in order for 7 MSS to be provided in wireless telecommunications networks. This document addresses 8 unicast services. 9 3G Multimedia Streaming Services 7
  8. 8. C.P0046-0 v1.0 1 5 References 2 3 5.1 Normative References 4 This section provides references to other specifications and standards that are 5 necessary to implement this document. 6 1. 3GPP2 S.R0021: "Multimedia Streaming Services – Stage 1". 7 2. 3GPP2 C.S0017-12: "Data Service Options for Spread Spectrum Systems: 8 cdma2000 High Speed Packet Data Service Option 33/66". 9 3. 3GPP2 C.S0017-10: "Data Service Options for Spread Spectrum Systems: Radio 10 Link Protocol Type 3". 11 4. 3GPP2 C.S0047: "Link-Layer Assisted Service Options for Voice-over-IP: Header 12 Removal (SO60) and Robust Header Compression (SO61)". 13 5. 3GPP2 C.S0014: "Enhanced Variable Rate Codec, Speech Service Option 3 for 14 Wideband Spread Spectrum Digital Systems". 15 6. 3GPP2 C.S0020: "High Rate Speech Service Option for Wide Band Spread 16 Spectrum Communication Systems". 17 7. 3GPP2 C.S0050: "File Format(s) for Multimedia Services". 18 8. 3GPP2 C.S0052: "Source-Controlled Variable-Rate Multimode Wideband Speech 19 Codec (VMR-WB) Service Option 62 for Spread Spectrum Systems". 20 9. ITU-T Recommendation H.263: "Video Coding for Low Bitrate Communication". 21 10. ISO/IEC 14496-2:2004: "Information Technology — Generic Coding of Audio- 22 Visual Object — Part 2: Visual". 23 11. IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Applications". 24 12. IETF RFC 768: ""User Datagram Protocol" 25 13. IETF RFC 791: "Internet Protocol DARPA Internet Program Protocol 26 Specification." 27 14. IETF RFC 3551: "RTP Profile for Audio and Video Conferences with Minimal 28 Control". 29 15. IETF RFC 3016: "RTP Payload Format for MPEG-4 Audio/Visual Streams". 30 16. IETF RFC 2429: "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 31 (H.263+)". 32 17. IETF RFC 2658: "RTP Payload Format for PureVoice(tm) Audio". 3G Multimedia Streaming Services 8
  9. 9. C.P0046-0 v1.0 1 18. IETF RFC 3558: "RTP Payload and Format for Enhanced Variable Rate Codecs 2 (EVRC) and Selectable Multimode Vocoders (SMV)". 3 19. IETF RFC 3984: "RTP Payload Format for H.264 Video". 4 20. IETF RFC 4348: "RTP Payload formats for Variable-Rate Multimode Wideband 5 (VMR-WB) Audio codec". 6 21. IETF RFC 2326: "Real-Time Streaming Protocol". 7 22. IETF RFC 2327: "Session Description Protocol". 8 23. IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 9 24. IETF STD 0007: "Transmission Control Protocol". 10 25. CompuServe Incorporated: "GIF Graphics Interchange Format: A Standard 11 defining a mechanism for the storage and transmission of raster-based graphics 12 information", Columbus, OH, USA, 1987. 13 26. CompuServe Incorporated: "Graphics Interchange Format: Version 89a", 14 Columbus, OH, USA, 1990. 15 27. ITU-T Recommendation T.81 (1991) | ISO/IEC 10918-1 (1992): "Information 16 technology - Digital compression and coding of continuous-tone still images - 17 Requirements and guidelines. 18 28. W3C Recommendation: "Synchronised Multimedia Integration Language 19 (SMIL 2.0) Specification", http://www.w3.org/TR/2005/REC-SMIL2-20050107/ 20 29. ISO/IEC 10646-1 (2000): "Information technology - Universal Multiple-Octet 21 Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane". 22 30. IETF RFC 2083: "PNG (Portable Networks Graphics) Specification version 1.0 ". 23 31. The Unicode Consortium: "The Unicode Standard", Version 3.0 Reading, MA, 24 Addison-Wesley Developers Press, 2000, ISBN 0-201-61633-5. 25 32. ANSI X3.4, 1986: "Information Systems; Coded Character Set 7 Bit; American 26 National Standard Code for Information Interchange". 27 33. ISO/IEC 8859-1:1998: "Information technology; 8-bit single-byte coded graphic 28 character sets; Part 1: Latin alphabet No. 1". 29 34. IETF; RFC 2279: "UTF-8, A Transformation format of ISO 10646", URL. 30 35. 3GPP TS 23.038: "Alphabets and language-specific information". 31 36. W3C Working Draft Recommendation: "Scalable Vector Graphics (SVG) 1.1 32 Specification", http://www.w3.org/TR/SVG11, February 2002. 33 37. W3C Recommendation: "Mobile SVG Profiles: SVG Tiny and SVG Basic", 34 http://www.w3.org/TR/SVGMobile/. 3G Multimedia Streaming Services 9
  10. 10. C.P0046-0 v1.0 1 38. 3GPP TS 26.234: "Transparent End-to-End Packet Switched Streaming Service 2 (PSS) Protocols and Codecs". 3 39. Polyphony MIDI Specification Version 1.0, RP-34, MIDI Manufacturers 4 Association, Los Angeles, CA, February 2002. 5 40. Scalable Polyphony MIDI Device 5-to-24 Note Profile for 3GPP Version 1.0, RP- 6 35, MIDI Manufacturers Association, Los Angeles, CA, February 2002. 7 41. "Standard MIDI Files 1.0", RP-001, in "The Complete MIDI 1.0 Detailed 8 Specification, Document Version 96.1" The MIDI Manufacturers Association, Los 9 Angeles, CA, USA, February 1996. 10 42. 3GPP2 C.S0045: "Multimedia Messaging Service (MMS): Codecs and File 11 Formats". 12 43. W3C Recommendation: "CC/PP structure and vocabularies", 13 http://www.w3.org/TR/CCPP-struct-vocab/. 14 44. W3C Recommendation: "Resource Description Framework (RDF) Vocabulary 15 Description Language 1.0: RDF Schema", http://www.w3.org/TR/rdf-schema. 16 45. ITU-T Recommendation H.264 (2003): "Advanced video coding for generic 17 audiovisual services" | ISO/IEC 14496-10:2003: "Information technology – 18 Coding of audio-visual objects – Part 10: Advanced Video Coding". 19 46. ITU-T Recommendation, J.127: "Recommendation: Transmission protocol for 20 multimedia Webcasting over TCP/IP networks" 21 47. ISO/IEC 14496-3:2001, Information technology - Coding of audio-visual objects 22 - Part 3: Audio. 23 48. ISO/IEC 14496-3:2001/Amd.1:2003, Bandwidth Extension. 24 49. ISO/IEC 14496-3:2001/Amd.1:2003/COR1:2004. 25 50. 3GPP2 C.S0047: "Link Layer Assisted Service Option for VoIP: Header removal 26 (SO 60) and Robust Header Compression (SO 61). 27 51. 3GPP2 C.S0024: "cdma2000 High Rate Packet Data Specification". 28 52. 3GPP TS 26.245 "3GPP Timed Text". 29 53. IETF RFC 2234: "Augmented BNF for Syntax Specifications: ABNF". 30 54. IETF RFC 2396: "Uniform Resource Identifiers (URI): Generic Syntax". 31 55. IETF RFC 2732: "Format for Literal IPv6 Addresses in URL's". 32 56. 3GPP2 C.R1001: "Administration of Parameter Value Assignments for cdma2000 33 Spread Spectrum Standards". 34 57. IETF RFC 3625: "The QCP File Format and Media type for speech data". 35 58. IETF RFC 3555: "MIME Type Registration of RTP Payload Formats". 36 59. W3C Recommendation: "XHTML 1.0: The extensible HyperText Markup 37 Language (Second Edition)", http://www.w3.org/TR/xhtml1. 3G Multimedia Streaming Services 10
  11. 11. C.P0046-0 v1.0 1 2 5.2 Informative References 3 This section provides references to other documents that may be useful for the reader 4 of this document. The following exemplifies two ways to reference TIA [1], 3GPP2 [OSA 5 API] or any other SDO’s documents. Please be consistent in referencing the documents 6 by either using acronyms or numbers. 7 3G Multimedia Streaming Services 11
  12. 12. C.P0046-0 v1.0 1 6 Definitions and Abbreviations 2 3 6.1 Definitions 4 For the purposes of the present document, the following terms and definitions apply. 5 codec: a system component that encodes and decodes data (usually audio, video, 6 etc.) from one representation to another, often with the goal of saving memory space 7 or transmission bandwidth (compression). 8 continuous media: media with an inherent notion of time. In the present document 9 speech, audio, synthetic audio, and video are examples of continuous media. 10 dynamic media: same as continuous media 11 discrete media: media that itself does not contain an element of time. In the 12 present document text and still image are examples of discrete media. Note that 13 timed text and bit map graphics can be continuous media also, depending on the 14 presentation aspects. 15 file format: an unambiguous method for storing data on a memory device (usually 16 non-volatile). 17 live content: content that is encoded in real-time and formatted for immediate 18 distribution. 19 media synchronization and media presentation: description of the spatial layout 20 and temporal behavior of a presentation; it can also contain hyperlinks. 21 multimedia: a combination of multiple media elements used in a service to enrich 22 the user experience. 23 natural media: media that occur naturally. In the present document, speech, 24 audio, video and still image are examples of natural media. 25 pre-encoded content: content that is encoded and then stored in a static file. 26 pseudo streaming: a stream of content distributed by progressive download via a 27 reliable delivery protocol (e.g. http) meant for real-time consumption. 28 synthetic media: media that are synthesized from algorithms and/or semantic 29 descriptions. In the present document, bit map graphics, vector graphics and 30 synthetic audio are examples of synthetic media. 31 Real-time streaming: a stream of content meant for real-time consumption. 32 user agent: the module on the terminal that performs MMS specific operations on a 33 user’s behalf. 34 3G Multimedia Streaming Services 12
  13. 13. C.P0046-0 v1.0 1 6.2 Abbreviations 2 For the purpose of this document, the following abbreviations apply: 3G Third Generation system 3G2 3GPP2 File Format for Multimedia Services 3GPP2 Third Generation Partnership Project 2 3GPP Third Generation Partnership Project AAC Advanced Audio Coding ABNF Augmented Backus-Naur Form AMR Adaptive Multi-Rate AMR-WB Adaptive Multi-Rate – Wideband AVC Advanced Video Coding CC/PP Composite Capabilities/Preferences Profile CE Capability Exchange CGI Common Gateway Interface CMF Compact Multimedia Format DO Data Only DV Data and Voice EVRC Enhanced Variable Rate Codec FFMS File Formats for Multimedia Services GIF Graphics Interchange Format HE AAC High Efficiency Advanced Audio Coding HRPD High Rate Packet Data HTTP Hyper Text Transport Protocol IEC International Electrotechnical Commission IETF Internet Engineering Task Force IP Internet Protocol ISO International Standards Organization ITU-T International Telecommunication Union - Telecommunication Sector LLAROHC Link Layer Assisted Robust Header Compression JPEG Joint Photographic Expert Group MIDI Musical Instrument Digital Interface MIME Multipurpose Internet Mail Extensions MMS Multimedia Messaging Service 3G Multimedia Streaming Services 13
  14. 14. C.P0046-0 v1.0 MPEG Motion Picture Expert Group MS Mobile Station (same as MSS terminal, MSS client) MSS Multimedia Streaming Service NADU Next Application Data Unit PSS Packet Switched Streaming QoS Quality of Service RDF Resource Description Framework RFC Request for Comments RLP Radio Link Protocol ROHC Robust Header Compression RTCP Real-time Transport Control Protocol RTP Real-time Transport Protocol RTSP Real-Time Streaming Protocol SBR Spectral Bandwidth Replication SDP Session Description Protocol SMIL Synchronized Media Integration Language SP-MIDI Scalable Polyphonic MIDI SO Service Option SVG Scalable Vector Graphics TCP Transport Control Protocol TIA Telecommunications Industry Association UDP User Datagram Protocol URI Uniform Resource Identifier URL Uniform Resource Calculator VOD Video On Demand VMR-WB Variable Rate Multimode Wide Band XML Extensible Markup Language XHTML Extensible Hypertext Markup Language 1 2 3G Multimedia Streaming Services 14
  15. 15. C.P0046-0 v1.0 1 7 Multimedia Streaming Services Structure 2 This service is defined as a point-to-point service. The streaming service is asymmetric 3 between the sender and the receiver, since the multimedia stream only goes in one 4 direction from a server (MSS server) to a client (MSS client, MS, MSS terminal). On the 5 sender side, the MSS includes content creation, storage, packetization, and 6 transmission. The streaming service supports both retrieval of pre-encoded content and 7 real-time encoded content. The service supports both real-time streaming (yellow) and 8 pseudo-streaming (blue). The requirements are different for real-time streaming and 9 pseudo-streaming. 10 Full Streaming Pseudo Streaming Render Media (Video,Speech,Audio,Other) Transport Media File Media File Control and Feedback Control MSS Terminal Air Interface Streaming Server 11 Figure 7-1 Multimedia Streaming Service 12 For real-time streaming the encoded information is sent through the packetizer at the 13 MSS server. The receiving MSS terminal Figure 7-2 de-packetizes the data and then 14 decodes it with the corresponding multimedia decoders. The output is then sent to local 15 multimedia devices to be played back. The MSS terminal may also receive a 16 presentation component, which allows additional spatial and temporal attributes to be 17 assigned to the received multimedia components beyond those implicit in the transport 18 and device defaults. 19 The MSS also includes system control protocols for setting up connections between the 20 client(s) and server; negotiating various options, capabilities, and configurations; and 21 communicating with and controlling the various source codecs that the MSS uses. It 22 also includes advanced procedures for monitoring and maintaining QoS under dynamic 23 conditions. The MSS service is intended to be interoperable (to the greatest extent 24 possible) with the 3GPP PSS service defined in [38]. 3G Multimedia Streaming Services 15
  16. 16. C.P0046-0 v1.0 1 Multimedia Streaming Service Terminal Functions Visual Output Video Decoder Presentation Synchronization De-packetizer and Transport Synchronization Audio Output Speech Decoder Presentation Layout Audio Decoder Wireless Communication Network Image Decoder Text Decoder Vector Graphics Decoder Presentation Description MSS Control MSS Control User Interface Interface 2 Figure 7-2 Multimedia Streaming Services Terminal Function 3 3G Multimedia Streaming Services 16
  17. 17. C.P0046-0 v1.0 1 8 Call procedures for Multimedia Streaming 2 Streaming of continuous media using RTP/UDP/IP (see 9.1) requires a session control 3 protocol to set-up and control the individual media streams. For the transport of 4 discrete media (images and text), vector graphics, and synthetic audio this specification 5 adopts the use of HTTP/TCP/IP (see 9.2). In this case there is no need for a separate 6 session set-up and control protocol since this is built into HTTP. This section describes 7 session set-up and control of continuous media. 8 8.1 Control Protocol (RTSP) 9 The MSS terminal shall use the Real-Time Streaming Protocol [21] to set-up and control 10 an MSS session. Additionally, MSS clients and servers: 11 • Shall follow the rules for minimal on-demand playback RTSP implementations in 12 appendix D of [21]; 13 • Shall implement the DESCRIBE method (see clause 10.2 in [21]; 14 • Shall implement the Range header field (see clause 12.29 in [21); 15 • Shall include the Range header field in all PLAY responses. 16 TCP should be used to transport RTSP messages reliably. 17 Additional requirements for RTSP usage during Capability Exchange (CE) are described 18 in section 8.2. 19 8.1.1 Mobile Link-Char Header 20 To enable MSS clients to report the link characteristics of the radio interface to the MSS 21 server, the "Mobile-Link-Char" RTSP header is defined. The header takes one or more 22 arguments. The reported information should be taken from a QoS profile as defined in 23 [2]. Note that this information is only valid for the wireless link and does not apply end- 24 to-end. However, the parameters do provide constraints that can be used. 25 Three parameters are defined that can be included in the header (future extensions are 26 possible). Any unknown parameter shall be ignored. The three parameters are: 27 - "MNT": the mobile network type. 28 - "GBW": the forward link user data rate in kilobits per second as defined by [2]. 29 - "MTD": the forward link maximum delay, as defined by [2] in milliseconds. 30 The "Mobile-Link-Char" header syntax is defined below using ABNF [53]: 31 mobilelinkheader = "Mobile-Link-Char" ":" link-char-spec *("," 0*1SP link-char-spec) 32 CRLF 33 link-char-spec = char-link-url *(";" 0*1SP link-parameters) 34 char-link-url = "url" "=" <">url<"> 35 link-parameters = Mobile-Type / Guaranteed-BW / Max-Transfer-delay / 36 extension-type 3G Multimedia Streaming Services 17
  18. 18. C.P0046-0 v1.0 1 Mobile-Type = "MNT" "=" 1*CHAR 2 Guaranteed-BW = "GBW" "=" 1*DIGIT ; kbps 3 Max-Transfer-delay = "MTD" "=" 1*DIGIT ; ms 4 extension-type = token "=" (token / quoted-string) 5 DIGIT = as defined in [21] 6 CHAR = as defined in [21] 7 token = as defined in [21] 8 quoted-string = as defined in [21] 9 url = as defined in [21] 10 The "Mobile-Link-Char" header can be included in a request using any of the following 11 RTSP methods: SETUP, PLAY, OPTIONS, and SET_PARAMETER. The header shall not 12 be included in any response. The header can contain one or more characteristic 13 specifications. Each specification contains a URI that can either be absolute or relative. 14 Any relative URI uses the RTSP request URI as a base. The URI points to the media 15 component that the given parameters apply to. This can either be an individual media 16 stream or a session aggregate. 17 The "Mobile-Link-Char" header should be included in a SETUP or PLAY request by the 18 client to give the initial values for the link characteristics. A SET_PARAMETER or 19 OPTIONS request can be used to update the Mobile-Link-Char values in a session 20 currently playing. It is strongly recommended that SET_PARAMETER be used as this 21 has the correct semantics for the operation. Additionally, it requires less overhead both 22 in bandwidth and server processing. If the client has initially reported these parameters 23 and they are changed during the session, the client shall update these parameters by 24 including the "Mobile-Link-Char" header in a SET_PARAMETER or OPTIONS request. 25 When performing updates of the parameters, all of the previous signaled values are 26 undefined and only the given ones in the update are defined. This means that even if a 27 parameter has not changed it must be included in the update. 28 The entries of the "MNT" field has the following syntax: 29 3GPP2-<Network Type ID>-<Release information> 30 Network Type ID: 31 1. SSS – Spread Spectrum Systems 32 2. HRPD – High Rate Packet Data 33 Example 1: 34 Mobile-Link-Char: url=" rtsp://server.foo.com/presentation.3g2"; MNT=3GPP2-SSS- 35 REL-C; GBW=32; MTD=2000 36 In the above example the header tells the server that its mobile network is cdma2000® 37 Spread Spectrum Systems Release C (1xEV-DV) on an Assured Mode with a bit-rate of 38 32 kbps and a maximum transfer delay of 2.0 seconds. If only mobile network type 39 "MNT" parameter is presented, the server shall assume Non-Assured Mode.  cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000® is a registered trademark of the Telecommunications Industry Association (TIA- USA) in the United States. 3G Multimedia Streaming Services 18
  19. 19. C.P0046-0 v1.0 1 Example 2: 2 Mobile-Link-Char: url=" rtsp://server.foo.com/presentation.3g2"; MNT=3GPP2-HRPD- 3 REL-0; 4 In this example the client tells the server that it is operating on a Non-Assured 1xEV- 5 DO Release 0 mobile network. 6 8.1.2 The 3GPP-Adaptation Header 7 To enable MSS clients to request a desired buffer size, a new RTSP request and 8 response header is defined. The header can be used in the methods SETUP, PLAY, 9 OPTIONS, and SET_PARAMETER. The header defined in ABNF [53] has the following 10 syntax: 11 3GPP-adaptation-def = "3GPP-Adaptation" ":" request-spec 0*("," request-spec) 12 request-spec = url-def *buffer-params 13 buffer-params = ";" buffer-size-def 14 / ";" target-time-def 15 url-def = "url" "=" <"> url <"> 16 buffer-size-def = "size" "=" 1*9DIGIT ; bytes 17 target-time-def = "target-time" "=" 1*9DIGIT; ms 18 url = ( absoluteURI / relativeURI ) 19 absoluteURI and relativeURI are defined in [54] and updated in [55]. The base URI for 20 any relative URI is the RTSP request URI. 21 The "3GPP-Adaptation" header shall be sent in responses to requests containing this 22 header. The MSS server shall not change the values in the response header. The 23 presence of the header in the response indicates to the client that the server 24 acknowledges the request. 25 The buffer size signaled in the "3GPP-Adaptation" header shall correspond to a 26 reception and de-jittering buffer that has this given amount of space for complete RTP 27 packets (including the RTP header). The specified buffer size shall also include any 28 Annex C. pre-decoder buffer space used for this media, as the two buffers cannot be 29 separated. 30 The target time signaled in the value of the "target-time" parameter is the targeted 31 minimum buffer level or, in other words, the client desired amount of playback time in 32 milliseconds to guarantee interrupt-free playback and allow the server to adjust the 33 transmission rate, if needed. 34 Example: 35 3GPP-Adaptation: url="rtsp://server.foo.com/presentation.3g2/streamID=1"; 36 size=35000;target-time=5000 37 8.1.3 The "Avc-rtpinterleaving" Header 38 The MSS client should implement the RTSP "avc-rtpinterleaving" header when 39 H.264/AVC RTP interleaved packetization mode is supported. The header can be used 3G Multimedia Streaming Services 19
  20. 20. C.P0046-0 v1.0 1 in the methods SETUP, PLAY, OPTIONS, and SET_PARAMETER. 2 The entry of the "avcrtpinterleaving" field defines how much memory out of the reported 3 client's jitter buffer space can be used for interleaved packets. The value of the 4 "avcrtpinterleaving" field is defined in bytes. If the value of the "avcrtpinterleaving" field 5 equals zero, the interleaved packetization mode is prohibited. This header also indicates 6 that all the AVC RTP packetization types are supported. 7 Example 1: 8 avc-rtpinterleaving: url=" rtsp://server.foo.com/presentation.3g2"; 9 avcrtpinterleaving=3200 10 8.2 Session Set-up (SDP) 11 SDP shall be used for MSS set-up. MSS servers shall provide and MSS clients shall 12 interpret the SDP syntax according to the SDP specification [22] and appendix C of [21]. 13 The SDP delivered to the MSS client shall declare the media types to be used in the 14 session using a codec specific MIME media type for media as described in section [11] 15 of this document. 16 The SDP [22] specification requires certain fields to always be included in an SDP file. 17 Apart from this an MSS server shall include the following fields in the SDP: 18 • "a=control:" according to clauses C.1.1, C.2 and C.3 in [21]; 19 • "a=range:" according to clause C.1.5 in [21]; 20 • "a=rtpmap:" according to clause 6 in [22]; 21 • "a=fmtp:" according to clause 6 in [22]. 22 The bandwidth field in SDP shall be used to indicate to the MSS terminal the amount of 23 bandwidth that is required for the session and the individual media in the presentation. 24 Therefore, an MSS server should include the "b=AS:" field in SDP (both at the session 25 and media level) and an MSS client shall be able to interpret this field. For RTP based 26 applications, AS gives the RTP "session bandwidth'' (including UDP/IP overhead) as 27 defined in section 6.2 of [11]. 28 NOTE: The SDP parsers and/or interpreters should be able to accept NULL values in 29 the 'c=' field (e.g. 0.0.0.0 in IPv4 case). This may happen when the media content does 30 not have a fixed destination address. For more details, see Section C.1.7 of [21] and 31 Section 6 of [22]. 32 8.2.1 Session Capability Exchange (SDP) 33 • An advanced method for Capability Exchange (CE) is defined in section 8.3 of this 34 document. When an MSS client or server supports capability exchange it shall 35 support the transport of profile information over both HTTP and RTSP as defined in 36 section 5.2.5, “Signalling of profile information between client and server,” of [38]. 37 [Note that the 3GPP acronym PSS is equivalent to the 3GPP2 acronym MSS]. 38 8.2.2 Session Video Buffering (SDP) 39 The following Buffering of Video (Normative) related media level SDP fields are defined 3G Multimedia Streaming Services 20
  21. 21. C.P0046-0 v1.0 1 for MSS: 2 • "a=X-predecbufsize:<size of the hypothetical pre-decoder buffer>" 3 This gives the suggested size of the Appendix C hypothetical pre-decoder buffer in 4 bytes. 5 • "a=X-initpredecbufperiod:<initial pre-decoder buffering period>" 6 This gives the required initial pre-decoder buffering period specified according to 7 Appendix C. Values are interpreted as clock ticks of a 90-kHz clock. That is, the 8 value is incremented by one for each 1/90 000 seconds. For example, value 180 9 000 corresponds to a two second initial pre-decoder buffering. 10 • "a=X-initpostdecbufperiod:<initial post-decoder buffering period>" 11 This gives the required initial post-decoder buffering period specified according to 12 Appendix C. Values are interpreted as clock ticks of a 90-kHz clock. 13 • "a=X-decbyterate:<peak decoding byte rate>" 14 This gives the peak decoding byte rate that was used to verify the compatibility of 15 the stream with Appendix C. Values are given in bytes per second. 16 If none of the attributes "a=X-predecbufsize:", "a=X-initpredecbufperiod:", "a=X- 17 initpostdecbufperiod:", and "a=x-decbyterate:" are present, clients should not expect a 18 packet stream according to Appendix C. If at least one of the listed attributes is present, 19 the transmitted video packet stream shall conform to Appendix C. If at least one of the 20 listed attributes is present, but some of the listed attributes are missing in an SDP 21 description, clients should expect a default value for the missing attributes according to 22 Appendix C. 23 8.2.3 Additional Attributes (SDP) 24 The MSS client should be able to interpret the following attribute: 25 a=X-disallowrandomaccess 26 This indicates that random access is not allowed for this session. This may imply that 27 the stream is live and that any PLAY request will display the stream from its current 28 point. A PLAY request, if used for an on-demand session after the initial one, will be 29 treated by the server to have no Range header regardless of the actual presence of it. 30 That is, the PLAY request indicates a restart from the beginning or resuming from the 31 pause point at the server's discretion (for details, refer to Section 10.5 of [21]). To avoid 32 an unnecessary delay that can be caused in this process, the MSS client should 33 deactivate the random access feature for such a session. E.g., deactivation of rewind 34 and fast forward buttons in the user interface. 35 36 For live sessions indicated by an open ended a=range attribute, a PAUSE will mean that 37 the MSS client does not receive the stream for the paused interval and the MSS client 38 shall issue a PLAY request to resume with Range header with the indicator, 'now', e.g., 39 "Range: npt=now-". 40 41 The MSS client and server should interpret the "alt", "alt-default-id", and "alt-group" 3G Multimedia Streaming Services 21
  22. 22. C.P0046-0 v1.0 1 attributes as described in [38]. The "alt" attribute is used to replace or add an SDP line 2 to the default configuration. The "alt-default-id" attribute is used to assign an 3 alternative identifier to the default alternative. The "alt-group" attribute is used to 4 define grouping alternatives from which the client can select the most appropriate. 5 These attributes are used together to create combinations consisting of, e.g., one audio 6 and one video alternative. It is the server’s responsibility to create meaningful grouping 7 alternatives. 8 8.2.4 Session 3GPP-Adaptation-Support (SDP) 9 The MSS server should implement a media level only SDP attribute when "Bit Rate 10 Adaptation" is supported. 11 "a=3GPP-Adaptation-Support:<report frequency>" 12 When a MSS client receives a SDP description where the SDP attribute "3GPP- 13 Adaptation-Support" is presented shall then in its subsequent RTSP signaling use the 14 "3GPP-Adaptation" header as defined in section 8.1.2, as well as the RTCP NADU APP 15 packet defined in section 9.1.1. 16 The report frequency value defines the frequency of the buffer level feedback signaling. 17 For example, if the value is 2 then the client shall send the NADU APP packet every two 18 RTCP packets. 19 When the MSS client receives "3GPP-Adaptation-Support" signaling from the server, the 20 Annex C related RTSP signaling "x-predecbufsize" and "x-initpostdecbufperiod" can be 21 ignored. The RTSP "x-initpredecbufperiod" and SDP signaling defined in clause 8.2.2 22 will remain effective. 23 8.2.5 Session HE AAC Support (SDP) 24 The terminal shall support the signaling types "implicit" and "hierarchical explicit" 25 signaling (as defined in [47]). If implicit signaling is used, the AAC object type is 26 signaled to maintain backwards compatibility. If, in such a case, the sampling rate as 27 indicated by the AAC object type descriptor (in the SDP) is 24 kHz or below and "SBR- 28 enabled" (see below) is not specified in the SDP, the output shall be configured to twice 29 the AAC sampling rate. In both types of signaling, the MIME type indicated to the 30 terminal for HE AAC shall be the same as for AAC LC. 31 Servers using implicit signaling shall include the "SBR-enabled" parameter in the SDP 32 "a=fmtp" line. "SBR-enabled" shall be set to "1" for streams containing SBR and shall be 33 set to "0" for streams not containing SBR. Terminals may rely on this parameter to set 34 the correct output sampling rate to either the indicated rate (where "SBR-enabled" is set 35 to "0") or twice the indicated rate (where "SBR-enabled" is set to "1"). 36 The above signaling support is not required if only AAC is supported. 37 8.3 Capability Exchange (CE) 38 39 8.3.1 Overview 40 Enhanced capability negotiation provides additional functionality for the MSS by 3G Multimedia Streaming Services 22
  23. 23. C.P0046-0 v1.0 1 enabling the MSS servers to provide tailored content suitable for a particular MSS 2 terminal. Another very important task is to provide a smooth transition between 3 different releases of MSS. A Capability Exchange (CE) mechanism for streaming is 4 defined in [38] and should be supported by MSS clients and servers with the additional 5 requirements as described in this document. 6 8.3.2 Description 7 When CE is supported the corresponding device capability profile shall be an RDF 8 document that follows the structure of the CC/PP framework and the CC/PP 9 application UAProf as described in clause 5.2.2 of [38]. 10 The CE vocabulary and its usage is also defined in [38] and summarized in Table 8-1, 11 Table 8-2, and Table 8-3. Some additional cdma2000 values are also defined. When CE 12 is supported, MSS CE vocabulary usage shall be as described in [38]. 13 When support for "media/types" in [38] conflicts with this specification, support as 14 described in this document shall take precedence. 15 The MSS base vocabulary contains one component called "Streaming". A vocabulary 16 extension to UAProf shall be defined as an RDF schema. This schema can be found in 17 Annex F or [38]. The schema together with the description of the attributes in this 18 section, defines the vocabulary. All MSS attributes shall be put in the "Streaming" 19 component. 20 MSS servers should understand the attributes of the "Streaming" component of the 21 MSS base vocabulary. 22 MSS Capability Exchange Vocabulary ( component = "Streaming" ) Name 3GPP2 values Applicable 3GPP Values AdaptationSupport "Yes","No" AvcRtpInterleaving Integer value greater than or equal to 0 (Bytes) AudioChannel "Mono","Stereo" Brands List of supported 3G2 List of supported 3GP profiles profiles identified by identified by brand. brand. MaxPolyphony Integer value between 5 and 24 StreamingAccept List of content types (MIME types) the application supports StreamingAccept-Subset List of content types for which the PSS application supports a subset "JPEG-PSS","SVG-Tiny","SVG- Basic" 3G Multimedia Streaming Services 23
  24. 24. C.P0046-0 v1.0 PssVersion or "3GPP2-MSS-0" "3GPP-R4","3GPP-R5","3GPP- R6" MssVersion RenderingScreenSize Two integer values equal or greater than zero. A value equal "0x0"means that there exists no possibility to render visual MSS presentations. SmilBaseSet "SMIL-3GPP2-FFMS-0", "SMIL-3GPP-R4","SMIL-3GPP- "SMIL-3GPP2-FFMS-A"1 R5","SMIL-3GPP-R6" SmilModules This attribute defines a list of SMIL 2.0 modules supported by the client. If the SmilBaseSet is used those modules do not need to be explicitly listed here. In that case only additional module support needs to be listed. SmilAccept This attribute defines a list of content types (MIME types) that can be part of a SMIL presentation. SmilAccept-Subset This attribute defines a list of content types for which the PSS application supports a subset. MIME types can in most cases effectively be used to express variations in support for different media types. "JPEG-PSS", "SVG-Tiny", "SVG-Basic" Three3GPP2LinkChar "Yes","No" ThreeG2Accept ThreeG2Accept-Subset VideoDecodingByteRate Integer value greater than or equal to 8000 (Bytes per second) VideoInitialPostDecoderBuf Integer value equal to or feringPeriod greater than zero 1 Version 1.0 and A for 3GPP2 SMIL profiles are defined in [7]. 3G Multimedia Streaming Services 24
  25. 25. C.P0046-0 v1.0 VideoPreDecoderBufferSize Integer value equal to or greater than zero. Values greater than one but less than the default buffer size defined in Annex C are not allowed 1 2 Table 8-1 Summary of non-UAProf defined Attributes for MSS CE 3 In the UAProf vocabulary [38] there are several attributes that are of interest for the 4 MSS. Table 8-2 and Table 8-3 summarize the UAProf attributes recommended for MSS 5 applications for "HardwarePlatform" and "SoftwarePlatform" respectively. 6 MSS servers should understand the recommended attributes from the UAProf 7 vocabulary [38]. An MSS server may additionally support other UAProf attributes. 8 UAProf Capability Exchange Vocabulary (component = "HardwarePlatform" ) Name 3GPP2 values Applicable UAProf Values BitsPerPixel The number of bits of color or grayscale information per pixel ColorCapable Whether the device display supports color or not: "Yes" or "No" PixelAspectRatio Ratio of pixel width to pixel height: "1x2" PointingResolution Type of resolution of the pointing accessory supported by the device" "Pixel" Model Model number assigned to the terminal device by the vendor or manufacturer: "Viper" Vendor Model number assigned to the terminal device by the vendor or manufacturer: "Dodge" 9 10 Table 8-2 Summary of UAProf (HardwarePlatform) defined Attributes for MSS CE 11 UAProf Capability Exchange Vocabulary ( component = "SoftwarePlatform" ) Name 3GPP2 values Applicable UAProf Values CcppAccept-Charset List of character sets the device supports CcppAccept-Encoding List of transfer encodings the device supports 3G Multimedia Streaming Services 25
  26. 26. C.P0046-0 v1.0 CcppAccept-Language List of preferred document languages 1 2 Table 8-3 Summary of UAProf (SoftwarePlatform) defined Attributes for MSS CE 3 The use of RDF enables an extensibility mechanism for CC/PP-based schemas to 4 address the evolution of new devices and applications. The MSS profile schema 5 specification provides a base vocabulary, which may need to be updated to express new 6 attributes. If the base vocabulary is updated, a new unique namespace will be assigned 7 to the updated schema. The base vocabulary shall only be changed by the TSG 8 responsible for the present document. All extensions to the profile schema shall be 9 governed by the methods defined in section 5.2.4.1 “Vocabulary definitions” of [38] 10 clause 7.7 11 • When an MSS client or server supports CE, it shall support the profile information 12 transport over both HTTP and RTSP between client and server as defined in section 13 5.3.5 “Signalling of profile information between client and server” of [38]. [Note that 14 the 3GPP acronym PSS is equivalent to the 3GPP2 acronym MSS]. 15 When device CE profiles are merged, they shall be merged as described in the clause 16 titled "Merging device capability profiles" in [38]. 17 When device CE profiles are exchanged between a CE profile server and an MSS server, 18 they shall be exchanged as described in clause titled "Profile transfer between PSS 19 server and the device profile server" in [38]. 20 8.4 Presentation/Layout Description 21 The presentation/layout description describes the spatial and temporal relationship 22 between the components of the media stream. The spatial format describes the 23 rendering of the visual media components on the MSS terminal display. The temporal 24 format describes when and how long visual media should be displayed or audio media 25 played. 26 The MSS terminal should support "presentation/layout description". If the MSS 27 terminal supports "presentation/layout description" it 28 • Shall support 3GPP2 SMIL language profile as described in [7]. 29 8.4.1 SMIL Usage in MSS 30 If the terminal has some prior knowledge about the file type it is about to retrieve, e.g. 31 file extensions, then: 32 When retrieving a SMIL file with HTTP the client should include profile information in 33 the GET request. This way the HTTP server can deliver an optimized SMIL presentation 34 to the client. A SMIL presentation can include links to static media. The server should 35 optimize the SMIL file so that links to the referenced static media are adapted to the 36 requesting client. When the "x-wap-profile-warning" indicates that content selection has 37 been applied (201-203) the MSS client should assume that no more capability exchange 38 has to be performed for the static media components. In this case it should not send 39 any profile information when retrieving static media to be included in the SMIL 40 presentation. This will minimize the HTTP header overhead. 3G Multimedia Streaming Services 26
  27. 27. C.P0046-0 v1.0 1 8.5 Data Channel Setup 2 The IP bearer for carrying the multimedia streaming traffic shall be set-up according to 3 the procedures described in: 4 • Service option 33 or 66 [2] for cdma2000 1x and cdma2000 1xEV-DV and 5 • Service Option 591 [56] for High Rate Packet Data [51]. 6 Service Option 33/66 uses the Radio Link Protocol Type 3 [3]. The RLP retransmission 7 scheme is negotiated between the MS and base station using the RLP_BLOB procedures 8 [3]. 9 As a general rule RLP allows the bearer to trade bandwidth and delay for reliability. As 10 a rule of thumb the bandwidth will be reduced by a factor of: 11 Effective Bandwidth = 1/(1+SUM(FERn)) n = 1…Num RLP Retransmissions, 12 and delay increased by a factor of n*RLP_RoundTripTime. Typically RLPRoundTripTime 13 is 100 to 200 ms. 14 8.5.1 Header Compression 15 Header compression is a method for greatly compressing redundant information in IP, 16 UDP, and RTP headers. Depending on the media type and the number of media frames 17 in a packet this header information can actually consume more bandwidth than the 18 raw media data. 19 There are several general-purpose and media specific header compression methods 20 which can be used with MSS, namely Robust Header Compression (ROHC) and the 21 cdma2000 specific header reduction methods [50] service option 60 (Header removal) 22 and service option 61 (LLAROHC). Service option 60 and 61 are only applicable to 23 cdma2000 vocoders (EVRC, 13K and VMR-WB), which conform to the RS1 (9.6kbps) or 24 RS2 (14.4kbps) channels. When service option 60 is in use the IP session for service 25 option 60 terminates at the PDSN and not at the MSS client. 26 MSS Client Speech codec From MSS IP Server IP SO33 ROHC ROHC SO61 LLAROHC LLAROHC SO60 1 This service option assignment made for identification defined in the Radio Access Network MSS Terminal is not carried over the air interface. Air Interface PDSN 3G Multimedia Streaming Services 27 IP traffic (uncompressed, compressed) - Control, Video, etc… Voice traffic (uncompressed, compressed)
  28. 28. C.P0046-0 v1.0 1 Figure 8-1 Data Channel Set-up (SO 33/66, 60 and 61) 2 8.6 Session Termination 3 RTSP shall be used to terminate the session when the session is completed. The packet 4 data service call is terminated using the procedures defined in Service Option 33/66 5 [2]. If service option 60 or 61 are in use they should be torn down before the service 6 option 33/66 teardown. 7 3G Multimedia Streaming Services 28
  29. 29. C.P0046-0 v1.0 1 9 Transport Protocol 2 The MSS client shall support packetization and transport via both RTP [11] /UDP [12] 3 /IP [13] and HTTP [23]/TCP [24] /IP to receive components of the MSS. 4 Support for specific media types are described in the remainder of this section. 5 9.1 RTP/UDP 6 The MSS client shall support transport of continuous media (video, speech, audio and 7 timed text) via RTP/UDP/IP. (Figure 9-1). 8 The MSS client shall provide an IP bearer as described in section 8.5. 9 Session Setup Speech Other Session Control Video Application Media Presentation Description Capability Exchange Audio PAYLOAD Other HTTP RTSP RTP/RTCP Transport TCP UDP Transport IP IP IP PPP PPP Other RLP RLP R-P R-P Air Link Air Link Physical Physical Physical MSS Terminal BTS/BSC/PCF PDSN/Server 10 11 Figure 9-1 Protocol Stack for Multimedia Streaming Service 12 The MSS terminal shall support RTP packetization and RTCP feedback as defined in 13 "RTP: A Transport Protocol for Real-Time Applications" [11] and in "RTP Profile for Audio 14 and Video Conferences with Minimal Control" [14] for the following media types when 15 supported: 16 For the MPEG-4 video coder, the payload format shall be as defined in "RTP Payload 17 Format for MPEG-4 Audio/Visual Streams" [15]. 18 For the H.263 video coder, the payload format shall be as defined in "RTP Payload 19 Format for the 1998 Version of ITU-T Rec. H.263 (H.263+)" [16]. 20 For the H.264 video coder, the payload format shall be as defined in "RTP Payload 21 Format for H.264 Video", [19]. 22 For the 13K speech coder, the payload format shall be as defined in "RTP Payload 23 Format for PureVoice(tm) Audio" [17]. 3G Multimedia Streaming Services 29
  30. 30. C.P0046-0 v1.0 1 For the EVRC speech coder, the payload format shall be as defined in "RTP Payload and 2 Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Multimode Vocoders 3 (SMV)" [18]. 4 For the VMR-WB speech coder, the payload format shall be as defined in "RTP Payload 5 formats for the Variable-Rate Multimode Wideband (VMR-WB) Audio codec" [20]. 6 For the MPEG4 AAC Audio Coder, the payload format shall be as defined in "RTP 7 Payload Format for MPEG-4 Audio Visual Streams" [15]. 8 For the MPEG-4 HE AAC Audio Coder, the payload format shall be as defined in "RTP 9 Payload Format for MPEG-4 Audio Visual Streams" [15]. 10 NOTE: The number of octets received by an MSS terminal can be closely calculated by 11 multiplying the "sender's octet count" field of the RTCP Sender report by the "fraction 12 lost" field of the corresponding report block in the RTCP Receiver report. 13 9.1.1 RTCP extension (NADU APP packet) 14 A MSS client should implement the RTCP APP packet (Application-Defined RTCP 15 Packet) as defined in section 6.7 of [11] to support the client buffer level feedback 16 function for reporting the Next Application Data Unit (NADU). 17 18 0 1 2 3 19 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 21 |V=2|P| subtype | PT=APP=204 | length | 22 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 23 | SSRC/CSRC | 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 25 | name (ASCII) | 26 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 27 | application-dependent data ... 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 29 Figure 9-2: Generic Format of an RTCP APP packet. 30 31 · name: The NADU APP data format is detected from the name "PSS0". (value: 32 0x50535330) 33 · subtype: This field shall be set to 0 for NADU format. 34 · Length: The number of 32 bit words -1, as defined in RFC 3550 [11]. This means 35 that the field will be 2+3*N, where N is the number of sources reported on. The 36 length field will typically be 5, i.e. 24 bytes packets.· Application-dependent data: 37 One or more of the following data format blocks (as described in Figure 9-3) can be 38 included in the application-dependent data location of the APP packet. The APP 39 packets length field is used to detect how many blocks of data are present. The 40 block shall be sent for the SSRCs for which there are a report block, part of either a 41 Receiver Report or a Sender Report, included in the RTCP compound packet. An 3G Multimedia Streaming Services 30
  31. 31. C.P0046-0 v1.0 1 NADU APP packet shall not contain any other data format than the one described in 2 Figure 9-3 below. 3 4 0 1 2 3 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | SSRC | 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Playout Delay | NSN | 10 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Reserved | NUN | Free Buffer Space (FBS) | 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13 Figure 9-3: Data format block for NADU reporting 14 SSRC: The SSRC of the media stream the buffered packets belong to. 15 Playout delay (16 bits): The difference between the scheduled playout time of the 16 next ADU to be decoded and the time of sending the NADU APP packet, as 17 measured by the media playout clock, expressed in milliseconds. The client may 18 choose not to indicate this value by using the reserved value (Ox FFFF). In case of 19 an empty buffer, the playout delay is not defined and the client should also use the 20 reserved value 0xFFFF for this field. 21 The playout delay allows the server to have a more precise value of the amount of 22 time before the client will underflow. The playout delay shall be computed until the 23 actual media playout (i.e., audio playback or video display). 24 25 NSN (16 bits): The RTP sequence number of the next ADU to be decoded for the 26 SSRC reported on. In the case where the buffer does not contain any packets for 27 this SSRC, the next not yet received sequence number shall be reported, i.e. an 28 NSN value that is one larger than the least significant 16 bits of the RTCP SR or RR 29 report block's "extended highest sequence number received". 30 NUN (5 bits): The unit number (within the RTP packet) of the next ADU to be 31 decoded. The first unit in a packet has a unit number equal to zero. The unit 32 number is incremented by one for each ADU in an RTP packet. In the case of an 33 audio codec, an ADU is defined as an audio frame. In the case of H.264 (AVC), an 34 ADU is defined as a NAL unit. In the case of H.263 and MPEG4 Visual Simple 35 Profile, an ADU is defined as a whole or a part of an H.263 video picture or MPEG4 36 VOP that is included in a RTP packet. In the specific case of H.263, each packet 37 carries a single ADU and the NUN field shall be thus set to zero. Future additions 38 of media encoding or transports capable of having more than one ADU in each RTP 39 payload shall define what shall be counted as an ADU for this format. 40 FBS (16 bit): The amount of free buffer space available in the client at the time of 41 reporting. The reported free buffer space shall all be part of the buffer space that 42 has been reported as available for adaptation by the 3GPP-Adaptation RTSP 43 header, see section 8.1.2. The amount of free buffer space are reported in number 44 of complete 64 byte blocks, thus allowing for up to 4194304 bytes to be reported as 45 free. If more is available, it shall be reported as the maximal amount available, i.e. 3G Multimedia Streaming Services 31
  32. 32. C.P0046-0 v1.0 1 4194304 with a field value 0xffff. 2 • Reserved (11 bits): These bits are not used and shall be set to 0 and shall be 3 ignored by the receiver. 4 9.2 HTTP/TCP and Container Formats 5 Some media types, which may be used in an MSS presentation do not currently have a 6 corresponding RTP definition. Therefore, it may be necessary to receive these media 7 types using HTTP/TCP/IP transport (Figure 9-1). Among these media types are: 8 • Audio (Synthetic): SP-MIDI [40], General MIDI [41] and Compact MIDI [7], 9 • Text: Unicode [31] (e.g. US-ASCII [32], ISO-8859-1 [33], UTF-8 [34], GSM 7-bit 10 default alphabet [35], Shift-JIS, etc…), 11 • Timed Text: 3GPP Timed Text [52], 12 • Bitmap Graphics: GIF87 [25], GIF89A [26], PNG [30], 13 • Still Image: JPEG [27], 14 • Vector Graphics: SVG-Tiny [36], [37] and SVG-Basic [36], [37]. 15 When delivering multimedia using HTTP/TCP/IP, media elements should be aggregated 16 into a container file. 17 When multiple media elements are aggregated for combined delivery over HTTP/TCP or 18 other non-streaming approaches they shall be combined using the ".3g2" format as 19 described in [7] when possible to do so. 20 When multiple media elements are aggregated for combined delivery over HTTP/TCP or 21 other non-streaming approaches, and it is not possible to do so using the ".3g2" format, 22 they shall be combined using the ".cmf" format as described in [7] when possible to do 23 so. 24 Media that cannot be aggregated using ".3g2" or CMF may use alternative methods. 25 NOTE: When timed text is present in a “.3g2” file along with audio, speech and/or video 26 components, the audio, speech and/or video components may be parsed at the server 27 and streamed using RTSP/RTP as described in 8.1 / 9.1. 28 9.2.1 Transport of CMF Over HTTP 29 HTTP GET request is used to specify a CMF file by URI. When retrieving a CMF file with 30 HTTP GET request, the client should include optional enhancement parameters such 31 that the HTTP server can deliver an optimized CMF content to the client. Optimizations 32 may include, but are not limited to, CMF version, display size and other content 33 restrictions. 34 The MSS server shall ignore the URI parameters that it does not support. Multiple URI 35 parameters may be listed, and the delimiter "&" shall be used for such cases. Syntax of 36 GET request is shown below. 37 GET URI?uri_parameter_name1=value&uri_parameter_name2=value HTTP/1.1 38 CRLF 39 CRLF 40 Item M/O Description 3G Multimedia Streaming Services 32
  33. 33. C.P0046-0 v1.0 URI M URI to the 3GPP2 CMF file. vn represents the CMF version number. CMF Version URI vn O parameters number is the 4 bytes of data from the 'vers' subchunk. The first two bytes specify major version and the second two bytes specify minor version. The major and minor version numbers are represented in ASCII sh O sh represents the screen height, with 2 bytes. sh=height sw O sw represents the screen width, with 2 bytes. sw=width 1 Table 9-1 CMF parameters for HTTP GET 2 M/O stands for "Mandatory" or "Optional", respectively. 3 3G Multimedia Streaming Services 33
  34. 34. C.P0046-0 v1.0 1 10 Pseudo Streaming 2 Transfer of dynamic media content (Video, Speech, Audio, Timed Text) to the MSS 3 terminal may also be accomplished via file download using the TCP protocol as 4 referenced previously in section 9. The ".3g2" file format [7] shall be used for pseudo 5 streaming of timed multimedia (such as video, associated audio and timed text]. 6 The basic sequence of pseudo streaming is depicted in Figure 10-1. MSS client sends 7 HTTP GET request which specifies the file to be downloaded and MSS server transmits 8 the file in the response to the request. MSS client may start multimedia decoding and 9 playback during the download. Client Server GET /foo.3g2 http/1.1 <CR><LF> HTTP/1.1 200 OK <CR><LF> Start of the file receiving Start of playback End of the file receiving 10 11 Figure 10-1 Basic Sequence of Pseudo-streaming 12 10.1 Session Description 13 When deploying pseudo streaming, MSS session set up procedure described in section 14 8.2 is not required. 15 The necessary information for the client is URI of multimedia file and the file size, 16 which are provided by some means such as HTTP, e-mail and etc. The representation of 17 such information is not defined in this specification. 18 10.2 Transport Options 19 20 10.2.1 Request 21 HTTP GET request is used to specify a pseudo streaming file by URI. 22 The request is optionally enhanced using URI parameters and message-headers. The 23 MSS pseudo-streaming server that does not support these options shall ignore the URI 24 parameters that it does not support. Multiple URI parameters may be listed; the 25 delimiter "&" shall be used for such cases. Syntax of GET request is shown below. 26 GET URI?uri_parameter_name1=value&uri_parameter_name2=value HTTP/1.1 3G Multimedia Streaming Services 34
  35. 35. C.P0046-0 v1.0 1 message-header 2 CRLF 3 CRLF 4 Item M/O Description URI M URI to the 3GPP2 file. URI ac O Access Ticket obtained from the presentation parameters description br O Bit rate selection in accordance with the presentation description st O Specifies the start position of the transmission in milliseconds. Effective only for the initial transmission request, where ts=2. ts O 2: The beginning of the transmission 3: Continuous transmission This parameter shall exist if ac is contained. message- Range O bytes=0-XXXXX (The beginning of the transmission) header bytes=YYYYY-ZZZZZ (Subsequent transmission) 5 Table 10-1 Pseudo-streaming HTTP GET request parameters 6 M/O stands for "Mandatory" or "Optional", respectively. 7 10.2.2 Response 8 Requested data is sent back to the MSS client in the response. The response is 9 optionally enhanced using message-headers. The MSS pseudo-streaming client that 10 does not support these options shall ignore those that it does not support. 11 Response to the data transmission request is defined in the following. 12 HTTP/1.1 Status Code 13 message-header 14 CRLF 15 CRLF 16 requested data 17 3G Multimedia Streaming Services 35
  36. 36. C.P0046-0 v1.0 Item M/O Value Status Code M 200 OK (for full length data) 206 Partial Content (for ranged data) message Content-Range O bytes=xxxx-xxxx/xxxxxx (The size -header transmitted) Required for the status "206 Partial Content" 1 Table 10-2 Pseudo-streaming HTTP response options 2 Regarding the Range parameter, the start bytes shall correspond to the actual bytes 3 received at the previous request. The following table shows an example. Note that the 4 Range parameter doesn’t specify an actual position of the content in the server but 5 specifies the number of bytes expected through the transmission. 6 The request number Specified bytes in the request Actual bytes in the response 1 0-96767 48000 2 48000-144767 52000 3 100000-196767 50000 7 Table 10-3 Example of pseudo-streaming message header range parameters 8 The uses of these options are described in the informative 9 3G Multimedia Streaming Services 36
  37. 37. C.P0046-0 v1.0 1 2 Pseudo Streaming Session Representation Example (Informative). 3 10.3 FFMS Usage in MSS 4 The MSS terminal should support pseudo-streaming. If the MSS terminal does support 5 pseudo-streaming, it shall support the ".3g2" MSS file format as specified in [7] and 6 specifically the transmission format for pseudo-streaming as specified in section B.1.2 7 of Annex B of that document. 8 3G Multimedia Streaming Services 37
  38. 38. C.P0046-0 v1.0 1 11 Media Types (Codecs) 2 3 11.1 General Requirements 4 Support for all media types is not required. When media support is not mandatory this 5 will be stated. When a media type is supported it shall include the mandatory codecs 6 specified for that media type. 7 11.2 "Video" 8 The MSS terminal should support the media type "Video". If the media type "video" is 9 supported then the MSS terminal: 10 • Shall support decoding of ITU-T Recommendation H.263 Profile 0 Level 45 [9] 11 • Shall support decoding of at least one of the following: 12 • MPEG-4 Visual Simple Profile Level 0b [10], 13 • H.264 Baseline Profile [45] Level 1b with constraint_set1_flag=1. 14 • Should support decoding of ITU-T Recommendation H.263 Profile 3 Level 45 [9] 15 For continuous video media the following MIME media types shall be used: 16 • For H.263 the MIME media type as defined in clause 4.2.7 of [14]; 17 • For MPEG-4 video the MIME media type as defined in [15]. When used in SDP 18 the configuration information shall be carried outband in the "config" SDP 19 parameter and inband (as stated in [15]). As described in [15], the 20 configuration information sent inband and the config information in the SDP 21 shall be the same except that first_half_vbv_occupancy and 22 latter_half_vbv_occupancy which, if exist, may vary in the configuration 23 information sent inband; 24 • For H.264 (AVC) video the MIME media type as defined in [19]. 25 Note that H.263 profile 0 level 10 is contained in MPEG-4 Visual as the short header 26 format. 27 The video decoder should include basic error concealment technologies. These 28 techniques may include re-generating data that is lost in transmission by re-using or 29 interpolating from the temporal adjacent frames or from spatial adjacent regions of the 30 same frame. 31 The video encoder and decoder for the MSS terminal should support square pixel 32 format. The encoder should signal this to avoid un-necessary pixel shape conversion. 33 11.3 "Speech" 34 There are two types of speech defined for MSS – Narrow Band (NB) and Wide Band 35 (WB). 3G Multimedia Streaming Services 38
  39. 39. C.P0046-0 v1.0 1 11.3.1 "Narrow Band Speech" 2 The MSS terminal shall support at least one of the following media type "Narrow Band 3 Speech": 4 • EVRC [5], 5 • 13K Vocoder [6]. 6 For continuous narrow band speech media the following MIME media types shall be 7 used: 8 • For EVRC the MIME media type as defined in clause 12.1 of [18]; 9 • For 13K the MIME media type as defined in clause 4.1 of [57] for storage and 10 clause 4.1.20 of [58] for streaming. 11 11.3.2 "Wide Band Speech" 12 The MSS terminal should support the media type "Wide Band Speech". If the media 13 type "Wide Band Speech" is supported the MMS terminal: 14 • Shall support VMR Wide Band [8]; 15 For continuous wide band speech media the following MIME media types shall be used: 16 • For VMR-WB the MIME media type as defined in [20] 17 11.4 "Audio" 18 The MSS terminal should support media type "audio". If the media type "audio" is 19 supported the MSS terminal: 20 • Should support the MPEG-4 AAC Profile Level 2 [47], [48], [49]; 21 • Should support the MPEG-4 HE AAC Profile, Level 2 [47], [48], [49]. 22 For continuous audio media the following MIME media types shall be used: 23 • For MPEG-4 AAC the MIME media type defined in clause 5.4 of [15]; 24 • For MPEG-4 HE AAC the MIME media type defined in clause 5.4 of [15]. 25 11.5 "Text in SMIL" 26 The MSS terminal should support media type "Text in SMIL", which is intended to 27 enable formatted text in a SMIL presentation. If text in SMIL is supported, the MSS 28 terminal: 29 • Shall support a SMIL plus XHTML profile contained in 3GPP2 SMIL language profile 30 [7] presentation and may ignore any unsupported XHTML modules in a SMIL 31 document; 32 • Shall support rendering of a SMIL presentation where text is referenced with the 33 SMIL 2.0 "text" element together with the SMIL 2.0 "src" attribute. 3G Multimedia Streaming Services 39
  40. 40. C.P0046-0 v1.0 1 11.6 "Timed Text" 2 The MSS terminal should support the media type "Timed Text". If timed text is 3 supported then the MSS terminal: 4 • Shall support 3GPP Timed Text [52]. 5 11.7 Other media 6 Other media types, as referenced in section 9.2, should be supported as described for 7 MMS [42]. 8 3G Multimedia Streaming Services 40
  41. 41. C.P0046-0 v1.0 1 12 Rate Adaptation of Streaming Media 2 3 12.1 Introduction 4 The goal of multimedia streaming rate adaptation is to achieve with the available 5 resources the highest possible quality of experience for the end-user while maintaining 6 interrupt-free playback of the media. This requires that the available network resources 7 are known or estimated and that transmission rates are adapted to the available 8 network link rates. With this information the server can better manage the network 9 buffers and thereby avoid packet losses by overflowing the buffer or underutilization the 10 network resources. The real-time properties of the transmitted media must be 11 considered so that media does not arrive too late to be useful. This will require that 12 media content rate is adapted to the transmission rate. 13 To avoid client buffer violation (underflow or overflow) while still allowing the server to 14 deliver as much data as possible into the client buffer, a functionality for client buffer 15 feedback is defined. This allows the server to closely monitor the buffering status on the 16 client side and thus to optimize the quality of service. The client can specify how much 17 buffer space the server can utilize and the desired target level of protection. When the 18 desired level of protection is achieved, the server may utilize any resources beyond what 19 is needed to maintain that protection level to increase the quality of the media. The 20 server can also utilize the buffer feedback information to decide if the media quality 21 needs to be lowered in order to avoid a buffer underflow and the resulting playback 22 interruption. 23 12.2 Rate Adaptation 24 The bit-rate adaptation for MSS is server centric in the meaning that transmission and 25 content rate are controlled by the server. The server uses RTCP and RTSP as the basic 26 information sources about the state of the client and network. This makes link-rate 27 adaptation for communicating with MSS client possible. 28 12.2.1 Link Characteristics 29 When connected on an assured network channel, a MSS client should inform the server 30 the quality of service parameters for the used wireless link. The known parameters 31 should be included in the RTSP "Mobile-Link-Char" header (section 8.1.1) in either the 32 RTSP SETUP or PLAY request. This enables the server to set some basic assumption 33 about the possible bit-rates and link response. If the client has initially reported these 34 parameters and they are changed during the session the client shall update these 35 parameters by including the "Mobile-Link-Char" header in a SET_PARAMETER or 36 OPTIONS request. 37 A MSS client should inform the server about initial bit-rate available over the link, if 38 known. This reporting shall be done using the RTSP "Bandwidth" header in either the 39 RTSP SETUP or PLAY request. The QoS negotiated guaranteed bit-rate is the best 40 estimate for the bandwidth value. 3G Multimedia Streaming Services 41

×