Managing state transitions of user equipment in multicast communications

Abstract

A radio access network (RAN) participating in a multicast and broadcast service (MBS) session may implement a method for managing MBS communications. The method comprises: (a) performing (i) unicast communication and (ii) multicast communication with a UE operating in a connected state; (b) in response to determining that the data of the unicast communication is inactive, transmitting a message indicating that the UE will transition from the connected state to an inactive state in which the radio connection between the UE and the RAN is suspended; and (c) continuing to perform multicast communication with the UE operating in the inactive state.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of the filing date of provisional U.S. patent application No. 63 / 388,288, entitled “MANAGING STATE TRANSITION FOR AUSER EQUIPMENT IN MULTICAST COMMUNICATION,” filed on July 12, 2022. The entire contents of the provisional application are hereby expressly incorporated herein by reference. Technical Field

[0003] The present disclosure relates to wireless communications, and more particularly to enabling one or more multicast and / or broadcast services (MBS) for a user equipment (UE) operating in an inactive state. Background Art

[0004] The background description provided herein is for the purpose of generally presenting the context of the present disclosure. The work of the presently named inventors (to the extent that it is described in this background section) and aspects of the specification that might not have been considered prior art at the time of filing are neither explicitly nor implicitly admitted to be prior art to the present disclosure.

[0005] In a telecommunications system, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as delivery, encryption, integrity protection, etc. of user-plane data. For example, the PDCP sublayer provides sequencing of protocol data units (PDUs) in the uplink direction from a user device (also referred to as user equipment or "UE") to a base station and in the downlink direction from a base station to a UE. The PDCP sublayer also provides services of signaling radio bearers (SRBs) to the radio resource control (RRC) sublayer. The PDCP sublayer also provides services of data radio bearers (DRBs) to the service data adaptation protocol (SDAP) sublayer or protocol layers such as the Internet Protocol (IP) layer, the Ethernet protocol layer, and the Internet Control Message Protocol (ICMP) layer. Generally speaking, depending on the scenario, the UE and the base station use SRBs to exchange RRC messages and non-access stratum (NAS) messages, and use DRBs to transmit data on the user plane.

[0006] In some scenarios, the UE concurrently utilizes the resources of multiple nodes (e.g., base stations, or components of distributed base stations or decomposed base stations) of a radio access network (RAN) interconnected by a backhaul. When such network nodes support different radio access technologies (RATs), this type of connection is called multi-radio dual connection (MR-DC). When operating with MR-DC, the cell associated with the base station operating as a master node (MN) defines a master cell group (MCG), and the cell associated with the base station operating as a secondary node (SN) defines a secondary cell group (SCG). The MCG covers one primary cell (PCell) and zero, one or more secondary cells (SCells), and the SCG covers one primary and secondary cells (PSCell) and zero, one or more SCells. The UE communicates with the MN via the MCG and the SN via the SCG. In other scenarios, the UE utilizes the resources of one base station at a time with a single connection (SC). The UE in the SC communicates with the MN via the MCG. The base station and / or the UE determines when the UE should establish a radio connection with another base station. For example, the base station determines to switch the UE to another base station and initiates a switching process. In other scenarios, the UE concurrently utilizes resources of another RAN node (eg, a base station, or a component of a distributed or disaggregated base station) interconnected via the backhaul.

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

[0008] In some scenarios, whether in SC or DC operation, the UE performs a handover procedure from one cell to another. These procedures involve messaging between RAN nodes and the UE (e.g., RRC signaling and preparation). Depending on the scenario, the UE performs a handover from a cell of a serving base station to a target cell of a target base station, or from a cell of a first distributed unit (DU) of a serving base station to a target cell of a second DU of the same base station. In some DC scenarios, the UE performs a PSCell change procedure to change the PSCell. These procedures involve messaging between RAN nodes and the UE (e.g., RRC signaling and preparation). Depending on the scenario, the UE performs a PSCell change from a PSCell of a serving SN to a target PSCell of a target SN, or from a PSCell of a source DU of a base station to a PSCell of a target DU of the same base station. In addition, the UE performs a handover or PSCell change within a cell for synchronous reconfiguration.

[0009] For broadcast communication services, the same service and the same specific content data are provided to all UEs in a certain geographic area at the same time (i.e., all UEs in the broadcast service area are authorized to receive the data). Broadcast communication services are delivered to UEs using broadcast sessions. Depending on the scenario, UEs receive broadcast communication services in RRC_IDLE, RRC_INACTIVE, and / or RRC_CONNECTED states. For multicast communication services, the same service and the same specific content data are provided to a dedicated set of UEs at the same time (i.e., not all UEs in the multicast service area are authorized to receive the data). Multicast communication services are delivered to UEs using multicast sessions.

[0010] RAN nodes use multicast for UEs operating in RRC_CONNECTED state, which may not fully meet the requirements of important services (such as mission critical services), especially for cells with a large number of UEs. Moreover, maintaining the RRC_CONNECTED state is not power efficient for the UE. Therefore, it is important to support multicast for UEs in RRC_INACTIVE state. However, it is not clear how to enable multicast for UEs operating in RRC_INACTIVE state. Summary of the invention

[0011] In a multicast and / or broadcast service (MBS) session, when a UE participating in both unicast and multicast transitions to an inactive state, the UE continues MBS reception after inactivity is detected for unicast. Depending on the implementation, the RAN communicates with the UE to enable the UE to continue MBS reception in the inactive state.

[0012] An example embodiment of these techniques is a multicast and / or broadcast service (MBS) communication method implemented in a radio access network (RAN). The method includes: performing (i) unicast communication and (ii) multicast communication with a UE operating in a connected state; in response to determining data inactivity of the unicast communication, sending a message indicating that the UE will transition from the connected state to an inactive state, in which a radio connection between the UE and the RAN is suspended; and continuing to perform multicast communication with the UE operating in the inactive state.

[0013] Another example embodiment of the techniques is a multicast and / or broadcast service (MBS) communication method implemented in a user equipment (UE). The method includes: in a connected state, performing (i) unicast communication and (ii) multicast communication with a radio access network (RAN); when data inactivity of the unicast communication is detected, receiving a message indicating that the UE will transition from the connected state to an inactive state, in which a radio connection between the UE and the RAN is suspended; and in the inactive state, continuing to perform multicast communication with the RAN. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1A is a block diagram of an example system in which the disclosed techniques for managing multicast radio resources may be implemented;

[0015] Figure 1B The centralized unit (CU) and the distributed unit (DU) can be Figure 1A A block diagram of an example base station operating in a system of FIG.

[0016] Figure 2A is a block diagram of an example protocol stack, Figure 1A The UE can be connected according to the protocol stack Figure 1A Base station communication;

[0017] Figure 2B is a block diagram of an example protocol stack, Figure 1A The UE can communicate with the DU and CU of the base station according to the protocol stack;

[0018] Figure 3 is a block diagram of an example tunnel architecture for an MBS session and a PDU session;

[0019] Figure 4 is a block diagram of an example tunnel architecture for MRB and DRB;

[0020] Figure 5A Among them Figure 1A and / or Figure 1BMessage passing diagram for an example scenario in which CN and RAN nodes manage transmission of downlink data for an MBS session to a UE operating in a connected state;

[0021] Figure 5B is with Figure 5A Messaging diagram for a similar example scenario, but where the CN and RAN nodes perform the distribution setup before performing the bearer context setup;

[0022] Figure 5C is with Figure 5A and Figure 5B a message passing diagram for a similar example scenario, but wherein the CN sends a message to the RAN node, the message comprising a first QoS flow configuration for generating a second QoS flow configuration;

[0023] Figure 5D is with FIG. 5A to FIG. 5C a messaging diagram for a similar example scenario, but where the RAN node determines to transition the UE to an inactive state after performing MBS data transmission for a first MBS session;

[0024] Figure 5E is with Figure 5D Message passing diagram for a similar example scenario, but where the RAN node sends a message to the UE to reconfigure radio resources instead of releasing radio resources;

[0025] Fig. 6A Among them Figure 1A and / or Figure 1B A flowchart of an example method for a RAN node performing unicast and multicast communications with a UE operating in a connected state and continuing to perform multicast communications with a UE operating in an inactive state;

[0026] Figure 6B is with Fig. 6A a flow chart of a similar example method, but wherein the RAN node determines whether to transition the UE to the inactive state or remain in the connected state based on whether the UE supports multicast communications in the inactive state;

[0027] Figure 7 Among them Figure 1A and / or Figure 1B A flowchart of an example method for a RAN node to determine whether to transition a UE to an inactive state depending on data inactivity and whether multicast transmission is configured;

[0028] Figure 8 Among them Figure 1A and / or Figure 1B A flowchart of an example method for a RAN node to determine whether to disable or enable data inactivity detection for a UE depending on whether multicast transmission is configured for the UE;

[0029] Fig. 9 Among them Figure 1A and / or Figure 1B A flowchart of an example method for a RAN node to enable and subsequently disable data inactivity detection for a UE;

[0030] Fig. 10A Among them Figure 1A and / or Figure 1B A flowchart of an example method for a RAN node to determine whether to send a data inactivity notification depending on whether multicast transmission is configured; and

[0031] Fig. 10B is with Fig. 10A Flowchart of a similar example method, but wherein the RAN node sends an indication of UE activity when the UE is configured to receive multicast transmissions. DETAILED DESCRIPTION

[0032] Figure 1A An example wireless communication system 100 is depicted in which the disclosed techniques 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 103 and base stations 104, 106 of 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 than Figure 1A More or fewer UEs and / or more or fewer base stations are shown. For example, base stations 104, 106 can be any suitable base station of one or more types, such as an evolved Node B (eNB), a next generation eNB (ng-eNB), or a 5G Node B (gNB). As a more specific example, base station 104 can be an eNB or a gNB, and base station 106 can be a gNB.

[0033] Base station 104 supports cell 124, and base station 106 supports cell 126. Cell 124 partially overlaps with cell 126, allowing UE 102A to be within range of communication with base station 104 while being within range of communication with base station 106 (or within range of detecting or measuring signals from base station 106). For example, the overlap may make it possible for UE 102A to switch between cells (e.g., from cell 124 to cell 126) or between base stations (e.g., from base station 104 to base station 106) before UE 102A experiences a radio link failure. In addition, the overlap allows various dual connectivity (DC) scenarios. For example, UE 102A may communicate with base station 104 (operating as a master node (MN)) and base station 106 (operating as a secondary node (SN)) in DC. When UE 102A is in DC with base station 104 and base station 106, base station 104 operates as a master eNB (MeNB), a master ng-eNB (Mng-eNB) or a master gNB (MgNB), and base station 106 operates as a secondary gNB (SgNB) or a secondary ng-eNB (Sng-eNB).

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

[0035] In MBS operation, the UE 102A may use an MBS radio bearer (MRB) that is terminated at a MN (e.g., base station 104) or a 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 is terminated at a base station 106 that may be operating as a MN or a SN. In some scenarios, the base station (e.g., MN or SN) may send MBS data to the UE 102A via the MRB over unicast radio resources (i.e., radio resources dedicated to the UE 102A). In other scenarios, the base station (e.g., MN or SN) may send MBS data to the UE 102A via the MRB over multicast radio resources (i.e., radio resources shared by the UE 102A and one or more other UEs) or a DL BWP of a cell from the base station. 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 MBS or not used for unicast).

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

[0037] Base station 106 includes processing hardware 140, which may include one or more general purpose processors (eg, CPUs) and computer readable memory storing machine readable instructions executable on the general purpose processors, and / or special purpose processing units. Figure 1A The processing hardware 140 in the example implementation includes an MBS controller 142 and a non-MBS controller 144, which may be similar to the controllers 132 and 134 of the base station 130, respectively. Figure 1ANot shown, but RAN 105 may include additional base stations with processing hardware similar to processing hardware 130 of base station 104 and / or processing hardware 140 of base station 106 .

[0038] UE 102A includes processing hardware 150, which may include one or more general-purpose processors (eg, CPUs) and computer-readable memory storing machine-readable instructions executable on the general-purpose processors, and / or special-purpose processing units. Figure 1A The processing hardware 150 in an example implementation includes an MBS controller 152 that is configured to manage or control the reception of MBS information. For example, the UE MBS controller 152 may be configured to support RRC configurations, procedures, and messaging associated with MBS processes, and / or other operations associated with those configurations and / or procedures (including HARQ processes), as discussed below. The processing hardware 150 may also include a non-MBS controller 154 that is configured to manage or control one or more RRC configurations and / or RRC procedures in accordance with any of the implementations discussed below when the UE 102A is communicating with the MN and / or SN during non-MBS operation. Although Figure 1A Not shown, but UEs 102B and 103 may include processing hardware similar to processing hardware 150 of UE 102A.

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

[0040] 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 deliver user plane packets associated with audio calls, video calls, Internet services, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides a connection from a UE (e.g., UE 102A or 102B) to one or more external packet data networks (e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network). The 5GC 160 includes a user plane function (UPF) 162 and an access and mobility management (AMF) 164, and / or a session management function (SMF) 166. UPF 162 is generally configured to deliver user plane packets associated with audio calls, video calls, Internet services, etc., AMF 164 is generally configured to manage authentication, registration, paging and other related functions, and SMF 166 is generally configured to manage PDU sessions.

[0041] UPF 162, AMF 164 and / or SMF 166 may be configured to support MBS. For example, SMF 166 may be configured to manage or control MBS delivery, configure UPF 162 and / or RAN 105 for MBS flows, and / or manage or configure one or more MBS sessions or PDU sessions for MBS for UE (e.g., UE 102A or 102B). UPF 162 is configured to deliver MBS data packets for audio, video, Internet services, etc. to RAN 105. UPF 162 and / or SMF 166 may be configured for both non-MBS unicast services and MBS, or only for MBS.

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

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

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

[0045] Figure 1B An example distributed implementation of any one or more of base stations 104 and 106 is depicted. In this implementation, base station 104 or 106 includes a central unit (CU) 172 and one or more distributed units (DUs) 174. CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions that can be executed on the general-purpose processors, and / or special-purpose processing units. For example, CU 172 may include Figure 1A Some or all of the processing hardware 130 or 140.

[0046] 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 storing 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 media access control (MAC) controller configured to manage or control one or more MAC operations or processes (e.g., random access processes); and a radio link control (RLC) controller configured to manage or control one or more RLC operations or processes when a base station (e.g., base station 104) operates as a MN or SN. The processing hardware may also include a physical (PHY) layer controller configured to manage or control one or more PHY layer operations or processes.

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

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

[0049] Figure 2AAn example protocol stack 200 is shown in a simplified manner, according to which a UE (e.g., UE 102A, 102B, or 103) can communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106). In the example protocol stack 200, 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 in turn 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 in turn provides RLC channels to the NR PDCP sublayer 210. In some implementations, the UE 102A supports both EUTRA and NR stacks, such as Figure 2A As shown, switching between EUTRA and NR base stations is supported and / or DC on EUTRA and NR interfaces is supported. Figure 2A As shown, the UE 102A may support layering of NR PDCP 210 on EUTRA RLC 206A, and layering of SDAP sublayer 212 on NR PDCP sublayer 210. Sublayers are also referred to herein simply as "layers."

[0050] 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 for cases where the difference between SDUs and PDUs is important, for simplicity, the present disclosure refers to both SDUs and PDUs as "packets." The packets may be MBS packets or non-MBS packets. For example, the MBS packets may include application content for MBS services (e.g., IPv4 / IPv6 multicast delivery, IPTV, wireless software delivery, group communication, IoT applications, V2X applications, and / or emergency messages related to public safety). As another example, the MBS packets may include application control information for the MBS services.

[0051] For example, on the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide SRBs 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 may provide DRBs to support data exchange. For example, the data exchanged on the NR PDCP sublayer 210 may be SDAP PDUs, IP packets, or Ethernet packets.

[0052] In a scenario where the UE 102A, 102B, or 103 operates with the base station 104 serving as the MeNB and the base station 106 serving as the SgNB in ​​EN-DC, the wireless communication system 100 may provide the UE 102A, 102B, or 103 with a MN-terminated bearer using the EUTRA PDCP sublayer 208 or a MN-terminated bearer using the NR PDCP sublayer 210. In various scenarios, the wireless communication system 100 may also provide the UE 102A, 102B, or 103 with a 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.

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

[0054] Figure 2B An example protocol stack 250 is shown in a simplified manner that a UE 102A, 102B, or 103 may use to communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). Figure 2A The radio protocol stack 200 is functionally split, as shown by Figure 2B 206B, NR MAC 204B, and NR PHY 202B) can be delegated to the DU. To support the connection with the 5GC, the NR PDCP 210 provides SRBs to the RRC 214, and the NR PDCP 210 provides DRBs to the SDAP 212 and SRBs to the RRC 214.

[0055] refer to Figure 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). For example, the MBS data may include IP packets, TCP / IP packets, UDP / IP packets, real-time transport protocol (RTP) / UDP / IP packets, or RTP / TCP / IP packets.

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

[0057] Tunnel 312A may be at a transport layer or sublayer, for example, operating on a user datagram protocol (UDP) protocol layered on an Internet protocol (IP). As a more specific example, tunnel 312A may be associated with a general packet radio system (GPRS) tunnel protocol (GTP). For example, tunnel 312A may correspond to a specific IP address (e.g., an IP address of a base station 104 / 106) and a specific tunnel endpoint identifier (TEID) (e.g., assigned by base station 104 / 106). More generally, tunnel 312A may have any suitable transport layer configuration. CN 110 may specify an IP address and a TEID address in a header of a tunnel packet including an MBS data packet, and send the tunnel packet downstream to base station 104 / 106 (i.e., the header may include an IP address and / or a TEID) via tunnel 312A. For example, the header may include an IP header and a GTP header including an IP address and a TEID, respectively. The base stations 104 / 106 may accordingly use the IP address and / or TEID to identify data packets propagating via the tunnel 312A.

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

[0059] For each of tunnels 312A, 312B, etc., the MBS service may include one or more quality of service (QoS) flows. For example, the MBS service on tunnel 312B may include a set of flows 316, which includes QoS flows 316A, 316B, ..., 316L. In addition, the logical channels of the MRB may support a single QoS flow or multiple QoS flows. Figure 3 In the example configuration of , base station 104 / 106 maps QoS flows 316A and 316B to the MTCH of MRB 314B-1, and maps QoS flow 316L to the MTCH of MRB 314B-N.

[0060] In various scenarios, CN 110 may assign different types of MBS services to different QoS flows. For example, a flow with a relatively higher QoS value may correspond to an audio packet, while a flow with a relatively lower QoS value may correspond to a video packet. As another example, a flow with a relatively higher QoS value may correspond to an I frame or a complete image used in video compression, while a flow with a relatively lower QoS value may correspond to a P frame or a predicted picture including only a modification of an I frame.

[0061] Continue to refer Figure 3, the base station 104 / 106 and the CN 110 may maintain one or more PDU sessions to support unicast services between the CN 110 and a specific 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, ..., 324-N). Each of the DRBs 324A may correspond to a corresponding logical channel such as a dedicated traffic channel (DTCH).

[0062] Reference now Figure 4 , when the base station 104 / 106 is implemented in a distributed manner, the CU 172 and the DU 174A / 174B may establish a tunnel for downlink data and / or uplink data associated with an MRB or a DRB. The MRB 314A-1 discussed above may be implemented as an MRB 402A, which connects the CU 172 to multiple UEs, such as, for example, UEs 102A and 102B. The MRB 402A may include a DL tunnel 412A connecting the CU 172 and the DU 174A / 174B and a DL logical channel 422A corresponding to the DL tunnel 412A. In particular, the DU 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, via which the CU 172 sends MBS data packets to multiple UEs. Alternatively, DL tunnel 412A may be a UE-specific DL tunnel via which CU 172 sends MBS data packets to a specific UE.

[0063] Optionally, the MRB 402A further 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 may map the uplink traffic received via the UL logical channel 423A to the UL tunnel 413A.

[0064] Tunnels 412A and 413A may operate on a transport layer or sublayer of the F1-U interface. As a more specific example, CU 172 and DU 174A / 174B may use F1-U for user plane services, and tunnels 412A and 413A may be associated with a GTP-U protocol layered on UDP / IP, where IP is layered on appropriate data link and physical (PHY) layers. In addition, in at least some of the cases described, MRB 402 and / or DRB 404 additionally support control plane services. More specifically, CU 172 and DU 174A / 174B may exchange F1-AP messages over an F1-C interface that relies on a stream control transmission protocol (SCTP) layered on IP, where, similar to F1-U, IP is layered on appropriate data link and PHY layers.

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

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

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

[0068] Next, refer to FIG. 5A to FIG. 5ESeveral example scenarios in which the UE and / or RAN perform the disclosed techniques for supporting MBS for UEs operating in a connected state and / or an inactive state are discussed. In the following description, the connected state, the inactive state, and the idle state may be, for example, an RRC_CONNECTED state, an RRC_INACITVE state, and an RRC_IDLE state, respectively.

[0069] Figure 5A An example scenario 500A for establishing an MBS session is shown. The base station 104 includes a DU 174, a CU-CP 172A, and a CU-UP 172B. It should be noted that the scenario 500A may also be applicable to an integrated CU (eg, a CU that is not split into CP and UP functional nodes).

[0070] UE 102 (e.g., Figure 1A UE 102A) initially performs 502 an MBS session join procedure with CN 110 via base station 104 to join a first MBS session. In some implementations, the MBS session join procedure does not involve CU-UP 172B. In other implementations, UE 102 subsequently performs additional one or more MBS join procedures, and event 502 is accordingly the first MBS join procedure of multiple MBS join procedures. In some implementations, since base station 104 configures a common DL tunnel for MBS services (rather than a UE-specific tunnel as discussed below), processes 502 and 592A occur in either order. In other words, in such implementations, base station 104 configures the common DL tunnel before any UE joins the first MBS session.

[0071] In some implementations, the UE 102 performs 502 an MBS session join process while operating in a connected state. In some scenarios or implementations, if the first MBS session has not yet started, the CU-CP 172A transitions the UE 102 to an inactive state or an idle state after the MBS session join process to save battery power of the UE 102. For example, the CU-CP 172A may send an RRC release message to the UE 102 to transition the UE 102 from a connected state to an inactive state or an idle state. The UE 102 transitions to an inactive state or an idle state in response to the RRC release message. In some implementations, for the inactive state, the UE 102 later initiates an RRC connection recovery process with the CU-CP 172A via the DU 174 to transition to a connected state. In response to the initiation, UE 102 sends an RRC recovery request message to CU-CP 172A via DU 174 and receives an RRC recovery message from CU-CP 172A via DU 174. In response, UE 102 transitions 503 to a connected state and sends an RRC recovery completion message to CU-CP 172A via DU 174. In another implementation, for the idle state, UE 102 later initiates an RRC connection establishment process with CU-CP 172A via DU 174 to transition to a connected state. In response to the initiation, UE 102 sends an RRC setup request message to CU-CP 172A via DU 174 and receives an RRC setup message from CU-CP 172A via DU 174. In response, UE 102 transitions 503 to a connected state and sends an RRC setup completion message to CU-CP 172A via DU 174.

[0072] Otherwise, if the first MBS session has started, is starting, or is about to start, the CU-CP 172A keeps the UE 102 in the connected state.

[0073] When UE 102 operates in a connected state, UE 102 monitors a PDCCH with a cell radio network temporary identifier (C-RNTI) to communicate unicast data with DU 174. In some implementations, the unicast data includes data associated with SRBs and / or DRBs. In one implementation, the unicast data includes the following messages for the MBS session join process and messages of events 528 and 530 described below. In some implementations, the unicast data also includes unicast MBS data (e.g., at event 536). In other implementations, the unicast data excludes multicast MBS data (e.g., at event 536). In some implementations, when UE 102 receives a DCI and a scrambled CRC on the PDCCH, UE 102 uses the C-RNTI and the DCI to verify the CRC. If UE 102 verifies that the CRC is valid and the DCI includes a UL grant, UE 102 sends a UL transmission including unicast data to DU174 according to the UL grant. If UE 102 verifies that the CRC is valid and the DCI includes a DL assignment, UE 102 receives a DL transmission including unicast data from DU 174 according to the DL assignment.

[0074] In some implementations, to perform the MBS session join procedure, UE 102 sends an MBS session join request message to CN 110 via base station 104. In some such implementations, in response, CN 110 sends an MBS session join response message to UE 102 via base station 104 to authorize UE 102 to access the first MBS session. In some implementations, UE 102 includes a first MBS session ID (e.g., MBS session ID 1) of the first MBS session in the MBS session join request message. In some cases, CN 110 includes the first MBS session ID in the MBS session join response message. In some implementations, UE 102 sends an MBS session join complete message to CN 110 via base station 104 in response to the MBS session join response message.

[0075] In some implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message are 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 are NAS messages, such as 5G Mobility Management (5GMM) messages or 5G Session Management messages (5GSM). In some implementations, for messages such as 5GSM messages, UE 102 sends a first UL container message including an MBS session join request message to CN 110 via base station 104; CN 110 sends a DL container message including an MBS session join response message to UE 102 via base station 104; and UE 102 sends a second UL container message including an MBS session join complete message to CN 110 via base station 104. In some implementations, such container messages are messages similar to 5GMM messages, or are 5GMM messages.

[0076] In some implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message are respectively a PDU session modification request message, a PDU session modification command message, and a PDU session modification complete message. To simplify the following description, the terms MBS session join request message, MBS session join response message, and / or MBS session join complete message may refer to corresponding container messages, or corresponding messages without containers.

[0077] In some implementations, UE 102 performs a PDU session establishment procedure with CN 110 via base station 104 to establish a PDU session in order to perform an MBS session join procedure. In another implementation, during the PDU session establishment procedure, UE 102 communicates a PDU session ID of the PDU session with CN 110 via base station 104.

[0078] In some implementations, before, during, or after the first MBS session joining process (event 502), CN 110 sends 504 a first CN to BS message (e.g., a multicast session activation request message) including the first MBS session ID to CU-CP 172A to request CU-CP 172A to configure or activate resources for the first MBS session (e.g., a multicast session).

[0079] In some implementations, the CN 110 includes a first MBS Quality of Service (QoS) flow configuration for the first MBS session in a first CN to BS message. In some implementations, the first MBS QoS flow configuration configures MBS QoS flows 1, ..., M associated with the first MBS session, where M is an integer and greater than zero. In some implementations, the first MBS QoS flow configuration includes an MBS QoS flow identifier 1, ..., M and / or MBS QoS flow level QoS parameters 1, ..., M of the MBS QoS flows 1, ..., M associated with the first MBS session. In some implementations, each of the MBS QoS flow configurations 1, ..., M includes an MBS QoS flow identifier and MBS QoS flow level QoS parameters for a specific MBS QoS flow.

[0080] In other implementations, CN 110 does not include the MBS QoS flow configuration for the first MBS session in the first CN to BS message. Therefore, CU-CP 172A generates a second MBS QoS flow configuration based on the preconfigured MBS QoS flow configuration. For example, the second MBS QoS flow configuration is the same as the preconfigured MBS QoS flow configuration. In another example, the second MBS QoS flow configuration is similar to the preconfigured MBS QoS flow configuration. In some implementations, CU-CP 172A is preconfigured with the preconfigured MBS QoS flow configuration before receiving the first CN to BS message. In other implementations, CU-CP 172A receives the preconfigured MBS QoS flow configuration from an operation, administration, and maintenance (OAM) node before receiving the first CN to BS message. The examples or implementations described for the first MBS QoS flow configuration may be applicable to preconfigured MBS QoS flow configurations.

[0081] In yet other implementations, CN 110 sends an additional CN to BS message (e.g., a multicast session update request message) including the first MBS session ID and the first MBS QoS flow configuration to CU-CP 172A after sending 504 the first CN to BS message. After receiving the additional CN to BS message, CU-CP 172A sends 560 the first CP to UP message and sends 506 the first CU to DU message to CU-UP 172B and DU 174, respectively. In other words, CU-CP 172A delays sending the first CP to UP message and the first CU to DU message (e.g., delays performing the MC bearer context setup procedure and the multicast context setup procedure) until the first MBS QoS flow configuration or the additional CN to BS message is received. In some such implementations, CU-CP 172A sends an additional BS to CN message (e.g., a multicast session update response message) to CN 110 in response to the additional CN to BS message.

[0082] In some implementations, the CU-CP 172A sends an additional BS-to-CN message to the CN 110 upon receiving 504 the first CN-to-BS message. In other implementations, the CU-CP 172A sends 518 the second BS-to-CN message to the CN 110 before or after receiving 514 the second CN-to-BS message, receiving 566 the second UP-to-CP message (e.g., as described below), or sending 516 the second CU-to-DU message. In some implementations, the CU-CP 172A sends 518 the second BS-to-CN message to the CN 110 before receiving the additional CN-to-BS message or sending the additional BS-to-CN message. In other implementations, the CU-CP 172A sends 518 the second BS-to-CN message to the CN 110 after receiving the additional CN-to-BS message or sending the additional BS-to-CN message.

[0083] In some implementations, CN 110 includes the first slice information in a fourth CN to BS message. In some such cases, CN 110 does not include the first slice information in the first CN to BS message. In some implementations, CN 110 includes the first MBS area information in additional CN to BS messages. In some such cases, CN 110 does not include the first MBS area information in the first CN to BS message.

[0084] In some implementations, CN 110 includes first slice information indicating a network slice for the first MBS session in the first CN to BS message. For example, in some implementations, the first slice information is single network slice selection assistance information (S-NSSAI) that identifies a specific network slice. In other implementations, CN 110 does not include slice information (e.g., S-NSSAI) in the first CN to BS message. In some such cases, a default network slice is used for the first MBS session.

[0085] In some implementations, CN 110 includes first MBS area information (e.g., MBS service area IE) configuring or indicating an MBS area of ​​a first MBS session in the first CN to BS message. In the case where the first MBS session is a location-dependent multicast session, the first MBS area information includes one or more tuples of {MBS area session ID IE, MBS service area information IE}. In the case where the first MBS session is a location-independent multicast session, the first MBS information includes an MBS service area information IE. The MBS service area information IE in the first MBS area information includes a cell identifier list and / or a tracking area identifier (TAI) list. In some implementations, the cell identifier is a cell global identifier (CGI). In other implementations, CN110 does not include the MBS area information (e.g., MBS service area IE) in the first CN to BS message.

[0086] After receiving 504 the first CN to BS message, CU-CP 172A sends 560 a first CP to UP message (e.g., an MC bearer context setup request message) to CU-UP 172B to request resources for the first MBS session. In some implementations, CU-CP 172A determines that one or more MRBs are configured for the first MBS session or MBS QoS flow 1, ..., M. In response to the determination, CU-CP 172A generates an MRB setup configuration to request resources for one or more MRBs. CU-CP 172A includes the first MBS session ID, MRB setup configuration, and / or the second MBS QoS flow configuration of the first MBS session in the first CP to UP message. In some implementations, the second MBS QoS flow configuration includes QoS parameters of the MBS QoS flow associated with the first MBS session. In some implementations, the QoS parameters include, for example, a 5G QoS identifier (5QI), a priority level, a packet delay budget, a packet error rate, an average window, and / or a maximum data burst.

[0087] In some implementations, the CU-CP 172A includes the second MBS QoS flow configuration (e.g., MBS QoS flow information to be set and / or MRB QoS IE, or QoS-Flow-QoS-Parameter-List and / or QoSFlowLevelQoSParameters IE) in an MRB setup configuration (e.g., MCMRBSetupConfigurationIE). In some implementations, the MRB setup configuration includes one or more MRB setup configuration items (e.g., MCMRBSetupConfiguration-Item IE). In some implementations, each of the MRB setup configuration items includes an MRB ID, an MRB configuration parameter (e.g., PDCP configuration and / or SDAP configuration), and / or a specific second MBS QoS flow configuration for a specific MRB in the second MBS QoS flow configuration. In some implementations, the PDCP configuration includes a UL PDCP sequence number size configuration, a DL PDCP sequence number size configuration, and / or an RLC mode configuration (e.g., acknowledged mode or unacknowledged mode). In some implementations, the SDAP configuration includes a default DRB configuration (eg, DefaultDRB IE), a SDAP UL header configuration (eg, SDAP-Header-UL), and / or a SDAP DL header configuration (eg, SDAP-Header-DL).

[0088] In some implementations, the second MBS QoS flow configuration includes the QoS parameters required for each of the MBS QoS flows associated with the MRB. In some implementations, the second MBS QoS flow configuration includes MBS QoS flow identifiers 1, ..., M and / or MBS QoS flow level QoS parameters 1, ..., M of the MBS QoS flows 1, ..., M associated with the first MBS session. The MBS QoS flow identifiers 1, ..., M identify the MBS QoS flows 1, ..., M. For example, the MRB setting configuration includes corresponding MRB setting configuration items 1, ..., N of MRBs 1, ..., N, where N is an integer and greater than zero. In some implementations, in the MRB setting configuration, the CU-CP 172A configures a mapping or association between the MBS QoS flows 1, ..., M and the MRBs 1, ..., N, where N is an integer and M≥N>0. In some implementations, the CU-CP 172A associates or maps a specific QoS flow to a specific MRB. In other words, CU-CP 172A avoids associating or mapping a specific QoS flow to two MRBs. In some implementations, for MRB X in MRB1, ..., N, the MRB setting configuration item X includes MRB ID X, PDCP configuration X, SDAP configuration X, and / or a specific MBS QoS flow configuration in the second MBS QoS flow configuration, where 1 ≤ X ≤ N.

[0089] Example 1 of MRB settings configuration:

[0090]

[0091] Example 2 of MRB setup configuration (i.e., SDAP-Configuration is omitted):

[0092]

[0093] In Example 2, the CU-CP 172A omits SDAP-Configuration from the MCMRBSetupConfiguration-Item.

[0094] In some implementations, the CU-CP 172A generates a second MBS QoS flow configuration based on the first MBS QoS flow configuration. For example, the second MBS QoS flow configuration is the same as the first MBS QoS flow configuration. In another example, the second MBS QoS flow configuration is similar to the first MBS QoS flow configuration.

[0095] In some cases where CU-CP 172A receives the first slice information from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the first slice information in the first CP to UP message to indicate that a specific network slice indicated by the first slice information is to be used for the first MBS session. In some cases where CU-CP 172A does not receive the slice information from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the preconfigured slice information in the first CP to UP message to indicate that a specific network slice is to be used for the first MBS session. Alternatively, in such cases, CU-CP 172A omits the slice information from the first CP to UP message to indicate that a default network slice is to be used for the first MBS session.

[0096] In some cases where CU-CP 172A receives the first MBS region information from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the first MBS region information in the first CP to UP message. In some cases where CU-CP 172A does not receive the first MBS region information from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the preconfigured MBS region information in the first CP to UP message. Alternatively, in such cases, CU-CP 172A omits the MBS region information from the first CP to UP message. In other cases where CU-CP 172A receives the first MBS region information from CN 110, CU-CP 172A retrieves the MBS region session ID from the first MBS region information and includes the MBS region session ID in the first CP to UP message. In some such cases, CU-CP 172A avoids including the MBS service area information IE in the first CP to UP message. In other cases where CU-CP 172A does not receive MBS region information from CN 110, CU-CP 172A includes the preconfigured MBS region session ID in the first CP to UP message. Alternatively, in such cases, CU-CP 172A omits the MBS region session ID from the first CP to UP message.

[0097] In response to the first CP to UP message, CU-UP 172B establishes or configures resources for the MRB and sends 562 a first UP to CP message (e.g., an MC bearer context setup response message). In some implementations, CU-UP 172B configures resources for each of the MRBs based on corresponding MRB configuration parameters and / or a specific configuration in the second MBS QoS flow configuration. In some implementations, CU-UP 172B configures resources for the MRB, MBS QoS flow, and / or the first MBS session based on the first slice information. In some implementations, CU-UP 172B establishes and / or configures one / multiple PDCP entities 1, ..., N according to PDCP configurations 1, ..., N for MRBs or MRB IDs 1, ..., N. In other implementations, for each of the PDCP configurations 1, ..., N, CU-UP 172B ignores or discards a portion of the PDCP configuration and establishes and / or configures the PDCP entity according to the remainder of the PDCP configuration. In one implementation, the CU-UP 172B ignores or discards the UL PDCP sequence number size configuration, and establishes and / or configures the PDCP entity according to the DL PDCP sequence number size configuration and / or the RLC mode. In another implementation, the CU-UP 172B ignores or discards the UL PDCP sequence number size configuration and the RLC mode, and establishes and / or configures the PDCP entity according to the DL PDCP sequence number size configuration.

[0098] In some implementations, CU-UP 172B establishes and / or configures one / multiple SDAP entities 1, ..., N according to SDAP configurations 1, ..., N for MRB or MRB ID 1, ..., N. In other implementations, for each of SDAP configurations 1, ..., N, CU-UP 172B ignores or discards a portion of the SDAP configuration, and establishes and / or configures the SDAP entity according to the rest of the SDAP configuration. In one implementation, CU-UP 172B ignores or discards the default DRB configuration and the SDAP UL header configuration, and establishes and / or configures the SDAP entity according to the SDAP DL header configuration. In another implementation, CU-UP 172B ignores or discards the default DRB configuration, and establishes and / or configures the SDAP entity according to the SDAP UL header configuration and the SDAP DL header configuration. In yet other implementations, the CU-UP 172B ignores or discards the entire SDAP configuration because the CU-UP 172B determines not to use SDAP to send the MBS data for the first MBS session.

[0099] In some implementations, CU-UP 172B includes a first CU transport layer configuration in the first UP to CP message to configure a common CN to BS DL tunnel for the first MBS session configuration. In some implementations, the first CU transport layer configuration includes a CU transport layer address (e.g., IP address and / or TEID) to identify the first common CN to BS DL tunnel. In other implementations, the first CU transport layer configuration is an MC bearer context NG-U TNL Info IE at NG-RAN. In some implementations, CU-CP 172A includes a first ID (e.g., CU-CP MBS E1AP ID) in the first CP to UP message to identify the first MBS session on the E1 interface between CU-CP 172A and CU-UP 172B. In some implementations, CU-UP 172B includes a first ID (e.g., CU-UP MBS E1AP ID) in the first UP to CP message to identify the first MBS session on the E1 interface between CU-CP 172A and CU-UP 172B. Depending on the implementation, the CU-UP 172B includes the first ID (eg, CU-CP MBS E1AP ID) in the first UP to CP message.

[0100] Events 560 and 562 in Figure 5A It is collectively referred to as the MC bearer context setting process.

[0101] After receiving 504 the first CN to BS message (e.g., in response to receiving 504 the first CN to BS message), the CU-CP 172A sends 506 a first CU to DU message (e.g., a multicast context setup request message) to the DU 174 to request setup of a multicast context and / or a common DL tunnel for the first MBS session. The CU-CP 172A determines that one or more MRBs are configured for the first MBS session or MBS QoS flows 1, ..., M. In response to the determination, the CU-CP 172A generates a configuration for the MRBs to be set to request resources for one or more MRBs. In some implementations, the first CU to DU message includes the first MBS session ID, the configuration for the MRBs to be set, and / or a third MBS QoS flow configuration for the first MBS session. In some implementations, the CU-CP 172A includes the first slice information in the first CU to DU message to indicate that a specific network slice indicated by the first slice information is to be used for the first MBS session. In some implementations, the configurations for the MRBs to be set include MRB IDs that each identify the MRB, and the DU 174 configures resources (e.g., PHY, MAC, and / or RLC resources) for the MRBs. The MRB IDs included in the first CU to DU message are the same as the MRB IDs included in the first CP to UP message. For example, the configurations for the MRBs to be set include the corresponding MRB IDs 1, ..., N of MRBs 1, ..., N. The third MBS QoS flow configuration includes QoS parameters required for the MBS QoS flows associated with the first MBS session. In some implementations, the third MBS QoS flow configuration includes MBS QoS flow identifiers 1, ..., M and / or MBS QoS flow level QoS parameters 1, ..., M of the MBS QoS flows 1, ..., M associated with the first MBS session. The MBS QoS flow identifiers 1, ..., M identify the MBS QoS flows 1, ..., M, respectively. In some implementations, in the configuration for the MRB to be set, the CU-CP 172A configures a mapping or association between the MBS QoS flow and the MRB. For example, the configuration for the MRB to be set includes corresponding setting configuration items 1, ..., N of MRB 1, ..., N. In some implementations, for MRB Y among MRB 1, ..., N, the setting configuration item Y includes MRB ID Y and a specific MBS QoS flow configuration in the third MBS QoS flow configuration, where 1 ≤ Y ≤ N. In some implementations, the CU-CP 172A generates a third MBS QoS flow configuration based on the first MBS QoS flow configuration. For example, the third MBS QoS flow configuration is the same as the first MBS QoS flow configuration. In another example, the third MBS QoS flow configuration is similar to the first MBS QoS flow configuration.In some implementations, the CU-CP 172A includes an ID (eg, CU MBS F1AP ID) in the first CU-to-DU message to identify the first MBS session on the F1 interface between the CU-CP 172A and the DU 174 .

[0102] In some cases where CU-CP 172A receives first slice information (e.g., S-NSSAI) associated with the first MBS session from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the first slice information in the first CU to DU message to indicate that a specific network slice is used for the first MBS session. In cases where CU-CP 172A does not receive slice information (e.g., S-NSSAI) associated with the first MBS session from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the preconfigured slice information in the first CU to DU message. Alternatively, in such cases, CU-CP 172A omits the slice information in the first CP to UP message.

[0103] In some cases where CU-CP 172A receives the first MBS region information from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the first MBS region information in the first CU to DU message. In some cases where CU-CP 172A does not receive the first MBS region information from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the preconfigured MBS region information in the first CU to DU message. Alternatively, in such cases, CU-CP 172A omits the MBS region information from the first CU to DU message. In other cases where CU-CP 172A receives the first MBS region information from CN 110, CU-CP 172A retrieves the MBS region session ID from the first MBS region information and includes the MBS region session ID in the first CU to DU message. In other cases where CU-CP 172A does not receive MBS region information from CN 110, CU-CP 172A includes the preconfigured MBS region session ID in the first CU-to-DU message. Alternatively, in such cases, CU-CP 172A omits the MBS region session ID from the first CU-to-DU message.

[0104] In response to receiving 506 the first CU-to-DU message, the DU 174 establishes or configures resources (e.g., multicast context and / or PHY, MAC, RLC, and / or tunnel resources) for the MRB and sends 508 a first DU-to-CU message (e.g., a multicast context setup response message) to the CU-CP 172A. In some implementations, the DU 174 establishes and / or configures a MAC entity for the MRB. In other implementations, the DU 174 establishes and / or configures one / multiple RLC entities 1, ..., N for the MRB or MRB IDs 1, ..., N, respectively. In some implementations, the DU 174 includes in the first DU-to-CU message a first DU transport layer configuration to configure a common CU-to-DU DL tunnel for the first MBS session (e.g., for the MRB identified by one of the MRB IDs). Depending on the implementation, DU 174 includes an additional DU transport layer configuration in the first DU to CU message to configure an additional common CU to DU DL tunnel for an additional MRB identified by an additional MRB ID in the MRB ID. In some implementations, DU174 includes an MRBID associated with the first DU transport layer configuration and / or the additional DU transport layer configuration in the first DU to CU message. For example, each of the MRB IDs is associated with a specific DU transport layer configuration. In some implementations, each of the first DU transport layer configuration and / or the additional DU transport layer configuration includes a DU transport layer address (e.g., an IP address and / or a TEID). In another implementation, each of the first DU transport layer configuration and / or the additional DU transport layer configuration is an MRBF1-U TNL Info IE at the DU.

[0105] Events 506 and 508 in Figure 5A In some implementations, the multicast context setup process and the MC bearer context setup process occur in parallel. In other implementations, the multicast context setup process occurs after the MC bearer context setup process, or vice versa.

[0106] In some implementations, DU 174 sends 510 a second DU-to-CU message (e.g., a multicast distribution setup request message) to CU-CP 172A after receiving 506 the first CU-to-DU message or sending 508 the first DU-to-CU message. In some implementations, DU 174 includes the first DU transport layer configuration and / or the additional DL transport layer configuration in the second DU-to-CU message instead of the first DU-to-CU message. In some implementations, DU 174 includes the MRB ID associated with the first DU transport layer configuration and / or the additional DU transport layer configuration in the second DU-to-CU message instead of the first DU-to-CU message. Therefore, the first DU-to-CU message does not include the DU transport layer configuration. In some implementations, CU-CP 172A sends 516 a second CU-to-DU message (e.g., a multicast distribution setup response message) to DU 174 in response to the second DU-to-CU message. Events 510 and 516 occur at Figure 5A are collectively referred to as the multicast distribution setup process.

[0107] After receiving 504 the first CN to BS message, receiving 562 the first UP to CP message, receiving 508 the first DU to CU message, or receiving 510 the second DU to CU message, CU-CP 172A sends 512 the first BS to CN message (e.g., a distribution setup request message) to CN 110. In some implementations, CU-CP 172A sends 512 the first BS to CN message to CN 110 before receiving 508 the first DU to CU message or receiving 510 the second DU to CU message. In another implementation, CU-CP 172A includes the first CU transport layer configuration in the first BS to CN message. Therefore, CN 110 sends MBS data to CU-UP 172B via the first public CN to BSDL tunnel, as described for event 532. In some implementations, CU-CP 172A includes the first MBS session ID in the first BS to CN message. In another implementation, CN 110 sends 514 a second CN to BS message (e.g., a distribution setup response message) to CU-CP 172A in response to the first BS to CN message. In some implementations, CN 110 includes the first CN transport layer configuration in the second CN to BS message. The first CN transport layer configuration includes at least one CN transport layer address (e.g., an IP address) to identify the first public CN to BS DL tunnel. In some implementations, at least one transport layer address includes an IP source address and / or an IP multicast address. In some implementations, the first CN transport layer configuration includes a TEID at / belonging to CN 110. In another implementation, CN 110 includes a fourth MBS QoS flow configuration for the first MBS session in the second CN to BS message. In some implementations, the fourth MBS QoS flow configuration is similar to the first MBS QoS flow configuration.

[0108] After receiving 514 the second CN to BS message, CU-CP 172A sends 564 a second CP to UP message (e.g., an MC bearer context modification request message) to CU-UP 172B. In some implementations, CU-CP 172A includes the MRB ID, the first DU transport layer configuration, the additional DU transport layer configuration, and / or the first CN transport layer configuration in the second CP to UP message. In response to the second CP to UP message of event 564, CU-UP 172B sends 566 a second UP to CP message (e.g., an MC bearer context modification response message). In some implementations, CU-UP 172B includes the MRB ID and / or the second CU transport layer configuration in the second UP to CP message. In some implementations, the second CU transport layer configuration includes a CU transport layer address (e.g., an IP address) for identifying the first common DU to CU UL tunnel. The second CU transport layer configuration additionally includes the TEID of CU-UP 172B. In another implementation, the CU-CP 172A includes the second CU transport layer configuration in the second CU to DU message and sends 516 the second CU to DU message to the DU 174 in response to the second DU to CU message of event 510. After receiving 566 the second UP to CP message or sending 516 the second CU to DU message, the CU-CP 172A sends 518 the second BS to CN message (e.g., a multicast session activation response message) to the CN 110 in response to the first CN to BS message. Alternatively, the CU-CP 172A sends 518 the second BS to CN message to the CN 110 before receiving 566 the second UP to CP message or sending 516 the second CU to DU message. For example, the CU-CP 172A sends 518 the second BS to CN message to the CN 110 after receiving 504 the first CN to BS message, receiving 562 the first UP to CP message, receiving 510 the second DU to CU message, or receiving 514 the second CN to BS message.

[0109] In some implementations, CU-CP 172A includes the fourth MBS QoS flow configuration in the MC bearer context modification request message. In some such implementations, CU-UP 172B modifies or reconfigures the resources for the MRB based on the fourth MBS QoS flow configuration. In some implementations, CU-UP 172B determines whether to modify or reconfigure the resources for the MRB based on the fourth MBS QoS flow configuration. For example, if the resources for the MRB at event 562 still meet the fourth MBS QoS flow configuration, CU-UP 172B does not modify or reconfigure the resources for the first MRB. Otherwise, CU-UP 172B modifies or reconfigures the resources for the MRB based on the fourth MBS QoS flow configuration. In some implementations, CU-UP 172B determines whether to modify or reconfigure the resources for a specific MRB among the MRBs based on the fourth MBS QoS flow configuration. For example, if the resources for the first MRB in the MRBs at event 562 still satisfy the specific configuration for the specific MBS QoS flow mapped to the first MRB in the fourth MBS QoS flow configuration, CU-UP 172B does not modify or reconfigure the resources for the first MRB. Otherwise, CU-UP 172B modifies or reconfigures the resources for the first MRB based on the specific MBS QoS flow configuration.

[0110] Events 504, 560, 562, 506, 508, 510, 512, 514, 564, 566, 516, and 518 are Figure 5A The above steps are collectively referred to as MBS session resource setup process 592A.

[0111] In some implementations, CN 110 sends 520 a third CN to BS message to CU-CP 172A indicating that UE 102 joins the first MBS session. In some implementations, CN 110 includes in the third CN to BS message a first MBS session ID and / or an MBS QoS flow identifier that respectively identifies the first MBS session and the MBS QoS flow associated with the first MBS session. In response to the third CN to BS message, CU-CP 172A sends 527 a third BS to CN message to CN 110. In some implementations, after receiving the third CN to BS message, CU-CP 172A sends 522 a UE context request message to DU 174 for UE 102. In some implementations, CU-CP 172A includes the MRB ID in the UE context request message. In another implementation, CU-CP 172A determines the MRB ID based on the first MBS session ID and / or the MBS QoS flow identifier received in the third CN to BS message. In some implementations, the CU-CP 172A does not include the first MBS session ID in the UE context request message.

[0112] In response to the UE context request message of event 522, DU 174 sends 524 to CU-CP 172A a UE context response message including multicast configuration parameters for UE 102A to receive MBS data of the first MBS session via MRB. In some implementations, some or all of the multicast configuration parameters may be associated with MRB / MRB ID. In some implementations, DU 174 generates a DU configuration (i.e., a first DU configuration) to include multicast configuration parameters (i.e., first multicast configuration parameters), and includes the DU configuration in the UE context response message. In some implementations, the DU configuration is a CellGroupConfig IE. In other implementations, the DU configuration is an MBS-specific IE. In some implementations, the multicast configuration parameters configure one or more logical channels (LCs) for the MRB. For example, the multicast configuration parameters include one or more logical channel IDs (LCIDs) for configuring logical channels. Each of the LCIDs identifies a specific logical channel in one or more logical channels. In some implementations, the third CN to BS message and the third BS to CN message are a PDU session resource modification request message and a PDU session resource modification response message, respectively. In other implementations, the third CN to BS message and the third BS to CN message are a PDU session resource setup request message and a PDU session resource setup response message, respectively. In some implementations, the third CN to BS message and the third BS to CN message are UE associated messages (e.g., the messages are associated with a specific UE 102).

[0113] In some implementations, the UE context request message and the UE context response message are respectively a UE context setup request message and a UE context setup response message. In other implementations, the UE context request message and the UE context response message are respectively a UE context modification request message and a UE context modification response message.

[0114] In some implementations, CU-CP 172A performs a bearer context procedure (e.g., a UE-specific bearer context procedure) with CU-UP 172B after receiving the third CN to BS message. In the bearer context procedure, CU-CP 172A sends a bearer context request message to CU-UP 172B to request to establish or modify a bearer context (e.g., a unicast bearer context) for UE 102. In response, CU-UP 172B establishes or modifies the bearer context for UE 102 and sends a bearer context response message to CU-CP 172A. In other implementations, CU-CP 172A avoids performing a bearer context procedure for UE 102 with CU-UP 172B upon receiving the third CN to BS message. In some implementations, the bearer context procedure is a bearer context setup procedure (e.g., as defined in Section 8.3.1 in 3GPP specifications 37.483 or 38.463). In some such cases, the bearer context request message and the bearer context setup message are a bearer context setup request message and a bearer context setup response message, respectively. In other implementations, the bearer context procedure is a bearer context modification procedure (e.g., as defined in Section 8.3.2 of 3GPP specifications 37.483 or 38.463). In some such cases, the bearer context request message and the bearer context setup message are a bearer context modification request message and a bearer context modification response message, respectively.

[0115] After receiving 524 the UE context response message, the CU-CP 172A generates an RRC reconfiguration message (e.g., an RRCReconfiguration message) including multicast configuration parameters and one or more MRB configurations (e.g., a first MRB configuration), and sends 526 the RRC reconfiguration message to the DU 174. The first MRB configuration configures the MRBs (e.g., MRB 1, ..., N). In some implementations, the first MRB configuration includes an MRB ID and a PDCP configuration. In turn, the DU 174 sends 528 the RRC reconfiguration message to the UE 102 operating in the connected state. Then, the UE 102 in the connected state sends 530 an RRC reconfiguration complete message to the DU 174, which in turn sends 531 an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the CU-CP 172A.

[0116] In some implementations, the UE 102 configures or establishes one / multiple PDCP entities (e.g., NRPDCP 210) for MRB and configures a MAC entity (e.g., MAC 204B) according to the multicast configuration parameters.

[0117] Events 520, 522, 524, 526, 527 (discussed below), 528, 530, and 531 are Figure 5A 594. CN 110 and / or CU-CP 172A performs process 594 for each of the UEs (e.g., UE 102A and UE 102B) that join the first MBS session. In some scenarios or implementations, process 594 occurs before process 592A. In other scenarios or implementations, process 594 occurs after process 592A. In still other scenarios or implementations, process 594 overlaps with process 592A.

[0118] In some implementations, the CU-CP 172A generates a PDCP PDU including an RRC reconfiguration message and sends 526 a CU-to-DU message including the PDCP PDU to the DU 174. In such implementations, the DU 174 retrieves the PDCP PDU from the CU-to-DU message and sends 528 the PDCP PDU to the UE 102 via the RLC layer 206B, the MAC layer 204B, and the PHY layer 202B. The UE 102 receives 528 the PDCP PDU from the DU 174 via the PHY layer 202B, the MAC layer 204B, and the RLC layer 206B. In some implementations, the UE 102 generates a PDCP PDU including an RRC reconfiguration complete message and sends 530 the PDCP PDU to the DU 174 via the RLC layer 206B, the MAC layer 204B, and the PHY layer 202B. DU 174 receives 530 PDCP PDU from UE 102 via PHY layer 202B, MAC layer 204B, and RLC layer 206B, and sends 531 a DU to CU message including the PDCP PDU to CU-CP 172A. CU-CP 172A retrieves the PDCP PDU from the DU to CU message, and retrieves the RRC reconfiguration complete message from the PDCP PDU.

[0119] In some implementations, before or after receiving 524 the UE context response message, the CU-CP 172A sends 527 a third BS to CN message to the CN 110 in response to the third CN to BS message 520. In some implementations, the CU-CP 172A sends 527 the third BS to CN message to the CN 110 before receiving 531 the RRC reconfiguration complete message. In other implementations, the CN 110 sends 527 the third BS to CN message to the CN 110 after receiving 531 the RRC reconfiguration complete message. Depending on the implementation, the CU-CP 172A includes the first CN UE interface ID and the first RAN UE interface ID in the third BS to CN message. In some implementations, the CN 110 assigns a first CN UE interface ID that identifies the UE 102 (e.g., UE 102A), and the CU-CP 172A assigns a first RAN UE interface ID that identifies the UE 102 (e.g., UE 102A). In some implementations, the “CN UE interface ID” is the “AMF UE NGAP ID” and the “RAN UE interface ID” is the “RAN UE NGAP ID”.

[0120] After receiving 518 the second BS-to-CN message or receiving 527 the third BS-to-CN message, the CN 110 (e.g., (MB-)UPF 162) sends 532 MBS data (e.g., one or more MBS data packets) for the first MBS session to the CU-UP 172B via the first common CN-to-BS DL tunnel (e.g., according to the first CU transport layer configuration and / or the first CN transport layer configuration). In some implementations, the CN 110 generates tunnel packets that each include a specific MBS data packet to send the MBS data packets via the first common CN-to-BS DL tunnel. In a header of each of the tunnel packets, the CN 110 sets the source IP address, the target IP address, and the TEID to the IP address in the first CN transport layer configuration, the IP address in the first CU transport layer configuration, and the TEID in the first CU transport layer configuration, respectively. In such implementations, the IP address in the first CN transport layer configuration, the IP address in the first CU transport layer configuration, and the TEID in the first CU transport layer configuration identify the first common CN-to-BSDL tunnel.

[0121] When CU-UP 172B receives 532 MBS data for the first MBS session from CN 110, CU-UP 172B in turn sends 534 the MBS data to DU 174 via the first common CU-to-DU tunnel and / or the additional common CU-to-DU DL tunnel (i.e., according to the first DU transport layer configuration and / or the additional DU transport layer configuration). In some cases where the MBS data is associated with some of the MBS QoS flows identified by the MBS QoS flow identifiers, CU-UP 172B determines which common CU-to-DU DL tunnel(s) to use to send the MBS data to DU 174 based on the MBS QoS flow identifiers. For example, when CU-UP 172B receives a first MBS data packet associated with a first MBS QoS flow identifier among the MBS QoS flow identifiers from CN 110, CU-UP 172B sends the first MBS data packet to DU 174 via the first common CU-to-DU DL tunnel. When CU-UP 172B receives a second MBS data packet associated with a second MBS QoS flow identifier in the MBS QoS flow identifier from CN 110, CU-UP 172B sends the second MBS data packet to DU 174 via one of the additional common CU-to-DU tunnels. In some implementations, CU-UP 172B generates tunnel packets, each of which includes a specific MBS data packet to send the MBS data packet via the first common CU-to-DU tunnel and / or the additional common CU-to-DU DL tunnel. In the case where CU-UP 172B sends one of the tunnel packets via the first common CU-to-DU tunnel, CU-UP 172B sets the source IP address, the destination IP address, and the TEID in the header of the tunnel packet to the IP address in the second CU transport layer configuration, the IP address in the first DU transport layer configuration, and the TEID in the first DU transport layer configuration, respectively. In such implementations, the IP address in the second CU transport layer configuration, the IP address in the first DU transport layer configuration, and the TEID in the first DU transport layer configuration identify the first common CU-to-DU DL tunnel. In the case where CU-UP 172B sends one of the tunnel packets via an additional common CU-to-DU tunnel, CU-UP 172B sets the source IP address, the destination IP address, and the TEID in the header of the tunnel packet to the IP address in the second CU transport layer configuration, the IP address in the additional DU transport layer configuration, and the TEID in the additional DU transport layer configuration, respectively. In such an implementation, the IP address in the second CU transport layer configuration, the IP address in the additional DU transport layer configuration, and the TEID in the additional DU transport layer configuration identify the first common CU-to-DU DL tunnel.

[0122] When the DU 174 receives 534 the MBS data from the CU-UP 172B, the DU 174 sends (e.g., multicast or unicast) 536 the MBS data to the UE 102 via one or more logical channels. The UE 102 receives 536 the MBS data via one or more logical channels. For example, the CU-UP 172B receives 532 the MBS data packet, generates a PDCP PDU including the MBS data packet, and sends 534 the PDCP PDU to the DU 174. In turn, the DU 174 generates a MAC PDU including the logical channel ID and the PDCP PDU, and sends 536 the MAC PDU to the UE 102 via multicast or unicast. The UE 102 receives 536 the MAC PDU via multicast or unicast, retrieves the PDCP PDU and the logical channel ID from the MAC PDU, identifies the PDCP PDU associated with the MRB based on the logical channel ID, and retrieves the MBS data packet from the PDCP PDU based on the PDCP configuration within the MRB configuration. In some implementations, the DU 174 transmits 536 MBS data or MAC PDUs to the UE 102 via one or more multicast transmissions (e.g., dynamic or SPS multicast transmissions), as described above. In some such cases, the UE 102 receives 536 MBS data or MAC PDUs from the DU 174 via one or more multicast transmissions, as described above. In some implementations, the UE 102 receives 536 MAC PDUs or MBS data using a MAC entity and processes the PDCP PDUs using one or more PDCP entities to obtain MBS data.

[0123] In some implementations, CU-CP 172A requests DU 174 to configure a UE-specific CU to DU DL tunnel for UE 102 in a UE context request message of event 522. In some implementations, CU-CP 172A includes a CU transport layer configuration in the UE context request message to request a UE-specific CU to DU DL tunnel for UE 102. The CU transport layer configuration includes a CU transport layer address (e.g., an IP address) for identifying the UE-specific CU to DU DL tunnel. In some implementations, the CU transport layer configuration additionally includes the TEID of CU-UP 172B. In response, DU 174 includes a DU transport layer configuration for configuring a UE-specific CU to DU DL tunnel in a UE context response message. The DU transport layer configuration includes a DU transport layer address (e.g., an IP address and / or TEID). In some implementations, after receiving 524 the UE context response message, CU-CP 172A sends a bearer context modification request message including the DU transport layer configuration to CU-UP 172B, and in response, CU-UP 172B sends a bearer context modification response message to CU-CP 172A. In other implementations, CU-UP 172B then sends 534 MBS data to DU 174 via a UE-specific CU-to-DU DL tunnel.

[0124] In some implementations, the multicast configuration parameters also include one or more RLC bearer configurations, each of which is associated with a specific MRB. Each of the MRB configurations includes an MRB ID, a PDCP configuration, a first MBS session ID, a PDCP reestablishment indication (e.g., reestablishPDCP) and / or a PDCP recovery indication (e.g., recoveryPDCP). In some implementations, the PDCP configuration is a PDCP-Config IE for DRB. In other implementations, the RLC bearer configuration is an RLC-BearerConfig IE. In some implementations, the RLC bearer configuration includes a logical channel ID for configuring a logical channel (LC). In some implementations, the logical channel is an MBS traffic channel (MTCH). In other implementations, the logical channel is a dedicated traffic channel (DTCH). In some implementations, the multicast configuration parameters include a logical channel configuration (e.g., LogicalChannelConfig IE) for configuring a logical channel. In some implementations, the RLC bearer configuration includes an MRB ID.

[0125] In some implementations, CU-CP 172A configures the MRB as a DL-only RB in the MRB configuration. For example, CU-CP 172A avoids including UL configuration parameters in the PDCP configuration within the MRB configuration to configure the MRB as a DL-only RB. CU-CP 172A includes only DL configuration parameters in the MRB configuration (e.g., as described above). In such cases, CU-CP 172A configures UE 102 to not send UL PDCP data PDUs to DU 174 and / or CU-CP 172A via MRB by excluding UL configuration parameters for MRB in the PDCP configuration in the MRB configuration. In another example, DU 174 avoids including UL configuration parameters in the RLC bearer configuration. In such cases, DU 174 configures UE 102 to not send control PDUs to base station 104 via logical channels by excluding UL configuration parameters from the RLC bearer configuration.

[0126] In the case where DU 174 includes UL configuration parameters in the RLC bearer configuration, UE 102 sends a control PDU (e.g., a PDCP control PDU and / or an RLC control PDU) to DU 174 via a logical channel using the UL configuration parameters. In some implementations, if the control PDU is a PDCP control PDU, DU 174 sends the PDCP control PDU to CU-UP 172B. For example, CU-CP 172A configures UE 102 to receive MBS data using a compression or decompression protocol (e.g., a robust header compression (ROHC) protocol). In such a case, when CU-UP 172B receives 532 MBS data packets from CN 110, CU-UP 172B compresses the MBS data packets using a compression protocol to obtain compressed MBS data packets, and sends 534 a PDCP PDU including the compressed MBS data packets to DU 174 via the first common CU to DU DL tunnel or the additional common CU to DU DL tunnel. In turn, DU 174 sends (e.g., multicast or unicast) 536 the PDCP PDU to UE 102 via the logical channel. When UE 102 receives the PDCP PDU via the logical channel, UE 102 retrieves the compressed MBS data packet from the PDCP PDU. UE 102 decompresses the compressed MBS data packet using a compression or decompression protocol to obtain the original MBS data packet. In some such cases, UE 102 sends a PDCP control PDU to DU 174 via the logical channel, and the PDCP control PDU includes header compression protocol feedback (e.g., interspersed ROHC feedback) for the operation of the header compression or decompression protocol. In turn, DU 174 sends the PDCP control PDU to CU-UP 172B via the UL tunnel. In some implementations, the UL tunnel is a first common DU to CU tunnel configured in the first DU transport layer configuration and the second CU transport layer configuration. For example, an IP address in the first DU transport layer configuration and an IP address and TEID in the second CU transport layer configuration identify the first common DU to CU tunnel. In other implementations, the UL tunnel is specific to the UE 102. In some implementations, the CU-CP 172A includes a CU transport layer configuration that configures the UE-specific UL tunnel in the UE context request message. The CU transport layer configuration includes a CU transport layer address (e.g., an Internet Protocol (IP) address) and a TEID to identify the UE-specific UL tunnel. The DU 174 includes a DU transport layer configuration that configures the UE-specific UL tunnel in the UE context response message. The DU transport layer configuration includes a DU transport layer address (e.g., an IP address and / or a TEID). For example, the IP address in the DU transport layer configuration and the IP address and TEID in the CU transport layer configuration identify the first common UL tunnel.

[0127] In some implementations, the MRB configuration is an MRB-ToAddMod IE including an MRB ID (e.g., mrb-Identity or MRB-Identity). The MRB ID identifies a specific MRB in the MRB. In some cases where the CU-CP 172A has configured the DRB to the UE 102 for unicast data communication, the CU-CP 172A sets one or more of the MRB IDs to a value different from the DRB ID of the DRB. In some such cases, the UE 102 and the CU-CP 172A distinguish whether the RB is an MRB or a DRB based on the RB ID of the RB. In other implementations, the CU-CP sets one or more of the MRB IDs to the same value as the DRB ID. In some such cases, the UE 102 and the CU-CP 172A distinguish whether the RB is an MRB or a DRB based on the RB ID of the RB and the RRC IE that configures the RB. For example, the DRB configuration that configures the DRB is a DRB-ToAddMod IE that includes a DRB identity (e.g., drb-Identity or DRB-Identity) and a PDCP configuration. Therefore, in some such implementations, if the UE 102 receives the DRB-ToAddMod IE that configures the RB, the UE 102 determines that the RB is a DRB, and if the UE 102 receives the MRB-ToAddMod IE that configures the RB, the UE 102 determines that the RB is an MRB. Similarly, if the CU-CP 172A sends the DRB-ToAddMod IE that configures the RB to the UE 102, the CU-CP 172A determines that the RB is a DRB, and if the CU-CP 172A sends the MRB-ToAddMod IE that configures the RB to the UE 102, it determines that the RB is an MRB.

[0128] In some implementations, the multicast configuration parameters for receiving MBS data of the first MBS session include one or more logical channel IDs for configuring one or more logical channels (LCs). In some implementations, the logical channel is a dedicated traffic channel (DTCH). In other implementations, the logical channel is a multicast traffic channel (MTCH).

[0129] In some implementations, the multicast configuration parameters include dynamically scheduled multicast configuration parameters for UE 102 to receive multicast transmissions, each of which includes MBS data or a specific portion of MBS data. In some implementations, the dynamically scheduled multicast configuration parameters include at least one of the following configuration parameters. The first example parameter is a group radio network temporary identifier (G-RNTI), for which DU 174 dynamically schedules each multicast transmission including a specific MAC PDU for UE 102 by generating a DCI, scrambling a cyclic redundancy check (CRC) of the DCI with the G-RNTI, and sending the DCI and the scrambled CRC on the PDCCH. In some implementations, the MAC PDU includes an MBS data packet or a portion of an MBS data packet. UE 102 receives the DCI and the scrambled CRC on the PDCCH and verifies the scrambled CRC with the G-RNTI. For each multicast transmission, after UE 102 verifies that the CRC is valid, UE 102 receives the multicast transmission according to the corresponding DCI and retrieves a specific MAC PDU from the multicast transmission. In such cases, each multicast transmission is a dynamically scheduled multicast transmission used in the following description. In some implementations, each DCI includes configuration parameters for configuring dynamically scheduled multicast radio resources that schedule the corresponding multicast transmission. In some implementations, the configuration parameters include at least one of the following parameters. The configuration parameters of each DCI include the same value and / or different values ​​of the following configuration parameters: (i) frequency domain resource assignment; (ii) time domain resource assignment; (iii) virtual resource block (VRB) to physical resource block (PRB) mapping; (iv) modulation and coding scheme (MCS); (v) new data indicator; (vi) redundancy version; (vii) HARQ process number; (viii) downlink assignment index; and / or (ix) PUCCH resource indicator. Another example parameter is a HARQ codebook (ID), which indicates a HARQ acknowledgment (ACK) codebook index of a corresponding HARQ ACK codebook for a dynamically scheduled multicast transmission received by UE 102. DU 174 uses the HARQ codebook (ID) to receive the HARQ ACK. In some cases where the configuration parameters do not include the HARQ codebook (ID), UE 102 and DU 174 use the HARQ codebook (ID) for unicast transmission. In some implementations, UE 102 receives the HARQ codebook (ID) for unicast transmission in the DU configuration from DU 174. In other implementations, UE 102 receives the HARQ codebook (ID) for unicast transmission in another DU configuration from DU 174, similar to events 516, 518, and 520.Another example parameter is a PUCCH resource configuration that indicates a HARQ resource on a PUCCH in which the UE 102 sends HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for a dynamically scheduled multicast transmission. In some cases in which the configuration parameters do not include a PUCCH resource configuration, the UE 102 and the DU 174 communicate the HARQ feedback using the PUCCH resource configuration for unicast transmissions. Another example parameter is a HARQ NACK-only indication that configures the UE 102 to send only a HARQ negative ACK (NACK) for a dynamically scheduled multicast transmission that the UE 102 receives from the DU 174 and from which the UE 102 fails to obtain a transport block. In some implementations, the UE 102 fails to obtain a transport block because the UE 102 fails to pass a cyclic redundancy check (CRC) for the transport block, or the UE 102 does not receive the dynamically scheduled multicast transmission. According to the indication, for the dynamically scheduled multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block, the UE 102 refrains from sending HARQ ACKs to the DU 174. In some cases where the configuration parameter does not include the indication, for the dynamically scheduled multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block, the UE 102 sends HARQ ACKs to the DU 174. Another example parameter is a HARQ ACK / NACK indication that configures the UE 102 to send HARQ NACKs for dynamically scheduled multicast transmissions in which the UE 102 fails to obtain a transport block, and configures the UE 102 to send HARQ ACKs for dynamically scheduled multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block. In cases where the configuration parameters do not include the indication, the UE 102 refrains from sending HARQ ACKs to the DUs 174 for dynamically scheduled multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block. In some such cases, the UE 102 only sends HARQ NACKs to the DUs 174 for dynamically scheduled multicast transmissions for which the UE 102 fails to obtain a transport block. Another example parameter is a HARQ ACK indication that configures the UE 102 to send HARQ ACKs for dynamically scheduled multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block. In cases where the configuration parameters do not include the indication, the UE 102 refrains from sending HARQ ACKs to the DUs 174 for dynamically scheduled multicast transmissions for which the UE 102 successfully obtains a transport block.In such cases, for dynamically scheduled multicast transmissions in which UE 102 fails to obtain a transport block, UE 102 only sends a HARQ NACK to DU 174. In some implementations, DU 174 includes any of a HARQ NACK indication, a HARQ ACK / NACK indication, and / or a HARQ ACK indication. Another example parameter is a modulation and coding scheme (MCS) configuration that indicates an MCS table used by DU 174 to send dynamically scheduled multicast transmissions and by UE 102 to receive dynamically scheduled multicast transmissions. For example, the MCS table is a specific MCS table (e.g., as defined in 3GPP specification 38.214 (e.g., a low SE 64QAM table indicated in Table 5.1.3.1-3 of 3GPP TS 38.214, or a new table specific to multicast transmissions)). In some implementations, if the DU 174 does not include the MCS configuration in the DU configuration, the UE 102 and the DU 174 apply a predefined MCS table (e.g., as defined in 3GPP specification 38.214). For example, the predefined MCS table is a 256QAM table or a 64QAM table (e.g., as indicated in Table 5.1.3.1-2 of specification 38.214, or a non-low SE 64QAM table as indicated in Table 5.1.3.1-1, respectively). In the case where the DU 174 does not include the MCS configuration in the DU configuration, the UE 102 and the DU 174 apply the MCS table for unicast transmissions to receive dynamically scheduled multicast transmissions from the DU 174. In some implementations, the DU 174 includes a PDSCH configuration (e.g., a PDSCH-Config IE) in the DU configuration that configures the MCS table for unicast transmissions. In other implementations, DU 174 sends another DU configuration including the PDSCH configuration to UE 102, similar to events 516, 518, and 520. Another example parameter is an aggregation factor, which is the number of repetitions of the dynamically scheduled multicast transmission. In some implementations, DU 174 sends (e.g., multicasts) multiple repetitions of the dynamically scheduled multicast transmission according to the aggregation factor, and UE 102 receives the repetitions based on the aggregation factor. In some cases where DU 174 does not include the aggregation factor in the DU configuration, in some implementations, UE 102 applies the aggregation factor for unicast transmission. In some implementations, DU 174 includes the aggregation factor for unicast transmission to UE 102 in the DU configuration. In other implementations, DU 174 sends another DU configuration including the aggregation factor for unicast transmission to UE 102, similar to events 516, 518, and 520.

[0130] The RRC reconfiguration message for the UE joining the first MBS session includes the same multicast configuration parameters for receiving MBS data for the first MBS session.In some implementations, the RRC reconfiguration message for the UE includes the same or different configuration parameters for receiving non-MBS data.

[0131] In some implementations, the multicast configuration parameters include at least one semi-persistent scheduling (SPS) multicast configuration for UE 102 to receive MBS data. Depending on the implementation, each of the SPS multicast configurations includes at least one of the following parameters for SPS multicast transmission. The example first parameter is a group configuration scheduling radio network temporary identifier (G-CS-RNTI), which is used to activate or release SPS multicast radio resources. In some implementations, DU 174 activates SPS multicast radio resources for UE 102 by generating an SPS multicast radio resource activation command (e.g., DCI), scrambling the CRC of the DCI with G-CS-RNTI, and sending the DCI and the scrambled CRC on the PDCCH. After activating the SPS multicast radio resources, DU 174 periodically sends multicast transmissions on the SPS multicast radio resources according to the DCI. UE 102 receives the DCI and the scrambled CRC on the PDCCH and verifies the scrambled CRC with the G-CS-RNTI. After UE 102 verifies that CRC is valid, UE 102 activates SPS multicast radio resources in response to DCI (e.g., starts receiving on SPS multicast radio resources), and periodically receives multicast transmission on SPS multicast radio resources according to SPS multicast radio resource activation command (e.g., DCI) before UE 102 deactivates SPS multicast radio resources. In such cases, multicast transmission is SPS multicast transmission used in the following description. In some implementations, DU 174 deactivates or releases SPS multicast radio resources by generating SPS multicast radio resource deactivation command (e.g., DCI), scrambling CRC of DCI with G-CS-RNTI, and sending DCI and scrambled CRC on PDCCH. UE 102 receives DCI and scrambled CRC on PDCCH and verifies scrambled CRC with G-CS-RNTI. After UE 102 verifies that CRC is valid, UE 102 deactivates SPS multicast radio resources (e.g., stops receiving on SPS multicast radio resources). Depending on the implementation, each of the SPS multicast transmissions includes a specific MAC PDU that includes an MBS data packet or a portion of an MBS data packet. In some implementations, the SPS multicast radio resource activation command (e.g., DCI) includes configuration parameters that configure the SPS multicast radio resources. In some implementations, the configuration parameters include at least one of the following parameters: (i) frequency domain resource assignment; (ii) time domain resource assignment; (iii) virtual resource block (VRB) to physical resource block (PRB) mapping; (iv) modulation and coding scheme (MCS); (v) new data indicator; (vi) redundancy version; (vii) HARQ process number; (viii) downlink assignment index; and / or (ix) PUCCH resource indicator.Another example parameter is periodicity, which indicates the periodicity of the SPS multicast radio resources.

[0132] Another example parameter is the number of the HARQ process, which indicates the number of HARQ processes used to communicate the SPS multicast transmission. DU 174 uses at most the number of HARQ processes to send the SPS multicast transmission, and UE 102 uses at most the number of HARQ processes to receive the SPS multicast transmission. Another example parameter is a HARQ codebook ID, which indicates the HARQ ACK codebook index of the corresponding HARQ ACK codebook for the SPS multicast transmission or SPS multicast radio resource deactivation command received by UE 102. In some cases where the configuration parameters do not include the HARQ codebook (ID), UE 102 uses the HARQ codebook (ID) for dynamically scheduled multicast transmission, as described above. Alternatively, UE 102 uses the HARQ codebook (ID) for unicast transmission. In some implementations, UE 102 receives the HARQ codebook (ID) for unicast transmission in the DU configuration from DU 174, as described above. Another example parameter is a HARQ process ID offset, which indicates an offset used when deriving a HARQ process ID for DU 174 to send SPS multicast transmissions and for UE 102 to receive SPS multicast transmissions. Another example parameter is a PUCCH resource configuration for SPS multicast transmissions, which indicates a HARQ resource on a PUCCH where UE 102 sends HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for SPS multicast transmissions. In some cases where the configuration parameters do not include a PUCCH resource configuration for SPS multicast transmissions, UE 102 and DU 174 communicate HARQ feedback using a PUCCH resource configuration for dynamically scheduled multicast transmissions, as described above. Alternatively, UE 102 uses a PUCCH resource configuration for unicast transmissions. In some implementations, UE 102 uses a PUCCH resource configuration for unicast transmissions, as described above. Another example parameter is a HARQ NACK-only indication that configures the UE 102 to send only a HARQ negative ACK (NACK) for SPS multicast transmissions that the UE 102 receives from the DU 174 and from which the UE 102 fails to obtain a transport block. In some implementations, the UE 102 fails to obtain a transport block because the UE 102 fails a cyclic redundancy check (CRC) for the transport block or the UE 102 does not receive the dynamically scheduled multicast transmission. Based on the indication, the UE 102 avoids sending a HARQ ACK to the DU 174 for SPS multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block.In some cases where the configuration parameters do not include the indication, for SPS multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block, the UE 102 sends a HARQ ACK to the DU 174. Another example parameter is a HARQ ACK / NACK indication that configures the UE 102 to send a HARQ NACK for SPS multicast transmissions in which the UE 102 fails to obtain a transport block, and configures the UE 102 to send a HARQ ACK for SPS multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block. In cases where the configuration parameters do not include the indication, the UE 102 refrains from sending a HARQ ACK to the DU 174 for SPS multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block. In such cases, the UE 102 only sends a HARQ NACK to the DU 174 for SPS multicast transmissions in which the UE 102 fails to obtain a transport block. Another example parameter is a HARQ ACK indication that configures the UE 102 to send a HARQ ACK for an SPS multicast transmission that the UE 102 successfully receives and from which the UE 102 obtains a transport block. In the case where the configuration parameter does not include the indication, the UE 102 avoids sending a HARQ ACK to the DU 174 for an SPS multicast transmission in which the UE 102 successfully obtains a transport block. In such a case, the UE 102 only sends a HARQ NACK to the DU 174 for an SPS multicast transmission in which the UE 102 fails to obtain a transport block. In some implementations, the DU 174 includes any one of a HARQ NACK indication, a HARQ ACK / NACK indication, and / or a HARQ ACK indication. Another example parameter is an aggregation factor, which is the number of repetitions of the SPS multicast transmission. The DU 174 sends multiple repetitions of the SPS multicast transmission according to the aggregation factor, and the UE 102 receives the repetitions based on the aggregation factor. In some cases where the DU 174 does not include the aggregation factor in the DU configuration, the UE 102 and DU 174 apply the aggregation factor for dynamically scheduled multicast transmissions, as described above. Alternatively, the UE 102 and DU 174 apply the aggregation factor for unicast transmissions. In some implementations, the UE 102 and DU 174 apply the aggregation factor for unicast transmissions, as described above. Another example parameter is the MCS configuration, which indicates the MCS table used by the DU 174 to send SPS multicast transmissions and the UE 102 to receive SPS multicast transmissions.For example, the MCS table is a specific MCS table (e.g., as defined in 3GPP specification 38.214 (e.g., a low SE 64QAM table indicated in Table 5.1.3.1-3 of 3GPP TS 38.214, or a new table specific to multicast transmission). In some implementations, if DU 174 does not include the MCS configuration in the DU configuration, UE 102 and DU 174 apply a predefined MCS table (e.g., as defined in 3GPP specification 38.214). For example, the predefined MCS table is a 256QAM table or a 64QAM table (e.g., as indicated in Table 5.1.3.1-2 of specification 38.214, or a non-low SE 64QAM table indicated in Table 5.1.3.1-1, respectively). In some cases where DU 174 does not include the MCS configuration in the DU configuration, in other implementations, UE 102 and DU 174 apply the MCS table for dynamically scheduled multicast transmissions to receive SPS multicast transmissions from DU 174, as described above. Alternatively, UE 102 and DU 174 apply the MCS table for unicast transmissions to receive SPS multicast transmissions from DU 174. In some implementations, UE 102 and DU 174 apply the MCS table for unicast transmissions to receive SPS multicast transmissions from DU 174, as described above. In some implementations, DU 174 includes a PDSCH configuration (e.g., PDSCH-Config IE) in the DU configuration that configures the MCS table for unicast transmissions. In other implementations, DU 174 sends another DU configuration including the PDSCH configuration to UE 102, similar to events 516, 518, and 520.

[0133] In some implementations, CU-CP 172A includes the MBS session join response message in the RRC reconfiguration message. In another implementation, UE 102 includes the MBS session join completion message in the RRC reconfiguration completion message. Alternatively, UE 102 sends a UL RRC message including the MBS session join completion message to CU-CP 172A via DU 174. Depending on the implementation, the UL RRC message is a ULInformationTransfer message or any suitable RRC message that may include a UL NAS PDU. In some implementations, CU-CP 172A includes the MBS session join completion message in a second BS to CN message. Alternatively, CU-CP 172A sends a BS to CN message (e.g., an uplink NAS transfer message) including the MBS session join completion message to CN 110.

[0134] In other implementations, CU-CP 172A sends a DL RRC message including an MBS session join response message to UE 102. Depending on the implementation, the DL RRC message is a DL Information Transfer message, another RRC reconfiguration message, or any suitable RRC message that may include a DL NAS PDU. In some implementations, UE 102 sends a UL RRC message including an MBS session join complete message to CU-CP 172A via DU 174. In other implementations, the UL RRC message is a UL Information Transfer message, another RRC reconfiguration complete message, or any suitable RRC message that may include a UL NAS PDU.

[0135] Events 532, 534, and 536 are Figure 5A The above processes are collectively referred to as MBS session data transmission process 596.

[0136] In some cases where CU-CP 172A does not receive slice information from CN 110, CU-CP 172A includes the pre-configured slice information in the first CP to UP message of event 560. In some cases where CU-CP 172A does not receive slice information from CN 110, CU-CP 172A includes the pre-configured slice information in the first CU to DU message of event 506.

[0137] Figure 5B Shown with Figure 5A Example scenario 500B similar to scenario 500A is shown. In scenario 500B, CN 110 includes the first MBS QoS flow configuration in the second CN to BS message at event 514. In some such cases, CN 110 does not include the first MBS QoS flow configuration in the first CN to BS message. After receiving the second CN to BS message, CU-CP 172A sends 560 a first CP to UP message and 506 a first CU to DU message to CU-UP 172B and DU 174, respectively. In other words, CU-CP 172A delays sending the first CP to UP message and the first CU to DU message (e.g., delays performing the MC bearer context setup procedure and the multicast context setup procedure) until the first MBS QoS flow configuration or the second CN to BS message is received.

[0138] Events 502, 512, 514, 560, 562, 506, 508, 510, 564, 566, 516, and 518 are Figure 5B The above steps are collectively referred to as MBS session resource setup process 592B.

[0139] In some implementations, CN 110 includes the first slice information in the second CN to BS message at event 514. In some such cases, CN 110 does not include the first slice information in the first CN to BS message. In some implementations, CN 110 includes the first MBS area information in the second CN to BS message at event 514. In some such cases, CN 110 does not include the first MBS area information in the first CN to BS message.

[0140] Figure 5C Shown with Figure 5A and Figure 5B Example scenario 500C is similar to scenarios 500A and 500B, respectively. In scenario 500C, CN 110 includes the first MBS QoS flow configuration in a third CN to BS message at event 520. After receiving the third CN to BS message, CN 110, CU-CP 172A, CU-UP 172B, and DU 174 perform 592A or 592B MBS session resource configuration process, except that CU-CP 172A generates a second MBS QoS flow configuration based on the first MBS QoS flow configuration received in the third CN to BS message at event 520. In some implementations, for scenario 500C, events 504 and 518 in process 592A or 592B may be omitted. In some implementations, CU-CP 172A sends 527 a third BS to CN message to CN 110 before, during, or after process 592A or 592B.

[0141] Events 520, 527, and 592A or 592B in Figure 5C The above steps are collectively referred to as MBS session resource setup process 592C.

[0142] In some implementations, CN 110 includes the first slice information in a third CN to BS message at event 520. In some such cases, CN 110 does not include the first slice information in the first CN to BS message. In some implementations, CN 110 includes the first MBS area information in the third CN to BS message at event 520. In some such cases, CN 110 does not include the first MBS area information in the first CN to BS message.

[0143] Figure 5DAn example scenario 500D is shown in which the CN 110 and the base station 104 manage the transmission of downlink data for an MBS session to UEs operating in a connected state and in an inactive state. In some implementations of the scenario 500D, while the UE 102 is communicating 596 with the base station 104, the CU-CP 172A determines 542 to transition the UE 102 from the connected state to the inactive state based on data inactivity of the UE 102 (i.e., the UE 102 in the connected state has no data activity with the base station 104 except for receiving MBS data). In some implementations, such as while the UE 102 is communicating with the base station 104, the UE 102 determines or detects data inactivity and sends 535 to the DU 174 UE assistance information (e.g., a UEAssistanceInformation message) indicating that the UE 102 prefers or requests to transition to the inactive state or leave the connected state. In turn, the DU 174 sends 537 a UL RRC messaging message including the UE assistance information to the CU-CP 172A. Thus, in some such implementations, the CU-CP 172A determines that the UE 102 has data inactivity based on the UE assistance information.

[0144] In other implementations, the DU 174 performs data inactivity monitoring for the UE 102. In some such implementations, the CU-CP 172A sends a CU-to-DU message (e.g., a UE context setup request message or a UE context modification request message) to the DU 174 to request or command the DU 174 to perform data inactivity monitoring. In some cases where the DU 174 detects or determines that the UE 102 has data inactivity during monitoring, the DU 174 sends 538 an inactivity notification (e.g., a UE inactivity notification message) to the CU-CP 172A. Thus, the CU-CP 172A determines that the UE 102 has data inactivity based on the inactivity notification received from the DU 174.

[0145] In yet other implementations, CU-UP 172B performs data inactivity monitoring for UE 102. In some such implementations, CU-CP 172A sends a CP to UP message (e.g., a bearer context setup request message or a bearer context modification request message) to CU-UP 172B to request or command CU-UP 172B to perform data inactivity monitoring. In some cases where CU-UP 172B detects or determines that UE 102 has data inactivity during monitoring, CU-UP 172B sends 540 an inactivity notification (e.g., a bearer context inactivity notification message) to CU-CP 172A. Thus, CU-CP 172A determines that UE 102 has data inactivity based on the inactivity notification received from CU-UP 172B. In some implementations, CU-CP 172A determines that UE 102 has data inactivity based on UE assistance information, inactivity notification of event 538, and / or inactivity notification of event 540.

[0146] In some implementations, after a specific period of data inactivity, CU-CP 172A determines that neither CU 172 (i.e., CU-CP 172A and / or CU-UP 172B) nor UE 102 sent any unicast data in the downlink direction or the uplink direction, respectively, during the specific period. In some implementations, CU-CP 172A determines 542 to transition UE 102 to an inactive state in response to the determination.

[0147] In response to or after determining that UE 102 has data inactivity (e.g., within a certain period of time) or determining to transition UE 102 to an inactive state, CU-CP 172A sends 544 a bearer context modification request message to CU-UP 172B to suspend unicast data transmission of UE 102. In response, CU-UP 172B suspends data transmission of UE 102 and sends 546 a bearer context modification response message to CU-CP 172A. In some implementations, in response to or after determining that the UE 102 has data inactivity or determines to transition the UE 102 to the inactive state, the CU-CP 172A sends 548 a CU-to-DU message (e.g., a UE context modification request message) to instruct the DU 174 to provide multicast configuration parameters for the inactive state. In some implementations, the CU-CP 172A includes a multicast request indication (e.g., a multicast indication for the inactive state) requesting the multicast configuration parameters for the inactive state in the CU-to-DU message of event 548.

[0148] In another implementation, in response to the multicast request indication or the CU-to-DU message, the DU 174 sends 550 to the CU-CP 172A a DU-to-CU message (e.g., a UE context modification response message) including multicast configuration parameters for the inactive state (i.e., second multicast configuration parameters for the UE 102 operating in the inactive state to receive a multicast transmission including MBS data from the DU 174). Alternatively, the DU 174 does not include the second multicast configuration parameters in the DU-to-CU message of event 548. Instead, the DU 174 sends an additional DU-to-CU message (e.g., a UE context modification required message) including the second multicast configuration parameters to the CU-CP 172A after receiving the CU-to-DU message of event 548 or sending the DU-to-CU message of event 550. In some implementations, the CU-CP 172A sends an additional CU-to-DU message (e.g., a UE context modification confirmation message) to the DU 174 in response to the additional CU-to-DU message.

[0149] Depending on the implementation, in response to determining to transition the UE 102 to the inactive state, the CU-CP 172A generates an RRC release message (e.g., an RRCRelease message or an RRCConnectionRelease message) to transition the UE 102 to the inactive state. In some implementations, the CU-CP 172A includes the second multicast configuration parameters for the inactive state (e.g., if obtained from the DU 174) and / or the MRB configuration for the inactive state (e.g., the second MRB configuration) in the RRC release message. Then, the CU-CP 172A sends 552 a CU-to-DU message (e.g., a UE context release command message, a UE context modification request message, or a DL RRC messaging message) including the RRC release message to the DU 174. In turn, the DU 174 sends 554 an RRC release message or a PDCP PDU to the UE 102. In some implementations, the DU 174 generates a MAC PDU including the RRC release message and sends 554 the MAC PDU to the UE 102. The RRC release message instructs UE 102 to transition to an inactive state. UE 102 transitions 556 from a connected state to an inactive state upon receiving the RRC release message. In some implementations, UE 102 stops or suspends receiving unicast data from DU 174 in response to the RRC release message or transitioning 556 to an inactive state. For example, the unicast data includes data associated with SRBs and / or DRBs. In some implementations, UE 102 stops using a UE-specific radio network temporary identifier (RNTI) (e.g., RNTI is specific to UE 102) to monitor the PDCCH in response to the RRC release message or transitioning 556 to an inactive state. In some implementations, the UE-specific RNTI includes a C-RNTI of UE 102.

[0150] Events 535, 537, 538, 540, 542, 544, 546, 548, 550, 552, and 554 are Figure 5D The process is collectively referred to as UE-specific RRC state transition process 588.

[0151] In some implementations, the UE 102 in the inactive state continues 558 to receive or attempt to receive MBS data for the first MBS session from the DU 174. In such implementations, the UE 102 in the inactive state continues to monitor the PDCCH with the G-RNTI and / or the G-CS-RNTI to receive MBS data for the first MBS session from the DU 174. If the RRC release message includes a multicast configuration parameter (e.g., a second multicast configuration parameter), the UE 102 in the inactive state continues 558 to receive or attempt to receive MBS data for the first MBS session from the DU 174 according to the second multicast configuration parameter. Otherwise, if the RRC release message does not include a multicast configuration parameter, the UE 102 in the inactive state continues 558 to receive or attempt to receive MBS data for the first MBS session from the DU 174 according to the first multicast configuration parameter. In some implementations, the UE 102 avoids suspending the MRB and / or the PDCP entity associated with the MRB after receiving the RRC release message to continue 558 receiving or attempting to receive MBS data for the first MBS session via the MRB. In some implementations, the UE 102 avoids resetting the MAC entity in response to the RRC release message to continue 558 receiving or attempting to receive MBS data for the first MBS session via the MAC entity.

[0152] In other implementations, the UE 102 stops or suspends receiving MBS data from the DU 174 in response to the RRC release message or transitioning 556 to the inactive state. In some such implementations, the UE 102 in the inactive state stops using the G-RNTI and / or G-CS-RNTI to monitor the PDCCH in response to stopping or suspending the reception of MBS data or when stopping or suspending the reception of MBS data. In some implementations, when the DU 174 receives the MBS data (e.g., event 561), the DU 174 sends (e.g., via multicast or broadcast) 557 a multicast reception indication to the UE 102 to indicate to the UE 102 that the multicast transmission is received. In another implementation, after receiving the multicast reception indication, the UE 102 in the inactive state starts or attempts to receive MBS data for the first MBS session, as described below. In some implementations, the multicast reception indication is a paging message (e.g., including the first MBS session ID). In other implementations, the multicast reception indication is a DCI that includes a specific field (e.g., a short message) that indicates to the UE 102 that a multicast transmission is received. In some implementations, to send the DCI, the DU 174 generates a CRC for the DCI, scrambles the CRC with a paging radio network temporary identifier (P-RNTI), and sends the DCI and the scrambled CRC on a PDCCH monitored by the UE 102. The UE 102 receives the DCI and the scrambled CRC on the PDCCH and verifies whether the scrambled CRC is valid. If the UE 102 verifies that the scrambled CRC is valid, the UE 102 starts or attempts to receive MBS data for the first MBS session from the DU 174. Otherwise, if the UE 102 verifies that the scrambled CRC is invalid, the UE 102 continues to stop or suspend receiving MBS data from the DU 174.

[0153] Depending on the implementation, in response to the CU-to-DU message of event 552, DU 174 retains the second multicast configuration parameters and releases the unicast configuration parameters (e.g., configuration parameters for unicast communication) configured by DU 174 for UE 102. Alternatively, DU 174 releases the second multicast configuration parameters. In another implementation, DU 174 sends a DU-to-CU message (e.g., a UE context release complete message or a UE context modification response message) to CU-CP 172A in response to the CU-to-DU message of event 552.

[0154] After transitioning UE 102 to the inactive state, or while UE 102 is operating in the inactive state, CU-UP 172B receives 559 MBS data for the first MBS session from CN 110 and sends 561 MBS data to DU 174, similar to events 532 and 534, respectively. DU 174 sends 563 MBS data to UE 102 (e.g., via multicast), similar to event 536. For example, the MBS data includes one or more MBS data packets, and DU 174 sends 563 one or more multicast transmissions, each of which includes a specific MBS data packet. UE 102 in the inactive state receives 563 MBS data or multicast transmissions according to the second multicast configuration parameters.

[0155] In some implementations, the examples or implementations described above for the first multicast configuration parameter are applicable to the second multicast configuration parameter. In some implementations, the second multicast configuration parameter extends the first multicast configuration parameter. In such implementations, UE 102 extends the first multicast configuration parameter with the second multicast configuration parameter. Therefore, UE 102 in an inactive state receives 563 MBS data according to the second multicast configuration parameter and the configuration parameters of the first multicast configuration parameter that are not extended by the second multicast configuration parameter. In some implementations, UE 102 retains the configuration parameters (e.g., values) extended by the second multicast configuration parameter. In some such implementations, DU 174 or CU-CP 172A retains the configuration parameters extended by the second multicast configuration parameter for UE 102. In some implementations, when UE 102 transitions from an inactive state to a connected state, UE 102 uses the retained configuration parameters to receive MBS data for the first MBS session from DU 174. Alternatively, UE 102 releases the configuration parameters augmented by the second multicast configuration parameters.

[0156] In some implementations, the first multicast configuration parameter includes a first configuration that configures the UE 102 to send HARQ feedback for a multicast transmission (e.g., including MBS data), and the second multicast configuration parameter releases the first configuration. In some implementations, the second multicast configuration parameter includes a second configuration that releases or disables the first configuration. The UE 102 releases or disables the first configuration in response to the second configuration. In another implementation, the second multicast configuration parameter excludes the first configuration to indicate to the UE 102 to release or disable the first configuration. The UE 102 releases or disables the first configuration in response to the second multicast configuration parameter excluding the first configuration.

[0157] In other implementations, UE 102 receives 563 MBS data using the second multicast configuration parameter instead of the first multicast configuration parameter. In some such cases, UE 102 retains the first multicast configuration parameter. In another implementation, when UE 102 transitions from the inactive state to the connected state, UE 102 receives MBS data for the first MBS session from DU 174 using the first multicast configuration parameter instead of the second multicast configuration parameter. Alternatively, UE 102 releases the first multicast configuration parameter in response to the RRC release message.

[0158] In some implementations, the second MRB configuration indicates or configures the MRB. For example, the second MRB configuration includes an MRB ID that identifies the MRBs respectively. UE 102 uses the indicated or configured MRBs to receive 563 MBS data. In other implementations, the RRC release message does not include an MRB configuration for indicating or configuring the MRB. In such implementations, UE 102 uses all MRBs configured in process 594 to receive 563 MBS data.

[0159] Figure 5E Shown with Figure 5D Example scenario 500E similar to scenario 500D shown. In some implementations of scenario 500E, CU-CP 172A generates an RRC reconfiguration message including the second multicast configuration parameters instead of an RRC release message after receiving the second multicast configuration parameters from DU 174. CU-CP 172A sends 567 a CU-to-DU message including the RRC reconfiguration message to DU 174, which in turn sends 568 an RRC reconfiguration message to UE 102, similar to events 526 and 528, respectively. In response, UE 102 sends 570 an RRC reconfiguration complete message to DU 174, which in turn sends 572 a DU-to-CU message including the RRC reconfiguration complete message to CU-CP 172A. In some implementations, DU 174 generates the second multicast configuration parameters in the same format as the first multicast configuration parameters, and the RRC reconfiguration message does not indicate the multicast configuration parameters. In some such cases, UE 102 is unaware that the second multicast configuration parameters are specific to the inactive state, and the UE in the connected state receives MBS data for the first MBS session from DU 174 according to the second multicast configuration parameters.

[0160] Depending on the implementation, in response to determining to transition UE 102 to the inactive state, CU-CP 172A generates an RRC release message (e.g., an RRCRelease message or an RRCConnectionRelease message) to transition UE 102 to the inactive state. In some implementations, CU-CP 172A includes an indication in the RRC release message indicating that UE 102 receives or continues to receive MBS data after transitioning to the inactive state (e.g., a multicast inactivity enable indication). CU-CP 172A sends 553 an RRC release message to DU 174, similar to event 552. In turn, DU 174 sends 555 an RRC release message to UE 102, similar to event 554. If CU-CP 172A sends 567 an RRC reconfiguration message, CU-CP 172A sends 553 an RRC release message after receiving 570 an RRC reconfiguration complete message. The UE 102 transitions 556 from the connected state to the inactive state in response to or upon receiving the RRC release message.

[0161] Events 535, 537, 538, 540, 542, 544, 546, 548, 550, 553, and 555 are Figure 5E The process is collectively referred to as UE-specific RRC state transition process 589.

[0162] The UE 102 determines to continue 558 receiving or attempting to receive the MBS data in response to the indication (e.g., the multicast inactivity enabled indication). If the RRC release message does not include the indication (e.g., the multicast inactivity enabled indication), the UE 102 determines not to receive or stop receiving the MBS data after receiving the RRC release message or transitioning to the inactive state.

[0163] If CU-CP 172A does not send the second multicast configuration parameters to UE 102 (e.g., events 567, 568, 570, and 572 are omitted), the inactive UE 102 continues to use the first multicast configuration parameters to receive 563 MBS data. Alternatively, in such a case, the inactive UE 102 uses the first part of the first multicast configuration parameters to receive 563 MBS data and avoids using the second part or the remaining part of the first multicast configuration parameters to receive 563 MBS data.

[0164] Now go to FIG. 6A to FIG. 10B , these figures generally illustrate various methods in which a RAN node, DU or CU-UP performs unicast and / or multicast communications with a UE and determines whether to enable data inactivity detection for the unicast communications. FIG. 6A to FIG. 6BIt is shown that the RAN node configures the UE to perform unicast and multicast communications in the connected state, and the RAN node determines whether to transition the UE to the inactive state to continue the multicast communications. Figures 7 and 8 The RAN node is shown performing unicast communication with the UE and, depending on the configuration of the multicast communication, causing the UE to transition to an inactive state or enabling data inactivity detection. Fig. 9 The RAN node is shown performing unicast and multicast communications with the UE and enabling unicast data inactivity detection. FIG. 10A to FIG. 10B It is shown that the DU or CU-UP detects data inactivity of unicast and performs inactivity notification depending on the configuration of the multicast transmission.

[0165] First reference Fig. 6A , a RAN node (e.g., base station 104, CU 172, CU-CP 172A, or DU 174) may implement example method 600A to perform unicast and multicast communications with a UE (e.g., UE 102) operating in a connected state and continue to perform multicast communications with a UE operating in an inactive state.

[0166] Method 600A begins at block 602, where a RAN node performs unicast communications and multicast communications with a UE operating in a connected state (e.g., events 502, 526, 528, 530, 531, 594, 534, 536, 596). At block 604, the RAN node detects data inactivity in unicast communications with the UE (e.g., events 537, 538, 540, 542). At block 606, in response to detecting data inactivity, the RAN node sends an RRC release message to the UE to transition the UE from a connected state to an inactive state (e.g., events 552, 554, 553, 555). At block 608, the RAN node continues to perform multicast communications with the UE operating in an inactive state, or performs multicast communications with the UE operating in an inactive state (e.g., events 561, 563, 597).

[0167] In some implementations, the RAN node performs multicast communications with other UEs operating in a connected state and / or an inactive state.

[0168] Figure 6B is a flow chart of an example method 600B that is similar to method 600A, except that method 600B additionally includes blocks 605 and 610 .

[0169] At block 605, the RAN node determines whether the UE supports multicast communications in the inactive state. If the RAN node determines that the UE supports multicast communications in the inactive state, the flow proceeds to blocks 606 and 608. If the RAN node determines that the UE does not support multicast communications in the inactive state, the flow proceeds to block 610, where the RAN node instructs the UE to remain in the connected state. In other words, the RAN node avoids transitioning the UE to the inactive state.

[0170] refer to Figure 7 , a RAN node (e.g., base station 104, CU 172, CU-CP 172A, or DU 174) may implement example method 700 to determine whether to transition a UE (e.g., UE 102) to an inactive state depending on data inactivity and whether multicast transmission is configured.

[0171] Method 700 begins at block 702, where a RAN node performs unicast communications with a UE operating in a connected state (e.g., events 502, 526, 528, 530, 531, 594). At block 704, the RAN node detects data inactivity in the unicast communications with the UE (e.g., events 537, 538, 540, 542). At block 706, the RAN node determines whether the UE is configured to receive multicast transmissions. If, at block 706, the RAN node determines that the UE is not configured to receive multicast transmissions, the flow proceeds to block 708, where, in response to detecting data inactivity, the RAN node sends an RRC release message to the UE to transition the UE from the connected state to the inactive state (e.g., events 552, 554, 553, 555).

[0172] If at block 706, the RAN node determines that the UE is configured to receive multicast transmissions (eg, events 526, 528, 594), flow proceeds to block 710, where the RAN node instructs the UE to remain in the connected state. In other words, the RAN node avoids transitioning the UE to the inactive state.

[0173] refer to Figure 8 , a RAN node (e.g., base station 104, CU 172, CU-CP 172A, or DU 174) may implement method 800 to determine whether to disable or enable data inactivity detection for a UE (e.g., UE 102) depending on whether multicast transmission is configured for the UE.

[0174] Method 800 begins at block 802, where a RAN node performs communications with a UE operating in a connected state (e.g., events 502, 526, 528, 530, 531, 594, 534, 536, 596). At block 804, the RAN node determines whether the UE is configured to receive multicast transmissions. If, at block 804, the RAN node determines that the UE is not configured to receive multicast transmissions, flow proceeds to block 806, where the RAN node enables (e.g., configures) data inactivity detection for the UE.

[0175] If, at block 804, the RAN node determines that the UE is configured to receive multicast transmissions (eg, events 526, 528, 594), flow proceeds to block 808 where the RAN node disables (eg, releases) data inactivity detection for the UE.

[0176] In some implementations, in a case where the RAN node is a CU (e.g., CU 172) or a CU-CP (CU-CP 172A) and data inactivity detection for a UE is enabled, the CU or CU-CP sends a first CU-to-DU message (e.g., a UE context setup request or a UE context modification request message) to a DU (e.g., DU 174) to request the DU to perform data inactivity detection for the UE. In response, the DU performs data inactivity monitoring for the UE and sends a first DU-to-CU message (e.g., a UE context setup response or a UE context modification response message) to the CU or CU-CP. In some implementations, if the DU detects data inactivity of the UE during monitoring, the DU sends a second DU-to-CU message (e.g., a UE inactivity notification message) indicating data inactivity of the UE to the CU or CU-CP.

[0177] In some implementations, in a case where the RAN node is a CU-CP (CU-CP 172A) and data inactivity detection for the UE is enabled, the CU or CU-CP sends a first CP to UP message (e.g., a bearer context setup request or a bearer context modification request message) to the CU-UP (e.g., CU-UP 172B) to request the CU-UP to perform data inactivity detection for the UE. In response, the CU-UP performs data inactivity monitoring and sends a first UP to CP message (e.g., a bearer context setup response or a bearer context modification response message) to the CU-CP. In some implementations, if the CU-UP detects data inactivity of the UE during monitoring, the CU-UP sends a second UP to CP message (e.g., a bearer context inactivity notification message) indicating data inactivity of the UE to the CU-CP.

[0178] In some implementations, when data inactivity detection for the UE is enabled, the RAN node sends a first DL RRC message (e.g., an RRC reconfiguration message) to the UE to configure the UE to (e.g., enable the UE to) indicate or report a preferred RRC state to the RAN node. In some implementations, the first RRC message includes a release preference configuration (e.g., a releasePreferenceConfig field or a ReleasePreferenceConfig-r16 IE) to configure the UE to indicate or report a preferred RRC state to the RAN node. In response, the UE performs data inactivity detection and sends a first UL RRC message (e.g., an RRC reconfiguration complete message) to the RAN node. In some implementations, if the UE detects data inactivity, the UE sends a UE assistance information message to the RAN node indicating that the UE prefers an inactive state or leaves a connected state.

[0179] refer to Fig. 9 , a RAN node (eg, base station 104, CU 172, CU-CP 172A, or DU 174) may implement method 900 to enable and disable data inactivity detection for a UE (eg, UE 102).

[0180] Method 900 begins at block 902, where a RAN node performs unicast communications with a UE (e.g., events 502, 526, 528, 530, 531, 594). At block 904, the RAN node enables data inactivity detection for the UE. At block 906, the RAN node configures the UE to receive multicast transmissions (e.g., events 502, 526, 528, 530, 531, 594). At block 908, the RAN node disables data inactivity detection for the UE in response to configuring the UE to receive multicast transmissions. At block 910, in some implementations, the RAN node configures the UE to stop receiving multicast transmissions. At block 912, in other implementations, the RAN node enables data inactivity detection for the UE in response to configuring the UE to stop receiving multicast transmissions.

[0181] against Figure 8 The described examples and / or implementations may be applied to Fig. 9 .

[0182] refer to Fig. 10A , a first RAN node (eg, DU 174 or CU-UP 172B) may implement example method 1000A to determine whether to send a data inactivity notification depending on whether multicast transmission is configured.

[0183] Method 1000A begins at block 1002, where a first RAN node performs unicast communications with a UE (e.g., events 502, 526, 528, 530, 531, 594). At block 1004, the first RAN node detects data inactivity of the unicast communications with the UE. At block 1006, the first RAN node determines whether the UE is configured to receive multicast transmissions. If, at block 1006, the first RAN node determines that the UE is not configured to receive multicast transmissions, the process proceeds to block 1008, where the first RAN node sends an inactivity notification message indicating UE inactivity to a second RAN node (e.g., CU 172 or CU-CP 172A) (e.g., events 538, 540). In some implementations, if the first RAN node is a DU, the inactivity notification message is a UE inactivity notification message. In other implementations, if the first RAN node is a CU-UP, the inactivity notification message is a bearer context inactivity notification message. If, at block 1006, the first RAN node determines that the UE is configured to receive multicast transmissions, flow proceeds to block 1010, where the first RAN node refrains from sending an inactivity notification message to the second RAN node indicating that the UE is inactive.

[0184] Fig. 10B is a flow chart of an example method 1000B that is similar to method 1000A, except that method 1000B includes block 1011 instead of block 1010 .

[0185] If at block 1006, the first RAN node determines that the UE is configured to receive multicast transmissions, flow proceeds to block 1011, where the RAN node sends an inactivity notification message indicating UE activity to the second RAN node.

[0186] The following additional considerations apply to the foregoing discussion.

[0187] In general, the description of one of the above figures may apply to another of the above figures. The events or boxes described above may be optional or omitted. For example, the events or boxes with dashed lines in the figures may be optional or omitted. In some cases, if the events or boxes with solid lines in the figures are not necessary, the events or boxes may still be optional or omitted. In some implementations, "message" is used and "information element (IE)" can be used instead of "message". In some implementations, "IE" is used and "field" can be used instead of "IE". In some implementations, "configuration" or "configuration parameter" can be used instead of "configuration". In some implementations, "multicast" or "multicast MBS" can be used instead of "MBS". In some implementations, "multicast transmission" can be used instead of "MBS data". In some implementations, "multicast MBS" and "multicast transmission" are interchangeable. In some implementations, "multicast communication", "multicast reception" and "multicast transmission" are interchangeable. In some implementations, "multicast SPS" may be used instead of "SPS multicast". Similarly, "multicast dynamic" may be used instead of "dynamically scheduled multicast". In some implementations, "identification" may be used instead of "identifier". In some implementations, "CFR" is used and "MBS BWP" may be used instead of "CFR". In some implementations, the term "transport layer configuration" may be replaced by "tunnel information" or "transport layer information". In some implementations, "using" may be used instead of "according to". In some implementations, "unicast data communication" may be used instead of "unicast communication".

[0188] The user device (e.g., UE 102A, 102B or UE 103) in which the technology of the present disclosure can be implemented can be any suitable device capable of wireless communication, such as a smart phone, a tablet computer, a laptop computer, a mobile game console, a point of sale (POS) terminal, a health monitoring device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device (such as a smart watch), a wireless hotspot, a femtocell or a broadband router. In addition, in some cases, the user device can be embedded in an electronic system (such as a head unit of a vehicle or an advanced driver assistance system (ADAS)). Further, the user device can be operated 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, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

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

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

[0191] After reading this disclosure, those skilled in the art will understand additional alternative structural and functional designs for performing HARQ processes to send MBS data through the principles disclosed herein. Therefore, although specific embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations that will be apparent to those of ordinary skill in the art may be made to the arrangement, operation and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims

1. A multicast and / or broadcast service (MBS) communication method implemented in a radio access network (RAN), the method comprising: performing (i) unicast communication and (ii) multicast communication with a UE operating in a connected state; responsive to determining data inactivity of the unicast communication, sending a message indicating that the UE is to transition from the connected state to an inactive state in which a radio connection between the UE and the RAN is suspended; and The multicast communication is continued with the UE operating in the inactive state.

2. The method of claim 1, further comprising: Data inactivity monitoring associated with the unicast communication is performed.

3. The method of claim 2, wherein the determination of the data inactivity comprises: It is determined that the UE has not sent or received unicast data during a specific time period.

4. The method according to claim 2 or 3, further comprising: said performing of said data inactivity monitoring at a distributed unit (DU) of a distributed base station; The method further comprises: A UE inactivity notification message is sent to a central unit (CU) of the distributed base station.

5. A method as claimed in any preceding claim, wherein the message comprises a Radio Resource Control (RRC) release command.

6. A method as claimed in any one of the preceding claims, wherein: The performing of the multicast communication comprises using a first multicast configuration; and The continuing to perform the multicast communication with the UE operating in the inactive state includes using a second multicast configuration.

7. A method as claimed in any one of the preceding claims, wherein: The performing of the multicast communication includes using a first MBS Radio Bearer (MRB) configuration; and The continuing to perform the multicast communication with the UE operating in the inactive state includes using a second MRB configuration.

8. The method according to any one of the preceding claims, further comprising: The multicast communication is associated with an MBS session corresponding to a temporary mobile group identity (TMGI).

9. A multicast and / or broadcast service (MBS) communication method implemented in a user equipment (UE), the method comprising: In a connected state, performing (i) unicast communication and (ii) multicast communication with a radio access network (RAN); receiving, upon detecting data inactivity of the unicast communication, a message indicating that the UE is to transition from the connected state to an inactive state in which a radio connection between the UE and the RAN is suspended; as well as In the inactive state, the multicast communication continues to be performed with the RAN.

10. The method of claim 9, wherein the message comprises a Radio Resource Control (RRC) release command.

11. The method of claim 9 or 10, wherein: The performing of the multicast communication comprises using a first multicast configuration; and The continuing to perform the multicast communication with the UE operating in the inactive state includes using a second multicast configuration.

12. The method of any one of claims 9 to 11, wherein: The performing of the multicast communication includes using a first MBS Radio Bearer (MRB) configuration; and The continuing to perform the multicast communication with the UE operating in the inactive state includes using a second MRB configuration.

13. The method according to any one of claims 9 to 12, further comprising: The multicast communication is associated with an MBS session corresponding to a temporary mobile group identity (TMGI).

14. The method of any one of claims 9 to 13, wherein the multicast communication is associated with a Multicast Traffic Channel (MTCH).

15. A device comprising: Transceiver; as well as Processing hardware configured to implement according to any one of the preceding claims.

Images