A.1 Generic File Delivery

26.3483GPPNorthbound Application Programming Interface (API) for Multimedia Broadcast/Multicast Service (MBMS) at the xMB reference pointRelease 17TS

A.1.1 Introduction

This clause illustrates the various xMB-U options for generic file delivery. A file many be a large file like a video on demand file or a small file. Files can also be regarded as messages e.g. a plain text file or with header and body.

A.1.2 File ingestion with Pull

The Content Provider delegates all MBMS related complexity to the operator and provides files for delivery using HTTP to the BM-SC. The Content Provider provides the file URLs to the BM-SC and the BM-SC fetches the files using HTTP. The BM-SC is handling all MBMS related complexity, e.g. converting the HTTP payload into an IP Multicast suitable protocols, adding AL-FEC, etc. The Content Provider delegates the delivery of MBMS of Service Announcement Metadata (i.e. IP Multicast protocol details, etc) to the MBMS Client to the BM-SC.

Figure A.1.2-1 illustrates a setup, where the BM-SC pulls files from a File Server. The xMB-C is used to provide the file URLs to the BM-SC.

Figure A.1.2-1: File Delivery using Pull Mode (HTTP GET)

The following Session Properties allow the configuration of this xMB-U mode:

– Session Type is set by the Content Provider to Files.

– Ingest Mode (Session Type specific property) is set by the Content Provider to Pull.

– The File List (Session Type specific property) is updated by the Content Provider with File URLs to be fetched by the BM-SC and then send. The BM-SC updates Service Announcement according to the File List information.

Procedure

The following flow diagram illustrates the message flow. During provisioning phase, the according xMB Service and Sessions are created. Some lead time is needed to secure that all intended receiving UEs are capable of receiving the content.

Figure A.1.2-2: Call Flow

Provisioning

1: The Content Provider creates the File Delivery Service and Session using xMB procedures.

2: As result of the Service and Session provisioning procedure, the Content Provider gets the service identification information (e.g. ServiceId), which needs to be used by the App to request the reception activation from the MBMS Client.

3: When a File Schedule should be inserted into service announcement, the content provider provides the full file list well in advance. The BM-SC determines the file sizes and creates the resulting file schedule entry.

4: The MBMS client receives the service access information via SACH.

5: When the App is interested in the service, the App requests the MBMS client to activate reception using the appropriate MBMS Client API call. The App uses the ServiceId as identification for the interested service.

At scheduled File Delivery Session start time.

6: When not all file URLs to be sent during the file delivery session are provided, the Content Provider updates the File List and adds additional file entries.

7: The BM-SC fetches the file according to the file list.

8: The BM-SC receives the requested file and wraps it into MBMS Download Delivery Objects.

9: The BM-SC sends the file as MBMS Download Delivery Object. When the MBMS Client has activated the reception for that service and is located inside of the broadcast coverage, the MBMS client receives the file (potentially after correcting packet losses).

10: When the MBMS Client has successfully received the file, it notifies the App.

11: Step 6 can be repeated multi times, independent from steps 7 to 9. Steps 7 to 9 are repeated (as sequence) for every file in the file list until the session schedule end time is reached.

A.1.3 File ingestion with Push

The Content Provider delegates all MBMS related complexity to the operator and provides files for delivery using HTTP to the BM-SC. The Content Provider pushes the files using HTTP. The BM-SC is handling all MBMS related complexity, e.g. converting the HTTP payload into an IP Multicast suitable protocols, adding AL-FEC, etc. The Content Provider delegates the delivery of MBMS of Service Announcement Metadata (i.e. DASH MPD, IP Multicast protocol details, etc) to the MBMS Client to the BM-SC.

Figure A.1.3-1 illustrates a setup, where a File Server pushes files using HTTP PUT into the BM-SC.

Figure A.1.3-1: File Delivery using Push Mode (HTTP PUT)

The following Session Properties allow the configuration of this xMB-U mode:

– Session Type is set by the Content Provider to Files.

– Ingest Mode (Session Type specific property) is set by the Content Provider to Push.

– The BM-SC provides the Push URL (Session Type specific property) to the Content Provider. The value of this property is configured to the File Server.

– Display Base URL contains the base URL for the files. In the URLs, used in the FLUTE FDT instances and (in some cases) in Service Announcement, the BM-SC replaces the Push URL part of the file URL with the value of the Display Base URL.

Procedure

The following flow diagram illustrates the message flow. During provisioning phase, the according xMB Service and Sessions are created. Some lead time is needed to secure that all intended receiving UEs are capable of receiving the content

Figure A.1.3-2: Call Flow

Provisioning:

1: The Content Provider creates the File Delivery Service and Session using xMB procedures.

2: As result of the Service and Session provisioning procedure, the Content Provider gets the service identification information, which needs to be used by the App to request the reception activation from the MBMS Client.

3: The MBMS client receives the service access information via SACH.

At scheduled DASH Session start time.

4: The content provider starts pushing files to the BM-SC, which wraps the received file into MBMS Download Delivery Objects.

5: The BM-SC sends the File as MBMS Download Delivery Object.

6: Step 5 and 6 are repeated for every file until the session schedule end time is reached.