19 3GP-DASH (Dynamic and Adaptive Streaming over HTTP) service

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

19.1 Session initiation and QoS reservation

19.1.1 General description

Figure 40: IMS based session initiation and QoS reservation for 3GP-DASH

1) HTTP streaming has started by fetching media segments from the HTTP server after obtaining the MPD

2) The UE initiates the streaming session by sending SIP INVITE to the IM CN subsystem, including an SDP offer.

3) The IM CN subsystem forwards the SIP INVITE message to the SCF.

4) The SCF selects a HTTP/SIP adapter, and forwards the SIP INVITE message to the HTTP/SIP adapter.

5) The HTTP/SIP adapter sends the SIP 200 OK answer to the SCF with the SDP answer.

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

7) The IM CN subsystem forwards the SIP 200 OK to the UE.

Afterwards, media segments are delivered to the UE using the reserved QoS.

19.1.2 Procedures at the UE

The UE initiates the HTTP streaming session by sending SIP INVITE to the IM CN subsystem. The content of the SIP INVITE shall be as follows:

– The Request URI is related to the session 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

– 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.

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

The content identifier shall be retrieved from service selection information.

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

An SDP offer shall be included in the initial INVITE request, in accordance with media capabilities and policies available for the HTTP streaming session and with the parameters received from the SSF during service selection procedure or during the procedure for retrieving missing parameters by SIP OPTIONS or by MPD analysis.

The SDP media parameters should describe the HTTP streaming session. The differences with the SDP offer defined for RTP streaming is the absence of media line corresponding to the control protocol (RTSP), and the indication of TCP transport and HTTP download method instead of streaming in "m" line.

The SDP parameters for the HTTP download channel shall be set as follows:

– a ‘m’ line for an HTTP download channel 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 HTTP runs directly on top of TCP and the latter is used when HTTP 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_http.

NOTE: the 3gpp_http 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 HTTP Server.

– An "a= connection" attribute shall be present and set as "existing".

– 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 HTTP download channel (ex. c=IN IP4 <IP_ADDRESS>).

– A "b=" line contains the proposed bandwidth. If the user has fetched the bandwidth required for this particular content delivery channel by MPD analysis, 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)

An example of the SDP offer for IMS-based HTTP streaming is:

v=0

o=bob 2890844527 2890844527 IN IP4 192.0.2.2

s=HTTP Streaming Session

i=A HTTP Streaming session declared within the session description protocol

t=0 0

m=application 9 TCP 3gpp_http

a=connection:existing

a=setup:active

c= IN IP4 192.0.2.2

b=AS:15000

19.1.3 Procedures at the IM CN subsystem

The IM CN subsystem shall forward the SIP INVITE to the SCF.

Upon reception of the SIP 200 OK from the SCF, the IM CN subsystem forwards the SIP 200 OK to the UE.

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

QoS reservation is carried out according to clause 9.

19.1.4 Procedures at the SCF

Upon reception of the SIP INVITE from the UE, the SCF checks the user rights for the requested content, identifies that the request is for HTTP streaming, selects and forwards the SIP request to the HTTP/SIP adapter which is in charge of the HTTP streaming service by changing the "Request-URI" accordingly.

When receiving a 301 or 302 response from the HTTP/SIP adapter, the SCF shall not forward this message to the UE.

19.1.5 Procedures at the HTTP/SIP adapter

Upon reception of the HTTP streaming session initiation request, the HTTP/SIP adapter shall examine the content identifier present in the user-part of the To header and the media parameters in the SDP and selects a HTTP Server according to the Request URI.

The HTTP/SIP adapter may decide to redirect the request to another HTTP/SIP adapter server. In this case the HTTP/SIP adapter shall return a 301 response if the content is not managed by this HTTP/SIP adapter or 302 response for any other reasons (e.g. load balancing). The redirecting HTTP/SIP adapter indicates one or more destination HTTP/SIP adapter addresses in the Contact header.

The HTTP/SIP adapter returns the SIP 200 OK message to the SCF, including the SDP answer. The SDP answer should describe the HTTP streaming session. The differences with the SDP answer defined for RTP streaming is the absence of media line corresponding to the control protocol (RTSP), the indication of TCP transport and HTTP download method instead of streaming in "m" line.

If the content that the user has selected cannot be found the HTTP/SIP adapter shall reply with appropriate, SIP error code 404 Not Found response.

The HTTP/SIP adapter shall construct the SIP 200 OK message as follows:

– an ‘m’ line for an HTTP streaming channel 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 of HTTP Server for the HTTP streaming channel, such as 80.

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

– The fmt field shall be identical to the one received in the SDP offer.

– 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 HTTP server for the flow of the related HTTP download channel (e.g. c=IN IP4 <IP_ADDRESS>).

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

– An "a= connection" attribute shall be present and set as "existing".

– the "b=" line shall contain the proposed bandwidth. Since the content download is unidirectional the bandwidth shall be set to 0.(ex. b=AS:0).

An example of the SDP answer in the SIP 200 OK response is:

v=0

o=bob 2890844527 2890844527 IN IP4 192.0.2.1

s=Download Session

i=A download session declared within the session description protocol

t=0 0

m=application 80 TCP 3gpp_http

a=connection:existing

a=setup:passive

c=IN IP4 192.0.2.1

b=AS:0

19.1.6 Procedures at the HTTP server

Upon reception of the HTTP GET message received from the UE, the HTTP server shall deliver the requested media segments.

19.2 MPD Update

19.2.1 General description

A SIP event frame work is used in order to inform the UE about a MPD update. This avoids direct polling of the HTTP server by the UE and reduces the signalling overhead.

Figure 41: MPD Update

1) The UE sends a SIP SUBSCRIBE message towards the IM CN subsystem.

2) The IM CN subsystem forwards the request to the SCF.

3) The SCF forwards the request to the HTTP/SIP adapter.

4) The HTTP/SIP adapter sends a SIP 200 OK response to the SCF.

5) The SCF forwards the SIP 200 OK response to the IM CN subsystem.

6) The IM CN subsystem forwards the SIP 200 OK response to the UE.

7) The HTTP/SIP adapter detects an updated MPD e.g by polling towards the HTTP server and recognizing a change of the MPD

8) The HTTP/SIP adapter sends a SIP NOTIFY message including the updated MPD to the SCF.

9) The SCF forwards the SIP NOTIFY message to the IM CN subsystem.

10) The IM CN subsystem forwards the message to the UE.

11) The UE sends a SIP 200 OK to the IM CN subsystem.

12) The IM CN subsystem forwards the response to the SCF.

13) The SCF forwards the SIP 200 OK to the HTTP/SIP adapter.

14) Adaptive HTTP streaming is continued by fetching media segments as described in the updated MPD.

19.2.2 Procedures at the UE

19.2.2.1 Subscription

When the UE intends to retrieve MPD Update information from the SDF, it shall generate a SUBSCRIBE request for the "MPD-Update" event package.

The contents of the SUBSCRIBE request shall be as follows:

– The value of the Request-URI shall be set to one of following:

– – the PSI of the SCF; or

– – the public user identity of the end user (when the UE does not know the PSI of the SCF).

– The From and To header shall be set to the public user identity of the user.

– The Event header shall be set to the "MPD-Update" event package.

– The message body shall include the MPD URL.

A UE that doesn’t subscribe for MPD updates may still get new MPD by regular MPD update procedures as specified in TS 26.247.

19.2.2.2 Receiving Notifications

Upon receipt of a NOTIFY request on the dialog which was generated during subscription, the application within the UE shall extract the MPD contained in the message body.

In case the UE does not understand the NOTIFY request or detects errors in the MPD, the UE shall return a 400 Bad Request to the NOTIFY request. In addition, the UE should behave in the same way as if erroneous MPD is received directly from the HTTP server.

Otherwise, the UE shall return a 200 OK response to the NOTIFY request.

19.2.3 Procedures at the IM CN subsystem

The IM CN subsystem shall forward the SIP SUBSCRIBE to the SCF.

Upon reception of the SIP 200 OK from the SCF, the IM CN subsystem forwards the SIP 200 OK to the UE.

The IM CN subsystem shall forward the SIP NOTIFY to the UE.

Upon reception of the SIP 200 OK from the UE, the IM CN subsystem forwards the SIP 200 OK to the SCF.

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

19.2.4 Procedures at the SCF

Upon reception of the SIP SUBSCRIBE from the UE, the SCF identifies that the request is for HTTP streaming, selects and forwards the SIP request to the HTTP/SIP adapter which is in charge of the HTTP streaming service by changing the "Request-URI" accordingly.

When receiving a 301 or 302 response from the HTTP/SIP adapter, the SCF shall not forward this message to the UE.

19.2.5 Procedures at the HTTP/SIP adapter

When the HTTP/SIP adapter receives a SUBSCRIBE request, it shall examine the parameters specified in the SIP SUBSCRIBE body and extract the MPD URL.

The HTTP/SIP adapter shall generate a SIP 200 OK in response to the SUBSCRIBE request.

The HTTP/SIP adapter shall be able to detect an updated MPD at the HTTP server and to download it. The exact procedure for MPD update detection is out of scope of this specification.

NOTE1: MPD update detection may be done by the following procedures: the HTTP/SIP adapter may send a HTTP GET message to the HTTP server requesting the MPD. Upon reception of the HTTP 200 OK the HTTP/SIP adapter may store the received MPD. The newly received MPD is compared with previously received and stored MPD. In case of a difference between these two MPD files, an MPD update is detected. The HTTP "Connection" header shall be set to "Keep-Alive" to indicate it is a persistent TCP connection.

NOTE2: In order to avoid the complete download of the MPD at each request HTTP, conditional GET including an If-Modified-Since header field may be used.

In case of a detected MPD update a SIP NOTIFY message is sent to the SCF. The contents of the NOTIFY request shall be as follows:

– The Event header shall be set to the "MPD-Update" event package.

– The content type shall be set to "video/vnd.3gpp.mpd".

– The message body shall contain the updated MPD.

In case of receiving a 400 Bad Request status code after sending the SIP NOTIFY message, the HTTP/SIP adapter shall repeat the MPD update detection procedure.

19.2.6 Procedures at the HTTP server

Procedures for MPD update detection at the server depend on the selected method. The exact procedure for MPD update detection is out of scope of this specification.

NOTE: In case of HTTP polling from the HTTP/SIP adapter and upon reception of the HTTP GET received from the HTTP/SIP adapter, the HTTP server delivers in the HTTP response the MPD file corresponding to the URL obtained in the received HTTP GET. The HTTP "Connection" header is set to "Keep-Alive" to indicate it is a persistent TCP connection.

Upon reception of the HTTP GET message received from the UE, the HTTP server shall deliver the requested media segments.

19.3 Session termination

19.3.1 General description

19.3.1.1 UE-initiated session termination

Figure 42: UE-initiated session termination

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

1) The UE sends a SIP BYE message.

2) The IM CN subsystem forwards the SIP BYE message to the SCF.

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

4) The HTTP/SIP adapter sends a SIP 200 OK to the SCF.

5) The SCF sends the SIP 200 OK to the IM CN subsystem.

6) The IM CN subsystem forwards the SIP 200 OK to the UE.

The UE may stop fetching media segments and close the HTTP connection before the SIP Bye procedure is initiated. The UE shall stop fetching media segments and close the HTTP connection at the latest immediately after step 6.

19.3.1.2 SCF-initiated session termination

Figure 43: SCF-initiated session termination

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

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

2) The HTTP/SIP adapter sends the SIP 200 OK message to the SCF.

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

4) The IM CN Subsystem forwards the SIP BYE message to the UE. The UE stops fetching media segments and closes the HTTP connection.

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

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

19.3.1.3 HTTP/SIP adapter-initiated session termination

Figure 44: HTTP/SIP adapter-initiated session termination

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

1) The HTTP/SIP adapter sends the SIP BYE message to the SCF.

2) The SCF sends the SIP 200 OK message to the HTTP/SIP adapter.

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

4) The IM CN Subsystem forwards the SIP BYE message to the UE. The UE stops fetching media segments and closes the HTTP connection.

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

6) The IM CN subsystem forwards the SIP 200 OK message to the SCF.

19.3.2 Procedures at the UE

19.3.2.1 UE-initiated session termination

To terminate the session, the UE shall send a SIP BYE message to the SCF.

After receiving the SIP 200 OK the UE stops fetching media segments and closes the HTTP connection.

19.3.2.2 Network-initiated session termination

Upon receipt of the SIP BYE message, the UE shall send the SIP 200 OK message to the SCF. The UE stops fetching media segments and closes the HTTP connection

19.3.3 Procedures at the IM CN Subsystem

The IM CN subsystem handles the SIP dialog as defined in [6].

19.3.4 Procedures at the SCF

19.3.4.1 UE-initiated session termination

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

19.3.4.2 SCF-initiated session termination

The SCF initiates the session termination by sending a SIP BYE message to theHTTP/SIP adapter. Upon receipt of the SIP 200 OK from the HTTP/SIP adapter, the SCF shall send a SIP BYE message to the UE.

19.3.4.3 HTTP/SIP adapter-initiated session termination

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

19.3.5 Procedures at the HTTP/SIP adapter

19.3.5.1 UE-initiated session termination

Upon receipt of a SIP BYE message the HTTP/SIP adapter shall send a SIP 200 OK message to the SCF.

19.3.5.2 SCF-initiated session termination

Upon receipt of the SIP BYE message, the HTTP/SIP adapter shall send a SIP 200 OK to the SCF.

19.3.5.3 HTTP/SIP adapter-initiated session termination

The HTTP/SIP adapter shall send the SIP BYE message to the SCF.

19.3.6 Procedures at the HTTP server

The HTTP server shall stop still on-going media segment transmissions if the HTTP connection is closed.