5 Service Requirements
22.2333GPPRelease 17Stage 1Transparent end-to-end packet-switched streaming serviceTS
5.1 General
Stage 2 implementations are shown in TS 26.233 [4] and stage 3 in TS 26.234 [5].
The PSS uses a Client / Server model. The client controls the server by sending requests to the server, which responds to these commands.
The PSS shall support downlink streaming.
The PSS shall maintain backwards compatibility (i.e. a Rel-4 client should be able to interoperate with a Rel-5 server and vice versa).
The PSS should consider interoperability with streaming elements (protocols, formats etc) already in use in other industries (e.g. the internet).
The PSS shall support access to live content in addition to pre-authored content. E.g. ability to listen to domestic radio station whilst abroad.
It shall be possible for an operator to configure a PSS television service so that the typical channel switching time, from the end user’s perspective, does not exceed 2 seconds. A PSS television service may include live content offering or video on-demand content offering.
PSS should allow support for time shifted live media consumption and bookmarks.
The PSS should be able to support mechanisms that allow for efficient usage of transport resources (e.g. by compression of data in PSS).
Such mechanisms should have no or minimal impacts on the core network and access networks.
Note: Such mechanisms may not be available for all streamed content.
The PSS shall:
use open standards where these are available for Streaming service requirements
use standard procedures and interfaces to avoid interoperability problems among client, server and encoder
– The live PSS shall define an interaction procedure to provide interoperability between server and encoder.
– The live PSS shall define an interaction procedure to provide interoperability between server and server.
use extensions to existing standards if needed
5.2 Media Types
The PSS should support multiple media types (see ref [5]) to enable rich, compelling multimedia services, for example:
Audio (including speech)
Video
Still image
Graphics (2D and 3D) including animation and Timed Graphics
Text
Plain text
Formatted text e.g. size, colour, font
Timed Text
Synthetic audio (e.g. MIDI)
Metadata e.g. indication that text has been supplied for the hard of hearing
The number of implementations of each media type shall be kept to a minimum, considering the implementation impact to the terminals, interoperability, contents mobility and backward compatibility.
The PSS shall share media codecs with other 3G multimedia services to allow easy interworking when needed.
The PSS should be able to call upon a font that is available across all terminals, either by use of an agreed default font in all terminals or by downloading the font prior to display. This requirement applies to formatted text only and is dependent upon the terminal capability.
5.3 Multimedia Composition and Interaction
The PSS shall enable the creation of multimedia services incorporating multiple media objects.
The PSS shall provide the capability to position and synchronise media objects on the client.
The PSS shall support flowing/scrolling of text or graphics in any direction.
The PSS shall provide the capability to specify the media attributes – text (e.g. colour, size, font, format) or graphics (e.g. size, colour) – in relation to the timebase of other media objects. E.g. in a karaoke application where the audio track and song lyrics are downloaded together, it should be possible to not only display the song lyrics in time to the music but to display the lyrics in different colours to indicate to the user when to sing them
The PSS shall provide the capability to update media objects dynamically. E.g. substitution of news report with a more up to date version on the content server.
The PSS should provide the capability to update the attributes of media objects dynamically. E.g. colour coded pre-paid indicator to indicate credit level.
The PSS should provide the capability to update the multimedia composition dynamically. E.g. the user interacts with the application and changes a scene.
The PSS shall provide the capability that allows the user to navigate through or interact with the multimedia service. E.g. Once a user has downloaded a “tour of London” application the user has the ability to navigate through London and see video clips or hear audio descriptions of points of interest in London.
The PSS shall provide the capability that allows clients of different capabilities to maximise the user experience. E.g. if a client did not support graphic animations it could render a single image.
The PSS shall support the transfer to the terminal of information on the accessed content in addition to the filename (e.g. song title, artist).
5.4 Transport
The PSS transport shall be provided by the PS Domain.
Quality of Service (e.g. time delay) requirements shall be in accordance with requirements in 22.105 (ref. 3)
The PSS should be able to work over different QoS bearers.
The PSS shall provide a mechanism whereby the client is sent a list of media encoding bit rates and the client determines which one to use based on the network service bearers offered and the user preferences.
The PSS client shall be capable of requesting an appropriate level of QoS for the session. The QoS supplied may be limited by the local operator’s access policy and/or network functionality.
The PSS should provide mechanisms for streaming servers and clients to adapt to the network conditions in order to achieve significant improvement in the quality of streaming, e.g. using information on end-to-end transport quality from the network.
The PSS should provide a reliable delivery mechanism that enables the user to receive the content without any errors due to the transport mechanism, i.e. a delivery mechanism without bit errors or packet loss. Such mechanism should support the following features :
– The rendering of video content without any transport degradation : the content is downloaded without any errors, it assures that the subscribers see the content that has been designed by the content creators.
Note: User expectation of live video is related to the fact that it is delivered without interruptions or long delays. As such, reliable delivery mechanism is not considered for rendering of live video content (under poor conditions it might even be difficult to achieve).- The rendering of the content should start before the transfer is complete.
– A broken session should be restarted efficiently without going back to the beginning : the PSS client is able to detect what content is missing and to ask the server to send this content.
Note: In addition to the regular PSS transport mechanism it is possible to use download transport mechanisms in the following way: Audiovisual data encapsulated in a file is transmitted from the server to the client. The user is able to play the content during the file download, giving a similar look and feel to the regular PSS transport mechanism.
5.5 Service Personalization
The PSS should support the ability for the client to have specific preferences described in the user profile. For example, if the user wants to watch a news show the preferred language (speech or subtitles) is specified in the user profile
The PSS shall support a basic set of terminal capabilities.
For the purpose of optimised presentation of the media streaming, PSS shall include capability exchange and negotiation mechanisms on server/client capabilities and user preferences at the session set up.
The client should be able to send user preferences to the server during a streaming session. E.g. the user may toggle between mono and stereo sound.
5.6 Service Management
User’s control of the service:
The client shall initiate the streaming session.
The user shall have the possibility to stop the streaming session after it has been invoked.
The user shall have the possibility to pause the streaming session after it has been invoked. E.g. if a user has activated the streaming session and then gets a phone call, he/she shall be able to decide whether or not he/she wants the streaming session to continue. After a pause the user can choose to resume the streaming session.
The PSS should be able to simultaneously handle the streaming session and conversational (circuit or packet?) services (e.g. voice and video telephony)
The user shall have the possibility of jumping to another point within the media clip (i.e., random access)
The user should be able to search through media content whilst viewing the content.
If the content is available under different formats corresponding to the terminal capabilities and user preferences, the client should have the opportunity to choose the format for which the content will be streamed. Assuming the user has already set the user profile and the client is aware of this.
Service Provider’s management of the service:
The end user should be notified if the PSS is unavailable.
The Streaming session should be gracefully disconnected if the client is not capable of handling the streamed content.
The service provider should have the means by which a streaming session can be gracefully terminated (e.g. in a prepay scenario when the user’s account has run out of credit)
The PSS should be able to support real-time quality of service metrics data from the UE.