Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.434  Word version:  19.4.2

Top   Top   Up   Prev   Next
0…   6…   8…   9…   9.3…   9.3.3…   9.3.8…   9.3.13…   9.3.20…   9.3.23…   9.4…   10…   10.3…   10.3.3…   10.3.7…   10.4…   11…   12…   13…   14…   14.3…   14.3.3   14.3.4   14.3.4A…   14.3.4A.5…   14.3.4A.8…   14.3.5…   14.3.9…   14.4…   15…   17…   18…   A…

 

14.3.4A  Multicast resource management for 5GS |R18|p. 253

14.3.4A.1  Generalp. 253

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 communication 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 consist of one or multiple QoS flows for different service requirements are either broadcast or multicast type. For the broadcast MBS session or local MBS session, the MBS service area is configured with the MBS session.
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 in RRC-CONNECTED state and RRC_INACTIVE 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, UE session join notification 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.
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.
Up

14.3.4A.2  MBS session creation and MBS session announcementp. 255

14.3.4A.2.1  Generalp. 255
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 announcementp. 255
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.
Reproduction of 3GPP TS 23.434, Fig. 14.3.4A.1.2-1: Use of pre-created MBS session.
Up
Step 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.
Step 2.
The NRM server initiates an MBS session creation procedure towards the 5GC as described in TS 23.247. 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.
In the case of an untrusted NRM server, when the requested MBS service area crosses several MB-SMF service areas, the NEF/MBSF rejects the TMGI allocation request, and it guides the NRM server by dividing the requested MBS service area into groups and returns the groups as described in TS 23.247. Hence, the NRM server initiates a new TMGI allocation request for each grouped MBS service area. If during MBS session creation request the 5GS discovers that the MBS service area crosses several MB-SMF service areas, the request is rejected and the NEF/MBSF guides the NRM server by dividing the requested MBS service area into groups and returns the groups as described in TS 23.247. The NRM initiates a new MBS session creation procedure for each grouped MBS service area.
The NRM server may utilize a unicast session if any MBS service area is not supported by any MB-SMF.
Step 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.
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 TS 23.280.
Step 4.
NRM clients store and process the received MBS session information.
Step 5.
NRM clients may provide an MBS session announcement acknowledgment to the NRM server to indicate the reception of the corresponding MBS session announcement.
Step 6.
Based on the MBS session mode (either multicast or broadcast), the following actions take place;
Step 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 TS 23.247. The NRM clients sends a UE session join notification towards the server as indicated in the MBS session announcement. 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
Step 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 TS 23.247, 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.
Step 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.
Step 8.
The NRM server provides a multicast/broadcast resource response to the VAL server.
Step 9.
An VAL service group communication setup takes place and uses the pre-created MBS session for this group communication packet DL delivery.
Up
14.3.4A.2.3  Procedure for dynamic MBS sessionsp. 257
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.
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.
Reproduction of 3GPP TS 23.434, Fig. 14.3.4A.2.3-1: Use of dynamic MBS session
Up
Step 1.
An VAL service group communication session is established and the DL media packet is delivered to the VAL client via unicast.
Step 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.
Step 3.
The NRM server decides to create an MBS session. The MBS session creation procedure takes place as described in clause 14.3.4A.2.2.
Step 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 TS 23.280.
Step 5.
The NRM client stores the MBS session ID and other associated information.
Step 6.
The NRM client may send an MBS session announcement ack back to the NRM server.
Step 7.
Based on the MBS session mode (either multicast or broadcast), the following actions take place:
Step 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 TS 23.247. The NRM client sends a UE session join notification towards the server as indicated in the MBS session announcement. 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
Step 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 TS 23.247, 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.
Step 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.
Step 9.
The NRM server provides a multicast/broadcast resource response to the VAL server.
Step 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.
Up

14.3.4A.3  MBS resources updatep. 259

14.3.4A.3.1  Generalp. 259
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 rulep. 259
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 TS 23.247.
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.
Reproduction of 3GPP TS 23.434, Fig. 14.3.4A.3.2-1: MBS session update without dynamic PCC
Up
Step 1.
An MBS session is established as described in in TS 23.247 (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.
Step 2.
The VAL server invokes 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, MBS 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.
Step 3.
The NRM server sends an MBS session update request towards the 5GC, either directly or via NEF, as described in TS 23.247, either directly or indirectly via NEF.
Step 4.
Based on the needed requirements, the corresponding MBS session is accordingly modified at the 5GS as described in TS 23.247. The update may lead to QoS Flow(s) addition, modification, or removal.
Step 5.
The NRM server receives an MBS session update response from the 5GS either directly or via NEF once the requested modifications are performed, and the indicated MBS session is updated accordingly.
Step 6.
In case of untrusted NRM server, if the requested MBS service area crosses several MB-SMF service areas, the requested MBS service area to be updated is partially accepted by the 5GC as described in TS 23.247. The reduced MBS service area is grouped and provided by the NEF/MBSF in the response. Hence, the NRM server sends a new MBS session creation request as described in clause 14.3.4A.2.2. for each grouped MBS service area.
Step 7.
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.
Step 8.
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.
Step 9.
The NRM clients process the received information over the MapGroupToSessionStream in order to receive the associated VAL media over the specific MBS session stream.
Step 10.
The NRM server returns the multicast resource update response to the VAL server.
Step 11.
If the MBS session creation is failed towards the grouped MBS service areas in step 6, then the NRM server indicates to the VAL server to use unicast delivery for that grouped MBS service areas via by sending the user plane delivery mode message.
Step 12.
VAL client 1 sends media to the VAL server over unicast to be distributed for the established group communication.
Step 13.
The VAL server distributes the VAL media to the VAL clients 2 to n over the indicated streams.
Up
14.3.4A.3.3  Procedure for updating MBS resources with dynamic PCC rulep. 261
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 TS 23.247.
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.
Reproduction of 3GPP TS 23.434, Fig. 14.3.4A.3.3-1: MBS session update with dynamic PCC
Up
Step 1.
An MBS session is established as described in TS 23.247 (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.
Step 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.
Step 3.
The NRM server sends an MBS session update request towards the 5GC as described in TS 23.247, either directly or indirectly via NEF.
Step 4.
Based on the update requirements perform the MBS session is updated with PCC procedure as described in TS 23.247.
Step 5.
The NRM server receives an MBS session update response from the 5GC either directly or via NEF once the requested modifications are performed, and the indicated MBS session is updated accordingly.
Step 6.
In case of untrusted NRM server, if the requested MBS service area crosses several MB-SMF service areas, the requested MBS service area to be updated is partially accepted by the 5GC, as described in TS 23.247. The reduced MBS service area is grouped and provided by the NEF/MBSF in the response. Hence, the NRM server sends a new MBS session creation request as described in clause 14.3.4A.2.2. for each grouped MBS service area.
Step 7.
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.
Step 8.
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.
Step 9.
The NRM server returns the multicast resource update response to the VAL server.
Step 10.
The NRM clients process the received information over the MapGroupToSessionStream in order to receive the associated VAL media over the specific MBS session stream.
Step 11.
If the MBS session creation is failed towards the grouped MBS service areas in step 6, then the NRM server indicates to the VAL server to use unicast delivery for that grouped MBS service areas via by sending the user plane delivery mode message.
Step 12.
VAL client 1 sends media to the VAL server over unicast to be distributed for the established group communication.
Step 13.
The VAL server distributes the VAL media to the VAL clients 2 to n over the indicated streams.
Up

14.3.4A.4  MBS resource deletionp. 262

14.3.4A.4.1  Generalp. 262
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.
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 TS 23.247.
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.
Up
14.3.4A.4.2  Procedurep. 263
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.
Reproduction of 3GPP TS 23.434, Fig. 14.3.4A.4.2-1: MBS session deletion procedure.
Up
Step 1.
The VAL server decides to delete the MBS session for the associated VAL group communication, either multicast or broadcast session.
Step 2.
The VAL server invokes the multicast/broadcast resource release service of the NRM server by sending the multicast/broadcast resource release request.
Step 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.
Step 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.
Step 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 TS 23.247.
Step 5.
Subsequently, the NRM clients may send an MBS session de-announcement acknowledgement message to the NRM server indicating the status of MBS session.
Step 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 TS 23.247.
Step 7.
The NRM server returns the multicast/broadcast resource release response to the VAL server indicating the result.
Up

Up   Top   ToC