Managing point-to-point and point-to-multipoint communications in a distributed base station

Abstract

To provide a method for managing transmission of MBS.SOLUTION: The method is implemented in a CU of a distributed base station including the CU and a DU. The method includes receiving, from a core network (CN), a request to configure resources for transmitting downlink (DL) MBS data associated with an MBS session, determining, based on at least one of (I) capabilities of the DU or (ii) capabilities of UEs that have joined the MBS session, whether the DU is to transmit the MBS data to the UEs on at least one of the air interfaces using a PTP delivery mechanism or a PTM delivery mechanism, and causing the DU to transmit the MBS data according to the determined delivery mechanism.SELECTED DRAWING: Figure 5A

Description

[Technical Field]

[0001] The present disclosure relates to wireless communications, and more particularly to managing multicast and / or broadcast communications in a distributed base station environment. [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 a radio protocol stack provides services such as user plane data transport, encryption, and integrity protection. For example, the PDCP sublayer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) air interface (see 3rd Generation Partnership Project (3GPP) specification TS 36.323 ("3GPP" is a registered trademark)) and New Radio (NR) (see 3GPP specification TS 38.323) provides protocol data unit (PDU) ordering 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 the service data adaptation protocol (SDAP) sublayer or protocol layers such as the Internet Protocol (IP) layer, the Ethernet protocol layer, and the Internet Control Message Protocol (ICMP) layer. In general, a UE and a base station may use SRBs to exchange RRC messages and non-access stratum (NAS) messages, and may use DRBs to transport data in the user plane.

[0004] In some scenarios, a UE can simultaneously utilize resources from multiple nodes of a radio access network (RAN) (e.g., base stations or components of a distributed base station, also known as a separated 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 operating as a master node (MN) define a master cell group (MCG), and cells associated with a base station operating as a secondary node (SN) define a secondary cell group (SCG). The MCG covers a primary cell (PCell) and zero, one, or more secondary cells (SCells), and the 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 resources from one base station at a time, in single connectivity (SC). A UE in an SC only communicates with the MN via the MCG. 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 resources of another RAN node (e.g., a base station or a component of a distributed or separated base station) interconnected by a backhaul.

[0005] 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), and "SRB2" resources support RRC messages including recorded measurement information or NAS messages, also on the DCCH but with lower priority than SRB1 resources. More generally, SRB1 and SRB2 resources allow the UE and MN to exchange RRC messages related to the MN to 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.

[0006] Base stations operating in accordance with fifth-generation (5G) New Radio (NR) requirements support much wider bandwidths than fourth-generation (4G) base stations. Accordingly, in Release 15, the Third Generation Partnership Project (3GPP) proposed that user equipment units (UEs) should support a 100 MHz bandwidth in Frequency Range 1 (FR1) and a 400 MHz bandwidth in Frequency Range 2 (FR2). Because the bandwidth of a typical carrier in 5G NR is relatively wide, 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, wireless software distribution, group communications, Internet of Things (IoT) applications, V2X applications, and public safety emergency messages. Summary of the Invention [Problem to be solved by the invention]

[0007] 5G NR provides both point-to-point (PTP) and point-to-multipoint (PTM) delivery methods for transmitting MBS packet flows over the air interface. In PTP communication, a RAN node transmits different copies of each MBS data packet to different UEs over the air interface, while in PTM communication, a RAN node transmits a single copy of each MBS data packet to multiple UEs over the air interface. However, in some scenarios, it is unclear how a base station receives MBS data packets from the core network and how the base station transmits each MBS data packet to a UE. [Means for solving the problem]

[0008] One exemplary embodiment of the techniques of this disclosure is a method for managing transmission of multicast and / or broadcast services (MBS), implemented in a CU of a distributed base station including the CU and the DU. The method includes receiving MBS data packets for a UE from a core network by processing hardware, determining, based on at least one of (i) a capability of the DU or (ii) a capability of the UE, whether the DU should transmit the MBS data packets over an air interface to the UE using a point-to-point (PTP) delivery mechanism or a point-to-multipoint (PTM) delivery mechanism, and causing the DU to transmit the MBS data packets according to the determined delivery mechanism.

[0009] Another exemplary embodiment of these techniques is a network node that includes processing hardware and is configured to perform one of the above methods. [Brief explanation of the drawings]

[0010] [Figure 1A] FIG. 1 is a block diagram of an example wireless communication system in which a core network (CN), base stations (BSs), and user equipments (UEs) can implement techniques of the present disclosure for managing multicast and / or broadcast service (MBS) communications in a distributed base station environment. [Figure 1B] 1B is a block diagram of an exemplary base station (BS) including a central unit (CU) and a distributed unit (DU) capable of operating 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] 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 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] 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. 1 is a messaging diagram of an example scenario in which a DU generates a PTP configuration for an MBS session and transmits DL MBS data to the DU via a UE-specific downlink (DL) tunnel. [Figure 5B] FIG. 10 is a messaging diagram of an example scenario in which a DU generates a PTP configuration for an MBS session and transmits downlink MBS data for multiple UEs to the DU via a common (group-specific) DL tunnel. [Figure 6A] FIG. 10 is a messaging diagram of an example scenario in which a DU generates a PTM configuration for an MBS session and transmits downlink MBS data to the DU via a group-specific DL tunnel. [Figure 6B] FIG. 10 is a messaging diagram of an exemplary scenario in which a DU generates a PTP configuration for a set of UEs and a PTM configuration for another set of UEs for an MBS session, and transmits downlink MBS data to the DU using a UE-specific tunnel and a group-specific tunnel. [Figure 6C]FIG. 6C is a messaging diagram of an exemplary scenario similar to FIG. 6B, but in which the DU also transfers PDCP control PDUs in the uplink direction. [Figure 7A] FIG. 10 is a messaging diagram of an example scenario in which a CU configures both PTP and PTM resources for an MBS session for a UE. [Figure 7B] FIG. 7B is a messaging diagram similar to FIG. 7A, but for an example scenario in which the UE also sends an RCL control PDU to the DU. [Figure 8A] 10 is a flow diagram of an example method in a CU for determining whether to have a DU request PTM configuration or PTP configuration for a UE depending on whether the UE supports multicast communication. [Figure 8B] 10 is a flow diagram of an example method in a CU for determining whether to have a DU request PTM configuration or PTP configuration for a UE depending on whether the DU supports multicast communication. [Figure 8C] 10 is a flow diagram of an example method in a CU for determining whether to have a DU request PTM configuration or PTP configuration for a UE depending on whether the UE supports multicast communication for MBS. [Figure 9A] 10 is a flow diagram of an example method in a DU for determining whether to generate a PTP configuration or a PTM configuration for a UE depending on whether the UE supports multicast communication. [Figure 9B] 10 is a flow diagram of an example method in a DU for determining whether to generate a PTP configuration or a PTM configuration for a UE depending on whether the UE supports multicast communication for MBS. [Figure 10A] 10 is a flow diagram of an example method in a CU for determining whether to configure a group-specific tunnel or one or more UE-specific tunnels depending on whether the UE supports multicast communication. [Figure 10B]10 is a flow diagram of an example method in a CU for determining whether to configure a group-specific tunnel or one or more UE-specific tunnels depending on whether a DU supports multicast communication. [Figure 11A] 10 is a flow diagram of an example method in a DU for determining whether to include a group identifier such as a G-RNTI in a DU configuration depending on whether a CU has requested multicast configuration parameters for an MBS session. [Figure 11B] 10 is a flow diagram of an example method in a DU for determining whether to include a group identifier, such as a G-RNTI, in a DU configuration for a UE depending on whether the UE supports multicast configuration. [Figure 11C] 10 is a flow chart of an example method in a DU for determining whether to include a group identifier such as a G-RNTI in a DU configuration depending on whether the DU supports multicast communication. [Figure 12A] 10 is a flow diagram of an example method in a DU for determining whether to include a G-RNTI or a unicast configuration in the DU configuration depending on whether the CU has requested multicast configuration parameters for an MBS session. [Figure 12B] 10 is a flow diagram of an example method in a DU for determining whether to include a G-RNTI or a unicast configuration in a DU configuration for a UE depending on whether the UE supports multicast configuration. [Figure 12C] 10 is a flow diagram of an example method in a DU for determining whether to include a G-RNTI or a unicast configuration in a DU configuration for a UE depending on whether the DU supports multicast communication. [Figure 13] 10 is a flow diagram of an example method in a DU for determining whether the DU should generate a configuration for an MBS session depending on whether the DU has previously configured an MBS session. [Figure 14A]10 is a flow diagram of an example method in a UE for configuring PTP reception of MBS data. [Figure 14B] 10 is a flow diagram of an example method in a UE for configuring PTP reception of MBS data without explicitly indicating PTP support to the RAN. [Figure 15] 10 is a flow diagram of an example method in a UE for indicating capabilities regarding MBS to the RAN and / or CN. [Figure 16] 10 is a flow diagram of an example method in a UE for determining how the UE should report multicast and unicast capabilities to the RAN and / or CN. DETAILED DESCRIPTION OF THE INVENTION

[0011] As discussed in more detail below, a node of the distributed base station of the present disclosure manages MBS transmissions over the CU-to-DU interface and over the air interface between one or more DUs and multiple UEs participating in the MBS session. More specifically, the CU can configure a common DL tunnel on the CU-to-DU link for transmitting MBS data packets received from the CN to multiple UEs. One or more DUs can configure logical channels (e.g., MTCH, DTCH) over the air interface for the MBS session. The CU can further configure a multicast radio bearer (MRB) including a DL tunnel on the CU-to-DU link, optionally a UL tunnel on the CU-to-DU link, one or more DL logical channels, and optionally one or more uplink logical channels. Furthermore, the CU can in some cases configure multiple QoS flows for the MBS session, and the DU can map them to different logical channels.

[0012] 1A illustrates an example wireless communication system 100 in which techniques of the present disclosure for managing transmission and reception of multicast and / or broadcast service (MBS) information may be implemented. The wireless communication system 100 includes user equipment (UE) 102A, 102B and base stations 104, 106 in a radio access network (RAN) 105 connected to a core network (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.

[0013] 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).

[0014] 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 of (i.e., within) the uplink (UL) bandwidth portion (BWP) of the cell and / or receives data from a base station via radio bearers on the downlink (DL) BWP of the 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 over the DL BWP. In this non-MBS operation, the UE 102A may be in a connected state. Alternatively, if the UE 102A supports small amounts of data transmission in the idle or inactive state, the UE 102A may be in an idle or inactive state.

[0015] 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).

[0016] The base station 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., central processing units (CPUs)), 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.

[0017] The base station 106 includes processing hardware 140, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory that stores machine-readable instructions executable on the general-purpose processor(s), 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 and 134, respectively, of the base station 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.

[0018] 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 UE 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 UE 102B may include processing hardware similar to the processing hardware 150 of the UE 102A.

[0019] The CN 110 may be an Evolved Packet Core (EPC) 111 or a 5th 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.

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

[0021] 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. 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, as denoted by the prefix “(MB-)” shown in FIG. 1A .

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

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

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

[0025] 1B illustrates any one or more exemplary distributed implementations of base stations 104 and 106. In this implementation, base stations 104, 106 include a central unit (CU) 172 and one or more distributed units (DUs) 174. 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, CU 172 may include some or all of processing hardware 130 or 140 of FIG. 1A.

[0026] 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 medium access control (MAC) controller configured to manage or control one or more 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 physical (PHY) layer controller configured to manage or control one or more PHY layer operations or procedures.

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

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

[0029] 2A illustrates, in a simplified manner, an exemplary protocol stack 200 according to which a UE (e.g., UE 102A or 102B) can communicate with an eNB / ng-eNB or gNB (e.g., one or more 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 then 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 then provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides RLC channels to the NR PDCP sublayer 210. In some implementations, the UE 102A or 102B supports both the 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 the NR PDCP 210 over the EUTRA RLC 206A and the SDAP sublayer 212 over the NR PDCP sublayer 210. In this specification, the sublayers are also referred to simply as "layers."

[0030] 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). For brevity, this disclosure refers to both SDUs and PDUs as "packets" unless the distinction between SDUs and PDUs is important. Packets may be MBS packets or non-MBS packets. MBS packets may include, for example, application content for an MBS service (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 an MBS service.

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

[0032] In a scenario where the UE 102A or 102B 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.

[0033] In some implementations, a base station (e.g., base station 104, 106) broadcasts MRB data packets over one or more MBS radio bearers (MRBs), and the UE 102A or 102B receives the MBS data packets over the MRBs. The base station may include a configuration for the MRB 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 over 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.

[0034] 2B illustrates, in a simplified manner, an exemplary protocol stack 250 that a UE 102A or 102B 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 in FIG. 2B. The CU in either base station 104 or 106 can retain all control and higher layer functions (e.g., RRC 214, SDAP 212, NR PDCP 210), while lower layer operations (e.g., NR RLC 206B, NA 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.

[0035] 2C illustrates, in a simplified manner, an exemplary protocol stack 260 that the UE 102A or 102B 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, but 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.

[0036] 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 top of UDP 276, which is overlaid on top of IP 274. The UDP / IP layer is above a data link layer 272 and a PHY 271 layer. The PHY layer 271 may be, for example, a wired link.

[0037] 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 a Stream Control Transmission Protocol (SCTP) layer 282 sits above the IP layer 274 to carry control messages.

[0038] 3, an MBS session 302A may include a tunnel 312A with endpoints at the CN 110 and the base station 104 / 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.

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

[0040] The tunnel 312A may operate at the transport layer or sublayer, for example, in 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 Service (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 through the tunnel 312A. The header may include the IP address and / or the TEID. For example, the header may include an IP header and a GTP header, each including the IP address and the TEID, respectively. Thus, the base stations 104 / 106 can use the IP address and / or TEID to identify data packets traveling through the tunnel 312A.

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

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

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

[0044] 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 and 324B, ... 324B-N. Each of the DRBs 324B may correspond to a respective logical channel, such as a DTCH.

[0045] Referring now to FIG. 4 , when the base stations 104 / 106 are implemented in a distributed manner, one or more DUs 174A / 174B may be associated with the CU 172. The CU 172 and the DUs 174A / 174B may establish tunnels for downlink and / or uplink data associated with an 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 the UE 102A and the UE 102B. The MRB 402A may include a DL tunnel 412A connecting the CU 172 and the DUs 174A / 174B and a DL logical channel 422A corresponding to the DL tunnel 412A. In particular, the DUs 174A / 174B 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, or alternatively, the DL tunnel 412A may be a UE-specific DL tunnel through which the CU 172 transmits MBS data packets to a specific UE.

[0046] Optionally, the MRB 402A includes a UL tunnel 413A connecting the CU 172 and the DU 174A / 174B, 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 174A / 174B can map uplink traffic received via the UL logical channel 423A to the UL tunnel 413A.

[0047] 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 174A / 174B 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 174A / 174B 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.

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

[0049] 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 174A / 174B and a DL logical channel 442A corresponding to the DL tunnel 432A. In particular, the DU 174A / 174B 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 174A / 174B 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 174A / 174B can map uplink traffic received via the UL logical channel 443A to the UL tunnel 433A.

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

[0051] 5A , in scenario 500A, UE 102A first performs an MBS session join procedure with CN 110 via base station 104 to join an MBS session (502). In some scenarios, UE 102A 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.

[0052] To perform the MBS session join procedure (event 502), in some implementations, the UE 102A 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 102A via the base station 104 to grant the UE 102A access to the first MBS session. In some implementations, the UE 102A 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 102A 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.

[0053] In some cases, the UE 102A 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 102A 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 102A 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 102A access to the second MBS session. In some implementations, the UE 102A can send a second MBS session join complete 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 102A may 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 102A may include the first MBS session ID and the second MBS session ID in the MBS session join request message (e.g., the 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.

[0054] 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 102A 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 102A via the base station 104, and the UE 102A 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.

[0055] In some implementations, to perform the (first) MBS session join procedure, the UE 102A 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 102A may communicate a PDU session ID of the PDU session with the CN 110 via the base station 104.

[0056] Similar to event 502, the UE 102B performs (503) a second MBS session join procedure with the CN 110. To this end, the UE 102B, the base station 104, and the CN 110 may exchange messages similar to those discussed above with respect to event 502.

[0057] Before, during, or after the first MBS session join procedure, the CN 110 may send a first CN-to-BS message including the first MBS session ID to the CU 172 to request the CU 172 to configure resources for the first MBS session (504). In some implementations, the CN 110 may additionally include a quality of service (QoS) configuration for the first MBS session in the first CN-to-BS message. In response to the first CN-to-BS message, the CU 172 may send a first BS-to-CN message (e.g., an MBS session resource setup response message) to the CN 110 including a CU DL transport layer configuration to configure a group-specific CN-to-BS DL tunnel for the first MBS session (510). In some implementations, the first CN-to-BS message may be an existing NGAP message or a new NGAP message (e.g., an MBS session resource setup request message). In some implementations, the first BS-to-CN message may be an existing NGAP message or a new NGAP message (e.g., an MBS session resource setup response message). The CU DL transport layer configuration includes a first CU DL transport layer address (eg, an Internet Protocol (IP) address) and a first CU DL TEID to identify a CN-to-BS common DL tunnel.

[0058] In some implementations, the QoS configuration includes QoS parameters for the first MBS session. In some implementations, the QoS configuration includes configuration parameters for configuring one or more QoS flows for the first MBS session. 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 set different values ​​of the QoS parameters for the QoS flows.

[0059] In some implementations, the CN 110 may indicate a list of UEs participating in the first MBS session in a 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 CU 172 may send a second BS-to-CN message to the CN 110 in response to the second CN-to-BS message 512 (526). In such a case, the second CN-to-BS message may be a non-UE-related message, i.e., not specific to the UE 102A. For example, the list of UEs includes 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. The CN 110 assigns the CN UE interface ID, and the base station 104 assigns the RAN UE interface ID. Before the CN 110 sends the list of (CN UE interface ID, RAN UE interface ID) pairs, the base station 104 sends a BS-to-CN message (e.g., an NGAP message, an INITIAL UE MESSAGE message, or a PATH SWITCH REQUEST message) including the RAN UE interface ID for each of the UEs to the CN 110, 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 for each of the UEs to the base station 104. 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 one of the UEs. In some implementations, the CN 110 may assign the UE IDs and transmit each of the UE IDs to a specific one 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 transmits the list of UE IDs, the CU 172 may receive the UE IDs from the UE 102 or the CN 110 for each of the UEs. For example, the CU 172 may receive an RRC message (e.g., an RRCSetupComplete message) including the UE ID from the UE 102 during an RRC connection establishment procedure. In another example, the CU 172 may receive 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 including the UE ID.

[0060] In other implementations, the CN 110 may send a second CN-to-BS message to the CU 172 indicating that the UE 102A (only) will participate in the first MBS session (512). The second CN-to-BS message may be a UE-related message for the UE 102A. That is, the second CN-to-BS message is specific to the UE 102A. After receiving or in response to receiving the second CN-to-BS message, the CU 172 may send a UE context request message for the UE 102A to the DU 174 (514). In some implementations, the CU 172 may include the first MBS session ID and / or the MRB ID of the MRB associated with the first MBS session (ID) in the UE context request message. In some implementations, the CU 172 may include a 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. In response to the UE context request message, the DU 174 sends a UE context response message to the CU 172 including PTP configuration parameters for the UE 102A to receive MBS data of the first MBS session (516). (Part of) the PTP configuration parameters may be associated with the MRB / MRB ID. In some implementations, the DU 174 generates a DU configuration to include the PTP 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 PTP configuration parameters include at least one first logical channel.

[0061] In some implementations, the DU 174 includes a DU DL transport layer configuration in the UE context response message to configure a first UE-specific DL tunnel for the UE 102A. Each of the DU DL transport layer configurations includes a DU transport layer address (e.g., Internet Protocol (IP)) address and a DU DL tunnel ID (TEID) to identify a CU-to-DU common DL tunnel. The DU 174 can configure different DU transport layer addresses and / or different DU DL TEIDs for the UE-specific DL tunnels. In some implementations, the CU 172 can include a CU UL transport layer configuration in the UE context request message to configure a UE-specific UL tunnel. The CU 172 can include a CU transport layer address (e.g., an IP address) and a CU UL TEID in the CU UL transport layer configuration to identify a UE-specific UL tunnel.

[0062] In some implementations, the CU 172 can instruct the DU 174 to generate PTP configuration parameters for the UE 102A in a UE context request message. For example, the CU 172 can include a PTP instruction in the UE context request message. In another example, the CU 172 may exclude a PTM instruction in the UE context request message to instruct the DU 174 to generate PTP configuration parameters. In some implementations, the CU 172 instructs the DU 174 to generate PTP configuration parameters if the CU 172 determines that the UE 102A does not support PTM communication, i.e., that the UE 102A does not support receiving PTM transmissions. In some implementations, the CU 172 instructs the DU 174 to generate PTP configuration parameters if the CU 172 determines that the UE 102A supports PTP communication, i.e., that the UE 102A supports receiving PTP transmissions. Before or during the first MBS session join procedure, the CU 172 may receive the UE capabilities of the UE 102A from the UE 102A, another base station (e.g., the base station 106), another CU (e.g., a CU of the base station 106), or the CN 110 (e.g., the AMF 164). For example, the CU 172 may receive a UE Capability IE including the UE capabilities from the UE 102A, another base station (e.g., the base station 106), another CU (e.g., a CU of the base station 106), or the CN 110 (e.g., the AMF 164). For example, the UE Capability IE may be a UE-NR-Capability IE or a UE-6G-Capability IE. The UE capabilities indicate whether the UE 102A supports PTM communication or PTP communication. Thus, the CU 172 can determine whether the UE 102A supports PTM communication or PTP communication based on the UE capabilities.

[0063] In some implementations, the CU 172 instructs the DU 174 to generate PTP configuration parameters if it determines that the DU 174 does not support PTM communication, i.e., the DU 174 does not support receiving PTM transmissions. In some implementations, the CU 172 instructs the DU 174 to generate PTP configuration parameters if it determines that the DU 174 supports PTP communication, i.e., the DU 174 supports receiving PTP transmissions. If the CU 172 determines that the DU 174 supports PTM communication, it instructs the DU 174 to generate PTP configuration parameters. Before or during the first MBS session join procedure, in some implementations, the CU 172 can receive the DU capability of the DU 174 from the DU 174, the CN 110 (e.g., the AMF 164), or an operation, administration, and maintenance (OAM) node. For example, the CU 172 can receive a DU Capability IE including the DU capability from the DU 174, the CN 110 (e.g., the AMF 164), or an OAM node. For example, the DU Capability IE may be a DU-NR-Capability IE or a DU-6G-Capability IE. The UE capability indicates whether the UE 102A supports PTM communication or PTP communication. Thus, the CU 172 can determine whether the DU 174 supports PTM communication or PTP communication based on the DU capability. In other implementations, the CU 172 may determine whether the DU 174 supports PTP communication or PTM communication based on pre-configuration. For example, the CU 172 may be pre-configured to determine that the DU 174 supports PTP communication. In another example, the CU 172 may be pre-configured to determine that the DU 174 does not support PTP communication. In yet another example, the CU 172 may be pre-configured to determine that the DU 174 supports PTM communication. In an additional example, the CU 172 may be pre-configured to determine that the DU 174 does not support PTM communication.

[0064] In some implementations, the UE context request message and the UE context response message may be a UE Context Setup Request message and a UE Context Setup Response message, respectively. In other implementations, the UE context request message and the UE context response message may be a UE Context Modification Request message and a UE Context Modification Response message, respectively.

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

[0066] 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 102A 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 102A 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.

[0067] Before or after receiving the UE context response message (516), the CU 172 may send a second BS-to-CN message to the CN 110 in response to the second CN-to-BS message 408 (526). The CN 110 may include a PDU Session Modification Command message or a second DL container message for the UE 102A in the second CN-to-BS message. The CU 172 may 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 may include the first UE ID in the second BS-to-BS message.

[0068] Events 512, 514, 516, 518, 520, 522, 524, and 526 are collectively referred to in FIG. 5 as PTP configuration procedure 598.

[0069] Similarly, the CN 110, the CU 172, the DU 174, and the UE 102B may perform a PTP configuration procedure (599), similar to event 598. In some implementations, the DU 174 includes a DU DL transport layer configuration in the UE context response message of the PTP configuration procedure 599 to configure a second UE-specific DL tunnel and at least one second logical channel for the UE 102B. In some implementations, (some of) the PTP configuration parameters for the UE 102A and the UE 102B to receive MBS data of the first MBS session are the same, i.e., identical. In other implementations, (some of) the PTP configuration parameters for the UE 102A and the UE 102B to receive MBS data of the first MBS session are different.

[0070] In some implementations, the CU 172 can include the CU DL transport layer configuration in the second BS-to-CN message for the UE 102A and the second BS-to-CN message for the UE 102B. In other words, the CU 172 can send the same CU DL transport layer configuration in the BS-to-CN message in response to the CN-to-BS message indicating that the UEs will participate in the same MBS session. In such implementations, the CN 110 can omit the MBS resource setup procedures 504, 510.

[0071] After performing PTP configuration procedures with UE 102A and UE 102B (588, 589), CN 110 can transmit MBS data (e.g., one or more MBS data packets) to CU 172 via the group-specific CN-to-BS DL tunnel (528). CU 172 can transmit the MBS data to DU 174 via a first UE-specific tunnel (530), and DU 174 transmits (i.e., unicasts) the MBS data to UE 102A via a first logical channel (532). Similarly, CU 172 can transmit the MBS data to DU 174 via a second UE-specific tunnel (534), and DU 174 transmits (i.e., unicasts) the MBS data to UE 102B via a second logical channel (536). In some implementations, the DU 174 can configure the same LCID for the first logical channel and the second logical channel because the DU 174 transmits the MBS data (532) and transmits the MBS data (536) on different radio resources. In other implementations, the DU 174 can configure different LCIDs for the first logical channel and the second logical channel. For example, the DU 174 can configure a first LCID (value) for the first logical channel. The DU 174 can configure a first LCID (value) for the DRB of the UE 102B, and the DU 174 can configure a second LCID (value) for the second logical channel. The second LCID (value) is different from the first LCID (value).

[0072] In some implementations, UE 102B may send one or more PDCP control PDUs to CU 172 via DU 174 to request CU 172 to retransmit one or more MBS data packets that CU 172 transmitted at event 536 (538, 540). In such a case, CU 172 retransmits the one or more MBS data packets to DU 174 via a second UE-specific DL tunnel (542), and DU 174 (re)transmits the one or more MBS data packets to UE 102B via a second UE-specific logical channel (544). In some implementations, the PDCP control PDU may include a COUNT value of the first missing MBS data packet and a bitmap indicating one or more missing MBS data packets after the first missing MBS data packet.

[0073] In some implementations, the PTP configuration parameters may include one or more MRB configurations that configure one or more MRBs associated with the first MBS session. In some implementations, the PTP configuration parameters may also include one or more RLC bearer configurations, each associated with a specific 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 that configures 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) that configures a logical channel. In some implementations, the RLC bearer configuration may include an MRB ID.

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

[0075] 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 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 (528), 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 the first UE-specific DU DL tunnel (530). The DU 174 then transmits (e.g., unicasts) the PDCP PDU to the UE 102A via the first logical channel (532). When the UE 102A receives the PDCP PDU via the first logical channel, the UE 102A extracts the compressed MBS data packet from the PDCP PDU. The UE 102A decompresses the compressed MBS data packet using a compression (decompression) protocol to obtain the original MBS data packet. In such a case, the UE 102A 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, for example, via the first logical channel. The DU 174 then transmits the PDCP control PDU to the CU 172 via the (first) UE-specific UL tunnel for the UE 102A.

[0076] In some implementations, the CU 172 transmits the PDCP PDU to the DU 174 via a second UE-specific DL tunnel (534). The DU 174 then transmits (i.e., unicasts) the PDCP PDU to the UE 102B via a second logical channel (536). When the UE 102B receives the PDCP PDU via the second logical channel, the UE 102B extracts the compressed MBS data packet from the PDCP PDU. The UE 102B decompresses the compressed MBS data packet using a compression (decompression) protocol to obtain the original MBS data packet. In such a case, the UE 102B may transmit a PDCP control PDU including header compression protocol feedback (e.g., interspersed ROHC feedback) for the operation of the header (decompression) compression protocol to the DU 174, for example, via the second logical channel. The DU 174 then transmits the PDCP control PDU to the CU 172 via the (second) UE-specific UL tunnel for the UE 102B. In another implementation, when the CU 172 receives an MBS data packet from the CN 110 (528), the CU 172 compresses the MBS data packet using a compression protocol to obtain a second compressed MBS data packet and transmits a second PDCP PDU including the second compressed MBS data packet to the DU 174 via a second UE-specific DL tunnel (534). The DU 174 then transmits (i.e., unicasts) the second PDCP PDU to the UE 102B via a second logical channel (536). When the UE 102B receives the second PDCP PDU via the second logical channel, the UE 102B extracts the second compressed MBS data packet from the second PDCP PDU. The UE 102B decompresses the second compressed MBS data packet using the (decompression) compression protocol to obtain the original MBS data packet. In such a case, the UE 102B may transmit, for example, via a second logical channel, a PDCP control PDU to the DU 174 that includes header compression protocol feedback (e.g., interspersed ROHC feedback) for the operation of the header (decompression) compression protocol.The DU 174 then transmits the PDCP control PDU to the CU 172 via the (second) UE-specific UL tunnel for the UE 102B.

[0077] In some implementations, the MRB configuration may be an MRB-ToAddMod IE. The MRB ID identifies a specific MRB of the MRB. 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 the MRB ID 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 the RB is an MRB or a DRB according to the RB ID of the RB. In other implementations, the CU 172 may set the MRB ID 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 the RB is an MRB or a DRB according to the RB ID of the RB and the RRC IE configuring the RB. For example, the DRB configuration configuring the DRB is a DRB-ToAddMod IE that includes DRB identification information and PDCP configuration. Thus, the UE 102 may determine that an RB is a DRB if it receives a DRB-ToAddMod IE that configures the RB, and may determine that an RB is an MRB if it receives an MRB-ToAddMod IE that configures the RB. Similarly, the CU 172 may determine that an RB is a DRB if it sends a DRB-ToAddMod IE that configures the RB to the UE 102, and may determine that an RB is an MRB if it sends an MRB-ToAddMod IE that configures the RB to the UE 102.

[0078] 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 dedicated traffic channel. In some implementations, the logical channel may be a dedicated traffic channel (DTCH). In other implementations, the logical channel may be a multicast traffic channel (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 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.

[0079] In some implementations, the CU 172 can include a PDU Session Modification Command message or a second DL container message in an RRC reconfiguration message. The UE 102 can include a PDU Session Modification Complete message or an additional UL container message in an RRC reconfiguration complete message. Alternatively, the UE 102 can send a UL RRC message including a PDU Session Modification Complete message or an additional UL container message to the CU 172 via the DU 174. The UL RRC message can be a UL Information Transfer message or any appropriate RRC message that can include a UL NAS PDU. The CU 172 can include a PDU Session Modification Complete message or an additional UL container 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 a PDU Session Modification Complete message or an additional UL container message to the CN 110.

[0080] In other implementations, the CU 172 sends a DL RRC message including a PDU Session Modification Command 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 a PDU Session Modification 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.

[0081] In some implementations, the MBS data includes IP packets, TCP / IP packets, UDP / IP packets, Real-time Transport Protocol (RTP) / UDP / IP packets, or RTP / TCP / IP packets.

[0082] 5B, scenario 500B is generally similar to scenario 500A, except that after CN 110 sends a (first) CN-to-BS message to CU 172 (504), CU 172 sends a CU-to-DU message to 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), DU 174 sends a DU-to-CU message including a first DU DL transport layer configuration to 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). 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 an MRB ID associated with the first DL transport layer configuration and / or 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., for an MBS context setup response message). The CN 110 can additionally include a quality of service (QoS) configuration 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).

[0083] 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 may 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.

[0084] In some implementations, the QoS configuration includes QoS parameters for the MBS session. In some implementations, the QoS configuration includes configuration parameters to configure one or more QoS flows for the MBS session (see FIG. 3). 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.

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

[0086] Furthermore, unlike scenario 500A, here, CU 172 transmits MBS data to DU 174 via one or more group-specific tunnels (531), which then unicasts the MBS data to UEs 102A and 102B (532, 534) as in scenario 500A. As a more specific example, the CU can transmit a single copy of an MBS data packet to DU 174 (531), and DU 174 can transmit this MBS data packet to two or more UEs (532, 534). Furthermore, in some scenarios, DU 174 receives an MBS data packet via a group-specific tunnel and transmits the MBS data packet to only one UE operating in the DU 174's cell.

[0087] 6A shows an example scenario 600A in which the UE 102A first performs an MBS session join procedure with the CN 110 via the base station 104 (602), and the UE 102B similarly performs an MBS session join procedure (603). The CN 110, the CU 172, and the DU 74 then perform an MBS session resource setup procedure 690. Procedures 602, 603, and 690 are similar to procedures 502, 503, and 590, respectively.

[0088] After the CN 110 sends a second CN-to-BS message to the CU 172 (612) (see the discussion of similar event 512 above), the CU 172 configures at least one MRB for the MBS session and sends a UE context request message including a corresponding MRB ID to the DU 174 (614). The DU 174 then generates a PTM configuration for the MBS session and sends the PTM configuration to the CU 172 (616). The CU 172 generates an RRC reconfiguration message including the PTM configuration parameters and one or more MRB configurations and sends the RRC reconfiguration message to the DU 174 (618). The DU 174 then sends an RRC reconfiguration message to the UE 102A (620). In response, the UE 102A sends an RRC reconfiguration complete message to the DU 174 (622), and the DU 174 sends the RRC reconfiguration complete message to the CU 172 (624). The CU 172 then responds to the CN to BS message of event 612 (626).

[0089] Events 612, 614, 616, 618, 620, 622, 624, and 626 are collectively referred to in FIG. 6 as PTM configuration procedure 696.

[0090] After UE 102B performs a similar PTM configuration procedure (695), CN 110 can transmit MBS data (e.g., one or more MBS data packets) to CU 172 via a group-specific CN-to-BS DL tunnel (628), which transmits the MBS data to DU 174 via one or more group-specific tunnels (631), and DU 174 then uses a group-specific logical channel to multicast the MBS data packets (633).

[0091] Figure 6B is a messaging diagram of an example scenario 600 in which a DU generates a PTP configuration for a set of UEs and a PTM configuration for another set of UEs and transmits downlink MBS data to the DU using UE-specific and group-specific tunnels. Figure 6C is a messaging diagram 600C of an example scenario similar to Figure 6B, but in which the DU also forwards PDCP control PDUs in the uplink direction. Figure 7A is a messaging diagram of an example scenario 700A in which a CU configures both PTP and PTM resources for MBS sessions for some UEs. Figure 7B is a messaging diagram of an example scenario 700B in which a UE also transmits RLC control PDUs to the DU.

[0092] FIG. 8A is a flow diagram of an example method 800A in a CU for determining whether to have a DU request PTM configuration or PTP configuration for a UE depending on whether the UE supports multicast communication.

[0093] In some implementations, the CU may receive a CN-to-BS message from the CN indicating that the UE will participate in the MBS session (e.g., events 504, 512). In response to the CN-to-BS message, the CU determines to obtain configuration parameters for the UE to receive the MBS session.

[0094] In some implementations, the PTM configuration parameters include a G-RNTI, at least one first logical channel ID, at least one RLC configuration parameter, at least one first RLC bearer configuration, at least one first RLC configuration, and / or an RLC mode (e.g., unacknowledged mode). In some implementations, the PTP configuration parameters include at least one second logical channel ID, at least one second RLC configuration parameter, at least one second RLC bearer configuration, at least one second RLC configuration, and / or an RLC mode (e.g., acknowledged mode).

[0095] In some implementations, the PTM configuration parameters include physical layer configuration parameters and / or MAC layer configuration parameters, hi some implementations, the physical layer configuration parameters include BWP configuration parameters, common frequency range configuration parameters, PDCCH configuration parameters, HARQ configuration parameters, and / or PDSCH configuration parameters.

[0096] After sending the PTP configuration parameters to the UE, the CU receives MBS data of the MBS session and sends the MBS data to the DU through the UE-specific tunnel, and the DU sends the MBS data to the UE using the PTP configuration parameters.

[0097] 8B is a flow diagram of an example method 800B in a CU for determining whether to have a DU request PTM configuration or PTP configuration for a UE depending on whether the DU supports multicast communication. FIG. 8C is a flow diagram of an example method 800C in a CU for determining whether to have a DU request PTM configuration or PTP configuration for a UE depending on whether the UE supports multicast communication for MBS.

[0098] 9A and 9B are flow diagrams of an example method 900A and 900B in a DU for determining whether to generate a PTP configuration or a PTM configuration for a UE depending on whether the UE supports multicast communication.

[0099] 10A is a flow diagram of an example method 1000A in a CU for determining whether to configure a group-specific tunnel or one or more UE-specific tunnels depending on whether the UE supports multicast communication. FIG. 10B is a flow diagram of an example method 1000B in a CU for determining whether to configure a group-specific tunnel or one or more UE-specific tunnels depending on whether the DU supports multicast communication.

[0100] FIG. 11A is a flow diagram of an example method 1100A in a DU for determining whether to include a group identifier such as a G-RNTI in the DU configuration depending on whether the CU has requested multicast configuration parameters for an MBS session.

[0101] In some implementations, the configuration parameters may be common for receiving MBS data of an MBS session via multicast and unicast. For example, the configuration parameters may include at least one RLC configuration parameter, at least one RLC bearer configuration (e.g., an RLC-BearerConfig IE), at least one logical channel ID, at least one RLC configuration, and / or an RLC mode (e.g., unacknowledged mode).

[0102] In some implementations, the DU configuration may be a CellGroupConfig IE. In other implementations, the DU configuration may be a new IE. In some implementations, the DU may include the G-RNTI in the physical layer configuration (e.g., PhysicalCellGroupConfig IE) in the DU configuration. In other implementations, the DU may include the G-RNTI in the MAC configuration (e.g., MAC-CellGroupConfig IE). In still other implementations, the DU may include the G-RNTI in the RLC bearer configuration.

[0103] In some implementations, the DU may include the C-RNTI in the DU configuration regardless of whether the CU-to-DU message requests multicast configuration parameters. For example, the DU may include the C-RNTI in the physical layer configuration.

[0104] 11B is a flow diagram of an example method 1100B in a DU for determining whether to include a group identifier such as a G-RNTI in a DU configuration for a UE depending on whether the UE supports multicast configuration. FIG. 11C is a flow diagram of an example method 1100C in a DU for determining whether to include a group identifier such as a G-RNTI in a DU configuration for a UE depending on whether the DU supports multicast communication.

[0105] 12A is a flow chart of an example method 1200A in a DU for determining whether to include a G-RNTI or a unicast configuration in the DU configuration depending on whether the CU has requested multicast configuration parameters for the MBS session. In some implementations, the at least one first configuration parameter includes a first logical channel ID, and the at least one second parameter includes a second logical channel ID. In other implementations, the at least one first configuration parameter includes at least one RLC configuration parameter, at least one first RLC bearer configuration, at least one first RLC configuration, and / or an RLC mode (e.g., unacknowledged mode). Similarly, the at least one second configuration parameter includes at least one second RLC configuration parameter, at least one second RLC bearer configuration, at least one second RLC configuration, and / or an RLC mode (e.g., acknowledged mode).

[0106] 12B is a flow diagram of an example method 1200B in a DU for determining whether to include a G-RNTI or a unicast configuration in a DU configuration for a UE depending on whether the UE supports multicast configuration. FIG. 12C is a flow diagram of an example method 1200C in a DU for determining whether to include a G-RNTI or a unicast configuration in a DU configuration for a UE depending on whether the DU supports multicast communication.

[0107] 13 is a flow diagram of an example method 1300 in a DU for determining whether the DU should generate a configuration for an MBS session depending on whether the DU previously configured an MBS session. In some implementations, the configuration parameters may be PTM configuration parameters as described with respect to FIG. 8A. In other implementations, the configuration parameters may be PTP configuration parameters as described with respect to FIG. 8A.

[0108] 14A is a flow diagram of an example method 1400A in a UE for configuring PTP reception of MBS data. FIG. 14B is a flow diagram of an example method 1400B in a UE for configuring PTP reception of MBS data without explicitly indicating PTP support to the RAN. In some implementations, the UL message may be a UECapabilityInformation message. In other implementations, the UL message may be a NAS message. For example, the NAS message may be a 5GMM message or a 5GSM message as defined in 3GPP specification 24.501. In another example, the NAS message may be a registration request message or a registration complete message. In some implementations, the information may be a UE radio capability ID IE. In some implementations, the information may be a UE-NR-Capability IE. In other implementations, the information may be a UE-6G-Capability IE.

[0109] 15 is a flow diagram of an example method 1500A in a UE for indicating capabilities for MBS to the RAN and / or CN. FIG. 16 is a flow diagram of an example method 1600 in a UE for determining how the UE should report multicast and unicast capabilities to the RAN and / or CN.

[0110] The following list of examples reflects various embodiments specifically contemplated by this disclosure.

[0111] Example 1. A method for managing transmission of multicast and / or broadcast services (MBS), implemented in a central unit (CU) and distributed units (DUs) of a distributed base station, comprising: receiving, by processing hardware, a request from a core network (CN) to configure resources for transmitting downlink (DL) MBS data associated with an MBS session; determining, based on at least one of (i) the capabilities of the DU or (ii) the capabilities of UEs that have joined the MBS session, whether the DU should transmit the MBS data to UEs over at least one of the radio interfaces using a point-to-point (PTP) delivery mechanism or a point-to-multipoint (PTM) delivery mechanism; and causing the DU to transmit the MBS data according to the determined delivery mechanism.

[0112] Example 2. The method of Example 1, further comprising transmitting the MBS data to the DU via a UE-specific DL tunnel, the DL tunnel operating at the transport layer of the CU-to-DU link.

[0113] Example 3. The method of Example 1, further comprising transmitting the MBS data to the DU via a DL tunnel common to a group including the UE and at least one other UE, the DL tunnel operating at a transport layer of a CU-to-DU link.

[0114] Example 4. The method of Example 1, wherein the step of causing the DU to transmit the MBS data to the UE includes the steps of causing the DU to transmit MBS data packets included in the MBS data to the UE using a PTM delivery mechanism, and if the DU detects a failure in delivery of the MBS data to the UE using the PTM delivery mechanism, causing the DU to retransmit the MBS data packets to the UE using a PTP delivery mechanism.

[0115] Example 5. The method of any of the preceding examples, wherein the determining step is based at least in part on whether the DU supports multicast communications.

[0116] Example 6. The method of any of the preceding examples, wherein the determining step is based at least in part on whether the UE supports multicast communication for the MBS.

[0117] Example 7. The method of any of the preceding examples, wherein the determining step is based at least in part on whether the DU supports multicast communications.

[0118] Example 8. A CU of a distributed base station comprising processing hardware and configured to implement any of the above examples.

[0119] The following additional considerations apply to the above discussion:

[0120] In some implementations, "message" may be used and replaced by "information element (IE)". In some implementations, "IE" may be used and replaced by "field". In some implementations, "configuration" may be replaced by "configurations" or configuration parameters. In some implementations, "MBS" may be replaced by "multicast" or "broadcast".

[0121] A user device (e.g., UE 102A or 102B) on which the techniques of this disclosure may be implemented may be any suitable device capable of wireless communication, such as a smartphone, a tablet computer, a laptop computer, a mobile game console, a point-of-sale (POS) terminal, a health management device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Furthermore, a user device may in some cases be integrated into an electronic system such as a vehicle head unit or an advanced driver assistance system (ADAS). Still further, a user device may operate as an internet-of-things (IoT) device or a mobile internet device (MID). Depending on the type, a user device may include one or more general-purpose processors, computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0122] Some embodiments are described in this disclosure as including logic or several components or modules. The modules may be software modules (e.g., code stored on a non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing several operations and may be configured or arranged in a certain manner. A hardware module may comprise dedicated circuitry or logic that is permanently configured to perform several operations (e.g., as a field programmable gate array (FPGA) or a dedicated processor such as an application-specific integrated circuit (ASIC)). A hardware module may also comprise programmable logic or circuitry (e.g., as contained in a general-purpose processor or other programmable processor) that is temporarily configured by software to perform several operations. The decision to implement a hardware module in dedicated, permanently configured circuitry or in temporarily configured circuitry (e.g., configured by software) may depend on cost and time considerations.

[0123] When implemented in software, the techniques may be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software may be executed by one or more general-purpose processors or one or more special-purpose processors.

[0124] Upon reading this disclosure, those skilled in the art will recognize still further alternative structural and functional designs for communicating MBS information through the principles disclosed herein. Accordingly, while particular embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the precise structure and components disclosed herein. [Explanation of symbols]

[0125] 101UE 102UE 103UE 104 Base station 105 RAN 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 220 Transport Network Layer 222 PHY 224 Data Link Layer 226 IP 228 UDP 230 GTP-U 232 F1AP 240 Transport Network Layer 242 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), implemented in a central unit (CU) of a distributed base station including a CU and distributed units (DUs), comprising: receiving, by the CU, from a core network (CN), a request to configure resources for transmitting downlink (DL) MBS data associated with an MBS session; determining whether the DU should transmit the MBS data to the UE over at least one of the radio interfaces using a point-to-point (PTP) delivery mechanism or a point-to-multipoint (PTM) delivery mechanism based on at least one of (i) the capability of the DU or (ii) the capability of the UEs that have joined the MBS session; causing the DU to transmit the MBS data according to the determined delivery mechanism.

2. The method of claim 1 , further comprising: transmitting the MBS data to the DU through a DL tunnel specific to the UE, the DL tunnel operating at a transport layer of a CU-to-DU link.

3. 2. The method of claim 1, further comprising transmitting the MBS data to the DU via a DL tunnel common to a group including the UE and at least one other UE, the DL tunnel operating at a transport layer of a CU-to-DU link.

4. causing the DU to transmit the MBS data to the UE, causing the DU to transmit MBS data packets included in the MBS data to the UE using the PTM delivery mechanism; and when the DU detects a failure in delivery of the MBS data to the UE using the PTM delivery mechanism, causing the DU to retransmit the MBS data packet to the UE using the PTP delivery mechanism.

5. The method of claim 1 , wherein the determining step is based at least in part on whether the DU supports multicast communication.

6. The method of claim 1 , wherein the determining step is based at least in part on whether the UE supports multicast communication for MBS.

7. 1. A method for managing transmission of multicast and / or broadcast services (MBS), implemented in a distributed unit (DU) of a distributed base station including a distributed unit (DU) and a central unit (CU), comprising: receiving, by the DU, from a CU, a CU-to-DU message requesting configuration parameters for a user equipment (UE) to be utilized to receive downlink (DL) MBS data associated with an MBS session; determining, by the DU, whether to include a Group Radio Network Temporary Identifier (G-RNTI) in a DU configuration for the UE to use to receive the DL MBS data from the DU based on whether the UE supports multicast configuration; generating, by the DU, the DU configuration according to the determination; and transmitting the DU configuration by the DU to the CU.

8. The generating step includes: The method of claim 7, comprising including the G-RNTI in the DU configuration in response to the UE determining that it supports a multicast configuration.

9. The generating step includes:

8. The method of claim 7, comprising refraining from including the G-RNTI in the DU configuration in response to the UE determining that it does not support a multicast configuration.

10. receiving, by the DU, a message from the CU, including the DU configuration; and transmitting the message by the DU to the UE.

11. A network node of a distributed base station comprising processing hardware and configured to implement the method according to any one of claims 1 to 10.

Images