Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x
Top   in Index   Prev   Next

TR 26.827
IMS-based Streaming
and Download Delivery enhancements

V12.0.0 (Wzip)  2014/03  13 p.
Rapporteur:
Dr. Curcio, Igor
Nokia Corporation

Content for  TR 26.827  Word version:  12.0.0

Here   Top

1  Scopep. 5

The objectives of the Work Item on IMS-based Streaming and Download Delivery Enhancements (IMS_SDE) include:
  • Identify use cases and recommended requirements based on Release 10/11 functionality included in the PSS and MBMS specifications to be addressed for IMS-based streaming and download enhancements, and document the adopted use cases.
  • Develop procedures towards enabling the IMS-based extensions of the identified use cases in TS 26.237.
The present document is written in a form that the recommendations made and assumptions stated are directed to authors and contributors to Technical Specifications being affected as a result of the study presented here.
Up

2  Referencesp. 5

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 26.234: "Transparent end-to-end Packet Switched Streaming service (PSS); Protocols and codecs".
[3]
TS 26.346: "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs".
[4]
TS 26.247: "Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)".
[5]
TS 26.237: "IP Multimedia Subsystem (IMS) based Packet Switch Streaming (PSS) and Multimedia Broadcast/Multicast Service (MBMS) User Service; Protocols".
Up

3  Abbreviationsp. 5

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
BM-SC
Broadcast-Multicast - Service Centre
DASH
Dynamic Adaptive Streaming over HTTP
eMBMS
E-UTRAN MBMS
FDT
File Description Table
FLUTE
File deLivery over Unidirectional Transport
MBMS
Multimedia Broadcast and Multicast Service
MPD
Media Presentation Description
PSI
Public Service Identity
PSS
Packet Switched Streaming Service
RTSP
Real-Time Streaming Protocol
SCF
Service Control Function (IN context), Service Capability Feature (VHE/OSA context)
SDP
Service Discovery Protocol (Bluetooth related)
SSF
Service Selection Function
Up

4  Use Cases, Recommended Requirements, Assumptions and Gap Analysisp. 6

4.1  Use Case#1: MBMS File Repair via Conventional HTTP Serversp. 6

4.1.1  Descriptionp. 6

A mobile network operator wishes to use conventional HTTP servers as repair servers for the MBMS File Repair feature as part of its IMS-based PSS and MBMS service deployment. The operator wishes not to use specialized file-repair servers and would prefer to use its existing conventional HTTP web servers for the file repair service as well as for delivering other content.

4.1.2  Recommended Requirementsp. 6

  • It is possible to use conventional HTTP web servers as file repair servers for the MBMS File Repair feature of an IMS-based PSS and MBMS service.
  • As part of an IMS-based MBMS download service, it is possible for the UE to employ SIP signalling procedures to initiate an HTTP-based file repair service from an HTTP server through the use of an HTTP/SIP adapter.
  • Upon receiving a SIP modification request from the UE to tear down the FLUTE-based MBMS download session from the BM-SC and activate an HTTP-based repair service from an HTTP server, it is possible for SCF to:
    • check on available repair methods (byte range based, symbol based or broadcast/multicast) and repair servers;
    • if broadcast/multicast repair is offered, reject the SIP modification request and reply with the URI for the SDP of the broadcast/multicast repair session;
    • check user rights and if granted, forward the SIP request to a HTTP/SIP adapter;
    • tear down the FLUTE-based MBMS download session between the BM-SC.UPF and UE;
    • reply to UE with the SDP including the URI of the file repair server.
  • Upon reception of the MBMS file repair activation request from SCF, it is possible for a HTTP/SIP adapter to select an HTTP server for the file repair service.
Up

4.1.3  Gap Analysisp. 6

IMS-based procedures are present in TS 26.237 to control MBMS download sessions over FLUTE as well as perform reception reporting using SIP INFO. No IMS-based procedures are present to control MBMS File Repair sessions, including those for file repair using conventional HTTP servers.
IMS-based signalling procedures may be defined in TS 26.237 to initiate and manage file repair sessions for symbol-based and byte-range based file repair over HTTP/TCP/IP as well as for broadcast/multicast file repair over FLUTE. This is for instance useful if UE receives one repair server URI from SCF in the SDP at the beginning of the FLUTE session (as already present in TS 26.237), while it may also receive other repair server URIs from the user service announcement or inband via FLUTE during MBMS download session (i.e. as FDT element for byte range based file repair, as postFileRepair element of the associatedProcedureDescription for symbol based file repair, and bmFileRepair element of the associatedProcedureDescription for broadcast/multicast based file repair), in which case IMS-based procedures can help the UE to check back with the SCF and determine or get updated on the latest repair service information.
Up

4.1.4  Solution Spacep. 6

A high-level exemplary sketch of the proposed SIP-based methods and signalling procedures for MBMS file repair sessions controlled by IMS is provided as follows:
Step 1.
The UE generates an initial SIP INVITE message sent to the IM CN Subsystem, indicating the chosen MBMS Download Service. A SDP offer is included in the SIP INVITE message. The IM CN Subsystem forwards the SIP INVITE message and SDP offer to the SCF.
Step 2.
Upon receipt of SIP INVITE request, the SCF examines the SDP parameters in the SDP offer and performs service authorization procedures to check the service rights of requested MBMS download service according to the user subscription information. In case of a successful examination, the SCF answers with a SIP 200 OK including the SDP answer. The SDP answer could contain the fdt_address:uri to indicate the address of the File Delivery Table, the repair-server-address:uri to indicate the address of the repair server or the address of the SDP for the broadcast/multicast repair session.
Step 3.
Once the UE receives the SIP response, the UE examines the FLUTE session parameters in the received SDP, and receive the MBMS download data accordingly.
Step 4.
In case of incomplete download, the UE executes the file repair procedures towards the repair server. The UE handles this by tearing down the FLUTE-based MBMS download session and activating HTTP-based delivery of the 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 is included in the SIP Re-INVITE message to activate the file repair. The IM CN subsystem forwards the SIP Re-INVITE message to the SCF.
Step 5.
When receiving the SIP modification request, the SCF will determine if the program currently broadcasted has HTTP-based file repair support. If this is not available for the UE, the session modification is rejected and the old MBMS session (along with the previous reserved resources) is maintained. Moreover, if broadcast/multicast repair is offered, SCF will 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). The UE in this case uses this URI to fetch the relevant SDP and executes SIP-based procedures to join the corresponding broadcast/multicast repair session.
If HTTP-based file repair is available for the UE, the SCF acting as a B2BUA can perform the following:
  • Upon reception of the SIP Re-INVITE from the UE, the SCF checks the user rights for the requested content, identifies that the request is for MBMS file repair procedures, selects a HTTP/SIP adapter and forwards the SIP INVITE request to the HTTP/SIP adapter which is in charge of the file repair service.
  • The SCF tears down the FLUTE-based MBMS download session between the BMSC.UPF and UE.
Step 6.
Upon reception of the MBMS file repair activation request, the HTTP/SIP adapter examines 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 sends an HTTP POST message to the HTTP server, including the IP address of the UE.
Step 7.
Upon reception of the HTTP POST message received from the HTTP/SIP adapter, the HTTP server answers to the HTTP/SIP adapter with a HTTP 200 OK response. The HTTP/SIP adapter returns 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.
Step 8.
The SCF forwards the SIP 200 OK to the IM CN subsystem. The IM CN subsystem forwards the SIP 200 OK to the UE.
Step 9.
After receiving the SIP 200 OK, the UE leaves the multicast channel and starts the MBMS file repair over HTTP/TCP/IP from the HTTP server.
These IMS-based procedures for MBMS file repair are depicted in Figure 1.
Copy of original 3GPP image for 3GPP TS 26.827, Figure 1:	Exemplary Procedures for IMS-based MBMS File Repair
Up

4.2  Use Case#2: Combining IMS-based Presence and DASHp. 8

4.2.1  Descriptionp. 8

An operator may wish to deploy IMS-based presence services in the context of DASH-based streaming. In an example, the UE 2 (presentity), who is watching DASH-formatted videos, is in the UE 1's (watcher) list of contacts and wants to publish the DASH content that it is currently watching.

4.2.2  Recommended Requirementsp. 8

 
  • It is possible for a DASH client (watcher) to subscribe for presence information for a list of contacts which includes another DASH client (presentity), by sending a SIP SUBSCRIBE message to the Presence Server.
  • After having initiated the DASH delivery, or after a DASH content switch, it is possible for a DASH client (presentity) to publish what content is being consumed by sending a SIP Publish message to the Presence Server, potentially, including additional attributes specific to DASH such as the content being consumed and the DASH media presentation description (MPD).
  • On reception of the SIP Publish, it is possible for the Presence server to notify a DASH client (watcher) of what another DASH client (presentity) is doing, by sending a SIP NOTIFY message.
  • It is possible to combine IMS-based presence and DASH for session initiation and/or content switching over both HTTP-based unicast transport and MBMS download delivery over FLUTE.
Up

4.2.3  Gap Analysisp. 9

The following gaps are identified:
  • The UE acting as presentity may send a SIP PUBLISH in the following cases:
    • On receipt of a final SIP 200 OK concerning a 3GP-DASH session initiation procedure.
    • On receipt of a final SIP 200 OK concerning a MBMS download session initiation procedure.
  • During a streaming session (including DASH-formatted content delivery), the UE may also send a PUBLISH request after having performed content switching. This includes the cases of:
  • PSS content switching (for both PSS streaming and 3GP-DASH services).
  • MBMS content switching (for both MBMS streaming and MBMS download services).
  • Switching from 3GP-DASH to MBMS download service with channel change.
  • Switching from MBMS download to 3GP-DASH service with channel change.
Up

4.3  Use Case#3: Combining MBMS and PSS Download Servicesp. 9

4.3.1  Descriptionp. 9

A mobile network operator offers download and progressive download content as part of its IMS-based PSS and MBMS service deployment. Some of this content includes popular files, making MBMS download delivery the method of choice for the operator. At the same time, the coverage for the MBMS infrastructure is limited, necessitating the usage of PSS-based unicast download methods. Enabling switching between PSS download and MBMS download delivery methods is desired for ensuring access to content without interruption.
Up

4.3.2  Recommended Requirementsp. 9

It is possible for the UE to employ SIP signalling procedures to initiate an IMS-based MBMS download session over FLUTE with the BM-SC and switch to HTTP-based PSS download service from an HTTP server through the use of an HTTP/SIP adapter.
It is possible for the UE to employ SIP signalling procedures to initiate an IMS-based PSS download session with an HTTP server and switch to IMS-based MBMS download service.
Upon receiving a SIP modification request from the UE to switch from FLUTE-based MBMS download to HTTP-based PSS download delivery, it is possible for SCF to:
  • check user rights and if granted, select a HTTP/SIP adapter to forward the SIP request;
  • tear down the FLUTE-based MBMS download session between the BM-SC.UPF and UE.
Upon receiving a SIP modification request from the UE to switch from HTTP-based delivery to FLUTE-based MBMS download delivery, it is possible for SCF to:
  • check user rights and if granted, initiate the FLUTE-based MBMS download session between the BM-SC.UPF and UE;
  • tear down the HTTP-based delivery session by notifying the HTTP/SIP adapter.
Up

4.3.3  Gap Analysisp. 10

Toward meeting the use case and recommended requirements for the combined MBMS and PSS download service, it is necessary to define SIP-based procedures for the following:
  • IMS-based switching from MBMS download to PSS download
  • IMS-based switching from PSS download to MBMS download

4.3.4  Solution Spacep. 10

4.3.4.1  IMS-based Switching from MBMS Download to PSS Downloadp. 10

Figure 2 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. If HTTP-based PSS download is available for the UE, the SCF acting as a B2BUA selects a HTTP/SIP adapter and sends the SIP INVITE request to the HTTP/SIP adapter which is in charge of the PSS download service.
  • 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.
Copy of original 3GPP image for 3GPP TS 26.827, Figure 2: Procedures for IMS-based switching from MBMS download to PSS download
Up

4.3.4.2  IMS-based Switching from PSS Download to MBMS Downloadp. 11

Figure 3 gives an overview about the procedures for IMS based switching from PSS download to MBMS download. The following steps are carried out:
  • Step 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.
  • Step 2: The IM CN subsystem forwards the SIP Re-INVITE message to the SCF.
  • Step 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 acting as B2BUA sends the SIP BYE message to the HTTP/SIP adapter in order to terminate the PSS download session, and initiates the FLUTE-based MBMS download session between the BM-SC.UPF and UE.
  • Step 4: The HTTP/SIP adapter sends an HTTP POST to the HTTP server.
  • Step 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.
  • Step 6: The HTTP/SIP adapter sends a SIP 200 OK answer to the SCF.
  • Step 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.
  • Step 8: The UE receives the MBMS download data using FLUTE.
Copy of original 3GPP image for 3GPP TS 26.827, Figure 3: Procedures for IMS-based switching from PSS download to MBMS download
Up

5  Conclusionp. 12

This technical report provides the following results of the IMS_SDE work item:
  • Descriptions of the use cases and enhancements
  • Documentation of any associated recommended requirements, assumptions, and gap analysis for each of the use cases

$  Change historyp. 13


Up   Top