Content for TS 26.233 Word version: 15.0.0

6.1 Session protocols and data transport 6.2 Codecs 6.3 Adaptation of continuous media (Releases 6, 9 and 10) 8.1 Interworking with WAP 8.2 Interworking with MMS 8.3 Interworking with charging/billing services

6 Functional components of a PSS terminal p. 15

This clause lists the 3G packet-switched streaming service components, which belong to the terminal. Note that not all of the components are mandatory. The functional behaviour of the different components is discussed in the following.

6.1 Session protocols and data transport p. 15

Protocols are needed for PSS session establishment, session set-up, capability exchange, session control, scene description, and data transport of streaming media and other data. The PSS protocols to be used are specified in [1].

Note that for the simple streaming case defined in clause 4.2.1, no specific capability exchange protocol in addition to the session description mechanism is required. In Release 6, capability exchange can easily be separated to streaming, progressive download and scene description (SMIL) specific capabilities.

The normative part of device capability and user preference profile exchange mechanism is defined in clause 5.2 and Annex F of [1]. An informative part is included in Annex A.4 of [1].

In Release 6 the RTP transport defined in clause 6.2 of [1] supports a payload format for RTP retransmission and streaming of timed text content.

6.2 Codecs p. 15

Decoders are needed for speech, natural and synthetic audio, video, still images, bitmap graphics, vector graphics and static and timed text [8]. The codecs to be used are specified in [1].

6.3 Adaptation of continuous media (Releases 6, 9 and 10) |R6| p. 15

PSS Release 6 includes a number of protocols and functionalities that can be utilized to allow the PSS session to adapt transmission and content rates to the available network resources. The goal of this is of course to achieve highest possible quality of experience for the end-user with the available resources, while maintaining interrupt-free playback of the media. This requires that the available network resources are estimated and that transmission rates are adapted to the available network link rates. This can prevent overflowing network buffers and thereby avoid packet losses. The real-time properties of the transmitted media must be considered so that media does not arrive too late to be useful. This will require that media content rate is adapted to the transmission rate.

To avoid buffer overflows, resulting in that the client must discard useful data, while still allowing the server to deliver as much data as possible into the client buffer, a functionality for client buffer feedback is defined within clauses 5.3.2, 5.3.3 and 6.2 of [1]. This allows the server to closely monitor the buffering situation on the client side and to do what it is capable in order to avoid client buffer underflow.

The client specifies how much buffer space the server can utilise and the desired target level of protection with aid of new RTSP signalling defined in clause 5.3.2.2 . When the desired level of protection is achieved, the server may utilise any resources beyond what is needed to maintain that protection level to increase the quality of the media. The server can also utilise the buffer feedback information to decide if the media quality needs to be lowered in order to avoid a buffer underflow and the resulting play-back interruption.

PSS Release-9 Adaptive HTTP Streaming includes bit-rate adaptation driven by the client and based on available alternative Representations of media content.

PSS Release-10 onwards 3GP-DASH enables delivering continuous media content over Hypertext Transfer Protocol (HTTP) in a sense that all resources that compose the service are accessible through HTTP-URLs and the HTTP/1.1 protocol as specified in RFC 2616 [9]. 3GP-DASH includes bit-rate adaptation driven by the client and based on available alternative Representations of media content.

7 File format p. 16

The file format is an important element of the content manipulation chain. Conceptually, there is a difference between the coding format and the file format. The coding format is related to the action of a specific coding algorithm that codes the content information into a codestream. The file format is instead a way of organising the prestored codestream in such way that it can be accessed for local decoding and playback, or transferred as a file on different media, or streamed over different transport. Some file formats are optimised for one or more of these functions, others aim instead at achieving a higher flexibility.

When a single media type is involved, the coding and the file format are often considered, and referred to, as a single entity. When multimedia information is involved, instead, it is appropriate to maintain, at least conceptually, the distinction between these two instances. The file format can play an important role in facilitating the organisation and the access to the coded information, independently of the specific coding formats.

The basic profile, as defined in clause 5.4.3 of the 3GPP File Format specification [7], specifies how the 3GPP MMS [3] shall utilise a file format. The format establishes a standardised content transport for audio-visual content between MMS elements. It also allows the delivery of the content to the recipient both as a file download or through streaming. A priori knowledge of the delivery mechanism is not needed when the message is created. See also clause 8.2.

In addition to basic profile, [7] defines several file profiles:

The general profile is a superset of all other profiles. It provides a generic umbrella, which covers all 3GP files.
The streaming-server profile is used in PSS and defines the conformance level of a server-side 3GP file, which contains specific information related to PSS streaming as well as streaming-server extensions as defined in clause 7 of [7].
The progressive-download profile defines the conformance level of a progressively downloadable 3GP file within the PSS context.
The extended-presentation profile enables a 3GP file to carry any kind of multimedia presentation composed of tracks, media files and a scene description.
The media stream recording profile is used to label 3GP files that contain recordings of multimedia streams e.g. from a PSS session.
The file-delivery server profile guarantees interoperability between content creation tools and file delivery servers.
The adaptive-streaming profile is used to label 3GP files that are primarily suitable for adaptive file-based streaming.
Media Segment Profile is used to label segments for adaptive file-based streaming.

[7] also defines the file format-level registration mechanism of the non-ISO based codecs in clause 6.

As part of the DRM commitment, clause 10 of [7] defines how encrypted content is to be stored in a 3GP file.

8 Interworking with other core network services p. 16

8.1 Interworking with WAP p. 16

Not required. As shown in Figure 1 the service may be initiated by an URI or a SDP file received via WAP.

8.2 Interworking with MMS p. 16

TS 23.140 defines a new optional feature for the MMS, which enables streaming of the MMS messages by the message recipient. The MMS streaming option uses the codecs and protocols in accordance with TS 26.234.

Additionally, [4] mandates the use of the interchange format recommendation specified in TS 26.244, clause 5.4.3 for MMS purposes.

8.3 Interworking with charging/billing services p. 17

Interworking with charging/billing services can be part of a future release of PSS.

9 Security p. 17

Security has been greatly enhanced in Release 6 of PSS. Streamed and downloaded content may be encrypted and protected for integrity while in transport. Release 6 supports transport-level integrity protection and content-level encryption, which may be applied at content creation time, making sure that content is protected for confidentiality at all times. A high level of security for the purpose of protecting commercial content can be achieved by using a Digital Rights Management framework. The component-based design provides maximum flexibility for building security features into services.

10 Digital Rights Management (Release 6) p. 17

The Release 6 of PSS adds support for streaming and downloading of encrypted content, as well as co-operation with key management systems governing access to cryptographic keys required for playback. Encryption is supported in all file format profiles and additional meta-information is used to carry key management system specific parameters. Streaming supports protected payloads and SDP attributes for signalling DRM information. 3GPP has worked together with OMA for supporting the OMA DRM Release 2.0 [10] in Release 6 of PSS and file format, while keeping the formats open for using other key management systems in a later phase. The OMA DRM Release 2.0 is an open standard, which is enjoying a substantial commitment from the mobile and content industries and 3GPP Release 6 is building on this momentum.

[not reproduced yet]

Figure 4: OMA DRM system architecture

The OMA DRM Release 2.0 is based on Public Key Infrastructure (PKI) and strong cryptographic algorithms to provide a high level of security for commercial content. It is an end-to-end system architecture with roles and trust relationships, providing flexible and robust components to be integrated to services. Main features include content superdistribution, preview, subscription, export and user domains support, which enable many different business models and good user experience.

OMA DRM 2.0 system consists of a Rights Issuer, Content Issuer and a DRM Agent (typically one per device). A Rights Issuer is responsible for setting usage permissions and authorising devices with keys, Content Issuer is typically a download or streaming service, and DRM Agent is responsible for enforcing the set of Rights expressed for a piece of content. When combined with PSS Release 6, content in 3GP files is pre-encrypted at a production facility, delivered through a download or streaming service to a device, and during delivery or playback, the OMA DRM Agent in the device handles authorisation by acquiring Rights from a Rights Issuer.