14.3.4A Multicast resource management for 5GS

23.4343GPPFunctional architecture and information flowsRelease 18Service Enabler Architecture Layer for Verticals (SEAL)TS

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

14.3.4A.1 General

This subclause defines information flows and procedures for 5G MBS usage that applies to VAL services. 5G MBS session can be used by any VAL service for any VAL service group.

The main purpose of using 5G Multicast-Broadcast Service (MBS) by verticals is to provide efficient downlink delivery of user traffic in VAL service group communications or in a certain area.

Multicast and broadcast services in 5G for vertical applicationsrely on the creation and establishment of MBS sessions to deliver user data in downlink. Shared and individual delivery from the VAL server to multiple VAL users is supported either as point-to-point or point-to-multipoint over the radio. The MBS session which is consist of one or multiple QoS flows for different service requirements can either be broadcast or multicast type.

NOTE 1: Support of MBS and specific session types is an implementation choice.

Within this arrangement, the VAL server decides whether to create broadcast or multicast MBS sessions to be associated with certain VAL service groups or area. The 5GC adaptively decides whether to deliver the MBS traffic from the MB-UPF in the form of shared delivery or individual delivery, where the latter is applicable to multicast MBS sessions. The NG-RAN decides to utilize point-to-point or point-to-multipoint delivery methods applicable for shared delivery only. MBS provides reliability enhancements and minimizes loss of information, e.g., due to mobility and handover.

MBS group scheduling mechanism enables simultaneous reception of MBS and unicast user traffic by the VAL UEs. The UEs can receive broadcast MBS sessions irrespective of their RRC state (i.e., connected, inactive or idle) and multicast sessions only in RRC‑CONNECTED state.

The following capabilities (non-exhaustive list) provided by MBS could be used by NRM server:

– MBS session creation;

– MBS session update;

– MBS session release;

– MBS session ID allocation;

– Dynamic PCC control for MBS session.

The first phase to utilize MBS sessions for VAL media transmission is to reserve the network resource by creating a MBS sessions. The MBS session creation is initiated by the VAL server towards the NRM server, and the NRM server further interacts with the 5GS to complete the whole process. The UE’s capabilities and service related information e.g., UE’s MBS capabilities, location, MBS listening status report sent by group members are considered when deciding to create or use MBS sessions. During the interaction with NRM server, the necessary information related to the requested session is determined, e.g., MBS session mode (either a broadcast or a multicast session) and the required service profile. This interaction between the NRM server and the 5GS depends on the configuration option under consideration, i.e., whether the NRM server is in trusted domain (limited operations), and whether the session creation is done with or without a dynamic PCC rule.

NOTE 1: It is implementation specific whether the VAL server decides to use multicast or broadcast MBS sessions.

NOTE 2: It is implementation specific whether the VAL decides to create (one or multiple) MBS sessions for VAL media for VAL group communications associated to a certain VAL group or create (one or multiple) dynamic MBS sessions once the need has emerged, e.g., dynamic MBS sessions to be associated for an ad hoc group.

NOTE 3: It is implementation specific whether an MBS session is associated to one or multiple VAL service groups, and whether it is re-assigned to other VAL service groups.

NOTE 4: How the NRM server uses the UE’s capabilities and service related information in order to create and use the MBS session is implementation specific.

The information elements describing the MBS session under consideration is then sent to the NRM clients via MBS session announcement, where the latter need to react according to the announced session mode.

If eMBMS and 5G MBS co-exist for VAL services, the NRM service server may decide to trigger the establishment of an eMBMS bearer to deliver the VAL media associated to the VAL service group communications, if the target VAL service group(s) consists of members with MBMS capable RAT. As a result, the NRM server subsequently needs to send an eMBMS bearer announcement towards the clients camping on LTE.

NOTE 5: It is implementation specific whether the NRM server triggers an eMBMS bearer or a unicast bearer to serve VAL clients camping on LTE.

14.3.4A.2 MBS session creation and MBS session announcement

14.3.4A.2.1 General

The procedures in this clause describe how MBS session creation and MBS session announcement can be used for the transmission of VAL service group communication data over either broadcast or multicast MBS sessions. The MBS session can either be created with or without dynamic PCC rule, where the latter requires less interaction done by the NRM server towards the 5GC (either directly or via NEF).

14.3.4A.2.2 Procedure for pre-created MBS session and MBS session announcement

Pre-conditions:

– The NRM server has decided to use an MBS session for VAL service group communications associated to a certain VAL servive group based on transport only mode.

– The NRM server has performed MB-SMF discovery and selection either directly or indirectly via NEF/MBSF, unless the corresponding information is locally configured.

– NRM clients 1 to n are attached to the 5GS, registered and belong to the same VAL service group X.

– The NRM server is aware whether to request the creation of the MBS service server with or without dynamic PCC rule.

TimelineDescription automatically generated

Figure 14.3.4A.1.2-1: Use of pre-created MBS session.

1. The VAL server sends a multicast/broadcast resource request towards the NRM server including the VAL server identity, service description(s), multicast resource type (e.g,. multicast type or broadcast type), service announcement mode (i.e., service announcement is sent by NRM or the VAL itself), Endpoint of the VAL server.

2. The NRM server initiates an MBS session creation procedure towards the 5GC as described in 3GPP TS 23.247 [39]. The procedure starts once the NRM server initiates a TMGI allocation request (either directly to MB-SMF or indirectly via NEF). Upon the reception of the TMGI allocation response, the NRM server sends an MBS session creation request, including further information related to the MBS session, e.g., MBS session ID, MBS session mode and the QoS requirements if dynamic PCC rule is not considered. However, if dynamic PCC rule is considered, the NRM server defines these requirements at a later step, namely it sends an MBS authorization/policy create request towards PCF (either directly or to the NEF) indicating the QoS requirements.

NOTE 1: In case of LTE eMBMS and 5G MBS co-existence, the NRM server may trigger the establishment of eMBMS bearers as described in clause 14.3.4 (or it may establish a unicast bearer) based on the RAT capabilities supported by the VAL service group members in the VAL service group X. If MBSF and BM-SC are co-located, TMGI used by 4G eMBMS can be the same as the MBS session ID.

NOTE 2: For the case of multi carrier support for broadcast MBS sessions, the NRM server may indicate the frequencies within a broadcast MBS service area by providing the MBS frequency selection area ID(s) (MBS FSA ID(s)) to the MB-SMF or indirectly via NEF.

3. The NRM server provides the NRM clients of the VAL service group X with the information related to the created MBS session via the MBS session announcement. The MBS session announcement includes information such as the MBS session ID, MBS session mode (broadcast or multicast service type) and SDP information related to the MBS session under consideration.

NOTE 3: The NRM server may send an MBS session announcement at an earlier step during the MBS session creation procedure towards the NRM clients once the VAL service group associated to the MBS session is known.

Optionally, the NRM server includes the information elements related to the established eMBMS bearer, as indicated in table 7.3.2.2-1. The NRM clients which camp on LTE will subsequently react to the information elements related to the eMBMS bearer as described in 3GPP TS 23.280 [3].

4. NRM clients store and process the received MBS session information.

5. NRM clients may provide an MBS session announcement acknowledgment to the NRM server to indicate the reception of the corresponding MBS session announcement.

6. Based on the MBS session mode (either multicast or broadcast), the following actions take place;

6a. For multicast MBS sessions, NRM clients initiate a UE session join request towards the 5GC using the information provided via the MBS session announcement. Hence, upon the first successful UE session join request, the multicast is then established, and the radio resources are reserved, if the session is in an active state. The established session can either be in active or inactive state as indicated in 3GPP TS 23.247 [39]. The NRM clients sends a UE session join notification towards the server. If indicated in the MBS session announcement information, NRM clients report the monitoring state (i.e. the reception quality of the MBS session) back to the NRM server; or

6b. For broadcast MBS sessions, if the NRM client is accessing over 5G, the session is established as part of the session creation procedures as described in 3GPP TS 23.247 [39], and the network resources are reserved both in 5GC and NG-RAN. The NRM clients start monitoring the reception quality of the broadcast MBS session. If indicated in the MBS session announcement information, NRM clients report the monitoring state (i.e. the reception quality of the MBS session) back to the NRM server.

NOTE 4: It is implementation specific whether the MBS session reception quality level is determined per MBS session, per media stream or per MBS QoS flow level via e.g., measurements of radio level signals, such as the reference signals from the NG-RAN node(s), or packet loss.

7. The NRM clients provide a listening status notification related to the announced session (multicast or broadcast session) in the form of an MBS listening status report.

8. The NRM server provides a multicast/broadcast resource response to the VAL server.

9. An VAL service group communication setup takes place and uses the pre-created MBS session for this group communication packet DL delivery.

14.3.4A.2.3 Procedure for dynamic MBS sessions

In this scenario, the VAL service group communication is already taken place and a unicast PDU session is utilized for DL transmission. When the NRM server decides to use an MBS session for the transmission under consideration, the NRM server interacts with 5GC to reserve the necessary network resources.

NOTE 1: The NRM server logic for determining when to create a dynamic MBS session is implementation specific.

The procedure in figure 14.3.4A.2.3-1 shows one NRM client receiving the DL media. There might also be NRM clients in the same VAL service group communication session that receive the communication on a PDU session.

Pre-conditions:

– NRM client is attached to the 5GS, registered and affiliated to a certain VAL service group X.

– The NRM server is aware whether to request the creation of the MBS session with or without dynamic PCC rule.

– The NRM server has performed MB-SMF discovery and selection either directly or indirectly via NEF/MBSF, unless the corresponding information is locally configured.

– No MBS session exists, or the existing multicast MBS session fails to satisfy the QoS requirements.

TimelineDescription automatically generated

Figure 14.3.4A.2.3-1: Use of dynamic MBS session.

1. An VAL service group communication session is established and the DL media packet is delivered to the VAL client via unicast.

2. The VAL server sends a multicast/broadcast resource request towards the NRM server including the VAL server identity, service description(s), multicast resource type (e.g,. multicast type or broadcast type), service announcement mode (i.e., service announcement is sent by NRM or the VAL itself), Endpoint of the VAL server.

3. The NRM server decides to create an MBS session. The MBS session creation procedure takes place as described in clause 14.3.4A.1.

NOTE 2: In case of LTE eMBMS and 5G MBS co-existence, the NRM server may trigger the establishment of eMBMS bearers as described in 3GPP TS 23.280 [3] (or it may establish a unicast bearer) based on the RAT capabilities supported by the affiliated members in the VAL service group X. If MBSF and BM-SC are co-located, TMGI used by 4G eMBMS can be the same as the MBS session ID.

NOTE 3: For the case of multi carrier support for broadcast MBS sessions, the NRM server may indicate the frequencies within a broadcast MBS service area by providing the MBS frequency selection area ID(s) (MBS FSA ID(s)) to the MB-SMF or indirectly via NEF.

4. The NRM server provides the NRM client with the information related to the created MBS session via an MBS session announcement. As described in table 7.3.2.2-1, the session announcement includes information such as the MBS session ID, MBS session mode (broadcast or multicast service type), and SDP information related to the MBS session.

Optionally, the NRM server includes the information elements related to the established eMBMS bearer once the NRM server has determined the need, as indicated in table 7.3.2.2-1. The NRM clients which camp on LTE will subsequently react to the information elements related to the eMBMS bearer as described in 3GPP TS 23.280 [3].

5. The NRM client stores the MBS session ID and other associated information.

6. The NRM client may send an MBS session announcement ack back to the NRM server.

7. Based on the MBS session mode (either multicast or broadcast), the following actions take place:

7a. For multicast MBS sessions, NRM client initiates a UE session join request towards the 5GC using the information provided via the MBS session announcement. Hence, upon the first successful UE session join request, the multicast is then established, and the radio resources are reserved, if the session is in active state. The established session can either be in active or inactive state as indicated in 3GPP TS 23.247 [39]. The NRM client sends a UE session join notification towards the server. If indicated in the MBS session announcement information, NRM clients report the monitoring state (i.e. the reception quality of the MBS session) back to the NRM server; or

7b. For broadcast MBS sessions, if the NRM client is accessing over 5G, the session is established as part of the session creation procedures as described in 3GPP TS 23.247 [39], and the network resources are reserved both in 5GC and NG-RAN. The NRM clients start monitoring the reception quality of the broadcast MBS session. If indicated in the MBS session announcement information, NRM clients report the monitoring state (i.e. the reception quality of the MBS session) back to the NRM server.

NOTE 4: It is implementation specific whether the MBS session reception quality level is determined per MBS session, per media stream or per MBS QoS flow level via e.g., measurements of radio level signaling such as the reference signals from the NG-RAN node(s), packet loss.

8. The NRM clients provide a listening status notification related to the announced session (multicast or broadcast session) in the form of an MBS listening status report.

9. The NRM server provides a multicast/broadcast resource response to the VAL server.

10. An VAL service group communication via dynamic MBS session is established. The VAL server sends the downlink packet for the VAL service group communication session over the MBS session.

14.3.4A.3 MBS resources update

14.3.4A.3.1 General

The VAL server can create one or several MBS sessions via the NRM server, based on certain service requirements, a certain service area, or the activity status of multicast MBS sessions. However, during the life cycle of the MBS sessions, the VAL server may need to trigger the update of the sessions via the NRM server to meet emerging needs, including the service requirements, service area related parameters.

14.3.4A.3.2 Procedure for updating MBS resources without dynamic PCC rule

The procedure shown in figure 14.3.4A.3.2-1 presents an MBS session update procedure triggered by the VAL server via the NRM server (either directly interacting with the MB-SMF, or indirectly with NEF/MBSF). Within the update request, either the service requirements, MBS service area, activity status of multicast MBS session, or all three are done, as indicated in 3GPP TS 23.247 [39].

Pre-conditions:

– The NRM clients 1 to n are attached to the 5GS, registered and belong to the same active VAL service group.

– The NRM server has obtained the required information related to the MB-SMF, either locally configured or during initial session configuration.

– The MBS session is created with certain service requirements and optionally with a certain broadcast/multicast service area. The MBS session is announced to be associated with the VAL service group for group communication purposes.

TimelineDescription automatically generated

Figure 14.3.4A.3.2-1: MBS session update without dynamic PCC

1. An MBS session is established as described in in 3GPP TS 23.247 [39] (either a multicast or a broadcast session), and associated with a certain active VAL service group for group communication purposes. In the case of a multicast MBS session, the NRM clients have already joined the session.

2. The VAL server invoke the multicast resource update request to the NRM server once the need has emerged to modify some aspects for the given MBS session under consideration. The updated parameters are included, e.g., service requirements, service area or both. In case of multicast MBS sessions, the VAL server may as well include the status (active or inactive) of the multicast MBS session to be set.

3. The NRM server performs an MBS session update procedure with the 5GC as described in 3GPP 23.247 [39]. Based on the needed requirements, the corresponding MBS session is accordingly modified at the 5GS. The update may lead to QoS Flow(s) addition, modification, or removal. The NRM server receives an MBS session update response once the requested modifications are performed, and the indicated MBS session is updated accordingly.

4. The NRM server may initiate a session announcement towards the NRM clients associated with the ongoing session in order to announce the updated information, if required, e.g., the updated service area or SDP information.

5. The NRM server sends an MapGroupToSessionStream over the configured MBS session providing the required information to receive the media related to the established VAL service group communication.

6. The NRM clients process the received information over the MapGroupToSessionStream in order to receive the associated VAL media over the specific MBS session stream.

7. The NRM server returns the multicast resource update resonse to the VAL server.

8. VAL client 1 sends media to the VAL server over unicast to be distributed for the established group communication.

9. The VAL server distributes the VAL media to the VAL clients 2 to n over the indicated streams.

14.3.4A.3.3 Procedure for updating MBS resources with dynamic PCC rule

The procedure shown in figure 14.3.4A.3.3-1 presents an MBS session update procedure triggered by the NRM server to the 5GC, either directly or via NEF/MBSF. Based on the required updates to be done, the NRM server needs to interact with the MB-SMF to update the MBS service area and multicast activity status, with the PCF to update the required QoS requirements, or sequentially both to update all the above, as indicated in 3GPP TS 23.247 [39].

Pre-conditions:

– The NRM clients 1 to n are attached to the 5GS, registered and belong to the same active VAL service group.

– The NRM server has obtained the required information related to the MB-SMF, either locally configured or during initial session configuration.

Figure 14.3.4A.3.3-1: MBS session update with dynamic PCC

1. An MBS session is established as described in 3GPP TS 23.247 [29] (either a multicast or a broadcast session), and associated with a certain active VAL service group for group communication purposes. In the case of a multicast MBS session, the NRM clients have already joined the session.

NOTE 1: The updated service area information is required for local MBS and for broadcast MBS services.

3. The NRM server, based on the update requirements from step 2, perform the MBS session update with PCC procedure towards the 5GS as described in 3GPP TS 23.247 [29].

4. The NRM server may initiate a session announcement towards the NRM clients associated with the ongoing session in order to announce the updated information if required, e.g., the updated service area or SDP information.

NOTE 2: The updated service area information is required for local MBS and for broadcast MBS services.

5. The NRM server sends an MapGroupToSessionStream over the MBS session providing the required information to receive the media related to the established VAL service group communication.

6. The NRM server returns the multicast resource update resonse to the VAL server.

7. The NRM clients process the received information over the MapGroupToSessionStream in order to receive the associated VAL media over the specific MBS session stream.

8. VAL client 1 sends media to the VAL server over unicast to be distributed for the established group communication.

9. The VAL server distributes the VAL media to the VAL clients 2 to n over the indicated streams.

14.3.4A.4 MBS resource deletion

14.3.4A.4.1 General

The VAL server can decide to release a certain MBS session once it is no longer further utilized for the associated VAL service group communication, e.g., the VAL service group is no longer active, the VAL media transmission is over and no further VAL media to be delivered, group communication is terminated. The MBS session deletion procedure leads to releasing the network resources associated to that MBS session.

NOTE: It is up to implementation of VALserver to decide whether to release the MBS session or re-use it for subsequent group operations.

To delete the MBS session, the VAL server invokes the multicast/broadcast resource release service of NRM server which further triggers the NRM server to send an MBS session deletion request to the 5GS providing the corresponding MBS session ID. The MBS session deletion request is sent to the MB-SMF (directly or via NEF/MBSF) when PCC is not used. However, if dynamic PCC rule is utilized, a policy authorization deletion request is initially sent to the PCF. Further details of the MBS session deletion are provided in 3GPP TS 23.247 [39].

NRM server further informs the NRM client with the MBS session de-announcement, so that the VAL UE stops monitoring the broadcast MBS session or leaves the multicast MBS session. This procedure is applied for both broadcast MBS session and multicast MBS session.

14.3.4A.4.2 Procedure

The procedure in figure 14.3.4A.4.2-1 describes the MBS session deletion aspects for group communication.

Pre-conditions:

– NRM clients 1 to n are attached to the 5GS, registered and affiliated to the same active VAL service group.

– An MBS session is configured to address the corresponding VAL service group with certain service requirements and optionally with a certain broadcast/multicast service area. The session is announced and established for group communication purposes for the VAL service group.

DiagramDescription automatically generated

Figure 14.3.4A.4.2-1: MBS session deletion procedure.

1. The VAL server decides to delete the MBS session for the associated VAL group communication, either multicast or broadcast session.

2. The VAL server invokes the multicast/broadcast resource release service of the NRM server by sending the multicast/broadcast resource release request.

3. Upon receiving the multicast/broadcast resource release request, the NRM server sends an MBS session de-announcement message with the MBS session ID towards the NRM client(s). Upon receiving the MBS session de-announcement message, either 4a or 4b is performed.

4a. If the MBS session identified by MBS session ID is a broadcast MBS session, the UE(s) stops monitoring the broadcast MBS session and removes the broadcast MBS session related information.

4b. If the MBS session identified by MBS session ID is a multicast MBS session, the joined UE(s) initiate an MBS session leave procedure to leave the indicated MBS session in order to release the respective network resources, as defined in 3GPP TS 23.247 [39].

5. Subsequently, the NRM clients may send an MBS session de-announcement acknowledgement message to the NRM server indicating the status of MBS session.

6. The NRM server initiates the MBS session deletion procedure with the 5GC (either directly or through NEF/MBSF) in order to stop using the configured MBS session and release the corresponding network resources. The NRM server indicates within the MBS session release request the corresponding MBS session ID. The MBS session deletion procedure can either be with or without a dynamic PCC rule, as indicated in 3GPP TS 23.247 [39].

7. The NRM server returns the multicast/broadcast resource release response to the VAL server indicating the result.

14.3.4A.5 Request to activate / de-activate multicast MBS sessions

14.3.4A.5.1 General

In case of multicast MBS sessions, the members affiliated to a certain VAL service group need to initiate a UE session join request towards the 5GC in order to receive the VAL media sent via the associated MBS session. The UE session join request enables the reservation of NG-RAN resources for the members of the VAL group. However, it is not necessary that the VAL media is delivered over the whole time the multicast MBS session is associated to the group under consideration. Therefore, the VAL server is able to efficiently utilize and control the reservation of radio resources based on the availability of VAL data to be delivered via the activation and de-activation procedure with NRM server. This presents more flexibility and efficient use of resources different from LTE.

The most suitable scenario to activate/de-activate a certain multicast MBS session is based on whether there is a VAL group communication, taking place over that associated session to the VAL service group. In this manner, the VAL server can activate the associated multicast session once a VAL group communication takes place, then deactivate it once the VAL group communication is over. Whether the multicast session is activated (i.e., in an active state), or de-activated (in an inactive state), the VAL group is associated to the multicast session and its members are within a UE session join.

The activation or de-activation request is initiated by the VAL server towards the NRM server which further interacts either directly with the MB-SMF or indirectly with NEF/MBSF.

NOTE: The activation of de-activation procedure may also be triggered by MB-SMF based on receiving notification from MB-UPF based on the availability of VAL data to be transmitted.

14.3.4A.5.2 Multicast MBS session activation procedure

The procedure shown in figure 14.3.4A.5.2-1 presents the multicast MBS session activation procedure initiated by the VAL server.

Pre-conditions:

– NRM clients are attached to the 5GS, registered and affiliated to the same VAL service group X.

– The NRM server has directly performed (or via NEF/MBSF) an MB-SMF discovery and selection, unless the corresponding information is locally configured.

– The multicast MBS session for NRM group communications associated to VAL service group X.

– The MBS session is created and announced to address VAL group communication related to the associated VAL service group X with certain service requirements and optionally with a certain service area.

DiagramDescription automatically generated

Figure 14.3.4A.5.2-1: Multicast MBS session activation procedure.

1. The multicast MBS session is established as the first UE session join request, which is initiated by the first VAL UE towards 5GC, is granted. At this stage, the multicast MBS session is established with an inactive state.

2. The VAL server decides to activate the multicast MBS session as VAL data is needed to be transmitted over the session to the VAL service group X, as a VAL group communication is to take place over the associated MBS session.

3. The VAL server invokes the multicast resource activation request provided by NRM server, the MBS session ID is included.

4. Upon receiving the request in step 3, the NRM server sends an MBS session activation request towards the 5GC, either directly to the MB-SMF or via NEF/MBSF, indicating the TMGI to be activated.

5. The 5GC changes the session status to "active" and finds the list of joined VAL UEs associated with the session and activates the NG- RAN resources for VAL data delivery.

6. The 5GC may send an MBS session activation response to the NRM server indicating that the requested multicast MBS session has been activated.

7. The NRM server returns the multicast resource activation response to the VAL server.

14.3.4A.5.3 Multicast MBS session de-activation procedure

The procedure shown in figure 14.3.4A.5.3-1 presents the multicast MBS session activation procedure initiated by the VAL server.

Pre-conditions:

– NRM clients are attached to the 5GS, registered and affiliated to the same VAL service group X.

– The NRM server has directly performed (or via NEF/MBSF) an MB-SMF discovery and selection, unless the corresponding information is locally configured.

– A multicast MBS session is created and announced to address the corresponding VAL service group with certain service requirements and optionally with a certain multicast service area.

– The VAL UE have already joined the multicast MBS session and are able to receive the VAL data over the associated MBS session.

DiagramDescription automatically generated

Figure 14.3.4A.5.3-1: Multicast MBS session deactivation procedure.

1. The group communication associated with VAL service group X takes place, and the corresponding VAL data is delivered over the associated multicast MBS session, hence the MBS session has an active state.

2. The VAL server decides to deactivate the multicast MBS session, as no further VAL data to be delivered to the associated group, or the VAL group communication is over, and no further VAL media is to be delivered.

3. The VAL server invokes the multicast resource deactivation request provided by NRM server, the MBS session ID is included.

4. Upon receiving the request in step 3, the NRM server sends an MBS session deactivation request towards the 5GC, either directly to the MB-SMF or via NEF/MBSF, indicating the TMGI to be deactivated.

4. The 5GC changes the session state to "inactive" and deactivates the radio resources associated with the joined VAL UEs.

5. The 5GC may send an MBS deactivation response to the server indicating that the requested multicast MBS session has been inactivated.

7. The NRM server may return the multicast resource deactivation response to the VAL server.

14.3.4A.6 VAL service group media transmissions over 5G MBS sessions

14.3.4A.6.1 General

The VAL server can decide to configure an MBS session per VAL service group to transmit the media related to the corresponding VAL group communications. Such group communications can comprise different service requirements. For that, multicast and broadcast MBS sessions need to be configured with multiple MBS QoS flows to address different service requirements, e.g., different required QoS, provided by the NRM server. For instance, application-level control messages or media associated to a group communication can comprise different QoS requirements. Also, different type of group communications can comprise different QoS requirements, e.g., emergency group communication should be handled with a higher priority than normal group communication.

The configuration of multiple MBS QoS flows to address different service requirements is associated to the assignment of different streams (e.g., different ports) within an MBS session.

The established multicast MBS session can either be in active or inactive state, where the former indicates the activation of radio resources hence transmitting the VAL media to the associated VAL service group, and the latter indicates their deactivation as no VAL media is being transmitted. The VAL server may initiate the activation of multicast MBS sessions once the VAL service group is established and active, as well as once the VAL media is available for transmission. For this purpose, the VAL server sends a multicast MBS session activation request towards the NRM indicating the MBS session ID to be activated, and the NRM server further interacts with the 5GS to complete the MBS session activation.

Similar to the use of eMBMS, the NRM server shall provide the associated information between a specific group communication and the stream to be used within an MBS session to the UE. This information could be sent in advance in an MBS session announcement or could be provided on demand in an additional signalling message for the MBS session, e.g., MapGroupToSessionStream (similar to the MapGroupToBearer in eMBMS).

14.3.4A.6.2 Procedure

The procedure in figure 14.3.4A.6.2-1 describes how media related to a specific group communication can be distributed over a configured MBS session which consist of multiple QoS flows, i.e. addressing different service requirements.

Pre-conditions:

– VAL UE 1 to n are attached to the 5GS, registered and belong to the same VAL service group X.

– The VAL server has decided to use an MBS session for VAL service group communications associated to VAL service group X.

– VAL UE 2 to n are within the MBS service area where the MBS session is configured.

TimelineDescription automatically generated

Figure 14.3.4A.6.2-1: VAL service group media transmission over MBS sessions

1. The VAL server creates a multicast or a broadcast MBS session targeting group communications associated to VAL service group X via the NRM server, as being specified in clause 14.3.4A.2. Therefore, the VAL server can provide default service requirements to be addressed by the MBS session.

The MBS session is announced by NRM server and received by NRM client 2 to n, which are within the MBS service area. The NRM server has identified that VAL UE 2 to n can receive media over the MBS sessions, e.g. based on a notification from NRM clients indicating the successful join of the multicast MBS session or a monitoring report of the broadcast MBS session (similar to the listening status report used for MBMS).

2. A new VAL group communication is established for the VAL service group X consisting of a specific required service requirements, e.g. a VAL service emergency group communication. The group communication setup can be done over unicast.

2a. For broadcast MBS sessions, the session is established as described in 3GPP TS 23.247 [39].

2b. For multicast MBS session, the session is established upon the acceptance of the first UE session join request initiated from the VAL UE towards the 5GS, as described in 3GPP TS 23.247 [39]. The multicast session can then have either an active or an inactive state.

3. The VAL server may initiate the multicast MBS activation towards the NRM as described in clause 14.3.4A.5 in order to activate the multicast MBS session in case the session has an inactive state.

4. Considering that the established group communication requires a specific QoS, e.g. an VALemergency group communication which requires higher priority (i.e. better ARP), the VAL server initiates an MBS session update to the NRM to provide the new required service requirements, if not done during the MBS session creation in step 1, as described in clause 14.3.4A.2. The MBS session should then be updated and an additional QoS flow may be configured.

5. The NRM server sends a MapGroupToSessionStream to NRM clients 2 to n over the configured MBS session providing the required stream information to receive the media related to the specific established VAL group communication within the MBS session.

6. NRM clients process the MapGroupToSessionStream information to receive the related media over the specific MBS session stream.

7. VAL client 1 sends media to the VAL server over unicast to be distributed for the established group communication.

8. The VAL server distributes the media to VAL clients 2 to n over the indicated stream within the established MBS session.

9. The VAL server may initiate the multicast MBS session deactivation towards the NRM as described in clause 14.3.4A.5, in order to deactivate the multicast MBS session.

10. The NRM server may further trigger the UE to leave multicast MBS session.

14.3.4A.7 Aplication level control signalling over 5G MBS sessions

14.3.4A.7.1 Description

The VAL server may use an 5G MBS session for application level control signalling. An 5G MBS session for application level control signalling is typically used for the purposes beyond the benefit for using 5G for resource efficiency, e.g. for improved MC service performance (KPIs), handling of high load scenarios.

Similar to the usage of eMBMS, both broadcast and multicast 5MBS session for application level control signalling may be used to transmit the following messages, for example:

– MBS session announcement for media sessions

– Group application paging

– Group dynamic data (e.g. status of the group)

5G MBS session for application level control signalling is created in a service area that is larger than the estimated service for media MBS session. The service area for the media sessions is mainly based on counting of group members in each defined service area. The MBS session for application level control signalling is also created with a QoS that is better than MBS media session since the packet loss requirements are much stricter.

The NRM client shall not send responses to group-addressed application level control signalling unless instructed or configured to respond.

14.3.4A.7.2 Procedure

The procedure in figure 14.3.4A.7.2-1 shows only one of the receiving VAL UE using a 5G MBS session.

DiagramDescription automatically generated

Figure 14.3.4A.7.2-1: Use of 5G MBS for application-level control signalling

1. The VAL server determines to create MBS session for application-level control signalling, the VAL server initiated the 5G MBS session establishment via the NRM is done according to clause 14.3.4A.2.

2. The NRM server passes the 5G MBS session info for the service description associated with the 5G MBS session to the NRM client. The NRM client obtains the MBS session ID, from the service description.

NOTE: For 5G MBS and 4G MBMS co-existence, the MBMS bearers activation and MBS session announcement are performed as specified in the procedure for pre-created MBS session and session announcement.

3. The NRM client stores the information associated with the MBS session ID. The NRM client uses the MBS session ID and other 5G MBS session related information to enable monitoring of the 5G MBS session by the VAL UE.

4. Steps 4 to 6 defined in clause 14.3.4A.2 are performed.

5. The VAL server transmits MC application control messages over the MBS session.

14.3.4A.8 Service continuity between 5G MBS delivery and unicast delivery

14.3.4A.8.1 General

This clause addresses the issue of VAL data delivery over MBS session, specifically, to maintain the service continuity when switching between 5G MBS delivery and unicast delivery.

14.3.4A.8.2 Service continuity for broadcast MBS session

14.3.4A.8.2.1 General

This solution provides the procedure which allows the NRM client to report the broadcast reception quality to the NRM server which is used to make the decision whether to use the unicast delivery to the VAL UE(s) which are suffering bad broadcast reception quality due to e.g., move out of the broadcast service area.

An NRM client monitors the broadcast MBS session to receive VAL data. Based on the received quality (e.g., radio level quality, RTP packet loss), the NRM client needs to inform the NRM server that the NRM client is able to receive the VAL data on the broadcast MBS session with sufficient quality or not.

This estimation of the broadcast reception quality may be dependent on, for example, the modulation and coding scheme (MCS) and measurements from the reference signals from the NG-RAN node(s), RTP packet loss, BLER of the received VAL data.

14.3.4A.8.2.2 Procedures

14.3.4A.8.2.2.1 Service continuity from broadcast to unicast

The procedure in figure 14.3.4A.8.2.2.1-1 illustrates the VAL UE which is receiving VAL data via broadcast MBS session is switched to unicast delivery because the VAL UE suffers from bad broadcast reception quality due to e.g., moving out of the broadcast service area. It shows only one of the receiving VAL UEs receiving the broadcast MBS session.

Pre-conditions:

1. The VAL group communication is ongoing and the VAL data (e.g., DL media, application layer control signalling) is transmitted via broadcast MBS session.

2. The NRM client is receiving the VAL data (e.g., DL media, application layer control signalling) via the broadcast MBS session.

3. The NRM client(s) already have the associated information (e.g., SDP) to receive the unicast delivery during the group communication establishment phase.

4. An VAL group communication session is ongoing and the DL VAL data is transmitted over broadcast MBS session.

Figure 14.3.4A.8.2.2.1-1: Service continuity from broadcast to unicast

1. The NRM client detects that it suffers bad broadcast reception due to e.g., moving out of the broadcast service area of the announced MBS session ID. The NRM client may determine the broadcast reception quality by using the BLER of the received media. When no media is received, the quality estimation can consider the reference signals and the modulation and coding scheme (MCS).

2. The NRM client sends MBS listening status report which indicates the broadcast reception quality associated with the MBS session ID is not sufficient to receive media. The NRM client may also map the determined broadcast reception quality to a broadcast reception quality level. The broadcast reception quality level indicates at which specific broadcast reception quality level the VAL data has been received.

NOTE 1: It is implementation that the broadcast reception quality level can be determined per MBS session, per media stream or per MBS QoS flow level via e.g., measurements of radio level signalling such as the reference signals from the NG-RAN node(s), packet loss.

NOTE 2: The set of MBS reception quality levels and the mapping of the determined broadcast reception quality to those levels are implementation.

NOTE 3: The frequency of VAL UE sending listening reports can be limited to prevent signalling congestion. E.g., the VAL UE can stop monitoring the broadcast reception quality and send the MBS listening status report only once when it moves outside of the broadcast service area.

3. The NRM server based on the report from the participant, determines that the UE is not able to receive the media or the QoS requirements is not satisfied. The NRM server determines the VAL media (e.g., DL media, application layer control signalling) needs to be delivered via the unicast delivery to the reported NRM client.

4. If the unicast QoS flow is not satisfied, the NRM server interacts with the 5GC to update the QoS requirements.

5. The NRM server informs the VAL server to send the VAL data via the unicast delivery towards the reported NRM client by sending a user plane delivery mode message.

6. The NRM server sends the VAL media via the unicast delivery towards the NRM client which suffers bad broadcast reception quality.

7. The NRM client then receives the DL VAL data via both broadcast MBS session and unicast delivery.

14.3.4A.8.2.2.2 Service continuity from unicast to broadcast

The procedure in figure 14.3.4A.8.2.2.2-1 illustrates the VAL UE receiving VAL data via unicast delivery being switched to broadcast MBS session as the UE enters the broadcast service area where the NG-RAN is broadcasting the VAL media of the ongoing group communication. The VAL UE now is able to receive the VAL data via the broadcast MBS session. Only one of the receiving VAL UEs receiving the broadcast MBS session is shown.

Pre-conditions:

1. The VAL group communication is ongoing and the VAL data (e.g., DL media, application layer control signalling) is transmitted via broadcast MBS session in the broadcast service areas.

2. The VAL UE is receiving the VAL data (e.g., DL media, application layer control signalling) via the unicast delivery.

3. The NRM client has already received the broadcast MBS session announcement, MapVALGroupToSessionStream information and enters the broadcast service area.

4. A VAL group communication session is ongoing and the broadcast MBS session is used by the VAL server to deliver the VAL data of the group communication. The VAL UE is receiving the VAL data via the unicast delivery.

Figure 14.3.4A.8.2.2.2-1: Service continuity from unicast to broadcast

1. The NRM client detects that it is able to receive the broadcast media due to e.g., moving into the broadcast service area of the announced MBS session ID. The NRM client may determine the broadcast reception quality by using the BLER of the received media. When no media is received, the quality estimation can consider the reference signals and the modulation and coding scheme (MCS).

2. The NRM client sends MBS listening status report which indicates the broadcast reception quality associated with the MBS session ID is sufficient to receive VAL data. The NRM client may also map the determined broadcast reception quality to a broadcast reception quality level. The broadcast reception quality level indicates at which specific broadcast reception quality level the VAL data has been received.

NOTE 1: The set of MBS reception quality levels and the mapping of the determined broadcast reception quality to those levels are up to implementation.

NOTE 2: It is up to implementation that the broadcast reception quality level can be determined per MBS session, per media stream or per MBS QoS flow level via e.g., measurements of radio level signals, such as the reference signals from the NG-RAN node(s), or packet loss.

3. The NRM server determines the VAL UE is able to receive the VAL data via the the broadcast MBS session, and the NRM server sends a user plane delivery mode to the VAL server indicating to stop the unicast delivery.

4. Based on the MapVALGroupToSessionStream received before, the NRM client receives the DL VAL data via both the broadcast MBS session and the unicast delivery.

NOTE 3: If any information about the broadcast MBS session stream has changed, the NRM server provides the MapVALGroupToSessionStream again.

5. The VAL server, based on the user plane delivery mode message, determines to stop sending the VAL data (e.g., DL media, application layer control signalling) via the unicast delivery to the reporting NRM client. After then, the NRM client receives the VAL data only via the broadcast MBS session.

14.3.4A.8.3 Service continuity for multicast MBS session

14.3.4A.8.3.1 General

The NRM server may also switch between multicast and unicast by utilizing application layer mechanisms similar to switching between broadcast and unicast as specified in clause 14.3.4A.8.2. If indicated in the MBS session announcement information, the NRM client reports the monitoring state (i.e., the reception quality of the MBS session) back to the NRM server.

NOTE: Once the VAL UE has successfully joined the multicast MBS session and started to receive the VAL data via the multicast MBS session, then the network mechanism specified in 3GPP TS 23.247 [39] will deliver the media from the NRM server via the 5GC Individual MBS traffic delivery method or the 5GC Shared MBS traffic delivery method towards the VAL UE(s). The usage of 5GC Individual MBS traffic delivery method or the 5GC Shared MBS traffic delivery method is transparent to the NRM server and VAL server.

14.3.4A.9 Service continuity between 5G MBS delivery and unicast delivery

14.3.4A.9.1 General

This clause addresses the issue of VAL data delivery over MBS session, specifically, to maintain the service continuity when switching between 5G MBS delivery and unicast delivery.

14.3.4A.9.2 Service continuity for broadcast MBS session

14.3.4A.9.2.1 General

14.3.4A.9.2.2 Procedures

14.3.4A.9.2.2.1 Service continuity from broadcast to unicast

The procedure in figure 14.3.4A.9.2.2.1-1 illustrates the VAL UE which is receiving VAL data via broadcast MBS session is switched to unicast delivery because the VAL UE suffers from bad broadcast reception quality due to e.g., moving out of the broadcast service area. It shows only one of the receiving VAL UEs receiving the broadcast MBS session.

Pre-conditions:

1. The VAL group communication is ongoing and the VAL data (e.g., DL media, application layer control signalling) is transmitted via broadcast MBS session.

2. The NRM client is receiving the VAL data (e.g., DL media, application layer control signalling) via the broadcast MBS session.

3. The NRM client(s) already have the associated information (e.g., SDP) to receive the unicast delivery during the group communication establishment phase.

4. An VAL group communication session is ongoing and the DL VAL data is transmitted over broadcast MBS session.

Figure 14.3.4A.9.2.2.1-1: Service continuity from broadcast to unicast

NOTE 2: The set of MBS reception quality levels and the mapping of the determined broadcast reception quality to those levels are implementation.

4. If the unicast QoS flow is not satisfied, the NRM server interacts with the 5GC to update the QoS requirements.

5. The NRM server informs the VAL server to send the VAL data via the unicast delivery towards the reported NRM client by sending a user plane delivery mode message.

6. The NRM server sends the VAL media via the unicast delivery towards the NRM client which suffers bad broadcast reception quality.

7. The NRM client then receives the DL VAL data via both broadcast MBS session and unicast delivery.

14.3.4A.9.2.2.2 Service continuity from unicast to broadcast

Pre-conditions:

1. The VAL group communication is ongoing and the VAL data (e.g., DL media, application layer control signalling) is transmitted via broadcast MBS session in the broadcast service areas.

2. The VAL UE is receiving the VAL data (e.g., DL media, application layer control signalling) via the unicast delivery.

3. The NRM client has already received the broadcast MBS session announcement, MapVALGroupToSessionStream information and enters the broadcast service area.

Figure 14.3.4A.9.2.2.2-1: Service continuity from unicast to broadcast

NOTE 1: The set of MBS reception quality levels and the mapping of the determined broadcast reception quality to those levels are up to implementation.

4. Based on the MapVALGroupToSessionStream received before, the NRM client receives the DL VAL data via both the broadcast MBS session and the unicast delivery.

NOTE 3: If any information about the broadcast MBS session stream has changed, the NRM server provides the MapVALGroupToSessionStream again.

14.3.4A.9.3 Service continuity for multicast MBS session

14.3.4A.9.3.1 General

The NRM server may also switch between multicast and unicast by utilizing application layer mechanisms similar to switching between broadcast and unicast as specified in clause 14.3.4A.9.2. If indicated in the MBS session announcement information, the NRM client reports the monitoring state (i.e., the reception quality of the MBS session) back to the NRM server.

14.3.4A.10 VAL service inter-system switching between 5G and LTE

14.3.4A.10.1 General

The VAL server delivers the VAL data to the VAL UE(s) without being aware of the mobility of the VAL UE with the assistance and guidance of the NRM server. When working in transport only mode, the NRM server guides the NRM clients throughout the VAL data transmission for switching between the LTE and 5G systems. For this purpose, the location management client sends location related information to the location management server, similar to the one defined in clause 9, which is triggered due to its location change – in this case due to Radio Access Technology (RAT) change, to inform the NRM server hence the latter provides guidance related to how to receive the VAL data after the location update.

Editor’s note: The location management service for triggering location reporting due to RAT change is to be specified in clause 9.

The procedures cover both the deployment scenarios with/without MBSF/MBSTF. The procedures specify four inter-system switching related scenarios as follows:

1. Inter-system switching from 5G MBS session to LTE eMBMS bearer, as in 14.3.4A.10.2

2. Inter-system switching from 5G MBS session to LTE unicast bearer, as in 14.3.4A.10.3

3. Inter-system switching from LTE eMBMS to 5G MBS session, as in 14.3.4A.10.4

4. Inter-system switching from LTE eMBMS to 5G unicast PDU session, as in 14.3.4A.10.5

In all the inter-system switching related scenario described in 14.3.4A.10.2, 14.3.4A.10.3, 14.3.4A.10.4 and 14.3.4A.10.5, the functional entity that resides in 5GS may be NEF, or MBSF, or MB-SMF for session creation and together with PCF or PCC related interaction.

NOTE: There will be a service interruption when the VAL server performs path switch between 5G and LTE bearers or sessions.

14.3.4A.10.2 Inter-system switching from 5G MBS session to LTE eMBMS bearer

The procedure provided in figure 14.3.4A.10.2-1 describes how the NRM server handles inter-system switching when the VAL UE switches from 5G to LTE network, where the NRM server is able to provide the VAL data to the clients over eMBMS bearer(s).

Pre-conditions:

– NRM clients are attached to the 5GS, registered.

– The VAL service can be provided via both 5GS and EPS.

– The NRM client(s) is within the eMBMS service area.

– It is assumed that the NRM client(s) has not received the eMBMS bearer announcement while camping in 5GS.

Figure 14.3.4A.10.2-1: Inter-system switching from 5G MBS session to LTE eMBMS bearer.

1. An VAL group communication takes place, and the VAL data is delivered over 5G MBS session (either broadcast or multicast session mode), which is associated to the VAL group X.

2. The VAL UE performs handover to EPS.

3. Location information indicating the RAT change from the VAL UE is provided to the NRM server. VAL UE`s location information is provided via the location management client, triggered by RAT change, to the location management server, where the latter provides the location information to the NRM server. Also, location information handling can be based on notifications provided from the network to the NRM server related to 5GS supporting EPS interworking, as specified in 3GPP TS 23.501 [10], 3GPP TS 23.502 [11], and 3GPP TS 23.503 [12]. For that, the NRM server can subscribe to receive notifications of specific events from the network. For instance, the NRM server can subscribe to PCF related notifications (via N5 or Rx) for specific events, e.g., access network information notification and change of access type. Also, when SCEF+NEF is deployed, the NRM server can subscribe to SCEF+NEF related notifications for specific events, e.g., core network (CN) type change.

4. The NRM server analyses the RAT change and decides how to deliver the DL VAL data. If the NRM server decides to serve the client via eMBMS bearer, it may send an eMBMS bearer announcement. This step is optional as the bearer announcement related information could be sent in advance (implementation specific).

5. If not already available, the NRM client stores the announced TMGI(s), service area, and any relevant information to the eMBMS, which is delivered via the bearer announcement. As a result, the NRM client starts monitoring the bearer.

6. The NRM server may inform the VAL server to stop sending DL VAL data via the MBS by sending the user plane delivery mode message, e.g., when the last UE leaves the MBS session or move out of the MBS service area.

7. The NRM client sends an eMBMS listening status report to inform the server of its ability of receiving DL VAK data over the specified bearer.

8. The NRM server sends the necessary information related to receiving the DL VAL data in the form of the MapGroupToBearer.

9. The NRM server may inform the VAL server to start sending DL VAL data via the eMBMS by sending the user plane delivery mode message, e.g., the first UE(s) enters the eMBMS service area.

10. The VAL group communication takes place over EPS, and the VAL data is transmitted over an eMBMS bearer.

14.3.4A.10.3 Inter-system switching from 5G MBS session to LTE unicast bearer

The procedure provided in figure 14.3.4A.10.3-1 describes how the NRM server handles inter-system switching when the VAL UE switches from 5G to LTE network, where the VAL server is unable to provide the VAL services to the VAL UE over eMBMS bearer.

Pre-conditions:

– NRM clients are attached to the 5GS, registered and affiliated to the same VAL group X.

– The VAL services can be provided via both 5GS and EPS.

Figure 14.3.4A.10.3-1: Inter-system switching from 5G MBS session to LTE unicast bearer.

1. An VAL group communication takes place, and the VAL data is delivered over 5G MBS session (either broadcast or multicast session mode), which is associated to the VAL group X.

2. The VAL UE performs handover to EPS.

Also, location information handling can be based on notifications provided from the network to the NRM server related to 5GS supporting EPS interworking, as specified in 3GPP TS 23.501 [10], 3GPP TS 23.502 [11], and 3GPP TS 23.503 [12]. For that, the NRM server can subscribe to receive notifications of specific events from the network. For instance, the NRM server can subscribe to PCF related notifications (via N5 or Rx) for specific events, e.g. access network information notification and change of access type. Also, when SCEF+NEF is deployed, the NRM server can subscribe to SCEF+NEF related notifications for specific events, e.g. core network (CN) type change.

4. The NRM server may inform the VAL server to stop sending DL VAL data via the MBS by sending the user plane delivery mode message, e.g., when the last UE leaves the MBS session or move out of the MBS service area.

5. The NRM server may interact with the EPC for providing the required media resources over the unicast bearer, if not already allocated.

6. The NRM server informs the VAL server to send DL VAL data to the VAL UE via the LTE unicast bearer by sending the user plane delivery mode message.

7. The VAL group communication takes place over EPS, and the DL VAL data is transmitted over a LTE unicast bearer.

14.3.4A.10.4 Inter-system switching from LTE eMBMS to 5G MBS session

The procedure provided in figure 14.3.4A.10.4-1 describes how the NRM server handles inter-system switching when the VAL UE switches from LTE network to 5G, where the NRM server is able to provide the VAL services to the client over 5G MBS sessions (either broadcast or multicast).

Pre-conditions:

– NRM clients are attached to the EPC.

– The VAL services can be provided via both 5GS and EPS.

– The NRM client(s) is within the service area (if the session is limited to an area), where the MBS session is configured.

– It is assumed that the NRM client(s) has not received the 5G MBS session announcement while camping in EPS.

Figure 14.3.4A.10.4-1: Inter-system switching from LTE eMBMS bearer to 5G MBS sessions (either broadcast or multicast).

1. An VAL group communication takes place, and the DL VAL data is delivered over eMBMS bearer, which is associated to the VAL group X.

2. The VAL UE performs handover to 5GS.

Also, location information handling can be based on notifications provided from the network to the NRM server related to 5GS supporting EPS interworking, as specified in 3GPP TS 23.501 [10], 3GPP TS 23.502 [11], and 3GPP TS 23.503 [12]. For that, the NRM server can subscribe to receive notifications of specific events from the network. For instance, the NRM server can subscribe to PCF related notifications (via N5 or Rx) for specific events, e.g., access network information notification and change of access type. Also, when SCEF+NEF is deployed, the NRM server can subscribe to SCEF+NEF related notifications for specific events, e.g., core network (CN) type change.

4. The NRM server analyses the RAT change and decides how to deliver the DL VAL data. If the NRM server decides to serve the client via 5G MBS session, it may send an MBS session announcement indicating information among others the session mode to serve the NRM client and the corresponding MBS session ID. This step is optional as the session announcement related information could be sent in advance (implementation specific).

5. The VAL UE acts according to the MBS session mode provided to receive the DL media.

5a. In case of multicast MBS sessions, the VAL UE performs a UE session join towards the 5GC indicating the MBS session ID to join. It may as well send a UE session join acknowledgement to the NRM server.

5b. In case of broadcast MBS sessions, the VAL UE starts monitoring the broadcast MBS session. 6. The NRM server may inform the VAL server to stop sending DL VAL data via the eMBMS bearer by sending the user plane delivery mode message, e.g., when the last UE moves out of the MBMS service area.

7. The NRM client sends an MBS listening status report to the server indicating its ability to receive media over the indicated MBS session.

8. The NRM server sends a MapVALGroupToSessionStream over the MBS session providing the required stream information to receive the media related to the group communication.

9. The NRM client processes the received information related to the DL VAL data over the MBS session.

10. The NRM server may inform the VAL server to start sending DL VAL data via the 5G MBS session by sending the user plane delivery mode message, e.g., the first UE(s) enters the MBS service area or joins the multicast MBS session.

11. The VAL group communication takes place over 5GS, and the DL VAL data is delivered over the broadcast or multicast MBS session.

14.3.4A.10.5 Inter-system switching from LTE eMBMS to 5G unicast PDU session

The procedure provided in figure 14.3.4A.10.5-1 describes how the NRM server handles inter-system switching when the VAL UE switches from LTE network to 5G, where the NRM server is able to provide the VAL services to the client over 5G MBS sessions (either broadcast or multicast).

Pre-conditions:

– NRM clients are attached to the EPC and affiliated to the same VAL group X.

– The VAL services can be provided via both 5GS and EPS.

Figure 14.3.4A.10.5-1: Inter-system switching from LTE eMBMS bearer to 5G unicast PDU session.

1. An VAL group communication takes place, and the VAL data is delivered over eMBMS bearer, which is associated to the VAL group X.

2. The VAL UE performs handover to 5GS.

4. The NRM server may inform the VAL server to stop sending DL VAL data via the eMBMS bearer by sending the user plane delivery mode message, e.g., when the last UE moves out of the LTE MBMS service area.

5. The NRM server may interact with the 5GC to request media resources (if not already allocated) with specific requirements over unicast PDU session, as it is able to serve the NRM client via unicast PDU session.

6. The NRM server informs the VAL server to send DL VAL data to the VAL UE via the PDU session by sending the user plane delivery mode message.

7. The VAL group communication takes place over 5GS, and the VAL data is delivered over unicast PDU session.