15 PSS download 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

15.1 General Description

Figure 33: IMS based session set-up for progressive download

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

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

3) The SCF verifies the user rights for the requested content, selects a HTTP/SIP adapter, and forwards the SIP INVITE message to the HTTP/SIP adapter.

4) The HTTP/SIP adapter selects a HTTP Server, and sends an HTTP POST message to the HTTP server, including the IP address of the UE.

5) The HTTP server answers to the HTTP/SIP adapter with a HTTP 200 OK response.

6) The HTTP/SIP adapter sends the SIP 200 OK answer to the SCF, including download URL of the requested content file in the SDP answer.

7) The SCF forward the SIP 200 OK to the IM CN subsystem.

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

9) The UE sends HTTP request to the URL obtained from the SIP 200 OK message.

10) The HTTP server delivers the content file in the HTTP response to the UE.

15.2 Procedures at the UE

The UE initiates the progressive download 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 PSS session and with the parameters received from the SSF during service selection procedure or during the procedure for retrieving missing parameters by SIP OPTIONS.

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

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

– a ‘m’ line for an HTTP progressive 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 "new" indicating that the UE will establish a new outgoing TCP connection towards the HTTP Server.

– 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 progressive download 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)

An example of the SDP offer for IMS-based PSS progressive download is:

v=0

o=bob 2890844527 2890844527 IN IP4 192.0.2.2

s=Download Session

i=A download session declared within the session description protocol

t=0 0

m=application 9 TCP 3gpp_http

a=connection:new

a=setup:active

c= IN IP4 192.0.2.2

b=AS:15000

Once the UE has received the SIP 200 OK from the HTTP/SIP adapter, it sends the HTTP GET request to the URL obtained in download session description. The HTTP "Connection" header shall be set to "Keep-Alive" to require persistent TCP connection.

An example of the HTTP GET request sent by the UE is:

HTTP GET http://123.23.23.23/ movie1.mpeg

15.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].

15.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 progressive download, selects and forwards the SIP request to the HTTP/SIP adapter which is in charge of the download 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.

15.5 Procedures at the HTTP/SIP adapter

Upon reception of the download 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, selects a HTTP Server according to the Request URI, and sends a HTTP POST message to the HTTP server including the IP address of the UE.

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 progressive download session. The differences with the SDP answer defined for streaming is the absence of media line corresponding to the control protocol (RTSP), the indication of TCP transport and HTTP progressive download method instead of streaming in "m" line, the indication of HTTP URL instead of RTSP URI.

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 progressive 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 the value of HTTP Server for the progressive download 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 progressive 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 "new" indicating that the UE will establish a new outgoing TCP connection towards the HTTP Server.

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

– a "fmtp:3gpp_http http-url" attribute in the format of an absolute URI to be used for the UE in the subsequent HTTP requests. The h‑uri can be in form of absolute or relative URI. If absolute URI is specified then it is used as-is in subsequent HTTP requests. If relative URI is specified in form of a media path, then the HTTP absolute URI could be constructed by the UE using the IPAddress (from c-line) and port (from m-line) as the base followed by h-uri value for the content path.

– 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:new

a=setup:passive

a=fmtp 3gpp_http h-url http://operator.com/movie1.mpeg

c=IN IP4 192.0.2.1

b=AS:0

15.6 Procedures at the HTTP server

Upon reception of the HTTP POST message received from the HTTP/SIP adapter, the HTTP server answers with an HTTP 200 OK message to the HTTP/SIP adapter.

Upon reception of the HTTP GET received from the UE, the HTTP server delivers in the HTTP response the content file corresponding to the URL obtained in the received HTTP GET. The HTTP "Connection" header shall be set to "Keep-Alive" to indicate it is a persistent TCP connection.

15.7 Session termination

15.7.1 General description

15.7.1.1 UE-initiated PSS download session teardown

Figure 33a: UE-initiated IMS PSS download 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 an HTTP POST to the HTTP server.

5) In case the HTTP Server is transmitting the content file, it stops sending data for this session. The HTTP server sends a HTTP 200 OK to the HTTP/SIP adapter.

6) The HTTP/SIP adapter sends a SIP 200 OK to the UE via SCF and IM CN subsystem.

15.7.1.2 SCF-initiated PSS download session teardown

Figure 33b: SCF-initiated IMS PSS download 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 HTTP/SIP adapter.

2) The HTTP/SIP adapter sends HTTP POST message to the HTTP server.

3) The HTTP server sends the HTTP 200 OK message to the HTTP/SIP adapter.

4) The HTTP/SIP 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.

15.7.1.3 HTTP/SIP adapter-initiated PSS download session teardown

Figure 33c: HTTP/SIP adpater-initiated IMS based session teardown for PSS download

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

1) The HTTP/SIP adapter sends the HTTP POST to the HTTP server.

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

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

4) The SCF sends the SIP 200 OK message to the HTTP/SIP 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 message to the SCF.

15.7.2 Procedures at the UE

15.7.2.1 UE-initiated PSS download session teardown

To teardown the PSS download session, the UE shall send a SIP BYE message to the SCF.

15.7.2.2 Network-initiated PSS download 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.

15.7.3 Procedures at the IM CN Subsystem

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

15.7.4 Procedures at the SCF

15.7.4.1 UE-initiated PSS download session teardown

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

15.7.4.2 SCF-initiated PSS download session teardown

The SCF initiates the PSS download session teardown 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.

15.7.4.3 HTTP/SIP adapter-initiated PSS download session teardown

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.

15.7.5 Procedures at the HTTP/SIP adapter

15.7.5.1 UE-initiated PSS download session teardown

Upon receipt of a SIP BYE message from the SCF the HTTP/SIP adapter shall send a HTTP POST message to the HTTP Server.

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

15.7.5.2 SCF-initiated PSS download session teardown

Upon receipt of the SIP BYE message, the HTTP/SIP adapter sends the HTTP POST message to the HTTP server. Upon receipt of the HTTP 200 OK message from the HTTP server, the HTTP/SIP adapter sends the SIP 200 OK to the SCF.

15.7.5.3 HTTP/SIP adapter-initiated PSS download session teardown

The HTTP/SIP adapter sends the HTTP POST to the HTTP server. Upon receipt of the HTTP 200 OK, the HTTP/SIP adapter sends the SIP BYE messge to the SCF.

15.7.6 Procedures at the HTTP server

Upon receipt of a HTTP POST from the HTTP/SIP adapter, the HTTP server shall stop still on-going data transmissions and send a HTTP 200 OK message to the HTTP/SIP adapter.

15.8 IMS-based Switching from PSS Download to MBMS Download

15.8.1 General Description

Figure 33d: IMS-based Switching from PSS Download to MBMS download

Figure 33d gives an overview about the procedures for IMS based switching from PSS download to MBMS download. The following steps are carried out:

1) The UE sends a SIP Re-INVITE message to the IM CN subsystem indicating the chosen MBMS download service. A SDP offer is included in the SIP Re-INVITE message.

2) The IM CN subsystem forwards the SIP Re-INVITE message to the SCF.

3) Upon receipt of SIP Re-INVITE message, the SCF examines the parameters in the SDP offer and verifies the user rights for the requested MBMS download service. In case of a successful examination, the SCF sends the SIP BYE message to the HTTP/SIP adapter in order to terminate the PSS download session.

4) The HTTP/SIP adapter sends an HTTP POST to the HTTP server.

5) In case the HTTP Server is transmitting the content file(s) for the PSS download service, it stops sending data for this session. The HTTP server sends a HTTP 200 OK to the HTTP/SIP adapter.

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

7) The SCF sends a SIP 200 OK message to the UE via the IM CN subsystem including the SDP answer to initiate the FLUTE-based MBMS download session.

8) The UE receives the MBMS download data using FLUTE.

15.8.2 Procedures at the UE

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

The UE shall tear down the PSS download session and initiate the MBMS download service, by issuing a SIP Re-INVITE sent to the IM CN subsystem. An SDP offer shall be included in the SIP Re-INVITE message to initiate the MBMS download service. The content of the SIP Re-INVITE shall be as follows:

– The Request-URI in the INVITE request shall be the well known PSI (Public Service Identifier) of the MBMS Download Service.

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

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 download service. The SDP offer shall include the following elements:

– An a=source-filter line to indicate the IP source address of the FLUTE session.

– An a=flute-tsi line to indicate Transport Session ID (TSI) of the FLUTE session.

NOTE: The combination of the TSI and the IP source address identifies the FLUTE session.

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

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

The descriptions of above parameters conform to section 7.3 of 3GPP TS 26.346[11].

– An a=mbms_download_service:ServiceId line to indicate the MBMS download service which the UE intends to initiate.

Once the UE receives the SIP response, the UE shall examine the FLUTE session parameters in the received SDP, and receive the MBMS download data accordingly.

In case the FDT is unavailable, the UE shall get the FDT according to fdt_address attribute in the SDP Answer. The FDT contains content description information for the files delivered in the FLUTE session.

15.8.3 Procedures at the IM CN Subsystem

The IM CN subsystem shall forward the SIP Re-INVITE from the UE to the SCF.

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

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

15.8.4 Procedures at the SCF

Upon receipt of SIP Re-INVITE request from the UE to switch from PSS download to MBMS download, the SCF shall perform service authorization procedures to check the service rights of requested MBMS download service according to the user subscription information, See clause 10.4. If MBMS download service is not available for the UE, the session modification shall be rejected and the old PSS download session (along with the previous reserved resources) is maintained.

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

– It shall examine the a=mbms_download_service parameter. This parameter contains the channel the UE intends to join. If the mbms_download_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_download_service parameter. If not, the SCF shall answer with a 403 error code.

If the SDP parameters are examined successfully and MBMS download service is available to the UE, the SCF acting as B2BUA shall perform the following:

– The SCF shall initiate the FLUTE-based MBMS download session between the BM-SC.UPF and UE. The SCF shall respond to the UE with a SIP 200 OK message after successful handling of the SIP Re-INVITE message.

– The SCF shall tear down the PSS download session by sending a SIP BYE message to the HTTP/SIP adapter.

The SCF shall answer to the UE with a SIP 200 OK, indicating the SDP answer as follows:

– the m-line(s) and c-line(s) shall be identical to ones indicated in the SDP offer.

– The source-filter and flute-tsi attributes shall be identical to ones indicated in the SDP offer.

– An a=fdt_address:uri to indicate the address of the File Delivery Table.

– An a=repair-server-address:uri to indicate the address of the repair server. In the case the file repair procedures are to be conducted over broadcast/multicast delivery, the repair-server-address:uri should instead be the URI of the Session Description (SDP file) of the broadcast/multicast repair session.

– An a=report-channel:SIP/HTTP line to indicate to the UE that the reception report procedure should be performed by SIP or HTTP channel.

– It shall include an a=recvonly attribute.

15.8.5 Procedures at the HTTP/SIP adapter

Upon receipt of a SIP BYE message from the SCF, the HTTP/SIP adapter shall send a HTTP POST message to the HTTP Server.

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

15.8.6 Procedures at the HTTP server

Upon receipt of a HTTP POST from the HTTP/SIP adapter, the HTTP server shall stop still on-going data transmissions and send a HTTP 200 OK message to the HTTP/SIP adapter.

15.8.7 Procedures at the BMSC.UPF

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