Content for TS 26.346 Word version: 19.1.0

0… 4… 5… 5.3… 6 7… 7.3… 8… 8A… 8B… 9… 9.4… 10… 11… 12… A B… C… D… G… H… J… K… L… M…

5.3 User Service initiation/termination 5.4 MBMS data transfer procedure 5.4A Procedures between Content Provider and BM-SC 5.5 MBMS protocols 5.6 DASH and MBMS 5.7 Generic Application Service
...

5.3 User Service initiation/termination p. 43

5.3.1 Initiation of MBMS Bearer Service based User Services p. 43

MBMS User Service initiation refers to UE mechanisms to set-up the reception of MBMS User Service data. During the User Service Initiation procedure, a set of MBMS Bearers may be activated. The User Service initiation procedure takes place after the discovery of the MBMS User Service.

Copy of original 3GPP image for 3GPP TS 26.346, Fig. 6: Initiation of an MBMS User Service

Figure 6: Initiation of an MBMS User Service
(⇒ copy of original 3GPP image)

Step 1.

The User Service initiation procedure is triggered and takes a User Service Description as input that has been obtained e.g. by executing the MBMS User Service discovery and announcement functions.

Step 2.

The MBMS UE registers to the MBMS User Service, if registration is required for the MBMS User Service. If security functions are activated for the MBMS User Service, the MBMS UE requests MBMS service keys. The keys are sent to the UE, after the user is authorized to receive the MBMS service. The request shall be authenticated. Details on the MBMS User Service Registration procedure are described in TS 33.246.

Step 3.

The MBMS UE uses the MBMS activation procedure to activate the MBMS Bearer Service. The MBMS activation procedure is the MBMS Multicast Service activation procedure, and the MBMS Broadcast activation procedure as defined in TS 23.246. In case the MBMS Broadcast Mode is activated, there is no activation message sent from the UE to the BM-SC. The activation is locally in the UE. Note that the MBMS Bearer Services may already be active and in use by another MBMS User Service.

Step 3n.

In case the MBMS User Service uses several MBMS Bearer Services, the User Service Description contains several description items. In that case, the MBMS receiver function repeats the activation procedure for each MBMS Bearer Service as described in 3.

5.3.2 Termination of MBMS Bearer Service based User Services p. 43

MBMS User Service termination refers to the UE mechanisms to terminate the reception of MBMS User Services. A set of MBMS Bearers may be deactivated during this procedure.

Copy of original 3GPP image for 3GPP TS 26.346, Fig. 7: Termination of an MBMS user service

Figure 7: Termination of an MBMS user service
(⇒ copy of original 3GPP image)

Step 1.

The User Service termination procedure is triggered. A reference to the User Service to terminate is provided as parameter.

Step 2.

The MBMS UE deregisters, when registration was required for the MBMS User Service. If security functions are activated for the MBMS User Service, the MBMS UE deregisters the security association for the MBMS User Services. Details on the MBMS User Service Deregistration procedure are described in TS 33.246.

Step 3.

If no other MBMS User Service uses the MBMS Bearer service, the MBMS UE uses the MBMS deactivation procedure to deactivate the MBMS Bearer Services. The MBMS deactivation procedure represents the MBMS Multicast service deactivation procedure and the MBMS Broadcast deactivation procedure as described in TS 23.246. In case the MBMS Broadcast Mode is deactivated, there is no message sent to the BM-SC. The deactivation is only locally in the UE.

Step 3n.

In case the MBMS User Service uses several Bearer Services, the UE repeats the deactivation procedure for each Bearer Service as described in 3.

5.3.3 Initiation of Unicast Bearer Service based User Services |R7| p. 44

Unicast Bearer Service based MBMS User Service initiation refers to the mechanisms to set-up the reception of MBMS User Service data via a UMTS/EPS Bearer Service with interactive and/or streaming traffic class.

In case of the initiation of a MBMS Streaming delivery method or a combined MBMS Streaming and MBMS Download delivery method, the Packet Switched Streaming Service (PSS) as defined in TS 26.234 shall be used. The establishment of a PSS session is described in clause 5.1 of TS 26.234.

In case of the initiation of a MBMS Download delivery method, the MBMS UE is registered in the BM-SC for OMA-PUSH based reception of the files with the BM-SC.

5.3.4 Termination of Unicast Bearer Service based Services |R7| p. 44

Unicast Bearer Service based MBMS User Service termination refers to the mechanisms to terminate the reception of MBMS user service data via a UMTS/EPS Bearer Service with interactive and/or streaming traffic class.

In case of the termination of a MBMS Streaming delivery method or a combined MBMS Streaming and MBMS Download delivery method, the Packet Switched Streaming Service (PSS) as defined in TS 26.234 shall be used. The termination of a PSS session is described in clause 5.3 of TS 26.234.

In case of the termination of a MBMS Download delivery method, the MBMS UE is deregistered in the BM-SC so that the OMA-PUSH based reception of the files with the BM-SC will be terminated.

5.3.5 Scalable service initiation and termination for MBMS Services |R7| p. 45

5.3.5.1 General p. 45

MBMS service initiation and termination as defined in clauses 5.3.1 to 5.3.4 may consist of network interactions such as sending an IGMP Join or Leave message to the network as described in clauses 8.2 and 8.7 of TS 23.246. Initiation and termination procedures may be triggered at the MBMS UE by the user or be scheduled to happen automatically. Upon (or after) receiving a user service announcement, the MBMS UE may render the information about the advertised services to the user to assist him in the service selection. The user may decide to receive a given service and hence trigger the service initiation procedure. Alternatively, the user may declare his interest in a specific service a priori and upon receiving the service announcement for that specific service, the MBMS UE may schedule the initiation procedure at or around the start time of the session. Similarly, the MBMS UE may schedule the termination procedure at or around the session end time.

As a consequence, MBMS UEs may be oriented to start their service initiation and termination procedures at the same time or during a relatively short period. This may cause network congestion, especially during the multicast of a popular service, as all MBMS UEs may be time synchronized.

5.3.5.2 Randomization of service initiation over time p. 45

The MBMS User Service description may contain parameters to uniformly randomize the User Service Initiation procedures of the MBMS UEs. Security functions may be part of the User Service Initiation procedure as defined in clause 5.3.1. If a user service initiation randomization is defined for a user service, then the overload prevention definition in the Security Description shall be ignored for the service initiation. For randomizing the time of the initiation procedure, the MBMS UE shall understand the following parameters, which may be signalled by the BM-SC in the MBMS User Service description as described in clause 11.2.1:

initiationStartTime parameter is used by the BM-SC to signal to the MBMS UE the start time for the User Service Initiation procedure randomization period. If the initiationStartTime parameter is not present, the MBMS UE uses the time of the Service Announcement reception as the start time.
protectionPeriod parameter is used by the BM-SC to signal to the MBMS UE the duration of the critical time periods, during which congestion shall be avoided. The MBMS UEs shall randomly spread the initiation procedure using the randomTimePeriod during this protection period.
randomTimePeriod parameter is used by the BM-SC to signal to the MBMS UE the duration of an interval over which initiation procedures shall be randomly deferred. The MBMS UE calculates a random time out of the randomTimePeriod interval to defer the execution of the initiation procedure.

The MBMS UE shall start its initiation procedure immediately if the procedure is triggered outside of protection periods.

5.3.5.3 Randomization of service termination over time p. 45

The MBMS User Service description may contain parameters to uniformly randomize the User Service Termination procedures of the MBMS UEs. For randomizing the time of the termination procedure, the MBMS UE shall understand the following parameters, which may be signalled by the BM-SC in the MBMS User Service Description as described in clause 11.2.1:

protectionPeriod parameter is used by the BM-SC to signal to the MBMS UE the duration of the critical time period, during which congestion needs to be avoided. The MBMS UEs shall randomly spread the termination procedure using the randomTimePeriod during this period and starting from the session end time.
randomTimePeriod parameter is used by the BM-SC to signal to the MBMS UE the duration of an interval over which termination procedures shall be randomly deferred. The termination procedure is only randomized during the protectionPeriod.

If the termination procedure is triggered before the session end time or after the protection period end time, the MBMS UE shall start its termination procedure immediately. If it is in a protection period, the MBMS UE shall defer its termination procedure to a random time spread over an interval of duration randomTimePeriod.

5.4 MBMS data transfer procedure p. 46

5.4.1 MBMS data transfer procedure using MBMS Bearer Services |R7| p. 46

MBMS data Ttansfer procedure using MBMS Bearer Services refers to the network (and UE) mechanism to transfer (and receive) data for one MBMS User Service on one or several MBMS Bearer Services.

Copy of original 3GPP image for 3GPP TS 26.346, Fig. 8: Procedure of MBMS data transfer

Figure 8: Procedure of MBMS data transfer
(⇒ copy of original 3GPP image)

Step 1.

The MBMS Delivery Method for the MBMS User Service is triggered by the MBMS User Service Provider. Note, details of the trigger are beyond of the present document.

Step 2-2n.

The MBMS Delivery function uses the MBMS Session Start Procedure to the GGSN and/or MBMS-GW, possibly through the Gmb Proxy and/or the SGmb Proxy function to activate all MBMS Bearer Services, which belong to the MBMS User Service. The MBMS Bearer service to be activated is uniquely identified by the TMGI.

Step 3-3n.

The data of the MBMS User Service are transmitted to all listening MBMS UEs. Several MBMS Bearer services may be used to transmit the MBMS User Service data. MBMS User Service data may be integrity- and/or confidentiality-protected. In case MBMS User Service data are integrity and/or confidentiality protected, MBMS traffic keys are delivered simultaneously on the same or a different MBMS bearer. Optionally, synchronization information for MBSFN may be added to the MBMS User Data. The headers of MBMS User Data may optionally be compressed (see TS 23.246 and TS 25.346)

Step 4-4n.

The MBMS Delivery function uses the MBMS Session Stop procedure to trigger the GGSN and/or MBMS-GW, possibly through the Gmb and/or SGmb Proxy function to release all MBMS Bearer Service for this User Service. A unique identifier for the MBMS Bearer service to be deactivated (i.e. the TMGI) is passed on as a parameter.

Step 5.

In case associated delivery procedures are allowed or requested for an MBMS User Service, the MBMS UE sends an associated-delivery procedure request to the associated -delivery function. The BM-SC may authenticate the user. See TS 33.246. The MBMS UE may need to wait a random time before it starts the associated delivery procedure according to clause 9.

5.4.2 MBMS data transfer procedure using other UMTS Bearer Services |R7| p. 47

MBMS data transfer procedure using other UMTS Bearer Services refers to the network (and UE) mechanism to transfer (and receive) data for one MBMS User Service on one or more Unicast Bearer Services.

In case the MBMS Data belong to a MBMS streaming session or a combined MBMS streaming and MBMS download session, the Packet Switched Streaming Service (PSS) as defined in TS 26.234 shall be used.

In case the MBMS Data belong to a MBMS download session, the MBMS data is transferred using OMA-PUSH.

5.4A Procedures between Content Provider and BM-SC |R14| p. 47

The reference point between Content Provider and BM-SC is named xMB. This reference point is specified in TS 26.348.

5.5 MBMS protocols p. 47

Figure 9 illustrates the protocol stack used by MBMS User services for Streaming and Download delivery. The grey-shaded protocols and functions are outside of the scope of the present document. MBMS security functions and the usage of HTTP-digest and SRTP are defined in TS 33.246, and 3GP-DASH is defined in TS 26.247.

Copy of original 3GPP image for 3GPP TS 26.346, Fig. 9: Protocol stack view of the MBMS User Services for Streaming and Download Delivery

Figure 9: Protocol stack view of the MBMS User Services for Streaming and Download Delivery
(⇒ copy of original 3GPP image)

5.6 DASH and MBMS |R9| p. 47

The 3GPP Dynamic Adaptive Streaming over HTTP (3GP-DASH) as defined in TS 26.247 specifies formats and methods that enable the delivery of streaming service(s) from standard HTTP servers to 3GP-DASH client(s). It specifies the description of a collection of Media Segments and auxiliary metadata (all referenced by HTTP-URLs) through a Media Presentation Description (MPD). In addition, ISO/IEC 23009-1 [116] defines DASH services.

MBMS is designed to serve large receive groups with same content. The MBMS Download Delivery Method is designed to deliver an arbitrary number of objects via MBMS to a large receiver population. MBMS download delivery defines several methods to increase reliability such as FEC and file repair. The download delivery method allows the delivery of 3GP-DASH Segments, Media Presentation Descriptions, as well as other objects referenced in the MPD as defined in TS 26.247.

In order to support DASH Streaming in MBMS, the USBD metadata fragment for a service shall contain either or both a r9:mediaPresentationDescription element referencing an MPD, and a r12:appService referencing an MPD, which is also a metadata fragment describing the service. The referenced MPD corresponds to a metadata fragment as defined in TS 26.247. If the USBD contains a reference to an MPD containing broadcast Representation(s), then

The User Service shall be a download delivery service, i.e. shall include at least one deliveryMethod element referencing an SDP that describes FLUTE transport.
If objects are not already provided during MBMS User Service Announcement, the MBMS download session shall deliver objects that are referenced by the MPD, all updates of the MPD and objects that are referenced by any update of the MPD, which are not already provided during MBMS User Service Announcement.
If a Segment is delivered as a FLUTE object then all of the following shall hold:

a)
The MBMS download session shall deliver segments such that the last packet of the delivered object is available at the UE latest at its segment availability start time as announced in the MPD.

b)
The Content-Location element in the FDT for the delivered object shall match the Segment URL in the MPD.
If an MPD update (with or without a metadata envelope) is delivered as a FLUTE object then all of the following shall hold:

c)
The URL of the delivered object shall match the URI of the appropriate referenced MPD.

d)
The MPD update shall be a valid update to a previously delivered MPD or an MPD delivered during MBMS User Service Announcement.
If an Initialization Segment (with or without a metadata envelope) is delivered as a FLUTE object then the URI of the delivered object shall match the appropriate reference in the MPD.
If any other resource in the MPD is delivered (e.g. xlinked resource, metrics, etc.) then

e)
The Content-Location element in the FDT Instance for the delivered object shall match the URL of the object in the MPD.

f)
The MBMS download session shall deliver objects such that the last packet of the delivered object is available at the UE latest at the earliest time a DASH client operating on the delivered MPD sequence may ask for the resource.

In the case a real-time streaming service is provided as DASH streaming over MBMS, then the MPD@type (attribute 'type' of the MPD) shall be set to "dynamic", i.e. this indicates that the segments get available over time, latest at its announced segment availability start time. When MPD@minimumUpdatePeriod (attribute 'minimumUpdatePeriod' of the MPD) is present, then the UE should expect MPD updates to be sent in the FLUTE session with the media segments and treat these updates as defined in step 4 above.

The objects delivered with the MBMS download delivery method shall be formatted according to the announcement in the MPD. The MPD and the described Media Presentation should conform to a profile specified in TS 26.247.

Furthermore, the Media Presentation Description fragment may contain reference(s) to Initialization Segment Description fragment(s) whose content is an Initialization Segment as defined in TS 26.247.

If the DASH Media Presentation conforms to the DASH Profile for CMAF content as defined in ISO/IEC 23009-1 [116], then the DASH Media Presentation follows the constraints for the CMAF Segment formats and additional CMAF constraints. In this case, the userServiceDescription element should contain an r12:appService element with a MIME type containing "application/dash+xml profiles=' urn:mpeg:dash:profile:cmaf:2019'" indicating that the DASH Media Presentation conforms to DASH Profile for CMAF content as defined in [116]. The MBMS distributed CMAF content may be consumed by streaming clients that support playback of CMAF content. The announcement of CMAF content to such a CMAF capable streaming client is implementation-specific.

If a Hybrid DASH/HLS service is provided as DASH over MBMS, then the content should conform to DASH Profile for CMAF content as defined in ISO/IEC 23009-1 [116] and the announcement in the userServiceDescription element should be provided as documented above.

The r9:mediaPresentationDescription element refers to an MPD which describes only the Representation(s) available over the MBMS bearer(s), and shall be used by UEs complying to previous versions of this specification.

The r12:appService element may refer to a unified MPD which describes Representations available for both broadcast and unicast reception, and shall be used by UEs compliant to this specification. If r12:appService element is absent, and r9:mediaPresentationDescription element is present, then a UE complying with this release of the specification shall use the r9:mediaPresentationDescription. This case also applies to UE compliant to the current release of this specification, deployed in networks of a previous releases not having r12:appService element defined. In practical deployments, different subsets of the Representations described by the unified MPD and referenced by such r12:appService may be specified for

broadcast only availability
both unicast and broadcast availability,
unicast only availability and the Representation is redundant in broadcast coverage, i.e. the usage of these resources does not provide an improved user experience. As an example, this may be a lower bitrate Representation of a media component for which a higher bitrate is available over broadcast, and
unicast always availability and the Representation is supplementary in broadcast coverage, i.e. even in broadcast coverage these resources provide an improved user experience. As an example, this may be a secondary language that is only accessible over unicast.

For more details on consistent signalling for resources in hybrid service offerings, refer to clause 7.6.

Clause 4.4.3 of this specification enables integrity and/or confidentiality protection of MBMS user services data according to TS 33.246. In this case each DASH formatted file is protected using the Protection of Download Data as described in TS 33.246.

As this protection mechanism is performed in the underlying layer of the DASH client it is transparent to 3GP-DASH client and not reflected in the MPD associated to the DASH representation.

For HTTP streaming, QoE reporting on MBMS level can be activated as described in clause 8.3.2.1 or 8.3.2.2, and QoE reporting shall in such case be done as specified in clause 8.4. The Network Resource, Loss of Objects, and Distribution of Symbol Count Underrun for Failed Blocks QoE metrics are relevant to DASH over MBMS.

QoE reporting can also be activated on DASH level as specified in clause 10 or Annex F of TS 26.247, and reporting shall in such case be done according to TS 26.247.

Media decoders for DASH streaming as defined in this clause delivered over MBMS are specified in clause 10 of this specification.

DASH streaming may also be switched from MBMS to unicast. In the case of PSS-based delivery, the media decoders for DASH are specified in clause 7.3.6 of TS 26.247.

Service interactivity functionality may be supported in a DASH-over-MBMS service. If supported, such functionality shall be implemented in accordance with TS 26.247 as follows:

by the BM-SC: delivery of interactivity event signaling as described in clause 15 of TS 26.247, and
by the DASH client: processing of interactivity event signaling, and forwarding of event metadata to the subscribing service interactivity application, as described in clause 15 of TS 26.247.

5.7 Generic Application Service |R12| p. 49

If the USD contains an Application Service Description fragment, then all resources that are directly or indirectly referenced in the application service entry point document instance of this metadata fragment, and are expected to be retrieved by HTTP GET, shall be delivered by at least one of the delivery methods associated with the r12:appService element. For more details on consistent signalling for resources in potentially hybrid service offerings, refer to clause 7.6.

In order to support generic application services in MBMS, the User Service Bundle Description metadata fragment shall contain an r12:appService element referencing an Application Service Description metadata fragment which describes the service. That application service entry document shall be formatted according to the value of the mimeType attribute. If the USD contains a reference to an application service entry document containing broadcast-delivered objects, then

The user service shall be a download delivery service, i.e. shall include at least one deliveryMethod element referencing an SDP that describes FLUTE transport.
The MBMS download session shall deliver objects that are directly or indirectly referenced by the service entry document.
If an object is delivered as a FLUTE object with an availability time defined by service is delivered then all of the following shall hold:
1. The MBMS download session shall deliver the objects such that the last packet of the delivered object is available at the UE latest at its availability time as announced in the application service document
2. The Content-Location element in the FDT for the delivered object shall match the URL in the application service document.
If an update to the application service document is delivered as a FLUTE object then the Content-Location element in the FDT for the delivered object shall match the URI of the appropriate referenced application service document by using the r12:appService element and the document referenced by this element

Clause 4.4.3 of the present document enables integrity and/or confidentiality protection of MBMS user services data according to TS 33.246. In this case each object is protected using the Protection of Download Data as described in TS 33.246.

QoE reporting on MBMS level can be activated as described in clauses 8.3.2.1 or 8.3.2.2, and QoE reporting shall in such case be done as specified in clause 8.4. The Network Resource, Loss of Objects, and Distribution of Symbol Count Underrun for Failed Blocks QoE metrics may be used to generic application services.

For any application service which is not a DASH-over-MBMS service, a) its service definition and any specialized handling for service delivery over MBMS, and b) the content format with the exception that it is an HTML5 document, management and hosting of the associated Application Service Description are outside the scope of this specification.