Configuring resources for multicast and / or broadcast services in a distributed base station architecture

Abstract

The objective of the present invention is to provide a configuration of resources for multicast and / or broadcast services in a distributed base station architecture. [Solution] A distributed base station comprising a central unit (CU) and distributed units (DUs) provides a method for configuring user equipment (UE) to receive multicast and / or broadcast services (MBS), the DU receiving a CU-to-DU message from the CU that identifies an MBS session and requests the DU to configure resources for the MBS session (1002), and in response to receiving the CU-to-DU message, transmitting configuration parameters to the UE for receiving the MBS session (1004).

Description

Technical Field

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

Background Art

[0002] The description of the background provided herein is for the purpose of generally presenting the context of the present disclosure. Aspects of the description that include the current research of the inventors named and that may not qualify as prior art at the time of filing are not admitted as prior art to the present disclosure, either expressly or implicitly.

[0003] In telecommunications systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as the transfer, encryption, and integrity protection of user plane data. For example, the PDCP sublayer defined for the Evolutionary Universal Terrestrial Radio Access (EUTRA) radio interface (see the 3rd Generation Partnership Project (3GPP®) specification, TS36.323) and New Radio (NR) (see the 3GPP® specification, TS38.323) provides the ordering of protocol data units (PDUs) in the uplink direction from the user device (also known as user equipment or "UE") to the base station and in the downlink direction from the base station to the 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 Adaptive Protocol (SDAP) sublayer or to protocol layers such as the Internet Protocol (IP) layer, the Ethernet Protocol layer, and the Internet Control Message Protocol (ICMP) layer. Generally speaking, UEs and base stations can use SRB to exchange RRC messages and non-access layer (NAS) messages, and use DRB to transmit data on the user plane.

[0004] In several scenarios, a UE can simultaneously utilize the resources of multiple nodes in a backhaul-interconnected radio access network (RAN) (e.g., components of a base station, distributed base station, or disaggregated base station) in so-called dual connectivity (DC) operation. These network nodes may all be nodes using the same radio access technology (RAT), or they 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, a cell(s) associated with a base station acting as a master node (MN) defines a master cell group (MCG), and a cell associated with a base station acting as a secondary node (SN) defines a secondary cell group (SCG). An MCG covers a primary cell (PCell) and 0, 1, or more secondary cells (SCells), and an SCG covers a primary secondary cell (PSCell) and 0, 1, or more 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. In SC, the UE communicates only with the MN via the MCG. The base station and / or UE decide when the UE should establish a radio connection with other base stations. For example, a base station can 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 other RAN nodes interconnected in the backhaul (e.g., base stations, or components of distributed or disaggregated base stations).

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

[0006] Regardless of whether it is in SC or DC operation, the UE can perform handover procedures to switch from one cell to another. These procedures involve messaging between the RAN node and the UE (e.g., RRC signaling and preparation). Depending on the scenario, the UE may hand over from a service-providing base station's cell to a target cell of a target base station, or from a first distributed unit (DU) of a service-providing base station to a target cell of a second DU of the same base station. In a DC scenario, the UE can change a PSCell by performing a PSCell change procedure. These procedures involve messaging between the RAN node and the UE (e.g., RRC signaling and preparation). Depending on the scenario, the UE may perform a PSCell change from a service-providing SN's PSCell to a target SN's target PSCell, or from a base station's source DU's PSCell to a target DU of the same base station. Furthermore, the UE may perform a handover or PSCell change within a cell for synchronous reconfiguration.

[0007] Base stations operating in accordance with the new fifth-generation (5G) radio (NR) requirements support significantly larger bandwidths than fourth-generation (4G) base stations. Therefore, the Third 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 2 (FR2). Because typical carrier bandwidths are relatively wide in 5G NR, 3GPP® proposes for Release 17 that 5G NR base stations can provide multicast and / or broadcast services (MBS) to UEs. MBS can be useful in many content delivery applications, including transparent IPv4 / IPv6 multicast distribution, IPTV, software distribution over the radio, group communications, Internet of Things (IoT) applications, V2X applications, and emergency messaging related to public safety.

[0008] 5G NR provides both point-to-point (PTP) and point-to-multipoint (PTM) delivery methods for transmitting MBS packet flows over the radio interface. In PTP communication, a RAN node sends different copies of each MBS data packet to different UEs over the radio interface, while in PTM communication, a RAN node sends a single copy of each MBS data packet to multiple UEs over the radio interface. However, in some scenarios, it is unclear how distributed base stations configure their resources to transmit MBS data packets via broadcast. [Overview of the project]

[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 multicast and / or broadcast services (MBS). The CU may, for example, receive a message from the core network (CN) requesting that a distributed base station set up resources for an MBS session. In response, the CU may identify the MBS session (for example, using a session identifier (ID) corresponding to the session) and send a CU-to-DU message (e.g., an MBS context setup request message) to the DU requesting that the DU configure resources for the MBS session. The DU may then send an MBS broadcast configuration message to a UE containing a list of one or more MBS sessions and MBS session information for each MBS session (or, more specifically, broadcast an MBS broadcast configuration message to one or more UEs). MBS session information for an MBS session includes configuration parameters that enable the UE to receive MBS data for the MBS session, such as the Packet Data Convergence Protocol (PDCP) configuration, Radio Link Control (RLC) configuration, Intermittent Reception (DRX) configuration, Group Radio Network Temporary Identifier (G-RNTI), and / or the session ID of the MBS session, which are associated with the MBS session.

[0010] Depending on the embodiment, a CU or DU may generate MBS broadcast configuration messages or MBS session information. In some embodiments, the DU generates both MBS session information and MBS broadcast configuration messages. The DU may receive configurations from the CU that are associated with the layers operated by the CU, and may 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 then generates information such as G-RNTI and RLC configurations at the layers operated by the DU, and may include such information in the MBS session information.

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

[0012] As described above, an MBS broadcast configuration message may contain MBS session information for multiple MBS sessions. To request resources for a second MBS session, the CU may send a second CU-to-DU message to the DU identifying the second MBS session, or the CU may send a single CU-to-DU message identifying both the first and second MBS sessions. The DU can then send MBS broadcast configuration information containing 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 (for example, in response to a request from the CN), the CU sends a request to the DU. In response, the DU may stop sending the first MBS session information and instead send an MBS broadcast configuration message excluding the first MBS session information and including the second MBS session information. The CU can also request that the DU correct the information for the MBS session, in which case the DU can update the MBS session information for the MBS session accordingly and send an MBS broadcast configuration message containing the updated MBS session information.

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

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

[0015] Another exemplary embodiment of these technologies is a network node comprising processing hardware and configured to implement any one of the methods described above. [Brief explanation of the drawing]

[0016] [Figure 1A] This is a block diagram of an exemplary system that can implement the technology of this disclosure for managing MBS resources. [Figure 1B] This is a block diagram of an exemplary base station in which a central unit (CU) and distributed units (DUs) can operate in the system shown in Figure 1A. [Figure 2A] Figure 1A shows a block diagram of an exemplary protocol stack that allows the UE to communicate with the base station in Figure 1A. [Figure 2B]Figure 1A is a block diagram of an exemplary protocol stack in which the UE can communicate with the DU and CU of the base station. [Figure 3] This block diagram shows an exemplary tunnel architecture for MBS and PDU sessions. [Figure 4] This block shows exemplary MRBs and DRBs that distributed base stations can be configured to communicate multicast, broadcast, and / or unicast traffic with UEs. [Figure 5A] This is a messaging diagram of an exemplary scenario in which the CN and distributed base stations configure resources to transmit MBS session data for multiple UEs via broadcast, where the DU generates MBS session information using the 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] This is a messaging diagram for an exemplary scenario similar to the scenario in Figure 5A, but where the DU receives the PDCP configuration in a CU-to-DU message after receiving the MBS context setup request message. [Figure 5C] This is a messaging diagram for an exemplary scenario, similar to the scenario in Figure 5A, but in which the CU generates MBS session information using the radio link control (RLC) configuration received from the DU in the MBS context setup response message, and then sends the MBS session information to the DU. [Figure 5D] This is a messaging diagram for an exemplary scenario similar to the scenario in Figure 5C, but where the CU receives the RLC configuration in a DU-to-CU message after receiving the MBS context setup response message. [Figure 5E] This is a messaging diagram for an exemplary scenario similar to the scenario in Figure 5A, but where the DU generates MBS session information without receiving the PDCP configuration from the CU. [Figure 5F]A messaging diagram of an exemplary scenario where a distributed base station may later release resources for an MBS session, which may be similar to any one of the scenarios shown in FIGS. 5A to 5E. [Figure 5G] A messaging diagram of an exemplary scenario where a distributed base station may also later suspend and resume resources for an MBS session, which may be similar to any one of the scenarios shown in FIGS. 5A to 5E. [Figure 5H] A messaging diagram of an exemplary scenario where a distributed base station may also configure resources for transmitting MBS data of another MBS session via broadcast and later release resources for the initial MBS session, which may be similar to any one of the scenarios shown in FIGS. 5A to 5E. [Figure 5I] A messaging diagram of an exemplary scenario where a distributed base station may later modify resources for an MBS session, which may be similar to any one of the scenarios shown in FIGS. 5A to 5E. [Figure 6A] A flowchart of an exemplary method for configuring resources for one or more MBS sessions that can be implemented in a DU, where the DU receives a session identifier (ID) for each of the one or more MBS sessions in each CU-to-DU message. [Figure 6B] A flowchart of an exemplary method that is similar to the method of FIG. 6A, but where the DU receives the session IDs of each of the one or more MBS sessions in a single CU-to-DU message. [Figure 7A] A flowchart of an exemplary method for configuring resources for one or more MBS sessions that can be implemented in a CU, where the CU transmits a session identifier (ID) for each of the one or more MBS sessions in each CU-to-DU message. [Figure 7B] A flowchart of an exemplary method that is similar to the method of FIG. 7A, but where the CU transmits the session IDs of each of the one or more MBS sessions in a single CU-to-DU message. [Figure 8A]FIG. is a flowchart of an exemplary method for suspending or releasing resources for an MBS session implementable at a DU. [Figure 8B] FIG. is a flowchart of an exemplary method for modifying resources for an MBS session implementable at a DU. [Figure 9A] FIG. is a flowchart of an exemplary method for suspending or releasing resources for an MBS session implementable at a CU. [Figure 9B] FIG. is a flowchart of an exemplary method for modifying resources for an MBS session implementable at a CU. [Figure 10] FIG. is a flowchart of an exemplary method for configuring resources for MBS implementable at a DU. [Figure 11] FIG. is a flowchart of an exemplary method for configuring resources for an MBS session implementable at a CU.

MODE FOR CARRYING OUT THE INVENTION

[0017] Generally speaking, the RAN and / or CN implement the techniques of the present disclosure to manage the transmission of multicast and / or broadcast services (MBS). The CN can request that the base station configure a common downlink (DL) tunnel, and through the DL tunnel, the CN can transmit MBS data for an MBS session to the base station for a plurality of UEs. In response to the request, the base station transmits 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] A base station can also configure one or more logical channels toward UEs and / or one or more MBS radio bearers (MRBs) associated with an MBS session, and there may be a one-to-one mapping between each logical channel and each MRB. After receiving MBS data for an MBS session via a common DL tunnel, the base station can 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 MBS data to multiple UEs via a single logical channel. Furthermore, if there are multiple quality of service (QoS) flows for an 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 a UE joins an MBS session. If additional UEs join the MBS session after the tunnel has been configured, the CN can use the same common DL tunnel to transmit MBS data to the base station for the multiple UEs.

[0020] Figure 1A shows an exemplary wireless communication system 100 capable of implementing the techniques of this disclosure for managing the transmission and reception of multicast and / or broadcast service (MBS) information. The wireless communication system 100 includes user equipment (UEs) 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 specified. In other embodiments or scenarios, the wireless communication system 100 may instead include more or fewer UEs and / or more or fewer base stations than shown in Figure 1A. Base stations 104, 106 may be any suitable one or more types of base stations, such as evolved node B (eNB), next-generation eNB (ng-eNB), or 5G node B (gNB). As a more specific example, base station 104 may be an eNB or a gNB, and base station 106 may be a gNB.

[0021] Base station 104 supports cell 124, and base station 106 supports cell 126. Because cell 124 partially overlaps with cell 126, UE102A can be within range of communicating with base station 104 while simultaneously being within range of communicating with base station 106 (or detecting or measuring signals from base station 106). This overlap allows UE102A to perform inter-cell (e.g., from cell 124 to cell 126) or inter-base station (e.g., from base station 104 to base station 106) handovers before experiencing, for example, a radio link failure. Furthermore, the overlap enables various dual connectivity (DC) scenarios. For example, UE102A can communicate with base station 104 (acting as a master node (MN)) and base station 106 (acting as a secondary node (SN)) in a DC. When UE102A is in DC relationship with base stations 104 and 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, UE102A can use radio bearers (e.g., DRB or SRB) that terminate at MN (e.g., base station 104) or SN (e.g., base station 106) at different times. For example, after a handover to base station 106 or an SN change, UE102A can use radio bearers (e.g., DRB or SRB) that terminate at base station 106. UE102A can apply one or more security keys when communicating with radio bearers in the uplink (from UE102A to base station) and / or downlink (from base station to UE102A) directions. In non-MBS operation, UE102A transmits data to base stations via radio bearers on (i.e., within) the cell's uplink (UL) bandwidth portion (BWP), and / or receives data from base stations via radio bearers on the cell's downlink (DL) BWP. UL BWP can be an initial UL BWP or a dedicated UL BWP, and DL BWP can be an initial DL BWP or a dedicated DL BWP. UE102A can receive paging, system information, public warning messages, or random access responses on DL BWP. In this non-MBS operation, UE102A can be in a connected state. Alternatively, UE102A can be in an idle or inactive state if it supports small data transmission in an idle or inactive state.

[0023] In MBS operation, UE102A can use an MBS radio bearer (MRB) that terminates at either the MN (e.g., base station 104) or the SN (e.g., base station 106) at different times. For example, after a handover or SN change, UE102A can use an MRB that terminates at base station 106, which can operate as either the MN or the SN. In some scenarios, a base station (e.g., MN or SN) can transmit MBS data to UE102A via the MRB over a unicast radio resource (i.e., a radio resource dedicated to UE102A). In other scenarios, a base station (e.g., MN or SN) can transmit MBS data over a multicast radio resource (i.e., a radio resource common to UE102A and one or more other UEs), or transmit a cell DL BWP from the base station to UE102A 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 MBS or a DL BWP not intended for unicast).

[0024] The base station 104 includes processing hardware 130 which may include one or more general-purpose processors (e.g., a central processing unit (CPU)), computer-readable memory for storing machine-readable instructions executable by one or more general-purpose processors, and / or a special-purpose processing unit. The processing hardware 130 in the exemplary embodiment of Figure 1A includes an MBS controller 132 configured to manage or control the transmission of MBS information received from the CN 110 or edge server. For example, the MBS controller 132 may be configured to support radio resource control (RRC) configurations, procedures and messaging associated with MBS procedures, and / or other operations associated with those configurations and / or procedures, as described below. The processing hardware 130 may also include a non-MBS controller 134 configured to manage or control one or more RRC configurations and / or RRC procedures when the base station 104 operates as an MN or SN during non-MBS operation.

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

[0026] UE102A includes processing hardware 150 which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory for storing machine-readable instructions executable by the general-purpose processors, and / or special-purpose processing units. The processing hardware 150 in the exemplary embodiment shown in Figure 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, MBS procedures and associated procedures and messaging, 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 one of the embodiments described below, when UE102A communicates with MN and / or SN during non-MBS operation. Although not shown in Figure 1A, UE102B and UE103 may include processing hardware similar to the processing hardware 150 of UE102A.

[0027] CN110 may be an evolved packet core (EPC) 111 or a fifth-generation core (5GC) 160, both of which are shown in Figure 1A. Base station 104 may be an eNB supporting an S1 interface for communicating with EPC111, an ng-eNB supporting an NG interface for communicating with 5GC160, or a gNB supporting an NR radio interface and an NG interface for communicating with 5GC160. Base station 106 may be an EUTRA-NR DC (EN-DC) gNB (en-gNB) with an S1 interface to EPC111, an en-gNB not connected to EPC111, a gNB supporting an NR radio interface and an NG interface to 5GC160, or an ng-eNB supporting an EUTRA radio interface and an NG interface to 5GC160. Base stations 104 and 106 may support an X2 interface or an Xn interface to directly exchange messages with each other during the scenarios described below.

[0028] Among other components, the EPC111 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 the UE (e.g., UE102A or 102B) to one or more external packet data networks, such as the Internet network and / or Internet Protocol (IP) Multimedia Subsystem (IMS) networks. The 5GC160 includes User Plane Functions (UPF) 162, Access and Mobility Management Functions (AMF) 164, and / or Session Management Functions (SMF) 166. UPF162 is generally configured to forward user plane packets related to audio calls, video calls, internet traffic, etc., AMF164 is generally configured to manage authentication, registration, paging, and other related functions, and SMF166 is generally configured to manage PDU sessions.

[0029] UPF162, AMF164, and / or SMF166 can be configured to support MBS. For example, SMF166 can be configured to manage or control MBS transport, configure UPF162 and / or RAN105 for MBS flows, and / or manage or set up one or more MBS sessions or PDU sessions for MBS for a UE (e.g., UE102A or 102B). UPF162 can be configured to forward MBS data packets to RAN105 for audio, video, internet traffic, etc. UPF162 and / or SMF166 can be configured for both non-MBS unicast services and MBS, or for MBS only, as indicated by the prefix "(MB-)" shown in Figure 1A.

[0030] Generally, the wireless communication system 100 may include any suitable number of base stations that support NR cells and / or EUTRA cells. More specifically, the EPC 111 or 5GC 160 may be connected to any suitable number of base stations that support NR cells and / or EUTRA cells. The following examples specifically refer to certain CN types (EPC, 5GC) and radio access technology (RAT) types (5G NR and EUTRA), but generally, the technology of this disclosure can also be applied to other suitable radio access technologies and / or core network technologies, such as, for example, sixth-generation (6G) radio access and / or 6G core networks or 5G NR-6G DC.

[0031] In different configurations or scenarios of the wireless communication system 100, base station 104 can operate as a MeNB, Mng-eNB, or MgNB, and base station 106 can operate as an SgNB or Sng-eNB. UE102A can communicate with base stations 104 and 106 via the same RAT, such as EUTRA or NR, or via different RATs.

[0032] When base station 104 is a MeNB and base station 106 is an SgNB, UE102A may be in EN-DC with MeNB104 and SgNB106. When base station 104 is a Mng-eNB and base station 106 is an SgNB, UE102A may be in next-generation (NG) EUTRA-NR DC (NGEN-DC) with Mng-eNB104 and SgNB106. When base station 104 is a MgNB and base station 106 is an SgNB, UE102A may be in NR-NR DC (NR-DC) with MgNB104 and SgNB106. When base station 104 is a MgNB and base station 106 is an Sng-eNB, UE102A may be in NR-EUTRA DC (NE-DC) with MgNB104 and Sng-eNB106.

[0033] Figure 1B shows one or more exemplary distributed embodiments of base stations 104, 106. In this embodiment, base stations 104, 106 include a central unit (CU) 172 and one or more distributed units (DUs) 174. In embodiments in which base stations 104, 106 include multiple DUs, the terms DU174A and 174B may be used to refer to the first and second DUs of the multiple DUs, respectively. CU172 includes processing hardware such as one or more general-purpose processors (e.g., CPUs), and computer-readable memory for storing machine-readable instructions executable on the general-purpose processors, and / or special-purpose processing units. For example, CU172 may include some or all of the processing hardware 130 or 140 in Figure 1A.

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

[0035] In some embodiments, CU172 may include one or more logical nodes (CU-CP(or CU-UP

[0036] A CU-CP(multiple)172A can connect to multiple CU-UP172Bs via the E1 interface. The CU-CP(multiple)172A selects the appropriate CU-UP(multiple)172B for the service requested to the UE102A. In some embodiments, a single CU-UP172B can connect to multiple CU-CP172A via the E1 interface. A CU-CP172A can connect to one or more DU174s via the F1-C interface. A CU-UP172B can connect to one or more DU174s via the F1-U interface under the control of the same CU-CP172A. In some embodiments, a single DU174 can connect to multiple CU-UP172Bs under the control of the same CU-CP172A. In such embodiments, connectivity between the CU-UP172B and DU174 is established by the CU-CP172A using bearer context management functionality.

[0037] Figure 2A shows a simplified exemplary protocol stack 200, in which a UE (e.g., UE102A, 102B, or 103) can communicate with an eNB / ng-eNB or gNB (e.g., one or more base stations 104, 106) according to the protocol stack 200. In the exemplary protocol stack 200, the EUTRA PHY sublayer 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208, and in some cases to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides an RLC channel to the NR PDCP sublayer 210. In some embodiments, the UE supports both EUTRA and NR stacks, as shown in Figure 2A, supports handover between EUTRA base stations and NR base stations, and / or supports DC via EUTRA and NR interfaces. Furthermore, as shown in Figure 2A, the UE can support layering of NR PDCP 210 on EUTRA RLC 206A and SDAP sublayer 212 on NR PDCP sublayer 210. Sublayers are also referred to simply as “layers” in this specification.

[0038] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 receive packets (e.g., from the IP layer layered directly or indirectly on PDCP layer 208 or 210) which may be called Service Data Units (SDUs), and output packets (e.g., to RLC layer 206A or 206B) which may be called Protocol Data Units (PDUs). Unless the difference between SDUs and PDUs is relevant, for simplicity, both SDUs and PDUs are referred to as “packets” in this disclosure. Packets can be MBS packets or non-MBS packets. MBS packets may contain, for example, application content for MBS services (e.g., IPv4 / IPv6 multicast distribution, IPTV, software distribution over radio, group communications, IoT applications, V2X applications, and / or emergency messages related to public safety). As another example, MBS packets may contain application control information for MBS services.

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

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

[0041] In some embodiments, base stations (e.g., base stations 104, 106) broadcast MBS data packets via one or more MBS radio bearers (MRBs), and UEs then receive the MBS data packets via the MRBs. Base stations may include the configuration(s) of the MRBs in the multicast configuration parameters (sometimes also called MBS configuration parameters) described below. In some embodiments, base stations broadcast MBS data packets via the RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and UEs receive the MBS data packets using the PHY sublayer 202, MAC sublayer 204, and RLC sublayer 206. In such embodiments, base stations and UEs may or may not use the PDCP sublayer 208 and SDAP sublayer 212 to communicate the MBS data packets. In other embodiments, the base station transmits MBS data packets via PDCP sublayer 208, RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and the UE receives the MBS data packets using PHY sublayer 202, MAC sublayer 204, RLC sublayer 206, and PDCP sublayer 208. In such embodiments, the base station and UE may or may not use SDAP sublayer 212 to communicate MBS data packets. In yet another embodiment, the base station transmits MBS data packets via SDAP sublayer 212, PDCP sublayer 208, RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and the UE receives the MBS data packets using PHY sublayer 202, MAC sublayer 204, RLC sublayer 206, PDCP sublayer 208, and SDAP sublayer 212.

[0042] Figure 2B shows a simplified exemplary protocol stack 250 that enables UE102 or UE103 to communicate with DU (e.g., DU174) and CU (e.g., CU172). The radio protocol stack 200 is functionally divided by the radio protocol stack 250 in Figure 2B, as shown. The CU, located in either base station 104 or 106, can hold all control and higher-layer functions (e.g., RRC214, SDAP212, NR PDCP210), while lower-layer operations (e.g., NR RLC206B, NR MAC204B, and NR PHY202B) are delegated to the DU. To support connectivity to 5GC, NR PDCP210 provides SRB to RRC214, NR PDCP210 provides DRB to SDAP212, and NR PDCP210 provides SRB to RRC214.

[0043] Referring to Figure 3, an MBS session 302A may include a tunnel 312A with endpoints at CN110 and base stations 104 / 106. An MBS session 302A may correspond to a specific session ID, such as a Temporary Mobile Group Identifier (TMGI). 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, CN110 and / or base stations 104 / 106 configure tunnel 312A only for MBS traffic directed from CN110 to base stations 104 / 106, and tunnel 312A may be called a downlink (DL) tunnel. However, in other cases, CN110 and base stations 104 / 106 use tunnel 312A for downlink and uplink (UL) MBS traffic to support, for example, commands or service requests from UEs. Furthermore, since base stations 104 / 106 can direct MBS traffic arriving via tunnel 312A to multiple UEs, tunnel 312A may be called a common tunnel or common DL tunnel.

[0045] Tunnel 312A can operate at the transport layer or sublayer, for example, with a User Datagram Protocol (UDP) protocol layered on top of the Internet Protocol (IP). More specifically, tunnel 312A can be associated with the General-Purpose Packet Radio System (GPRS) Tunneling Protocol (GTP). Tunnel 312A can correspond, for example, to a specific IP address (e.g., the IP address of base stations 104 / 106) and a specific Tunnel Endpoint Identifier (TEID) (e.g., assigned by base stations 104 / 106). More generally, tunnel 312A can have any suitable transport layer configuration. CN110 can specify the IP address and TEID address in the header(s) of the tunnel packet containing the MBS data packet and transmit the tunnel packet downstream to base stations 104 / 106 via tunnel 312A. The header(s) can contain the IP address and / or TEID. For example, the header(s) may contain an IP header and a GTP header, each containing the IP address and TEID, respectively. Therefore, base stations 104 / 106 can identify data packets traveling through tunnel 312A using their IP addresses and / or TEID.

[0046] As shown in Figure 3, base stations 104 / 106 map traffic within tunnel 312A to N radio bearers 314A-1, 314A-2, ... 314A-N, which can be configured as MBS radio bearers or MRBs, where N ≥ 1. Each MRB may correspond to its 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 MRB314A can, for example, correspond to its respective MBS traffic channel (MTCH). Base stations 104 / 106 and CN110 can also maintain another MBS session 302B, which may similarly include tunnel 312B corresponding to MRBs 314B-1, 314B-2, ... 314B-N, where N ≥ 1. Each MRB314B can correspond to its respective logical channel.

[0047] MBS traffic can include one or more Quality of Service (QoS) flows for each of the tunnels, such as 312A and 312B. For example, MBS traffic on tunnel 312B can include a set of flows 316, including QoS flows 316A, 316B, ..., 316L. Furthermore, a logical channel of an MRB can support a single QoS flow or multiple QoS flows. In the exemplary configuration of Figure 3, base stations 104 / 106 map QoS flows 316A and 316B to the MTCH of MRB314B-1 and QoS flow 316L to the MTCH of MRB314B-N.

[0048] In various scenarios, the CN110 can assign different types of MBS traffic to different QoS flows. For example, a flow with a relatively high QoS value can handle audio packets, while a flow with a relatively low QoS value can handle video packets. Another example is that a flow with a relatively high QoS value can handle I-frames or full images used in video compression, while a flow with a relatively low QoS value can handle predictive pictures that only include P-frames or changes to I-frames.

[0049] Continuing to refer to Figure 3, base stations 104 / 106 and CN110 can maintain one or more PDU sessions to support unicast traffic between CN110 and a specific UE. PDU session 304A can include UE-specific DL tunnels and / or UE-specific UL tunnels 322A corresponding to one or more DRB324A such as DRB324A-1, 324A-2, ..., 324-N. Each DRB324A can correspond to its respective logical channel, such as a Dedicated Traffic Channel (DTCH). Base stations 104 / 106 and CN110 can also maintain one or more other PDU sessions to support unicast traffic between CN110 and a specific UE. For example, PDU session 304B can include UE-specific DL tunnels and / or UE-specific UL tunnels 322B corresponding to one or more DRB324B such as DRB324B-1, 324B-2, ..., 324B-N. Each DRB324B can correspond to its respective logical channel, such as a DTCH.

[0050] Referring to Figure 4, when base stations 104 / 106 are implemented in a distributed manner, one or more DU174A / 174B can be associated with CU172. CU172 and DU(multiple)174A / 174B can establish tunnels for downlink and / or uplink data associated with MRB or DRB. The MRB314A-1 described above can be implemented as MRB402A, connecting CU172 to multiple UEs, such as UE102A and 102B. MRB402A can include a DL tunnel 412A connecting CU172 and DU(multiple)174A / 174B, and a DL logical channel 422A corresponding to DL tunnel 412A. In particular, DU(multiple)174A / 174B can map downlink traffic received via DL tunnel 412A to DL logical channel 422A, which may be, for example, MTCH or DTCH. DL tunnel 412A can be a common DL tunnel, and CU172 can send MBS data packets to multiple UEs via the common DL tunnel. Alternatively, DL tunnel 412A can be an UE-specific DL tunnel, and CU172 can send MBS data packets to a specific UE via the UE-specific DL tunnel.

[0051] Optionally, the MRB402A also includes a UL tunnel 413A connecting CU172 and DU(174A / 174B), and a UL logical channel 423A corresponding to the UL tunnel 413A. The UL logical channel 423A may be, for example, PUCCH. The DU(174A / 174B) can map uplink traffic received via the UL logical channel 423A to the UL tunnel 413A.

[0052] Tunnels 412A and 413A can operate at the transport layer or sublayer of the F1-U interface. More specifically, CU172 and DU(multiple)174A / 174B can utilize F1-U for user plane traffic, and tunnels 412A and 413A can be associated with the GTP-U protocol layered over UDP / IP, with IP layered over the appropriate data link layer and physical (PHY) layer. Furthermore, MRB(multiple)402 and / or DRB(multiple)404 additionally support control plane traffic in at least some cases. More specifically, CU172 and DU(multiple)174A / 174B can exchange F1-AP messages via an F1-C interface that relies on the Stream Controlled Transmit Protocol (SCTP) layered over IP, with IP layered over the appropriate data link layer and PHY layer, similar to F1-U.

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

[0054] In some cases, CU172 uses DRB404A to transmit MBS data packets or unicast data associated with PDU sessions to a specific UE (e.g., UE102A or UE102B). DRB404A may include a UE-specific DL tunnel 432A connecting CU172 and DU(multiple)174A / 174B, and a DL logical channel 442A corresponding to DL tunnel 432A. In particular, DU(multiple)174A / 174B can map downlink traffic received via DL tunnel 432A to DL logical channel 442A, which may be, for example, DTCH. DRB404A may also include a UE-specific UL tunnel 433A connecting CU172 and DU(multiple)174A / 174B, and a UL logical channel 443A corresponding to UL tunnel 433A. UL logical channel 443A may be, for example, PUSCH. DU(174A / 174B) can map uplink traffic received via UL logical channel 443A to UL tunnel 433A.

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

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

[0057] Next, several exemplary scenarios in which base station 104, including CU172 and DU174, constitutes resources for transmitting MBS data for an MBS session (i.e., a broadcast MBS session) are described with reference to Figures 5A to 5I. Generally speaking, similar events in Figures 5A to 5I are labeled with the same reference number, and the differences are described below as necessary.

[0058] Referring first to Figure 5A, in Scenario 500A, DU174 generates MBS session information using the PDCP configuration received from CU172. In Scenario 500A, base station 104 broadcasts a specific MBS session (i.e., a first MBS session identified by a first MBS session ID). Initially, CN110 may request CU172 to configure resources for the first MBS session by sending an MBS session resource setup request message (502) that includes the first MBS session ID. In some embodiments, CN110 omits the PDU session ID from the MBS session resource setup request message. In response, CU172 may request DU174 to set up an MBS context and / or common DL tunnel for the first MBS session by sending an MBS context setup request message (504). In the MBS context setup request message, CU172 includes a first session ID and a first PDCP configuration(s) for the first MBS session. CU172 generates a first PDCP configuration(s) to transmit MBS data for the first MBS session. Later, CU172 transmits MBS data for the first MBS session according to the first PDCP configuration(s), as described in event 522. In some embodiments, each of the first PDCP configuration(s) includes a PDCP sequence number size (e.g., 12 bits) and at least one header compression configuration. The header compression configuration may consist of one or more header compression profiles or no header compression.

[0059] In some embodiments, CU172 may include a first intermittent receive (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, CU172 may determine the first DRX cycle length according to a QoS configuration(s). In other embodiments, CU172 may receive the first DRX cycle length in the MBS session resource setup request message(502). In some embodiments, CU172 excludes the PDU session ID from the MBS context setup request message.

[0060] In some embodiments, CU172 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, DU174 may receive first MBS neighbor cell information from an Operation, Administration, and Maintenance (OAM) node.

[0061] In response to receiving an MBS context setup request message (504), DU174 may send an MBS context setup response message to CU172 that includes a first DU DL transport layer configuration for configuring a first common CU-DU DL tunnel for the first MBS session (506). CN110 may further include a Quality of Service (QoS) configuration(s) for the first MBS session in the MBS session resource setup request message. In such a case, CU172 may include the QoS configuration(s) in the MBS context setup request message. In some embodiments, the MBS context setup request message and the MBS context setup response message may be non-UE specific messages.

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

[0063] In some embodiments, the QoS configuration(s) include QoS parameters for an MBS session. In some embodiments, the QoS configuration(s) include configuration parameters for configuring one or more QoS flows for an MBS session (see Figure 3). In some embodiments, the configuration parameters include one or more QoS flow IDs that identify the QoS flow(s). Each QoS flow ID(s) identifies a specific QoS flow(s) within the QoS flow(s). In some embodiments, the configuration parameters include QoS parameters for each QoS flow. QoS parameters may include a 5G QoS identifier (5QI), priority level, packet delay budget, packet error rate, averaging window, and / or maximum data burst amount. The CN110 can specify different values ​​for QoS parameters for a QoS flow.

[0064] In some embodiments, DU174 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, DU174 may indicate the 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, CU172 can configure one or more MRBs (or MRBs) for a first MBS session and generate one or more MRB IDs (or MRB IDs) for each specific MRB(or MRB). In such cases, CU172 can include the MRB IDs (or MRB IDs) in the MBS context setup request message to request DU174 to configure resources for the MRB(or MRB). In some embodiments, CU172 can associate each of the first PDCP configurations (or MRB) with a specific MRB / MRB ID (or MRB ID) and indicate the association (or MRB ID) in the MBS context setup request message. In some embodiments, DU174 can include the MRB IDs (or MRB IDs) in the MBS context setup response message to indicate that the resources for the MBB(or MRB) have been successfully established. If DU174 does not have sufficient resources for all of the MRB, DU174 may include a portion of the MRB ID in the MBS context setup response message to indicate that resources for a portion of the MRB have been successfully established. In the MBS context setup response message, DU174 may, in some embodiments, include an additional DU DL transport layer configuration that constitutes an additional common CU-DU DL tunnel for the first MBS session. DU174 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 specific 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., an IP address) and / or TEID to identify the additional common CU-DU DL tunnel.

[0066] In response to or after receiving an MBS context setup request message (504), DU174 may generate a first MBS broadcast configuration message (e.g., an MBSBroadcastConfiguration message) containing a first session ID and a first PDCP configuration(s) (512).

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

[0068] Before, during, or after the MBS resource setup procedure 586A, DU174 transmits (e.g., broadcasts) (514) system information (e.g., one or more system information blocks (SIBs)) containing MBS control information about one or more cells (e.g., cell 124 and / or other cells(s) operated by DU174). In some embodiments, DU174 periodically transmits (514) system information about one or more cells. The MBS control information includes configuration parameters for UE102 to receive a first MBS broadcast configuration message. In some embodiments, DU174 has performed the MBS resource setup procedure (586A). 6A) In response, system information can be transmitted (514) (transmission initiated). In some embodiments, CU172 generates system information and sends a CU-to-DU message containing the system information to DU174. For example, the CU-to-DU message may be a non-UE related message such as a gNB-CU configuration update message, a gNB-DU configuration update acknowledgment message, a system information distribution command message, or an F1 setup response message (e.g., an F1AP message). In other embodiments, DU174 generates system information. In some embodiments, DU174 can send a DU-to-CU message containing system information to CU172.

[0069] After generating the first MBS broadcast configuration message (512), DU174 transmits (e.g., broadcasts) the first MBS broadcast configuration message according to the MBS control information (516). In some embodiments, DU174 can transmit the first MBS broadcast configuration message according to the MBS control information via 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 of the MCCH (e.g., pdsch-Config-MCCH), a PDSCH configuration of the MTCH (e.g., pdsch-Config-MTCH), a PDCCH configuration of the MCCH (e.g., pdcch-Config-MCCH), and / or a PDCCH configuration of the MTCH (e.g., pdcch-Config-MTCH). The CFR configuration configures the common frequency resource so that UE102 can receive the MBS (e.g., the first MBS session). If no CFR configuration exists, UE102 can receive the MBS via an initial DL BWP. UE102 can obtain the configuration parameters of the initial DL BWP in SIB1 that UE102 receives from DU172. The MCCH PDSCH configuration configures cell-specific configuration parameters so that UE102 receives PDSCH transmissions containing MCCH data (e.g., MBS broadcast configuration messages, including the first MBS broadcast configuration message). If no MCCH PDSCH configuration exists, UE102 can use the PDSCH configuration in SIB1 to receive PDSCH transmissions containing MCCH data (e.g., MBS broadcast configuration messages, including the first MBS broadcast configuration message). The MTCH PDSCH configuration configures cell-specific configuration parameters so that UE102 receives PDSCH transmissions. If no MTCH PDSCH configuration exists, UE102 can use the PDSCH configuration in SIB1 to receive PDSCH transmissions. Each PDSCH transmission includes including MTCH data (e.g., MBS data for an MBS session, such as MBS data for the first MBS session). The MCCH PDCCH configuration configures cell-specific configuration parameters so that UE102 receives PDCCH transmissions. If a PDCCH configuration for MCCH does not exist, UE102 can use the PDCCH configuration of SIB1 to receive PDCCH transmissions.Each PDCCH transmission includes DCI scrambled with MCCH-RNTI or G-RNTI and the CRC (of the DCI), which schedules a PDSCH transmission containing MCCH data (e.g., MBS broadcast configuration messages, including the first MBS broadcast configuration message). The MTCH PDCCH configuration configures cell-specific configuration parameters so that UE102 can receive PDCCH transmissions. If no MTCH PDCCH configuration exists, UE102 can use the SIB1 PDCCH configuration to receive PDCCH transmissions. Each PDCCH transmission includes DCI scrambled with G-RNTI and the CRC (of the DCI), which 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 the PDSCH configuration of the MTCH (e.g., pdsch-Config-MTCH) and / or the PDCCH configuration of the MTCH (e.g., pdcch-Config-MTCH) instead of system information or MBS control information.

[0072] In some embodiments, the MCCH configuration includes configuration parameters such as a window start slot, window duration, correction period, and / or repetition period and offset. The window duration indicates a duration starting from a slot indicated by the window start slot (i.e., an MCCH transmit window in units of (consecutive) slots), which may determine the schedule for transmitting MCCH information (i.e., transmitting(multiple) MBS configurations over MCCH) during the window start slot. The correction period defines a regularly occurring boundary, i.e., a radio frame in which the SFN corrects correction period = 0. The content of different transmissions of MCCH information may differ only 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. Transmission of MCCH information is scheduled in a radio frame in which the system frame number (SFN) corrects the repetition period length offset of the repetition period.

[0073] In some embodiments, DU174 can generate first MBS session information (e.g., MBS-SessionInfo IE) including a first MBS session ID, a first G-RNTI, a first RLC configuration(s), and / or a first PDCP configuration(s), and can include the first MBS session information in an MBS broadcast configuration message. In some embodiments, DU174 can generate first MRB configuration(s), including a first PDCP configuration(s) and / or a first RLC configuration(s).(512) Each of the first MRB configuration(s) may include a specific PDCP configuration(s) of the first PDCP configuration(s). Each of the first MRB configuration(s) may include a specific RLC configuration(s) of the first RLC configuration(s). In some embodiments, DU174 may establish and use one or more RLC entities to transmit MBS data for a first MBS session to UE102 according to a first RLC configuration(s)(522). If DU174 receives a first DRX cycle configuration from CU172, DU174 may generate a first DRX configuration (e.g., DRX-ConfigPTM IE) according to the first DRX cycle configuration (e.g., first DRX cycle length). In such a case, DU174 may include the first DRX configuration in the first MBS session information.

[0074] The first G-RNTI is used by DU174 to schedule the transmission of MBS data for the first MBS session. Each of the first RLC configurations 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 specific MRB(s) of the MRB(s). The first DRX configuration configures the DRX parameters to transmit MBS data for the first MBS session with an on-duration of a periodic DRX cycle in order to conserve power for the UE. According to the DRX parameters, the UE is able to intermittently receive MBS data for the first MBS session. For example, the DRX parameters may include: • Inactivity Timer parameter (e.g., drx-InactivityTimerPTM field): Duration after a PDCCH occasion in which the PDCCH indicates a new DL multicast transmission for a MAC entity. • DRX cycle and start offset parameters (e.g., the drx-(Long)CycleStartOffsetPTM field): Defines the length of the DRX cycle and the subframe in which the DRX cycle begins. • On-duration parameter (e.g., drx-onDurationTimerPTM): The duration at the start of the DRX cycle.

[0075] In some embodiments, DU174 can generate a first RLC configuration(s) according to, for example, a QoS configuration(s) and / or MRB ID(s). Alternatively, DU174 can generate a first RLC configuration(s) using pre-configured RLC parameters. In some embodiments, DU174 can include a first logical channel ID(s) in the first RLC configuration(s). If DU174 receives a first DRX cycle configuration, DU174 sets the DRX cycle length to the first DRX cycle length. If DU174 does not receive a DRX cycle configuration for a first MBS session, DU174 can determine the DRX cycle length according to, for example, a QoS configuration(s) received from CU172. Alternatively, DU174 can determine the DRX cycle length according to pre-configured DRX parameters. Alternatively, DU174 may 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 embodiments, DU174 may assign a first G-RNTI(value) and associate the first G-RNTI with the first MBS session ID.

[0076] If DU174 receives first MBS neighbor cell information, DU174 may include the first MBS neighbor cell information in the first MBS session information. If CU172 does not send first MBS neighbor cell information to DU174, DU174 may generate first MBS neighbor cell information and include it in the first MBS session information. In some embodiments, DU174 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] Following the MBS resource setup procedure 586A, CN110 transmits MBS data for the first MBS session to CU172 via the first common CN-BS DL tunnel (518). CU172 then transmits MBS data to DU174 via the first common CU-DU DL tunnel and / or additional common CU-DU DL tunnels according to the first PDCP configuration (520). DU174 then transmits (i.e., broadcasts) MBS data according to the MBS broadcast configuration message (for example, 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). UE102 receives the MBS data according to the first MBS broadcast configuration or the first MBS session information (522). For example, CU172 receives an MBS data packet (518), generates a PDCP PDU containing the MBS data packet according to the PDCP configuration, and transmits the PDCP PDU to DU174 via a first common CU-DU DL tunnel (520). In some embodiments, CU172 can use PDCP state variables to generate a PDCP sequence number included in the PDCP PDU. In some embodiments, DU174 generates a MAC PDU containing a first logical channel ID and a PDCP PDU, and transmits the MAC PDU to UE102 using a first G-RNTI (522). UE102 receives the MAC PDU using the first G-RNTI (522), extracts the PDCP PDU and the first logical channel ID from the MAC PDU, identifies the 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, DU174 generates multiple RLC PDU segments containing a PDCP PDU, and each of the multiple RLC PDU segments contains a specific portion of the PDCP PDU, each containing an RLC sequence number (i.e., the same RLC sequence number). In some embodiments, DU174 can use RLC state variables to generate the RLC sequence number.For each of the multiple RLC PDU segments, DU174 generates a MAC PDU containing a first logical channel ID and the RLC PDU segment, and transmits the MAC PDU to UE102 using the first G-RNTI (522). UE102 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 segment to obtain a PDCP PDU, identifies the PDCP PDU associated with the MRB based on the first logical channel ID, and extracts the MBS data packets from the PDCP PDU according to the first PDCP configuration.

[0078] In some embodiments, CU172 includes CU-CP172A and CU-UP172B, as described with respect to Figure 1B. In such cases, the events of the MBS resource setup procedure 586A occur between CU-CP172A and CN110 and DU174. In such cases, events 518 and 520 occur between CN110 and CU-UP172B and DU174. After receiving the MBS context setup response message (506), CU-CP172A may request CU-UP172B to establish an MBS bearer context for the first MBS session and / or MRB(multiple) by sending an MBS bearer context setup request message (not shown in Figure 5A) to CU-UP172B, which may include a first MBS session ID and / or MRB(multiple) ID. In some embodiments, CU-CP172A omits the PDU session ID from the MBS bearer context setup request message. In response to an MBS bearer context setup request message, CU-UP172B can generate an MBS bearer context and send an MBS bearer context setup response message to CU-CP172A. In some embodiments, CU-UP172B can include a first CU DL transport layer configuration in the MBS bearer context setup response message, so that CU-CP can include a first CU DL transport layer configuration in the MBS session resource setup response message. Thus, CN110 can send MBS data for a first MBS session to CU-UP172B via a first common CN-BS DL tunnel (518).

[0079] In some embodiments, CU-CP172A may include a first PDCP configuration(s) in the MBS bearer context setup request message, and CU-UP172B may transmit MBS data for the first MBS session to DU174 according to the first PDCP configuration(s) (520). In some embodiments, CU-UP172B may establish one or more PDCP entities according to the first PDCP configuration(s) and use one or more PDCP entities to transmit MBS data for the first MBS session to DU174 (520). In some embodiments, CU-CP172A may include an MRB ID(s) in the MBS bearer context setup request message, and CU-CP172A may associate each of the first PDCP configuration(s) with a specific MRB / MRB ID(s) and indicate the association(s) in the MBS bearer context setup request message. In some embodiments, CU-CP172A includes a first DU DL transport layer configuration and / or additional DU DL transport layer configurations in the MBS bearer context setup request message so that CU-UP172B can send MBS data for the first MBS session to DU174 via the first common CU-DU DL tunnel and / or additional CU-DU DL tunnels (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] The operations that can be performed by CU-CP172A and CU-UP172B will be further explained with reference to Figures 7A-7B and 9A-9B. Furthermore, although not shown in Figures 5B-5E, the events of MBS resource procedures 586B-586E (described below) may occur between CU-CP172A, CN110, and DU174, similar to the events described for MBS resource procedure 586A.

[0082] Figure 5B is a messaging diagram for an exemplary scenario 500B, similar to scenario 500A, except that DU174 receives the PDCP configuration in a CU-to-DU message from CU172 after receiving the MBS context setup request message, as described below. More specifically, CU172 sends an MBS context setup request message to DU174 containing a first MBS session ID (503), and CU172 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, CU172 sends a CU-to-DU message to DU174 containing the first MBS session ID, the first PDCP configuration(s), and / or the first DRX cycle configuration (510). In some embodiments, CU-to-DU messages may be F1 Application Protocol (F1AP) messages. Events 502, 503, 506, 508, 510, and 512 are collectively referred to as MBS resource setup procedure 586B in Figure 5B.

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

[0084] If DU174 generates the first DRX configuration as described above, in some embodiments, DU174 may include the first DRX configuration in the CU-to-DU message of event 505. In such cases, CU172 includes the first DRX configuration in the first MBS session information. In other embodiments, CU172 may generate the first DRX configuration and include it in the first MBS session information. In yet another embodiment, CU172 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 embodiments, CU172 may include first MBS neighbor cell information in first MBS session information. In some embodiments, DU174 may include first MBS neighbor cell information in MBS context setup response message. In other embodiments, CU172 generates first MBS neighbor cell information. In some embodiments, CU172 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 first MBS session information.

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

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

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

[0089] In further embodiments, the configuration(s) may include CU-to-DU header compression configurations(s), each being an IE (e.g., F1AP IE) of a CU-to-DU message for a specific MRB(s) of the first MBS session. DU174 can generate header compression configurations(s) in the first PDCP configuration(s) according to the CU-to-DU header compression configurations(s). If the CU-to-DU message does not include a CU-to-DU header compression configuration(s) for a specific MRB(s) of the MRB(s), DU174 can generate a header compression configuration that does not constitute header compression, and the first PDCP configuration may include a header compression configuration.

[0090] In further embodiments, the configuration(s) may include CU-to-DUPDCP sequence number size configurations(s), each being an IE (e.g., F1AP IE) of a CU-to-DU message for a specific MRB(s) of the first MBS session. DU174 can generate PDCP sequence number sizes(s) in the first PDCP configuration(s) according to the CU-to-DUPDCP sequence number size configuration(s). If the CU-to-DU message does not include a PDCP sequence number size setting(s) for a specific MRB(s) of the MRB(s), DU174 can include a default PDCP sequence number size in the first PDCP configuration.

[0091] DU174 then generates the first MBS broadcast configuration message (515). Events 502, 503, 506, 508, and 515 are collectively referred to as MBS resource setup procedure 586E in Figure 5E.

[0092] Figure 5F is a messaging diagram of an exemplary scenario 500F, similar to scenarios 500A-E, except that base station 104 later releases resources for the first MBS session. Scenario 500F can begin with any one of the MBS resource setup procedures 586A-E. After sending the MBS data (518), CN110 may decide to request RAN105 to release resources for the first MBS session. In response to this decision, CN110 sends an MBS session resource release request message to CU172 containing the first MBS session ID (524). In response to receiving the MBS session resource release request message (524), or after receiving it, CU172 sends an MBS context release command message to DU174 (526), ​​requesting DU174 to release resources for the first MBS session. In some embodiments, CU172 may include the first MBS session ID in the MBS context release command message. CU172 may or may not include the MRB ID(s) in the MBS context release command message. In response, DU174 releases the 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 CU172 (528). In response to receiving the MBS context release complete message (528), or after receiving it, CU172 may send an MBS session resource release response message to CN110 (530) to confirm that the resources for the first MBS session have been released.

[0093] In some embodiments, CU172 may decide to request DU174 to release resources for the first MBS session without receiving an MBS session resource release request message from CN110. For example, CU172 may make this decision after detecting an MBS data inactive state for the first MBS session over a period of time. In response to the decision, CU172 may send an MBS context release command message to DU174 (526). In some embodiments, CU172 may receive the value of that period from CN110 in a CN-to-BS message. For example, the CN-to-BS message may be an MBS session resource setup request message for event 502, or an NG Application Protocol (NGAP) message. In other embodiments, CU172 may receive the value of that period from an OAM node. In yet another embodiment, CU172 may be pre-configured with the value of that period.

[0094] DU174 may, in response to or after receiving the MBS context release command message (526), ​​stop sending (e.g., broadcast) the first MBS broadcast configuration message (532). Alternatively, DU174 may, in response to or after receiving the MBS context release command message (526), ​​send (e.g., broadcast) a second MBS broadcast configuration message, excluding the first MBS session information, according to the MBS control information. In some embodiments, DU174 generates the second MBS broadcast configuration message as described for the first MBS broadcast configuration message. In other embodiments, CU172 generates the second MBS broadcast configuration message and sends a CU-to-DU message containing the second MBS broadcast configuration message to DU174 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, DU174 may, in response to or after receiving an MBS context release command message (526), ​​release one or more RLC entities used by DU174 to transmit MBS data for the first MBS session. In some embodiments, DU174 may stop transmitting system information for event 514.

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

[0097] In some embodiments, CU172 includes CU-CP172A and CU-UP172B. In such cases, events 524, 526, 528, and 530 occur between CU-CP172A of CU172 and CN110 and DU174. After receiving the message for event 524, CU-CP172A may request CU-UP172B to release the MBS bearer context for the first MBS session by sending an MBS bearer context release command message (not shown in Figure 5F) including a first MBS session ID and / or MRB ID(s). In some embodiments, CU172 omits the PDU session ID from the MBS bearer context release command message. In response to the MBS bearer context release command message, CU-UP172B may release the MBS bearer context and send an MBS bearer context release complete message to CU-CP172A. In some embodiments, the CU-UP172B may release one or more PDCP entities used by the CU-UP172B to transmit MBS data for a first MBS session, in response to receiving or after receiving an MBS bearer context release command message.

[0098] Figure 5G is a messaging diagram for an exemplary scenario 500G, similar to scenarios 500A-E, except that base station 104 later suspends and resumes resources for the first MBS session. Scenario 500G can be initiated by any one of the MBS resource setup procedures 586A-E. After transmitting MBS data (518), CN110 may decide to suspend the first MBS session. In response to this decision, CN110 sends an MBS session resource modification request message to CU172, which includes the first MBS session ID and an indication to suspend the first MBS session (525). The indication may be an indication of suspension, or to suspend resources and / or operations for the first MBS session, or to cause CU172 to suspend resources and / or operations for the first MBS session. In response to receiving (525) an MBS session resource modification request message or indication, or after receiving one, CU172 sends an MBS context modification request message to DU174 containing an indication requesting DU174 to suspend resources for a first MBS session or MRB(or MRB)(527). The indication may be a suspension indication, or an indication to suspend resources and / or operations for a first MBS session, or an IE causing CU172 to suspend resources and / or operations for a first MBS session. In some embodiments, CU172 may include a first MBS session ID and / or MRB(or MRB) ID(or MRB) in the MBS context modification request message. In response, DU174 suspends resources and / or operations for a first MBS session or MRB(or MRB)(or MRB)(529) and sends an MBS context modification response message to CU172. In response to receiving (529) an MBS context correction response message, or after receiving one, CU172 may send an MBS session resource correction response message to CN110 (531) to confirm that the resources for the first MBS session have been suspended.

[0099] In some embodiments, CU172 may decide to request DU174 to suspend the first MBS session without receiving an MBS session resource correction request message from CN110. For example, CU172 may make this decision after detecting an MBS data inactive state for the first MBS session over a period of time. In response to the decision, CU172 may send an MBS context correction request message to DU174 (527). In some embodiments, CU172 may receive the value of that period from CN110 in a CN-to-BS message. For example, the CN-to-BS message may be an MBS session resource setup request message for event 502, or an NG Application Protocol (NGAP) message. In other embodiments, CU172 may receive the value of that period from an OAM node. In yet another embodiment, CU172 may be pre-configured with the value of that period.

[0100] In response to or after receiving the MBS context correction request message (527), DU174 may stop sending (e.g., broadcasting) the first MBS broadcast configuration message (532). Alternatively, in response to or after receiving the MBS context correction request message (527), DU174 may send (e.g., broadcasting) a second MBS broadcast configuration message, excluding the first MBS session information, according to the MBS control information. In some embodiments, DU174 generates the second MBS broadcast configuration message as described for the first MBS broadcast configuration message. In other embodiments, CU172 generates the second MBS broadcast configuration message and sends a CU-to-DU message containing the second MBS broadcast configuration message to DU174. The CU-to-DU message may be an MBS context correction request message or an F1AP message.

[0101] In some embodiments, DU174 may maintain one or more RLC entities used by DU174 to transmit MBS data for a first MBS session in response to or after receiving an MBS context correction request message (527). In such cases, DU174 may maintain RLC state variables in one embodiment. In another embodiment, DU174 may reset RLC state variables in response to or after receiving an MBS context correction request message (527).

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

[0103] In some embodiments, CU172 includes CU-CP172A and CU-UP172B. In such cases, events 525, 527, 529, and 531 occur between CU-CP172A of CU172 and CN110 and DU174. After receiving the message for event 525, CU-CP172A may send an MBS bearer context correction request message (not shown in Figure 5G) to CU-CP172B, including a first MBS session ID and / or MRB ID(s), to request CU-UP172B to suspend resources and / or operations for the first MBS session. In some embodiments, CU-CP172A omits the PDU session ID from the MBS bearer context correction request message. In response to an MBS bearer context correction request message, CU-UP172B may suspend resources (e.g., MBS bearer context) and / or operations for the first MBS session and send an MBS bearer context correction response message to CU-CP172A. In some embodiments, CU-UP may hold one or more PDCP entities used by CU-UP172B to transmit MBS data for the first MBS session in response to or after receiving an MBS bearer context correction request message. In such cases, CU-UP172B may hold PDCP state variables in one embodiment. In another embodiment, DU174 may reset PDCP state variables.

[0104] Later, CN110 may decide to resume the first MBS session. In response to this decision, CN110 may send another second MBS session resource modification request message to CN110, which includes the first MBS session ID and an indication to request CU172 to resume the first MBS session (534). In some embodiments, the indication may be an indication of resumption, or an indication to resume the first MBS session, or an IE to cause CU172 to resume the first MBS session. In response to receiving (534) or after receiving the MBS session resource modification request message, CU172 sends an MBS context modification request message to DU174, which includes an indication to resume the first MBS session (536). In some embodiments, CU172 may include the first MBS session ID in the MBS context modification request message. CU172 may or may not include the MRB ID(s) in the MBS context correction request message. In response to the MBS context correction request message, DU174 resumes the suspended resources and / or operations and sends an MBS context correction response message to CU172 (538). In response to receiving the MBS context correction response message (538), or after receiving it, CU172 may send an MBS session resource correction response message to CN110 (540) to confirm that the resources of the first MBS session have been resumed.

[0105] In some embodiments, CU172 may decide to request DU174 to resume the first MBS session without receiving an MBS session resource correction request message from CN110. For example, CU172 detects MBS data activity in response to receiving MBS data for the first MBS session (548), and makes a decision after detecting the MBS data activity. In response to the decision, CU172 may send an MBS context correction request message to DU174 (536). In response to the MBS context correction request message, DU174 resumes the suspended resource and / or operation and sends an MBS context correction response message to CU172 (538).

[0106] DU174 may resume sending the first MBS broadcast configuration message in response to or after receiving the MBS context correction request message (536) (542). Alternatively, DU174 may decide to send (e.g., broadcast) (542) a third MBS broadcast configuration message in response to or after receiving the MBS context correction 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 embodiments, DU174 generates the third MBS broadcast configuration message as described for the first MBS broadcast configuration message. In other embodiments, CU172 generates the third MBS broadcast configuration message and sends a CU-to-DU message containing the third MBS broadcast configuration message to DU174 as described for the first MBS broadcast configuration message. The CU-to-DU message may be an MBS context correction request message or an F1AP message.

[0107] In some embodiments, DU174 may reset the RLC state variable in response to or after receiving an MBS context correction request message (536). Alternatively, DU174 may refrain from resetting the RLC state variable in response to or after receiving an MBS context correction request message (536). If DU174 stops transmitting system information in response to or after receiving an MBS context correction request message (527), DU174 resumes transmitting system information in response to or after receiving an MBS context correction request message (536). Alternatively, DU174 may decide to transmit new system information, including new MBS control information, in response to or after receiving an MBS context correction request message (536). In response to the resumption or decision, DU174 transmits the (new) system information to UE102 via broadcast (544). In response to the resumption or decision of event 542, DU174 sends a first or third MBS broadcast configuration message (e.g., broadcast) via (new) MBS control information (546).

[0108] Events 534, 536, 538, and 540 are collectively referred to as the MBS resource restart procedure 590 in Figure 5G. After procedures 590, 542, 544, or 546, CN110 may send the MBS data for the first MBS session to CU172, as with event 518 (548). CU172 may then send the MBS data for the first MBS session to DU174, as with event 520 (550). DU174 then sends the MBS data for the first MBS session to UE102, as with event 522 (552). In some embodiments, DU174 may send the MBS data for the first MBS session using (reset) RLC state variables (552).

[0109] In some embodiments, CU172 includes CU-CP172A and CU-UP172B. In such cases, events 534, 536, 538, and 540 occur between CU-CP172A of CU172 and CN110 and DU174. After receiving the message for event 534, CU-CP172A may send an MBS bearer context correction request message (not shown in Figure 5G) to CU-UP172B, including a first MBS session ID and / or MRB ID(s)(or more), requesting CU-UP172B to resume resources and / or operations for the first MBS session. In some embodiments, CU-CP172A omits the PDU session ID from the MBS bearer context correction request message. In response to an MBS bearer context correction request message, CU-UP172B may resume the suspended resources (e.g., MBS bearer context) and / or operations for the first MBS session and send an MBS bearer context correction response message. After resuming the suspended resources and / or operations, CU-UP172B may, in response to receiving or after receiving the MBS bearer context correction request message, send (e.g., broadcast) the MBS data for the first MBS session to DU174 using one or more held PDCP entities (550). In one embodiment, CU-UP172B may send the MBS data using held PDCP state variables (550). In another embodiment, CU-UP172B may reset the PDCP state variables in response to the MBS bearer context correction request message and then send the MBS data for the first MBS session to UE102 using the PDCP state variables (552).

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

[0111] Scenario 500H may begin with any one of the 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), CN110 may decide to set up a second MBS session. In response to this decision, CN110, CU172, and DU174 may perform an MBS resource setup procedure for the second MBS session, similar to any one of the procedures 586A-E (587). In MBS resource setup procedure 587, CU172 or DU174 generates second MBS session information for the second MBS session, including a second MBS session ID, a second G-RNTI, and a second MRB configuration(s). The second MBS session ID identifies the second MBS session, and the second MRB configuration(s) constitute one or more MRBs for the second MBS session. CU172 or DU174 may further include second DRX configuration and / or second neighbor cell information in the second MBS session information. In response to or after performing the MBS resource setup procedure 587, DU174 may send system information via broadcast (554) and send a second MBS broadcast configuration message (556), as well as events 514 and 516, respectively. More specifically, CU172 or DU174 may include the first MBS session information and the second MBS session information in the second MBS broadcast configuration message. Thus, UE102 (i.e., the UE interested in receiving the first MBS session) and UE103 (the UE interested in receiving the second MBS session) can receive the broadcasted second MBS broadcast configuration message, which includes the first MBS session information and the second MBS session information, respectively.

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

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

[0114] Following the MBS resource setup procedure 587, CN110 transmits MBS data for the second MBS session to CU172 via the second common CN-BS DL tunnel (558). CU172 then transmits MBS data to DU174 via the second common CU-DU DL tunnel and / or additional common CU-DU DL tunnels according to the second PDCP configuration (560). DU174 then transmits (i.e., broadcasts) MBS data according to the MBS broadcast configuration message (e.g., via the 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). UE103 receives the MBS data according to the second MBS broadcast configuration or second MBS session information (562). For example, CU172 receives an MBS data packet (558), generates a PDCP PDU containing the MBS data packet according to the PDCP configuration, and transmits the PDCP PDU to DU174 via a second common CU-DU DL tunnel (560). In some embodiments, CU172 can use PDCP state variables to generate a PDCP sequence number included in the PDCP PDU. In some embodiments, DU174 generates a MAC PDU containing a second logical channel ID and the PDCP PDU, and transmits the MAC PDU to UE103 using a second G-RNTI (562). In some embodiments, DU174 can use RLC state variables to generate an RLC sequence number. UE103 receives the MAC PDU using the second G-RNTI (562), extracts the second logical channel ID and PDCP PDU from the MAC PDU, identifies the PDCP PDU associated with the MRB based on the second logical channel ID, and extracts the MBS data packets from the PDCP PDU according to the first PDCP configuration. In other embodiments, DU174 generates multiple RLC PDU segments containing the PDCP PDU, and each of the multiple RLC PDU segments contains a specific portion of the PDCP PDU, each containing an RLC sequence number (i.e., the same RLC sequence number) and the multiple RLC PDU segments.In some embodiments, DU174 can generate an RLC sequence number using an RLC state variable. For each of the multiple RLC PDU segments, DU174 generates a MAC PDU containing a first logical channel ID and the RLC PDU segment and transmits the MAC PDU to UE102 using a second G-RNTI (562). UE103 receives the MAC PDU using a second G-RNTI (562), extracts the second logical channel ID and the RLC PDU segment from the MAC PDU, assembles the RLC PDU segment to obtain a PDCP PDU, identifies the PDCP PDU associated with the MRB based on the second logical channel ID, and extracts the MBS data packets from the PDCP PDU according to the second PDCP configuration.

[0115] Following the MBS resource setup procedure 587, CN110 sends the MBS data for the first MBS session to CU172, as in event 518 (548). Next, CU172 sends the MBS data to DU174, as in event 520 (550). Subsequently, DU174 sends the MBS data to UE102 via broadcast, as in event 522 (552).

[0116] Subsequently, CN110, CU172, and DU174 perform the 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), DU174 stops broadcasting the first MBS session information. To stop broadcasting the first MBS session information, DU174 may send (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, CU172 includes CU-CP172A and CU-UP172B. In such cases, the events of step 587 occur between CU-CP172A of CU172 and CN110 and DU174. In such cases, events 518, 548, 558 and events 520, 550, 560 occur between CN110 and CU-UP172B, and between CU-UP172B and DU174, respectively. After receiving the MBS context setup response message of step 587, CU-CP172A may request CU-UP172B to establish an MBS bearer context for the second MBS session and / or MRB(s) by sending an MBS bearer context setup request message to CU-UP172B including a second MBS session ID and / or MRB(s) ID(s). In some embodiments, CU-CP172A omits the PDU session ID from the MBS bearer context setup request message. In response to the MBS bearer context setup request message, CU-UP172B can generate the MBS bearer context and send an MBS bearer context setup response message to CU-CP172A. In some embodiments, CU-UP can include a second CU DL transport layer configuration in the MBS bearer context setup response message, so that CU-CP172A can include at least one second CU DL transport layer configuration in the MBS session resource setup response message. Thus, CN110 can send MBS data for a second MBS session to CU-UP172B via at least one second common CN-BS DL tunnel (558).

[0118] In some embodiments, CU-CP172A may include a second PDCP configuration(s) in the MBS bearer context setup request message, and CU-UP172B may transmit MBS data for the second MBS session according to the second PDCP configuration(s) (560). In some embodiments, CU-UP172B may establish one or more PDCP entities according to the second PDCP configuration(s) and use one or more PDCP entities to transmit MBS data for the second MBS session to DU174 (560). In some embodiments, CU-CP172A may include MRB ID(s) in the MBS bearer context setup request message, and CU-CP172A may associate each of the second PDCP configuration(s) with a specific MRB / MRB ID(s) and indicate the association(s) in the MBS bearer context setup request message. In some embodiments, CU-CP172A includes at least one second DU DL transport layer configuration in the MBS bearer context setup request message so that CU-UP172B can send MBS data for a second MBS session to DU174 via at least one second common CU-DU DL tunnel (560).

[0119] In some embodiments, 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] Figure 5I is an exemplary messaging diagram of scenario 500I, similar to scenarios 500A-E, except that base station 104 later modifies resources for the first MBS session. Scenario 500I can be initiated by any one of the MBS resource setup procedures 586A-E.

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

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

[0123] In some embodiments, CN110 may include a new QoS configuration(s) in an MBS session resource modification request message to request CU174 to modify resources for the first MBS session. In such cases, CU172 may include a new QoS configuration(s) in an MBS context modification request message. Thus, DU174 can implement the new QoS configuration(s) to transmit MBS data for the first MBS session (552).

[0124] In some embodiments, DU174 may, in response to or as a result of the MBS resource correction procedure 591, send a new MBS broadcast configuration message containing new MBS session information for a first MBS session via one or more cells according to MBS control information (517). The new MBS session information may include a first MBS session ID, a first MRB configuration(s), a new MRB configuration(s) (described below), and / or a DRX configuration (i.e., either the first DRX configuration or the new DRX configuration described below). In some embodiments, DU174 may generate new MBS session information or a new MBS broadcast configuration message as described in Figure 5A. In other embodiments, CU172 may generate new MBS session information or a new MBS broadcast configuration message as described in Figure 5C.

[0125] In some embodiments, CU172 can configure or generate a new DRX cycle configuration that includes a new DRX cycle length and include the new DRX cycle configuration in the MBS context correction request message. In some embodiments, CU172 can determine the new DRX cycle length according to the new QoS configuration(s). In other embodiments, CU172 can receive the new DRX cycle length in the MBS session resource correction request message. After receiving the new DRX cycle length, DU174 can generate a new DRX configuration (e.g., DRX-ConfigPTM IE) according to the new DRX cycle length. In some embodiments, DU174 generates new MBS session information that includes the new DRX configuration and generates a new MBS broadcast configuration message that includes the new MBS session information. In other embodiments, DU174 includes the new DRX configuration in the MBS context correction response message. In such a case, CU172 generates new MBS session information including the new DRX configuration and sends a CU-to-DU message (e.g., an F1AP message) containing the new MBS session information to DU174. DU174 then generates a new MBS broadcast configuration message containing the new MBS session information. Alternatively, CU172 generates a new MBS broadcast configuration message containing the new MBS session information and sends a CU-to-DU message (e.g., an F1AP message) containing the new MBS session information to DU174.

[0126] In some embodiments, CU172 may decide to configure an additional MRB for the first MBS session in response to an MBS session resource modification request message or according to a new QoS configuration(s). For example, the new QoS configuration(s) may include a new QoS flow ID for a new QoS flow, and CU172 may decide to configure an additional MRB for the new QoS flow. In response to this decision, CU172 may include an additional PDCP configuration for the additional MRB in the MBS context modification request message, as well as in event 504. CU172 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, DU174 may generate an additional RLC configuration for the additional PDCP configuration or additional MRB. The additional RLC configuration includes an additional logical channel ID. DU174 can generate additional MRB configurations including additional RLC configurations and additional PDCP configurations, generate new MBS session information (e.g., MBS-SessionInfo IE) including a first MBS session ID, a first G-RNTI, a first MRB configuration(s), and additional MRB configurations, and generate a new MBS broadcast configuration message including the MBS session information. DU174 then transmits the new MBS broadcast configuration message via one or more cells according to the MBS control information, as well as event 516 (517). In some embodiments, DU174 may include a new G-RNTI(value) in the new MBS session information instead of the first G-RNTI(value).

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

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

[0129] Next, several exemplary methods in which the devices shown in Figures 1A and 1B, such as the CU172 (which may include CU-CP172A and CU-UP172B), and the DU174 of base station 104 can be implemented will be described with reference to Figures 6A to 11. The exemplary methods described with reference to Figures 6A to 11 can be performed during the scenarios 500A to 500I described above. Each of these methods can be implemented as a set of instructions that can be stored in a non-temporary computer-readable medium and executed by one or more processors.

[0130] Referring first to Figure 6A, a DU such as DU174 can implement method 600A to send configuration parameters for sending MBS data for an MBS session.

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

[0132] In block 612, the DU receives at least one second CU-to-DU message from the third RAN node containing 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 containing the first MBS session information and the second MBS session information for the second MBS session (see, e.g., event 587). Alternatively, the DU receives the second MBS broadcast configuration message in one of the at least one second CU-to-DU messages from the third RAN node (see, e.g., events 513, 587). Since the first MBS broadcast configuration message does not contain the second MBS session information, the second MBS broadcast configuration message replaces the first MBS broadcast configuration message. In block 616, the DU sends the second MBS broadcast configuration message through one or more cells as described for scenario 500H (see, e.g., event 556). In block 618, the DU receives MBS data for the second MBS session from the fourth RAN node (see, for example, event 560). In block 620, the DU uses the second MBS session information to transmit MBS data for the second MBS session through one or more cells (see, for example, event 562). After sending the second MBS broadcast configuration message, the DU may receive subsequent MBS data for the first MBS session from the second RAN node and use the first MBS session information to transmit subsequent MBS data through one or more cells.

[0133] According to Method 600A, the DU can send new MBS session information for a new MBS session.

[0134] In some embodiments, at least one first CU-to-DU message may include an MBS session setup list containing a first MBS session ID. Similarly, at least one second CU-to-DU message may include an MBS session setup list containing a second MBS session ID. In some embodiments, the DU may generate first MBS session information and / or second MBS session information. In other embodiments, the DU may receive first MBS session information and / or second MBS session information from a first RAN node and / or a third RAN node, respectively. In such cases, the DU may include first MBS session information and / or 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, at least one first CU-to-DU message includes a first PDCP configuration(s). In other embodiments, at least one first CU-to-DU message does not include a first PDCP configuration(s). In such cases, the DU can receive a first PDCP configuration(s) from a first Operation, Management, and Maintenance (OAM) node, in one embodiment. In another embodiment, the first PDCP configuration(s) are pre-configured for a first MBS session ID. That is, the DU stores a first PDCP configuration(s) before receiving at least one first CU-to-DU message.

[0137] In some embodiments, at least one second CU-to-DU message includes a second PDCP configuration(s). In other embodiments, at least one second CU-to-DU message does not include a second PDCP configuration(s). In such cases, 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 a second MBS session ID. That is, the DU stores the second PDCP configuration(s) before receiving at least one second CU-to-DU message. The first OAM node and the second OAM node may 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 cases, the first RAN node may be CU-CP and the second RAN node may be 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 cases, the third RAN node may be CU-CP and the fourth RAN node may be 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 may be different CU or CU-CP. 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 may be different CU-UP.

[0139] In response to at least one first CU-to-DU message, the DU may, in some embodiments, generate a first DRX configuration for a first DRX cycle. 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 inactive state 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 the DRX cycle length and the subframe number from which the first DRX cycle begins. In some embodiments, at least one first CU-to-DU message may include a first DRX cycle configuration for a 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 cases, 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 a DRX cycle start offset configuration as a pre-configured DRX cycle length.

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

[0141] Similarly, in response to at least one second CU-to-DU message, the DU may, in some embodiments, generate a second DRX configuration for a second DRX cycle. In the second DRX cycle configuration, the DU may include at least one second DRX parameter, such as a DRX on-duration timer value, a DRX inactive state 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 the DRX cycle length and the subframe number from which the second DRX cycle begins. In some embodiments, at least one first CU-to-DU message may include a second DRX cycle configuration for a first MBS session. The second DRX cycle configuration includes the second DRX cycle length. In some embodiments, the second DRX cycle configuration is the CU-DU interface protocol IE. In such cases, the DU configures the DRX cycle length in the DRX cycle start offset configuration as the second DRX cycle length. If at least one second CU-to-DU message does not include a DRX cycle configuration, the DU configures the DRX cycle length with a DRX cycle start offset configuration as a pre-configured DRX cycle length.

[0142] In other embodiments, instead of autonomously generating the first DRX configuration, the DU receives the second DRX configuration from the third RAN node in 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., a first or third RAN node or DU) can determine the 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., a first or second MBS session).

[0144] In some embodiments, at least one first DRX parameter and at least one second DRX parameter include the same or different parameters. For example, at least one first DRX parameter and at least one second DRX parameter each include a first on-duration for a first DRX cycle and a second on-duration for a second DRX cycle. The DU transmits the MBS data for the first MBS session and the MBS data for the second MBS session within the first on-duration and the second on-duration, respectively. The DU may configure the first on-duration and the second on-duration to not overlap in order to provide sufficient radio resources to transmit the MBS data for the first MBS session and the MBS data for the second MBS session. Alternatively, the DU may configure the first on-duration and the second on-duration to partially or completely overlap in order to simplify embodiments of the DU and to save power for UEs receiving the first and second MBS sessions simultaneously.

[0145] Figure 6B is an exemplary flowchart of Method 600B, similar to Method 600A except that the DU receives a CU-to-DU message containing session IDs for two MBS sessions, rather than a single MBS session.

[0146] Method 600B begins in block 603, in which the DU receives a CU-to-DU message from the first RAN node containing the first MBS session ID and the third MBS session ID for the first MBS session and the third MBS session, respectively (see, e.g., events 503, 504, 510, 513, 537, 586A-E, 591). In some embodiments, the CU-to-DU message may be one of at least one first CU-to-DU message described in Figure 6A. In block 605, the DU generates a first MBS broadcast configuration message containing the first MBS session information and the 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 sending the first MBS broadcast configuration message, the DU can receive MBS data for the first MBS session and MBS data for the third MBS session in blocks 608 and 619, respectively. In block 610, the DU uses the first MBS session information to transmit MBS data for the first MBS session through one or more cells. In block 621, the DU uses the third MBS session information to transmit MBS data for the third MBS session through one or more cells.

[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 a first PDCP configuration and / or a third PDCP configuration. In other embodiments, the CU-to-DU message does not include a first and / or third PDCP configuration. In such cases, the DU may receive a first and / or third PDCP configuration from a first OAM node, in one embodiment. In another embodiment, the first and / or third PDCP configurations are pre-configured for the first and / or third MBS session IDs, respectively. In other words, the DU stores the first and / or third PDCP configuration(s) before receiving the CU-to-DU message.

[0148] In response to a CU-to-DU message, the DU may, in some embodiments, generate a first DRX configuration for a first DRX cycle, as described with reference to Figure 6A. In response to a CU-to-DU message, the DU may, in some embodiments, generate a third DRX configuration for a 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 inactive state 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 may indicate or include the DRX cycle length and the subframe number from which the third DRX cycle begins. In some embodiments, the CU-to-DU message may include a first DRX cycle configuration for a first MBS session, as described with reference to Figure 6A. The CU-to-DU message may include a third DRX cycle configuration for a third MBS session. The third DRX cycle configuration includes the third DRX cycle length. In some embodiments, the third DRX cycle configuration is the CU-DU interface protocol IE. In such cases, the DU configures the DRX cycle length as the third DRX cycle length using the DRX cycle start offset configuration. 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 as the pre-configured DRX cycle length using the DRX cycle start offset configuration.

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

[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., the first RAN node or DU) can determine the DRX cycle length (e.g., the first or third DRX cycle length) according to one or more QoS configurations required for an MBS session (e.g., the first or third MBS session).

[0151] In some embodiments, at least one first DRX parameter and at least one third DRX parameter include the same or different parameters. For example, at least one first DRX parameter and at least one third DRX parameter include a first on-duration for the first DRX cycle and a third on-duration for the third DRX cycle, respectively. The DU transmits the MBS data for the first MBS session and the MBS data for the third MBS session within the first on-duration and the third on-duration, respectively. The DU may configure the first on-duration and the third on-duration to not overlap in order to provide sufficient radio resources to transmit the MBS data for the first MBS session and the MBS data for the third MBS session. Alternatively, the DU may configure the first on-duration and the third on-duration to partially or completely overlap in order to simplify embodiments of the DU and to save power for UEs receiving the first and third MBS sessions simultaneously.

[0152] Referring next to Figure 7A, a CU such as CU172 can implement Method 700A to transmit configuration parameters for transmitting MBS data for an MBS session. In some embodiments, the CU-CP and CU-UP of the CU, such as CU-CP172A and CU-UP172B respectively, implement Method 700A. Control plane functions that can be performed by the CU-CP are shown in boxes labeled "CP", and user plane functions that can be performed by the CU-UP are shown in boxes labeled "UP". These "CP" and "UP" boxes are similarly used in Figures 7B and 9A-9B to illustrate control plane and user plane functions that can be performed by the CU-CP and CU-UP, respectively.

[0153] Method 700A begins in block 702, in which a CU or CU-CP receives a first CN-to-BS message from a first CN node containing a first MBS session ID to request resources for the first MBS session (see, e.g., events 502, 586A-E). In block 704, the CU or CU-CP sends at least one first CU-to-DU message containing a first MBS session ID to at least one first DU to cause at least one first DU to broadcast a first MBS broadcast configuration message (see, e.g., events 503, 504, 510, 513, 537, 586A-E, 591). In block 706, the CU or CU-CP configures at least one first CU-UP to receive MBS data for the first MBS session from the second CN by sending at least one first CP-to-UP message to at least one first CU-UP, and configures at least one first CU-UP to send MBS data to at least one first DU. In block 708, the CU or CU-UP receives MBS data for the first MBS session from the second CN node (see, for example, events 518, 548). In block 710, the CU or CU-UP sends MBS data for the first MBS session to at least one first DU (see, for example, events 520, 550).

[0154] In block 712, the CU or CU-CP receives a second first CN-to-BS message from a third CN node, containing the second MBS session ID and requesting resources for the second MBS session (see, for example, event 587). In block 714, the CU or CU-CP sends at least one second CU-to-DU message containing the second MBS session ID to at least one second DU, causing at least one second DU to broadcast a second MBS broadcast configuration message (see, for example, event 587), as described in 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, configuring at least one second CU-UP to receive MBS data for the second MBS session from a fourth CN, and configuring at least one second CU-UP to send MBS data to at least one second DU. In block 718, the CU or CU-UP receives MBS data for the second MBS session from the fourth CN node (see, for example, event 560). In block 720, the CU or CU-UP sends MBS data for the second MBS session to at least one second DU (see, for example, 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, at least one first DU and at least one second DU may include the same DU and / or different DUs.

[0156] In some embodiments, at least one first CU-to-DU message and at least one second CU-to-DU message are as described with respect to Figure 6A. In some embodiments, the first and second MBS broadcast configuration messages are as described with respect to Figure 6A. In some embodiments, at least one first CU-to-DU message and at least one second CU-to-DU message may each include a first PDCP configuration and a second PDCP configuration, as described with respect to Figure 6A. In other embodiments, at least one first CU-to-DU message and at least one second CU-to-DU message may each include a first MRB configuration and a second MRB configuration, as described with respect to Figure 6A. In yet another embodiment, at least one first CU-to-DU message and at least one second CU-to-DU message may each include first MBS session information and second MBS session information, as described with respect to Figure 6A.

[0157] Figure 7B is an exemplary flowchart of Method 700B, similar to Method 700A in Figure 7A, except for blocks 703, 705, 707, 719, and 721. Similar to Method 700A, in some embodiments, the CU's CU-CP and CU-UP implement Method 700B, and the respective exemplary functions of the CU-CP and CU-UP are indicated in Figure 7B by boxes labeled "CP" and "UP". Furthermore, similar to Method 600B, the CU sends a CU-to-DU message containing session IDs for two MBS sessions.

[0158] Method 700B begins in block 703, in which the CU or CU-CP receives a CN-to-BS message from a first CN node containing a first MBS session ID and a third MBS session ID, requesting resources for the first MBS session and the third MBS session, respectively (see, e.g., events 502, 586A-E, 587). In block 705, the CU or CU-CP sends a CU-to-DU message to at least one first DU containing a first MBS session ID and a third MBS session ID, causing 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 embodiments, the CU-to-DU message may be one of at least one first CU-to-DU messages described in Figure 7A. In block 707, the CU or CU-CP configures at least one first CU-UP to receive MBS data for the first and third MBS sessions from the second CN by sending at least one first CP-to-UP message to at least one first CU-UP, and configures at least one first CU-UP to send MBS data to at least one first DU. In block 719, the CU or CU-UP receives MBS data for the third MBS session from the second CN node (see, for example, events 518 and 548). In block 721, the CU or CU-UP sends MBS data for the third MBS session to at least one first DU (see, for example, events 520 and 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 embodiments, the CU-to-DU message is as described with respect to Figure 6B. In some embodiments, the first MBS broadcast configuration message is as described with respect to Figure 6B. In some embodiments, the CU-to-DU message may include a first PDCP configuration and a third PDCP configuration, as described with respect to Figure 6B. In other embodiments, the CU-to-DU message may include a first MRB configuration and a third MRB configuration, as described with respect to Figure 6B. In yet another embodiment, the CU-to-DU message may include first MBS session information and third MBS session information, as described with respect to Figure 6B.

[0160] Referring here to Figure 8A, a DU such as DU174 can implement method 800A to set up and later pause or release resources for an MBS session. Method 800A begins in block 802, in which the DU performs a first CU-DU procedure using a first RAN node to configure resources for the MBS session (see, for example, events 503, 504, 510, 513, 537, 586A-E, 587, 591). In block 804, in response to the first CU-DU procedure, the DU sends an MBS control message containing MBS session information for the MBS session through one or more cells (see, for example, events 516, 517, 546, 556). For example, the MBS control message could be an MBS broadcast configuration message. In block 806, the DU receives MBS data for the MBS session from a second RAN node (see, for example, events 520, 550, 560). In block 808, the DU uses the MBS session information to send MBS data for the MBS session through one or more cells (see, for example, events 522, 552, and 562). In block 810, the DU performs a second CU-DU procedure using the first RAN node to pause or release resources for the MBS session (see, for example, events 526, 528, 527, 529, 588, and 589). The flow can then proceed to either block 812 or block 814. In block 812, the DU stops sending MBS control messages in response to the second CU-DU procedure (see, for example, event 532). In block 814, the DU updates the MBS control message to exclude the MBS session information in response to the second CU-DU procedure (see, for example, event 533). In block 816, the DU sends the updated MBS control message through one or more cells (see, for example, event 564).

[0161] In some embodiments, the DU may decide to stop sending MBS control messages (i.e., proceed to block 812) or to update the MBS control messages to exclude the MBS session information (i.e., proceed to block 814), depending on whether the MBS session is the last (i.e., only) MBS session in which the DU constitutes a resource. If the MBS session is the last MBS session, the DU may stop sending MBS control messages. If the MBS session is not the last MBS session (i.e., there are other MBS sessions in which the DU constitutes a resource), the DU may update the MBS control messages to exclude the MBS information for the MBS session and send the updated MBS control messages.

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

[0163] Figure 8B is an exemplary flowchart of 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 using a first RAN node to modify resources for the MBS session. In block 813, the DU updates the 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 uses the (updated) MBS session information to transmit MBS data for the MBS session through one or more cells.

[0164] In some embodiments, the DU adds or modifies configuration parameters to the MBS session information as a result of a second CU-DU procedure. Therefore, in block 813, the DU updates the MBS control message to include the added or modified configuration parameters. 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 cases, in block 820, the DU implements the new QoS configuration(s) to transmit MBS data for the MBS session using the (updated) MBS session.

[0165] Referring to Figure 9A, a CU such as CU172 can implement Method 900A to set up resources for an MBS session and later release or pause them. As illustrated with reference to Figures 7A and 7B, CU-CP and CU-UP of CUs such as CU-CP172A and CU-UP172B, respectively, can implement Method 900A, and exemplary functions of CU-CP and CU-UP, respectively, are shown in Figure 9A by boxes labeled "CP" and "UP".

[0166] Method 900A begins in block 902, in which a CU or CU-CP configures resources for broadcasting an MBS session by performing a first CN-BS procedure using a CN (see, for example, events 502, 508, 586A-E). In block 904, in response to the first CN-BS procedure, the CU or CU-CP configures resources for the MBS session by performing at least one first CU-DU procedure using at least one DU (see, for example, events 503, 504, 505, 506, 510, 513, 537, 539, 586A-E, 591). In block 906, in response to the first CN-BS procedure, the CU or CU-CP configures resources for the MBS session by performing at least one first CP-UP procedure using at least one CU-UP. 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 using 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 using 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 with at least one CU-UP to release or suspend resources for the broadcast MBS session in response to a second CN-BS procedure.

[0167] Figure 9B is an exemplary flowchart of Method 900B, similar to Method 900A in Figure 9A, except for blocks 913, 915, 917, 918, and 920. Furthermore, similar to Method 700A, in some embodiments, the CU's CU-CP and CU-UP implement Method 900B, and the respective exemplary functions of the CU-CP and CU-UP are indicated in Figure 9B by boxes labeled "CP" and "UP". In contrast to Method 900B, in Method 900A, the CU modifies resources for the MBS session. In block 913, the CU or CU-CP modifies resources for the MBS session by performing a second CN-BS procedure using the CN (see, for example, events 535, 541, and 591). In block 915, the CU or CU-CP performs a second CU-DU procedure using at least one DU to correct resources for the MBS session in response to a 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 using at least one CU-UP to correct resources for the MBS session in response to a second CN-BS procedure. In block 918, the CU or CU-UP receives MBS data for the broadcast MBS session from the CN (see, e.g., event 548). In block 920, the CU or CU-UP transmits MBS data for the MBS session via at least one DU according to the corrected resources (see, e.g., event 550).

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

[0169] In some embodiments, the DU generates an MBS session information element (e.g., MBS session information such as MBS-SessionInfo IE), includes configuration parameters in the MBS session information element, and sends the configuration parameters to the UE by sending the MBS session information element to the UE (e.g., events 512, 515, and 516 in Figures 5A, 5B, and 5E). In such embodiments, the DU may receive a PDCP configuration from the CU (e.g., in a CU-to-DU message received in block 1002 (e.g., event 504), or in a second CU-to-DU message after receiving a 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 pre-configured PDCP configuration and include it in the MBS session information element (e.g., event 515). Furthermore, 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 group temporary identifier (e.g., G-RNTI) and include the RLC configuration and / or 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 receives an MBS session information element containing the configuration parameters from the CU before sending the configuration parameters, and sends the configuration parameters to the UE by sending the MBS session information element (e.g., events 513 and 516 in Figures 5C and 5D). In such embodiments, the DU may send to the CU information to be included in the MBS session information element, such as an RLC configuration and / or group temporary identifier associated with the MBS session. The DU may send the information in a DU-to-CU message in response to a 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., an MBSBroadcastConfiguration message) containing the MBS session information element from the CU and send 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 containing the MBS session information element, and send the MBS broadcast configuration message to the UE.

[0171] Depending on the scenario, method 1000 may also include configuring resources for multiple MBS sessions. A CU-to-DU message received by the DU in block 1002 (i.e., a first CU-to-DU message that identifies a first MBS session and requests the DU to configure a first resource for the first MBS session) may identify a second MBS session and request the DU to configure a second resource for the second MBS session (e.g., by including a first session ID for the first MBS session and a second session ID for the second MBS session), or the DU may receive a second CU-to-DU message after receiving the first CU-to-DU message in block 1002, the second CU-to-DU message identifying a second MBS session and requesting the DU to configure a second resource for the second MBS session (e.g., by including a second session ID for the second MBS session) (e.g., event 587). To send a second configuration parameter, the DU may send the first configuration parameter along with the second parameter (for example, by sending the first and second MBS session information elements in an MBS broadcast configuration message) (e.g., event 556). If the DU later receives a CU-to-DU message indicating that the DU is releasing or suspending the first resource for the first MBS session, the DU may send an MBS broadcast message that includes the second MBS session information but excludes the first MBS session information element (e.g., event 564).

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

[0173] Referring to Figure 11, a DU (e.g., DU174) and a CU (e.g., CU172) of a distributed base station (e.g., base station 104 or 106) including a CU can implement method 1100 for configuring a UE (e.g., UE102) to receive an MBS. The method may be implemented by processing hardware (e.g., processing hardware 130 or 140). In block 1102, the CU receives a CN-to-BS message from the CN requesting the distributed base station to configure resources for an MBS session (e.g., event 502). In block 1104, the CU sends a CU-to-DU message to the DU identifying the MBS session, 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 embodiments reflects the various embodiments expressly intended by this disclosure.

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

[0176] Example 2. The method according to Example 1, further comprising generating an MBS session information element, including the configuration parameters in the MBS session information element, wherein transmitting the configuration parameters is a part of 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, wherein the MBS session information element includes the PDCP configuration.

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

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

[0180] Example 6. The method of Example 2, further comprising the processing hardware retrieving a pre-configured packet data convergence protocol (PDCP) configuration in the DU, and generating the MBS session information element, wherein the MBS session information element includes the PDCP configuration.

[0181] Example 7. The method according to any one of Examples 2 to 6, further comprising the processing hardware receiving an intermittent receive (DRX) configuration along with the PDCP configuration from the CU, and generating the MBS session information element, wherein the MBS session information element includes the DRX configuration.

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

[0183] Example 9. The 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 includes including the group temporary identifier in the MBS session information element.

[0184] Example 10. The method according to any one of Examples 2 to 9, wherein receiving the CU-to-DU message includes receiving the CU-to-DU message which includes 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 according to Example 1, further comprising the processing hardware receiving an MBS session information element containing the configuration parameter from the CU before transmitting the configuration parameter, wherein transmitting the configuration parameter includes transmitting the MBS session information element.

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

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

[0188] Example 14. The method according to Example 12 or 13, wherein transmitting the information includes transmitting a temporary group 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. The method according to any one of Examples 12 to 14, further comprising the processing hardware sending a first DU-to-CU message to the CU in response to the CU-to-DU message, wherein the transmission of the information includes sending the information in a second DU-to-CU message after the first DU-to-CU message has been sent.

[0191] Example 17. The 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 containing the MBS session information element, and transmitting the MBS session information element includes transmitting an MBS broadcast configuration message.

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

[0193] Example 19. The method according to Example 17 or 18, wherein sending the MBS broadcast configuration message includes sending the MBSBroadcastConfiguration message.

[0194] Example 20. The method according to any one of the prior embodiments, wherein the CU-to-DU message is a first CU-to-DU message that identifies a first MBS session and requests the DU to configure a first resource for the first MBS session, the configuration parameter is a first configuration parameter, and the method further comprises the processing hardware receiving a second CU-to-DU message from the CU that identifies a second MBS session and requests the DU to configure a second resource for the second MBS session, and the processing hardware transmitting a second configuration parameter for receiving the second MBS session to the UE in response to receiving the second CU-to-DU message.

[0195] Example 21. The method according to 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 according to Example 20 or 21, wherein receiving the second CU-to-DU message includes receiving the second CU-to-DU message containing a session identifier (ID) that identifies the second MBS session.

[0197] Example 23. The method according to any one of Examples 1 to 19, wherein the MBS session is a first MBS session, the resource is a first resource, 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 parameter includes transmitting the first configuration parameter together with the second configuration parameter for receiving the second MBS session.

[0198] Example 24. The method according to Example 23, wherein receiving the CU-to-DU message includes receiving a CU-to-DU message that includes 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 according to 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 containing the first configuration parameter together with a second MBS session information element containing 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 comprising the first MBS session information element and the second MBS session information element.

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

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

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

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

[0205] Example 31. The method according to Example 30, further comprising holding the configuration parameters by the processing hardware.

[0206] Example 32. The method according to Example 30 or 31, wherein the request is a first request, and the method further comprises the processing hardware receiving a request from the CU to resume the resources for the MBS session and the processing hardware to resume sending the configuration parameters.

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

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

[0209] Example 35. The method according to any one of the prior embodiments, wherein transmitting the configuration parameter includes broadcasting the configuration parameter to a plurality of UEs, the plurality of UEs including the UE.

[0210] Example 36. A method according to any one of the prior embodiments, further comprising: the processing hardware receiving MBS data for the MBS session from the CU; and the processing hardware transmitting the MBS data to the UE according to the configuration parameters.

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

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

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

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

[0215] Example 41. The method according to any one of Examples 38 to 40, wherein transmitting the PDCP configuration includes transmitting an intermittent receive (DRX) configuration along with the PDCP configuration, causing the DU to include the DRX configuration in the configuration parameters.

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

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

[0218] Example 44. The method according to Example 42 or 43, further comprising: generating an intermittent reception (DRX) configuration by the processing hardware; and including the DRX configuration in the configuration parameters by the processing hardware.

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

[0220] Example 46. The method according to any one of Examples 42 to 45, further comprising receiving information from the DU by the processing hardware to be included in the MBS session information element, and generating the MBS session information element, which includes including the information in the MBS session information element.

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

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

[0223] Example 49. The method according to 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. The method according to any one of Examples 46 to 48, further comprising: the processing hardware receiving a first DU-to-CU message in response to the CU-to-DU message; and the processing hardware receiving a second DU-to-CU message containing the information after receiving the first DU-to-CU message.

[0225] Example 51. The method according to any one of Examples 37 to 50, wherein the CN-to-BS message is a first CN-to-BS message requesting the distributed base station to configure a first resource for a first MBS session, the CU-to-DU message is a first CU-to-DU message, the configuration parameter is a first configuration parameter, and the method further comprises the processing hardware receiving a second CN-to-BS message requesting the distributed base station to configure a second resource for a second MBS session, and the processing hardware sending a second CU-to-DU message to the UE causing the DU to send a second configuration parameter for receiving the second MBS session.

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

[0227] Example 53. The method according to 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, the configuration parameter is a first configuration parameter, receiving the CN-to-BS message includes receiving the CN-to-BS message further requesting the distributed base station to configure a second resource for a second MBS session, and transmitting the CU-to-DU message includes transmitting the CU-to-DU message further identifying the second MBS session, causing the DU to transmit the first configuration parameter along with a second configuration parameter for receiving the second MBS session.

[0228] Example 54. The method according to Example 53, wherein receiving the CN-to-BS message includes receiving the CN-to-BS message which includes a first session identifier (ID) which identifies the first MBS session and a second session ID which identifies the second MBS session, and sending the CU-to-DU message includes sending the CU-to-DU message which includes the first session ID and the second session ID.

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

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

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

[0232] Example 58. The 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 configuring the UP logical node of the central unit to receive the MBS data from the CN and transmit the MBS data to the DU via the control plane (CP) logical node of the central unit.

[0234] Example 60. The method according to 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. The method according to any one of Examples 37 to 60, wherein sending the CU-to-DU message includes sending the CU-to-DU message which includes a session identifier (ID) that identifies the MBS session.

[0236] Example 62. A network node comprising processing hardware and configured to implement the method described in any one of the prior embodiments.

[0237] The following additional considerations apply to the above description.

[0238] In some embodiments, “message” is used and can be replaced with “information element (IE)” and vice versa. In some embodiments, “IE” is used and can be replaced with “field” and vice versa. In some embodiments, “configuration” can be replaced with “multicast” or configuration parameter. In some embodiments, “MBS” can be replaced with “multicast” or “broadcast”. The messages described in the above events are examples and should not limit the applicability of the 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, CU-to-DU messages and DU-to-CU messages may be F1AP messages. 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, CP-to-UP messages and UP-to-CP messages may be E1 Application Protocol (E1AP) messages.

[0239] User devices that can implement the technology of this disclosure (e.g., UE102 or 103) may be any suitable wireless communication-capable device such as a smartphone, tablet computer, laptop computer, mobile game console, point-of-sale (POS) terminal, health management device, drone, camera, media streaming dongle or other personal media device, smartwatch, wireless hotspot, femtocell, or wearable device such as a broadband router. Furthermore, in some cases, the user device may be embedded in an electronic system such as a vehicle head unit or advanced driver-assistance system (ADAS). Moreover, 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 described herein include logic, or several components, modules, or mechanisms. A module may be a software module (e.g., code stored in a non-temporary machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing a certain operation 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 an application-specific processor such as an application-specific integrated circuit (ASIC)) to perform a certain operation. 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 a certain operation. 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 left to cost and time considerations.

[0241] When implemented in software, the technique may be provided as part of an operating system, a library used by multiple applications, or a specific software application. The software can run on one or more general-purpose processors or one or more special-purpose processors.

[0242] A person skilled in the art will understand, by reading this disclosure, yet another alternative structural and functional design for communicating MBS information through the principles disclosed herein. Therefore, while specific embodiments and applications are shown and described, it should be understood that the disclosed embodiments are not limited to the exact configurations and components disclosed herein. Various modifications, changes, and variations obvious to a person 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. A method for configuring user equipment (UE) to receive multicast and / or broadcast services (MBS), which is implemented in the DU of a distributed base station including a central unit (CU) and a distributed unit (DU), The processing hardware of the DU receives an MBS context setup request for the MBS session from the CU, which requests the DU to configure resources for the MBS session, wherein the MBS context setup request includes a Packet Data Convergence Protocol (PDCP) configuration. In response to receiving the aforementioned MBS context setup request, the processing hardware transmits to the UE configuration parameters for receiving the MBS session, including at least the PDCP configuration. Methods that include...

2. To generate MBS session information elements, The MBS session information element includes the configuration parameters, It further includes, Sending the aforementioned configuration parameters This includes transmitting the aforementioned MBS session information elements. The method according to claim 1.

3. Receiving the aforementioned MBS context setup request includes receiving the aforementioned MBS context setup request which includes a session identifier (ID) that identifies the MBS session, Generating the aforementioned MBS session information element includes including the session identifier in the aforementioned MBS session information element. The method according to claim 2.

4. The processing hardware further includes receiving an MBS session information element from the CU, which includes at least some of the configuration parameters, before transmitting the configuration parameters. Transmitting the aforementioned configuration parameters includes transmitting the aforementioned MBS session information elements. The method according to claim 1.

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

6. The processing hardware receives a request from the CU to release the resources for the MBS session, The processing hardware stops the transmission of the configuration parameters, The method according to any one of claims 1 to 5, further comprising:

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

8. The processing hardware receives a request to modify the resources for the MBS session, The processing hardware modifies the configuration parameters according to the request, The processing hardware transmits the modified configuration parameters, The method according to any one of claims 1 to 5, further comprising:

9. A method for configuring user equipment (UE) to receive multicast and / or broadcast services (MBS), which is implemented in the CU of a distributed base station including a distributed unit (DU) and a central unit (CU), The CU's processing hardware receives a CN-to-BS message from the core network (CN) requesting the distributed base station to configure resources for an MBS session. The processing hardware instructs the DU to identify the MBS session and send an MBS context setup request including a Packet Data Convergence Protocol (PDCP) configuration, causing the DU to send configuration parameters for receiving the MBS session, including the PDCP configuration, to the UE. Methods that include...

10. The aforementioned processing hardware generates MBS session information elements, The processing hardware includes including at least some of the configuration parameters in the MBS session information element. The processing hardware transmits the MBS session information elements to the DU, The method according to claim 9, further comprising:

11. The processing hardware generates an MBS broadcast configuration message including the MBS session information element, The processing hardware transmits the MBS broadcast configuration message to the DU, The method according to claim 10, further comprising:

12. The processing hardware further includes receiving information from the DU to be included in the MBS session information element, Generating the aforementioned MBS session information element includes including the aforementioned information in the aforementioned MBS session information element. The method according to claim 10 or 11.

13. The method according to 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 according to any one of claims 9 to 13, further comprising sending a request to the DU by the processing hardware to release, modify, or suspend the resources for the MBS session.

15. The method according to any one of claims 9 to 14, further comprising configuring the UP logical node of the central unit to send a CP-to-UP message to the user plane (UP) logical node of the central unit via the control plane (CP) logical node of the central unit to receive MBS data from the CN and 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