14 MBMS 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

This section depicts the procedures for retrieval of missing parameters before session initiation in clause 14.1, the MBMS download session initiation, file repair and reception report procedures in clause 14.2, and session teardown procedure in clause 14.3.

14.1 Missing parameters before session initiation

14.1.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 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 shall initiate MBMS download session as described in 14.2.

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

14.2 MBMS Download Session Initiation, File Repair and Reception Report

14.2.1 General description

Figure 31 gives an overview about the procedures for an IMS based MBMS Download Session initiation, File-Repair and reception report.

If an associated delivery procedure description for File-Repair operations is available, then the UE receiver may use the File-Repair service as specified in [11] sub-clause 9.3.

If an associated delivery procedure description for reception reporting is available, then the UE shall provide reception reports as specified in [11] sub-clause 9.4.

Figure 31 Procedures for IMS based MBMS Download

Step 1, 2: The UE generates an initial SIP INVITE message sent to the SCF, indicating the chosen MBMS Download Service. A SDP offer is included in the SIP INVITE message.

Step 3, 4: Upon receipt of SIP INVITE the SCF examine the SDP parameters in the SDP offer. In case of a successful examination, the SCF answers with a SIP 200 OK including the SDP answer.

Step 5: The UE receives the MBMS download data using FLUTE.

Step 6: In case of incomplete download, file repair procedures are executed. If the UE uses IMS-based procedures to initiate the file repair session, the following sequence of steps shall be exercised. Figure 31a gives an overview of the procedures for an IMS-based MBMS File Repair session initiation.

– Step 6a: The UE initiates the file repair session and tears down the MBMS download session by sending a SIP Re-INVITE message to the IM CN subsystem..

– Step 6b: The IM CN subsystem forwards the SIP Re-INVITE message to the SCF.

– Step 6c: The SCF verifies the user rights for the requested file repair service, selects a HTTP/SIP adapter, and forwards the SIP Re-INVITE message to the HTTP/SIP adapter. Furthermore, the SCF shall tear down the FLUTE-based MBMS download session between the BMSC.UPF and UE.

– Step 6d: The HTTP/SIP adapter selects a HTTP Server for the file repair service, and sends an HTTP POST message to the HTTP server, including the IP address of the UE.

– Step 6e: The HTTP server answers to the HTTP/SIP adapter with a HTTP 200 OK response.

– Step 6f: The HTTP/SIP adapter sends the SIP 200 OK answer to the SCF, including URI of the file repair server in the SDP answer.

– Step 6g: The SCF forwards the SIP 200 OK to the IM CN subsystem.

– Step 6h: The IM CN subsystem forwards the SIP 200 OK to the UE.

– Step 6i: The UE leaves the multicast channel and sends HTTP request(s) to the URI obtained from the SIP 200 OK message to execute file repair procedures. The HTTP server delivers the requested content file(s) for file repair in the HTTP response(s) to the UE.

Step 7, 8: The UE reports the reception statistics using either HTTP or SIP INFO message.

Figure 31a Procedures for IMS based MBMS File Repair Session Initiation

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

In case of incomplete download, the UE shall execute the file repair procedures towards the repair server indicated by repair-server-address attribute in the SDP Answer. In the case the file repair procedures are to be conducted over broadcast/multicast delivery, the repair-server-address:uri should instead indicate the Session Description (SDP file) for the broadcast/multicast repair session and UE shall then use this URI to fetch the SDP and join the corresponding broadcast/multicast repair session.

If the UE uses IMS-based methods to initiate file repair procedures, it shall handle this by tearing down the FLUTE-based MBMS download session and activating the file repair service, by issuing a SIP Re-INVITE sent to the IM CN subsystem. An SDP offer and Request-URI pointed to the repair server shall be included in the SIP Re-INVITE message to activate the file repair. The repair server URI shall be indicated in the Request-URI of the SIP Re-INVITE message based on the repair-server-address attribute indicated in the SDP Answer from the SCF during MBMS download session initiation. The To header shall contain the same URI as in the Request-URI (repair server address URI). The From header shall indicate the public user identity of the user. An SDP offer shall be included in the Re-INVITE request. The SDP media parameters should describe the HTTP-based file repair session and shall be set as follows:

– a ‘m’ line for an HTTP-based file repair session 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 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)

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 file repair session description.

The UE shall report the reception statistics using either HTTP or SIP INFO message according to report-channel parameter of the SDP Answer. The XML contents in the report message refer to section 9.5.3.2 of 3GPP TS 26.346[11].

14.2.3 Procedures at the IM CN Subsystem

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

In case of IMS-based MBMS file repair, 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.

14.2.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 download 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_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, the SCF shall answer 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.

If the SCF receives a SIP modification request from the UE to initiate a file repair session (i.e., in a SIP Re-INVITE message as described in clause 14.2.2), it shall check the user rights for the requested service, identify that the request is for MBMS file repair procedures and determine if the program currently broadcasted has HTTP-based file repair support. If this is not available for the UE, the session modification shall be rejected and the old MBMS session (along with the previous reserved resources) is maintained. Moreover, if broadcast/multicast repair is offered, SCF shall again reject the SIP modification request and reply with the URI for the SDP of the broadcast/multicast repair session (in case this is different from the current FLUTE session).

If HTTP-based file repair is available for the UE, the SCF acting as a B2BUA shall perform the following:

– The SCF shall select a HTTP/SIP adapter and generate the SIP INVITE request to the HTTP/SIP adapter which is in charge of the file repair service by changing the "Request-URI" accordingly. . The ‘To’ header of the SIP INVITE request shall be the same as the Request-URI of the SIP Re-INVITE request received from the UE. When receiving a 301 or 302 response from the HTTP/SIP adapter, the SCF shall not forward this message to the UE.

– The SCF shall tear down the FLUTE-based MBMS download session between the BMSC.UPF and UE.

14.2.5 Procedures at the BMSC.UPF

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

14.2.6 Procedures at the HTTP/SIP Adapter

In case of IMS-based file repair, upon reception of SIP INVITE request from the SCF, the HTTP/SIP adapter shall shall examine the To header and the media parameters in the SDP and select a HTTP Server for the file repair service according to the Request URI. The HTTP/SIP adapter shall send an 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 file repair service 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 shall return the SIP 200 OK message to the SCF, including the SDP answer. The SDP answer should describe the HTTP-based file repair session including URI of the designated repair server. The HTTP/SIP adapter shall construct the SIP 200 OK message as follows:

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

– An a=repair-server-address:uri to indicate the address of the repair server.

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

14.2.7 Procedures at the HTTP Server

In case of IMS-based file repair, upon reception of the HTTP POST message received from the HTTP/SIP adapter, the HTTP server shall answer to the HTTP/SIP adapter with a HTTP 200 OK response.

14.3 MBMS Download Session Teardown

14.3.1 General Description

Figure 32: MBMS Download Session Termination

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

Step 2, 3: UE initiates a SIP BYE message to SCF, indicating which MBMS download 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 download 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]).

14.3.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]).

14.3.3 Procedures at the IM CN Subsystem

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

14.3.4 Procedures at the SCF

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

14.3.5 Procedures at the BMSC.UPF

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

14.4 IMS-based MBMS File Repair Session Teardown

Identical SIP procedures for tearing down PSS download delivery sessions as described in clause 15.7 shall be used.

14.5 IMS-based Switching from MBMS Download to PSS Download

14.5.1 General Description

Figure 32b: IMS-based Switching from MBMS Download to PSS download

Figure 32b gives an overview of the procedures for IMS-based switching from MBMS download to PSS download. The following steps are carried out:

– Step 1: The UE initiates the PSS download session and tears down the MBMS download session by sending a SIP Re-INVITE message to the IM CN subsystem including an SDP offer.

– Step 2: The IM CN subsystem forwards the SIP Re-INVITE message to the SCF.

– Step 3: The SCF verifies the user rights for the requested PSS download service, selects a HTTP/SIP adapter, and sends a SIP INVITE message to the HTTP/SIP adapter. Furthermore, the SCF shall tear down the FLUTE-based MBMS download session between the BMSC.UPF and UE.

– Step 4: The HTTP/SIP adapter selects a HTTP Server for the PSS download service, and sends an HTTP POST message to the HTTP server, including the IP address of the UE.

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

– Step 6: The HTTP/SIP adapter sends the SIP 200 OK answer to the SCF, including the URI of the HTTP server in the SDP answer.

– Step 7: The SCF forwards the SIP 200 OK to the IM CN subsystem.

– Step 8: The IM CN subsystem forwards the SIP 200 OK to the UE.

– Step 9: The UE leaves the MBMS download session and sends HTTP request(s) to the URI obtained from the SIP 200 OK message to execute PSS download procedures. The HTTP server delivers the requested content file(s) for PSS download in the HTTP response(s) to the UE.

14.5.2 Procedures at the UE

The UE shall tear down the FLUTE-based MBMS download session and initiate the PSS download service, by issuing a SIP Re-INVITE sent to the IM CN subsystem. An SDP offer and Request-URI pointed to the HTTP server shall be included in the SIP Re-INVITE message to initiate the PSS download service. The content of the SIP Re-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.

An SDP offer shall be included in the SIP Re-INVITE request. The SDP media parameters should describe the PSS download session and shall be set as follows:

– a ‘m’ line for an HTTP-based download session 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 <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 download channel (ex. c=IN IP4 <IP_ADDRESS>).

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.

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

14.5.4 Procedures at the SCF

When the SCF receives a SIP modification request from the UE to initiate a PSS download session, i.e., in a SIP Re-INVITE message as described in clause 14.5.2, it shall check the user rights for the requested service, identify that the request is for PSS download procedures and determine if the program currently broadcasted has HTTP-based PSS download support. If this is not available for the UE, the session modification shall be rejected and the old MBMS session (along with the previous reserved resources) is maintained.

If HTTP-based PSS download is available for the UE, the SCF acting as a B2BUA shall perform the following:

– The SCF shall select a HTTP/SIP adapter and send the SIP INVITE request to the HTTP/SIP adapter which is in charge of the PSS download service by changing the "Request-URI" accordingly. The ‘To’ header of the SIP INVITE request shall be the same as the Request-URI of the SIP Re-INVITE request received from the UE. When receiving a 301 or 302 response from the HTTP/SIP adapter, the SCF shall not forward this message to the 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 FLUTE-based MBMS download session between the BMSC.UPF and UE.

14.5.5 Procedures at the BMSC.UPF

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

14.5.6 Procedures at the HTTP/SIP Adapter

Upon reception of SIP INVITE request from the SCF, the HTTP/SIP adapter shall shall examine the To header and the media parameters in the SDP and select a HTTP Server for the PSS download service according to the Request URI. The HTTP/SIP adapter shall send an 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 PSS download service 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 shall return the SIP 200 OK message to the SCF, including the SDP answer. The SDP answer should describe the HTTP-based PSS download session including URI of the designated HTTP server. The HTTP/SIP adapter shall construct the SIP 200 OK message as follows:

– an ‘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 the value of HTTP Server for the downlaod 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.

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

14.5.7 Procedures at the HTTP Server

Upon reception of the HTTP POST message received from the HTTP/SIP adapter, the HTTP server shall answer to the HTTP/SIP adapter with a HTTP 200 OK response.

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.