Access network signaling and resource allocation for multicast / broadcast sessions - Patents.com

Abstract

This disclosure describes an architecture for supporting MBS sessions in a wireless access network. Each such MBS session is flexibly and dynamically distributed by the access network into one or more point-to-point (PTP or unicast) and point-to-multipoint (PTM or multicast) distribution instances. Thus, a subset of UEs participating in the MBS session can be configured to receive the MBS session in a PTP-like manner and quality. The architecture further enables access network-level switching of one or more UEs participating in the MBS session between PTP mode and PTM mode. Such switching is effected dynamically without application layer involvement.

Description

[Technical Field]

[0001] The present disclosure is directed generally to multicast / broadcast service (MBS) session context management and resource allocation in wireless communication networks, and specifically 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 technology]

[0002] There has always been a demand for multicast broadcast services (MBS) in wireless communication networks. Such services have gradually expanded from the early days of television-like terrestrial video broadcasting services to public safety, vehicle-to-everything (V2X), Internet of Things (IoT), and other application areas. Flexible and dynamic resource allocation and signaling mechanisms are desirable 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 [Means for solving the problem]

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

[0004] In some example implementations, a method for radio resource allocation, implemented by a first access network node (ANN) communicating with a second ANN in a wireless communication network, is disclosed. The method may include receiving one or more requests for establishing, modifying, or releasing a resource allocation at the first ANN from the second ANN for transmitting service data of a multicast / broadcast service (MBS) session to a set of user equipments (UEs) in a point-to-point (PTP) distribution mode and a point-to-multipoint (PTM) distribution mode, the one or more requests comprising an MBS session identifier; establishing, modifying, or releasing the resource allocation at the first ANN based on the one or more requests; generating configuration information corresponding to the resource allocation; and transmitting the configuration information to the second ANN. The present invention provides, for example, the following. (Item 1) 1. A method for radio resource allocation performed by a first access network node (ANN) in communication with a second ANN in a wireless communication network, comprising: receiving one or more requests for establishing, modifying, or releasing a resource allocation in a first multicast / broadcast service (MBS) session from a second ANN for transmitting service data of the MBS session to a set of user equipments (UEs) in a point-to-point (PTP) distribution mode and a point-to-multipoint (PTM) distribution mode, and for communicating control information between the first ANN and the second ANN, wherein the one or more requests comprise an MBS session identifier; establishing, modifying, or releasing the resource allocation in the first ANN based on the one or more requests; generating configuration information corresponding to the resource allocation; transmitting said configuration information to said second ANN; A method comprising: (Item 2) The MBS session identifier used to identify one or more sets of MBSs is: a session identifier associated with the MBS session; an IP multicast address with a source address, IP multicast addresses without a source address, a first interface identifier generated at the first ANN for identifying the MBS session to the second ANN; a second interface identifier generated at the second ANN for identifying the MBS session to the first ANN; a Temporary Mobile Group Identity (TMGI) for the MBS session; or an identifier that uniquely identifies the MBS session within the first ANN, the second ANN, or a public land mobile network (PLMN); Item 1, the method comprising at least one of: (Item 3) At least one of the requests further comprises a first interface identifier generated by the second ANN to identify the MBS session to the second ANN; the configuration information comprises a second interface identifier generated by the first ANN corresponding to the first interface identifier to identify the MBS session to the first ANN; The method according to item 1. (Item 4) Item 10. The method of item 1, wherein one of the requests further comprises a UE identifier to indicate a target UE of the request. (Item 5) The UE identifier is a first interface identifier generated at the first ANN for identifying the target UE to the second ANN; a second interface identifier generated at the second ANN to identify the target UE to the first ANN; a Cell Radio Network Temporary Identifier (C-RNTI); and a wireless area network user identifier; an identifier that uniquely identifies the target user within the first ANN, the second ANN, or a public land mobile network (PLMN); Item 5. The method of item 4, comprising at least one of: (Item 6) Item 1, wherein the one or more requests further comprise MBS-related UE capability information for at least one of the set of UEs. (Item 7) Item 10. The method of item 1, wherein the one or more requests further comprise MBS-related capability requirement information for the MBS session. (Item 8) Item 1. The method of item 1, wherein the one or more requests further comprise a set of radio bearer (RB) identifiers for uniquely identifying, together with the MBS session identifier, a set of RBs allocated by the second ANN to a Quality of Service (QoS) flow of the MBS session. (Item 9) 9. The method of claim 8, wherein the one or more requests further comprise a distinct UE-specific RB identifier for at least one of the set of RBs for at least one specific UE of the set of UEs. (Item 10) 10. The method of claim 9, further comprising including the distinct UE-specific RB identifier in a configuration of a radio link control (RLC) bearer allocated to the at least one specific UE in the first ANN, wherein the configuration information transmitted by the first ANN to the second ANN comprises the configuration of the RLC bearer. (Item 11) The one or more claims further comprise: a first set of QoS parameters corresponding to each RB in the set of RBs; a second set of QoS parameters for each of the QoS flows that are mapped to the set of RBs; and Item 9. The method of item 8, comprising: (Item 12) the at least one or more requests comprise a set of information items; The method further includes establishing, modifying, or releasing, by the first ANN, the resource allocation corresponding to a plurality of delivery instances for transmission of MBS session protocol data units (PDUs) of the MBS session based on the set of information items. The method according to item 8. (Item 13) each of the plurality of delivery instances is either a PTP delivery instance or a PTM delivery instance; Each PTP delivery instance corresponds to a single specific UE that receives the MBS session PDU in the PTP delivery mode; Each PTM delivery instance corresponds to a group of UEs in the set of UEs that receive the MBS session PDU in the PTM delivery mode. Item 13. The method according to item 12. (Item 14) Item 14. The method according to item 13, wherein for each set of UEs, the distribution mode, which is either the PTP distribution mode, the PTM distribution mode, or both PTP and PTM distribution modes, is determined by the second ANN. (Item 15) the set of information items comprising a UE identifier of a UE from the set of UEs and a delivery mode indication for the UE; The method includes establishing a resource allocation for a PTP or PTM delivery instance or modifying an existing PTP or PTM delivery instance corresponding to the UE according to the delivery mode indication. Item 15. The method according to item 14. (Item 16) determining, by the first ANN, a number of PTM delivery instances within one or more serving cells of the UE; When the delivery mode indication indicates that the UE should receive the MBS session PDU in the PTM delivery mode, establishing a PTM delivery instance as one of the number of PTM delivery instances with resource allocation for the UE; further comprising Item 16. The method of item 15, wherein the configuration information further comprises distribution instance configuration information for the UE. (Item 17) Item 16. The method of item 15, wherein the configuration information transmitted by the first ANN to the second ANN comprises information of the PTP or PTM distribution instance established for the UE. (Item 18) the set of information items comprises a cell identity of a serving cell of the first ANN; The method comprises: determining a number of PTM distribution instances associated with the serving cell; and establishing a resource allocation for the number of PTM distribution instances associated with the serving cell; Including, The configuration information further comprises information about the PTM delivery instance. Item 15. The method according to item 14. (Item 19) the set of information items further comprises, in addition to the cell identification, a UE list; The configuration information further comprises UE sublists of the UE list, each UE sublist relating to one of the number of PTM delivery instances. Item 19. The method according to item 18. (Item 20) the set of information items comprises a cell identity of a serving cell of the first ANN and a definition of one or more PTM instances associated with the serving cell; the method includes establishing the resource allocation for the one or more PTM delivery instances associated with the serving cell. Item 15. The method according to item 14. (Item 21) the set of information items further comprises, in addition to the cell identification, a UE list; The configuration information further comprises UE sub-lists of the UE list, each UE sub-list relating to one of the one or more PTM delivery instances. Item 20. The method according to item 20. (Item 22) the set of information items further comprises a UE sub-list in addition to a definition of the one or more PTM instances associated with the cell identity; the configuration information further comprises UE sub-lists of the UE list, each UE sub-list corresponding to one of the one or more PTM delivery instances. Item 20. The method according to item 20. (Item 23) Item 14. The method according to item 13, wherein for each set of UEs, the distribution mode, which is either the PTP distribution mode, the PTM distribution mode, or both PTP and PTM distribution modes, is determined by the first ANN. (Item 24) 24. The method of claim 23, wherein the set of information items comprises information about the set of UEs. (Item 25) The method further comprises: determining a delivery mode of PTP or PTM or both for each set of UEs; determining a PTM distribution instance configuration between serving cells of the first ANN; Establishing resource allocation for a PTP delivery instance for each UE in the PTP delivery mode and for a PTM delivery instance according to the PTM delivery instance configuration for each subset of UEs in the PTM delivery mode; Including, 25. The method of claim 24, wherein the configuration information comprises association information between the set of UEs and the PTP and PTM distribution instances and configurations for the PTP and PTM distribution instances. (Item 26) Item 14. The method of item 13, wherein each PTP or PTM delivery instance is associated with a delivery instance identification. (Item 27) 27. The method of claim 26, wherein the identifier of the specific UE is used to identify a PTP distribution instance. (Item 28) PTM distribution instances are When the PTM distribution instance is the only PTM distribution instance in a cell, a cell identifier of the cell; When a cell is associated with multiple PTM distribution instances, a cell identifier of the cell together with a PTM distribution instance index of the PTM distribution instance in the cell; or a PTM delivery instance ID that uniquely identifies the PTM delivery instance within the first ANN or within an interface between the first ANN and the second ANN for the MBS session; 27. The method of claim 26, wherein the instance identifier is associated with an instance identifier comprising one of: (Item 29) For each PTP or PTM distribution instance, allocating a set of radio link control (RLC) bearers corresponding to one or more RBs of the set of RBs; allocating a set of F1-U user plane tunnels corresponding to one or more RBs of the set of RBs; Allocating a set of MAC / PHY layer resources; Item 14. The method according to Item 13, comprising: (Item 30) a logical channel associated with the RLC bearer for a particular RB of a PTM delivery instance is associated with a first logical channel identification (LCID) and a second LCID; the first LCID is specific to a UE; The second LCID is common to a group of UEs of the PTM delivery instance and is included in a subheader of a MAC PDU generated from the logical channel. Item 29. The method according to item 29. (Item 31) At least one of the PTM delivery instances is further associated with at least one additional RLC bearer for a particular UE and a particular RB associated with the at least one PTM delivery instance; The additional RLC bearer receiving a PDCP status report for the particular RB from the UE; or retransmitting the specific RB data to the specific UE. allocated by the first ANN for at least one of Item 29. The method according to item 29. (Item 32) The method of item 31 further includes determining, by the first ANN, a second downlink data tunnel associated with the additional RLC bearer in addition to a first downlink tunnel associated with the particular RB in at least one of the PTM distribution instances. (Item 33) At least one of the PTP distribution instances comprises an RLC entity associated with an RLC bearer for RBs corresponding to a first data tunnel and a second data tunnel; the first data tunnel is configured to transmit PDCP PDUs associated with the RB to the RLC entity; the second data tunnel is configured to retransmit the PDCP PDU associated with the RB to the RLC entity. Item 29. The method according to item 29. (Item 34) Item 34. The method of item 33, wherein the second data tunnel is further configured to transmit a UE uplink PDCP status report for the RB. (Item 35) the configuration information further comprises a configuration of the set of MAC / PHY resources for the PTM delivery instance; The MAC / PHY resource configuration for a PTM delivery instance comprises: DRX information corresponding to the PTM distribution instance; a Radio Network Temporary Identifier (RNTI) for the PTM distribution instance; time domain scheduling information corresponding to the PTM delivery instance to indicate a subframe or time slot in which transmission of the PTM delivery instance is scheduled; frequency domain resource allocation information corresponding to the PTM distribution instance; A PDCCH (Physical Downlink Control Channel) configuration and a PDSCH (Physical Downlink Shared Channel) configuration corresponding to the PTM distribution instance; or BWP (Bandwidth Portion) information corresponding to the PTM distribution instance comprising at least one of: Item 29. The method according to item 29. (Item 36) Item 14. The method of item 13, wherein a delivery instance of the plurality of delivery instances corresponds to a resource allocation for all transmissions of a set of RBs of the MBS session. (Item 37) Item 14. The method of item 13, wherein a delivery instance of the plurality of delivery instances corresponds to a resource allocation for transmission of a subset of the set of RBs. (Item 38) the first ANN fails to set or modify resource allocation for another subset of RBs of a delivery instance of the MBS session; The configuration information includes a list of another subset of the RBs that indicates a failure of the setting or modification and a corresponding failure cause. Item 37. The method according to item 37. (Item 39) Item 14. The method according to item 13, wherein a distribution instance corresponds to one downlink data tunnel for transmitting data of each RB associated with the distribution instance from the second ANN to the first ANN. (Item 40) Item 14. The method of item 13, wherein at least two distribution instances share user plane resources for transmitting data flows belonging to the same RB from the second ANN to the first ANN. (Item 41) Item 14. The method according to item 13, wherein each of the plurality of distribution instances uses independent user plane resources to transmit data flows belonging to the same RB from the second ANN to the first ANN. (Item 42) Item 14. The method of item 13, further comprising releasing resources in the resource allocation of all or a list of RBs associated with the delivery instance that are not shared by other delivery instances. (Item 43) Item 14. The method of item 13, further comprising releasing resources in the resource allocation of all or a list of RBs associated with the UE that are not shared by other UEs. (Item 44) Item 14. The method of item 13, further comprising releasing resources in the resource allocation of all or a list of RBs associated with the cell that are not shared by other cells. (Item 45) determining downlink data tunnel information for receiving PDCP PDUs associated with RBs at the first ANN; including the downlink data tunnel information in the configuration information for transmission to the second ANN; receiving the PDCP PDU associated with the RB from the second ANN according to the downlink data tunnel information; Item 9. The method of item 8, further comprising: (Item 46) 9. The method of claim 8, wherein one of the requests further comprises a retransmission activation indication associated with a UE of the set of UEs and associated with an RB of the set of RBs. (Item 47) establishing an RLC entity for an RB associated with a PTP instance for a UE by the first ANN, the RLC entity being associated with a first data tunnel for transmitting PDCP PDUs associated with the RB from the second ANN to the first ANN; performing retransmission of the RB to the UE using the same RLC entity for retransmission of the PDCP PDU associated with the RB from the second ANN to the first ANN; Item 47. The method of item 46, further comprising: (Item 48) Performing retransmission of the RB includes: establishing a second data tunnel between the second ANN and the first ANN; transmitting the configuration information including the second data tunnel information to the second ANN; receiving the retransmitted PDCP PDU from the second data tunnel; submitting the received PDCP PDU from the second data tunnel to the RLC entity; Item 48. The method according to Item 47, comprising: (Item 49) Item 49. The method of item 48, further comprising transmitting a PDCP status report of the UE using the second data tunnel. (Item 50) The method further comprises: Item 48. The method of item 47, comprising receiving the PDCP PDU associated with the RB from the second ANN using the first data tunnel for both transmission and retransmission of the PDCP PDU associated with the RB for the UE when the first data tunnel is not shared with other UEs. (Item 51) 51. The method of claim 50, further comprising transmitting, by the first ANN, a PDCP status report associated with the RB for the UE to the second ANN using the first data tunnel. (Item 52) the retransmission activation indication indicates that retransmission of the RB for the UE is enabled; The method further includes, when the UE determines that it is configured to receive the RB in the PTM delivery mode, exclusively establishing a separate RLC bearer for the UE and the RB for retransmission; the configuration information comprises information of the separate RLC bearers. Item 47. The method according to item 46. (Item 53) the separate RLC entity receives MBS session data associated with the RB from the second ANN using a second data tunnel for the retransmission; the second data tunnel is different from the first data tunnel for receiving the MBS session data associated with the RB with respect to the original transmission; the configuration information further comprises information regarding the second data tunnel. Item 53. The method according to item 52. (Item 54) one of the requests further comprising downlink data tunnel information of a data tunnel for forwarding MBS session data associated with the RB by the second ANN to a plurality of ANNs via IP multicast; The method further comprises: receiving the MBS session data associated with the RB by the first ANN by joining IP multicast of the MBS session data associated with the RB from the data tunnel based on the downlink data tunnel information; delivering the received MBS session data associated with the RB to one or more RLC entities corresponding to the RB; Item 9. The method according to item 8, comprising: (Item 55) Item 55. The method of item 54, wherein the downlink data tunnel information comprises an IP multicast address and / or a source IP address and a tunnel endpoint identifier for identifying the downlink data tunnel. (Item 56) one of the requests further comprising uplink data tunnel information regarding an uplink data tunnel associated with the RB and the UE; The method further includes transmitting, by the first ANN, a PDCP status report for an RB from the UE to the second ANN via the uplink data tunnel according to the uplink data tunnel information. The method according to item 8. (Item 57) Item 10. The method of item 1, further comprising modifying the resource allocation in the first ANN upon initiation of the first ANN. (Item 58) A network node comprising a processor and a memory, the processor configured to read computer code from the memory and to implement the method according to any one of items 1-57. (Item 59) 58. A computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of items 1-57. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 illustrates an exemplary wireless communication network architecture.

[0006] [Figure 2] FIG. 2 shows exemplary protocol stacks for the control plane and user plane in a central radio access network node (ANN) and in a distributed radio access network node.

[0007] [Figure 3] FIG. 3 shows exemplary resource allocation and data paths through different layers and network entities for delivering an MBS to a group of UEs served by different cells in point-to-point (PTP) and point-to-multipoint (PTM) delivery modes.

[0008] [Figure 4] FIG. 4 illustrates an example serving cell configuration and attributes of distribution modes and distribution instances between various UEs within the serving cell.

[0009] [Figure 5]FIG. 5 shows an example signaling flow for managing MBS context and resource allocation by the central unit ANN and the distributed unit ANN.

[0010] [Figure 6] FIG. 6 shows an exemplary data tunnel configuration for transmitting PDCP PDUs from a CU to a DU.

[0011] [Figure 7] FIG. 7 shows another exemplary data tunnel configuration for transmitting PDCP PDUs from a CU to a DU.

[0012] [Figure 8] FIG. 8 shows another exemplary data tunnel configuration for transmitting and retransmitting PDCP PDUs from a CU to a DU and transmitting UE PDCP status reports from a DU to a CU.

[0013] [Figure 9] FIG. 9 shows another exemplary data tunnel configuration for transmitting and retransmitting PDCP PDUs from a CU to a DU and transmitting UE PDCP status reports from a DU to a CU.

[0014] [Figure 10] FIG. 10 shows another exemplary data tunnel configuration for transmitting and retransmitting PDCP PDUs from a CU to a DU and transmitting UE PDCP status reports from a DU to a CU.

[0015] [Figure 11] FIG. 11 illustrates an exemplary option for a user plane architecture for a distribution instance.

[0016] [Figure 12] FIG. 12 illustrates another exemplary option for a user plane architecture for a distribution instance.

[0017] [Figure 13] FIG. 13 illustrates some further exemplary options for user plane architecture for a distribution instance. DETAILED DESCRIPTION OF THE INVENTION

[0018] Detailed Description The following description and drawings detail certain illustrative implementations of the present disclosure, illustrating some exemplary ways in which various principles of the present disclosure may be implemented. However, the illustrated examples do not exhaust 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 when considered in conjunction with the drawings. Introduction

[0019] Multicast Broadcast Services (MBS) have been provided to some extent in wireless systems. One such example includes the evolved Multimedia Broadcast Multicast Service (eMBMS) technology architecture in 4G wireless communication systems. However, various limitations of eMBMS technology have restricted the expansion of cellular broadcast services from traditional terrestrial video broadcast applications such as television to application scenarios including, but not limited to, public safety, vehicle-to-everything (V2X), the Internet of Things (IoT), and the like. In particular, traditional eMBMS broadcast network architectures are essentially designed for quasi-static video service distribution. For example, delivery of LTE eMBMS over the air interface relies on no or very limited feedback from the UE. Therefore, the network can only understand users' reception interest and reception quality of the MBS to a very limited extent. As a result, such network architectures are unable to provide flexible and dynamic resource allocation and scheduling of MBS, thereby leading to inefficient use of air interface resources.

[0020] Single-cell point-to-multipoint (SC-PTM) technology has been introduced to improve the flexibility of air interface scheduling to some extent. However, SC-PTM technology essentially relies on the same foundation of the previous network architecture of SC-PTM technology and simply adds an air interface data-bearing mechanism based on independent scheduling in a single cell. For example, instead of using a physical multicast channel in traditional eMBMS, SC-PTM technology instead uses a PDSCH (Physical Downlink Shared Channel), which is more consistent with unicast data. Despite such improvements, SC-PTM technology still cannot solve problems related to, for example, the quasi-static nature of broadcast area configuration at the architectural level. Furthermore, SC-PTM as a network-side technology is not properly integrated with the flexible and powerful air interface in the existing 3GPP framework. Therefore, it may be difficult to achieve efficient utilization of communication resources and ensure service reliability and continuity.

[0021] In particular, when its reception quality is downgraded or improved, a UE receiving MBS session data may need to switch from a point-to-multipoint delivery mode to a point-to-point delivery mode (or vice versa). Based on current LTE multicast broadcast technologies, such as eMBMS described above, such UEs can only switch between unicast and broadcast through the application layer. As a result, long switching delays and potential service interruptions may occur. Such delays and interruptions may be unacceptable in time-sensitive multicast broadcast services, such as MCPTT (Mission Critical Push-to-Talk) for public safety applications.

[0022] The following various implementations describe an architecture for supporting MBS sessions in a wireless access network. Each such MBS session is flexibly and dynamically delivered by the access network with one or more point-to-point (PTP or unicast) and point-to-multipoint (PTM or multicast) delivery instances. Accordingly, a subset of UEs participating in the MBS may be configured to receive MBS session data in a PTP manner. The architecture further enables access network-level switching of one or more UEs participating in an MBS session between PTP mode and PTM mode. Such switching is effected dynamically without application layer involvement. Resource allocation and configuration for the PTP and PTM delivery instances may be performed cooperatively in the access network between a central unit (CU) and one or more distributed units (DUs). Such cooperative resource allocation and configuration may be effected using a novel architecture for signaling messages between the CU and DU. Wireless Communication Network Architecture

[0023] FIG. 1 illustrates an exemplary wireless communication network 100 including a user equipment (UE) and a carrier network. For example, the carrier network may further 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 backhauled to the core network 110. For example, the radio ANN 120 may further include multiple separate ANNs in the form of a central unit (CU) 122 and at least one distributed unit (DU) 124 and 126. The CU 122 is connected with DU1 124 and DU2 126 via various F1 interfaces. For example, the F1 interfaces may further include an F1-C interface and an F1-U interface used to carry control plane data and user plane data, respectively. The UE may be connected to the carrier network via the ANN 120 via an air interface. UEs may be served by at least one cell. In the example of FIG. 1 , UE1, UE2, and UE3 are served by DU1's cell 1 130, while UE4 and UE5 are served by DU1's cell 2 132. UEs may include both mobile and fixed network devices. For example, UEs may include, but are not limited to, mobile phones, laptop computers, tablets, personal digital assistants, wearable devices, distributed remote sensor devices, vehicle onboard communication equipment, roadside communication equipment, and desktop computers. While FIG. 1 and various implementations described below are provided in the context of a 5G cellular wireless network, the underlying principles described herein are applicable to other types of wireless access networks, including, but not limited to, Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

[0024] 2 illustrates an exemplary protocol stack implementation 200 of the F1 interface between the CU 122 and the DU 124. The control planes of the CU and DU are connected by the F1-C interface. The user planes of the CU and DU are connected by 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.

[0025] In particular, the functionality of a radio access network node may be divided between a CU and a 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 DUs, along with the lower layers of the network, may be responsible for allocating resources autonomously or under control by the CU. In some embodiments, a CU may be associated with and control multiple DUs.

[0026] In some embodiments, the CU is a gNB central unit (gNB-CU) and the DU is a gNB distributed unit (gNB-DU).

[0027] The signaling protocol between the CU and DU is referred to as the F1 Application Protocol (F1AP). The corresponding signaling may be divided into two categories: non-UE-associated and UE-associated. Such signaling may be implemented as various procedures used to support CU and DU interactions. For example, the context setup procedure may represent a UE-associated procedure used to establish a UE context, including the DRB configuration for the UE. For another example, the gNB-CU Configuration Update procedure and the gNB-DU Configuration Update procedure are non-UE-associated procedures used to update application-level configuration data required for the CU and DU to properly interoperate over the F1 interface. Notably, these F1AP procedures may be invoked in a flexible manner, either independently or in combination. Each of these procedures may be associated with at least one signaling message, which may or may not trigger a response message.

[0028] In the user plane, the F1-U link may be implemented, for example, based on the GPRS Tunneling Protocol over UDP (GTP-U) and may be used to carry user data in units of PDCP protocol data units (PDUs), as shown in FIG. 2. Data may be transmitted from a CU to a DU (downlink) or from a DU to a CU (uplink). When a CU is connected to and controls multiple DUs, downlink data communication from the CU to the multiple DUs may be based, for example, on the GTP-U protocol and carried in IP multicast or IP point-to-point tunnels. For DUs participating in IP multicast from a CU, information for identifying the IP multicast tunnel, including, for example, an IP multicast address and a tunnel identifier (e.g., a tunnel endpoint identifier (TEID)), may be provided from the CU to the DU via the F1-C interface. For IP point-to-point communication from a CU to a DU, the destination IP address and tunnel identifier may be provided by the DU to the CU again via the F1-C link for the CU to transmit data to the DU. The data tunnel between the CU and the DU may be bidirectional. In other words, a single tunnel may support both downlink and uplink data transmission. Access network level implementation of MBS in PTP and PTM modes

[0029] The wireless communication network may be configured to provide a multicast / broadcast service (MBS) to at least one UE. To establish an MBS session, the core network transmits session management related content to the access network, where the session management related content includes context related to the MBS, such as:

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

[0031] If the MBS session is a multicast session, a UE list of UEs associated with (or targeted by) the multicast session. For example, the UE list may include identifiers of a set of UEs associated with the access network that have applied for and are enabled to receive the multicast service. Optionally, a multicast area list may be included if required. The multicast area list may be provided in the form of a list of multicast area indexes or in the form of a list of cells. Each multicast area index may further be mapped to a cell list.

[0032] If the MBS session is a broadcast session, a broadcast area list. For example, the broadcast area list may be provided in the form of a list of broadcast area indexes or in the form of a list of cells. Each broadcast area index may be further mapped to a cell list. The mapping relationship may be implemented by interaction between the core network and the radio access network, or it may be determined autonomously by the radio access network.

[0033] After receiving the MBS session context information from the core network, the access network further allocates various communication resources to implement transmission or delivery of MBS session data from the access network to the UE and, if needed, to receive various status reports from the UE. Such transmission of MBS session data may be performed at the QoS granularity of the radio bearer. Correspondingly, various communication resources may be allocated per radio bearer. In this disclosure, the term multicast / broadcast radio bearer (MRB) is used to refer to a radio bearer serving an MBS session. An MRB may alternatively be referred to as a radio bearer (RB). Each MRB is associated with its own QoS parameters.

[0034] Based on the MBS context information, the access network maps each QoS flow of the MBS with a set of QoS flow parameters to a corresponding MRB having QoS parameters that meet the QoS requirements of the QoS flow according to predetermined or dynamically configurable criteria. In some implementations, multiple QoS flows may be mapped to one MRB. The access network may further determine UE-specific delivery modes of the various MRBs to each UE participating in the multicast / broadcast service session over the air interface. Such delivery modes may include, for example, a PTP delivery mode or a PTM delivery mode.

[0035] In the PTP delivery mode, the QoS flow of an MBS session mapped to an MRB is transmitted from the access network to a specific UE using communication resources allocated for that specific UE. A UE in the PTP delivery mode therefore uses independent resource allocation to receive the MBS in a unicast manner. In the PTM delivery mode, the data flow of an MBS mapped to an MRB is transmitted from the access network to a group of UEs (referred to as a PTM UE group) using communication resources allocated to and shared by a PTM UE group. In some implementations, the set of UEs receiving MBS session data is divided into a subset of UEs 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 may be further divided into multiple PTM UE groups. Each PTM UE group may be allocated communication resources separate from other PTM groups.

[0036] In some implementations, one specific UE may receive MBS session data in PTP mode and be dynamically switched to PTM mode, or vice versa. In some implementations, one specific UE may receive MBS session data in both PTP mode and PTM mode.

[0037] The service data of an MBS session is referred to as MBS session data in some implementations, and alternatively as MBS session packet data units (PDUs) in other implementations. PTP and PTM Delivery Instances

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

[0039] Such an implementation branches the 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 may be provided to some of the UEs with point-to-point or unicast-like quality characteristics.

[0040] The decision of the delivery mode for each UE may be made by the access network based on UE information that may be obtained from the wireless communication network. As will be explained in more detail below, such a decision may be made by either the CU or DU of the access network. The corresponding resource allocation for the various PTP or PTM delivery instances may be performed by the DU and / or CU. Some of the resources, in particular the user plane downlink data tunnel for transmitting or retransmitting MBS data flows from the CU to the DU or the uplink data tunnel for transmitting UE reports from the DU to the CU, may be shared between different delivery instances in various manners in some circumstances, as will be explained in more detail below.

[0041] In the context of a functional division between a CU and a DU as shown in the example access network of Figures 1 and 2, the communication resource allocation to support various PTP and PTM distribution instances may include resources allocated in various air interface protocol stacks of the CU and DU, and F1-U resources between the CU and DU.

[0042] In summary, a distribution instance for an MBS session in a radio access network corresponds to a resource set and associated configuration for distributing MBS session data. Such resources may include, for example, a Service Data Adaptation Protocol (SDAP) entity, a Packet Data Convergence Protocol (PDCP) entity, an F1-U instance, a Radio Link Control (RLC) entity, and MAC / PHY resources. In some example implementations, the PTP or PTM distribution instance described above may be associated with one or more of the following characteristics:

[0043] Identification (ID) for a delivery instance. For an MBS session, the delivery instance ID may be unique within a PLMN (Public Land Mobile Network), or within a CU, or within a DU, or within a cell. The delivery instance ID may uniquely identify a delivery instance and its associated characteristics.

[0044] A delivery mode, including either a PTP delivery mode or a PTM delivery mode. Again, a delivery instance using a PTP delivery mode may be referred to as a PTP delivery instance, while a delivery instance using a PTM delivery mode may be referred to as a PTM delivery instance. An identifier for a particular UE may be used to identify the PTP delivery instance. The instance identifier for a PTM delivery instance may be:

[0045] the cell identifier of the cell when the PTM delivery instance is the only PTM delivery instance in the cell for the MBS session,

[0046] When a cell is associated with multiple PTM delivery instances for the MBS session, the cell identifier of the cell together with the PTM delivery instance index of the PTM delivery instance in the cell, or

[0047] A PTM delivery instance ID that uniquely identifies the PTM delivery instance within the DU or F1 interface for the MBS session. Conversely, in some embodiments, given the instance ID of the PTM delivery instance, which is unique in the cell, the identity of the cell can be derived.

[0048] Each delivery instance may be associated with one or more MRBs of an MBS session. For example, a delivery instance may be associated with all of the MRBs of an MBS session. In another embodiment, a delivery instance may be associated with a subset of the MRBs of an MBS session.

[0049] For each MRB associated with a distribution instance, there is at least one first F1-U data tunnel used to transport MRB data (e.g., PDCP PDUs or PDCP protocol data units) between the CU and the DU. Such a first F1-U data tunnel may be shared by multiple distribution instances for the same MRB. In some implementations, all distribution instances associated with the same DU may share the same first F1-U data tunnel for a particular MRB. In some other implementations, each distribution instance may be allocated an independent first F1-U data tunnel for a particular MRB. In yet some other implementations, some distribution instances may use independent first F1-U data tunnels, while other distribution instances may share the first F1-U data tunnel in one or more groups of distribution instances for a particular MRB. For example, for a particular MRB, each PTP distribution instance may use an independent first F1-U data tunnel, while other PTM distribution instances may share the first F1-U data tunnel. In some implementations, higher priority may be given in resource allocation to a PTP distribution instance that is to be provided with an independent first F1-U data tunnel than a PTM distribution instance.

[0050] An MRB in either a PTP or PTM delivery instance may be associated with a second F1-U data tunnel to transport PDCP PDUs of the MRB from the CU to the DU for UE-specific retransmission of MRB data to a specific UE (either the target UE for a PTP delivery instance or a specific UE of a PTM UE group for a PTM delivery instance). Similarly, a specific MRB may be associated with multiple second F1-U tunnels, each to one of the UEs in the PTM UE group, for UE-specific PDCP PDU retransmissions of the specific MRB.

[0051] The above-mentioned first F1-U data tunnel for data transmission and the above-mentioned second F1-U data tunnel for retransmission for a specific MRB in a specific PTP distribution instance may be shared when such shared data tunnel is used exclusively for a specific PTP distribution instance and is not further shared with other distribution instances.

[0052] The above-mentioned second F1-U data tunnel for retransmission of a specific MRB in either a PTP or PTM delivery instance may further be used as either a bidirectional data tunnel (for both downlink and uplink data transmission between the CU and the DU) or a unidirectional data tunnel (only from the CU to the DU). Such a bidirectional data tunnel may further be used to transmit UE reports from the DU to the CU regarding a specific UE associated with such data tunnel and regarding a specific MRB. Such a UE report may be a PDCP status report regarding a specific MRB.

[0053] For each MRB associated with a delivery instance, there is at least one RLC entity allocated to transmit MRB data to the UE via the MAC / PHY resources associated with the RLC entity. For a PTP delivery instance, such an RLC corresponds to the transmission of MRB data to a specific UE. For a PTM delivery instance, such an RLC entity is common to all UEs in a PTM UE group. For a PTM delivery instance, the corresponding RLC PDU is Provides service to all UEs in a UE group.

[0054] An RLC entity associated with a particular MRB in a PTP distribution instance may also be involved in retransmission of MRB data to a particular UE with the PTP distribution instance when retransmission is required. In other words, no duplicated RLC entity may be required for retransmission of an MRB in a PTP distribution instance. Alternatively, a separate RLC entity may nevertheless be allocated for an MRB in a PTP distribution instance for retransmission of the MRB to a particular UE.

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

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

[0057] Each PTP or PTM delivery instance corresponds to a MAC / PHY configuration set. According to the configuration set, a UE or multiple UEs can complete reception of the MBS delivery instance according to the time and frequency domain corresponding to the MAC / PHY configuration set. The MAC / PHY configuration set may further include: -DRX information corresponding to this PTM distribution instance. · The Radio Network Temporary Identifier (RNTI) for the PTM distribution instance. · Time domain scheduling information corresponding to the PTM delivery instance to indicate the subframe or slot in which the PTM transmission is scheduled.

[0058] Frequency domain resource allocation information corresponding to the PTM distribution instance.

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

[0060] · BWP (Bandwidth Portion) information corresponding to the PTM delivery instance.

[0061] For a UE participating in receiving an MBS session, the UE receives the MBS session data using the resource allocation of at least one delivery instance, either a PTP delivery instance or a PTM delivery instance. In some embodiments, a UE may be enabled to receive MRBs for an MBS session using both a PTP delivery instance and a PTM instance. In some example implementations, a UE may receive all or a portion of the MRB data for an MBS session in a PTP delivery instance and all the MRB data in a separate PTM delivery instance that also delivers the MRB data to other UEs in a PTM manner. Thus, the UE may receive at least one of the MRBs from both the PTP delivery instance and the PTM delivery instance using different sets of corresponding resources. Such redundancy reduces package loss and failed delivery of MRBs to a UE in some circumstances. User plane resource architecture for delivery instances in MBS sessions

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

[0063] A distribution mode switch from one mode to another for one specific UE, e.g., UE1 receiving MBS session data in PTM mode, may experience poor connectivity. As a result, UE1 may then be reconfigured to receive MBS session data in PTP mode to improve reception quality. Or vice versa, the UE can also be reconfigured to switch from PTP mode to PTM mode, e.g., to achieve better spectral efficiency.

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

[0065] In other words, as shown in Figures 11-13, RLC entities 1 and 2 as part of a corresponding distribution instance may be associated with the same UE or with different UEs in different scenarios. In Figures 11-13, RLC entities 1 and 2, which comprise a corresponding distribution instance, may serve the same UE or different UEs at different times. The architecture options for distribution instances can be applied to both scenarios.

[0066] To enable delivery of QoS flows associated with an MBS session to UEs in different delivery modes, i.e., PTP, PTM, or both, for the same or different UEs, several different options exist from the perspective of user plane (UP) architecture, as shown in Figures 11-12. The protocol stack for a delivery instance comprises SDAP, PDCP, RLC, MAC, and PHY protocols or layers. For the above scenarios, different user plane architecture options utilize different protocol layers as anchor layers for mode switching or delivery mode coexistence, and in all options, different RLC entities are used for different delivery modes, either to the same UE or simultaneously to different UEs. The above protocol layers at and above the anchor layer are shared by the delivery instances. The following description focuses on mode switching from one delivery mode to another for one specific UE. The underlying principles are also applicable to cases with different UEs in different reception modes or UEs in different subgroups with PTM mode. UEs in different subgroups either receive the MBS session data in different cells, or receive the MBS session data in the same cell but in different distribution configurations, eg, different physical layer configurations.

[0067] Option 0 (Figure 11). For one specific MRB, two different delivery instances share the same SDAP, PDCP entity, F1-U instance, and RLC entity. The anchor layer is RLC. Protocol layers at and above RLC (all layers shown in Figure 11 except the physical layer) are shared by the delivery instances. QoS flows or data flows from the core network are submitted to a shared SDAP entity 1, some or all of the QoS flows are mapped to an MRB (other possible MRBs are not depicted), and the corresponding PDCP PDUs are submitted to an F1-U tunnel 1 in the case of a CU / DU split scenario, and the PDCP PDUs are submitted to a shared RLC entity serving different UEs. In some implementations, the two delivery instances also share a MAC entity, and the same MAC PDUs are scheduled separately on two different sets of physical resources.

[0068] Option 1 (Figure 12). For one specific MRB, two different delivery instances share the same SDAP and PDCP entities, and also the same F1 tunnel instance, but different RLC entities. The anchor layer is the F1-U on the DU side. The protocol stack layers at and above the FU are shared by the delivery instances. QoS flows or data flows from the core network are submitted to a shared SDAP entity 1, and some or all of the QoS flows are mapped to the MRB (other possible MRBs are not depicted) and the corresponding PDCP In the case of a CU / DU split scenario, the PDU is submitted to F1-U Tunnel 1 and The PDUs may be submitted to different RLC entities serving different UEs, or may be duplicated and submitted to more than one RLC entity if the UE receives MBS session data in both modes.

[0069] Option 2 (Figure 12). For one specific MRB, two different delivery instances share the same SDAP and PDCP entities, but different F1-Tunnel i and RLC entities. The anchor layer is therefore the PDCP layer. Protocol stack layers at and above the PDCP layer are shared by the delivery instances. QoS flows or data flows from the core network are submitted to a shared SDAP entity 1, some or all of the QoS flows are mapped to an MRB (other possible MRBs are not depicted), and the corresponding PDCP PDUs are submitted to different F1-U instances, e.g., Tunnel 1 and Tunnel 2, in case of a CU / DU split scenario, and the PDCP PDUs are submitted to different RLC entities, respectively.

[0070] 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. Protocol stack layers at and above the SDAP layer are shared by the delivery instances. QoS flows or data flows from the core network are submitted to a shared SDAP entity 1, where QoS flows are mapped to one set of MRBs, while identical QoS flows are mapped to another set of MRBs using the same or different mapping rules. The MRB data is then handled by different PDCP entities with separate sequencing operations. As a result, PDCP PDUs from different PDCP entities above are sent to DUs in different F1 tunnels and submitted to different RLC entities.

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

[0072] In the next section of this disclosure, further details regarding Option 1 and Option 2 are provided. User plane resource configuration and MBS data flow in a delivery instance of an MBS session, part 2

[0073] FIG. 3 illustrates an exemplary data resource configuration and data path in an access network including a CU and a DU for transmitting an MBS session. While an MBS session may be distributed by multiple DUs under the control of a CU, the following disclosure considers only one DU. The underlying principles apply to other DUs. As an example, a specific DU-UE configuration is assumed, as illustrated in FIG. 4. In particular, a DU is associated with multiple cells, including cell 1, cell 2, and cell 3 in FIG. 4. For this DU, there are multiple UEs distributed in the DU's serving cell that receive the MBS using either a PTP or PTM distribution mode associated with resource allocations for various PTP or PTM distribution instances, as listed below.

[0074] Cell 1-UE 1, PTP distribution instance 1,

[0075] Cell 1 - UE2 and UE3, PTP distribution instance 1,

[0076] Cell 2 - UE4 and UE5, PTP distribution instance 2,

[0077] Cell 3 - UE6, UE7, and UE8, PTP distribution instance 3,

[0078] Cell 3 - UE9 and UE10, PTP distribution instance 4.

[0079] Such a DU-UE configuration is further shown in Figure 3 as 380. In Figure 3, resource allocations in the CU-DU system for five (5) delivery instances are delimited by double-dashed lines 311, 313, 315, and 317, and the corresponding delivery instances are indicated by 301 (PTP1), 303 (PTM1), 305 (PTM2), 307 (PTM3), and 309 (PTM4). The resource allocations and data paths in Figure 3 are laid out from the upper layers through the lower layers of the network protocol stack in the CU-DU system to the UE, including the CU 310, the F1-U data tunnel 320 between the CU and DU, the DU 330, and the UE 380. Those skilled in the art will understand that Figure 3 merely includes some resource allocations and data paths relevant to the description of various embodiments of the present disclosure.

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

[0081] These PDCP PDUs associated with RB1-RB4 are transmitted to the DU over the F1-U interface using data tunnel 320. Multiple shared or unshared data tunnels may be included within F1-U data tunnel 320, as described above. These data tunnels may be downlink, uplink, or bidirectional. Further details about F1-U data tunnel configuration and sharing are provided when specific implementations are described below.

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

[0083] Each delivery instance may be responsible for delivering data for one or more MRBs (all or a subset of the MRBs) to a UE (for a PTP delivery instance) or multiple UEs (for a PTM delivery instance). Each MRB being transmitted by a particular delivery instance is associated with an RLC entity. For example, as shown by 352 in FIG. 3, PTP delivery instance 301 (PTP1) is responsible for delivering all four MRBs to UE1 in cell 1 and is then allocated four RLC entities corresponding to the four MRBs. For another example, UE2 and UE3 served by at least cell 1, which share the PTM1 delivery instance, may also need to receive all four MRBs using the four RLC entities allocated for the PTM1 delivery instance, as shown by 354. UE4 and UE5 served by at least cell 2, which share the PTM2 delivery instance, may only be able to receive two RBs, i.e., RB1 and RB2. For example, RB3 and RB4 cannot be configured for the PTM2 delivery instance. The distribution instance PTM2 may therefore be allocated only two corresponding RLC entities, as indicated by 356. Similarly, UE6, UE7, and UE8 served by cell 3, which share the distribution instance of PTM3, may only need to receive data for two RBs, i.e., RB2 and RB3. The distribution instance of PTM3 may therefore be allocated two corresponding RLC entities, as indicated by 358. Finally, UE9 and UE10 served by at least cell 3, which share the distribution instance PTM4, may only need to receive data for three RBs, i.e., RB1, RB2, and RB3. The distribution instance of PTM4 may therefore be allocated three corresponding RLC entities, as indicated by 359.

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

[0085] For retransmissions of a particular MRB for a UE in a PTP distribution instance, because the original RLC entities in such PTP distribution instance are not shared with other UEs, the original RLC entities may be used, and no additional RLC entities may need to be allocated for such retransmissions. However, in some alternative implementations, additional RLC entities may nevertheless be allocated for such retransmissions. For example, as shown in FIG. 3, PTP distribution instance PTP1 may require retransmissions for RB1, RB2, and RB3 for UE1. Because the original RLC entities 352 are not shared with other UEs (i.e., the RLC resources of the PTP instance are not shared with other instances), they may be used for retransmissions without allocating any additional RLC entities. Alternatively, an additional RLC entity 353 may nevertheless be allocated for such PTP retransmissions to UE1.

[0086] For either the PTP or PTM delivery instance, the RLC SDUs corresponding to the retransmitted PDCP PDUs are for retransmission as shown by 336 for the PTP1 delivery instance and 337 for the PTM2 delivery instance in Figure 3. For the PTP1 delivery instance, in the case where no additional RLC entities (such as 353) are allocated, the additional retransmitted RLC SDUs 336 will be submitted to the original RLC entity as shown by dotted routing line 339.

[0087] As further indicated by 370 in FIG. 3, each delivery instance 301, 303, 305, 307, and 309 is also associated with a corresponding set of MAC entities and physical layer functions for transmission of MBS data over the air interface to the UE.

[0088] The above exemplary resource configuration may be allocated by the CU and DU as controlled by signaling information and corresponding responses communicated between the CU and DU via the F1-C interface. Figure 3 merely represents an exemplary snapshot of such resource allocation and configuration. Such resource allocation and configuration may be dynamically established, modified, and released at any time under the control of such signaling interactions. For example, a particular UE may be switched between PTM and PTP delivery modes. The resource allocation and configuration may be dynamically modified to reflect such switching. Such switching and resource reallocation can be accomplished at the access network level without involvement from the application layer and can therefore be effected with little delay and service interruption.

[0089] Various exemplary implementations of signaling procedures, design of the information content of such signaling and responses, messaging formats, and distribution of configuration tasks between CU and DU are further described in more detail below. Signaling procedures between CU, DU and UE for resource allocation, modification and release, and UE delivery mode switching

[0090] FIG. 5 illustrates exemplary signaling message flows and procedures between the CU, DU, and UE for effecting MBS session context management, resource allocation / modification / release in the CU and DU for the various delivery instances described above to support transmission of an MBS session to the UE, and delivery mode switching of the UE between PTM and PTP delivery modes.

[0091] In some implementations, the CU receives MBS session context information from the core network, as described above. The CU then performs initial resource allocation, such as mapping between QoS flows and MRBs in the MBS session. As shown in step 0 of FIG. 5, the CU further performs a decision related to a delivery mode for each UE targeted by the MBS session based on the MBS session context information and information about the targeted UEs (as will be described later, such a decision may alternatively be made by the DU instead of the CU). For example, the CU may determine a delivery mode for each targeted UE. In some implementations, a subset of the targeted UEs may be assigned to the PTP delivery mode, while another subset of the targeted UEs may be assigned to the PTM delivery mode. In some other implementations, all targeted UEs may be assigned to the PTP delivery mode. In yet some other implementations, all UEs may be assigned to the PTM mode. Some of the targeted UEs may be assigned to both the PTP and PTM delivery modes. In some other implementations, such a determination of the delivery mode may be made by the CU or DU based on MRB granularity within each UE, rather than on a per-UE basis as a whole. Step 1 thus achieves synchronization of the MBS context between the CU and the DU.

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

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

[0094] · A delivery mode for the UE or serving cell or delivery instance for receiving the MBS data, which can be a PTP delivery mode or a PTM delivery mode.

[0095] When IP multicast is used, F1-U related information for transporting PDCP PDUs for the MRB from the CU to the DU. Such information may include, for example, the source address for the tunnel and the IP multicast address with or without the GTP-TEID.

[0096] In step 2, the DU performs various resource allocations and configurations based on the information received from the CU in step 1, and returns a response message to the CU. The response message may contain configuration information about successfully allocated lower layer resources for the allowed MRBs for various delivery instances. The message may also contain an MRB list for MRBs that failed to be created and the corresponding failure reason.

[0097] In step 3, the CU receives the lower-level configuration from the response message from the DU in step 2, generates an MBS radio resource configuration for the UE, and transmits such MBS radio resource configuration to the UE. Further, in step 3 or in a separate step, the CU may generate an MBS reception status report / feedback configuration for the UE and transmit the report / feedback configuration to the UE. The message in step 3 may be transmitted via broadcast or dedicated signaling. Thus, the CU may dynamically configure how the UE should provide feedback of MBS session reception, including, but not limited to, the form, content, timing, and trigger conditions of the feedback.

[0098] 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 status reports or feedback to the CU based on the form, content, timing, and trigger conditions specified in the status report / feedback configuration received from the CU in step 3. For example, the status reports or feedback may be transmitted periodically, triggered by a predetermined event, or both.

[0099] In some other implementations, alternatively or in addition to step 4, the feedback from the UE may first be sent to the DU, as shown in step 4a / 1, and then, as shown in step 4a / 2, the DU generates and sends a notification message to the CU based on the UE providing report or feedback to the DU in step 4a / 1.

[0100] In step 5, the CU modifies the MBS context information based on the status report, or feedback, or notification from the DU or UE, and transmits the modified MBS context information and other related information to the DU using an MBS context modification or release message, resulting in modification or release of resource allocation for various delivery instances and / or resulting in delivery mode switching for one or more UEs.

[0101] In step 6, the DU returns an MBS context modification or release response. The message may contain updated MRB configurations for successfully modified MRBs and MRB lists for failed modifications, as well as other information about various delivery instances and other related configuration information. Subsequently, the CU may further transmit any modified radio resource allocation information to the UE, similar to step 3. The context release described above may be implemented in the following manner. · The DU may initiate an MBS context release request (DU initiated). The CU may initiate an MBS context release request (CU initiated).

[0102] Other messages not included within the message flow of Figure 5 may also be used to communicate various other information between the CU and DU to assist in the allocation and configuration of resources for various delivery instances. These messages may include notification messages such as, but not limited to:

[0103] Notification messages to inform a UE that the requested QoS cannot be met.

[0104] A notification message from the UE to the DU, informing the DU that the UE cannot meet certain conditions and triggering the DU to further notify the CU. This notification can for example be included in the information sent in step 4a / 2 above.

[0105] The exemplary procedure shown in Figure 5 provides not only a mechanism for achieving initial resource allocation and configuration for a delivery instance in a CU and a DU through CU-DU interaction, but also a UE feedback mechanism for achieving delivery mode switching for one or more UEs. In particular, Figure 5 provides a mechanism for a UE to dynamically provide reception status reports or feedback to a CU so that the CU or DU can initiate a mode switching decision, implement corresponding modifications of delivery instances and corresponding resource allocations, and switch to a better delivery mode for transmitting an MBS session to the UE. Such switching and modifications may be achieved dynamically and based on real-time UE feedback.

[0106] Furthermore, because MBS context management and mode switch decisions are initiated and completed at the access network level, the delay introduced by a delivery mode switch between PTP and PTM for a UE is minimized compared to a mode switch initiated at the application level, which requires the involvement of more upper layers and more network elements. Signaling information exchange between CU and DU

[0107] Although the messages described above in the various steps in the signaling procedure of Figure 5 are each shown as being implemented as one signaling message, the information contained in these steps may be transmitted via multiple signaling messages. The sequence of these steps may be arranged in a flexible manner to achieve the two-way communication of MBS context and other information needed to enable the CU and DU to establish, modify, and release resource allocations and configurations for the various delivery instances. These steps may be repeated in their entirety or in part as necessary.

[0108] Each of these messages may contain one or more information items that are communicated bidirectionally between the CU, DU, and UE to effect resource allocation and configuration of a delivery instance for transmitting an MBS session to the UE. Such information items may be communicated for various purposes in resource allocation and configuration and to trigger various actions and responses from the CU or DU. The disclosure below describes in more detail these information items and corresponding actions and responses by the DU and / or CU to achieve dynamically reconfigurable resource allocation for various delivery instances as illustrated in the example configuration snapshot of FIG. 3.

[0109] After the CU receives the MBS context from the core network, maps the QoS flows of the MBS session to MRBs, and determines the delivery mode for the UEs participating in the MBS session, various information items may be exchanged from the CU to the DU (as will be explained later, such decisions may alternatively be made by the DU instead of the CU). A message sent from the CU to the DU may include any one of the following data items:

[0110] · Action indicators (e.g., set action, correct action, release action).

[0111] · MBS session identifier (further details provided below).

[0112] MRB information corresponding to the MBS session, including, for example, the RB ID of the MRB. The RB ID corresponds to an identifier that can be used to uniquely identify an MRB between the CU and the DU. Each RB ID may be represented by an index from an RB ID index space. An MRB may be further associated with a second RB ID for a particular UE to provide a mapping between the unique RB ID for the MRB and the RB ID used by the UE for the same MRB when the UE shares the RB ID index space with other MBS or PDU sessions associated with the UE. The second RB ID will be used as the served radio bearer in the RLC bearer configuration corresponding to the MRB returned by the DU to the CU.

[0113] · QoS parameters corresponding to MRB.

[0114] ·QoS parameters or profiles of QoS flows that are mapped to MRBs.

[0115] · MBS capability of the UE.

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

[0117] F1-U tunnel information corresponding to the MRB in one or more distribution instances. In some specific scenarios, a source address and an IP multicast address with or without a TEID may be included for DUs to join IP multicast and obtain PDCP PDUs for the MRB. Such IP multicast data tunnels may be shared among one or more distribution instances or may be exclusive for a particular distribution instance for a particular MRB.

[0118] When a PDCP PDU for an MRB is transmitted from a CU to a DU in an IP point-to-point transmission and no F1-U tunnel information from the CU is included for the MRB, the DU may respond with IP point-to-point transport information including an IP address and TEID as destination information for a downlink F1-U tunnel for the MRB. An F1-U tunnel may be shared among one or more distribution instances or may be exclusive for a particular distribution instance for a particular MRB instance.

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

[0120] PDCP retransmission enable indication for a specific UE (optionally based on MRB or MBS session). The DU establishes an RLC bearer for retransmission and returns configuration information to the CU.

[0121] A list of failed MRBs in the DU response for the delivery instance, along with the reason for the failure.

[0122] ·Configuration information corresponding to the delivery instance, including MAC / PHY configuration in the DU response.

[0123] · The RLC mode for the PTP delivery instance is either Acknowledged Mode (AM), Bidirectional Unacknowledged Mode (UM), Unidirectional UM Uplink, or Unidirectional UM Downlink.

[0124] RLC bearer configuration as a response from the DU after the DU has established an RLC entity for the MRB for the delivery instance, in the form of an RLC configuration and a Logical Channel ID (LCID). For MRBs in a PTM delivery instance, the RLC bearer may be associated with a UE-specific second LCID that may be returned from the DU to the CU in the response message, depending on whether the particular UE shares an LCID space with other MBS or PDU sessions associated with the UE.

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

[0126] · UE ID or UE ID list for UEs with PTP or PTM indication.

[0127] UE ID or UE ID list with response from DU indicating PTP or PTM mode.

[0128] Optionally, a cell ID or cell ID list with a UE ID list.

[0129] Optionally, a cell ID and a delivery instance ID along with a list of UE IDs.

[0130] · UE ID list with cell ID information. The above MBS session identifier may be used to identify an MBS session and may be provided in at least one of the following forms:

[0131] Session ID: An MBS session ID in a session management procedure for a UE that uniquely defines an MBS session among multiple sessions, including PDU sessions, for a UE; the session ID may be included in the SDAP configuration.

[0132] ·TMGI (Temporary Mobile Group Identification).

[0133] An IP multicast address with a source address.

[0134] An IP multicast address without a source address. Interface MBS ID that uniquely identifies an MBS session within the CU-DU interface, such as:

[0135] gNB-CU MBS F1AP ID: The gNB-CU MBS F1AP ID uniquely identifies an MBS association across the F1 interface within a gNB-CU.

[0136] gNB-DU MBS F1AP ID: The gNB-DU MBS F1AP ID uniquely identifies an MBS association across the F1 interface within the gNB-DU.

[0137] An identifier or index that can uniquely identify an MBS session within a CU or DU or F1 interface. The above UE ID (either alone or in a UE ID list) may be used to identify a UE and may be provided in at least one of the following forms: gNB-CU UE F1AP ID, gNB-DU UE F1AP ID, ·C-RNTI, RAN UE ID, An identifier or index that can uniquely identify a UE within a CU or DU or F1 interface. CU-DU interaction

[0138] This section describes various example interactions between a CU and a DU. In general, information items contained in signaling messages sent from a CU to a DU may trigger configuration actions in the DU and / or trigger responses from the DU. Some configuration decisions may be made by the CU. Some configuration decisions may be made by the DU. Some configuration decisions may be made either by the CU or the DU, or jointly by the CU and DU.

[0139] In some implementations, the determination of the delivery mode for each UE in a group of UEs of an MBS session may be determined by the CU, as described above in connection with FIG.

[0140] However, in some other alternative implementations, such a decision may be up to the DU. For example, the CU may provide a UE ID list via a signaling message from the CU to the DU. The DU may then use information such as UE connection status, along with other information in the DU, such as resource utilization or UE capabilities / MBS session requirements, to determine a delivery mode for each UE and return such a decision to the CU via a response signaling message. In other words, the steps in the signaling procedure of FIG. 5 may be performed by the DU between steps 1 and 2, and the step labeled "Determine Delivery Mode" between steps 4a / 2 and 5 may be performed by the DU between steps 4a / 2 and 5. For UEs associated with the PTP mode, the DU may allocate resources for the allowed MRBs for the PTP delivery instance corresponding to the PTP UE and return their configuration information. The DU determines the serving cell for the PTM delivery instance for UEs associated with the PTM delivery mode. The DU may further determine the number of PTM delivery instances in the determined serving cell for the PTM UE, perform resource allocation to these PTM delivery instances, and return a resource configuration including cell information and PTM delivery instance information (such as a PTM delivery instance index or ID). The DU may also return a UE ID for the UE in each of the PTM delivery instances. In some implementations, for one MBS session, only one PTM instance is allocated for one specific cell. In such a case, the PTM delivery instance ID may be a cell ID.

[0141] In some other implementations, assuming that the delivery mode per UE is determined by the CU, the decision on the delivery instance distribution in the serving cell of the DU for an MBS session may be made either by the CU, by the DU, or jointly by the CU and DU, using (but not limited to) the following alternatives:

[0142] In one implementation, the CU may determine everything, including the number of PTP distribution instances (the number of UEs in PTP distribution mode) and the number of PTM distribution instances, and the number of PTP distribution instances and the number of PTM distribution instances present in each serving cell of the DU. In such an implementation, the CU may send the UE list for PTP distribution instances, information about the PTM instances in each cell to the DU via various signaling messages. In response, the DU may allocate corresponding resources for the allowed MRBs and return various configurations described above to the CU. Optionally, the information sent by the CU may include the entire UE list.

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

[0144] In another implementation, for the PTM delivery mode, the CU may send information to define the PTM serving cell. In response, the DU may determine the number of PTM delivery instances in the serving cell, perform resource allocation to these PTM delivery instances, and return resource configuration for the PTM delivery instance information (including PTM delivery instance IDs). The DU may further return a UE ID list for the UEs associated with the PTM delivery instances if the CU includes a UE ID list in its message to the DU. In some implementations, for one MBS session, only one PTM instance is allocated for one specific cell. In such cases, the PTM delivery instance ID may be a cell ID.

[0145] In another implementation, for PTM delivery mode, the CU may send information to define the PTM serving cell and the PTM delivery instances therein. In response, the DU may perform resource allocation to these PTM delivery instances and return resource configurations for the PTM delivery instance information (including the PTM delivery instance ID). Optionally, the CU may further include a UE ID list in its message to the DU for each PTM delivery instance.

[0146] In the above embodiment, the configuration information returned by the DU may include at least one of (but not limited to) RLC bearer information for allowed MRBs per delivery instance, MAC / physical information per delivery instance, tunnel information for the CU to transmit PDCP PDUs to the DU, and the like. The RLC bearer configuration information for the MRB may include a unique RLC LCID and a first unique RB ID (unique between the CU and the DU for an MBS session). The unique LCID is common to a group of UEs of a PTM delivery instance and is included in the subheader of a MAC PDU generated from the corresponding logical channel. Furthermore, the RLC bearer configuration information may include, for a specific UE, a second LCID of the RLC bearer if the specific UE shares an LCID space with another MBS session or PDU session associated with the UE. Furthermore, the RLC configuration information may include, for a specific UE, a second RB ID provided by the CU if the specific UE shares a radio bearer space with another MBS session or PDU session associated with the UE.

[0147] In some implementations, an information item in a signaling message sent from a CU to a DU may include a retransmission enable indicator for a specific UE to enable retransmissions either based on a delivery instance or based on an MRB, i.e., for a delivery instance of an MBS session or for a defined MRB list only. In response, the DU may allocate resources for retransmissions. For example, the DU may allocate additional RLC bearers for a specific UE and corresponding MRBs if the specific UE belongs to a PTM delivery instance. The DU may further establish a downlink tunnel between the CU and the DU for each such MRB and for the specific UE. The DU may further return configurations for additional RLC bearers (e.g., additional LCIDs), downlink retransmission tunnel information (e.g., IP addresses and TEIDs) to the CU in one or more messages.

[0148] In some implementations, information items in a signaling message sent from a CU to a DU may include UE-specific uplink tunnel information (e.g., on a per-MRB basis). In response, the DU sends UE status reports to the CU when needed based on such uplink tunnel information.

[0149] Other information exchanges, actions, and responses between the CU and the DU not included above in this section are explicitly or implicitly described in other sections and detailed embodiments within this disclosure.

[0150] In some embodiments, the information item in the signaling message sent from the CU to the DU or from the DU to the CU further includes releasing resources in the resource allocation of all or a list of RBs associated with the distribution instance that are not shared by other distribution instances. For example, for a PTP distribution instance, the associated RLC bearer configuration and possible F1-U resources for retransmissions for a specific RB for a UE are released, while F1-U tunnels for RBs shared between other distribution instances are not released. For a PTM distribution instance, the associated RLC bearer configuration and possible F1-U resources for retransmissions for a specific RB for a specific UE are released, while F1-U tunnels for RBs shared between other distribution instances are not released. If the entire distribution instance is released instead of only a subset of the associated MRBs, the associated MAC / PHY resources for the PTM distribution instance are released as well. In some implementations, such a release indication is indicated by releasing resources in the resource allocation of all or a list of RBs associated with the UE that are not shared by other UEs, and thus UE-specific resources for RBs associated with MBS sessions in the DU and F1-U tunnels are released. In some implementations, such release is triggered by UE association signaling, including a UE context release request (DU initiated) and a UE context release request (DU initiated). In some implementations, such a release indication is indicated by releasing resources in the resource allocation of all or a list of RBs associated with a cell or cell list that are not shared by other cells. As a result, UE-specific resources associated with the associated RLC bearers and MRBs are released. The resources allocated for PTM distribution within the cell, including the F1-U tunnel, are released. If all MRBs are released instead of only a subset of the associated MRBs, the associated MAC / PHY resources for the PTM distribution instance within the cell are released as well. Signaling Message Architecture

[0151] The above various information items communicated between the CU, the DU, and the UE may be organized and grouped as one or more signaling messages according to a predetermined messaging format and one or more predetermined message categories. For example, request and response messages between the CU and the DU over the F1 interface may include, but are not limited to, the following categories: Context Setup Request (CU to DU): To trigger the DU to setup the MBS session context and allocate resources.

[0152] Context Setup Request Response (DU to CU): For the DU to respond with accepted and rejected MRB information for one or more delivery instances, RLC bearer configuration (e.g., RLC configuration, LCID), MAC / PHY configuration information, delivery instance information, downlink PDCP PDU tunnel information, and the like. Context modification request (CU to DU): To trigger the DU to modify the MBS session context and resource allocation.

[0153] · Context Modify Request Response (DU to CU): For the DU to respond with information similar to the Context Setup Request Response.

[0154] · Context Modification Request (DU to CU): To enable the DU to initiate a context modification.

[0155] · Context Modification Acknowledgement (CU to DU): Response to a context modification request from the DU.

[0156] Context release operation (CU initiated): for the release of resource allocation for an MBS session or a delivery instance (including a PTP delivery instance for a specific UE or a PTM delivery instance targeted to a group of UEs).

[0157] Context Release Operation (DU Initiated): To enable a DU to initiate the release of resource allocation for an MBS session or a delivery instance (including a PTP delivery instance for a specific UE or a PTM delivery instance targeted to a group of UEs).

[0158] Notification (DU to CU): The DU transmits a QoS-related notification to the CU regarding the MRB for a particular delivery instance to inform the CU that the QoS of an already established GBR (Guaranteed Bit Rate) MRB can no longer be met or that it can be met again.

[0159] These categories of messages may be structured at various levels and may be transmitted, for example, to target resource allocation and configuration of one or more UEs for a particular delivery instance or for an MBS session.

[0160] In some implementations, the above messages may be structured as UE association signaling messages (or per-UE or UE-specific signaling). In particular, each UE association message communicated from the CU to the DU is directed to a specific UE along with the context information and other information items described above to effect MBS session setup / modification / release, resource allocation, and configuration related to the specific UE. The DU correspondingly provides a UE association response to the CU. Such type of signaling may be based on an extension of the existing UE association signaling message scheme between the CU and DU. The establishment, modification, and release of resources for delivering MBS session data to all UEs in an MBS group may be achieved by cumulatively communicating and processing UE association signaling messages targeted to each of the UEs in the MBS UE group.

[0161] Alternatively, the above messages may be constructed as MBS association signaling messages (or per-MBS or MBS-specific signaling) rather than UE association signaling messages. In particular, each MBS association message communicated from the CU to the DU may not be directed to a specific UE, even though it contains information for effecting resource allocation and configuration for at least one UE in an MBS UE group. The MBS association message is directed to an MBS session and therefore contains a set of UE information items. To implement such MBS association messaging, a specific procedure code space, separate from that of the UE association procedure code space, may be reserved to represent various categories of the above messages that are MBS association. The signaling message may carry a <message type> information element containing a procedure code field indicating a message category related to the MBS association signaling message category. Therefore, from the perspective of signaling architecture, the CU-DU messaging format may be designed in one of the following exemplary manners:

[0162] Signaling Message Format Embodiment 1: Provides a format for UE association signaling messages of different categories only between CU-DU signaling.

[0163] Signaling Message Format Embodiment 2: MBS association signaling messages of different categories are provided only between CU-DU signaling.

[0164] Signaling Message Format Embodiment 3: Separate procedure code spaces are used to provide formats for both UE association and MBS association signaling messages between CU and DU. In some example implementations, the various categories of requests and responses described above related to a PTP delivery instance for a particular UE may be carried using a UE association signaling message format, while the various categories of requests and responses described above related to a particular PTM delivery instance may be carried using an MBS association signaling message format.

[0165] Exemplary characteristics of UE association signaling formats are described below. During interaction between the CU and DU for an MBS session context, the above various categories of UE association signaling messages always target a single UE to perform MBS session context management or operations over the F1 interface. In other words, the CU and DU use per-UE signaling units.

[0166] A particular UE association signaling message may carry any of the relevant information items described above. For example, the UE association signaling message may carry information items such as MBS session context information identified by an MBS session ID, MRB information, etc., which may include one or more of any of the following information items: MBS session ID. MRB corresponding to the MBS session. For each MRB, A UE-specific MRB Identifier (RBID) and possibly a second RB ID. QoS parameters for each MRB.

[0167] QoS parameters for QoS flows that are mapped to the MRB. Downlink F1-U tunnel information for the UE for MRB retransmission and a possible second downlink F1-U tunnel.

[0168] · Delivery mode for targeted UEs, such as PTP, PTM, or both.

[0169] F1-U tunnel information for additional tunnels for specific MRBs according to specific delivery characteristics (e.g., UE-specific uplink tunnels for PDCP status reporting from the UE and / or UE-specific downlink tunnels for PDCP PDU retransmissions).

[0170] RLC bearer configuration information for the UE.

[0171] Such UE association signaling messages are communicated between the CU and the DU and are used collectively by the CU and the DU to synchronize MBS session context information. In other words, the exchange of information items between the CU and the DU may be cumulatively based on multiple signaling interactions at different times.

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

[0173] Any UE association signaling message targeted to an MBS session may operate on the MBS session context and configuration, which may include, but is not limited to, the following information or a combination thereof:

[0174] MRB attributes, including their release and addition.

[0175] ·Modifying QoS parameters corresponding to MRB, adding and removing QoS flows mapped to MRB.

[0176] ·PDCP configuration modifications such as PDCP SN length, reordering timer, cipher and integrity protection configuration.

[0177] In some scenarios, the above behavior as a result of the UE association signaling may be applicable to all delivery instances of the MBS session associated with the DU. For example, in a delivery instance of an MBS session, the UE association signaling message updates the F1-U tunnel information corresponding to the MRB of the MBS session, and if corresponding MRBs in multiple delivery instances of the MBS session share the same F1-U tunnel, the tunnel information update applies to all other transmission instances that share this F1-U tunnel.

[0178] Any UE association signaling targeted to a specific UE can operate on various aspects of the delivery instance associated with the specific UE in the MBS session, including, but not limited to, the following information or a combination thereof:

[0179] Delivery instance ID.

[0180] ·F1-U tunnel associated with the distribution instance for the MRB.

[0181] · Control information corresponding to the configuration and delivery instance of the associated RLC bearer.

[0182] ·MAC / PHY configuration set for a specific PTM delivery instance associated with the UE, including the delivery cell identification or a specific PTM delivery instance within the cell.

[0183] With respect to an MBS association signaling message targeted at an MBS session, the particular MBS association signaling message may carry any of the relevant information items described above. For example, the MBS association signaling message may carry information items such as MBS session context information identified by an MBS session ID, MRB information, etc., which may include one or more of any of the following information items:

[0184] MBS session ID. MRB corresponding to the MBS session. For each MRB,

[0185] o MRB Identifier (RBID).

[0186] QoS parameters for each MRB.

[0187] QoS parameters for QoS flows that are mapped to the MRB.

[0188] *Downlink F1-U tunnel information.

[0189] · Delivery mode for targeted UEs, such as PTP, PTM, or both.

[0190] F1-U tunnel information for additional tunnels for specific MRBs according to specific delivery characteristics (e.g., UE-specific uplink tunnels for PDCP status reporting from the UE and / or UE-specific downlink tunnels for PDCP PDU retransmissions).

[0191] RLC bearer configuration information for the delivery instance. ·MAC / PHY configuration set for a specific PTM delivery instance, including delivery cell identification or a specific PTM delivery instance within a cell.

[0192] Such MBS association signaling messages are communicated between the CU and the DU and are used collectively by the CU and the DU to synchronize MBS session context information. In other words, the exchange of information items between the CU and the DU may be cumulatively based on multiple signaling interactions at different times.

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

[0194] The MBS association signaling message by the CU may instruct the DU to perform context synchronization and / or resource allocation and configuration based on either an MBS session, a delivery instance, or an MRB. The MBS association signaling message may include various lists and tables of MRBs, UEs, and delivery instances involving the MRBs, UEs, or delivery instance-specific information defined by the lists or tables.

[0195] The following disclosure further provides a detailed description of the signaling message format embodiments 1-3 messaging architecture between the CU and the DU in achieving bidirectional resource allocation and configuration for various delivery instances. Embodiment 1

[0196] In a first embodiment using only UE-specific signaling (alternatively referred to as UE association signaling), the CU may decide that some UEs will receive the MBS in PTP mode (group 1 UEs) while some UEs will receive the MBS in PTM mode (group 2 UEs) (as will be explained later, such a decision may alternatively be made by the DU instead of the CU). The CU uses UE association F1 signaling, such as a UE context setup or UE context modification message, to request the DU to allocate, modify, or release the corresponding resources and return the relevant configuration to the DU. In this embodiment, MBS session context management is always performed on a per-UE basis. If the CU needs to perform MBS session context management for multiple UEs, multiple UE association signaling messages are transmitted and combined to result in resource allocation and configuration.

[0197] UE association signaling for MBS session context setup or modification initiated from a CU contains at least the following information items, along with information items that may be returned by the DU in a response message: Since the UE association signaling is targeted to a specific UE, some of the actions within the signaling are therefore specific only to that UE. 1. Information independent of delivery mode (PTP / PTM), including UE ID, MBS session ID, MRB QoS parameters, and associated QoS parameters of QoS flows.

[0198] User Interface ID: gNB-CU UE F1AP ID, gNB-DU UE F1AP ID, and MBS Session ID or MBS Session ID list.

[0199] DU response: gNB-CU UE F1AP ID, gNB-DU UE F1AP ID, MBS session ID or MBS session ID list.

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

[0201] o DU Response: First RLC bearer configuration information corresponding to each MRB, including the corresponding served RB ID, which can be RBID1 or RBID2.

[0202] ·For a specific MRB, its QoS parameters and the QoS parameters of the QoS flows that are mapped to the MRB.

[0203] For a specific MRB, its downlink multicast address (with or without source address) and the corresponding GTP-TEID (GPRS Tunneling Protocol Tunnel Endpoint Identifier). If downlink tunnel information is allocated by the DU for the MRB, o DU Response: First downlink tunnel information (IP address and associated GTP-TEID) corresponding to each MRB allowed by the DU. ·UE capabilities regarding UE. · UE capability requirements for MBS sessions.

[0204] 2. The CU makes a delivery mode decision for the UE and includes a delivery mode indication in the information sent to the DU. In another implementation, the CU sends only the MBS session context to the DU, and the DU makes a delivery mode decision for the UE and returns a configuration with the delivery mode.

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

[0206] · The RLC mode corresponding to the MRB, which can be Acknowledged Mode (AM), Bidirectional Unacknowledged Mode (UM), Unidirectional UM Uplink, or Unidirectional UM Downlink.

[0207] ·Uplink tunnel information corresponding to each MRB of the MBS session.

[0208] · Indicator for enabling or activating retransmissions (e.g., PDCP retransmissions) for the MRB or MRB list of an MBS session.

[0209] o DU response: Corresponding second downlink tunnel information (DL-TNL2, including IP address and associated GTP-TEID).

[0210] o DU Response: DU-CU RRC information containing at least the RLC bearer configuration above.

[0211] In response to receiving a request from the CU, the DU attempts to allocate or modify resources per the request. The DU then sends response information to the CU, providing feedback on whether each RB is successfully created. Furthermore, for each successfully created MRB, the DU creates a configuration for the specific RB and returns the configuration to the CU. For MRBs that failed the corresponding operation, the DU response further includes an MRB list of the MRBs that failed the operation request and the corresponding cause.

[0212] 4. Message related to PTM mode request. CU / DU interaction information includes PTM delivery mode indicator (if CU decides delivery mode and sends indicator to DU). Otherwise, DU decides mode to UE, PTM delivery cell, PTM delivery instance ID, first RLC bearer configuration, second RLC bearer configuration. There are several solutions for CU / DU message (PTM delivery cell is the cell in which MBS session is delivered, especially for PTM delivery instance): CU message does not specify PTM delivery cell and does not specify delivery instance ID. Only MBS session context containing UE list with PTM delivery mode, o DU Response: PTM delivery cell or cell list, optionally PTM delivery instance ID corresponding to the PTM delivery cell, and optionally UE list corresponding to the delivery instance.

[0213] ·PTM delivery cell specified by CU message.

[0214] The CU message specifies a PTM delivery cell and does not specify a PTM delivery instance ID in the transmission cell.

[0215] o DU Response: Optionally, the DU returns the PTM Delivery Instance ID in the transmit cell.

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

[0217] The DU in the response message contains the MAC / PHY configuration corresponding to the PTM distribution cell or distribution instance within the cell. For each allowed MRB in a PTM delivery cell or PTM delivery instance of an MBS session,

[0218] DU response: Configuration information of the first RLC bearer corresponding to the MRB, further including the associated logical channel identification LCID1. In some scenarios, the logical channel identification may include LCID1 and LCID2.

[0219] The CU message further contains uplink tunnel information corresponding to the MRB.

[0220] The CU message further indicates the mode of the RLC entity corresponding to the MRB, which can be acknowledged mode (AM), bidirectional unacknowledged mode (UM), unidirectional UM uplink, or unidirectional UM downlink.

[0221] · The CU message may further enable or activate retransmissions (such as PDCP retransmissions) for the MRB.

[0222] o DU Response: Corresponding second downlink tunnel information (DL-TNL2, including IP address and associated TEID) for the specific UE. This tunnel may be used for PDCP retransmissions or UE PDCP status reporting for the specific UE.

[0223] o DU Response: Marking the second RLC bearer configuration for the particular UE and its logical channel identification LCID3, corresponding to the primary path used to transmit the PDCP SR.

[0224] DU Response: A list of MRBs for which the operation corresponding to the PTM delivery instance corresponding to the MBS session failed, along with the corresponding reasons.

[0225] Now, refer to FIG. 4 for an exemplary distribution instance configuration for a UE under a DU. The DU is associated with at least three cells and is associated with UE1-UE10 in an MBS session context. The CU or DU makes a decision on the UE distribution mode for the MBS. If the CU makes the decision, it sends the distribution mode associated with the UE to the DU. If the DU makes the decision, it sends only the MBS session context to the DU, letting the DU make the decision, and the DU returns the allocated resource configuration. In some implementations, the CU provides only UE information without the distribution mode. As a result, the DU determines the distribution mode for the UE, for example, taking into account the connection status of the UE and available radio resources, and also the UE capabilities for the UE, and also the UE capability requirements for the MBS session. In the response information from the DU, the DU provides corresponding scheduling information including transmission cell information and possibly a distribution instance ID for the transmission cell and a MAC / PHY configuration set. Based on the interaction between the CU and the DU, there is an interaction result as shown in FIG. 4. Cell 1-UE1, PTP Cell 1 - UE2 and UE3, PTM Cell 2 - UE4 and UE5, PTM Cell 3 - UE6, UE7, and UE8, PTM Cell 3 - UE9 and UE10, PTM

[0226] It is clear that each cell may support multiple distribution instances in either PTP or PTM mode. In some embodiments, only one distribution instance is allowed for a cell.

[0227] In some embodiments, the PTP distribution mode, the PTP distribution mode in different cells, and the PTM distribution mode in the same cell are all mapped to different distribution instances. At least one RLC entity is allocated on the DU side for each MRB.

[0228] The message interactions between the CU and the DU and the information items carried within the messages are further described below and are organized in several groups. MBS Session Related Content

[0229] The CU initiates a context management operation for an MBS session or MBS session list to the DU using UE association signaling, where the operation may be adding or modifying an MBS context, or the message contains the MBS session-related context and its operation. The message is identified by the gNB-CU UE F1AP ID or, optionally, the gNB-DU UE F1AP ID. An MBS session may correspond to one MBS or category of MBS, and an MBS may be associated with multiple MBS sessions. An MBS session is identified by an MBS session ID. The MBS session ID may be used to identify an MBS session and may be one of the following IDs or a combination thereof:

[0230] Session ID: The MBS session corresponds to a session ID in the session management mechanism of a certain UE, and the session ID uniquely defines the MBS session among multiple sessions of the UE, and the session ID may be included in the SDAP configuration.

[0231] ·TMGI (Temporary Mobile Group Identification).

[0232] IP multicast addresses (with or without source addresses).

[0233] · gNB-CU MBS F1AP ID: The gNB-CU MBS F1AP ID uniquely identifies an MBS association across the F1 interface within a gNB-CU.

[0234] · gNB-DU MBS F1AP ID: The gNB-DU MBS F1AP ID uniquely identifies an MBS association across the F1 interface within a gNB-DU.

[0235] An identifier or index that may uniquely identify an MBS session in a CU or DU or F1 interface. An MBS session may correspond to one service or category of service, while an MBS may be associated with multiple MBS sessions.

[0236] In the corresponding DU response message, the message is The ID and gNB-DU UE F1AP ID are used to identify the associated F1 logical connection, and the response message also contains the MBS session ID.

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

[0238] In some scenarios, the MRB is further associated with a second RB ID (RBID2), and the served radio bearer in the first RLC bearer configuration for the delivery instance in the DU response message is configured as the second RB ID (RBID2) in the CU for the UE. Service data received by the UE based on the RLC bearer is delivered to the PDCP entity identified by RBID2.

[0239] The operation further includes QoS parameters for each MRB and QoS parameters mapped to QoS flows of the MRB. F1-U Tunnel Resources

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

[0241] In some embodiments, the CU uses the MBS session as the granularity and requests the DU to deliver MBS session data to the UE in PTP mode, i.e., the CU requests the DU to deliver service data of all MRBs of the MBS session in PTP mode. However, in some other embodiments, for example, when air interface resources are limited or scarce, it is more desirable to include only data of specific MRBs instead of all MRB data of the MBS session in PTP delivery mode. In this scenario, the CU requests the DU to deliver specific MRBs or an MRB list of the MBS session in PTP mode.

[0242] In some embodiments, the DU receives a request from the CU to use a PTM delivery mode for the MBS session. For example, for the PTM delivery mode, the MBS data is delivered based on the granularity of the MBS session. For a particular request as described above, regardless of the delivery mode, for a particular MRB, if the DU accepts an MRB delivery request for an MBS session from the CU:

[0243] In some embodiments, as shown in FIG. 6 (to illustrate downlink tunnel sharing for a particular MRB among some of the distribution instances of FIG. 4), the CU uses IP multicast 610 to transmit MRB data to the DU at the IP layer of the tunnel. The information sent by the CU contains IP multicast downlink tunnel information for the MRB, i.e., first IP multicast type downlink tunnel information. The DU then joins the IP multicast group and receives the MBS if any of the associated distribution instances allow the MRB. Tunnel 1 is above the IP layer based on IP multicast 610. The tunnel information includes an IP multicast address, and optionally a source address and a GTP-TEID. In this scenario, Tunnel 1 is shared by multiple distribution instances, for example, a PTP distribution instance for UE1 (602 in FIG. 6), a PTM distribution instance for UE6, UE7, and UE8 (604 in FIG. 6), and a PTM distribution instance for UE9 and UE10 (606 in FIG. 6). MRB data is delivered from the CU to the DU using Tunnel 1, and the DU then submits the MRB data to multiple RLC entities (RLC entities 1, 2, and 3) to serve the corresponding delivery instances. Figure 6 shows a data delivery example for one MRB, but the same principles apply to other MRBs.

[0244] In some embodiments, as shown in FIG. 6, the CU transmits MRB data to the DU using IP point-to-point transmission 612. The F1-U tunnel information of the MRB is provided by the DU. If there is no previous distribution instance on the DU side that allows an MRB for an MBS session, or if this is the first time such an MRB for an MBS session is configured in the DU, the DU allocates corresponding F1-U interface resources, which are the first downlink tunnel, and returns corresponding first downlink tunnel information, including the IP address and associated GTP-TEID, to the CU. It should be further noted that once the MRB data is received by the DU from Tunnel 1, the DU handles the remaining data distribution tasks in the same manner as mentioned above. In this scenario, Tunnel 1 is shared by multiple distribution instances, for example, a PTP distribution instance for UE1 (602 in FIG. 6), a PTM distribution instance for UE6, UE7, and UE8 (604 in FIG. 6), and a PTM distribution instance for UE9 and UE10 (606 in FIG. 6). MRB data is delivered from the CU to the DU using Tunnel 1, and the DU then submits the MRB data to multiple RLC entities (RLC entities 1, 2, and 3) to serve the corresponding delivery instances. Figure 6 shows a data delivery example for one MRB, but the same principles apply to other MRBs.

[0245] In some embodiments, if a DU previously had a delivery instance (including either a PTP or PTM delivery instance) including an MRB corresponding to an MBS session, the same MRB for the same MBS session share an F1-U downlink tunnel, and the DU returns downlink tunnel information on the F1-U interface, i.e., the first DL tunnel, established for the MRB of the MBS session. For example, in FIG. 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 for the same MRB. 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.

[0246] In some embodiments, the MRB uses an independent F1-U downlink tunnel; that is, for a certain MRB of an MBS session, there are multiple independent F1-U tunnels on the corresponding F1 interface based on different distribution instances. Therefore, based on an MBS session context management request, the DU returns independent tunnel information for the same MRB under different distribution instances. The tunnel created under this scenario is referred to as the first downlink tunnel under each distribution instance. For example, in FIG. 7 (to illustrate the use of independent downlink data tunnels for some of the distribution instances of FIG. 4), multiple distribution instances (a PTP distribution instance for UE1 labeled 702 in FIG. 7, a PTM distribution instance for UE6, UE7, and UE8 labeled 704 in FIG. 7, and another PTM distribution instance for UE9 and UE10 labeled 706 in FIG. 7) use independent F1-U tunnels, namely, Tunnel 2, Tunnel 3, and Tunnel 4. At this point, after the PDCP PDU from the PDCP entity corresponding to the MRB is transmitted to the DU through an individual tunnel, it is submitted to RLC entities corresponding to multiple delivery instances, e.g., RLC entity 1, RLC entity 2, and RLC entity 3.

[0247] The following sections describe CU-DU interactions for handling PTP-related requests. Handling requests related to PTP delivery mode and RLC bearer configuration

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

[0249] The CU message also carries uplink tunnel information corresponding to the MRB. Specifically, the IP address and associated GTP-TEID. The uplink tunnel information may be used by the DU to establish an uplink tunnel. In some scenarios, this uplink tunnel is used to carry a corresponding PDCP Status Report (PDCP SR) generated by the UE related to MRB data reception. This is shown in Figure 8.

[0250] More specifically, Figure 8 illustrates a tunnel configuration for particular MRBs in distribution instances 802 and 804, with data tunnel 1 and data tunnel 2. Distribution instance 804 may be a PTP distribution instance, while distribution instance 802 may be either a PTP or PTM distribution instance. As shown in Figure 8, tunnel 1 is shared by distribution instances 802 and 804 for normal downlink transmission of PDCP PDUs of the MRBs to RLC entities for the MRBs in distribution instances 802 and 804, while tunnel 2 is established for uplink PDCP SR 810 transmission to the CU. Handling PTP retransmission requests When the CU enables or activates PDCP retransmissions for the MRB, there may be different scenarios regarding how the F1-U downlink tunnel is shared.

[0251] In some embodiments, the CU transmits the MRB data to the DU using IP multicast. Referring again to FIG. 8, FIG. 8 further illustrates the use of Tunnel 2 for retransmissions for the PTP distribution instance 804, which is shared with the uplink tunnel for transmitting PDCP SRs. Information about Tunnel 1 is provided by the CU, while Tunnel 2 information is submitted by the DU. For MRB data transmission, initial data transmissions for different distribution instances share Tunnel 1, and MRB data retransmissions for the PTP distribution instance 804 use Tunnel 2. For the PTP distribution instance 804, both the initial data and the retransmitted data are submitted to RLC entity 2 corresponding to the PTP distribution instance 804.

[0252] In some embodiments, the CU transmits MRB data to the DU using point-to-point. Referring to Figure 8, both Tunnel 1 and Tunnel 2 information are provided by the DU. In this scenario, for MRB data transmission, initial data transmissions for different delivery instances share Tunnel 1. For PTP delivery instance 804, MRB data retransmissions use Tunnel 2. Both the initial data and the retransmitted data are delivered to the same RLC entity corresponding to the PTP delivery instance, which is RLC entity 2.

[0253] In some embodiments, the same MRB in different distribution instances uses independent tunnels. Referring to FIG. 9 (showing distribution instances 902 and 904 using independent data tunnels for a particular MRB), PTP distribution instance 904 for UE1 uses Tunnel 2, while distribution instances for other UEs use Tunnel 1. For PTP distribution instance 904 for UE1, MRB data initial transmission and retransmissions use the same tunnel, Tunnel 2. In this scenario, Tunnel 2 may be bidirectional. It can be used as a downlink for MRB data initial transmission and retransmission. It can also be used as an uplink for transmission of PDCP SRs corresponding to the MRB. DU handling denies creation of some MRBs

[0254] For a CU message specifying a PTP delivery mode for a UE, the DU may reject the creation or modification of one or more MRBs. In this case, the DU returns an MRB list containing the MRBs that failed to be created or modified and the reason for the failure.

[0255] The following section describes CU-DU interactions for handling PTM related requests. PTM related request - cell related information and lower layer configuration information

[0256] Each PTM delivery instance always corresponds to a specific transmission cell. Depending on different implementations, when a UE receiving an MBS session is in a connected state, context regarding the cell associated with the UE exists on both the CU and DU sides. The transmission cell information for a PTM delivery instance may be provided by the CU or DU. In addition, if an MBS session is enabled to be transmitted in a cell based on multiple delivery instances, a combination of cell identification and unique identification within the cell is required to uniquely identify these delivery instances. Alternatively, an identifier exists on the F1 interface that can uniquely identify a delivery instance and its corresponding cell for an MBS session. The delivery instance identifier may be provided by the CU or DU. In the following disclosure, the above different possibilities regarding the delivery instance identifier will be disclosed in detail. In addition, each PTM delivery instance corresponds to a MAC / PHY configuration set. Based on the configuration set, the UE can complete reception of the MBS delivery instance in the time-frequency domain corresponding to the physical layer.

[0257] In some implementations, the CU provides only UE information without a distribution mode. As a result, the DU determines the distribution mode for the UE, for example, taking into account the connection status of the UE and available radio resources, and also the UE capabilities for the UE, and also the UE capability requirements of the MBS session. In the response information from the DU, the DU provides corresponding scheduling information including transmission cell information and possibly a distribution instance ID in the transmission cell and a MAC / PHY configuration set.

[0258] In some implementations, the CU provides UE information along with the corresponding delivery mode, and the CU does not specify cell information regarding PTM transmission for the UE's MBS, while the DU includes a cell or cell list of PTM transmission in the corresponding response message. Optionally, the DU further includes in the response message a PTM delivery instance ID corresponding to the transmitting cell and scheduling information corresponding to the corresponding cell or the corresponding PTM delivery instance in the corresponding cell.

[0259] The CU may define a transmission cell in the PTM transmission. Optionally, the CU further defines a PTM delivery instance ID in the transmission cell.

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

[0261] If the CU further specifies cell information regarding PTM transmission and a PTM distribution instance ID in the corresponding cell, the DU includes, in the corresponding response message, scheduling information corresponding to the corresponding cell or the corresponding PTM distribution instance in the corresponding cell.

[0262] The above scheduling information includes a MAC / PHY configuration corresponding to a PTM delivery instance, and may also include the following information or a combination of the following information: -DRX information corresponding to this PTM distribution instance. · The Radio Network Temporary Identifier (RNTI) for the PTM distribution instance. · Time domain scheduling information corresponding to the PTM delivery instance to indicate the subframe or slot in which the PTM transmission is scheduled. Frequency domain resource allocation information corresponding to the PTM distribution instance.

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

[0264] · BWP (Bandwidth Portion) information corresponding to the PTM delivery instance. PTM related requests, RLC bearer configuration

[0265] If the DU accepts the corresponding MRB transmission request in PTM mode, if 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 a corresponding first RLC bearer configuration to the CU according to the configuration corresponding to the existing delivery instance.

[0266] In some embodiments, if the DU accepts the corresponding MRB transmission request in PTM mode, the DU must include in the response message the RLC bearer configuration information corresponding to each MRB for the MBS session, including the logical channel ID corresponding to the MRB.

[0267] In another embodiment, when 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, further including 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 and corresponds to the logical channel information in the subheader of the MAC PDU containing the corresponding MRB service data, while LCID2 is mapped to LCID1. After receiving the PDU, the UE submits the data marked with LCID1 in the MAC PDU subheader to the logical channel identified by LCID2 for further processing. PTM related requests - PDCP SR and retransmission handling

[0268] Referring to Figure 10 (which shows the tunnel configuration for a PTM instance 1002 for a particular MRB), in some scenarios, the network needs to enable PDCP SRs for the MRB and / or PDCP data retransmissions for the MRB in the PTM delivery instance 1001 for a particular UE using a bidirectional tunnel. The UE is configured with two independent RLC entities in the PTM delivery instance 1002: RLC entity 1 associated with tunnel 1 for performing initial MRB data transmission in PTM mode, and RLC entity 2 (labeled 1004 in Figure 10) associated with tunnel 2 for performing retransmissions of MRB data in PTP mode and transmission of PDCP SRs corresponding to the MRB in the uplink. Tunnel 2 in this case is bidirectional.

[0269] The CU message further carries uplink tunnel information corresponding to the MRB, specifically, an IP address and an associated GTP-TEID. If the CU enables or activates PDCP retransmission for the MRB, the DU returns second downlink tunnel information, including an IP address and an associated GTP-TEID. Here, the DU on the F1 interface contains information about two tunnels corresponding to the MRB. The first tunnel (Tunnel 1) may be used to transmit initial transmission data corresponding to the MRB, and the second tunnel (Tunnel 2) is used to transmit retransmission data corresponding to the MRB and uplink PDCP SR.

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

[0271] For a CU message specifying a PTM delivery mode for a UE, the DU may reject the creation or modification of one or more MRBs. In this case, the DU returns an MRB list containing the MRBs that failed to be set or modified and the reason for the failure. Handling dual modes using both PTP and PTM

[0272] In some embodiments, for a particular UE, the CU may request both PTP and PTM delivery modes, and the DU may allocate corresponding resources, so that the UE may be able to receive MRB data in PTP and PTM modes simultaneously. Embodiment 2

[0273] In this embodiment, the CU determines that some UEs will receive the MBS in PTP mode (Group 1 UEs) while some UEs will receive the MBS in PTM mode (Group 2 UEs). The CU uses MBS association F1 signaling, such as an MBS context setup or MBS context modification message, to transmit the decision to the DU and request the DU to allocate or modify corresponding resources and related configurations. Meanwhile, on the DU side, in response to receiving a CU-initiated MBS association message containing delivery mode information (PTP for a specific UE, or PTM for a specific UE, cell, or instance within a cell), the DU allocates resources and creates corresponding configurations. Based on whether each MBS is successfully created, the DU sends a feedback message containing MRB configuration information, such as F1-U and RLC bearer configuration, and air interface resource allocation for the delivery instance corresponding to the MBS session. In this embodiment, MBS session context management is always performed on a per-MBS basis. This new mechanism is supported by the introduction of MBS association signaling in this disclosure.

[0274] In some implementations, the DU determines that some UEs receive the MBS in PTP mode (Group 1 UEs), while some UEs receive the MBS in PTM mode (Group 2 UEs). Meanwhile, on the DU side, in response to receiving the CU-initiated MBS association message, the DU allocates resources and creates corresponding configurations. Based on whether each MBS is successfully created, the DU sends a feedback message including MRB configuration information, such as F1-U and RLC bearer configurations, and air interface resource allocation for the delivery instance corresponding to the MBS session. In this embodiment, MBS session context management is always performed on a per-MBS basis.

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

[0276] The MBS association message interactions between the CU and the DU and the information items carried within the messages are further described below and are organized in several groups. The basic information, independent of the delivery mode, includes the interface ID, the MBS session ID, the MRB QoS parameters and the associated QoS flow parameters.

[0277] gNB-CU MBS F1AP ID, gNB-DU MBS F1AP ID: MBS session ID or session ID list.

[0278] DU response: gNB-CU UE F1AP ID, gNB-DU UE F1AP ID, MBS session ID or session ID list

[0279] Delivery mode description, which may include the MRBs in the MRB list for the entire MBS session or this MBS session using PTP mode, together with the corresponding UE ID list and the UE ID list for all UEs using PTM mode, or the cell list using PTM mode or the instance list in the corresponding cell list.

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

[0281] An MRB ID list for MRBs serving one of the MBS sessions, where a first RB ID (RBID1) corresponding to each MRB is an index of all MRBs for the MBS; optionally, the CU provides a UE ID list containing all UEs receiving the MBS session; and optionally, for each UE, the RB ID (RBID1) of each MRB is associated with a second RB ID (RBID2) if the RB ID for the MBS and the RB ID used by the UE use independent namespaces.

[0282] o DU Response: First RLC bearer configuration information corresponding to each MRB of the MBS session, including the corresponding served RB ID, which may be RBID1 or RBID2, for each UE mentioned above.

[0283] ·For a specific MRB, its QoS parameters and the QoS parameters of the QoS flows that are mapped to the MRB.

[0284] For a specific MRB, its downlink IP multicast address (and its source address) and the corresponding GTP-TEID. In the case of transmission of MRB data using point-to-point delivery at the IP layer of the tunnel, o DU Response: First downlink tunnel information (IP address and associated GTP-TEID) corresponding to each MRB allowed by the DU. If there are multiple distribution instances for the MRB, the allowed MRB list for each distribution instance may not be identical.

[0285] ·UE capabilities regarding UE.

[0286] · UE capability requirements for MBS sessions. Message related to PTP mode request. DU CU interaction information includes PTP delivery mode indicator, RLC entity mode, and RLC bearer configuration including served RB ID.

[0287] For a UE using PTP mode as determined by the CU, the CU instructs the UE to receive all MRBs of the MBS session in PTP mode, or the UE receives an MRB or MRBs in the MRB list in PTP mode.

[0288] · The CU further indicates the RLC entity mode corresponding to the MRB, which may be acknowledged mode (AM), bidirectional unacknowledged mode (UM), unidirectional UM uplink, or unidirectional UM downlink.

[0289] The CU may further contain the uplink tunnel information corresponding to each MRB mentioned above (including the IP address and associated GTP-TEID).

[0290] · The CU may further enable or activate retransmissions (such as PDCP retransmissions) for each MRB mentioned above.

[0291] o DU response: Corresponding second downlink tunnel information (DL-TNL2, including IP address and associated GTP-TEID).

[0292] o DU Response: DU-CU RRC information containing at least the RLC bearer configuration above.

[0293] DU Response: A list of MRBs that failed the operation request and the corresponding reasons. Messages related to PTP mode requests

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

[0295] In the request message, the CU specifies that the PTM mode is used to transport MBS session data. In the DU response message, a PTM delivery instance list is present, and each delivery instance in the list may further be associated with a UE ID list. The information exchange between the CU and DU interactions is listed below.

[0296] The CU request message includes a UE ID list, and the list contains UEs that use the PTM delivery mode.

[0297] o DU response: optional PTM distribution cell or cell list, optionally PTM distribution instance IDs corresponding to the PTM distribution cells, and optionally a list of UE IDs corresponding to the distribution instances.

[0298] The CU request message includes a cell list corresponding to the PTM delivery mode, and each cell in the cell list may be further associated with a UE ID list.

[0299] o DU response: optional PTM distribution cell or cell list, optionally a PTM distribution instance list corresponding to the PTM distribution cells, and optionally a UE ID list corresponding to the distribution instances.

[0300] ·UE capabilities regarding UE.

[0301] · UE capability requirements for MBS sessions.

[0302] The CU request message includes a cell list corresponding to the PTM delivery mode and a PTM delivery instance list, where each cell in the cell list may be further associated with a UE ID list, and each delivery instance in the delivery instance list may be further associated with a UE ID list.

[0303] o DU response: optional PTM distribution cell or cell list, optionally PTM distribution instance IDs corresponding to the PTM distribution cells, and optionally a list of UE IDs corresponding to the distribution instances.

[0304] The DU response message contains the MAC / PHY configuration corresponding to the PTM distribution cell or distribution instance within the cell. For each MRB in a PTM delivery cell or PTM delivery instance of an MBS session, or for each MRB allowed in a CU request,

[0305] o DU response: Configuration information of the first RLC bearer corresponding to the MRB, further including the associated logical channel identification LCID1. In some scenarios, the logical channel identification may include LCID1 and LCID2.

[0306] The CU further contains uplink tunnel information corresponding to the MRB.

[0307] · The CU further indicates the mode of the RLC entity corresponding to the MRB, which may be acknowledged mode (AM), bidirectional unacknowledged mode (UM), unidirectional UM uplink, or unidirectional UM downlink.

[0308] The CU may also enable or activate retransmissions (such as PDCP retransmissions) for the MRB.

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

[0310] o DU response: Marking the second RLC bearer configuration and its logical channel identification LCID3, which corresponds to the primary path used to transmit the PDCP SR.

[0311] DU Response: A list of MRBs whose operations corresponding to the PTM delivery instances corresponding to the MBS session failed and the corresponding reasons. Generally applicable ID An MBS session may correspond to one MBS or category of MBS. An MBS session ID may be used to identify an MBS session and may be one of the following IDs or a combination thereof:

[0312] Session ID: The MBS session corresponds to the session ID in the session management mechanism of a certain UE, and uniquely defines the MBS session among multiple sessions of the UE. The session ID may be included in the SDAP configuration.

[0313] ·TMGI (Temporary Mobile Group Identification).

[0314] IP multicast addresses (with or without source addresses).

[0315] · gNB-CU MBS F1AP ID: The gNB-CU MBS F1AP ID uniquely identifies an MBS association across the F1 interface within a gNB-CU.

[0316] · gNB-DU MBS F1AP ID: The gNB-DU MBS F1AP ID uniquely identifies an MBS association across the F1 interface within a gNB-DU.

[0317] An identifier or index that can uniquely identify an MBS session on a CU or DU or F1 interface.

[0318] 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 the response message also contains the MBS session ID.

[0319] The CU request message further contains a description of the delivery mode, in which case the CU determines which UEs in the MBS session UE group are in which delivery mode.

[0320] The CU further includes the following delivery mode description in the request message, including 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, and UE2-UE10 use the PTM delivery mode. The above UE ID may be used to identify the UE and may be one of the following IDs or a combination thereof: gNB-CU UE F1AP ID gNB-DU UE F1AP ID C-RNTI

[0321] An identifier or index that can uniquely identify a UE on a CU or DU or F1 interface. General Provisions - MRB ID Information

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

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

[0324] The operation further includes QoS parameters for each MRB and QoS parameters mapped to QoS flows of the MRB. General Provisions-F1-U

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

[0326] In some embodiments, the CU uses the MBS session as the granularity and requests the DU to transmit MBS session data to the UE in PTP mode, i.e., the CU requests the DU to transmit service data of all MRBs of the MBS session in PTP mode. In some embodiments, for example, when air interface resources are limited or scarce, it is more desirable to include only data of specific MRBs instead of all MRB data of the MBS session in PTP delivery mode. The CU requests the DU to transmit specific MRBs or an MRB list of the MBS session in PTP mode.

[0327] In some embodiments, the DU receives a request from the CU to target a PTM delivery mode for an MBS session. For example, under the PTM delivery mode, MBS data is transmitted based on the granularity of the MBS session. For a specific request as described above, regardless of the delivery mode, for a specific MRB, if the DU accepts an MRB transmission request for an MBS session from the CU:

[0328] In some embodiments, as shown in FIG. 6 (downlink tunnel sharing), the CU uses IP multicast 610 to transmit MRB data to the DU using Tunnel 1. The CU message contains IP multicast downlink tunnel information for the MRB, i.e., the first downlink tunnel information. The tunnel information includes an IP multicast address, and optionally a source address and a GTP-TEID. The DU then joins the IP multicast group and receives the MBS. Tunnel 1 is above the IP layer based on IP multicast 610.

[0329] In some embodiments, as shown in FIG. 6 (downlink tunnel sharing), the CU transmits MRB data to the DU using IP point-to-point transmission 612. The F1-U tunnel information of 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 resource, which is the first downlink tunnel, and returns the corresponding first downlink tunnel information, including the IP address and the associated GTP-TEID, to the CU.

[0330] In some embodiments, if a DU previously had a delivery instance (including a PTP or PTM delivery instance) for an MRB corresponding to an MBS session, the same MRB for the same MBS session shares an F1-U downlink tunnel, and the DU returns downlink tunnel information over the F1-U interface, i.e., the first downlink tunnel, established for the MRB of the MBS session. For example, in FIG. 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 for the same MRB. PDCP PDUs generated by the PDCP entities corresponding to the MRB are submitted to the RLC entities (RLC entities 1, 2, and 3) after passing through the tunnel and then delivered to the corresponding delivery instances.

[0331] In some embodiments, the MRB uses an independent F1-U downlink tunnel; that is, 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. Thus, based on the request, the DU returns independent tunnel information for the MRB, which is the first downlink tunnel. For example, in FIG. 7 (independent downlink data tunnels), 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. PDCP PDUs generated by the PDCP entity corresponding to the MRB 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. Messages Related to PTP Requests and RLC Bearer Configuration The CU message instructs the UE to receive the MBS session in PTP mode, or the UE receives an MRB or MRB list with the MBS session in PTP mode. Regarding the MRBs allowed by this UE and DU,

[0332] The CU message further indicates the RLC entity mode corresponding to the MRB, which may be AM or UM. If the DU accepts the corresponding MRB transmission request in the PTP mode, the DU creates or modifies the RLC entity corresponding to the MRB, allocates corresponding MAC resources such as logical channels, and returns a corresponding second RLC bearer configuration in a response message. The RLC bearer configuration is included in the cell group configuration and is further included in the DU-CU RRC information to be sent to the CU.

[0333] The CU message further commands uplink tunnel information corresponding to the MRB, specifically, the IP address and associated GTP-TEID. In some scenarios, the F1-U tunnel is used to transmit the corresponding PDCP status report (PDCP SR) generated by the UE related to MRB data reception. As shown in Figures 8 and 9, for UE1, the PDCP status reports 810 and 910 of the MRB are transmitted through Tunnel 2 to the PDCP entity on the network side, i.e., in the CU. When the CU enables or activates PDCP retransmissions for the MRB, there may be different scenarios regarding how the F1-U downlink tunnel is shared.

[0334] In some embodiments, the CU transmits MRB data to the DU using multicast. Referring to Figure 8, Tunnel 1 information is provided by the CU, while Tunnel 2 information is provided by the DU. For MRB data transmission, initial data transmissions for different delivery instances share Tunnel 1.

[0335] In some embodiments, the CU transmits MRB data to the DU using point-to-point. Referring to Figure 8, both Tunnel 1 and Tunnel 2 information are provided by the DU. For MRB data transmission, initial data transmissions for different delivery instances share Tunnel 1. For the UE, MRB data retransmissions use Tunnel 2. Both the initial data and retransmitted data are delivered to RLC entity 2 corresponding to the PTP delivery instance for UE 1.

[0336] In some embodiments, the same MRB in different distribution instances uses independent tunnels. Referring to Figure 9 (independent tunnels for distribution instances 902 and 904), distribution instances for other UEs use Tunnel 1 associated with RLC entity 1, while the PTP distribution instance for UE 1 uses Tunnel 2 associated with RLC entity 2. For UE 2, MRB data initial transmissions and retransmissions share Tunnel 2. In this scenario, Tunnel 2 is bidirectional because it can also be used as an uplink tunnel for transmission of PDCP SRs corresponding to the MRB. DU handling denies creation of some MRBs

[0337] For a CU message specifying a PTP delivery mode for a UE, the DU may reject the creation or modification of one or more MRBs. In this case, the DU returns an MRB list containing the MRBs that failed to be created or modified and the reason for the failure.

[0338] The CU message may further contain uplink tunnel information corresponding to each MRB mentioned above. PTM related requirements

[0339] Since this embodiment is based on per-MBS signaling, the main difference with embodiment 1 is that the per-MBS signaling may or may not carry any UE information to indicate operation or configuration to a specific UE or implicitly to a group of UEs.

[0340] Each PTM delivery instance always corresponds to a specific transmission cell. According to different implementations, when a UE receiving an MBS session is in a connected state, the context about the cell associated with the UE exists on both the CU side and the DU side. The transmission cell information may be provided by the CU or the DU. That is, the CU may only provide a UE list containing UEs using PTP mode, and the DU determines the cell or cell list corresponding to the PTM transmission according to the UE connection status or other information, and further determines the delivery instance ID in each cell.

[0341] For example, in one embodiment, an MBS session may be allowed to be transmitted in a cell based on multiple delivery instances. Furthermore, these delivery instances may need to be characterized by a unique delivery instance ID in a DU, which uniquely defines the delivery instance in combination with a cell identifier and a unique identifier in the cell. For example, in one embodiment, UE6, UE7, and UE8 may correspond to a first delivery instance in cell 3, and UE9 and UE10 may correspond to a second delivery instance in cell 3.

[0342] The CU further includes the following receive mode description in the request message, indicating that the service data of the MBS session is transmitted in PTM mode: The DU response message contains a list of PTM delivery instances for multiple possibilities, and each delivery instance may further be associated with a list of UE IDs.

[0343] In one scenario, in the PTM transmission request, the CU includes a UE ID list associated with the PTM distribution mode, and the CU does not specify cell information or distribution instance IDs in the corresponding cells for PTM transmission for the UE's MBS. In response to receiving the request, the DU generates corresponding scheduling results, such as cells in the DU to which PTM transmission should be performed and cell-to-distribution instance ID mapping, based on each cell to which each UE is connected and the UE's connection status in each cell. Based on the scheduling results, the DU includes, in a response message, an optional PTM distribution cell or cell list, or alternatively, a PTM distribution instance ID corresponding to the PTM distribution cell, and optionally, a UE ID list corresponding to the distribution instance. In addition, the DU also provides scheduling information corresponding to the cell or distribution instance.

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

[0345] In one scenario, in the PTM transmission request, the CU includes a cell list associated with the PTM distribution mode and a distribution instance ID list associated with each cell in the cell list, and each distribution instance may further be associated with a UE ID list. That is, the CU specifies the cell and distribution instance ID associated with the PTM transmission. In response to receiving the request, the DU generates scheduling parameters associated with each distribution instance in each cell based on the connection status of the UE. Based on the scheduling result, the DU includes in the response message an optional PTM distribution cell or cell list, or alternatively, a PTM distribution instance ID corresponding to the PTM distribution cell, and optionally a UE ID list corresponding to the distribution instance. In addition, the DU also provides scheduling information corresponding to the cell or distribution instance.

[0346] The above scheduling information includes a MAC / PHY configuration corresponding to a PTM delivery instance, and may also include the following information or a combination of the following information: -DRX information corresponding to this PTM distribution instance. · The Radio Network Temporary Identifier (RNTI) for the PTM distribution instance. · Time domain scheduling information corresponding to the PTM delivery instance to indicate the subframe or slot in which the PTM transmission is scheduled. Frequency domain resource allocation information corresponding to the PTM distribution instance.

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

[0348] · BWP (Bandwidth Portion) information corresponding to the PTM delivery instance. PTM related requests, RLC bearer configuration

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

[0350] In some embodiments, if the DU accepts the corresponding MRB transmission request in PTM mode, the DU must include in the response message the RLC bearer configuration information corresponding to each MRB for the MBS session, including the logical channel ID corresponding to the MRB. In some embodiments, for each UE associated with a delivery instance:

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

[0352] In some scenarios, the network uses a bidirectional tunnel to enable PDCP data retransmissions for MRBs in PTM transmissions for the UE. The UE relies on two independent RLC entities: RLC entity 1 for performing the initial MRB data transmission in PTM mode, and a UE-specific RLC entity 2 for performing MRB data retransmissions and transmission of PDCP SRs corresponding to the MRBs.

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

[0354] If the CU enables or activates PDCP retransmission for the MRB, the DU returns second downlink tunnel information, including an IP address and associated GTP-TEID. Here, there are two tunnels corresponding to the MRB on the F1 interface. The first downlink tunnel may be used to transmit initial transmission data corresponding to the MRB, and the second downlink tunnel may be used to transmit retransmission data corresponding to the MRB and uplink PDCP SR.

[0355] The CU further 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 corresponding MAC resources such as logical channels, and returns a corresponding second RLC bearer configuration in a response message. The RLC bearer configuration is included in the cell group configuration and further included in the DU-CU RRC information to be sent to the CU. DU handling denies creation of some MRBs

[0356] For a CU message specifying a PTM delivery mode, the DU creates a PTM delivery instance or a PTM delivery instance list. For each delivery instance, the DU may reject the creation or modification of one or more MRBs due to resource or other reasons. In this case, the DU returns an MRB list containing the MRBs that failed to be created or modified and the reason for the failure. Handling dual modes using both PTP and PTM

[0357] In some embodiments, for a particular UE, the CU may request both PTP and PTM delivery modes, and the DU may allocate corresponding resources, so that the UE may be able to receive MRB data in PTP and PTM modes simultaneously. Example of Embodiment 2

[0358] Refer to Figure 4 for an exemplary CU determination of UE delivery modes for an MBS session. Based on the CU determination, UE1 uses the PTP delivery mode, and UE2-UE5 use the PTM delivery mode. In some scenarios, the CU further determines that some UEs, such as UE2 and UE3, use the PTM delivery mode in one cell under the DU, and UE4 and UE5 use the PTM delivery mode in another cell under the DU. Specific signaling may or may not carry corresponding UE ID lists. In some scenarios, the DU may implement multiple PTM delivery instances in a cell based on interaction with the CU.

[0359] In some scenarios, the CU does not determine the cell in which the PTM distribution instance resides, but instructs a UE to receive using PTM or PTM mode. At this point, the DU determines the number of PTM distribution instances to generate and the associated cells. In some scenarios, the DU may generate multiple PTM distribution instances in a cell.

[0360] In addition, the PDCP PDUs generated for the corresponding PDCP PDUs corresponding to the MBS may be delivered to the DUs through a shared tunnel or may be delivered to the DUs through independent tunnels.

[0361] The following describes the above scenarios separately: The configurations per UE may not be presented in the same F1 signaling at the same time, as the configurations may be presented in different F1 signaling at different times.

[0362] After receiving the decision from the CU, the DU performs MBS reception scheduling 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.

[0363] In the context setup 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 across the F1 interface. These signaling messages may further carry an MBS session ID or MBS ID corresponding to the MBS, such as an IP multicast address, to inform the DU of the MBS identification.

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

[0365] In a signaling message, the CU may instruct a specific UE or a list of UEs to receive a specific MRB or an entire MBS in PTP mode. The entire MBS indicates all corresponding MRBs associated with it. The UE list may be identified by the gNB-CU UE F1AP ID or gNB-DU UE F1AP ID of the UE on the F1 interface.

[0366] The signaling may further carry an RLC entity mode corresponding to a specific MRB for a specific UE, which may be AM or UM mode. For example, if the QoS requirements corresponding to an MRB of an MBS are not delay-sensitive but require high reliability, the corresponding RLC entity may be configured in AM mode. On the other hand, if the QoS requirements are delay-sensitive, the corresponding RLC entity may be configured in UM mode. Referring to Figures 8 and 9, in some scenarios, for UE1, an uplink tunnel shown as tunnel 2 needs to be established to transport uplink data, e.g., feedback information such as a PDCP status report generated by UE1 related to MRB data reception. In this case, the signaling may further carry a user plane uplink tunnel address corresponding to a specific MRB for UE1.

[0367] After receiving the CU request, if the DU can allocate the corresponding resource, in the returned response message, the DU will return downlink tunnel information for the specific MRB of the UE in the above request. Referring to Figure 8, Tunnel 2 is now 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 the specific UE.

[0368] In some scenarios, the CU carries an IP multicast address for transmitting PDCP PDUs 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. Referring to Figures 6 and 7, RLC entity 1, RLC entity 2, and RLC entity 3 are associated with the same MRB and share tunnel 1, and service data is simultaneously submitted to RLC entity 1, RLC entity 2, and RLC entity 3.

[0369] In some scenarios, the DU may return downlink tunnel information for the MBS in response to the request, and thus a downlink tunnel from the CU to the DU may be created. The PDCP PDUs corresponding to the MRBs of the MBS are transmitted to the DU through the downlink tunnel and simultaneously submitted to all RLC entities associated with the MRBs.

[0370] There are at least two solutions distinguished by the information in the signaling sent from the CU to the DU to create a specific PTM delivery instance: In the first solution, the signaling contains a cell list containing the cells on which the MBS is scheduled; in the second solution, the signaling contains a UE ID list containing the UEs that are assigned to use PTM mode. Each solution is described in detail below.

[0371] In the first solution, during the CU determination process, the CU not only determines the delivery mode for the UE, whether it is PTP or PTM. The CU also determines the cells under the DU where PTM transmission will occur. Therefore, the CU-DU signaling carries a cell list for instructing PTM transmission. On the DU side, for each cell in the cell list, the DU allocates corresponding PTM resources for the MBS or denies part of the QoS flow, and further denies the creation of the corresponding MRB. Therefore, the DU response message contains the MRB creation results for the MBS on a cell-by-cell basis. If some MRBs fail to be created, the message returns the failed MRBs and the corresponding failure reasons.

[0372] Optionally, if the signaling carries a list of UEs using PTM mode, the response message from the DU may carry a first logical channel ID (LCID1) for each UE, where the LCID identifies the logical channel that is the primary path for the UE to send a status report. In addition, the DU may further carry a second logical channel ID (LCID2), which is the LCID used by the UE to receive MRBs of the MBS. For example, LCID1 is associated with LCID2, and after the UE receives the MAC PDU, the UE submits data marked with LCID1 to the logical channel identified by LCID2 for further processing.

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

[0374] In order to meet the QoS requirements of the MBS, in the CU-DU signaling, there are QoS parameters corresponding to each MRB and QoS parameters of the QoS flows corresponding to the MRB, and therefore the DU may allocate appropriate resources based on the QoS parameters.

[0375] For a certain MRB, 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 implementations for passing MRB data.

[0376] In the first case, the CU distributes the MRB data to the DUs using IP multicast. The CU-DU signaling carries the IP multicast address and TEID. The DUs can then join the multicast group and receive the MRB data from the tunnel.

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

[0378] In this embodiment, the various categories of requests and responses described above related to a PTP delivery instance for a particular UE may be conveyed using a UE association signaling message format, while the various categories of requests and responses described above related to a particular PTM delivery instance may be conveyed using an MBS association signaling message format.

[0379] If the CU determines that some UEs receive the MBS in PTP mode (Group 1 UEs) while some UEs receive the MBS in PTM mode (Group 2 UEs), then: For Group 1 UEs, the CU uses per-UE F1 signaling (or UE association signaling), such as UE context setup or UE context modification signaling; For Group 2 UEs, the CU uses per-MBS F1 signaling (or MBS association signaling), such as MBS context setup or MBS context modification signaling. In either case, the CU uses corresponding F1 signaling, sends a decision to the DU, and requests the DU to allocate corresponding resources. The MBS association signaling may apply to one UE or multiple UEs or one cell or multiple cells.

[0380] In response to receiving requests from the CU, the DU attempts to allocate resources for each request. The DU then sends response information to the CU, providing feedback on whether each MRB was successfully created. Additionally, for each successfully created MRB, the DU creates a configuration for the particular MRB and returns the configuration to the CU.

[0381] 5, the signaling messages are generally referred to as MBS context setup or MBS context modification, which may be further classified into two types of operations: per-UE F1 messages and per-MBS F1 messages. The contents contained in the above signaling are described separately below.

[0382] For Group 1 UEs using PTP receive mode, the CU uses per-UE F1 signaling, such as UE context setup or UE context modification signaling. The present disclosure extends the current per-UE signaling to include at least one of the parameters in a signaling message initiated from the CU.

[0383] ·gNB-CU UE F1AP ID.

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

[0385] MBS session ID.

[0386] · A list of MRB IDs containing the radio bearers serving the MBS and, optionally, a radio bearer ID the UE uses during UE-side data processing associated with each MRB in the MRB list.

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

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

[0389] User plane uplink tunnel address for the UE associated with the MRB. The user plane uplink tunnel address is used by the UE to perform MBS status reporting.

[0390] For each RB serving a 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 source address) and the corresponding TEID.

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

[0392] Correspondingly, the present disclosure extends the current per-UE signaling to include at least one of the parameters in signaling messages initiated from the DU, which may be response messages or autonomous messages.

[0393] ·gNB-CU UE F1AP ID.

[0394] ·gNB-DU UE F1AP ID.

[0395] MBS session ID.

[0396] A list of successfully created or modified MRBs.

[0397] -Downlink tunnel information for each MRB.

[0398] A list of MRBs that failed to be created or modified.

[0399] Cell group configuration update for the UE, which may be DU-CU RRC information.

[0400] Similarly, for Group 2 UEs using PTM delivery mode, the CU uses per-MBS F1 signaling, such as MBS context setup or MBS context modification signaling. The present disclosure extends the current per-MBS UE signaling to include at least one of the parameters in a signaling message initiated from the CU.

[0401] ·gNB-CU UE F1AP ID.

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

[0403] MBS session ID.

[0404] A list of MRB IDs containing radio bearers serving the MBS.

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

[0406] A cell list containing the cells for which the MBS is scheduled. Optionally, a corresponding PTM instance ID list per cell and a UE ID list per PTM instance.

[0407] A UE ID list containing UEs that use the PTM delivery mode. Optionally, an RB ID list and a mapping RB ID used by the UE for each MRB in the RB ID list.

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

[0409] The UE ID may be a gNB-CU UE F1AP ID or a gNB-DU UE F1AP ID used to uniquely identify a logical connection of a UE on an F1 interface within a CU or DU. The UE ID may also be a UE group index that may be used to aid in subsequent scheduling of the DU, such as determining feedback resources.

[0410] Correspondingly, the present disclosure extends the current per-MBS signaling to include at least one of the parameters in signaling messages initiated from the DU, which may be response messages or autonomous messages.

[0411] ·gNB-CU UE F1AP ID.

[0412] ·gNB-DU UE F1AP ID.

[0413] MBS session ID.

[0414] For each UE using PTM mode, its associated cell or cell list, and optionally the corresponding PTM instance ID for each cell. Optionally, a cell list for each PTM distribution instance in the cell.

[0415] A list of MRB IDs containing MRBs accepted by the DU to serve the MBS, and another list of MRBs containing MRBs rejected by the DU.

[0416] ○ Corresponding MAC / PHY configuration for each MRB.

[0417] Optionally, per-UE feedback configuration.

[0418] Optionally, for each allowed MRB, its corresponding F1-U tunnel information, including downlink IP address and TEID.

[0419] -LCID configuration per UE. Exemplary implementation of embodiment 3

[0420] In this embodiment, the CU determines that for an MBS group, some UEs use the PTP delivery mode (Group 1 UEs) and some UEs use the PTM delivery mode (Group 2 UEs). The CU uses different signaling types for different groups of UEs, i.e., per-UE signaling for Group 1 UEs and per-MBS signaling for Group 2 UEs.

[0421] The CU first determines that UE1 receives the MBS in PTP mode, then the CU creates F1 signaling for each corresponding UE and sends the signaling to the DU. The specific process is described below. The information elements are listed in both the request message and the response message with detailed descriptions. gNB-CU UE F1AP ID, optionally gNB-DU UE F1AP ID

[0422] The per-UE context setup / modification signaling initiated from the CU is identified by the gNB-CU UE F1AP ID. This ID indicates that the signaling is of per-UE type and targets UE1, which receives the MBS in PTP mode. Therefore, the corresponding DU response message contains the gNB-CU UE F1AP ID and the gNB-DU Carries the UE F1AP ID, and the gNB-DU UE F1AP ID is used to uniquely identify the UE's logical connection on the F1 interface within the DU.

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

[0424] In some scenarios, for an MRB serving an 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. Therefore, the F1 signaling does not need to carry the MBS session ID, and the MRB ID itself may 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 that is mapped to a unique F1-U tunnel, thus saving transport resources between the CU and the DU. An MRB list containing MRBs needs to be created or modified.

[0425] The MRB list may list all or only some of the MRBs serving the MBS. If the F1 signaling for instructing the UE delivery mode switch is based on per-service granularity, the signaling applies to all MRBs for the MBS. In this case, the signaling message may carry all MRBs or only the MBS ID. For each MRB in the MRB list, additional information is carried in the message.

[0426] MRB ID. In some scenarios, the MRB ID (RBID1) of each MRB is associated with a second RB ID (RBID2) that is used by the UE to process PDUs. Subsequently, when the DU configures an RLC bearer, the DU sets the corresponding served radio bearer to RBID2.

[0427] Per-MRB QoS parameters and corresponding flow-level QoS parameters. DUs must use these parameters to perform MRB scheduling.

[0428] Notification control configuration: If the notification control corresponding to the MRB is active, the DU may 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 determine whether a UE delivery mode switch is required.

[0429] Corresponding RLC Mode—Based on the MBS characteristics, the RLC entity associated with the MRB is configured to be in AM mode or UM mode. For example, if the QoS requirements for the corresponding MRB are not sensitive to time delay but require high reliability, the corresponding RLC instance may be set to AM mode, whereas if the QoS requirements for the corresponding RB are time sensitive, the corresponding RLC instance may be set to UM mode.

[0430] UE user plane uplink tunnel address corresponding to the MRB associated with the UE. If the RB is configured to implement PDCP status reporting, the CU needs to assign 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.

[0431] Downlink tunnel information (IP multicast)—If the MRB is distributed from the CU to the DU using IP multicast, the CU needs to provide an IP multicast address along with its corresponding tunnel end ID (TEID) for the MRB and adds the information in the F1 signaling message. The DU can then join the IP multicast group and receive the downlink data. In some scenarios, for a particular MRB, multiple UEs receiving the MBS can share a downlink tunnel on the F1-U link, regardless of the UE's 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 PTP mode and UEs receiving the MRB using PTM mode use independent downlink tunnels on the F1-U link, and the downlink tunnels are mapped to different IP multicast addresses and TEIDs. See 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, which is tunnel 2, as shown in Figure 8. The DU further creates the corresponding RLC entity 2 configuration and associated LCID information, and 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 the PDCP status report for this MRB.

[0432] Downlink Tunnel Information (IP Point-to-Point)—If the DU allows creation or modification of an MRB and the MRB is distributed from the CU to the DU using the point-to-point protocol, the DU returns 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 a shared downlink tunnel to serve a specific MRB, thus saving resources on the F1-U link. In this case, the DU may return information about existing tunnels, including IP addresses and TEIDs. See 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 may then return information about two user plane downlink tunnels, namely, Tunnel 1 and Tunnel 2, as shown in Figure 8. Tunnel 1 is used to transport MRB data, which may be shared by other UEs. Tunnel 2 is for MRB data retransmission. At the same time, the DU creates the corresponding RLC entity 2 configuration. RLC entity 2 receives PDCP PDUs from the CU and then transmits PDU data to UE 1 in PTP mode. Alternatively, it can be used for PDCP layer data retransmission. The response message from the DU may carry corresponding logical channel ID (LCID) information, which identifies the logical channel corresponding to the primary RLC on the UE side for transmitting the PDCP status report. After receiving the PDCP PDU corresponding to the MRB from 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 returns only information about one user plane downlink tunnel, and the initial MRB data transmission and possible retransmission by the CU are performed on this same tunnel.

[0433] If the DU does not accept the MRB, the DU will return an MRB list containing the MRBs that it failed to create or modify in the response message. In this case, the tunnel information may not apply.

[0434] The CU then determines that UE2-UE10 receive MBSs in PTM mode, creates F1 signaling for each corresponding MBS, and sends the signaling to the DU, so that the DU can create an MBS session context and allocate corresponding resources for the PTM instance. The specific process is described below. The information elements are listed in both the request message and the response message. gNB-CU MBS F1AP ID and gNB-DU MBS F1AP ID

[0435] The CU signaling message carries at least the gNB-CU MBS F1AP ID to uniquely identify the MBS session within the CU across the F1 interface. Similarly, the DU may carry the gNB-CU MBS F1AP ID in the response message to uniquely identify the MBS session within the DU across the F1 interface. Returns ID and gNB-DU MBS F1AP ID information. (MBS identifier) The MBS identifier may be one of the following:

[0436] ·TMGI (Temporary Mobile Group Identification).

[0437] IP multicast addresses (with or without source addresses).

[0438] ·MBS ID.

[0439] Any other identifier or index that can uniquely identify the MBS across the F1 interface.

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

[0441] In some scenarios, for a particular MRB, transport of MRB data 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. MRB List 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.

[0442] MRB ID. In some scenarios, the MRB ID (RBID1) of each MRB is associated with a second RB ID (RBID2) that is used by the UE to process PDUs. Subsequently, when the DU configures an RLC bearer, the DU sets the corresponding served radio bearer to RBID2.

[0443] Per-MRB QoS parameters and corresponding flow-level QoS parameters. DUs must use these parameters to perform MRB scheduling.

[0444] Notification control configuration: If the notification control corresponding to the MRB is active, the DU may 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 determine whether a UE delivery mode switch is required.

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

[0446] 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 along with its corresponding tunnel end ID (TEID) for the MRB and add the information in the F1 signaling message. If the DU accepts the MRB, it can join the IP multicast group and receive downlink data. Cell Information

[0447] There are two solutions for the CU to carry the cell list, each of which is listed below. Solution A:

[0448] The F1 signaling message contains a cell list containing cells scheduled by the MBS, optionally a PTM distribution instance list under each cell, and optionally a corresponding UE ID list.

[0449] During the CU determination process, the CU not only determines the distribution mode for the UE, whether it is PTP or PTM, but also determines the cell under the DU in which PTM transmission will occur, optionally a PTM distribution instance under the cell. For example, the CU determines that UE1 uses PTP mode in cell 1, UE2 and UE3 use PTM mode in cell 1, and UE4 and UE5 use PTM mode in cell 2. The CU signaling message carries a cell list under the DU. Correspondingly, after receiving the message, the DU allocates PTM resources for MBSs in each cell or rejects the creation or modification of some or all of the MRBs for the MBSs.

[0450] The DU response message contains the MRB creation result for the MBS on a cell-by-cell basis. Optionally, the DU response message carries all PTM delivery instances under each cell and their PTM resource allocation results, including the RLC entity configuration and corresponding MAC / PHY configuration. If the CU signaling message contains a UE ID list, the DU may provide a UE-specific RLC entity configuration. If the CU signaling message further contains a UE ID list for each PTM delivery instance, optionally, the CU message contains a mapping from all MRBs of the MBS (RBID1) 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 served radio bearer field in the RLC bearer configuration is set to RBID2 by the DU.

[0451] In some scenarios, the CU does not specify a PTM delivery instance ID in the transmission cell; rather, the DU carries the PTM delivery instance information and, optionally, an associated UE list in the response message. Referring to Figure 4, the CU determines that UE6-UE10 use PTM mode under cell 3, and the DU further determines that UE6, UE7, and UE8 use PTM delivery instance 3 (PTM3), and UE9 and UE10 use PTM delivery instance 4 (PTM4). Solution B:

[0452] The F1 signaling message contains a UE ID list containing UEs that use PTM mode.

[0453] The CU message does not specify cell information, but only contains UE IDs and their corresponding distribution modes. For example, referring to FIG. 4, UE2-UE10 all use PTM mode to receive MBS. On the DU side, based on the connection status of each UE and its capabilities, the DU allocates PTM distribution cells for the UEs, and optionally PTM distribution instances in the PTM distribution cells. In some embodiments, the DU flexibly schedules PTM scheduling parameters based on the connection status context of each UE in each cell and the available resources in each cell. Therefore, the decision by the DU is sometimes more efficient.

[0454] In some scenarios, the DU may implement multiple PTM distribution instances in a cell for UEs in the same MBS group and allocate corresponding MAC / PHY configurations. The DU sends the configurations to the CU on a cell-by-cell basis, i.e., for each cell, the DU returns a MAC / PHY configuration list. The above scheduling results may be included in DU-CU information and sent to the CU. In some scenarios, the above configurations may be broadcast in the corresponding cells together with the corresponding MRB configurations, and thus the information may be sent to the UEs.

[0455] For example, referring to Figure 4, the DU determines that UE2 and UE3 use delivery instance PTM1 under cell 1, UE4 and UE5 use 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 further selects a MAC / PHY configuration corresponding to each PTM delivery instance, adds the configuration information to a response message, and sends the response message to the CU either per cell or per PTM instance within the cell.

[0456] Based on the UE ID list, the DU may then provide a UE-specific RLC entity configuration, including an RLC bearer configuration. If the CU signaling message further contains a UE ID list for each PTM delivery instance, optionally, the CU message contains a mapping of all MRBs of the MBS (RBID1) to RBID2, where RBID2 is the radio bearer ID used by the UE when processing PDCP PDUs. Additionally, in the RLC bearer configuration created by the DU for the UE, the served radio bearer field in the RLC bearer configuration is set to RBID2 by the DU.

[0457] If the MRB is distributed from the CU to the DU using IP multicast and the MRB transports for different PTP and PTM distribution instances share the same F1-U downlink tunnel, the CU needs to provide the IP multicast address along with its corresponding TEID for the MRB and add the information in the F1 signaling message. The DU can then join the IP multicast group and receive the downlink data.

[0458] When the MRB is distributed from the CU to the DU using a point-to-point protocol, on the DU side, the MBS ID and the corresponding MRB in the F1 signaling message are Based on the ID, the DU will access the pre-established For a given MRB in an MBS, different PTM distribution instances in different cells or the same cell may share a single tunnel between the CU and the DU.

[0459] The UE ID in the UE ID list may be a gNB-CU UE F1AP ID or a gNB-DU UE F1AP ID used to uniquely identify the UE's logical connection on the F1 interface within a CU or DU. The UE ID may also be a UE group index that may be used to aid in subsequent scheduling of the DU, such as determining feedback resources. In some scenarios, the CU message may contain only the UE group index or UE index in subsequent air interface resource allocation, and the DU may use the UE index to uniquely identify HARQ or CSI-RS feedback resources for the UE.

[0460] In some embodiments, a per-UE signaling message may be used only to notify the DU that the UE needs to join an MBS group, which may be implicitly identified by service information such as an MBS session ID in the message. Subsequent MBS management may be achieved by using per-MBS signaling conversations. Such MBS management includes DRB updates and QoS-related information updates.

[0461] Throughout this specification and the claims, terms may have subtle meanings suggested or implied in context other than those explicitly stated. Similarly, the phrase "in one embodiment / implementation" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment / implementation" as used herein does not necessarily refer to a different embodiment. For example, it is intended that the claimed subject matter include, in whole or in part, any combination of the example embodiments.

[0462] Generally, terminology can be understood, at least in part, from its use in context. For example, terms such as "and," "or," or "and / or," as used herein, can include a variety of meanings that may depend, at least in part, on the context in which such terms are used. Typically, when "or" is used to relate a list such as A, B, or C, it is intended to refer to A, B, and C, used herein in an inclusive sense, and to A, B, or C, used herein in an exclusive sense. Additionally, the term "one or more," as used herein, can be used to describe any feature, structure, or characteristic in a singular sense, or can be used to describe a combination of features, structures, or characteristics in a plural sense, depending, at least in part, on the context. Similarly, terms such as "a," "an," or "the" can be understood to convey the use of the singular or to convey the use of the plural, depending, at least in part, on the context. Additionally, the term "based on" can be understood not to necessarily convey an exclusive set of factors, but instead, can allow for the existence of additional factors not necessarily specifically described, again, depending, at least in part, on the context.

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

[0464] Furthermore, the described features, advantages, and characteristics of the solution may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize, in light of the description herein, that the solution may be practiced without one or more of the specific features or advantages of a particular embodiment. In other cases, additional features and advantages may be recognized in some embodiments that may not be present in all embodiments of the solution.

Claims

1. 1. A method for radio resource allocation implemented by a first access network node (ANN) in communication with a second ANN in a wireless communication network, comprising: receiving one or more requests for establishing, modifying, or releasing a resource allocation in a first ANN from a second ANN for transmitting service data of a Multicast / Broadcast Service (MBS) session in a Point-to-Point (PTP) distribution mode and a Point-to-Multipoint (PTM) distribution mode to a set of User Equipments (UEs) and for communicating control information between the first ANN and the second ANN, the one or more requests comprising an MBS session identifier; establishing the resource allocation in the first ANN based on the one or more requests; and Including, The one or more requirements may include: a UE identifier for indicating a target UE of the request; a distinct UE-specific RB identifier for at least one of the sets of RBs for at least one specific UE of the set of UEs; and The method further comprises:

2. 2. The method of claim 1, wherein the one or more requests further comprise a set of Radio Bearer (RB) identifiers to uniquely identify, together with the MBS session identifier, a set of RBs allocated by the second ANN to a Quality of Service (QoS) flow of the MBS session.

3. The one or more requirements may include: a first set of QoS parameters corresponding to each RB in the set of RBs; a second set of QoS parameters for each of the QoS flows that are mapped to the set of RBs; and The method of claim 2 , further comprising:

4. the at least one or more requests comprising a set of information items; 3. The method of claim 2, further comprising: establishing, modifying, or releasing, by the first ANN, the resource allocation corresponding to a plurality of delivery instances for transmission of MBS Session Protocol Data Units (PDUs) of the MBS session based on the set of information items.

5. The method of claim 4 , wherein each of the plurality of delivery instances is either a PTP delivery instance or a PTM delivery instance.

6. The method of claim 5, wherein for each set of UEs, a transmission mode is determined by the first ANN, the transmission mode being either a PTP transmission mode, a PTM transmission mode, or both the PTP transmission mode and the PTM transmission mode.

7. determining downlink data tunnel information for receiving PDCP PDUs associated with a RB in the first ANN; including the downlink data tunnel information in configuration information for transmission to the second ANN; receiving the PDCP PDU associated with the RB from the second ANN according to the downlink data tunnel information; The method of claim 2 , further comprising:

8. 3. The method of claim 2, wherein the one or more requests further comprise a retransmission activation indication associated with a UE of the set of UEs and associated with a RB of the set of RBs.

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

10. 1. A first Access Network Node (ANN), the first ANN comprising: a memory for storing computer instructions; and a processor in communication with the memory, the processor executing the computer instructions causing the processor to: receiving one or more requests for establishing, modifying, or releasing a resource allocation in a first ANN from a second ANN for transmitting service data of a Multicast / Broadcast Service (MBS) session in a Point-to-Point (PTP) distribution mode and a Point-to-Multipoint (PTM) distribution mode to a set of User Equipments (UEs) and for communicating control information between the first ANN and the second ANN, the one or more requests comprising an MBS session identifier; establishing the resource allocation in the first ANN based on the one or more requests; and and causing the first ANN to perform The one or more requirements may include: a UE identifier for indicating a target UE of the request; a distinct UE-specific RB identifier for at least one of the sets of RBs for at least one specific UE of the set of UEs; and The first ANN further comprises:

11. The first ANN of claim 10, wherein the one or more requests further comprise a set of Radio Bearer (RB) identifiers for uniquely identifying, together with the MBS session identifier, a set of RBs allocated by the second ANN to a Quality of Service (QoS) flow of the MBS session.

12. The one or more requirements may include: a first set of QoS parameters corresponding to each RB in the set of RBs; a second set of QoS parameters for each of the QoS flows that are mapped to the set of RBs; and The first ANN of claim 11 further comprising:

13. the at least one or more requests comprising a set of information items; The first ANN of claim 11, wherein when the processor executes the computer instructions, the processor is further configured to cause the first ANN to establish, modify, or release the resource allocation corresponding to multiple delivery instances for transmission of MBS session protocol data units (PDUs) of the MBS session based on the set of information items.

14. The first ANN of claim 13, wherein each of the plurality of delivery instances is either a PTP delivery instance or a PTM delivery instance.

15. The first ANN of claim 14, wherein for each set of UEs, a distribution mode is determined by the first ANN, the distribution mode being either a PTP distribution mode, a PTM distribution mode, or both the PTP distribution mode and the PTM distribution mode.

16. A non-transitory storage medium for storing computer readable instructions, the computer readable instructions, when executed by a processor of a first access network node (ANN), comprising: receiving one or more requests for establishing, modifying, or releasing a resource allocation in a first ANN from a second ANN for transmitting service data of a Multicast / Broadcast Service (MBS) session in a Point-to-Point (PTP) distribution mode and a Point-to-Multipoint (PTM) distribution mode to a set of User Equipments (UEs) and for communicating control information between the first ANN and the second ANN, the one or more requests comprising an MBS session identifier; establishing the resource allocation in the first ANN based on the one or more requests; and causing said processor to perform The one or more requirements may include: a UE identifier for indicating a target UE of the request; a distinct UE-specific RB identifier for at least one of the sets of RBs for at least one specific UE of the set of UEs; and The non-transitory storage medium further comprises:

17. 17. The non-transitory storage medium of claim 16, wherein the one or more requests further comprise a set of Radio Bearer (RB) identifiers for uniquely identifying, together with the MBS session identifier, a set of RBs allocated by the second ANN to a Quality of Service (QoS) flow of the MBS session.

18. The one or more requirements may include: a first set of QoS parameters corresponding to each RB in the set of RBs; a second set of QoS parameters for each of the QoS flows that are mapped to the set of RBs; and The non-transitory storage medium of claim 17 further comprising:

19. the at least one or more requests comprising a set of information items; 20. The non-transitory storage medium of claim 17, wherein the computer-readable instructions are further configured to cause the processor to establish, modify, or release the resource allocation corresponding to a plurality of delivery instances for transmission of MBS Session Protocol Data Units (PDUs) of the MBS session based on the set of information items.

20. 20. The non-transitory storage medium of claim 19, wherein each of the plurality of delivery instances is either a PTP delivery instance or a PTM delivery instance.

Images