Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.434  Word version:  19.2.0

Top   Top   Up   Prev   Next
0…   4…   5   6…   6.4…   6.5…   6.5.3…   7…   8…   8.2.2…   9…   9.3…   9.3.2.21…   9.3.3…   9.3.6…   9.3.11…   9.3.13…   9.3.14…   9.4…   9.4.6…   9.5…   10…   10.3…   10.3.2.22…   10.3.3…   10.3.7…   10.3.10…   10.4…   11…   11.3…   11.3.3…   11.4…   12…   12.3…   13…   14…   14.2.2.2…   14.3…   14.3.2.20…   14.3.2.40…   14.3.3…   14.3.3.3…   14.3.4…   14.3.4.6   14.3.4.7…   14.3.4A…   14.3.4A.3…   14.3.4A.4…   14.3.4A.6…   14.3.4A.8…   14.3.4A.9…   14.3.4A.10…   14.3.5…   14.3.6…   14.3.9…   14.3.12…   14.4…   15…   16…   17…   18…   A   B…

 

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

14.3.4A.1  Generalp. 216

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. 217

14.3.4A.2.1  Generalp. 217
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. 217
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.
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. 219
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.1.
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

Up   Top   ToC