Content for TS 26.346 Word version: 18.0.0

4.1 MBMS functional layers 4.2 MBMS User Service Entities 4.3 MBMS bearer service architecture 4.4 Functional Entities to support MBMS User Services 4.5 Usage of identity of MBMS session 4.6 Time Synchronization between the BM-SC and MBMS UEs
...

4 MBMS system description p. 23

4.1 MBMS functional layers p. 23

Three distinct functional layers are defined for the delivery of MBMS-based service. They are Bearers, Delivery method and User service. Figure 1 depicts these layers with examples of bearer types, delivery methods and applications.

Copy of original 3GPP image for 3GPP TS 26.346, Fig. 1: Functional Layers for MBMS User Service

Figure 1: Functional Layers for MBMS User Service
(⇒ copy of original 3GPP image)

Bearers:

Bearers provide the mechanism by which IP data is transported. MBMS bearers as defined in TS 23.246 and TS 22.146 are used to transport multicast and broadcast traffic in an efficient one-to-many manner and are the foundation of MBMS-based services. MBMS bearers may be used jointly with unicast PDP contexts in offering complete service capabilities.

Delivery Method:

When delivering MBMS content to a receiving application one or more delivery methods are used. The delivery layer provides functionality such as security and key distribution, reliability control by means of forward-error-correction techniques and associated delivery procedures such as file-repair, delivery verification. Four delivery methods are defined, namely download, streaming, transparent, and group communication. Delivery methods may be added beyond the current release. Delivery methods may use MBMS bearers and may make use of point-to-point bearers through a set of MBMS associated procedures.

User service:

The MBMS User service enables applications. Different applications impose different requirements when delivering content to MBMS subscribers and may use different MBMS delivery methods. As an example a messaging application such as MMS would use the download delivery method while a streaming application such as PSS would use the streaming delivery method, and a group communications application such as MCPTT would use the group communication delivery method.

4.2 MBMS User Service Entities p. 23

Figure 2 shows the MBMS user service entities and their inter-relations. Relation cardinality is depicted as well.

Copy of original 3GPP image for 3GPP TS 26.346, Fig. 2: Entities and Relations

Figure 2: Entities and Relations
(⇒ copy of original 3GPP image)

An MBMS user service is an entity that is used in presenting a complete service offering to the end-user and allowing him to activate or deactivate the service. It is typically associated with short descriptive material presented to the end-user, which would potentially be used by the user to decide whether and when to activate the offered service.

A single service entity can contain multiple distinct multimedia objects, streams, or object flows, which may need to be provided over various MBMS download session, MBMS streaming session, MBMS transparent session, or MBMS group communication delivery method. A download session or a streaming session is associated with either a unicast bearer or one or more MBMS bearers and a set of delivery method parameters specifying how content is to be received on the mobile side. A delivery method for the carriage of a group communication service through the MBMS system is associated with one or more MBMS bearers. A transparent session is associated with exactly one MBMS bearer. The MBMS User Service Session may be mapped either on MBMS Bearer Services or on unicast bearer services.

A set of one or more MBMS bearers can be used for delivering data as part of an MBMS download or streaming session. As an example, the audio and visual parts can be carried on separate MBMS bearers. However, it is recommended to transfer MBMS download and/or streaming sessions, which belong to the same MBMS user service on the same MBMS bearer service.

An MBMS bearer service (identified by TMGI) may be used to transport data for one or more MBMS download, streaming, transparent, or GC sessions (clause 5 of TS 22.246).

4.3 MBMS bearer service architecture p. 24

The MBMS Bearer Service Architecture is defined in TS 23.246. The MBMS User Service interfaces to the MBMS system via 3 entities.

The BM-SC.
The GGSN (for GPRS) or MBMS-GW (for EPS).
The UE.

In addition, for MBMS delivery of GCS (such as MCPTT application services), the group communication delivery method enables the MBMS Bearer Service to be accessed by the GCS Application Server (AS), via the MB2 interface between the AS and BM-SC, for carriage of application service data to the UE.

The BM-SC provides functions for MBMS user service provisioning and delivery to the content provider. It can also serve as an entry point for IP MBMS data traffic from the MBMS User Service source.

The GGSN (for GPRS) or MBMS-GW (for EPS) serves as an entry point for IP multicast traffic as MBMS data from the BM-SC.

4.4 Functional Entities to support MBMS User Services p. 24

4.4.1 MBMS User Service Architecture p. 24

Figure 3a and Figure 3b depict the MBMS network architecture showing MBMS related entities involved in providing MBMS user services.

Copy of original 3GPP image for 3GPP TS 26.346, Fig. 3a: MBMS network architecture model for GPRS

Figure 3a: MBMS network architecture model for GPRS
(⇒ copy of original 3GPP image)

Copy of original 3GPP image for 3GPP TS 26.346, Fig. 3b: MBMS network architecture model for EPS

Figure 3b: MBMS network architecture model for EPS
(⇒ copy of original 3GPP image)

MBMS User Service architecture is based on an MBMS receiver on the UE side and a BM-SC on the network side.

The use of the Gmb / SGmb and Gi / SGi-mb interface in providing IP multicast traffic and managing MBMS bearer sessions is described in detail in TS 23.246.

Details about the BM-SC functional entities are given in Figure 4.

Figure 3c depicts the MBMS network architecture showing MBMS related entities involved in providing Group Communication Services (such as MCPTT application services) delivery to the UE.

Copy of original 3GPP image for 3GPP TS 26.346, Fig. 3c: MBMS network architecture model for GCS delivery

Figure 3c: MBMS network architecture model for GCS delivery
(⇒ copy of original 3GPP image)

Copy of original 3GPP image for 3GPP TS 26.346, Fig. 4: BM-SC sub-functional structure

Figure 4: BM-SC sub-functional structure
(⇒ copy of original 3GPP image)

The Session and Transmission function is further subdivided into the MBMS Delivery functions and the Associated Delivery functions.

The BM-SC and UE may exchange service and content related information either over point-to-point bearers or MBMS bearers whichever is suitable. To that end the following MBMS procedures are provided:

User Service Discovery / Announcement providing service description material to be presented to the end-user as well as application parameters used in providing service content to the end-user.
MBMS-based delivery of data/content from the BM-SC to the UE over IP multicast or over IP unicast.
The data/content is optionally confidentiality and/or integrity protected
The data/content is optionally protected by a forward error correction code
IP multicast delivery of Group Communication application data (such as MCPTT), as an MBMS User Service which originates outside the BM-SC, over the MBMS Bearer Service.
Key Request and Registration procedure for receiving keys and key updates.
Key distribution procedures whereby the BM-SC distributes key material required to access service data and delivered content.
Associated Delivery functions are invoked by the UE in relation to the MBMS data transmission. The following associated delivery functions are available:
- File repair for download delivery method used to complement missing data.
- Delivery verification and reception statistics collection procedures.

The interfaces between internal BM-SC functions are outside the scope of the present document.

A "Proxy and Transport function" may be located between the "Session and Transmission Function" and the GGSN (for GPRS) or MBMS-GW (for EPS). The "Proxy and Transport function" is transparent to the "Session and Transmission function". The "Proxy and Transport" function is defined in sub-clause 5.1.3 of TS 23.246.

For Group Communication Service, the announcement of the MBMS bearer is performed by the GCS AS, when necessary. To enable the reception of Group Communication Service (such as MCPTT application service) data from the AS for delivery through the MBMS system, the BM-SC shall support the MB2 interface between the GCS Application Server (AS) and the BM-SC as specified in TS 29.468. As described in TS 29.468, Diameter messages are exchanged over the MB2-C interface, pertaining to procedures for the allocation (deallocation) and activation (deactivation) of the MBMS Bearer Service in the MBMS system, with associated information (e.g. QoS, start time, Flow Id, service area, radio frequency, BM-SC IP address) for the delivery of application data from the AS. Over MB2-U, GCS user plane data, encapsulated in UDP and IP, are transparently transported between the GCS AS (such as an MCPTT server) and the application client at the UE. The BM-SC, using the group communication delivery method, forwards these protocol layers transparently to the MBMS-GW.

4.4.1a Content Provider / Multicast Broadcast Source p. 27

The Content Provider/Multicast Broadcast Source may provide discrete and continuous media, as well as service descriptions and control data, to the BM-SC to offer services at a time. An MBMS User Service may use one or several MBMS delivery methods simultaneously. The Content Provider/Multicast Broadcast Source may also be a 3rd Party Content Provider/Multicast Broadcast Source.

The Content Provider/Multicast Broadcast Source function may reside within the operator's network or may be provided from outside the operator's network. The Content Provider/Multicast Broadcast Source can also configure the Session and Transmission functions (e.g. delivery or associated delivery). The interface between the Content Provider/Multicast Broadcast Source and the BM-SC is specified in TS 26.348.

4.4.1b Group Communication Service Application Server (GCS AS) |R13| p. 27

The GCS AS as defined by TS 23.468 uses the MBMS Group Communication delivery method on top of the MBMS bearers for MBMS delivery.

The GCS AS interfaces to the BM-SC using the MB2 interface. MB2 carries control plane signalling (via MB2-C) and user plane data (via MB2-U) between the GCS AS and BM-SC. The data transferred via MBMS bearer(s) is delivered from the BM-SC using the Group Communication delivery method. A GCS AS may transfer data from one or multiple GCS AS sessions via a single MBMS bearer. Description of the stage 2 procedures on MB2 between the GCS AS and the BM-SC is provided in TS 23.468. The stage 3 specification of the MB2 procedures and the protocol aspects of MB2-C and MB2-U are given in TS 29.468.

4.4.2 MBMS Key Management Function p. 27

The MBMS Key Management function is used for distributing MBMS keys (Key Distribution subfunction) to authorized UEs. Before the UE can receive MBMS keys, the UE needs to register to the Key Request subfunction of the Key Management function by indicating the MBMS User Service Id. Once registered, the UE can request missing MBMS keys from the BM-SC by indicating the specific MBMS key Id. In order for the UE to stop the BM-SC to send MBMS key updates a deregistration with the MBMS User Service Id is needed.

If the MBMS User Service does not require any MBMS data protection, then the UE shall not register for key management purposes.

A detailed description of all key management procedures is provided in TS 33.246.

4.4.3 MBMS Session and Transmission Function p. 28

The MBMS Session and Transmission function transfers the actual MBMS session data to the group of MBMS UEs using either MBMS Bearer Services or unicast bearer services. The MBMS Session and Transmission function interacts with the GGSN (for GPRS) through the Gmb Proxy function to activate and release the MBMS transmission resources. The MBMS Session and Transmission function interacts with the MBMS-GW (for EPS) through the SGmb Proxy function to activate and release the MBMS transmission resources.

The session and transmission function may compress headers of MBMS data in some cases. Further, the session and transmission function may need to add synchronization information for the MBMS payload e.g. in case of MBSFN transmissions. For details on usage of synchronization and header compression see TS 23.246 and TS 25.346.

The function contains the MBMS delivery methods, which use the MBMS bearer service for distribution of content. Further this function contains a set of Associated-Delivery Functions, which may be invoked by the UE in relation to the MBMS data transmission (e.g. after the MBMS data transmission).

The BM-SC Session and Transmission function is further described in later clauses of the present document as well as in TS 23.246.

MBMS user services data may be integrity and/or confidentiality protected as specified within TS 33.246, and protection is applied between the BM-SC and the UE. This data protection is based on symmetric keys, which are shared between the BM-SC and the UEs accessing the service.

MBMS user services may also be protected against packet loss between BM-SC and UE using a forward error correction code.

4.4.4 User Service Discovery / Announcement function p. 28

The User Service Discovery / Announcement provides service description information, which may be delivered via the Session and Transmission function or via the Interactive Announcement function. This includes information, which is necessary to initiate an MBMS user service as described in sub-clause 5.3.1. Metadata for the service descriptions are described in sub-clause 5.2.

4.4.5 Interactive Announcement Function p. 28

An Interactive Announcement Function may offer alternative means to provide service descriptions to the UE using HTTP or be distributed through other interactive transport methods.

4.4.6 MBMS UE p. 28

The MBMS UE hosts the MBMS User Services receiver function. The MBMS receiver function may receive data from MBMS bearer services or from unicast bearer services. The MBMS receiver function may receive data from several MBMS User Services simultaneously. According to the MBMS UE capabilities, some MBMS UEs may be able to receive data belonging to one MBMS User Service from several MBMS Bearer Services simultaneously. The MBMS receiver function uses interactive bearers for user service initiation / termination, user service discovery and associated delivery procedures.

In case the MBMS user service is secured, the UE needs one or more cryptographic MBMS service keys, therefore the UE requests the relevant cryptographic MBMS service keys using the BM-SC Key Request function. The received keys (i.e. MSK) are then used for securing the MBMS session. The MBMS UE should support the Application Programming Interfaces (APIs) and URL as specified in TS 26.347.

4.5 Usage of identity of MBMS session p. 29

The Session Identity of the MBMS session is provided with the MBMS session start procedure from the BM-SC to the GGSN (for GPRS) or MBMS-GW (for EPS) via the Gmb (for GPRS) or SGmb (for EPS) protocol in the MBMS Session Identity information element. The "MBMS Session Identity" information element is specified in TS 29.061. The size of the Session Identity field is 1 octet. The MBMS Session Identity is forwarded with the MBMS SESSION START REQUEST message through the system and received by the MBMS UE with the paging message.

The usage of the MBMS Session Identity is optional. The MBMS Session Identity is only applicable to MBMS download sessions. The MBMS transmission resources are activated as described in sub-clause 5.4. Each MBMS session of the MBMS User Service may be activated using a different MBMS Session Identity. The MBMS UE determines, based on the MBMS Session Identity value, whether the files of the upcoming MBMS download session were already received. If the files have already been completely received, the MBMS UE does not respond to the notification of the MBMS Session.

The association of MBMS Session Identities to files is determined by the BM-SC and communicated within the File Delivery Table. This association of a MBMS Session Identity to files is valid until a particular expiry time, also signalled within the File Delivery Table. If a UE has not received a File Delivery Table associating a given MBMS Session Identity to a specific file or set of files, or a previously received association has expired, then the UE shall assume that the MBMS Session Identity value is associated to new files which has not yet been received and shall respond as normal to MBMS notifications with that Session Identity value.

A single MBMS Session Identity value may be associated with a single file or with a set of files. Once a MBMS Session Identity value has been associated with a particular file or a set of files, this association shall not be changed before the expiry of the validity time for that MBMS Session Identity value. In particular, a File Delivery Table including some files that has previously been associated with a particular Session Identity value must include all files previously associated with that value, even if it is not intended to include all the files within the MBMS transmission session.

An FDT instance includes the MBMS Session Identity expiry time and associates the MBMS Session Identity expiry times with particular MBMS Session Identity values.

If the MBMS Session Identity is used by the BM-SC, the BM-SC shall also provide the session repetition number of that MBMS transmission session on the Gmb (for GPRS) or SGmb (for EPS) interface.

If the BM-SC starts using the MBMS Session Identity for one MBMS Bearer Service, the BM-SC may still decide not to use the MBMS Session Identity for a later MBMS transmission on that MBMS bearer service (e.g. when an MBMS download or streaming session is transmitted only once).

After determining that all files for a MBMS Session Identity value has been received, the UE shall not respond to MBMS notifications for the MBMS Bearer Service with that MBMS Session Identity value until the MBMS Session Identity is expired. Once the MBMS Session Identity has expired, the content is no longer guaranteed to be repeated, and therefore the UE may begin to respond to MBMS notifications for the associated MBMS Bearer Service.

The BM-SC may send FDT instances on a separate transmission session or interleaved with other data packets of the same transmission session. An FDT instance may describe more files than the files to be transmitted over the same transmission session as that FDT instance.

4.6 Time Synchronization between the BM-SC and MBMS UEs p. 29

A number of MBMS metadata fragments and File Delivery Table (FDT) contain NTP encoded time values. NTP uses UTC as reference time and is independent from time zones. In order to process the time information from the BM-SC correctly, the MBMS UEs shall be time synchronized with the BM-SC with a tolerance of +/- 1 second. The BM-SC shall offer an SNTP RFC 5905 time server. The MBMS UEs should use SNTP to synchronize the time with the BM-SC. It is expected that the MBMS UE periodically requests SNTP time synchronization in order to keep the +/- 1 second tolerance. However, the MBMS UE should use the SNTP time synchronization service only as necessary to keep +/- 1 second accuracy, and should at most use the SNTP time synchronization once every 24 hours to avoid scalability issues.

To further prevent scalability issues, the MBMS UE should randomize its periodic SNTP requests over 1 hour just preceding its determined SNTP request time.

SNTP time synchronization may be achieved either by using SNTP anycast RFC 5905, or SNTP unicast RFC 5905, depending on network support.

For network deployment where intermediate router nodes between the UE and BM-SC have anycast enabled, the BM-SC shall support the SNTP anycast mode. The MBMS UE sends a request to a designated IPv4 or IPv6 local broadcast address or multicast group address. One or more SNTP anycast servers reply and include a timestamp with their current time and its precision. BM-SC SNTP servers shall only respond if they have a valid synchronization time and shall not leave the timestamp blank, such that the SNTP Leap Indicator (LI) field shall not use the value 3 (warning: unsynchronised). The MBMS UE does not need to keep server address state data and changes in the SNTP server addressing will not affect each subsequent synchronization operation.

For IPv4, the Internet Assigned Numbers Authority (IANA) has assigned the multicast group address 224.0.1.1 for NTP, which is used by both multicast servers and anycast clients. For IPv6, the IANA has assigned the multicast group address FF0X:0:0:0:0:0:0:101. These NTP assignments apply to SNTP usage as well. The SNTP server will join these IP multicast groups.

For network deployment where intermediate router nodes between the UE and the SNTP servers do not have anycast enabled, the SNTP server(s) shall support unicast mode. The MBMS UE sends a request to the server using its pre-configured SNTP server address . The network may distribute the SNTP request traffic load to a pool of SNTP servers in the network, as long as the UE pre-configured SNTP server address is unchanged. The way the network performs this load distribution is out of scope of this specification. SNTP servers shall only respond if they have a valid synchronization time and shall not leave the timestamp blank, such that the SNTP Leap Indicator (LI) field shall not use the value 3 (warning: unsynchronized).

An MBMS UE shall select the SNTP mode to use as follows:

Attempt time synchronization using SNTP anycast;
If SNTP anycast procedure is successful then the UE should use SNTP anycast and continue using anycast for future periodic SNTP time synchronization over the same access network;
If the SNTP anycast procedure fails then it should use SNTP unicast and continue using unicast for future periodic SNTP time synchronization over the same access network.
In case of access network change detected by the UE, the UE should go to step 1 for its next periodic SNTP time synchronization.