Managing configurations for multicast and unicast communications

Abstract

In a method for configuring a radio bearer, a distributed unit (DU) of a distributed base station receives a request to configure radio resources for the radio bearer from a central unit (CU) of the distributed base station, and includes or refrains from including one or more configuration parameters for the radio bearer in a response based on one or more factors associated with the radio bearer. The DU also sends the response to the CU.

Description

[Technical Field]

[0001] The present disclosure relates to wireless communications, and more particularly to enabling the setup and / or modification of radio resources for unicast, multicast, and / or broadcast communications. [Background technology]

[0002] The discussion of the background art provided herein is intended to provide a general context for the present disclosure. The work of the presently named inventors, to the extent that it is described in this background art section, is not admitted expressly or impliedly as prior art to the present disclosure, as are aspects of the present disclosure that may not, in some cases, be considered prior art at the time of filing.

[0003] In telecommunications systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as transport, encryption, and integrity protection of user plane data. For example, the PDCP sublayer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) air interface (see 3rd Generation Partnership Project (3GPP®) specification TS 36.323) and New Radio (NR) (see 3GPP® specification TS 38.323) provides sequencing of protocol data units (PDUs) in the uplink direction from a user device (also known as user equipment or "UE") to a base station and in the downlink direction from a base station to a UE. The PDCP sublayer also provides services for signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer. The PDCP sublayer further provides services for data radio bearers (DRBs) to the Service Data Adaptation Protocol (SDAP) sublayer or protocol layers such as the Internet Protocol (IP) layer, the Ethernet protocol layer, or 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 on the user plane.

[0004] In some scenarios, a UE can simultaneously utilize resources of multiple nodes (e.g., base stations or components of a distributed or disaggregated base station) of a radio access network (RAN) interconnected by a backhaul. When these network nodes support different radio access technologies (RATs), this type of connectivity 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 the SN (via the SCG). In other scenarios, the UE utilizes resources of one base station at a time, in single connectivity (SC). A UE in an SC communicates only 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 separate base station) interconnected by a backhaul.

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

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

[0007] Base stations operating in accordance with fifth-generation (5G) New Radio (NR) requirements support significantly larger bandwidths than fourth-generation (4G) base stations. Accordingly, the 3rd Generation Partnership Project (3GPP) is proposing for Release 15 that UEs support a 100 MHz bandwidth in Frequency Range 1 (FR1) and a 400 MHz bandwidth in Frequency Range 2 (FR2). Due to the relatively wide bandwidth of a typical carrier in 5G NR, 3GPP is proposing for Release 17 that 5G NR base stations 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, software distribution over wireless, group communications, Internet of Things (IoT) applications, V2X applications, and emergency messages related to public safety.

[0008] 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, the RAN node transmits different copies of each MBS data packet to different UEs over the air interface, while in PTM communication, the 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 what configuration the base station should generate for the UE to receive MBS data packets multicast and / or unicast by the base station. [Prior art documents] [Non-patent literature]

[0009] [Non-Patent Document 1] 3rd Generation Partnership Project (3GPP) Specification TS 36.323 [Non-patent document 2] 3GPP specification TS 38.323 Summary of the Invention [Means for solving the problem]

[0010] In one aspect of the present disclosure, a method for configuring a radio bearer is implemented by a DU of a distributed base station. The method includes receiving a request to configure radio resources for the radio bearer from a central unit (CU) of the distributed base station. The method also includes including or refraining from including one or more configuration parameters for the radio bearer in a response based on one or more factors associated with the radio bearer. The method further includes transmitting the response to the CU.

[0011] In another aspect of the present disclosure, a method for configuring a radio bearer is implemented by a RAN node. The method includes determining to configure radio resources for the radio bearer and, based on whether the radio bearer is an MRB or not, respectively, including or refraining from including first RLC parameters in the configuration for the radio bearer. The method also includes transmitting the configuration to another node.

[0012] In another aspect of the present disclosure, a method for configuring an MRB associated with an MBS session is implemented by a CU of a distributed base station that also includes a DU. The method includes determining whether the MRB or the MBS session requires uplink resources, and, based on the determining step, including or omitting to include an indication that the MRB or the MBS session requires uplink resources in a CU-DU message. The method also includes transmitting the CU-DU message to the DU.

[0013] In another aspect of the present disclosure, a method for configuring a radio bearer is performed by a CU of a distributed base station that also includes a DU, the method including the steps of determining an RLC mode for the radio bearer, including an indication of the RLC mode in a CU-DU message, and sending the CU-DU message to the DU. [Brief explanation of the drawings]

[0014] [Figure 1A] 1 is a block diagram of an example system in which techniques of the present disclosure for managing the transmission and reception of MBS information may be implemented. [Figure 1B] 1B is a block diagram of an exemplary base station in which the central unit (CU) and distributed units (DU) can operate in the system of FIG. 1A. [Figure 2A] 1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A may communicate with the base station of FIG. 1A. [Figure 2B]FIG. 1A is a block diagram of an exemplary protocol stack that allows a UE to communicate with a base station's DU and CU. [Figure 3] FIG. 3 is a block diagram showing an exemplary tunnel architecture for MBS sessions and PDU sessions. [Figure 4] FIG. 6 is a block diagram showing exemplary MRBs and DRBs that can be configured by a distributed base station to communicate multicast traffic, broadcast traffic, and / or unicast traffic with a UE. [Figure 5A] FIG. 9 is a messaging diagram of an exemplary scenario where the CN and the distributed base station configure resources for transmitting MBS data of an MBS session to a plurality of UEs. [Figure 5B] FIG. 12 is a messaging diagram of an exemplary scenario where the CN and the distributed base station configure resources for transmitting MBS data of an MBS session to a plurality of UEs. [Figure 6A] FIG. 15 is a flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 6B] FIG. 18 is a flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 7] FIG. 21 is a flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 8] FIG. 24 is a flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 9A] FIG. 27 is a flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 9B] A flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 10] A flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 11A] A flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 11B] A flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 11C] A flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 12A] A flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 12B] A flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 13] A flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B. [Figure 14] A flowchart of an exemplary method for configuring configuration parameters for DRBs and MRBs that can be implemented in the base station of FIG. 1A or in the CU or DU of FIG. 1B.

Best Mode for Carrying Out the Invention

[0015] Generally, a radio access network (RAN) and / or core network (CN) implement the techniques of this disclosure to manage multicast and / or broadcast service (MBS) transmissions. The CN can request that a base station configure a common downlink (DL) tunnel through which the CN can transmit MBS data for an MBS session for multiple user equipments (UEs) to the base station. In response to the request, the base station sends the configuration of the common DL tunnel to the CN. The configuration can include transport layer information such as an Internet Protocol (IP) address and a tunnel identifier (e.g., a tunnel endpoint identifier (TEID)).

[0016] The base station may also configure one or more logical channels toward the UE and / or one or more MBS radio bearers (MRBs) associated with the MBS session, where there may be a one-to-one mapping between each logical channel and each MRB. After receiving MBS data for the MBS session via the common DL tunnel, the base station may transmit the MBS data via one or more logical channels to one or more UEs participating in the MBS session. In some implementations, the base station transmits the MBS data to multiple UEs via a single logical channel. Furthermore, if there are multiple quality of service (QoS) flows for the MBS session, a single logical channel may be associated with multiple QoS flows, or there may be a one-to-one mapping between each QoS flow and each logical channel.

[0017] Before or after a UE joins an MBS session, the CN can have the base station configure a common DL tunnel. If additional UEs join the MBS session after the tunnel is configured, the CN can use the same common DL tunnel to transmit MBS data for multiple UEs to the base station.

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

[0019] The base station 104 supports a cell 124, and the base station 106 supports a cell 126. The cell 124 partially overlaps with the cell 126, such that the UE 102A can be within range to communicate with the base station 106 (or within range to detect or measure a signal from the base station 106) and within range to communicate with the base station 104 at the same time. This overlap can enable, for example, 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. Furthermore, 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 DC 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).

[0020] In non-MBS (unicast) operation, the UE 102A may use radio bearers (e.g., DRBs or SRBs) that terminate at the MN (e.g., base station 104) or SN (e.g., base station 106) at different times. For example, after a handover or SN change to the base station 106, 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 when communicating on radio bearers in the uplink (UE 102A to base station) direction and / or downlink (base station to UE 102A) direction. In non-MBS operation, the UE 102A transmits data to a base station via radio bearers on the cell's uplink (UL) bandwidth part (BWP) (i.e., within the UL BWP) and / or receives data from a base station via radio bearers on the cell's downlink (DL) BWP. The UL BWP can be an initial UL BWP or a dedicated UL BWP, and the DL BWP can be an initial DL BWP or a dedicated DL BWP. The UE 102A can receive paging, system information, public alert messages, or random access responses on the DL BWP. In this non-MBS operation, the UE 102A can be in a connected state. Alternatively, if the UE 102A supports small data transmission (sometimes referred to as "early data transmission") in the idle or inactive state, the UE 102A can be in an idle or inactive state.

[0021] In MBS operation, the UE 102A may use an MBS radio bearer (MRB) that terminates at an 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 over unicast radio resources (i.e., radio resources dedicated to the UE 102A) via the MRB. In other scenarios, the base station (e.g., MN or SN) may transmit MBS data from the base station to the UE 102A 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 via the MRB. 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, not for unicast).

[0022] The base station 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., central processing units (CPUs)) and computer-readable memory that stores machine-readable instructions executable on the one or more general-purpose processors and / or special-purpose processing units. The processing hardware 130 in the example implementation of FIG. 1A includes an MBS controller 132 configured to manage or control transmission of MBS information received from the CN 110 or edge server. For example, the MBS controller 132 may be configured to support radio resource control (RRC) configurations, procedures, and messaging associated with MBS procedures, and / or other operations associated with those configurations and / or procedures, as described below. 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.

[0023] 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 processors and / or special-purpose processing units. The processing hardware 140 in the example implementation of FIG. 1A includes an MBS controller 142 and a non-MBS controller 144, which may be similar to the controllers 132 and 134, respectively, of the base station 130. Although not shown in FIG. 1A, the RAN 105 may include additional base stations having processing hardware similar to the processing hardware 130 of the base station 104 and / or the processing hardware 140 of the base station 106.

[0024] The UE 102A includes processing hardware 150, 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 processors and / or special-purpose 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, the MBS controller 152 may be configured to support RRC configurations, procedures, and messaging associated with MBS procedures, as described below, and / or other operations associated with 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 described below when the UE 102A communicates with the MN and / or SN during non-MBS operation. Although not shown in FIG. 1A, the UEs 102B, 103 may each include processing hardware similar to the processing hardware 150 of the UE 102A.

[0025] The CN 110 may be an evolved packet core (EPC) 111 or a fifth-generation core (5GC) 160, both of which are illustrated 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 or Xn interface to directly exchange messages with each other during the scenarios described below.

[0026] 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 audio 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 EPC 160 includes a User Plane Function (UPF) 162, an Access and Mobility Management (AMF) 164, and / or a Session Management Function (SMF) 166. The UPF 162 is generally configured to forward user plane packets related to audio 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.

[0027] 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 control 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, or for MBS only.

[0028] 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 refer to particular CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), in general, the techniques of this disclosure may also be applied to other suitable radio access and / or core network technologies, such as, for example, sixth-generation (6G) radio access and / or 6G core networks or 5G NR-6G DC.

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

[0030] When the base station 104 is an MeNB and the base station 106 is an SgNB, the UE 102A can be in EN-DC 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 can be in Next Generation (NG) EUTRA-NR DC (NGEN-DC) 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 can be in NR-NR DC (NR-DC) 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 can be in NR-EUTRA DC (NE-DC) with the MgNB 104 and the Sng-eNB 106.

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

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

[0033] 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 for the CU 172 and / or the Radio Resource Control (RRC) protocol for 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 for the CU 172. As described herein, the CU-CP 172A may transmit non-MBS control information and MBS control information, and the CU-UP 172B may transmit non-MBS data packets and MBS data packets.

[0034] 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 implementations, one DU 174 may be connected to multiple CU-UPs 172B under the control of the same CU-CP 172A. In such implementations, connectivity between the CU-UP 172B and the DUs 174 is established by the CU-CP 172A using a bearer context management function.

[0035] The above description regarding UE 102A may also apply to UE 102B and / or UE 103.

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

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

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

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

[0040] In some implementations, a base station (e.g., base station 104 or 106) broadcasts MBS data packets via one or more MRBs, and the UE then receives the MBS data packets via the MRBs. The base station may include the configuration of the MRBs in multicast configuration parameters (sometimes referred to as MBS configuration parameters), described below. In some implementations, the base station broadcasts the MBS data packets via the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and the UE correspondingly receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, and the RLC sublayer 206. In such implementations, the base station and the UE 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 the UE correspondingly receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, and the PDCP sublayer 208. In such implementations, the base station and the UE may not use the SDAP sublayer 212 to communicate the MBS data packets. In yet other implementations, 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 the UE correspondingly receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, the PDCP sublayer 208, and the SDAP sublayer 212.

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

[0042] 3, which illustrates an example architecture 300 for MBS and PDU sessions, an MBS session 302A may include a tunnel 312A having endpoints at the CN 110 and a base station 104 / 106 (i.e., the base station 104 or the base station 106). The MBS session 302A may correspond to a particular 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.

[0043] 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 MBS traffic as well as for 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.

[0044] The tunnel 312A may operate at a transport layer or sublayer, for example, on a User Datagram Protocol (UDP) protocol layered on top of 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 a particular IP address (e.g., the IP address of the base station 104 / 106) and a particular 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 in a 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. The base stations 104 / 106 can accordingly use the IP address and / or TEID to designate data packets traveling through the tunnel 312A.

[0045] 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 described above, the PDCP sublayer provides support for radio bearers such as SRBs, DRBs, and MRBs, and the EUTRA MAC sublayer or NR MAC sublayer provides logical channels to the EUTRA RLC sublayer or NR RLC sublayer. Each of the MRBs 314A may correspond to, for example, 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 can correspond to a respective logical channel.

[0046] MBS traffic may include one or more quality of service (QoS) flows for each of tunnels 312A, 312B, etc. For example, MBS traffic on tunnel 312B may include a set of flows 316 including QoS flows 316A, 316B, ... 316L, where L > 1. Furthermore, a logical channel of an MRB may 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 maps QoS flow 316L to the MTCH of MRB 314B-N.

[0047] 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 can correspond to audio packets, and a flow with a relatively low QoS value can correspond to video packets. As another example, a flow with a relatively high QoS value can correspond to I-frames or full images used in video compression, and a flow with a relatively low QoS value can correspond to P-frames or predicted pictures that include only changes to the I-frames.

[0048] 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. A PDU session 304A can 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 can correspond to a respective logical channel, such as a dedicated traffic channel (DTCH).

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

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

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

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

[0053] The CU 172, in some cases, 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 the UE 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. The UL logical channel 443A may be, for example, a PUSCH. The DU 174A / 174B can map uplink traffic received via the UL logical channel 443A to the UL tunnel 433A.

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

[0055] Referring now to FIG. 5A, in an example scenario 500A, a base station 104 including a CU 172 and a DU 174 configures resources for transmitting MBS data for an MBS session.

[0056] A UE 102 (i.e., one or both / each of UEs 102A and 102B) first performs a (first) MBS session join procedure 502 with the CN 110 via a base station 104 to join a particular MBS session (i.e., a first MBS session). As described below, procedures 502 and 590 can be performed in either order because the base station 104 configures a common DL tunnel for MBS traffic rather than a UE-specific tunnel. In other words, the base station 104 can configure a common DL tunnel even before a single UE joins the MBS session.

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

[0058] In some implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message may be Session Initiation Protocol (SIP) messages. In other implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message may be NAS messages such as 5G Mobility Management (5GMM) messages or 5G Session Management (5GSM) messages. In the case of 5GSM messages, the UE 102 may send a (first) UL container message including the MBS session join request message to the CN 110 (via the base station 104), the CN 110 may send a DL container message including the MBS session join response message to the UE 102 (via the base station 104), and the UE 102 may send a (second) UL container message including the MBS session join complete message to the CN 110 via the base station 104. These container messages may 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. To simplify the following description, the MBS Session Join Request message, the MBS Session Join Response message, and / or the MBS Session Join Complete message may represent container messages.

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

[0060] Before, during, or after the (first) MBS session join procedure 502, the CN 110 may send (504) a (first) CN-to-BS message to the CU 172 including a first MBS session ID (e.g., MBS Session ID 1) and / or a PDU session ID to request the CU 172 to configure resources for the first MBS session. In response to receiving (504) the first CN-to-BS message, the CU 172 may send (506) a CU-to-DU message to the DU 174 to request MBS context setup and / or a common DL tunnel for the first MBS session. In response to receiving (506) the first CU-to-DU message, the DU 174 may send (508) a DU-to-CU message to the CU 172 including a first DL transport layer configuration for configuring the common CU-to-DU DL tunnel for the first MBS session. In some implementations, the CU-DU message is a generic F1AP message or a dedicated F1AP message specially defined for conveying this type of request (e.g., an MBS context setup request message). In some implementations, the DU-CU message of event 508 is a generic F1AP message or a dedicated F1AP message specially defined for this purpose (e.g., an MBS context setup response message). The CN 110 may additionally include a quality of service (QoS) configuration for the first MBS session. In such a case, the CU 172 may include the QoS configuration in the CU-DU message (event 506). In some implementations, the CU-DU message and the DU-CU message may be non-UE-specific messages.

[0061] The CU 172 sends a first inter-BS-CN message (e.g., an MBS Session Resource Setup Response message) in response to the message of event 504 (510). The CU 172 can include a first MBS session ID and / or a PDU session ID in the first inter-BS-CN message. The first inter-BS-CN message can include a DL transport layer configuration for configuring a common DL tunnel for the CN 110 to send MBS data to the CU 172. The DL transport layer configuration includes transport layer information such as a transport layer address (e.g., an IP address) and / or a TEID to identify the common DL tunnel. In some implementations, the inter-CN-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 inter-BS-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 convey resources for an MBS session. In such a case, the CN-BS message of event 504 and the BS-CN message of event 510 may be non-UE specific messages.

[0062] In some implementations, the QoS configuration includes QoS parameters for the MBS session. In some implementations, the QoS configuration includes configuration parameters for configuring one or more QoS flows for the MBS session (see FIG. 3 and its description above). In some implementations, the configuration parameters include one or more QoS flow IDs that identify the QoS flows. Each of the QoS flow IDs identifies a particular QoS flow among 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 averaging window, and / or a maximum data burst volume. The CN 110 can specify different values ​​of the QoS parameters for the QoS flows.

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

[0064] In some implementations, the CN 110 can indicate a list of UEs participating in the first MBS session in a first CN-to-BS message. In other implementations, the CN 110 can send (512) a second CN-to-BS message to the CU 172 indicating a list of UEs participating in the first MBS session. The CN 110 can include the first MBS session ID and / or PDU session ID in the second CN-to-BS message. The CU 172 can send (519) a second BS-to-CN message to the CN 110 in response to the second CN-to-BS message 512. In such a case, the second CN-to-BS message can be a non-UE-specific message, e.g., a message not specific to UE 102A or UE 102B. The CU 172 can include the first MBS session ID and / or PDU session ID in the second BS-to-CN message. For example, the list of UEs may include UE 102A and / or 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 of which identifies a specific one of the UEs. The CN 110 assigns the CN UE interface ID, and the CU 172 assigns the RAN UE interface ID. Before the CN 110 sends the list of (CN UE interface ID, RAN UE interface ID) pairs, the CU 172 sends a BS-CN message (e.g., an NGAP message, an INITIAL UE message, or a PATH SWITCH REQUEST message) including the RAN UE interface ID to the CN 110 for each of the UEs, and the CN 110 sends a CN-BS message (e.g., an NGAP message, an INITIAL CONTEXT SETUP REQUEST message, or a PATH SWITCH REQUEST ACKNOWLEDGE message) including the CN UE interface ID to the CU 172 for each of the UEs.In one example, the list of pairs includes a first pair identifying the UE 102A (first CN UE interface ID, first RAN UE interface ID) and a second pair identifying the UE 102B (second CN UE interface ID, second RAN UE interface ID). In some implementations, the “CN UE interface ID” can be an “AMF UE NGAP ID,” and the “RAN UE interface ID” can be a “RAN UE NGAP ID.” In other implementations, the CN 110 can include a list of UE IDs, each identifying a specific one of the UEs. In some implementations, the CN 110 can assign UE IDs and send 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 can include a first UE ID of the UE 102A and a second UE ID of the UE 102B. In some implementations, the UE ID is an S-Temporary Mobile Subscriber Identity (S-TMSI) (e.g., 5G-S-TMSI). Before the CN 110 sends the list of UE IDs, the CU 172 can receive the UE IDs from the UE 102 or the CN 110 for each of the UEs. For example, the CU 172 can 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 can receive a CN-BS message (e.g., an NGAP message, an INITIAL CONTEXT SETUP REQUEST message, or a UE INFORMATION TRANSFER message) including the UE ID from the CN 110.

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

[0066] In some implementations, the second CN-to-BS message and the second BS-to-CN message may be a PDU session resource change request message and a PDU session resource change response message, respectively.

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

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

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

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

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

[0072] Events 512, 514, 516, 518, 519, 520, 522, and 523 are collectively referred to in FIG. 5A as a UE-specific MBS session resource configuration procedure 592. In some implementations, a respective instance of events 512, 514, 516, 518, 519, 520, 522, and 523 occurs for each of UE 102A and UE 102B. The configuration parameters for UE 102A and UE 102B to receive MBS data for the first MBS session may be the same. In some implementations, MBS session join procedure 502 includes UE-specific MBS session resource setup procedure 592. In such a case, CN 110 can include an MBS session join response message for UE 102 in the second CN-BS message.

[0073] In some implementations, the CU 172 can include the CU DL transport layer configuration in the second BS-CN message. In other words, the CU 172 can send the same CU DL transport layer configuration in a BS-CN message in response to a CN-BS message indicating that the UE will participate in the same MBS session. Similarly, the DU 174 can include the first DU DL transport layer configuration in a UE context response message. In other words, the DU 174 can send the same DU DL transport layer configuration in a DU-CU message in response to a CU-DU message indicating that the UE will participate in the same MBS session. In such implementations, the CN 110 participates in the MBS resource setup procedure 590 and can blend the second CN-BS message and the second BS-CN message into a single procedure.

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

[0075] After receiving the first inter-BS-CN message (510) or the second inter-BS-CN message (519), the CN 110 can send MBS data (e.g., one or more MBS data packets) to the CU 172 via a common CN-BS DL tunnel (i.e., the first common CN-BS DL tunnel) (524), and the CU 172 sends the MBS data to the DU 174 via a common CU-DU DL tunnel (i.e., the first common CU-DU DL tunnel) (526). The DU 174 transmits (e.g., multicast or unicast) the MBS data to the UE 102 (i.e., UE 102A and / or UE 102B) via one or more logical channels (528). The UE 102 receives the MBS data via one or more logical channels (528). For example, the CU 172 receives (524) an MBS data packet, generates a PDCP PDU including the MBS data packet, and transmits (526) the PDCP PDU to the DU 174. The DU 174 then generates (528) a MAC PDU including the logical channel ID and the PDCP PDU, and transmits (528) the MAC PDU to the UE 102 via multicast or unicast. The UE 102 receives (528) the MAC PDU via multicast or unicast, extracts the PDCP PDU and logical channel ID from the MAC PDU, identifies the PDCP PDU associated with the MRB, and extracts the MBS data packet from the PDCP PDU.

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

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

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

[0079] In some implementations, the MRB configuration may be an MRB-ToAddMod IE that includes an MRB ID (e.g., mrb-Identity or MRB-Identity). The MRB ID identifies a specific MRB among the MRBs. The CU 172 sets the MRB ID to a different value. If the CU 172 configures a DRB for the UE 102 for unicast data communication, the CU 172 may, in some implementations, 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 an RB is an MRB or a DRB according to the RB ID of the RB. In other implementations, the CU 172 may set one or more of the MRB IDs to values ​​that may be the same as one or more of the DRB IDs. In such a case, the UE 102 and the CU 172 may distinguish whether an RB is an MRB or a DRB according to the RB ID of the RB and the RRC IE that configures the RB. For example, a DRB configuration that configures a DRB is a DRB-ToAddMod IE that includes DRB identification information (e.g., drb-Identity or DRB-Identity) and a PDCP configuration. Thus, the UE 102 can determine that an RB is a DRB if the UE 102 receives a DRB-ToAddMod IE that configures the RB, and can determine that an RB is an MRB if the UE 102 receives an MRB-ToAddMod IE that configures the RB. Similarly, the CU 172 can determine that an RB is a DRB if the CU 172 sends a DRB-ToAddMod IE that configures the RB to the UE 102, and can determine that an RB is an MRB if the CU 172 sends an MRB-ToAddMod IE that configures the RB to the UE 102.

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

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

[0082] In another implementation, the CU 172 sends a DL RRC message, which is an MBS session join response message, to the UE 102 via the DU 174. 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, which includes an MBS session join complete message, to the CU 172 via the DU 174. The UL RRC message may be a UL Information Transfer message, another RRC reconfiguration complete message, or any suitable RRC message that may include a UL NAS PDU.

[0083] Continuing with reference to FIG. 5A , UE 103 (and possibly each of one or more other UEs not shown in FIG. 1A ) may perform an MBS session join procedure 530 to join a second MBS session identified by a second MBS session ID (e.g., MBS session ID 2), similar to procedure 502 described above. Base station 104 may perform an MBS session resource setup procedure 591 with CN 110 to configure a second common CN-to-BS DL tunnel and a second common CU-to-DU DL tunnel for the second MBS session, similar to procedure 590. Base station 104 may perform a UE-specific MBS session configuration procedure 593 with UE 103 and CN 110 to send configuration parameters and one or more MRB configurations for the second MBS session to UE 103, similar to procedure 590. Some or all of the configuration parameters and MRB configurations of procedure 593 may differ from the configuration parameters and MRB configurations of procedure 592. For example, the configuration parameters of step 593 may include a second G-RNTI (value) that is different from the G-RNTI (value) in the configuration parameters of step 592. In another example, the MRB configuration of step 593 may include an MRB ID that is different from the MRB ID in the configuration parameters of step 592.

[0084] After the UE 103 joins the second MBS session (at event 530) and obtains the necessary RRC configuration, and after the CN 110 performs the procedure (591), the CN 110 can send (532) MBS data (e.g., one or more MBS data packets) to the CU 172 via the second common CN-to-BS DL tunnel, similar to event 524. The CU 172 then sends (534) the MBS data to the DU 174 via the second common CU-to-DU DL tunnel, similar to event 526. The DU 174 transmits (536) the MBS data to the UE 103 (and possibly to each of one or more other UEs not shown in FIG. 1A ) via one or more logical channels, similar to event 528. The UE 103 (and possibly other UEs) receive (536) the MBS data via one or more logical channels, similar to event 528.

[0085] After the CU 172 performs procedure 591 with the CN 110 and the DU 174 and the UE 103 joins the second MBS session (at event 530) and acquires the necessary RRC configuration, the CU 172 continues to receive MBS data via the first common CN-BS DL tunnel (538) and transmits MBS data to the DU 174 via the first common CU-DU DL tunnel (540). In some implementations, the DU 174 transmits MBS data to the UE 102A and the UE 102B via multicast (542), similar to event 528. The UEs 102 (e.g., UE 102A and UE 102B) can receive the MBS data (542), similar to event 528. Alternatively, the base station 104 can transmit the MBS data separately to the UEs 102 (including UE 102A and UE 102B) via unicast, similar to event 528. In this case, the UE 102A and the UE 102B may separately receive 542 the MBS data via unicast, similar to event 528.

[0086] Referring now to Figure 5B, a scenario 500B is illustrated that is substantially similar to scenario 500A. Events in this scenario that are similar to those described above are labeled with the same reference numbers, and examples and implementations for Figure 5A can be applied to Figure 5B. Differences between the scenarios of Figure 5A and Figure 5B are described below.

[0087] In some implementations, the CU 172 can perform an MBS session resource setup procedure with the CN 110 (i.e., events 510 and 504) in response to receiving (512) the second inter-CN-BS message. In such implementations, the CU 172 transmits (510) a first inter-BS-CN message to the CN 110 in response to receiving (512) the second inter-CN-BS message. The CN 110 transmits (504) a first inter-CN-BS message to the CU 172 in response to receiving (510) the first inter-BS-CN message. In such cases, the CN 110 may or may not include an MBS session ID (i.e., the first MBS session ID) in the first inter-CN-BS message. The CN 110 can transmit (519) an inter-BS-CN message in response to or after receiving (512) the second inter-CN-BS message or the first inter-CN-BS message. After or in response to receiving (512) the second CN-to-BS message, transmitting (510) the second BS-to-CN message, or receiving (504) the first CN-to-BS message, the CU 172 may transmit (506) a CU-to-DU message to the DU 174.

[0088] 5B is referred to collectively as an MBS resource setup and UE-specific MBS session configuration procedure 594. Similar to procedure 594, base station 104 may perform an MBS resource setup and UE-specific MBS session configuration procedure with UE 103 and CN 110 to send configuration parameters and one or more MRB configurations for the second MBS session to UE 103.

[0089] Some example methods that the devices shown in Figures 1A and 1B may implement in particular scenarios will now be described with reference to Figures 6A-14. Each of these methods may be implemented by one or more processors executing a set of instructions stored on a non-transitory computer-readable medium.

[0090] Referring first to FIG. 6A , a DU, such as the DU 174, can implement / perform a method 600A to determine whether to configure at least one configuration parameter for a radio bearer (RB). The method 600A begins at block 602, in which the DU determines to configure resources for the RB (e.g., events 506, 514, 593). At block 604, the DU determines whether the RB is an MRB. If the RB is not an MRB (i.e., if the RB is a unicast RB such as an SRB or DRB), the flow proceeds to block 606. At block 606, the DU includes a first logical channel ID for the RB in a DU-to-CU message. At block 608, the DU includes at least one configuration parameter for the RB in a DU-to-CU message. If the RB is an MRB, the flow instead proceeds to block 610. At block 610, the DU includes a second logical channel ID for the RB in a DU-to-CU message (e.g., events 508, 516, 593). In block 612, the DU refrains from including at least one configuration parameter for the RB in the DU-to-CU message (e.g., events 508, 516, 593). In block 614, the DU sends the DU-to-CU message to the CU (e.g., events 508, 516, 593).

[0091] In some implementations, the first and second logical channel IDs can be the same logical channel ID. In other implementations, the first and second logical channel IDs can be different logical channel IDs. In some implementations, the DU can set the first and second logical channel IDs to the same value. In other implementations, the DU can set the first and second logical channel IDs to different values.

[0092] In some implementations, the DU receives a CU-DU message from the CU (e.g., events 506, 514, 593). The CU can indicate in the CU-DU message whether the RB is a unicast RB (e.g., DRB or SRB) or an MRB. In some implementations, the CU can include the RB ID of the RB in the CU-DU message. If the RB is an MRB, the RB ID may be the MRB ID. If the RB is an SRB, the RB ID may be the SRB ID. If the RB is a DRB, the RB ID is the DRB ID. In response to the CU-DU message, the DU decides to configure resources for the RB. Depending on whether the RB is an MRB or a unicast RB (e.g., DRB or SRB), the DU obtains different configuration parameters (e.g., a logical channel ID and / or at least one other configuration parameter) as described above and includes the different configuration parameters in the DU-CU message. The DU then sends a DU-CU message to the CU in response to the CU-DU message. In some implementations, the DU can determine whether the RB is an MRB, an SRB, or a DRB according to the MRB indication, the SRB indication, or the DRB indication for the RB, respectively. In other implementations, the DU can determine whether the RB is an MRB, an SRB, or a DRB according to the MRB ID, the SRB ID, or the DRB ID, respectively.

[0093] In some implementations, the CU-DU message and the DU-CU message may be F1 Application Protocol (F1AP) messages. In some implementations, the CU-DU message and the DU-CU message may be UE Context Setup Request messages and UE Context Setup Response messages, respectively. In other implementations, the CU-DU message and the DU-CU message may be UE Context Modification Request messages and UE Context Modification Response messages, respectively. In still other implementations, the CU-DU message and the DU-CU message may be MBS Context Setup Request messages and MBS Context Setup Response messages, respectively. In still other implementations, the CU-DU message and the DU-CU message may be MBS Context Modification Request messages and MBS Context Modification Response messages, respectively.

[0094] If the RB is an MRB, the CU (e.g., CU 172) generates a first DL message including a first logical channel ID (value) and at least one configuration parameter and transmits the first DL message to the UE via the DU. In other words, the DU can transmit the first logical channel ID (value) and at least one configuration parameter to the first UE via the CU. In some implementations, the CU can generate an MRB configuration including an MRB ID and / or PDCP configuration parameters for the MRB and include the MRB configuration in the DL message. If the RB is a unicast RB, the CU generates a second DL message including a second logical channel ID (value) and transmits the second DL message to the second UE via the DU. In some implementations, the CU can generate a unicast RB configuration (e.g., an SRB configuration or a DRB configuration) including a unicast RB ID (e.g., an SRB ID or a DRB ID) and / or PDCP configuration parameters for the unicast RB and include the unicast RB configuration in the second DL message. The first and second UEs may be the same UE or different UEs. In some implementations, the first and second DL messages are RRC reconfiguration messages (e.g., RRCReconfiguration messages).

[0095] In some implementations, the at least one configuration parameter includes a logical channel configuration (e.g., a mac-LogicalChannelConfig field or a LogicalChannelConfig IE). In other implementations, the at least one configuration parameter includes an uplink configuration parameter for the MAC layer (e.g., a ul-SpecificParameters field). In still other implementations, the at least one configuration parameter includes a logical channel group (e.g., a logicalChannelGroup field), a subcarrier spacing list (e.g., an allowedSCS-List field), a scheduling request ID (e.g., a schedulingRequestedID field or a SchedulingRequestedId IE), a timer value (e.g., a bitRateQueryProhibitTimer field), a physical priority index (e.g., an allowedPHY-PriorityIndex field), a channel access priority (e.g., a channelAccessPriority field), and / or a bit rate multiplier (e.g., a bitRateMultiplier field).

[0096] In some implementations, the DU may transmit at least one first uplink configuration parameter for the physical layer to the UE, for example, via the CU. When the UE receives a PDSCH transmission including a PDU associated with an RB (i.e., a unicast RB), the UE may transmit HARQ feedback to the RAN node according to the at least one first configuration parameter. For example, the at least one first configuration parameter may include a PUCCH configuration (e.g., a PUCCH-Config IE). In another example, the at least one first configuration parameter may include at least one PUCCH resource configuration, which may include or configure one or more PUCCH resources (e.g., a PUCCH-Resource IE) and / or one or more PUCCH resource sets (e.g., one or more PUCCH-ResourceSet IEs). In yet another example, the at least one first configuration parameter may include at least one PUCCH format configuration (e.g., a PHCCH-FormatConfig IE), at least one PUCCH spatial relation configuration (e.g., a PUCCH-SpatialRelationInfo IE), a PUCCH power control configuration (e.g., a PUCCH-PowerControl IE), and / or at least one downlink data-uplink acknowledgement timing configuration (e.g., a dl-DataToUL-ACK field, a dl-DataToUL-ACK-DCI-1-2 field, a dl-DataToUL-ACK-r16 field, and / or a dl-DataToUL-ACK-DCI-1-2-r17 field). In some implementations, the at least one first uplink configuration parameter for the physical layer and the at least one second uplink configuration parameter for the physical layer may include the same configuration parameter (value). In other implementations, the at least one first uplink configuration parameter for the physical layer and the at least one second uplink configuration parameter for the physical layer may include different configuration parameters (values).

[0097] In other implementations, the RAN node may transmit at least one second uplink configuration parameter for the physical layer to the UE, for example, in at least one second message. When the UE receives a PDSCH transmission including a PDU associated with an MRB, the UE may transmit HARQ feedback to the RAN node according to the at least one second configuration parameter. For example, the at least one second configuration parameter may include a PUCCH configuration (e.g., a PUCCH-Config IE). In another example, the at least one second configuration parameter may include at least one PUCCH resource configuration, which may include or configure one or more PUCCH resources (e.g., a PUCCH-Resource IE) and / or one or more PUCCH resource sets (e.g., one or more PUCCH-ResourceSet IEs). In yet another example, the at least one second configuration parameter may include at least one PUCCH format configuration (e.g., PHCCH-FormatConfig IE), at least one PUCCH spatial relationship configuration (e.g., PUCCH-SpatialRelationInfo IE), a PUCCH power control configuration (e.g., PUCCH-PowerControl IE), and / or at least one downlink data-uplink acknowledgement timing configuration (e.g., dl-DataToUL-ACK field, dl-DataToUL-ACK-DCI-1-2 field, dl-DataToUL-ACK-r16 field, and / or dl-DataToUL-ACK-DCI-1-2-r17 field).

[0098] 6B is a flow diagram of an example method 600B that is similar to the method 600A of FIG. 6A. In block 602, a DU (e.g., DU 174) decides to configure resources for an RB (e.g., events 506, 514, 593). In block 603, the DU includes a logical channel ID for the RB in a DU-to-CU message (e.g., events 508, 516, 593). In block 604, the DU determines whether the RB is an MRB. If the RB is not an MRB (e.g., if the RB is a unicast RB such as an SRB or DRB), the flow proceeds to block 608. In block 608, the DU includes at least one configuration parameter for the RB in a DU-to-CU message. If the RB is an MRB, the flow instead proceeds to block 612. In block 612, the DU refrains from including at least one configuration parameter for the RB in a DU-to-CU message (e.g., events 508, 516, 593). In block 614, the DU sends a DU-to-CU message to the CU (eg, events 508, 516, 593).

[0099] Referring now to FIG. 7, a DU, such as the DU 174, may implement / perform a method 700 to determine to configure a first or second configuration for an RB. In block 702, the DU decides to configure resources for the RB (e.g., events 506, 514, 593). In block 704, the DU determines whether the RB is an MRB. If the RB is not an MRB (i.e., if the RB is a unicast RB such as an SRB or DRB), the flow proceeds to block 706. In block 706, the DU includes the first configuration for the RB (e.g., a first CellGroupConfig IE or a first RLC-BearerConfig IE) in a DU-CU message. If the RB is an MRB, the flow instead proceeds to block 708. In block 708, the DU includes the second configuration for the RB (e.g., a second CellGroupConfig IE or a second RLC-BearerConfig IE) in a DU-CU message (e.g., events 508, 516, 593). In block 710, the DU sends a DU-to-CU message to the CU (eg, events 508, 516, 593).

[0100] In some implementations, the first and second configurations include different configuration parameters and / or different values ​​of configuration parameters, ie, the first and second configurations include configuration parameters as described with respect to Figures 5 and / or 6A.

[0101] In some implementations, the DU receives a CU-to-DU message from the CU (e.g., events 506, 514, 593), as described with respect to Figure 5 and / or Figure 6A, and the DU decides to configure resources for the RB in response to the CU-to-DU message. In such implementations, the DU sends a DU-to-CU message in response to the CU-to-DU message.

[0102] In some implementations, if the RB is an MRB, the DU includes RLC parameters (e.g., an um-Uni-Directional-DL field) in the second configuration to indicate that the RB is a DL-only RB (i.e., a unidirectional DL RB). In some implementations, if the RB is a unicast RB, the DU includes RLC parameters (e.g., an am field or an um-Bi-Directional field) in the first configuration to indicate that the RB is a bidirectional RB.

[0103] Referring now to FIG. 8, a DU, such as DU 174, may implement / perform an example method 800 to determine whether to configure at least one configuration parameter for an MRB.

[0104] More specifically, in block 802, the DU decides to provide configuration parameters for the MRB (e.g., events 506, 514, 593). In block 804, the DU includes at least one first configuration parameter for the MRB in a DU-CU message (e.g., events 508, 516, 593). In block 806, the DU determines whether the MRB requires UL resources. If the MRB requires UL resources, the flow proceeds to block 808. In block 808, the DU includes at least one second configuration parameter in a DU-CU message (e.g., events 508, 516, 593). If the MRB does not require UL resources, the flow proceeds instead to block 810. In block 810, the DU sends a DU-CU message to the CU (e.g., events 508, 516, 593), i.e., does not include the second configuration parameter in the DU-CU message.

[0105] In some implementations, the DU determines whether the MRB requires UL resources in block 806 according to QoS parameters associated with the MRB. In some implementations, the DU receives at least one CU-DU message including QoS parameters from the CU. In other implementations, the DU is pre-configured with QoS parameters for the MRB.

[0106] In one implementation, if the QoS parameters include a specific QoS parameter (e.g., a first QoS parameter), the DU determines in block 806 that the MRB requires UL resources. Otherwise (e.g., if the QoS parameters do not include a specific QoS parameter), the DU determines in block 806 that the MRB does not require UL resources. For example, the QoS parameters may include a QoS flow ID. If the QoS flow ID is a specific QoS flow ID (e.g., a first QoS flow ID), the DU determines in block 806 that the MRB requires UL resources. Otherwise (e.g., if the QoS flow ID (e.g., a second QoS flow ID) is not a specific QoS flow ID), the DU determines in block 806 that the MRB does not require UL resources. In another example, the QoS parameters include QoS flow-level QoS parameters. If the QoS flow-level QoS parameters include a specific QoS flow-level QoS parameter (e.g., a first QoS flow-level QoS parameter), the DU determines in block 806 that the MRB requires UL resources. Otherwise (e.g., if the QoS flow-level QoS parameters do not include the specific QoS flow-level QoS parameters), the DU determines in block 806 that the MRB does not require UL resources. In another implementation, if the QoS parameters include QoS parameters for the uplink, the DU determines in block 806 that the MRB requires UL resources. Otherwise (e.g., if the QoS parameters do not include QoS parameters for the uplink), the DU determines in block 806 that the MRB does not require UL resources. For example, if the QoS parameters include a UE aggregate maximum bit rate for the uplink, the DU may determine in block 806 that the MRB requires UL resources. Otherwise (e.g., if the QoS parameters do not include a UE aggregate maximum bit rate for the uplink), the DU determines in block 806 that the MRB does not require UL resources. In yet another example, the QoS parameters include a QoS identifier (e.g., a 5G QoS identifier).If the QoS identifier is a specific QoS identifier (e.g., the first QoS identifier), the DU determines that the MRB requires UL resources in block 806. Otherwise (e.g., if the QoS identifier (e.g., the second QoS identifier) ​​is not a specific QoS identifier), the DU determines that the MRB does not require UL resources in block 806.

[0107] In some implementations, the DU receives a CU-DU message for the MRB from the CU. If the CU-DU message includes an indication that UL resources are required, the DU determines that the MRB requires UL resources in block 806. Otherwise (e.g., if the CU-DU message does not include an indication that UL resources are required for the MRB or includes an indication that DL-only resources are required for the MRB), the DU determines that the MRB does not require UL resources in block 806.

[0108] In some implementations, the at least one second configuration parameter is similar to the at least one configuration parameter described above with respect to FIGS. 5 and 6A.

[0109] Referring now to FIG. 9A, a CU, such as CU 172, may implement / perform an example method 900A to indicate to a DU that uplink resources are needed for an MRB or MBS session, or to refrain from indicating this to the DU.

[0110] In block 902, the CU decides to configure an MRB for the MBS session (e.g., events 504, 591). In block 904, the CU includes the MRB ID of the MRB in a CU-DU message (e.g., events 506, 514, 593). In block 906, the CU determines whether the MRB or MBS session requires UL resources. If the MRB or MBS session requires UL resources, the flow proceeds to block 908. In block 908, the CU includes an indication in the CU-DU message indicating that UL resources are required for the MRB or MBS session (e.g., events 506, 514, 593). If the MRB or MBS session does not require UL resources, the flow proceeds instead to block 910. In this case, the CU refrains from including an indication in the CU-DU message. The flow proceeds from block 906 (for the "no" branch) as well as from block 908 to block 910. In block 910, the CU sends a CU-DU message to the DU (e.g., events 506, 514, 593). In block 912, in response to the CU-DU message, the CU receives a DU-CU message including configuration parameters for the MRB (e.g., in a container IE) from the DU (e.g., events 508, 516, 593). In block 914, the CU extracts the configuration parameters from the DU-CU message (e.g., extracts a container IE including the configuration parameters) (e.g., events 508, 516, 593). In block 916, the CU sends a DL message including the configuration parameters (e.g., in a container IE) to the UE via the DU (e.g., events 518, 520, 593).

[0111] In some implementations, the CU receives from the CN (e.g., AMF) a CN-to-BS message including an MBS session ID of the MBS session from the CU, and the CU determines to configure an MRB for the MBS session in response to the CN-to-BS message. The CU can send a BS-to-CN message to the CN in response to the CN-to-BS message.

[0112] In some implementations, the CN-to-BS messages and the BS-to-CN messages may be Next Generation Application Protocol (NGAP) messages. In other implementations, the CN-to-BS messages and the BS-to-CN messages may be PDU Session Resource Setup Request messages and PDU Session Resource Setup Response messages, respectively. In other implementations, the CN-to-BS messages and the BS-to-CN messages may be PDU Session Resource Modify Request messages and PDU Session Resource Modify Response messages, respectively. In still other implementations, the CN-to-BS messages and the BS-CN messages may be MBS Session Resource Setup Request messages and MBS Session Resource Setup Response messages, respectively. In still other implementations, the CN-to-BS messages and the BS-CN messages may be MBS Session Resource Modify Request messages and MBS Session Resource Modify Response messages, respectively.

[0113] The CU can indicate whether an RB is a unicast RB (e.g., DRB or SRB) or an MRB in a CU-DU message. In some implementations, the CU can include the RB ID of the RB in the CU-DU message. If the RB is an MRB, the RB ID may be an MRB ID. If the RB is an SRB, the RB ID may be an SRB ID. If the RB is a DRB, the RB ID is a DRB ID. In response to the CU-DU message, the DU decides to configure resources for the RB. Depending on whether the RB is an MRB or a unicast RB (e.g., a DRB or SRB), the DU obtains different configuration parameters (e.g., a logical channel ID and / or at least one configuration parameter) as described above and includes the different configuration parameters in the DU-CU message. Then, the DU sends a DU-CU message to the CU in response to the CU-DU message. In some implementations, the DU can determine whether the RB is an MRB, an SRB, or a DRB according to an MRB indication, an SRB indication, or a DRB indication for the RB, respectively. In other implementations, the DU may determine that the RB is an MRB, an SRB, or a DRB according to the MRB ID, the SRB ID, or the DRB ID, respectively.

[0114] In some implementations, the CU-DU message and the DU-CU message may be F1AP messages. In some implementations, the CU-DU message and the DU-CU message may be UE context setup request messages and UE context setup response messages, respectively. In other implementations, the CU-DU message and the DU-CU message may be UE context modification request messages and UE context modification response messages, respectively. In still other implementations, the CU-DU message and the DU-CU message may be MBS context setup request messages and MBS context setup response messages, respectively. In still other implementations, the CU-DU message and the DU-CU message may be MBS context modification request messages and MBS context modification response messages, respectively.

[0115] In some implementations, the container IE may be a CellGroupConfig IE. In some implementations, the CU determines whether the MRB or MBS session requires UL resources according to QoS parameters associated with the MRB or MBS session. In some implementations, the CN-to-BS message (i.e., the first CN-to-BS message) includes the QoS parameters. In other implementations, the CU receives a second CN-to-BS message from the CN that includes the QoS parameters. In still other implementations, the CU is pre-configured with QoS parameters for the MRB or MBS session. In one implementation, if the QoS parameters include a specific QoS parameter (e.g., a first QoS parameter), the CU determines in block 906 that the MRB or MBS session requires UL resources. Otherwise (e.g., if the QoS parameters do not include the specific QoS parameter), the CU determines in block 906 that the MRB or MBS session does not require UL resources. For example, the QoS parameters include a QoS flow ID. If the QoS flow ID is a specific QoS flow ID (e.g., the first QoS flow ID), the CU determines in block 906 that the MRB or MBS session requires UL resources. Otherwise (e.g., if the QoS flow ID (e.g., the second QoS flow ID) is not a specific QoS flow ID), the CU determines in block 906 that the MRB or MBS session does not require UL resources. In another example, the QoS parameters include QoS flow-level QoS parameters. If the QoS flow-level QoS parameters include a specific QoS flow-level QoS parameter (e.g., the first QoS flow-level QoS parameter), the CU determines in block 906 that the MRB requires UL resources. Otherwise (e.g., if the QoS flow-level QoS parameters do not include a specific QoS flow-level QoS parameter), the CU determines in block 906 that the MRB does not require UL resources.In another implementation, if the QoS parameters include QoS parameters for the uplink, the CU determines that the MRB requires UL resources in block 906. Otherwise (e.g., if the QoS parameters do not include QoS parameters for the uplink), the CU determines that the MRB does not require UL resources in block 906. For example, if the QoS parameters include a UE aggregate maximum bit rate for the uplink, the CU determines that the MRB requires UL resources in block 906. Otherwise (e.g., if the QoS parameters do not include a UE aggregate maximum bit rate for the uplink), the CU determines that the MRB does not require UL resources in block 906. In yet another example, the QoS parameters include a QoS identifier (e.g., a 5G QoS identifier). If the QoS identifier is a specific QoS identifier (e.g., a first QoS identifier), the CU determines that the MRB requires UL resources in block 906. Otherwise (e.g., if the QoS identifier (e.g., a second QoS identifier) ​​is not a specific QoS identifier), the CU determines that the MRB does not require UL resources in block 906.

[0116] In some implementations, if the first or second CN-to-BS message includes an indication that UL resources are required, the CU determines that the MRB or MBS session requires UL resources in block 906. Otherwise (e.g., if the first or second CN-to-BS message does not include an indication that UL resources are required for the MRB or includes an indication that DL-only resources are required for the MRB), the CU determines in block 906 that the MRB or MBS session does not require UL resources.

[0117] In some implementations, the indication in block 908 is a new IE. In other implementations, the indication in block 908 is a QoS parameter as described above.

[0118] In response to the indication indicating that UL resources are needed for the MRB or MBS session, the DU, in some implementations, generates at least one configuration parameter and includes the at least one configuration parameter in a container IE or a DU-CU message. In such implementations, the DU may include at least one first uplink configuration parameter for the PHY in the container IE or the DU-CU message. Examples and implementations of the at least one configuration parameter and the at least one first uplink configuration parameter for the PHY are as described above with respect to FIG. 6A.

[0119] If the MRB or MBS session does not require UL resources, the CU may, in some implementations, include an indication that UL resources are not required for the MRB or MBS session. If the MRB or MBS session does not require UL resources, the CU may, in other implementations, include an indication that DL-only resources are required for the MRB or MBS session.

[0120] If the CU-DU message excludes an indication that UL resources are required, or includes an indication that UL resources are not required or an indication that DL-only resources are required, the DU does not include at least one configuration parameter in the container IE or DU-CU message. In such a case, in some implementations, the DU may include at least one first uplink configuration parameter for the PHY in the container IE or DU-CU message. Alternatively, the DU may not include at least one first uplink configuration parameter for the PHY in the container IE or DU-CU message.

[0121] FIG. 9B illustrates an example method 900B that is similar to method 900A except that method 900B includes blocks 907 and 909 instead of blocks 906 and 908.

[0122] In block 907, the CU determines whether the MRB or MBS session requires DL dedicated resources or not. If the MRB or MBS session requires DL dedicated resources, the flow proceeds to block 909. In block 909, the CU includes an indication in the CU-DU message indicating that DL dedicated resources are required for the MRB or MBS session (e.g., events 506, 514, 593). If the MRB or MBS session requires UL resources, the flow proceeds instead to block 910. The flow proceeds from block 907 (the "no" branch) as well as from block 909 to block 910.

[0123] The examples and implementations described above for FIG. 9A can also be applied to FIG. 9B.

[0124] If the CU-DU message excludes an indication that DL dedicated resources are required, the DU, in some implementations, generates at least one configuration parameter and includes the at least one configuration parameter in a container IE or a DU-CU message. In such implementations, the DU can further include at least one first uplink configuration parameter for the PHY in the container IE or the DU-CU message.

[0125] In response to the indication that DL dedicated resources are required, the DU does not include at least one configuration parameter in the container IE or DU-CU message. In such a case, in some implementations, the DU may include at least one first uplink configuration parameter for the PHY in the container IE or DU-CU message. Alternatively, the DU does not include at least one first uplink configuration parameter for the PHY in the container IE or DU-CU message.

[0126] Referring now to FIG. 10, a CU, such as CU 172, may implement / perform an example method 1000 to determine an RLC mode for an MRB.

[0127] In block 1002, the CU decides to configure an MRB for the MBS session (e.g., events 504, 591). In block 1004, the CU includes the MRB ID of the MRB in a CU-DU message (e.g., events 506, 514, 593). In block 1006, the CU determines the RLC mode in the RLC mode IE. In block 1008, the CU includes the RLC mode IE in a CU-DU message (e.g., events 506, 514, 593). In block 1010, the CU sends a CU-DU message to the DU (e.g., events 506, 514, 593). In response to the CU-DU message, in block 1012, the CU receives a DU-CU message including configuration parameters for the MRB (e.g., in a container IE) from the DU (e.g., events 508, 516, 593). In block 1014, the CU retrieves the configuration parameters from the DU-to-CU message (e.g., retrieves a container IE containing the configuration parameters). In block 1016, the CU sends a DL message containing the configuration parameters (including the container IE) to the UE via the DU (e.g., events 518, 520, 593).

[0128] In some implementations, the CU determines the RLC mode based on the QoS parameters for the MBS session as described above. For example, if the QoS parameters indicate a certain level of reliability is required, the CU may determine the RLC mode to be RLC acknowledged mode (AM). Otherwise, the CU determines the RLC mode to be RLC unacknowledged mode (UM). In another example, if the QoS parameters indicate a certain level of latency is required, the CU determines the RLC mode to be RLC UM. Otherwise, the CU determines the RLC mode to be RLC AM. More generally, if the QoS parameters include a certain QoS parameter (e.g., a first QoS parameter), the CU determines the RLC mode to be RLC AM. Otherwise (i.e., if the QoS parameters include a second QoS parameter), the CU determines the RLC mode to be RLC UM.

[0129] In some implementations, the DU generates an RLC bearer configuration according to the RLC mode IE. If the RLC mode IE indicates RLC AM, the RLC bearer configuration includes an indication of RLC AM and / or RLC AM parameters. If the RLC mode IE indicates RLC UM, the RLC bearer configuration includes an indication of RLC UM and / or RLC UM parameters. The DU includes the RLC bearer configuration in the configuration parameters. Thus, the DU transmits MBS data of the MBS session using the RLC mode configured in the RLC bearer configuration via multicast or unicast. The UE receives the MBS data using the RLC mode.

[0130] Referring now to FIG. 11A, a CU, such as CU 172, may implement / perform an example method 1100A to determine an RLC mode for an MRB.

[0131] Method 1100A begins at block 1102, where the CU decides to configure an MRB for an MBS session (e.g., events 504, 591). In block 1104, the CU includes the MRB ID of the MRB in a CU-DU message (e.g., events 506, 514, 593). In block 1106, the CU determines whether the MRB or MBS session requires UL resources. If the MRB or MBS session requires UL resources, flow proceeds to block 1108. In block 1108, the CU sets the RLC mode IE to a value indicating RLC AM and includes the RLC mode IE in a CU-DU message (e.g., events 506, 514, 593). If the MRB or MBS session does not require UL resources, flow proceeds instead to block 1109. In block 1109, the CU sets the RLC mode IE to a value indicating RLC UM and includes the RLC mode IE in the CU-DU message (e.g., events 506, 514, 593). Flow proceeds from block 1108 and from block 1109 to block 1110. In block 1110, the CU performs the actions described above for blocks 910, 912, 914, and 916. The examples and implementations described above for Figure 10 can also be applied to Figure 11A.

[0132] 11B shows an example method 1100B that is similar to method 1100A except that method 1100B includes block 1107 instead of block 1106. In block 1107, the CU determines whether to request PTP transmission for the MRB or MBS session or to request PTM transmission instead (e.g., events 504, 591). If the CU requests PTP transmission for the MRB or MBS session, flow proceeds to block 1108. If the CU requests PTM transmission for the MRB or MBS session, flow proceeds to block 1109 instead.

[0133] 11C shows an example method 1100C that is similar to method 1100A except that method 1100C includes block 1105 instead of block 1106. In block 1105, the CU determines whether to request unicast transmission for the MRB or MBS session or instead request multicast transmission (e.g., events 504, 591). If the CU requests PTP transmission for the MRB or MBS session, flow proceeds to block 1108. If the CU requests PTM transmission for the MRB or MBS session, flow proceeds instead to block 1109.

[0134] Referring now to FIG. 12A, a CU, such as CU 172, may implement an example method 1200A to determine an RLC mode for an MRB.

[0135] Method 1200A begins at block 1202, where the CU determines to configure an RB (e.g., events 504, 591). In block 1204, the CU includes the RB ID of the RB in a CU-DU message (e.g., events 506, 514, 593). In block 1206, the CU determines whether the RB is an MRB or a DRB. If the RB is a DRB, flow proceeds to block 1208. In block 1208, the CU sets the RLC mode IE to a value indicating RLC AM and includes the RLC mode IE in a CU-DU message (e.g., events 506, 514, 593). If the RB is an MRB, flow proceeds to block 1209. In block 1209, the CU sets the RLC mode IE to a value indicating RLC UM and includes the RLC mode IE in a CU-DU message (e.g., events 506, 514, 593). Flow proceeds from block 1208 and from block 1209 to block 1210. In block 1210, the CU performs the actions described above for blocks 910, 912, 914, and 916.

[0136] 12B shows an example method 1200B that is similar to method 1200A except that method 1200B includes block 1207 instead of block 1206. In block 1207, the CU determines whether the RB is an MRB or is configured for IMS voice or video services or not (e.g., events 504, 591). If the RB is an MRB or is configured for IMS voice or video services, flow proceeds to block 1208. Otherwise, flow proceeds instead to block 1209. The IMS voice service may be an IMS voice call or an IMS emergency call.

[0137] In some implementations, if the RB is an MRB, the CU may include a unidirectional indication in a CU-DU message to indicate that the RB is a DL-only RB (i.e., a unidirectional DL RB). In response to the unidirectional indication, the DU may include RLC parameters (e.g., a um-Uni-Directional-DL field) in the configuration parameters in a DU-CU message for the RB. If the RB is configured for IMS voice or video services, the CU does not include the unidirectional indication.

[0138] Referring now to FIG. 13, a RAN node, such as a DU 174 or a base station 104, may implement an example method 1300 to determine RLC parameters for an RB (ie, an MRB or a DRB).

[0139] In block 1302, the RAN node decides to configure resources for an MRB (e.g., events 506, 514, 593). In block 1304, the RAN node determines whether the RB is an MRB or a DRB. If the RB is an MRB, the flow proceeds to block 1306. In block 1306, the RAN node includes first RLC parameters in the configuration for the RB (e.g., an RLC configuration such as an RLC-BearerConfig IE). If the RB is a DRB, the flow proceeds instead to block 1308. In block 1308, the RAN node determines whether the DRB is for an IMS voice or video service or not. If the DRB is for an IMS voice or video service, the flow proceeds to block 1310. In block 1310, the RAN node includes second RLC parameters in the configuration for the RB. If the DRB is not for an IMS voice or video service, the flow proceeds instead to block 1312. In block 1312, the RAN node includes the third RLC parameter in a configuration for the RB. Flow proceeds from each of blocks 1306, 1310, and 1312 to block 1314. In block 1314, the RAN node sends the configuration to the CU or UE (e.g., events 508, 516, 520, 593). If the RAN node is a DU (e.g., DU 174), the DU may, in some implementations, send a DU-to-CU message including the configuration to the CU. If the RAN node is a base station (e.g., base station 104), the base station may, in some implementations, send a DL message (e.g., an RRC reconfiguration message) including the configuration to the UE.

[0140] In some implementations, the first RLC parameter, the second RLC parameter, and the third RLC parameter may be a um-Uni-Directional-DL field, a um-Bi-Directional field, and an am field, respectively. In some implementations, the DU may indicate a first RLC sequence number size, a second RLC sequence number size, and a third RLC sequence number size in the first RLC parameter, the second RLC parameter, and the third RLC parameter, respectively. At least two (e.g., all) of the first, second, and third RLC sequence number sizes may be the same or different.

[0141] Referring now to FIG. 14, a DU, such as the DU 174, may implement / perform an example method 1400 to determine RLC parameters for an RB (ie, an MRB or a DRB).

[0142] In block 1402, the DU receives a CU-DU message indicating RLC UM for the RB from the CU (e.g., events 506, 514, 593). In block 1404, the DU determines whether the RB is an MRB or a DRB. If the RB is an MRB, flow proceeds to block 1406. In block 1406, the DU includes first RLC parameters in a configuration for the RB (e.g., an RLC configuration such as an RLC-BearerConfig IE). If the RB is a DRB, flow proceeds instead to block 1408. In block 1408, the DU includes second RLC parameters in a configuration for the RB. Flow proceeds from block 1406 and from block 1408 to block 1410. In block 1410, the DU sends a DU-CU message including the configuration to the CU (e.g., events 508, 516, 593).

[0143] In some implementations, the first and second RLC parameters may be a um-Uni-Directional-DL field and a um-Bi-Directional field, respectively. In some implementations, the DU may indicate a first and second RLC sequence number size in the first and second RLC parameters, respectively. The first and second sequence number sizes may be the same or different.

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

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

[0146] A user device (e.g., UE 102A, 102B, or 103) in 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 monitoring 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 embedded in an electronic system such as a head unit of a vehicle 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.

[0147] Certain 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 specific operations and may be configured or arranged in a particular way. A hardware module may comprise dedicated circuitry or logic that is permanently configured to perform specific operations (e.g., as a dedicated processor such as a field programmable gate array (FPGA) or application-specific integrated circuit (ASIC)). A hardware module may also comprise programmable logic or circuitry (e.g., as contained within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform specific operations. The decision to implement a hardware module in dedicated, permanently configured circuitry or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

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

[0149] After reading this disclosure, those skilled in the art will appreciate still further alternative structural and functional designs for communicating MBS information through the principles disclosed herein. Accordingly, while specific embodiments and applications have been illustrated and described, it should be understood that the disclosed embodiments are not limited to the precise configuration and components disclosed herein. Various modifications, changes, and variations that will be apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope, as defined in the appended claims. [Explanation of symbols]

[0150] 100 Wireless Communication System 102, 102A, 102B UE 103UE 104 Base station, MeNB, Mng-eNB, MgNB 105 RAN 106 Base station, SgNB, Sng-eNB 110CN 111 Evolved Packet Core (EPC), EPC 112 Serving Gateway (SGW), SGW 114 Mobility Management Entity (MME), MME 116 Packet Data Network Gateway (PGW), PGW 124 cells 126 cells 130 Processing Hardware 132 MBS Controller, Controller 134 Non-MBS Controller, Controller 140 Processing Hardware 142 MBS Controller 144 Non-MBS Controller 150 Processing Hardware 152 MBS Controller 154 Non-MBS Controller 160 5th Generation Core (5GC), 5GC 162 User Plane Function (UPF), UPF 164 Access and Mobility Management (AMF), AMF 166 Session Management Facility (SMF), SMF 172 CU 172A CU-CP 172B CU-UP 174 DU 200 Protocol Stack 202 PHY Sublayer 202A PHY Sublayer 202B NR PHY, PHY layer 204 MAC Sublayer 204A EUTRA MAC Sublayer 204B NR MAC sublayer, NR MAC, MAC layer 206 RLC Sublayer 206A EUTRA RLC sublayer, EUTRA RLC, RLC layer 206B NR RLC sublayer, NR RLC, RLC layer 208 EUTRA PDCP sublayer, PDCP sublayer, PDCP layer 210 NR PDCP sublayer, NR PDCP, PDCP layer 212 SDAP Sublayer, SDAP 214 RRC 250 Protocol Stack 300 Architecture 302A, 302B MBS Sessions 304A PDU Session 312A and 312B Tunnels 314A-1, 314A-2, 314A-N Radio Bearers 314A MRB 314B, 314B-1, 314B-2, 314B-N MRB Set of 316 flows 316A, 316B, 316L QoS Flows 322A UE-specific DL tunnel and / or UE-specific UL tunnel 324A-1, 324A-2, 324A-N DRB 402, 402A, 402B MRB 404, 404A, 404B DRB 412A DL Tunnel, Tunnel 412B DL ​​Tunnel 413A UL Tunnel, Tunnel 413B UL Tunnel 422A, 422B DL ​​logical channels 423A, 423B UL logical channels 432A UE-specific DL tunnel, DL tunnel 432B UE-specific DL tunnel 433A UE specific UL tunnel, UL tunnel 433B UE-specific UL tunnel 442A, 442B DL ​​logical channels 443A, 443B UL logical channels 500A Scenario 500B Scenario 502 (First) MBS Session Join Procedure, Procedure, MBS Session Join Procedure 504 Events 506 Events 508 Events 510 Events 512 Second CN-BS Message, Event 514 Events 516 Events 518 Events 519 Events 520 Events 522 Events 523 Events 524 Events 526 Events 528 Events 530 MBS Session Participation Procedures, Events 590 Procedure, MBS Resource Setup Procedure 591 MBS Session Resource Setup Procedures, Events 592 Procedures 593 UE-specific MBS session configuration procedures, procedures and events 594 MBS resource setup and UE-specific MBS session configuration procedures 600A, 600B method 700 methods 800 ways 900A, 900B method 1000 ways 1100A, 1100B, 1100C Method 1200A, 1200B method 1300 methods 1400 methods

Claims

1. A method for configuring radio bearers for multicast or unicast transmission, performed by a distributed unit (DU) of a distributed base station, comprising: receiving a request to configure radio resources for the radio bearer from a central unit (CU) of the distributed base station; including or refraining from including in the response one or more configuration parameters for the radio bearer based on one or more factors associated with the radio bearer identified in the request; refraining from including the one or more configuration parameters in the response when a first factor of the one or more factors indicates that the radio bearer is a Multicast and / or Broadcast Service (MBS) Radio Bearer (MRB); and when the first factor indicates that the radio bearer is not an MRB, including the one or more configuration parameters in the response. and sending the response to the CU; A method comprising:

2. A method for configuring radio bearers for multicast or unicast transmission, performed by a distributed unit (DU) of a distributed base station, comprising: receiving a request to configure radio resources for the radio bearer from a central unit (CU) of the distributed base station; including or refraining from including in the response one or more configuration parameters for the radio bearer based on one or more factors associated with the radio bearer identified in the request; when a first factor of the one or more factors indicates that the radio bearer is a Multicast and / or Broadcast Service (MBS) Radio Bearer (MRB), including the one or more configuration parameters in the response, wherein the configuration parameters include a second CellGroupConfig IE or a second RLC-BearerConfig IE; and when the first factor indicates that the radio bearer is not an MRB, including in the response one or more other configuration parameters different from the one or more configuration parameters, wherein the configuration parameters include a first CellGroupConfig IE or a first RLC-BearerConfig IE; and sending the response to the CU; Including, method.

3. The method described in claim 2, wherein the one or more configuration parameters include a cell group configuration and / or a radio link control (RLC) bearer configuration.

4. 4. The method of claim 1, wherein the one or more configuration parameters for the radio bearer include one or more configuration parameters for an uplink for the radio bearer.

5. A method according to claim 1, further comprising the step of including a logical channel identifier for the radio bearer in the response.

6. including the logical channel identifier in the response, When the first factor indicates that the radio bearer is an MRB, including a first logical channel identifier in the response; when the first factor indicates that the radio bearer is not an MRB, including a second logical channel identifier in the response, the second logical channel identifier being different from the first logical channel identifier; 6. The method of claim 5, comprising:

7. including the logical channel identifier in the response, including the same logical channel identifier in the response regardless of whether the radio bearer is a radio bearer or not.

6. The method of claim 5, comprising:

8. The method of claim 7, wherein when a first factor of the one or more factors indicates that the radio bearer is a multicast and / or broadcast service (MBS) radio bearer (MRB), including first radio link control (RLC) parameters in the response; when the first cause indicates that the radio bearer is not an MRB, including second RLC parameters in the response that are different from the first RLC parameters; 4. The method according to claim 1, comprising:

9. including the second RLC parameters in the response when the first cause indicates that the radio bearer is a data radio bearer (DRB).

9. The method of claim 8, comprising:

10. the one or more configuration parameters: Logical channel configuration, uplink configuration parameters for the Medium Access Control (MAC) layer; logical channel groups, Subcarrier spacing list, a scheduling request identifier, timer value, Physical Priority Index, Channel access priority, and Bitrate Multiplier 4. The method of claim 1, comprising one or more of:

11. A Distributed Unit (DU) of a distributed base station, the DU being configured to implement the method according to any one of claims 1 to 3.

Images