A.2 xMB Procedure example for Live DASH services (MBMS Broadcast only)

29.1163GPPRelease 18Representational state transfer over xMB reference point between content provider and BM-SCTS

This procedure example describes the xMB procedures for the delivery of a DASH Live service (see clause 11 of 3GPP TS 26.247 [18] for the specification of DASH Live services) , to a single broadcast area. A push interface like WebDAV is used here as the ingestion method for the user-plane data (xMB-U). The push interface is identified by a unique URI. The source of the user plane data (CP Source) are the DASH Media Segments as produced by a Live Encoder / Segmenter and the source pushes each new Segment when it becomes available. The Media Presentation Description (MPD) URL and Initialization Segment (IS) for the Live DASH session is provided to BM-SC during Session creation or in a subsequent update request to the BM-SC.

Figure A.2-1: xMB-C and xMB-U Procedures for a Live DASH Service

1: The operator and the Content Provider agree on a Service Level Agreement (SLA), which entitles the Content Provider to use the MBMS system (in accordance to some rules) for content delivery. For instance, the SLA can include day/time ranges, during which the Content Provider can distribute its content. The SLA can also include geographical areas in which the Content Provider is allowed to distribute its content. The SLA also includes target bitrates and likely definitions of tolerable losses per service.

2: The BM-SC administrators (operator) apply the agreed ranges. This can imply the provisioning of additional Service Areas, and other system related configurations.

The following steps describe Content Provider provisioning of a single Live DASH session in a single broadcast area.

3: The Content Provider authenticates itself as authorized user. The Content Provider can only see those configurations, sessions and services which belong to the Content Provider.

4: The Content Provider creates a new Service. Optionally, the Content Provider may provide properties for the service like service class, service languages, service names, notification configuration as well as consumption reporting configuration. The Content Provider can select whether the Content Provider or the operator distributes service announcement by providing a list of Service Announcement Channel (SACH, as defined in Annex L.2 / L.3 of 3GPP TS 26.346 [3]) services used for operator-driven service announcement.

NOTE 1: BM-SC derives the required UE capabilities from the provided service and session properties.

5: Upon successful service creation by the BM-SC, the BM-SC will provide a unique id for the service resource which is expected to be used by the Content Provider for subsequent requests.

6: The Content Provider retrieves the current service properties. The unique resource id of the service are provided by the Content Provider as input to the BM-SC. The BM-SC responds with the service properties.

7: The Content Provider updates service properties. The unique resource id of the service and some or all service properties are provided by the Content Provider as input to the BM-SC

8: The Content Provider creates a session for the previously created service. The unique resource id of the service are provided by the Content Provider as input to the BM-SC. Optionally, the Content Provider may provide common session properties such as maximum ingestion bitrate (excluding any FEC redundancy and transport overhead), scheduling information (start time, stop time), QoE Reporting configuration and session type (set to Application) as input. DASH specific session properties provided as input by the Content Providerinclude MIME-type of MPD fragment (here, set to application/dash+xml), Application Entry Point URL (here, the MPD URL), xMB-U ingest mode (push/pull), Unicast Delivery Indicator, etc.

NOTE 2: BM-SC allocates the following parameters for the session description of the MBMS User Service: TMGI, FLUTE IP Multicast Address, UDP Port and TSI (see IETF RFC 3926 [19]).

NOTE 3: BM-SC derives the SAI list for the MBMS Service Area from Geographical Area provided in Content Provider request and from PLMN id negotiated in step 1. FEC information (codec and ratio) and MBMS Bearer QoS (ARP, QCI) are also negotiated in step 1.

NOTE 4: The Service Announcement start time can be provided in the request. If not, BM-SC is expected to start announcing the service as soon as all required service and session properties are provided by the Content Provider.

NOTE 5: In the case of regionalized services, i.e. ones whose contents are region- specific, a session can be cloned so that all sessions of the user service share the same FLUTE parameters.

9: A unique resource id of the session, which identifies the created session, is returned by the BM-SC to the Content Provider. Additionally, the push URL ( whereby the required xMB-U ingest mode is set to push) and QoE Report URL are added to the response.

10: The Content Provider queries the session configurationby providing the resource ids of the session and service. The Content Provider needs the Push URL to configure the DASH segmenter. The BM-SC provides the information in the response, which includes all readable session properties.

11: The Content Provider updates the session by providing the DASH MPD URL (Application Entry Point URL). The BM-SC sends a response with update status.

12: Once all information for service announcement is available, and if service announcement start time has elapsed, the BM-SC starts announcing the service automatically. Service announcement is automatically updated following subsequent session updates.

The following steps pertain to the BM-SC activating automatically the MBMS Bearer at session start time. See 3GPP TS 26.346 [3] and 3GPP TS 29.061 [20] for further details.

13: The BM-SC activates the MBMS bearer by providing the TMGI, the Flow ID, the MBMS Service Area (MSA), the GBR and other parameters to the MBMS-GW.

14: When the Content Provider has configured a Notification URL for the service, the BM-SC delivers service/session related notification messages to the Content Provider.

15: When the MBMS bearer is activated, the BM-SC will start forwarding the xMB-U user plane data (push interface here). Any xMB-U user plane data received before activation of the MBMS bearer can be discarded.

16: At session stop time, the MBMS bearer is terminated.

17: The BM-SC can notify the Content Provider about the termination of the MBMS Bearer.

NOTE 6: The Content Provider terminates the service, when the service is not needed anymore. All sessions, which have been created or are active will be deleted automatically by BM-SC with the termination of the service.