The simple streaming service includes a basic set of streaming control protocols, transport protocols, media codecs and scene description protocol. In this basic case defined for the first time in the Release 4 version of this specification, there is neither explicit capability exchange, nor any encryption or digital rights management. A mobile user gets a URI to specific content that suits his or her terminal. This URI may come from a WWW-browser, a WAP-browser, or typed in by hand. This URI specifies a streaming server and the address of the content on that server. A PSS application that establishes the multimedia session shall understand a Session Description Protocol (SDP) file. Sessions containing only non-streamable content such as a SMIL file, still images and text to form a time-synchronised presentation don't require use of an SDP file in session establishment. Instead HTTP protocol shall be used for receiving the presentation files. PSS SMIL [9] sessions can also include URIs to streamable content, requiring parsing a SDP file and/or RTSP signalling. The SDP file may be obtained in a number of ways. It may be provided in a link inside the HTML page that the user downloads, via an embed tag. It may also be directly obtained by typing it as a URI. It may also be obtained through RTSP signalling via the DESCRIBE method. In case of streaming delivery option of MMS service, the SDP file is obtained via the MMS user agent that receives a modified MMS message from the MMS relay or server. The SDP file contains the description of the session (session name, author,…), the type of media to be presented, and the bitrate of the media. The session establishment is the process in which the browser or the mobile user invokes a streaming client to set up the session against the server. The UE is expected to have an active PDP context in accordance with [5] or other type of radio bearer that enables IP packet transmission at the start of session establishment signalling. The client may be able to ask for more information about the content. The client shall initiate the provisioning of a bearer with appropriate QoS for the streaming media. The set up of the streaming service is done by sending an RTSP SETUP message for each media stream chosen by the client. This returns the UDP and/or TCP port etc. to be used for the respective media stream. The client sends a RTSP PLAY message to the server that starts to send one or more streams over the IP network. This case is illustrated below in figure 1a. Figure 1b illustrates the service use case when the SDP file is obtained via MMS. Figure 1a : Schematic view of a basic streaming session

The streaming service defined in Release 5 of PSS supports all features defined for the Release 4 streaming case in a fully backwards compatible manner, and may additionally include more advanced service features, such as capability exchange.

Release 6 of PSS, while remaining essentially backwards compatible to content servers using earlier PSS releases, completes the PSS feature set to a comprehensive content delivery framework. The Release 6 framework updates the list of recommended media types and codecs to achieve higher service quality within the 3GPP environments. It consists of already defined download and streaming framework appended with alternative of progressive downloading, in an end-to-end delivery context which enables optional use of strong content encryption and integrity protection capabilities, as well as interoperability with cryptographic key management systems. A standardised container file exchange between PSS providers is possible as a specific server file format. PSS allows selection of streaming session alternatives (alternative SDP) and dynamic, link-aware bandwidth adaptation to adapt the session bandwidth to the potentially time-varying cellular network bandwidth, especially useful in cellular networks where QoS-enabled bearers are not available. There is also a defined mechanism to gather streaming session Quality of Experience metrics at the PSS service provider's premises. The capability exchange mechanisms of Release 5 have been strengthened and upgraded to enable service filtering better for both streaming and static media contents. Progressive Downloading Progressive downloading is the ability to start media playback while the file or media data is still being "downloaded". The function works by using a HTTP download over TCP/IP connection, and this service option is available for specific media types that have a container format suitable for progressive download - audio, video, timed text [8] that will use progressive download profile of [7] and vector graphics. A progressive-download session is established with one or more HTTP GET requests issued by the client to the server. The media resource (e.g. a progressively downloadable 3GP file) is pointed by a valid HTTP URL. Figure 1c illustrates the data flow and signalling in progressive downloading session.

The Rel-7 of PSS improves user experience introducing procedures to allow faster start up and switching of content for both on-demand and live applications by reducing the client/server interactions to a minimum. Various general RTSP extensions are required for support of fast content start-up and switching. PSS clients are enabled to reuse the existing RTSP control session and RTP resources while switching to new content. Release 7 also sees the introduction of DIMS [12]. Dynamic and Interactive Multimedia Scenes (DIMS) is a dynamic, interactive, scene-based media system which enables display and interactive control of multimedia data such as audio, video, graphics, images and text. It ranges from a movie enriched with vector graphic overlays and interactivity (possibly enhanced with closed captions), to complex multi-step services with fluid interaction/interactivity and different media types at each step.

The 3GPP IP Multimedia Subsystem (IMS) enables the deployment of IP multimedia applications. PSS and MBMS User Services are IP multimedia services but they were specified before IMS. IMS brings enablers and features to operators and subscribers that can enhance the experience of PSS and MBMS User Services. IMS based PSS architecture and protocols are specified in [11]. It describes the use of the IMS to initiate and control PSS and enables deployment of PSS as IMS services. This specification allows convergence with IMS based IPTV systems as specified by Open IPTV Forum and ETSI TISPAN. Time shifting functionality is designed to enhance the access to live streaming sessions. For this reason, the PSS server maintains a time-shift buffer for each live feed. The server side timeshift buffer allows the PSS client to pause live sessions and even navigate (rewind, fast forward) in the offered time-shift buffer range. A timeshift supporting PSS client, which is connected to a timeshift supporting PSS server is able to perform some or all of the following operations on timeshifted streaming sessions:

• Pause and resume the playout at a later point in time
• Start playout from (or seek to) a position in the stream that corresponds to a past time instant in the live streaming session
• Perform operations such as Fast and Slow Forward or Rewind (i.e. Trick Mode).

From Rel-8 onward, when EPC/LTE is used then Secondary PDP Context Activation/Deactivation procedure is replaced by Dedicated Bearer establishment/Deactivation procedure [14].

3GPP Adaptive HTTP-Streaming provides a streaming service. It enables delivering content from standard HTTP servers to an HTTP-Streaming client and enables caching content by standard HTTP caches. Figure 1d shows the architecture for Adaptive HTTP streaming. The HTTP-Streaming Client has access to a Media Presentation Description (MPD). An MPD provides sufficient information for the HTTP-Streaming Client to provide a streaming service to the user by sequentially downloading media data from an HTTP server and rendering the included media appropriately.

To initiate the streaming service to the user, the HTTP Streaming Client establishes a Media Presentation by downloading the relevant metadata and subsequently the media data. The media presentation, protocols , the use of 3GP file format as media container format, the codecs, guidelines on the client behaviour and security related aspects are specified in [1]. The HTTP streaming file format extensions are define in [7]. Timed graphics is a media type that enables advanced subtitle like services in parallel to video. It enables high quality text and graphics at a low cost. Timed Graphics is specified in [13]. In low bit-rate video, the areas which are often perceived as the worst are subtitles and graphics or tables (encoded as part of the video). Encoding subtitles as timed text instead of as part of the video can increase the perceived quality of the video substantially. Timed Text [4] solves the problem of subtitles and when used gives a perceptual quality much higher that encoding the text as part of the video stream. DIMS [5] allows the placement of vector graphics on top of video - but from an application perspective and requires DIMS to control the media. Timed Graphics works together with these abovementioned specifications, or independently, to enable better "video" quality.

3GPP Dynamic Adaptive Streaming over HTTP (3GP-DASH as specified in TS 26.247) defines a streaming format form 3GPP Release 10 onwards. It enables delivering content from PSS Server including HTTP server to a PSS Client including a 3GP-DASH client and enables caching content by standard HTTP caches. Figure 1e shows the architecture for Adaptive HTTP streaming. The PSS Client has access to a Media Presentation Description (MPD). An MPD provides sufficient information for the 3GP-DASH Client to provide a streaming service to the user by sequentially downloading media data from an HTTP server and rendering the included media appropriately.

To initiate the streaming service to the user, the 3GP-DASH Client establishes a Media Presentation by downloading the relevant metadata and subsequently the media data. The media presentation, protocols , the use of 3GP file format as media container format, the codecs, guidelines on the client behaviour and security related aspects are specified in [15]. The 3GP-DASH file format extensions are defined in [15].

SAND support in 3GP-DASH is specified in TS 26.247. In the PSS architecture for 3GP-DASH in Figure 1e, SAND functionality can be supported by hosting the DANE capabilities described in [17] in the PSS server, and by hosting the SAND-capable DASH client capabilities described in [17] in the PSS client. This is illustrated in Figure 1f. As such the relevant SAND messages, including PER and status messages, can be exchanged between the PSS server and PSS client. Further architectural considerations for SAND are presented in clause 4 of TR 26.957. Despite being part of the PSS Server logically, the SAND Functionality of the PSS Server could be co-located with other functions that are separate from the MPD Delivery Function and Segment Delivery Function. One particular realization of such a split is when the SAND Functionality is located near to the network edge, in order to provide segment delivery assistance. Here the SAND messages are out-of-band of the media flow, i.e. carried in signalling flows that are separate from the MPD and Media Segment flows.