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.

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

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.

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: These IMS-based procedures for MBMS file repair are depicted in Figure 1.

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.

 

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

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.

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.

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.

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