Managing paging for multicast and / or broadcast services (MBS) services

Abstract

Managing paging for multicast and / or broadcast services (MBS) of interested UEs that do not have an active radio connection with the RAN may include providing an indication of radio capabilities of each of the interested UEs along with identities of the interested UEs in an MBS service paging order, e.g., so that the DU can obtain the necessary UE radio capability information according to the paging order. Another technique may include a base station providing an indication of the UE radio capability information of the interested UEs to another base station. Yet another technique includes storing, in the DU or CU, the indication of the UE radio capabilities and / or a default or predefined set of UE radio capabilities for use in paging the interested UEs.

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE The present disclosure relates to wireless communications, and more particularly, to managing paging for multicast and / or broadcast communications. [Background technology]

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

[0003] In telecommunication systems, the Packet Data Convergence Protocol (PDCP) layer 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 Evolved Universal Terrestrial Radio Access (EUTRA) air interface (see 3GPP® specification TS 36.323) and New Radio (NR) (see 3GPP specification TS 38.323) provides sequencing of protocol data units (PDUs) in the uplink direction (from a user device, also known as user equipment (UE) to a base station) as well as in the downlink direction (from a base station to a UE). Furthermore, the PDCP sublayer provides services for signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer. The PDCP sublayer also provides services for data radio bearers (DRBs) to the Service Data Adaptation Protocol (SDAP) sublayer or protocol layers such as the Internet Protocol (IP) layer, the Ethernet protocol layer, and the Internet Control Message Protocol (ICMP) layer. In general, the UE and the base station can exchange RRC messages and non-access stratum (NAS) messages using the SRBs and can transport data in the user plane using the DRBs.

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

[0005] In some scenarios, the UE may operate in a state where the radio resource control connection with the RAN is not active (e.g., RRC_IDLE or RRC_INACTIVE state) and subsequently transition to a connected state. In general, in the inactive state, the radio connection between the UE and the radio access network (RAN) is interrupted. When the UE is subsequently triggered to transmit data (e.g., originating a phone call, launching a browser) or receiving a paging message from the base station, the UE may then transition to a connected state. To make this transition, the UE may request the base station to establish a radio connection (e.g., by sending an RRC Setup Request message to the base station) or to resume a suspended radio connection (e.g., by sending an RRC Resume Request message to the base station), so that the base station may configure the UE to operate in the connected state.

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

[0007] Recently, 3GPP has discussed providing multicast paging for Multicast and / or Broadcast Services (MBS), i.e., by sending a multicast paging message or instruction indicating that UEs that have previously indicated interest in a particular MBS service and are not operating in an active state should be paged for the MBS service. For example, a Core Network (CN) can receive MBS data to be sent to multiple interested UEs, and based on the received MBS data, the CN can send a multicast paging message to a Central Unit (CU) of a distributed base station (BS) identifying a set of UEs that are interested in the MBS service. The CU can send one or more corresponding multicast paging messages to a Distributed Unit (DU) of the distributed base station, and each CU-to-DU multicast paging message indicates one or more interested UEs associated with the receiving DU.

[0008] However, multicast paging for MBS has some challenges. For example, the DU does not store or otherwise have any information of the radio capabilities of the associated UEs to prepare and send paging messages. Similarly, in some situations, such as when an interested UE is in RRC_IDLE state, neither the CU nor the DU stores or otherwise has any information of the radio capabilities of UEs interested in the MBS service. Such situations may result in extra upstream (e.g., toward the CN) messaging for the DU to obtain the required radio configuration capabilities, as well as delays in establishing an MBS session over which the interested UEs can receive the content data of the MBS service. Summary of the Invention [Problem to be solved by the invention]

[0009] A node of a radio access network (RAN) may use one or more of the techniques described herein to manage paging for multicast and / or broadcast services (MBS) of interested UEs that do not have an active radio connection with the RAN. These techniques may be utilized pursuant to receiving an MBS paging order (e.g., without needing to query the RAN and upstream components or nodes of the wireless communication system) and without delaying the establishment of an MBS session and the delivery of MBS content data to the interested UEs. An exemplary technique includes providing an indication of the radio capabilities of each of the interested UEs together with the identification information of the interested UEs in the MBS service paging order, so that the DU can obtain the necessary UE radio capability information in accordance with the paging order. Such UE capability information may be provided by any upstream component or node (e.g., CN, CU, etc.) of the wireless communication system to a corresponding downstream component or node (e.g., integrated BS or CU, DU, etc.). Another exemplary technique includes storing, in the DU, an indication of the radio capability information of each of one or more interested UEs. Yet another exemplary technique enables a base station to provide an indication of radio capability information of an interested UE to other base stations, e.g., when the interested UE moves into the coverage area of ​​the other base station. Moreover, advantageously, the techniques for managing paging for MBS services described herein are compatible with known techniques for managing paging for unicast services.

[0010] An exemplary embodiment of these techniques is a method in a core network (CN) of a wireless communications system for managing paging of a plurality of user equipments (UEs) interested in a Multicast-Broadcast Service (MBS) service when respective radio connections between the UEs and respective base stations of the wireless communications system are not active, e.g., when the respective radio connections are idle or inactive. The method includes generating, by processing hardware of the CN, a set of paging instructions for paging the plurality of UEs interested in the MBS service, the set of paging instructions including an indication of a respective set of radio capabilities of each UE of the plurality of UEs, and transmitting, by the processing hardware, the set of paging instructions to one or more base stations of the wireless communications system, thereby causing each UE to be paged according to its respective set of radio capabilities for activating data reception of the MBS service.

[0011] Another example embodiment of these techniques is a method in a distributed unit (DU) of a distributed base station of a radio access network (RAN) for managing paging of a plurality of user equipments (UEs) interested in a multicast and broadcast service (MBS) service when respective radio connections between the UEs and respective base stations of a wireless communication system are not active, e.g., when the respective radio connections are idle or inactive. The method includes receiving, from the CU by processing hardware of the DU, a single multicast paging message including a session identifier of an MBS session of the MBS service and respective identification information of each UE included in the plurality of UEs, and paging, by the processing hardware, each UE of the plurality of UEs for the MBS service, wherein the paging is in accordance with a respective set of radio capabilities of each identified UE, and wherein the paging indicates the MBS session identifier.

[0012] Yet another exemplary embodiment of these techniques is a method in a central unit (CU) of a distributed base station of a radio access network (RAN) for managing paging of one or more user equipments (UEs) interested in a multicast and / or broadcast service (MBS) service when respective radio connections between the UEs and respective base stations of a wireless communication system are not active, e.g., when the respective radio connections are idle or inactive. The method includes receiving, by processing hardware of the CU from a core network (CN) or another base station, a transmission corresponding to one or more UEs interested in the MBS service, and transmitting, by the processing hardware to the DU, a set of paging instructions to the DU, thereby causing the DU to page each UE of the one or more UEs according to a respective set of radio capabilities for activating data reception of the MBS service at each of the paged UEs.

[0013] Another example embodiment of these techniques is a method in a base station (BS) of a wireless communications system for paging a plurality of user equipments (UEs) interested in a multicast and / or broadcast service (MBS) service when respective radio connections between the UEs and respective base stations of the wireless communications system are not active, e.g., when the respective radio connections are idle or inactive. The method includes receiving, by processing hardware of the BS, a single multicast paging message that includes a session identifier of an MBS session of the MBS service, identification information of each of the plurality of UEs, and an indication of a respective set of radio capabilities of the plurality of UEs. The method further includes generating, by the processing hardware, a respective paging message corresponding to each UE of the plurality of UEs in response to receiving the single multicast paging message, where the respective paging message includes the MBS session identifier; generating, by the processing hardware, for each UE, a respective time domain resource allocation, a respective frequency domain resource allocation, and an indication of a respective modulation scheme in accordance with a respective set of radio capabilities of each UE; transmitting, by the processing hardware, via one or more shared downlink control channels in accordance with the respective set of radio capabilities of each UE, the indication of the respective time domain resource allocation, the respective frequency domain resource allocation, and the respective modulation scheme corresponding to each UE; and transmitting, by the processing hardware, via one or more shared downlink data channels in accordance with the respective set of radio capabilities of each UE.

[0014] Yet another exemplary embodiment of these techniques is a method in a Radio Access Network (RAN) node of a wireless communications system for paging a UE when a radio connection between a user equipment interested in a multicast and / or broadcast service (MBS) service and the RAN node is not active, e.g., when the radio connection is idle or inactive. The method includes determining, by processing hardware of the RAN node, whether an indication of a set of radio capabilities of the UE is stored in the RAN node. When an indication of a set of radio capabilities of the UE is stored in the RAN node, the method includes paging, by the processing hardware, the UE according to the stored indication. When an indication of the set of radio capabilities of the UE is not stored in the RAN node, the method includes one of the steps of (i) obtaining, by the processing hardware, an indication of a default set of radio capabilities, where the indication of the default set of radio capabilities is stored in the RAN node, or obtaining, by the processing hardware, an indication of the set of radio capabilities of the UE from another node of the wireless communications system, where the other node is a Core Network (CN) or another RAN node; and (ii) paging, by the processing hardware, the UE according to the obtained indication.

[0015] Yet another exemplary embodiment of these techniques is a method in a base station (BS) of a wireless communication system for paging a plurality of user equipments (UEs) interested in a multicast broadcast service (MBS) service when respective radio connections between the UEs and respective base stations of the wireless communication system are not active, e.g., when the respective radio connections are idle or inactive. The method includes determining, by processing hardware of the BS, to page the plurality of UEs via another BS, generating, by the processing hardware, a single multicast paging message including a session identifier of an MBS session of the MBS service, identification information of each of the plurality of UEs, and one or more indications of a respective set of radio capabilities of the plurality of UEs, and transmitting, by the processing hardware, the single multicast paging message to the other BS.

[0016] Another exemplary embodiment of these techniques is a wireless communication system for managing paging of one or more user equipments (UEs) interested in a multicast and broadcast service (MBS) service when respective radio connections between the UEs and respective base stations of the wireless communication system are not active, e.g., when the respective radio connections are idle or inactive. The system includes a first component, which may be a core network (CN), a base station (BS), or a central unit (CU) of the BS. The first component is configured to generate a set of paging instructions to page the one or more UEs interested in the MBS service, the set of paging instructions including an indication of a respective set of radio capabilities of each UE of the one or more UEs, and transmit the set of paging instructions to one or more receiving components of the wireless communication system, thereby causing each UE to be paged according to the respective set of radio capabilities for activating data reception of the MBS service via a shared session of the MBS service. [Brief description of the drawings]

[0017] [Figure 1A] FIG. 1 is a block diagram of an example wireless communication system in which a core network (CN), a base station (BS), and a user equipment (UE) can implement the techniques of the present disclosure for managing multicast paging for a multicast and / or broadcast service (MBS). [Figure 1B] FIG. 1B is a block diagram of an exemplary base station (BS) including a central unit (CU) and a distributed unit (DU) capable of operating in the system of FIG. 1A. [Figure 2A] 1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A communicates with a base station. [Figure 2B] FIG. 1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A may communicate with the DU and CU of the base station. [Diagram 3] FIG. 1 is a block diagram illustrating an example tunnel architecture for MBS and PDU sessions. [Figure 4] A block diagram illustrating example MRBs and DRBs that a distributed base station can configure to communicate multicast, broadcast, and / or unicast traffic with UEs. [Figure 5A] 1 is a messaging diagram of an example scenario in which a CN and a distributed base station configure resources for transmitting MBS data of an MBS session to multiple UEs. [Figure 5B] 1 is a messaging diagram of an example scenario in which a CN and a distributed base station configure resources for transmitting MBS data of an MBS session to multiple UEs. [Figure 6A]1 is an example message sequence in which the CN sends a single multicast paging message for an MBS service to a CU of a BS, the CU sends a corresponding single multicast paging message to a DU, and the DU pages one or more UEs that are interested in the MBS service while the UEs are operating in an idle or inactive state, thereby activating data reception for the MBS service in the UEs without changing their state. [Figure 6B] 1 is an exemplary message sequence in which the CN sends content data of an MBS service to a CU of a BS, and the CU sends the MBS content data to a DU, which causes the DU to page one or more UEs that are interested in the MBS service while the UEs are operating in an inactive state, thereby activating data reception for the MBS service in the UEs without changing their state. [Figure 6C] An exemplary message sequence in which the CN sends content data of an MBS service to a CU of a BS, which causes the CU to send a corresponding single multicast paging message for the MBS service to a DU, and the DU pages one or more UEs that are interested in the MBS service when the UEs are operating in an inactive state, thereby activating data reception for the MBS service in the UEs without changing their state. [Figure 6D] 1 is an example message sequence in which the CN and BS activate data reception for an MBS service in an interested UE operating in an idle state, the UE connects to the BS and starts operating in a connected state, and the CN delivers MBS content data to the UE operating in a connected state. [Figure 6E] 1 is an example message sequence in which the CN and BS activate data reception for an MBS service in an interested UE operating in an inactive state, the UE resumes connection to the BS and begins operating in a connected state, and the CN delivers MBS content data to the UE operating in a connected state. [Figure 6F]1 is an example message sequence in which multiple UEs operating in an inactive state and disposed at a first location associated with a first BS are interested in an MBS service, the first UE remains at the first location and the second UE moves to a second location associated with a second BS, the first BS sends a single multicast paging message for the MBS service to the second BS, the second BS pages the second UE to activate data reception for the MBS service in the UE, thereby receiving content data for the MBS service from the CN via the second BS while in a connected state, and receiving the MBS content data via the first BS while the first UE is in an inactive state. [Figure 7A] 1 is an example message sequence in which the CN sends a single multicast paging message for the MBS service to the CU of the BS, the CU sends respective unicast paging messages to each UE indicated in the single multicast paging message to the DU, and the DU pages each of the UEs individually while the UEs are operating in an idle or inactive state, thereby activating data reception for the MBS service in the UEs. [Figure 7B] 1 is an example message sequence in which the CN sends a single multicast paging message for the MBS service to the CU of the BS, the CU sends a corresponding single multicast paging message to the DU, and the DU pages each of the UEs individually while the UEs are operating in an idle or inactive state, thereby activating data reception for the MBS service in the UEs. [Figure 7C]1 is an example message sequence in which multiple UEs operating in an idle or inactive state move from a first location associated with a first base station to a second location associated with a second base station, the CN sends a single multicast paging message for the MBS service to the first base station, the first base station sends a respective unicast message for each UE indicated in the single multicast paging message to the second base station, and the second base station pages each of the UEs individually, thereby activating data reception for the MBS service at the UEs. [Figure 7D] 1 is an example message sequence in which a plurality of UEs operating in an inactive state move from a first location associated with a first base station to a second location associated with a second base station, the CN sends a single multicast paging message to the first base station indicating a plurality of UEs that are interested in the MBS service, the first base station sends a corresponding single multicast paging message to the second base station, and the second base station individually pages each of the indicated UEs, thereby activating data reception for the MBS service at the UEs. [Figure 8A] 1 is a flow diagram of an example method that may be implemented by a CU to generate a single multicast paging message indicating multiple UEs interested in an MBS service and transmit the multicast paging message to one or more DUs. [Figure 8B] 1 is a flow diagram of an example method that may be implemented by a CU for generating a respective unicast paging message for each UE included in a set of a plurality of UEs that are interested in an MBS service and transmitting the unicast paging message to one or more DUs. [Figure 9]1 is a flow diagram of an example method that may be implemented by a CU for determining whether paging of a UE is for an MBS service or a unicast service, and generating and sending a single multicast paging message to a first at least one DU when the service is an MBS service, and generating and sending a unicast paging message to a second at least one DU when the service is a unicast service. [Figure 10A] 1 is a flow diagram of an example method that may be implemented by a DU for receiving a single multicast paging message for an MBS service from a CU and generating and transmitting a corresponding paging message for each UE indicated in the received multicast paging message. [Figure 10B] 1 is a flow diagram of an example method that may be implemented by a BS for receiving a single multicast paging message for an MBS service from a CN and generating and transmitting a corresponding unicast paging message for each UE indicated in the received multicast paging message. [Figure 10C] 1 is a flow diagram of an example method that may be implemented by a second Radio Access Network (RAN) node for receiving a single multicast paging message for an MBS service from a first RAN node and generating and transmitting a corresponding unicast paging message for each UE indicated in the received multicast paging message. [Figure 11] FIG. 1 is a flow diagram of an example method that may be implemented by a RAN node for paging a UE according to stored radio capabilities corresponding to the UE, or, when the RAN node does not store radio capabilities corresponding to the UE, for paging the UE according to predetermined or default radio capabilities. [Figure 12A]1 is a flow diagram of an example method that may be implemented by a CN for generating a single multicast paging message indicating multiple UEs that are interested in an MBS service and transmitting the single multicast paging message to one or more RAN nodes or base stations. [Figure 12B] 1 is a flow diagram of an example method that may be implemented by a CN for generating a respective unicast paging message for each UE included in a set of UEs interested in an MBS service and transmitting the unicast paging message to one or more RAN nodes or base stations. [Figure 13A] 10 is a flow diagram of an example method that may be implemented by another RAN node for generating a single multicast paging message indicating multiple UEs interested in an MBS service and transmitting the single multicast paging message to one or more RAN nodes. [Figure 13B] 10 is a flow diagram of an example method that may be implemented by another RAN node for generating a respective unicast paging message for each UE included in a set of UEs interested in an MBS service and transmitting the unicast paging messages to one or more RAN nodes. [Figure 14] 1 is a flow diagram of an example method that may be implemented by a CN for determining whether paging for a UE is for an MBS service or a unicast service, generating and sending a single multicast paging message to a first at least one RAN node when the service is an MBS service, and generating and sending a unicast paging message to a second at least one RAN node when the service is a unicast service. [Figure 15]1 is a flow diagram of an example method that may be implemented by another RAN node for determining whether a paging for a UE is for an MBS service or a unicast service, generating and sending a single multicast paging message to a first at least one RAN node when the service is an MBS service, and generating and sending a unicast paging message to a second at least one RAN node when the service is a unicast service. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] Generally, one or more nodes of a wireless communication system (e.g., CN, base station, RAN node, CU, and / or DU) implement the techniques of this disclosure to manage paging of UEs for multicast and / or broadcast services (MBS), along with managing paging of UEs for unicast services in some scenarios. This document uses the terms "multicast-broadcast service," "multicast and broadcast service," "multicast service and / or broadcast service," and "multicast and / or broadcast service" interchangeably to generally refer to point-to-multipoint communication and / or data services or schemes, and the acronym "MBS" refers to any or all of these terms, individually and / or collectively. Additionally, this document uses the term "unicast service" to generally refer to point-to-point communication and / or data services or schemes.

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

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

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

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

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

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

[0025] The UE 102A includes processing hardware 150, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory that stores machine-readable instructions executable on the general-purpose processors, and / or dedicated processing units. The processing hardware 150 in the example implementation of FIG. 1A includes an MBS controller 152 configured to manage or control reception of MBS information. For example, as discussed below, the UE MBS controller 152 may be configured to support RRC configurations, procedures and messaging related to MBS procedures, and / or other operations related to those configurations and / or procedures. The processing hardware 150 may also include a non-MBS controller 154 configured to manage or control one or more RRC configurations and / or RRC procedures according to any of the implementations discussed below when the UE 102A communicates with the MN and / or SN during non-MBS operation. Additionally, in an example implementation, the processing hardware 150 includes one or more paging controllers 156 configured to manage MBS and non-MBS (e.g., unicast services) paging operations with one or more base stations (e.g., BSs 104, 106) when the UE 102A is operating in an RRC_INACTIVE or RRC_IDLE state. Although not shown in FIG. 1A, the UE 102B may include processing hardware similar to the processing hardware 150 of the UE 102A.

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

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

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

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

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

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

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

[0033] Each of the DUs 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory that stores machine-readable instructions executable on the one or more general-purpose processors, and / or a dedicated processing unit. For example, the processing hardware may include a MAC controller configured to manage or control one or more medium access control (MAC) operations or procedures (e.g., random access procedures) and a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures when the base station (e.g., base station 104) operates as a 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0047] In various scenarios, the CN 110 can assign different types of MBS traffic to different QoS flows. For example, a flow with a relatively high QoS value may correspond to audio packets, and a flow with a relatively low QoS value may correspond to video packets. As another example, a flow with a relatively high QoS value may correspond to an I-frame or a complete image used in video compression, and a flow with a relatively low QoS value may correspond to a P-frame or a predicted picture that contains only changes to the I-frame.

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

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

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

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

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

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

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

[0055] 5A, in a scenario 500A, the UE 102A first performs an MBS session join procedure with the CN 110 via the base station 104 to join an MBS session (502). In some scenarios, the UE 102A subsequently performs one or more additional MBS join procedures, such that the event 502 is the first of multiple MBS join procedures. When the base station 104 configures a common DL tunnel for MBS traffic rather than a UE-specific tunnel, procedures 502 and 586 can occur in either order. In other words, the base station 104 can configure a common DL tunnel even if there are no UEs yet to join the MBS session.

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

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

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

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

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

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

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

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

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

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

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

[0067] In some implementations, the second CN-to-BS message and the second BS-to-CN message may be a PDU Session Resource Modify Request message and a PDU Session Resource Modify Response message, respectively. In some implementations, the second CN-to-BS message and the second BS-to-CN message may be UE-related messages, i.e., the messages are associated with a particular UE (e.g., UE 102A or 102B).

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

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

[0070] In some implementations, the UE Context Request message and the UE Context Response message are UE Context Setup Request message and UE Context Setup Response message, respectively. In other implementations, the UE Context Request message and the UE Context Response message are UE Context Modification Request message and UE Context Modification Response message, respectively.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0091]

[0033] Referring now to Figure 5B, a scenario 500B is illustrated that is generally similar to scenario 500A. Events in this scenario similar to those discussed above are labeled with the same reference numbers, and the examples and implementations of Figure 5A may apply to Figure 5B. Differences between the scenarios of Figure 5A and Figure 5B are discussed below.

[0092] In some implementations, the CU 172 can perform an MBS session resource setup procedure and a UE-specific MBS session configuration procedure 587 (e.g., a combination of events 586 and 589) with the CN 110 in response to receiving (512) a second CN-to-BS message that specifies a UE ID and a session ID for the UE 102A. In such implementations, the CU 172 transmits (510) a first BS-to-CN message to the CN 110 in response to receiving (512) the second CN-to-BS message. The CN 110 then transmits (504) a first CN-to-BS message to the CU 172 in response to receiving (510) the first BS-to-CN message. In such a case, the CN 110 may or may not include an MBS session ID (i.e., the first MBS session ID) in the first CN-to-BS message. The CN 110 may transmit a second BS-to-CN message (519) in response to or after receiving the second CN-to-BS message (512) or the first CN-to-BS message (504). After or in response to receiving the second CN-to-BS message (512), transmitting the first BS-to-CN message (510), or receiving the first CN-to-BS message (504), the CU 172 may transmit a CU-to-DU message to the DU 174 (506).

[0093] Instead of sending a CU-to-DU message to request that the CU 172 configure a common CU-to-DU DL tunnel (506), the DU 174 may, in some implementations, send a DU-to-CU message in response to receiving the UE Context Request message (514) in addition to sending a UE Context Response message (516). The CU 172 may then send a CU-to-DU response message to the DU 174 in response to receiving the DU-to-CU message (506) (508). In such a case, the DU-to-CU message and the CU-to-DU response message may be non-UE-associated messages, i.e., the messages are not associated with a particular UE.

[0094] Thus, events 512, 510, 504, 506, 508, 514, 516, 518, 519, 520, 522, and 523 are collectively referred to in FIG. 5B as an MBS resource setup and UE-specific MBS session configuration procedure 587. If the CN 110 admits an additional MBS session for the UE 102A in an additional MBS session join procedure, the CN 110 may perform an MBS resource setup and UE-specific MBS session configuration procedure with the base station 104 and the UE 102A, similar to procedure 587. In such a case, the CN 110 may include the additional MBS session ID, and optionally a QoS configuration for the additional MBS session ID, in a CN-to-BS message in the MBS resource setup and UE-specific MBS session configuration procedure, similar to the first or second CN-to-BS message. In such a case, the CU 172 includes additional transport layer configurations for the additional MBS sessions to configure additional common DL tunnels in the BS-to-CN message in the MBS resource setup and UE-specific MBS session configuration procedure, similar to the first or second BS-to-CN message. Each of the transport layer configurations may configure a specific common DL tunnel of the common DL tunnels and be associated with a specific MBS session of the additional MBS session. The transport layer configurations may be different to distinguish different common DL tunnels. In particular, any pair of transport layer configurations may have different IP addresses, different DL TEIDs, or different IP addresses as well as different DL TEIDs.

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

[0096] Generally, the UE and / or the RAN manage information regarding multicast and / or broadcast services (MBS). The UE may, for example, transmit an MBS interest indication to the RAN indicating a configuration (e.g., an "MBS interest configuration") according to which the UE prefers to receive MBS transmissions. The MBS interest configuration may include a set of frequencies on which the UE is receiving or is interested in receiving MBS, and a list of MBS services that the UE is receiving or is interested in receiving on the indicated frequencies. In response to determining that the radio connection between the UE and the RAN should be modified, the UE may decide to either maintain or release the MBS interest configuration. If the UE maintains the MBS interest configuration, the UE may later transmit an MBS interest indication update to the RAN. If the UE releases the MBS interest configuration, the UE may transmit another MBS interest indication to the RAN after modifying the radio connection.

[0097] Similarly, a node of the RAN may also receive an MBS interest indication from a UE and, in response to determining that the radio connection between the UE and the RAN should be modified, either maintain or release the configuration included in the MBS interest indication. Triggering events that may cause the UE and / or the RAN to decide to release or maintain the MBS interest indication include the UE detecting a failure in the radio connection or the UE suspending, resuming, or re-establishing the radio connection with the RAN.

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

[0099] Some example scenarios in which the devices shown in FIGS. 1A-5B may participate will now be discussed with respect to FIGS. 6A-6F and 7A-7D.

[0100] 6A illustrates an example scenario 600A that may occur in the wireless communication system 100, in which the CN 110 requests the BS 104 to page UEs that have previously indicated interest in a particular MBS service. In general, the CN 110 transmits a single first multicast paging message 614 to the CU 172 of the BS 104 instructing the BS 104 to page a group of UEs that have previously indicated interest in the MBS service and are operating in an idle or inactive state. The CU 172 then transmits a corresponding single second multicast paging message 616 indicating the group of UEs to the DU 174 of the BS 104, which then pages (620) one or more UEs (including the UE 102) that have interest in the MBS service while the UEs are operating in an idle or inactive state 602, e.g., as described in more detail below, thereby activating MBS data reception 622 for the MBS service at the UEs without the UEs changing state.

[0101] As initially shown in FIG. 6A , the CN 110 and the BS 104 may perform an MBS session resource setup procedure 690 to prepare, configure, reserve, and / or otherwise set up resources at the BS 104 to support delivery of content data of the MBS service via a common DL tunnel and an MBS session of the MBS service to interested UEs associated with the BS 104. In general, the MBS session resource setup procedure 690 may be similar to the MBS session resource setup procedure 586 of FIG. 5A . For example, as part of the MBS session resource setup procedure 690, the CN 110 may send 606 a CN-to-BS message (e.g., an MBS Session Resource Setup Request message) to the base station 104, where the message 606 includes an MBS session ID of the MBS service and, in some cases, a corresponding QoS profile, thereby requesting the base station 104 to reserve and configure resources for the MBS service. In response to receiving the CN-to-BS message (606), the CU 172 sends a CU-to-DU message (e.g., an MBS Context Setup Request) to request the DU 174 to set up (e.g., prepare, configure, reserve, and / or otherwise set up resources) an MBS context and / or a common DL tunnel for the MBS session indicated in the MBS resource setup request (608). The DU 174 sends a corresponding response (e.g., an MBS Context Setup Response message) indicating the resources the DU 174 has prepared for the MBS session of the MBS service, such as a DU transport layer configuration (610). The CU 172 then sends a BS-to-CN message (e.g., an MBS Session Resource Setup Response message) including a DL transport layer configuration for the CN 100 to use in configuring a common DL tunnel through which the CN 110 can transmit MBS data to the base station 104 (612).The DL transport layer configuration includes, for example, a transport layer address (eg, an IP address and / or a TEID) for identifying a common DL tunnel.

[0102] Events 606, 608, 610, and 612 are collectively referred to in FIG. 6A as an MBS session resource setup procedure 690.

[0103] Next, as shown in scenario 600A of FIG. 6A, the CN 110, the BS 104, and the UE 102 may perform an MBS session activation procedure 692 through which the BS 104 (and specifically, the DU 174 of the BS 104) pages the UE 102 (and in some cases, other interested UEs operating in an idle or inactive state) for the MBS service, and the UE 102 activates (622) for receiving the MBS content data. For example, the CN 110 may send (614) a CN-to-BS message, which is a single (e.g., only one) message that includes a multicast or group paging instruction for a set of one or more UEs (but typically multiple UEs or groups of UEs) that are interested in the MBS service and are operating in an idle or inactive state, and that should be paged for the MBS service. Such a message sent at event 614 is generally referred to herein as a "group paging message" or a "multicast paging message." In some implementations, the group or multicast paging message for event 614 is a multicast group paging message defined for 3GPP TS 38.413 NGAP. The single multicast paging message includes the MBS Session ID, an indication of the identities of UEs that have previously indicated interest in the MBS service, and optionally, if desired, an indication of the UE radio capabilities of each of the interested UEs, the service area of ​​the MBS service, and possibly other information. For example, the CN-to-BS message sent at event 614 can identify the interested UEs via their respective specific and / or derived paging identities or by some other suitable format of identification, e.g., similar to the UE identification formats previously discussed with respect to event 512 of FIG. 5A ((CN UE Interface ID / RAN UE Interface ID) pair, S-TMSI, etc.).Thus, a single multicast paging message can indicate, by using only a single message, multiple UEs to be paged for an MBS service, as well as an MBS session ID that each of the multiple UEs can use to receive content data of the MBS service, e.g., via a common tunnel set up in procedure 690.

[0104] In some circumstances, the CN 110 stores an indication of the respective radio capabilities of the UEs, and the CN 110 can include an indication of the respective UE radio capabilities of the interested UEs, such as a respective UERadioPagingInformation IE, other indications of the respective radio capabilities in paging information elements (IEs), UE capabilities IEs, etc., in the multicast paging message transmitted at event 614. The indicated respective UE radio capabilities may include, for example, respective supported time domain resources, supported frequency domain resources (e.g., supported bands, such as supported NR bands), supported modulation schemes, support for wake-up signals, support for early paging indications, supported downlink schedule offsets (e.g., discontinuous reception (DRX) cycle configurations) for one or more types and one or more frequency ranges, and other types of UE-specific radio capability information. For example, the downlink scheduling offset information may include dl-SchedulingOffset-PDSCH-TypeA-FDD-FR1, dl-SchedulingOffset-PDSCH-TypeA-TDD-FR1, dl-SchedulingOffset-PDSCH-TypeA-TDD-FR2, dl-SchedulingOffset-PDSCH-TypeB-FDD-FR1, dl-SchedulingOffset-PDSCH-TypeB-TDD-FR1, and / or dl-SchedulingOffset-PDSCH-TypeB-TDD-FR2.

[0105] However, in some situations, such as when at least some of the UE radio capability information is pre-stored in the CU 172 and / or the DU 174 (and as discussed elsewhere in this document with respect to other example scenarios), the UE radio capability information may be excluded from the multicast paging message sent by the CN 110 at event 614.

[0106] In any event, upon receiving the single multicast paging message from the CN 110, the CU 172 reserves and / or otherwise sets up internal resources to support the MBS service and subsequently generates and transmits (616) one or more CU-to-DU messages, e.g., a second single multicast paging message, to one or more DUs 174. For example, the CU 172 may maintain a list or other indication of UEs that are operating in an inactive and / or idle state and associated with the base station 104, and the CU 172 may filter the list to determine a set of UEs that are associated with the base station 104, operating in an idle or inactive state, and that are interested in the MBS service (e.g., as indicated by the CN-to-BS message received at event 614). The CU 172 may generate and send a second single multicast paging message to one or more DUs 174 (616), the second single multicast paging message including the MBS session ID, an indication of the identity of the filtered set of UEs associated with the base station 104 and that have previously indicated interest in the MBS service, and optionally UE radio capability information and / or other information, e.g., in a manner similar to that described above for the single multicast paging message sent at event 614. In some embodiments, such as when the BS 104 includes multiple DUs 174 and the CU 172 maintains an indication of which UEs are currently associated with which particular DU 174, the CU 172 may additionally filter the set of interested UEs operating in an inactive or idle state on a per-DU basis and send an indication of only a respective subset of interested UEs associated with each DU in each CU-to-DU group multicast paging message (616).

[0107] Upon receiving a CU-to-DU message instructing the DU 174 to page the indicated UEs for the MBS service (616), the DU 174 may determine a respective paging scheme for each indicated UE, for example, based on the respective radio capabilities of each indicated UE (618). In some circumstances, such as when the received paging command 616 includes an indication of the respective radio capabilities of each indicated UE, the DU 174 may page each indicated UE according to the received respective UE radio capabilities indicated in the paging command at event 616 (620). Additionally or alternatively, in some circumstances, the DU 174 has pre-stored an indication of the respective radio capabilities of at least some of the indicated UEs, and the DU 174 may page each of at least some of the indicated UEs in the second multicast paging message according to the respective pre-stored indications (620). Importantly, however, as shown in scenario 600A, the DU 174 includes an MBS session ID in each UE paging message (620) so that the receiving UE can utilize the MBS session ID to join the MBS service and use the tunnel established for the MBS service. That is, each UE paging message includes information that the receiving UE uses to activate itself for receiving content data of the MBS service over the MBS session (622).

[0108] Events 614, 616, 628, and 620 are collectively referred to in FIG. 6A as an MBS session activation procedure 692.

[0109] With the UE 102 operating in an idle or inactive state 602, the UE 102 activates to receive MBS content data of an MBS session. For example, the UE 102 may perform an MBS session join procedure, such as the MBS session join procedure 502 or 530, to join an MBS session of an MBS service and communicatively connect to a common DL tunnel for the MBS service. Thus, via the common DL tunnel, the CN 110 may transmit content data of the MBS service to the CU 172 (624), the CU 172 may transmit or forward the received MBS content data to the DU 174 (626), and the DU 174 may transmit or forward the received MBS content data to the activated UE 102 (628).

[0110] Collectively, the transmission of the MBS content data from the CN 110 to the UE 102 through the established common DL tunnel (e.g., the collection of events 624, 626, 628) is referred to in FIG. 6A as an MBS content data delivery procedure 696. Further, in scenario 600A, the UE 102 does not change its operation state for receiving MBS content data. That is, the UE 102 can maintain its operation state in an idle or inactive state 602 while activating for MBS content data reception (622) and while receiving MBS data (628).

[0111] 6B illustrates an example scenario 600B that may occur in the wireless communication system 100, in which the CN 110 transmits (630) content data of an MBS service to the CU 172 of the BS 104, the CU 172 transmits or forwards (632) the received MBS content data to the DU 174 of the BS 104, and the DU 174 pages (620) one or more interested UEs 102 for the MBS service. At least some of the scenario 600B is generally similar to the scenario 600A, and thus events in the scenario 600B similar to those discussed above for the scenario 600A are labeled with the same reference numbers, and similar examples and implementations of FIG. 6A may apply to FIG. 6B. Differences between the scenarios of FIG. 6A and FIG. 6B are discussed below.

[0112] As shown in scenario 600B, a UE 102 that is interested in an MBS service is operating in an inactive state 603. At some point, the CN 110 and the BS 104 perform an MBS session resource setup procedure 690 to configure resources to support a common DL tunnel through which content data of the MBS service will be delivered to the interested UE, as well as to set up other required resources. For example, before the UE 102 transitions to operating in the inactive state 603 as shown in FIG. 6B, the CN 110 and the BS 104 may have performed the MBS session resource setup procedure 690 for the MBS service, the UE 102 may have participated in an MBS session for the MBS service while the UE 102 was operating in a connected state, and the UE 102 may have received MBS content data via the established common DL tunnel for the MBS service while operating in the connected state, e.g., in a manner similar to that shown in FIG. 5A and FIG. 5B.

[0113] In any case, in FIG. 6B, after the UE 102 transitions to operating in the inactive state 603, the CN 110 receives content data for the MBS service, and the CN 110 transmits the received MBS content data to the CU 172 of the BS 104 (630), for example, via a common DL tunnel. Upon receiving the MBS content data (630), the CU 172 transmits the received MBS content data to one or more DUs 174 (632), for example, via a common DL tunnel. Upon receiving the MBS content data (632), since the UE 102 is operating in the inactive state 603 and its wireless connection with the DU 174 is interrupted, the DU 174 determines a paging scheme for the UE 102, for example, based on the wireless capabilities of the UE 102 (618). The DU 174 pages the UE 102 according to the UE's respective wireless capabilities (620), and the paging message includes the MBS session ID. For example, the DU 174 may page the UE by sending a paging message (620) according to the radio capabilities of the UE 102, where the paging message 620 indicates the MBS session ID. Further, as shown in scenario 600B, when multiple UEs are operating in an inactive state 603 with respect to the DU 174, the DU 174 may determine (618) a respective paging scheme for each such UE, and the DU 174 may page (620) each such UE accordingly.

[0114] In scenario 600B, the DU 174 has pre-stored wireless capability information of the UE 102, e.g., based on a previously established wireless connection of the UE 102 with the DU 174 through which the UE 102 was receiving MBS content data, or based on a previous connection attempt between the UE 102 and the BS 104 via the DU 174. Thus, in scenario 600B, the CU 172 simply transmits or forwards (632) the received MBS content data to the DU 174, e.g., without transmitting any UE-specific wireless capability information, and the DU 174 generates a paging message 620 for the UE 102 based on the UE's wireless capability information stored in the DU 174.

[0115] Events 630, 632, 618, and 620 are collectively referred to in FIG. 6B as an MBS session activation procedure 693.

[0116] While the DU 174 is paging (620) the UE 102 operating in the inactive state 603 for the MBS service, the DU 174 may cache the MBS content data that the DU 174 received (632) from the CU 172. If the paging (620) of the UE 102 is successful and the UE 102 subsequently (re)activates (622) the reception of MBS content data for the MBS service, the DU 174 may transmit (634) the cached MBS content data to the UE 102. Furthermore, since the UE 102 (re)joins the MBS session upon (re)activation 622, the CN 110 may transmit (696) further MBS content data to the UE 102 via the common DL tunnel of the MBS service. Notably, in the scenario 600B, the UE 102 does not change the operation state for receiving MBS content data. That is, the UE 102 may maintain its operational state in inactive 603 while (re)activating (622) for reception of MBS content data and while receiving MBS content data (634, 696).

[0117] 6C illustrates an example scenario 600C that may occur in the wireless communication system 100 in which the CN 110 transmits (630) content data for an MBS service to the CU 172 of the BS 104, the CU 172 transmits (616) a single multicast paging message (indicating multiple interested UEs, including the UE 102) to the DU 174 of the BS 104, and based on the received (616) multicast paging message, the DU 174 pages (620) interested UEs (including the UE 102) in an inactive state 603 for the MBS service. Because at least some of the scenario 600C is generally similar to scenario 600A and / or scenario 600B, events in scenario 600C similar to those discussed above for scenario 600A and / or scenario 600B are labeled with the same reference numbers, and similar examples and implementations of FIGS. 6A and 6B may apply to FIG. 6C. The differences between scenarios 600C, 600B, and 600A are discussed below.

[0118] 6B, scenario 600C occurs when UE 102 is operating in an inactive state 603. In contrast to scenario 600B, however, in scenario 600C, CU 172 (rather than DU 174) has pre-stored radio capability information for UE 102, e.g., based on a previous connection (or connection attempt) of UE 102 with BS 104. Thus, in the embodiment of scenario 600C shown in FIG. 6C, when CU 172 receives content data of an MBS service (630), CU 172 sends (616) a multicast paging message to DU 174 indicating UE 102 and other interested UEs (e.g., multiple interested UEs) operating in an inactive state 603 with respect to BS 104, where the multicast paging message includes an indication of the MBS session ID and the respective stored radio capability information of the indicated UEs. In addition, while the DU 174 is performing paging 620, the CU 172 may cache the MBS content data received (630) from the CN 110. When an interested UE 102 (re)activates (622) reception of content data for the MBS service, the CU 172 may transmit (632) the cached MBS content data to the DU 174, which may transmit or forward (634) the received (632) MBS content data to the UE 102. In FIG. 6C, after (re)activation (622) of reception of content data for the MBS service, the UE 102 continues to operate in the inactive state 603, and the UE 102 may receive further MBS content data via the common DL tunnel (696).

[0119] Events 630, 616, 618, and 620 are collectively referred to in FIG. 6C as an MBS session activation procedure 694.

[0120] In another embodiment (not shown) of scenario 600C, instead of sending a multicast paging message to DU 174 (616), CU 172 can send a respective unicast paging message for each interested UE operating in inactive state 603 and associated with DU 174 to DU 174. That is, since each unicast paging message indicates only one UE to be paged for the MBS service, when multiple interested UEs are to be paged for the MBS service, CU 172 sends multiple unicast paging messages per UE to DU 174. Each unicast paging message includes an MBS session ID and an indication of the radio capability information of the receiving UE (e.g., based on the stored UE radio capability information in CU 172).

[0121] 6D illustrates an example scenario 600D that may occur in the wireless communications system 100, in which reception of MBS content data is activated (622) in a UE 102 operating in an idle state 601, the UE 102 and the BS 104 establish a wireless connection, causing the UE 102 to transition to a connected state 640, and the UE 102 receives (696) the MBS content data for the MBS service via a common DL tunnel supported by the established wireless connection. Because at least some of the scenario 600D are generally similar to scenarios 600A, 600B, and / or 600C, events in scenario 600D similar to those discussed above for scenarios 600A, 600B, and / or 600C are labeled with the same reference numbers, and similar examples and implementations of FIGS. 6A, 6B, and 6C may apply to FIG. 6D. The differences between scenario 600D and previously discussed scenarios 600A, 600B, and 600C are discussed below.

[0122] 6D, the scenario 600D begins while the UE 102 is operating in an idle state 601. The CN 110 and the DU 174 may perform an MBS resource setup procedure 690, for example, before or in conjunction with the CN 110, the BS 104, and the UE 102 performing an MBS session activation procedure 692 and activating (622) the UE to receive content data of the MBS service via the MBS session.

[0123] Next, the UE 102, the BS 104, and the CN 110 perform a state transition procedure 686, which causes the UE 102 to transition from operating in the idle state 610 with respect to the DU 174 to operating in the connected state 640. As shown in FIG. 6D, the state transition procedure 686 may include a random access procedure 636 performed by the DU 174 of the UE 102 and the BS 104, and a radio connection establishment procedure 638 performed by the CU 172 of the UE 102 and the BS 104, which causes the UE 102 to transition to operating in the connected state 640. The random access procedure 636 and the radio connection establishment procedure 638 may be any suitable random access procedure and radio connection establishment procedure utilized by the distributed base station to connect with the UE. For example, the radio connection establishment procedure 638 may be an RRC establishment procedure. When the DU 174 establishes a wireless connection with the UE 102, the CU 172 of the BS 104 sends a CU-to-CN message (e.g., an Initial UE message) to inform the CN 110 of the established wireless connection with the UE 102 (642), and the CN 110 sends a response (e.g., an Initial Context Setup Request message) to the CU 172 corresponding to the connection (644). Based on the received (644) Initial Context Setup Request message, the CU 172 and the UE 102 perform a security mode procedure 646 and a wireless connection re-establishment procedure 648, thereby securing the established wireless connection between the UE 102 and the DU 174. When the wireless connection is secured, the CU 172 sends a response (e.g., an Initial Context Setup Response) to inform the CN 110 (650). Similar to the random access procedure 636 and the radio connection establishment procedure 638, the security mode procedure 646 and the radio connection reconfiguration procedure 648 may be any suitable security mode procedure and radio connection reconfiguration procedure utilized by the distributed base station. For example, the radio connection reconfiguration procedure 648 may be an RRC reconfiguration procedure. In another example, the radio connection reconfiguration procedure 648 may be an MBS radio connection reconfiguration procedure 589.In some implementations, the CU 172 may initiate an MBS radio connection reconfiguration procedure 589 in response to the Initial Context Setup Request message.

[0124] Events 636, 638, 640, 642, 644, 646, 648, and 650 are collectively referred to in FIG. 6D as state transition procedure 686.

[0125] Further, in an embodiment, instead of providing MBS radio resources to the UE 102 in procedure 648 (i.e., MRB configuration and DU configuration as in events 518, 520), the BS 104 may perform an MBS radio connection reconfiguration procedure with the UE 102 and the CN 110 to provide MBS radio resources to the UE 102, similar to procedures 587 or 588 (688).

[0126] In any event, after the radio connection between the UE 102 and the BS 104 is established and secured via the state transition procedure 686, the CN 110 may transmit (696) the MBS content data to the UE 102 (now operating in the connected state 640) via, for example, the established common DL tunnel supported by the secured radio connection between the UE 102 and the DU 174. Thus, in scenario 600D, the UE 102 changes from operating in the idle state 601 to operating in the connected state 640 in order to receive (696) the MBS content data.

[0127] Turning now to Figure 6E, Figure 6E illustrates an example scenario 600E that may occur in the wireless communications system 100, in which reception of content data of an MBS service is activated (622) in a UE 102 operating in an inactive state 603, the UE 102 and the BS 104 resume their radio connection, the UE 102 transitions to operating in a connected state 640, and the UE 102 receives (696) the MBS content data while operating in the connected state 640 via the resumed radio connection. Because at least some of the scenario 600E are generally similar to scenarios 600A, 600B, 600C, and / or 600D, events in scenario 600E similar to those discussed above for scenarios 600A, 600B, 600C, and / or 600D are labeled with the same reference numbers, and similar examples and implementations of Figures 6A, 6B, 6C, and 6D may apply to Figure 6E. The differences between scenario 600E and previously discussed scenarios 600A, 600B, 600C, and 600D are discussed below.

[0128] As shown in FIG. 6E, the CN 110 and the DU 174 may perform an MBS resource setup procedure 690, for example, before or in conjunction with the CN 110, the BS 104, and the UE 102 performing an MBS session activation procedure 692, 693, or 694 and activating (622) the UE to receive content data for the MBS service via the MBS session.

[0129] Next, the UE 102, the BS 104, and the CN 110 perform a state transition procedure 687. As shown in FIG. 6E, the state transition procedure 687 may include a random access procedure 636 and a radio connection resume procedure 639, after which the UE 102 transitions to operating (again) in a connected state 640 with the BS 104, e.g., via the DU 174. The random access procedure 636 and the radio connection resume procedure 639 may be any suitable random access procedure and radio connection resume procedure utilized by the distributed base station. For example, the radio connection resume procedure 639 may be an RRC resume procedure. Following performing the radio connection resume procedure 639, the UE 102 transitions to operating in the connected state 640.

[0130] Events 636, 639, and 640 are collectively referred to in FIG. 6E as state transition procedure 687.

[0131] If the BS 104 has not configured MBS radio resources for the UE 102 at or before procedure 639 (i.e., MRB configuration and DU configuration as in events 518, 520), the BS 104 may perform an MBS radio connection reconfiguration procedure with the UE 102 and the CN 110 to provide the UE 102 with MBS radio resources (688), similar to procedures 587 or 588.

[0132] After performing the state transition procedure 687, the CU 172 may transmit any cached MBS content data (e.g., any content data of the MBS service received by the CU 172 while the UE 102 was operating in the inactive state 603, not shown) to the DU 174 (632), and the DU 174 may transmit or forward the received MBS content data to the UE 102 (634), e.g., via a common DL tunnel of the MBS service supported by the resumed wireless connection between the UE 102 and the DU 174. Thus, in scenario 600E, the UE 102 changes from operating in the inactive state 603 to operating in the connected state 640 to receive content data of the MBS service, which may include, e.g., MBS content data cached at the CU 172 (e.g., associated with the events 632, 634) and may include additional MBS content data transmitted (696) from the CN 110 to the UE 102 via the common DL tunnel corresponding to the MBS service.

[0133] 6F illustrates a wireless communication system 100 in which reception of MBS content data is activated (622) in a first UE 102A operating in an inactive state 603 with respect to the BS 104, thereby enabling the UE 102B to receive (696) the MBS content data via a common DL tunnel established for the MBS service via the BS 104. Additionally, a second UE 102B previously in the inactive state 603 with respect to the BS 104 has changed physical location such that the second UE 102B is no longer associated with the BS 104, but is instead associated with the BS 106, and thus the second UE 102B is in an inactive state 604 with respect to the BS 106. Thus, the system 100 pages the second UE 102B via the BS 106 to activate (323) the UE 102B to receive the content data of the MBS service. In FIG. 6F, BS 104 may be a distributed base station (such as those illustrated in FIGS. 6A-6E) or may be an integrated base station, and BS 106 may be a distributed base station or may be an integrated base station. Because at least some of scenario 600F is generally similar to scenarios 600A, 600B, 600C, 600D, and / or 600E, events in scenario 600F similar to those discussed above for scenarios 600A, 600B, 600C, 600D, and / or 600E are labeled with the same reference numbers, and similar examples and implementations of FIGS. 6A, 6B, 6C, 6D, and 6E may apply to FIG. 6F. Differences between scenario 600F and previously discussed scenarios 600A, 600B, 600C, 600D, and / or 600E are discussed below.

[0134] In the scenario 600F, the CN 110 and the DU 174 may perform an MBS resource setup procedure 690 (e.g., before or together with the CN 110, the BS 104, and the UE 102A perform the MBS session activation procedure 692, 693, or 694) to set up resources at the BS 104 to support a common DL tunnel for the MBS service. The UE 102A activates (622) to receive content data of the MBS service, and the UE 102A and the BS 104 perform a radio connection resume procedure 639 to thereby resume the radio connection between the UE 102A and the BS 104 to support the common DL tunnel for the MBS service. Through the common DL tunnel of the MBS service supported by the resumed radio connection, the BS 104 may transmit (617) any content data of the MBS service that the BS 104 received and cached while the radio connection between the UE 102A and the BS 104 was interrupted. Additionally, the CN 110 may transmit additional MBS content data to the UE 102A via the common DL tunnel (696). In scenario 600F, the UE 102A continues to operate in the inactive state 603 while receiving the content data of the MBS service (617, 696). However, in some embodiments (not shown), the UE 102A may transition to operating in a connected state 640 with respect to the BS 104 in order to receive the content data of the MBS service (617, 696).

[0135] Similar to UE 102A, UE 102B has also previously indicated interest in MBS services. However, as described above, UE 102B is operating in an inactive state 605 with respect to BS 106, but not with respect to BS 104. Thus, BS 104 transmits (652) a BS-to-BS message to BS 106 instructing BS 106 to page the UEs indicated in the BS-to-BS message for the MBS service. For example, BS 104 may transmit (652) a single multicast paging message to BS 106, the multicast paging message including an MBS session ID, an indication of each of the identities of one or more UEs (which in scenario 600F includes UE 102B) to be paged for the MBS service, and an indication of the UE radio capabilities of each of the indicated UEs. The format of the content of the multicast paging message may be similar to the format of the content of the multicast paging message discussed elsewhere in this document for other events, such as the multicast paging messages associated with events 614 and 616. For example, the multicast paging message may indicate multiple UEs, or the multicast paging message may indicate a single UE. In particular, in scenario 600F, BS 104 can simply fill in the BS-to-BS multicast paging message with an indication of the respective radio capabilities of the indicated UEs because the indicated UEs were previously in an inactive state 603 with respect to BS 104 just prior to moving into the coverage area of ​​BS 106, and thus BS 104 has stored an indication of the respective radio capabilities of the UEs. In some implementations, the BS-to-BS message at event 652 is a RAN multicast group paging message defined for 3GPP TS 38.423 XnAP.

[0136] Upon receiving (652) the single multicast paging message at BS 106 from BS 104, BS 106 determines (618) respective paging schemes for the UEs indicated therein, and BS 106 pages (620) each indicated UE (including paging (620) UE 102B) according to, for example, the UE's respective radio capabilities as indicated in the received (652) multicast paging message. Each paging message includes an MBS session ID so that the receiving UEs can activate (623) MBS content data reception for the MBS service via BS 106.

[0137] Events 652, 618, and 620 are collectively referred to in FIG. 6F as a BS-initiated MBS session activation procedure 695.

[0138] In another embodiment (not shown) of the BS-initiated MBS session activation procedure, instead of the BS 104 sending a multicast paging message indicating multiple UEs to be paged for the MBS service (652), the BS 104 may send a respective unicast paging message (e.g., multiple unicast paging messages) to the BS 106 for each UE to be paged for the MBS service, with each unicast paging message indicating only one respective UE, the radio capabilities of that only one respective UE, and the MBS session ID. Once the BS 106 receives the unicast paging message for each UE, the BS 106 may page the indicated UEs for the MBS service (620).

[0139] In any event, continuing with scenario 600F, upon activating UE 102B to receive MBS content data for the MBS service (623), UE 102B, BS 104, and BS 106 perform a state transition procedure 685 to resume UE 102B's wireless connection with system 100, but with BS 106 instead of with BS 104. For example, as shown in FIG. 6F, UE 102B and BS 106 perform a random access procedure 635, and UE 102B and BS 104 perform a wireless connection resumption procedure involving UE context lookup (637), whereby UE 102B transitions from operating in an inactive state with respect to BS 106 to operating in a connected state 643 with respect to BS 106 via the resumed wireless connection. Finally, CN 110 and BS 106 perform a path switching procedure 641 such that the path between CN 110 and UE 102B is via BS 106 instead of BS 104. The random access procedure 635 and the radio connection resumption procedure with UE context search 637 may be any suitable random access procedure and radio connection resumption procedure with UE context search utilized when a UE operating in an inactive state with respect to one base station moves into the coverage area of ​​another base station. For example, the radio connection resumption procedure with UE context search 637 may be an RRC resumption procedure with UE context search.

[0140] Events 635, 637, 643, and 639 are collectively referred to in FIG. 6F as state transition procedure (including UE context lookup and route switching) 685.

[0141] In some situations, a common DL tunnel for the MBS service already exists between the CN 110 and the BS 106, for example, because the CN 110 and the BS 106 have already performed the MBS resource setup procedure 691 at some time before the UE 102B enters the connected state 643 with respect to the BS 106. For example, another UE (not shown in FIG. 6F) that is interested in the MBS service may be located within the coverage area of ​​the BS 106, and the CN 110 and the BS 106 have performed the MBS resource setup procedure 691 to deliver content data of the MBS service to the other interested UE via the BS 106. In these situations, the CN 110 may transmit the MBS content data for the MBS service to the BS 106 via the existing common DL tunnel (625), and the BS 106 may transmit or forward the received MBS content data to the UE 102B (629).

[0142] In other situations, a common DL tunnel for the MBS service does not already exist between the CN 110 and the BS 106, e.g., because none of the other UEs currently served by the BS 106 are interested in the MBS service. In these situations, scenario 600F may include establishing a common DL tunnel between the CN 110 and the BS 106, e.g., by performing an MBS resource setup procedure 691 for the BS 106 after performing a path switching procedure 641 (e.g., instead of performing an MBS resource setup procedure 691 as shown in scenario 600F).

[0143] Turning now to FIG. 7A, FIG. 7A illustrates a scenario that may occur in the wireless communication system 100, in which the CN 110 sends a single multicast paging message indicating multiple UEs for paging for an MBS service to the CU 172 of the BS 104 (712), and the CU 172 instructs the DU 174 to page the UEs 102A and 102B via respective unicast paging messages. In general, the scenario 700A is similar to the scenario 600A of FIG. 6A. However, in the scenario 700A, the CU 172 instructs the DU 174 to page the interested UEs by sending multiple respective unicast paging messages 715, 765 for each UE, rather than sending a single multicast paging message indicating multiple interested UEs (616) as in the scenario 600A. Additionally, as discussed below, at least other portions of scenario 700A are generally similar to aspects of scenarios 600A, 600B, 600C, 600D, 600E, and / or 600F, such that similar examples and implementations of Figures 6A, 6B, 6C, 6D, 6E, and 6F may apply to Figure 7A. Differences between scenario 700A and previously discussed scenarios 600A, 600B, 600C, 600D, 600E, and 600F are discussed below.

[0144] As shown in scenario 700A, both UE 102A and UE 102B are located in the coverage area of ​​base station 104, both UE 102A and 102B are associated with DU 174 of distributed BS 104, and each of UE 102A, 102B is operating in an idle or inactive state with respect to DU 174, as indicated by reference numerals 702 and 702B, respectively. In FIG. 7A, CN 110 and BS 104 may perform an MBS resource setup procedure 790 some time before or in conjunction with CN 110 instructing BS 104 to page UEs of interest for MBS services (712), which may be generally similar to MBS resource setup procedure 690 of FIG. 6A. Additionally, generally similar to event 614 in Figure 6A, in Figure 7A, the CN 110 can send a CN-to-BS message (712) instructing the CU 172 of the BS 104 to page multiple UEs for the MBS service, the CN-to-BS message being a multicast paging message indicating the MBS session ID, at least the UEs 102A, 102B, and optionally the radio configurations of each of the indicated UEs. However, instead of the CU 172 sending a second corresponding multicast paging message (616) to one or more DUs 174 as shown in Figure 6A, in Figure 7A, the CU 172 sends a different per-UE unicast paging message (715, 765) to the DUs 174 for each interested UE indicated in the multicast paging message received by the CU 172 (712). That is, the CU 172 transmits (715) a first CU-to-DU unicast paging message indicating the MBS session ID, one indicating only the UE 102A, and optionally the respective radio capability information of the UE 102A. Similarly, the CU 172 transmits (765) a second CU-to-DU unicast message indicating the MBS session ID, one indicating only the UE 102B, and optionally the respective radio capability information of the UE 102B.However, CU172 may generate and fill the content of a different unicast paging message for each of events 715, 765 in a manner similar to that which it generates and fills the content of the single multicast paging message for event 616, e.g., based on whether each interested UE is in an inactive or idle state, based on whether CU172 or DU172 has stored any UE radio capability information, based on whether CN110 has sent UE radio capability information for any UE to CU172, and / or in other manners as previously described.

[0145] Based on the respective reception of the unicast paging messages transmitted by the CU 172 at the DU 174 (715, 758), the DU 174 determines (718) a respective paging scheme for the UE 102A and performs a respective MBS session paging procedure 720 for the UE 102A using the respective radio capabilities of the UE 102A, and the DU 174 determines (758) a respective paging scheme for the UE 102B and performs a respective MBS session paging procedure 760 for the UE 102B using the respective radio capabilities of the UE 102B. In general, the determination of the paging scheme (718, 758) in FIG. 7A may be similar to the determination of one paging scheme for multiple UEs (618) shown in FIG. 6A, and the paging procedures 720, 760 in FIG. 7A may be similar to the single paging procedure of the group of paging procedures 620 shown in FIG. 6A.

[0146] In response to the respective paging procedures 720, 760, the UE 102A and the UE 102B each activate (722, 721) reception of content data for the MBS service, thereby establishing or (possibly) joining a common DL tunnel for the MBS service. In some cases, when the UE 102A and / or the UE 102B are operating in the inactive states 702A, 702B, the UE 102A and / or the UE 102B may continue to operate in the inactive states 702A, 702B and receive (796) further MBS content data transmitted by the CN 110 via the established common DL tunnel for the MBS service while operating in the inactive states 702A, 702B. In other cases, such as when the UE 102A and / or the UE 102B are in the inactive state 702A, 702B, the UE 102A and / or the UE 102B may perform a respective state transition procedure 786, 787 to transition to operating in a connected state before receiving (796) further MBS content data from the CN 110. Additionally, when the UE 102A and / or the UE 102B are in the idle state 702A, 702B, the UE 102A and / or the UE 102B may perform a respective state transition procedure 786, 787 to transition to operating in a connected state before receiving (796) further MBS content data from the CN 110. In general, the state transition procedure 786 may be similar to the state transition procedure 686 of FIG. 6D, and the state transition procedure 787 may be similar to the state transition procedure 687 of FIG. 6E.

[0147] 7B illustrates an example scenario 700B that may occur in the wireless communication system 100, in which the CN 110 transmits (712) a first single multicast paging message to the CU 172 of the BS 104 indicating a plurality of UEs to be paged for an MBS service, and the CU 172 subsequently instructs (714) the DU 174 to page the plurality of UEs via a corresponding second single multicast paging message. In general, the scenario 700B is similar to the scenario 600A of FIG. 6A and / or the scenario 700A of FIG. 7A. Moreover, as discussed below, at least other portions of the scenario 700A are generally similar to aspects of the scenarios 600A, 600B, 600C, 600D, 600E, 600F, and / or 700A, and therefore similar examples and implementations of FIG. 6A, FIG. 6B, FIG. 6C, FIG. 6D, FIG. 6E, FIG. 6F, and FIG. 7A may apply to FIG. 7B. The differences between scenario 700B and previously discussed scenarios 600A, 600B, 600C, 600D, 600E, 600F, and 700A are discussed below.

[0148] As shown in scenario 700B, and similar to scenario 700A, both UE 102A and UE 102B are located in the coverage area of ​​base station 104, both UE 102A and 102B are associated with DU 174 of distributed BS 104, and each of UE 102A, 102B is operating in an idle or inactive state with respect to DU 174, which are indicated by reference numerals 702A and 702B, respectively. Also similar to scenario 700A, in scenario 700B, CN 110 and BS 104 may perform MBS resource setup procedure 790 at some time before or together with CN 110 instructs BS 104 to page interested UEs for MBS service (712), and the CN-to-BS message is a single multicast paging message indicating MBS session ID, an indication of multiple UEs interested in MBS service (including UE 102A, 102B), and optionally, respective radio configurations of the indicated UEs.

[0149] However, unlike scenario 700A of Figure 7A, but similar to scenario 600A of Figure 6A, in scenario 700B, when CU 172 receives (712) a single (first) multicast paging message from CN 110, CU 172 generates and sends (714) a corresponding single second multicast paging message to DU 174, where the second multicast paging message indicates an MBS session ID, an indication of multiple interested UEs (including UE 102A and UE 102) that are in an idle or inactive state with respect to DU 174, and optionally radio capability information for each of the indicated UEs. CU 172 can fill in the content of the single second multicast paging message, for example, in a manner similar to event 616 of Figure 6A.

[0150] Upon receiving the single second multicast paging message (714), the DU 174 may determine a respective paging scheme for each UE 102A, 102B indicated in the second multicast paging message (718, 758), and the DU 274 may initiate a respective MBS session paging procedure 720, 760 for each indicated UE 102A, 102B using the respective determined paging scheme, e.g., in a manner similar to that discussed for events 718, 720, 758, and 760 of Figure 7A. Additionally, events 721, 722, 786, 787, and 796 may also be implemented in a manner similar to that discussed for the same events of Figure 7A, e.g.

[0151] 7C illustrates an example scenario 700C that may occur in the wireless communication system 100, in which the CN 110 transmits (712) a first single multicast paging message to the first BS 106 indicating multiple UEs to page for the MBS service. Upon receiving (712) the first single multicast paging message, the first BS 106 transmits (713, 763) multiple unicast paging messages to the second BS 104 into whose coverage area at least some of the multiple UEs have moved, each of which indicates a different UE to page for the MBS service. As discussed below, at least a portion of scenario 700C is similar to aspects of scenarios 600A, 600B, 600C, 600D, 600E, 600F, 700A, and / or 700B, so similar examples and implementations of Figures 6A, 6B, 6C, 6D, 6E, 6F, 7A, and 7B may apply to Figure 7C. Differences between scenario 700C and previously discussed scenarios 600A, 600B, 600C, 600D, 600E, 600F, 700A, and 700B are discussed below.

[0152] As shown in scenario 700C, both UE 102A and UE 102B have moved from being located in the coverage area of ​​BS 106 to being located in the coverage area of ​​BS 104, with each of UE 102A, 102B operating in an idle or inactive state with respect to BS 104 (e.g., as shown in FIG. 7C by reference numerals 702A and 702B, respectively). In scenario 700C, CN 110 and BS 106 may perform MBS resource setup procedure 790 some time before or along with CN 110 instructing BS 106 to page interested UEs for the MBS service (712), e.g., by transmitting a single multicast paging message (712) that includes an indication of multiple UEs (including UE 102A and UE 102B) to be paged for the MBS service. Upon receiving the multicast paging message at BS106 (712), because BS104 needs to page (at least) UEs 102A, 102B (but not BS106), BS106 sends multiple BS-to-BS messages to BS104 (713, 763), each BS-to-BS message being a single unicast paging message indicating a different (only one) UE to be paged for MBS services by BS104. That is, in contrast to scenario 600F, in which BS104 sends a single multicast paging message to BS106 to indicate the multiple UEs to be paged (652), and in scenario 700C, BS106 sends multiple per-UE unicast paging messages to BS104 to indicate the multiple UEs to be paged (713, 763). However, similar to scenario 600F, BS104 can simply fill in each unicast paging message with an indication of the respective radio capabilities for the indicated UE because the indicated UE was previously in an inactive state with respect to BS104 immediately prior to moving into the coverage area of ​​BS106, after which BS104 has stored an indication of the respective radio capabilities of the indicated UE.

[0153] In scenario 700C, when BS 104 receives each unicast paging message (718, 768), BS 104 determines a respective paging scheme for the UEs indicated by the received unicast paging message (718, 758), and BS 104 performs a respective MBS session paging procedure 720, 760 for the indicated UEs, thereby activating each indicated UE (e.g., UE 102A and UE 102B) to receive content data of the MBS service (722, 721). Subsequently, as shown in FIG. 7C, UE 102A and CN 110 may perform a state transition procedure (including a context lookup for UE 102A and a route switch from BS 106 to BS 104) (784), thereby causing UE 102A to operate in a connected state with respect to BS 104 and enabling UE 102A to participate in an MBS session of the MBS service via BS 104. Similarly, the UE 102B and the CN 110 may perform (785) a state transition procedure (including context lookup for the UE 102B and path switching from the BS 106 to the BS 104) such that the UE 102B operates in a connected state with respect to the BS 104 and enables the UE 102B to participate in an MBS session of the MBS service via the BS 104. In general, the state transition procedure 784, 785 including UE context lookup and path switching may be similar to the state transition procedure 685 including UE context lookup and path switching.

[0154] In scenario 700C, when BS 104 already supports an existing common DL tunnel for the MBS service (e.g., due to BS 104 previously setting up MBS resources for another UE that is interested in the MBS service, not shown), CN 110 may transmit content data of the MBS service to UE 102A and UE 102B via the existing common DL tunnel (796). Otherwise, BS 104 and CN 110 may perform an MBS resource setup procedure to establish a common DL tunnel via BS 104 (790), thereby enabling CN 110 to transmit MBS content data to UE 102A and UE 102B via the established common DL tunnel for the MBS service (796). Additionally, although FIG. 7C shows the MBS resource setup procedure 790 after the state transition procedure 784, the MBS resource setup procedure 790 may occur any time after activation of the MBS service content data for at least one UE (e.g., event 721 for UE 102B, event 722 for UE 102A) before the CN 110 transmits (796) the MBS service content data to the at least one UE 102A, 102B.

[0155] Figure 7D illustrates an example scenario 700D that is generally similar to the example scenario 700C of Figure 7C. However, in Figure 7D, when the BS 106 receives from the CN 110 a single multicast paging message indicating multiple UEs (including UE 102A and UE 102B) for the MBS service (712), instead of the BS 106 sending a different unicast paging message to the BS 104 for each indicated UE (713, 763) as in Figure 7C, in Figure 7D the BS 106 sends a corresponding single multicast paging message to the BS 104 indicating the multiple UEs (including UE 102A and UE 102B) (711). The single multicast paging message sent by the BS 106 to the BS 104 (711) may include information similar to that discussed above for the other scenarios, such as an MBS session ID, an indication of the multiple UEs, and an indication of the radio capabilities of each of the indicated UEs.

[0156] Some example scenarios in which the devices shown in Figures 1A to 7D can be implemented will now be discussed with reference to Figures 8A to 15. Each of these methods may be implemented, for example, as a set of instructions stored on a non-transitory computer-readable medium and executable by one or more processors.

[0157] Referring first to FIG. 8A, a CU may perform a method 800A instructing a DU to page one or more UEs for MBS services. For example, the CU may be the CU 172 of the base station 104, and the DU may be the DU 174 of the base station 104. The method 800A begins at block 802, where the CU determines to page 1-M UEs for the MBS services, where M is an integer greater than 1 (e.g., see events 614, 630, and 712, the respective occurrences of which may cause the CU to determine (802) to page 1-M UEs for the MBS services). At block 804, in response to the determination 802, the CU generates a single CU-to-DU message indicating the set of UEs 1-M. In some implementations, the CU-to-DU message may be an interface message. For example, the interface message may be an F1 interface message, such as an F1 Application Protocol (F1AP) message. In other implementations, the CU-to-DU message may be a multicast paging interface message (eg, an F1AP multicast paging message).

[0158] The generated CU-to-DU message may include, for example, a session ID of an MBS session of the MBS service, an indication of the respective identity of each of the 1-M UEs, and an indication of a total of N respective sets of radio capabilities of the 1-M UEs (e.g., a capability IE, a field of capability IEs, or other suitable indications). In some implementations, the UE ID is a 5G-S-TMSI. Furthermore, the total number N of indicated sets of radio capabilities (N is an integer equal to or greater than 1) may be less than or equal to the total number M of indicated UEs. In some implementations, N is less than M, for example, when multiple UEs share a common radio capability. In other implementations, for example, not all M UEs provide a respective set of radio capabilities (e.g., radio capabilities for paging), because they may not support such functionality and only a respective set of N total radio capabilities for paging (of the M UEs) is available in the CU. In some implementations, the indication of the set of UE radio capabilities may be a capability IE, such as that described above. In other implementations, the indication of each set of UE radio capabilities may be a field or IE included in the UE Radio Capability IE, such as those described above. In other implementations, the indication of the set of UE radio capabilities may be a UE-NR-Capability IE or a UE-6G-Capability IE, each of which may include multiple UE capabilities for communication with a 5G RAN or a 6G RAN.

[0159] At block 806 of method 800A, the CU sends the generated CU-to-DU message to one or more DUs, thereby instructing the one or more DUs to page the indicated UEs 1-M.

[0160] 8B, the CU may perform method 800B to instruct the DU to page one or more UEs for the MBS service. For example, the CU may be the CU 172 of the base station 104, and the DU may be the DU 174 of the base station 104. The method 800B begins at block 802, where the CU determines to page 1-M UEs for the MBS service in a manner similar to event 802 of the method 800A. However, in block 814, in response to the determination 802, the CU generates a respective CU-to-DU message for each of UE1-M to indicate to the DU that the DU should page each of UE1-M. That is, in block 814, the CU generates a total of M CU-to-DU messages, each corresponding to a different UE1-M.

[0161] In some implementations, each CU-to-DU message generated by the CU (814) may include a session ID of an MBS session of the MBS service, an indication of one of 1 to M UEs, and an indication of a respective set of radio capabilities of the indicated UEs. Furthermore, the total number N of the indicated sets of radio capabilities (N is an integer equal to or greater than 1) may be less than or equal to the total number M of UEs. For example, multiple UEs share a common radio capability and N is less than M. When N is equal to M, a first CU-to-DU message corresponding to UE1 may include the MBS session ID, an indication of an identity of UE1, and capabilities IE1, a second CU-to-DU message corresponding to UE2 may include the MBS session ID, an indication of an identity of UE2, and capabilities IE2, and so on, and an Mth CU-to-DU message corresponding to UE M includes the MBS session ID, an identity of UE M, and capabilities IE M. If N is less than M (i.e., at least two of UE1-M share the same UE radio capabilities), the first CU to DU message corresponding to UE1 may include the MBS session ID, an indication of the identity of UE1, and capabilities IE1, the second CU to DU message corresponding to UE2 may include the MBS session ID, an indication of the identity of UE2, and capabilities IE2, and the Nth CU to DU message corresponding to UE N may include the MBS session ID, the identity of UE N, and capabilities IE N. Each of the remaining CU to DU messages (e.g., CU to DU messages corresponding to UE(N+1) through UE M) may include the MBS session ID and the identity of the corresponding remaining UE, but omit any indication of UE radio capabilities. For example, the N+1th CU to DU message corresponding to UE(N+1) may include the MBS session ID and the identity of UE(N+1), the N+2th CU to DU message corresponding to UE(N+2) may include the MBS session ID and the identity of UE(N+2), and so on.

[0162] In other implementations, each CU-to-DU message generated by the CU (814) may include a session ID of an MBS session of the MBS service, an indication of each of the 1-M UEs, and optionally an indication of the respective sets of radio capabilities of the indicated UEs. For example, instead of all M UEs providing an indication of a respective set of radio capabilities (e.g., radio capabilities for paging) because they may not support such functionality and only a total of N respective sets of radio capabilities (of the M UEs) are available at the CU. The N indications of the respective sets of radio capabilities are not necessarily distinct from each other.

[0163] In yet another implementation, each CU-to-DU message generated by the CU (814) may include a session ID of an MBS session for the MBS service, an indication of each of the 1-M UEs, and an indication of a respective set of radio capabilities for the indicated UEs. The indication of a respective set of radio capabilities may be predefined (default) capabilities for UEs that are interested in receiving the MBS and that correspond specifically to a UE.

[0164] At block 816 of method 800B, the CU sends the generated CU-to-DU message to one or more DUs, thereby instructing the one or more DUs to page the indicated UE1-M.

[0165] Turning now to FIG. 9, a CU may perform a method 900 to instruct one or more DUs to page one or more UEs for an MBS service. For example, the CU may be the CU 172 of the base station 104, and the DU may be the DU 174 of the base station 104. The method 900 begins at block 902, where the CU determines to page one or more UEs for a service. At block 904, the CU determines whether the service is an MBS service or a unicast service. Once the CU determines (904) that the service is an MBS service, the method 900 proceeds to block 906, where the CU generates a first CU-to-DU message that includes an MBS Session ID for the MBS service, an indication of respective identities of the one or more UEs, and an indication of a respective set of UE radio capabilities of the one or more UEs, which may be represented, for example, by a respective Capabilities IE of each indicated UE. In addition, the CU may optionally include an indication of a respective discontinuous reception (DRX) cycle configuration for at least one of the one or more UEs in the first CU-to-DU message at block 908. At block 910, the CU may send or transmit the first CU-to-DU message to one or more DUs (see, e.g., events 616 and 714).

[0166] On the other hand, when the CU determines in block 904 that the service is a unicast service, the method 900 proceeds to block 912, where the CU generates a second set of CU-to-DU messages, each of which corresponds to a different one of the one or more UEs. For example, each CU-to-DU message included in the second set of CU-to-DU messages may include an indication of the respective UE's identity, a session ID that uniquely corresponds to a combination of the unicast service and the respective UE, and an indication of the UE radio capabilities of the respective UE. In addition, in block 914, the CU may optionally include an indication of the respective DRX cycle configuration of the respective UE in each CU-to-DU message. In block 916, the CU may send or transmit the second set of CU-to-DU messages to one or more DUs (e.g., see events 715 and 765, events 713 and 763), which may be the same or a different set of one or more DUs to which the CU sent or transmitted the first CU-to-DU message.

[0167] Via method 900, a particular UE may be indicated for paging for only multicast services, only unicast services, or both multicast and unicast services. Furthermore, in some implementations, the first CU-to-DU message and the second set of CU-to-DU messages may be interface messages. For example, the interface messages may be F1 interface messages, such as F1 Application Protocol (F1AP) messages. In other implementations, the first CU-to-DU message may be a multicast paging interface message (e.g., an F1AP multicast paging message), and each CU-to-DU message included in the second set of CU-to-DU messages may be a paging interface message (e.g., an F1AP paging message).

[0168] 10A, a DU may perform a method 1000A for paging one or more UEs for an MBS service. For example, the DU may be the DU 174 of the base station 104. The method 1000A begins at block 1002, where the DU receives a CU-to-DU message from a CU (e.g., the CU 172 of the base station 104) including a session ID of an MBS session of the MBS service, an indication of the identity of each of UEs 1-M that the DU should page for the MBS service, and an indication of N of the respective sets of UE radio capabilities among those M UEs, where M and N are integers greater than 1 and N is less than or equal to M. In some implementations, the received CU-to-DU message also includes an indication of the respective sets of UE radio capabilities for each of UEs 1-M, where each set of UE radio capabilities may be represented, for example, by a respective capability IE. For example, the received CU-to-DU message may include a respective capability IE for each of UEs 1-M. A total of N different sets of UE radio capabilities may be indicated, where N is an integer greater than or equal to 1 and N is less than or equal to the total number of UEs, M. For example, when different UEs utilize a common set of UE radio capabilities, N is less than M.

[0169] In other implementations, the received CU-to-DU message optionally includes an indication of a respective set of UE radio capabilities for each UE1-M. For example, instead of all M UEs providing an indication of a respective set of radio capabilities (e.g., radio capabilities for paging) because they may not support such functionality, only an indication of a respective set of N total radio capabilities (of the M UEs) is available at the CU. The N indications of the respective sets of radio capabilities are not necessarily distinct from one another.

[0170] In response to receiving the CU-to-DU message (1002), in block 1004, the DU can generate a set of paging messages for use when paging UEs 1 to M, each paging message including the session ID of the MBS session of the MBS service, and each paging message corresponding to a respective set of resource allocation information (e.g., each combination of time domain resource allocation, frequency domain resource allocation, and modulation scheme). In fact, in block 1006, the DU can generate different sets of resource allocation information corresponding to the paging messages for UEs 1 to M, and specifically, corresponding to different sets of UE radio capabilities of UEs 1 to M. For example, the DU can generate a total of K different sets of resource allocation information, where K is an integer greater than or equal to 1, and K is an integer less than or equal to the total number N of sets of UE radio capabilities for M UEs. For example, when different sets of UE radio capabilities utilize a common set of resource allocation information, K is less than N. That is, mathematically, 0 < K ≤ N ≤ M. Therefore, in block 1004, the DU can generate K different paging messages, and in block 1006, the DU can generate K different sets of resource allocation information.

[0171] In one embodiment, each different set of resource allocation information (e.g., each allocated time domain resource, each allocated frequency domain resource, and each different combination of modulation schemes) can be represented by different downlink control information, i.e., DCI. Further, in some implementations, in block 1006, the DU can generate a respective cyclic redundancy code (CRC) for each DCI, and can scramble each CRC using, for example, a paging radio network temporary identifier (P-RNTI) or other suitable paging identifier as shown in FIG. 10A.

[0172] At block 1008, the DU may transmit each of the K different sets of resource allocation information on one or more shared downlink control channels, such as a Physical Downlink Control Channel (PDCCH) and / or other suitable shared downlink control channels. In an implementation in which the different sets of resource allocations are different DCIs and the CU generates a respective scrambled CRC for each DCI, the DU may transmit the respective scrambled CRC along with transmitting each DCI on the one or more shared downlink control channels.

[0173] Further, in block 1010, the DU may transmit each of the generated paging messages according to a respective set of UE radio capabilities of UE1-M, for example, via one or more appropriate shared downlink data channels (such as a Physical Downlink Shared Channel (PDSCH) and / or other appropriate shared downlink data channels), thereby paging each of UE1-M.

[0174] Referring now to FIG. 10B, a base station may perform method 1000B to page one or more UEs for an MBS service. The base station performing method 1000B may be an integrated base station or may be a distributed base station. For example, the base station may be base station 104 or base station 106. Method 1000B is generally similar to method 1000A. However, instead of the DU receiving a CU-to-DU message indicating UEs 1-M (1002) and instructing the DU to page the indicated UEs 1-M, as shown in method 1000A, in method 1000B, the BS receives a CN-to-BS message (e.g., from a core access and mobility management function (AMF) or similar) indicating UEs 1-M and instructing the BS to page the indicated UEs 1-M (1001). The received CN-to-BS message may include a session ID of an MBS session of the MBS service and an indication of the respective identities of UEs 1-M that the BS should page for the MBS service. In some implementations, the received CN-to-BS message also optionally includes an indication of a respective set of UE radio capabilities for each UE1-M, where each set of UE radio capabilities may be represented, for example, by a respective capability IE. For example, instead of all M UEs providing an indication of a respective set of radio capabilities (e.g., radio capabilities for paging) because they may not support such functionality and only a total of N respective sets of radio capabilities (of the M UEs) are available at the BS. The N indications of the respective sets of radio capabilities are not necessarily distinct from each other.

[0175] In response to receiving the CN-to-BS message (1001), the BS may generate a set of paging messages, e.g., a set of K different paging messages (1005), each of which includes an ID of an MBS session for the MBS service. The remainder of method 1000B (e.g., steps 1006, 1008, and 1010) may then be performed by the BS in a manner similar to that performed by the DU of FIG. 10A.

[0176] In some implementations of method 1000A of FIG. 10A and / or method 1000B of FIG. 10B, the specific capability IE X (e.g., in block 1002 and / or block 1001) includes information of supported NR bands and / or information of supported downlink scheduling offsets, where 1≦X≦N, as described for FIG. 6A. In some implementations, a RAN node (e.g., a DU or a base station) may determine to transmit a specific set of resource allocation information (e.g., a specific DCI) on at least one carrier frequency in a supported NR band. In some implementations, the RAN node may indicate a downlink scheduling slot offset (e.g., the offset is greater than 0) in the specific set of resource allocation information in a situation where the information of supported downlink scheduling offsets indicates support of a downlink scheduling slot offset for at least one carrier frequency. If the specific capability IE X does not include information of supported NR bands, the RAN node may determine to transmit a specific set of resource allocation information on a given carrier frequency. If the capability IE X does not include information of a supported downlink scheduling offset, the RAN node may indicate a downlink scheduling slot offset (e.g., the offset is equal to 0) or may refrain from including a downlink scheduling slot offset in the particular set of resource allocation information.

[0177] In some implementations of method 1000A and / or method 1000B, capability IE X (e.g., in block 1002 and / or block 1001) may include an indication that wake-up signaling is supported in corresponding UE Y, where 1≦Y≦M. Thus, when capability IE X includes an indication that wake-up signaling is supported in UE Y, a RAN node (e.g., CU or BS) may send a wake-up signal in a paging occasion before transmitting a particular set of resource allocation information in that paging occasion. Furthermore, if UE Y detects a wake-up signal, UE Y attempts to receive a corresponding set of resource allocation information (e.g., corresponding DCI) via shared downlink control channel Y (e.g., PDCCH Y) in the paging occasion. Otherwise, UE Y may not attempt to receive (e.g., may refrain from receiving) the corresponding set of resource allocation information on shared downlink control channel Y in the paging occasion. In addition, when capability IE X does not include an indication of supporting wake-up signaling, the RAN node may refrain from sending a wake-up signal prior to sending a set of resource allocation information corresponding to UE Y on a paging occasion.

[0178] In some implementations of method 1000A and / or method 1000B, capability IE X (e.g., in block 1002 and / or block 1001) may include an indication of support for paging early indication (PEI) in corresponding UE Y, where 1≦Y≦N. If capability IE X includes an indication of support for PEI in a particular UE Y, a RAN node (e.g., CU or BS) may include a PEI field in a corresponding set of resource allocation information (e.g., corresponding DCI). If UE Y receives the corresponding set of resource allocation information at a paging occasion and identifies the included PEI, UE Y may attempt to receive a transmission including a paging message via a shared downlink data channel (e.g., PDSCH) according to the corresponding set of resource allocation information. Otherwise, UE Y may not attempt to receive (or may refrain from receiving) any transmission according to the corresponding set of resource allocation information via the shared downlink data channel. In some implementations, UE Y receives transmissions over the shared downlink data channel in accordance with the corresponding set of resource allocation information regardless of whether support for the PEI is indicated (or not). If UE Y receives the corresponding set of resource allocation information at a paging occasion and identifies the PEI, UE Y may in such case attempt to decode information transmissions, including paging messages, received over the shared downlink data channel in accordance with the corresponding set of resource allocation information. Otherwise, UE Y may not attempt to decode any transmissions received over the shared downlink data channel in accordance with the corresponding set of resource allocation information.

[0179] 10C, a base station may perform method 1000C to page one or more UEs for MBS services. The base station performing method 1000C may be, for example, an integrated base station or a distributed base station. For example, the base station may be base station 104. Method 1000C is generally similar to method 1000A. However, rather than the DU receiving 1002 a CU-to-DU message indicating UEs 1-M and instructing the DU to page the indicated UEs 1-M as shown in method 1000A, in method 1000C, the base station receives 1003 a BS-to-BS message from a RAN node (e.g., from a CU of a distributed base station or from an integrated base station) indicating UEs 1-M and instructing the BS to page the indicated UEs 1-M. In an embodiment, the received BS-to-BS message may be a single (e.g., only one) message. The received BS-to-BS message may include a session ID of an MBS session of the MBS service and an indication of the respective identities of UEs 1-M that the BS should page for the MBS service. In some implementations, the received BS-to-BS message may also optionally include an indication of a respective set of UE radio capabilities for each UE 1-M, where the respective sets of UE radio capabilities may be represented, for example, by a respective capability IE. For example, instead of all M UEs providing an indication of a respective set of radio capabilities (e.g., radio capabilities for paging) because they may not support such functionality and / or only a total of N respective sets of radio capabilities of the M UEs may be available at the BS. The N indications of the respective sets of radio capabilities are not necessarily distinct from each other.

[0180] In response to receiving the BS-to-BS message (1003), the BS may generate a set of paging messages, e.g., a set of K different paging messages (1007), each of which includes an ID of an MBS session for the MBS service. The remainder of method 1000B (e.g., steps 1006, 1008, and 1010) may then be performed by the BS in a manner similar to that performed by the DU in FIG. 10A.

[0181] With reference to FIG. 11, a RAN node may perform a method 1100 for paging one or more UEs for MBS services. For example, the RAN node may be a DU, such as the DU 174 of the base station 104, or the RAN node may be an integrated base station. In block 1102, the RAN node may determine to page the UE (1102), for example, after receiving an instruction to page the UE from another RAN node (e.g., a CU or another base station) or a CN. The RAN node then determines (1104) whether the RAN node can obtain UE radio capability information (e.g., UE radio capability for paging) for the UE to be paged. For example, as discussed above, in various embodiments and circumstances, the DU or CU of the distributed base station may store UE-specific radio capability information. When the RAN node can obtain the UE's specific radio capability information from a stored local location (e.g., from the DU or CU), in block 1106, the RAN node obtains at least one UE radio configuration according to the UE's stored specific radio capability information, and in block 1108, the RAN node transmits a paging message to the UE according to the at least one first configuration corresponding to the UE's stored specific radio capability information.

[0182] On the other hand, when the RAN node cannot obtain the specific radio capability information of the UE, in block 1100, the RAN node obtains at least one radio configuration according to a predetermined or default set of UE radio capabilities. The predetermined or default set of UE radio capabilities may be stored in the RAN node (e.g., in a corresponding DU or CU), for example. In block 1112, the RAN node transmits a paging message to the UE according to at least one first configuration according to the predetermined or default UE radio capabilities.

[0183] In some implementations, a RAN node (e.g., a DU) receives a CU-to-DU message (e.g., an F1 multicast paging message or an F1 paging message) from a network node (e.g., a CU) and determines to page the UE in response to the received CU-to-DU message (1102). In other implementations, a RAN node (e.g., a base station) receives a CN-to-BS message (e.g., an NGAP multicast paging message, an NGAP paging message, or a multicast group paging message) from a network node (e.g., an AMF) and determines to page the UE in response to receiving the CN-to-BS message (1102). In yet other implementations, a RAN node (e.g., a base station) receives a BS-to-BS message (e.g., an Xn multicast paging message, an Xn paging message, or a RAN multicast group paging) from a network node (e.g., from another base station) and determines to page the UE in response to receiving the BS-to-BS message (1102). In yet another implementation, the RAN node receives an MBS data packet (e.g., content data for an MBS service) from a network node and determines to page the UE in response to receiving the MBS data packet (1102).

[0184] Turning now to FIG. 12A, a CN may perform a method 1200A for paging one or more UEs for an MBS service. For example, the CN may be the CN 110. In block 1202, the CN may determine to page multiple UEs, e.g., UEs 1-M. In response to determining (1202), the CN may generate a single CN-to-BS message (1204), where the CN-to-BS message includes a session ID of an MBS session of the MBS service, an indication of identities of the UEs 1-M, and an indication of a respective set of UE radio capabilities for each UE 1-M, where the respective sets of UE radio capabilities may be represented by a respective capabilities IE, e.g., in the manner described above. For example, the CN-to-BS message may be a multicast group paging message. The CN may then transmit (1206) the generated CN-to-BS message to one or more RAN nodes, e.g., one or more CUs or base stations, which may include an integrated base station.

[0185] FIG. 12B illustrates a method 1200B that may be implemented by a CN for paging one or more UEs for an MBS service. For example, the CN may be the CN 110. Similar to method 1200A, method 1200B may include the CN determining (1202) to page UEs 1-M. However, instead of generating (1204) and transmitting (1206) a single CN-to-BS message as shown in FIG. 12A, in FIG. 12B, method 1200B includes the CN generating (1214) a respective CN-to-BS message for each of UEs 1-M in response to the determination (1202). That is, the CN generates (1214) multiple CN-to-BS messages, each of which indicates a different UE 1-M. Each CN-to-BS message may include a session ID for the MBS service, an indication of the respective UE, and an indication of a particular set of radio capabilities of the indicated UEs, which may be represented by respective capabilities IEs of the indicated UEs, such as in the manner described above. The CN may transmit each of the generated CN-to-BS messages to one or more RAN nodes, for example, to one or more CUs or base stations, which may include an integrated base station (1216).

[0186] Turning now to FIG. 13A, a base station may implement a method 1300A for paging one or more UEs for an MBS service. The base station may be an integrated base station or a distributed base station. For example, the base station may be BS 104. In block 1302, the BS may determine to page multiple UEs, e.g., UEs 1-M. In response to the determination (1302), the BS may generate a single BS-to-BS message (1304), where the BS-to-BS message includes a session ID of an MBS session of the MBS service, an indication of identities of UEs 1-M, and an indication of a respective set of UE radio capabilities for each UE 1-M, where the respective sets of UE radio capabilities may be represented by a respective Capabilities IE, e.g., in the manner described above. For example, the BS-to-BS message may be a RAN Multicast Group Paging message. The BS may then transmit the generated BS-to-BS message (1306) to one or more RAN nodes, e.g., one or more CUs or base stations, which may include an integrated base station.

[0187] FIG. 13B illustrates a method 1300B that may be implemented by a base station for paging one or more UEs for an MBS service. The base station may be an integrated base station or a distributed base station. For example, the base station may be base station 104. Similar to method 1300A, method 1300B may include the BS determining (1302) to page UEs 1-M. However, instead of generating (1304) and transmitting (1306) a single BS-to-BS message as shown in FIG. 13A, in FIG. 13B, method 1300B includes the BS generating (1314) a respective BS-to-BS message for each of UEs 1-M in response to the determination (1302). That is, the BS generates (1314) multiple BS-to-BS messages, each of which indicates a different UE 1-M. Each BS-to-BS message may include a session ID for the MBS service, an indication of the respective UE, and an indication of a particular set of radio capabilities of the indicated UE, which may be represented, for example, by a respective capability IE of the indicated UE. The BS may transmit each of the generated BS-to-BS messages to one or more RAN nodes, e.g., one or more CUs or base stations, which may be integrated base stations (1316). For example, the BS-to-BS messages may be RAN Paging messages.

[0188] With reference to FIG. 14, a CN may perform method 1400 to instruct one or more base stations to page one or more UEs for an MBS service. For example, the CN may be CN 110. Method 1400 begins at block 1402, where the CN determines to page one or more UEs for a service. At block 1404, the CN determines whether the service is an MBS service or a unicast service. When the CN determines (1404) that the service is an MBS service, method 1400 proceeds to block 1406, where the CN generates a first CN-to-BS message including an MBS Session ID for the MBS service, an indication of respective identities of the one or more UEs, and an indication of a respective set of UE radio capabilities of the one or more UEs, which may be represented, for example, by a respective Capabilities IE of each indicated UE. In addition, the CN may optionally include in the first CN-to-BS message an indication of respective discontinuous reception (DRX) cycle configurations for at least some of the one or more UEs in block 1408. In block 1410, the CN may send or transmit the first CN-to-BS message to one or more RAN nodes, e.g., to one or more CUs and / or base stations, which may include an integrated base station.

[0189] On the other hand, when the CN determines in block 1404 that the service is a unicast service, the method 1400 proceeds to block 1412, where the CN generates a second set of CN-to-BS messages, each of which corresponds to a different one of the one or more UEs. For example, each CN-to-BS message included in the second set of CN-to-BS messages may include an indication of the respective UE's identity, a unicast service session ID that uniquely corresponds to a combination of the unicast service and the respective UE, and an indication of the UE radio capabilities of the respective UE. Additionally, in block 1414, the CN may optionally include in each CN-to-BS message an indication of the respective DRX cycle configuration of the respective UE. In block 1416, the CU may send or transmit the second set of CN-to-BS messages to one or more RAN nodes, which may be the same or a different set of RAN nodes to which the CN sent or transmitted the first CN-to-BS message.

[0190] Via method 1400, a particular UE may be indicated for paging for only multicast services, only unicast services, or both multicast and unicast services. Additionally, in some implementations, the first CN-to-BS message and the second set of CN-to-BS messages may be interface messages. For example, the interface messages may be NG interface messages, such as next generation application protocol (NGAP) messages. In other implementations, the first CN-to-BS message may be a multicast paging interface message (e.g., an NGAP multicast paging message or a Multicast Group Paging message) and / or the second set of CN-to-BS messages may be a set of paging interface messages (e.g., a set of NGAP paging messages).

[0191] 15, a base station may perform a method 1500 to instruct one or more other base stations to page one or more UEs for an MBS service, e.g., to page one or more UEs that have moved from being located in the coverage area of ​​the base station to being located in the coverage area of ​​one or more other base stations. The base station performing the method 1500 may be an integrated base station or a distributed base station. For example, the base station may be the base station 104 or the base station 106. The method 1500 begins at block 1502, where the BS determines to page one or more UEs for a service. At block 1504, the BS determines whether the service is an MBS service or a unicast service. When the BS determines (1504) that the service is an MBS service, method 1500 proceeds to block 1506, where the BS generates a first BS-to-BS message including an MBS Session ID for the MBS service, an indication of respective identities of one or more UEs, and an indication of a respective set of UE radio capabilities of the one or more UEs, which may be represented, for example, by a respective Capabilities IE of each indicated UE. Additionally, at block 1508, the BS may optionally include in the first BS-to-BS message an indication of respective Discontinuous Reception (DRX) cycle configurations for at least some of the one or more UEs. At block 1510, the BS may send or transmit the first BS-to-BS message to one or more RAN nodes, for example, to one or more CUs and / or base stations, which may include an integrated base station. Further, in some embodiments, in block 1511, the BS may implement or execute events 906, 908, and / or 910 of FIG. 9 so that, for example, interested UEs that have not left the coverage area of ​​the BS are paged by the BS for MBS services.

[0192] On the other hand, when the BS determines in block 1504 that the service is a unicast service, method 1500 proceeds to block 1512, where the CN generates a second set of BS-to-BS messages, each corresponding to a different one of the one or more UEs. For example, each BS-to-BS message included in the second set of BS-to-BS messages may include an indication of the respective UE's identity, a service ID of the unicast service that uniquely corresponds to the combination of the unicast service and the respective UE, and an indication of the UE radio capabilities of the respective UE. Additionally, in block 1514, the CN may optionally include in each BS-to-BS message an indication of the respective DRX cycle configuration of the respective UE. In block 1516, the BS may send or transmit the second set of BS-to-BS messages to one or more RAN nodes, which may be the same or a different set of RAN nodes to which the CN sent or transmitted the first BS-to-BS message. Further, in some embodiments, in block 1518, the BS may implement or execute events 912, 914, and / or 916 of FIG. 9 so that interested UEs that have not left the coverage area of ​​the BS are paged by the BS for MBS services.

[0193] Via method 1500, a particular UE may be indicated for paging for only multicast services, only unicast services, or both multicast and unicast services. Furthermore, in some implementations, the first BS-to-BS message and the second BS-to-BS message may be interface messages. For example, the interface messages may be Xn interface messages, such as Xn Application Protocol (XnAP) messages. In other implementations, the first BS-to-BS message may be a multicast paging interface message (e.g., an XnAP multicast paging message or a RAN Multicast Group Paging message), and the second set of BS-to-BS messages may be a set of paging interface messages (e.g., a set of XnAP paging messages or a RAN Paging message).

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

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

[0196] A user device (e.g., UE 102A or 102B) on which the techniques of the present disclosure may be implemented may be any suitable device capable of wireless communication, such as a smartphone, a tablet computer, a laptop computer, a mobile game console, a point-of-sale (POS) terminal, a health management device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smart watch, a wireless hotspot, a femtocell, or a broadband router. Furthermore, the user device may in some cases be integrated into an electronic system such as a vehicle head unit or an advanced driver assistance system (ADAS). Still further, 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.

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

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

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

[0200] 102UE 104 Base station 105 RAN 106 Base Station 110 Core Network 111 EPC 112 SGW 114 MME 116 PGW 124 cells 126 cells 130 Processing Hardware 132 MBS Controller 134 Non-MBS Controller 136 Paging Controller 140 Processing Hardware 142 MBS Controller 144 Non-MBS Controller 146 Paging Controller 150 Processing Hardware 152 MBS Controller 154 Non-MBS Controller 156 UE Paging Controller 160 5GC 162 (MB-)UPF 164 AMF 166 (MB-)SMF 172 CU 174 DU 202 PHY 204 MAC 206 RLC 208 EUTRA PDCP 210NR PDCP 212 SDAP 214 RRC 302 MBS Session 304 PDU sessions 312 DL Tunnel 314 MRB 316 QoS Flows 322 UE-specific DL tunnel and / or UL tunnel 324 DRB 402 MRB 404 DRB 412 DL Tunnel 413 UL Tunnel 422 DL logical channel 423 UL logical channel 432 UE-specific DL tunnel 433 UE-specific UL tunnel 442 DRB / DL logical channels 443 DRB / UL logical channels

Claims

1. 1. A method in a core network (CN) of a wireless communication system for managing paging of a plurality of user equipments (UEs) interested in a multicast and / or broadcast service (MBS) service when respective radio connections between the UEs and respective base stations of the wireless communication system are inactive, comprising: generating, by the CN, a single multicast paging message for paging the plurality of UEs interested in the MBS service, the single multicast paging message including an indication of a respective set of radio capabilities for each UE of the plurality of UEs; and transmitting, by the CN, the single multicast paging message to one or more base stations of the wireless communication system, thereby causing each of the UEs to be paged according to the respective set of radio capabilities for activating data reception of the MBS service.

2. The method described in claim 1, wherein the step of generating the single multicast paging message includes a step of generating a single multicast paging message including a session identifier of an MBS session of the MBS service, identification information of each of the plurality of UEs, and the indication of the respective sets of radio capabilities of each of the plurality of UEs.

3. The method described in claim 1, wherein the step of generating the single multicast paging message includes a step of generating the single multicast paging message in response to the CN receiving content data of the MBS service to be delivered to interested UEs.

4. The method described in claim 1, wherein the step of generating the single multicast paging message includes a step of generating the single multicast paging message in response to the CN setting up, together with at least one base station of the one or more base stations, a respective set of resources corresponding to the MBS service.

5. At least one UE of the plurality of UEs is operating in an idle state; the method further comprising storing, at the CN, an indication of the respective set of UE radio capabilities of the at least one UE operating in the idle state; 2. The method of claim 1, wherein generating the single multicast paging message including the indication of the respective set of radio capabilities of each of the plurality of UEs is based on the stored indication corresponding to the at least one UE operating in the idle state.

6. At least one UE of the plurality of UEs is operating in an idle state, and the method further comprises, following each activation of data reception of the MBS service in the at least one UE operating in the idle state: The method according to claim 1 , comprising the step of transmitting, by the CN, content data of the MBS service to the at least one UE operating in the idle state.

7. Upon activation of data reception of the MBS service in one or more UEs of the plurality of UEs, and transmitting, by the CN, content data of the MBS service to the one or more UEs of the plurality of UEs via an MBS session of the MBS service.

6. The method according to any one of claims 1 to 5.

8. At least one UE of the plurality of UEs is operating in an inactive state, and the method further comprises, following each activation of data reception of the MBS service in the at least one UE operating in the inactive state: transmitting, by the CN, content data of the MBS service to the at least one UE operating in the inactive state; 6. The method according to any one of claims 1 to 5.

9. one or more UEs of the plurality of UEs are operating in an inactive state or an idle state, and the method further comprises, following respective activation of data reception of the MBS service in the one or more UEs operating in the inactive state: transitioning, by the CN, the one or more UEs to operate in a connected state with the one or more UEs operating in the inactive state or the idle state; and transmitting, by the CN, content data of the MBS service to the one or more UEs operating in the connected state.

10. at least one UE of the plurality of UEs is operating in an inactive state corresponding to a respective radio connection with a first base station of the wireless communication system; The method further includes receiving, by the CN, a request to switch the path of the at least one UE of the plurality of UEs from corresponding to the first base station to corresponding to a second base station of the wireless communication system; transmitting, by the CN, content data of the MBS service to the at least one UE of the plurality of UEs via the second base station.

6. The method according to any one of claims 1 to 5.

11. The method further comprises determining, by the CN, to page the plurality of UEs for an indicated service; and determining that the indicated service is the MBS service; 6. The method of claim 1, wherein performing the method of claim 1 is in response to determining that the indicated service is the MBS service.

12. A method described in any one of claims 1 to 5, further comprising a step of including an indication of a respective discontinuous reception (DRX) cycle configuration corresponding to each of the plurality of UEs indicated in the single multicast paging message, wherein the respective DRX cycle configurations corresponding to each of the UEs for the MBS service are different from the respective DRX cycle configurations corresponding to each of the UEs for the unicast service.

13. A node of a wireless communication system comprising processing hardware and configured to perform the method of any one of claims 1 to 5.

14. A core network (CN) of a wireless communication system comprising processing hardware and configured to implement the method of any one of claims 1 to 5.

15. A wireless communication system comprising processing hardware and configured to implement the method of any one of claims 1 to 5.

Images