7.3 Use of MBMS transmission (on-network)

23.2823GPPFunctional architecture and information flows to support Mission Critical Data (MCData)Release 18Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.3.1 Information flows for MBMS Transmission

Information flows for generic MBMS procedures are defined in 3GPP TS 23.280 [5].

7.3.2 Use of pre-established MBMS bearers

The MCData service shall support the procedure for using pre-established MBMS bearers as specified in 3GPP TS 23.280 [5] with the following clarifications:

– The MC service client is the MCData client;

– The MC service server is the MCData server; and

– The MC service ID is the MCData ID.

The MCData service shall use the MCData-6, MCData-SDS-1, MCData-SDS-2, MCData-SDS-3, MCData-FD-1, MCData‑FD-3, MCData-DS-1 and MCData‑DS-3 reference points for this procedure.

MCData may use pre-established MBMS bearer for the MCData features short data service, file distribution and data streaming. The MBMS bearer can be used by any group. Depending on the capacity of the MBMS bearer, the bearer can be used to broadcast one or more services in parallel.

Both the media packets as well as application level control signalling (e.g. transmission control) to the receiving users may be sent on the MBMS bearer. Optionally, a separate MBMS bearer could be used for the application level control signalling (e.g. transmission control), due to different bearer characteristic requirements.

7.3.3 Use of dynamic MBMS bearer establishment

The MCData service shall support the procedure for using dynamic MBMS bearers as specified 3GPP TS 23.280 [5] with the following clarifications:

– The MC service client is the MCData client;

– The MC service server is the MCData server; and

– The MC service ID is the MCData ID.

The MCData service shall use the MCData-6, MCData-SDS-1, MCData-SDS-3, MCData-FD-1, MCData‑FD-3, MCData-DS-1 and MCData-DS-3 reference points for this procedure.

MCData may use dynamic MBMS bearer for the MCData features short data service, file distribution and data streaming. The MBMS bearer can be used by any group. Depending on the capacity of the MBMS bearer, the bearer can be used to broadcast one or more services in parallel.

7.3.4 Switching from MBMS bearer to unicast bearer

The MCData service shall support the procedure for switching from MBMS bearer to unicast bearer as specified 3GPP TS 23.280 [5] with the following clarifications:

– The MC service client is the MCData client;

– The MC service server is the MCData server; and

– The MC service ID is the MCData ID.

The MCData service shall use the MCData-SDS-1, MCData-SDS-2, MCData-FD-1, MCData‑FD-3, MCData-DS-1 and MCData‑DS-3 reference points for this procedure.

7.3.5 Use of MBMS user services for file distribution

7.3.5.1 General

This subclause defines information flows and procedures for usage of MBMS user services that applies to MCData file distribution. MBMS user services can be used for any MC service group.

The MBMS user service architecture is described in 3GPP TS 26.346 [21].

NOTE: The current specification does not cover MCData end-to-end encryption file distribution using MBMS when the BM-SC is in the MCData system trust domain.

7.3.5.2 Information flows for MBMS user service usage

7.3.5.2.1 MBMS user service announcement

Table 7.3.5.2.1-1 describes the information flow MBMS bearer announcement from the MCData server to the MCData client.

Table 7.3.5.2.1-1: MBMS user service announcement

Information element	Status	Description
MBMS user service id	M	Id of the MBMS user service
SA file	M	The service announcement file as returned in the create/update session response (subclause 5.4 in 3GPP TS 26.348 [19]) (see NOTE)
Monitoring state	O	The monitoring state is used to control if the client is actively monitoring the reception quality or the MBMS bearer used by the MBMS user service.
Unicast status	O	An indication that the listening status of the unicast bearer is requested.
NOTE: The SA file provides the TMGI, the list of MBMS service area identifiers, the frequency and the delivery parameters.

7.3.5.3 Procedures for MBMS user service usage

7.3.5.3.1 Use of pre-established MBMS user services

7.3.5.3.1.1 General

In this scenario, the MCData server pre-establishes MBMS user service(s) in certain pre-configured areas before the initiation of a group file distribution. When a user originates a request for a file distribution in one of these areas, the MCData server can use the pre-established MBMS user service(s) for the DL media transmission.

The MBMS user service can be announced prior to the file distribution or within the signalling message for the file distribution.

The MBMS user service does not transmit application level control signalling. An MBMS bearer could be used for the application level control messages according to the generic MBMS procedures defined in 3GPP TS 23.280 [5].

7.3.5.3.1.2 Procedure

Editor’s note: The procedure in this clause needs to be revised considering that MBMS user services, as specified in 3GPP TS 26.346 [21], cannot be supported over the MB2 interface.

The procedure figure 7.3.5.3.1.2-1 shows only one of the receiving MCData clients using an MBMS user service.

Pre-conditions:

– The participating users are already affiliated.

Figure 7.3.5.3.1.2-1: Use of pre-established MBMS user service

1. The MCData server determines to create an MBMS user service with a given MBMS user service id. If the MCData server makes use of the xMB interface, the MCData server creates an MBMS user service over xMB-C (subclause 5.3 from 3GPP TS 26.348 [19]).

NOTE 1: The procedure to determine the creation of MBMS user services is implementation specific.

2. If the MCData server makes use of the xMB interface, the MCData server creates an MBMS session over xMB-C for the MBMS user service (subclause 5.4 from 3GPP TS 26.348 [19]), with the type set to "Files" to use the MBMS download delivery method. Additionally, the MCData server defines the ingest mode, pull or push, to provide the file into the BM‑SC via xMB‑U. This MBMS session will be used for file distribution. In response, the MCData server gets the TMGI of the MBMS bearer used for the MBMS session, and the SA file containing the metadata of the MBMS user service. When the push ingest mode is used, as part of the response from the BM‑SC the MCData server also obtains the URL to be used to push the file.

3a. Else, the MCData server activates an MBMS bearer over MB2-C for the MBMS user service.

3b. The MCData server, if not already in the possession of the SA file, generates the SA file containing the metadata of the MBMS user service.

4. The MCData server passes using control plane signalling the MBMS user service info for the service description associated with the pre-established MBMS user service to the MCData client. The MCData client obtains the TMGI, identifying the MBMS bearer, from the SA file included in the MBMS user service description.

5. The MCData client stores the information associated with the MBMS user service. The MCData client uses the TMGI and other MBMS user service related information to activate the monitoring of the MBMS bearer.

6. The MCData client that enters or is in the service area of at least one announced TMGI indicates to the MCData server that the MCData client is able to receive file distributed over MBMS, whereby the MCData server may decide to use this MBMS user service instead of unicast bearer for MC communication sessions.

NOTE 2: Step 4 is optional for the MCData UE on subsequent MBMS user service announcements.

NOTE 3: The information flow is specified in subclause 10.7.2.2 from 3GPP TS 23.280 [5].

7. If the MCData server makes use of the xMB interface and wants to deliver a file to a group, the MCData server updates the MBMS session to provide the file list when the pull ingest mode is defined. As described in 3GPP TS 26.348 [19], the file list includes, among other information, the file URL to be used by the BM‑SC to fetch the file and the earliest fetch time.

8. The MCData server signals the file transmission over the MBMS user service to the targeted MCData clients.

NOTE 4: After step 8, the file can be provided for distribution over the MBMS session. If the pull ingest mode is defined, the BM‑SC fetches the file from the indicated file URL. If the push ingest mode is defined, the MCData server can start pushing the file to the corresponding URL.

9. The file, transmitted with the MBMS download delivery method, is received by the MCData clients. If the MCData server does not make use of the xMB interface, the MCData server fragments the file to be sent, applies error correction according to the MBMS download delivery method (3GPP TS 26.346 [21]) and sent the FLUTE packets over MB2-U.

7.3.5.3.2 Use of dynamic MBMS user service establishment

Editor’s note: The procedure in this clause needs to be revised considering that MBMS user services, as specified in 3GPP TS 26.346 [21], cannot be supported over the MB2 interface.

In this scenario depicted in figure 7.3.5.3.2-1, the MCData server decides to establish an MBMS user service for the distribution of a given file. The MBMS user service is announced to the MCData client, together with the file information to be received.

NOTE 1: The MCData server logic for determining when to establish the new MBMS user service is implementation specific. For example, the MCData server could decide to establish the MBMS delivery based on the location of the UE’s that are a part of the targeted group.

Figure 7.3.5.3.2-1: Use of dynamic MBMS user service establishment

1. The MCData server determines to create a MBMS user service with a given an MBMS user service id for the group communication session. If the MCData server makes use of the xMB interface, the MCData server creates an MBMS user service over xMB-C (subclause 5.3 from 3GPP TS 26.348 [19]).

2. If the MCData server makes use of the xMB interface, the MCData server creates a MBMS session for the MBMS user service (subclause 5.4 from 3GPP TS 26.348 [19]), with the type set to "Files" to use the MBMS download delivery method. Additionally, the MCData server defines the ingest mode, pull or push, to provide the file into the BM‑SC via xMB‑U. When the pull ingest mode is defined, the MCData server provides the file list. The file list includes, among other information, the file URL to be used by the BM‑SC to fetch the file and the earliest fetch time. In response, the MCData server gets the TMGI of the MBMS bearer used for the MBMS session and the SA file containing the metadata of the MBMS user service. When the pull ingest mode is defined, the MCData server also obtains the scheduling parameter for the file delivery. When the push ingest mode is used, as part of the response from the BM‑SC the MCData server obtains the URL to be used to push the file.

3a. Else, the MCData server activates an MBMS bearer over MB2-C for the MBMS user service.

3b. The MCData server, if not already in the possession of the SA file, generates the SA file containing the metadata of the MBMS user service.

4. The MCData server passes using control plane signalling the SA file to the MCData client. The MCData client obtains the TMGI, identifying the MBMS bearer, from the SA file included in the MBMS user service description.

7. The MCData server signals the file transmission over the MBMS user service to the targeted MCData clients.

NOTE 2: After step 7, the file can be provided for distribution over the MBMS session. If the pull ingest mode is defined, the BM‑SC fetches the file from the indicated file URL. If the push ingest mode is defined, the MCData server can start pushing the file to the corresponding URL.

8. The file, transmitted with the MBMS download delivery method, is received by the MCData clients. If the MCData server does not make use of the xMB interface, the MCData server fragments the file to be sent, applies error correction according to the MBMS download delivery method (3GPP TS 26.346 [21]) and sent the FLUTE packets over MB2-U.

7.3.5.3.3 Providing stored files in the MCData content server for distribution over MBMS

7.3.5.3.3.1 General

As described in clause 6.6.3.1.5, the MCData content server provides a repository area where authorized MCData users temporarily store files that are intended to be shared with other MCData users. The distribution of such files targeting a group of MCData users can be performed over MBMS.

For the case that the MBMS user service architecture is used over the xMB interface (specified in 3GPP TS 26.348 [19]), two ingest modes, push and pull, can be defined by the MCData server to ingest the file into the BM‑SC for distribution over the MBMS sessions.

NOTE: It is implementation specific if the MCData server uses pull or push ingest mode to ingest the file into the BM‑SC over the xMB interface.

7.3.5.3.3.2 File fetching by the MCData server

A file can be fetched by the MCData server from the MCData content server over the MCData-FD-5 reference point using the file URL provided by MCData users. The MCData server, thus, enables via the xMB‑U interface that the file is ingested, either by pull or push, into the BM‑SC for distribution over MBMS.

NOTE 1: The file also becomes available for the case that the MCData server decides to distribute the file over the MB2 interface to MCData users from the target MCData group.

When the MCData server defines a pull ingest mode, the MCData server provides via the xMB‑C interface the resource location from which the BM‑SC will fetch the file as well as other session properties (e.g. file earliest fetch time), as described in 3GPP TS 26.348 [19].

When the MCData server defines a push ingest mode, the MCData server directly ingests into the BM‑SC via the xMB‑U interface the file obtained from the MCData content server. The BM‑SC provides to the MCData server the URL to be used to push the file(s).

NOTE 2: For the push ingest mode, the MCData server is always the functional entity ingesting the file content into the BM‑SC via the xMB‑U interface.

The procedure in figure 7.3.5.3.3.2-1 describes the case where the file to be distributed over MBMS is fetched by the MCData server from the MCData content server.

Pre-conditions:

– The MCData users on the MCData client 1 to n belong to the same MCData group and are already registered and affiliated for receiving MCData service.

– The file to be distributed is uploaded to the MCData content server.

– The BM‑SC has the necessary permissions to fetch a file from the MCData system.

Figure 7.3.5.3.3.2-1: File fetching by the MCData server for file distribution over MBMS

1. The MCData server receives a request from the MCData client 1 to distribute a file to a target MCData group. The MCData file distribution request contains the resource location (i.e. the file URL) in the MCData content server.

2. The MCData server decides to fetch the file from the MCData content server via the MCData-FD-5 reference point.

3. The MCData server creates an MBMS service and session for file delivery using xMB procedures via the xMB‑C interface, as described in 3GPP TS 26.348 [19]. The MCData server indicates, among other session properties, the ingest mode. For the case of pull ingest mode, the MCData server provides the file URL from which the BM‑SC will fetch the file. For the case of push ingest mode, the BM‑SC provides to the MCData server the URL to be used to push the file into the MBMS session.

NOTE 3: Step 3 may also occur before step 2.

4. The MCData server provides to the MCData users from the target MCData group the application signalling related to the MBMS session and the file distribution.

5a. For the case that the file is ingested into the BM‑SC based on the push ingest mode, the MCData server pushes the file to the URL indicated by the BM‑SC.

5b. For the case that the file is ingested into the BM‑SC based on the pull ingest mode, the BM‑SC pulls the file from the provided file URL.

6. The BM‑SC distributes the file over the established MBMS session. When the target MCData clients have activated the reception for that service and are located within the MBMS area coverage, the MCData clients receive the file.

7.3.5.3.3.3 File fetching by the BM‑SC

When the MCData server defines a pull ingest mode, the MCData server can alternatively provide to the BM‑SC the resource location in the MCData content server (i.e. the file URL contained within the received file distribution request). The BM‑SC, thus, will directly fetch the file from the MCData content server.

NOTE 1: In order to the enable that the BM‑SC fetches the file from the MCData content server, the MCData content server supports the xMB‑U interface to the BM‑SC.

NOTE 2: For the case that the file is ingested into the BM‑SC from the MCData content server, only the pull ingest mode is supported. When push ingest mode is required, the procedure is described in clause 7.3.5.3.3.2.

The procedure in figure 7.3.5.3.3.3-1 describes the case where the file to be distributed over MBMS is fetched by the BM‑SC from the MCData content server.

Pre-conditions:

– The MCData users on the MCData client 1 to n belong to the same MCData group and are already registered and affiliated for receiving MCData service.

– The file to be distributed is uploaded to the MCData content server.

– The BM‑SC has the necessary permissions to fetch a file from the MCData system.

Figure 7.3.5.3.3.3-1: File fetching by the BM‑SC for file distribution over MBMS

2. The MCData server creates an MBMS service and session for file delivery using xMB procedures via the xMB‑C interface, as described in 3GPP TS 26.348 [19]. The MCData server defines, among other session properties, the ingest mode to pull. The MCData server provides the file URL from which the BM‑SC will fetch the file from the MCData content server.

3. The MCData server provides to the MCData users from the target MCData group the application signalling related to the MBMS session and the file distribution.

4. The BM‑SC fetches the file from the MCData content server via the xMB‑U interface.

5. The BM‑SC distributes the file over the established MBMS session. When the target MCData clients have activated the reception for that service and are located within the MBMS area coverage, the MCData clients receive the file.

7.3.6 Group communication connect and disconnect over MBMS bearer procedures

7.3.6.1 General

MBMS bearer can be used for MCData group communication. One MBMS bearer is not permanently associated to one specific group or group communication. Before sending data packets of a group communication over MBMS bearer, the MCData server shall send the association information between group communication and the MBMS bearer. The group session setup procedure indicates the media stream within one MBMS bearer that is used for the specific group communication. When the group communication over the MBMS bearer is finished, this temporary association information of an MCPTT group communication to specific resources on a MBMS bearer is undone.The procedure in clause 7.3.6 requires that the group session is setup before the data transmission starts. This eliminates the need for the receiving clients to continuously use a unicast bearer. Prior to group session setup, the MBMS bearer is activated and announced to the MCData clients.

NOTE: It is implementation-specific that one MBMS bearer can be re-assigned to different groups, or is associated to only one group.

7.3.6.2 Procedure

The procedure in this clause uses an establishment of group communication as described in clause 7.4.2.7. Similary, the procedure defined in this clause is also applicable for the group communication established as described in clause 7.4.2.6.

7.3.6.2.1 Group communication connect over MBMS bearer

Pre-conditions:

– The MCData clients 1 to n are registered and affiliated to the same MCData group X.

– The MCData server has decided to use an MBMS bearer for the MCData service group communication associated with to the MCData group X.

Figure 7.3.6.2.1-1: Group communication connect on MBMS bearer.

1. Activation and announcement of MBMS bearer availability.

NOTE 1: The procedure does not include the steps for MCData client location reporting, or for MBMS capability information exchange.

2. The MCData client 1 initiates a group communication by sending a MCData group data request over a unicast PDN connection towards the MCData server.

3. MCData server initiates the MCData group data request towards each MCData clients 2 to n.

4. The receiving MCData clients 2 to n optionally notify the user about the incoming MCData session data request.

5. The receiving MCData client 2 to n accept or reject the MCData group data request and the corresponding result is in the MCData group data response towards MCData server.

6. The MCData server will send a MapGroupToBearer message over a previously activated MBMS bearer to all users that will receive the communication over an MBMS bearer. The MapGroupToBearer message includes association information between the group communication and MBMS bearer. The MapGroupToBearer message includes MCData group ID and information about the media stream identifier of the activated MBMS bearer and may include the identifier (i.e. the TMGI) of the MBMS bearer broadcasting the communication.

7. The MCData clients 2 to n process the MapGroupToBearer information and may send a MapGroupToBearer Ack back to the MCData server if required.

8. MCData server forwards the MCData group data response received from MCData client 2 to n to the MCData user initiating the MCData session data request.

NOTE 2: The steps 3 to 5 and steps 6 to 7 can occur in any order, and prior to step 9 depending on the conditions to proceed with the data transmission.

9. MCData client 1 sends the MC data over uplink unicast PDN connection towards the MCData server.

10. The MCData server sends the MC data over the indicated stream within the associated MBMS bearer to the MCData clients 2 to n.

7.3.6.2.2 Group communication disconnect from MBMS bearer

Figure 7.3.6.2.2-1 shows the high level procedure where an UnmapGroupFromBearer message is sent by the MCData server to the MCData clients to indicate that the MCData group communication is being dissociated from the MBMS bearer.

Figure 7.3.6.2.2-1: Group communication disconnect on MBMS bearer.

1. The MC group communication is taking place over MBMS bearer. MCData client 1 is sending the MC data over a unicast PDN connection to the MCData server.

2. The MCData server sends the MC data over the MBMS bearer to MCData clients 2 to n.

3. After the MC data transmission is over, i.e., no further data to be sent over the group communication, the MCData server sends an UnMapGroupFromBearer to de-associate the group communication from the MBMS bearer.