Managing multicast data reception

Abstract

A multicast and / or broadcast service (MBS) communication method is implemented in a user equipment (UE). The method comprises: receiving MBS data from a radio access network (RAN) according to a multicast configuration in a first cell and in an inactive state in which a radio connection between the UE and the RAN is suspended; determining to reselect from the first cell to a second cell; in response to determining the reselection, pausing the reception of MBS data; and resuming reception of MBS data in the second cell after resuming the radio connection via the second cell.

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,293, entitled “MANAGING MULTICAST DATARECEPTION,” 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 otherwise may not be considered prior art at the time of filing are neither explicitly nor implicitly admitted to be prior art with respect 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 user plane data delivery, encryption, integrity protection, etc. 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 (BS) and in the downlink direction from the base station to the UE. The PDCP sublayer also provides the service of signaling radio bearers (SRBs) to the radio resource control (RRC) sublayer. The PDCP sublayer also provides the service 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 DRBs can be used to transport data on the user plane.

[0006] In some scenarios, the UE can concurrently utilize 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 backhaul. When such network nodes support different radio access technologies (RATs), this type of connectivity is called multi-radio dual connectivity (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 the primary cell (PCell) and zero, one or more secondary cells (SCells), and the SCG covers the primary and secondary cells (PSCells) and zero, one or more SCells. The UE communicates with the MN via the MCG and communicates with the SN via the SCG. In other scenarios, the UE utilizes the resources of one base station at a time with a single connectivity (SC). The UE in the SC communicates with the MN via the MCG. The base station and / or the UE determine 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 base station or a decomposed 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 recorded measurement information or NAS messages also on the DCCH but with a lower priority than SRB1 resources. More generally, SRB1 resources 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 MCGSRBs. "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, the UE may perform a handover procedure from one cell to another, whether in SC or DC operation. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. Depending on the scenario, the UE may perform 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 may perform a PSCell change procedure to change the PSCell. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. 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 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, the UE receives 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 group 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 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 desirable to support multicast for UEs in RRC_INACTIVE state. However, it is unclear how to enable multicast for UEs operating in RRC_INACTIVE state. Summary of the invention

[0011] An exemplary embodiment of the technology disclosed herein is a multicast and / or broadcast service (MBS) communication method implemented in a user equipment (UE), the method comprising: receiving MBS data from a radio access network (RAN) according to a multicast configuration in a first cell and in an inactive state in which a radio connection between the UE and the RAN is suspended; determining to reselect from the first cell to a second cell; suspending reception of the MBS data in response to determining the reselection; and resuming reception of the MBS data in the second cell after resuming the radio connection via the second cell.

[0012] Another exemplary implementation of the techniques is a user equipment (UE) that includes a transceiver and processing hardware configured to implement the above methods. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0015] Figure 2A is a block diagram of an exemplary protocol stack, Figure 1A The UE can be connected according to the protocol stack Figure 1A Communicate with the base station;

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

[0017] Figure 3 is a block diagram of an exemplary tunnel architecture for MBS sessions and PDU sessions;

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

[0019] Figure 5A Among them Figure 1A and / or Figure 1B A messaging diagram for an exemplary scenario in which a CN and RAN node manage the transmission of downlink data for an MBS session to a UE operating in a connected state;

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

[0021] Figure 5C is with Figure 5A and Figure 5B A messaging diagram for a similar exemplary scenario, but wherein the CN transmits a message to the RAN node including a first QoS flow configuration for generating a second QoS flow configuration;

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

[0023] Figure 5E is with Figure 5D a messaging diagram for a similar exemplary scenario, but where the RAN node transmits a message to the UE to reconfigure radio resources instead of releasing radio resources;

[0024] Fig. 6A Among them Figure 1A and / or Figure 1B A messaging diagram for an exemplary scenario in which a RAN node manages transmission of downlink data of a UE during a state transition between an inactive state and a connected state;

[0025] Figure 6B is with Fig. 6A Messaging diagram for a similar exemplary scenario, but where the RAN node instructs the UE to remain in an inactive state rather than transitioning to a connected state;

[0026] Figure 6C is with Fig. 6A and Figure 6B a messaging diagram for a similar exemplary scenario, but where the RAN node transmits an indication that multicast inactivity is enabled rather than multicast configuration parameters for the inactive state;

[0027] Fig. 7A Among them Figure 1A and / or Figure 1B A messaging diagram for an exemplary scenario in which a RAN node manages transmission of downlink data for a UE operating in an inactive state and accessing a new RAN node;

[0028] Figure 7B is with Fig. 7A Messaging diagram for a similar exemplary scenario, but where the RAN node instructs the UE to remain in an inactive state rather than transitioning to a connected state;

[0029] Figure 7C is with Fig. 7A and Figure 7Ba messaging diagram for a similar exemplary scenario, but where the RAN node transmits an indication that multicast inactivity is enabled rather than multicast configuration parameters for the inactive state;

[0030] Fig.7D is with 7A to 7C Messaging diagram for a similar exemplary scenario, but where the UE continues MBS data reception instead of suspending and resuming data reception;

[0031] Fig. 8A is a flow chart of an exemplary method in which a UE is configured to perform MBS data reception in an inactive state and during or after performing a recovery procedure;

[0032] Figure 8B For Fig. 8A a flow chart of a similar exemplary method, but wherein the UE suspends MBS data reception while performing a recovery procedure;

[0033] Figure 8C is with Fig. 8A and Figure 8B A flow chart of a similar exemplary method, but wherein the UE utilizes Figure 1A or Figure 1B The RAN node initiates a random access procedure and suspends MBS data reception when performing the random access procedure;

[0034] Fig. 9 is a flow chart of an exemplary method in which a UE is configured to perform MBS data reception in an inactive state and determine whether to continue MBS data reception;

[0035] Fig. 10A is a flowchart of an exemplary method in which a UE is configured to perform MBS data reception in an inactive state and resume MBS data reception, suspend MBS data reception, and resume MBS data reception via a second cell; and

[0036] Fig. 10B is with Fig. 10A A flow chart of a similar exemplary method, but wherein the UE is based on Figure 1A and / or Figure 1B Whether to resume MBS data reception depends on whether the message of the RAN node configures MBS data reception. DETAILED DESCRIPTION

[0037] Figure 1AAn 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 alternatively include a plurality of wireless communication systems. 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.

[0038] Base station 104 supports cell 124, and base station 106 supports cell 126. Cell 124 partially overlaps with cell 126, so that UE 102A can be within the range of communicating with base station 104 while being within the range of communicating with base station 106 (or within the range of detecting or measuring a signal 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 (acting as a master node (MN)) and base station 106 (acting as a secondary node (SN)) in DC. When UE 102A is in DC with base station 104 and base station 106, base station 104 operates as a master eNB (MeNB), 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).

[0039] In non-MBS (unicast) operation, the UE 102A may use radio bearers (e.g., DRBs or SRBs) that terminate at different times at a MN (e.g., base station 104) or a SN (e.g., base station 106). For example, after handover to the base station 106 or a 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 transmits data to the base station via a radio bearer on an uplink (UL) bandwidth part (BWP) of the cell (i.e., within) and / or receives data from the base station via a radio bearer on a downlink (DL) BWP of the cell. The UL BWP may be an initial UL BWP or a dedicated UL BWP, and the DLBWP 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.

[0040] In MBS operation, UE 102A may use MBS radio bearers (MRBs) that terminate at different times at a MN (e.g., base station 104) or a SN (e.g., base station 106). For example, after a handover or SN change, UE 102A may use an MRB that terminates at base station 106, which may be operating as a MN or SN. In some scenarios, a base station (e.g., MN or SN) may transmit MBS data to UE 102A via an MRB over unicast radio resources (i.e., radio resources dedicated to UE 102A). In other scenarios, a base station (e.g., MN or SN) may transmit MBS data to UE 102A via an MRB over multicast radio resources (i.e., radio resources shared by 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 MBSDL BWP (i.e., a DL BWP specific to MBS or not used for unicast).

[0041] 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 1AThe processing hardware 130 in an example implementation of includes an MBS controller 132 configured to manage or control the sending 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.

[0042] 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 1A Not 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 .

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

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

[0045] 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 traffic, 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 pass user plane packets associated with audio calls, video calls, Internet traffic, 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.

[0046] 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 transmission, configure UPF 162 and / or RAN 105 for MBS flow, 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 of audio, video, Internet traffic, 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.

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

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

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

[0050] 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 executable 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.

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

[0052] 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, while CU-UP 172B may transmit non-MBS data packets and MBS data packets, as described herein.

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

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

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

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

[0057] In a scenario in which the UE 102A, 102B, or 103 operates in EN-DC with the base station 104 serving as a MeNB and the base station 106 serving as an SgNB, the wireless communication system 100 may provide the UE 102A, 102B, or 103 with a bearer terminated at the MN using the EUTRA PDCP sublayer 208 or a bearer terminated at the MN 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 bearer terminated at the SN using only the NR PDCP sublayer 210. The bearer terminated at the MN may be an MCG bearer, a split bearer, or an SCG bearer terminated at the MN. The bearer terminated at the SN may be an SCG bearer, a split bearer, or an MCG bearer terminated at the SN. The bearer terminated at the MN may be an SRB (e.g., SRB1 or SRB2) or a DRB. The bearer terminated at the SN may be an SRB or a DRB.

[0058] 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 transmits the MBS data packets via the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE 102A, 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 transmits MBS data packets via the SDAP sublayer 212, the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE 102A, 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.

[0059] 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 (eg, DU 174) and a CU (eg, 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.

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

[0061] 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 can 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.

[0062] Tunnel 312A may be operated at a transport layer or sublayer, for example, 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 transmit the tunnel packet downstream to base station 104 / 106 via tunnel 312A (i.e., the header may include an IP address and / or a TEID). 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.

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

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

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

[0066] Continue to refer Figure 3 , the base station 104 / 106 and the CN 110 may maintain one or more PDU sessions to support unicast traffic between the CN 110 and a 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).

[0067] 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 transmits MBS data packets to multiple UEs. Alternatively, DL tunnel 412A may be a UE-specific DL tunnel via which CU 172 transmits MBS data packets to a specific UE.

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

[0069] 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 described cases, 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.

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

[0071] In some cases, CU 172 uses DRB 404A to transmit 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.

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

[0073] Next, refer to FIG. 5A to FIG. 5E , FIG. 6A to FIG. 6C as well as 7A to 7D Several exemplary scenarios in which a UE and / or RAN performs the disclosed technology for supporting MBS for a UE 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_INACTIVE state, and an RRC_IDLE state, respectively.

[0074] Figure 5A An exemplary scenario 500A for establishing an MBS session is depicted. The base station 104 includes a DU 174, a CU-CP 172A, and a CU-UP 172B. Note that the scenario 500A may also be applicable to an integrated CU (eg, a CU that is not split into a CP functional node and a UP functional node).

[0075] UE 102 (e.g., Figure 1AUE 102A) first 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 therefore the first of multiple MBS join procedures. In some implementations, because 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 any order. In other words, in such implementations, base station 104 configures the common DL tunnel before any UE joins the first MBS session.

[0076] In some implementations, the UE 102 performs 502 the 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 transmit 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. In response to the RRC release message, the UE 102 transitions to an inactive state or an idle state. 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, the UE 102 transmits an RRC recovery request message to the CU-CP 172A via the DU 174, and receives an RRC recovery message from the CU-CP 172A via the DU 174. In response, UE 102 transitions 503 to a connected state and transmits an RRC recovery complete message to CU-CP 172A via DU 174. In other implementations, 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 transmits 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 transmits an RRC setup complete message to CU-CP 172A via DU 174.

[0077] Otherwise, if the first MBS session has been initiated, is being initiated, or is about to be initiated, the CU-CP 172A keeps the UE 102 in the connected state.

[0078] When UE 102 operates in a connected state, UE 102 monitors PDCCH using a cell radio network temporary identifier (C-RNTI) to transmit 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 does not include multicast MBS data (e.g., at event 536). In some implementations, when UE 102 receives DCI and a scrambled CRC on PDCCH, UE 102 uses C-RNTI and DCI to verify CRC. If UE 102 verifies that CRC is valid and DCI includes UL grant, UE 102 transmits UL transmission including unicast data to DU 174 according to the UL grant. If the UE 102 verifies that the CRC is valid and the DCI includes a DL assignment, the UE 102 receives a DL transmission including unicast data from the DU 174 according to the DL assignment.

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

[0080] 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 transmits a first UL container message including an MBS session join request message to CN 110 via base station 104; CN 110 transmits a DL container message including an MBS session join response message to UE 102 via base station 104; and UE 102 transmits 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.

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

[0082] 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 other implementations, during the PDU session establishment procedure, UE 102 communicates a PDU session ID of the PDU session with CN 110 via base station 104.

[0083] 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).

[0084] In some implementations, the CN 110 includes a first MBS Quality of Service (QoS) flow configuration for the first MBS session in the 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 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 MBS QoS flow configuration 1...M includes an MBS QoS flow identifier and MBS QoS flow level QoS parameters for a particular MBS QoS flow.

[0085] In other implementations, CN 110 does not include the MBS QoS flow configuration of 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 pre-configured MBS QoS flow configuration. For example, the second MBS QoS flow configuration is the same as the pre-configured MBS QoS flow configuration. In another example, the second MBS QoS flow configuration is similar to the pre-configured MBS QoS flow configuration. In some implementations, CU-CP 172A is pre-configured with the pre-configured MBS QoS flow configuration before receiving the first CN to BS message. In other implementations, CU-CP 172A receives the pre-configured 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 applied to the pre-configured MBS QoS flow configuration.

[0086] In other implementations, CN 110 sends an additional CN to BS message (e.g., a multicast session update request message) to CU-CP 172A after sending 504 the first CN to BS message, the additional CN to BS message including the first MBS session ID and the first MBS QoS flow configuration. After receiving the additional CN to BS message, CU-CP 172A sends 560 the first CP to UP message to CU-UP 172B and DU 174, respectively, and sends 506 the first CU to DU message. 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.

[0087] In some implementations, the CU-CP 172A sends the 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 transmitting 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.

[0088] 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 an additional CN to BS message. In some such cases, CN 110 does not include the first MBS area information in the first CN to BS message.

[0089] In some implementations, CN 110 includes first slice information indicating a network slice to be used 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 particular 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.

[0090] In some implementations, CN 110 includes first MBS area information (e.g., MBS service area IE) in the first CN to BS message, and the first MBS area information configures or indicates the MBS area of ​​the first MBS session. 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 IDIE, MBS service area information IE}. In the case where the first MBS session is a location-independent multicast session, the first MBS area information includes the MBS service area information IE. The MBS service area information IE in the first MBS area information includes a cell identity list and / or a tracking area identity (TAI) list. In some implementations, the cell identity is a cell global identity (CGI). In other implementations, CN 110 does not include MBS area information (e.g., MBS service area IE) in the first CN to BS message.

[0091] 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 one or more MRBs configured for the first MBS session or MBS QoS flows 1…M. In response to the determination, CU-CP 172A generates an MRB setup configuration for requesting 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.

[0092] 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 QoSFlowLevelQoSParametersIE) in the MRB setup configuration (e.g., MCMRBSetupConfigurationIE). In some implementations, the MRB setup configuration includes one or more MRB setup configuration items (e.g., MCMRBSetupConfiguration-ItemIE). In some implementations, each MRB setup configuration item includes an MRBID of a specific MRB, an MRB configuration parameter (e.g., PDCP configuration and / or SDAP configuration), and / or a specific one or more of 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., acknowledgement mode or non-acknowledgement 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).

[0093] In some implementations, the second MBS QoS flow configuration includes QoS parameters required for each MBS QoS flow 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 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 MRB setting configuration items 1…N corresponding to MRBs 1…N, where N is an integer greater than zero. In some implementations, in the MRB setting configuration, the CU-CP 172A configures a mapping or association between MBS QoS flows 1…M and 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, the CU-CP 172A avoids associating or mapping a specific QoS flow to two MRBs. In some implementations, for MRB X in MRBs 1...N, the MRB setting configuration item X includes MRBID 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.

[0094] Example 1 of MRB settings configuration:

[0095]

[0096] Example 2 of MRB setup configuration (i.e. omitting SDAP-Configuration):

[0097]

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

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

[0100] 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 used for the first MBS session. In some cases where CU-CP 172A does not receive the first slice information from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the pre-configured slice information in the first CP to UP message to indicate that a specific network slice is used for the first MBS session. Alternatively, CU-CP 172A omits the slice information in the first CP to UP message in these cases to indicate that a default network slice is used for the first MBS session.

[0101] 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 pre-configured MBS region information in the first CP to UP message. Alternatively, CU-CP 172A omits the MBS region information from the first CP to UP message in these cases. 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 pre-configured MBS region session ID in the first CP to UP message. Alternatively, CU-CP 172A omits the MBS region session ID from the first CP to UP message in these cases.

[0102] 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 MRB 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 PDCP entities 1…N according to PDCP configurations 1…N of MRBs or MRBIDs 1…N. In other implementations, for each PDCP configuration 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 other implementations, 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.

[0103] In some implementations, CU-UP 172B establishes and / or configures SDAP entities 1 ... N according to SDAP configurations 1 ... N of MRB or MRBID 1 ... N. In other implementations, for each SDAP configuration 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 other implementations, 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, CU-UP 172B ignores or discards the entire SDAP configuration because CU-UP 172B determines not to use SDAP to transmit MBS data for the first MBS session.

[0104] In some implementations, CU-UP 172B includes in the first UP to CP message a first CU transport layer configuration for configuring a common CN to BSDL tunnel for a first MBS session configuration. In some implementations, the first CU transport layer configuration includes a CU transport layer address (e.g., an IP address and / or TEID) for identifying the first common CN to BSDL tunnel. In other implementations, the first CU transport layer configuration is MC bearer context NG-U TNL information at NG-RAN IE. In some implementations, CU-CP 172A includes in the first CP to UP message a first ID (e.g., CU-CP MBS E1APID) 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 in the first UP to CP message a first ID (e.g., CU-UP MBS E1AP ID) 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 a first ID (eg, CU-CP MBS E1APID) in the first UP to CP message.

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

[0106] After (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., an MBS context setup request message) to the DU 174 to request setup for a multicast context and / or a common DL tunnel for the first MBS session. The CU-CP 172A determines one or more MRBs configured for the first MBS session or MBS QoS flows 1…M. In response to the determination, the CU-CP 172A generates a configuration of the MRBs to be set up in order to request resources for the one or more MRBs. In some implementations, the first CU to DU message includes a first MBS session ID for the first MBS session, a configuration of the MRBs to be set up, and / or a third MBS QoS flow configuration. In some implementations, the CU-CP 172A includes 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 configuration of the MRBs to be set includes MRBIDs, each MRBID identifies an MRB, and the DU 174 configures resources (e.g., PHY, MAC, and / or RLC resources) for the MRBs. The MRBIDs included in the first CU to DU message are the same as the MRBIDs included in the first CP to UP message. For example, the configuration of the MRBs to be set includes MRBIDs 1…N corresponding to 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 of the MRBs to be set, the CU-CP 172A configures a mapping or association between the MBS QoS flows and the MRBs. For example, the configuration of the MRB to be set includes setting configuration items 1…N corresponding to MRBs 1…N. In some implementations, setting configuration item Y includes MRB IDY for MRB Y in MRBs 1…N and a specific MBS QoS flow configuration in the third MBS QoS flow configuration, where 1≤Y≤N. Therefore, CU-CP 172A generates a third MBS QoS flow configuration based on the pre-configured 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 .

[0107] 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 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 pre-configured slice information in the first CU to DU message. Alternatively, CU-CP 172A omits the slice information in the first CP to UP message in these cases.

[0108] 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 pre-configured MBS region information in the first CU to DU message. Alternatively, CU-CP 172A omits the MBS region information from the first CU to DU message in these cases. 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 DU message. In other cases where CU-CP 172A does not receive MBS region information from CN 110, CU-CP 172A includes the pre-configured MBS region session ID in the first CU to DU message. Alternatively, CU-CP 172A omits the MBS region session ID from the first CU to DU message in these cases.

[0109] In response to receiving 506 the first CU-to-DU message, 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 CU-CP 172A. In some implementations, DU 174 establishes and / or configures a MAC entity for the MRB. In other implementations, DU 174 establishes and / or configures an RLC entity / RLC entity 1...N for the MRB or MRB IDs 1...N, respectively. In some implementations, DU 174 includes in the first DU-to-CU message a first DU transport layer configuration for configuring a common CU-to-DU DL tunnel for a first MBS session (e.g., for an MRB identified by one of the MRB IDs). Depending on the implementation, DU 174 includes additional DL transport layer configurations in the first DU to CU message to configure additional common CU to DU DL tunnels for additional MRBs identified by additional MRB IDs in the MRB IDs. 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 configurations includes a DU transport layer address (e.g., an IP address and / or a TEID). In other implementations, each of the first DU transport layer configuration and / or the additional DU transport layer configuration is an MRB F1-U TNLinfo IE at the DU.

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

[0111] In some implementations, DU 174 transmits 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 transmitting 508 the first DU-to-CU message. In some implementations, DU 174 includes the first DU transport layer configuration and / or additional DL transport layer configuration in the second DU-to-CU message instead of in 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 additional DU transport layer configuration in the second DU-to-CU message instead of in the first DU-to-CU message. Thus, the first DU-to-CU message does not include the DU transport layer configuration. In some implementations, CU-CP 172A transmits 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.

[0112] 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 transmits 512 the first BS to CN message (e.g., a distribution setup request message) to CN 110. In some implementations, CU-CP 172A transmits 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 other implementations, CU-CP 172A includes the first CU transport layer configuration in the first BS to CN message. Thus, 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 other implementations, 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 a 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) for identifying a first public CN to BSDL tunnel. In some implementations, the 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 CN 110 / TEID of CN 110. In other implementations, 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.

[0113] 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 an MRB ID, a first DU transport layer configuration, an additional DU transport layer configuration, and / or a first CN transport layer configuration. 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 an MRB ID and / or a 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 other implementations, 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 transmitting 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 transmits 518 the second BS to CN message to the CN 110 before receiving 566 the second UP to CP message or transmitting 516 the second CU to DU message. For example, 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, the CU-CP 172A sends 518 the second BS to CN message to the CN 110.

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

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

[0116] In some implementations, CN 110 sends 520 a third CN to BS message to CU-CP 172A, the third CN to BS message 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 for UE 102 to DU 174. In some implementations, CU-CP 172A includes an MRBID in the UE context request message. In other implementations, CU-CP 172A determines the MRBID 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.

[0117] In response to the UE context request message of event 522, DU 174 sends 524 a UE context response message including a multicast configuration parameter to CU-CP 172A, so that UE 102A receives MBS data for the first MBS session via the MRB. In some implementations, some or all of the multicast configuration parameters may be associated with the MRB / MRBID. In some implementations, DU174 generates a DU configuration (i.e., a first DU configuration) to include a multicast configuration parameter (i.e., a first multicast configuration parameter), 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 parameter configures one or more logical channels (LCs) for the MRB. For example, the multicast configuration parameter includes one or more logical channel IDs (LCIDs) for configuring the logical channel. Each of the LCIDs identifies a specific logical channel in the 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).

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

[0119] 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 a bearer context for UE 102 and sends a bearer context response message to CU-CP 172A. In other implementations, CU-CP 172A does not perform 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 establishment procedure (e.g., as defined in Section 8.3.1 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 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.

[0120] 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 transmits 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. The DU 174 then transmits 528 the RRC reconfiguration message to the UE 102 operating in a connected state. The UE 102 in the connected state then transmits 530 an RRC reconfiguration complete message to the DU 174, which in turn transmits 531 an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the CU-CP 172A.

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

[0122] 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 UE (e.g., UE 102A and UE 102B) that joins 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 other scenarios or implementations, process 594 overlaps with process 592A.

[0123] 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 transmits 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 transmits 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 the 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.

[0124] In some implementations, before or after receiving 524 the TOUE 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 TORRC 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, CN 110 assigns a first CN UE interface ID that identifies UE 102 (e.g., UE 102A), and CU-CP 172A assigns a first RAN UE interface ID that identifies 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 NGAPID”.

[0125] After receiving 518 the second BS-to-CN message or receiving 527 the third BS-to-CN message, 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 CU-UP 172B via the first common CN-to-BSDL tunnel (e.g., according to the first CU transport layer configuration and / or the first CN transport layer configuration). In some implementations, CN 110 generates tunnel packets that each include a specific MBS data packet to transmit the MBS data packets via the first common CN-to-BSDL tunnel. CN 110 sets the source IP address, the target IP address, and the TEID in the header of each tunnel packet 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.

[0126] When CU-UP 172B receives 532 MBS data for the first MBS session from CN 110, CU-UP 172B then 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 tunnels (i.e., according to the first and / or additional DU transport layer configurations). In some cases where the MBS data is associated with some MBS QoS flows identified by the MBS QoS flow identifiers, CU-UP 172B determines which common CU-to-DU DL tunnel 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 of 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 the second one of the MBS QoS flow identifiers 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 including a specific MBS data packet to transmit the MBS data packets 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 transmits one of the tunnel packets via the first common CU-to-DU tunnel, CU-UP 172B sets the source IP address, the target 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 transmits one of the tunnel packets via the 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.

[0127] When the DU 174 receives 534 the MBS data from the CU-UP 172B, the DU 174 transmits (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 transmits 534 the PDCP PDU to the DU 174. The DU 174 then generates a MAC PDU including a logical channel ID and the PDCP PDU, and transmits 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 the MBS data or the MAC PDU 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 the MBS data or the MAC PDU from the DU 174 via one or more multicast transmissions, as described above. In some implementations, the UE 102 receives 536 the MAC PDU or MBS data using a MAC entity and processes the PDCP PDU using a PDCP entity to obtain the MBS data.

[0128] 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 a UE-specific CU to DU DL tunnel. In some implementations, the CU transport layer configuration additionally includes a 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 transmits 534 the MBS data to DU 174 via a UE-specific CU-to-DU DL tunnel.

[0129] In some implementations, the multicast configuration parameters also include one or more RLC bearer configurations, each RLC bearer configuration being associated with a specific MRB. Each MRB configuration includes an MRBID, 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.

[0130] 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 transmit 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 transmit control PDUs to base station 104 via logical channels by excluding UL configuration parameters from the RLC bearer configuration.

[0131] In the case where DU 174 includes UL configuration parameters in the RLC bearer configuration, UE 102 transmits 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 transmits 534 the PDCP PDU including the compressed MBS data packets to DU 174 via a first or additional common CU to DU DL tunnel. DU 174 then transmits 536 the PDCP PDU to UE 102 via the logical channel (e.g., multicast or unicast). 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 transmits a PDCP control PDU to DU 174 via the logical channel, the PDCP control PDU including header compression protocol feedback (e.g., interspersed ROHC feedback) for the operation of the header compression or decompression protocol. DU 174 then 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, the IP address in the first DU transport layer configuration and the 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 a 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 a 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.

[0132] In some implementations, the MRB configuration is an MRB-ToAddModIE including an MRBID (e.g., mrb-Identity or MRB-Identity). The MRBID identifies a specific MRB in the MRB. In the case 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 MRBIDs to a value different from the DRBID 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 RBID of the RB. In other implementations, the CU-CP sets one or more of the MRBIDs to the same value as the DRBID. 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 RBID of the RB and the RRCIE configuring 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 transmits 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 transmits the MRB-ToAddMod IE that configures the RB to the UE 102, it determines that the RB is an MRB.

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

[0134] In some implementations, the multicast configuration parameters include dynamically scheduled multicast configuration parameters for UE 102 to receive multicast transmissions, each multicast transmission including 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. A first exemplary 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 using the G-RNTI; and transmitting the DCI and the scrambled CRC on a 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 using the G-RNTI. For each multicast transmission, after the UE 102 verifies that the CRC is valid, the UE 102 receives the multicast transmission according to the corresponding DCI and retrieves a specific MAC PDU from the multicast transmission. In such a case, each multicast transmission is a dynamically scheduled multicast transmission used in the following description. In some implementations, each DCI includes a configuration parameter that configures the dynamically scheduled multicast radio resources that schedule the corresponding multicast transmission. In some implementations, the configuration parameter includes at least one of the following parameters. The configuration parameter of each DCI includes the same value and / or different values ​​of the following configuration parameters: (i) frequency domain resource assignment; (ii) time domain resource assignment; (iii) mapping of virtual resource blocks (VRBs) to physical resource blocks (PRBs); (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 exemplary parameter is a HARQ codebook (ID) indicating a HARQ confirmation (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 exemplary parameter is a PUCCH resource configuration that indicates a HARQ resource on the PUCCH at which the UE 102 transmits HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for a dynamically scheduled multicast transmission. In some cases where the configuration parameters do not include a PUCCH resource configuration, the UE 102 and the DU 174 transmit the HARQ feedback using the PUCCH resource configuration for unicast transmissions. Another exemplary parameter is a HARQ NACK-only indication that configures the UE 102 to transmit a HARQ negative ACK (NACK) only for dynamically scheduled 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, for the dynamically scheduled multicast transmissions that the UE 102 successfully received and from which the UE 102 obtained a transport block, the UE 102 does not transmit a HARQ ACK to the DU 174. In some cases where the configuration parameters do not include the indication, for the dynamically scheduled multicast transmissions that the UE 102 successfully received and from which the UE 102 obtained a transport block, the UE 102 transmits a HARQ ACK to the DU 174. Another exemplary parameter is a HARQ ACK / NACK indication that configures the UE 102 to transmit a HARQ NACK for the dynamically scheduled multicast transmissions for which the UE 102 failed to obtain a transport block, and configures the UE 102 to transmit a HARQ ACK for the dynamically scheduled multicast transmissions that the UE 102 successfully received and from which the UE 102 obtained a transport block. In the event that the configuration parameters do not include this indication, the UE 102 does not transmit a HARQ ACK to the DU 174 for a dynamically scheduled multicast transmission that the UE 102 successfully receives and from which the UE 102 obtains a transport block. In some such cases, the UE 102 transmits only a HARQ NACK to the DU 174 for a dynamically scheduled multicast transmission at which the UE 102 fails to obtain a transport block. Another exemplary parameter is a HARQ ACK indication that configures the UE 102 to transmit a HARQ ACK for a dynamically scheduled multicast transmission that the UE 102 successfully receives and from which the UE 102 obtains a transport block. In the event that the configuration parameters do not include this indication, the UE 102 does not transmit a HARQ ACK to the DU 174 for a dynamically scheduled multicast transmission at which the UE 102 successfully obtains a transport block.In such cases, the UE 102 transmits only a HARQ NACK to the DU 174 for the dynamically scheduled multicast transmission for which the UE 102 failed 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 a HARQ ACK indication. Another exemplary parameter is a modulation and coding scheme (MCS) configuration that indicates the MCS table used by the DU 174 to transmit the dynamically scheduled multicast transmission and by the UE 102 to receive the dynamically scheduled multicast transmission. For example, the MCS table is a specific MCS table (e.g., 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 an MCS configuration in the DU configuration, UE 102 and DU 174 apply a predefined MCS table (e.g., defined in 3GPP specification 38.214). For example, the predefined MCS table is a 256QAM table or a 64QAM table (e.g., 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 an MCS configuration in the DU configuration, UE 102 and DU 174 apply an MCS table for unicast transmission to obtain the MCS configuration from DU 174. 174 receives a dynamically scheduled multicast transmission. In some implementations, DU 174 includes in the DU configuration a PDSCH configuration (e.g., a PDSCH-Config IE) that configures an MCS table for unicast transmissions. In other implementations, similar to events 516, 518, and 520, DU 174 transmits to UE 102 another DU configuration including the PDSCH configuration. Another exemplary parameter is an aggregation factor, which is the number of repetitions for the dynamically scheduled multicast transmission. In some implementations, DU 174 transmits (i.e., 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 an aggregation factor in the DU configuration, in some implementations, UE 102 applies an aggregation factor for unicast transmissions. In some implementations, DU 174 includes in the DU configuration an aggregation factor for unicast transmissions to UE 102. In other implementations, similar to events 516, 518, and 520, DU 174 transmits to the UE 102 another DU configuration including an aggregation factor for unicast transmission.

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

[0136] 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 SPS multicast configuration includes at least one of the following parameters for SPS multicast transmission. An exemplary 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 the G-CS-RNTI; and transmitting the DCI and the scrambled CRC on the PDCCH. After activating the SPS multicast radio resources, DU 174 periodically transmits 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 the UE 102 verifies that the CRC is valid, the UE 102 activates the SPS multicast radio resource in response to the DCI (e.g., starts receiving on the SPS multicast radio resource), and periodically receives multicast transmissions on the SPS multicast radio resource according to the SPS multicast radio resource activation command (e.g., DCI) before the UE 102 deactivates the SPS multicast radio resource. In such cases, the multicast transmission is the SPS multicast transmission used in the following description. In some implementations, the DU 174 deactivates or releases the SPS multicast radio resource by: generating an SPS multicast radio resource deactivation command (e.g., DCI); scrambling the CRC of the DCI with the G-CS-RNTI; and transmitting the DCI and the scrambled CRC on the PDCCH. The 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 the CRC is valid, UE 102 deactivates the SPS multicast radio resources (e.g., stops receiving on the SPS multicast radio resources). Depending on the implementation, each SPS multicast transmission 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) mapping of virtual resource blocks (VRBs) to physical resource blocks (PRBs); (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 exemplary parameter is periodicity, which indicates the periodicity of the SPS multicast radio resources.

[0137] Another exemplary parameter is the number of HARQ processes, which indicates the number of HARQ processes used to transmit SPS multicast transmissions. DU 174 uses at most the number of HARQ processes to transmit SPS multicast transmissions, and UE 102 uses at most the number of HARQ processes to receive SPS multicast transmissions. Another exemplary 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 the case where the configuration parameters do not include a HARQ codebook (ID), UE 102 uses a HARQ codebook (ID) for dynamically scheduled multicast transmissions, as described above. Alternatively, UE 102 uses a HARQ codebook (ID) for unicast transmissions. In some implementations, UE 102 receives the HARQ codebook (ID) for unicast transmission in the DU configuration from DU 174, as described above. Another exemplary parameter is a HARQ process ID offset, which indicates an offset for deriving a HARQ process ID for DU 174 to transmit SPS multicast transmissions and for UE 102 to receive SPS multicast transmissions. Another exemplary parameter is a PUCCH resource configuration for SPS multicast transmissions, which indicates the HARQ resources on the PUCCH at which UE 102 transmits 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 use a PUCCH resource configuration for dynamically scheduled multicast transmissions to transmit HARQ feedback, 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 exemplary parameter is a HARQ NACK-only indication, which configures the UE 102 to transmit 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 a dynamically scheduled multicast transmission. According to the indication, the UE 102 does not transmit 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, the UE 102 transmits 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.Another exemplary parameter is a HARQ ACK / NACK indication that configures the UE 102 to transmit a HARQ NACK for an SPS multicast transmission at which the UE 102 failed to obtain a transport block, and configures the UE 102 to transmit a HARQ ACK for an SPS multicast transmission that the UE 102 successfully received and from which the UE 102 obtained a transport block. In the event that the configuration parameter does not include this indication, the UE 102 does not transmit a HARQ ACK to the DU 174 for an SPS multicast transmission at which the UE 102 successfully received and from which the UE 102 obtained a transport block. In such a case, the UE 102 only transmits a HARQ NACK to the DU 174 for an SPS multicast transmission at which the UE 102 failed to obtain a transport block. Another exemplary parameter is a HARQ ACK indication that configures the UE 102 to transmit a HARQ ACK for an SPS multicast transmission at which the UE 102 successfully received and from which the UE 102 obtained a transport block. In the case where the configuration parameters do not include this indication, the UE 102 does not transmit a HARQ ACK to the DU 174 for the SPS multicast transmission for which the UE 102 successfully obtains the transport block. In such a case, the UE 102 transmits only a HARQ NACK to the DU 174 for the SPS multicast transmission for which the UE 102 fails to obtain the transport block. In some implementations, the DU 174 includes any one of a HARQ NACK indication, a HARQ ACK / NACK indication, and a HARQ ACK indication. Another exemplary parameter is an aggregation factor, which is the number of repetitions for the SPS multicast transmission. The DU 174 transmits multiple repetitions of the SPS multicast transmission according to the aggregation factor, and the UE 102 receives the repetition 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 the DU 174 apply the aggregation factor for dynamically scheduled multicast transmissions, as described above. Alternatively, UE 102 and DU 174 apply an aggregation factor for unicast transmission. In some implementations, UE 102 and DU 174 apply an aggregation factor for unicast transmission as described above. Another exemplary parameter is an MCS configuration, which indicates an MCS table used by DU 174 to transmit SPS multicast transmission and UE 102 to receive SPS multicast transmission. For example, the MCS table is a specific MCS table (e.g., 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 an MCS configuration in the DU configuration, UE 102 and DU 174 apply a predefined MCS table (e.g., defined in 3GPP specification 38.214).For example, the predefined MCS table is a 256QAM table or a 64QAM table (e.g., 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 an MCS configuration in the DU configuration, in other implementations, UE 102 and DU 174 apply an 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 an MCS table for unicast transmissions to receive SPS multicast transmissions from DU 174. In some implementations, UE 102 and DU 174 apply an 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 (eg, PDSCH-Config IE) in the DU configuration that configures the MCS table for unicast transmission. In other implementations, similar to events 516, 518, and 520, DU 174 transmits another DU configuration including the PDSCH configuration to UE 102.

[0138] In some implementations, CU-CP 172A includes an MBS session join response message in the RRC reconfiguration message. In other implementations, UE 102 includes an MBS session join complete message in an RRC reconfiguration complete message. Alternatively, UE 102 sends an UL RRC message including an MBS session join complete 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 an MBS session join complete message in a second BS to CN message. Alternatively, CU-CP 172A sends a BS to CN message (e.g., an uplink NAS transport message) including an MBS session join complete message to CN 110.

[0139] In other implementations, the CU-CP 172A transmits a DL RRC message including an MBS session join response message to the 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, the UE 102 sends a UL RRC message including an MBS session join complete message to the CU-CP 172A via the 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 NASPDU.

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

[0141] 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 at 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 at event 560.

[0142] Figure 5B Draws the Figure 5A . 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 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 second CN to BS message is received.

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

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

[0145] Figure 5C Draw and respectively Figure 5A and Figure 5B 00A and 500B are illustrated in FIG. 500C. 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 procedures, 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 procedures 592A or 592B may be omitted. In some implementations, CU-CP 172A transmits 527 the third BS to CN message to CN 110 before, during, or after procedures 592A or 592B.

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

[0147] In some implementations, CN 110 includes the first slice information in the 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.

[0148] Figure 5DAn exemplary scenario 500D is depicted in which the CN 110 and the base station 104 manage the transmission of downlink data for an MBS session to a UE operating in a connected state and 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 transmits 535 UE assistance information (e.g., a UEAssistanceInformation message) to the DU 174, the UE assistance information indicating that the UE 102 prefers or requests to transition to the inactive state or leave the connected state. The DU 174 then transmits 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.

[0149] In other implementations, the DU 174 performs data inactivity monitoring for the UE 102. In some such implementations, the CU-CP 172A transmits 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 transmits 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.

[0150] In yet other implementations, CU-UP 172B performs data inactivity monitoring for UE 102. In some such implementations, CU-CP 172A transmits 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 transmits 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, an inactivity notification of event 538, and / or an inactivity notification of event 540.

[0151] In some implementations, after a 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 has transmitted any data in the downlink direction or the uplink direction, respectively, during the period of data inactivity. In some implementations, CU-CP 172A determines 542 to transition UE 102 to an inactive state in response to the determination.

[0152] In response to or after determining that the UE 102 has data inactivity (e.g., for a certain period of time) or determining to transition the UE 102 to the inactive state, the CU-CP 172A sends 544 a bearer context modification request message to the CU-UP 172B to suspend unicast data transmission of the UE 102. In response, the CU-UP 172B suspends data transmission of the UE 102 and sends 546 a bearer context modification response message to the CU-CP 172A. In some implementations, in response to or after determining that the UE 102 has data inactivity or determining 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 (eg, a multicast indication for an inactive state) in the CU-to-DU message at event 548 to request multicast configuration parameters for the inactive state.

[0153] In other implementations, in response to the multicast request indication or the CU-to-DU message, the DU 174 transmits 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 request message) including the second multicast configuration parameters to the CU-CP 172A after receiving the CU-to-DU message of event 548 or after transmitting the DU-to-CU message of event 550. In some implementations, the CU-CP 172A transmits 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.

[0154] 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 a second multicast configuration parameter for the inactive state (e.g., if obtained from the DU 174) and / or an MRB configuration for the inactive state (e.g., a 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. The DU 174 then transmits 554 the RRC release message or the PDCP PDU to the UE 102. In some implementations, the DU 174 generates a MAC PDU including the RRC release message and transmits 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 transition 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., the RNTI is specific to UE 102) to monitor the PDCCH in response to the RRC release message or transition 556 to an inactive state. In some implementations, the UE-specific RNTI includes a C-RNTI of UE 102.

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

[0156] 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 using the G-RNTI and / or the G-CS-RNTI to receive the 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 does not suspend 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 the MBS data of the first MBS session via the MRB. In some implementations, the UE 102 does not reset the MAC entity in response to the RRC release message to continue 558 receiving or attempting to receive the MBS data of the first MBS session via the MAC entity.

[0157] In other implementations, the UE 102 stops or suspends receiving MBS data from the DU 174 in response to the RRC release message or transition 556 to an 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 receiving MBS data or when stopping or suspending receiving MBS data. In some implementations, when the DU 174 receives the MBS data (e.g., event 561), the DU 174 transmits (e.g., via multicast or broadcast) 557 a multicast reception indication to the UE 102 to indicate that the UE 102 receives the multicast transmission. In other implementations, 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 including a specific field (e.g., a short message) indicating that the UE 102 receives the multicast transmission. In some implementations, to transmit the DCI, the DU 174 generates a CRC for the DCI, scrambles the CRC using a paging radio network temporary identifier (P-RNTI), and transmits 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.

[0158] 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 some implementations, in response to the CU-to-DU message of event 552, 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.

[0159] 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 transmits 561 the MBS data to DU 174, similar to events 532 and 534, respectively. DU 174 transmits 563 the MBS data (e.g., via multicast) to UE 102, similar to event 536. For example, the MBS data includes one or more MBS data packets, and DU 174 transmits 563 one or more multicast transmissions, each of which includes a specific MBS data packet. UE 102 in the inactive state receives 563 the MBS data or multicast transmission according to the second multicast configuration parameters.

[0160] 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 receives MBS data for the first MBS session from DU 174 using the retained configuration parameters. Alternatively, UE 102 releases the configuration parameters augmented by the second multicast configuration parameters.

[0161] In some implementations, the first multicast configuration parameter includes a first configuration that configures the UE 102 to transmit 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 other implementations, the second multicast configuration parameter does not include the first configuration to instruct 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 that does not include the first configuration.

[0162] 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 other implementations, 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.

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

[0164] Figure 5E Draws the Figure 5D 526 and 528, respectively. In response, UE 102 transmits an RRC reconfiguration complete message 570 to DU 174, which in turn transmits a DU to CU message (including the RRC reconfiguration complete message) 572 to CU-CP 172A. In some implementations, DU 174 generates the second multicast configuration parameter in the same format as the first multicast configuration parameter, and the RRC reconfiguration message does not indicate the multicast configuration parameter. In some such cases, UE 102 is unaware that the second multicast configuration parameter is 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 parameter.

[0165] 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 (e.g., a multicast inactivity enabled indication) in the RRC release message, thereby indicating that UE 102 receives or continues to receive MBS data after transitioning to the inactive state. CU-CP 172A transmits 553 the RRC release message to DU 174, similar to event 552. DU 174 then transmits 555 the RRC release message to UE 102, similar to event 554. If CU-CP 172A transmits 567 an RRC reconfiguration message, CU-CP 172A transmits 553 the RRC release message after receiving 570 the RRC reconfiguration complete message. The UE 102 transitions 556 from the connected state to the inactive state in response to or upon receipt of the RRC release message.

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

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

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

[0169] Fig. 6A An exemplary scenario 600A is depicted in which a base station 104 manages an MBS session (eg, for FIG. 5A to FIG. 5E1. The first MBS session described above is described in detail with reference to FIG. 1. The first MBS session described above is described with reference to FIG. 1. The first MBS session described above is described with reference to FIG. 1. The first MBS session described above is described with reference to FIG. 1. The first MBS session described above is described with reference to FIG. 1. The first MBS session described above is described with reference to FIG. 1. The first MBS session described above is described with reference to FIG. 1. The first MBS session described above is described with reference to FIG. 1. The first MBS session described above is described with reference to FIG. 1. The first MBS session described above is described with reference to FIG. 1. The first MBS session described above is described with reference to FIG. 1. FIG. 5A to FIG. 5E Examples and implementations applicable to Fig. 6A The following discussion Fig. 6A Scenario 600A and FIG. 5A to FIG. 5E The differences between scenes 500A-E.

[0170] In scenario 600A, UE 102 initially operates in an inactive state 656. When UE 102 operates in an inactive state 656, CN 110 and base station 104 perform 697 MBS data transmission for a first MBS session with UE 102. In some implementations or scenarios, Fig. 6A Prior to the events shown, UE 102 transitions to an inactive state and receives MBS data for a first MBS session while operating in the inactive state, such as for Figure 5D and Figure 5E Later, the UE 102 operating in the inactive state initiates an RRC connection recovery procedure with the DU 174 via a cell (e.g., cell 124). In some implementations, the UE 102 initiates the RRC connection recovery procedure to transmit unicast data (e.g., data associated with an SRB or a DRB). In other implementations, the UE 102 receives a paging message from the DU 174 and initiates the RRC connection recovery procedure in response to the paging message. In other implementations, the UE 102 initiates the RRC connection recovery procedure for a periodic RAN Notification Area (RNA) update.

[0171] In response to initiating the RRC connection recovery procedure, UE 102A transmits 606 an RRC recovery request message (e.g., an RRCResumeRequest message) to DU 174. In some implementations, UE 102 performs a random access procedure with DU 174 via a cell to transmit the RRC recovery request message. In some implementations, the random access procedure is a two-step random access procedure, and UE 102 transmits message A including the RRC recovery request message to DU 174 during the random access procedure. In other implementations, the random access procedure is a four-step random access procedure, and UE 102 transmits message 3 including the RRC recovery request message to DU 174 during the random access procedure. DU 174 then transmits 607 an initial UL RRC messaging message including the RRC recovery request to CU-CP 172A. In some implementations, UE 102 suspends 605 MBS data reception of the first MBS session in response to the initiation. In other implementations, the UE 102 does not suspend MBS data reception for the first MBS session during or after initiating the RRC connection recovery procedure.

[0172] After receiving the RRC resume request message at event 607 (e.g., in response thereto), CU-CP 172A sends 622 a first CU-to-DU message (e.g., a UE context setup request message) to DU 174. In some implementations, CU-CP 172A includes a first MBS session ID (e.g., MBS session ID 1) and / or MRBID in the first CU-to-DU message, similar to event 522. In some implementations, CU-CP 172A includes first multicast configuration parameters in the first CU-to-DU message. In some implementations, the first multicast configuration parameters include multicast configuration parameters used by UE 102 and DU 174 for multicast communication at event 697. In some implementations, the first multicast configuration parameters include multicast configuration parameters used by UE 102 and DU 174 for multicast communication (e.g., transmitting MBS data for the first MBS session) when UE 102 operates in a connected state before event 656. In some other implementations, CU-CP 172A includes in the first CU to DU message the first unicast configuration parameters used by UE 102 and DU 174 for unicast communication when UE 102 operates in a connected state before event 656. In other implementations, the first unicast configuration parameters include configuration parameters included in the CellGroupConfig IE and defined for unicast communication. In some implementations, the first multicast configuration parameters include configuration parameters included in the CellGroupConfig IE and defined for multicast communication. In other implementations, CU-CP 172A includes the first unicast configuration parameters and the first multicast configuration parameters in a first container IE (e.g., a CU to DU RRC information IE or a first CellGroupConfig IE) and includes the first container IE in the first CU to DU message.

[0173] In response to the first CU to DU message of event 622, DU 174 sends 624 a first DU to CU message (e.g., a UE context setup response message) including a second unicast configuration parameter to CU-CP 172A. In some implementations, DU 174 generates a second unicast configuration parameter to augment the first unicast configuration parameter. In such implementations, the second unicast configuration parameter is an incremental configuration on top of the first unicast configuration parameter. In other implementations, DU 174 generates a second unicast configuration parameter to replace the first unicast configuration parameter. In such implementations, the second unicast configuration parameter is a complete configuration (i.e., a complete and self-contained configuration). In some implementations, DU 174 includes in the UE context setup response message a second multicast configuration parameter for UE 102 to receive MBS data for the first MBS session. In some implementations, DU 174 generates a second multicast configuration parameter to augment the first multicast configuration parameter. In such implementations, the second multicast configuration parameter is an incremental configuration on top of the first multicast configuration parameter. In other implementations, the DU 174 generates the second multicast configuration parameters to replace the first multicast configuration parameters. In such implementations, the second multicast configuration parameters are a complete configuration (ie, a complete and independent configuration).

[0174] In some implementations, the second unicast configuration parameters include configuration parameters included in the CellGroupConfig IE and defined for unicast communication. In other implementations, the second multicast configuration parameters include configuration parameters included in the CellGroupConfig IE and defined for multicast communication. In some implementations, the CU-CP 172A includes the second unicast configuration parameters and the second multicast configuration parameters in a first container IE (e.g., a CU to DU RR information IE or a second CellGroupConfig IE) and includes the second container IE in the first DU to CU message. In other implementations, the second multicast configuration parameters include configuration parameters included in the CellGroupConfig IE and defined for multicast communication. FIG. 5A to FIG. 5E The examples and / or implementations of the described multicast configuration parameters apply to the first multicast configuration parameters and / or the second multicast configuration parameters. In other implementations, if the DU 174 determines that the first multicast configuration parameters are still suitable for multicast communication with the UE 102, the DU 174 does not include the multicast configuration parameters (e.g., the second multicast configuration parameters) in the first DU to CU message. Similarly, if the DU 174 determines that the first unicast configuration parameters are still suitable for unicast communication with the UE 102, the DU 174 does not include the unicast configuration parameters (e.g., the second unicast configuration parameters) in the first DU to CU message.

[0175] After receiving 624 the first DU to CU message, the CU-CP 172A generates an RRC recovery message (e.g., an RRCResume message). In the case where the first DU to CU message includes a second unicast configuration parameter and / or a second multicast configuration parameter, the CU-CP 172A includes the second unicast configuration parameter and / or the second multicast configuration parameter in the RRC recovery message. In some implementations, if the CU-CP 172A determines to configure or reconfigure the MRB for the first MBS session, the CU-CP 172A includes the MRB configuration used to configure or reconfigure the MRB in the RRC recovery message. Otherwise, the CU-CP 172A does not include the MRB configuration in the RRC recovery message. Then, the CU-CP 172A transmits 616 a second CU to DU message (e.g., a DL RRC messaging message) including the RRC recovery message to the DU 174. The DU 174 then transmits 618 the RRC recovery message to the UE 102. In response to the RRC recovery message, UE 102 transitions 604 from the inactive state to the connected state. UE 102 in the connected state then transmits 626 an RRC recovery complete message (e.g., an RRCResumeComplete message) to DU 174, which in turn sends 628 a second DU-to-CU message (e.g., an UL RRC messaging message) including the RRC recovery complete message to CU-CP 172A. Events 606, 607, 622, 624, 616, 618, 612, 614, 604, 626, and 628 are grouped as an RRC connection recovery procedure (with state transitions) 686A.

[0176] In some implementations, after receiving the first DU to CU message or transmitting the RRC resume message, CU-CP 172A sends 612 a CP to UP message (e.g., a bearer context modification request message) to CU-UP 172B to restore the DRB configured by CU-CP 172A for UE 102 (e.g., for unicast communication with UE 102). In some cases where CU-CP 172A does not configure DRBs for UE 102 and configures MRBs for UE 102, CU-CP 172A does not transmit the CP to UP message to CU-UP 172B. In other implementations, if CU-CP 172A configures DRBs for UE 102, CU-CP 172A includes the DRBID of the DRB in the CP to UP message to restore the DRB. In response to the CP to UP message, CU-UP 172B sends 614 a UP to CP message (e.g., a bearer context modification response message) to CU-CP 172A. In some implementations, the CU-UP 172B includes the DRBID of the DRB in the UP to CP message to indicate a successful DRB recovery operation.

[0177] In the case where the UE 102 suspends MBS data reception at event 605, the UE 102 in the connected state resumes 630 receiving MBS data for the first MBS session from the DU 174 after receiving the RRC resume message. In some implementations, the CN 110 and the base station 104 then perform 696 MBS data transmission for the first MBS session with the UE 102 operating in the connected state. In some cases where the UE 102 does not suspend MBS data reception after initiating the RRC connection recovery procedure, the UE 102 continues to perform or performs MBS data reception for the first MBS session during or after the RRC connection recovery procedure. Depending on the implementation, the UE 102 in the connected state performs multicast communication (e.g., including receiving MBS data for the first MBS session) with the DU 174 according to the first multicast configuration parameter, the second multicast configuration parameter, or the configuration parameters of the second multicast configuration parameter and / or the first multicast configuration parameter that is not augmented by the second multicast configuration parameter. Similarly, depending on the implementation, the UE 102 in the connected state performs unicast communication with the DU 174 according to the first unicast configuration parameter, the second unicast configuration parameter, or the second unicast configuration parameter and / or the first unicast configuration parameter not augmented by the second unicast configuration parameter.

[0178] The base station 104 and the UE 102 may perform 688 respectively with Figure 5D or Figure 5E After performing the RRC state transition procedure at event 688 (e.g., in response thereto), UE 102 transitions 657 to the inactive state. In some implementations, after UE 102 transitions to the inactive state at event 657, UE 102 performs or continues 658 to perform the following steps: Figure 5D or Figure 5E The CN 110 and the base station 104 then perform 698 MBS data transmission for the first MBS session with the UE 102 operating in the inactive state.

[0179] Figure 6B An exemplary scenario 600B is depicted that is similar to scenario 600A, in which base station 104 instructs UE 102 to remain in an inactive state during the RRC connection recovery process, rather than causing UE 102 to transition to a connected state. Figure 6B The scene 600B and Fig. 6A The difference between the scenarios 600A.

[0180] In some implementations, after receiving the RRC resume request message at event 607, CU-CU 172A sends 648 a UE context setup request message to DU 174, the message including a first MBS session ID (e.g., MBS session ID 1) and / or an MRBID and / or a multicast indication of an inactive state, similar to events 548 and 622. In some implementations, CU-CP 172A includes a first multicast configuration parameter for the inactive state in the UE context setup request message, and when UE 102 operates in the inactive state at event 656, UE 102 and DU 174 use the first multicast configuration parameter for multicast communication of MBS data for the first MBS session. In other implementations, CU-CP 172A does not include a multicast configuration parameter (e.g., a first multicast configuration parameter for the inactive state) in the UE context setup request message. In some implementations, in response to the UE context setup request message, DU 174 sends 650 a UE context setup response message to CU-CP 172A, similar to events 550 and 624. In other implementations, DU 174 includes a second multicast configuration parameter for the inactive state in the UE context setup response message (e.g., a second multicast configuration parameter for UE 102 operating in the inactive state to receive a multicast transmission including MBS data from DU 174).

[0181] In some implementations, DU 174 generates a second multicast configuration parameter to augment the first multicast configuration parameter for the inactive state. In such implementations, the second multicast configuration parameter for the inactive state is an incremental configuration on top of the first multicast configuration parameter for the inactive state. In other implementations, DU 174 generates a second multicast configuration parameter for the inactive state to replace the first multicast configuration parameter for the inactive state. In such implementations, the second multicast configuration parameter is a complete configuration (i.e., a complete and independent configuration). In other implementations, if DU 174 determines that the first multicast configuration parameter is still appropriate for UE 102, DU 174 does not include the multicast configuration parameter (e.g., the second multicast configuration parameter for the inactive state) in the UE context setup response message.

[0182] Unlike the scenario 600A, the CU-CP 172A in the scenario 600B does not perform the bearer context modification process (eg, events 612 and 614 ) with the CU-UP 172B.

[0183] In some implementations, CU-CP 172A does not include unicast configuration parameters in the UE context setup request message. In other implementations, CU-CP 172A includes the first unicast configuration parameters in the UE context setup request message, similar to event 622, but DU 174 ignores the first unicast configuration parameters. In some implementations, DU 174 does not include unicast configuration parameters in the UE context setup response message.

[0184] After receiving 650 the UE context setup response message, CU-CP 172A generates an RRC release message (e.g., an RRCRelease message) instead of an RRC resume message, such as event 622. In the case where the UE context setup response message includes a second multicast configuration parameter for an inactive state, CU-CP 172A includes the second multicast configuration parameter for the inactive state in the RRC release message. In some implementations, if CU-CP 172A determines to configure or reconfigure the MRB for the first MBS session, CU-CP 172A includes the MRB configuration used to configure or reconfigure the MRB in the RRC release message. Otherwise, CU-CP 172A does not include the MRB configuration in the RRC release message. CU-CP 172A sends 652, 654 RRC release messages to UE 102 via DU 174, similar to events 552 and 554, respectively. In response to the RRC release message, UE 102 remains in an inactive state. Events 606, 607, 648, 650, 652, and 654 are grouped as RRC Connection Recovery Procedure (Stateless Transition) 686B.

[0185] In the case where UE 102 suspends MBS data reception at event 605, UE 102 resumes 630 receiving MBS data for the first MBS session from DU 174 after receiving the RRC release message (e.g., in response to the RRC release message). Thereafter, CN 110 and base station 104 perform 698 MBS data transmission for the first MBS session with UE 102 operating in an inactive state, similar to event 697. In some cases where UE 102 does not suspend MBS data reception after initiating the RRC connection recovery procedure, UE 102 continues to perform or perform MBS data reception for the first MBS session during or after the RRC connection recovery procedure. Depending on the implementation, the UE 102 in the inactive state performs multicast communication (e.g., including receiving MBS data of the first MBS session) with the DU 174 according to the first multicast configuration parameter for the inactive state, the second multicast configuration parameter for the inactive state, or the second multicast configuration parameter and / or the configuration parameter of the first multicast configuration parameter for the inactive state that is not expanded by the second multicast configuration parameter for the inactive state.

[0186] Figure 6C An exemplary scenario 600C is depicted which is similar to scenarios 600A and 600B. Fig. 6A and Figure 6B Similar events to those discussed in the Fig. 6A and Figure 6B Examples and implementations applicable to Figure 6C . After receiving the RRC recovery request message (e.g., in response to the RRC recovery request message), CU-CP 172A generates an RRC release message including a multicast inactivity enablement indication, and sends 653, 655 the RRC release message to UE 102 via DU 174, similar to events 553 and 555. Unlike scenario 600A, CU-CP 172A in scenario 600C does not perform a bearer context modification procedure with CU-UP 172B (e.g., events 612 and 614). In addition, unlike scenario 600B, CU-CP 172A in scenario 600C does not perform a UE context setup procedure with DU 174 (e.g., events 648 and 650) after receiving the RRC recovery request message. After receiving the multicast inactivity enabling indication in the RRC release message, the UE 102 in the inactive state performs multicast communication with the DU 174 according to the first multicast configuration parameter for the inactive state (e.g., including receiving MBS data of the first MBS session). If the RRC release message does not include the multicast inactivity enabling indication, the UE 102 in the inactive state stops performing multicast communication (e.g., stops receiving MBS data of the first MBS session).

[0187] Events 606, 607, 653, and 655 are grouped as an RRC connection recovery procedure (stateless transition) 686C.

[0188] Next turn Fig. 7A , which depicts an exemplary scenario 700A similar to scenario 600A, in which the UE 102 in an inactive state is receiving an MBS session (e.g., for FIG. 5A to FIG. 5EThe base station 106 receives MBS data of the first MBS session described above and moves to the coverage of the base station 106. The base station 106 includes a DU 174, a CU-CP 172A, and a CU-UP 172B. Events in this scenario that are similar to events discussed above are labeled with similar reference numbers (e.g., events 756, 797, 792, 705, 706, 707, 712, 714, 716, 718, 722, 724, 704, 726, 728, 786A, 730, 796, 788, 757, 758, and 798 are similar to events 656, 697, 592A-C, 605, 606, 607, 612, 614, 616, 618, 622, 624, 604, 626, 628, 686A, 630, 696, 688, 657, 658, and 698, respectively), and FIG. 5A to FIG. 5E as well as FIG. 6A to FIG. 6C Examples and implementations applicable to Fig. 7A The following discussion Fig. 7A Scene 700A with Fig. 6A The difference between the scenarios 600A.

[0189] In scenario 700A, UE 102 initially operates in an inactive state 756. In some implementations, Fig. 7A Prior to the events shown, UE 102 transitions to an inactive state and receives MBS data for a first MBS session while operating in the inactive state, such as for FIG. 5D to FIG. 5E as well as FIG. 6A to FIG. 6C As described. Later, the inactive UE 102 performs cell selection or reselection on a cell of the base station 106 (e.g., cell 126), and initiates an RRC connection recovery process with the base station 106 via the cell. In response to initiating the RRC connection recovery process, the UE 102 transmits 706 an RRC recovery request message (e.g., an RRCResumeRequest message) to the DU 174, and the DU 174 then transmits the RRC recovery request message to the CU-CP 172A. After receiving the RRC recovery request message (e.g., in response to receiving the RRC recovery request message), the CU-CP 172A sends 708 a retrieve UE context request message to the base station 104 (e.g., the CU-CP of the base station 104). In response, the base station 104 sends 709 a retrieve UE context response message including the UE context of the UE 102 to the CU-CP 172A. In some implementations, the UE context includes multicast configuration parameters and unicast configuration parameters for multicast communication and unicast communication respectively configured by the base station 104 for the UE 102. In some implementations, the multicast configuration parameters are for Fig. 6AIn other implementations, the unicast configuration parameter is for Fig. 6A In some implementations, the base station 104 includes DRB information in the retrieve UE context response message, the DRB information including a DRB ID identifying the DRB configured by the base station 104 for the UE 102 .

[0190] In some implementations, after receiving the retrieve UE context response message, CU-CP 172A sends 710 a CP to UP message (e.g., a bearer context setup request message) to CU-UP 172B to establish a bearer context for the DRB. In response, CU-UP 172B establishes a bearer context for the DRB and sends 711 a UP to CP message (e.g., a bearer context setup response message) to CU-CP 172A. In some implementations, after transmitting an RRC recovery message at event 716 or receiving an RRC recovery complete message at event 728, CU-CP 172A sends 732 a path switch request message to CN 110 to switch the downlink termination point of the NG-U tunnel associated with UE 102 to CU-CP 172A. In response, CN 110 sends 734 a path switch response message to CU-CP 172A.

[0191] Events 706, 707, 710, 711, 722, 724, 716, 718, 712, 714, 704, 726, and 728 are grouped as an RRC connection recovery procedure (with state transitions) 786A.

[0192] Figure 7B An exemplary scenario 700B similar to scenarios 700A and 600B is depicted, wherein the UE 102 in an inactive state is receiving an MBS session (eg, for a FIG. 5A to FIG. 5E The UE 102 receives the MBS data of the first MBS session described in the above description and moves to the coverage of the base station 106. In addition, the base station 106 instructs the UE 102 to remain in an inactive state during the RRC connection recovery process instead of transitioning the UE 102 to a connected state. Fig. 7A and Figure 6B Similar events to those discussed in the present invention are labeled with similar reference numerals (e.g., events 756, 797, 705, 706, 707, 748, 750, 752, 754, 786B, 730, and 798 are similar to events 656, 697, 605, 606, 607, 648, 650, 652, 654, 686B, 630, and 698, respectively), and Fig. 7A and Figure 6BExamples and implementations applicable to Figure 7B The following discusses Fig. 7A , Figure 7B and Figure 6B The difference between.

[0193] Prior to receiving the RRC resume request message at event 706 or 707, base station 106 performs 792 an MBS session resource configuration procedure with CN 110 to configure radio resources for the first MBS session, similar to procedures 592A, 592B, and / or 592C. In some implementations, after configuring the radio resources for the first MBS session, base station 106 transmits (e.g., multicasts) MBS data for the first MBS session to a UE operating in an inactive state or a connected state via one or more cells (e.g., cell 126). After UE 102 performs 786B an RRC connection resume procedure (stateless transition) with base station 106, CN 110 and base station 106 then perform 798 MBS data transmission for the first MBS session with UE 102 operating in an inactive state.

[0194] In some cases where the retrieve UE context response message includes DRB information for UE 102, CU-CP 172A includes a suspension indication (e.g., a bearer context state change IE) in the bearer context setup request message of event 710, thereby instructing CU-UP 172B to suspend DRBs for UE 102. CU-UP 172B suspends DRBs for UE 102 in response to the suspension indication. Alternatively, CU-CP 172A does not include a suspension indication in the bearer context setup request message. In some such implementations, CU-CP 172A sends a UE context modification request message including a suspension indication (e.g., a bearer context state change IE) to CU-CP 172B, and receives a UE context modification response message in response, similar to events 712 and 174. CU-UP 172B suspends DRBs for UE 102 in response to the suspension indication received in the UE context modification request message. In the event that the retrieve UE context response does not include DRB information for UE 102, CU-CP 172A does not send a bearer context setup request message to CU-UP 172B. In such a case, events 710 and 711 are omitted.

[0195] Events 706, 707, 712, 714, 748, 750, 752, and 754 are Figure 7B It is collectively referred to as the RRC connection recovery process (stateless transition) 786B.

[0196] Figure 7CAn exemplary scene 700C is depicted which is similar to scenes 700A, 700B, and 600C. Fig. 7A , Figure 7B and Figure 6C Similar events to those discussed in the present invention are labeled with similar reference numerals (e.g., events 756, 797, 705, 706, 707, 753, 755, 786C, 730, and 798 are similar to events 656, 697, 605, 606, 607, 648, 650, 652, 654, 686C, 630, and 698, respectively), and Fig. 7A , Figure 7B and Figure 6C Example 7B and implementations may be applicable to Figure 7C .

[0197] Events 706, 707, 710, 711, 753, and 755 are Figure 7C It is collectively referred to as the RRC connection recovery process (stateless transition) 786C.

[0198] Fig.7D An exemplary scenario 700D similar to scenarios 700A-700C is depicted, wherein CN 110 and base stations 104 and 106 simultaneously manage transmission of downlink data for an MBS session, and UE 102 in an inactive state continues MBS data reception from base station 104 to base station 106 after UE inactive mobility operation without performing an RRC connection recovery procedure.

[0199] Similar to scenarios 700A-700C, UE 102 in scenario 700D transitions 756 to an inactive state and performs 797 MBS data reception for a first MBS session with CN 110 and base station 104. UE 102 in the inactive state later moves from the coverage of base station 104 to the coverage of base station 106. After UE 102 camps on a cell (e.g., cell 126) of base station 106, UE 102 continues 758 to receive MBS data for the first MBS session from base station 106. UE 102 then receives 798 MBS data transmission for the first MBS session from base station 106 and CN 110.

[0200] In some implementations, when the multicast configuration parameters are the same, the UE 102 continues 758 to receive the MBS data for the first MBS session after the mobility operation because the MRB configuration for the inactive state and / or the MC configuration parameters for the inactive state are applied across the base stations 104 and 106. Therefore, the UE 102 applies the same multicast configuration parameters to receive multicast transmissions (e.g., including the MBS data for the first MBS session) from the base station 104 and the base station 106. In other implementations, because the MRB configuration for the inactive state and / or the multicast configuration parameters for the inactive state provided by the base station 104 to the UE 102 include the multicast configuration parameters of the cell of the base station 106, the UE 102 continues 758 to receive the MBS data for the first MBS session after the mobility. When the UE 102 camps on the cell of the base station 106, the UE 102 applies the multicast configuration parameters for the cell of the base station 106.

[0201] Now turn to FIG. 8A to FIG. 10B , which generally illustrate various methods by which a RAN node configures and performs unicast and / or multicast communications with a UE in an inactive state and following an RRC state transition. FIG. 8A to FIG. 8C It is illustrated that the UE is configured to perform MBS data reception in an inactive state and during or after performing an RRC recovery procedure. Fig. 9 It is illustrated that the UE is configured to perform MBS data reception in an inactive state, and determines whether to continue the MBS data reception after performing an RRC recovery procedure. FIG. 10A to FIG. 10B It is illustrated that the UE is configured to perform MBS data reception in an inactive state and resume the MBS data reception after performing an RRC resumption procedure via a second cell of the RAN.

[0202] First reference Fig. 8A , when a UE (e.g., UE 102) is operating in an inactive state and during or after performing an RRC recovery procedure, the UE may implement exemplary method 800A to perform MBS data reception from a RAN (e.g., BS 104 or 106, CU 172, CU-CP 172A, or DU 174).

[0203] Method 800A begins at block 802, where the UE receives one or more RRC messages including first multicast configuration parameters and / or first MRB configuration from the RAN (e.g., events 528, 594, 554, 588, 568, 555, 589, 616, 618, 686A, 688, 652, 654, 686B, 653, 655, 686C, 716, 718, 786A, 788, 752, 754, 786B, 753, 755, 786C). At block 804, the UE performs MBS data reception to receive MBS data for an MBS session from the RAN via a first cell according to the first multicast configuration parameters and / or the first MRB configuration when operating in an inactive state (e.g., events 563, 597, 697, 698, 797, 798). At block 806, the UE performs an RRC connection recovery procedure with the RAN via the first cell (e.g., events 606, 607, 616, 618, 626, 628, 686A, 652, 654, 686B, 653, 655, 686C, 706, 707, 716, 718, 726, 728, 786A, 752, 754, 786B, 753, 755, 786C). At block 808, the UE continues MBS data reception while performing the RRC recovery procedure. At block 810, the UE continues MBS data reception after performing the RRC recovery procedure (e.g., events 696, 796).

[0204] Figure 8B 800A, except that method 800B includes blocks 809 and 811 instead of blocks 808 and 810. After block 806, the flow proceeds to block 809, where the UE suspends MBS data reception while performing an RRC connection recovery procedure (e.g., events 605, 705). At block 811, the UE resumes MBS data reception after performing an RRC recovery procedure (e.g., events 630, 730).

[0205] Figure 8C 800A or 800B, except that method 800C includes blocks 805 , 807 , and 812 instead of blocks 806 and 808 .

[0206] After block 804, the flow proceeds to block 805, where the UE initiates a random access procedure with the RAN via the first cell. At block 807, the UE suspends MBS data reception when initiating the random access procedure (e.g., events 605, 705). At block 812, the UE resumes MBS data reception after receiving a random access response, message B, or completing the random access procedure (e.g., events 630, 730).

[0207] refer to Fig. 9 When a UE (e.g., UE 102) is operating in an inactive state and determines whether to resume MBS data reception after performing an RRC recovery procedure, the UE may implement exemplary method 900 to perform MBS data reception from a RAN (e.g., BS 104 or 106, CU 172, CU-CP 172A, or DU 174).

[0208] Method 900 is similar to Fig. 8A 804 and 806 of . At block 908, the UE receives a DL RRC message of an RRC connection recovery procedure from the RAN (e.g., events 616, 618, 652, 654, 653, 655, 716, 718, 752, 754, 753, 755). At block 910, the UE determines whether the DL RRC message configures MBS data reception. If the DL RRC message configures MBS data reception at block 910, the flow proceeds to block 912, where the UE performs the actions described in block 810 or 811. If the DL RRC message does not configure MBS data reception at block 910, the flow proceeds to block 914, where the UE releases the multicast configuration parameters and / or MRB configuration.

[0209] In some implementations, the DL RRC message is an RRC recovery message. In other implementations, the DL RRC message is an RRC release message. In some implementations, the DL RRC message does not include a specific IE (related to multicast communication or MBS) and indicates that the UE releases the multicast configuration parameters and / or MRB configuration. In such implementations, not including the specific IE is an implicit release indication to indicate the release of the multicast configuration parameters and / or MRB configuration. In other implementations, the DL RRC message includes an explicit indication of the release of the multicast configuration parameters and / or MRB configuration.

[0210] refer to Fig. 10A , a UE (eg, UE 102) may implement exemplary method 1000A to perform MBS data reception from a RAN (eg, BS 104 or 106, CU 172, CU-CP 172A, or DU 174).

[0211] Method 1000A begins with Fig. 8AAt block 1006, the UE determines to reselect the second cell and / or reselect the second cell from the first cell. At block 1008, the UE suspends MBS data reception in response to the determination or reselection (e.g., events 605, 705). At block 1010, the UE performs an RRC connection recovery procedure with the RAN via the second cell (e.g., events 706, 707, 716, 718, 726, 728, 786A, 752, 754, 786B, 753, 755, 786C). At block 1012, the UE resumes MBS data reception after performing the RRC recovery procedure (e.g., events 630, 730).

[0212] Fig. 10B is a flow chart of an exemplary method 1000B that is similar to methods 1000A and 900 , except that method 1000B also includes blocks 1009 , 1011 , 1013 , 1012 , and 1014 . Fig. 9 and / or Fig. 10A Examples and / or implementations of may be applicable to method 1000B.

[0213] After block 1008, the flow proceeds to block 1009, where the UE transmits an RRC recovery request message to the RAN via the second cell (e.g., event 706). At block 1011, the UE receives a DL RRC message from the RAN in response to the RRC recovery request message (e.g., events 716, 718, 752, 754, 753, 755). At block 1013, the UE determines whether the DL RRC message configures MBS data reception. If the DL RRC message configures MBS data reception, the flow proceeds to block 1012, where the UE resumes MBS data reception after performing an RRC recovery procedure (e.g., event 730).

[0214] If the DL RRC message does not configure MBS data reception, flow proceeds to block 1014 where the UE releases the multicast configuration parameters and / or MRB configuration.

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

[0216] In general, the description of one of the figures above may apply to another figure in the figures above. The events or boxes described above may be optional or omitted. For example, an event or box with a dashed line in the figure may be optional or omitted. In some cases, if an event or box with a solid line in the figure is not required, the event or box may still be optional or omitted. In some implementations, "message" is used and "information element (IE)" can be used to replace "message". In some implementations, "IE" is used and "field" can be used to replace "IE". In some implementations, "configuration" or "configuration parameter" can be used to replace "configuration". In some implementations, "MBS" can be replaced with "multicast" or "multicast MBS". In some implementations, "MBS data" can be replaced with "multicast transmission". 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, “SPS multicast” may be replaced with “multicast SPS”. Similarly, “dynamically scheduled multicast” may be replaced with “multicast dynamic”. In some implementations, “identifier” may be replaced with “identity”. In some implementations, “CFR” is used and “MBS BWP” may be replaced with “CFR”. In some implementations, the term “transport layer configuration” may be replaced with “tunnel information” or “transport layer information”. In some implementations, “using” may be replaced with “according to”. In some implementations, “unicast communication” may be replaced with “unicast data communication”.

[0217] 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 or an advanced driver assistance system (ADAS) of a vehicle. 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.

[0218] 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., a code stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit that can perform certain operations and can be configured or arranged in a particular 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 a programmable logic or circuit system (e.g., contained 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 with a dedicated and permanently configured circuit system or with a temporarily configured circuit system (e.g., configured by software) may be driven by cost and time considerations.

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

[0220] After reading this disclosure, those skilled in the art will understand additional alternative structural and functional designs for performing HARQ processes to transmit 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 constructions 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 user equipment UE, the method comprising: receiving MBS data from a radio access network RAN ​​in a first cell and in an inactive state in which a radio connection between the UE and the RAN is suspended according to a multicast configuration; Determine to reselect from the first cell to a second cell; In response to the determining to reselect, suspending the receiving of the MBS data; as well as After the radio connection is restored via the second cell, the reception of the MBS data is restored in the second cell.

2. The method of claim 1, wherein the suspending the reception of the MBS data comprises suspending an MBR radio bearer (MRB).

3. The method of claim 1 or 2, wherein the suspending the reception of the MBS data comprises suspending a Packet Data Convergence Protocol (PDCP) entity.

4. The method of any preceding claim, wherein said suspending said reception of said MBS data comprises ceasing to monitor a Physical Downlink Control Channel (PDCCH) using a group Radio Network Temporary Identifier (RNTI).

5. A method as claimed in any one of the preceding claims, wherein: The MBS data received in the first cell and in the inactive state and the MBS data received in the second cell after resuming the radio connection are associated with the same MBS session.

6. The method of claim 5, wherein the MBS session is associated with a Temporary Mobile Group Identity (TMGI).

7. The method of any one of the preceding claims, wherein the resuming the radio connection via the second cell comprises: A radio resource control (RRC) resumption request is sent in the second cell.

8. The method of claim 7, further comprising: In response to the RRC recovery request, receiving a downlink DLRRC message, Wherein said resuming said reception of said MBS data in said second cell is in response to said DL RRC message configuring said reception of said MBS data in said second cell.

9. The method of claim 8, wherein the DL RRC message includes an information element (IE) indicating that the UE is to retain the multicast configuration.

10. The method of claim 8, wherein the DL RRC message does not include an (IE) indicating that the UE is to release the multicast configuration.

11. The method according to any one of claims 8 to 10, wherein the DL RCC message is a RRC release command.

12. A method as claimed in any preceding claim, wherein the multicast configuration comprises scheduling parameters.

13. The method of any preceding claim, wherein the multicast configuration comprises parameters of a Multicast Traffic Channel (MTCH).

14. The method according to claim 8, wherein said resuming said receiving of said MBS data in said second cell occurs in a first instance; The method further comprises: In a second example, in response to receiving the DL RRC message, an MBS configuration associated with the MBS data is released.

15. A user equipment (UE), comprising: Transceiver; as well as Processing hardware configured to implement according to any of the preceding claims.

Images