Managing multicast and unicast wireless data transmissions

Abstract

A method for managing transmission of multicast and / or broadcast services (MBS) performed by a distributed unit (DU) of a distributed base station in a radio access network (RAN) is provided, the method including the steps of receiving MBS data packets from a central unit (CU) of the distributed base station via a downlink (DL) tunnel, selecting a multicast scheme for transmitting the MBS data packets to a plurality of UEs based on one or more properties of the DL tunnel, and transmitting the data packets to a plurality of UEs via a radio interface using the multicast scheme according to the selection. Additionally, a method for managing transmission of data packets is provided, the method being implemented by a node of the RAN, the method including the steps of receiving MBS data packets associated with a quality of service (QoS) flow from an upstream node, selecting a logical channel on the radio interface based on the QoS flow, and multicasting the MBS data packets on the logical channel to a plurality of UEs.

Description

[Technical Field]

[0001] The present disclosure relates to wireless communications, and more particularly to managing multicast and unicast wireless data transmissions for multicast and / or broadcast services. [Background technology]

[0002] The background discussion provided herein is intended to provide an overall context for the present disclosure. To the extent described in this Background section, the work of the inventors named herein, as well as aspects of the description that may not qualify as prior art at the time of filing, are not expressly or implicitly admitted as prior art to the present disclosure.

[0003] In telecommunications systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as transport, encryption, and integrity protection of user plane data. For example, the PDCP sublayer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) air interface (see 3rd Generation Partnership Project (3GPP®) specification TS36.323) and New Radio (NR) (see 3GPP® specification TS38.323) provides sequencing of protocol data units (PDUs) in the uplink direction from a user device (also known as user equipment or “UE”) to a base station and in the downlink direction from a base station to a UE. The PDCP sublayer also provides services for signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer. The PDCP sublayer further provides services for data radio bearers (DRBs) to a Service Data Adaptation Protocol (SDAP) sublayer or to protocol layers such as the Internet Protocol (IP) layer, the Ethernet protocol layer, or the Internet Control Message Protocol (ICMP) layer. In general, the UE and the base station can exchange RRC messages and non-access stratum (NAS) messages using SRBs, and can transport data in the user plane using DRBs.

[0004] The RRC sublayer defines an RRC_IDLE state in which the UE has no active radio connection with a base station, an RRC_CONNECTED state in which the UE has an active radio connection with a base station, and an RRC_INACTIVE state in which Radio Access Network (RAN) level base station coordination and RAN paging procedures allow the UE to return to the RRC_CONNECTED state more quickly.

[0005] In some scenarios, the UE may operate in a state in which the radio resource control connection with the RAN is not active (e.g., RRC_IDLE state or RRC_INACTIVE state) and subsequently transition to the connected state. Generally, in the inactive state, the radio connection between the UE and the RAN is suspended. When the UE is subsequently prompted to transmit data (e.g., by placing a phone call, launching a browser), or receives a paging message from the base station, the UE may then transition to the connected state. To make this transition, the UE may request the base station to establish a radio connection (e.g., by sending an RRC Setup Request message to the base station) or to resume a suspended radio connection (e.g., by sending an RRC Resume Request message to the base station), thereby allowing the base station to configure the UE to operate in the connected state.

[0006] In some cases, a UE in RRC_IDLE or RRC_INACTIVE state only needs to transmit one packet (or several relatively small packets), or a base station only needs to transmit one packet (or several relatively small packets) to a UE operating in RRC_IDLE or RRC_INACTIVE state. In these cases, a UE in RRC_IDLE or RRC_INACTIVE state can perform early data communication without transitioning to RRC_CONNECTED state, for example, by using techniques such as those specified in sections 7.3a-7.3d of 3GPP specification 36.300 v16.4.0.

[0007] In some scenarios, a UE can simultaneously utilize resources from multiple nodes of the RAN (e.g., base stations or components of a distributed base station, also known as a disaggregated base station) interconnected by a backhaul. When these network nodes support different radio access technologies (RATs), this type of connection is called multi-radio dual connectivity (MR-DC). When operating in MR-DC, cells associated with a base station acting as a master node (MN) define a master cell group (MCG), and cells associated with a base station acting as a secondary node (SN) define a secondary cell group (SCG). An MCG covers a primary cell (PCell) and zero, one, or more secondary cells (SCells), and an SCG covers a primary secondary cell (PSCell) and zero, one, or more Scells. The UE communicates with the MN (via the MCG) and with the SN (via the SCG). In other scenarios, the UE utilizes the resources of one base station at a time in single connectivity (SC). The UE communicates with the MN only via the MCG in SC. The base station and / or the UE decide when the UE should establish a radio connection with another base station. For example, the base station may decide to hand over the UE to another base station and initiate a handover procedure. In other scenarios, the UE may simultaneously utilize the resources of different RAN nodes (e.g., base stations or components of a distributed base station, also called separated base stations) interconnected by a backhaul.

[0008] A UE can use several types of SRBs and DRBs. So-called "SRB1" resources carry RRC messages, which in some cases include NAS messages on a dedicated control channel (DCCH). "SRB2" resources support RRC messages including recorded measurement information or NAS messages, also on the DCCH, but at a lower priority than SRB1 resources. More generally, SRB1 and SRB2 resources allow the UE and MN to exchange RRC messages related to the MN and embed RRC messages related to the SN, and may also be referred to as MCG SRBs. "SRB3" resources allow the UE and SN to exchange RRC messages related to the SN, and may also be referred to as SCG SRBs. Split SRBs allow the UE to exchange RRC messages directly with the MN via the MN's and the SN's lower layer resources. Furthermore, a DRB that terminates in an MN and uses lower layer resources only in the MN can be called an MCG DRB, a DRB that terminates in an SN and uses lower layer resources only in the SN can be called an SCG DRB, and a DRB that terminates in an MN or an SN but uses lower layer resources only in the MN and SN can be called a split DRB. A DRB that terminates in an MN but uses lower layer resources only in the SN can be called an MN-terminated SCG DRB. A DRB that terminates in an SN but uses lower layer resources only in the MN can be called an SN-terminated MCG DRB.

[0009] A UE can perform handover procedures to switch from one cell to another, regardless of whether it is in SC or DC operation. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. Depending on the scenario, the UE may hand over from a cell of a serving base station to a target cell of a target base station, or from a cell of a first distributed unit (DU) of the serving base station to a target cell of a second DU of the same base station. In a DC scenario, the UE can perform PSCell exchange procedures to exchange PSCells. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. Depending on the scenario, the UE may perform a PSCell change from a PSCell of a serving SN to a target PSCell of a target SN, or from a PSCell of a source DU of a base station to a PSCell of a target DU of the same base station. Additionally, the UE may perform a handover or PSCell change within a cell for synchronous reconfiguration.

[0010] Base stations operating in accordance with fifth-generation (5G) New Radio (NR) requirements support significantly wider bandwidths than fourth-generation (4G) base stations. Accordingly, the Third Generation Partnership Project (3GPP) proposed in Release 15 that UEs should support 100 MHz bandwidths in frequency range 1 (FR1) and 400 MHz bandwidths in frequency range (FR2). Due to the relatively wider bandwidths of typical carriers in 5G NR, 3GPP proposed in Release 17 that 5G NR base stations should be capable of providing multicast and / or broadcast services (MBS) to UEs. MBS can be useful in many content distribution applications, such as transparent IPv4 / IPv6 multicast distribution, IPTV, over-the-air software distribution, group communications, Internet of Things (IoT) applications, V2X applications, and public safety emergency messages.

[0011] It has been proposed to provide multicast paging for multicast and / or broadcast services (MBS), i.e., by transmitting a multicast paging message or instruction indicating that UEs that have previously indicated interest in a particular MBS service and are not operating in an active state should be paged for the MBS service. For example, a core network (CN) can receive MBS data to be transmitted to multiple interested UEs, and based on the received MBS data, the CN can transmit a multicast paging message to a central unit (CU) of a distributed base station (BS) identifying a set of UEs interested in the MBS service. The CU can transmit one or more corresponding multicast paging messages to distributed units (DUs) of the distributed base station, with each CU-to-DU multicast paging message indicating one or more interested UEs associated with the receiving DU.

[0012] 5G NR supports both multicast and unicast delivery methods for transmitting MBS packet flows over the air interface. In unicast communication, the RAN node transmits different copies of each MBS data packet to different UEs over the air interface, whereas in multicast communication, the RAN node transmits a single copy of each MBS data packet to multiple UEs over the air interface. However, in some scenarios, including when base stations are implemented in a distributed manner, it is unclear how the base station receives MBS data packets from the core network and how the base station transmits each MBS data packet to the UE. Furthermore, in some scenarios, it is unclear how the base station maps downlink MBS traffic to the air interface when there are two available delivery methods: multicast and unicast. Summary of the Invention [Means for solving the problem]

[0013] In one embodiment, a method is provided for managing transmission of multicast and / or broadcast services (MBS) performed by a distributed unit (DU) of a distributed base station in a radio access network (RAN), the method comprising: receiving MBS data packets from a central unit (CU) of the distributed base station via a downlink (DL) tunnel; selecting a multicast scheme for transmitting the MBS data packets to multiple UEs based on one or more properties of the DL tunnel; and transmitting the data packets to the multiple UEs over an air interface using the multicast scheme in accordance with the selection.

[0014] In another embodiment, a method is provided for managing transmission of data packets, performed by a node of a radio access network (RAN), comprising the steps of receiving MBS data packets associated with a quality-of-service (QoS) flow from an upstream node, selecting a logical channel on an air interface based on the QoS flow, and multicasting the MBS data packets to a plurality of UEs on the logical channel. [Brief explanation of the drawings]

[0015] [Figure 1A] FIG. 1 is a block diagram of an example wireless communication system in which a core network (CN), base stations (BS), and user equipment (UE) can implement the techniques of the present disclosure for managing multicast and unicast wireless data transmissions for multicast and / or broadcast services (MBS). [Figure 1B] 1B is a block diagram of an exemplary distributed base station (BS) including a central unit (CU) and a distributed unit (DU) that can operate in the system of FIG. 1A. [Figure 2A] 1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A may communicate with the base station of FIG. 1A. [Figure 2B] FIG. 1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A may communicate with the DU and CU of the distributed base station. [Figure 2C] FIG. 1B is a block diagram of another example protocol stack according to which the UE of FIG. 1A can communicate with the DU and CU of the base station, including support for the F1AP protocol between the CU and DU. [Figure 2D] FIG. 10 is a block diagram of an example protocol stack according to which a CU and a DU may communicate user plane traffic. [Figure 2E] FIG. 10 is a block diagram of an example protocol stack according to which a CU and a DU may communicate control plane traffic. [Figure 3] FIG. 1 is a block diagram illustrating an example tunnel architecture for MBS and PDU sessions. [Figure 4] FIG. 1 is a block diagram illustrating example MRBs and DRBs that a distributed base station can configure to communicate multicast, broadcast, and / or unicast traffic with UEs. [Figure 5A] FIG. 10 is a messaging diagram of an example scenario in which a CN and a distributed base station configure resources for transmitting MBS data of an MBS session to multiple UEs. [Figure 5B] 5B is a messaging diagram similar to FIG. 5A, but for a scenario in which the CN provides a list of UEs participating in non-MBS sessions before, rather than after, configuring a CN-to-BS tunnel for MBS. [Figure 6A]1 is a flow diagram illustrating an example method that may be implemented in a RAN node of the present disclosure for determining whether to transmit a data packet using multicast or unicast depending on whether the data packet arrived via a common tunnel or a UE-specific tunnel. [Figure 6B] 1 is a flow chart illustrating an example method that may be implemented in a RAN node of the present disclosure for determining whether to transmit a data packet using multicast or unicast depending on whether the data packet arrived via a first tunnel or a second tunnel. [Figure 7] 1 is a flow chart illustrating an example method that may be implemented in a RAN node of the present disclosure for determining whether to transmit a data packet using multicast or unicast depending on whether a tunnel through which the data packet arrived has a first transport layer configuration or a second transport layer configuration. [Figure 8A] 1 is a flow chart illustrating an example method that may be implemented in a RAN node of the present disclosure for selecting a first logical channel identifier or a second logical channel identifier for a data packet depending on whether the data packet arrived via a common tunnel or a UE-specific tunnel. [Figure 8B] 1 is a flow diagram illustrating an example method that may be implemented in a RAN node of the present disclosure for selecting a first logical channel identifier or a second logical channel identifier for a data packet depending on whether the data packet arrived via a first tunnel or a second tunnel. [Figure 9] 1 is a flow diagram illustrating an example method that may be implemented in a RAN node of the present disclosure for selecting a first logical channel identifier or a second logical channel identifier for a data packet depending on whether a tunnel through which the data packet arrived has a first transport layer configuration or a second transport layer configuration. [Figure 10A] 1 is a flow chart illustrating an example method that may be implemented in a RAN node of the present disclosure for selecting a group Network Temporary Identifier (G-RNTI) and a first logical channel, or a UE-specific RNTI (C-RNTI) and a second logical channel, for a data packet depending on whether the data packet arrived via a common tunnel or a UE-specific tunnel. [Figure 10B] 1 is a flow chart illustrating an example method for selecting a G-RNTI and a first logical channel or a C-RNTI and a second logical channel for a data packet depending on whether the data packet arrived via a first tunnel or a second tunnel, which may be implemented in a RAN node of the present disclosure. [Figure 11] 1 is a flow chart illustrating an example method, which may be implemented in a RAN node of the present disclosure, for selecting a G-RNTI and a first logical channel or a C-RNTI and a second logical channel for a data packet depending on whether a tunnel through which the data packet arrived has a first transport layer configuration or a second transport layer configuration. [Figure 12] 1 is a flow diagram illustrating an example method that may be implemented in a RAN node of the present disclosure for selecting a first logical channel identifier or a second logical channel identifier for a data packet depending on whether the data packet is associated with a first Quality of Service (QoS) flow identifier or a second QoS flow identifier. [Figure 13]FIG. 1 is a flow diagram illustrating an example method that may be implemented in a RAN node of the present disclosure for determining whether to select a first logical channel identifier or a second logical channel identifier for a data packet depending on whether the data packet is associated with a first QoS flow identifier or a second QoS flow identifier, or for determining whether to select a second logical channel identifier for a data packet depending on whether a tunnel through which the data packet arrived has a first transport layer configuration or a second transport layer configuration. [Figure 14] 1 is a flow diagram illustrating an example method for selecting a first logical channel identifier and a G-RNTI or a second logical channel identifier and a G-RNTI for a data packet depending on whether the data packet is associated with a first QoS flow identifier or a second QoS flow identifier, which may be implemented in a RAN node of the present disclosure. [Figure 15] FIG. 10 is a flow chart illustrating an example method that may be implemented in a RAN node of the present disclosure for determining whether to select a first logical channel identifier and G-RNTI or a second logical channel identifier and G-RNTI for a data packet depending on whether the data packet is associated with a first QoS flow identifier or a second QoS flow identifier, or for determining whether to select a second logical channel identifier and C-RNTI for a data packet depending on whether a tunnel through which the data packet arrived has a first transport layer configuration or a second transport layer configuration. DETAILED DESCRIPTION OF THE INVENTION

[0016] Generally, a radio access network (RAN) node of the present disclosure selects between a multicast scheme and a unicast scheme for transmitting data packets to at least one user equipment (UE) over an air interface based on how the data packets were received from an upstream node. More specifically, in some implementations, the RAN node may receive multicast and / or broadcast service (MBS) data packets for multiple UEs via a common DL tunnel and determine that the RAN node should use the multicast scheme to transmit the MBS data packets. In different scenarios, the RAN node may be a DU of a distributed base station (and the DL tunnel may operate on a CU-to-DU interface) or a DU of a non-distributed base station (and the DL tunnel may operate on a core network (CN)-to-base station (BS), i.e., a CN-to-BS interface).

[0017] 1A illustrates an example wireless communication system 100 in which techniques of the present disclosure for managing transmission and reception of MBS information may be implemented. The wireless communication system 100 includes UEs 102A, 102B, 103 and base stations 104, 106 of a RAN 105 connected to a CN 110. In other implementations or scenarios, the wireless communication system 100 may instead include more or fewer UEs and / or more or fewer base stations than shown in FIG. 1A. The base stations 104, 106 may be any suitable type or types of base stations, such as, for example, an evolved node B (eNB), a next-generation eNB (ng-eNB), or a 5G Node B (gNB). As a more specific example, the base station 104 may be an eNB or a gNB, and the base station 106 may be a gNB.

[0018] The base station 104 supports a cell 124, and the base station 106 supports a cell 126. Because the cell 124 partially overlaps with the cell 126, the UE 102A can be within communication range of the base station 104 and simultaneously within communication range of the base station 106 (or within range to detect or measure a signal from the base station 106). This overlap can enable the UE 102A to handover between cells (e.g., from the cell 124 to the cell 126) or between base stations (e.g., from the base station 104 to the base station 106) before the UE 102A experiences a radio link failure. Moreover, this overlap enables various dual connectivity (DC) scenarios. For example, the UE 102A can communicate in DC with the base station 104 (acting as a master node (MN)) and the base station 106 (acting as a secondary node (SN)). When the UE 102A is in a DC state with the base station 104 and the base station 106, the base station 104 operates as a master eNB (MeNB), a master ng-eNB (Mng-eNB), or a master gNB (MgNB), and the base station 106 operates as a secondary gNB (SgNB) or a secondary ng-eNB (Sng-eNB).

[0019] In non-MBS (unicast) operation, the UE 102A may use radio bearers (e.g., DRBs or SRBs) that terminate at different times at the MN (e.g., base station 104) or the SN (e.g., base station 106). For example, after a handover to the base station 106 or an SN change, the UE 102A may use radio bearers (e.g., DRBs or SRBs) that terminate at the base station 106. The UE 102A may apply one or more security keys in the uplink (UE 102A to base station) and / or downlink (base station to UE 102A) directions when communicating on the radio bearers. In non-MBS operation, the UE 102A transmits data to a base station via radio bearers on (i.e., within) the uplink (UL) bandwidth part (BWP) of a cell and / or receives data from a base station via radio bearers on the downlink (DL) BWP of a cell. The UL BWP may be an initial UL BWP or a dedicated UL BWP, and the DL BWP may be an initial DL BWP or a dedicated DL BWP. The UE 102A can receive paging, system information, public warning messages, or random access responses on the DL BWP. In this non-MBS operation, the UE 102A may be in a connected state. Alternatively, the UE 102A may be in an idle or inactive state if it supports small data transmission in the idle or inactive state (which may also be referred to as "early data transmission").

[0020] In MBS operation, the UE 102A may use an MBS radio bearer (e.g., MRB) that terminates at a MN (e.g., base station 104) or an SN (e.g., base station 106) at different times. For example, after a handover or SN change, the UE 102A may use an MRB that terminates at the base station 106, which may be operating as an MN or an SN. In some scenarios, the base station (e.g., MN or SN) may transmit MBS data to the UE 102A via an MRB over unicast radio resources (i.e., radio resources dedicated to the UE 102A). In other scenarios, the base station (e.g., MN or SN) may transmit MBS data from the base station to the UE 102A via an MRB over multicast radio resources (i.e., radio resources common to the UE 102A and one or more other UEs) or over a cell's DL BWP. The DL BWP may be an initial DL BWP, a dedicated DL BWP, or an MBS DL BWP (i.e., a DL BWP specific to the MBS or not for unicast).

[0021] The base station 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., central processing units (CPUs)) and computer-readable memory that stores machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 130 in the example implementation of FIG. 1A includes an MBS controller 132 configured to manage or control transmission of MBS information received from the CN 110 or edge server. For example, as discussed below, the MBS controller 132 may be configured to support radio resource control (RRC) configurations, procedures and messaging related to MBS procedures, and / or other operations related to those configurations and / or procedures. The processing hardware 130 may also include a non-MBS controller 134 configured to manage or control one or more RRC configurations and / or RRC procedures when the base station 104 operates as an MN or SN during non-MBS operation.

[0022] The base station 106 includes processing hardware 140, which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory that stores machine-readable instructions executable on the general-purpose processors, and / or special-purpose processing units. The processing hardware 140 in the example implementation of FIG. 1A includes an MBS controller 142 and a non-MBS controller 144, which may be similar to the controllers 132, 134, respectively, of the base station hardware 130. Although not shown in FIG. 1A, the RAN 105 may include additional base stations with processing hardware similar to the processing hardware 130 of the base station 104 and / or the processing hardware 140 of the base station 106.

[0023] The UE 102A includes processing hardware 150, which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory storing machine-readable instructions executable on the general-purpose processors, and / or dedicated processing units. The processing hardware 150 in the example implementation of FIG. 1A includes an MBS controller 152 configured to manage or control reception of MBS information. For example, as discussed below, the MBS controller 152 may be configured to support RRC configuration, procedures and messaging related to MBS procedures, and / or other operations related to those configurations and / or procedures. The processing hardware 150 may also include a non-MBS controller 154 configured to manage or control one or more RRC configurations and / or RRC procedures according to any of the implementations discussed below when the UE 102A communicates with the MN and / or SN during non-MBS operation. Although not shown in FIG. 1A, the UEs 102B, 103 may each include processing hardware similar to the processing hardware 150 of the UE 102A.

[0024] The CN 110 may be an evolved packet core (EPC) 111 or a fifth-generation core (5GC) 160, both of which are shown in FIG. 1A . The base station 104 may be an eNB supporting an S1 interface for communicating with the EPC 111, an ng-eNB supporting an NG interface for communicating with the 5GC 160, or a gNB supporting an NR air interface and an NG interface for communicating with the 5GC 160. The base station 106 may be a EUTRA-NR DC (EN-DC) gNB (en-gNB) with an S1 interface to the EPC 111, an en-gNB that does not connect to the EPC 111, a gNB supporting an NR air interface and an NG interface to the 5GC 160, or an ng-eNB supporting a EUTRA air interface and an NG interface to the 5GC 160. The base stations 104 and 106 may support an X2 interface or an Xn interface to directly exchange messages with each other during the scenarios discussed below.

[0025] Among other components, the EPC 111 may include a serving gateway (SGW) 112, a mobility management entity (MME) 114, and a packet data network gateway (PGW) 116. The SGW 112 is generally configured to forward user plane packets related to voice calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from a UE (e.g., UE 102A or 102B) to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 160 may include a user plane function (UPF) 162 and an access and mobility management function (AMF) 164, and / or a session management function (SMF) 166. The UPF 162 is generally configured to forward user plane packets related to voice calls, video calls, Internet traffic, etc., the AMF 164 is generally configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is generally configured to manage PDU sessions.

[0026] The UPF 162, the AMF 164, and / or the SMF 166 may be configured to support MBS. For example, the SMF 166 may be configured to manage or control MBS transport, configure the UPF 162 and / or the RAN 105 for MBS flows, and / or manage or configure one or more MBS or PDU sessions for MBS for a UE (e.g., UE 102A or 102B). The UPF 162 is configured to forward MBS data packets for audio, video, Internet traffic, etc. to the RAN 105. As indicated by the prefix “(MB-)” shown in FIG. 1A , the UPF 162 and / or the SMF 166 may be configured for both non-MBS unicast services and MBS services, or for only MBS services.

[0027] In general, the wireless communication system 100 may include any suitable number of base stations supporting NR and / or EUTRA cells. More specifically, the EPC 111 or 5GC 160 may be connected to any suitable number of base stations supporting NR and / or EUTRA cells. While the following examples specifically reference particular CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), in general, the techniques of this disclosure may also apply to other suitable radio access and / or core network technologies, such as, for example, sixth generation (6G) radio access and / or 6G core network or 5G NR-6G DC.

[0028] In different configurations or scenarios of the wireless communication system 100, the base station 104 may operate as an MeNB, an Mng-eNB, or an MgNB, and the base station 106 may operate as an SgNB or an Sng-eNB. The UE 102A may communicate with the base station 104 and the base station 106 via the same radio access technology (RAT), such as EUTRA or NR, or via different RATs.

[0029] When the base station 104 is an MeNB and the base station 106 is an SgNB, the UE 102A may be in an EN-DC state with the MeNB 104 and the SgNB 106. When the base station 104 is an Mng-eNB and the base station 106 is an SgNB, the UE 102A may be in a next generation (NG) EUTRA-NR DC (NGEN-DC) state with the Mng-eNB 104 and the SgNB 106. When the base station 104 is an MgNB and the base station 106 is an SgNB, the UE 102A may be in an NR-NR DC (NR-DC) state with the MgNB 104 and the SgNB 106. When the base station 104 is an MgNB and the base station 106 is an Sng-eNB, the UE 102A may be in an NR-EUTRA DC (NE-DC) state with the MgNB 104 and the Sng-eNB 106.

[0030] 1B shows an exemplary distributed implementation of one or both of the base stations 104 and 106. In this implementation, the base stations 104, 106 include a central unit (CU) 172 and one or more distributed units (DUs) 174. The CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and computer-readable memory that stores machine-readable instructions executable on the general-purpose processors, and / or dedicated processing units. For example, the CU 172 may include some or all of the processing hardware 130 or 140 of FIG. 1A.

[0031] Each of the DUs 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory that stores machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. For example, the processing hardware may include a MAC controller configured to manage or control one or more medium access control (MAC) operations or procedures (e.g., random access procedures), and a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures when the base station (e.g., base station 104) operates as an MN or SN. The processing hardware may also include a PHY layer controller configured to manage or control one or more PHY layer operations or procedures.

[0032] In some implementations, the CU 172 may include one or more logical nodes (CU-CP 172A) that host the control plane portion of the Packet Data Convergence Protocol (PDCP) protocol and / or the Radio Resource Control (RRC) protocol of the CU 172. The CU 172 may also include one or more logical nodes (CU-UP 172B) that host the user plane portion of the PDCP protocol and / or the Service Data Adaptation Protocol (SDAP) protocol of the CU 172. As described herein, the CU-CP 172A can transmit non-MBS control information and MBS control information, and the CU-UP 172B can transmit non-MBS data packets and MBS data packets.

[0033] The CU-CP 172A may be connected to multiple CU-UPs 172B through an E1 interface. The CU-CP 172A selects an appropriate CU-UP 172B for a requested service for the UE 102A. In some implementations, a single CU-UP 172B may be connected to multiple CU-CPs 172A through an E1 interface. The CU-CP 172A may be connected to one or more DUs 174 through an F1-C interface. The CU-UP 172B may be connected to one or more DUs 174 through an F1-U interface under the control of the same CU-CP 172A. In some embodiments, one DU 174 may be connected to multiple CU-UPs 172B under the control of the same CU-CP 172A. In such implementations, the connection between the CU-UP 172B and the DU 174 is established by the CU-CP 172A using a bearer context management function.

[0034] 2A illustrates, in a simplified manner, an exemplary protocol stack 200 according to which a UE (e.g., UE 102A, 102B, or 103) can communicate with an eNB / ng-eNB or gNB / en-gNB (e.g., one or both of base stations 104, 106). In the exemplary protocol stack 200, the EUTRA PHY sublayer 202A provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides RLC channels to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides the RLC channel to the NR PDCP sublayer 210. In some implementations, the UE 102A or 102B supports both EUTRA and NR stacks as shown in FIG. 2A to support handover between EUTRA and an NR base station and / or to support DC over the EUTRA and NR interfaces. Additionally, as shown in FIG. 2A, the UE 102A or 102B can support layering of NR PDCP 210 over EUTRA RLC 206A and an SDAP sublayer 212 over the NR PDCP sublayer 210. In this specification, sublayers are also referred to simply as "layers."

[0035] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets that may be referred to as service data units (SDUs) (e.g., from an IP layer layered directly or indirectly on the PDCP layer 208 or 210) and output packets that may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). Except where the distinction between SDUs and PDUs is important, this disclosure sometimes refers to both SDUs and PDUs as "packets" for brevity. Packets may be MBS packets or non-MBS packets. MBS packets may, for example, include application content for MBS services (e.g., IPv4 / IPv6 multicast distribution, IPTV, wireless software distribution, group communication, IoT applications, V2X applications, and / or public safety emergency messages). As another example, MBS packets may include application control information for MBS services.

[0036] On the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide SRBs, for example, to exchange RRC messages or non-access stratum (NAS) messages. On the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide DRBs to support data exchange. The data exchanged on the NR PDCP sublayer 210 can be, for example, SDAP PDUs, IP packets, or Ethernet packets.

[0037] In a scenario where the UE 102A, 102B, or 103 operates in an EN-DC with the base station 104 acting as an MeNB and the base station 106 acting as an SgNB, the wireless communication system 100 can provide the UE 102A or 102B with an MN-terminated bearer using the EUTRA PDCP sublayer 208 or an MN-terminated bearer using the NR PDCP sublayer 210. In various scenarios, the wireless communication system 100 can also provide the UE 102A or 102B with an SN-terminated bearer using only the NR PDCP sublayer 210. The MN-terminated bearer can be an MCG bearer, a split bearer, or an MN-terminated SCG bearer. The SN-terminated bearer can be an SCG bearer, a split bearer, or an SN-terminated MCG bearer. The MN-terminated bearer can be an SRB (e.g., SRB1 or SRB2) or a DRB. The SN-terminated bearer can be an SRB or a DRB.

[0038] In some implementations, a base station (e.g., base station 104 or 106) broadcasts MBS data packets via one or more MRBs, and the UE 102A or 102B receives the MBS data packets via the MRBs. The base station may include the configuration of the MRBs in multicast configuration parameters (which may also be referred to as MBS configuration parameters), described below. In some implementations, the base station broadcasts the MBS data packets via the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE 102A or 102B uses the PHY sublayer 202, the MAC sublayer 204, and the RLC sublayer 206 to receive the MBS data packets. In such implementations, the base station and the UE 102A or 102B may not use the PDCP sublayer 208 and the SDAP sublayer 212 to communicate the MBS data packets. In other implementations, the base station transmits MBS data packets via the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE 102A or 102B uses the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, and the PDCP sublayer 208 to receive the MBS data packets. In such implementations, the base station and UE 102A or 102B may not use the SDAP sublayer 212 to communicate the MBS data packets. In yet another implementation, the base station transmits MBS data packets via the SDAP sublayer 212, the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE 102A or 102B uses the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, the PDCO sublayer 208, and the SDAP sublayer 212 to receive the MBS data packets.

[0039] 2B illustrates, in a simplified manner, an exemplary protocol stack 250 that a UE 102A, 102B, or 103 can use to communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally divided as illustrated by the radio protocol stack 250 of FIG. 2B. The CU can retain all control and higher layer functions (e.g., RRC 214, SDAP 212, NR PDCP 210) in the base station 104 or 106, while lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connectivity to 5GC, the NR PDCP 210 provides SRBs to the RRC 214, which in turn provides DRBs to the SDAP 212 and provides SRBs to the RRC 214.

[0040] 2C shows, in a simplified manner, an exemplary protocol stack 260 that the UE 102A, 102B, or 103 may use to communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). Protocol stack 260 is generally similar to protocol stack 250, except that here, an RRC layer 214 is overlaid on the PDCP layer 210 to carry RRC messages between the UE and the CU 172, transparent to the DU 174.

[0041] 2D is a block diagram of an example protocol stack 270 according to which the CU 172 and DU 174 may communicate user plane traffic. A GTP-U layer 278 is overlaid on a UDP 276, which is overlaid on an IP 274. The UDP / IP layers 276, 274 are above a data link layer 272 and a PHY 271 layer. The PHY layer 271 may be, for example, a wired link.

[0042] 2E is a block diagram of an example protocol stack 280 according to which the CU 172 and DU 174 may communicate control plane traffic. The stack 280 is generally similar to the stack 270, but here a Stream Control Transmission Protocol (SCTP) layer 282 sits above the IP layer 274 to carry control messages.

[0043] 3 , which illustrates an example architecture 300 for MBS and PDU sessions, an MBS session 302A may include a tunnel 312A with endpoints at the CN 110 and a base station 104 / 106 (i.e., the base station 104 or the base station 106). The MBS session 302A may correspond to a session ID, such as, for example, a Temporary Mobile Group Identity (TMGI). The MBS data may include, for example, IP packets, TCP / IP packets, UDP / IP packets, Real-Time Transport Protocol (RTP) / UDP / IP packets, or RTP / TCP / IP packets.

[0044] In some cases, the CN 110 and / or base station 104 / 106 configure the tunnel 312A only for MBS traffic directed from the CN 110 to the base station 104 / 106, and the tunnel 312A may be referred to as a downlink (DL) tunnel. However, in other cases, the CN 110 and base station 104 / 106 use the tunnel 312A for downlink as well as uplink (UL) MBS traffic, for example, to support commands or service requests from a UE. Furthermore, because the base station 104 / 106 can direct MBS traffic arriving via the tunnel 312A to multiple UEs, the tunnel 312A may be referred to as a common tunnel or a common DL tunnel.

[0045] The tunnel 312A may operate at the transport layer or sublayer of, for example, the User Datagram Protocol (UDP) protocol layered on the Internet Protocol (IP). As a more specific example, the tunnel 312A may be associated with the General Packet Radio System (GPRS) Tunneling Protocol (GTP). The tunnel 312A may correspond, for example, to an IP address (e.g., the IP address of the base station 104 / 106) and a Tunnel Endpoint Identifier (TEID) (e.g., assigned by the base station 104 / 106). More generally, the tunnel 312A may have any suitable transport layer configuration. The CN 110 may specify the IP address and the TEID address in the header of a tunnel packet containing the MBS data packet and transmit the tunnel packet downstream to the base station 104 / 106 via the tunnel 312A. The header may include the IP address and / or the TEID. For example, the headers include an IP header and a GTP header, which include an IP address and a TEID, respectively. Thus, the base station 104 / 106 can use the IP address and / or the TEID to identify data packets traveling through the tunnel 312A.

[0046] As shown in FIG. 3, the base station 104 / 106 maps traffic in the tunnel 312A to N radio bearers 314A-1, 314A-2, ... 314A-N, which may be configured as MBS radio bearers or MRBs, where N > 1. Each MRB may correspond to a respective logical channel. As discussed above, the PDCP sublayer supports radio bearers such as SRBs, DRBs, and MRBs, and the EUTRA or NR MAC sublayer provides logical channels to the EUTRA or NR RLC sublayer. For example, each of the MRBs 314A may correspond to a respective MBS traffic channel (MTCH). The base station 104 / 106 and the CN 110 may also maintain another MBS session 302B, which may similarly include a tunnel 312B corresponding to MRBs 314B-1, 314B-2, ... 314B-N, where N > 1. Each of the MRBs 314B may correspond to a respective logical channel.

[0047] MBS traffic may include one or more quality-of-service (QoS) flows for each of tunnels 312A, 312B, etc. For example, MBS traffic on tunnel 312B may include a set of flows 316 including QoS flows 316A, 316B, ... 316L, where L > 1. Furthermore, a logical channel of an MRB can support a single QoS flow or multiple QoS flows. In the example configuration of FIG. 3, base station 104 / 106 maps QoS flows 316A and 316B to the MTCH of MRB 314B-1 and QoS flow 316L to the MTCH of MRB 314B-N.

[0048] In various scenarios, the CN 110 can assign different types of MBS traffic to different QoS flows. For example, a flow with a relatively high QoS value may correspond to audio packets, while a flow with a relatively low QoS value may correspond to video packets. As another example, a flow with a relatively high QoS value may correspond to I-frames or full images used in video compression, while a flow with a relatively low QoS value may correspond to P-frames or predicted pictures that contain only changes to I-frames.

[0049] Continuing with reference to FIG. 3, the base station 104 / 106 and the CN 110 can maintain one or more PDU sessions to support unicast traffic between the CN 110 and a particular UE. The PDU session 304A may include a UE-specific DL tunnel and / or a UE-specific UL tunnel 322A corresponding to one or more DRBs 324A, such as DRBs 324A-1, 324A-2, ... 324A-N. Each of the DRBs 324A may correspond to a respective logical channel, such as a Dedicated Traffic Channel (DTCH). The base station 104 / 106 and the CN 110 may also maintain one or more other PDU sessions to support unicast traffic between the CN 110 and a particular UE. For example, the PDU session 304B may include a UE-specific DL tunnel and / or a UE-specific UL tunnel 322B corresponding to one or more DRBs 324B, such as DRBs 324B-1, 324B-2, ... 324B-N. Each of the DRBs 324B may correspond to a respective logical channel, such as a DTCH.

[0050] Referring now to FIG. 4 , which illustrates exemplary MRBs and DRBs when the base stations 104 / 106 are implemented in a distributed manner, one or more DUs 174 may be associated with a CU 172. The CU 172 and DU 174 may establish tunnels for downlink and / or uplink data associated with the MRB or DRB. The MRB 314A-1 discussed above may be implemented as an MRB 402A connecting the CU 172 to multiple UEs, such as UE 102A and UE 102B. The MRB 402A may include a DL tunnel 412A connecting the CU 172 and the DU 174 and a DL logical channel 422A corresponding to the DL tunnel 412A. In particular, the DU 174 may map downlink traffic received via the DL tunnel 412A to the DL logical channel 422A, which may be, for example, an MTCH or a DTCH. The DL tunnel 412A may be a common DL tunnel through which the CU 172 transmits MBS data packets to multiple UEs. Alternatively, the DL tunnel 412A may be a UE-specific DL tunnel through which the CU 172 transmits MBS data packets to a particular UE.

[0051] Optionally, the MRB 402A includes a UL tunnel 413A connecting the CU 172 and the DU 174, and a UL logical channel 423A corresponding to the UL tunnel 413A. For example, the UL logical channel 423A may be a DTCH. The DU 174 can map uplink traffic received via the UL logical channel 423A to the UL tunnel 413A.

[0052] Tunnels 412A and 413A can operate at the transport layer or sublayer of the F1-U interface. As a more specific example, CU 172 and DU 174 can utilize F1-U for user plane traffic, and tunnels 412A and 413A may be associated with the GTP-U protocol layered over UDP / IP, with IP layered over the appropriate data link and physical (PHY) layer. Furthermore, MRB 402 and / or DRB 404 additionally support control plane traffic, at least in some instances. More specifically, CU 172 and DU 174 can exchange F1-AP messages over the F1-C interface relying on Stream Control Transmission Protocol (SCTP) layered over IP, with IP layered over the appropriate data link and PHY layer, similar to F1-U.

[0053] Similarly, MRB 402B may include DL tunnel 412B and, optionally, UL tunnel 413B. DL tunnel 412B may correspond to DL logical channel 422B, and UL tunnel 413B may correspond to UL logical channel 423B.

[0054] In some cases, the CU 172 uses the DRB 404A to transmit MBS data packets or unicast data packets associated with a PDU session to a specific UE (e.g., the UE 102A or 102B). The DRB 404A may include a UE-specific DL tunnel 432A connecting the CU 172 and the DU 174 and a DL logical channel 442A corresponding to the DL tunnel 432A. In particular, the DU 174 can map downlink traffic received via the DL tunnel 432A to the DL logical channel 442A, which may be, for example, a DTCH. The DRB 404A further includes a UE-specific UL tunnel 433A connecting the CU 172 and the DU 174 and a UL logical channel 443A corresponding to the UL tunnel 433A. For example, the UL logical channel 443A may be a PUSCH. The DU 174 can map uplink traffic received via the UL logical channel 443A to the UL tunnel 433A.

[0055] Similarly, the DRB 404B may include a UE-specific DL tunnel 432B corresponding to the DL logical channel 442B and a UE-specific UL tunnel 433B corresponding to the UL logical channel 443B.

[0056] 5A, in scenario 500A, UE 102 first performs an MBS session join procedure with CN 110 via base station 104 to join an MBS session (502). While FIGS. 5A and 5B show only a single “UE 102,” it is understood that this could be either or both UEs 102A and 102B. In some scenarios, UE 102 subsequently performs one or more additional MBS join procedures, making event 502 the first of multiple MBS join procedures. When base station 104 configures a common DL tunnel for MBS traffic rather than a UE-specific tunnel, procedures 502 and 586 can occur in either order. In other words, base station 104 can configure a common DL tunnel even if no UEs yet participate in the MBS session.

[0057] To perform the MBS session join procedure 502, in some implementations, the UE 102 sends an MBS session join request message to the CN 110 via the base station 104. In response, the CN 110 can send an MBS session join response message to the UE 102 via the base station 104 to grant the UE 102 access to the first MBS session. In some implementations, the UE 102 can include an MBS session ID of the MBS session in the MBS session join request message. In some cases, the CN 110 includes the MBS session ID in the MBS session join response message. In some implementations, the UE 102 can send an MBS session join complete message to the CN 110 via the base station 104 in response to the MBS session join response message.

[0058] In some cases, the UE 102 performs an additional MBS session join procedure with the CN 110 via the RAN 105 (e.g., the base station 104 or the base station 106) to join the additional MBS session. For example, the UE 102 can perform a second MBS session join procedure with the CN 110 via the RAN 105 to join the second MBS session. Similar to event 502, in some implementations, the UE 102 can send a second MBS session join request message to the CN 110 via the base station 104, and the CN 110 can respond with a second MBS session join response message to grant the UE 102 access to the second MBS session. In some implementations, the UE 102 can send a second MBS session join completion message to the CN 110 via the base station 104 in response to the second MBS session join response message. In some implementations, the UE 102 can include a second MBS session ID of the second MBS session in the second MBS session join request message. Optionally, the CN 110 includes the second MBS session ID in the second MBS session join response message. In some implementations, the UE 102 may include the first MBS session ID and the second MBS session ID in an MBS session join request message (e.g., a first MBS session join request message) to request to join the first MBS session and the second MBS session simultaneously. In such a case, the CN 110 may send an MBS session response message to admit either the first MBS session or the second MBS session, or both the first MBS session and the second MBS session.

[0059] In some implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message may be session initiation protocol (SIP) messages. In other implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message may be NAS messages such as 5G mobility management (5GMM) messages or 5G session management (5GSM) messages. In the case of 5GSM messages, the UE 102 may send a (first) UL container message including the MBS session join request message to the CN 110 (via the base station 104), the CN 110 may send a DL container message including the MBS session join response message to the UE 102 (via the base station 104), and the UE 102 may send a (second) UL container message including the MBS session join complete message to the CN 110 via the base station 104. These container messages may alternatively be 5GMM messages. In some implementations, the MBS Session Join Request message, the MBS Session Join Response message, and the MBS Session Join Complete message may be a PDU Session Modification Request message, a PDU Session Modification Command message, and a PDU Session Modification Complete message, respectively. For simplicity of the following description, the MBS Session Join Request message, the MBS Session Join Response message, and / or the MBS Session Join Complete message may also represent their respective container messages.

[0060] In some implementations, to perform the (first) MBS session join procedure, the UE 102 may perform a PDU session establishment procedure (not shown) with the CN 110 via the base station 104 to establish a PDU session. During the PDU session establishment procedure, the UE 102 may communicate a PDU session ID of the PDU session with the CN 110 via the base station 104.

[0061] Before, during, or after the (first) MBS session join procedure 502, the CN 110 may send a (first) CN-to-BS message including the first MBS session ID and / or PDU session ID to the CU 172 to request the CU 172 to configure resources for the (first) MBS session (504). In response to receiving the first CN-to-BS message (504), the CU 172 sends a CU-to-DU message to the DU 174 to request setup for an MBS context and / or a common DL tunnel for the first MBS session (506). In response to receiving the CU-to-DU message (506), the DU 174 sends a DU-to-CU message including a first DU DL transport layer configuration to the CU 172 to configure a common CU-to-DU DL tunnel for the first MBS session (e.g., for an MRB identified by one of the MRB IDs) (508). The DU 174 can include additional DL transport layer configurations in the DU-to-CU message to configure additional common CU-to-DU DL tunnels for additional MRBs identified by additional MRB IDs in the MRB IDs. In some implementations, the DU 174 can include MRB IDs associated with the first DL transport layer configuration and / or the additional DL transport layer configurations in the DU-to-CU message. In some implementations, the CU-to-DU message is a generic F1AP message or a dedicated F1AP message specifically defined for carrying this type of request (e.g., an MBS context setup request message). In some implementations, the DU-to-CU message of event 508 is a generic F1AP message or a dedicated F1AP message specifically defined for this purpose (e.g., an MBS context setup response message). The CN 110 can additionally include quality of service (QoS) configurations for the first MBS session in the first CN-to-BS message. In such a case, the CU 172 can include the QoS configuration in the CU-to-DU message (event 506).

[0062] The CU 172 sends 510 a first BS-to-CN message (e.g., an MBS session resource setup response message) in response to the message of event 504. The CU 172 can include a first MBS session ID and / or a PDU session ID in the first BS-to-CN message. The first BS-to-CN message can include a DL transport layer configuration to configure a common DL tunnel for the CN 110 to transmit MBS data to the CU 172. The DL transport layer configuration includes a transport layer address (e.g., an IP address and / or a TEID) to identify the common DL tunnel. In some implementations, the CN-to-BS message of event 504 is a generic NGAP message or a dedicated NGAP message (e.g., an MBS session resource setup request message) specifically defined to request resources for an MBS session. In some implementations, the BS-to-CN message of event 510 is a generic NGAP message or a dedicated NGAP message (e.g., an MBS session resource setup response message) specifically defined to carry resources for an MBS session. In such a case, the CN-to-BS message of event 504 and the BS-to-CN message of event 510 may be non-UE specific messages.

[0063] In some implementations, the QoS configuration includes QoS parameters for the MBS session. In some implementations, the QoS configuration includes configuration parameters for configuring one or more QoS flows for the MBS session (see FIG. 3 and the description above). In some implementations, the configuration parameters include one or more QoS flow IDs that identify the QoS flows. Each of the QoS flow IDs identifies a particular QoS flow of the QoS flows. In some implementations, the configuration parameters include QoS parameters for each QoS flow. The QoS parameters may include a 5G QoS identifier (5QI), a priority level, a packet delay budget, a packet error rate, an average duration, and / or a maximum data burst amount. The CN 110 can specify different values ​​of the QoS parameters for the QoS flows.

[0064] Events 504, 506, 508, and 510 are collectively referred to as MBS session resource setup procedure 586 in FIG. 5A.

[0065] When the CN 110 admits the UE 102 to an additional MBS session in an additional MBS session join procedure, the CN 110 can include the additional MBS session ID and, optionally, the QoS configuration for the additional MBS session ID in the first CN-to-BS message, a subsequent CN-to-BS message, or an additional CN-to-BS message similar to the first or subsequent CN-to-BS message. In such a case, the CU 172 includes additional transport layer configurations for the additional MBS session to configure additional common DL tunnels in the first BS-to-CN message, a subsequent BS-to-CN message, or an additional BS-to-CN message similar to the first or subsequent BS-to-CN message. Each of the transport layer configurations configures a specific common DL tunnel of the common DL tunnel and may be associated with a specific MBS session of the additional MBS session. Alternatively, the CN 110 can perform an additional MBS session resource setup procedure with the CU 172 to obtain the additional transport layer configurations from the CU 172, similar to the single-session MBS session resource setup procedure 586 shown in FIG. 5A. To distinguish different common DL tunnels, the transport layer configurations may be different. In particular, any pair of transport layer configurations may have different IP addresses, different DL TEIDs, or different IP addresses and different DL TEIDs.

[0066] In some implementations, the CN 110 may indicate a list of UEs participating in the first MBS session in the first CN-to-BS message. In other implementations, the CN 110 may send a second CN-to-BS message to the CU 172 indicating a list of UEs participating in the first MBS session (512). The CN 110 may include the first MBS session ID and / or PDU session ID in the second CN-to-BS message. The CU 172 may send a second BS-to-CN message to the CN 110 in response to the second CN-to-BS message 512 (519). In such a case, the second CN-to-BS message may be a non-UE-specific message, e.g., a message that is not specific to the UE 102A or the UE 102B. The CU 172 may include the first MBS session ID and / or PDU session ID in the second BS-to-CN message. For example, the list of UEs may include the UE 102A and / or the UE 102B. To indicate the list of UEs, the CN 110 may include a list of (CN UE interface ID, RAN UE interface ID) pairs, each identifying a specific UE of the UE. The CN 110 assigns the CN UE interface ID, and the CU 172 assigns the RAN UE interface ID. The CN 110 sends the list of (CN UE interface ID, RAN UE interface ID) pairs in a second CN-to-BS message (512), the CU 172 sends a BS-to-CN message (e.g., an NGAP message, an INITIAL UE MESSAGE, or a PATH SWITCH REQUEST message) including the RAN UE interface ID to the CN 110 for each of the UEs (not shown), and the CN 110 sends a CN-to-BS message (e.g., an NGAP message, an INITIAL CONTEXT SETUP REQUEST message, or a PATH SWITCH REQUEST ACKNOWLEDGE message) including the CN UE interface ID to the CU 172 for each of the UEs (not shown).In one example, the list of pairs includes a first pair (first CN UE interface ID and first RAN UE interface ID) identifying the UE 102A and a second pair (second CN UE interface ID, second RAN UE interface ID) identifying the UE 102B. In some implementations, the "CN UE interface ID" may be an "AMF UE NGAP ID," and the "RAN UE interface ID" may be a "RAN UE NGAP ID." In other implementations, the CN 110 may include a list of UE IDs, each identifying a specific UE of the UEs. In some implementations (not shown), the CN 110 may assign the UE IDs and transmit each of the UE IDs to a specific UE of the UEs in a NAS procedure (e.g., a registration procedure) that the CN 110 performs with the specific UE. For example, the list of UE IDs may include a first UE ID of the UE 102A and a second UE ID of the UE 102B. In some implementations, the UE IDs are S-Temporary Mobile Subscriber Identities (S-TMSIs) (e.g., 5G-S-TMSI). Before the CN 110 sends (512) the list of UE IDs, the CU 172 may receive (not shown) the UE IDs from the UE 102 or the CN 110 for each of the UEs. For example, the CU 172 may receive (not shown) an RRC message (e.g., an RRCSetupComplete message) from the UE 102 during an RRC connection establishment procedure that includes the UE IDs. In another example, the CU 172 may receive (not shown) a CN-to-BS message (e.g., an NGAP message, an INITIAL CONTEXT SETUP REQUEST message, or a UE INFORMATION TRANSFER message) from the CN 110 that includes the UE IDs.

[0067] In other implementations, the CN 110 may send a second CN-to-BS message to the CU 172 indicating (only) the UE 102 (e.g., either UE 102A or UE 102B) that will participate in the first MBS session (512). The second CN-to-BS message may be a UE-related message for the UE 102. That is, the second CN-to-BS message is specific to the UE 102. In response to receiving the second CN-to-BS message, the CU 172 may send a UE context request message for the UE 102 to the DU 174 (514). In some implementations, the CU 172 may include the first MBS session ID and / or an MRB ID of an MRB associated with the first MBS session (ID) in the UE context request message. In response to the UE context request message, the DU 174 sends a UE context response message to the CU 172 that includes configuration parameters for the UE 102 to receive MBS data of the first MBS session (516). In some implementations, the CU 172 can include the QoS configuration in the UE context request message. In such a case, the CU 172 may or may not include the QoS configuration in the CU-to-DU message sent (506) during the MBS session resource setup procedure 586. (Part of) the configuration parameters may be associated with the MRB / MRB ID. In some implementations, the DU 174 generates a DU configuration to include the configuration parameters and includes the DU configuration in the UE context response message. In some implementations, the DU configuration may be a CellGroupConfig IE. In other implementations, the DU configuration may be an MBS-specific IE. In some implementations, the configuration parameters configure one or more logical channels (LCs). For example, the configuration parameters may include one or more logical channel IDs (LCIDs) for configuring one or more logical channels. Each LCID identifies a specific logical channel of the one or more logical channels.

[0068] In some implementations, the second CN-to-BS message and the second BS-to-CN message may be a PDU session resource modification request message and a PDU session resource modification response message, respectively. In some implementations, the second CN-to-BS message and the second BS-to-CN message may be UE-related messages, i.e., the messages are associated with a particular UE (e.g., UE 102A or 102B).

[0069] If the CN 110 admits an additional MBS session for the UE 102 in the additional MBS session join procedure, the CN 110 may include an additional MBS session ID and / or QoS configuration for the additional MBS session ID in the first CN-to-BS message or the second CN-to-BS message. In such a case, the CU 172 may include an additional MBS session ID and MRB ID in the CU-to-DU message, and the DU 174 may include an additional DU transport layer configuration for configuring an additional CN-to-BS DL tunnel for the additional MBS session in the DU-to-CU message. Alternatively, the CU 172 may perform an additional MBS session resource setup procedure with the DU 174 to obtain the additional DU DL transport layer configuration, similar to events 506 and 508. In some implementations, the CU 172 includes an additional CU DL transport layer configuration for the additional MBS session in the first BS-to-CN message for configuring an additional CN-to-BS common DL tunnel. Each of the transport layer configurations configures a specific DL tunnel of the common CN-to-BS DL tunnel and may be associated with a specific MBS session of the additional MBS session. Alternatively, the CN 110 can perform additional MBS session resource setup procedures with the CU 172, similar to the MBS session resource setup procedure 586, to obtain additional CU DL transport layer configurations from the CU 172. The transport layer configurations may be different to distinguish between different common DL tunnels. In particular, any pair of transport layer configurations may have different IP addresses, different DL TEIDs, or different IP addresses and different DL TEIDs.

[0070] In some implementations, the CN 110 includes the QoS configuration in the second CN-to-BS message. In such a case, the CN 110 may include the QoS configuration in the first CN-to-BS message or may omit the QoS configuration. In some implementations, the DU 174 generates configuration parameters for the UE 102 to receive MBS data of the first MBS session in response to receiving the CU-to-DU message (506) or receiving the UE context request message (514). In some implementations, the CU 172 includes the QoS configuration in the UE context request message and / or the CU-to-DU message. The DU 174 can determine the content of the configuration parameters according to the QoS configuration. When the CU 172 does not include the QoS configuration in either the CU-to-DU message or the UE context request message, the DU 174 can determine the value of the configuration parameter according to a predetermined (default) QoS configuration.

[0071] In some implementations, the UE context request message and the UE context response message are UE Context Setup Request and UE Context Setup Response messages, respectively. In other implementations, the UE context request message and the UE context response message are UE Context Modification Request and UE Context Modification Response messages, respectively.

[0072] After receiving the UE context response message (516), the CU 172 generates an RRC reconfiguration message including the configuration parameters and one or more MRB configurations and sends the RRC reconfiguration message (518) to the DU 174. The DU 174 then sends the RRC reconfiguration message (520) to the UE 102. The UE 102 then sends an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the DU 174 (522), and the DU 174 sends the RRC reconfiguration complete message to the CU 172 (523).

[0073] Events 512, 514, 516, 518, 519, 520, 522, and 523 are collectively referred to in Figure 5A as MBS radio connection reconfiguration procedure 588. Events 514, 516, 518, 520, 522, and 523 are collectively referred to in Figure 5A as MBS radio connection reconfiguration procedure 589.

[0074] In some implementations, the CU 172 generates a PDCP PDU including the RRC reconfiguration message and transmits a CU-to-DU message including the PDCP PDU to the DU 174 (518), and the DU 174 extracts the PDCP PDU from the CU-to-DU message and transmits the PDCP PDU to the UE 102 via the RLC layer 206B, the MAC layer 204B, and the PHY layer 202B (520). The UE 102 receives the PDCP PDU from the DU 174 via the PHY layer 202B, the MAC layer 204B, and the RLC layer 206B (520). In some implementations, the UE 102 generates a PDCP PDU including the RRC reconfiguration complete message and transmits the PDCP PDU to the DU 174 via the RLC layer 206B, the MAC layer 204B, and the PHY layer 202B (522). The DU 174 receives PDCP PDUs from the UE 102 via the PHY layer 202B, the MAC layer 204B, and the RLC layer 206B (522) and sends DU-to-CU messages containing the PDCP PDUs to the CU 172 (523). The CU 172 extracts the PDCP PDUs from the DU-to-CU messages and extracts the RRC reconfiguration complete message from the PDCP PDUs.

[0075] Before or after receiving the UE context response message (516), the CU 172 can send a second BS-to-CN message to the CN 110 in response to the second CN-to-BS message 512 (519). In some implementations, the CU 172 sends the second BS-to-CN message to the CN 110 (519) before receiving the RRC reconfiguration complete message (523). In other implementations, the CN 110 sends the second BS-to-CN message to the CN 110 (519) after receiving the RRC reconfiguration complete message (523). The CU 172 can include the first CN UE interface ID and the first RAN UE interface ID in the second BS-to-CN message. Alternatively, the CU 172 can include the first UE ID in the second BS-to-CN message.

[0076] In some implementations, a respective instance of the MBS radio connection reconfiguration procedure 588 exists for each of the UE 102A and the UE 102B. The configuration parameters for the UE 102A and the UE 102B to receive MBS data of the first MBS session may be the same.

[0077] In some implementations, the CU 172 includes the CU DL transport layer configuration in the second BS-to-CN message and / or a subsequent BS-to-CN message. In other words, the CU 172 can send the same CU DL transport layer configuration in a BS-to-CN message in response to the CN-to-BS message indicating that the UE will participate in the same MBS session. In such implementations, the CN 110 can blend the MBS resource setup procedure 586 and the MBS radio connection reconfiguration procedure 588 into a single procedure.

[0078] When the CU 172 performs the MBS resource setup procedure 586 (e.g., events 504, 510) with the CN 110 to establish a common CN-to-BS DL tunnel for the first MBS session, the CU 172 may refrain from including the DL transport layer configuration for the first MBS session in the second BS-to-CN message. In such a case, the CN 110 may refrain from including the UL transport layer configuration for the first MBS session in the second CN-to-BS message. When the DU 174 performs the MBS resource setup procedure 586 (e.g., events 506, 508) with the CU 172 to establish a common CU-to-DU DL tunnel for the first MBS session, the DU 174 may refrain from including the DL transport layer configuration for the first MBS session in the UE context response message. In such a case, the CU 172 may refrain from including the UL transport layer configuration for the first MBS session in the UE context request message.

[0079] After receiving the first BS-to-CN message (510) or the second BS-to-CN message (519), the CN 110 can transmit MBS data (e.g., one or more MBS data packets, also interchangeably referred to herein as “MBS content data” or “MBS payload data”) to the CU 172 via the common CN-to-BS DL tunnel (524), and the CU 172 transmits the MBS data to the DU 174 via the common CU-to-DU tunnel (526). The DU 174 transmits (e.g., multicast or unicast) the MBS data to the UE 102 (e.g., UE 102A and / or UE 102B) via one or more logical channels (528). The UE 102 receives the MBS data via one or more logical channels (528). For example, the CU 172 receives the MBS data packet (524), generates a PDCP PDU including the MBS data packet, and transmits the PDCP PDU to the DU 174 (526). The DU 174 then generates a MAC PDU including the logical channel ID and the PDCP PDU and transmits the MAC PDU to the UE 102 via multicast or unicast (528). The UE 102 receives the MAC PDU via multicast or unicast (528), extracts the PDCP PDU and the logical channel ID from the MAC PDU, identifies the PDCP PDU associated with the MRB according to the logical channel ID, and extracts the MBS data packet from the PDCP PDU according to the PDCP configuration in the MRB configuration.

[0080] In some implementations, the CU 172 may configure (determine) a UE-specific CN-to-BS DL tunnel for the UE 102 in response to receiving the first CN-to-BS message (504) or the second CN-to-BS message (512). In such a case, the CU 172 may omit event 506 and may include in the second BS-to-CN message a DL transport layer configuration for configuring the UE-specific DL tunnel. The CN 110 may transmit (524) the MBS data to the CU 172 via the UE-specific CN-to-BS DL tunnel. In some implementations, the CU 172 may configure (determine) a UE-specific CU-to-DU DL tunnel for the UE 102 in response to receiving the first CN-to-BS message (504) or the second CN-to-BS message (512). In such a case, the CU 172 may omit event 510 and the DU 174 may include in the UE context response message a DL transport layer configuration for configuring the UE-specific CU-to-DU DL tunnel. In such a case, the CU 172 may transmit the MBS data to the DU 174 via the UE-specific CU-to-DU DL tunnel (526).

[0081] In some implementations, one or more MRB configurations constituting one or more MRBs are associated with the first MBS session. In some implementations, the configuration parameters also include one or more RLC bearer configurations, each associated with a particular MRB. Each of the MRB configurations may include an MRB ID, a PDCP configuration, a first MBS session ID, a PDCP reestablishment indication (e.g., reestablishPDCP), and / or a PDCP recovery indication (e.g., recoveryPDCP). In some implementations, the PDCP configuration may be a PDCP-Config IE for the DRB. In other implementations, the RLC bearer configuration may be an RLC-BearerConfig IE. In some implementations, the RLC bearer configuration may include a logical channel (LC) ID constituting a logical channel. In some implementations, the logical channel may be a multicast traffic channel (MTCH). In other implementations, the logical channel may be a dedicated traffic channel (DTCH). In some implementations, the configuration parameters may include a logical channel configuration (e.g., a LogicalChannelConfig IE) constituting a logical channel. In some implementations, the RLC bearer configuration may include an MRB ID.

[0082] In some implementations, the CU 172 can configure the MRB as a DL-only RB in the MRB configuration. For example, the CU 172 refrains from including UL configuration parameters in the PDCP configuration in the MRB configuration to configure the MRB as a DL-only RB. The CU 172 includes only DL configuration parameters in the MRB configuration, for example, as described above. In such a case, the CU 172 MRBThe UE 102 is configured to not transmit UL PDCP data PDUs to the DU 174 and / or CU 172 via the MRB by not including UL configuration parameters for the MRB in the PDCP configuration in the configuration. In another example, the DU 174 refrains from including UL configuration parameters in the RLC bearer configuration. In such a case, the DU 174 configures the UE 102 to not transmit control PDUs to the base station 104 via logical channels by not including UL configuration parameters in the RLC bearer configuration.

[0083] If the DU 174 includes an UL configuration parameter in the RLC bearer configuration, the UE 102 may transmit a control PDU (e.g., a PDCP control PDU and / or an RLC control PDU) to the DU 174 via a logical channel using the UL configuration parameter. If the control PDU is a PDCP control PDU, the DU 174 may transmit the PDCP control PDU to the CU 172. For example, the CU 172 may configure the UE 102 to receive MBS data using a compression (decompression) protocol (e.g., a robust header compression (ROHC) protocol), for example, in the MRB configuration. In this case, when the CU 172 receives an MBS data packet from the CN 110 (524), the CU 172 compresses the MBS data packet using the compression protocol to obtain a compressed MBS data packet and transmits a PDCP PDU including the compressed MBS data packet to the DU 174 via a common CU-to-DU DL tunnel (526). The DU 174 then transmits (e.g., multicast or unicast) the PDCP PDU to the UE 102 via the logical channel (528). When the UE 102 receives the PDCP PDU via the logical channel, the UE 102 extracts the compressed MBS data packet from the PDCP PDU. The UE 102 decompresses the compressed MBS data packet using a compression (decompression) protocol to obtain the original MBS data packet. In such a case, the UE 102 may transmit a PDCP control PDU including header compression protocol feedback (e.g., interspersed ROHC feedback) for the operation of the header compression (decompression) protocol to the DU 174 via the logical channel. The DU 174 then transmits the PDCP control PDU to the CU 172 via a UE-specific UL tunnel, i.e., the UL tunnel is specific to the UE 102 (e.g., UE 102A). In some implementations, the CU 172 can include a CU UL transport layer configuration for configuring the UE-specific UL tunnel in the UE context request message.The CU UL transport layer configuration includes a CU transport layer address (eg, an Internet Protocol (IP) address) and a CU UL TEID to identify a UE-specific UL tunnel.

[0084] In some implementations, the MRB configuration may be an MRB-ToAddMod IE (e.g., mrb-Identity or MRB-Identity) that includes an MRB ID. The MRB ID identifies a particular MRB of the MRBs. The base station 104 sets the MRB ID to a different value. When the CU 172 configures a DRB for the UE 102 for unicast data communication, in some implementations, the CU 172 may set one or more of the MRB IDs to a value different from the DRB ID of the DRB. In such a case, the UE 102 and the CU 172 may distinguish whether an RB is an MRB or a DRB according to the RB ID of the RB. In other implementations, the CU 172 may set one or more of the MRB IDs to a value that may be the same as the DRB ID. In such a case, the UE 102 and the CU 172 may distinguish whether an RB is an MRB or a DRB according to the RB ID of the RB and the RRC IE that configures the RB. For example, a DRB configuration that configures a DRB is a DRB-ToAddMod IE that includes DRB identification information (e.g., drb-Identity or DRB-Identity) and a PDCP configuration. Thus, the UE 102 can determine that an RB is a DRB if it receives a DRB-ToAddMod IE that configures an RB, and can determine that an RB is an MRB if it receives an MRB-ToAddMod IE that configures an RB. Similarly, the CU 172 can determine that an RB is a DRB if it sends a DRB-ToAddMod IE that configures an RB to the UE 102, and can determine that an RB is an MRB if it sends an MRB-ToAddMod IE that configures an RB to the UE 102.

[0085] In some implementations, the configuration parameters for receiving MBS data of the first MBS session include one or more logical channel (LC) IDs for configuring one or more logical channels. In some implementations, the logical channel may be a DTCH. In other implementations, the logical channel may be an MTCH. In some implementations, the configuration parameters may or may not include a group radio network temporary identifier (G-RNTI). An RRC reconfiguration message for the UEs (e.g., UE 102A and UE 102B) participating in the first MBS session includes the same configuration parameters as for receiving MBS data of the first MBS session. In some implementations, the RRC reconfiguration message for the UEs may include the same or different configuration parameters as for receiving non-MBS data.

[0086] In some implementations, the CU 172 can include an MBS session join response message in an RRC reconfiguration message. The UE 102 can include an MBS session join complete message in an RRC reconfiguration complete message. Alternatively, the UE 102 can send an UL RRC message including the MBS session join complete message to the CU 172 via the DU 174. The UL RRC message can be any appropriate RRC message that can include a UL information transfer message or a UL NAS PDU. The CU 172 can include the MBS session join complete message in a second BS-to-CN message. Alternatively, the CU 172 can send a BS-to-CN message (e.g., an UPLINK NAS TRANSPORT message) including the MBS session join complete message to the CN 110.

[0087] In another implementation, the CU 172 sends a DL RRC message including an MBS Session Join Response message to the UE 102. The DL RRC message may be a DL Information Transfer message, another RRC Reconfiguration message, or any suitable RRC message that may include a DL NAS PDU. The UE 102 may send a UL RRC message including an MBS Session Join Complete message to the CU 172 via the DU 174. The UL RRC message may be a UL Information Transfer message, another RRC Reconfiguration Complete message, or any suitable RRC message that may include a UL NAS PDU.

[0088] 5A , the UE 103 may perform an MBS session join procedure similar to procedure 502 discussed above (530). The UE 103 may perform a PDU session establishment procedure with the CN 110 via the base station 104, as described with reference to procedure 502. The UE 103 may communicate a PDU session ID with the CN 110 in the PDU session establishment procedure. The UE 103 may join the same MBS session as the UE 102 by sending an MBS session join request and specifying the same MBS session ID. In this example scenario, the UE 103 joins the MBS session after the base station 104 begins transmitting MBS data packets to the UE 102 (528). The CN 110 sends a CN-to-BS message including the MBS session ID and / or PDU session ID to the CU 172 to indicate that the UE 103 should begin receiving MBS data for the MBS session corresponding to the MBS session ID (532).

[0089] In some scenarios, the CU 172 or the CN 110 determines that a DL tunnel already exists for the MBS session identified in event 532 and that there is no need to perform procedure 586. However, optionally, the CU 172 sends a CU-to-DU message to the DU 174 to trigger an MBS radio connection reconfiguration procedure for the first MBS session similar to event 589 (534), and the DU 174 responds with a DU configuration (536).

[0090] The CU 172 sends an RRC reconfiguration message to the DU 174 (538), and the DU 174 sends an RRC reconfiguration message to the UE 103 to configure the UE 103 to receive MBS traffic (540). The RRC reconfiguration message may include the same LCID (value), MRB configuration, and RLC bearer configuration as in event 520 when the UE 102 (i.e., UE 102A and / or UE 102B) operates in the same cell as the UE 103. When the UEs 102 and 103 operate in different cells, the RRC reconfiguration message may have, for example, different G-RNTI, LCID, and / or RLC bearer configuration. The RRC reconfiguration message may include the same MRB configuration as in event 520 when the UEs 102 and 103 operate in different cells. As shown in FIG. 3, the CU 172 can map data packets arriving via the common CN-to-BS DL tunnel to one or more MRBs, each corresponding to a common CU-to-DU DL tunnel and / or a respective logical channel.

[0091] In response to the RRC reconfiguration message of event 540, the UE 103 sends an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the base station 104 (specifically to the DU 174) (542). In response to the DU 174 of the base station 104 receiving the RRC reconfiguration complete message (542), the DU 174 sends an RRC reconfiguration complete message to the CU 172 (not shown in FIG. 5A ). Before or after receiving the RRC reconfiguration complete message (542), the base station 104 in some cases sends another BS-to-CN message to the CN 110 (539), e.g., in a manner generally similar to event 519. The BS-to-CN message can indicate, for example, an updated list of UEs associated with the MBS session specified in event 532. After the UE 103 joins the MBS session (530) and acquires the required RRC configuration (at event 540), the CU 172 continues to receive MBS data via the common CN-to-BS DL tunnel (544) and transmits MBS data to the DU 174 via the common CU-to-DU DL tunnel (546). In some implementations, the DU 174 transmits MBS data to the UE 102 and the UE 103 via multicast (548). The UE 102 and the UE 103 can receive the MBS data similar to event 528 (548). Alternatively, the base station 104 can transmit the MBS data to the UE 102 and the UE 103 separately via unicast (548).

[0092] 5B, a scenario 500B is shown that is generally similar to scenario 500A, but in which the CN 110 provides a list of UEs participating in a non-MBS session before, rather than after, configuring a CN-to-BS tunnel for an MBS. Events in this scenario similar to those discussed above are labeled with the same reference numbers, and the examples and implementations of FIG. 5A may apply to FIG. 5B. Differences between the scenarios of FIG. 5A and FIG. 5B are discussed below.

[0093] The UE 102 performs a PDU session establishment procedure with the CN 110 via the base station 104 (550), similar to procedure 502, but for a non-MBS session. Following procedure 500, the CN 110 sends a CN-to-BS message including a PDU session ID to the CU 172 (552). The CU 172 sends a CU-to-DU message to the DU 174 to trigger a reconfiguration procedure for the PDU session (554), and the DU 174 responds with a DU configuration (556). The following events 558, 560, 562, and 563 are similar to events 518, 520, 522, and 523 in FIG. 5A , but for DRM configuration rather than MRB configuration. Before or after receiving the RRC reconfiguration complete message (562), the base station 104 may in some cases send another BS-to-CN message to the CN 110 (559), e.g., in a manner generally similar to event 519. The BS-to-CN message may, for example, indicate an updated list of UEs associated with the MBS session specified at event 552. After the UE 102 acquires the necessary RRC configuration (560), the CU 172 continues to receive non-MBS data via the UE-specific CN-to-BS DL tunnel (564) and transmits the non-MBS data to the DU 174 via the UE-specific CU-to-DU DL tunnel and via unicast (566). Thus, the UE 102 can receive non-MBS data from the DU 174 (568).

[0094] In such a case, the CN 110 may include the additional MBS session ID and, optionally, the QoS configuration for the additional MBS session ID in the CN-to-BS message in the MBS resource setup and UE-specific MBS session configuration procedure, similar to the first or second CN-to-BS message. In such a case, the CU 172 may include additional transport layer configurations for the additional MBS session to configure the additional common DL tunnel in the BS-to-CN message in the MBS resource setup and UE-specific MBS session configuration procedure, similar to the first or second BS-to-CN message. Each of the transport layer configurations may configure a specific common DL tunnel of the common DL tunnel and be associated with a specific MBS session of the additional MBS session. The transport layer configurations may be different to distinguish different common DL tunnels. In particular, any pair of transport layer configurations may have different IP addresses, different DL TEIDs, or different IP addresses and different DL TEIDs.

[0095] A UE that is receiving or interested in receiving MBS can send an MBS interest indication to the network (e.g., to the CN 110). Based on the MBS interest indication, the network attempts to enable the UE to receive MBS and unicast services, subject to the UE's capabilities, e.g., the UE's radio capabilities. In the MBS interest indication, the UE can indicate a set of frequencies (including one or more frequencies) on which the UE is receiving or interested in receiving MBS. The MBS interest indication can also indicate a list of MBS services that the UE is receiving or interested in receiving on the indicated one or more frequencies. Furthermore, the UE can send an MBS interest indication regardless of whether the serving cell supports MBS. In some cases, the UE can send a first MBS interest indication to the network and later send a second, updated MBS interest indication.

[0096] Generally, a UE (e.g., UE 102A) and / or a RAN (e.g., RAN 105) manage information related to MBSs. In response to determining that the radio connection between the UE and the RAN should be modified, the UE can decide to either maintain or release the MBS interest indication. If the UE maintains the MBS interest indication, the UE can later send an MBS interest indication update to the RAN. If the UE releases the MBS interest indication, the UE can send another MBS interest indication to the RAN after modifying the radio connection.

[0097] Similarly, a node of the RAN (e.g., base station 104 or DU 174 and / or CU 172) may also receive an MBS interest indication from the UE and, in response to determining that the radio connection between the UE and the RAN should be modified, may either maintain or release the configuration included in the MBS interest indication. Triggering events that may cause the UE and / or RAN to decide to release or maintain the MBS interest indication may include, for example, the UE detecting a failure in the radio connection or the UE suspending, resuming, or re-establishing its radio connection with the RAN.

[0098] Additionally, the MBS interest indication may be stored in the receiving RAN node, in other RAN nodes, and / or in one or more CNs of the wireless communications system. For example, a RAN node that receives the MBS interest indication from the UE may forward the received UE MBS interest indication to another RAN node, a CN, etc., any of which may forward the UE MBS interest indication to other RAN nodes and / or CNs.

[0099] 6A , an exemplary method 600A for determining whether to transmit a data packet using multicast or unicast depending on whether the data packet arrived via a common tunnel or a UE-specific tunnel may be implemented, for example, in a RAN node (e.g., a base station 104 or a DU 174) of the present disclosure. The method 600A begins at block 602, where the RAN node receives a data packet from an upstream node (e.g., events 518, 524, 526, 538, 544, 546, 564, 566). At block 604, the RAN node determines whether the data packet was received via a common DL tunnel. If the data packet was received via the common DL tunnel, at block 606, the RAN node transmits the data packet to multiple UEs via multicast (e.g., events 528, 548). If the data packet was not received via a common DL tunnel (e.g., if the data packet was received via a UE-specific DL tunnel or via a control plane message), then in block 608, the RAN node transmits the data packet via unicast to the specific UE (e.g., events 520, 540, 560, 568).

[0100] 6B, an exemplary method 600B for determining whether to transmit a data packet using multicast or unicast depending on whether the data packet arrived via a first tunnel or a second tunnel may be implemented, for example, in a RAN node (e.g., a base station 104 or a DU 174) of the present disclosure. Method 600B is generally similar to method 600A, except that after block 602, rather than proceeding to block 604 as in method 600A, method 600B proceeds to block 605, where the RAN node determines whether the data packet was received via the first DL tunnel or the second DL tunnel. If the data packet was received via the first DL tunnel, then in block 606, the RAN node transmits the data packet to multiple UEs via multicast. If the data packet was received via the second DL tunnel, then in block 608, the RAN node transmits the data packet to a specific UE via unicast.

[0101] 7, an exemplary method 700 for determining whether to transmit a data packet using multicast or unicast depending on whether the tunnel through which the data packet arrived has a first transport layer configuration or a second transport layer configuration may be implemented, for example, in a RAN node (e.g., base station 104) of the present disclosure. Method 700 begins at block 702, where the RAN node configures a first DL transport layer configuration including first transport layer information for receiving packets from an upstream node (e.g., events 508, 510). At block 704, the RAN node configures a second DL transport layer configuration including second transport layer information for receiving packets from the upstream node (e.g., events 508, 510). At block 706, the RAN node receives a DL tunnel packet and a specific data packet including the specific transport layer information from the upstream node (e.g., events 518, 524, 526, 538, 544, 546, 564, 566). At block 708, the RAN node determines whether the specific transport layer information from the DL tunnel packet is first transport layer information or second transport layer information. If the specific transport layer information is first transport layer information, method 700 proceeds to block 606, where the RAN node transmits the data packet to multiple UEs via multicast (e.g., events 528, 548). If the specific transport layer information is second transport layer information, method 700 proceeds to block 608, where the RAN node transmits the data packet to the specific UE via unicast (e.g., events 520, 540, 560, 568).

[0102] 8A , an exemplary method 800A for selecting a first logical channel identifier or a second logical channel identifier for a data packet depending on whether the data packet arrived via a common tunnel or a UE-specific tunnel may be implemented, for example, in a RAN node (e.g., a base station 104 or a DU 174) of the present disclosure. The method 800A begins at block 802, where the RAN node receives a data packet from an upstream node (e.g., events 518, 524, 526, 538, 544, 546, 564, 566). At block 804, the RAN node determines whether the data packet was received via a common DL tunnel. If the data packet was received via the common DL tunnel, at block 806, the RAN node selects a first logical channel ID. At block 808, the RAN node generates a PDU including the first logical channel ID and the data packet. At block 810, the RAN node transmits the PDU to multiple UEs via multicast (eg, events 528, 548).

[0103] If the data packet was not received via a common DL tunnel (e.g., if the data packet was received via a UE-specific DL tunnel or via a control plane message), the RAN node selects a second logical channel ID in block 812. In block 814, the RAN node generates a PDU including the second logical channel ID and the data packet. In block 816, the RAN node transmits the PDU via unicast to the specific UE (e.g., events 520, 540, 560, 568).

[0104] Referring now to FIG. 8B, an exemplary method 800B for selecting a first or second logical channel identifier for a data packet depending on whether the data packet arrived via a first tunnel or a second tunnel may be implemented, for example, in a RAN node (e.g., a base station 104 or a DU 174) of the present disclosure. Method 800B is generally similar to method 800A, except that after block 802, instead of proceeding to block 804 as in method 800A, method 800B proceeds to block 805, where the RAN node determines whether the data packet was received via the first DL tunnel or the second DL tunnel. If the data packet was received via the first DL tunnel, then in block 806, the RAN node selects a first logical channel ID. In block 808, the RAN node generates a PDU including the first logical channel ID and the data packet. In block 810, the RAN node transmits the PDU to multiple UEs via multicast.

[0105] The data packet is received via the second DL tunnel. was If so, the RAN node selects a second logical channel ID in block 812. The RAN node generates a PDU including the second logical channel ID and the data packet in block 814. The RAN node transmits the PDU via unicast to the specific UE in block 816.

[0106] 9, an exemplary method 900 for selecting a first logical channel identifier or a second logical channel identifier for a data packet depending on whether the tunnel through which the data packet arrived has a first transport layer configuration or a second transport layer configuration may be implemented in a RAN node (e.g., base station 104) of the present disclosure in an example. Method 900 begins at block 902, where the RAN node configures a first DL transport layer configuration including first transport layer information for receiving packets from an upstream node. At block 904, the RAN node configures a second DL transport layer configuration including second transport layer information for receiving packets from the upstream node. At block 906, the RAN node receives a DL tunnel packet from the upstream node including particular transport layer information and a particular data packet (e.g., events 518, 524, 526, 538, 544, 546, 564, 566). At block 908, the RAN node determines whether the particular transport layer information from the DL tunnel packet is first transport layer information or second transport layer information. If the particular transport layer information is first transport layer information, method 900 proceeds to block 910, which includes blocks 806, 808, and 810 as discussed above with respect to Figures 8A and 8B. If the particular transport layer information is second transport layer information, method 900 proceeds to block 912, which includes blocks 812, 814, and 816 as discussed above with respect to Figures 8A and 8B.

[0107] 10A , an exemplary method 1000A for selecting a Group Network Temporary Identifier (G-RNTI) and a first logical channel or a UE-specific RNTI (C-RNTI) and a second logical channel for a data packet depending on whether the data packet arrived via a common tunnel or a UE-specific tunnel may be implemented in a RAN node (e.g., a base station 104 or a DU 174) of the present disclosure in an example. Method 1000A begins at block 1002, where the RAN node receives a data packet from an upstream node (e.g., events 518, 524, 526, 538, 544, 546, 564, 566). At block 1004, the RAN node determines whether the data packet was received via the common DL tunnel.

[0108] If the data packet is received via the common DL tunnel, the RAN node selects a first logical channel ID and a G-RNTI in block 1006. In block 1008, the RAN node generates a PDU including the first logical channel ID and the data packet. In block 1010, the RAN node generates a DCI and a CRC of the DCI to schedule a PDSCH transmission of the PDU. In block 1012, the RAN node scrambles the CRC with the G-RNTI to obtain a scrambled CRC.

[0109] If the data packet was not received via a common DL tunnel (e.g., the data packet was received via a UE-specific DL tunnel or via a control plane message), the RAN node selects a second logical channel ID and a C-RNTI in block 1014. In block 1016, the RAN node generates a PDU including the second logical channel ID and the data packet. In block 1018, the RAN node generates a DCI and a CRC of the DCI to schedule a PDSCH transmission of the PDU. In block 1020, the RAN node scrambles the CRC with the C-RNTI to obtain a scrambled CRC.

[0110] In either case, after block 1012 or block 1020, respectively, method 1000A proceeds to block 1022, where the RAN node transmits the DCI and scrambled CRC on the PDCCH. In block 1024, the RAN node transmits a PDSCH transmission of the PDU in accordance with the DCI.

[0111] 10B, an exemplary method 1000B for selecting a G-RNTI and a first logical channel or a C-RNTI and a second logical channel for a data packet depending on whether the data packet arrived via a first tunnel or a second tunnel may be implemented in an example RAN node (e.g., a base station 104 or a DU 174) of the present disclosure. Method 1000B is generally similar to method 1000A, except that after block 1002, rather than proceeding to block 1004 as in method 1000A, method 1000B proceeds to block 1005, where the RAN node determines whether the data packet was received via the first DL tunnel or the second DL tunnel.

[0112] If the data packet is received via the first DL tunnel, the RAN node selects a first logical channel ID and a G-RNTI in block 1006. In block 1008, the RAN node generates a PDU including the first logical channel ID and the data packet. In block 1010, the RAN node generates a DCI and a CRC of the DCI to schedule a PDSCH transmission of the PDU. In block 1012, the RAN node scrambles the CRC with the G-RNTI to obtain a scrambled CRC.

[0113] The data packet is received via the second DL tunnel. was If so, in block 1014, the RAN node selects a second logical channel ID and a C-RNTI. In block 1016, the RAN node generates a PDU including the second logical channel ID and the data packet. In block 1018, the RAN node generates a DCI and a CRC of the DCI to schedule a PDSCH transmission of the PDU. In block 1020, the RAN node scrambles the CRC with the C-RNTI to obtain a scrambled CRC.

[0114] In either case, after block 1012 or block 1020, respectively, method 1000A proceeds to block 1022, where the RAN node transmits the DCI and scrambled CRC on the PDCCH. At block 1024, the RAN node transmits a PDSCH transmission of the PDU in accordance with the DCI.

[0115] 11 , an exemplary method 1100 for selecting a G-RNTI and a first logical channel or a C-RNTI and a second logical channel for a data packet depending on whether the tunnel through which the data packet arrived is a first transport layer configuration or a second transport layer configuration may be implemented, for example, in a RAN node (e.g., base station 104) of the present disclosure. Method 1100 begins at block 1102, where the RAN node configures a first DL transport layer configuration including first transport layer information for receiving packets from an upstream node. At block 1104, the RAN node configures a second DL transport layer configuration including second transport layer information for receiving packets from the upstream node. At block 1106, the RAN node receives a DL tunnel packet from the upstream node (e.g., events 518, 524, 526, 538, 544, 546, 564, 566) including specific transport layer information and a specific data packet. At block 1108, the RAN node determines whether the particular transport layer information from the DL tunnel packet is first transport layer information or second transport layer information. If the particular transport layer information is first transport layer information, method 1100 proceeds to block 1110, which includes blocks 1006, 1008, 1010, 1012, 1022, and 1024, as discussed above with respect to Figures 10A and 10B. If the particular transport layer information is second transport layer information, method 1100 proceeds to block 1112, which includes blocks 1006, 1008, 1010, 1012, 1022, and 1024, as discussed above with respect to Figures 10A and 10B. 0A and Figure 1 0B As discussed above, the block 1014 includes blocks 1016, 1018, 1020, 1022, and 1024.

[0116] 12 , an exemplary method 1200 for selecting a first logical channel identifier or a second logical channel identifier for a data packet depending on whether the data packet is associated with a first quality of service (QoS) flow identifier or a second QoS flow identifier may be implemented in an RAN node (e.g., a base station 104 or a DU 174) of the present disclosure in an example. Method 1200 begins at block 1202, where the RAN node receives a data packet from an upstream node (e.g., events 518, 524, 526, 538, 544, 546, 564, 566). Method 1200 may then proceed to block 1250, which includes blocks 1204, 1206, 1208, 1210, 1212, and 1214. At block 1214, the RAN node determines whether the received data packet is associated with the first QoS flow identifier or the second QoS flow identifier.

[0117] If the data packet is associated with the first QoS flow identifier, the method 1200 proceeds to block 1206, where the RAN node selects a first logical channel ID. At block 1208, the RAN node generates a PDU that includes the first logical channel ID and the data packet.

[0118] If the data packet is associated with a second QoS flow identifier, the method 1200 proceeds to block 1210, where the RAN node selects a second logical channel ID. At block 1212, the RAN node generates a PDU that includes the second logical channel ID and the data packet.

[0119] In either case, after block 1208 or block 1212, respectively, the method 1200 proceeds to block 1214, where the RAN node transmits the PDU to multiple UEs via multicast.

[0120] 13 , an exemplary method 1300 for determining whether to select a first logical channel identifier or a second logical channel identifier for a data packet depending on whether the data packet is associated with a first QoS flow identifier or a second QoS flow identifier, or whether to select a second logical channel identifier for a data packet depending on whether a tunnel through which the data packet arrived has a first transport layer configuration or a second transport layer configuration, may be implemented in a RAN node (e.g., a base station 104) of the present disclosure in an example. The method 1300 begins at block 1302, where the RAN node configures a first DL transport layer configuration including first transport layer information for receiving packets from an upstream node. At block 1304, the RAN node configures a second DL transport layer configuration including second transport layer information for receiving packets from the upstream node. At block 1306, the RAN node receives a DL tunnel packet from an upstream node (e.g., events 518, 524, 526, 538, 544, 546, 564, 566) that includes specific transport layer information and a specific data packet. At block 1308, the RAN node determines whether the specific transport layer information from the DL tunnel packet is first transport layer information or second transport layer information. If the specific transport layer information is first transport layer information, the method 1300 If the particular transport layer information is second transport layer information, method 1300 proceeds to block 1312, which includes blocks 812, 814, and 816, as discussed above with respect to Figures 8A and 8B.

[0121] In different implementations, the RAN node may consider any suitable number of factors to select a transmission scheme, and the RAN node may perform blocks 1308, 1310, and 1312 in any suitable order to effectively assign different priorities to these factors.

[0122] 14, an exemplary method 1400 for selecting a first logical channel identifier and G-RNTI or a second logical channel identifier and G-RNTI for a data packet depending on whether the data packet is associated with a first QoS flow identifier or a second QoS flow identifier may be implemented in an RAN node (e.g., a base station 104 or a DU 174) of the present disclosure in an example. The method 1400 begins at block 1402 when the RAN node receives a data packet from an upstream node. The method 1400 then proceeds to block 1450, which includes blocks 1404, 1406, 1408, 1410, 1412, 1414, 1416, 1418, and 1420. At block 1404, the RAN node determines whether the received data packet is associated with the first QoS flow identifier or the second QoS flow identifier.

[0123] If the data packet is associated with the first QoS flow identifier, the method 1400 proceeds to block 1406, where the RAN node selects a first logical channel ID and a G-RNTI. At block 1408, the RAN node generates a PDU that includes the first logical channel ID and the data packet.

[0124] If the data packet is associated with a second QoS flow identifier, the method 1400 proceeds to block 1410, where the RAN node selects a second logical channel ID and a G-RNTI. At block 1412, the RAN node generates a PDU that includes the second logical channel ID and the data packet.

[0125] In either case, after block 1408 or block 1412, respectively, method 1400 proceeds to block 1414, where the RAN node generates the DCI and a CRC of the DCI to schedule a PDSCH transmission of the PDU. At block 1416, the RAN node scrambles the CRC with the G-RNTI to obtain a scrambled CRC. At block 1418, the RAN node transmits the DCI and scrambled CRC on a PDCCH. At block 1420, the RAN node transmits a PDSCH transmission of the PDU in accordance with the DCI.

[0126] Referring now to FIG. 15, an example method 1500 for determining whether to select a first logical channel identifier and G-RNTI or a second logical channel identifier and G-RNTI for a data packet depending on whether the data packet is associated with a first QoS flow identifier or a second QoS flow identifier, or for determining whether to select a second logical channel identifier and C-RNTI for a data packet depending on whether a tunnel through which the data packet arrived has a first transport layer configuration or a second transport layer configuration, may be implemented in a RAN node (e.g., base station 104) of the present disclosure in an example.

[0127] Method 1500 begins at block 1502, where a RAN node configures a first DL transport layer configuration including first transport layer information for receiving packets from an upstream node. At block 1504, the RAN node configures a second DL transport layer configuration including second transport layer information for receiving packets from the upstream node. At block 1506, the RAN node receives a DL tunnel packet from the upstream node, the DL tunnel packet including specific transport layer information and a specific data packet. At block 1508, the RAN node determines whether the specific transport layer information from the DL tunnel packet is the first transport layer information or the second transport layer information. If the particular transport layer information is first transport layer information, method 1500 proceeds to block 1510, which includes block 1450 (which includes blocks 1404, 1406, 1408, 1410, 1412, 1414, 1416, 1418, and 1420, as discussed above with respect to FIG. 14). If the particular transport layer information is second transport layer information, method 1500 proceeds to block 1512, which includes blocks 1014, 1016, 1018, 1020, 1022, and 1024, as discussed above with respect to FIG. 10A and FIG. 10B.

[0128] The following list of examples reflects various implementations expressly contemplated by this disclosure.

[0129] Example 1. A method for managing transmission of multicast and / or broadcast services (MBS), implemented in a node of a radio access network (RAN), comprising: receiving, by processing hardware, MBS data packets from an upstream node via a downlink (DL) tunnel; selecting, by the processing hardware, a multicast scheme for transmitting the MBS data packets to multiple UEs based on one or more properties of the DL tunnel; and transmitting, by the processing hardware, the data packets over the air interface using the multicast scheme in accordance with the selection to the multiple UEs.

[0130] Example 2. The method of Example 1, wherein the selecting step includes determining, via the node, that the DL tunnel is a common DL tunnel over which the upstream node is configured to transmit a single copy of the MBS data packet to multiple UEs.

[0131] Example 3. The method of Example 2, wherein the receiving, selecting, and transmitting steps occur in a first case, and further comprising, in a second case, receiving a second data packet via a UE-specific tunnel, selecting a unicast method for transmitting the second data packet to at least one certain UE based on the UE-specific tunnel, and transmitting the second data packet to the at least one certain UE via the air interface using the unicast method.

[0132] Example 4. The method of Example 1, wherein the selecting step includes determining that the DL tunnel is a first DL tunnel of a plurality of DL tunnels configured at the node.

[0133] Example 5. The method of Example 4, wherein the receiving, selecting, and transmitting steps occur in a first case, and further comprising, in a second case, receiving a second data packet via a second DL tunnel of a plurality of DL tunnels configured at the node, selecting a unicast scheme for transmitting the second data packet to at least one certain UE based on the second DL tunnel of the plurality of DL tunnels, and transmitting the second data packet to the at least one certain UE via the air interface using the unicast scheme.

[0134] Example 6. The method of Example 1, wherein the selecting step includes determining that the DL tunnel has a first transport layer configuration of a plurality of transport layer configurations at the node.

[0135] Example 7. The method of Example 6, wherein the receiving, selecting, and transmitting steps occur in a first case, and further comprising, in a second case, receiving a second data packet via a second DL tunnel, determining that the second DL tunnel has a second transport layer configuration at the node of a plurality of transport layer configurations, and transmitting the second data packet over the air interface to at least one certain UE using a unicast method.

[0136] Example 8. The method of any of the preceding examples, further comprising selecting a logical channel identifier based on one or more properties of the DL tunnel.

[0137] Example 9. The method of Example 8, wherein the transmitting step includes including an MBS data packet and a logical channel identifier in a protocol data unit (PDU).

[0138] Example 10. The method of example 8, wherein the logical channel selected for the MBS data packets is a multicast traffic channel (MTCH).

[0139] Example 11. The method of any of Examples 8 to 10, wherein the step of selecting a logical channel identifier is further based on a Quality of Service (QoS) flow identifier of the MBS data packet.

[0140] Example 12. The method of any of Examples 1 to 10, further comprising selecting a radio network temporary identifier (RNTI) based on one or more properties of the DL tunnel.

[0141] Example 13. The method of example 11, wherein the RNTI selected for the MBS data packet is a group RNTI (G-RNTI).

[0142] Example 14. The method of any of Examples 12 or 13, wherein the step of selecting an RNTI is further based on a QoS flow identifier of the MBS data packet.

[0143] Example 15. The method of any of the preceding examples, wherein the node is a distributed unit (DU) of a distributed base station and the upstream node is a central unit (CU) of the distributed base station.

[0144] Example 16. The method of any of Examples 1 to 14, wherein the node is a distributed unit (DU) of a distributed base station and the upstream node is a user plane function (CU-UP) of a CU.

[0145] Example 17. The method of any of Examples 1 to 14, wherein the node is a distributed unit (DU) of a distributed base station and the upstream node is a control plane function (CU-CP) of a CU.

[0146] Example 18. The method of any of examples 1 to 14, wherein the node is a base station and the upstream node is a user plane function (UPF) of a core network (CN).

[0147] Example 19. The method of any of Examples 1 to 14, wherein the node is a base station and the upstream node is an Access and Mobility Management Function (AMF) of the CN.

[0148] Example 20. A method for managing transmission of data packets implemented in a node of a radio access network (RAN), comprising the steps of receiving, by processing hardware from an upstream node, MBS data packets associated with a quality of service (QoS) flow; selecting, by the processing hardware, a logical channel on the air interface based on the QoS flow; and multicasting, by the processing hardware, the MBS data packets on the logical channel to a plurality of UEs.

[0149] Example 21. The method of Example 20, wherein receiving the MBS data packet includes receiving the MBS data packet over a DL tunnel, and selecting a logical channel based on the QoS flow is in response to determining that the DL tunnel has a first transport layer configuration of a plurality of transport layer configurations.

[0150] Example 22. The method of Example 21, wherein the determining step further includes determining that the DL tunnel is a common DL tunnel over which the upstream node is configured to transmit a single copy of the MBS data packet to multiple UEs.

[0151] Example 23. The method of any of Examples 20 to 22, further comprising selecting an RNTI based on the QoS flow by processing hardware.

[0152] Example 24. The method of Example 23, wherein selecting an RNTI includes selecting a G-RNTI.

[0153] Example 25. A network node comprising processing hardware and configured to implement the method of any of the preceding examples. [Explanation of symbols]

[0154] 102UE 103UE 104 Base station 105 RAN 106 Base Station 110 Core Network 111 EPC 112 SGW 114 MME 116 PGW 124 cells 126 cells 130 Processing Hardware 132 MBS Controller 134 Non-MBS Controller 140 Processing Hardware 142 MBS Controller 144 Non-MBS Controller 150 Processing Hardware 152 MBS Controller 154 Non-MBS Controller 160 5GC 162 (MB-)UPF 164 AMF 166 (MB-)SMF 172 CU 174 DU 202 PHY 204 MAC 206 RLC 208 EUTRA PDCP 210NR PDCP 212 SDAP 214 RRC 232 F1AP 220 Transport Network Layer 240 Transport Network Layer 271 PHY 272 Data Link Layer 274 IP 276 UDP 278 GTP-U 282 SCTP 302 MBS Sessions 304 PDU sessions 312 DL Tunnel 314 MRB 316 QoS Flows 322 UE-specific DL tunnel and / or UL tunnel 324 DRB 402 MRB 404 DRB 412 DL Tunnel 413 UL Tunnel 422 DL logical channels 423 UL logical channels 432 UE-specific DL tunnel 433 UE-specific UL tunnel 442 DRB / DL logical channels 443 DRB / UL logical channels

Claims

1. 1. A method for managing transmission of multicast and / or broadcast services (MBS) performed by a distributed unit (DU) of a distributed base station in a radio access network (RAN), comprising: receiving, by the DU, a data packet from a central unit (CU) of the distributed base station via a downlink (DL) tunnel; determining, by the DU, based on an IP address and / or a Tunnel Endpoint Identifier (TEID) corresponding to the DL tunnel, whether the data packet is received via a common downlink (DL) tunnel connecting the CU and the DU, through which the CU transmits MBS data packets to multiple user equipments (UEs); selecting, by the DU, a multicast scheme for transmitting the data packet to the plurality of UEs when the DU determines that the data packet has been received from the CU via the common DL tunnel; selecting, by the DU, a unicast method for transmitting the data packet to a specific UE when the DU determines that the data packet has not been received from the CU via the common DL tunnel; transmitting the data packet to the plurality of UEs or the specific UE via a radio interface using the selected scheme; A method comprising:

2. 2. The method of claim 1, wherein the step of receiving the data packet via the DL tunnel comprises receiving the data packet via the DU via a common DL tunnel in which the CU is configured to transmit a single copy of the data packet to the plurality of UEs.

3. The method of claim 1 , wherein receiving the data packet over the DL tunnel comprises receiving the data packet over a UE-specific DL tunnel.

4. the selecting step: The method of claim 1 , comprising determining that the DL tunnel is a first DL tunnel of a plurality of DL tunnels configured at the DU.

5. receiving the data packet via the first DL tunnel includes receiving the data packet via the common DL tunnel; The steps of receiving, selecting, and transmitting the data packets via the common DL tunnel occur in a first case; In the second case, receiving a second data packet via a second DL tunnel of the plurality of DL tunnels; selecting the unicast method for transmitting the second data packet to at least one UE based on the second DL tunnel; transmitting the second data packet to the at least one UE via the radio interface using the unicast method; The method of claim 4 further comprising:

6. The method of claim 1 , further comprising selecting a logical channel identifier based on whether the data packet is received at the DU via the common DL tunnel.

7. The transmitting step includes: The method of claim 6, comprising including the data packet and the logical channel identifier in a protocol data unit (PDU).

8. The method of claim 6, wherein the logical channel corresponding to the selected logical channel identifier for the data packet is a Multicast Traffic Channel (MTCH).

9. 7. The method of claim 6, wherein the selecting the logical channel identifier is further based on a Quality of Service (QoS) flow identifier of the data packet.

10. 2. The method of claim 1, further comprising: selecting a Radio Network Temporary Identifier (RNTI) based on whether the data packet is received at the DU via the common DL tunnel.

11. The method of claim 10, wherein the RNTI selected for the data packet is a group RNTI (G-RNTI).

12. The method of claim 10 , wherein the selecting the RNTI is further based on a QoS flow identifier of the data packet.

13. receiving, by the DU from the CU, a request to set up the common DL tunnel; and sending, by the DU to the CU in response to the received request to set up the common DL tunnel, a first DU DL transport layer configuration for configuring the common DL tunnel; or receiving, by the DU from the CU, a request for a context of the UE, and sending, by the DU to the CU in response to the received request for the context of the UE, a second DU DL transport layer configuration for configuring the UE-specific DL tunnel. The method of claim 3 , further comprising at least one of:

14. A network node configured to implement the method of any one of claims 1 to 13.

Images