Access network signaling and resource allocation for multicast / broadcast sessions

Abstract

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

Description

Technical Field

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

[0002] There has always been a demand for multicast broadcast services (MBS) in wireless communication networks. This service has gradually expanded from the initial TV-like terrestrial broadcast video broadcast 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 urgently needed to achieve reliable and efficient MBS session data delivery to multiple user equipments (UEs) with different reception conditions and requirements. Summary of the invention

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

[0004] In some exemplary embodiments, a method for wireless resource allocation is disclosed, the method being performed by a first access network node (ANN) in communication with a second ANN in an access network of a wireless communication network. The method may include: receiving context information of a multicast / broadcast service (MBS) session from a core network; performing a first resource allocation for the MBS session; identifying a group of user equipments (UEs) for which the MBS session is intended and served by the second ANN; dividing the group of UEs into a first subset and a second subset of UEs for receiving MBS session data from the second ANN over an air interface in a point-to-point (PTP) mode and a point-to-multipoint (PTM) mode, respectively, or receiving the division from the second ANN; sending one or more signaling messages to the second ANN according to a predetermined signaling message format, each signaling message including an identifier for the MBS session, so that the second ANN performs establishment, modification or release of a second resource allocation and configuration for the MBS session; and receiving one or more response messages based on the predetermined signaling message format from the second ANN.

[0005] In some other embodiments, a method for wireless resource allocation is disclosed, which is performed by a first access network node (ANN) and a second ANN in an access network of a wireless communication network. The method may include: receiving context information of a multicast / broadcast service (MBS) session from a core network by the first ANN; allocating at least one radio bearer (RB) for the MBS session by the first ANN; identifying a group of user equipments (UEs) targeted by the MBS session and served by the second ANN by the first ANN; dividing the group of UEs into a first subset and a second subset of UEs by the first ANN or the second ANN for receiving the MBS session from the second ANN over the air interface in a point-to-point (PTP) mode and a point-to-multipoint (PTM) mode, respectively; and exchanging one or more signaling messages between the first ANN and the second ANN, each signaling message including an identifier for the MBS session, to allocate, modify or release resource allocations for one or more PTP or PTM delivery instances in the first ANN and the second ANN for the MBS session. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0007] Figure 2 Exemplary protocol stacks of the control plane and the user plane in a centralized radio access network node (ANN) and a distributed radio access network node are shown.

[0008] Figure 3 Exemplary resource allocations and data paths through different layers and network entities are shown for delivering MBS to a group of UEs served by different cells in point-to-point (PTP) and point-to-multipoint (PTM) delivery modes.

[0009] Figure 4 An exemplary serving cell configuration is shown, as well as the delivery mode and attributes of the delivery instance between the various UEs within the serving cell.

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

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

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

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

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

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

[0016] Fig.11 Example options for a user plane architecture for a delivery instance are shown.

[0017] Fig.12 Other example options for the user plane architecture of the delivery instance are shown.

[0018] Fig.13 Some other example options for the user plane architecture of the delivery instance are shown. DETAILED DESCRIPTION

[0019] The following description and accompanying drawings set forth in detail certain exemplary embodiments of the present disclosure, which indicate several exemplary ways in which the various principles of the present disclosure may be implemented. However, the examples shown are not exhaustive of many possible embodiments of the present disclosure. Other purposes, advantages and novel features of the present disclosure will be considered and set forth in the following detailed description in conjunction with the accompanying drawings.

[0020] introduce

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

[0022] Single-cell point-to-multipoint (SC-PTM) technology was further introduced to improve the flexibility of air interface scheduling to some extent. However, SC-PTM technology essentially relies on the same basic principles as the network architecture before SC-PTM, and only adds an air interface data carrying mechanism based on independent scheduling in a single cell. For example, instead of using physical multicast channels in traditional eMBMS, SC-PTM technology uses PDSCH (physical downlink shared channel) which is more consistent with unicast data. Despite these improvements, SC-PTM technology still cannot solve problems related to, for example, the semi-static nature of broadcast area configuration at the architectural level. In addition, as a network-side technology, SC-PTM cannot fully coordinate 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.

[0023] In particular, when the reception quality of the UE receiving the MBS session data has been reduced or improved, the UE receiving the MBS session data may need to switch from the point-to-multipoint delivery mode to the point-to-point delivery mode, or vice versa. Based on current LTE multicast broadcast technologies such as the above-mentioned eMBMS, such UEs can only switch between unicast and broadcast through the application layer. Therefore, longer switching delays and potential service interruptions may result. In time-sensitive multicast broadcast services such as MCPTT (Mission Critical Push-to-Talk) for public safety applications, such delays and interruptions may be unbearable.

[0024] The various embodiments below 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 using one or more point-to-point (PTP, or unicast) and point-to-multipoint (PTM, or multicast) delivery instances. Therefore, a subset of UEs participating in the MBS can be configured to receive MBS session data in a PTP manner. The architecture also allows one or more UEs participating in an MBS session to switch between PTP mode and PTM mode at the access network level. This switching is implemented dynamically without the involvement of the application layer. Resource allocation and configuration of PTP and PTM delivery instances can be performed collaboratively in the access network between a centralized unit (CU) and one or more distributed units (DUs). This collaborative resource allocation and configuration can be implemented using a novel architecture for signaling messages between CUs and DUs.

[0025] Wireless communication network architecture

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

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

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

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

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

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

[0032] Access network implementation of MBS in PTP and PTM modes

[0033] The wireless communication network may be configured to provide a multicast / broadcast service (MBS) to at least one UE. In order to establish an MBS session, the core network sends session management related content to the access network, wherein the session management related content includes the context of the MBS, such as:

[0034] • 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.

[0035] 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 group of UEs associated with the access network that have applied for and are allowed to receive multicast services. Optionally, a multicast area list may be included if necessary. The multicast area list may be provided in the form of a list of multicast area indices or in the form of a cell list. Each multicast area index may be further mapped to a cell list.

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

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

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

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

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

[0041] In some embodiments, the service data of an MBS session is referred to as MBS session data, and in other embodiments may alternatively be referred to as MBS session packet data units (PDUs).

[0042] PTP and PTM delivery examples

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

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

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

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

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

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

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

[0050] A delivery mode including a PTP delivery mode or a PTM delivery mode. Likewise, a delivery instance using the PTP delivery mode may be referred to as a PTP delivery instance, and a delivery instance using the PTM delivery mode may be referred to as a PTM delivery instance. An identifier of a specific UE may be used to identify the PTP delivery instance. An instance identifier for a PTM delivery instance may be:

[0051] o the cell identifier of the cell when the PTM delivery instance is the only PTM delivery instance in the cell for the MBS session;

[0052] o when the cell is associated with multiple PTM delivery instances for the MBS session, the cell identifier of the cell and the PTM delivery instance index of the PTM delivery instance in the cell; or

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

[0054] 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 MRBs of an MBS session. For another example, a delivery instance may be associated with a subset of MRBs of an MBS session.

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

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

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

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

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

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

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

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

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

[0064] The MAC / PHY configuration set may also include:

[0065] DRX information corresponding to this PTM delivery instance

[0066] The Radio Network Temporary Identifier (RNTI) of the PTM delivery instance

[0067] Time domain scheduling information corresponding to the PTM delivery instance, indicating the subframe or time slot for scheduled PTM transmission

[0068] • Frequency domain resource allocation information corresponding to the PTM delivery instance.

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

[0070] - BWP (Bandwidth Part) information corresponding to the PTM delivery instance.

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

[0072] User plane resource architecture for delivery instances in an MBS session

[0073] In order to implement the delivery mode switching from one mode to another mode for a UE, and different delivery modes for a group of UEs associated with the same MBS session, such as Figure 11-12 As shown, five (5) options for the user plane architecture are given. At least two scenarios are considered for UE mode switching:

[0074] For a specific UE, the delivery mode is switched from one mode to another, for example, UE1 receiving MBS session data in PTM mode may experience poor connection. Therefore, UE1 can 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, for example, to achieve better spectrum efficiency.

[0075] Different delivery modes may co-exist 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 states 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, for example, 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 co-exist in the same cell.

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

[0077] In order to be able to deliver the QoS flows associated with the MBS session to the UE in different delivery modes (ie, PTP, PTM or both PTP and PTM), for the same UE or different UEs, Figure 11-12 As shown, there are several different options from the perspective of the user plane (UP) architecture. The protocol stack used for the delivery instance includes SDAP, PDCP, RLC, MAC and PHY protocols or layers. For the above scenarios, different user plane architecture options use 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, whether for the same UE or for different UEs at the same time. The protocol layers at and above the anchor layer are shared by the delivery instance. The following description focuses on the mode switching of a specific UE from one delivery mode to another. The basic principle also applies to the case where different UEs are in different reception modes, or the case where UEs in different subgroups are in PTM mode. UEs in different subgroups either receive MBS session data in different cells, or receive MBS session data in the same cell but with different delivery configurations (e.g., different physical layer configurations).

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

[0079] Option 1 ( Fig.12). For a specific MRB, two different delivery instances share the same SDAP and PDCP entities, and the same F1 tunnel instance, but different RLC entities. The anchor layer is F1-U on the DU side. The protocol stack layers F1-U and above are shared by the delivery instances. QoS flows or data flows from the core network are submitted to the shared SDAP entity 1; some or all QoS flows are mapped to MRBs (possible other MRBs are not depicted); in the case of CU / DU separation, the corresponding PDCP PDU is submitted to F1-U tunnel 1; PDCP PDUs are submitted to different RLC entities serving different UEs, or are copied and submitted to more than one RLC entity, UE

[0080] This prevents the UE from receiving MBS session data in two modes at the same time.

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

[0082] Option 3 ( Fig.13 ). Two different delivery instances share the same SDAP entity, but the PDCP entities, F1 tunnel instances and RLC entities are different. The anchor layer is the SDAP layer. The 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 the shared SDAP entity 1; the QoS flows are mapped to a set of MRBs, and the same QoS flows are mapped to another set of MRBs with the same or different mapping rules. The MRB data is then processed by different PDCP entities through separate sorting operations. Therefore, the PDCP PDUs from the above-mentioned different PDCP entities are sent to DUs in different F1 tunnels and submitted to different RLC entities.

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

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

[0085] User plane resource configuration and MBS data flow in the delivery instance in MBS session part 2

[0086] Figure 3 An exemplary data resource configuration and data path in an access network including a CU and a DU for transmitting an MBS session are shown. Although an MBS session can be delivered by multiple DUs under the control of a CU, the following disclosure only considers one DU. The basic principles apply to other DUs. As an example, assuming a specific DU-UE configuration such as Figure 4 In particular, the DU is connected to multiple cells (including Figure 4 Regarding this DU, there are multiple UEs distributed in the serving cells of this DU, which receive MBS using PTP or PTM delivery modes associated with resource allocations of various PTP or PTM delivery instances, as listed below:

[0087] Cell 1-UE1, PTP delivery instance 1;

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

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

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

[0091] Cell 3—UE9 and UE10, PTM delivery instance 4.

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

[0093] CU 310 allocates MRBs for various QoS flows of the MBS session. As an example, for this particular MBS session, assume that the QoS flows of the MBS session are mapped to 4 MRBs, which are marked as RB1, RB2, RB3 and RB4 in the PDCP layer of CU 310 (corresponding to four groups of PDCP PDUs).

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

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

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

[0097] When configured, for retransmission of a specific MRB for a specific UE in a PTM instance, an additional RLC entity may be allocated for the specific UE and the specific MRB in the PTM instance, because the original RLC entity allocated for transmission of the specific MRB is shared with at least one other UE in the PTM UE group. Figure 3 As shown, the PTM delivery instance PTM 2 may require resource allocation for retransmission of both RB1 and RB2 for UE 5. Therefore, an additional RLC entity 357 may need to be allocated for such UE-specific retransmission of RB1 and RB2, since the original RLC entity 356 is shared by other UEs.

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

[0099] For PTP or PTM delivery examples, such as Figure 3 The RLC SDUs corresponding to the retransmitted PDCP PDUs shown in 336 for the PTP 1 delivery instance and 337 for the PTM 2 delivery instance are used for retransmission. For the PTP 1 delivery instance, in the absence of an additional RLC entity (e.g., 353) being allocated, the additional retransmitted RLC SDUs 336 will be submitted to the original RLC entity, as shown by the dotted routing line 339.

[0100] like Figure 3 As further shown in 370 , each delivery instance 301 , 303 , 305 , 307 and 309 is also associated with a corresponding MAC entity and a physical layer function set for transmitting MBS data to the UE via an air interface.

[0101] The above example resource configurations may be allocated by the CU and DU as controlled by signaling information and corresponding responses transmitted between the CU and DU via the F1-C interface. Figure 3 Only exemplary snapshots of such resource allocation and configuration are shown. Such resource allocation and configuration can be dynamically established, modified, and released at any time under the control of such signaling interactions. For example, a particular UE can switch between PTM and PTP delivery modes. Resource allocation and configuration can be dynamically modified to reflect such switching. Such switching and resource reallocation can be done at the access network level without the involvement of the application layer, and can therefore be achieved with minimal delay and service interruption.

[0102] Various exemplary embodiments of the signaling process, the design of the information content of such signaling and responses, the messaging format, and the allocation of configuration tasks between the CU and the DU will be further described in more detail below.

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

[0104] Figure 5 The MBS session context management, resource allocation / modification / release in the CU and DU to support the transmission of the MBS session to the UE, and exemplary signaling message flows and processes between the CU, DU and UE for the UE to switch the delivery mode between PTM delivery mode and PTP delivery mode are shown for implementing the above-mentioned various delivery instances.

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

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

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

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

[0109] F1-U related information used to transmit the PDCP PDU of the MRB from the CU to the DU when IP multicast is used. This information may include, for example, the IP multicast address with or without the source address and the GTP-TEID of the tunnel.

[0110] In step 2, the DU performs various resource allocation and configuration based on the information received from the CU in step 1, and sends a response message back to the CU. The response message may contain configuration information of the low-level resources successfully allocated to the accepted MRBs for various delivery instances. The message may also contain an MRB list of MRBs that were not created, and the corresponding failure reasons.

[0111] 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 sends such MBS radio resource configuration to the UE. In addition, in step 3 or a separate step, the CU may generate an MBS reception status report / feedback configuration for the UE and send the report / feedback configuration to the UE. The message in step 3 may be sent via broadcast or dedicated signaling. In this way, the CU may dynamically configure how the UE should provide feedback on MBS session reception, including but not limited to the form, content, timing, and triggering conditions of the feedback.

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

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

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

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

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

[0117] DU can initiate MBS context release request (DU initiated)

[0118] CU can initiate an MBS context release request (initiated by CU)

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

[0120] A notification message notifying a UE that the QoS requested by the UE may not be met.

[0121] Notify the DU that the UE cannot meet a certain condition and trigger a notification message from the UE to the DU, which further notifies the CU. For example, the notification may be included in the information sent in step 4a / 2 above.

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

[0123] Furthermore, since MBS context management and mode switching decisions are initiated and completed at the access network level, the delay introduced by the delivery mode switching between PTP and PTM of the UE is minimized compared to mode switching initiated at the application layer which requires the involvement of more higher layers and more network elements.

[0124] Signaling information exchange between CU and DU

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

[0126] Each of these messages may contain one or more information items that are exchanged between the CU, DU, and UE to implement resource allocation and configuration for transmitting a delivery instance of an MBS session to the UE. These information items may be transmitted for various purposes in resource allocation and configuration, and are used to trigger various actions and responses from the CU or DU. The following disclosure describes these information items and corresponding actions and responses of the DU and / or CU in more detail to implement the following. Figure 3 Dynamically reconfigurable resource allocation for different delivery instances as shown in the exemplary configuration snapshots.

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

[0128] • Operation indication (eg, create operation, modify operation, release operation).

[0129] • MBS Session Identifier (more details provided below).

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

[0131] QoS parameters corresponding to the MRB.

[0132] · Profiles mapped to QoS parameters of an MRB or QoS flows.

[0133] MBS capabilities of the UE.

[0134] • Required UE capabilities related to the MBS session.

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

[0136] When a PDCP PDU for MRB is sent from CU to DU in IP point-to-point transport mode, and no F1-U tunnel information for MRB is included from CU, the DU may respond with IP point-to-point transport information including IP address and TEID as destination information of downlink F1-U tunnel for MRB. The F1-U tunnel may be shared between one or more delivery instances, or may be dedicated to a specific delivery instance for a specific MRB instance.

[0137] Uplink tunnel information used to transmit the PDCP layer status report of a specific MRB of a specific UE from the DU to the CU.

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

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

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

[0141] • The RLC mode of the PTP delivery instance, which can be Acknowledged Mode (AM), Bidirectional Unacknowledged Mode (UM), Unidirectional UM Uplink or Unidirectional UM Downlink.

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

[0143] • Delivery mode indicator of the UE (MBS session based or MRB based).

[0144] • UE ID or list of UE IDs of UEs with PTP or PTM indication.

[0145] • UE ID or list of UE IDs with a response from the DU indicating PTP or PTM mode.

[0146] • Cell ID or a list of cell IDs, optionally with a list of UE IDs.

[0147] • Cell ID and Delivery Instance ID, optionally with a list of UE IDs.

[0148] · UE ID list with cell ID information.

[0149] The MBS session identifier may be used to identify the MBS session and may be provided in at least one of the following forms:

[0150] Session ID: MBS session ID in the session management process for a certain UE, which uniquely specifies the MBS session among multiple sessions including the PDU session for the UE. The session ID may be included in the SDAP configuration.

[0151] TMGI (Temporary Mobile Group Identity).

[0152] IP multicast address with source address.

[0153] An IP multicast address without a source address.

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

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

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

[0157] • An identifier or index that can uniquely identify an MBS session within a CU, DU or F1 interface.

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

[0159] gNB-CU UE F1AP ID,

[0160] gNB-DU UE F1AP ID,

[0161] C-RNTI,

[0162] RAN UE ID,

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

[0164] CU-DU interaction

[0165] This section describes various exemplary interactions between the CU and the DU. Typically, information items included in a signaling message sent from the CU to the 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 by the CU or the DU, or jointly by the CU and the DU.

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

[0167] However, in some other alternative embodiments, such a decision may depend on the DU. For example, the CU may provide a list of UE IDs via a signaling message from the CU to the DU. The DU may then use information like the UE connection status and other information at the DU (e.g., resource utilization or UE capabilities / MBS session requirements regarding UE capabilities) to determine the delivery mode for each UE and return such a decision to the CU via a response signaling message. In other words, Figure 5 The steps in the signaling process may be performed by the DU between step 1 and step 2, and the steps labeled "determine delivery mode" between step 4a / 2 and step 5 may be performed by the DU between step 4a / 2 and step 5. For a UE associated with the PTP mode, the DU may allocate resources for the accepted MRB of the PTP delivery instance corresponding to the PTP UE and return its configuration information. The DU determines the serving cell of the PTM delivery instance for the UE associated with the PTM delivery mode. The DU further determines the number of PTM delivery instances in the serving cell determined for the PTM UE, performs resource allocation for these PTM delivery instances, and returns 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 list of UE IDs of UEs in each PTM delivery instance. In some embodiments, for an MBS session, only one PTM instance is allocated to a specific cell. In this case, the PTM delivery instance ID may be a cell ID.

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

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

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

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

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

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

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

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

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

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

[0178] Signaling message architecture

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

[0180] Context Establishment Request (CU to DU): used to trigger the DU to establish the MBS session context and allocate resources

[0181] 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, etc.

[0182] Context modification request (CU to DU): used to trigger DU to modify MBS session context and resource allocation

[0183] Context Modification Request Response (DU to CU): used for the DU to respond with information similar to the Context Establishment Request Response.

[0184] Context Modification Request (DU to CU): used to enable a DU to initiate a context modification.

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

[0186] Context release operation (CU initiated): used to release resource allocation for a certain MBS session or a certain delivery instance (including a PTP delivery instance for a specific UE, or a PTM delivery instance for a group of UEs).

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

[0188] Notification (DU to CU): used for the DU to send a notification related to the QoS of an MRB for a specific delivery instance to the CU to inform the CU that the QoS of the established GBR (guaranteed bit rate) MRB can no longer be met or can be met again.

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

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

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

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

[0193] · Signaling message transmission format embodiment 1 : The format is provided only for signaling messages associated with different categories of UEs between CU-DU signaling.

[0194] · Signaling message transmission format embodiment 2 : Signaling messages associated with different categories of MBS are only provided between CU-DU signaling.

[0195] · Signaling message transmission format embodiment 3 : Provides the format of UE-associated and MBS-associated signaling messages between CU-DUs using separate process code spaces. In some example embodiments, the above various categories of requests and responses related to a specific UE's PTP delivery instance may be carried using the UE-associated signaling message format, while the above various categories of requests and responses related to a specific PTM delivery instance may be carried using the MBS-associated signaling message format.

[0196] The example features of the UE-associated signaling format are described as follows. During the interaction between the CU and the DU on the MBS session context, in order to perform MBS session context management or operation through the F1 interface, the above-mentioned various categories of UE-associated signaling messages are always directed to a single UE. In other words, the CU and the DU use the signaling unit for each UE.

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

[0198] MBS Session ID

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

[0200] o MRB identifier (RBID) and possibly a second RBID specific to the UE

[0201] οQoS parameters for each MRB

[0202] o QoS parameters of the QoS flow mapped to the MRB.

[0203] o Downlink F1-U tunnel information, and possible second downlink F1-U tunnel for UE to perform MRB retransmission

[0204] The delivery mode of the target UE, such as PTP, PTM or both PTP and PTM.

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

[0206] UE's RLC bearer configuration information.

[0207] This UE-associated signaling message is transmitted between the CU and the DU and is used by both the CU and the DU to synchronize the MBS session context information. In other words, the exchange of information items between the CU and the DU can be cumulatively based on multiple signaling interactions at different times.

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

[0209] Any UE-associated signaling message for an MBS session may operate the MBS session context and configuration, which includes but is not limited to the following information or a combination thereof:

[0210] · Includes its released and added MRB attributes.

[0211] Corresponding to the modification of QoS parameters of MRB, the addition and removal of QoS flows mapped to MRB.

[0212] Modification of PDCP configuration (such as PDCP SN length, reordering timer, ciphering and integrity protection configuration).

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

[0214] Any UE-associated signaling for a specific UE may operate on various aspects of a delivery instance associated with the specific UE in an MBS session, including but not limited to the following information or a combination thereof:

[0215] Delivery instance ID.

[0216] • The F1-U tunnel associated with the delivery instance of the MRB.

[0217] • Configuration of the associated RLC bearers, and control information corresponding to the delivery instance.

[0218] • A MAC / PHY configuration set for a specific PTM delivery instance associated with the UE, which includes the delivery cell identity or a specific PTM delivery instance in a cell.

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

[0220] MBS Session ID.

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

[0222] oMRB identifier (RBID).

[0223] οQoS parameters for each MRB.

[0224] o QoS parameters of the QoS flow mapped to the MRB.

[0225] ο Downlink F1-U tunnel information.

[0226] The delivery mode of the target UE, such as PTP, PTM or both PTP and PTM.

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

[0228] • Delivery instance's RLC bearer configuration information.

[0229] • A MAC / PHY configuration set for a specific PTM delivery instance, which includes the delivery cell identity or a specific PTM delivery instance in a cell.

[0230] Such MBS-related signaling messages are transmitted between the CU and the DU, and are used 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.

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

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

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

[0234] Example 1

[0235] In a first embodiment using only UE-specific signaling (alternatively referred to as UE-associated signaling), the CU can make a decision (as described later, such a decision can be made by the DU instead of the CU) that some UEs receive MBS in PTP mode (Group 1 UEs) and some UEs receive MBS in PTM mode (Group 2 UEs). The CU uses UE-associated F1 signaling such as UE context establishment or UE context modification messages, and requests the DU to allocate, modify or release corresponding resources, and sends the relevant configuration back 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 on multiple UEs, multiple UE-associated signaling messages are transmitted and combined to achieve resource allocation and configuration.

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

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

[0238] UE interface ID: gNB-CU UE F1AP ID, gNB-DU UE F1AP ID; and MBS session ID or MBS session ID list.

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

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

[0241] oDU response: the first RLC bearer configuration information corresponding to each MRB, which includes the corresponding service RB ID, which can be RBID1 or RBID2.

[0242] • For a specific MRB, its QoS parameters and the QoS parameters of the QoS flows mapped to the MRB.

[0243] 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 the downlink tunnel information is assigned to the MRB by the DU, then

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

[0245] UE capabilities of the UE,

[0246] UE capability requirements for MBS sessions.

[0247] 2. The CU determines the delivery mode for the UE and includes the delivery mode indication in the information sent to the DU. In another embodiment, the CU only sends the MBS session context to the DU, and the DU determines the delivery mode for the UE and returns the configuration based on the delivery mode.

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

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

[0250] • Uplink tunnel information corresponding to each MRB of the MBS session.

[0251] • An indicator to enable or activate retransmissions (such as PDCP retransmissions) of an MRB or MRB list for an MBS session.

[0252] o DU response: corresponding second downlink tunnel information (DL-TNL2, which includes the IP address and associated GTP-TEID).

[0253] oDU response: RRC information from DU to CU, which contains at least the above-mentioned RLC bearer configuration. Upon receiving a request from the CU, the DU attempts to allocate or modify resources according to the request. The DU then sends a response message to the CU to give feedback on whether each RB is successfully created. In addition, for each successfully created MRB, the DU creates a configuration for the specific RB and sends the configuration back to the CU. For MRBs that failed in the corresponding operation, the DU response also includes: an MRB list of the MRBs that failed in the operation request, and the corresponding reasons.

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

[0255] The CU message does not specify a PTM delivery cell, nor a delivery instance ID. It only contains an MBS session context that includes a list of UEs with PTM delivery mode.

[0256] o DU response: PTM delivery cell or cell list, optionally, a PTM delivery instance ID corresponding to the PTM delivery cell, and optionally, a UE list corresponding to the delivery instance.

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

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

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

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

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

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

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

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

[0265] • The CU message also indicates the mode of the RLC entity corresponding to the MRB, which may be Acknowledged Mode (AM), Bidirectional Unacknowledged Mode (UM), Unidirectional UM Uplink or Unidirectional UM Downlink.

[0266] • The CU message may also enable or activate retransmission of MRB (such as PDCP retransmission).

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

[0268] οDU response: The second RLC bearer configuration for a specific UE and its logical channel identifier LCID3, and marks the LCID3 corresponding to the main path, which is used to send the PDCP SR.

[0269] oDU response: A list of MRBs for which operations failed corresponding to the PTM delivery instance corresponding to the MBS session, and the corresponding reasons.

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

[0271] Cell 1 – UE1, PTP

[0272] Cell 1 – UE2 and UE3, PTM

[0273] Cell 2 – UE4 and UE5, PTM

[0274] Cell 3 – UE6, UE7 and UE8, PTM

[0275] Cell 3 – UE9 and UE10, PTM

[0276] Obviously, each cell can support multiple delivery instances of PTP mode or PTM mode. In some embodiments, a cell only allows one delivery instance.

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

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

[0279] MBS session related content

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

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

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

[0283] TMGI (Temporary Mobile Group Identity).

[0284] • IP multicast address (with or without source address).

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

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

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

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

[0289] In the same context management operation, the message also includes an MRB list containing MRBs serving the MBS, a first RB ID (RBID1) corresponding to each MRB in the MRB list, RBID1 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.

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

[0291] The operation also includes the QoS parameters of each MRB and the QoS parameters of the QoS flows mapped to the MRB.

[0292] F1-U Tunnel Resources

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

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

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

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

[0297] In some embodiments, Figure 6 Shown (for illustration Figure 4 The CU uses IP multicast 610 to transmit the MRB data to the DU in the IP layer of the tunnel. The information sent by the CU contains the IP multicast downlink tunnel information for the MRB, that is, the downlink tunnel information of the first IP multicast type. Then, if any associated delivery instance accepts the MRB, the DU will join the IP multicast group and receive the MBS. Tunnel 1 is located above the IP layer based on IP multicast 610. Its tunnel information includes: IP multicast address and optional source address, as well as GTP-TEID. In this scenario, Tunnel 1 consists of multiple delivery instances (for example, the PTP delivery instance ( Figure 6 602), PTM delivery example for UE6, UE7 and UE8 ( Figure 6 604), and PTM delivery examples for UE9 and UE10 ( Figure 6 The MRB data is delivered from the CU to the DU using tunnel 1, and then the DU submits the MRB data to multiple RLC entities (RLC entities 1, 2, and 3) to serve the corresponding delivery instances. Figure 6 An example of data delivery for one MRB is shown, but the same principles apply to other MRBs.

[0298] In some embodiments, Figure 6 As shown, the CU transmits the 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 no previous delivery instance of the MRB for the MBS session has been accepted on the DU side, or this is the first time such an MRB for the MBS session is established in the DU, the DU allocates the corresponding F1-U interface resources, which is the first downlink tunnel, and returns the corresponding first downlink tunnel information to the CU, which includes the IP address and the associated GTP-TEID. It should also be noted that once the DU receives the MRB data from tunnel 1, the DU handles the remaining data delivery tasks in the same manner as described above. In this scenario, tunnel 1 consists of multiple delivery instances (for example, a PTP delivery instance for UE1 ( Figure 6602), PTM delivery example for UE6, UE7 and UE8 ( Figure 6 604) and PTM delivery examples for UE9 and UE10 ( Figure 6 The MRB data is delivered from the CU to the DU using tunnel 1, and then the DU submits the MRB data to multiple RLC entities (RLC entities 1, 2, and 3) to serve the corresponding delivery instances. Figure 6 An example of data delivery for one MRB is shown, but the same principles apply to other MRBs.

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

[0300] In some embodiments, the MRB uses an independent F1-U downlink tunnel, that is, for a certain MRB of the MBS session, there are multiple independent F1-U tunnels on the corresponding F1 interface based on different delivery instances. Therefore, based on the MBS session context management request, the DU returns independent tunnel information for the same MRB under different delivery instances. The tunnel created in this scenario is called the first downlink tunnel under each delivery instance. For example, in Figure 7 (used to explain Figure 4 Some delivery instances in use independent downlink data tunnels), multiple delivery instances (PTP delivery instances for UE1, Figure 7 The PTM delivery instance for UE6, UE7 and UE8 is marked as 702 in FIG. Figure 7 704 in FIG. 1 and another PTM delivery example for UE9 and UE10 in FIG. 1 Figure 7 In the example, the PDCP PDU from the PDCP entity corresponding to the MRB is transmitted to the DU through the respective tunnels, and then it is submitted to the RLC entities corresponding to the multiple delivery instances, for example, RLC entity 1, RLC entity 2 and RLC entity 3.

[0301] The following sections describe the CU DU interactions for handling PTP related requests.

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

[0303] 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 accepting the request sent by the corresponding MRB in PTP mode, the DU establishes or modifies the configuration of the RLC entity corresponding to the MRB, and allocates corresponding MAC resources such as logical channels, and returns the corresponding RLC bearer configuration in the response message. The RLC bearer configuration is included in the cell group configuration and further included in the DU to CU RRC information to be sent to the CU.

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

[0305] In more detail, Figure 8 The tunnel configuration of a specific MRB in delivery instances 802 and 804 is shown, which has data tunnel 1 and data tunnel 2. Delivery instance 804 can be a PTP delivery instance, while delivery instance 802 can be a PTP or PTM delivery instance. Figure 8 As shown, in delivery instances 802 and 804, tunnel 1 is shared by delivery instances 802 and 804 for normal downlink transmission of PDCP PDUs from the RLC entity of the MRB to the MRB, while tunnel 2 is the established uplink PDCP SR 810 transmission to the CU.

[0306] Processing of PTP retransmission requests

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

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

[0309] In some embodiments, the CU transmits the MRB data to the DU using a point-to-point approach. Figure 8 , both Tunnel 1 and Tunnel 2 information are provided by the DU. In this scenario, for MRB data transmission, initial data transmission for different delivery instances share Tunnel 1. For PTP delivery instance 804, MRB data retransmission uses Tunnel 2. Both initial data and retransmission data are delivered to the same RLC entity corresponding to the PTP delivery instance (i.e., RLC entity 2).

[0310] In some embodiments, the same MRB in different delivery instances uses separate tunnels. Fig. 9 (Delivery examples using independent data tunnels 902 and 904 for a specific MRB are shown), the PTP delivery example 904 for UE1 uses tunnel 2, while the delivery examples for other UEs use tunnel 1. For the PTP delivery example 904 for UE1, the initial transmission and retransmission of MRB data use the same tunnel (i.e., tunnel 2). In this scenario, tunnel 2 can be bidirectional. It can be used as a downlink for initial transmission and retransmission of MRB data. It can also be used as an uplink for transmitting a PDCP SR corresponding to an MRB.

[0311] Handle DU's refusal to create some MRBs

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

[0313] The following sections describe the CU DU interactions for handling PTM related requests.

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

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

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

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

[0318] The CU may specify a transmission cell in a PTM transmission. Optionally, the CU further specifies a PTM delivery instance ID in the transmission cell.

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

[0320] If the CU further specifies the cell information of the PTM transmission and the PTM delivery instance ID in the corresponding cell, the DU includes scheduling information corresponding to the corresponding cell or the corresponding PTM delivery instance in the corresponding cell in the corresponding response message.

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

[0322] DRX information corresponding to this PTM delivery instance

[0323] The Radio Network Temporary Identifier (RNTI) of the PTM delivery instance

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

[0325] • Frequency domain resource allocation information corresponding to the PTM delivery instance.

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

[0327] - BWP (Bandwidth Part) information corresponding to the PTM delivery instance.

[0328] PTM related requests, RLC bearer configuration

[0329] 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 the information from the CU message such as PDCP SN. Otherwise, if the PTM delivery instance already exists in the DU, the DU associates the UE with the PTM delivery instance and sends the corresponding first RLC bearer configuration to the CU according to the configuration corresponding to the existing delivery instance.

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

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

[0332] PTM-related requests - handling PDCP SR and Retransmission

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

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

[0335] The CU message also indicates the mode of the RLC entity corresponding to the MRB, whether it is confirmed mode (AM), bidirectional unconfirmed 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 the RLC bearer corresponding to the MRB, allocates corresponding MAC resources such as logical channels, and returns the corresponding second RLC bearer configuration in the response message. The RLC bearer configuration is included in the cell group configuration and is further included in the DU to CU RRC information to be sent to the CU.

[0336] Handle DU rejection of some MRB creation

[0337] 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 including the MRBs for which the establishment or modification failed, and the reasons for the failure.

[0338] Dual-mode processing using both PTP and PTM

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

[0340] Example 2

[0341] In this embodiment, the CU makes a decision that some UEs receive MBS in PTP mode (Group 1 UEs) and some UEs receive MBS in PTM mode (Group 2 UEs). The CU uses MBS-associated F1 signaling such as MBS context establishment or MBS context modification messages to send the decision to the DU and request the DU to allocate or modify the corresponding resources and related configurations. At the same time, on the DU side, when receiving an MBS-associated message initiated by the CU including delivery mode information (PTP for a specific UE, or PTM for a specific UE or cell or instance in a cell), the DU allocates resources and creates the corresponding configuration. Based on whether each MRB is successfully created, the DU sends a feedback message including 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 introducing MBS-associated signaling in the present disclosure.

[0342] In some embodiments, the DU makes a decision that some UEs receive MBS in PTP mode (Group 1 UEs) and some UEs receive MBS in PTM mode (Group 2 UEs). Meanwhile, on the DU side, upon receiving the MBS-associated message initiated by the CU, the DU allocates resources and creates the corresponding configuration. Based on whether each MRB is successfully created, the DU sends a feedback message including 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.

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

[0344] MBS-related message exchanges between the CU and the DU and the information items carried in the messages are further described below and organized into several groups.

[0345] Basic information that is independent of the delivery mode, including interface ID, MBS Session ID, MRB QoS parameters and associated QoS flow parameters

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

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

[0348] Delivery mode description. This may include the entire MBS session, or the MRBs in the MRB list for 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 a list of instances in the corresponding cell list.

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

[0350] · A list of MRB IDs of the MRBs serving one of the MBS sessions, wherein the first RB ID (RBID1) corresponding to each MRB is an index of all MRBs for that MBS, and optionally, the CU provides a list of UE IDs containing all UEs receiving the MBS session, and optionally, for each UE, if a separate name space is used for the RB ID of the MBS and the RB ID used by the UE, the RB ID (RBID1) of each MRB is associated with a second RB ID (RBID2).

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

[0352] • For a specific MRB, its QoS parameters and the QoS parameters of the QoS flows mapped to the MRB.

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

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

[0355] UE capabilities for UE.

[0356] UE capability requirements for MBS sessions.

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

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

[0359] • The CU also indicates the RLC entity mode corresponding to the MRB, which can be Acknowledged Mode (AM), Bidirectional Unacknowledged Mode (UM), Unidirectional UM Uplink or Unidirectional UM Downlink.

[0360] • The CU may also contain uplink tunnel information corresponding to each of the above MRBs (including IP address and associated GTP-TEID).

[0361] • The CU may also enable or activate retransmission (such as PDCP retransmission) for each of the above MRBs.

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

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

[0364] oDU response: MRB list of MRBs for which the operation request failed, and the corresponding reasons.

[0365] Messages related to PTM mode request

[0366] 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.

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

[0368] • The CU request message includes a UE ID list containing UEs using the PTM delivery mode.

[0369] o DU Response: optional PTM delivery cell or cell list, optionally, a PTM delivery instance ID corresponding to the PTM delivery cell, and optionally, a list of UE IDs corresponding to the delivery instance.

[0370] • The CU request message includes a cell list corresponding to the PTM delivery mode. Each cell in the cell list may also be associated with a UE ID list.

[0371] o DU Response: optional PTM delivery cell or cell list, optionally, a list of PTM delivery instances corresponding to the PTM delivery cells, and optionally, a list of UE IDs corresponding to the delivery instances.

[0372] UE capabilities for UE.

[0373] UE capability requirements for MBS sessions.

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

[0375] o DU Response: optional PTM delivery cell or cell list, optionally, a PTM delivery instance ID corresponding to the PTM delivery cell, and optionally, a list of UE IDs corresponding to the delivery instance.

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

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

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

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

[0380] • The CU also indicates the mode of the RLC entity corresponding to the MRB, which can be Acknowledged Mode (AM), Bidirectional Unacknowledged Mode (UM), Unidirectional UM Uplink or Unidirectional UM Downlink.

[0381] • The CU may also enable or activate retransmissions (such as PDCP retransmissions) for MRBs.

[0382] oDU response: corresponding downlink tunnel information (DL-TNL2, including IP address and associated TEID).

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

[0384] o DU Response: List of MRBs whose operations failed corresponding to the PTM delivery instance corresponding to the MBS session, and the corresponding reasons.

[0385] Universal ID

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

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

[0388] TMGI (Temporary Mobile Group Identity).

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

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

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

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

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

[0394] Common UE ID List

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

[0396] The CU also includes the following delivery mode description in the request message, which includes 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. Figure 4 In the example, UE1 uses the PTP delivery mode; UE2-UE10 use the PTM delivery mode.

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

[0398] gNB-CU UE F1AP ID

[0399] gNB-DU UE F1AP ID

[0400] C-RNTI

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

[0402] General – MRB ID Information

[0403] In the same context management operation, the message also includes an MRB list containing MRBs serving the MBS, a first RB ID (RBID1) corresponding to each MRB in the MRB list, and RBID1 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 scope or CU scope or on the F1 interface.

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

[0405] The operation also includes the QoS parameters of each MRB and the QoS parameters of the QoS flows mapped to the MRB.

[0406] Universal – F1-U

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

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

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

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

[0411] In some embodiments, Figure 6As shown in (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, that is, the first downlink tunnel information. The tunnel information includes: IP multicast address, and optional source address and GTP-TEID. Then, the DU joins the IP multicast group and receives the MBS. Tunnel 1 is located above the IP layer based on IP multicast 610.

[0412] In some embodiments, Figure 6 As shown in (Downlink Tunnel Sharing), the CU transmits the 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 resources, which is the first downlink tunnel, and returns the corresponding first downlink tunnel information (which includes the IP address and the associated GTP-TEID) to the CU.

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

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

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

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

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

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

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

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

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

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

[0423] Handle DU rejection of some MRB creation

[0424] For CU messages that specify PTP delivery mode for UE, DU may reject the creation or modification of one or more MRBs. In this case, DU returns an MRB list, which includes the MRBs that failed to be created or modified, and the reasons for the failure.

[0425] The CU message may also include uplink tunnel information corresponding to each of the above-mentioned MRBs.

[0426] PTM related requests

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

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

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

[0430] The CU also includes the following reception mode description in the request message and indicates 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 also be associated with a list of UEIDs.

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

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

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

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

[0435] DRX information corresponding to this PTM delivery instance

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

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

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

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

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

[0441] PTM related requests, RLC bearer configuration

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

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

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

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

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

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

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

[0449] CU also indicates the mode of the RLC entity corresponding to the MRB, whether 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 the corresponding second RLC bearer configuration in the response message. The RLC bearer configuration is included in the cell group configuration and is also included in the DU to CU RRC information to be sent to the CU.

[0450] Handle DU rejection of MRB creation

[0451] For CU messages that specify the PTM delivery mode, the DU creates a PTM delivery instance or a PTM delivery instance list. For each delivery instance, the DU may reject one or more MRB creation or modification due to resources or other reasons. In this case, the DU returns an MRB list that includes the MRBs that failed to be created or modified and the reasons for the failure.

[0452] Dual-mode processing using PTP and PTM

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

[0454] Example 2 Example

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

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

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

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

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

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

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

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

[0463] The signaling may also carry the RLC entity mode corresponding to a specific MRB for a specific UE, which may be AM or UM mode. For example, if the QoS requirement corresponding to the MRB for MBS is not sensitive to delay but requires high reliability, the corresponding RLC entity may be configured in AM mode. On the other hand, if the QoS requirement is sensitive to delay, the corresponding RLC entity may be configured in UM mode. Figure 8 and Fig. 9 In some scenarios, for UE1, an uplink tunnel shown as Tunnel 2 needs to be established to transmit uplink data, for example, feedback information such as PDCP status report related to MRB data reception generated by UE1. In this case, the signaling may also carry a user plane uplink tunnel address corresponding to a specific MRB for UE1.

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

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

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

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

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

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

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

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

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

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

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

[0475] Example 3

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

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

[0478] Upon receiving a request from the CU, the DU attempts to allocate resources according to each request. The DU then sends a response message to the CU to provide feedback on whether each MRB was successfully created. In addition, for each successfully created MRB, the DU creates a configuration for the specific MRB and sends the configuration back to the CU.

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

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

[0481] gNB-CU UE F1AP ID.

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

[0483] MBS Session ID.

[0484] • A list of MRB IDs containing the radio bearers serving the MBS and, optionally, the radio bearer ID used by the UE during UE-side data processing associated with each MRB in the MRB list.

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

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

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

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

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

[0490] Accordingly, the present disclosure extends the current signaling per UE and includes at least one parameter in the signaling messages initiated from the DU, which may be response messages or autonomous messages:

[0491] gNB-CU UE F1AP ID.

[0492] gNB-DU UE F1AP ID.

[0493] MBS Session ID.

[0494] • A list of MRBs for which an MRB was successfully created or modified.

[0495] • Downlink tunnel information for each MRB.

[0496] · List of MRBs for which MRB creation or modification failed.

[0497] UE’s cell group configuration update, which can be the RRC information from DU to CU.

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

[0499] gNB-CU UE F1AP ID.

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

[0501] MBS Session ID.

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

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

[0504] A cell list containing cells that schedule MBSs. Optionally, a corresponding PTM instance ID list for each cell, and a UE ID list for each PTM instance.

[0505] • A UE ID list containing UEs using PTM delivery mode. Optionally, a RB ID list, and the mapped RB ID used by the UE for each MRB in the RB ID list.

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

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

[0508] Accordingly, the present disclosure extends the current signaling per MBS and includes at least one parameter in the signaling messages initiated from the DU, which may be response messages or autonomous messages:

[0509] gNB-CU UE F1AP ID.

[0510] gNB-DU UE F1AP ID.

[0511] MBS Session ID.

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

[0513] A list of cells, optionally for each PTM delivery instance in the cell:

[0514] o A list of MRB IDs containing MRBs that are accepted by the DU and serve the MBS, and another list of MRBs containing MRBs that are rejected by the DU.

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

[0516] Optionally, feedback configuration for each UE.

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

[0518] LCID configuration for each UE.

[0519] Example 3 Exemplary Implementation

[0520] In this embodiment, the CU decides that for the 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 UE groups, that is, for Group 1 UEs, signaling based on each UE is used, and for Group 2 UEs, signaling based on each MBS is used.

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

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

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

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

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

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

[0527] The MRB list may list all or only some of the MRBs serving the MBS. If the F1 signaling indicating the UE delivery mode switch is based on a 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.

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

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

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

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

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

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

[0534] Downlink Tunnel Information (IP Multicast) - If IP multicast is used to distribute MRBs from CU to DUs, the CU needs to provide the IP multicast address and its corresponding tunnel end ID (TEID) for the MRB and add this information to the F1 signaling message. The DU can then join the IP multicast group to receive downlink data.

[0535] In some scenarios, for a specific MRB, multiple UEs receiving 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 MRB using PTP mode and UEs receiving MRS 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.

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

[0537] Downlink Tunnel Information (IP Point-to-Point) - If the DU accepts the 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 the downlink tunnel information corresponding to the MRB. In some scenarios, based on the MBS ID and the corresponding MRB ID in the F1 signaling message sent from the CU, the DU is able to identify a shared downlink tunnel to serve a specific MRB, thereby saving resources on the F1-U link. In this case, the DU can return the information of the existing tunnel (which includes the IP address and TEID).

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

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

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

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

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

[0543] (MBS Identifier)

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

[0545] TMGI (Temporary Mobile Group Identity).

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

[0547] MBS ID.

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

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

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

[0551] MRB List

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

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

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

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

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

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

[0558] Community Information

[0559] There are two solutions for the CU to carry the cell list, each of which is described below.

[0560] Solution A:

[0561] The F1 signaling message includes a cell list, which includes cells scheduled by the MBS, and optionally includes a PTM delivery instance list under each cell, and optionally includes a corresponding UE ID list.

[0562] During the CU decision process, the CU not only determines the delivery mode of the UE, whether it is PTP or PTM, the CU also determines which cells under the DU the PTM transmission occurs in. Optionally, the PTM delivery instance under the cell. For example, the CU decides 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 the list of cells under the DU. Therefore, after receiving the message, the DU allocates PTM resources for the MBS in each cell, or refuses to create or modify some or all MRBs for the MBS.

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

[0564] In some scenarios, the CU does not specify the PTM delivery instance ID in the transmission cell, but the DU carries the PTM delivery instance information and an optional associated UE list in the response message. Figure 4 , CU decides that UE6 to UE10 use PTM mode in cell 3, and DU further decides that UE6, UE7 and UE8 use PTM delivery instance 3 (PTM3), and UE9 and UE10 use PTM delivery instance 4 (PTM4).

[0565] Solution B :

[0566] The F1 signaling message includes a UE ID list, and the UE ID list includes UEs using the PTM mode.

[0567] The CU message does not specify cell information and only contains the UE ID and its corresponding delivery mode. Figure 4 , UE2 to 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 a PTM delivery cell to the UE. Optionally, a PTM delivery instance in a PTM delivery cell. In some embodiments, based on the connection status context of each UE in each cell and the available resources in each cell, the DU flexibly schedules PTM scheduling parameters. In this way, the decision made by the DU is sometimes more effective.

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

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

[0570] Based on the UE ID list, the DU can then provide UE-specific RLC entity configuration, which includes the RLC bearer configuration. If the CU signaling message also contains a UE ID list for each PTM delivery instance, the CU message optionally contains a mapping from each MRB 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 Serving Radio Bearer field in the RLC bearer configuration is set to RBID2 by the DU.

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

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

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

[0574] In some embodiments, the signaling message per UE 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 implemented using a signaling session per MBS. This MBS management includes DRB updates and QoS related information updates.

[0575] Throughout the specification and claims, in addition to the explicitly defined meanings, terms may have nuanced meanings indicated or implied by the context. Likewise, 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, the claimed subject matter is intended to include combinations of all or part of the exemplary embodiments.

[0576] In general, terms can be understood at least in part from usage in context. For example, terms such as "and", "or" or "and / or" etc. as used herein may include various meanings, which may depend at least in part on the context in which the terms are used. Typically, "or", if used in an association list such as A, B or C, is intended to represent A, B and C used in an inclusive sense here, and A, B or C used in an exclusive sense here. In addition, the term "one or more" used herein may be used to describe any feature, structure or characteristic in a singular sense, or may 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" etc. may be understood to represent singular usage or plural usage, which depends at least in part on the context. In addition, the term "based on" may be understood to not necessarily be intended to convey a set of exclusive factors, but on the contrary, other factors that are not necessarily explicitly described may be allowed to exist, which also depends at least in part on the context.

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

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

Claims

1. A method for wireless resource allocation, performed by a first access network node ANN in an access network of a wireless communication network and communicating with a second ANN, the method comprising: Performing a first resource allocation for a multicast / broadcast service MBS session, the MBS session being for a group of user equipments UE served by the second ANN; Dividing the group of UEs into a first subset of UEs and a second subset of UEs to receive MBS session data from the second ANN over the air interface in a point-to-point PTP mode and a point-to-multipoint PTM mode, respectively, or receiving the division from the second ANN; sending one or more signaling messages to the second ANN according to a predetermined signaling message format, each signaling message including an identifier for the MBS session, so that the second ANN performs establishment, modification or release of second resource allocation and configuration for the MBS session; and One or more response messages based on the predetermined signaling message format are received from the second ANN.

2. The method according to claim 1, wherein: The first ANN includes a gNB-centralized unit CU, and the second ANN includes a gNB-distributed unit DU.

3. The method according to claim 1, wherein: Performing the first resource allocation for the MBS session includes allocating at least one radio bearer (RB) for the MBS session.

4. The method according to claim 3, wherein: Allocating at least one RB for the MBS session includes mapping QoS flows of the MBS session having various quality of service QoS levels to the at least one RB.

5. The method according to claim 3, wherein: Each of the one or more signaling messages or the one or more response messages includes a context establishment request message or a context modification request message.

6. The method according to claim 3, further comprising: interactively managing a plurality of MBS session delivery instances with the second ANN, The multiple MBS session delivery instances include a group of PTP delivery instances and one or more PTM delivery instances, each PTP delivery instance corresponds to a UE in the first subset of UEs, and each PTM delivery instance corresponds to at least one UE in the second subset of UEs.

7. The method according to claim 6, wherein: Each of the one or more signaling messages belongs to a single process code space for control information exchange between the first ANN and the second ANN.

8. The method according to claim 7, wherein: Each of the one or more signaling messages includes UE-associated signaling.

9. The method according to claim 8, wherein: The first ANN cumulatively processes the one or more signaling messages to enable the second ANN to establish or modify a specific PTM delivery instance and identify UEs belonging to the specific PTM delivery instance.

10. The method according to claim 8, wherein: Each of the one or more signaling messages further includes a mode indicator indicating whether the target UE receives the MBS session in the PTP mode or in the PTM mode.

11. The method according to claim 1, wherein: The first subset of UEs and the second subset of UEs overlap.

12. A method for wireless resource allocation, performed by a first access network node ANN and a second ANN in an access network of a wireless communication network, the method comprising: The first ANN receives context information of a multicast / broadcast service MBS session from a core network; Allocating, by the first ANN, at least one radio bearer RB for the MBS session by mapping QoS flows of the MBS sessions with various quality of service QoS levels to at least one radio bearer RB; identifying, by the first ANN, a group of user equipments UEs targeted by the MBS session and served by the second ANN; as well as The first ANN or the second ANN divides the group of UEs into a first subset and a second subset of UEs, so as to receive the MBS session from the second ANN over the air interface in a point-to-point PTP mode and a point-to-multipoint PTM mode respectively.

13. The method according to claim 12, wherein: In addition to PHY resources, the resource allocations of the PTP delivery instance and the PTM delivery instance each include a protocol stack layer entity or tunnel, which, in the processing order of downlink data packets, from higher layers to lower layers, includes at least one of the following: PDCP entity; F1-U Tunnel; and RLC entity.

14. The method according to claim 13, wherein: The PTP delivery instance and the PTM delivery instance share the F1-U tunnel and other entities above the F1-U tunnel, and include a separate entity below the F1-U tunnel.

15. The method according to claim 13, wherein: The PTP delivery instance and the PTM delivery instance share the PDCP entity and all entities above the PDCP entity, and include a separate entity below the PDCP entity.

16. One or more network nodes, comprising a processor and a memory, wherein: The processor is configured to read computer code from the memory to implement the method according to any one of claims 1 to 15.

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

Images