In order to minimise the implementation efforts for a service provider to support both MBS and eMBMS distribution, further harmonisation of interfaces and functions is introduced in this Annex based on the architecture in clause 4.9.
Three main aspects are considered:
Only the MBS northbound reference points Nmb10 (Nmb5/N33) and Nmb8 are exposed respectively by the MBSF and MBSTF. These reference points are re-used or extended as required to support eMBMS transport. This is shown in Figure D.1.1-1, but the interfaces are marked with an asterisk to show the extension, if needed.
No modifications are needed at reference point Nmb8 to support MBMS data ingest. Hence the reference point is shown unmodified in Figure D.1.1-1.
Provisioning of MBS User Services at reference point Nmb10 (or Nmb5/N33) requires the ability to provide additional MBMS bearer-specific information. Hence, these reference points are shown with an asteriks in Figure D.1.1-1. Details are provided in the remainder of this annex.
User Service advertisement and delivery protocols are harmonised across eMBMS and MBS by extending the MBS User Service Announcement to support eMBMS-based distribution, using common delivery protocols. Such an approach permits a single MBS/eMBMS user service client that exposes unified APIs to UE applications.
Building on this aspect, the APIs in the client are largely agnostic to the delivery system such that UE applications are able to implement a single set of common APIs that can be used for MBS and eMBMS reception.
In this version of the specification, harmonization only based on group communication functionalities are presented. TR 26.802 also discusses other options.
In order to extend MBS User Services, a reference architecture based on eMBMS Group Communication functionalities is used. This is shown Figure D.1.2-1 where a subset of MB2 procedures and protocols is used southbound of the MBSF and MBSTF to communicate with the EPS via a function implementing the Group Communication functionality of a BM-SC.
According to TS 26.346, the Group Communication Service (GCS) AS, as defined by TS 23.468, uses the MBMS Group Communication delivery method on top of MBMS bearers for MBMS delivery. However, in general, the MBMS Group Communication delivery method is available for any application. In this case, the application interfaces to the BM-SC at reference point MB2'. This carries control plane signalling (via reference point MB2'-C) and user plane data (via reference point MB2'-U) between the Application Server for Group Communication (GCS AS) and the BM-SC.
The data transferred via MBMS bearer(s) is delivered from the BM-SC using the Group Communication delivery method as defined in TS 26.346. Stage 2 procedures between the GCS AS and the BM-SC at reference point MB2 are defined in TS 23.468.
In this deployment scenario, with reference to the interworking architecture defined in annex C of TS 23.247, the MBS User Service is treated as an application on top of the Group Communication delivery method:
The MBSF additionally implements the relevant subset of GCS AS control plane functionality, including MB2-C provisioning operations at a new reference point MB2'-C, allowing it to control a separate BM-SC that implements at least Group Communication functionality.
The MBSTF additionally implements the relevant subset of GCS AS user plane functionality, including MB2-U protocols at a new reference point MB2'-U to exchange user plane data with a separate BM-SC that implements at least Group Communication functionality.
A UE connecting to the E-UTRAN implements the relevant MBS User Service functionalities and the MBMS Client to support the reception of MBS User Services via the Group Communication API as defined in TS 23.479.
The MBMS Client only includes the Access Stratum in the UE modem as well as the functionality to provide the Group Communication API.
Figure D.1.2-2 provides an MBS/eMBMS interworking reference architecture for this purpose including the client architecture based on what is available in Figure D.1.2-1.
using Group Communication
In this case, the application only needs to have knowledge of the MBS Client but can use MBMS/GCS delivery. The MBS Client also plays the role of an MBMS/GCS-Aware Application that can use GCS API to consume MBS User Services from Group Communication packets delivered using the MBMS System.
In order to support the harmonized deployment architecture based on the reference architecture in clause D.1.2, no new architectural components are required. The following functional extensions to existing MBS functions defined in clause 4.3 are needed:
The MBSF as defined in clause 4.3.2 is extended as follows:
The MBSF supports the configuration of a BM-SC implementing Group Communication functionality at reference point MB2'-C using a relevant subset of service operations equivalent to those defined at reference point MB2-C.
The MBSTF as defined in clause 4.3.3 is extended as follows:
The MBSTF also may send MBS data packets via reference point MB2'-U to a BM-SC implementing Group Communication functionality using a relevant subset of procedures and protocols equivalent to those specified at reference point MB2-U.
The MBS Client as defined in clause 4.3.5 is extended as follows:
The MBSF Client is able to configure the MBSTF Client to receive Group Communication packets.
The MBSTF Client is able to receive MBS User Services data from a Group Communication Client using the GCS API.
In order to support the harmonised deployment architecture based on the reference architecture in clause D.1.2, no new reference points or interfaces are required externally to the joint BM-SC + MBSF function. The following extensions for reference points and interfaces as defined in clause 4.4 are needed:
MBS User Service provisioning at reference point Nmb10 is extended as follows:
An additional value of the MBS User Service parameter Service type defined in table 4.5.3-1 indicates transmission via MBMS.
Minimum parameters for MB2-C are provided in order to establish an MBMS bearer namely:
Temporary Mobile Group Identity (TMGI) allocated by the MBSF (i.e. joint BM-SC + MBSF function) to the corresponding MBMS bearer service,
MBMS Service Area, indicating the area over which the MBMS bearer service is to be distributed.
Radio frequency(ies) for transmitting the MBMS bearer service, as defined in TS 26.346 allocated by the MBSF (i.e. joint BM-SC + MBSF function) and returned to the provisioning MBS Application Provider acting as GCS AS.
The extended high-level baseline procedures for the MBS User Services architecture using Group Communication depicted in Figure D.1.2-2 are shown in Figure D.2-1, highlighting in boldface the extensions to the call flow compared with that in clause 5.2.
The Distribution Session provisioning, TMGI allocation and MBMS bearer allocation in steps 2, 3 and 4 are extended to address the allocation of bearers to support the MBMS distribution. The variant shown in the Figure allows the MBSF to handle the communicaton with the MBSTF and BM-SC.
In step 10, the MBSF Client provides information to the MBMS Client using the MC-MBMS-API in order to establish the MBMS bearer, involving also the MBSTF Client.
In step 11, the MBMS Client activates the MBMS session to receive Group Communication data and the MBSTF Client activates the MBS User Services session to receive MBS data conveyed in the MBMS session.
In step 13, MBS User Services session data is received through the MBMS bearer and directly provided to the MBSTF Client for relevant processing, for example FEC decoding, unicast repair determination and so on.