CONFIGURING RESOURCES FOR MULTICAST AND / OR BROADCAST SERVICES IN A DISTRIBUTED BASE STATION ARCHITECTURE - Patent application

Abstract

A DU of a distributed base station, including a central unit (CU) and a distributed unit (DU), can implement a method for configuring a user equipment (UE) to receive a multicast and / or broadcast service (MBS). The method can include receiving 1002 a CU-to-DU message from the CU identifying an MBS session and requesting that the DU configure resources for the MBS session, and transmitting 1004 configuration parameters for receiving the MBS session to the UE in response to receiving the CU-to-DU message.

Description

[Technical field]

[0001] The present disclosure relates to wireless communications, and more particularly to enabling broadcast communications for multicast and / or broadcast services (MBS) in a distributed or disaggregated base station architecture. [Background technology]

[0002] The background description provided herein is for the purpose of generally presenting the context of the present disclosure. To the extent described in this Background section, the work of the currently named inventors, and aspects of the description that may not qualify as prior art at the time of filing, are not admitted, expressly or impliedly, as prior art to the present disclosure.

[0003] In telecommunication 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 ordering 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 provides services for data radio bearers (DRBs) to the Service Data Adaptation Protocol (SDAP) sublayer or protocol layers such as the Internet Protocol (IP) layer, the Ethernet protocol layer, and the Internet Control Message Protocol (ICMP) layer. Generally speaking, a UE and a base station can exchange RRC messages and non-access stratum (NAS) messages using SRBs, and can transmit data in the user plane using DRBs.

[0004] In some scenarios, a UE can simultaneously utilize resources of multiple nodes (e.g., base stations or components of distributed or disaggregated base stations) of a radio access network (RAN) interconnected by a backhaul in a so-called dual connectivity (DC) operation. These network nodes may all be nodes using the same radio access technology (RAT) or may include nodes using different RATs. Exemplary DC configurations include NR-only dual connectivity (NR-DC) and EUTRA and NR dual connectivity (EN-DC). When a UE operates in DC, the cell(s) associated with the base station acting as a master node (MN) define a master cell group (MCG), and the cells associated with the base station acting as a secondary node (SN) define a secondary cell group (SCG). The MCG covers a primary cell (PCell) and zero, one, or multiple secondary cells (SCells), and the SCG covers a primary secondary cell (PSCell) and zero, one, or multiple SCells. The UE communicates with the MN (via the MCG) and with the SN (via the SCG). In other scenarios, the UE is in a single connection (SC) and utilizes the resources of one base station at a time. A UE in a 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 the resources of another RAN node (e.g., a base station or a component of a distributed or disaggregated base station) interconnected by a backhaul.

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

[0006] The UE can perform handover procedures to switch from one cell to another, regardless of whether it is 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 first distributed unit (DU) of a serving base station to a target cell of a second DU of the same base station, depending on the scenario. In a DC scenario, the UE can perform a PSCell change procedure 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 a handover or a PSCell change within a cell for synchronous reconfiguration.

[0007] Base stations operating in accordance with the fifth generation (5G) new radio (NR) requirements support significantly larger bandwidths than fourth generation (4G) base stations. Thus, the 3rd Generation Partnership Project (3GPP) proposes for Release 15 that user equipment units (UEs) support 100 MHz bandwidth in Frequency Range 1 (FR1) and 400 MHz bandwidth in Frequency Range (FR2). Due to the relatively large bandwidth of a typical carrier in 5G NR, 3GPP proposes for Release 17 that 5G NR base stations can provide multicast and / or broadcast service(s) (MBS) to UEs. MBS can be useful in many content distribution applications, such as transparent IPv4 / IPv6 multicast distribution, IPTV, over-the-air software distribution, group communication, 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 the transmission of 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 not clear how a distributed base station configures resources to transmit MBS data packets via broadcast. Summary of the Invention

[0009] A network node acting as a central unit (CU) or a distributed unit (DU) of a distributed base station can implement the techniques of this disclosure to configure resources for a multicast and / or broadcast service (MBS). The CU can, for example, receive a message from a core network (CN) requesting that a distributed base station set up resources for an MBS session. In response, the CU can send a CU-to-DU message (e.g., an MBS context setup request message) to the DU that identifies the MBS session (e.g., using a session identifier (ID) corresponding to the session) and requests that the DU configure resources for the MBS session. The DU can then send an MBS broadcast configuration message to the UE (or, more specifically, broadcast the MBS broadcast configuration message to one or more UEs) that includes a list of one or more MBS sessions and MBS session information for each respective MBS session. The MBS session information for the MBS session includes configuration parameters that enable the UE to receive MBS data for the MBS session, such as a Packet Data Convergence Protocol (PDCP) configuration, a Radio Link Control (RLC) configuration, a Discontinuous Reception (DRX) configuration, a Group Radio Network Temporary Identifier (G-RNTI) associated with the MBS session, and / or a Session ID for the MBS session.

[0010] Depending on the embodiment, the CU or the DU may generate the MBS broadcast configuration message or the MBS session information. In some embodiments, the DU generates the MBS session information and the MBS broadcast configuration message. The DU may receive configurations associated with layers operated by the CU from the CU and include these configurations in the MBS session information. For example, the DU receives a PDCP configuration or a DRX configuration from the CU. The DU may then generate information, such as G-RNTI and RLC configuration, at layers operated by the DU and include such information in the MBS session information.

[0011] In other embodiments, the CU may generate the MBS session information and may or may not generate the MBS broadcast configuration message. In such embodiments, the CU may receive an RLC configuration and G-RNTI for the MBS session from the DU, and may include the RLC configuration and MBS session information in the MBS session information along with configurations generated by the CU, such as PDCP configuration and DRX configuration. In some scenarios, the CU sends the MBS session information to the DU to enable the DU to generate and send the MBS broadcast configuration message to the UE. Alternatively, the CU may generate an MBS broadcast configuration message including the MBS session information and send the MBS broadcast configuration message to the DU for forwarding to the UE.

[0012] As mentioned above, the MBS broadcast configuration message may include MBS session information for multiple MBS sessions. To request resources for the second MBS session, the CU can send a second CU-to-DU message to the DU identifying the second MBS session, or the CU can send a single CU-to-DU message identifying both the first and second MBS sessions. The DU can then send MBS broadcast configuration information including both the first and second MBS session information for the first and second MBS sessions, respectively. If the CU decides to suspend or release resources for the first MBS session (e.g., in response to a request from the CN), the CU sends a request to the DU. In response, the DU can stop sending the first MBS session information and instead send an MBS broadcast configuration message that excludes the first MBS session information and includes the second MBS session information. The CU may also request that the DU modify information for the MBS session, in which case the DU may update the MBS session information for the MBS session accordingly and send an MBS Broadcast Configuration message including the updated MBS session information.

[0013] One exemplary embodiment of these techniques is a method for configuring a UE to receive MBS, implemented in a DU of a distributed base station including a CU and a DU. The method may be executed by processing hardware and includes receiving a CU-to-DU message from a CU identifying an MBS session and requesting that the DU configure resources for the MBS session, and sending configuration parameters for receiving the MBS session to the UE in response to receiving the CU-to-DU message.

[0014] Another exemplary embodiment of these techniques is a method implemented in a CU of a distributed base station including a CU and a DU for configuring a UE to receive MBS. The method may be performed by processing hardware and includes receiving a CN-to-BS message from a core network (CN) requesting that the distributed base station configure resources for an MBS session, and sending a CU-to-DU message to the DU identifying the MBS session to cause the DU to send configuration parameters for receiving the MBS session to the UE.

[0015] Yet another exemplary embodiment of these techniques is a network node including processing hardware and configured to implement any one of the above methods. [Brief description of the drawings]

[0016] [Figure 1A] FIG. 1 is a block diagram of an example system capable of implementing techniques of the present disclosure for managing resources of an MBS. [Figure 1B] FIG. 1B is a block diagram of an exemplary base station in which a central unit (CU) and a distributed unit (DU) can operate in the system of FIG. 1A. [Figure 2A] 1B is a block diagram of an example protocol stack by which the UE of FIG. 1A can communicate with the base station of FIG. 1A. [Figure 2B]FIG. 1B is a block diagram of an example protocol stack by which the UE of FIG. 1A can communicate with the DU and CU of the base station. [Diagram 3] FIG. 1 is a block diagram illustrating an example tunnel architecture for MBS and PDU sessions. [Figure 4] A block diagram illustrating example MRBs and DRBs that a distributed base station can configure to communicate multicast, broadcast, and / or unicast traffic with UEs. [Figure 5A] FIG. 1 is a messaging diagram of an example scenario in which a CN and a distributed base station configure resources for transmitting MBS data of an MBS session to multiple UEs via broadcast, in which the DU generates MBS session information using a Packet Data Convergence Protocol (PDCP) configuration received from the CU in an MBS Context Setup Request message and broadcasts the MBS session information in an MBS Broadcast Configuration message. [Figure 5B] FIG. 5B is a messaging diagram of an example scenario similar to that of FIG. 5A, but in which the DU receives a PDCP configuration in a CU-to-DU message after receiving an MBS context setup request message. [Figure 5C] FIG. 5B is a messaging diagram of an example scenario similar to that of FIG. 5A, but in which the CU generates MBS session information using a radio link control (RLC) configuration received from the DU in the MBS context setup response message and transmits the MBS session information to the DU. [Figure 5D] FIG. 5C is a messaging diagram of an example scenario similar to that of FIG. 5C, but in which the CU receives an RLC configuration in a DU-to-CU message after receiving an MBS context setup response message. [Figure 5E] FIG. 5B is a messaging diagram of an example scenario similar to that of FIG. 5A, but in which the DU generates MBS session information without receiving a PDCP configuration from the CU. [Figure 5F]FIG. 5B is a messaging diagram of an example scenario in which a distributed base station subsequently releases resources for an MBS session, which may be similar to any one of the scenarios shown in FIGS. 5A-5E. [Figure 5G] FIG. 5B is a messaging diagram of an example scenario in which a distributed base station also suspends and later resumes resources for an MBS session, which may be similar to any one of the scenarios shown in FIGS. 5A-5E. [Figure 5H] FIG. 5B is a messaging diagram of an example scenario in which a distributed base station also configures resources for transmitting MBS data of another MBS session via broadcast and later releases resources for the initial MBS session, which may be similar to any one of the scenarios shown in FIGS. 5A to 5E. [Figure 5I] FIG. 5B is a messaging diagram of an example scenario in which a distributed base station subsequently modifies resources for an MBS session, which may be similar to any one of the scenarios shown in FIGS. 5A-5E. [Figure 6A] FIG. 1 is a flow diagram of an exemplary method for configuring resources for one or more MBS sessions that may be implemented in a DU, where the DU receives a session identifier (ID) for each of the one or more MBS sessions in a respective CU-to-DU message. [Figure 6B] FIG. 6B is a flow diagram of an example method similar to that of FIG. 6A, but in which a DU receives a session ID for each of one or more MBS sessions in a single CU-to-DU message. [Figure 7A] FIG. 1 is a flow diagram of an example method for configuring resources for one or more MBS sessions that may be implemented in a CU, where the CU sends a session identifier (ID) for each of the one or more MBS sessions in a respective CU-to-DU message. [Figure 7B] FIG. 7B is a flow diagram of an example method similar to that of FIG. 7A, but in which the CU sends a session ID for each of one or more MBS sessions in a single CU-to-DU message. [Figure 8A]1 is a flow diagram of an example method for suspending or releasing resources for an MBS session that may be implemented in a DU. [Figure 8B] 1 is a flow diagram of an example method for modifying resources for an MBS session that may be implemented in a DU. [Figure 9A] 1 is a flow diagram of an example method for suspending or releasing resources for an MBS session that may be implemented in a CU. [Figure 9B] 1 is a flow diagram of an example method for modifying resources for an MBS session that may be implemented in a CU. [Figure 10] 1 is a flow diagram of an example method for configuring resources for an MBS that can be implemented in a DU. [Figure 11] 1 is a flow diagram of an example method for configuring resources for an MBS session that may be implemented in a CU. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] Generally speaking, the RAN and / or CN implement the techniques of this disclosure to manage transmission of multicast and / or broadcast services (MBS). The CN can request that a base station configure a common downlink (DL) tunnel over which the CN can transmit MBS data for an MBS session for multiple 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)).

[0018] 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, and there may be a one-to-one mapping between each logical channel and each MRB. After receiving the MBS data for the MBS session via the common DL tunnel, the base station may transmit the MBS data to one or more UEs participating in the MBS session via one or more logical channels. In some embodiments, the base station transmits the MBS data to multiple UEs via a single logical channel. Furthermore, when 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.

[0019] The CN can have the base station configure a common DL tunnel before or after the UE joins the MBS session. 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 to the base station for multiple UEs.

[0020] 1A illustrates an example wireless communication system 100 in which techniques of the present disclosure for managing transmission and reception of multicast and / or broadcast service (MBS) information can be implemented. The wireless communication system 100 includes user equipment (UE) 102A, 102B, 103, and base stations 104, 106 of a radio access network (RAN) 105 connected to a core network (CN) 110. For ease of reading, UE 102 is used herein to represent UE 102A, UE 102B, or both UE 102A and UE 102B, unless otherwise noted. 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 illustrated in FIG. 1A. The base stations 104, 106 may be any suitable type of base station, 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.

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

[0022] In non-MBS (unicast) operation, the UE 102A may use radio bearers (e.g., DRB or SRB) that terminate at the MN (e.g., base station 104) or at the 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., DRB or SRB) 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 a radio bearer on (i.e., within) the uplink (UL) bandwidth portion (BWP) of the cell and / or receives data from a base station via a radio bearer on the downlink (DL) BWP of the cell. The UL BWP may be an initial UL BWP or a dedicated UL BWP, and the DL BWP may be an initial DL BWP or a dedicated DL BWP. The UE 102A may receive paging, system information, public alert message(s), or random access response on the DL BWP. In this non-MBS operation, the UE 102A may be in a connected state. Alternatively, if the UE 102A supports small data transmission in the idle or inactive state, the UE 102A may be in an idle or inactive state.

[0023] In MBS operation, the UE 102A can use an MBS Radio Bearer (MRB) that terminates at the MN (e.g., base station 104) or at the SN (e.g., base station 106) at different times. For example, after handover or SN change, the UE 102A can use an MRB that terminates at the base station 106 that can operate as an MN or an SN. In some scenarios, the base station (e.g., MN or SN) can transmit MBS data to the UE 102A via 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) can transmit MBS data via multicast radio resources (i.e., radio resources common to the UE 102A and one or more other UEs) or can transmit a DL BWP of a cell from the base station to the UE 102A via the MRB. The DL BWP can be an initial DL BWP, a dedicated DL BWP, or an MBS DL BWP (i.e., a DL BWP specific to the MBS or a DL BWP not for unicast).

[0024] The base station 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., central processing units (CPUs)), computer-readable memory storing machine-readable instructions executable by the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 130 of the exemplary embodiment 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 a MN or SN during non-MBS operation.

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

[0026] The UE 102A includes processing hardware 150, which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory storing machine-readable instructions executable by the general-purpose processor(s), and / or special-purpose processing units. The processing hardware 150 of the exemplary embodiment of FIG. 1A includes an MBS controller 152 configured to manage or control the reception of MBS information. For example, the UE MBS controller 152 may be configured to support 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 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 embodiments described below when the UE 102A communicates with the MN and / or SN during non-MBS operation. Although not shown in FIG. 1A, the UE 102B and UE 103 may include processing hardware similar to the processing hardware 150 of the UE 102A.

[0027] The CN 110 may be an evolved packet core (EPC) 111 or a fifth generation core (5GC) 160, both of which are shown in FIG. 1A. The base station 104 may be an eNB supporting an S1 interface for communicating with the EPC 111, an ng-eNB supporting an NG interface for communicating with the 5GC 160, or a gNB supporting an NR radio interface and an NG interface for communicating with the 5GC 160. The base station 106 may be an 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 radio interface and an NG interface to the 5GC 160, or an ng-eNB supporting an EUTRA radio interface and an NG interface to the 5GC 160. To directly exchange messages with each other during the scenarios described below, the base stations 104 and 106 may support an X2 interface or an Xn interface.

[0028] 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, such as an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 160 includes a User Plane Function (UPF) 162, an Access and Mobility Management Function (AMF) 164, and / or a Session Management Function (SMF) 166. The UPF 162 is generally configured to forward user plane packets related to 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.

[0029] The UPF 162, AMF 164, and / or SMF 166 can be configured to support MBS. For example, the SMF 166 can be configured to manage or control MBS transport, configure the UPF 162 and / or the RAN 105 for MBS flows, and / or manage or set up one or more MBS or PDU sessions for the 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 SMF 166 can be configured for both non-MBS unicast services and MBS, or for only MBS, as indicated by the prefix "(MB-)" shown in FIG. 1A.

[0030] 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. The following examples refer specifically to particular CN types (EPC, 5GC) and radio access technology (RAT) types (5G NR and EUTRA), but 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 network or 5G NR-6G DC.

[0031] 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 stations 104 and 106 via the same RAT, such as EUTRA or NR, or via different RATs.

[0032] When the base station 104 is an MeNB and the base station 106 is an SgNB, the UE 102A may be an 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 may be a 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 may be an 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 SgNB, the UE 102A may be an NR-EUTRA DC (NE-DC) with the MgNB 104 and the Sng-eNB 106.

[0033] FIG. 1B illustrates an exemplary distributed implementation of any one or more of the base stations 104, 106. In this implementation, the base station 104, 106 includes a central unit (CU) 172 and one or more distributed units (DUs) 174. In an implementation in which the base station 104, 106 includes multiple DUs, the terms DUs 174A and 174B may be used to refer to a first DU and a second DU of the multiple DUs, respectively. 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 processor(s), 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.

[0034] Each of the DUs 174 also includes processing hardware that 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 a MN or SN. The processing hardware may also include a PHY layer controller configured to manage or control one or more PHY layer operations or procedures.

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

[0036] The CU-CP(s) 172A can connect to multiple CU-UP(s) 172B via an E1 interface. The CU-CP(s) 172A selects the appropriate CU-UP(s) 172B for the service requested for the UE 102A. In some embodiments, a single CU-UP 172B can connect to multiple CU-CPs 172A via an E1 interface. The CU-CP 172A can connect to one or more DUs 174 via an F1-C interface. The CU-UP 172B can connect to one or more DUs 174 via an F1-U interface under the control of the same CU-CP 172A. In some embodiments, one DU 174 can connect to multiple CU-UPs 172B under the control of the same CU-CP 172A. In such embodiments, the connectivity between the CU-UP 172B and the DU 174 is established by the CU-CP 172A using a bearer context management function.

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

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

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

[0040] In a scenario where the UE operates in an EN-DC where the base station 104 acts as an MeNB and the base station 106 acts as an SgNB, the wireless communication system 100 can 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 can also provide the UE with an SN terminated bearer using only the NR PDCP sublayer 210 in various scenarios. 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.

[0041] In some implementations, a base station (e.g., base station 104, 106) broadcasts MBS data packets over one or more MBS radio bearers (MRB(s)), and the UE then receives the MBS data packets over the MRB(s). The base station may include configuration(s) for the MRB(s) in multicast configuration parameters (which may also be referred to as MBS configuration parameters), described below. In some implementations, the base station broadcasts the MBS data packets over the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and in response, the UE 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 or may not use the PDCP sublayer 208 and the SDAP sublayer 212 to communicate the MBS data packets. In other embodiments, the base station transmits the MBS data packets via the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and in response, the UE 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 embodiments, the base station and the UE may or may not use the SDAP sublayer 212 to communicate the MBS data packets. In yet other embodiments, the base station transmits the 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 in response, the UE 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.

[0042] FIG. 2B illustrates a simplified example protocol stack 250 by which a UE 102 or UE 103 may communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally divided by the radio protocol stack 250 of FIG. 2B as shown. The CU in either the base station 104 or 106 may retain all control and higher layer functions (e.g., RRC 214, SDAP 212, NR PDCP 210), while lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support a connection to 5GC, the NR PDCP 210 provides an SRB to the RRC 214, which provides a DRB to the SDAP 212, which provides an SRB to the RRC 214.

[0043] 3, the MBS session 302A may include a tunnel 312A with endpoints at the CN 110 and the base station 104 / 106. The MBS session 302A may correspond to a particular session ID, such as, for example, a Temporary Mobile Group Identification (TMGI). The MBS data may include, for example, IP packets, TCP / IP packets, UDP / IP packets, Real-time Transport Protocol (RTP) / UDP / IP packets, or RTP / TCP / IP packets.

[0044] In some cases, the CN 110 and / or the 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 the base station 104 / 106 use the tunnel 312A for downlink and uplink (UL) MBS traffic to support, for example, a command or service request from a UE. Furthermore, because the base station 104 / 106 can direct MBS traffic arriving via the tunnel 312A to multiple UEs, the tunnel 312A may be referred to as a common tunnel or a common DL tunnel.

[0045] The tunnel 312A may operate at a transport layer or sub-layer, such as, for example, a User Datagram Protocol (UDP) protocol layered on the Internet Protocol (IP). As a more specific example, the tunnel 312A may be associated with a 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 address in the header(s) of the tunnel packet including the MBS data packet and transmit the tunnel packet downstream to the base station 104 / 106 via the tunnel 312A. The header(s) may include the IP address and / or the TEID. For example, the header(s) may include an IP header and a GTP header including the IP address and the TEID, respectively. Thus, base stations 104 / 106 can use the IP address and / or TEID to identify data packets traveling through tunnel 312A.

[0046] As shown in FIG. 3, the base station 104 / 106 maps the 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 or NR MAC sublayer provides logical channels to the EUTRA 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 the MRBs 314B-1, 314B-2, ... 314B-N, where N > 1. Each of the MRBs 314B may correspond to a respective logical channel.

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

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

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

[0050] Now referring to FIG. 4, when the base station 104 / 106 is implemented in a distributed manner, one or more DUs 174A / 174B can be associated with the CU 172. The CU 172 and the DU(s) 174A / 174B can establish tunnels for downlink and / or uplink data associated with the MRB or DRB. The MRB 314A-1 described above can be implemented as an MRB 402A that connects the CU 172 to multiple UEs, such as UEs 102A and 102B. The MRB 402A can include a DL tunnel 412A that connects the CU 172 and the DU(s) 174A / 174B, and a DL logical channel 422A that corresponds to the DL tunnel 412A. In particular, the DU(s) 174A / 174B can map downlink traffic received via the DL tunnel 412A to the DL logical channel 422A, which can be, for example, an MTCH or a DTCH. The DL tunnel 412A may be a common DL tunnel, and the CU 172 transmits the MBS data packets to multiple UEs through the common DL tunnel. Alternatively, the DL tunnel 412A may be a UE-specific DL tunnel, and the CU 172 transmits the MBS data packets to a particular UE through the UE-specific DL tunnel.

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

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

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

[0054] The CU 172 uses the DRB 404A in some cases to transmit MBS data packets or unicast data associated with a PDU session to a particular UE (e.g., UE 102A or UE 102B). The DRB 404A may include a UE-specific DL tunnel 432A connecting the CU 172 and the DU(s) 174A / 174B, and a DL logical channel 442A corresponding to the DL tunnel 432A. In particular, the DU(s) 174A / 174B may 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 may include a UE-specific UL tunnel 433A connecting the CU 172 and the DU(s) 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(s) 174A / 174B can map uplink traffic received via the UL logical channel 443A to the UL tunnel 433A.

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

[0056] In some embodiments, the DU (e.g., DU 174A / 174B) assigns a specific logical channel ID (value) to each of the logical channel(s) associated with MRB(s) associated with the same or different MBS sessions. In other embodiments, the DU assigns the same logical channel ID (value) to each of the logical channel(s) associated with MRB(s) associated with different MBS sessions. In some embodiments, the DU assigns a specific logical channel ID (value) to each of the logical channel(s) associated with DRB(s). In some embodiments, the DU sets the logical channel IDs associated with the MRB(s) and DRB(s) respectively to different values. In other embodiments, the DU sets the logical channel IDs associated with the MRB(s) and DRB(s) respectively to the same value.

[0057] Several example scenarios in which a base station 104, including a CU 172 and a DU 174, configures resources for transmitting MBS data of an MBS session (i.e., a broadcast MBS session) will now be described with reference to Figures 5A-5I. Generally speaking, similar events in Figures 5A-5I are labeled with the same reference numbers, and differences are described below as necessary.

[0058] 5A, in a scenario 500A, the DU 174 generates MBS session information using a PDCP configuration received from the CU 172. In the scenario 500A, the base station 104 broadcasts a particular MBS session (i.e., a first MBS session identified by a first MBS session ID). First, the CN 110 may send (502) an MBS session resource setup request message to the CU 172, including the first MBS session ID, to request the CU 172 to configure resources for the first MBS session. In some implementations, the CN 110 excludes the PDU session ID from the MBS session resource setup request message. In response, the CU 172 may send (504) an MBS context setup request message to the DU 174 to request the setup of an MBS context and / or a common DL tunnel for the first MBS session. In the MBS context setup request message, CU 172 includes a first session ID and a first PDCP configuration(s) for the first MBS session. CU 172 generates the first PDCP configuration(s) for transmitting MBS data of the first MBS session. Later, CU 172 transmits the MBS data of the first MBS session according to the first PDCP configuration(s), as described for event 522. In some implementations, each of the first PDCP configuration(s) includes at least one of a PDCP sequence number size (e.g., 12 bits) and a header compression configuration. The header compression configuration can configure one or more header compression profiles or configure no header compression.

[0059] In some embodiments, the CU 172 may include a first discontinuous reception (DRX) cycle configuration for the first MBS session in the MBS context setup request message. The first DRX cycle configuration includes or configures a first DRX cycle length. In some embodiments, the CU 172 may determine the first DRX cycle length according to the QoS configuration(s). In other embodiments, the CU 172 may receive the first DRX cycle length in the MBS session resource setup request message (502). In some embodiments, the CU 172 excludes a PDU session ID from the MBS context setup request message.

[0060] In some embodiments, the CU 172 may further include first MBS neighbor cell information in the MBS context setup request message. The first MBS neighbor cell information indicates one or more neighbor cells that provide the first MBS session. Alternatively, the DU 174 may receive the first MBS neighbor cell information from an operation, administration, and maintenance (OAM) node.

[0061] In response to receiving the MBS context setup request message (504), the DU 174 may send to the CU 172 an MBS context setup response message including a first DU DL transport layer configuration for configuring a first common CU-DU DL tunnel for the first MBS session (506). The CN 110 may further include quality of service (QoS) configuration(s) for the first MBS session in the MBS session resource setup request message. In such a case, the CU 172 may include the QoS configuration(s) in the MBS context setup request message. In some implementations, the MBS context setup request message and the MBS context setup response message may be non-UE specific messages.

[0062] The CU 172 transmits (508) an MBS session resource setup response message to the CN 110 in response to the message of event 504. In some embodiments, the CU 172 can transmit (508) the MBS session resource setup response message after receiving (506) the MBS context setup response message. In other embodiments, the CU 172 can transmit (508) the MBS session resource setup response message before receiving (506) the MBS context setup response message. The CU 172 can include the first MBS session ID in the MBS session resource setup response message. The MBS session resource setup response message can include a first CU DL transport layer configuration for configuring a first common CN-BS DL tunnel for the CN 110 to transmit MBS data of the first MBS session to the CU 172. The first CU DL transport layer configuration includes transport layer information such as a transport layer address (e.g., IP address) and / or a TEID to identify the first common CN-BS DL tunnel.

[0063] In some embodiments, the QoS configuration(s) include QoS parameters for the MBS session. In some embodiments, the QoS configuration(s) include configuration parameters for configuring one or more QoS flows for the MBS session (see FIG. 3). In some embodiments, the configuration parameters include one or more QoS flow IDs that identify the QoS flow(s). Each of the QoS flow ID(s) identifies a particular QoS flow of the QoS flow(s). In some embodiments, 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 amount. The CN 110 may assign different values ​​of the QoS parameters to the QoS flows.

[0064] In some embodiments, the DU 174 may include the first MBS session ID in the MBS context setup response message to indicate that the first MBS session has been successfully established. In some embodiments, the DU 174 may indicate an association between the first MBS session and the first common CU-DU DL tunnel in the MBS context setup response message.

[0065] In some embodiments, the CU 172 may configure one or more MRBs (MRB(s)) for the first MBS session and generate one or more MRB IDs (MRB ID(s)) for each specific MRB of the MRB(s). In such a case, the CU 172 may include the MRB ID(s) in the MBS context setup request message to request the DU 174 to configure resources for the MRB(s). In some embodiments, the CU 172 may associate each of the first PDCP configuration(s) with a specific MRB / MRB ID(s) of the MRB(s) / MRB ID(s) and indicate the association(s) in the MBS context setup request message. In some embodiments, the DU 174 may include the MRB ID(s) in the MBS context setup response message to indicate that resources for the MBB(s) have been successfully established. If the DU 174 does not have enough resources for all of the MRBs, the DU 174 may include a portion of the MRB ID in the MBS context setup response message to indicate that resources for a portion of the MRBs have been successfully established. In the MBS context setup response message, the DU 174 may, in some embodiments, include an additional DU DL transport layer configuration that configures an additional common CU-DU DL tunnel for the first MBS session. The DU 174 may associate each of the common CU-DU DL tunnels, including the first common CU-DU DL tunnel and the additional common CU-DU DL tunnel, with a particular MRB or portion of the MRB and indicate the association in the MBS context setup response message. The additional DU DL transport layer configuration includes transport layer information such as a transport layer address (e.g., IP address) and / or a TEID to identify the additional common CN-DU DL tunnel.

[0066] In response to or after receiving the MBS context setup request message (504), the DU 174 may generate a first MBS broadcast configuration message (e.g., an MBS Broadcast Configuration message) including the first session ID and the first PDCP configuration(s) (512).

[0067] Events 502, 504, 506, 508, and 512 are collectively referred to as MBS resource setup procedure 586A in FIG. 5A.

[0068] Before, during, or after the MBS resource setup procedure 586A, the DU 174 transmits (e.g., broadcasts) (514) system information (e.g., one or more system information blocks (SIBs)) including MBS control information for one or more cells (e.g., the cell 124 operated by the DU 174 and / or other cell(s). In some embodiments, the DU 174 periodically transmits (514) system information for one or more cells. The MBS control information includes configuration parameters for the UE 102 to receive the first MBS broadcast configuration message. In some embodiments, the DU 174 transmits (514) system information for one or more cells including MBS control information for one or more cells (e.g., the cell 124 operated by the DU 174 and / or other cell(s). In some embodiments, the DU 174 transmits (514) system information for one or more cells including MBS control information for one or more cells (e.g., the cell 124 operated by the DU 174 and / or other cell(s)). In some embodiments, the DU 174 transmits (514) system information for one or more cells including MBS control information for one or more cells (e.g., the cell 124 operated by the DU 174). 6A), the CU 172 may transmit (514) (start transmission) system information. In some embodiments, the CU 172 generates system information and transmits a CU-to-DU message including the system information to the DU 174. For example, the CU-to-DU message may be a non-UE-related message (e.g., an F1AP message), such as a gNB-CU configuration update message, a gNB-DU configuration update acknowledgement message, a system information delivery command message, or an F1 setup response message. In other embodiments, the DU 174 generates the system information. In some embodiments, the DU 174 may transmit a DU-to-CU message including the system information to the CU 172.

[0069] After generating the first MBS broadcast configuration message (512), the DU 174 transmits (e.g., broadcasts) the first MBS broadcast configuration message in accordance with the MBS control information (516). In some implementations, the DU 174 can transmit the first MBS broadcast configuration message in accordance with the MBS control information over one or more cells (516).

[0070] In some embodiments, the MBS control information includes an MBS control channel (MCCH) configuration, a common frequency resource (CFR) configuration (e.g., cfr-Config-MCCH-MTCH), a PDSCH configuration for the MCCH (e.g., pdsch-Config-MCCH), a PDSCH configuration for the MTCH (e.g., pdsch-Config-MTCH), a PDCCH configuration for the MCCH (e.g., pdcch-Config-MCCH), and / or a PDCCH configuration for the MTCH (e.g., pdcch-Config-MTCH). The CFR configuration configures the common frequency resources for the UE 102 to receive the MBS (e.g., the first MBS session). If no CFR configuration exists, the UE 102 can receive the MBS via an initial DL BWP. The UE 102 can obtain configuration parameters for the initial DL BWP in SIB1 that the UE 102 receives from the DU 172. The PDSCH configuration for the MCCH configures cell-specific configuration parameters for the UE 102 to receive PDSCH transmissions including MCCH data (e.g., MBS broadcast configuration message(s) including the first MBS broadcast configuration message). If a PDSCH configuration for the MCCH does not exist, the UE 102 can use the PDSCH configuration in SIB1 to receive PDSCH transmissions including MCCH data (e.g., MBS broadcast configuration message(s) including the first MBS broadcast configuration message). The PDSCH configuration for the MTCH configures cell-specific configuration parameters for the UE 102 to receive PDSCH transmissions. If a PDSCH configuration for the MTCH does not exist, the UE 102 can use the PDSCH configuration in SIB1 to receive PDSCH transmissions. Each of the PDSCH transmissions includes including MTCH data (e.g., MBS data for an MBS session, such as MBS data for the first MBS session). The PDCCH configuration for the MCCH configures cell-specific configuration parameters for the UE 102 to receive PDCCH transmissions. If there is no PDCCH configuration for the MCCH, the UE 102 may use the PDCCH configuration in SIB1 to receive the PDCCH transmission.Each of the PDCCH transmissions includes a DCI scrambled with an MCCH-RNTI or G-RNTI and a CRC (of the DCI) that schedules a PDSCH transmission containing MCCH data (e.g., MBS broadcast configuration message(s) including the first MBS broadcast configuration message). The PDCCH configuration for the MTCH configures cell-specific configuration parameters for the UE 102 to receive the PDCCH transmission. If a PDCCH configuration for the MTCH does not exist, the UE 102 can use the PDCCH configuration of SIB1 to receive the PDCCH transmission. Each of the PDCCH transmissions includes a DCI scrambled with a G-RNTI and a CRC (of the DCI) that schedules a PDSCH transmission containing MTCH data (e.g., MBS data for an MBS session, such as MBS data for the first MBS session).

[0071] In some embodiments, the first MBS broadcast configuration message may include a PDSCH configuration for the MTCH (e.g., pdsch-Config-MTCH) and / or a PDCCH configuration for the MTCH (e.g., pdcch-Config-MTCH) instead of system information or MBS control information.

[0072] In some implementations, the MCCH configuration includes configuration parameters such as window start slot, window duration, modification period, and / or repetition period and offset. The window duration indicates a duration (i.e., the MCCH transmission window, e.g., in units of (consecutive) slots) starting from the slot indicated by the window start slot, during which the transmission of MCCH information (i.e., the transmission(s) of the MBS configuration(s) via the MCCH) may be scheduled. The modification period defines a periodically displayed boundary, i.e., a radio frame in which the SFN modifies the modification period=0. The content of different transmissions of the MCCH information may only differ if there is at least one such boundary between them. The repetition period and offset parameters define the length and offset of the MCCH repetition period. The transmission of the MCCH information is scheduled in a radio frame in which the system frame number (SFN) modifies the repetition period length offset of the repetition period.

[0073] In some embodiments, the DU 174 may generate 512 first MBS session information (e.g., MBS-SessionInfo IE) including the first MBS session ID, the first G-RNTI, the first RLC configuration(s), and / or the first PDCP configuration(s) and include the first MBS session information in the MBS Broadcast Configuration message. In some embodiments, the DU 174 may generate 512 first MRB configuration(s) including the first PDCP configuration(s) and / or the first RLC configuration(s). Each of the first MRB configuration(s) may include a specific PDCP configuration of the first PDCP configuration(s). Each of the first MRB configuration(s) may include a specific RLC configuration of the first RLC configuration(s). In some implementations, the DU 174 may establish and use one / more RLC entities to transmit (522) MBS data of the first MBS session to the UE 102 according to the first RLC configuration(s). If the DU 174 receives the first DRX cycle configuration from the CU 172, the DU 174 may generate a first DRX configuration (e.g., a DRX-ConfigPTM IE) according to the first DRX cycle configuration (e.g., a first DRX cycle length). In such a case, the DU 174 may include the first DRX configuration in the first MBS session information.

[0074] The first G-RNTI is used by the DU 174 to schedule the transmission of the MBS data of the first MBS session. Each of the first RLC configuration(s) configures a logical channel ID, an RLC sequence number size (e.g., 6 bits or 12 bits), and / or a timer (value) for the reconstruction of a particular MRB of the MRB(s). The first DRX configuration configures DRX parameters to transmit the MBS data of the first MBS session at an on duration of a periodic DRX cycle to save the power of the UE. According to the DRX parameters, the UE enables discontinuous reception of the MBS data of the first MBS session. For example, the DRX parameters may include: Inactivity timer parameter (e.g., drx-InactivityTimerPTM field): the duration after a PDCCH occasion when a PDCCH indicates a new DL multicast transmission for the MAC entity. · DRX cycle and start offset parameter (eg drx-(Long)CycleStartOffsetPTM field): defines the length of the DRX cycle and defines the subframe in which the DRX cycle starts. · On-duration parameter (e.g., drx-onDurationTimerPTM): duration at the start of a DRX cycle.

[0075] In some embodiments, the DU 174 can generate the first RLC configuration(s), for example, according to the QoS configuration(s) and / or the MRB ID(s). Alternatively, the DU 174 can generate the first RLC configuration(s) using pre-configured RLC parameters. In some embodiments, the DU 174 can include the first logical channel ID(s) in the first RLC configuration(s). If the DU 174 receives the first DRX cycle configuration, the DU 174 sets the length of the DRX cycle to the first DRX cycle length. If the DU 174 does not receive the DRX cycle configuration for the first MBS session, the DU 174 can determine the length of the DRX cycle, for example, according to the QoS configuration(s) received from the CU 172. Alternatively, the DU 174 can determine the length of the DRX cycle according to pre-configured DRX parameters. Further alternatively, the DU 174 does not include, exclude, or refrain from including the DRX configuration of the first MBS session in the first MBS session information or MBS broadcast configuration message. In some implementations, the DU 174 may assign a first G-RNTI (value) and associate the first G-RNTI with the first MBS session ID.

[0076] If the DU 174 receives the first MBS neighbor cell information, the DU 174 may include the first MBS neighbor cell information in the first MBS session information. If the CU 172 does not transmit the first MBS neighbor cell information to the DU 174, the DU 174 may generate the first MBS neighbor cell information and include the first MBS neighbor cell information in the first MBS session information. In some implementations, the DU 174 may generate a first field / IE (e.g., mtch-NeighbourCell-r17) to indicate one or more cells included in the first MBS neighbor cell information and include the field / IE in the first MBS session information.

[0077] After the MBS resource setup procedure 586A, the CN 110 transmits (518) the MBS data of the first MBS session to the CU 172 via the first common CN-BS DL tunnel. The CU 172 then transmits (520) the MBS data to the DU 174 via the first common CU-DU DL tunnel and / or additional common CU-DU DL tunnel in accordance with the first PDCP configuration(s). The DU 174 then transmits (i.e., broadcasts) the MBS data in accordance with the MBS broadcast configuration message (e.g., via the first logical channel(s) identified by the first logical channel ID(s) and using the first RLC configuration(s) and / or the first G-RNTI) (522). The UE 102 receives (522) the MBS data in accordance with the first MBS broadcast configuration or the first MBS session information. For example, the CU 172 receives (518) the MBS data packet, generates a PDCP PDU including the MBS data packet according to the PDCP configuration, and transmits (520) the PDCP PDU to the DU 174 via the first common CU-DU DL tunnel. In some embodiments, the CU 172 can use a PDCP state variable to generate a PDCP sequence number included in the PDCP PDU. In some embodiments, the DU 174 generates (522) a MAC PDU including the first logical channel ID and the PDCP PDU, and transmits (522) the MAC PDU to the UE 102 using the first G-RNTI. The UE 102 receives (522) the MAC PDU using the first G-RNTI, extracts the PDCP PDU and the first logical channel ID from the MAC PDU, identifies a PDCP PDU associated with the MRB based on the first logical channel ID, and extracts the MBS data packet from the PDCP PDU according to the first PDCP configuration. In other embodiments, the DU 174 generates multiple RLC PDU segments that include the PDCP PDU, the multiple RLC PDU segments including an RLC sequence number (i.e., the same RLC sequence number), and each of the multiple RLC PDU segments includes a particular portion of the PDCP PDU. In some embodiments, the DU 174 can generate the RLC sequence number using an RLC state variable.For each of the multiple RLC PDU segments, the DU 174 generates a MAC PDU including the first logical channel ID and the RLC PDU segment, and transmits the MAC PDU to the UE 102 using the first G-RNTI (522). The UE 102 receives the MAC PDU using the first G-RNTI (522), extracts the first logical channel ID and the RLC PDU segment from the MAC PDU, assembles the RLC PDU segments to obtain a PDCP PDU, identifies a PDCP PDU associated with the MRB based on the first logical channel ID, and extracts the MBS data packet from the PDCP PDU according to the first PDCP configuration.

[0078] In some embodiments, the CU 172 includes a CU-CP 172A and a CU-UP 172B, as described with respect to FIG. 1B. In such a case, the events of the MBS resource setup procedure 586A occur between the CU-CP 172A, the CN 110, and the DU 174. In such a case, the events 518 and 520 occur between the CN 110, the CU-UP 172B, and the DU 174. After receiving the MBS context setup response message (506), the CU-CP 172A can send an MBS bearer context setup request message (not shown in FIG. 5A) to the CU-UP 172B, including the first MBS session ID and / or MRB ID(s), to request the CU-UP 172B to establish an MBS bearer context for the first MBS session and / or MRB(s). In some embodiments, the CU-CP 172A excludes the PDU session ID from the MBS bearer context setup request message. In response to the MBS bearer context setup request message, the CU-UP 172B can generate an MBS bearer context and send an MBS bearer context setup response message to the CU-CP 172A. In some embodiments, the CU-UP 172B can include the first CU DL transport layer configuration in the MBS bearer context setup response message, so that the CU-CP can include the first CU DL transport layer configuration in the MBS session resource setup response message. Thus, the CN 110 can send MBS data of the first MBS session to the CU-UP 172B via the first common CN-BS DL tunnel (518).

[0079] In some embodiments, the CU-CP 172A can include the first PDCP configuration(s) in the MBS bearer context setup request message, and the CU-UP 172B transmits MBS data of the first MBS session to the DU 174 according to the first PDCP configuration(s) (520). In some embodiments, the CU-UP 172B establishes one / multiple PDCP entities according to the first PDCP configuration(s) and transmits MBS data of the first MBS session to the DU 174 using the one / multiple PDCP entities (520). In some embodiments, the CU-CP 172A can include MRB ID(s) in the MBS bearer context setup request message, and the CU-CP 172A can associate each of the first PDCP configuration(s) with a particular MRB / MRB ID of the MRB(s) / MRB ID(s) and indicate the association(s) in the MBS bearer context setup request message. In some embodiments, the CU-CP 172A includes the first DU DL transport layer configuration and / or the additional DU DL transport layer configuration in the MBS bearer context setup request message so that the CU-UP 172B can send MBS data of the first MBS session to the DU 174 via the first common CU-DU DL tunnel and / or the additional CU-DU DL tunnel (520).

[0080] In some embodiments, the MBS bearer context may include a first PDCP configuration(s), a first DU DL transport layer configuration, an additional DU DL transport layer configuration, and / or a first CU DL transport layer configuration.

[0081] Operations that may be performed by the CU-CP 172A and the CU-UP 172B are further described with reference to Figures 7A-7B and Figures 9A-9B. Additionally, although not shown in Figures 5B-5E, events of MBS resource procedures 586B-586E (described below) may occur between the CU-CP 172A, the CN 110, and the DU 174 in a manner similar to that described for the MBS resource procedure 586A.

[0082] 5B is a messaging diagram of an example scenario 500B similar to scenario 500A, except that the DU 174 receives a PDCP configuration in a CU-to-DU message from the CU 172 after receiving an MBS context setup request message, as described below. More specifically, the CU 172 sends an MBS context setup request message including a first MBS session ID to the DU 174 (503), and the CU 172 excludes the first PDCP configuration(s) and / or the first DRX cycle configuration from the MBS context setup request message. Instead of including the first PDCP configuration(s) and / or the first DRX cycle configuration in the MBS context setup request message of event 503, the CU 172 sends a CU-to-DU message including the first MBS session ID, the first PDCP configuration(s), and / or the first DRX cycle configuration to the DU 174 (510). In some implementations, the CU-to-DU message may be an F1 Application Protocol (F1AP) message.Events 502, 503, 506, 508, 510, and 512 are collectively referred to in FIG.

[0083] 5C is a messaging diagram of an example scenario 500C similar to scenarios 500A and 500B, but in which the CU 172 generates the MBS session information instead of the DU 174. In scenario 500C, the DU 174 sends an MBS context setup response message to the CU 172 including the first RLC configuration(s) and the first G-RNTI (505). After receiving the first RLC configuration(s) and the first G-RNTI, the CU 172 generates the first MBS session information including the first MBS session ID, the first G-RNTI, and the first MRB configuration(s) (i.e., including the first PDCP configuration(s) and the first RLC configuration(s)) (511). The CU 172 then sends a CU-to-DU message including the first MBS session information to the DU 174 (513). After receiving the first MBS session information, the DU 174 may generate a first MBS broadcast configuration message including the first MBS session information and transmit the first MBS broadcast configuration message as described above (516). Alternatively, the CU 172 may generate a first MBS broadcast configuration message including the first MBS session information and include the first MBS broadcast configuration message in the CU-to-DU message of event 513. Thus, the DU 174 may transmit the first MBS broadcast configuration message as described above (516).

[0084] If the DU 174 generates the first DRX configuration as described above, the DU 174 may, in some embodiments, include the first DRX configuration in the CU-to-DU message of event 505. In such a case, the CU 172 includes the first DRX configuration in the first MBS session information. In other embodiments, the CU 172 may generate the first DRX configuration and include the first DRX configuration in the first MBS session information. In yet other embodiments, the CU 172 excludes the DRX configuration from the first MBS session information or the first MBS broadcast configuration message (or refrains from including the DRX configuration in the first MBS session information or the first MBS broadcast configuration message).

[0085] In some implementations, the CU 172 may include the first MBS neighbor cell information in the first MBS session information. In some implementations, the DU 174 may include the first MBS neighbor cell information in an MBS context setup response message. In other implementations, the CU 172 may generate the first MBS neighbor cell information. In some implementations, the CU 172 may generate a first field / IE (e.g., mtch-NeighbourCell-r17) to indicate one or more cells included in the first MBS neighbor cell information and include the field / IE in the first MBS session information.

[0086] Events 502, 503, 505, 508, 511, and 513 are collectively referred to as MBS resource setup procedure 586C in FIG. 5C.

[0087] 5D is a messaging diagram of an example scenario 500D similar to scenario 500C, except that instead of including the first RLC configuration(s), the first G-RNTI, and / or the first DRX cycle configuration in the MBS context setup response message of event 505, the DU 174 sends 509 a DU-to-CU message including the first RLC configuration(s) and the first G-RNTI to the CU 172. In some implementations, the CU-to-DU message may be an F1AP message. Events 502, 503, 506, 508, 509, 511, and 513 are collectively referred to in FIG. 5D as an MBS resource setup procedure 586D.

[0088] 5E is a messaging diagram of an example scenario 500E similar to scenarios 500A and 500B, except that the DU 174 does not receive the PDCP configuration from the CU 172. Because the CU 172 does not provide the first PDCP configuration(s) to the DU 174, the DU 174, in some embodiments, can be preconfigured with the first PDCP configuration(s) or can receive the first PDCP configuration(s) from an OAM node. In other embodiments, the DU 174 can generate the first PDCP configuration(s) according to the configuration(s) in the CU-to-DU message received from the CU 172. In one embodiment, the CU-to-DU message can be an MBS context setup request message. In some embodiments, the configuration(s) can be QoS configuration(s). The DU 174 can determine or generate a PDCP sequence number size and / or a header compression configuration according to the QoS configuration(s). For example, if the QoS configuration(s) require or indicate a high data rate, the DU 174 may determine or generate the PDCP sequence number size to be a larger size (e.g., 18 bits). Otherwise, the DU 174 may determine the PDCP sequence number size to be a smaller size (e.g., 12 bits). In another example, if the QoS configuration(s) require or indicate QoS for a streaming service (e.g., voice or video service), the DU 174 may determine or generate to configure one or more header compression profiles for the MRB(s) of the first MBS session. Otherwise, the DU 174 may determine not to configure header compression for the MRB(s) of the first MBS session.

[0089] In yet another embodiment, the configuration(s) may include CU-to-DU header compression configuration(s), each being an IE (e.g., F1AP IE) in a CU-to-DU message for a particular MRB of the MRB(s) of the first MBS session. The DU 174 may generate header compression configuration(s) in the first PDCP configuration(s) according to the CU-to-DU header compression configuration(s). If the CU-to-DU message does not include a CU-to-DU header compression configuration(s) for a particular MRB of the MRB(s), the DU 174 may generate a header compression configuration that does not configure header compression and include the header compression configuration in the first PDCP configuration.

[0090] In yet another embodiment, the configuration(s) may include CU-to-DU PDCP sequence number size configuration(s), each being an IE (e.g., F1AP IE) in a CU-to-DU message for a particular MRB of the MRB(s) of the first MBS session. The DU 174 may generate PDCP sequence number size(s) in the first PDCP configuration(s) according to the CU-to-DU PDCP sequence number size configuration(s). If the CU-to-DU message does not include PDCP sequence number size setting(s) for a particular MRB of the MRB(s), the DU 174 may include a default PDCP sequence number size in the first PDCP configuration.

[0091] The DU 174 then generates a first MBS broadcast configuration message 515. Events 502, 503, 506, 508, and 515 are collectively referred to as an MBS resource setup procedure 586E in FIG.

[0092] FIG. 5F is a messaging diagram of an example scenario 500F similar to scenarios 500A-E, except that the base station 104 later releases resources for the first MBS session. Scenario 500F may begin with any one of MBS resource setup procedures 586A-E. After transmitting MBS data (518), the CN 110 may determine to request the RAN 105 to release resources for the first MBS session. In response to the determination, the CN 110 transmits an MBS session resource release request message to the CU 172 (524) including the first MBS session ID. In response to or after receiving the MBS session resource release request message (524), the CU 172 transmits an MBS context release command message to the DU 174 (526) to request the DU 174 to release resources for the first MBS session. In some implementations, the CU 172 may include the first MBS session ID in the MBS context release command message. The CU 172 may or may not include the MRB ID(s) in the MBS context release command message. In response, the DU 174 releases resources (e.g., the first G-RNTI, the first RLC configuration(s), the first DRX configuration, and / or the first and / or additional DU DL transport layer configurations) and sends an MBS context release complete message to the CU 172 (528). In response to or after receiving the MBS context release complete message (528), the CU 172 may send an MBS session resource release response message to the CN 110 (530) to confirm that the resources for the first MBS session have been released.

[0093] In some embodiments, the CU 172 may determine to request the DU 174 to release resources for the first MBS session without receiving an MBS session resource release request message from the CN 110. For example, the CU 172 may make the determination after detecting MBS data inactivity for the first MBS session for a period of time. In response to the determination, the CU 172 may send an MBS context release command message to the DU 174 (526). In some embodiments, the CU 172 may receive the value of the period in a CN-to-BS message from the CN 110. For example, the CN-to-BS message may be an MBS session resource setup request message of event 502 or an NG application protocol (NGAP) message. In other embodiments, the CU 172 may receive the value of the period from an OAM node. In yet other embodiments, the CU 172 may be preconfigured with the value of the period.

[0094] The DU 174 may stop transmitting (e.g., broadcasting) the first MBS broadcast configuration message in response to or after receiving the MBS context release command message (526) (532). Alternatively, the DU 174 may transmit (e.g., broadcast) a second MBS broadcast configuration message excluding the first MBS session information in accordance with the MBS control information in response to or after receiving the MBS context release command message (526). In some embodiments, the DU 174 generates the second MBS broadcast configuration message as described for the first MBS broadcast configuration message. In other embodiments, the CU 172 generates the second MBS broadcast configuration message and sends a CU-to-DU message including the second MBS broadcast configuration message to the DU 174 as described for the first MBS broadcast configuration message in scenario 500C. The CU-to-DU message may be an MBS context release command message or an F1AP message.

[0095] In some embodiments, in response to or after receiving the MBS context release command message (526), ​​the DU 174 may release one / more RLC entities used by the DU 174 to transmit MBS data of the first MBS session. In some embodiments, the DU 174 may stop transmitting system information for the event 514.

[0096] Events 524, 526, 528, and 530 are collectively referred to as an MBS resource release procedure 588 in FIG. 5F.

[0097] In some embodiments, the CU 172 includes a CU-CP 172A and a CU-UP 172B. In such a case, events 524, 526, 528, and 530 occur between the CU-CP 172A of the CU 172, the CN 110, and the DU 174. After receiving the message of event 524, the CU-CP 172A can send an MBS Bearer Context Release Command message (not shown in FIG. 5F) to the CU-UP 172B, including the first MBS Session ID and / or MRB ID(s), to request the CU-UP 172B to release the MBS bearer context for the first MBS session. In some embodiments, the CU 172 excludes the PDU Session ID from the MBS Bearer Context Release Command message. In response to the MBS Bearer Context Release Command message, the CU-UP 172B can release the MBS bearer context and send an MBS Bearer Context Release Complete message to the CU-CP 172A. In some embodiments, in response to or after receiving the MBS Bearer Context Release Command message, CU-UP 172B may release one / more PDCP entities used by CU-UP 172B to transmit MBS data for the first MBS session.

[0098] FIG. 5G is a messaging diagram of an example scenario 500G similar to scenarios 500A-E, except that the base station 104 later suspends and resumes resources for the first MBS session. Scenario 500G may begin with any one of MBS resource setup procedures 586A-E. After transmitting MBS data (518), the CN 110 may decide to suspend the first MBS session. In response to the decision, the CN 110 sends an MBS Session Resources Modification Request message to the CU 172 including the first MBS session ID and an indication to suspend the first MBS session (525). The indication may be an indication of suspension or an IE indicating to suspend resources and / or operations for the first MBS session or causing the CU 172 to suspend resources and / or operations for the first MBS session. In response to or after receiving the MBS session resource modification request message or indication (525), the CU 172 sends an MBS context modification request message to the DU 174 including an indication to request the DU 174 to suspend resources for the first MBS session or MRB(s) (527). The indication may be an indication of suspension or an IE indicating to suspend resources and / or operations for the first MBS session or causing the CU 172 to suspend resources and / or operations for the first MBS session. In some implementations, the CU 172 may include the first MBS session ID and / or MRB ID(s) in the MBS context modification request message. In response, the DU 174 suspends resources and / or operations for the first MBS session or MRB(s) and sends an MBS context modification response message to the CU 172 (529). In response to or after receiving the MBS context modification response message (529), CU172 may send an MBS session resource modification response message to CN110 (531) to confirm that the resources for the first MBS session have been suspended.

[0099] In some embodiments, the CU 172 may determine to request the DU 174 to suspend the first MBS session without receiving an MBS session resource modification request message from the CN 110. For example, the CU 172 may make the determination after detecting MBS data inactivity for the first MBS session for a period of time. In response to the determination, the CU 172 may send an MBS context modification request message to the DU 174 (527). In some embodiments, the CU 172 may receive the value of the period in a CN-to-BS message from the CN 110. For example, the CN-to-BS message may be an MBS session resource setup request message of event 502 or an NG Application Protocol (NGAP) message. In other embodiments, the CU 172 may receive the value of the period from an OAM node. In yet other embodiments, the CU 172 may be preconfigured with the value of the period.

[0100] In response to or after receiving the MBS context modification request message (527), the DU 174 can stop transmitting (e.g., broadcasting) the first MBS broadcast configuration message (532). Alternatively, in response to or after receiving the MBS context modification request message (527), the DU 174 can transmit (e.g., broadcast) a second MBS broadcast configuration message excluding the first MBS session information according to the MBS control information. In some embodiments, the DU 174 generates the second MBS broadcast configuration message as described for the first MBS broadcast configuration message. In other embodiments, the CU 172 generates the second MBS broadcast configuration message and transmits a CU-to-DU message including the second MBS broadcast configuration message to the DU 174. The CU-to-DU message can be an MBS context modification request message or an F1AP message.

[0101] In some embodiments, the DU 174 may maintain one / more RLC entities used by the DU 174 to transmit MBS data of the first MBS session in response to or after receiving the MBS context modification request message (527). In such a case, the DU 174 may maintain an RLC state variable in one embodiment. In another embodiment, the DU 174 may reset the RLC state variable in response to or after receiving the MBS context modification request message (527).

[0102] Events 525, 527, 529, and 531 are collectively referred to as an MBS resource suspension procedure 589 in FIG. 5G.

[0103] In some embodiments, the CU 172 includes a CU-CP 172A and a CU-UP 172B. In such a case, events 525, 527, 529, and 531 occur between the CU-CP 172A of the CU 172, the CN 110, and the DU 174. After receiving the message of event 525, the CU-CP 172A can send an MBS bearer context modification request message (not shown in FIG. 5G) including the first MBS session ID and / or MRB ID(s) to the CU-CP 172B to request the CU-UP 172B to suspend resources and / or operations for the first MBS session. In some embodiments, the CU-CP 172A excludes the PDU session ID from the MBS bearer context modification request message. In response to the MBS Bearer Context Modify Request message, the CU-UP 172B may suspend resources (e.g., MBS bearer context) and / or operations for the first MBS session and send an MBS Bearer Context Modify Response message to the CU-CP 172A. In some embodiments, the CU-UP may maintain one / more PDCP entities used by the CU-UP 172B to transmit MBS data for the first MBS session in response to or after receiving the MBS Bearer Context Modify Request message. In such a case, the CU-UP 172B may maintain PDCP state variables in one embodiment. In another embodiment, the DU 174 may reset the PDCP state variables.

[0104] Later, the CN 110 may decide to resume the first MBS session. In response to the decision, the CN 110 may send to the CN 110 another second MBS session resource modification request message including the first MBS session ID and an indication to request the CU 172 to resume the first MBS session (534). In some embodiments, the indication may be an indication of resumption or an IE indicating to resume the first MBS session or causing the CU 172 to resume the first MBS session. In response to or after receiving the MBS session resource modification request message (534), the CU 172 sends to the DU 174 an MBS context modification request message including an indication to resume the first MBS session (536). In some embodiments, the CU 172 may include the first MBS session ID in the MBS context modification request message. The CU 172 may or may not include the MRB ID(s) in the MBS context modification request message. In response to the MBS context modification request message, the DU 174 resumes the suspended resources and / or operations and sends (538) an MBS context modification response message to the CU 172. In response to or after receiving (538) the MBS context modification response message, the CU 172 may send (540) an MBS session resource modification response message to the CN 110 to confirm that the resources of the first MBS session have been resumed.

[0105] In some embodiments, the CU 172 may determine to request the DU 174 to resume the first MBS session without receiving an MBS session resource modification request message from the CN 110. For example, the CU 172 may detect MBS data activity in response to receiving MBS data for the first MBS session (548) and make the determination after detecting the MBS data activity. In response to the determination, the CU 172 may send an MBS context modification request message to the DU 174 (536). In response to the MBS context modification request message, the DU 174 resumes the suspended resources and / or operations and sends an MBS context modification response message to the CU 172 (538).

[0106] The DU 174 may resume transmitting the first MBS broadcast configuration message (542) in response to or after receiving the MBS context modification request message (536). Alternatively, the DU 174 may decide to transmit (e.g., broadcast) (542) a third MBS broadcast configuration message in response to or after receiving the MBS context modification request message (536). The third MBS broadcast configuration message may include the first MBS session information or new MBS session information for the first MBS session. In some implementations, the DU 174 generates the third MBS broadcast configuration message as described for the first MBS broadcast configuration message. In other implementations, the CU 172 generates the third MBS broadcast configuration message and transmits a CU-to-DU message including the third MBS broadcast configuration message to the DU 174 as described for the first MBS broadcast configuration message. The CU-to-DU message may be an MBS context modification request message or an F1AP message.

[0107] In some implementations, the DU 174 can reset the RLC state variables in response to or after receiving the MBS context modification request message (536). Alternatively, the DU 174 refrains from resetting the RLC state variables in response to or after receiving the MBS context modification request message (536). If the DU 174 stopped transmitting system information in response to or after receiving the MBS context modification request message (527), the DU 174 resumes transmitting system information in response to or after receiving the MBS context modification request message (536). Alternatively, the DU 174 decides to transmit new system information including new MBS control information in response to or after receiving the MBS context modification request message (536). In response to the resume or decision, the DU 174 transmits (544) the (new) system information to the UE 102 via broadcast. In response to the restart or determination of event 542, the DU 174 transmits (eg, broadcasts) the first or third MBS broadcast configuration message via the (new) MBS control information (546).

[0108] Events 534, 536, 538, and 540 are collectively referred to as MBS resource resume procedure 590 in FIG. 5G. After procedure 590, 542, 544, or 546, the CN 110 may transmit (548) the MBS data of the first MBS session to the CU 172, similar to event 518. The CU 172 may then transmit (550) the MBS data of the first MBS session to the DU 174, similar to event 520. The DU 174 may then transmit (552) the MBS data of the first MBS session to the UE 102, similar to event 522. In some implementations, the DU 174 may transmit (552) the MBS data of the first MBS session using the (reset) RLC state variables.

[0109] In some embodiments, the CU 172 includes a CU-CP 172A and a CU-UP 172B. In such a case, events 534, 536, 538, and 540 occur between the CU-CP 172A of the CU 172, the CN 110, and the DU 174. After receiving the message of event 534, the CU-CP 172A can send an MBS bearer context modification request message (not shown in FIG. 5G) including the first MBS session ID and / or MRB ID(s) to the CU-UP 172B to request the CU-UP 172B to resume resources and / or operations for the first MBS session. In some embodiments, the CU-CP 172A excludes the PDU session ID from the MBS bearer context modification request message. In response to the MBS bearer context modification request message, the CU-UP 172B may resume the suspended resources (e.g., MBS bearer context) and / or operations for the first MBS session and send an MBS bearer context modification response message. After resuming the suspended resources and / or operations, the CU-UP 172B may transmit (e.g., broadcast) MBS data for the first MBS session to the DU 174 using one / more PDCP entities that were retained in response to or after receiving the MBS bearer context modification request message (550). In one embodiment, the CU-UP 172B may transmit the MBS data using the retained PDCP state variables (550). In another embodiment, the CP-UP 172B may reset the PDCP state variables in response to the MBS bearer context modification request message and then transmit the MBS data for the first MBS session to the UE 102 using the PDCP state variables (552).

[0110] FIG. 5H is a messaging diagram of an example scenario 500H similar to scenarios 500A-E, where base station 104 also configures resources for transmitting MBS data of a second MBS session via broadcast.

[0111] Scenario 500H may begin with any one of MBS resource setup procedures 586A-E to set up resources for a first MBS session. After transmitting MBS data for the first MBS session (518), CN 110 may decide to set up a second MBS session. In response to the decision, CN 110, CU 172, and DU 174 may perform an MBS resource setup procedure for the second MBS session (587), similar to any one of procedures 586A-E. In the MBS resource setup procedure 587, CU 172 or DU 174 generates second MBS session information including a second MBS session ID, a second G-RNTI, and a second MRB configuration(s) for the second MBS session. The second MBS session ID identifies the second MBS session, and the second MRB configuration(s) configure one or more MRBs for the second MBS session. The CU 172 or the DU 174 may further include the second DRX configuration and / or the second neighbor cell information in the second MBS session information. In response to or after performing the MBS resource setup procedure 587, the DU 174 may transmit (554) system information via broadcast and transmit (556) the second MBS broadcast configuration message, similar to events 514 and 516, respectively. More specifically, the CU 172 or the DU 174 may include the first MBS session information and the second MBS session information in the second MBS broadcast configuration message. Thus, the UE 102 (i.e., the UE interested in receiving the first MBS session) and the UE 103 (the UE interested in receiving the second MBS session) may receive the broadcasted second MBS broadcast configuration message including the first MBS session information and the second MBS session information, respectively.

[0112] In some embodiments, the DU 174 sets the second G-RNTI and the first G-RNTI to different values. In other embodiments, the DU 174 sets the second G-RNTI and the first G-RNTI to the same value. In some embodiments, the CU 172 may indicate in the MBS context setup request or CU-to-DU message in procedure 587 whether the second MBS session is multiplexed with the first MBS session. For example, the CU 172 may include in the MBS context setup request or CU-to-DU message in procedure 587 a first indication indicating that the second MBS session is multiplexed with the first MBS session. In response to the first indication, the DU 174 may set the second G-RNTI and the first G-RNTI to the same value. If the DU 174 does not receive the first indication in procedure 587, the DU 174 sets the second G-RNTI and the first G-RNTI to different values. In another example, the CU 172 may include a second indication in the MBS context setup request or CU-to-DU message in procedure 587, indicating that the second MBS session is not multiplexed with the first MBS session. In response to the second indication, the DU 174 may set the second G-RNTI and the first G-RNTI to different values. If the DU 174 does not receive the second indication in procedure 587, the DU 174 sets the second G-RNTI and the first G-RNTI to the same value.

[0113] Similar to establishing the first common CN-BS DL tunnel, the CU 172 can establish a second common CN-BS DL tunnel with the CN 110 in an MBS resource setup procedure 587. The MBS session resource setup response message in procedure 587 can include a second CU DL transport layer configuration for configuring the second common CN-BS DL tunnel for the CN 110 to transmit MBS data of the second MBS session to the CU 172. The second CU DL transport layer configuration includes transport layer information such as a transport layer address (e.g., IP address) and / or a TEID to identify the second common CN-BS DL tunnel. Similar to establishing the first common CU-DU DL tunnel, the DU 174 can establish at least one second common CU-DU DL tunnel with the CU 172 in an MBS resource setup procedure 587. The MBS context setup response message of procedure 587 may include at least one second DU DL transport layer configuration for configuring at least one second common CN-DU DL tunnel for the second MBS session.

[0114] After the MBS resource setup procedure 587, the CN 110 transmits (558) the MBS data of the second MBS session to the CU 172 via the second common CN-BS DL tunnel. The CU 172 then transmits (560) the MBS data to the DU 174 via the second common CU-DU DL tunnel and / or additional common CU-DU DL tunnel in accordance with the second PDCP configuration(s). The DU 174 then transmits (i.e., broadcasts) the MBS data in accordance with the MBS broadcast configuration message (e.g., via second logical channel(s) identified by the second logical channel ID(s) and using the second RLC configuration(s) and / or the second G-RNTI) (562). The UE 103 receives (562) the MBS data in accordance with the second MBS broadcast configuration or the second MBS session information. For example, the CU 172 receives the MBS data packet (558), generates a PDCP PDU including the MBS data packet according to the PDCP configuration, and transmits the PDCP PDU to the DU 174 via the second common CU-DU DL tunnel (560). In some embodiments, the CU 172 can use a PDCP state variable to generate a PDCP sequence number included in the PDCP PDU. In some embodiments, the DU 174 can generate a MAC PDU including the second logical channel ID and the PDCP PDU, and transmits the MAC PDU to the UE 103 using the second G-RNTI (562). In some embodiments, the DU 174 can use an RLC state variable to generate an RLC sequence number. The UE 103 receives (562) a MAC PDU using the second G-RNTI, extracts a second logical channel ID and a PDCP PDU from the MAC PDU, identifies a PDCP PDU associated with the MRB based on the second logical channel ID, and extracts an MBS data packet from the PDCP PDU according to the first PDCP configuration. In another embodiment, the DU 174 generates a plurality of RLC PDU segments including the PDCP PDU, the plurality of RLC PDU segments including an RLC sequence number (i.e., the same RLC sequence number), and each of the plurality of RLC PDU segments includes a particular portion of the PDCP PDU.In some implementations, the DU 174 can generate the RLC sequence number using the RLC state variables. For each of the multiple RLC PDU segments, the DU 174 generates a MAC PDU including the first logical channel ID and the RLC PDU segment, and transmits the MAC PDU to the UE 102 using the second G-RNTI (562). The UE 103 receives the MAC PDU using the second G-RNTI (562), extracts the second logical channel ID and the RLC PDU segment from the MAC PDU, assembles the RLC PDU segments to obtain a PDCP PDU, identifies a PDCP PDU associated with the MRB based on the second logical channel ID, and extracts the MBS data packet from the PDCP PDU according to the second PDCP configuration.

[0115] After the MBS resource setup procedure 587, the CN 110 transmits (548) the MBS data of the first MBS session to the CU 172, similar to event 518. The CU 172 then transmits (550) the MBS data to the DU 174, similar to event 520. The DU 174 then transmits (552) the MBS data to the UE 102 via broadcast, similar to event 522.

[0116] Later, the CN 110, the CU 172, and the DU 174 perform an MBS resource release procedure (588) to release resources for the first MBS session. In response to or after performing the MBS resource release procedure (588), the DU 174 stops broadcasting the first MBS session information. To stop broadcasting the first MBS session information, the DU 174 may transmit (e.g., broadcast) a second MBS broadcast configuration message excluding the first MBS session information according to the MBS control information (564).

[0117] In some embodiments, the CU 172 includes a CU-CP 172A and a CU-UP 172B. In such a case, the events of procedure 587 occur between the CU-CP 172A of the CU 172, the CN 110, and the DU 174. In such a case, events 518, 548, 558 and events 520, 550, 560 occur between the CN 110 and the CU-UP 172B and between the CU-UP 172B and the DU 174, respectively. After receiving the MBS context setup response message of procedure 587, the CU-CP 172A can send an MBS bearer context setup request message including the second MBS session ID and / or MRB ID(s) of the MRB(s) for the second MBS session to the CU-UP 172B to request the CU-UP to establish an MBS bearer context for the second MBS session and / or MRB(s). In some embodiments, the CU-CP 172A excludes the PDU session ID from the MBS bearer context setup request message. In response to the MBS bearer context setup request message, the CU-UP 172B can generate an MBS bearer context and send an MBS bearer context setup response message to the CU-CP 172A. In some embodiments, the CU-UP can include a second CU DL transport layer configuration in the MBS bearer context setup response message, so that the CU-CP 172A can include at least one second CU DL transport layer configuration in the MBS session resource setup response message. Thus, the CN 110 can send MBS data of the second MBS session to the CU-UP 172B via at least one second common CN-BS DL tunnel (558).

[0118] In some embodiments, the CU-CP 172A can include the second PDCP configuration(s) in the MBS bearer context setup request message, and the CU-UP 172B transmits MBS data for the second MBS session according to the second PDCP configuration(s) (560). In some embodiments, the CU-UP 172B establishes one / more PDCP entities according to the second PDCP configuration(s) and transmits MBS data for the second MBS session to the DU 174 using the one / more PDCP entities (560). In some embodiments, the CU-CP 172A can include MRB ID(s) in the MBS bearer context setup request message, and the CU-CP 172A can associate each of the second PDCP configuration(s) with a particular MRB / MRB ID of the MRB(s) / MRB ID(s) and indicate the association(s) in the MBS bearer context setup request message. In some embodiments, the CU-CP 172A includes at least one second DU DL transport layer configuration in the MBS bearer context setup request message so that the CU-UP 172B can send MBS data of the second MBS session to the DU 174 via at least one second common CU-DU DL tunnel (560).

[0119] In some implementations, the MBS bearer context may include a second PDCP configuration(s), at least one second DU DL transport layer configuration, and / or a second CU DL transport layer configuration.

[0120] 5I is a messaging diagram of an example scenario 500I that is similar to scenarios 500A-E, except that the base station 104 later modifies the resources for the first MBS session. Scenario 500I may begin with any one of MBS resource setup procedures 586A-E.

[0121] After transmitting the MBS data (518), the CN 110 may decide to modify resources for the first MBS session. In response to the decision, the CN 110 may send an MBS session resource modification request message including the first MBS session ID to the CU 172 (535), requesting the CU 172 to modify resources for the first MBS session. In response to or after receiving the MBS session resource modification request message (535), the CU 172 may send an MBS context modification request message to the DU 174 (537), requesting the DU 174 to modify resources for the first MBS session or MRB(s). In some implementations, the CU 172 may include the first MBS session ID and / or MRB ID(s) in the MBS context modification request message. In response, the DU 174 modifies resources for the first MBS session or MRB(s) and sends an MBS context modification response message to the CU 172 (539). In response to or after receiving the MBS context modification response message (539), CU172 may send an MBS session resource modification response message to CN110 (541) to confirm that the resources for the first MBS session have been modified.

[0122] Events 535, 537, 539, and 541 are collectively referred to as MBS resource modification procedure 591 in FIG. 5H.

[0123] In some implementations, the CN 110 may include the new QoS configuration(s) in an MBS session resource modification request message to request the CU 174 to modify resources for the first MBS session. In such a case, the CU 172 may include the new QoS configuration(s) in the MBS context modification request message. Thus, the DU 174 may implement the new QoS configuration(s) for transmitting MBS data of the first MBS session (552).

[0124] In some embodiments, the DU 174 may transmit (517) a new MBS broadcast configuration message including new MBS session information for the first MBS session over one or more cells according to the MBS control information in response to or as a result of the MBS resource modification procedure 591. The new MBS session information may include a first MBS session ID, a first MRB configuration(s), a new MRB configuration (described below), and / or a DRX configuration (i.e., either a first DRX configuration or a new DRX configuration described below). In some embodiments, the DU 174 may generate a new MBS session information or a new MBS broadcast configuration message as described with respect to FIG. 5A. In other embodiments, the CU 172 may generate a new MBS session information or a new MBS broadcast configuration message as described with respect to FIG. 5C.

[0125] In some embodiments, the CU 172 may configure or generate a new DRX cycle configuration including the new DRX cycle length and include the new DRX cycle configuration in the MBS context modification request message. In some embodiments, the CU 172 may determine the new DRX cycle length according to the new QoS configuration(s). In other embodiments, the CU 172 may receive the new DRX cycle length in the MBS session resource modification request message. After receiving the new DRX cycle length, the DU 174 may generate a new DRX configuration (e.g., DRX-ConfigPTM IE) according to the new DRX cycle length. In some embodiments, the DU 174 generates new MBS session information including the new DRX configuration and generates a new MBS broadcast configuration message including the new MBS session information. In other embodiments, the DU 174 includes the new DRX configuration in the MBS context modification response message. In such a case, the CU 172 generates new MBS session information including the new DRX configuration, and sends a CU-to-DU message (e.g., F1AP message) including the new MBS session information to the DU 174. Then, the DU 174 generates a new MBS broadcast configuration message including the new MBS session information. Instead, the CU 172 generates a new MBS broadcast configuration message including the new MBS session information, and sends a CU-to-DU message (e.g., F1AP message) including the new MBS session information to the DU 174.

[0126] In some implementations, the CU 172 may determine to configure an additional MRB for the first MBS session in response to the MBS session resource modification request message or according to the new QoS configuration(s). For example, the new QoS configuration(s) include a new QoS flow ID for a new QoS flow, and the CU 172 determines to configure an additional MRB for the new QoS flow. In response to the determination, the CU 172 may include an additional PDCP configuration for the additional MRB in the MBS context modification request message, similar to event 504. The CU 172 may or may not include an additional MRB ID for the additional MRB in the MBS context modification request message. After receiving the additional PDCP configuration, the DU 174 may generate an additional PDCP configuration or an additional RLC configuration for the additional MRB. The additional RLC configuration includes an additional logical channel ID. The DU 174 may generate an additional MRB configuration including an additional RLC configuration and an additional PDCP configuration, generate new MBS session information (e.g., MBS-SsssionInfo IE) including the first MBS session ID, the first G-RNTI, the first MRB configuration(s), and the additional MRB configuration, and generate a new MBS broadcast configuration message including the MBS session information. The DU 174 then transmits (517) the new MBS broadcast configuration message via one or more cells according to the MBS control information, similar to event 516. In some implementations, the DU 174 may include the new G-RNTI (value) in the new MBS session information instead of the first G-RNTI (value).

[0127] In an alternative embodiment, the DU 174 includes the additional RLC configuration in the MBS context modification response message, similar to event 505. In such a case, the CU 172 can generate new MBS session information, similar to event 511. If the DU 174 includes a new G-RNTI(value) for the first MBS session in the MBS context modification response message, the CU 172 includes the new G-RNTI(value) in the new MBS session information instead of the first G-RNTI(value). In some embodiments, the CU 172 can send a CU-to-DU message including the new MBS session information to the DU 174. In such a case, the DU 174 generates a new MBS broadcast configuration message including the new MBS session information and transmits the new MBS broadcast configuration message to the UE 102 (517). In other embodiments, the CU 172 generates a new MBS broadcast configuration message including the new MBS session information and transmits the new MBS broadcast configuration message to the UE 102 (517).

[0128] In some embodiments, the DU 174 may include an additional DU DL transport layer configuration to configure an additional common CU-DU DL tunnel for the additional MRB. The additional DU DL transport layer configuration includes transport layer information, such as a transport layer address (e.g., IP address) and / or a TEID, to identify the additional common CN-DU DL tunnel. The DU 174 may receive (550) MBS data of the first MBS session via the additional common CU-DU DL tunnel and transmit (552) the MBS data using the additional logical channel ID, similar to event 522. The DU 174 may receive (550) MBS data of the first MBS session via the first common CU-DU DL tunnel and transmit (552) the MBS data using the first logical channel ID, similar to event 522.

[0129] Next, some exemplary methods that the devices illustrated in Figures 1A and 1B, such as the CU 172 (which may include the CU-CP 172A and the CU-UP 172B), and the DU 174 of the base station 104, may implement will be described with reference to Figures 6A-11. The exemplary methods described with reference to Figures 6A-11 may be performed during the above-mentioned scenarios 500A-500I. Each of these methods may be implemented as a set of instructions stored on a non-transitory computer-readable medium and executable by one or more processors.

[0130] Referring first to FIG. 6A, a DU, such as the DU 174, can implement a method 600A to transmit configuration parameters for transmitting MBS data of an MBS session.

[0131] The method 600A begins at block 602, where the DU receives at least one first CU-to-DU message including a first MBS session ID for a first MBS session from a first RAN node (see, e.g., events 503, 504, 510, 513, 537, 586A-E, 591). At block 604, the DU generates a first MBS broadcast configuration message including first MBS session information for the first MBS session (see, e.g., events 512, 515, 586A-E, 591). In return, the DU receives the first MBS broadcast configuration message in one of the at least one first CU-to-DU messages from the first RAN node (see, e.g., event 513). At block 606, the DU transmits the first MBS broadcast configuration message over one or more cells (see, e.g., events 516, 517, 546). At block 608, the DU receives MBS data for the first MBS session from the second RAN node (e.g., see events 520, 550). At block 610, the DU transmits the MBS data for the first MBS session over one or more cells using the first MBS session information (e.g., 522, 552).

[0132] In block 612, the DU receives at least one second CU-to-DU message from the third RAN node, the second MBS session ID for the second MBS session (see, e.g., event 587). In block 614, the DU generates a second MBS broadcast configuration message including the first MBS session information and the second MBS session information for the second MBS session (see, e.g., event 587). Instead, the DU receives the second MBS broadcast configuration message in one of the at least one second CU-to-DU message from the third RAN node (see, e.g., events 513, 587). The second MBS broadcast configuration message replaces the first MBS broadcast configuration message because the first MBS broadcast configuration message does not include the second MBS session information. In block 616, the DU transmits the second MBS broadcast configuration message over one or more cells, as described for scenario 500H (see, e.g., event 556). At block 618, the DU receives MBS data for the second MBS session from the fourth RAN node (e.g., see event 560). At block 620, the DU transmits the MBS data for the second MBS session over one or more cells using the second MBS session information (e.g., see event 562). After transmitting the second MBS broadcast configuration message, the DU may receive subsequent MBS data for the first MBS session from the second RAN node and transmit the subsequent MBS data over one or more cells using the first MBS session information.

[0133] According to the method 600A, the DU may send new MBS session information for the new MBS session.

[0134] In some embodiments, at least one first CU-to-DU message can include an MBS session setup list including the first MBS session ID. Similarly, at least one second CU-to-DU message can include an MBS session setup list including the second MBS session ID. In some embodiments, the DU can generate the first MBS session information and / or the second MBS session information. In other embodiments, the DU can receive the first MBS session information and / or the second MBS session information from the first RAN node and / or the third RAN node, respectively. In such a case, the DU can include the first MBS session information and / or the second MBS session information in the first MBS broadcast configuration message and the second MBS broadcast configuration message, respectively.

[0135] In some embodiments, the first MBS session information includes a first MBS Session ID, a first G-RNTI, and / or at least one first MRB configuration. Each of the at least one first MRB configuration may include a first PDCP configuration and / or a first RLC configuration. The first MBS session information may additionally include a first DRX configuration. Similarly, the first MBS session information may include a second MBS Session ID, a second G-RNTI, and / or at least one second MRB configuration. Each of the at least one second MRB configuration may include a second PDCP configuration and / or a second RLC configuration. The second MBS session information may additionally include a second DRX configuration.

[0136] In some embodiments, the at least one first CU-to-DU message includes the first PDCP configuration(s). In other embodiments, the at least one first CU-to-DU message does not include the first PDCP configuration(s). In such a case, the DU may receive the first PDCP configuration(s) from a first Operations, Administration and Maintenance (OAM) node in one embodiment. In another embodiment, the first PDCP configuration(s) are pre-configured for the first MBS Session ID. That is, the DU has stored the first PDCP configuration(s) before receiving the at least one first CU-to-DU message.

[0137] In some embodiments, the at least one second CU-to-DU message includes the second PDCP configuration(s). In other embodiments, the at least one second CU-to-DU message does not include the second PDCP configuration(s). In such a case, the DU can receive the second PDCP configuration from the second OAM in one embodiment. In another embodiment, the second PDCP configuration(s) are pre-configured for the second MBS Session ID. That is, the DU has stored the second PDCP configuration(s) before receiving the at least one second CU-to-DU message. The first OAM node and the second OAM node can be the same OAM node or different OAM nodes.

[0138] In some embodiments, the first RAN node and the second RAN node are the same RAN node (e.g., CU). In other embodiments, the first RAN node and the second RAN node are different RAN nodes. In such a case, the first RAN node may be a CU-CP and the second RAN node may be a CU-UP. In some embodiments, the third RAN node and the fourth RAN node are the same RAN node (e.g., CU). In other embodiments, the third RAN node and the fourth RAN node are different RAN nodes. In such a case, the third RAN node may be a CU-CP and the fourth RAN node may be a CU-UP. In some embodiments, the first RAN node and the third RAN node may be the same CU or CU-CP. In other embodiments, the first RAN node and the third RAN node are different CUs or CU-CPs. In some embodiments, the second RAN node and the fourth RAN node are the same CU-UP. In other embodiments, the second RAN node and the fourth RAN node are different CU-UPs.

[0139] In response to the at least one first CU-to-DU message, the DU may generate a first DRX configuration for the first DRX cycle in some embodiments. In the first DRX cycle configuration, the DU may include at least one first DRX parameter, such as a DRX on duration timer value, a DRX inactivity timer value, a DRX slot offset value, a DRX cycle start offset configuration, a DRX retransmission timer value, and / or a DRX HARQ round trip timer value. The DRX cycle start offset configuration indicates or includes a DRX cycle length and a subframe number at which the first DRX cycle starts. In some embodiments, the at least one first CU-to-DU message may include a first DRX cycle configuration for the first MBS session. The first DRX cycle configuration includes the first DRX cycle length. In some embodiments, the first DRX cycle configuration is a CU-DU interface protocol IE. In such a case, the DU configures the DRX cycle length in the DRX cycle start offset configuration as the first DRX cycle length. If at least one first CU-to-DU message does not include a DRX cycle configuration for the first MBS session, the DU configures the DRX cycle length with the DRX cycle start offset configuration as the pre-configured DRX cycle length.

[0140] In another embodiment, instead of autonomously generating the first DRX configuration, the DU receives the first DRX configuration from the first RAN node in one of the at least one first CU-to-DU message.

[0141] Similarly, in response to the at least one second CU-to-DU message, the DU can generate a second DRX configuration for the second DRX cycle in some embodiments. In the second DRX cycle configuration, the DU can include at least one second DRX parameter, such as a DRX on duration timer value, a DRX inactivity timer value, a DRX slot offset value, a DRX cycle start offset configuration, a DRX retransmission timer value, and / or a DRX HARQ round trip timer value. The DRX cycle start offset configuration indicates or includes a DRX cycle length and a subframe number at which the second DRX cycle starts. In some embodiments, the at least one first CU-to-DU message can include a second DRX cycle configuration for the first MBS session. The second DRX cycle configuration includes the second DRX cycle length. In some embodiments, the second DRX cycle configuration is a CU-DU interface protocol IE. In such a case, the DU configures the DRX cycle length in the DRX cycle start offset configuration as the second DRX cycle length. If the at least one second CU-to-DU message does not include the DRX cycle configuration, the DU configures the DRX cycle length in the DRX cycle start offset configuration as the preset DRX cycle length.

[0142] In another embodiment, instead of autonomously generating the first DRX configuration, the DU receives the second DRX configuration from the third RAN node in one of the at least one second CU-to-DU message.

[0143] In some embodiments, the first DRX cycle length and the second DRX cycle length may be the same or different. A RAN node (e.g., the first or third RAN node or the DU) may determine a DRX cycle length (e.g., the first or second DRX cycle length) according to one or more QoS configurations required for an MBS session (e.g., the first or second MBS session).

[0144] In some implementations, the at least one first DRX parameter and the at least one second DRX parameter include the same or different parameters. For example, the at least one first DRX parameter and the at least one second DRX parameter include a first on-duration of a first DRX cycle and a second on-duration of a second DRX cycle, respectively. The DU transmits MBS data of the first MBS session and MBS data of the second MBS session within the first on-duration and the second on-duration, respectively. The DU can configure the first on-duration and the second on-duration to be non-overlapping to provide sufficient radio resources for transmitting the MBS data of the first MBS session and the MBS data of the second MBS session. Meanwhile, the DU can configure the first on-duration and the second on-duration to be partially or fully overlapping to simplify the implementation of the DU and save power for UEs receiving the first MBS session and the second MBS session simultaneously.

[0145] FIG. 6B is a flow diagram of an example method 600B, which is similar to method 600A, except that the DU receives a CU-to-DU message including session IDs of two MBS sessions instead of a single MBS session.

[0146] Method 600B begins at block 603, where the DU receives a CU-to-DU message from a first RAN node, the CU-to-DU message including a first MBS session ID and a third MBS session ID for a first MBS session and a third MBS session, respectively (see, e.g., events 503, 504, 510, 513, 537, 586A-E, 591). In some implementations, the CU-to-DU message may be one of at least one first CU-to-DU message described in FIG. 6A. At block 605, the DU generates a first MBS broadcast configuration message including first MBS session information and third MBS session information for the first MBS session and the third MBS session, respectively (see, e.g., events 512, 515, 586A-E, 591). Alternatively, the DU receives the first MBS broadcast configuration message in a CU-to-DU message from the first RAN node (see, e.g., event 513). After transmitting the first MBS broadcast configuration message, the DU can receive MBS data of the first MBS session and MBS data of the third MBS session, at blocks 608 and 619, respectively. At block 610, the DU transmits MBS data of the first MBS session via one or more cells using the first MBS session information. At block 621, the DU transmits MBS data of the third MBS session via one or more cells using the third MBS session information.

[0147] In some embodiments, the third MBS session information includes a third MBS Session ID, a third G-RNTI, and / or at least one third MRB configuration. Each of the at least one third MRB configuration may include a third PDCP configuration and / or a third RLC configuration. The third MBS session information may additionally include a third DRX configuration. In some embodiments, the CU-to-DU message includes the first PDCP configuration(s) and / or the third PDCP configuration(s). In other embodiments, the CU-to-DU message does not include the first and / or third PDCP configuration(s). In such a case, the DU may receive the first and / or third PDCP configuration(s) from the first OAM node in one embodiment. In another embodiment, the first and / or third PDCP configuration(s) are preconfigured for the first and / or third MBS Session ID, respectively. That is, the DU stores the first and / or third PDCP configuration(s) before receiving the CU-to-DU message.

[0148] In response to the CU-to-DU message, the DU may, in some embodiments, generate a first DRX configuration for the first DRX cycle, as described with respect to FIG. 6A. In response to the CU-to-DU message, the DU may, in some embodiments, generate a third DRX configuration for the third DRX cycle. In the third DRX cycle configuration, the DU may include at least one third DRX parameter, such as a DRX on duration timer value, a DRX inactivity timer value, a DRX slot offset value, a DRX cycle start offset configuration, a DRX retransmission timer value, and / or a DRX HARQ round trip time timer value. The DRX cycle start offset configuration indicates or includes a DRX cycle length and a subframe number at which the third DRX cycle starts. In some embodiments, the CU-to-DU message may include the first DRX cycle configuration for the first MBS session, as described with respect to FIG. 6A. The CU-to-DU message may include the third DRX cycle configuration for the third MBS session. The third DRX cycle configuration includes a third DRX cycle length. In some embodiments, the third DRX cycle configuration is a CU-DU interface protocol IE. In such a case, the DU configures the DRX cycle length in the DRX cycle start offset configuration as the third DRX cycle length. If the CU-to-DU message does not include a DRX cycle configuration for the third MBS session, the DU configures the DRX cycle length in the DRX cycle start offset configuration as the pre-configured DRX cycle length.

[0149] In another embodiment, instead of autonomously generating the third DRX configuration, the DU receives the third DRX configuration from the first RAN node in one of the at least one first CU-to-DU message.

[0150] In some embodiments, the first DRX cycle length and the third DRX cycle length may be the same or different. A RAN node (e.g., a first RAN node or a DU) may determine a DRX cycle length (e.g., a first or third DRX cycle length) according to one or more QoS configurations required for an MBS session (e.g., a first or third MBS session).

[0151] In some implementations, the at least one first DRX parameter and the at least one third DRX parameter include the same or different parameters. For example, the at least one first DRX parameter and the at least one third DRX parameter include a first on-duration of a first DRX cycle and a third on-duration of a third DRX cycle, respectively. The DU transmits MBS data of the first MBS session and MBS data of the third MBS session within the first on-duration and the third on-duration, respectively. The DU can configure the first on-duration and the third on-duration to be non-overlapping to provide sufficient radio resources for transmitting the MBS data of the first MBS session and the MBS data of the third MBS session. Meanwhile, the DU can configure the first on-duration and the third on-duration to be partially or fully overlapping to simplify the implementation of the DU and save power for UEs receiving the first MBS session and the third MBS session simultaneously.

[0152] 7A, a CU, such as CU 172, can implement method 700A to transmit configuration parameters for transmitting MBS data for an MBS session. In some implementations, a CU-CP and a CU-UP of a CU, such as CU-CP 172A and CU-UP 172B, respectively, implement method 700A. Control plane functions that may be performed by the CU-CP are shown in the box labeled "CP" and user plane functions that may be performed by the CU-UP are shown in the box labeled "UP." These "CP" and "UP" boxes are similarly used in FIGS. 7B and 9A-9B to indicate control plane and user plane functions that may be performed by the CU-CP and CU-UP, respectively.

[0153] Method 700A begins at block 702, where a CU or CU-CP receives a first CN-to-BS message including a first MBS Session ID from a first CN node to request resources for a first MBS session (e.g., see events 502, 586A-E). At block 704, the CU or CU-CP sends at least one first CU-to-DU message including the first MBS Session ID to at least one first DU to cause the at least one first DU to broadcast a first MBS Broadcast Configuration message (e.g., see events 503, 504, 510, 513, 537, 586A-E, 591). At block 706, the CU or CU-CP sends at least one first CP-to-UP message to at least one first CU-UP to configure the at least one first CU-UP to receive MBS data of the first MBS session from the second CN and to configure the at least one first CU-UP to transmit MBS data to the at least one first DU. At block 708, the CU or CU-UP receives MBS data of the first MBS session from the second CN node (see, e.g., events 518, 548). At block 710, the CU or CU-UP transmits MBS data of the first MBS session to the at least one first DU (see, e.g., events 520, 550).

[0154] In block 712, the CU or CU-CP receives a second first CN-to-BS message including the second MBS session ID from the third CN node requesting resources for the second MBS session (e.g., see event 587). In block 714, the CU or CU-CP sends at least one second CU-to-DU message including the second MBS session ID to at least one second DU to cause the at least one second DU to broadcast a second MBS broadcast configuration message (e.g., see event 587), as described for scenario 500H. In block 716, the CU or CU-CP sends at least one second CP-to-UP message to at least one second CU-UP to configure the at least one second CU-UP to receive MBS data for the second MBS session from the fourth CN and to configure the at least one second CU-UP to transmit MBS data to the at least one second DU. At block 718, the CU or CU-UP receives MBS data for the second MBS session from the fourth CN node (e.g., see event 560). At block 720, the CU or CU-UP transmits the MBS data for the second MBS session to at least one second DU (e.g., see event 562).

[0155] The first MBS Session ID and the second MBS Session ID identify the first MBS session and the second MBS session, respectively. In some embodiments, the first CN node and the third CN node are the same CN node (e.g., AMF). In other embodiments, the first CN node and the third CN node are different CN nodes (e.g., AMF). In some embodiments, the second CN node and the fourth CN node are the same CN node (e.g., UPF). In other embodiments, the second CN node and the fourth CN node are different CN nodes (e.g., (MB-)UPF). In some embodiments, the at least one first DU and the at least one second DU may include the same DU and / or different DUs.

[0156] In some implementations, the at least one first CU-to-DU message and the at least one second CU-to-DU message are as described with respect to FIG. 6A. In some implementations, the first and second MBS broadcast configuration messages are as described with respect to FIG. 6A. In some implementations, the at least one first CU-to-DU message and the at least one second CU-to-DU message may include the first PDCP configuration(s) and the second PDCP configuration(s), respectively, as described with respect to FIG. 6A. In other implementations, the at least one first CU-to-DU message and the at least one second CU-to-DU message may include the first MRB configuration(s) and the second MRB configuration(s), respectively, as described with respect to FIG. 6A. In yet other implementations, the at least one first CU-to-DU message and the at least one second CU-to-DU message may include the first MBS session information and the second MBS session information, respectively, as described with respect to FIG. 6A.

[0157] Figure 7B is a flow diagram of an example method 700B similar to method 700A of Figure 7A, except for blocks 703, 705, 707, 719, and 721. Like method 700A, in some embodiments, the CU-CP and CU-UP of the CU implement method 700B, and example respective functions of the CU-CP and CU-UP are illustrated in Figure 7B by the boxes labeled "CP" and "UP." Additionally, like method 600B, the CU sends a CU-to-DU message that includes session IDs for the two MBS sessions.

[0158] Method 700B begins at block 703, where a CU or CU-CP receives a CN-to-BS message from a first CN node, including a first MBS Session ID and a third MBS Session ID, to request resources for the first MBS session and the third MBS session, respectively (see, e.g., events 502, 586A-E, 587). At block 705, the CU or CU-CP sends a CU-to-DU message to at least one first DU, including the first MBS Session ID and the third MBS Session ID, to cause the at least one first DU to broadcast a first MBS broadcast configuration message (see, e.g., events 503, 504, 510, 513, 537, 586A-E, 587, 591). In some implementations, the CU-to-DU message may be one of the at least one first CU-to-DU messages described in FIG. 7A. In block 707, the CU or CU-CP sends at least one first CP-to-UP message to at least one first CU-UP to configure the at least one first CU-UP to receive MBS data of the first MBS session and the third MBS session from the second CN and to configure the at least one first CU-UP to transmit MBS data to the at least one first DU. In block 719, the CU or CU-UP receives MBS data of the third MBS session from the second CN node (see, e.g., events 518, 548). In block 721, the CU or CU-UP transmits MBS data of the third MBS session to the at least one first DU (see, e.g., events 520, 550).

[0159] The first MBS Session ID and the third MBS Session ID identify the first MBS session and the third MBS session, respectively. In some implementations, the CU-to-DU message is as described with respect to FIG. 6B. In some implementations, the first MBS Broadcast Configuration message is as described with respect to FIG. 6B. In some implementations, the CU-to-DU message can include the first PDCP configuration(s) and the third PDCP configuration(s) as described with respect to FIG. 6B. In other implementations, the CU-to-DU message can include the first MRB configuration(s) and the third MRB configuration(s), respectively, as described with respect to FIG. 6B. In yet other implementations, the CU-to-DU message can include the first MBS session information and the third MBS session information, respectively, as described with respect to FIG. 6B.

[0160] 8A, a DU, such as the DU 174, can implement a method 800A to set up and later suspend or release resources for an MBS session. The method 800A begins at block 802, where the DU performs a first CU-DU procedure with a first RAN node to configure resources for the MBS session (e.g., see events 503, 504, 510, 513, 537, 586A-E, 587, 591). At block 804, the DU responds to the first CU-DU procedure by transmitting an MBS control message including MBS session information for the MBS session via one or more cells (e.g., see events 516, 517, 546, 556). For example, the MBS control message can be an MBS broadcast configuration message. At block 806, the DU receives MBS data for the MBS session from a second RAN node (e.g., see events 520, 550, 560). At block 808, the DU transmits MBS data for the MBS session via one or more cells using the MBS session information (e.g., see events 522, 552, 562). At block 810, the DU performs a second CU-DU procedure with the first RAN node to suspend or release resources for the MBS session (e.g., see events 526, 528, 527, 529, 588, 589). Flow can then proceed to either block 812 or block 814. At block 812, the DU stops transmitting MBS control messages in response to the second CU-DU procedure (e.g., see event 532). At block 814, the DU updates the MBS control message to exclude the MBS session information in response to the second CU-DU procedure (e.g., see event 533). At block 816, the DU transmits the updated MBS control message via one or more cells (e.g., see event 564).

[0161] In some implementations, the DU may decide to stop sending the MBS control message (i.e., proceed to block 812) or decide to update the MBS control message to exclude the MBS session information (i.e., proceed to block 814) depending on whether the MBS session is the last (i.e., the only) MBS session for which the DU configures resources. If the MBS session is the last MBS session, the DU may stop sending the MBS control message. If the MBS session is not the last MBS session (i.e., there are other MBS session(s) for which the DU configures resources), the DU may update the MBS control message to exclude the MBS information for the MBS session and send the updated MBS control message.

[0162] In some embodiments, the first RAN node and the second RAN node may be the same RAN node (e.g., CU), while in other embodiments, the first RAN node and the second RAN node may be a CU-CP and a CU-UP, respectively.

[0163] 8B is a flow diagram of an example method 800B similar to method 800A, except for blocks 811, 813, 818, and 820. In contrast to method 800B, in method 800A, the DU modifies resources for the MBS session. Specifically, in block 811, the DU performs a second CU-DU procedure with the first RAN node to modify resources for the MBS session. In block 813, the DU updates an MBS control message in response to the second CU-DU procedure. In block 818, the DU receives MBS data for the MBS session from the second RAN node. In block 820, the DU transmits MBS data for the MBS session via one or more cells using the (updated) MBS session information.

[0164] In some embodiments, the DU adds or modifies configuration parameters to the MBS session information as a result of the second CU-DU procedure. Thus, the DU updates the MBS control message to include the added or modified configuration parameters in block 813. In other embodiments, the DU receives the new QoS configuration(s) in the CU-to-DU message of the second CU-DU procedure. In such a case, the DU implements the new QoS configuration(s) in order to transmit MBS data of the MBS session using the (updated) MBS session in block 820.

[0165] 9A, a CU, such as CU 172, can implement method 900A to set up and later release or suspend resources for an MBS session. As described with reference to FIGS. 7A-7B, a CU-CP and a CU-UP of a CU, such as CU-CP 172A and CU-UP 172B, respectively, may implement method 900A, with exemplary respective functions of the CU-CP and CU-UP illustrated in FIG. 9A by the boxes labeled "CP" and "UP."

[0166] Method 900A begins at block 902, where a CU or CU-CP performs a first CN-BS procedure with a CN to configure resources for broadcasting an MBS session (see, e.g., events 502, 508, 586A-E). At block 904, the CU or CU-CP performs at least one first CU-DU procedure with at least one DU in response to the first CN-BS procedure to configure resources for the MBS session (see, e.g., events 503, 504, 505, 506, 510, 513, 537, 539, 586A-E, 591). At block 906, the CU or CU-CP performs at least one first CP-UP procedure with at least one CU-UP in response to the first CN-BS procedure to configure resources for the MBS session. In block 908, the CU or CU-UP receives MBS data for the MBS session from the CN (see, e.g., events 518, 548). In block 910, the CU or CU-UP transmits MBS data for the broadcast MBS session via at least one DU (see, e.g., events 520, 550). In block 912, the CU or CU-CP performs a second CN-BS procedure with the CN to release or suspend resources for the MBS session (see, e.g., events 524, 530, 525, 531, 588, 589). In block 914, the CU or CU-CP performs a second CU-DU procedure with at least one DU to release or suspend resources for the MBS session in response to the second CN-BS procedure (see, e.g., events 526, 528, 527, 529, 588, 589). In block 916, the CU or CU-CP performs at least one second CP-UP procedure using at least one CU-UP to release or suspend resources for the broadcast MBS session in response to the second CN-BS procedure.

[0167] FIG. 9B is a flow diagram of an exemplary method 900B similar to method 900A of FIG. 9A, except for blocks 913, 915, 917, 918, and 920. Additionally, similar to method 700A, in some implementations, the CU-CP and CU-UP of the CU implement method 900B, and exemplary respective functions of the CU-CP and CU-UP are illustrated in FIG. 9B by boxes labeled "CP" and "UP." In contrast to method 900B, in method 900A, the CU modifies resources for the MBS session. At block 913, the CU or CU-CP performs a second CN-BS procedure with the CN to modify resources for the MBS session (see, e.g., events 535, 541, 591). In block 915, the CU or CU-CP performs a second CU-DU procedure with at least one DU to modify resources for the MBS session in response to the second CNBS procedure (see, e.g., events 537, 539, 591). In block 917, the CU or CU-CP performs at least one second CP-UP procedure with at least one CU-UP to modify resources for the MBS session in response to the second CN-BS procedure. In block 918, the CU or CU-UP receives MBS data of the broadcast MBS session from the CN (see, e.g., event 548). In block 920, the CU or CU-UP transmits MBS data of the MBS session via at least one DU according to the modified resources (see, e.g., event 550).

[0168] 10, a DU (e.g., DU 174) of a distributed base station (e.g., base station 104 or 106) including a CU (e.g., CU 172) and a DU can implement a method 1000 for configuring a UE (e.g., UE 102) to receive MBS. The method can be implemented by processing hardware (e.g., processing hardware 130 or 140). At block 1002, the DU receives a CU-to-DU message (e.g., MBS context setup request message) from the CU that identifies an MBS session and requests that the DU configure resources for the MBS session (e.g., events 504, 503). At block 1004, in response to receiving the CU-to-DU message, the DU transmits (e.g., broadcasts) configuration parameters for receiving the MBS session to the UE (e.g., event 516). Later, the DU can receive MBS data for the MBS session from the CU and transmit the MBS data to the UE according to the configuration parameters (e.g., events 520, 522).

[0169] In some implementations, the DU generates an MBS session information element (e.g., MBS session information such as MBS-SessionInfo IE), includes the configuration parameters in the MBS session information element, and transmits the configuration parameters to the UE by transmitting the MBS session information element to the UE (e.g., events 512, 515, and 516 of FIG. 5A, 5B, and 5E). In such implementations, the DU may receive a PDCP configuration from the CU (e.g., in the CU-to-DU message received in block 1002 (e.g., event 504), or in a second CU-to-DU message after receiving the CU-to-DU message in block 1002 (event 510)) and include the PDCP configuration in the MBS session information element. Alternatively, the DU may retrieve a PDCP configuration preconfigured in the DU and include the PDCP configuration in the MBS session information element (e.g., event 515). Additionally, the DU may receive DRX configuration and / or MBS neighbor cell information from the CU and include the DRX configuration and / or MBS neighbor cell information in the MBS session information element. Depending on the embodiment, the DU may generate an RLC configuration and / or a group temporary identifier (e.g., G-RNTI) and include the RLC configuration and / or the group temporary identifier in the MBS session information element. The CU-to-DU message may include a session identifier (ID) that identifies the MBS session, and the DU may include the session ID in the MBS session information element.

[0170] In other embodiments, the DU may receive an MBS session information element including the configuration parameters from the CU prior to transmitting the configuration parameters, and transmit the configuration parameters to the UE by transmitting the MBS session information element (e.g., events 513, 516 in FIG. 5C and FIG. 5D). In such embodiments, the DU may transmit information to the CU for inclusion in the MBS session information element, such as an RLC configuration and / or a group temporary identifier associated with the MBS session. The DU may transmit the information in a DU-to-CU message in response to the CU-to-DU message (e.g., event 505) or in a second DU-to-CU message (e.g., event 509). Furthermore, in such embodiments, the DU may (i) receive an MBS broadcast configuration message (e.g., MBS Broadcast Configuration message) including the MBS session information element from the CU and transmit the MBS broadcast configuration message to the UE, or (ii) receive an MBS session information element from the CU, generate an MBS configuration broadcast message including the MBS session information element, and transmit the MBS broadcast configuration message to the UE.

[0171] Depending on the scenario, method 1000 may also include configuring resources for multiple MBS sessions. The CU-to-DU message that the DU receives in block 1002 (i.e., a first CU-to-DU message identifying a first MBS session and requesting that the DU configure first resources for the first MBS session) may identify a second MBS session and request that the DU configure second resources for the second MBS session (e.g., by including a first session ID of the first MBS session and a second session ID of the second MBS session), or the DU may receive a second CU-to-DU message after receiving the CU-to-DU message in block 1002, the second CU-to-DU message identifying a second MBS session and requesting that the DU configure second resources for the second MBS session (e.g., by including a second session ID of the second MBS session) (e.g., event 587). To transmit the second configuration parameters, the DU may transmit the first configuration parameters along with the second parameters (e.g., by transmitting the first MBS session information element and the second MBS session information element in an MBS broadcast configuration message) (e.g., event 556). When the DU later receives a CU-to-DU message indicating that the DU releases or suspends the first resources for the first MBS session, the DU may transmit an MBS broadcast message that includes the second MBS session information and excludes the first MBS session information element (e.g., event 564).

[0172] The DU may receive a notification from the CU to release, suspend, or modify resources for the MBS session. For example, the DU may receive a request from the CU to release resources for the MBS session (e.g., event 526). In response, the DU may stop transmitting configuration parameters (e.g., event 532). As another example, the DU may receive a request from the CU to suspend resources for the MBS session (e.g., event 527), and the DU may stop transmitting configuration parameters in response. The DU may retain the configuration parameters and may resume transmitting the configuration parameters in response to receiving a request from the CU to resume resources for the MBS session (e.g., events 536, 542). In yet another embodiment, the DU may receive a request from the CU to modify resources for the MBS session, modify the configuration parameters according to the request, and transmit the modified configuration parameters to the UE (e.g., events 537, 517).

[0173] 11, a CU (e.g., CU 172) of a distributed base station (e.g., base station 104 or 106) including a DU (e.g., DU 174) and a CU can implement a method 1100 for configuring a UE (e.g., UE 102) to receive MBS. The method can be implemented by processing hardware (e.g., processing hardware 130 or 140). At block 1102, the CU receives a CN-to-BS message from a CN requesting that the distributed base station configure resources for an MBS session (e.g., event 502). At block 1104, the CU sends a CU-to-DU message to the DU identifying the MBS session and causing the DU to send configuration parameters for receiving the MBS session to the UE (e.g., events 504, 503, 510, 513).

[0174] The following list of examples reflects various embodiments expressly contemplated by this disclosure.

[0175] Example 1. A method for configuring a user equipment (UE) to receive a multicast and / or broadcast service (MBS), implemented in a distributed unit (DU) of a distributed base station including a central unit (CU) and a distributed unit (DU), comprising: receiving, by processing hardware of the DU, a CU-to-DU message from the CU identifying an MBS session and requesting that the DU configure resources for the MBS session; and in response to receiving the CU-to-DU message, transmitting, by the processing hardware, configuration parameters for receiving the MBS session to the UE.

[0176] Example 2. The method of example 1, further comprising: generating an MBS session information element; and including the configuration parameters in the MBS session information element; and transmitting the configuration parameters comprises transmitting the MBS session information element.

[0177] Example 3. The method of example 2, further comprising receiving a Packet Data Convergence Protocol (PDCP) configuration from the CU by the processing hardware, and generating the MBS session information element comprises including the PDCP configuration in the MBS session information element.

[0178] Example 4. The method of example 3, wherein receiving the PDCP configuration includes receiving the PDCP configuration in the CU-to-DU message.

[0179] Example 5. The method of example 3, wherein the CU-to-DU message is a first CU-to-DU message, and receiving the PDCP configuration includes receiving a second CU-to-DU message after receiving the first CU-to-DU message, the second CU-to-DU message including the PDCP configuration.

[0180] Example 6. The method of example 2, further comprising retrieving, by the processing hardware, a Packet Data Convergence Protocol (PDCP) configuration preconfigured in the DU, and generating the MBS session information element comprises including the PDCP configuration in the MBS session information element.

[0181] Example 7. The method of any one of Examples 2 to 6, further comprising receiving, by the processing hardware, from the CU a discontinuous reception (DRX) configuration along with the PDCP configuration, and generating the MBS session information element comprises including the DRX configuration in the MBS session information element.

[0182] Example 8. The method of any one of Examples 2 to 7, further comprising generating a radio link control (RLC) configuration, wherein generating the MBS session information element comprises including the RLC configuration in the MBS session information element.

[0183] Example 9. A method according to any one of Examples 2 to 8, further comprising generating a group temporary identifier associated with the MBS session, wherein generating the MBS session information element comprises including the group temporary identifier in the MBS session information element.

[0184] Example 10. A method according to any one of Examples 2 to 9, wherein receiving the CU-to-DU message includes receiving the CU-to-DU message including a session identifier (ID) that identifies the MBS session, and generating the MBS session information element includes including the session identifier in the MBS session information element.

[0185] Example 11. The method of example 1, further comprising receiving, by the processing hardware from the CU, an MBS session information element including the configuration parameters, before transmitting the configuration parameters, and transmitting the configuration parameters comprises transmitting the MBS session information element.

[0186] Example 12. The method of example 11, further comprising transmitting, by the processing hardware to the CU, information for inclusion in the MBS session information element.

[0187] Example 13. The method of example 12, wherein transmitting the information includes transmitting a radio link control (RLC) configuration.

[0188] Example 14. The method of example 12 or 13, wherein transmitting the information includes transmitting a group temporary identifier associated with the MBS session.

[0189] Example 15. The method according to any one of Examples 12 to 14, wherein transmitting the information includes transmitting the information in a DU-to-CU message in response to the CU-to-DU message.

[0190] Example 16. A method according to any one of Examples 12 to 14, further comprising transmitting a first DU-to-CU message to the CU by the processing hardware in response to the CU-to-DU message, and transmitting the information comprises transmitting the information in a second DU-to-CU message after transmitting the first DU-to-CU message.

[0191] Example 17. A method according to any one of Examples 11 to 16, wherein receiving the MBS session information element from the CU includes receiving an MBS broadcast configuration including the MBS session information element, and transmitting the MBS session information element includes transmitting the MBS broadcast configuration message.

[0192] Example 18. A method according to any one of Examples 2 to 16, wherein transmitting the MBS session information element includes generating an MBS broadcast configuration message including the MBS session information element, and transmitting the MBS broadcast configuration message to the UE.

[0193] Example 19. The method of example 17 or 18, wherein sending the MBS broadcast configuration message includes sending an MBS Broadcast Configuration message.

[0194] Example 20. The method of any one of the preceding examples, wherein the CU-to-DU message is a first CU-to-DU message identifying a first MBS session and requesting that the DU configure first resources for the first MBS session, and the configuration parameters are first configuration parameters, and the method further includes receiving, by the processing hardware, from the CU, a second CU-to-DU message identifying a second MBS session and requesting that the DU configure second resources for the second MBS session, and transmitting, by the processing hardware, to the UE in response to receiving the second CU-to-DU message, second configuration parameters for receiving the second MBS session.

[0195] Example 21. The method of example 20, wherein transmitting the second configuration parameter includes transmitting the first configuration parameter together with the second configuration parameter.

[0196] Example 22. The method of example 20 or 21, wherein receiving the second CU-to-DU message includes receiving the second CU-to-DU message including a session identifier (ID) that identifies the second MBS session.

[0197] Example 23. The method of any one of Examples 1 to 19, wherein the MBS session is a first MBS session, the resource is a first resource, and the configuration parameter is a first configuration parameter, receiving the CU-to-DU message includes receiving the CU-to-DU message further identifying a second MBS session and further requesting that the DU configure a second resource for the second MBS session, and transmitting the configuration parameters includes transmitting the first configuration parameter together with the second configuration parameter for receiving the second MBS session.

[0198] Example 24. The method of Example 23, wherein receiving the CU-to-DU message includes receiving the CU-to-DU message including a first session identifier (ID) that identifies the first MBS session and a second session ID that identifies the second MBS session.

[0199] Example 25. The method of any one of Examples 21, 23, or 24, wherein transmitting the first configuration parameter together with the second configuration parameter includes transmitting a first MBS session information element including the first configuration parameter together with a second MBS session information element including the second configuration parameter.

[0200] Example 26. The method of Example 25, wherein transmitting the first MBS session information element together with the second MBS session information element includes transmitting an MBS broadcast configuration message including the first MBS session information element and the second MBS session information element.

[0201] Example 27. The method of Example 26, further comprising: receiving, by the processing hardware, from the CU, a third CU-to-DU message requesting that the DU release or suspend the first resource for the first MBS session; modifying, by the processing hardware, the MBS broadcast configuration message to exclude the first MBS session information element; and transmitting, by the processing hardware, the MBS broadcast configuration message to the UE, the MBS broadcast configuration message including the second MBS session information element and excluding the first MBS session information element.

[0202] Example 28. A method according to any one of Examples 1 to 26, further comprising receiving, by the processing hardware, a request from the CU to release the resources for the MBS session, and stopping, by the processing hardware, the transmission of the configuration parameters.

[0203] Example 29. The method of example 28, further comprising releasing, by the processing hardware, the configuration parameters.

[0204] Example 30. A method according to any one of Examples 1 to 26, further comprising receiving, by the processing hardware, a request from the CU to suspend the resources for the MBS session, and stopping, by the processing hardware, the transmission of the configuration parameters.

[0205] Example 31. The method of example 30, further comprising maintaining, by the processing hardware, the configuration parameters.

[0206] Example 32. A method as described in Example 30 or 31, wherein the request is a first request, and the method further includes receiving a request from the CU by the processing hardware to resume the resources for the MBS session and to resume transmission of the configuration parameters by the processing hardware.

[0207] Example 33. A method according to any one of Examples 1 to 26, further comprising receiving, by the processing hardware, a request to modify the resources for the MBS session, modifying, by the processing hardware, the configuration parameters in accordance with the request, and transmitting, by the processing hardware, the modified configuration parameters.

[0208] Example 34. The method of any one of the preceding examples, wherein receiving the CU-to-DU message includes receiving an MBS context setup request message.

[0209] Example 35. The method of any one of the preceding examples, wherein transmitting the configuration parameters includes broadcasting the configuration parameters to a plurality of UEs, the plurality of UEs including the UE.

[0210] Example 36. A method according to any one of the preceding examples, further comprising receiving, by the processing hardware, MBS data for the MBS session from the CU, and transmitting, by the processing hardware, the MBS data to the UE in accordance with the configuration parameters.

[0211] Example 37. A method for configuring a user equipment (UE) to receive a multicast and / or broadcast service (MBS), implemented in a distributed unit (DU) and a central unit (CU) of a distributed base station including the CU, comprising: receiving a CN-to-BS message from a core network (CN) by processing hardware of the CU, requesting that the distributed base station configure resources for an MBS session; and sending a CU-to-DU message by the processing hardware to the DU, identifying the MBS session, to cause the DU to send configuration parameters for receiving the MBS session to the UE.

[0212] Example 38. The method of Example 37, further comprising transmitting a Packet Data Convergence Protocol (PDCP) configuration to the DU by the processing hardware to cause the DU to include the PDCP configuration in the configuration parameters.

[0213] Example 39. The method of Example 38, wherein transmitting the PDCP configuration includes transmitting the PDCP configuration in the CU-to-DU message.

[0214] Example 40. The method of Example 38, wherein the CU-to-DU message is a first CU-to-DU message, and sending the PDCP configuration includes sending a second CU-to-DU message including the PDCP configuration to the DU after sending the first CU-to-DU message.

[0215] Example 41. The method of any one of Examples 38 to 40, wherein transmitting the PDCP configuration includes transmitting a discontinuous reception (DRX) configuration together with the PDCP configuration to cause the DU to include the DRX configuration in the configuration parameters.

[0216] Example 42. The method of Example 37, further comprising: generating, by the processing hardware, an MBS session information element; including, by the processing hardware, the configuration parameters in the MBS session information element; and transmitting, by the processing hardware, the MBS session information element to the DU.

[0217] Example 43. The method of example 42, further comprising: generating, by the processing hardware, a Packet Data Convergence Protocol (PDCP) configuration; and including, by the processing hardware, the PDCP configuration in the configuration parameters.

[0218] Example 44. The method of example 42 or 43, further comprising: generating, by the processing hardware, a discontinuous reception (DRX) configuration; and including, by the processing hardware, the DRX configuration in the configuration parameters.

[0219] Example 45. A method according to any one of Examples 42 to 44, further comprising: generating, by the processing hardware, an MBS broadcast configuration message including the MBS session information element; and transmitting, by the processing hardware, the MBS broadcast configuration message to the DU.

[0220] Example 46. A method according to any one of Examples 42 to 45, further comprising receiving information for inclusion in the MBS session information element from the DU by the processing hardware, and generating the MBS session information element comprises including the information in the MBS session information element.

[0221] Example 47. The method of example 46, wherein receiving the information includes receiving a radio link control (RLC) configuration.

[0222] Example 48. The method of example 46 or 47, wherein receiving the information includes receiving a group temporary identifier associated with the MBS session.

[0223] Example 49. The method of any one of Examples 46 to 48, wherein receiving the information includes receiving the information in a DU-to-CU message in response to the CU-to-DU message.

[0224] Example 50. A method according to any one of Examples 46 to 48, further comprising: receiving, by the processing hardware, a first DU-to-CU message in response to the CU-to-DU message; and receiving, by the processing hardware, a second DU-to-CU message including the information after receiving the first DU-to-CU message.

[0225] Example 51. A method according to any one of Examples 37 to 50, wherein the CN-to-BS message is a first CN-to-BS message requesting that the distributed base station configure first resources for a first MBS session, the CU-to-DU message is a first CU-to-DU message, and the configuration parameters are first configuration parameters, and the method further includes receiving, by the processing hardware, a second CN-to-BS message requesting that the distributed base station configure second resources for a second MBS session, and sending, by the processing hardware, a second CU-to-DU message to the UE to cause the DU to send second configuration parameters for receiving the second MBS session.

[0226] Example 52. The method of Example 51, wherein receiving the second CN-to-BS message includes receiving the second CN-to-BS message including a session identifier (ID) that identifies the second MBS session, and transmitting the second CU-to-DU message includes transmitting the second CU-to-DU message including the session ID that identifies the second MBS session.

[0227] Example 53. The method of any one of Examples 37 to 50, wherein the MBS session is a first MBS session, the CN-to-BS message is a first CN-to-BS message, the resource is a first resource, and the configuration parameter is a first configuration parameter, receiving the CN-to-BS message includes receiving the CN-to-BS message further requesting that the distributed base station configure a second resource for a second MBS session, and sending the CU-to-DU message includes sending the CU-to-DU message that further identifies the second MBS session to cause the DU to send the first configuration parameter together with a second configuration parameter for receiving the second MBS session.

[0228] Example 54. The method of Example 53, wherein receiving the CN-to-BS message includes receiving the CN-to-BS message including a first session identifier (ID) identifying the first MBS session and a second session ID identifying the second MBS session, and transmitting the CU-to-DU message includes transmitting the CU-to-DU message including the first session ID and the second session ID.

[0229] Example 55. The method of any one of Examples 37 to 54, further comprising sending, by the processing hardware, to the DU a request to release or suspend the resources for the MBS session.

[0230] Example 56. The method of any one of Examples 37 to 54, further comprising sending, by the processing hardware to the DU, a request to modify the resources for the MBS session.

[0231] Example 57. The method of example 55 or 56, wherein sending the request includes sending the request in response to receiving a message from the CN.

[0232] Example 58. A method according to any one of Examples 37 to 57, further comprising receiving MBS data for the MBS session from the CN by the processing hardware, and transmitting the MBS data to the DU by the processing hardware.

[0233] Example 59. The method of Example 58, further comprising sending a CP-to-UP message by a control plane (CP) logical node of the central unit to a user plane (UP) logical node of the central unit to configure the UP logical node to receive the MBS data from the CN and to transmit the MBS data to the DU.

[0234] Example 60. The method of any one of Examples 37 to 59, wherein sending the CU-to-DU message includes sending an MBS context setup request message.

[0235] Example 61. A method according to any one of Examples 37 to 60, wherein transmitting the CU-to-DU message includes transmitting the CU-to-DU message including a session identifier (ID) that identifies the MBS session.

[0236] Example 62. A network node comprising processing hardware and configured to implement the method according to any one of the preceding examples.

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

[0238] In some embodiments, a "message" is used and can be replaced with an "information element (IE)" or vice versa. In some embodiments, an "IE" is used and can be replaced with a "field" or vice versa. In some embodiments, a "configuration" is replaced with a "multiple configurations" or a configuration parameter. In some embodiments, an "MBS" is replaced with a "multicast" or a "broadcast". The messages described in the above events are examples and should not limit the applicability of the present invention. In some embodiments, a message sent from a CU to a DU can be generalized as a CU-to-DU message, and a message sent from a DU to a CU can be generalized as a DU-to-CU message. In some embodiments, the CU-to-DU message and the DU-to-CU message can be an F1AP message. In some embodiments, a message sent from a CU-CP to a CU-UP can be generalized as a CP-to-UP message, and a message sent from a CU-UP to a CU-CP can be generalized as a UP-to-CP message. In some embodiments, the CP-to-UP message and the UP-to-CP message can be an E1 Application Protocol (E1AP) message.

[0239] A user device (e.g., UE 102 or 103) capable of implementing the techniques of this disclosure may be any suitable device capable of wireless communication, such as a smartphone, a tablet computer, a laptop computer, a mobile game console, a point of sale (POS) terminal, a health management device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smart watch, a wireless hotspot, a femtocell, or a broadband router. Furthermore, the user device may in some cases be embedded in an electronic system such as a vehicle's head unit or an advanced driver assistance system (ADAS). Still further, the user device may operate as an Internet of Things (IoT) device or a Mobile Internet Device (MID). Depending on the type, the 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.

[0240] Certain embodiments are described herein as including logic, or some components, modules, or mechanisms. A module may be a software module (e.g., code stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit that can perform certain operations and may be configured or arranged in a certain manner. A hardware module may include dedicated circuitry or logic that is permanently configured (e.g., as a field programmable gate array (FPGA) or a special purpose processor such as an application specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also include programmable logic or circuitry that is temporarily configured by software (e.g., contained within a general purpose processor or other programmable processor) to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry or in temporarily configured circuitry (e.g., configured by software) may be subject to cost and time considerations.

[0241] If 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 executable by one or more general-purpose processors or one or more special-purpose processors.

[0242] After reading this disclosure, those skilled in the art will appreciate further alternative structural and functional designs for communicating MBS information through the principles disclosed in this disclosure. Thus, while specific embodiments and applications have been shown 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 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 of the appended claims.

Claims

1. 1. A method for configuring a user equipment (UE) to receive a multicast and / or broadcast service (MBS), the method being implemented in a central unit (CU) and a distributed unit (DU) of a distributed base station, the method comprising: receiving, by a processing hardware of the DU, from the CU, an MBS context setup request for the MBS session, the DU requesting that the DU configure resources for the MBS session, the MBS context setup request including a Packet Data Convergence Protocol (PDCP) configuration; sending, by the processing hardware to the UE in response to receiving the MBS context setup request, configuration parameters for receiving the MBS session, including at least the PDCP configuration; A method comprising:

2. generating an MBS session information element; including said configuration parameters in said MBS session information element; Further comprising: transmitting the configuration parameters, transmitting the MBS session information element; The method of claim 1.

3. receiving the MBS context setup request includes receiving the MBS context setup request including a session identifier (ID) that identifies the MBS session; generating the MBS session information element includes including the session identifier in the MBS session information element. The method of claim 2.

4. and receiving, by the processing hardware, from the CU, an MBS session information element including at least some of the configuration parameters, before transmitting the configuration parameters; transmitting the configuration parameters includes transmitting the MBS session information element. The method of claim 1.

5. The method of claim 4 , further comprising transmitting, by the processing hardware, to the CU, information for inclusion in the MBS session information element.

6. receiving, by the processing hardware, from the CU a request to release the resources for the MBS session; ceasing, by said processing hardware, transmission of said configuration parameters; The method of any one of claims 1 to 5, further comprising:

7. The method of claim 6 , further comprising releasing, by the processing hardware, the configuration parameters.

8. receiving, by the processing hardware, a request to modify the resources for the MBS session; modifying, by said processing hardware, said configuration parameters in accordance with said request; transmitting, by the processing hardware, the modified configuration parameters; The method of any one of claims 1 to 5, further comprising:

9. A method for configuring a user equipment (UE) to receive a multicast and / or broadcast service (MBS), the method being implemented in a central unit (CU) of a distributed base station including a distributed unit (DU) and a central unit (CU), the method comprising: receiving, by processing hardware of the CU, a CN-to-BS message from a core network (CN) requesting that the distributed base station configure resources for an MBS session; sending an MBS context setup request to the DU, the MBS session being identified and including a Packet Data Convergence Protocol (PDCP) configuration, to cause the DU to send configuration parameters for receiving the MBS session, including the PDCP configuration, to the UE; A method comprising:

10. generating, by said processing hardware, an MBS session information element; including, by said processing hardware, at least some of said configuration parameters in said MBS session information element; transmitting, by the processing hardware, the MBS session information element to the DU; The method of claim 9 further comprising:

11. generating, by said processing hardware, an MBS broadcast configuration message including said MBS session information element; transmitting the MBS broadcast configuration message to the DU by the processing hardware; The method of claim 10 further comprising:

12. receiving, by the processing hardware, information from the DU for inclusion in the MBS session information element; generating the MBS session information element includes including the information in the MBS session information element.

12. The method according to claim 10 or 11.

13. The method of claim 12 , wherein receiving the information includes receiving the information in a DU-to-CU message after receiving the MBS context setup request.

14. The method of any one of claims 9 to 13, further comprising sending, by the processing hardware to the DU, a request to release, modify or suspend the resources for the MBS session.

15. 15. The method of claim 9, further comprising: sending a CP-to-UP message by a control plane (CP) logic node of the central unit to a user plane (UP) logic node of the central unit to receive MBS data from the CN and to configure the UP logic node to transmit the MBS data to the DU.

16. A network node comprising processing hardware and configured to implement the method according to any one of claims 1 to 15.

Images