Access Network Signaling and Resource Allocation for Multicast / Broadcast Sessions

Abstract

The present disclosure describes an architecture for supporting MBS sessions in a radio access network. Each such MBS session is flexibly and dynamically delivered by the access network into one or more point-to-point (PTP, or unicast) and point-to-multipoint (PTM, or multicast) delivery instances. In this way, a subset of UEs participating in the MBS can be configured to receive the MBS session in a PTP-like manner and quality. The architecture also allows one or more UEs participating in the MBS session to perform access network-level switching between the PTP mode and the PTM mode. This switching is dynamically implemented and does not require the participation of the application layer. Resource allocation and configuration of the PTP and PTM delivery instances can be jointly performed in the access network between a central unit (CU) and one or more distributed units (DU). This collaborative resource allocation and configuration can be implemented using a new architecture for signaling messages between the CU and the DU.

Description

Technical Field

[0001] The present disclosure generally relates to multicast / broadcast service (MBS) session context management and resource allocation in a wireless communication network, and more particularly to access network-level signaling and resource allocation for point-to-point (PTP) and point-to-multipoint (PTM) transmission of MBS session data or packet data units (PDUs) to user equipment. Background Art

[0002] There has been a continuous demand for multicast broadcast service (MBS) in wireless communication networks. Such services have gradually expanded from the initial television-like terrestrial broadcast video broadcast service to public safety, vehicle-to-everything (V2X), Internet of Things (IoT), and other application areas. Flexible and dynamic resource allocation and signaling mechanisms are urgently needed to achieve reliable and efficient delivery of MBS session data to multiple user equipments (UEs) with different reception conditions and requirements. Summary of the Invention

[0003] The present disclosure relates to methods, systems, and devices for MBS session resource allocation, and particularly to methods, systems, and devices for context management and delivery mode switching. In particular, the present disclosure describes an architecture for supporting MBS sessions in a radio access network. Each such MBS session is flexibly and dynamically delivered by the access network into one or more point-to-point (PTP, or unicast) and point-to-multipoint (PTM, or multicast) delivery instances. In this way, a subset of UEs participating in the MBS can be configured to receive the MBS session in a PTP-like manner and quality. The architecture also allows one or more UEs participating in the MBS session to perform access network-level switching between the PTP mode and the PTM mode. Such switching is dynamically implemented without the involvement of the application layer. Resource allocation and configuration of PTP and PTM delivery instances can be performed collaboratively between a central unit (CU) and one or more distributed units (DUs) in the access network. Such collaborative resource allocation and configuration can be achieved using a novel architecture for signaling messages between the CU and the DU.

[0004] In some exemplary embodiments, a method for wireless resource allocation is disclosed, which is performed by a first access network node (ANN) communicating with a second ANN in a wireless communication network. The method may include: receiving, from the second ANN, one or more requests for establishing, modifying, or releasing resource allocation in the first ANN for transmitting service data of a multicast / broadcast service (MBS) session to a group of user equipments (UEs) in a point-to-point (PTP) delivery mode and a point-to-multipoint (PTM) delivery mode, and for transmitting control information between the first ANN and the second ANN, wherein the one or more requests include an MBS session identifier; based on the one or more requests, establishing, modifying, or releasing the resource allocation in the first ANN; generating configuration information corresponding to the resource allocation; and transmitting the configuration information to the second ANN. Description of the Drawings

[0005] Figure 1 An exemplary wireless communication network architecture is shown.

[0006] Figure 2 An exemplary protocol stack of a control plane and a user plane in a centralized radio access network node (ANN) and a distributed radio access network node is shown.

[0007] Figure 3 An exemplary resource allocation and data path through different layers and network entities are shown for delivering MBS to a group of UEs served by different cells in a point-to-point (PTP) and a point-to-multipoint (PTM) delivery mode.

[0008] Figure 4 An exemplary serving cell configuration and attributes of delivery modes and delivery instances among individual UEs within the serving cell are shown.

[0009] Figure 5 An exemplary signaling flow for managing MBS context and resource allocation through a centralized unit ANN and a distributed unit ANN is shown.

[0010] Figure 6 An exemplary data tunnel configuration for sending PDCP PDUs from a CU to a DU is shown.

[0011] Figure 7 Another exemplary data tunnel configuration for sending PDCP PDUs from a CU to a DU is shown.

[0012] Figure 8 Another exemplary data tunnel configuration for sending and retransmitting PDCP PDUs from a CU to a DU and for sending a PDCP status report of a UE from a DU to a CU is shown.

[0013] Figure 9Shows another exemplary data tunnel configuration for sending and retransmitting PDCP PDUs from the CU to the DU and for sending the PDCP status report of the UE from the DU to the CU.

[0014] Figure 10 Shows another exemplary data tunnel configuration for sending and retransmitting PDCP PDUs from the CU to the DU and for sending the PDCP status report of the UE from the DU to the CU.

[0015] Figure 11 Shows an example option of the user plane architecture of the delivery instance.

[0016] Figure 12 Shows other example options of the user plane architecture of the delivery instance.

[0017] Figure 13 Shows some other example options of the user plane architecture of the delivery instance. Detailed Description

[0018] The following description and drawings elaborate in detail certain exemplary embodiments of the present disclosure, which indicate several example ways in which the various principles of the present disclosure can be implemented. However, the shown examples are not an exhaustive list of the many possible embodiments of the present disclosure. Other objects, advantages, and novel features of the present disclosure will be set forth in the following detailed description in conjunction with the drawings.

[0019] Introduction

[0020] To some extent, multicast and broadcast services (MBS) have been provided in wireless systems. One such example includes the evolved Multimedia Broadcast Multicast Service (eMBMS) technical architecture in 4G wireless communication systems. However, various limitations of the eMBMS technology have restricted the expansion of cellular broadcast services from traditional TV-like terrestrial video broadcast applications to application scenarios including but not limited to public safety, vehicle-to-everything (V2X), Internet of Things (IoT), etc. In particular, the traditional eMBMS broadcast network architecture is basically designed for semi-static video service distribution. For example, the delivery of LTE eMBMS over the air interface does not depend on feedback from the UE or depends very limitedly on feedback from the UE. Thus, the network can only understand the user's reception interest in the MBS and the reception quality of the MBS to a very limited extent. Therefore, such a network architecture cannot provide flexible and dynamic MBS resource allocation and scheduling, resulting in inefficient use of air interface resources.

[0021] The single-cell point-to-multipoint (SC-PTM) technology is further introduced to improve the flexibility of air interface scheduling to some extent. However, the SC-PTM technology essentially relies on the same basic principles as the network architecture before SC-PTM, and only adds an air interface data bearing mechanism based on independent scheduling in a single cell. For example, instead of using the physical multicast channel in traditional eMBMS, the SC-PTM technology uses the PDSCH (Physical Downlink Shared Channel) which is more consistent with unicast data. Despite these improvements, the SC-PTM technology still cannot solve the problems related to, for example, the semi-static characteristics of broadcast area configuration at the architecture level. In addition, as a network-side technology, SC-PTM cannot be fully coordinated with the flexible and powerful air interface in the existing 3GPP framework. Therefore, it may be difficult to achieve the effective utilization of communication resources and ensure service reliability and continuity.

[0022] In particular, when the reception quality of a UE receiving MBS session data has been degraded or improved, it may be necessary for the UE receiving MBS session data to switch from the point-to-multipoint delivery mode to the point-to-point delivery mode, and vice versa. Based on the current LTE multicast-broadcast technology such as the above-mentioned eMBMS, such a UE can only switch between unicast and broadcast at the application layer. Therefore, it may result in a long switching delay and potential service interruption. In time-sensitive multicast-broadcast services (such as MCPTT (Mission-Critical Push-to-Talk) for public safety applications), such delays and interruptions may be intolerable.

[0023] The following various embodiments describe an architecture for supporting MBS sessions in a radio access network. Each such MBS session is flexibly and dynamically delivered by the access network using one or more point-to-point (PTP, or unicast) and point-to-multipoint (PTM, or multicast) delivery instances. Therefore, a subset of UEs participating in the MBS can be configured to receive MBS session data in the PTP manner. The architecture also allows one or more UEs participating in the MBS session to perform an access network-level switch between the PTP mode and the PTM mode. This switch is dynamically implemented without the participation of the application layer. The resource allocation and configuration of the PTP and PTM delivery instances can be performed collaboratively between a central unit (CU) and one or more distributed units (DUs) in the access network. This collaborative resource allocation and configuration can be achieved using a novel architecture for signaling messages between the CU and the DU.

[0024] Wireless communication network architecture

[0025] Figure 1FIG. 100 shows an exemplary wireless communication network including a user equipment (UE) and a carrier network. For example, the carrier network may also include a radio access network 140 and a core network 110. The radio access network may include one or more various types of radio base stations or radio access network nodes (ANNs) 120 and 121, which may include, but are not limited to, gNBs, eNodeBs, NodeBs, or other types of base stations. The access network 140 is backhaul connected to the core network 110. The radio ANN 120 may also include, for example, a plurality of individual ANNs in the form of a centralized unit (CU) 122 and at least one distributed unit (DU) 124 and 126. The CU 122 is connected to the DU1 124 and the DU2 126 via various F1 interfaces. The F1 interface may also include, for example, an F1-C interface and an F1-U interface, which are respectively used to carry control plane data and user plane data. The UE may be connected to the carrier network via the ANN 120 over the air interface. The UE may be served by at least one cell. In Figure 1 the example of FIG. 2, UE1, UE2, and UE3 are served by cell 1 130 of DU1, while UE4 and UE5 are served by cell 2 132 in DU1. The UE may include mobile and fixed network devices. For example, the UE may include, but is not limited to, mobile phones, laptops, tablets, personal digital assistants, wearable devices, distributed remote sensor devices, vehicular communication devices, roadside communication devices, and desktop computers. Although Figure 1 and the various embodiments described below are provided in the context of a 5G cellular wireless network, the basic principles described herein are applicable to other types of radio access networks, including but not limited to Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

[0026] Figure 2 FIG. 200 shows an exemplary protocol stack implementation of the F1 interface between the CU 122 and the DU 124. The control planes of the CU and the DU are connected via the F1-C interface. The user planes of the CU and the DU are connected via the F1-U interface. The F1-U interface is based on the GTP-U protocol, which further relies on UDP / IP for IP-level data transmission.

[0027] In particular, the functions of the radio access network nodes may be split between the CU and the DU. The CU hosts the RRC (Radio Resource Control), SDAP (Service Data Adaptation Protocol), and PDCP (Packet Data Convergence Protocol) protocols. The DU hosts the RLC (Radio Link Control), MAC (Medium Access Control), and PHY (Physical) layers. The DU with the lower layers of the network may be responsible for autonomously allocating resources or allocating resources under the control of the CU. In some embodiments, the CU may be associated with and control multiple DUs.

[0028] In some embodiments, the CU is a gNB Central Unit (gNB-CU), and the DU is a gNB Distributed Unit (gNB-DU).

[0029] The signaling protocol between the CU and the DU is called the F1 Application Protocol (F1AP). The corresponding signaling can be classified into two categories: non-UE associated and UE associated. Such signaling can be implemented for various procedures to support the interaction between the CU and the DU. For example, the context establishment procedure can represent a UE-associated procedure for establishing a UE context (including the DRB configuration of the UE). For another example, the gNB-CU configuration update procedure and the gNB-DU configuration update procedure are non-UE associated procedures, which are used to update the application-level configuration data required for the CU and the DU to interoperate properly through the F1 interface. In particular, these F1AP procedures can be invoked in a flexible manner, either individually or in combination. Each of these procedures can be associated with at least one signaling message, which can trigger a response message or not.

[0030] In the user plane, the F1-U link can be implemented based on, for example, the GPRS Tunneling Protocol (GTP-U) over UDP, and can be used to carry user data in units of PDCP protocol data units (PDUs), as Figure 2 shown. The data can be sent from the CU to the DU (downlink) or from the DU to the CU (uplink). When the CU is connected to and controls multiple DUs, the downlink data communication from the CU to the multiple DUs can be based on, for example, the GTP-U protocol, and can be carried in an IP multicast or IP point-to-point tunnel. For a DU participating in the IP multicast from the CU, information for identifying the IP multicast tunnel can be provided from the CU to the DU via the F1-C interface, and the information for identifying the IP multicast tunnel includes, for example, the IP multicast address and the tunnel identifier (e.g., the tunnel endpoint identifier (TEID)). For the IP point-to-point communication from the CU to the DU, the destination IP address and the tunnel identifier can be provided by the DU to the CU again via the F1-C link so that the CU can send data to the DU. The data tunnel between the CU and the DU can be bidirectional. In other words, a single tunnel can support both downlink and uplink data transmission simultaneously.

[0031] Access network-level implementation of MBS in PTP and PTM modes

[0032] A radio communication network can be configured to provide multicast / broadcast services (MBS) to at least one UE. To establish an MBS session, the core network sends session management-related content to the access network, where the session management-related content includes the context of the MBS, such as

[0033] · Quality of Service (QoS) information corresponding to the QoS flow of the MBS session. For example, each QoS flow of the MBS session can be associated with different QoS parameters. Each data stream with corresponding QoS parameters can be referred to as a QoS flow.

[0034] · If the MBS session is a multicast session, it is a list of UEs associated with (or targeted by) the multicast session. For example, the UE list can include identifiers of a group of UEs associated with the access network that have applied for and been permitted to receive multicast services. Optionally, if needed, a multicast area list can be included. The multicast area list can be provided in the form of a multicast area index list or a cell list. Each multicast area index can be further mapped to a cell list.

[0035] · If the MBS session is a broadcast session, it is a list of broadcast areas. For example, the broadcast area list can be provided in the form of a broadcast area index list or a cell list. Each broadcast area index can be further mapped to a cell list. This mapping relationship can be implemented through the interaction between the core network and the radio access network, or it can be determined autonomously by the radio access network.

[0036] After receiving the MBS session context information from the core network, the access network further allocates various communication resources to implement the transmission or delivery of MBS session data from the access network to the UE, and receives various status reports from the UE when needed. This transmission of MBS session data can be performed at the QoS granularity of the radio bearer. Accordingly, various communication resources can be allocated for each radio bearer. In the present disclosure, the term multicast / broadcast radio bearer (MRB) is used to represent the radio bearer serving the MBS session. The MRB can alternatively be referred to as a radio bearer (RB). Each MRB is associated with its own QoS parameters.

[0037] Based on the MBS context information, the access network maps each QoS flow of the MBS with a certain set of QoS flow parameters to the corresponding MRB, whose QoS attributes can meet the QoS requirements of the corresponding QoS flow, and this mapping relationship is predefined or dynamically configured. In some embodiments, multiple QoSs can be mapped to one MRB. The access network can further determine the UE-specific delivery mode of various MRBs to each UE participating in the multicast / broadcast service session via the air interface. For example, such a delivery mode can include the PTP delivery mode or the PTM delivery mode.

[0038] In the PTP delivery mode, one or more QoS flows of an MBS session mapped to an MRB are transmitted from the access network to a specific UE using the communication resources allocated to the specific UE. The UE in the PTP delivery mode thus uses independent resource allocation for receiving MBS in unicast. In the PTM delivery mode, one or more data streams of an MBS session mapped to an MRB are transmitted from the access network to a group of UEs (referred to as a PTM UE group) using the communication resources allocated to and shared by the PTM UE group. In some embodiments, a group of UEs receiving MBS session data is divided into a subset of UEs (each UE receiving the MBS session in PTP mode), and a subset of UEs receiving the MBS session in PTM mode. The subset of UEs receiving the MBS session in PTM mode can be further divided into multiple PTM UE groups. Each PTM UE group can be allocated communication resources separate from other PTM groups.

[0039] In some embodiments, a specific UE can receive MBS session data in PTP mode and be dynamically switched to PTM mode, and vice versa. In some embodiments, a specific UE can receive MBS session data in both PTP mode and PTM mode simultaneously.

[0040] In some embodiments, the service data of an MBS session is referred to as MBS session data, while in other embodiments, alternatively, it is referred to as MBS session packet data unit (PDU).

[0041] PTP and PTM delivery instances

[0042] In the context of the above description, the communication resource allocation in the access network for an MBS session can be collectively referred to as various allocation instances, referred to as delivery instances. Each delivery instance corresponds to a set of communication resources for PTP transmission to a specific UE (referred to as a PTP delivery instance) or PTM transmission to a PTM UE group of UEs (referred to as a PTM delivery instance). Figure 3 is shown in Figure 1 Example PTP or PTM delivery instances in the access network of. In particular, five (5) different delivery instances are shown as 301, 303, 305, 307, and 309, represented by double-dashed lines 311, 313, 315, and 317, and further details are shown below.

[0043] This embodiment branches an MBS session into parallel delivery instances with corresponding communication resources allocated to support UEs with different reception quality requirements and reception channel conditions. MBS session data can be provided to some UEs with point-to-point or similar unicast quality characteristics.

[0044] The delivery mode for each UE can be determined by the access network based on UE information obtained from the radio communication network. As will be described in further detail below, this determination can be made by the CU or DU of the access network. The corresponding resource allocation for various PTP or PTM delivery instances can be performed by the DU and / or CU. Some resources, especially the user plane downlink data tunnel for sending or retransmitting MBS data streams from the CU to the DU, or the uplink data tunnel for sending UE reports from the DU to the CU, can be shared among different delivery instances in various ways in some cases, as will be described in more detail below.

[0045] In the context of the functional division between the CU and DU as shown in the exemplary access network in Figure 1 and Figure 2 the communication resource allocation for supporting various PTP and PTM delivery instances may include resources allocated in the various radio access protocol stacks of the CU and DU, as well as the F1-U resources between the CU and DU.

[0046] In summary, the delivery instance of an MBS session in the radio access network corresponds to a set of resources and associated configurations for delivering MBS session data. Such resources can include, for example, SDAP (Service Data Adaptation Protocol) entities, PDCP (Packet Data Convergence Protocol) entities, F1-U instances, radio link control (RLC) entities, and MAC / PHY resources.

[0047] In some exemplary embodiments, the above PTP or PTM delivery instances may be associated with one or more of the following features:

[0048] · An identifier (ID) for the delivery instance. For a certain MBS session, the delivery instance ID can be unique within the PLMN (Public Land Mobile Network), CU, DU, or cell. The delivery instance ID can uniquely identify the delivery instance and its associated features.

[0049] · A delivery mode including the PTP delivery mode or the PTM delivery mode. Similarly, a delivery instance using the PTP delivery mode can be referred to as a PTP delivery instance, while a delivery instance using the PTM delivery mode can be referred to as a PTM delivery instance. The identifier of a specific UE can be used to identify a PTP delivery instance. The instance identifier for a PTM delivery instance may be:

[0050] ο The cell identifier of the cell when the PTM delivery instance is the only PTM delivery instance in the cell of the MBS session;

[0051] ο The cell identifier of the cell and the PTM delivery instance index of the PTM delivery instance in the cell when the cell is associated with multiple PTM delivery instances of the MBS session; or

[0052] οPTM delivery instance ID, which uniquely identifies a PTM transmission instance for an MBS session within the DU or within the F1 interface. In some embodiments, and conversely, given the instance ID of a PTM delivery instance that is unique within a cell, the identity of the cell can be derived.

[0053] · Each delivery instance can be associated with one or more MRBs of an MBS session. For example, a delivery instance can be associated with all MRBs of an MBS session. For another example, a delivery instance can be associated with a subset of MRBs of an MBS session.

[0054] · For each MRB associated with a delivery instance, at least one first F1-U data tunnel is used to transmit MRB data (e.g., PDCP PDU or PDCP protocol data unit) between the CU and the DU. Such a first F1-U data tunnel can be shared by multiple delivery instances for the same MRB. In some implementations, all delivery instances associated with the same DU may share the same first F1-U data tunnel for a particular MRB. In some other implementations, an independent first F1-U data tunnel for a particular MRB can be assigned to each delivery instance. In still some other implementations, some delivery instances can use independent first F1-U data tunnels, while other delivery instances can share the first F1-U data tunnel for a particular MRB in one or more groups of delivery instances. For example, for a particular MRB, each PTP delivery instance can use an independent first F1-U data tunnel, while other PTM delivery instances can share the first F1-U data tunnel. In some implementations, in the resource allocation where independent first F1-U data tunnels will be provided, a higher priority can be given to PTP delivery instances than to PTM delivery instances..

[0055] · The MRB in a PTP or PTM delivery instance can be associated with a second F1-U data tunnel for transmitting the PDCP PDU of the MRB from the CU to the DU for UE-specific retransmission of the MRB data to a specific UE (the target UE of the PTP delivery instance, or a specific UE in the PTM UE group of the PTM delivery instance). Similarly, a particular MRB can be associated with multiple second F1-U tunnels, each for one UE in the PTM UE group, for UE-specific PDCP PDU retransmission of the particular MRB.

[0056] · When such a shared data tunnel is dedicated to a particular PTP delivery instance and is not further shared with other delivery instances, the above-mentioned first F1-U data tunnel for data transmission and the above-mentioned second F1-U data tunnel for retransmission of a particular MRB in a particular PTP delivery instance can be shared.

[0057] · The second F1-U data tunnel for retransmission of a specific MRB in the PTP delivery instance or the PTM delivery instance can be further used as a bidirectional data tunnel (for downlink and uplink data transmission between the CU and the DU) or a unidirectional data tunnel (only from the CU to the DU). For a specific UE and a specific MRB associated with such a data tunnel, such a bidirectional data tunnel can also be used to transmit UE reports from the DU to the CU. Such UE reports can be PDCP status reports for a specific MRB.

[0058] · For each MRB associated with a delivery instance, at least one RLC entity is allocated for transmitting MRB data to the UE via the MAC / PHY resources associated with the RLC entity. For the PTP delivery instance, such an RLC corresponds to the transmission of MRB data to a specific UE. For the PTM delivery instance, such an RLC entity is common to all UEs in the PTM UE group. For the PTM delivery instance, the corresponding RLC PDUs serve all UEs in the PTM UE group.

[0059] · When retransmission is required, the RLC entity associated with a specific MRB in the PTP delivery instance may further be responsible for retransmitting the MRB data to the specific UE via the PTP delivery instance. In other words, in the PTP delivery instance, retransmission of an MRB may not require a replicated RLC entity. Alternatively, in the PTP delivery instance, a separate RLC entity may also be allocated for the MRB for retransmitting the MRB to a specific UE.

[0060] · For a specific MRB in the PTM delivery instance, a separate UE-specific RLC entity may be allocated for a specific UE in the PTM UE group for UE-specific retransmission of MRB data to the specific UE and for the uplink of UE-specific PDCP status reports associated with the MRB.

[0061] · Different delivery instances may share certain transmission resources and configurations. For example, as described above, for the MRB of an MBS session, the F1-U resources of the MRB can be shared in the same CU / DU interface between different delivery instances.

[0062] · Each PTP or PTM delivery instance corresponds to a set of MAC / PHY configurations. According to the set of configurations, a UE or multiple UEs can complete the reception of the MBS delivery instance according to the time domain and frequency domain corresponding to the set of MAC / PHY configurations.

[0063] The set of MAC / PHY configurations may further include:

[0064] · DRX information corresponding to this PTM delivery instance

[0065] · Radio Network Temporary Identifier (RNTI) of the PTM delivery instance

[0066] · Time domain scheduling information corresponding to the PTM delivery instance for indicating the subframe or time slot for scheduling PTM transmission

[0067] · Frequency domain resource allocation information corresponding to the PTM delivery instance.

[0068] · Physical Downlink Control Channel (PDCCH) configuration and Physical Downlink Shared Channel (PDSCH) configuration corresponding to this PTM delivery instance.

[0069] · Bandwidth Part (BWP) information corresponding to the PTM delivery instance.

[0070] For a UE participating in receiving an MBS session, the UE uses the resource allocation of at least one delivery instance (PTP delivery instance or PTM delivery instance) to receive MBS session data. In some embodiments, the UE may be allowed to use both the PTP delivery instance and the PTM instance simultaneously to receive the MRB of a certain MBS session. In some exemplary embodiments, the UE may receive all or part of the MRB data of the MBS session in the PTP delivery instance, and may also receive all the MRB data in a separate PTM delivery instance, which also delivers the MRB data to other UEs in the PTM manner. In this way, the UE can receive at least one MRB from the PTP delivery instance and the PTM delivery instance using corresponding different resource sets. In certain cases, this redundancy reduces the packet loss and failed delivery of the MRB to the UE.

[0071] User plane resource architecture for delivery instances in MBS sessions

[0072] To achieve the delivery mode switch for a UE from one mode to another mode, and different delivery modes for a group of UEs associated with the same MBS session, as Figures 11 - 12 shown, five (5) options of the user plane architecture are given. At least two scenarios are considered for the UE mode switch:

[0073] · For a specific UE, the delivery mode switches from one mode to another mode. For example, UE1 may encounter poor connection when receiving MBS session data in the PTM mode. Therefore, UE1 can then be reconfigured to receive MBS session data in the PTP mode to improve the reception quality. Or vice versa, the UE can also be reconfigured to switch from the PTP mode to the PTM mode, for example, to achieve better spectral efficiency.

[0074] · For different UEs, different delivery modes may coexist. For example, a group of UEs interested in an MBS session may be associated with the same CU or DU. The connection states may be different, or the UEs may belong to different DUs or physical cells, so there can be more than one delivery instance for different UEs. For example, PTP delivery for UE1 in one cell, and PTM delivery for UE2 and UE3 in another cell. Delivery instances of the same MBS session can coexist in the same cell.

[0075] In other words, as Figures 11 - 13 shown, as part of the corresponding delivery instances, RLC entities 1 and 2 can be associated with the same UE, or with different UEs in different scenarios. In Figures 11 - 13 , RLC entities 1 and 2 (including the corresponding delivery instances) can serve the same UE or different UEs at different times. The architecture options for delivery instances can be applied to both scenarios.

[0076] To be able to deliver QoS flows associated with an MBS session to a UE in different delivery modes (i.e., PTP, PTM, or both PTP and PTM), there are several different options for the same UE or different UEs, as Figures 11 - 12 shown. From the perspective of the user plane (UP) architecture, for delivery instances, the protocol stack includes SDAP, PDCP, RLC, MAC, and PHY protocols or layers. For the above scenarios, different user plane architecture options use different protocol layers as the anchor layer for mode switching or delivery mode coexistence, and in all options, different RLC entities are used for different delivery modes, whether for the same UE simultaneously or for different UEs. The protocol layers at and above the anchor layer are shared by the delivery instances. The following description focuses on mode switching of a specific UE from one delivery mode to another. The basic principle also applies to the case where different UEs are in different reception modes, or where UEs in different subgroups are in PTM mode. UEs in different subgroups either receive MBS session data in different cells or receive MBS session data in the same cell but with different delivery configurations (e.g., different physical layer configurations).

[0077] · Option 0 ( Figure 11 ). For a specific MRB, two different delivery instances share the same SDAP, PDCP entities, F1-U instance, and RLC entity. The anchor layer is RLC. The protocol layers at and above RLC ( Figure 11All layers shown (except the physical layer) are shared by the delivery instances. The QoS flow or data flow from the core network is submitted to the shared SDAP entity 1; part or all of the QoS flows are mapped to the MRB (other possible MRBs are not depicted); in the case of CU / DU separation, the corresponding PDCP PDUs are submitted to the F1-U tunnel 1; the PDCP PDUs are submitted to the shared RLC entity serving different UEs. In some embodiments, two delivery instances also share the MAC entity, and the same MAC PDUs are separately scheduled in two different physical resource sets.

[0078] · Option 1 ( Figure 12 ). For a specific MRB, two different delivery instances share the same SDAP and PDCP entities, as well as the same F1 tunnel instance, but different RLC entities. The anchor layer is F1-U on the DU side. The protocol stack layers above F1-U are shared by the delivery instances. The QoS flow or data flow from the core network is submitted to the shared SDAP entity 1; part or all of the QoS flows are mapped to the MRB (other possible MRBs are not depicted); in the case of CU / DU separation, the corresponding PDCP PDUs are submitted to the F1-U tunnel 1; the PDCP PDUs are submitted to different RLC entities serving different UEs, or are replicated and submitted to more than one RLC entity for the UE to prevent the UE from receiving MBS session data in both modes simultaneously.

[0079] · Option 2 ( Figure 12 ). For a specific MRB, two different delivery instances share the same SDAP and PDCP entities, but different F1 tunnel i and RLC entities. Therefore, the anchor layer is the PDCP layer. The protocol stack layers above the PDCP layer are shared by the delivery instances. The QoS flow or data flow from the core network is submitted to the shared SDAP entity 1; part or all of the QoS flows are mapped to the MRB (other possible MRBs are not depicted); in the case of CU / DU separation, the corresponding PDCP PDUs are submitted to different F1-U instances (e.g., tunnel 1 and tunnel 2); the PDCP PDUs are separately submitted to different RLC entities.

[0080] · Option 3 ( Figure 13)。Two different delivery instances share the same SDAP entity, but different PDCP entities, F1 tunnel instances, and RLC entities. The anchor layer is the SDAP layer. The protocol stack layers above the SDAP layer are shared by the delivery instances. The QoS flow or data stream from the core network is submitted to the shared SDAP entity 1; the QoS flow is mapped to a set of MRBs, and the same QoS flow is mapped to another set of MRBs with the same or different mapping rules. Then, the MRB data is processed by different PDCP entities through separate sorting operations. Therefore, the PDCP PDUs from the above different PDCP entities are sent to the DU in different F1 tunnels and are submitted to different RLC entities.

[0081] · Option 4( Figure 13 )。Two different delivery instances share separate SDAP entities, PDCP entities, F1 tunnel instances, and RLC entities. The anchor layer is N3-U (above the SDAP). In this case, the delivery instances are independent of each other. The same set of QoS flows of an MBS session is processed by two different sets of Uu protocol layers (including different SDAP entities, PDCP entities, F1-U tunnels, and RLC entities).

[0082] In the next section of this disclosure, more details of Option 1 and Option 2 are given.

[0083] User plane resource configuration and MBS data flow in delivery instances in MBS session part 2

[0084] Figure 3 An exemplary data resource configuration and data path in the access network are shown, and the access network includes a CU and a DU for transmitting an MBS session. Although an MBS session can be delivered by multiple DUs under the control of the CU, only one DU is considered in the following disclosure. The basic principle applies to other DUs. As an example, assume a specific DU-UE configuration, such as Figure 4 shown. In particular, the DU is associated with multiple cells (including Figure 4 Cell 1, Cell 2, and Cell 3). For this DU, there are multiple UEs distributed in the serving cells of the DU, and these UEs receive the MBS using PTP or PTM delivery modes associated with resource allocations of various PTP or PTM delivery instances, as listed below:

[0085] · Cell 1-UE1, PTP delivery instance 1;

[0086] · Cell 1-UE2 and UE3, PTM delivery instance 1;

[0087] · Cell 2–UE4 and UE5, PTM delivery instance 2;

[0088] · Cell 3–UE6, UE7, and UE8, PTM delivery instance 3;

[0089] ·Cell 3 – UE9 and UE10, PTM Delivery Instance 4.

[0090] This DU-UE configuration is further shown as 380 in Figure 3 . In Figure 3 , the resource allocation in the CU-DU system for five (5) delivery instances is represented by the double-dashed lines 311, 313, 315, and 317, and the corresponding delivery instances are shown by 301 (PTP1), 303 (PTM1), 305 (PTM2), 304 (PTM3), and 309 (PTM4). Figure 3 The resource allocation and data path from the upper layer to the lower layer of the network protocol stack in the CU-DU system to the UE include: CU 310, the F1-U data tunnel 320 between the CU and the DU, DU 330, and UE 380. Those of ordinary skill in the art understand that Figure 3 only some resource allocations and data paths related to the description of the various embodiments of the present disclosure are included.

[0091] The CU 310 allocates MRBs for the various QoS flows of the MBS session. As an example, for this particular MBS session, it is assumed that the QoS flows of the MBS session are mapped to 4 MRBs, which are labeled as RB1, RB2, RB3, and RB4 (corresponding to four sets of PDCP PDUs) in the PDCP layer of the CU 310.

[0092] These PDCP PDUs associated with RB1 - RB4 are transmitted to the DU via the F1-U interface using the data tunnel 320. As described above, multiple shared or non-shared data tunnels can be included in the F1-U data tunnel 320. These data tunnels can be downlink, uplink, or bidirectional. More detailed information regarding the F1-U data tunnel configuration and sharing is provided when describing the specific embodiments below.

[0093] The DU 330 receives data from the F1-U data tunnel and then submits the data to the RLC entity (RLC SDU 332). Each RLC SDU of 332 corresponds to one MRB and is associated with one of the PTP or PTM delivery instances 301, 303, 305, 307, and 309. Then, the RLC SDU is submitted to the RLC entity 350. Each RLC entity corresponds to one MRB and is associated with one of the PTP or PTM delivery instances 301, 303, 305, 307, and 309.

[0094] Each delivery instance may be responsible for delivering data of one or more MRBs (all MRBs or a subset of MRBs) to one UE (for a PTP delivery instance) or multiple UEs (for a PTM delivery instance). Each MRB transmitted by a specific delivery instance is associated with an RLC entity. For example, as Figure 3 shown in 352, the PTP delivery instance 301 (PTP 1) is responsible for delivering all four MRBs to UE 1 in cell 1 and is then assigned four RLC entities corresponding to these four MRBs. As another example, UE2 and UE3 served by at least cell 1 sharing the delivery instance of PTM 1 may also need to use the four RLC entities assigned to the delivery instance of PTM 1 to receive all four MRBs, as shown in 354. UE4 and UE5 served by at least cell 2 sharing the delivery instance of PTM 2 may only be able to receive two RBs: RB 1 and RB 2. For example, RBs 3 and 4 cannot be established for the delivery instance of PTM 2. Therefore, the delivery instance of PTM2 is only assigned two corresponding RLC entities, as shown in 356. Similarly, UE6, UE7, and UE8 served by cell 3 sharing the delivery instance of PTM3 may only need to receive data of 2 RBs (RB2 and RB3). Therefore, the delivery instance of PTM 3 is assigned two corresponding RLC entities, as shown in 358. Finally, UE9 and UE10 served by at least cell 3 sharing the delivery instance of PTM4 may only need to receive data of three RBs (RB1, RB2, and RB3). Therefore, the delivery instance of PTP4 can be assigned three corresponding RLC entities, as shown in 359.

[0095] When configured, for retransmission of a specific MRB of a specific UE in a PTM instance, additional RLC entities may be assigned in the PTM instance for the specific UE and the specific MRB, because the original RLC entity assigned for the transmission of the specific MRB is shared with at least one other UE in the PTM UE group. For example, as Figure 3 shown, the PTM delivery instance PTM 2 may require resource allocation for retransmission of both RB1 and RB2 for UE5. Therefore, additional RLC entities 357 may need to be assigned for this UE-specific retransmission of RB1 and RB2, because the original RLC entity 356 is shared by other UEs.

[0096] For retransmission of a specific MRB for a UE in a PTP delivery instance, the original RLC entity may be used and additional RLC entities may not need to be assigned for such retransmission, because the original RLC entity in such a PTP delivery instance is not shared with other UEs. However, in some alternative embodiments, additional RLC entities may still be assigned for such retransmission. For example, as Figure 3As shown, the PTP delivery instance PTP 1 may be required for retransmission of RB1, RB2, and RB3 for UE1. Since the original RLC entity 352 is not shared with other UEs (i.e., the RLC resources of the PTP instance are not shared with other instances), they can be used for retransmission without allocating any additional RLC entities. Alternatively, an additional RLC entity 353 can still be allocated for such PTP retransmission to UE 1.

[0097] For PTP or PTM delivery instances, the RLC SDUs corresponding to the retransmitted PDCP PDUs, as shown by 336 for the PTP 1 delivery instance and 337 for the PTM 2 delivery instance in Figure 3 are used for retransmission. For the PTP1 delivery instance, without allocating an additional RLC entity (such as 353), the additional retransmission RLC SDU 336 will be submitted to the original RLC entity, as shown by the dashed routing line 339.

[0098] As Figure 3 further shown by 370 in

[0099] each delivery instance 301, 303, 305, 307, and 309 is also associated with a corresponding MAC entity and physical layer function set for transmitting MBS data to the UE via the air interface. Figure 3 The above example resource configuration can be allocated by the CU and DU, as controlled by the signaling information and corresponding responses transmitted between the CU and DU via the F1-C interface.

[0100] This only represents an exemplary snapshot of such resource allocation and configuration. Such resource allocation and configuration can be dynamically established, modified, and released at any time under the control of such signaling interactions. For example, a specific UE can switch between the PTM and PTP delivery modes. The resource allocation and configuration can be dynamically modified to reflect such a switch. Such a switch and resource reallocation can be done at the access network level without the involvement of the application layer, and thus can be achieved with minimal latency and service interruption.

[0101] Signaling procedures between CU, DU, and UE for resource allocation, modification, release, and UE delivery mode switching

[0102] Figure 5 Shows an exemplary signaling message flow and process among the CU, DU, and UE for implementing MBS session context management, resource allocation / modification / release in the CU and DU to support the transmission of the MBS session to the UE, and delivery mode switching of the UE between the PTM delivery mode and the PTP delivery mode for the above various delivery instances.

[0103] In some embodiments, as described above, the CU receives MBS session context information from the core network. Then, the CU performs initial resource allocation, such as mapping QoS flows in the MBS session to MRBs. As shown in step 0 of Figure 5 , the CU further makes delivery mode-related decisions for each UE targeted by the MBS session based on the MBS session context information and information of the target UE (as will be described later, such decisions can alternatively be made by the DU instead of the CU). For example, the CU can determine the delivery mode for each target UE. In some embodiments, a subset of the target UEs can be assigned to the PTP delivery mode, while another subset of the target UEs can be assigned to the PTM delivery mode. In some other embodiments, all target UEs can be assigned to the PTP delivery mode. In some other embodiments, all UEs can be assigned to the PTM mode. Some target UEs can be assigned to both the PTP delivery mode and the PTM delivery mode simultaneously. In some other embodiments, such delivery mode decisions can be made by the CU or DU based on the MRB granularity within each UE, rather than for each UE as a whole. Thus, step 1 achieves synchronization of the MBS context between the CU and the DU.

[0104] In step 1, as shown in Figure 5 , the CU initiates an MBS context establishment message to the DU for sending the MBS context information to the DU. This message may also carry other information to enable the DU to perform resource allocation and configuration autonomously or jointly with the CU for various delivery instances. For example, the CU can transmit the initial delivery mode decision for at least one UE or the serving cell of the DU using this message. Thus, the information carried in the signaling message of step 1 can include, for example:

[0105] · QoS information, such as the QoS parameters of each MRB allocated by the CU for the MBS session, and the QoS parameters and identifiers of the QoS flows mapped to each MRB.

[0106] · The delivery mode of the UE or serving cell or delivery instance for receiving MBS data, which can be the PTP delivery mode or the PTM delivery mode.

[0107] · When using IP multicast, F1-U related information for transmitting the PDCP PDUs of the MRB from the CU to the DU. Such information may include, for example, the IP multicast address with or without a source address and the GTP-TEID of the tunnel.

[0108] In step 2, the DU performs various resource allocations and configurations based on the information received from the CU in step 1 and sends a response message back to the CU. The response message may contain configuration information of the lower-layer resources successfully allocated for the accepted MRBs for various delivery instances. The message may also include a list of MRBs for which the MRBs have not been created, along with the corresponding failure reasons.

[0109] In step 3, the CU receives the lower-layer configuration from the response message from the DU in step 2, generates an MBS radio resource configuration for the UE, and sends such an MBS radio resource configuration to the UE. Additionally, in step 3 or a separate step, the CU may generate an MBS reception status report / feedback configuration for the UE and send the report / feedback configuration to the UE. The message in step 3 may be sent via broadcast or dedicated signaling. In this way, the CU can dynamically configure how the UE should provide feedback on MBS session reception, including but not limited to the form, content, timing, and triggering conditions of the feedback.

[0110] In step 4, the UE configures its protocol stack according to the MBS radio resource configuration from the CU to receive MBS session data. The UE further monitors various reception and channel parameters and provides a status report or feedback to the CU based on the form, content, timing, and triggering conditions specified in the status report / feedback configuration received from the CU in step 3. For example, the status report or feedback may be sent periodically, triggered by predefined events, or both.

[0111] In some alternative or additional embodiments of step 4, the feedback from the UE may be first sent to the DU, as shown in step 4a / 1, and then, as shown in step 4a / 2, the DU generates a notification message based on the report or feedback provided by the UE to the DU in step 4a / 1 and sends the notification message to the CU.

[0112] In step 5, the CU modifies the MBS context information based on the status report, feedback, or notification from the DU or the UE, and sends the modified MBS context information and other relevant information to the DU using an MBS context modification or release message to achieve modification or release of the resource allocation for various delivery instances and / or to achieve a delivery mode switch for one or more UEs.

[0113] In step 6, the DU sends back an MBS context modification or release response. The message may contain the updated MRB configuration of the MRBs successfully modified, the list of MRBs for which the modification has failed, as well as other information and other relevant configuration information for various delivery instances. Subsequently, similar to step 3, the CU may also send any modified radio resource allocation information to the UE.

[0114] The above context release can be implemented in the following ways:

[0115] · The DU can initiate an MBS context release request (initiated by the DU)

[0116] · The CU can initiate an MBS context release request (initiated by the CU)

[0117] Other messages not included in Figure 5 the message flow can also be used to transfer various other information between the CU and the DU to assist in allocating and configuring resources for various delivery instances. These messages can include, but are not limited to, notification messages such as:

[0118] · A notification message notifying that the QoS requested by a certain UE may not be satisfied.

[0119] · A notification message from the UE to the DU notifying the DU that the UE cannot meet a certain condition and triggering the DU to further notify the CU. For example, this notification can be included in the information sent in step 4a / 2 above.

[0120] Figure 5 The example process shown not only provides a mechanism for initial resource allocation and configuration of delivery instances in the CU and the DU through CU-DU interaction, but also provides a UE feedback mechanism for implementing delivery mode switching for one or more UEs. Specifically, Figure 5 it provides a mechanism for the UE to dynamically provide a reception status report or feedback to the CU, enabling the CU or the DU to initiate a mode switching decision and perform corresponding modifications to the delivery instance and the corresponding resource allocation to switch to a better delivery mode for transmitting the MBS session to the UE. This switching and modification can be achieved dynamically and based on real-time UE feedback.

[0121] In addition, since MBS context management and mode switching decisions are initiated and completed at the access network level, the latency introduced by the delivery mode switching between the UE's PTP and PTM is minimized compared to mode switching initiated at the application layer that requires more involvement of higher layers and more network elements.

[0122] Signaling information exchange between CU and DU

[0123] Although each of the above messages is shown as being implemented as a signaling message in the various steps of the Figure 5 signaling process, the information contained in these steps can be transmitted via multiple signaling messages. The order of these steps can be arranged in a flexible manner to achieve the interactive communication of the MBS context and other information, which is required for the establishment, modification, and release of resource allocation and configuration for various delivery instances by the CU and the DU. These steps can be repeated in full or in part as needed.

[0124] Each of these messages may include one or more information items exchanged between the CU, DU, and UE to achieve resource allocation and configuration for delivering instances of an MBS session to the UE. These information items may be transmitted for various purposes in resource allocation and configuration and are used to trigger various actions and responses from the CU or DU. The present disclosure below describes in more detail these information items and the corresponding actions and responses of the DU and / or CU for achieving dynamic reconfigurable resource allocation for different delivery instances as shown in the exemplary configuration snapshot of Figure 3 as follows.

[0125] After the CU receives the MBS context from the core network, various information items may be exchanged from the CU to the DU, map the QoS flows of the MBS session to the MRBs, and determine the delivery mode of the UEs participating in the MBS session (as will be described later, this decision may alternatively be made by the DU instead of the CU). The message sent from the CU to the DU may include any one of the following data items:

[0126] · Operation indication (e.g., establishment operation, modification operation, release operation).

[0127] · MBS session identifier (more details are provided below).

[0128] · MRB information corresponding to the MBS session, e.g., including the RB ID of the MRB. The RB ID corresponds to an identifier that can be used to uniquely identify the MRB between the CU and the DU. Each RB ID may be represented by an index from the RB ID index space. The MRB may also be associated with a second RB ID for a specific UE to provide a mapping between the unique RB ID for the MRB and the RBID of the same MRB used by the UE in cases where the UE shares the RB ID index space with other MBS sessions or PDU sessions associated with the UE. The second RB ID will be used for the served radio bearers in the RLC bearer configuration corresponding to the MRB returned by the DU to the CU.

[0129] · QoS parameters corresponding to the MRB.

[0130] · Configuration file of the QoS parameters or QoS flows mapped to the MRB.

[0131] · MBS capabilities of the UE.

[0132] · Required UE capabilities related to the MBS session.

[0133] · F1-U tunnel information corresponding to the MRB in one or more delivery instances. In some specific scenarios, an IP multicast address with or without a source address and TEID may be included so that the DU can join the IP multicast to obtain the PDCP PDUs of the MRB. Such an IP multicast data tunnel can be shared among one or more delivery instances or can be dedicated to a specific delivery instance of a specific MRB.

[0134] · When the PDCP PDUs for the MRB are sent from the CU to the DU in an IP point-to-point transmission manner and no F1-U tunnel information for the MRB from the CU is included, the DU may respond with IP point-to-point transmission information including an IP address and TEID as the destination information for the downlink F1-U tunnel for the MRB. The F1-U tunnel can be shared among one or more delivery instances or can be dedicated to a specific delivery instance of a specific MRB instance.

[0135] · Uplink tunnel information for transmitting the PDCP layer status report of a specific MRB of a specific UE from the DU to the CU.

[0136] · PDCP retransmission enabling indication for a specific UE (optionally configured per MRB or per MBS session). The DU establishes an RLC bearer for retransmission and returns the configuration information to the CU.

[0137] · List of failed MRBs for a delivery instance and the DU response failure reason.

[0138] · Configuration information corresponding to the delivery instance, which includes MAC / PHY configuration in the DU response.

[0139] · RLC mode of the PTP delivery instance, which can be acknowledged mode (AM), unacknowledged mode (UM) in both directions, unidirectional UM uplink, or unidirectional UM downlink.

[0140] · After the DU establishes the RLC entity for the MRB of the delivery instance, the RLC bearer configuration in the form of RLC configuration and logical channel ID (LCID) as a response from the DU. For the MRB in the PTM delivery instance, the RLC bearer can be associated with a UE-specific second LCID, which can be returned from the DU to the CU in the response message, depending on whether the specific UE shares the LCID space with other MBS sessions or PDU sessions associated with the UE.

[0141] · Delivery mode indicator for the UE (based on MBS session or based on MRB).

[0142] · UE ID or list of UE IDs of the UE with PTP or PTM indication.

[0143] · A UE ID or list of UE IDs with an indication from the DU of PTP or PTM mode in the response.

[0144] · A cell ID or list of cell IDs, optionally with a list of UE IDs.

[0145] · A cell ID and a delivery instance ID, optionally with a list of UE IDs.

[0146] · A list of UE IDs with cell ID information.

[0147] The above MBS session identifiers can be used to identify an MBS session and can be provided in at least one of the following forms:

[0148] · Session ID: The MBS session ID in the session management process for a certain UE, which uniquely specifies the MBS session among multiple sessions including the PDU session for that UE, and this session ID can be included in the SDAP configuration.

[0149] · TMGI (Temporary Mobile Group Identity).

[0150] · An IP multicast address with a source address.

[0151] · An IP multicast address without a source address.

[0152] · An interface MBS ID that uniquely identifies the MBS session within the CU-DU interface, such as:

[0153] ο gNB-CU MBS F1AP ID: The gNB-CU MBS F1AP ID uniquely identifies the MBS association through the F1 interface within the gNB-CU.

[0154] ο gNB-DU MBS F1AP ID: The gNB-DU MBS F1AP ID uniquely identifies the MBS association through the F1 interface within the gNB-DU.

[0155] · An identifier or index that can uniquely identify the MBS session within the CU, DU, or F1 interface.

[0156] The above UE ID (alone or in a list of UE IDs) can be used to identify a UE and can be provided in at least one of the following forms:

[0157] · gNB-CU UE F1AP ID,

[0158] · gNB-DU UE F1AP ID,

[0159] · C-RNTI,

[0160] ·RAN UE ID,

[0161] ·An identifier or index that can uniquely identify a UE within the CU or DU or F1 interface.

[0162] CU - DU interaction

[0163] This section describes various exemplary interactions between the CU and the DU. Generally, information items included in signaling messages sent from the CU to the DU can trigger configuration actions in the DU and / or trigger responses from the DU. Some configuration decisions can be made by the CU. Some configuration decisions can be made by the DU. Some configuration decisions can be made by the CU or the DU, or jointly by the CU and the DU.

[0164] In some embodiments, the determination of the delivery mode for each UE in a UE group for an MBS session can be determined by the CU, as described above with respect to Figure 5 described.

[0165] However, in some other alternative embodiments, such a decision may depend on the DU. For example, the CU can provide a list of UE IDs via a signaling message from the CU to the DU. Then, the DU can use information such as the UE connection state and other information at the DU (such as resource utilization or UE capabilities / MBS session requirements regarding UE capabilities) to determine the delivery mode for each UE and return such a decision to the CU via a response signaling message. In other words, Figure 5 the steps in the signaling procedure of can be performed by the DU between step 1 and step 2, and the step labeled "Determine Delivery Mode" between step 4a / 2 and step 5 can be performed by the DU between step 4a / 2 and step 5. For UEs associated with the PTP mode, the DU can allocate resources for the accepted MRBs of the PTP delivery instances corresponding to the PTP UEs and return its configuration information. The DU determines the serving cell of the PTM delivery instance for UEs associated with the PTM delivery mode. The DU further determines multiple PTM delivery instances in the serving cell determined for the PTM UEs, performs resource allocation for these PTM delivery instances, and returns a resource configuration including cell information and PTM delivery instance information (such as PTM delivery instance index or ID). The DU can also return a list of UEIDs of the UEs in each PTM delivery instance. In some embodiments, for one MBS session, only one PTM instance is allocated to a specific cell. In this case, the PTM delivery instance ID can be the cell ID.

[0166] In some other embodiments, assuming that the delivery mode of each UE is determined by the CU, the following alternatives (but not limited to) may be used by the CU, the DU, or the CU and the DU jointly to determine the delivery instance distribution in the serving cell of the DU for the MBS session:

[0167] · In one embodiment, the CU can determine everything, including the number of PTP delivery instances (the number of UEs in the PTP delivery mode) and the number of PTM delivery instances, and how many PTP delivery instances and how many PTM delivery instances are in each serving cell of the DU. In this embodiment, the CU can send the UE list of the PTP delivery instances and the information about the PTM instances in each cell to the DU via various signaling messages. In response, the DU can allocate corresponding resources for the accepted MRBs and return the above various configurations to the CU. Optionally, the information sent by the CU can include the entire UE list.

[0168] · In another embodiment, the CU may only send the UE ID or a list of UE IDs and the delivery mode indication of these UEs. In response, the DU can allocate resources for the accepted MRBs of the PTP delivery instances corresponding to the PTP UEs and return its configuration information. The DU determines the serving cell of the PTM delivery instance for the UE associated with the PTM delivery mode. The DU further determines a plurality of PTM delivery instances in the serving cell determined for the PTM UE, performs resource allocation for these PTM delivery instances, and returns a resource configuration including cell information and PTM delivery instance information (such as PTM delivery instance index or ID). The DU can also return the list of UE IDs of the UEs in each PTM delivery instance. In some embodiments, for one MBS session, only one PTM instance is allocated to a specific cell. In this case, the PTM delivery instance ID can be the cell ID.

[0169] · In another embodiment, for the PTM delivery mode, the CU can send information to specify the PTM serving cell. In response, the DU can determine a plurality of PTM delivery instances in the serving cell, perform resource allocation for these PTM delivery instances, and return a resource configuration of the PTM delivery instance information (including the PTM delivery instance ID). If the CU includes the UE ID list in its message to the DU, the DU also returns the list of UE IDs of the UEs associated with the PTM delivery instance. In some embodiments, for one MBS session, only one PTM instance is allocated to a specific cell. In this case, the PTM delivery instance ID may be the cell ID.

[0170] · In another embodiment, for the PTM delivery mode, the CU may send information to specify the PTM serving cell and the PTM delivery instances therein. In response, the DU may perform resource allocation for these PTM delivery instances and return the resource configuration of the PTM delivery instance information (including the PTM delivery instance ID). Optionally, for each PTM delivery instance, the CU may also include a list of UE IDs in its message to the DU.

[0171] In the above embodiment, the configuration information returned by the DU may include at least one (but not limited to) the RLC bearer information of the accepted MRB for each delivery instance, the MAC / physical information for each delivery instance, the tunnel information for the CU to send PDCP PDUs to the DU, etc. The RLC bearer configuration information of the MRB may include a unique RLC LCID and a first unique RB ID (unique between the CU and the DU for the MBS session). This unique LCID is common to the UE group of the PTM delivery instance and is included in the sub-header of the MAC PDU generated from the corresponding logical channel. In addition, for a specific UE, the RLC bearer configuration information may include a second LCID of the RLC bearer in case the specific UE shares the LCID space with other MBS sessions or PDU sessions associated with the UE. In addition, for a specific UE, the RLC configuration information may include a second RB ID provided by the CU, and the specific UE shares the radio bearer space with other MBS sessions or PDU sessions associated with the UE.

[0172] In some embodiments, the information items in the signaling message sent from the CU to the DU may include a retransmission enabling indicator for a specific UE based on the delivery instance or based on the MRB, that is, enabling retransmission for the delivery instance of the MBS session or only for the specified MRB list. In response, the DU may allocate resources for retransmission. For example, if a specific UE belongs to a PTM delivery instance, the DU may allocate an additional RLC bearer for the specific UE and the corresponding MRB. The DU may also establish a downlink tunnel between the CU and the DU for each such MRB and the specific UE. The DU may also return the configuration of the additional RLC bearer (e.g., additional LCID) and the downlink retransmission tunnel information (e.g., IP address and TEID) to the CU in one or more response messages.

[0173] In some embodiments, the information items in the signaling message sent from the CU to the DU may include UE-specific uplink tunnel information (e.g., based on each MRB). In response, when needed, the DU sends a UE status report to the CU based on this uplink tunnel information.

[0174] Other information exchanges, actions, and responses between the CU and DU that are not included in this chapter are described explicitly or implicitly in other chapters and detailed embodiments of this disclosure.

[0175] In some embodiments, the information items in the signaling messages sent from the CU to the DU or from the DU to the CU further include: releasing the resources in the resource allocation of all RBs or RB lists associated with a delivery instance that are not shared by other delivery instances. For example, for a PTP delivery instance, the relevant RLC bearer configuration for a specific RB of the UE and the possible F1-U resources for retransmission are released, while the F1-U tunnels for the RBs shared in other delivery instances are not released. For a PTM delivery instance, the relevant RLC bearer configuration for a specific RB of a specific UE and the possible F1-U resources for retransmission are released, while the F1-U tunnels for the RBs shared in other delivery instances are not released. If the entire delivery instance is released instead of just a subset of the associated MRBs being released, the relevant MAC / PHY resources for the PTM delivery instance are also released. In some embodiments, such a release indication is indicated by releasing the resources in the resource allocation of all RBs or RB lists associated with the UE that are not shared by other delivery instances, so the UE-specific resources for the RBs associated with the MBS session in the DU and the F1-U tunnels are released. In some embodiments, such a release is triggered by UE-associated signaling, which includes UE context release request (initiated by DU) and UE context release request (initiated by DU). In some embodiments, such a release indication is indicated by releasing the resources in the resource allocation of all RBs or RB lists associated with a cell or cell list that are not shared by other cells. Therefore, the resources allocated for PTM delivery in the cell including the associated RLC bearer and the F1-U tunnel associated with the MRB are released. If all MRBs are released instead of just a subset of the associated MRBs being released, the relevant MAC / PHY resources for the PTM delivery instance in the cell are also released.

[0176] Signaling message architecture

[0177] The various information items transmitted between the CU, DU, and UE as described above can be organized and grouped into one or more signaling messages according to some predefined message passing formats and one or more predefined message categories. For example, the request and response messages between the CU and DU via the F1 interface may include, but are not limited to, the following categories:

[0178] · Context establishment request (CU to DU): Used to trigger the DU to establish an MBS session context and allocate resources

[0179] · Context establishment request response (DU to CU): Used for the DU to respond with accepted MRB information and rejected MRB information of one or more delivery instances, RLC bearer configuration (e.g., RLC configuration, LCID), MAC / PHY configuration information, delivery instance information, downlink PDCP PDU tunneling information, etc.

[0180] · Context modification request (CU to DU): Used to trigger the DU to modify the MBS session context and resource allocation

[0181] · Context modification request response (DU to CU): Used for the DU to respond with information similar to the context establishment request response.

[0182] · Context modification request (DU to CU): Used to enable the DU to initiate context modification.

[0183] · Context modification confirmation (CU to DU): Response to the context modification request from the DU.

[0184] · Context release operation (initiated by CU): Used for the release of resource allocation for a certain MBS session or a certain delivery instance (including the PTP delivery instance of a specific UE, or the PTM delivery instance for a group of UEs).

[0185] · Context release operation (initiated by DU): Used to enable the DU to initiate the release of resource allocation for a certain MBS session or a certain delivery instance (including the PTP delivery instance of a specific UE, or the PTM delivery instance for a group of UEs).

[0186] · Notification (DU to CU): Used for the DU to send a QoS-related notification of the MRB for a specific delivery instance to the CU to notify that the QoS of the established GBR (guaranteed bit rate) MRB can no longer be met or can be met again.

[0187] These categories of messages can be constructed at various levels and can be transmitted to the target resource allocation and configuration of one or more UEs for a specific delivery instance or MBS session.

[0188] In some embodiments, the above messages may be constructed as UE - associated signaling messages (either per UE, or UE - specific signaling). In particular, each UE - associated message transmitted from the CU to the DU is directed to a specific UE, which has context information and other information items described above for implementing MBS session establishment / modification / release, resource allocation, and configuration related to that specific UE. The DU accordingly provides a UE - associated response to the CU. Such signaling may be based on an extension of the existing UE - associated signaling message scheme between the CU and the DU. The establishment, modification, and release of resources for delivering MBS session data to all UEs in an MBS group can be achieved by cumulatively transmitting and processing UE - related signaling messages for each UE in the MBS UE group.

[0189] Alternatively, the above messages may be constructed as MBS - associated signaling messages (either per MBS, or MBS - specific signaling), rather than UE - associated signaling messages. In particular, each MBS - associated message transmitted from the CU to the DU may not be directed to a specific UE, even though it contains information for implementing resource allocation and configuration for at least one UE in the MBS UE group. The MBS - associated message is directed to the MBS session and thus contains a set of information items for the UEs. To implement such MBS - associated messaging, a specific process code space separated from the UE - associated process code space may be reserved to represent the various message categories associated with MBS as described above. The signaling message may carry a <message type> information element, which contains a process code field pointing to the message category related to the MBS - associated signaling message category.

[0190] Therefore, from the perspective of the signaling architecture, the CU - DU message passing format can be designed in one of the following exemplary ways:

[0191] · Signaling message transfer format Example 1 : Provide formats only for different categories of UE - associated signaling messages between CU - DU signaling.

[0192] · Signaling message transfer format Example 2 : Provide only different categories of MBS - associated signaling messages between CU - DU signaling.

[0193] · Signaling message transfer format Example 3 : Use a separate process code space to provide formats for UE - associated and MBS - associated signaling messages between the CU and the DU. In some example embodiments, the above - mentioned various categories of requests and responses related to the PTP delivery instance of a specific UE can be carried using the UE - associated signaling message format, while the above - mentioned various categories of requests and responses related to a specific PTM delivery instance can be carried using the MBS - associated signaling message format.

[0194] Example features of the UE - associated signaling format are described below. During the interaction between the CU and the DU on the MBS session context, in order to perform MBS session context management or operations over the F1 interface, the various categories of UE - associated signaling messages mentioned above are always for a single UE. In other words, the CU and the DU use the signaling unit for each UE.

[0195] A specific UE - associated signaling message can carry any of the above - mentioned relevant information items. For example, a UE - associated signaling message can carry information items such as: MBS session context information identified by the MBS session ID, MRB information, which can include one or more of any of the following information items:

[0196] · MBS session ID

[0197] · MRBs corresponding to the MBS session. For each MRB:

[0198] ο MRB identifier (RBID) and possibly a UE - specific second RBID

[0199] ο QoS parameters of each MRB

[0200] ο QoS parameters of the QoS flows mapped to the MRB.

[0201] ο Downlink F1 - U tunnel information, and possibly a second downlink F1 - U tunnel, for the UE to perform MRB retransmission

[0202] · Delivery mode of the target UE, e.g., PTP, PTM, or both PTP and PTM.

[0203] · F1 - U tunnel information for additional tunnels (e.g., UE - specific uplink tunnel for PDCP status reports from the UE and / or UE - specific downlink tunnel for PDCP PDU retransmission) for one or more specific MRBs depending on specific delivery characteristics.

[0204] · RLC bearer configuration information of the UE.

[0205] Such UE - associated signaling messages are transmitted between the CU and the DU and are jointly used by the CU and the DU to synchronize the MBS session context information. In other words, the exchange of information items between the CU and the DU can cumulatively be based on multiple signaling interactions at different times.

[0206] For example, if the DU receives for the first time a request for MBS session context management and operation associated with a UE for this DU, it creates a corresponding context for the MBS session based on the received context information. In a subsequent signaling message associated with a second UE, for example, if the signaling message associated with the second UE is for the same MBS session but for a different second UE, and if the second signaling message includes an MBS context operation for the same MBS, the DU then updates the MBS session context based on the message (if necessary). Specifically, the signaling message 1 associated with the UE for UE1 carries the initial MBS session context. If at a later time, the signaling message 2 associated with the UE for UE2 carries the MRB QoS parameters and the corresponding QoS flow information of the same MBS session as in the message 1 associated with the UE, the DU updates the existing MBS session context previously established based on the content of the message 1 associated with the UE according to the message 2 associated with the UE. For example, the DU may update its MBS UE list to include UE 2 with appropriate delivery mode information and association with other UEs in the same PTM group (if the UE is in PTM mode). Optionally, if the subsequent message 2 does not carry the configuration information of the MBS session, the DU will maintain the content or configuration of the current MBS session context that was successfully created or modified last time. For example, after the DU creates an MBS context based on the MRB information in the signaling message associated with the UE for UE1, if some of its contexts (such as MRB QoS parameters) do not need to be updated, the subsequent signaling message associated with the UE for UE2 may or may not carry the corresponding MRB QoS parameters. In this way, this embodiment saves signaling transmission and processing overhead.

[0207] Any signaling message associated with a UE for an MBS session can operate on the MBS session context and configuration, including but not limited to the following information or combinations thereof:

[0208] · MRB attributes including their release and addition.

[0209] · Modification of QoS parameters corresponding to the MRB, addition and removal of QoS flows mapped to the MRB.

[0210] · Modification of PDCP configuration (such as PDCP SN length, reordering timer, cipher and integrity protection configuration).

[0211] In some scenarios, the above operations as a result of UE - associated signaling apply to all delivery instances of an MBS session associated with a DU. For example, in a delivery instance of an MBS session, UE - associated signaling messages update the F1 - U tunnel information corresponding to the MRB of the MBS session. If the corresponding MRBs in multiple delivery instances of the MBS session share the same F1 - U tunnel, the update of the tunnel information applies to all other transmission instances sharing that F1 - U tunnel.

[0212] Any UE - associated signaling for a specific UE can operate on various aspects of the delivery instance associated with the specific UE in an MBS session. The various aspects of the delivery instance associated with the specific UE include, but are not limited to, the following information or combinations thereof:

[0213] · Delivery instance ID.

[0214] · F1 - U tunnel associated with the delivery instance of the MRB.

[0215] · Configuration of the associated RLC bearer and control information corresponding to the delivery instance.

[0216] · Set of MAC / PHY configurations for a specific PTM delivery instance associated with the UE, which includes the delivery cell identifier or a specific PTM delivery instance in the cell.

[0217] For MBS - associated signaling messages for an MBS session, a specific MBS - associated signaling message can carry any of the above - mentioned relevant information items. For example, an MBS - associated signaling message can carry information items such as MBS session context information identified by the MBS session ID, MRB information, which can include any one or more of the following information items:

[0218] · MBS session ID.

[0219] · MRBs corresponding to the MBS session. For each MRB:

[0220] ο MRB identifier (RBID).

[0221] ο QoS parameters of each MRB.

[0222] ο QoS parameters of the QoS flow mapped to the MRB.

[0223] ο Downlink F1 - U tunnel information.

[0224] · Delivery mode of the target UE, such as PTP, PTM, or both PTP and PTM.

[0225] · F1-U tunnel information for additional tunnels for one or more specific MRBs depending on specific delivery characteristics (e.g., UE-specific uplink tunnels for PDCP status reports from the UE and / or UE-specific downlink tunnels for PDCP PDU retransmission).

[0226] · RLC bearer configuration information for the delivery instance.

[0227] · A set of MAC / PHY configurations for a specific PTM delivery instance, which includes the delivery cell identifier or a specific PTM delivery instance in the cell.

[0228] Such MBS-associated signaling messages are transmitted between the CU and the DU and are jointly used by the CU and the DU to synchronize the MBS session context information. In other words, the exchange of information items between the CU and the DU can cumulatively be based on multiple signaling interactions at different times.

[0229] When the DU receives the MBS session context management and operation request for the first time, it creates a corresponding context for the MBS session. In subsequent MBS-associated signaling messages, for example, if the subsequent MBS-associated signaling message is for the same MBS session, the DU updates the MBS session context based on the subsequent MBS-associated message. In some scenarios, the MBS-associated signaling message may only trigger the partial creation or update of the MBS session context.

[0230] The MBS-associated signaling message sent by the CU can instruct the DU to perform context synchronization and / or resource allocation and configuration based on the MBS session, based on the delivery instance, or based on the MRB. The MBS-associated signaling message can include various lists and tables of MRBs, UEs, and delivery instances (with MRB-, UE-, or delivery instance-specific information specified by the list or table).

[0231] The following disclosure further provides a detailed description of the signaling message format embodiment 1-3 messaging architecture between the CU and the DU when implementing interactive resource allocation and configuration for various delivery instances.

[0232] Example 1

[0233] In a first embodiment that only uses UE-specific signaling (alternatively referred to as UE-associated signaling), the CU can make a decision (as will be described later, such a decision can be made by the DU instead of the CU) that some UEs receive MBS in PTP mode (group 1 UEs), while some UEs receive MBS in PTM mode (group 2 UEs). The CU uses UE-associated F1 signaling such as UE context establishment or UE context modification messages, and requests the DU to allocate, modify, or release the corresponding resources, and sends the relevant configuration back to the DU. In this embodiment, MBS session context management is always performed per UE. If the CU needs to perform MBS session context management on multiple UEs, multiple UE-associated signaling messages are transmitted and combined to achieve resource allocation and configuration.

[0234] The UE-associated signaling initiated by the CU for MBS session context establishment or modification includes at least the following information items and the information items that can be returned by the DU in the response message. Since the UE-associated signaling is for a specific UE, some operations within the signaling are specific only to that UE.

[0235] 1. Information independent of the delivery mode (PTP / PTM), which includes UE ID, MBS session ID, MRB QoS parameters, and QoS parameters associated with the QoS flow:

[0236] · UE interface IDs: gNB-CU UE F1AP ID, gNB-DU UE F1AP ID; and MBS session ID or list of MBS session IDs.

[0237] ο DU response: gNB-CU UE F1AP ID, gNB-DU UE F1AP ID, MBS session ID or list of MBS session IDs.

[0238] · List of RB IDs of the MRBs serving one of the MBS sessions, where the RB ID is the MRB index of the MBS, and optionally, if the RB ID for the MBS and the RB ID used by the UE use a shared RB ID space between the MBS session and the PDU session associated with the UE, the RB ID (RBID1) of each MRB is associated with a second RB ID (RBID2).

[0239] ο DU response: The first RLC bearer configuration information corresponding to each MRB, which includes the corresponding serving RB ID, and the serving RB ID can be either RBID1 or RBID2.

[0240] · For a specific MRB, its QoS parameters and the QoS parameters of the QoS flow mapped to the MRB.

[0241] · For a specific MRB, its downlink multicast address (with or without a source address) and the corresponding GTP-TEID (GPRS Tunneling Protocol Tunnel Endpoint Identifier). If the downlink tunnel information is allocated by the DU to the MRB, then

[0242] ο DU response: The first downlink tunnel information (IP address and associated GTP-TEID) corresponding to each MRB accepted by the DU.

[0243] · UE capabilities of the UE,

[0244] · UE capability requirements for the MBS session.

[0245] 2. The CU determines the delivery mode for the UE and includes a delivery mode indicator in the information sent to the DU.

[0246] In another implementation, the CU only sends the MBS session context to the DU, and the DU determines the delivery mode for the UE and returns the configuration according to the delivery mode.

[0247] 3. Messages related to the PTP mode request. The CU / DU interaction information includes a PTP delivery mode indicator (if the CU determines the delivery mode and sends the indicator to the DU), the RLC entity mode, and the RLC bearer configuration including the served RB ID. The CU-to-DU message instructs the DU to deliver all MRBs of the MBS session to the UE in PTP mode, or instructs the DU to deliver a certain MRB or list of MRBs of the MBS session in PTP mode. The CU and DU messages, as well as the DU response, also contain:

[0248] · The RLC mode corresponding to the MRB, which may be the acknowledged mode (AM), the two-way unacknowledged mode (UM), the unidirectional UM uplink, or the unidirectional UM downlink.

[0249] · The uplink tunnel information corresponding to each MRB of the MBS session.

[0250] · An indicator to enable or activate retransmission (such as PDCP retransmission) for the MRB or list of MRBs of the MBS session.

[0251] ο DU response: The corresponding second downlink tunnel information (DL-TNL2, which includes an IP address and an associated GTP-TEID).

[0252] ο DU response: The RRC information from the DU to the CU, which at least contains the above RLC bearer configuration.

[0253] Upon receiving a request from the CU, the DU attempts to allocate or modify resources according to the request. The DU then sends response information to the CU to provide feedback on whether each RB has been successfully created. In addition, for each successfully created MRB, the DU creates a configuration for the specific RB and sends the configuration back to the CU. For the MRBs that fail in the corresponding operation, the DU response also includes: a list of MRBs that failed in the operation request, and the corresponding reasons.

[0254] 4. Messages related to PTM mode requests. The CU / DU interaction information includes a PTM delivery mode indicator (if the CU determines the delivery mode and sends the indicator to the DU. Otherwise, the DU determines the mode to the UE), the PTM delivery cell, the PTM delivery instance ID, the first RLC bearer configuration, and the second RLC bearer configuration. There are solutions for several CU / DU messages (the PTM delivery cell is the cell in which the MBS session is delivered, especially for the PTM delivery instance):

[0255] · The CU message does not specify the PTM delivery cell nor the delivery instance ID. There is only the MBS session context including a list of UEs with the PTM delivery mode.

[0256] ο DU response: The PTM delivery cell or a list of cells, optionally, the PTM delivery instance ID corresponding to the PTM delivery cell, and optionally, a list of UEs corresponding to the delivery instance.

[0257] · The PTM delivery cell specified in the CU message.

[0258] · The CU message specifies the PTM delivery cell but does not specify the PTM delivery instance ID in the transmission cell.

[0259] ο DU response: Optionally, the DU returns the PTM delivery instance ID in the transmission cell.

[0260] · The CU message specifies the PTM delivery cell and the CU specifies the PTM delivery instance ID in the transmission cell.

[0261] The DU includes the MAC / PHY configuration corresponding to the PTM delivery cell or the delivery instance in the cell in the response message.

[0262] For each accepted MRB in the PTM delivery cell or the PTM delivery instance of the MBS session:

[0263] · DU response: The configuration information of the first RLC bearer corresponding to the MRB, which also includes the associated logical channel identifier LCID1. In some scenarios, the logical channel identifier may include LCID1 and LCID2.

[0264] · The CU message also contains uplink tunnel information corresponding to the MRB.

[0265] · The CU message also indicates the mode of the RLC entity corresponding to the MRB, which may be the acknowledged mode (AM), the two-way unacknowledged mode (UM), the unidirectional UM uplink, or the unidirectional UM downlink.

[0266] · The CU message can also enable or activate the retransmission of the MRB (such as PDCP retransmission).

[0267] ο DU response: The corresponding second downlink tunnel information (DL-TNL2, including the IP address and the associated TEID) for a specific UE. This tunnel can be used for the PDCP retransmission of a specific UE or the UE PDCP status report.

[0268] ο DU response: The second RLC bearer configuration for a specific UE and its logical channel identifier

[0269] LCID3, and mark LCID3 corresponding to the main path, which is used to send PDCP SR.

[0270] ο DU response: A list of MRBs for which the operation of the PTM delivery instance corresponding to the MBS session has failed, and the corresponding reasons.

[0271] Now refer to Figure 4 , to understand the exemplary delivery instance configuration of the UE under the DU. The DU is associated with at least 3 cells and is associated with UE1 to UE10 in the context of the MBS session. The CU or DU makes a decision on the UE delivery mode for the MBS. If the CU makes a decision, the CU sends the delivery mode associated with the UE to the DU; if the DU makes a decision, the CU only sends the MBS session context to the DU and lets the DU make a decision, and the DU sends back the allocated resource configuration. In some embodiments, the CU only provides UE information and does not provide more delivery. Therefore, the DU decides the delivery mode of the UE, for example, considering the connection state of the UE and the available radio resources, as well as the UE capabilities of the UE, and the UE capability requirements of the MBS session. In the response information from the DU, the DU provides the transmission cell information and the delivery instance ID in the possible transmission cells, as well as the corresponding scheduling information including the MAC / PHY configuration set. Based on the interaction between the CU and the DU, there are interaction results as Figure 4 shown:

[0272] · Cell 1 – UE1, PTP

[0273] · Cell 1 – UE2 and UE3, PTM

[0274] · Cell 2 – UE4 and UE5, PTM

[0275] · Cell 3 – UE6, UE7, and UE8, PTM

[0276] · Cell 3 – UE9 and UE10, PTM

[0277] Obviously, each cell can support multiple delivery instances in PTP mode or PTM mode. In some embodiments, only one delivery instance is allowed per cell.

[0278] In some embodiments, each PTP delivery mode, PTM delivery mode in different cells, and each delivery in PTM delivery mode in the same cell are mapped to different delivery instances. For each MRB, at least one RLC entity is allocated on the DU side.

[0279] The message interaction between the CU and the DU and the information items carried in the messages are further described below and are organized into several groups.

[0280] Contents related to MBS sessions

[0281] The CU initiates a context management operation for a certain MBS session or a list of MBS sessions to the DU using UE - associated signaling. This operation can be the addition or modification of the MBS context, or the message contains the context related to the MBS session and its operation. This message is identified by the gNB - CU UE F1AP ID or optionally the gNB - DU UE F1AP ID. An MBS session can correspond to one MBS or a class of MBSs, and one MBS can be associated with multiple MBS sessions. An MBS session is identified by the MBS session ID.

[0282] The MBS session ID can be used to identify the MBS session and can be one of the following IDs or a combination thereof:

[0283] · Session ID: The session ID in the session management mechanism corresponding to a certain UE for which the MBS session corresponds. This session ID uniquely specifies one MBS session among multiple sessions of the UE, and this session ID can be included in the SDAP configuration.

[0284] · TMGI (Temporary Mobile Group Identity).

[0285] · IP multicast address (with or without a source address).

[0286] · gNB - CU MBS F1AP ID: The gNB - CU MBS F1AP ID uniquely identifies the MBS association within the gNB - CU through the F1 interface.

[0287] · gNB-DU MBS F1AP ID: The gNB-DU MBS F1AP ID uniquely identifies the MBS association within the gNB-DU over the F1 interface.

[0288] · An identifier or index that can uniquely identify an MBS session in the CU, DU, or F1 interface. An MBS session can correspond to a service or a class of services, and an MBS can be associated with multiple MBS sessions.

[0289] In the corresponding DU response message, the message uses the gNB-CU UE F1AP ID and the gNB-DU UE F1AP ID to identify the associated F1 logical connection, and the response message also includes the MBS session ID.

[0290] In the same context management operation, the message also includes an MRB list containing the MRBs serving the MBS, a first RB ID (RBID1) corresponding to each MRB in the MRB list. RBID1 is the index of all MRBs serving the MBS. Based on the MBS session ID and RBID1, the MRB can be uniquely identified within the DU scope, CU scope, or over the F1 interface.

[0291] In some scenarios, the MRB is also associated with a second RB ID (RBID2), and the served radio bearer in the first RLC bearer configuration for delivering instances within the DU response message is configured as the second RB ID (RBID2) for the UE in the CU. The service data based on the RLC bearer received by the UE is delivered to the PDCP entity identified by RBID2.

[0292] This operation also includes the QoS parameters for each MRB and the QoS parameters of the QoS flow mapped to the MRB.

[0293] F1 - U tunnel resources

[0294] In some embodiments, the DU receives a PTP or PTM delivery request from the CU for a certain MRB of a certain MBS session.

[0295] In some embodiments, the CU uses the MBS session as a granularity to request the DU to deliver MBS session data to the UE in PTP mode, that is, the CU requests the DU to deliver the service data of all MRBs of the MBS session in PTP mode. However, in some other embodiments, for example, when the radio resources are limited or scarce, it is more desirable to include only the data of a specific one or more MRBs in the PTP delivery mode rather than all MRB data of the MBS session. In such a scenario, the CU requests the DU to deliver a specific MRB or MRB list of the MBS session in PTP mode.

[0296] In some embodiments, the DU receives from the CU a request to use the PTM delivery mode for an MBS session. For example, for the PTM delivery mode, MBS data is delivered based on the granularity of the MBS session.

[0297] For the above specific request, regardless of the delivery mode, for a specific MRB, if the DU accepts the MRB delivery request from the CU for the MBS session, then:

[0298] · In some embodiments, as Figure 6 shown (for illustrating Figure 4 the sharing of the downlink tunnel of a specific MRB among some delivery instances), the CU uses IP multicast 610 to transmit the MRB data to the DU at the IP layer of the tunnel. The information sent by the CU includes the IP multicast downlink tunnel information for the MRB, that is, the downlink tunnel information of the first IP multicast type. Then, if any associated delivery instance accepts the MRB, the DU will join the IP multicast group and receive the MBS. Tunnel 1 is on top of the IP layer based on IP multicast 610. Its tunnel information includes: the IP multicast address and an optional source address, as well as the GTP-TEID. In this scenario, Tunnel 1 is shared by multiple delivery instances (for example, the PTP delivery instance for UE1 ( Figure 6 602), the PTM delivery instances for UE6, UE7, and UE8 ( Figure 6 604), and the PTM delivery instances for UE9 and UE10 ( Figure 6 606)). The MRB data is delivered from the CU to the DU using Tunnel 1, and then the DU submits the MRB data to multiple RLC entities (RLC entities 1, 2, and 3) to serve the corresponding delivery instances. Figure 6 A data delivery example of an MRB is shown, but the same principle also applies to other MRBs.

[0299] · In some embodiments, as Figure 6 shown, the CU uses IP point-to-point transmission 612 to transmit the MRB data to the DU. The F1-U tunnel information of the MRB is provided by the DU. If there is no previous delivery instance that has accepted the MRB for the MBS session on the DU side, or this is the first time such an MRB for the MBS session is established in the DU, the DU will allocate the corresponding F1-U interface resources, which is the first downlink tunnel, and return the corresponding first downlink tunnel information to the CU, and this information includes the IP address and the associated GTP-TEID. It should also be noted that once the DU receives the MRB data from Tunnel 1, the DU processes the remaining data delivery tasks in the same way as above. In this scenario, Tunnel 1 is shared by multiple delivery instances (for example, the PTP delivery instance for UE1 ( Figure 6602) for PTM delivery instances for UE6, UE7, and UE8 ( Figure 6 604) and PTM delivery instances for UE9 and UE10 ( Figure 6 606)) are shared. The MRB data is delivered from the CU to the DU using Tunnel 1, and then the DU submits the MRB data to multiple RLC entities (RLC Entity 1, 2, and 3) to serve the corresponding delivery instances. Figure 6 Shows a data delivery example for one MRB, but the same principle also applies to other MRBs.

[0300] · In some embodiments, if the DU previously had a delivery instance that included an MRB corresponding to an MBS session (including PTP or PTM delivery instances), the same MRB for the same MBS session shares the F1-U downlink tunnel, and the DU returns the downlink tunnel information, i.e., the first DL tunnel, through the F1-U interface that has been established for the MRB of the MBS session. For example, in Figure 6 , multiple delivery instances (PTP transmission for UE1, PTM transmission for UE6, UE7, and UE8, and another PTM delivery instance for UE9 and UE10) share the same F1-U Tunnel 1 of the same MRB. The PDCP PDUs from the PDCP entity corresponding to the MRB are submitted to the RLC entities corresponding to the multiple delivery instances after passing through the tunnel.

[0301] · In some embodiments, the MRB uses an independent F1-U downlink tunnel, i.e., for a certain MRB of an MBS session, there are multiple independent F1-U tunnels on the corresponding F1 interface based on different delivery instances. Therefore, based on the MBS session context management request, the DU returns independent tunnel information for the same MRB under different delivery instances. The tunnels created in this scenario are called the first downlink tunnels under each delivery instance. For example, in Figure 7 (for illustration of Figure 4 some delivery instances in which use independent downlink data tunnels), multiple delivery instances (PTP delivery instance for UE1, labeled 702 in Figure 7 , PTM delivery instances for UE6, UE7, and UE8, labeled 704 in Figure 7 , and another PTM delivery instance for UE9 and UE10, labeled 706 in Figure 7 ) use independent F1-U tunnels, i.e., Tunnel 2, Tunnel 3, and Tunnel 4. At this time, after the PDCP PDUs from the PDCP entity corresponding to the MRB are transmitted to the DU through their respective tunnels, it is submitted to the RLC entities corresponding to the multiple delivery instances, for example, RLC Entity 1, RLC Entity 2, and RLC Entity 3.

[0302] The following section describes the CU-DU interaction for handling PTP-related requests.

[0303] Request handling related to PTP delivery mode and RLC bearer configuration

[0304] The CU message carries the RLC mode corresponding to the MRB, whether it is AM, two-way UM, unidirectional UM uplink, or unidirectional UM downlink. After accepting a request sent in PTP mode for the corresponding MRB, the DU establishes or modifies the configuration of the RLC entity corresponding to the MRB, and allocates the corresponding MAC resources such as logical channels, and returns the corresponding RLC bearer configuration in the response message. The RLC bearer configuration is included in the cell group configuration and further included in the DU-to-CU RRC information to be sent to the CU.

[0305] The CU message also carries the uplink tunnel information corresponding to the MRB. Specifically, the IP address and the associated GTP-TEID. The uplink tunnel information can be used by the DU to establish an uplink tunnel. In some scenarios, this uplink tunnel is used to transmit the corresponding PDCP status report (PDCP SR) related to the MRB data reception generated by the UE. This is as Figure 8 shown.

[0306] More specifically, Figure 8 shows the tunnel configurations of specific MRBs in delivery instances 802 and 804, which have data tunnel 1 and data tunnel 2. Delivery instance 804 can be a PTP delivery instance, while delivery instance 802 can be a PTP or PTM delivery instance. As Figure 8 shown, in delivery instances 802 and 804, tunnel 1 is shared by delivery instances 802 and 804 for the normal downlink transmission of the MRB's RLC entity to the MRB's PDCP PDU, while tunnel 2 is the established uplink PDCPSR 810 transmission to the CU.

[0307] Handling of PTP retransmission requests

[0308] If the CU enables or activates PDCP retransmission for the MRB, there may be different scenarios regarding how to share the F1-U downlink tunnel:

[0309] · In some embodiments, the CU uses IP multicast to transmit the MRB data to the DU. Referring again to Figure 8 . Figure 8Further, it is shown that tunnel 2 is used for retransmission of the PTP delivery instance 804, which shares an uplink tunnel with the uplink tunnel for transmitting PDCP SR. The information of tunnel 1 is provided by the CU, while the information of tunnel 2 is provided by the DU. For MRB data transmission, the initial data transmission for different delivery instances shares tunnel 1, and the MRB data retransmission for the PTP delivery instance 804 uses tunnel 2. For the PTP delivery instance 804, both the initial data and the retransmission data are submitted to the RLC entity 2 corresponding to the PTP delivery instance 804.

[0310] · In some embodiments, the CU uses a point-to-point manner to transmit MRB data to the DU. Refer to Figure 8 , both the tunnel 1 and tunnel 2 information are provided by the DU. In this scenario, for MRB data transmission, the initial data transmission for different delivery instances shares tunnel 1. For the PTP delivery instance 804, the MRB data retransmission uses tunnel 2. Both the initial data and the retransmission data are delivered to the same RLC entity (i.e., RLC entity 2) corresponding to the PTP delivery instance.

[0311] · In some embodiments, the same MRB in different delivery instances uses independent tunnels. Refer to Figure 9 (showing delivery instances using independent data tunnels 902 and 904 for a specific MRB), the PTP delivery instance 904 for UE1 uses tunnel 2, while the delivery instances for other UEs use tunnel 1. For the PTP delivery instance 904 for UE1, the MRB data initial transmission and retransmission use the same tunnel (i.e., tunnel 2). In this scenario, tunnel 2 can be bidirectional. It can be used as the downlink for MRB data initial transmission and retransmission. It can also be used as the uplink for transmitting the PDCP SR corresponding to the MRB.

[0312] Handling DU's rejection of creating some MRBs

[0313] For the CU message specifying the PTP delivery mode for the UE, the DU can reject the creation or modification of one or more MRBs. In this case, the DU returns an MRB list, which includes the MRBs for which the creation or modification fails, and the reason for the failure.

[0314] The following section describes the CU-DU interaction for handling PTM-related requests.

[0315] PTM-related requests - cell-related information and lower-layer configuration information

[0316] Each PTM delivery instance always corresponds to a specific transmission cell. Depending on different implementations, if the UE receiving the MBS session is in the connected state, the context of the cell associated with the UE exists on both the CU and DU sides. The transmission cell information for the PTM delivery instance can be provided by the CU or the DU. Additionally, if the transmission of a certain MBS session in a certain cell is allowed based on multiple delivery instances, then in order to uniquely identify these delivery instances, it is necessary to combine the cell identifier and the unique identifier within the cell. Alternatively, on the F1 interface, for an MBS session, there is an identifier that can uniquely identify the delivery instance and its corresponding cell. The delivery instance identifier can be provided by the CU or the DU. In the following disclosure, the above different possibilities of the delivery instance identifier are disclosed in detail. Additionally, each PTM delivery instance corresponds to a set of MAC / PHY configurations. Based on this configuration set, the UE can complete the reception of the MBS delivery instance within the time-frequency domain corresponding to the physical layer.

[0317] In some implementations, the CU only provides UE information and does not provide more about the delivery. Therefore, the DU determines the delivery mode of the UE, for example, considering the connection state of the UE and the available radio resources, as well as the UE capabilities of the UE, and the UE capability requirements of the MBS session. In the response information from the DU, the DU provides the transmission cell information and the delivery instance ID in the possible transmission cell, as well as the corresponding scheduling information including the MAC / PHY configuration set.

[0318] In some implementations, the CU provides more UE information and the corresponding delivery, and the CU does not specify the cell information for the PTM transmission for the MBS of the UE, while the DU includes the cell or list of cells for the PTM transmission in the corresponding response message. Optionally, the DU further includes in the response message the PTM delivery instance ID corresponding to the transmission cell, and the scheduling information corresponding to the corresponding cell or the corresponding PTM delivery instance in the corresponding cell.

[0319] The CU can specify the transmission cell in the PTM transmission. Optionally, the CU further specifies the PTM delivery instance ID in the transmission cell.

[0320] In some scenarios, the CU specifies the cell information for the PTM transmission, while the DU optionally includes in the corresponding response message the PTM delivery instance ID of the corresponding transmission cell, and the scheduling information corresponding to the corresponding cell or the corresponding PTM delivery instance in the corresponding cell.

[0321] If the CU further specifies the cell information for the PTM transmission and the PTM delivery instance ID in the corresponding cell, then the DU will include in the corresponding response message the scheduling information corresponding to the corresponding cell or the corresponding PTM delivery instance in the corresponding cell.

[0322] The above scheduling information includes: MAC / PHY configuration corresponding to the PTM delivery instance, and may also include the following information or a combination of the following information:

[0323] · DRX information corresponding to the PTM delivery instance

[0324] · Radio Network Temporary Identifier (RNTI) of the PTM delivery instance

[0325] · Time-domain scheduling information corresponding to the PTM delivery instance for indicating the subframe or time slot for scheduling PTM transmission

[0326] · Frequency-domain resource allocation information corresponding to the PTM delivery instance.

[0327] · PDCCH (Physical Downlink Control Channel) configuration and PDSCH (Physical Downlink Shared Channel) configuration corresponding to the PTM delivery instance.

[0328] · BWP (Bandwidth Part) information corresponding to the PTM delivery instance.

[0329] PTM - related requests, RLC bearer configuration

[0330] If the DU accepts the corresponding MRB transmission request in PTM mode and the delivery instance specified by the CU or DU does not exist, the DU establishes the corresponding RLC bearer based on information from the CU message such as PDCP SN. Otherwise, if the PTM delivery instance already exists in the DU, the DU associates the UE with the PTM delivery instance and sends the corresponding first RLC bearer configuration to the CU according to the configuration corresponding to the existing delivery instance.

[0331] In some embodiments, if the DU accepts the corresponding MRB transmission request in PTM mode, the DU needs to include in the response message the RLC bearer configuration information corresponding to each MRB of the MBS session, which includes the logical channel ID corresponding to the MRB.

[0332] In another embodiment, if the DU accepts the corresponding MRB transmission request in the PTM mode, in the first RLC bearer configuration, the DU includes RLC bearer configuration information corresponding to each MRB in the MBS session. The RLC bearer configuration information further includes a first logical channel ID1 (LCID1) and an associated second logical channel ID2 (LCID2). Among them, LCID1 is actually included in the MAC PDU generated by the DU in the actual PTM delivery, which corresponds to the logical channel information in the sub-header of the MAC PDU including the corresponding MRB service data, and LCID2 is mapped to LCID1. After receiving the MAC PDU, the UE submits the data marked as LCID1 in the MAC PDU sub-header to the logical channel identified by LCID2 for further processing.

[0333] PTM - related requests - handling PDCPSR and retransmission

[0334] Reference Figure 10 (shows the tunnel configuration of the PTM instance 1002 for a specific MRB). In some scenarios, the network needs to use a bidirectional tunnel to enable PDCP SR for the MRB and / or PDCP data retransmission for the MRB in the PTM delivery instance 1001 for a specific UE. The UE is configured with two independent RLC entities within the PTM delivery instance 1002: an RLC entity 1 associated with tunnel 1 that performs the initial MRB data transmission in the PTM mode, and an RLC entity 2 associated with tunnel 2 that performs the retransmission of MRB data in the PTP mode ( Figure 10 marked as 1004 in), and the transmission of PDCP SR corresponding to the MRB in the uplink. In this case, tunnel 2 is bidirectional.

[0335] The CU message also carries the uplink tunnel information corresponding to the MRB, specifically the IP address and the associated GTP-TEID. If the CU enables or activates PDCP retransmission for the MRB, the DU returns the second downlink tunnel information (including the IP address and the associated GTP-TEID). Now, the DU includes the information of two tunnels corresponding to the MRB on the F1 interface. The first tunnel (tunnel 1) can be used to transmit the initial transmission data corresponding to the MRB, while the second tunnel (tunnel 2) is used to transmit the retransmission data corresponding to the MRB and the uplink PDCP SR.

[0336] The CU message also indicates the mode of the RLC entity corresponding to the MRB, whether it is the acknowledged mode (AM), the two-way unacknowledged mode (UM), the unidirectional UM uplink, or the unidirectional UM downlink. After the DU accepts the corresponding MRB transmission request in the PTM mode, the DU creates or modifies the RLC bearer corresponding to the MRB, allocates the corresponding MAC resources such as logical channels, and returns the corresponding second RLC bearer configuration in the response message. The RLC bearer configuration is included in the cell group configuration and further included in the DU-to-CU RRC information to be sent to the CU.

[0337] Handling DU's rejection of creating some MRBs

[0338] For the CU message that specifies the PTM delivery mode for the UE, the DU may reject the creation or modification of one or more MRBs. In this case, the DU returns an MRB list that includes the MRBs for which the establishment or modification has failed, as well as the reason for the failure.

[0339] Handling dual - mode using PTP and PTM

[0340] In some embodiments, for a specific UE, the CU may request both the PTP and PTM delivery modes. The DU allocates the corresponding resources so that the UE can receive MRB data in both the PTP and PTM modes simultaneously.

[0341] Example 2

[0342] In this embodiment, the CU makes a decision that some UEs receive MBS in the PTP mode (group 1 UEs), while some UEs receive MBS in the PTM mode (group 2 UEs). The CU uses MBS-related F1 signaling such as the MBS context establishment or MBS context modification message to send this decision to the DU and requests the DU to allocate or modify the corresponding resources and related configurations. At the same time, on the DU side, when receiving a CU-initiated MBS-related message that includes the delivery mode information (PTP for a specific UE, or PTM for a specific UE or cell or instance in the cell), the DU allocates resources and creates the corresponding configuration. Based on whether each MRB is successfully created, the DU sends a feedback message that includes MRB configuration information such as F1-U and RLC bearer configuration, as well as the radio interface resource allocation for the delivery instance corresponding to the MBS session. In this embodiment, the MBS session context management is always performed based on each MBS. This new mechanism is supported by introducing MBS-related signaling in this disclosure.

[0343] In some embodiments, the DU makes a decision that some UEs receive MBS in PTP mode (group 1 UEs), while some UEs receive MBS in PTM mode (group 2 UEs). Meanwhile, on the DU side, upon receiving an MBS - associated message initiated by the CU, the DU allocates resources and creates corresponding configurations. Based on whether each MRB is successfully created, the DU sends a feedback message that includes MRB configuration information such as F1 - U and RLC bearer configurations, and radio - access - network resource allocations for the delivery instances corresponding to the MBS session. In this embodiment, MBS session context management is always performed per MBS.

[0344] For each MBS session, on the corresponding F1 interface, there may be an F1 logical connection used for context management between the CU and the DU. In some scenarios, for all MBS sessions, there is unified signaling on the F1 interface, and this unified signaling can be used to manage the context of the MBS session list.

[0345] The MBS - associated message interaction between the CU and the DU and the information items carried in the messages are further described below and are organized into several groups.

[0346] Basic information independent of the delivery mode, which includes interface ID, MBS session ID, MRB QoS parameters, and associated QoS flow parameters

[0347] · gNB - CU MBS F1AP ID, gNB - DU MBS F1AP ID: MBS session ID or list of session IDs.

[0348] ο DU response: gNB - CU UE F1AP ID, gNB - DU UE F1AP ID, MBS session ID or list of session IDs.

[0349] · Delivery mode description. This can include the entire MBS session, or the MRBs in the MRB list for this MBS session using PTP mode, together with the corresponding list of UE IDs, and the list of UE IDs for all UEs using PTM mode, or the list of cells or list of instances in the corresponding cell list using PTM mode.

[0350] · The UE ID can be one of the following identifiers, or a combination of them: gNB - CU UE F1AP ID, gNB - DU UE F1AP ID, C - RNTI, or any other identifier or index that can uniquely identify the UE in the CU or DU or on the F1 interface.

[0351] · A list of MRB IDs of MRBs serving one of the MBS sessions, where the first RB ID (RBID1) corresponding to each MRB is the index of all MRBs of the MBS. Optionally, the CU provides a list of UE IDs of all UEs receiving the MBS session. Optionally, for each UE, if independent namespaces are used for the RB ID of the MBS and the RB ID used by the UE, the RB ID (RBID1) of each MRB is associated with a second RB ID (RBID2).

[0352] ο DU response: For each of the above UEs, the first RLC bearer configuration information corresponding to each MRB of the MBS session, which includes the corresponding serving RB ID, which can be RBID1 or RBID2.

[0353] · For a specific MRB, its QoS parameters and the QoS parameters of the QoS flows mapped to the MRB. · For a specific MRB, its downlink IP multicast address (and its source address) and the corresponding GTP-TEID. In the case of using point-to-point delivery to transmit MRB data at the IP layer of the tunnel,

[0354] ο DU response: The first downlink tunnel information (IP address and associated GTP-TEID) corresponding to each MRB accepted by the DU. If there are multiple delivery instances of MRBs, the list of acceptable MRBs for each delivery instance may be different.

[0355] · UE capabilities for the UE.

[0356] · UE capability requirements for the MBS session.

[0357] Messages related to PTP mode requests. DU CU interaction information includes PTP delivery mode indicator, RLC entity mode including the served RB RLC bearer configuration with RB ID

[0358] · For a UE using the PTP mode determined by the CU, the CU instructs the UE to receive all MRBs of the MBS session in the PTP mode, or the UE to receive some or all MRBs in the MRB list in the PTP mode.

[0359] · The CU also instructs the RLC entity mode corresponding to the MRB, which can be the acknowledged mode (AM), the two-way unacknowledged mode (UM), the one-way UM uplink, or the one-way UM downlink.

[0360] · The CU can also include uplink tunnel information (which includes the IP address and associated GTP-TEID) corresponding to each of the above MRBs.

[0361] ·CU can also enable or activate retransmissions (such as PDCP retransmissions) for each of the above MRBs.

[0362] ο DU response: The corresponding second downlink tunnel information (DL-TNL2, including the IP address and the associated GTP-TEID).

[0363] ο DU response: The RRC information from DU to CU, which at least includes the above RLC bearer configuration.

[0364] ο DU response: The MRB list of the MRBs for which the operation request fails, and the corresponding reasons.

[0365] Messages related to PTM mode requests

[0366] The CU-DU interaction information includes the PTM delivery mode indicator, the PTM delivery cell, the PTM delivery instance ID, the first RLC bearer configuration and the corresponding RLC entity configuration, the second RLC bearer configuration and the corresponding RLC entity configuration.

[0367] In the request message, the CU specifies to use the PTM mode to transmit MBS session data. In the DU response message, there is a list of PTM delivery instances, and each delivery instance in the list can also be associated with a list of UE IDs. The information exchange between the CU and DU interactions is as follows:

[0368] · The CU request message includes a list of UE IDs, which contains the UEs using the PTM delivery mode.

[0369] ο DU response: Optional PTM delivery cell or list of cells, optionally, the PTM delivery instance ID corresponding to the PTM delivery cell, and optionally, the list of UE IDs corresponding to the delivery instance.

[0370] · The CU request message includes a list of cells corresponding to the PTM delivery mode, and each cell in the list of cells can also be associated with a list of UE IDs.

[0371] ο DU response: Optional PTM delivery cell or list of cells, optionally, the list of PTM delivery instances corresponding to the PTM delivery cell, and optionally, the list of UE IDs corresponding to the delivery instance.

[0372] · The UE capabilities for the UE.

[0373] · The UE capability requirements for the MBS session.

[0374] · The CU request message includes a list of cells corresponding to the PTM delivery mode and a list of PTM delivery instances. Each cell in the cell list may also be associated with a list of UE IDs, and each delivery instance in the delivery instance list may also be associated with a list of UE IDs.

[0375] ο DU response: Optional PTM delivery cell or list of cells, optionally, the PTM delivery instance ID corresponding to the PTM delivery cell, and optionally, a list of UE IDs corresponding to the delivery instance.

[0376] The DU response message includes the MAC / PHY configuration corresponding to the PTM delivery cell or the delivery instance in the cell.

[0377] For each MRB in the PTM delivery cell or PTM delivery instance of the MBS session, or for each MRB acceptable in the CU request:

[0378] ο DU response: Configuration information of the first RLC bearer corresponding to the MRB, which also includes the associated logical channel identifier LCID1. In some scenarios, the logical channel identifier may include LCID1 and LCID2.

[0379] · The CU also contains the uplink tunnel information corresponding to the MRB.

[0380] · The CU also indicates the mode of the RLC entity corresponding to the MRB, which may be the acknowledged mode (AM), the two-way unacknowledged mode (UM), the unidirectional UM uplink, or the unidirectional UM downlink.

[0381] · The CU may also enable or activate retransmission for the MRB (such as PDCP retransmission).

[0382] ο DU response: Corresponding downlink tunnel information (DL-TNL2, including the IP address and the associated TEID).

[0383] ο DU response: The second RLC bearer configuration and its logical channel identifier LCID3, and mark LCID3 corresponding to the main path, which is used to send PDCP SR.

[0384] ο DU response: A list of MRBs with operation failures corresponding to the PTM delivery instance of the MBS session, and the corresponding reasons.

[0385] General ID

[0386] The MBS session may correspond to one MBS or a class of MBSs. The MBS session ID can be used to identify the MBS session and can be one of the following IDs or a combination thereof:

[0387] · Session ID: The session ID in the session management mechanism corresponding to an MBS session for a certain UE uniquely specifies the MBS session among multiple sessions of the UE, and the session ID can be included in the SDAP configuration.

[0388] · TMGI (Temporary Mobile Group Identity).

[0389] · IP multicast address (with or without a source address).

[0390] · gNB-CU MBS F1AP ID: The gNB-CU MBS F1AP ID uniquely identifies the MBS association through the F1 interface within the gNB-CU.

[0391] · gNB-DU MBS F1AP ID: The gNB-DU MBS F1AP ID uniquely identifies the MBS association through the F1 interface within the gNB-DU.

[0392] · An identifier or index that can uniquely identify the MBS session in the CU or DU or the F1 interface.

[0393] In the corresponding DU response message, the message uses the gNB-CU MBS F1AP ID, and optionally, the gNB-DU MBS F1AP ID to identify the associated F1 logical link, and this response message also contains the MBS session ID.

[0394] General UE ID list

[0395] If the CU decides which UE in the MBS session UE group belongs to which delivery mode, the CU request message also contains a description of the delivery mode.

[0396] The CU also includes the following delivery mode descriptions in the request message, which include the PTP delivery mode of the MBS session or the MRB list in the MBS session, the corresponding UE ID list; and the PTM delivery mode of the UE list corresponding to the MBS session. For example, in Figure 4 UE1 uses the PTP delivery mode; UE2 - UE10 use the PTM delivery mode.

[0397] The above UE ID can be used to identify the UE and can be one of the following IDs or a combination thereof:

[0398] · gNB-CU UE F1AP ID

[0399] · gNB-DU UE F1AP ID

[0400] · C-RNTI

[0401] · An identifier or index that can uniquely identify a UE in the CU or DU or F1 interface.

[0402] General - MRB ID information

[0403] In the same context management operation, the message further includes an MRB list containing the MRBs serving the MBS, a first RB ID (RBID1) corresponding to each MRB in the MRB list, and RBID1 is the index of all MRBs serving the MBS. Based on the MBS session ID and RBID1, the MRB can be uniquely identified within the DU scope or CU scope or on the F1 interface.

[0404] In some scenarios, the MRB is also associated with a second RB ID (RBID2), and the served radio bearer in the first RLC bearer configuration is established as the second RB ID (RBID2). The service data of the UE received based on the RLC bearer is delivered to the PDCP entity identified by RBID2 for processing.

[0405] This operation further includes the QoS parameters of each MRB and the QoS parameters of the QoS flow mapped to the MRB.

[0406] General - F1 - U

[0407] In some embodiments, the DU receives a PTP or PTM transmission request from the CU for a certain MRB of a certain MBS session.

[0408] In some embodiments, the CU uses the MBS session as a granularity to request the DU to transmit MBS session data to the UE in PTP mode, that is, the CU requests the DU to transmit the service data of all MRBs of the MBS session in PTP mode. In some embodiments, for example, when the radio resources in the air interface are limited or scarce, it is more desirable to include only the data of a specific one or more MRBs in the PTP delivery mode rather than the data of all MRBs of the MBS session. The CU requests the DU to transmit a specific MRB or MRB list of the MBS session in PTP mode.

[0409] In some embodiments, the DU receives a request from the CU for the PTM delivery mode of an MBS session. For example, in the PTM delivery mode, the MBS data is transmitted based on the granularity of the MBS session.

[0410] For the above specific request, regardless of the delivery mode, for a specific MRB, if the DU accepts the MRB transmission request from the CU for the MBS session, then:

[0411] · In some embodiments, such as Figure 6(Downlink Tunnel Sharing) As shown, the CU uses IP multicast 610 to transmit MRB data to the DU using Tunnel 1. The CU message contains the IP multicast downlink tunnel information for the MRB, i.e., the first downlink tunnel information. This tunnel information includes: the IP multicast address, and optionally the source address and GTP-TEID. Then, the DU joins the IP multicast group and receives the MBS. Tunnel 1 is on top of the IP layer based on IP multicast 610.

[0412] · In some embodiments, as Figure 6 (Downlink Tunnel Sharing) As shown, the CU uses IP point-to-point transmission 612 to transmit MRB data to the DU. The F1-U tunnel information for the MRB is provided by the DU. If there is no previous delivery instance of the MRB for the MBS session on the DU side, the DU allocates the corresponding F1-U interface resources, which is the first downlink tunnel, and returns the corresponding first downlink tunnel information (which includes the IP address and the associated GTP-TEID) to the CU.

[0413] · In some embodiments, if the DU already has a delivery instance (including PTP or PTM delivery instances) of the MRB corresponding to the MBS session, then the same MRB of the same MBS session shares the F1-U downlink tunnel, and the DU returns the downlink tunnel information, i.e., the first downlink tunnel, through the F1-U interface already established for the MRB of the MBS session. For example, in Figure 6 , multiple delivery instances (PTP transmission for UE1, PTM transmission for UE6, UE7, and UE8, and another PTM delivery instance for UE9 and UE10) share the same F1-U Tunnel 1 of the same MRB. The PDCPPDU generated by the PDCP entity corresponding to the MRB is submitted to the RLC entity (RLC entities 1, 2, and 3) after passing through the tunnel and is further delivered to the corresponding delivery instance.

[0414] · In some embodiments, the MRB uses an independent F1-U downlink tunnel, i.e., for a certain MRB of the MBS session, there are multiple independent F1-U tunnels on the corresponding F1 interface based on different delivery instances. Therefore, based on the request, the DU returns the independent tunnel information for the MRB, which is the first downlink tunnel. For example, in Figure 7(Independent downlink data tunnel), multiple delivery instances (PTP transmission for UE1, PTM transmission for UE6, UE7, and UE8, and another PTM delivery instance for UE9 and UE10) use independent F1-U tunnels, namely Tunnel 2, Tunnel 3, and Tunnel 4. The PDCP PDUs generated by the PDCP entities corresponding to the MRBs are submitted to the RLC entities (RLC Entities 1, 2, and 3) after passing through each tunnel and are further delivered to the corresponding delivery instances.

[0415] Messages related to PTP requests and RLC bearer configuration

[0416] The CU message indicates that the UE receives the MBS session in PTP mode, or the UE receives a certain MRB or list of MRBs of the MBS session in PTP mode. For the MRBs accepted by this UE and DU:

[0417] The CU message also indicates the RLC entity mode corresponding to the MRB, which can be AM or UM. If the DU accepts the corresponding MRB transmission request in PTP mode, the DU will create or modify the RLC entity corresponding to the MRB, allocate the corresponding MAC resources such as logical channels, and return the corresponding second RLC bearer configuration in the response message. The RLC bearer configuration is included in the cell group configuration and is also included in the DU-to-CU RRC information to be sent to the CU.

[0418] The CU message also indicates the uplink tunnel information corresponding to the MRB. Specifically, the IP address and the associated GTP-TEID. In some scenarios, the F1-U tunnel is used to transmit the corresponding PDCP status reports (PDCP SRs) related to the MRB data reception generated by the UE. As Figure 8 and Figure 9 shown, for UE1, the PDCP status reports 810 and 910 of the MRB are transmitted to the network side, i.e., the PDCP entity in the CU, through Tunnel 2.

[0419] If the CU enables or activates PDCP retransmission for the MRB, there may be different scenarios regarding how to share the F1-U downlink tunnel:

[0420] · In some embodiments, the CU uses multicast to transmit MRB data to the DU. Referring to Figure 8 , the Tunnel 1 information is provided by the CU, and the Tunnel 2 information is provided by the DU. For MRB data transmission, the initial data transmissions of different delivery instances share Tunnel 1.

[0421] · In some embodiments, the CU uses a point-to-point manner to transmit MRB data to the DU. Referring to Figure 8, the information of both Tunnel 1 and Tunnel 2 is provided by the DU. For MRB data transmission, the initial data transmission of different delivery instances shares Tunnel 1. For UE1, the MRB data retransmission uses Tunnel 2. Both the initial data and the retransmitted data are delivered to RLC entity 2 corresponding to the PTP delivery instance of UE1.

[0422] · In some embodiments, the same MRB uses independent tunnels in different delivery instances. Refer to Figure 9 (independent tunnels of delivery instances 902 and 904), the delivery instances of other UEs use Tunnel 1 associated with RLC entity 1, while the PTP delivery instance of UE1 uses Tunnel 2 associated with RLC entity 2. For UE2, the initial transmission and retransmission of MRB data share Tunnel 2. In this case, Tunnel 2 is bidirectional because it can also be used as an uplink tunnel for transmitting PDCP SR corresponding to the MRB.

[0423] Handling DU's rejection of creating some MRBs

[0424] For the CU message specifying the PTP delivery mode for a UE, the DU can reject the creation or modification of one or more MRBs. In this case, the DU returns an MRB list, which includes the MRBs for which the creation or modification fails, as well as the reason for the failure.

[0425] The CU message can also contain uplink tunnel information corresponding to each of the above MRBs.

[0426] PTM - related requests

[0427] Since this embodiment is based on each MBS signaling, the main difference from Embodiment 1 is that each MBS signaling can carry or not carry any UE information to indicate the operation or configuration of a specific UE, or imply a group of UEs.

[0428] Each PTM delivery instance always corresponds to a specific transmission cell. According to different implementation manners, if a UE receives an MBS session in the connected state, the context of the cell associated with the UE exists on both the CU and DU sides. The transmission cell information can be provided by the CU or the DU. That is, the CU can only provide a UE list including the UE using the PTM mode, and the DU determines the cell or cell list corresponding to the PTM transmission according to the UE connection state or other information, and the delivery instance ID in each cell.

[0429] For example, in one embodiment, based on multiple delivery instances, transmission of a certain MBS session is allowed in a certain cell. In addition, these delivery instances may need to be uniquely specified by combining a cell identifier and a unique identifier in the cell, or characterized by a unique delivery instance ID in the DU. For example, in one embodiment, UE6, UE7, and UE8 may correspond to the first delivery instance in cell 3, while UE9 and UE10 may correspond to the second delivery instance in cell 3.

[0430] The CU also includes the following reception mode description in the request message and indicates the transmission of service data of the MBS session in the PTM mode. The DU response message contains a list of PTM delivery instances for multiple possibilities, and each delivery instance may also be associated with a list of UEIDs.

[0431] In one scenario, in the PTM transmission request, the CU includes a list of UE IDs associated with the PTM delivery mode, and the CU does not specify the cell information or the delivery instance ID in the corresponding cell for PTM transmission for the UE. When receiving the request, the DU generates a corresponding scheduling result (such as which cells in the DU should perform PTM transmission and mapping the cells to the delivery instance IDs) based on each cell to which each UE is connected and the connection status of the UE in each cell. Based on the scheduling result, the DU includes an optional PTM delivery cell or a list of cells in the response message, or alternatively, includes the PTM delivery instance ID corresponding to the PTM delivery cell, and optionally includes a list of UE IDs corresponding to the delivery instance. In addition, the DU also provides scheduling information corresponding to the cell or the delivery instance.

[0432] In one scenario, in the PTM transmission request, the CU includes a list of cells associated with the PTM delivery mode, and each cell in the cell list may be associated with a list of UE IDs. The CU specifies the PTM transmission in the cell. Optionally, the CU provides a list of UE IDs associated with the PTM transmission. When receiving the request, the DU allocates multiple delivery instances associated with the cell based on the list of UE IDs to support the PTM transmission request. Based on the scheduling result, the DU includes an optional PTM delivery cell or a list of cells in the response message, or alternatively, includes the PTM delivery instance ID corresponding to the PTM delivery cell, and optionally includes a list of UE IDs corresponding to the delivery instance. In addition, the DU also provides scheduling information corresponding to the cell or the delivery instance.

[0433] In a scenario, in a PTM transmission request, the CU includes a list of cells associated with the PTM delivery mode, and a list of delivery instance IDs associated with each cell in the cell list. Each delivery instance can also be associated with a list of UE IDs. That is, the CU specifies the cells and delivery instance IDs associated with the PTM transmission. When receiving the request, the DU generates scheduling parameters associated with each delivery instance in each cell based on the connection state of the UE. Based on the scheduling result, the DU includes, in the response message, an optional PTM delivery cell or a list of cells, or alternatively, includes the PTM delivery instance ID corresponding to the PTM delivery cell, and optionally includes a list of UE IDs corresponding to the delivery instance. In addition, the DU also provides scheduling information corresponding to the cell or the delivery instance.

[0434] The above scheduling information includes: the MAC / PHY configuration corresponding to the PTM delivery instance, and may also include the following information or a combination of the following information:

[0435] · DRX information corresponding to this PTM delivery instance

[0436] · Radio Network Temporary Identifier (RNTI) of the PTM delivery instance

[0437] · Time-domain scheduling information corresponding to the PTM delivery instance for indicating the subframe or time slot for scheduling the PTM transmission

[0438] · Frequency-domain resource allocation information corresponding to the PTM delivery instance.

[0439] · PDCCH (Physical Downlink Control Channel) configuration and PDSCH (Physical Downlink Shared Channel) configuration corresponding to this PTM delivery instance.

[0440] · BWP (Bandwidth Part) information corresponding to the PTM delivery instance.

[0441] PTM - related requests, RLC bearer configuration

[0442] For each delivery instance, if the DU accepts the corresponding MRB transmission request in PTM mode and the delivery instance specified by the CU or the DU does not exist, the DU creates a corresponding RLC entity based on information from the CU message such as the PDCP SN. Otherwise, if the PTM delivery instance already exists in the DU, the DU sends the corresponding first RLC bearer configuration to the CU according to the configuration corresponding to the existing delivery instance.

[0443] In some embodiments, if the DU accepts the corresponding MRB transmission request in PTM mode, the DU needs to include in the response message the RLC bearer configuration information corresponding to each MRB of the MBS session, which includes the logical channel ID corresponding to the MRB.

[0444] In some embodiments, for each UE associated with a delivery instance:

[0445] · If the DU accepts the corresponding MRB transmission request in PTM mode, in the first RLC bearer configuration, the DU includes the RLC bearer configuration information corresponding to each MRB in the MBS session, which also includes a first logical channel ID1 (LCID1) and an associated second logical channel ID2 (LCID2). Among them, LCID1 is included in the MAC PDU generated by the DU in the actual PTM delivery, and this LCID1 corresponds to the logical channel information in the sub-header of the MAC PDU corresponding to the MRB service data. After the UE receives the MAC PDU, the UE submits the data marked as LCID1 in the sub-header of the MAC PDU to the logical channel identified by LCID2 for further processing.

[0446] · In some scenarios, the network enables PDCP data retransmission for MRBs in PTM transmission for the UE using a bidirectional tunnel. The UE relies on two independent RLC entities: an RLC entity 1 that performs the initial MRB data transmission in PTM mode, and a UE-specific RLC entity 2 that performs the retransmission of MRB data, as well as the transmission of the PDCP SR corresponding to the MRB.

[0447] · The CU message also indicates the uplink tunnel information corresponding to the MRB, specifically the IP address and the associated GTP-TEID. In some scenarios, the F1-U tunnel is used to transmit the corresponding PDCP SR generated by the UE when receiving MRB data. As Figure 10 shown, tunnel 2 is used for the uplink transmission of the PDCP SR.

[0448] · If the CU enables or activates PDCP retransmission for the MRB, the DU returns the second downlink tunnel information, which includes the IP address and the associated GTP-TEID. Now, on the F1 interface, there are two downlink tunnels corresponding to the MRB. The first downlink tunnel can be used to transmit the initial transmission data corresponding to the MRB, while the second downlink tunnel can be used to transmit the retransmission data corresponding to the MRB and the uplink PDCP SR.

[0449] ·The CU also indicates the mode of the RLC entity corresponding to the MRB, whether it is AM or UM. After the DU accepts the corresponding MRB transmission request in PTM mode, the DU creates or modifies the RLC entity corresponding to the MRB, allocates the corresponding MAC resources such as logical channels, and returns the corresponding second RLC bearer configuration in the response message. The RLC bearer configuration is included in the cell group configuration and is also included in the DU-to-CU RRC information to be sent to the CU.

[0450] Handling DU's rejection of creating MRBs

[0451] For a CU message specifying the PTM delivery mode, the DU creates a PTM delivery instance or a list of PTM delivery instances. For each delivery instance, the DU may reject the creation or modification of one or more MRBs due to resources or other reasons. In this case, the DU returns a list of MRBs that includes the MRBs for which the creation or modification has failed and the reasons for the failure.

[0452] Handling dual - mode using PTP and PTM

[0453] In some embodiments, for a specific UE, the CU may request both PTP and PTM delivery modes simultaneously. The DU allocates the corresponding resources so that the UE can receive MRB data in both PTP and PTM modes simultaneously.

[0454] Example 2 example

[0455] For an exemplary CU decision regarding the UE delivery mode for an MBS session, refer to Figure 4 . Based on the CU decision, UE1 uses the PTP delivery mode, and UE2 to UE5 use the PTM delivery mode. In some scenarios, the CU also decides that some UEs such as UE2 and UE3 use the PTM delivery mode in one cell under the DU, while UE4 and UE5 use the PTM delivery mode in another cell under the DU. The specific signaling may or may not carry the corresponding UE ID list. In some scenarios, the DU can implement multiple PTM delivery instances in a cell based on the interaction with the CU.

[0456] In some scenarios, the CU does not determine in which cell the PTM delivery instance exists, but indicates that a certain UE uses the PTM or PTP mode to receive. At this time, the DU decides how many PTM delivery instances to generate and the associated cells. In some scenarios, the DU can generate multiple PTM delivery instances in one cell.

[0457] In addition, the PDCP PDUs generated for the corresponding PDCP corresponding to the MBS can be delivered to the DU through a shared tunnel or can be delivered to the DU through an independent tunnel.

[0458] The above scenarios are described separately below. The configurations of each UE may not be presented in the same F1 signaling at the same time, because the configurations may be presented in different F1 signaling at different time points.

[0459] After receiving the decision from the CU, the DU schedules MBS reception for each UE and allocates resources for the bearers corresponding to each delivery instance. In case of resource allocation failure, the DU sends feedback with the failure reason to the CU.

[0460] In the context establishment or modification request message sent by the CU, the gNB-CU MBS-AP ID is used to uniquely identify the MBS session on the CU side via the F1 interface. These signaling messages may also carry the MBS session ID such as the IP multicast address or the MBS ID corresponding to the MBS, to notify the DU of the MBS identity.

[0461] In addition, the signaling also carries the QoS parameters corresponding to the MRB or MRB list serving the MBS. Each MRB is identified by an RB ID. The signaling also includes the list of QoS flows mapped to the MRB and the corresponding QoS flow level QoS parameters (including the QoS flow identifier (QFI)).

[0462] The CU may indicate a specific UE or list of UEs in the signaling message to receive a specific one or more MRBs or the entire MBS in PTP mode. The entire MBS indication refers to all the corresponding MRBs associated with it. The list of UEs can be identified on the F1 interface by the gNB-CU UE F1AP ID or gNB-DU UE F1AP ID of the UE.

[0463] The signaling may also carry the RLC entity mode corresponding to the specific MRB for a specific UE, which can be the AM or UM mode. For example, if the QoS requirements corresponding to the MRB of the MBS are not sensitive to latency but require high reliability, the corresponding RLC entity can be configured in the AM mode. On the other hand, if the QoS requirements are sensitive to latency, the corresponding RLC entity can be configured in the UM mode. Refer to Figure 8 and Figure 9 , in some scenarios, for UE1, it is necessary to establish an uplink tunnel shown as tunnel 2 to transmit uplink data, such as feedback information such as PDCP status reports related to MRB data reception generated by UE1. In this case, the signaling may also carry the user plane uplink tunnel address corresponding to the specific MRB for UE1.

[0464] After receiving the CU request, if the DU can allocate the corresponding resources, in the returned response message, the DU returns the downlink tunnel information of the specific MRB for the UE in the above request. Refer to Figure 8 , Tunnel 2 has now been successfully established and can be used to transmit service data corresponding to the bearer transmitted to the UE in PTP mode, and can also be used to transmit PDCP PDU retransmission data for a specific UE.

[0465] In some scenarios, the CU carries the IP multicast address for transmitting the PDCP PDU corresponding to the MRB corresponding to the MBS. After receiving the IP multicast address, the DU joins the multicast group and receives the multicast service data. Refer to Figure 6 and Figure 7 , RLC entity 1, RLC entity 2, and RLC entity 3 are associated with the same MRB and share Tunnel 1, and the service data is submitted to RLC entity 1, RLC entity 2, and RLC entity 3 simultaneously.

[0466] In some scenarios, the DU replies with the downlink tunnel information for the MBS as a response to the above request, so a downlink tunnel from the CU to the DU can be created. The PDCP PDU corresponding to the MRB of the MBS is transmitted to the DU through the downlink tunnel and is simultaneously submitted to all RLC entities associated with the MRB.

[0467] To create a specific PTM delivery instance, there are at least two solutions distinguished by the information in the signaling sent from the CU to the DU. In the first solution, the signaling contains a cell list that includes the cells scheduling the MBS. In the second solution, the signaling contains a UE ID list that includes the UEs assigned to use the PTM mode. Each solution is described in detail below.

[0468] In the first solution, during the CU decision-making process, the CU not only determines the delivery mode of the UE, whether it is PTP or PTM. The CU also determines in which cells under the DU the PTM transmission occurs. Therefore, the CU-to-DU signaling carries a cell list to indicate the PTM transmission. On the DU side, for each cell in the cell list, the DU allocates the corresponding PTM resources for the MBS, or rejects some QoS flows, and thus rejects the creation of the corresponding MRB. In this way, the DU response message contains the MRB creation results for the MBS based on each cell. If the creation of some MRBs fails, the message will return the failed MRBs, as well as the corresponding failure reasons.

[0469] Optionally, if the signaling carries the UE list in PTM mode, the response message from the DU can carry the first logical channel ID (LCID1) (LCID identifies the logical channel) for each UE, which is the main path for the UE to send status reports. In addition, the DU can also carry the second logical channel ID (LCID2), which is the LCID for the UE to receive the MRB of the MBS. For example, LCID1 is associated with LCID2. After the UE receives the MAC PDU, the UE submits the data marked with LCID1 to the logical channel identified by LCID2 for further processing.

[0470] In the second solution, during the CU decision-making process, the decision may not include information about the relevant cells, but only include each UE and its delivery mode. For example, UE2-PTM, UE3-PTM, UE4-PTM, UE5-PTM. On the DU side, the DU looks up the cell to which each UE is connected, and then based on the connection status of the UE in the corresponding cell and the available resources in the cell, the DU flexibly selects appropriate PTM scheduling parameters. For example, the DU decides that on cell 1, UE2 and UE3 use one PTM instance to receive MBS data, and on cell 2, UE4 and UE5 use another PTM instance to receive MBS data. The DU also decides the MAC / PHY configuration for each PTM instance and sends this configuration back to the CU in the response message. In some scenarios, multiple UEs in a cell receive the same MBS. The DU can decide to create multiple PTM instances to serve these UEs. The DU also decides the MAC / PHY configuration for each PTM instance and sends this configuration back to the CU in the response message. In this case, the configuration information can be in list format.

[0471] To meet the QoS requirements of the MBS, in the signaling from the CU to the DU, there are QoS parameters corresponding to each MRB, and QoS parameters of the QoS flow corresponding to the MRB, so that the DU can allocate appropriate resources based on the QoS parameters.

[0472] For a certain MRB, the MRB data is distributed from the CU to the DU through the F1-U tunnel. Depending on how the CU distributes the MRB data, there are two implementation methods for delivering the MRB data.

[0473] In the first case, the CU uses IP multicast to distribute the MRB data to the DU. The signaling from the CU to the DU carries the IP multicast address and the TEID. Then, the DU can join the multicast group and receive the MRB data from the tunnel.

[0474] In the second case, the CU distributes the MRB data to the DU using the Point-to-Point Protocol. In the received signaling message, based on the MBS ID and its corresponding MRB ID or other information that can reflect this information, the DU may be able to reuse the existing tunnel. If there is no existing tunnel for the MRB, the DU will allocate a downlink IP address and the corresponding TEID, and send this downlink tunnel-related information to the CU in the response message. By doing so, for a specific MRB in the MBS session, a single tunnel can be shared by different RLC entities, and there is no need to replicate the PDU data at the PDCP layer.

[0475] Example 3

[0476] In this embodiment, various types of requests and responses related to the PTP delivery instance of a specific UE above can be carried using the signaling message format associated with the UE, while various types of requests and responses related to the PTM delivery instance above can be carried using the signaling message format associated with the MBS.

[0477] If the CU makes a decision that some UEs (Group 1 UEs) receive the MBS in PTP mode, while some UEs (Group 2 UEs) receive the MBS in PTM mode. For Group 1 UEs, the CU uses the F1 signaling according to each UE (or the signaling associated with the UE), such as UE context establishment or UE context modification signaling. For Group 2 UEs, the CU uses the F1 signaling according to each MBS (or the signaling associated with the MBS), such as MBS context establishment or MBS context modification signaling. In either case, the CU will use the corresponding F1 signaling to send this decision to the DU and request the DU to allocate the corresponding resources. The signaling associated with the MBS can be applied to one UE or multiple UEs, or one cell or multiple cells.

[0478] Upon receiving the request from the CU, the DU attempts to allocate resources according to each request. Then, the DU sends response information to the CU to feedback whether each MRB is successfully created. In addition, for each successfully created MRB, the DU creates a configuration for the specific MRB and sends this configuration back to the CU.

[0479] Reference Figure 5 , the signaling messages are usually referred to as MBS context establishment or MBS context modification, and they can also be divided into two operations, namely the F1 message according to each UE and the F1 message according to each MBS. The content included in the above signaling will be described separately below.

[0480] For the group 1 UEs using the PTP reception mode, the CU uses per-UE F1 signaling such as UE context establishment or UE context modification signaling. This disclosure extends the current per-UE signaling and includes at least one parameter in the signaling message initiated from the CU:

[0481] · gNB-CU UE F1AP ID.

[0482] · gNB-DU UE F1AP ID (optional).

[0483] · MBS session ID.

[0484] · A list of MRB IDs that serve the radio bearers for MBS, and optionally, the radio bearer IDs used by the UE during UE-side data processing associated with each MRB in the MRB list.

[0485] · QoS parameters for each MRB, and the corresponding QoS parameters for the QoS flows.

[0486] · RLC bearer mode (AM or UM) corresponding to the MRB.

[0487] · The user plane uplink tunnel address of the UE associated with the MRB. The UE uses the user plane uplink tunnel address to perform MBS status reporting.

[0488] · For each RB serving the multicast service, if IP multicast is used at the transport network layer (i.e., the UDP / IP layer in the GTP-U protocol stack), the corresponding IP multicast address (with or without the source address) and the corresponding TEID.

[0489] · The CU explicitly enables PDCP status reporting and / or PDCP PDU retransmission.

[0490] Correspondingly, this disclosure extends the current per-UE signaling and includes at least one parameter in the signaling message initiated from the DU, which can be a response message or a spontaneous message:

[0491] · gNB-CU UE F1AP ID.

[0492] · gNB-DU UE F1AP ID.

[0493] · MBS session ID.

[0494] · A list of MRBs for which the MRBs have been successfully created or modified.

[0495] · Downlink tunnel information for each MRB.

[0496] ·MRB list for MRB creation or modification failure.

[0497] ·Cell group configuration update for the UE, which can be RRC information from DU to CU.

[0498] Similarly, for group 2 UEs using the PTM delivery mode, the CU uses F1 signaling per MBS such as MBS context establishment or MBS context modification signaling. This disclosure extends the current per-MBS signaling and includes at least one parameter in the signaling message initiated from the CU:

[0499] ·gNB-CU UE F1AP ID.

[0500] ·gNB-DU UE F1AP ID (optional).

[0501] ·MBS session ID.

[0502] ·List of MRB IDs containing the radio bearers serving the MBS.

[0503] ·QoS parameters for each MRB and the corresponding QoS parameters of the QoS flow.

[0504] ·List of cells containing the cells scheduling the MBS. Optionally, a list of corresponding PTM instance IDs for each cell and a list of UE IDs for each PTM instance.

[0505] ·List of UE IDs of UEs using the PTM delivery mode. Optionally, a list of RB IDs and the mapped RB IDs used by the UE for each MRB in the list of RB IDs.

[0506] ·Downlink IP multicast address (which may or may not include the source address) and TEID.

[0507] The UE ID can be the gNB-CU UE F1AP ID or the gNB-DU UE F1AP ID, which is used to uniquely identify the logical connection of the UE within the CU or DU through the F1 interface. The UE ID can also be the UE group index, which can be used to assist subsequent scheduling in the DU, such as the determination of feedback resources.

[0508] Correspondingly, this disclosure extends the current per-MBS signaling and includes at least one parameter in the signaling message initiated from the DU, and these messages can be response messages or autonomous messages:

[0509] ·gNB-CU UE F1AP ID.

[0510] ·gNB-DU UE F1AP ID.

[0511] · MBS session ID.

[0512] · For each UE using the PTM mode, its associated cell or cell list, optionally, the corresponding PTM instance ID for each cell.

[0513] · Cell list, optionally, for each PTM delivery instance in the cell:

[0514] ο List of MRB IDs including the MRBs serving MBS accepted by the DU, and another list of MRBs that are rejected by the DU.

[0515] ο Corresponding MAC / PHY configuration for each MRB.

[0516] · Optionally, feedback configuration for each UE.

[0517] · Optionally, for each accepted MRB, its corresponding F1-U tunnel information includes: downlink IP address and TEID.

[0518] · LCID configuration for each UE.

[0519] Example 3 Exemplary implementation

[0520] In this example, the CU decides that for an MBS group, some UEs use the PTP delivery mode (Group 1 UEs), while some UEs use the PTM delivery mode (Group 2 UEs). The CU uses different types of signaling for different UE groups, that is, signaling based on each UE for Group 1 UEs and signaling based on each MBS for Group 2 UEs.

[0521] The CU first decides that UE1 receives MBS in the PTP mode, then the CU creates the corresponding per-UE F1 signaling and sends this signaling to the DU. The specific process is described as follows. Information elements are listed in both the request message and the response message, and there are detailed explanations.

[0522] gNB - CU UE F1AP ID, optionally, gNB - DU UE F1AP ID

[0523] The per-UE context establishment / modification signaling initiated by the CU is identified by the gNB-CU UE F1AP ID. This ID indicates that the signaling is of the per-UE type, and the target UE receives MBS in the PTP mode. Therefore, the corresponding DU response message carries the gNB-CU UE F1AP ID and the gNB-DU UE F1AP ID, and the gNB-DU UE F1AP ID is used to uniquely identify the UE's logical connection through the F1 interface within the DU.

[0524] In some scenarios, for the MRBs serving MBS, the MRB ID namespace on the network side is independent of the RB ID namespace used by the UE on the UE side for other PDU sessions of the UE. In this way, the MBS session ID combined with the MRB ID can be used to uniquely identify the MRB for this MBS. In some scenarios, the DU can use the aforementioned combination of the MBS session ID and the MRB ID from the F1 signaling to allocate only one downlink tunnel address, which is mapped to only one F1-U tunnel for a specific MRB, thus saving transmission resources between the CU and the DU.

[0525] In some scenarios, for the MRBs serving MBS, the MRB ID namespace on the network side shares the same RB ID namespace used by the UE on the UE side for other PDU sessions of the UE. In this way, the F1 signaling does not need to carry the MBS session ID, and the MRB ID itself can be used to uniquely identify the MRB for this MBS. In some other scenarios, the F1 signaling still needs to carry the MBS session ID, and the DU can use the combination of the MBS session ID and the MRB ID from the F1 signaling to allocate only one downlink tunnel address, which is mapped to a unique F1-U tunnel, thus saving transmission resources between the CU and the DU.

[0526] MRB list containing MRBs to be created or modified

[0527] The MRB list can list all or only some of the MRBs serving MBS. If the F1 signaling indicating UE delivery mode switching is based on each service granularity, the signaling applies to all MRBs for MBS. In this case, the signaling message may carry all MRBs, or only the MBS ID.

[0528] For each MRB in the MRB list, additional information is carried in the message:

[0529] · MRB ID. In some scenarios, the MRB ID (RBID1) of each MRB is associated with the second RBID (RBID 2) used by the UE to process the PDU. Subsequently, when the DU configures the RLC bearer, the DU sets the corresponding serving radio bearer to RBID2.

[0530] · QoS parameters for each MRB, and the corresponding QoS flow level QoS parameters. The DU needs to use these parameters to perform MRB scheduling.

[0531] · Notification control configuration. If the notification control corresponding to the MRB is active, the DU can notify the CU whether the transmission and reception requirements of the MRB are met based on UE feedback or measurement reports, so that the CU can further decide whether a UE delivery mode switch is required.

[0532] · Corresponding RLC mode – Based on the MBS characteristics, the RLC entity associated with the MRB is configured as the AM mode or the UM mode. For example, if the QoS requirements of the corresponding MRB are not sensitive to latency but require high reliability, the corresponding RLC instance can be set to the AM mode; on the other hand, if the QoS requirements of the corresponding RB are time-sensitive, the corresponding RLC instance can be set to the UM mode.

[0533] · UE user plane uplink tunnel address corresponding to the MRB associated with the UE. If the RB is configured to perform PDCP status reporting, the CU needs to allocate this uplink tunnel address so that the peer PDCP instance on the UE side can provide feedback. In this case, the signaling message needs to carry the uplink tunnel address corresponding to the MRB.

[0534] · Downlink tunnel information (IP multicast) - If the MRB is distributed from the CU to the DU using IP multicast, the CU needs to provide the IP multicast address and its corresponding tunnel endpoint ID (TEID) for the MRB and add this information to the F1 signaling message. Then, the DU can join the IP multicast group to receive downlink data.

[0535] In some scenarios, for a specific MRB, multiple UEs receiving the MBS can share the downlink tunnel on the F1-U link, regardless of the UE delivery mode (PTP or PTM). The downlink tunnel is mapped to the same IP multicast address and TEID. In other scenarios, UEs receiving the MRB using the PTP mode and UEs receiving the MRS using the PTM mode use independent downlink tunnels on the F1-U link, and the downlink tunnels are mapped to different IP multicast addresses and TEIDs.

[0536] Now refer to Figure 8 . In some scenarios, the CU explicitly enables PDCP status reporting and / or PDCP PDU retransmission, or the retransmission mechanism is the default setting. The DU needs to return the corresponding downlink tunnel information, i.e., Tunnel 2 as shown in Figure 8 . The DU further creates the corresponding RLC entity 2 configuration and associated LCID information. The logical channel identified by the LCID corresponds to the primary RLC associated with the MRB on the UE side and is used as the primary path for transmitting PDCP status reports for this MRB.

[0537] · Downlink tunnel information (IP point-to-point) - If the DU accepts the creation or modification of an MRB and distributes the MRB from the CU to the DU using the point-to-point protocol, the DU returns the downlink tunnel information corresponding to the MRB. In some scenarios, based on the MBS ID and the corresponding MRB ID in the F1 signaling message sent from the CU, the DU can identify the shared downlink tunnel to serve a specific MRB, thus saving resources on the F1-U link. In this case, the DU can return the information of the existing tunnel (which includes the IP address and TEID).

[0538] Now refer to Figure 8 .. In some scenarios, the CU explicitly enables PDCP status reporting and / or PDCP PDU retransmission, or the retransmission mechanism is the default setting. Then the DU can return the information for two user-plane downlink tunnels (such as Figure 8 the tunnels 1 and 2 shown). Tunnel 1 is used to transmit MRB data and it can be shared by other UEs. Tunnel 2 is used for MRB data retransmission. At the same time, the DU creates the corresponding RLC entity 2 configuration. RLC entity 2 is used to receive PDCP PDUs from the CU and then send the PDU data to UE1 in PTP mode. Or it can be used for PDCP layer data retransmission. The response message from the DU can carry the corresponding logical channel ID (LCID) information, and the LCID identifies the logical channel of the primary RLC that sends the PDCP status report on the UE side. After receiving the PDCP PDU corresponding to the MRB from the shared tunnel 1, the DU submits the MRB data to at least RLC entity 1 and RLC entity 2 to serve different UEs. In some scenarios, the DU only returns the information of one user-plane downlink tunnel, and the initial MRB data transmission and possible retransmissions by the CU occur in this same tunnel.

[0539] If the DU does not accept the MRB, the DU will return in the response message an MRB list containing the MRB for which the creation or modification has failed. In this case, the tunnel information may not be applicable.

[0540] Then, the CU decides that UEs 2 to 10 receive the MBS in PTM mode, creates the corresponding F1 signaling according to each MBS, and sends the signaling to the DU so that the DU can create the MBS session context and allocate the corresponding resources for the PTM instance. The specific process is described as follows. Information elements are listed in both the request message and the response message.

[0541] gNB - CU MBS F1AP ID and gNB - DU MBS F1AP ID

[0542] The CU signaling message carries at least the gNB-CU MBS F1AP ID to uniquely identify the MBS session over the F1 interface within the CU. Similarly, the DU returns the gNB-CU MBS F1AP ID and gNB-DU MBS F1AP ID information in the response message to be used to uniquely identify the MBS session over the F1 interface within the DU.

[0543] (MBS identifier)

[0544] The MBS identifier can be one of the following:

[0545] ·TMGI (Temporary Mobile Group Identity).

[0546] ·IP multicast address (with or without source address).

[0547] ·MBS ID.

[0548] ·Any other identifier or index that can uniquely identify the MBS over the F1 interface.

[0549] In some scenarios, for the MRBs serving the MBS, the MRB ID namespace on the network side is independent of the RB ID namespace used by the UE on the UE side for other PDU sessions of the UE. Therefore, the MBS session ID combined with the MRB ID can be used to uniquely identify the MRB for this MBS. In some scenarios, the DU can use the aforementioned combination of the MBS session ID and the MRB ID from the F1 signaling to allocate only one downlink tunnel address, which is mapped to only one F1-U tunnel for a specific MRB, thus saving transmission resources between the CU and the DU.

[0550] In some scenarios, for a specific MRB, the MRB data transmission from the CU to the DU shares a downlink tunnel. The DU receives the MRB data from the shared tunnel and then submits the data to multiple RLC entities. These RLC entities correspond to different PTP and PTM instances.

[0551] MRB list

[0552] The MRB list contains the MRBs that need to be created or modified. For each MRB in the list, additional information is carried in the message:

[0553] ·MRB ID. In some scenarios, the MRB ID (RBID1) of each MRB is associated with the second RBID (RBID 2) used by the UE to process the PDU. Subsequently, when the DU configures the RLC bearer, the DU sets the corresponding serving radio bearer to RBID2.

[0554] · QoS parameters for each MRB, and the corresponding QoS flow level QoS parameters. The DU needs to use these parameters to perform MRB scheduling.

[0555] · Notification control configuration. If the notification control corresponding to the MRB is active, the DU can notify the CU whether the transmission and reception requirements of the MRB are met based on UE feedback or measurement reports, so that the CU can further decide whether a UE delivery mode switch is required.

[0556] · Corresponding RLC entity mode (optional). For MBS sessions, the default mode is UM.

[0557] · Downlink tunnel information (IP multicast) - If IP multicast is used to distribute the MRB from the CU to the DU, the CU needs to provide the IP multicast address and its corresponding tunnel endpoint ID (TEID) for the MRB and add this information to the F1 signaling message. If the DU accepts the MRB, the DU can join the IP multicast group to receive downlink data.

[0558] Cell information

[0559] There are two solutions for the CU to carry the cell list, and each solution is as follows.

[0560] Solution A:

[0561] The F1 signaling message contains the cell list, which includes the cells for MBS scheduling, optionally, the list of PTM delivery instances under each cell, and optionally, the corresponding UE ID list.

[0562] During the CU decision-making process, the CU not only determines the UE delivery mode, whether it is PTP or PTM, but also determines which cells under the DU the PTM transmission occurs in. Optionally, the PTM delivery instances under the cell. For example, the CU decides that UE1 uses the PTP mode in cell 1, UE2 and UE3 use the PTM mode in cell 1, and UE4 and UE5 use the PTM mode in cell 2. The CU signaling message carries the cell list under the DU. Therefore, after receiving this message, the DU allocates PTM resources for MBS in each cell, or rejects to create or modify some or all MRBs for MBS.

[0563] The DU response message contains the MRB creation results for per-cell based MBS. Optionally, the DU response message carries each PTM delivery instance under each cell and its PTM resource allocation results, which include RLC entity configuration and the corresponding MAC / PHY configuration. If the CU signaling message contains a list of UE IDs, the DU can provide UE-specific RLC entity configuration. If the CU signaling message also contains a list of UE IDs for each PTM delivery instance, optionally, the CU message contains a mapping from each MRB (RBID1) of the MBS to RBID2, where RBID2 is the radio bearer ID used by the UE when processing the PDCP PDU. In addition, in the RLC bearer configuration created by the DU for the UE, the serving radio bearer field in the RLC bearer configuration is set by the DU to RBID2.

[0564] In some scenarios, the CU does not specify the PTM delivery instance ID in the transmission cell, but the DU carries the PTM delivery instance information and an optional associated UE list in the response message. Refer to Figure 4 , the CU decides that UEs 6 to 10 use the PTM mode in cell 3, and the DU further decides that UEs 6, 7, and 8 use PTM delivery instance 3 (PTM3), and UEs 9 and 10 use PTM delivery instance 4 (PTM4).

[0565] Solution B :

[0566] The F1 signaling message contains a list of UE IDs that includes the UEs using the PTM mode.

[0567] The CU message does not specify cell information and only contains the UE IDs and their corresponding delivery modes. For example, refer to Figure 4 , UEs 2 to 10 all receive MBS using the PTM mode. On the DU side, based on the connection state and capabilities of each UE, the DU assigns a PTM delivery cell to the UE. Optionally, the PTM delivery instance in the PTM delivery cell. In some embodiments, based on the connection state context of each UE in each cell and the available resources in each cell, the DU flexibly schedules the PTM scheduling parameters. In this way, the decisions made by the DU are sometimes more effective.

[0568] In some scenarios, the DU can implement multiple PTM delivery instances for UEs in the same MBS group in a cell and allocate corresponding MAC / PHY configurations. The DU sends this configuration to the CU based on each cell, that is, for each cell, the DU returns a list of MAC / PHY configurations. The above scheduling result can be included in the DU-to-CU information and sent to the CU. In some scenarios, the above configuration and the corresponding MRB configuration are broadcast together in the corresponding cell, so the information can be sent to the UE.

[0569] For example, referring to Figure 4 , the DU decides that UE2 and UE3 use the delivery instance PTM1 under cell 1, UE4 and UE5 use the delivery instance PTM2 under cell 2, while (UE6, UE7, UE8) and (UE9, UE10) use different delivery instances PTM3 and PTM4 under cell 3. The DU also selects the MAC / PHY configuration corresponding to each PTM delivery instance, adds this configuration information to the response message, and sends the response message for each cell or each PTM instance in the cell to the CU.

[0570] Based on the UE ID list, then, the DU can provide UE-specific RLC entity configurations, which include RLC bearer configurations. If the CU signaling message also contains the UE ID list for each PTM delivery instance, optionally, the CU message contains the mapping from each MRB (RBID1) of the MBS to RBID2, where RBID2 is the radio bearer ID used by the UE when processing PDCP PDUs. In addition, in the RLC bearer configuration created by the DU for the UE, the serving radio bearer field in the RLC bearer configuration is set by the DU to RBID2.

[0571] If IP multicast is used to distribute the MRB from the CU to the DU, and for different PTP and PTM delivery instances, the MRB transmission shares the same F1-U downlink tunnel, the CU needs to provide the IP multicast address and its corresponding TEID for the MRB and add this information to the F1 signaling message. Then, the DU can join the IP multicast group to receive downlink data.

[0572] If the point-to-point protocol is used to distribute the MRB from the CU to the DU, on the DU side, based on the MBS ID and the corresponding MRB ID in the F1 signaling message, the DU can reuse the pre-established tunnel, including its IP address and TEID information. For a certain MRB in the MBS, different cells or different PTM delivery instances in the same cell can share a single tunnel between the CU and the DU.

[0573] The UE ID in the UE ID list can be the gNB-CU UE F1AP ID or the gNB-DU UE F1AP ID, which is used to uniquely identify the logical connection of the UE through the F1 interface within the CU or DU. The UE ID can also be a UE group index, which can be used to assist the subsequent scheduling of the DU, such as the determination of feedback resources. In some scenarios, the CU message may only contain the UE group index or the UE index. In subsequent radio resource allocation, the DU may use the UE index to uniquely identify the HARQ or CSI-RS feedback resources of the UE.

[0574] In some embodiments, the signaling message according to each UE can be only used to notify the DU that the UE needs to join the MBS group, and the MBS group can be implicitly identified by the service information (such as the MBS session ID) in the message. Subsequent MBS management can be achieved by using the signaling session according to each MBS. Such MBS management includes DRB update and QoS-related information update.

[0575] Throughout the specification and claims, terms may have nuanced meanings indicated or implied by the context in addition to the explicitly defined meanings. Similarly, the phrase "in one embodiment / implementation" used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment / implementation" used herein does not necessarily refer to different embodiments. For example, the claimed subject matter is intended to include combinations of all or part of the exemplary embodiments.

[0576] Generally, terms can be understood at least in part from their usage in context. For example, terms such as "and", "or", or "and / or" used herein can include a variety of meanings, which can at least in part depend on the context in which these terms are used. Generally, "or" if used in an associated list such as A, B, or C is intended to mean A, B, and C in the inclusive sense here, as well as A, B, or C in the exclusive sense here. In addition, the term "one or more" used herein can be used to describe any feature, structure, or property in the singular sense, or can be used to describe a combination of features, structures, or properties in the plural sense (at least in part depending on the context). Similarly, terms such as "a", "an", or "the" can be understood to denote singular or plural usage, at least in part depending on the context. In addition, the term "based on" can be understood to not necessarily convey a set of exclusive factors, but rather, can allow for the existence of other factors that are not necessarily explicitly described, which also at least in part depends on the context.

[0577] References to features, advantages, or similar language throughout this specification do not imply that all features and advantages that can be realized by the solution should or are included in any single embodiment thereof. On the contrary, language referring to features and advantages is understood to mean that a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the solution. Thus, discussions of features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same embodiment.

[0578] In addition, the described features, advantages, and characteristics of the solution may be combined in any suitable manner in one or more embodiments. Based on the description herein, those of ordinary skill in the relevant art will recognize that the solution may be practiced without one or more specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the solution.

Claims

1. A method for wireless resource allocation performed by a first access network node (ANN) communicating with a second ANN in a wireless communication network, the method comprising: Receiving, from the second ANN, one or more requests for establishment, modification, or release of resource allocation in the first ANN for transmitting service data of a multicast / broadcast service (MBS) session to a group of user equipments (UEs) in point-to-point (PTP) delivery mode and point-to-multipoint (PTM) delivery mode, and for transmitting control information between the first ANN and the second ANN, wherein the one or more requests include an MBS session identifier, and wherein the one or more requests further include: A UE identifier indicating the target UE of the request; and A set of radio bearer (RB) identifiers for uniquely identifying, together with the MBS session identifier, a set of RBs of a quality of service (QoS) flow allocated by the second ANN to the MBS session; Based on the one or more requests, establishing the resource allocation in the first ANN.

2. The method according to claim 1, wherein, The one or more requests further include: A first set of QoS parameters corresponding to each RB in the set of RBs; and A second set of QoS parameters for each QoS flow in the QoS flows mapped to the set of RBs.

3. The method according to claim 1, wherein: The one or more requests include a set of information items; and The method further includes, by the first ANN, establishing, modifying, or releasing the resource allocation corresponding to a plurality of delivery instances for transmission of MBS session protocol data units (PDUs) for the MBS session based on the set of information items.

4. The method according to claim 3, wherein Each delivery instance in the plurality of delivery instances is a PTP delivery instance or a PTM delivery instance.

5. The method according to claim 4, wherein The first ANN determines the delivery mode for each UE in the set of UEs, which is PTP delivery mode, PTM delivery mode, or both PTP and PTM delivery modes.

6. The method according to claim 1, further comprising: Determining downlink data tunnel information for receiving PDCP PDUs associated with an RB at the first ANN; Including the downlink data tunnel information in configuration information for transmission to the second ANN; And Receiving, from the second ANN, the PDCP PDUs associated with the RB according to the downlink data tunnel information.

7. The method according to claim 1, wherein The one or more requests further include a retransmission activation indication associated with the UE in the set of UEs and associated with the RB in the set of RBs.

8. The method according to claim 7, further comprising: The first ANN establishing an RLC entity for an RB associated with a PTP instance for a UE, wherein the RLC entity is associated with a first data tunnel for transmitting PDCP PDUs associated with the RB from the second ANN to the first ANN.

9. A network node, comprising a processor and a memory, wherein, The processor is configured to read computer code from the memory to implement the method according to any one of claims 1 to 8.

10. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 8.

Images