8 Streaming session and media control

26.2373GPPIP Multimedia Subsystem (IMS) based Packet Switch Streaming (PSS) and Multimedia Broadcast/Multicast Service (MBMS) User ServiceProtocolsRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

8.1 General

This clause specifies the procedures and protocols used for the IMS based initiation and control of streaming sessions on PSS or MBMS User Service.

The client shall use SIP to initiate and control PSS and MBMS streaming sessions. Once a PSS streaming session is established, the client shall use RTSP protocols to perform media control.

8.2 PSS Streaming

8.2.1 PSS Media codecs and formats

PSS Media codecs and formats defined in 3GPP TS 26.234 [8] are applicable to the present document for IMS initiated and controlled PSS services.

8.2.2 Procedure for providing missing parameters

8.2.2.1 Procedures at the UE

If the UE does not have all the information it needs to form an SDP offer, the UE shall send a SIP OPTIONS message:

– • The "Request-URI" is related to the PSS session that the user wants to activate. The Request-URI shall be composed of a user and domain part as defined as follows:

– The user part contains the content identifier, retrieved from user service description information from SSF.

– For COD service, content identifier is constructed by "PSS_COD_<content-id>", wherein content-id shall be globalContentID defined in [27].

– For Live service, content identifier shall be globalServiceID defined in [27] or serviceId defined in [11].

– The domain part is the Service Provider domain name, obtained from SSF.

– • The TO header shall contain the same URI as in the "Request-URI" parameter.

– The other headers shall be set according to TS 24.229 [7].

Upon reception of the 200 OK including SDP, the UE may initiate PSS session as described in clause 8.2.3.

8.2.2.2 Procedures at the SCF

When receiving the SIP OPTIONS message, the SCF shall select the appropriate PSS Adapter and forward the SIP request to the appropriate PSS Adapter by changing the "Request-URI" accordingly.

The SCF shall not change the user-part of the TO header in order to keep the content-id in the OPTIONS request.

8.2.2.3 Procedures at the PSS Adapter

When receiving SIP OPTIONS request, the PSS Adapter shall examine the content identifier present in the user-part of the TO header.

If the PSS adapter does not have the user service description information, it shall send an RTSP DESCRIBE message to the PSS server to retrieve the user service description information

Then, the PSS Adapter shall answer with the user service description information of the content delivery channel in SDP as requested by the request URI.

8.2.3 PSS Streaming Session initiation

8.2.3.1 General description

Figure 7: IMS based PSS initiation

NOTE 1: This sequence is simplified and does not e.g. show session progress messages and the ACK message from the UE in response to the reception of 200 OK.

NOTE 2: SIP messages between PSS adapter and SCF go through the IM CN Subsystem even if not indicated on the sequences.

8.2.3.2 Procedures at the UE

The UE shall generate an initial INVITE request according to TS 24.229 [7] with the following additions:

– The Request-URI is related to the PSS session that the user wants to activate.

– For an On Demand service, it shall be composed of a user part and a domain part, as follows:

– A user part containing the content identifier in a free string format.

– Content identifier is constructed by "PSS_COD_<content-id>", wherein content-id shall be globalContentID defined in [27].

– A domain part containing the content provider domain name, obtained from the SSF.

– For Live content, it shall contain the PSI (Public Service Identity) of the "Live stream@<domain name>", wherein the domain name is obtained from SSF".

– The To header shall contain the same URI as in the Request-URI.

– The Recv-Info header shall be empty [42].

The other headers shall be set according to TS 24.229 [7].

An SDP Offer shall be included in the initial INVITE request, in accordance with media capabilities and policies available for the PSS session and with the parameters received from the SSF during service selection procedure.

The SDP offer shall contain a media description for the RTSP content control channel and one for the content delivery channel. The RTSP content control media description shall be carried by TCP.

The SDP parameters for the RTSP content control channel shall be set as follows:

– a ‘m’ line for an RTSP stream of format: m=<media> <port> <transport> <fmt>

– The media field shall have a value of "application".

– The port field shall be set to a value of 9, which is the discard port. See RFC 4145 [13] and RFC 4572 [14].

– The transport field shall be set to TCP or TCP/TLS. The former is used when RTSP runs directly on top of TCP and the latter is used when RTSP runs on top of TLS, which in turn runs on top of TCP.

– The <fmt> parameter shall be included and shall be set to 3gpp_rtsp.

NOTE: the 3gpp_rtsp application format should have a new MIME subtype registered in IANA.

– An "a=setup" attribute shall be present and set to "active" indicating that the UE will initiate an outgoing TCP connection to the PSS Adapter [7] and [13].

– An "a= connection" attribute shall be present and set as "new" " indicating that the UE will establish a new outgoing TCP connection towards the PSS Adapter [7] and [13].

– A "c" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and IP address of the flow of the related RTSP content control (ex. c=IN IP4 <IP_ADDRESS>).

– For Live service, an "a=PSS_Live_service: ServiceID" line shall be include to indicate the PSS live service which the UE intends to initiate. The ServiceID shall be globalServiceID defined in [27] or serviceId defined in [11], which is retrieved from service selection information.

Example of RTSP ‘m’ line offer from the UE:

m=application 9 TCP 3gpp_rtsp

c=IN IP4 192.0.2.2

a=setup:active

a=connection:new

For each media stream controlled by the RTSP content control channel, the SDP offer shall include a "receiver only" content delivery channel media description set as defined in 3GPP TS 26.234 [8], clause 5.3.3:

– the "m=" line indicates the type of the media, the transport protocol and the port of the related content delivery channel. It may also include a fmt parameter which shall indicate the format given by the SSF or by executing the procedure for providing missing parameters before session initiation described in clauses 8.2.2, a subset of them or the format offered by the UE if none is given by the SSF;

– the "c=" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and unicast address of the flow of the related content delivery channel;
(ex. c=IN IP4 <IP_ADDRESS>)

– optionally a "b=" line may contain the proposed bandwidth. If the user has fetched the bandwidth required for this particular content delivery channel during service selection retrieval, the bandwidth attribute at media level shall be set to this value. Otherwise, this attribute shall be set to a pre-configured value;
(ex. b=AS:15000)

– A "a=" line with a "recvonly".

The UE should receive a SIP 200 OK back containing the answer SDP.

8.2.3.3 Procedures at the IM CN Subsystem

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.2.3.4 Procedures at the SCF

Upon receipt of SIP INVITE request, the SCF shall examine the Request-URI and SDP parameters to determine that it is a PSS session initiation request for Live Streaming or Content-On-Demand. According to the user subscription information, the SCF shall check the service rights of the requested PSS service.

If the Request-URI contains a content identifier in the user part and a domain name in the domain part, the SCF determines that the PSS streaming session is initiated for On Demand content. In this case, the SCF shall select a suitable PSS adapter and forwards the SIP INVITE to the selected PSS adapter by changing the Request-URI accordingly. The SCF shall not change the user part of the To header in order to keep the content identifier in the INVITE request.

When receiving a 301 or 302 response from the PSS adapter, the SCF shall not forward this message to the UE. It may check if the PSS adapter indicated in the Contact header belong to allowed destination. If allowed, the SCF shall use one of the PSS adapter URI indicated in the Contact header of this response and use it as a destination for the redirected INVITE.

If the request-URI contains the PSI " Live Stream", the SCF determines that the PSS streaming session is initiated for Live content. In this case, the SCF shall select a suitable PSS adapter and forwards the SIP INVITE to the selected PSS adapter. The SCF shall include the list of authorized Live content channels for the user in the SIP INVITE transmitted to the PSS adapter by including the package identifiers containing to the list of authorized Live content channels for the session and optionally transmitting the list of authorized RTSP URIs.

The Recv-Info header shall indicate the supported Info Package ("Content-Reporting") for reception and processing by the SCF [42]. The "Content-Reporting" info package is defined in annex Q of [44].

Based on the Request-URI and SDP parameters, the SCF selects a suitable PSS Adapter and forwards the SIP INVITE to the selected PSS Adapter.

Once receiving a SIP 200 OK response from PSS Adapter, the SCF shall check the Recv-Info header and remove it from the response. Following that the SCF shall forward the revised response to UE.

8.2.3.5 Procedures at the PSS Adapter

The PSS Adapter shall be statefully aware of any sessions between the PSS Adapter and a UE, and the PSS Adapter and the PSS Server related to the same streaming session . This means that the RTSP session between the PSS Adapter and the PSS Server and the SIP & RTSP sessions between the PSS Adapter and the UE are associated at the PSS Adapter in order to keep session structure and alignment. This includes, but is not limited to, RTSP parameters such as sessionId, IP version, CSeq, etc.

The PSS Adapter shall support the following RTSP methods for PSS Server session establishment and teardown control:

– DESCRIBE (PSS Adapter to PSS Server).

– SETUP (PSS Adapter to PSS Server).

– TEARDOWN (PSS Adapter to PSS Server).

The PSS Adapter should support the "3gpp-pipelined" feature so as to be able to pipeline SETUP messages.

Upon receipt of a SIP INVITE message, the PSS Adapter performs the following actions:

– It shall resolve the RTSP URI based on the R-URI, the SDP parameters and the selected PSS Server.

– It may send a DESCRIBE message to the PSS Server to fetch the SDP file.

– It shall construct and send the RTSP SETUP message(s) to setup the relevant media streams.

– Return the answer SDP to the UE in the SIP 200 OK.

The PSS Adapter shall construct the RTSP SETUP message according to the SIP Invite as follows:

– The Request-Line shall be present of format: Request-Line = Method SP Request-URI SP RTSP-Version CRLF:

– Method field is set to SETUP;

– RTSP-Version field to be set of RTSP/1.0.

– The CSeq header field is set to a value allocated by PSS Adapter according to RFC 2326 [25]

– The transport header field:

– the protocol and profile sub-fields together are set to a value of the protocol sub-field of the corresponding "m=" line in the SDP offer,

– the unicast | multicast parameter is set to unicast.

– The destination parameter is set to a value of the "c=" line of the corresponding media delivery channel in the SDP offer,

– The RTP port value of client_port parameter is set to the value of the port sub-field of the corresponding "m=" line in the SDP offer, and the RTCP port value of client_port parameter is set to a value of the RTP port value plus 1.

An example of the RTSP SETUP message is:

PSS Adapter->PSS Server: SETUP rtsp://media.example.com/movie001/audiotrack RTSP/1.0

CSeq: 1

Transport: RTP/AVP/UDP; unicast; destination=<IP ADDRESS>; client_port=3400-3401

The PSS Adapter may send multiple RTSP SETUP messages if multiple media delivery channels are carried within the SDP offer. In this case, the pipeline of multiple RTSP SETUP messages may be supported.

When receiving a RTSP 200 OK response from the PSS Server, the PSS Adapter parses the response, constructs a SIP 200 OK response with the final SDP, and sends the SIP 200 OK response to the SCF. The final SDP shall describe the RTSP session established by the PSS Adapter and the TCP connection to be established by the UE.

The PSS Adapter shall construct the SIP 200 OK message according to RTSP 200 OK as follows:

– The Recv-Info header shall be set to "ContentReportConfig" [42].

– an ‘m’ line for an RTSP stream of format: m=<media> <port> <transport> <fmt>

– The media field shall have a value of "application".

– The port field shall be set to the value allocated by PSS Adapter for the UE to establish RTSP session, such as 554.

– The transport field shall be set to TCP or TCP/TLS. The former is used when RTSP runs directly on top of TCP and the latter is used when RTSP runs on top of TLS, which in turn runs on top of TCP.

– a "c" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and IP address of PSS Adapter for the flow of the related RTSP content control (e.g. c=IN IP4 <IP_ADDRESS>).

– The "setup" attribute is set to ‘passive’ indicating that connection shall be initiated by the other endpoint (UE).

– An "a= connection" attribute shall be present and set as "new" indicating that the UE will establish a new outgoing TCP connection towards the PSS Adapter [7][13].

– An "a=control" attribute shall be present in the format of an absolute URI to be used for the UE in the subsequent RTSP requests.

– One or more a=fmtp lines representing RTSP specific attributes set as follows:

– a "fmtp:3gpp_rtsp h-session" attribute representing the session identifier for the RTSP session to be established with the UE.

The PSS Adapter may include "fmtp: 3gpp_rtsp h-offset" attribute that indicates where the playback is to start from.

Example of RTSP ‘m’ line answer from the PSS Adapter:

m=application 554 TCP 3gpp_rtsp

c=IN IP4 192.0.2.1

a=setup:passive

a=connection:new

a=control:rtsp://example.com/channel/content1.sdp

a=fmtp 3gpp_rtsp h-session=12345

a=fmtp 3gpp_rtsp h-offset=30

For each media stream controlled by the RTSP content control channel, the SDP answer shall include a content delivery channel media description set as follows:

– the "m=" line indicates the type of the media, the transport protocol and the port of the related content delivery channel.

– The port value shall be set to the RTP port value retrieved from the server_port parameter in the RTSP 200 OK message.

– If an fmt parameter is in the SDP offer it shall be completed with the supported format by the PSS Server;

– the "c=" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and the unicast address of the PSS Server for the flow related to the content delivery channel,
(ex. c=IN IP4 <IP_ADDRESS>);

– the "b=" line shall contain the proposed bandwidth. Since the PSS media stream is unidirectional the bandwidth shall be set to 0, except for the case that the transport is RTP and RTCP is allowed.
(ex. b=AS:0);

– an "a=" line with a value of "sendonly". (ex. a=sendonly).

8.2.4 PSS Streaming Playback Control

8.2.4.1 General Description

Figure 8: Initial Payback

8.2.4.2 Procedures at the UE

The UE shall support the following RTSP methods for RTSP playback control:

– PLAY (UE to PSS Adapter).

– PAUSE (UE to PSS Adapter).

– GET_PARAMETER (UE to PSS Adapter).

– SET_PARAMETER (UE to PSS Adapter).

– OPTIONS (UE to PSS Adapter).

When receiving any SIP response, the UE shall examine the media parameters in the received SDP: the UE shall immediately setup the TCP connection carrying RTSP. The UE shall fetch the RTSP session ID from the SDP answer contained in the SIP response. This RTSP session ID shall be used for RTSP media control messages.

After SIP session establishment, the UE can exchange RTSP messages to start to receive media streams. The UE shall send an RTSP PLAY message to the PSS adapter according to 3GPP TS 26.234 [8].

– The RTSP URL shall be set to the value retrieved from the SDP "a=control" attribute in the case of an absolute URI. If the value of "a=control" is a relative URI that is in the form of a media path, then the RTSP absolute URL is constructed by the UE using the SDP IP address (from c-line) and port (from m-line) as the base followed by "a=control" value for the media path.

– The RTSP session ID in the h-session received in the SDP shall be used in RTSP media control messages.

– The version attribute shall be present in the SDP and its value shall be 1.0 in this version of the specification.

– If the h-offset attribute is present in the SDP, the Range parameter in the first RTSP PLAY message may be set to its value. E.g. Range: npt=<OFFSET>- (with OFFSET being the value of the h-offset attribute).

8.2.4.3 Procedures at the PSS Adapter

If the PSS Adapter supports the proxying of RTSP towards the PSS Server then the following methods shall be supported:

– PLAY;

– PAUSE;

– GET_PARAMETER;

– SET_PARAMETER;

– OPTIONS.

Upon receipt of a RTSP message from an UE, the PSS Adapter shall match the RTSP session with the RTSP sessions once established with PSS Server according to the Session ID carried in the received RTSP message. If there is a session match, PSS Adapter shall send the RTSP message to PSS Server on the matched RTSP session. If no session matches, PSS Adapter shall response with a RTSP error code 454 (Session Not Found).

When receiving a RTSP response message from a PSS Server, the PSS Adapter shall match the RTSP session with the RTSP sessions once established with UEs according to the Session ID carried in the received RTSP response message, and send the RTSP response message to UE on the matched RTSP session.

The PSS Adapter should send a SIP INFO message to the SCF indicating that playback has started. This SIP INFO message should be equal to the SIP INFO messages for PSS content switching defined in clause 8.2.5.

8.2.4.4 Procedures at the PSS Server

The procedures at the PSS Server shall conform to those defined in 3GPP TS 26.234 [8].

8.2.5 PSS content switching

8.2.5.1 PSS Streaming session modification

8.2.5.1.1 General description

NOTE 1: The specification assumes the UE will trigger a Re-INVITE procedure to change the QoS to fit the new channel requirements. It will be considered whether the network can trigger the QoS change without the UE taking management.

This procedure presents the generic PSS streaming session modification procedure. It can be referred in some cases for PSS Content Switching, when there is a change of media components and/or bandwidth.

Figure 9: UE-initiated PSS session modification

NOTE 2: Like in other call-flows of the specification, the figure does not show that messages exchanged between the PSS adapter and the SCF are routed through the IM CN subsystem.

1) The UE sends the Re-INVITE request containing the SDP offer to the IM CN Subsystem to establish the content delivery channel. The IM CN Subsystem may require the PCRF to reserve additional resources for RTP streams according to the SDP in the Re-INVITE. The IM CN subsystem may also issue the PCRF to release resources for RTP streams.

2) The IM CN Subsystem forwards the Re-INVITE request to the SCF.

3) The SCF sends the Re-INVITE to the PSS adapter via the IM CN Subsystem.

4) The PSS adapter sends the according number of RTSP SETUP to the PSS server, if additional media components are described in the SDP.

5) The PSS server responds with RTSP 200 OK to the PSS adapter (only, if the PSS adapter has send SETUP messages to the PSS Server).

6) The PSS adapter sends one SIP 200 OK to the SCF with the SDP answer containing the new media descriptions of RTP streams to be used.

7) The SCF sends the SIP 200 OK to the IM CN Subsystem. The IM CN subsystem interacts with the PCRF to commit the reservation, and then forwards the SIP 200 OK to the UE.

8) The UE sends the SIP ACK to the IM CN subsystem, which forwards to the SCF. The SCF forwards the SIP ACK to the PSS adapter.

8.2.5.1.2 Procedures at the UE

To modify the session, the UE shall send a Re-INVITE or an UPDATE request as specified in TS 24.229 [7] for an originating UE.

The UE shall not modify RTSP channel m-line description in the SDP if the media delivery streams controlled by RTSP are not removed (port not set to 0 in the m lines) in the SDP.

8.2.5.1.3 Procedures at the IM CN subsystem

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.2.5.1.4 Procedures at the SCF

Upon receipt of a Re-INVITE request or an UPDATE request, the SCF shall follow the procedures defined in TS 24.229 [7] concerning the AS acting as a proxy or a B2BUA.

When receiving an SDP offer, the SCF may modify the SDP offer in accordance to the user subscription. If the SCF finds a media line not compatible with the user’s subscription, it shall set the port of this media line to 0. If none of the media lines are acceptable, it shall reply with a 403 error response.

Then the SCF forwards the Re-INVITE message to the PSS adapter.

8.2.5.1.5 Procedures at the PSS adapter

Upon receipt of a Re-INVITE request or an UPDATE request, the PSS adapter shall modify the session as specified in TS 24.229 [7] if the request is acceptable to the PSS adapter in accordance with the user subscription.

The PSS adapter sets up new media components, if the SDP file contains additional components.

8.2.5.1.6 Procedures at the PSS server

Upon receipt of an RTSP setup, the PSS server executes the requested method and responds with an RTSP status code to the PSS adapter.

8.2.5.2 PSS Content switching with available SDP, no change of media component and bandwidth

8.2.5.2.1 General description

The UE has retrieved the SDP prior to the content switching. The procedure is as described as in 3GPP TS 26.234 [8], with the server role being played by the PSS adapter.

Figure 10: IMS PSS Content switching

1) The UE sends a PLAY request with the aggregated control URI of the new content to the PSS adapter. The PSS client adds the media control URIs of the new streams in the "Switch-Stream" header field to the RTSP PLAY method request as defined 3GPP TS 26.234 [8] clause 5.5.4.3.

2) The PSS Adapter sends the RTSP PLAY message to the PSS Server.

3) The PSS Server responses a RTSP 200 OK message to the PSS Adapter.

4) The PSS Adapter sends the RTSP 200 OK message to UE.

5) The PSS server delivers the switched content streams to the UE.

6) The PSS Adapter should send a SIP INFO message including the Info Package (Content Reporting) to the SCF with content switching information. See clause 8.2.5.2.5.

The SCF may utilize the content switching information for statistic, charging etc. purpose, and may initiate a SIP Re-INVITE request to the UE to adjust the QoS reservation if the transport resources changed before and after switching.

8.2.5.2.2 Procedures at the UE

To switch content of the PSS streaming session the UE shall send an RTSP PLAY request with the new content URI as defined in TS 26.234 [8] clause 5.5.4.

8.2.5.2.3 Procedures at the IM CN Subsystem

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.2.5.2.4 Procedures at the SCF

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the PSS adapter.

8.2.5.2.5 Procedures at the PSS Adapter

Upon identification of a successful content switch, the PSS Adapter starts the content switching timer for a particular session. If another content switch occurs during the life of the timer, the timer is restarted. If the session is terminated during the life of the timer, the timer is stopped. After timer expiration, the PSS Adapter should send a SIP INFO message with the Info Package (Content Reporting) to the SCF. The Content Reporting Info Package shall contain an XML document as defined in Annex D and Annex E.

– ImsPssMbmsCommand shall be set to "PssSwitch".

– ContentID is set to the RTSP URI of the new content.

– DateTime is set to the current date and time.

The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command+xml".

8.2.5.2.6 Procedures at the PSS Server

The PSS Server reacts as defined in 3GPP TS 26.234 [8] clause 5.5.4.

8.2.5.3 PSS Content switching with available SDP, change of media components or QoS

8.2.5.3.1 General Description

Fast Content Switching as defined in 26.234 [8] Clause 5.5.4 allows also changing content when the new content channel requires a different number or characteristics of media components as the old content channel, or when the bandwidth needs to be modified.

For instance, the old content stream consists out of an audio and a video stream and the new content channel offers an audio, video and 3GPP Timed Text media component. Addition a media component to an ongoing stream is defined in 26.234 [8] clause 5.5.4.6 and removing a media component in 26.234 [8] clause 5.5.4.7.

Figure 11: IMS PSS Content switching

NOTE 1: This sequence is simplified and does not e.g. show the ACK message from in response to the reception of 200 OK.

NOTE 2: The number of required RTSP SETUP interactions between the PSS Adapter and the PSS Server depend on the number of new media components in the SDP.

The UE determines that the new SDP file contains a different number of media components as the old SDP. The UE updates the streaming session by sending a Re-INVITE with the new SDP file, as described in clause 8.2.3.2. The Re-INVITE is sent either before, during or after the RTSP PLAY switch. As soon as the UE receives the 200 OK for the Re-INVITE, the UE initiates a PLAY to get the new synchronization information.

8.2.5.3.2 Procedures at the UE

The UE shall send an RTSP PLAY request with the new content URI as defined in TS 26.234 [8] clause 5.5.4. The UE changes the number of media components by sending a Re-INVITE message with the new SDP offer. After receiving the 200 OK for the Re-INVITE the UE initiates a PLAY to get the new synchronization information.

8.2.5.3.3 Procedures at the IM CN Subsystem

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.2.5.3.4 Procedures at the SCF

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the PSS adapter.

8.2.5.3.5 Procedures at the PSS Adapter

– ImsPssMbmsCommand shall be set to "PssSwitch".

– ContentID is set to the RTSP URI of the new content.

– DateTime is set to the current date and time.

The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command+xml".

When receiving the SIP Re-INVITE message from the SCF, if a new media component needs to be added or removed, the PSS adapter shall send the RTSP SETUP to the PSS server, indicating the new media component that needs to be added or removed.

8.2.5.3.6 Procedures at the PSS Server

The PSS Server behaves as defined in 3GPP TS 26.234 [8] clause 5.5.4

8.2.5.4 PSS Content switching with unavailable SDP, no change of media component and/or bandwidth

8.2.5.4.1 General description

In this case, the UE does not have the SDP for the streams it intends to switch to. The new content has same media and bandwidth characteristics.

Figure 12: IMS PSS Content switching without available SDP, no change of media component and/or bandwidth

The UE sends a PLAY request to the PSS adapter indicating that it needs the SDP for the new streams. The PSS Adapter sends the RTSP PLAY message to the PSS Server.

The PSS Server responses a RTSP 200 OK message to the PSS Adapter, PSS Adapter sends the RTSP 200 OK message to UE containing the SDP for the new streams.

The PSS server starts streaming the switched content streams to the UE.

The PSS Adapter should send a SIP INFO message including the Info Package (Content Reporting) to the SCF according to clause 8.2.5.2.1.

8.2.5.4.2 Procedures at the UE

To switch content of the PSS streaming session the UE shall send an RTSP PLAY to request the new SDP as defined in TS 26.234 [8].

8.2.5.4.3 Procedures at the IM CN Subsystem

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.2.5.4.4 Procedures at the SCF

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the PSS adapter.

8.2.5.4.5 Procedures at the PSS Adapter

– ImsPssMbmsCommand shall be set to "PssSwitch".

– ContentID is set to the RTSP URI of the new content.

– DateTime is set to the current date and time.

The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command+xml".

The PSS Adapter sends the RTSP 200 OK message to UE containing the SDP for the new stream.

8.2.5.4.6 Procedures at the PSS Server

The PSS Server behaves as defined in 3GPP TS 26.234 [8] clause 5.5.4.

8.2.5.5 PSS Content switching with unavailable SDP, change of media component and/or bandwidth

8.2.5.5.1 General description

In this case, the UE does not have the SDP for the streams it intends to switch to. And the new content has different media and/or bandwidth characteristics.

Figure 13: IMS PSS Content switching without available SDP,
change of media component and/or bandwidth

The UE sends a PLAY request to the PSS adapter indicating that it needs the SDP for the new streams. The PSS Adapter sends the RTSP PLAY message to the PSS Server.. If the UE receives a "206 Partial Data" success status code, then the UE changes the number of media components and/or bandwidth by sending a RE-INVITE message with the new SDP file, as described in clause 8.2.5.1.

8.2.5.5.2 Procedures at the UE

If the UE receives a "206 Partial Data" success status code, then the UE changes the number of media components by sending a re-INVITE message with the new SDP file.

8.2.5.5.3 Procedures at the IM CN Subsystem

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.2.5.5.4 Procedures at the SCF

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the PSS adapter.

8.2.5.5.5 Procedures at the PSS Adapter

– ImsPssMbmsCommand shall be set to "PssSwitch".

– ContentID is set to the RTSP URI of the new content.

– DateTime is set to the current date and time.

The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command+xml".

When receiving the SIP RE-INVITE message from the SCF, if a new media component needs to be added, the PSS adapter shall send the RTSP SET-UP to the PSS server, indicating the new media component that needs to be added.

8.2.5.5.6 Procedures at the PSS Server

The PSS Server reacts as defined in 3GPP TS 26.234 [8] clause 5.5.4.

8.2.5.6 PSS content switching reporting update

8.2.5.6.1 General Description

If the SCF does not want to receive content switching information anymore or would like to start content switching reporting, the SCF should send a SIP UPDATE message to the PSS adapter with the Recv-Info header set appropriately.

Note: In this case, the SCF is acting as B2BUA.

Figure 13a: PSS content switching reporting update

8.2.5.6.2 Procedures at the PSS adapter

After receiving a SIP UPDATE message from the SCF, the PSS adapter shall dependent on the Recv-Info header, stop or start the content switching reporting.

8.2.5.6.3 Procedures at the SCF

If the SCF does not want to receive content switching information anymore, it should send a SIP UPDATE message with the Recv-Info header set to nil to the PSS adapter.

If the SCF decides to start content switching reports, the SCF should send a SIP UPDATE message with the Recv-Info header set to content info to the PSS adapter.

8.2.5.7 PSS Content Report Configuration

8.2.5.7.1 General Description

During service consumption with PSS session, the SCF may request the PSS Adapter to re-config the content report behaviours e.g. report timer, etc. The following clauses describe how the SCF can reconfigure a PSS Adapter.

According to sub-clause 8.2.3, a PSS streaming session was initiated and the PSS Adapter has indicated his willing to accept Content Reporting Configuration Info-Package.

In order to send the updated content report configuration information, the SCF issues a SIP INFO request to the PSS Adapter, with the new configuration information.

After receiving SIP INFO request, the PSS Adapter responses with SIP 200 OK and config itself with the new configuration information.

Figure 13b: Content Report Configuration Information Delivery to PSS Adapter

8.2.5.7.2 Procedures in SCF

Whenever the SCF wants to re-configure a PSS Adapter, the SCF shall issue a SIP INFO request to the PSS Adapter with the Info Package (Content Report Configuration). The Content Reporting Configuration Package shall contain an XML document as defined in Annex K.

– ReportTimer shall be set to the time value (in seconds) of the updated report timer;

8.2.5.7.3 Procedures at the IM CN Subsystem

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.2.5.7.4 Procedures in PSS Adapter

Upon receipt of a SIP INFO message the PSS Adapter shall send a SIP 200 OK to the SCF.

The PSS Adapter shall then parse the XML file in the message body, according the schema defined in Annex X. Following that the PSS Adapter shall configure itself according to the XML file:

– If the "ReportTimer" is different from the timer which is set for content report, then reset the timer with the value "ReportTimer".

8.2.6 PSS Streaming Session Teardown

8.2.6.0 Introduction

Assuming the streaming session is established, the session can be terminated either by the UE or by the network. For the network-initiated PSS streaming session teardown, either the SCF or the PSS adapter can initiate the procedure.

8.2.6.1 General Description

8.2.6.1.1 UE-initiated PSS streaming session teardown

Figure 14a: UE-initiated IMS PSS Session termination

Here the case of UE termination is described. The following steps are carried out:

1) Note that the PSS Adapter should maintain the RTSP session to the PSS Server until after step 5.

2) The UE sends a SIP BYE message.

3) The IMS CN subsystem forwards the SIP BYE message to the SCF.

4) The SCF sends the SIP BYE message to the PSS adapter.

5) The PSS adapter sends a RTSP TEARDOWN to the PSS server.

6) In case the PSS Server is transmitting RTP data it stops sending RTP data for this session. The PSS server sends a RTSP 200 OK to the PSS adapter.

7) The PSS adapter sends a SIP 200 OK to the UE via SCF and IMS CN subsystem.

8.2.6.1.2 SCF-initiated PSS streaming session teardown

Figure 14b: SCF-initiated IMS PSS Session termination

Here the case of the SCF-initiated teardown procedure is described. The following steps are carried out:

1) The SCF sends a SIP BYE to the PSS adapter.

2) The PSS adapter sends the RTSP TEARDOWN message to the PSS server.

3) The PSS server sends the RTSP 200 OK message to the PSS adapter.

4) The PSS adapter sends the SIP 200 OK message to the SCF.

5) Upon receipt of the SIP 200 OK, the SCF sends the SIP BYE message to the IM CN subsystem.

6) The IM CN Subsystem forwards the SIP BYE message to the UE.

7) The UE sends a SIP 200 OK message to the IM CN Subsystem.

8) The IM CN Subsystem forwards the SIP 200 OK to the SCF.

8.2.6.1.3 PSS adapter-initiated PSS streaming session teardown

Figure 14c: PSS adapter-initiated IMS PSS Session termination

Here the case of the SCF-initiated teardown procedure is described. The following steps are carried out:

1) The PSS adapter sends the RTSP TEARDOWN to the PSS server.

2) The PSS server sends the RTSP 200 OK to the PSS adapter.

3) The PSS adapter sends the SIP BYE message to the SCF.

4) The SCF sends the SIP 200 OK message to the PSS adapter.

5) The SCF sends the SIP BYE message to the IM CN Subsystem.

6) The IM CN Subsystem forwards the SIP BYE message to the UE.

7) The UE sends a SIP 200 OK message to the IM CN Subsystem.

8) The IM CN Subsystem forwards the SIP 200 OK to the SCF.

8.2.6.2 Procedures at the UE

8.2.6.2.1 UE-initiated PSS streaming session teardown

To teardown the PSS streaming session the UE shall close the TCP connection for RTSP between UE and PSS Adapter, if existing. Further, the UE shall send a SIP BYE to the SCF.

8.2.6.2.2 Network-initiated PSS streaming session teardown

Upon receipt of the SIP BYE message, the UE shall the SIP 200 OK message to the SCF. The UE procedes to release the associated resources held for the PSS session.

8.2.6.3 Procedures at the IM CN Subsystem

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.2.6.4 Procedures at the SCF

8.2.6.4.1 UE-initiated PSS streaming session teardown

Upon receipt of a SIP BYE message the SCF shall forward it to the PSS adapter.

8.2.6.4.2 SCF-initiated PSS streaming session teardown

The SCF initiates the PSS streaming session teardown by sending a SIP BYE message to the PSS adapter. Upon receipt of the SIP 200 OK from the PSS adapter, the SCF shall send a SIP BYE message to the UE.

8.2.6.4.3 PSS adapter-initiated PSS streaming session teardown

Upon receipt of the SIP BYE message received from the PSS adapter, the SCF sends the SIP 200 OK message to the PSS adapter. Then the SCF forwards the SIP BYE message to the UE.

8.2.6.5 Procedures at the PSS Adapter

8.2.6.5.1 UE-initiated PSS streaming session teardown

Upon receipt of a SIP BYE message from the SCF the PSS adapter shall send a RTSP TEARDOWN message to the PSS Server.

Upon receipt of a RTSP 200 OK message from the PSS server, the PSS adapter shall send a SIP 200 OK message to the SCF.

The PSS Adapter shall not close the RTSP session to the PSS Server on receipt of a TCP close, but waits until it has received the SIP BYE message in step 4 of clause 8.2.6.1.1.

8.2.6.5.2 SCF-initiated PSS streaming session teardown

Upon receipt of the SIP BYE message, the PSS adapter sends the RTSP TEARDOWN message to the PSS server. Upon receipt of the RTSP 200 OK message from the PSS server, the PSS adapter sends the SIP 200 OK to the SCF.

8.2.6.5.3 PSS adapter-initiated PSS streaming session teardown

The PSS adapter sends the RTSP TEARDOWN to the PSS server. Upon receipt of the RTSP 200 OK, the PSS adapter sends the SIP BYE messge to the SCF.

8.2.6.6 Procedures at the PSS Server

Upon receipt of a RTSP TEARDOWN from the PSS adapter, the PSS server shall stop still on-going RTP transmissions and send a RTSP 200 OK message to the PSS adapter.

8.2.7 Supported procedures

Clause 8.2 specifies IMS initiated and controlled PSS streaming sessions. Protocols and procedures as defined in 3GPP TS 26.234 [8] are supported including

– Fast content switching and start-up (clause 5.5). In the case of fast content start-up, the pipelining takes place between the PSS adapter and the PSS server.

– Time-shifting support (clause 5.6)

– RTP and RTCP extensions (clause 6.2.3)

– Adaptation of continuous media (clause 10)

– Quality of Experience reporting (clause 11).

8.3 MBMS Streaming

8.3.1 MBMS Media codecs and formats

MBMS Media codecs and formats defined in 3GPP TS 26.346 [11] are applicable to the present document for IMS initiated and controlled MBMS User service.

8.3.2 Procedure for providing missing parameters

8.3.2.1 Procedures at the UE

If the UE does not have the all the information it needs to form an SDP offer, the UE shall send a SIP OPTIONS message.

The "Request-URI" is related to the MBMS service that the user wants to activate. The "Request-URI" shall be composed of a user and domain part as defined as follows:

– The user part contains the serviceId. The serviceId shall be globalServiceID defined in [27] or serviceId defined in [11], which is retrieved from service selection information.

– The domain part is the Service Provider domain name, obtained from SSF.

The TO header shall contain the same URI as in the "Request-URI" parameter.

The FROM header shall indicate the public user identity of the user.

Upon reception of the 200 OK including service access information encapsulated in multipart/MIME, the UE may initiate MBMS session as described in clause 8.3.3.

8.3.2.2 Procedures at the SCF

When receiving the SIP OPTIONS message, the SCF shall examine the serviceId present in the user-part of the TO header and lookup the requested User Service Description information.

The SCF shall answer with the user service description information of the content delivery channel (encapsulated in multipart/MIME) as requested by the serviceId.

8.3.3 MBMS Streaming Session initiation

8.3.3.1 General description

Figure 15: MBMS Streaming Session Initiation

It is assumed that the UE has already received the MBMS USD containing the SDP and associated fragments for the service from the SSF before initiating the MBMS session.

Step 1, 2: UE initiates a SIP INVITE message to SCF, indicating which MBMS Streaming User Service the user has chosen.

Step 3, 4: SCF responds UE with a SIP 200 OK message when the SIP INVITE is successfully handled. The SIP 200 OK contains an SDP files containing the Multicast address of the service. The UE then activates the MBMS bearers either using the MBMS Broadcast Service Activation procedure [4] or the MBMS Multicast Service Activation Procedure [4].

Step 5: The UE can start receiving the MBMS Streaming session data when transmitted by the BM-SC.UPF.

The construction of the SDP is not affected by the use of MBMS stream bundling, see section 8.2.2 of [11], nor are any of the procedures.

8.3.3.2 Procedures at the UE

The UE shall support the procedures specified in TS 24 229 [7] for originating sessions.

The UE shall generate an initial INVITE request:

– The Request-URI in the INVITE request shall be the well known PSI (Public Service Identifier) of the MBMS Service, i.e. Live Stream@<Domain name>.

– The To header shall contain the same URI as in the Request-URI.

– The From header shall indicate the public user identity of the user.

– The Recv-Info header shall be set to "ContentReportConfig" [42].

An SDP offer shall be included in the request. The SDP offer shall be done in accordance with the parameters received during UE service selection procedure and with media capabilities and required bandwidth available for the MBMS session. The SDP offer corresponds to the MBMS Streaming Session. See 3GPP TS 26.346 [11], clause 8.3.1. . The SDP offer at media level shall include the following elements:

– The m-line(s) shall be set to the media parameters retrieved via service selection procedures for the requested MBMS service.

– The c-line(s) shall be set according to the multicast address retrieved via service selection procedures for the requested MBMS service.

– An a=mbms_service:MBMS_ServiceId line to indicate the MBMS service which the UE intends to initiate first. The MBMS_ServiceId shall be globalServiceID defined in [27] or serviceId defined in [11], which is retrieved from service selection information.

– The a-attribute shall be set to the value of "recvonly".

Once the UE receives the SIP response, the UE shall examine the media parameters in the received SDP, and initiate the MBMS channel according to the a=mbms_service line. It can activate the corresponding MBMS User Service as described in the USDs. MBMS User Service reception initiation may correspond to the MBMS Broadcast Mode activations as described in 3GPP TS 23.246 [4], clause 8.12 or the MBMS Multicast Mode activation procedure as described in 3GPP TS 23.246 [4], clause 8.2.

The received SDP may contain an a=suggestedPresentationOffset:value line. The value of suggestedPresentationOffset specifies a delay offset from the time when the first octet of a data unit was generated at the sender that is suggested to be used for presentation of the first octet of the data unit. For a received RTP packet, if the wall-clock time corresponding to the RTP timestamp carried in the RTP packet is T, a UE may present the data contained in the first octet of the associated RTP packet to the user at T+ suggestedPresentationOffset in terms of the wall-clock time if synchronized playout with other UEs adhering to the same rule is desired.

8.3.3.3 Procedures at the IM CN Subsystem

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. The corresponding PCC procedures are performed as described in clause 9.

8.3.3.4 Procedures at the SCF

The SCF shall support the procedures specified in TS 24.229 [7] applicable to an AS acting as a terminating UA.

Upon receipt of SIP INVITE request, the SCF shall perform service authorization procedures to check the service rights of requested MBMS service according to the user subscription information, See clause 10.4.

The SCF shall examine the SDP parameters in the SDP offer.

– It shall examine the a=mbms_service parameter. This parameter contains the channel the UE intends to join. If the mbms_service parameter does not point to a channel that the UE is allowed to join the SCF shall not accept the offer and shall answer with a 403 error code.

– It shall examine the c-line(s) to determine that it is a multicast session. It may also check that it corresponds to the mbms_service parameter. If not, the SCF shall answer with a 403 error code.

If the SDP parameters are examined successfully, the SCF shall answer with a SIP 200 OK, indicating the SDP answer as follows:

– the c-lines and m-lines shall be identical to ones indicated in the SDP offer.

– it shall include an a=sendonly attribute.

– It may include an a= suggestedPresentationOffset:value line. The value of suggestedPresentationOffset provides a mapping of the presentation time of each data unit to the wall-clock time to enable synchronized playout of the UEs adhering to the same rule.

The SIP 200 OK shall indicate the supported Info Packages in the Recv-Info header (Content Reporting) [42].

8.3.3.5 Procedures at the BMSC.UPF

The MBMS session is already ongoing at the BMSC.UPF. No specific action is required.

8.3.4 MBMS content switching

8.3.4.1 General Description

It is assumed that MBMS streaming reception is already active and a stream is delivered to the UE via MBMS. In case of MBMS content switching, the UE tunes into a new content channel e.g. in case of MBMS multicast mode the UE leaves a multicast channel and joins another one.

The UE should sent a SIP INFO Message with the included Info Package (Content Reporting) to inform the SCF about which channel is being received unless the SCF prohibits it. A timer is started with a preconfigured value with default value of 10 seconds, when the channel switch is executed. After timer expiration the SIP INFO message is sent.

Figure 16: MBMS content switching reporting

The UE sends content switching information to the SCF.

The content switching information may include the serviceId after switching. The SCF may utilize the content switching information for statistical or charging purposes etc.

If the SCF does not want to receive content switching information anymore or would like to start content switching reporting, the SCF should send a SIP UPDATE message to the UE with the Recv-Info header set appropriately.

Figure 16a: MBMS content switching reporting update

8.3.4.2 Procedures at the UE

The UE performs MBMS content switching according to the deactivation/activation procedures defined in [4].

Upon identification of a successful content switch, the UE starts the content switching timer for a particular session. If another content switch occurs during the life of the timer, the timer is restarted. If the session is terminated during the life of the timer, the timer is stopped. After timer expiration, the UE should send a SIP INFO message with the Info Package (Content Reporting) to the SCF. The Content Reporting Info Package shall contain an XML document as defined in Annex D and Annex F.

– ImsPssMbmsCommand shall be set to "MbmsSwitch";

– ServiceId shall be set to the value of the new channel. If the OMA BCAST Service Guide [27] is used, this shall be set to Global Service ID, otherwise shall be set to the MBMS User Service Description serviceId.

– ProgrammeId may be present and if present shall be set to the identifier of the current programme of the new channel. If the OMA BCAST Service Guide [27] is used, this shall be set to service Name.

– DateTime shall be set to the date & time of the channel switch.

The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command +xml".

After receiving a SIP UPDATE message from the SCF, the UE shall dependent on the Recv-Info header, stop or start the content switching reporting.

8.3.4.3 Procedures at the IM CN Subsystem

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.3.4.4 Procedures at the SCF

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the UE.

If the SCF does not want to receive content switching information anymore, it should send a SIP UPDATE message with the Recv-Info header set to nil.

If the SCF decides to start content switching reports, the SCF should send a SIP UPDATE message with the Recv-Info header set to Content Reporting to the UE.

8.3.4.5 Procedures at the BMSC.UPF

The BMSC.UPF transmits the RTP flows, and is not involved in the reporting of content switching information.

8.3.5 MBMS Streaming Session Teardown

8.3.5.1 General Description

Figure 17: MBMS Streaming Session Termination

Step 1: UE receives Streaming content from the BM-SC.UPF.

Step 2, 3: UE initiates a SIP BYE message to SCF, indicating which MBMS Streaming session to close.

Step 4, 5: SCF responds UE with a SIP 200 OK message when the SIP BYE is successfully handled and session terminated. At this stage, the UE can stop receiving the MBMS Streaming session.

The UE may deactivate the according MBMS Bearer Service during steps 2 to 5 or after step 5. The deactivation is either according to the MBMS Broadcast Service deactivation (3GPP TS 23.246 [4]) or the MBMS Multicast Mode deactivation procedure (3GPP TS 23.246 [4]).

8.3.5.2 Procedures at the UE

The UE shall send a SIP BYE to the SCF.

The UE may deactivate the according MBMS Bearer Service during steps 2 to 5 or after step 5 of clause 8.3.5.1. The deactivation is either according to the MBMS Broadcast Service deactivation (3GPP TS 23.246 [4]) or the MBMS Multicast Mode deactivation procedure (3GPP TS 23.246 [4]).

8.3.5.3 Procedures at the IM CN Subsystem

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.3.5.4 Procedures at the SCF

The SCF responds to the UE with a SIP 200 OK message after handling of the SIP BYE message.

8.3.5.5 Procedures at the BMSC.UPF

The BMSC.UPF is acting as described in 3GPP TS 23.246 [4].

8.3.6 MBMS Content Report Configuration

8.3.6.1 General Description

During service consumption with MBMS session, the SCF may request the UE to re-config the content report behaviours e.g. report timer, etc. The following clauses describe how the SCF can reconfigure a UE.

According to sub-clause 8.3.3, a MBMS streaming session was initiated and the UE has indicated his willing to accept Content Reporting Configuration Info-Package.

In order to send the updated content report configuration information, the SCF issues a SIP INFO request to the UE, with the new configuration information.

After receiving SIP INFO request, the UE responses with SIP 200 OK and config itself with the new configuration information.

Figure 17a: Content Report Configuration Information Delivery to UE

8.3.6.2 Procedures in SCF

Whenever the SCF wants to re-configure an UE, the SCF shall issue a SIP INFO request to the UE with the Info Package (Content Report Configuration). The Content Reporting Configuration Package shall contain an XML document as defined in Annex K.

– ReportTimer shall be set to the time value (in seconds) of the updated report timer;

The Content-Type header shall be set to"application/3gpp-ims-pss-mbms-contentReportConfig+xml".

8.3.6.3 Procedures at the IM CN Subsystem

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.3.6.4 Procedures in UE

Upon receipt of a SIP INFO message the UE shall send a SIP 200 OK to the SCF.

The UE shall then parse the XML file in the message body, according the schema defined in Annex X. Following that the UE shall configure itself according to the XML file:

– If the "ReportTimer" is different from the timer which is set for content report, then reset the timer with the value "ReportTimer".

8.4 Combined PSS and MBMS Streaming

8.4.1 Introduction

Combined PSS and MBMS streaming is important to ensure a consistent user experience. An UE may switch between one and the other depending on certain circumstances, e.g. changing between a PSS and MBMS coverage etc., or triggered by specific user action, e.g. trick play, etc.

It is assumed that the UE has an already established PSS or MBMS session and is capable of switching to the other delivery method.

Clause 8.4.2 gives the different cases and scenarios for switching between PSS and MBMS .

8.4.2 PSS – MBMS Switching

In the case of hybrid PSS-MBMS switching, it is distinguished between:

(a) switching from MBMS streaming to PSS streaming:

• Without channel change e.g. when a user is viewing an MBMS user service and moves out of MBMS coverage, or the user initiates trick play mode action, etc.

• With channel change e.g. changing to a channel only available on PSS.

(b) switching from PSS streaming to MBMS streaming:

• Without channel change e.g. the user returns back from trick play mode to a normal MBMS user service, etc.

• With channel change e.g. changing to a channel available on MBMS.

8.4.3 Switching from MBMS streaming to PSS streaming

According to clause 8.3.3 an MBMS streaming session was initiated and the UE is receiving the MBMS session from the BM-SC.UPF.

In order to switch from MBMS to unicast reception of a stream via PSS e.g. for allowing trick play mode, a SIP Re-INVITE is issued by the UE. An SDP offer and Request-URI shall be included according to clause 8.2.3.

After receiving the 200 OK, the UE leaves the multicast channel and starts playback.

Figure 18: IMS Hybrid PSS-MBMS-to-PSS content switching

8.4.3.1 Combined Session establishment

8.4.3.1.1 Procedures at the UE

When the UE switches from an MBMS User Service to a PSS user service, the UE sends a session modification request, i.e. SIP re-INVITE, with an SDP Offer and Request-URI.

The Request-URI is related to the PSS session that the user wishes to activate. The Request-URI shall be composed of a user and domain part as defined in clause 8.2.3.2.

The SDP offer shall include previously negotiated media descriptions with the port set to zero and two or more additional media descriptions: one for media control channel (i.e. RTSP control channel) and one or more for media delivery channel (i.e. delivery channel for the unicast streams).

The RTSP control media descriptor shall follow TS 24.229 [7]. The SDP offer for media delivery shall be identical to the previous SDP offer done for broadcast in term of codecs and transport protocol.

The UE may record the media offset for the MBMS user service.

When receiving SIP 200 OK response, the UE shall setup a media control channel with the PSS Adapter, and setup a media delivery channel with PSS Server according to the SDP answer. The UE shall send RTSP PLAY message to start the delivery of the media streams.

8.4.3.1.2 Procedures at the IM CN Subsystem

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.4.3.1.3 Procedures at the SCF

When receiving the SIP modification request, the SCF will determine if the programme currently broadcasted has MBMS to PSS switching support.

NOTE: The SCF may determine whether the SIP modification request is for MBMS to PSS switching according to the addition of the RTSP media control channel or unicast media delivery channel in the SDP offer.

If MBMS to PSS switching is not available for the UE, the session modification is rejected and the old MBMS session (along with the previous reserved resources) is maintained.

If MBMS to PSS switching is available for the UE, the SCF acting as a B2BUA, shall:

– Handle the SIP modification request as defined in clause 8.2.3.4;

– If the Request-URI contains a content identifier in the user part and a domain name in the domain part, the SCF shall select a suitable PSS adapter and generate a SIP INVITE request to the selected PSS adapter. The To header of the SIP INVITE request shall contain the same content identifier as in the Request-URI of the SIP modification request received from the UE;

– Send the SIP INVITE request to the PSS Adapter with the SDP parameters for the content control channel of RTSP, and for the media delivery channel of unicast streams. The SCF shall precise the content identifier in the user part of the Request-URI.

When sending the SIP INVITE message to PSS Adapter, SCF shall follow the procedures defined in TS 24.229 [7] concerning the AS acting as B2BUA.

8.4.3.1.4 Procedures at the PSS Adapter

When receiving a SIP INVITE request from SCF, as well as receiving RTSP 200 OK message from PSS Server, the PSS Adapter shall conform to clause 8.2.3.5.

Prior to replying, the PSS Adapter uses real time to calculate the media offset for the MBMS user service when replying with the offered media.

When receiving RTSP message from UE, the PSS Adapter shall conform to clause 8.2.4.2.

8.4.3.1.5 Procedures at the PSS Server

The procedures at the PSS Server shall conform to those defined in 3GPP TS 26.234 [8].

8.4.3.2 Combined session teardown

The combined session teardown shall conform to clause 8.2.6.

8.4.4 Switching from PSS streaming to MBMS streaming

According to clause 8.2.2 a PSS streaming session was initiated and the UE is receiving the PSS session from the PSS server.

In order to switch from PSS to MBMS reception of a stream, a SIP Re-INVITE is issued by the UE and sent to the SCF. The SCF shall act as a B2BUA, and send a SIP BYE messge to PSS Adapter to terminate the SIP session between them. The PSS Adapter shall send a RTSP TEARDOWN messag to PSS Server to release the RTSP session.

Once the UE receives the SIP 200 OK response, it can activate the corresponding MBMS User Service as described in the SDP as defined in clause 8.3.3.2.

After switching to MBMS reception, the PSS session shall be terminated.

Figure 19: IMS PSS-to-MBMS content switching

8.4.4.1 Combined Session establishment

8.4.4.1.1 Procedures at the UE

When the UE switches from a PSS User Service to an MBMS user service, the UE sends a session modification request, i.e. SIP re-INVITE, an SDP offer shall be included according to clause 8.3.3. The SDP offer for media delivery shall be identical to the previous SDP offer done for PSS in term of codecs and transport protocol.

Once the UE receives the SIP 200 OK response, it can activate the corresponding MBMS User Service as described in the SDP as defined in clause 8.3.3.2. MBMS User Service reception initiation may correspond to the MBMS Broadcast Mode activation procedure as described in 3GPP TS 23.246 [4], clause 8.12 or the MBMS Multicast Mode activation procedure as described in 3GPP TS 23.246 [4], clause 8.2.

8.4.4.1.2 Procedures at the IM CN Subsystem

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

8.4.4.1.3 Procedures at the SCF

When receiving the SIP modification request, the SCF will determine if the content currently delivered has PSS to MBMS switching support.

If PSS to MBMS switching is not available for the UE, the session modification is rejected and the old PSS session (along with the previous reserved resources) is maintained.

If PSS to MBMS switching is available for the UE, the SCF shall act as a B2BUA, and send a SIP BYE message to the PSS Adapter to terminate the SIP session between them. When sending the SIP BYE message to PSS Adapter, SCF shall follow the procedures defined in TS 24.229 [7] concerning the AS acting as B2BUA.

Once receiving a SIP 200 OK message from PSS Adapter, SCF sends a SIP 200 OK message to UE with a SDP answer as defined in clause 8.3.3.4.

8.4.4.1.4 Procedures at the PSS Adapter

When receiving a SIP BYE message from SCF, as well as receiving RTSP 200 OK message from PSS Server, the PSS Adapter shall conform to clause 8.2.6.5.

8.4.4.1.5 Procedures at the PSS Server

The procedures at the PSS Server shall conform to those defined in 3GPP TS 26.234 [8].

8.4.4.2 Combined session teardown

The combined session teardown shall conform to clause 8.3.5.