Management of Multicast Reception in Inactive State

Abstract

A radio access network (RAN) participating in a multicast and broadcast service (MBS) session can implement a method for managing MBS communications. The method includes: (a) transmitting, to a UE operating in a connected state, a first multicast configuration including a first MBS radio bearer (MRB) configuration for receiving MBS data in the connected state; (b) transmitting, according to the first multicast configuration, the first MBS data to the UE operating in the connected state; (c) transmitting, to the UE, a second multicast configuration including a second MRB configuration for receiving MBS data in a non-active state; and (d) transmitting, according to the second MRB configuration, the second MBS data to the UE operating in the non-active state.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 388,303, filed on July 12, 2022, entitled "MANAGING MULTICAST RECEPTION IN AN INACTIVE STATE", the entire content of the provisional application being hereby expressly incorporated by reference herein.

[0002] This disclosure relates to wireless communication, and more particularly, to enabling reception of one or more multicast and / or broadcast services (MBS) in a user equipment (UE) operating in an inactive state.

Background Art

[0003] For the purpose of generally presenting the context of the present disclosure, the background art provided herein is described. In the scope described in this background art section, the research of the inventors named herein, as well as aspects of the description that could not be considered prior art at the time of filing, are not admitted as prior art to the present disclosure, either expressly or implicitly.

[0004] In a telecommunication system, the packet data convergence protocol (PDCP) sublayer of the radio protocol stack provides services such as transfer, encryption, and integrity protection of user plane data. For example, the PDCP sublayer provides sequencing of protocol data units (PDUs) in the uplink direction from a user device (also known as a user equipment or "UE") to a base station (BS), as well as in the downlink direction from the base station to the UE. The PDCP sublayer also provides services for signaling radio bearers (SRBs) to the radio resource control (RRC) sublayer. The PDCP sublayer further provides services for data radio bearers (DRBs) to a service data adaptation protocol (SDAP) sublayer, or protocol layers such as an Internet protocol (IP) layer, an Ethernet protocol layer, and an Internet control message protocol (ICMP) layer. Generally, the UE and the base station exchange RRC messages and non-access stratum (NAS) messages using SRBs, and transmit data in the user plane using DRBs, depending on the scenario.

[0005] In some scenarios, the UE simultaneously utilizes the resources of multiple nodes (e.g., base stations, or components of a distributed base station or disaggregated base station) of a radio access network (RAN) interconnected by a backhaul. When such network nodes support different radio access technologies (RATs), this type of connection is referred to as multi-radio dual connectivity (MR-DC). When operating in MR-DC, the cell(s) associated with the base station operating as the master node (MN) define a master cell group (MCG), and the cell(s) associated with the base station operating as the secondary node (SN) define a secondary cell group (SCG). The MCG covers a primary cell (PCell) and zero, one, or multiple secondary cells (SCells), and the SCG covers a primary-secondary cell (PSCell) and zero, one, or multiple SCells. The UE communicates with the MN via the MCG and with the SN via the SCG. In other scenarios, the UE utilizes the resources of a single base station at a time in a single connection (SC). The UE within an 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 hand over the UE to another base station and initiates a handover procedure. In other scenarios, the UE simultaneously utilizes the resources of other RAN nodes (e.g., base stations, or components of a distributed base station or disaggregated base station) interconnected by a backhaul.

[0006] Depending on the scenario, the UE uses several types of SRBs and DRBs. The "SRB1" resource conveys RRC messages, which in some cases include NAS messages, via the dedicated control channel (DCCH), and the "SRB2" resource supports RRC messages, which include logged measurement information or NAS messages, via the DCCH but with a lower priority than the SRB1 resource. More generally, the SRB1 and SRB2 resources enable the UE and the MN to exchange RRC messages related to the MN and embed RRC messages related to the SN, and can also be referred to as MCG SRBs. The "SRB3" resource enables the UE and the SN to exchange RRC messages related to the SN and can also be referred to as SCG SRBs. The split SRBs allow the UE to directly exchange RRC messages with the MN via the lower layer resources of the MN and the SN. Further, a DRB that terminates at the MN and uses only the lower layer resources of the MN can be referred to as an MCG DRB, a DRB that terminates at the SN and uses only the lower layer resources of the SN can be referred to as an SCG DRB, and a DRB that terminates at the MN or the SN but uses the lower layer resources of both the MN and the SN can be referred to as a split DRB. A DRB that terminates at the MN but uses only the lower layer resources of the SN can be referred to as an MN-terminated SCG DRB. A DRB that terminates at the SN but uses only the lower layer resources of the MN can be referred to as an SN-terminated MCG DRB.

[0007] In some scenarios, the UE performs a handover procedure to switch from one cell to another, regardless of whether it is in SC operation 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 the cell of the serving base station to the target cell of the target base station, or from the cell of the first distributed unit (DU) of the serving base station to the target cell of the second DU of the same base station. In some DC scenarios, the UE performs a PSCell change procedure to change the PSCell. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. Depending on the scenario, the UE may perform a PSCell change from the PSCell of the serving SN to the target PSCell of the target SN, or from the PSCell of the source DU of the base station to the PSCell of the target DU of the same base station. Additionally, the UE performs a handover or PSCell change within the cell for synchronization reconfiguration.

[0008] In the case of broadcast communication services, the same service and the same specific content data are provided to all UEs within a geographical area simultaneously (i.e., all UEs within the broadcast service area are authorized to receive the data). Broadcast communication services are delivered to UEs using a broadcast session. Depending on the scenario, the UE may receive the broadcast communication service in the RRC_IDLE state, the RRC_INACTIVE state, and / or the RRC_CONNECTED state. In the case of multicast communication services, the same service and the same specific content data are provided to a dedicated set of UEs simultaneously (i.e., not all UEs within the multicast service area are authorized to receive the data). Multicast communication services are delivered to UEs using a multicast session.

[0009] The RAN node uses multicast for UEs operating in the RRC_CONNECTED state, but this may not fully meet the requirements of critical services such as mission-critical services, especially in the case of cells with a large number of UEs. Also, maintaining the RRC_CONNECTED state is not power-efficient for the UE. Therefore, it is desirable to support multicast for UEs in the RRC_INACTIVE state. However, it is not clear how a UE can receive multicast transmissions in the RRC_INACTIVE state.

SUMMARY OF THE INVENTION

[0010] In a multicast and / or broadcast service (MBS) session, a radio access network (RAN) provides different multicast configurations for UEs in a connected state and an inactive state, and the configurations include MBS radio bearer (MRB) information. In some embodiments, the RAN node transmits a multicast configuration including an MRB configuration to the UE while the UE is in the connected state for use when the UE receives MBS data in the inactive state or the connected state.

[0011] An exemplary embodiment of one of these techniques is a multicast and / or broadcast service (MBS) communication method implemented in a radio access network (RAN). The method includes transmitting, to a UE operating in a connected state, a first multicast configuration including a first MBS radio bearer (MRB) configuration for receiving MBS data in the connected state; transmitting, according to the first multicast configuration, first MBS data to the UE operating in the connected state; transmitting, to the UE, a second multicast configuration including a second MRB configuration for receiving MBS data in an inactive state; and transmitting, according to the second MRB configuration, second MBS data to the UE operating in the inactive state.

[0012] Other exemplary embodiments of these techniques are multicast and / or broadcast service (MBS) communication methods implemented in a user equipment (UE). The method includes receiving, from a radio access network (RAN), a first radio resource control (RRC) message including a multicast configuration for receiving MBS data in a connected state; receiving first MBS data in the connected state according to the multicast configuration; receiving, from the RAN, a second RRC message indicating that the UE is transitioning to a non-active state; receiving second MBS data in the non-active state in response to a determination that the second RRC message configures the UE to receive the second MBS data in the non-active state; or stopping receiving MBS data in the non-active state in response to a determination that the second RRC message does not configure the UE to receive the second MBS data in the non-active state.

Brief Description of the Drawings

[0013]

Figure 1A

Figure 1B

Figure 2A

Figure 2B

Figure 3

Figure 4

Figure 5A

Figure 5B

Figure 5C

Figure 5D

Figure 5E

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

[0014] FIG. 1A shows an exemplary wireless communication system 100 in which the techniques of the present disclosure for managing the 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 embodiments or scenarios, the wireless communication system 100 may alternatively include more or fewer UEs and / or more or fewer base stations than shown in FIG. 1A. The base stations 104, 106 may be any suitable one or more types of base stations, such as, for example, evolved Node B (eNB), next-generation eNB (ng-eNB), or 5G Node B (gNB). As a more specific example, base station 104 may be an eNB or a gNB, and base station 106 may be a gNB.

[0015] Base station 104 supports cell 124, and base station 106 supports cell 126. Since cell 124 partially overlaps with cell 126, UE 102A can be within the range of communicating with base station 104 and at the same time be within the range of communicating with base station 106 (or within the range of detecting or measuring signals from base station 106). Due to the overlap, for example, before UE 102A experiences a radio link failure, UE 102A may be able to perform a handover between cells (e.g., from cell 124 to cell 126) or between base stations (e.g., from base station 104 to base station 106). Furthermore, due to the overlap, various dual connectivity (DC) scenarios become possible. For example, UE 102A can communicate with base station 104 (operating as a master node (MN)) and base station 106 (operating as a secondary node (SN)) in DC. When UE 102A is in a DC state 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).

[0016] In non-MBS (unicast) operation, UE102A may use radio bearers (e.g., DRB or SRB) that terminate at the MN (e.g., base station 104) or SN (e.g., base station 106) at different times. For example, after a handover to or SN change with base station 106, UE102A may use a radio bearer (e.g., DRB or SRB) that terminates at base station 106. When communicating with a radio bearer in the uplink (from UE102A to the base station) direction and / or downlink (from the base station to UE102A) direction, UE102A may apply one or more security keys. In non-MBS operation, UE102A transmits data to the base station via a radio bearer on the uplink (UL) bandwidth part (BWP) of the cell (i.e., within the UL BWP) and / or receives data from the base station via a radio bearer on the downlink (DL) BWP of the cell. The UL BWP can be an initial UL BWP or a dedicated UL BWP, and the DL BWP can be an initial DL BWP or a dedicated DL BWP. UE102A may receive paging, system information, public warning message(s), or a random access response on the DL BWP. In this non-MBS operation, UE102A may be in a connected state. Alternatively, if UE102A supports small data transmission in the idle or non-active state, UE102A may be in the idle or non-active state.

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

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

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

[0020] UE 102A includes processing hardware 150, which may include one or more general-purpose processors (e.g., CPUs), a computer-readable memory storing machine-readable instructions executable by the general-purpose processor(s), and / or a dedicated processing device. The processing hardware 150 in the exemplary embodiment of FIG. 1A includes an MBS controller 152 configured to manage or control the reception of MBS information. For example, the UE MBS controller 152 may be configured to support these configurations and / or procedures, including RRC configurations, procedures and messaging associated with MBS procedures, and / or other operations associated with these configurations and / or procedures, including HARQ processes, as described below. The processing hardware 150 may also include a non-MBS controller 154, which is configured to manage or control one or more RRC configurations and / or RRC procedures according to any of the embodiments described below when the UE 102A communicates with the MN and / or SN during non-MBS operations. Although not shown in FIG. 1A, the UEs 102B and 103 may include processing hardware similar to the processing hardware 150 of the UE 102A.

[0021] CN110 can be an evolved packet core (EPC) 111 or a 5th generation core (5GC) 160, both of which are shown in FIG. 1A. The base station 104 can be an eNB that supports an S1 interface for communicating with the EPC 111, an ng-eNB that supports an NG interface for communicating with the 5GC 160, or a gNB that supports an NR radio interface and an NG interface for communicating with the 5GC 160. The base station 106 can be an EUTRA-NR DC (EN-DC) gNB (en-gNB) having an S1 interface to the EPC 111, an en-gNB not connected to the EPC 111, a gNB that supports an NR radio interface and an NG interface to the 5GC 160, or an ng-eNB that supports an EUTRA radio interface and an NG interface to the 5GC 160. In order to directly exchange messages with each other during the scenarios described later, the base stations 104 and 106 can support an X2 interface or an Xn interface.

[0022] Among a number of components, EPC111 may include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. The SGW 112 is typically configured to transfer user plane packets related to, for example, voice calls, video calls, Internet traffic, etc. 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., UE102A or 102B) to one or more external packet data networks, such as the Internet network and / or the Internet Protocol (IP) Multimedia Subsystem (IMS) network. 5GC160 includes a User Plane Function (UPF) 162, an Access and Mobility Management (AMF) 164, and / or a Session Management Function (SMF) 166. The UPF 162 is typically configured to transfer user plane packets related to, for example, voice calls, video calls, Internet traffic, etc. The AMF 164 is typically configured to manage authentication, registration, paging, and other related functions. The SMF 166 is typically configured to manage PDU sessions.

[0023] UPF162, AMF164, and / or SMF166 may be configured to support MBS. For example, SMF166 may be configured to manage or control MBS transmission, configure UPF162 and / or RAN105 for MBS flows, and / or manage or configure one or more MBS sessions or PDU sessions for MBS for a UE (e.g., UE102A or 102B). UPF162 is configured to transfer MBS data packets related to, for example, audio, video, Internet traffic, etc., to RAN105. UPF162 and / or SMF166 may be configured for both non-MBS unicast services and MBS, or for MBS only.

[0024] Generally, the wireless communication system 100 may include any suitable number of base stations that support NR cells and / or EUTRA cells. More specifically, the EPC 111 or 5GC 160 may be connected to any suitable number of base stations that support NR cells and / or EUTRA cells. In the following examples, specific CN types (EPC, 5GC) and RAT types (5G NR and EUTRA) are specifically referred to. However, generally, the techniques of the present disclosure can also be applied to other suitable radio access technologies and / or core network technologies, such as, for example, 6th generation (6G) radio access and / or 6G core network or 5G NR-6G DC.

[0025] In different configurations or scenarios of the wireless communication system 100, the base station 104 may operate as a MeNB, Mng-eNB, or MgNB, and the base station 106 may operate as an SgNB or 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.

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

[0027] Figure 1B shows an exemplary distributed implementation of any one or more of base stations 104 and 106. 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, which may include, for example, one or more general-purpose processors (e.g., CPUs), a computer-readable memory storing machine-readable instructions executable by the general-purpose processor(s), and / or a dedicated processing device. For example, CU 172 may include some or all of the processing hardware 130 or 140 of FIG. 1A.

[0028] Each of DUs 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs), a computer-readable memory storing machine-readable instructions executable by one or more general-purpose processors, and / or a dedicated processing device. For example, the processing hardware may include a MAC controller configured to manage or control one or more medium access control (MAC) operations or procedures (e.g., random access procedures), and an RLC controller configured to manage or control one or more radio link control (RLC) operations or procedures when the base station (e.g., base station 104) operates as an MN or SN. The processing hardware may also include a PHY layer controller configured to manage or control operations or procedures of one or more physical (PHY) layers.

[0029] In some embodiments, CU172 may include one or more logical nodes (CU-CP(s) 172A) that host the control plane portion of the packet data convergence protocol (PDCP) protocol and / or the radio resource control (RRC) protocol of CU172. CU172 may also include one or more logical nodes (CU-UP(s) 172B) that host the user plane portion of the PDCP protocol and / or the service data adaptation protocol (SDAP) protocol of CU172. As described herein, CU-CP(s) 172A may transmit non-MBS control information and MBS control information, and CU-UP(s) 172B may transmit non-MBS data packets and MBS data packets.

[0030] CU-CP(s) 172A may be connected to a plurality of CU-UPs 172B via an E1 interface. CU-CP(s) 172A selects a suitable CU-UP(s) 172B for the requested service for UE102A. In some embodiments, a single CU-UP 172B may be connected to a plurality of 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 embodiments, one DU 174 may be connected to a plurality of CU-UPs 172B under the control of the same CU-CP 172A. In such embodiments, the connection between CU-UP 172B and DU 174 is established by CU-CP 172A using a bearer context management function.

[0031] Figure 2A shows a simplified exemplary protocol stack 200 that a UE (e.g., UE 102A, 102B, or 103) may follow to communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106). In the exemplary protocol stack 200, the PHY sublayer 202A of EUTRA provides a transport channel to the EUTRA MAC sublayer 204A, and then the EUTRA MAC sublayer 204A provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides the RLC channel to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, and then the NR MAC sublayer 204B provides a logical channel to the NR RLC sublayer 206B. Next, the NR RLC sublayer 206B provides the RLC channel to the NR PDCP sublayer 210. UE 102A, in some embodiments, supports both the EUTRA and NR stacks as shown in Figure 2A to support handover between EUTRA base stations and NR base stations and / or support DC via the EUTRA interface and the NR interface. Further, as shown in Figure 2A, UE 102A may support the layering of NR PDCP 210 on top of EUTRA RLC 206A and SDAP sublayer 212 on top of the NR PDCP sublayer 210. The sublayers are also simply referred to as "layers" herein.

[0032] The EUTRA PDCP sub-layer 208 and the NR PDCP sub-layer 210 receive packets that can be referred to as service data units (SDUs) (e.g., from an IP layer hierarchically arranged directly or indirectly above the PDCP layer 208 or 210), and output packets that can be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). Except when related to the differences between SDUs and PDUs, in this disclosure, for simplicity, both SDUs and PDUs are referred to as "packets". The packets can be MBS packets or non-MBS packets. MBS packets can include, for example, application content of 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, MBS packets can include application control information of MBS services.

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

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

[0035] In some embodiments, a base station (e.g., base stations 104, 106) broadcasts MBS data packets via one or more MBS radio bearers (MRBs (plural)), and then UE102A, 102B, or 103 receives the MBS data packets via the MRBs (plural). The base station may include the configuration(s) of the MRBs (plural) in multi-cast configuration parameters (which may also be referred to as MBS configuration parameters) described below. In some embodiments, the base station broadcasts MBS data packets via the RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and in response, UE102A receives the MBS data using the PHY sublayer 202, MAC sublayer 204, and RLC sublayer 206. In such embodiments, the base station and UE102A, 102B, or 103 may communicate MBS data packets without using the PDCP sublayer 208 and SDAP sublayer 212. In other embodiments, the base station transmits MBS data packets via the PDCP sublayer 208, RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and in response, UE102A, 102B, or 103 receives the MBS data packets using the PHY sublayer 202, MAC sublayer 204, RLC sublayer 206, and PDCP sublayer 208. In such embodiments, the base station and UE102A, 102B, or 103 may communicate MBS data packets without using the SDAP sublayer 212. In yet other embodiments, the base station transmits MBS data packets via the SDAP sublayer 212, PDCP sublayer 208, RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and in response, UE102A, 102B, or 103 receives the MBS data packets using the PHY sublayer 202, MAC sublayer 204, RLC sublayer 206, PDCP sublayer 208, and SDAP sublayer 212.

[0036] FIG. 2B schematically shows an exemplary protocol stack 250 that UE102A, 102B, or 103 may use to communicate with a DU (e.g., DU174) and a CU (e.g., CU172). As shown by the radio protocol stack 250 in FIG. 2B, the radio protocol stack 200 in FIG. 2A is functionally split. The CU in either base station 104 or 106 may hold all control and upper layer functions (e.g., RRC214, SDAP212, NR PDCP210), while lower layer operations (e.g., NR RLC206B, NR MAC204B, and NR PHY202B) may be delegated to the DU. To support the connection to the 5GC, NR PDCP210 provides SRBs to RRC214, and NR PDCP210 provides DRBs to SDAP212 to provide SRBs to RRC214.

[0037] Referring to FIG. 3, the MBS session 302A may include a tunnel 312A having endpoints at the CN110 and the base station 104 / 106. The MBS session 302A may correspond to a specific session ID, such as, for example, a Temporary Mobile Group Identification Information (TMGI). The MBS data may include, for example, IP packets, TCP / IP packets, UDP / IP packets, Real-Time Transport Protocol (RTP) / UDP / IP packets, or RTP / TCP / IP packets.

[0038] In some cases, the CN110 and / or the base station 104 / 106 may configure the tunnel 312A only for MBS traffic directed from the CN110 to the base station 104 / 106, and the tunnel 312A may be referred to as a downlink (DL). However, in other cases, the CN110 and the base station 104 / 106 may use the tunnel 312A for both downlink and uplink (UL) MBS traffic, such as, for example, to support commands or service requests from the UE. Further, since the base station 104 / 106 may send the MBS traffic arriving via the tunnel 312A to multiple UEs, the tunnel 312A may be referred to as a common tunnel or a common DL tunnel.

[0039] Tunnel 312A can operate on a transport layer or sub - layer, for example, the User Datagram Protocol (UDP) protocol layered on top of the Internet Protocol (IP). As a more specific example, Tunnel 312A can be associated with the General Packet Radio Service (GPRS) Tunneling Protocol (GTP). Tunnel 312A can correspond to, for example, a specific IP address (e.g., the IP address of base stations 104 / 106) and a specific Tunnel Endpoint Identifier (TEID) (e.g., the TEID assigned by base stations 104 / 106). More generally, Tunnel 312A can have any suitable transport layer configuration. CN110 can specify the IP address and TEID address in the header(s) of the tunnel packet(s) containing the MBS data packet and send the tunnel packet(s) downstream to base stations 104 / 106 via Tunnel 312A (i.e., the header(s) can include the IP address and / or TEID). For example, the header(s) can include an IP header and a GTP header each containing the IP address and TEID respectively. Thus, base stations 104 / 106 can identify the data packets moving through Tunnel 312A using the IP address and / or TEID.

[0040] As shown in FIG. 3, the base stations 104 / 106 map the traffic in tunnel 312A to N radio bearers 314A-1, 314A-2, ... 314A-N that can be configured as MBS radio bearers or MRBs (where N≥1). Each MRB can correspond to a respective logical channel. As described above, the PDCP sublayer provides support for radio bearers such as SRBs, DRBs, and MRBs, and the EUTRA sublayer or NR MAC sublayer provides logical channels to the EUTRA sublayer or NR RLC sublayer. Each of the MRBs 314A can correspond to, for example, a respective MBS traffic channel (MTCH). The base stations 104 / 106 and the CN 110 can also maintain other MBS sessions 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 respective logical channel.

[0041] The MBS traffic can include one or more quality of service (QoS) flows for each of tunnels 312A, 312B, etc. For example, the MBS traffic on tunnel 312B can include a set of flows 316 that includes QoS flows 316A, 316B, ... 316L. Further, the logical channels of the MRBs can support a single QoS flow or multiple QoS flows. In the exemplary configuration of FIG. 3, the base stations 104 / 106 map QoS flows 316A and 316B to the MTCH of MRB 314B-1 and map QoS flow 316L to the MTCH of MRB 314B-N.

[0042] In various scenarios, CN110 may allocate different types of MBS traffic to different QoS flows. For example, a flow with a relatively high QoS value may correspond to audio packets, and a flow with a relatively low QoS value may correspond to video packets. As another example, a flow with a relatively high QoS value may correspond to I-frames or complete images used for video compression, and a flow with a relatively low QoS value may correspond to P-frames or predicted pictures that contain only changes to the I-frame.

[0043] Continuing to refer to FIG. 3, the base stations 104 / 106 and CN110 may maintain one or more PDU sessions to support unicast traffic between CN110 and a particular UE. The PDU session 304A may include a UE-specific DL tunnel and / or a UE-specific UL tunnel 322A corresponding to one or more DRBs 324A, such as DRB324A-1, 324A-2,... 324-N. Each of the DRBs 324A may correspond to a respective logical channel, such as a dedicated traffic channel (DTCH).

[0044] Referring now to FIG. 4, when the base stations 104 / 106 are implemented in a distributed manner, the CU 172 and the DUs 174A / 174B can establish tunnels for downlink data and / or uplink data associated with the MRB or DRB. The aforementioned MRB 314A-1 can be implemented as an MRB 402A that connects the CU 172 to a plurality of UEs such as, for example, UEs 102A and 102B. The MRB 402A can include a DL tunnel 412A that connects the CU 172 and the DUs 174A / 174B, and a DL logical channel 422A corresponding to the DL tunnel 412A. Specifically, the DUs 174A / 174B can map the downlink traffic received via the DL tunnel 412A to a DL logical channel 422A that can be, for example, an MTCH or a DTCH. The DL tunnel 412A can be a common DL tunnel, via which the CU 172 transmits MBS data packets to a plurality of UEs. Alternatively, the DL tunnel 412A can be a UE-specific DL tunnel, via which the CU 172 transmits MBS data packets to a specific UE.

[0045] Optionally, the MRB 402A also includes a UL tunnel 413A that connects the CU 172 and the DUs 174A / 174B, and a UL logical channel 423A corresponding to the UL tunnel 413A. The UL logical channel 423A can be, for example, a DTCH. The DUs 174A / 174B can map the uplink traffic received via the UL logical channel 423A to the UL tunnel 413A.

[0046] Tunnels 412A and 413A can operate in the transport layer or sublayer of the F1-U interface. As a more specific example, CU172 and DU174A / 174B may utilize F1-U for user plane traffic, and tunnels 412A and 413A may be associated with the GTP-U protocol layered on top of UDP / IP, where IP is layered on top of the appropriate data link layer and physical (PHY) layer. Further, MRB(s) 402 and / or DRB(s) 404 support control plane traffic additionally in at least some of the cases. More specifically, CU172 and DU174A / 174B may exchange F1-AP messages via the F1-C interface that depends on the Stream Control Transmission Protocol (SCTP) layered on top of IP, and similar to F1-U, IP is layered on top of the appropriate data link layer and PHY layer.

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

[0048] In some cases, CU172 uses DRB404A to send MBS data packets or unicast data packets associated with a PDU session to a specific UE (e.g., UE102A or UE102B). DRB404A may include a UE-specific DL tunnel 432A that connects CU172 and DU174A / 174B, and a DL logical channel 442A corresponding to DL tunnel 432A. Specifically, DU174A / 174B may map downlink traffic received via DL tunnel 432A to a DL logical channel 442A, which may be, for example, a DTCH. DRB404A further includes a UE-specific UL tunnel 433A that connects CU172 and DU174A / 174B, and a UL logical channel 443A corresponding to UL tunnel 433A. UL logical channel 443A may be, for example, a PUSCH. DU174A / 174B may map uplink traffic received via UL logical channel 443A to UL tunnel 433A.

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

[0050] Next, to support MBS for UEs operating in a connected state and / or an inactive state, several exemplary scenarios in which the techniques of the present disclosure are executed by the UE and / or the RAN are discussed with reference to FIGS. 5A-5E. In the following description, for example, the connected state, the inactive state, and the idle state may be the RRC_CONNECTED state, the RRC_INACITVE state, and the RRC_IDLE state, respectively.

[0051] FIG. 5A shows an exemplary scenario 500A for establishing an MBS session. The base station 104 includes DU174, CU-CP172A, and CU-UP172B. Note that scenario 500A is also applicable to an integrated CU (e.g., a CU that is not split into a CP function node and a UP function node).

[0052] UE 102 (e.g., UE 102A in FIG. 1A) first performs (502) an MBS session attachment procedure with CN 110 via base station 104 to attach to a first MBS session. In some embodiments, the MBS session attachment procedure does not include CU-UP 172B. In further embodiments, UE 102 then performs one or more additional MBS attachment procedures, and thus, event 502 is the first of the plurality of MBS attachment procedures. In some embodiments, since base station 104 constructs a common DL tunnel for MBS traffic (not a UE-specific tunnel described later), procedures 502 and 592A can occur in either order. In other words, in such embodiments, any UE attaches to a first MBS session after base station 104 constructs a common DL tunnel.

[0053] In some embodiments, UE102 executes the MBS session participation procedure (502) while operating in the connected state. In some scenarios or embodiments, if the first MBS session has not yet started, CU-CP172A transitions UE102 to the inactive state or the idle state after the MBS session participation procedure to conserve the battery power of UE102. For example, CU-CP172A may send an RRC release message to UE102 to transition UE102 from the connected state to the inactive state or the idle state. In response to the RRC release message, UE102 transitions to the inactive state or the idle state. In some embodiments, in the case of the inactive state, UE102 later initiates an RRC connection resume procedure with CU-CP172A via DU174 to transition to the connected state. In response to the initiation, UE102 sends an RRC resume request message to CU-CP172A via DU174 and receives an RRC resume message from CU-CP172A via DU174. In response thereto, UE102 transitions to the connected state (503) and sends an RRC resume complete message to CU-CP172A via DU174. In further embodiments, in the case of the idle state, UE102 later initiates an RRC connection establishment procedure with CU-CP172A via DU174 to transition to the connected state. In response to the initiation, UE102 sends an RRC setup request message to CU-CP172A via DU174 and receives an RRC setup message from CU-CP172A via DU174. In response thereto, UE102 transitions to the connected state (503) and sends an RRC setup complete message to CU-CP172A via DU174.

[0054] Alternatively, if the first MBS session has started, is starting, or is about to start, CU-CP172A keeps UE102 in the connected state.

[0055] While the UE 102 operates in a connected state, the UE 102 monitors the PDCCH using a cell radio network temporary identifier (C-RNTI) to communicate unicast data with the DU 174. In some embodiments, the unicast data includes data associated with the SRB(s) and / or DRB(s). In one embodiment, the unicast data includes subsequent messages of the MBS session participation procedure and messages of events 528 and 530 described below. In some embodiments, the unicast data also includes unicast MBS data (e.g., in event 536). In further embodiments, the unicast data excludes multicast MBS data (e.g., in event 536). In some embodiments, when the UE 102 receives DCI and a scrambled CRC on the PDCCH, the UE 102 uses the C-RNTI and the DCI to verify the CRC. If the UE 102 verifies that the CRC is valid and the DCI includes a UL grant, the UE 102 transmits a UL transmission including unicast data to the DU 174 according to the UL grant. If the UE 102 verifies that the CRC is valid and the DCI includes a DL allocation, the UE 102 receives a DL transmission including unicast data from the DU 174 according to the DL allocation.

[0056] In some embodiments, to execute the MBS session participation procedure, UE 102 transmits an MBS session participation request message to CN 110 via base station 104. In some such embodiments, in response thereto, CN 110 transmits an MBS session participation response message to UE 102 via base station 104 to permit UE 102 to access the first MBS session. In some embodiments, UE 102 includes a first MBS session ID (e.g., MBS session ID1) of the first MBS session in the MBS session participation request message. CN 110 includes the first MBS session ID in the MBS session participation response message in some cases. In some embodiments, in response to the MBS session participation response message, UE 102 transmits an MBS session participation completion message to CN 110 via base station 104.

[0057] In some embodiments, the MBS session participation request message, the MBS session participation response message, and the MBS session participation completion message are session initiation protocol (SIP) messages. In other embodiments, the MBS session participation request message, the MBS session participation response message, and the MBS session participation completion message are NAS messages such as 5G mobility management (5GMM) messages or 5G session management messages (5GSM). In some embodiments, in the case of messages such as 5GSM messages, UE 102 transmits a first UL container message including the MBS session participation request message to CN 110 via base station 104, CN 110 transmits a DL container message including the MBS session participation response message to UE 102 via base station 104, and UE 102 transmits a second UL container message including the MBS session participation completion message to CN 110 via base station 104. In some embodiments, such container messages are messages similar to 5GMM messages or are 5GMM messages.

[0058] In some embodiments, the MBS session participation request message, the MBS session participation response message, and the MBS session participation completion message are, respectively, a PDU session change request message, a PDU session change command message, and a PDU session change completion message. For the sake of brevity in the following description, the terms MBS session participation request message, MBS session participation response message, and / or MBS session participation completion message may represent either the respective container messages or the respective containerless messages.

[0059] In some embodiments, the UE 102 executes a PDU session establishment procedure with the CN 110 via the base station 104 to establish a PDU session in order to execute the MBS session participation procedure. In a further embodiment, during the PDU session establishment procedure, the UE 102 communicates the PDU session ID of the PDU session with the CN 110 via the base station 104.

[0060] In some embodiments, before, during, or after the first MBS session participation procedure (event 502), the CN 110 transmits a first CN–BS message (e.g., a multicast session activate request message) including the first MBS session ID to the CU-CP 172A (504) and requests the CU-CP 172A to configure or activate resources for the first MBS session (e.g., a multicast session).

[0061] In some embodiments, CN110 includes, in a first CN~BS message, service quality (QoS) flow configuration(s) for a first MBS session. In some embodiments, the first MBS QoS flow configuration(s) constitute MBS QoS flow(s) 1, …, M associated with the first MBS session (where M is an integer greater than 0). In some embodiments, the first MBS QoS flow configuration(s) include, for MBS QoS flow(s) 1, …, M associated with the first MBS session, MBS QoS flow identifier(s) 1, …, M and / or MBS QoS flow level QoS parameter(s) 1, …, M. In some embodiments, each of MBS QoS flow configuration(s) 1, …, M includes an MBS QoS flow identifier and an MBS QoS flow level QoS parameter for a particular MBS QoS flow.

[0062] In other embodiments, CN110 does not include, in a first CN~BS message, MBS QoS flow configuration(s) for a first MBS session. Thus, CU-CP172A generates a second MBS QoS flow configuration(s) based on a preconfigured MBS QoS flow configuration(s). For example, the second MBS QoS flow configuration(s) is the same as the preconfigured MBS QoS flow configuration(s). In other examples, the second MBS QoS flow configuration(s) is similar to the preconfigured MBS QoS flow configuration(s). In some embodiments, CU-CP172A is preconfigured with a preconfigured MBS QoS flow configuration(s) before receiving the first CN~BS message. In other embodiments, CU-CP172A receives a preconfigured MBS QoS flow configuration(s) from an operations, administration, and maintenance (OAM) node before receiving the first CN~BS message. The examples or embodiments described for the first MBS QoS flow configuration(s) may also be applicable to the preconfigured MBS QoS flow configuration(s).

[0063] In yet another embodiment, after transmitting the first CN~BS message (504), CN110 transmits an additional CN~BS message (e.g., a multicast session update request message) including the first MBS session ID and the first MBS QoS flow configuration(s) to CU-CP172A. After receiving the additional CN~BS message, CU-CP172A respectively performs the transmission of the first CP~UP message (560) to CU-UP172B and the transmission of the first CU~DU message (506) to DU174. In other words, CU-CP172A delays the transmission of the first CP~UP message and the first CU~DU message (e.g., delays the execution of the MC bearer context setup procedure and the multicast context setup procedure) until it receives the first MBS QoS flow configuration(s) or the additional CN~BS message. In some such embodiments, in response to the additional CN~BS message, CU-CP172A transmits an additional BS~CN message (e.g., a multicast session update response message) to CN110.

[0064] In some embodiments, upon receiving the first CN~BS message (504), CU-CP172A transmits an additional BS~CN message to CN110. In other embodiments, CU-CP172A transmits the second BS~CN message to CN110 (518) before or after receiving the second CN~BS message (514), before or after receiving the second UP~CP message (566) (e.g., as described later), or before or after transmitting the second CU~DU message (516). In some embodiments, CU-CP172A transmits the second BS~CN message to CN110 (518) before receiving the additional CN~BS message or before transmitting the additional BS~CN message. In other embodiments, CU-CP172A transmits the second BS~CN message to CN110 (518) after receiving the additional CN~BS message or after transmitting the additional BS~CN message.

[0065] In some embodiments, CN110 includes the first slice information in the fourth CN~BS message. In some such cases, CN110 does not include the first slice information in the first CN~BS message. In some embodiments, CN110 includes the first MBS area information in an additional CN~BS message. In some such cases, CN110 does not include the first MBS area information in the first CN~BS message.

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

[0067] In some embodiments, CN110 includes first MBS area information (e.g., MBS service area IE) that constitutes or indicates the MBS area(s) of the first MBS session in the first CN~BS message. In the case where the first MBS session is a location-dependent multicast session, the first MBS area information includes one or more tuples of {MBS area session ID IE, MBS service area information IE}. In the case where the first MBS session is a location-independent multicast session, the first MBS is information including the MBS service area information IE. The MBS service area information IE within the first MBS area information includes a list of cell ID(s) and / or a list of tracking area ID(s) (TAI(s)). In some embodiments, the cell ID(s) is / are cell global ID(s) (CGI(s)). In other embodiments, CN110 does not include MBS area information (e.g., MBS service area IE) in the first CN~BS message.

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

[0069] In some embodiments, the CU-CP 172A includes a second MBS QoS flow configuration(s) (e.g., MBS QoS flow information and / or MRB QoS IE(s) to be set up, or QoS-Flow-QoS-Parameter-List and / or QoSFlowLevelQoSParameters IE(s)) in an MRB setup configuration (e.g., MCMRBSetupConfiguration IE). In some embodiments, the MRB setup configuration includes one or more MRB setup configuration item(s) (e.g., MCMRBSetupConfiguration-Item IE(s)). In some embodiments, each of the MRB setup configuration items includes, for a particular MRB, an MRB ID, MRB configuration parameters (e.g., PDCP configuration and / or SDAP configuration), and / or a particular second MBS QoS flow configuration(s) of the second MBS QoS flow configuration(s). In some embodiments, 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., an acknowledgement mode or a negative acknowledgement mode). In some embodiments, the SDAP configuration includes a default DRB configuration (e.g., DefaultDRB IE), an SDAP UL header configuration (e.g., SDAP-Header-UL), and / or an SDAP DL header configuration (e.g., SDAP-Header-DL).

[0070] In some embodiments, the second MBS QoS flow configuration(s) includes the QoS parameters required for each of the MBS QoS flow(s) associated with the MRB(s). In some embodiments, the second MBS QoS flow configuration(s) includes, for MBS QoS flow(s) 1, …, M associated with the first MBS session, the MBS QoS flow identifier(s) 1, …, M and / or the MBS QoS flow level QoS parameter(s) 1, …, M. The MBS QoS flow identifier(s) 1, …, M identify the MBS QoS flow(s) 1, …, M. For example, the MRB setup configuration includes, for MRB(s) 1, …, N (where N is an integer greater than 0), the MRB setup configuration item(s) 1, …, N respectively. In some embodiments, the CU-CP 172A configures the mapping(s) or association(s) between the MBS QoS flow(s) 1, …, M and the MRB(s) 1, …, N in the MRB setup configuration (where N is an integer and M≥N>0). In some embodiments, the CU-CP 172A associates or maps a specific QoS flow to a specific MRB. In other words, the CU-CP 172A refrains from associating or mapping a specific QoS flow to two MRBs. In some embodiments, the MRB setup configuration item X includes, for MRB X among MRB(s) 1, …, N, the MRB ID X, the PDCP configuration X, the SDAP configuration X, and / or a specific MBS QoS flow configuration(s) among the second MBS QoS flow configuration(s) (where 1≤X≤N).

[0071] Example 1 of MRB setup configuration: MCMRBSetupConfiguration ::= SEQUENCE (SIZE(1..maxnoofMRBs)) OF MCMRBSetupConfiguration-Item MCMRBSetupConfiguration-Item ::= SEQUENCE { mrb-ID MRB-ID, sdap-config SDAP-Configuration, mbs-pdcp-config PDCP-Configuration, qoS-Flow-QoS-Parameter-List QoS-Flow-QoS-Parameter-List, qoSFlowLevelQoSParameters QoSFlowLevelQoSParameters OPTIONAL, iE-Extensions ProtocolExtensionContainer { {MCMRBSetupConfiguration-Item-ExtIEs}} OPTIONAL, ... }

[0072] Example 2 of MRB setup configuration (i.e., the SDAP configuration is omitted): MCMRBSetupConfiguration ::= SEQUENCE (SIZE(1..maxnoofMRBs)) OF MCMRBSetupConfiguration-Item MCMRBSetupConfiguration-Item ::= SEQUENCE { mrb-ID MRB-ID, mbs-pdcp-config PDCP-Configuration, qoS-Flow-QoS-Parameter-List QoS-Flow-QoS-Parameter-List, qoSFlowLevelQoSParameters QoSFlowLevelQoSParameters OPTIONAL, iE-Extensions ProtocolExtensionContainer { {MCMRBSetupConfiguration-Item-ExtIEs}} OPTIONAL, ... } In Embodiment 2, CU-CP172A omits the SDAP configuration from the MCMRBSetupConfiguration-Item.

[0073] In some embodiments, CU-CP172A generates a second MBS QoS flow configuration(s) based on the first MBS QoS flow configuration(s). For example, the second MBS QoS flow configuration(s) is the same as the first MBS QoS flow configuration(s). In other embodiments, the second MBS QoS flow configuration(s) is similar to the first MBS QoS flow configuration(s).

[0074] In some cases where CU-CP172A receives first slice information from CN110 (e.g., in the first CN~BS message), CU-CP172A includes the first slice information in the first CP~UP message, indicating that the specific network slice indicated by the first slice information is used for the first MBS session. In some cases where CU-CP172A does not receive slice information from CN110 (e.g., in the first CN~BS message), CU-CP172A includes pre-configured slice information in the first CP~UP message, indicating that a specific network slice is used for the first MBS session. Alternatively, in such cases, CU-CP172A excludes slice information from the first CP~UP message, indicating that the default network slice is used for the first MBS session.

[0075] In some cases where CU-CP172A wants to receive the first MBS area information from CN110 (e.g., in the first CN~BS message), CU-CP172A includes the first MBS area information in the first CP~UP message. In some cases where CU-CP172A has not received the MBS area information from CN110 (e.g., in the first CN~BS message), CU-CP172A includes pre-configured MBS area information in the first CP~UP message. Alternatively, in such cases, CU-CP172A excludes the MBS area information from the first CP~UP message. In further cases where CU-CP172A has received the first MBS area information from CN110, CU-CP172A obtains the MBS area session ID from the first MBS area information and includes the MBS area session ID in the first CP~UP message. In some such cases, CU-CP172A refrains from including the MBS service area information IE in the first CP~UP message. In further cases where CU-CP172A has not received the MBS area information from CN110, CU-CP172A includes a pre-configured MBS area session ID in the first CP~UP message. Alternatively, in such cases, CU-CP172A excludes the MBS area session ID from the first CP~UP message.

[0076] In response to the first CP~UP message, the CU-UP 172B establishes or configures resources for the MRB(s) and transmits the first UP~CP message (e.g., the MC bearer context setup response message) (562). In some embodiments, the CU-UP 172B configures resources for each of the MRB(s) based on corresponding MRB configuration parameters and / or specific configurations (if any) of the second MBS QoS flow configuration(s). In some embodiments, the CU-UP 172B configures resources for the MRB(s), MBS QoS flow(s), and / or the first MBS session based on the first slice information. In some embodiments, the CU-UP 172B establishes and / or configures the PDCP entity(ies) 1, …, N according to the PDCP configuration(s) 1, …, N of the MRB(s) or MRB ID(s) 1, …, N. In other embodiments, for each of the PDCP configuration(s) 1, …, N, the CU-UP 172B ignores or discards a part of the PDCP configuration and establishes and / or configures the PDCP entity according to the remaining PDCP configuration. In one embodiment, 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 a further embodiment, 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.

[0077] In some embodiments, the CU-UP 172B establishes and / or configures the SDAP entity(ies) 1, …, N according to the SDAP configuration(s) 1, …, N of the MRB(s) or MRB ID(s) 1, …, N. In other embodiments, for each of the SDAP configuration(s) 1, …, N, the CU-UP 172B ignores or discards a part of the SDAP configuration and establishes and / or configures the SDAP entity according to the remaining of the SDAP configuration. In one embodiment, the 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 a further embodiment, the 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 embodiments, since the CU-UP 172B determines not to use SDAP to transmit the MBS data of the first MBS session, the CU-UP 172B ignores or discards the entire SDAP configuration.

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

[0079] In Figure 5A, events 560 and 562 are collectively referred to as the MC bearer context setup procedure.

[0080] After receiving the first CN~BS message (504) (e.g., in response to receiving (504)), the CU-CP 172A transmits (506) a first CU~DU message (e.g., a multicast context setup request message) to the DU 174 to request the setup of the multicast context of the first MBS session and / or a set of common DL tunnels. The CU-CP 172A determines to configure one or more MRBs for the first MBS session or MBS QoS flow(s) 1, …, M. In response to the determination, the CU-CP 172A generates a configuration of the MRBs to be set up to request resources of the one or more MRBs. In some embodiments, the first CU~DU message includes, for the first MBS session, the first MBS session ID, the configuration of the MRBs to be set up, and / or the third MBS QoS flow configuration(s). In some embodiments, the CU-CP 172A includes the first slice information in the first CU~DU message to indicate that the specific network slice indicated by the first slice information is used for the first MBS session. In some embodiments, the configuration of the MRBs to be set up includes MRB ID(s) (plural) that identify the MRBs respectively, and the DU 174 configures resources (e.g., PHY resources, MAC resources, and / or RLC resources) for the MRB(s). The MRB ID(s) included in the first CU~DU message are the same as the MRB ID(s) included in the first CP~UP message. For example, the configuration of the MRBs to be set up includes MRB ID(s) 1, …, N respectively for MRB(s) 1, …, N. The third MBS QoS flow configuration(s) includes the QoS parameters required for the MBS QoS flow(s) associated with the first MBS session. In some embodiments, the third MBS QoS flow configuration(s) includes, for the MBS QoS flow(s) 1, …, M associated with the first MBS session, MBS QoS flow identifier(s) 1, …, M and / or MBS QoS flow level QoS parameter(s) 1, …, M.The MBS QoS flow identifier(s) 1, …, M identify the MBS QoS flow(s) 1, …, M, respectively. In some embodiments, the CU-CP 172A configures the mapping(s) or association(s) between the MBS QoS flow(s) and the MRB(s) in the configuration of the MRBs to be set up. For example, the configuration of the MRBs to be set up includes setup configuration item(s) 1, …, N with respect to the MRB(s) 1, …, N, respectively. In some embodiments, the setup configuration item Y includes an MRB ID Y and a specific MBS QoS flow configuration(s) among the third MBS QoS flow configuration(s) with respect to the MRB Y among the MRB(s) 1, …, N (where 1 ≤ Y ≤ N). In some embodiments, the CU-CP 172A generates the third MBS QoS flow configuration(s) based on the first MBS QoS flow configuration(s). For example, the third MBS QoS flow configuration(s) is / are the same as the first MBS QoS flow configuration(s). In other examples, the third MBS QoS flow configuration(s) is / are similar to the first MBS QoS flow configuration(s). In some embodiments, the CU-CP 172A includes an ID (e.g., CU MBS F1AP ID) in the first CU-DU message to identify the first MBS session at the F1 interface between the CU-CP 172A and the DU 174.

[0081] In some cases where CU-CP172A receives the first slice information (e.g., S-NSSAI) associated with the first MBS session from CN110 (e.g., in the first CN~BS message), CU-CP172A includes the first slice information in the first CU~DU message, indicating that a specific network slice is used for the first MBS session. In cases where CU-CP172A does not receive the slice information (e.g., S-NSSAI) associated with the first MBS session from CN110 (e.g., in the first CN~BS message), CU-CP172A includes pre-configured slice information in the first CU~DU message. Alternatively, in such cases, CU-CP172A excludes the slice information in the first CP~UP message.

[0082] In some cases where CU-CP172A receives the first MBS area information from CN110 (e.g., in the first CN~BS message), CU-CP172A includes the first MBS area information in the first CU~DU message. In some cases where CU-CP172A does not receive the MBS area information from CN110 (e.g., in the first CN~BS message), CU-CP172A includes pre-configured MBS area information in the first CU~DU message. Alternatively, in such cases, CU-CP172A excludes the MBS area information from the first CU~DU message. In further cases where CU-CP172A receives the first MBS area information from CN110, CU-CP172A obtains the MBS area session ID from the first MBS area information and includes the MBS area session ID in the first CU~DU message. In further cases where CU-CP172A does not receive the MBS area information from CN110, CU-CP172A includes a pre-configured MBS area session ID in the first CU~DU message. Alternatively, in such cases, CU-CP172A excludes the MBS area session ID from the first CU~DU message.

[0083] In response to receiving the first CU–DU message (506), DU174 establishes or configures resources (e.g., multicast context and / or PHY resources, MAC resources, RLC resources, and / or tunnel resources) for the MRB(s) and transmits a first DU–CU message (e.g., a multicast context setup response message) to CU-CP172A (508). In some embodiments, DU174 establishes and / or configures a MAC entity for the MRB(s). In further embodiments, DU174 establishes and / or configures RLC entity(ies) 1, …, N for the MRB(s) or MRB ID(s) 1, …, N, respectively. In some embodiments, DU174 includes a first DU transport layer configuration in the first DU–CU message to configure a CU–DU common DL tunnel for the first MBS session (e.g., for the MRB(s) identified by the MRB ID(s)). In some embodiments, DU174 includes an additional DU transport layer configuration(s) in the first DU–CU message to configure additional CU–DU common DL tunnel(s) for additional MRB(s) identified by additional MRB ID(s) of the MRB ID(s). In some embodiments, DU174 includes the MRB ID(s) associated with the first DU transport layer configuration and / or the additional DU transport layer configuration(s) in the first DU–CU message. For example, each of the MRB ID(s) is associated with a specific DU transport layer configuration. In some embodiments, each of the first DU transport layer configuration and / or the additional DU transport layer configuration(s) includes a DU transport layer address (e.g., an IP address and / or a TEID). In further embodiments, each of the first DU transport layer configuration and / or the additional DU transport layer configuration(s) is MRB F1-U TNL information in the DU IE.

[0084] In Figure 5A, events 506 and 508 are collectively referred to as the multicast context setup procedures. In some embodiments, the multicast context setup procedures and the MC bearer context setup procedures are performed in parallel. In other embodiments, the multicast context setup procedures are performed after the MC bearer context setup procedures, or vice versa.

[0085] In some embodiments, after receiving the first CU-DU message (506) or after transmitting the first DU-CU message (508), DU174 transmits a second DU-CU message (e.g., a multicast delivery setup request message) to CU-CP172A (510). In some embodiments, DU174 includes the first DU transport layer configuration and / or additional DL transport layer configuration(s) in the second DU-CU message instead of the first DU-CU message. In some embodiments, DU174 includes the MRB ID(s) associated with the first DU transport layer configuration and / or additional DU transport layer configuration(s) in the second DU-CU message instead of the first DU-CU message. Thus, the first DU-CU message does not include the DU transport layer configuration. In some embodiments, in response to the second DU-CU message, CU-CP172A transmits a second CU-DU message (e.g., a multicast delivery setup response message) to DU174 (516). In Figure 5A, events 510 and 516 are collectively referred to as the multicast delivery setup procedures.

[0086] After receiving the first CN~BS message (504), after receiving the first UP~CP message (562), after receiving the first DU~CU message (508), or after receiving the second DU~CU message (510), CU-CP172A sends the first BS~CN message (e.g., a delivery setup request message) to CN110 (512). In some embodiments, CU-CP172A sends the first BS~CN message to CN110 (512) before receiving the first DU~CU message (508) or before receiving the second DU~CU message (510). In a further embodiment, CU-CP172A includes a first CU transport layer configuration in the first BS~CN message. Thus, as described in event 532, CN110 sends MBS data to CU-UP172B via the first CN~BS common DL tunnel. In some embodiments, CU-CP172A includes a first MBS session ID in the first BS~CN message. In a further embodiment, CN110 sends a second CN~BS message (e.g., a delivery setup response message) to CU-CP172A in response to the first BS~CN message (514). In some embodiments, CN110 includes a first CN transport layer configuration in the second CN~BS message. The first CN transport layer configuration includes at least one CN transport layer address (e.g., one or more IP addresses) to identify the first CN~BS common DL tunnel. In some embodiments, the at least one transport layer address includes an IP source address and / or an IP multicast address. In some embodiments, the first CN transport layer configuration includes a TEID at CN110 or the TEID of CN110. In a further embodiment, CN110 includes a fourth MBS QoS flow configuration(s) of the first MBS session in the second CN~BS message. In some embodiments, the fourth MBS QoS flow configuration(s) is / are similar to the first MBS QoS flow configuration(s).

[0087] After receiving the second CN~BS message (514), CU-CP172A sends (564) the second CP~UP message (e.g., MC bearer context modification request message) to CU-UP172B. In some embodiments, CU-CP172A includes the MRB ID(s), the first DU transport layer configuration, additional DU transport layer configuration(s), and / or the first CN transport layer configuration in the second CP~UP message. In response to the second CP~UP message of event 564, CU-UP172B sends (566) the second UP~CP message (e.g., MC bearer context modification response message). In some embodiments, CU-UP172B includes the MRB ID(s) and / or the second CU transport layer configuration in the second UP~CP message. In some embodiments, the second CU transport layer configuration includes a CU transport layer address (e.g., IP address) to identify the first DU~CU common UL tunnel. The second CU transport layer configuration further includes the TEID of CU-UP172B. In a further embodiment, in response to the second DU~CU message of event 510, CU-CP172A includes the second CU transport layer configuration in the second CU~DU message and sends the second CU~DU message to DU174 (516). After receiving the second UP~CP message (566) or after sending the second CU~DU message (516), CU-CP172A sends (518) the second BS~CN message (e.g., multicast session activate response message) to CN110 in response to the first CN~BS message. Alternatively, CU-CP172A sends the second BS~CN message to CN110 (518) before receiving the second UP~CP message (566) or before sending the second CU~DU message (516).For example, after receiving the first CN~BS message (504), after receiving the first UP~CP message (562), after receiving the second DU~CU message (510), or after receiving the second CN~BS message (514), CU-CP172A transmits the second BS~CN message to CN110 (518).

[0088] In some embodiments, CU-CP172A includes the fourth MBS QoS flow configuration(s) in the MC bearer context modification request message. In some such embodiments, CU-UP172B modifies or reconfigures the resource(s) of the MRB(s) based on the fourth MBS QoS flow configuration(s). In some embodiments, CU-UP172B determines whether to modify or reconfigure the resource(s) of the MRB(s) based on the fourth MBS QoS flow configuration(s). For example, if the resource(s) of the MRB(s) in event 562 still satisfy the fourth MBS QoS flow configuration(s), CU-UP172B does not modify or reconfigure the resource of the first MRB. Otherwise, CU-UP172B modifies or reconfigures the resource(s) of the MRB(s) based on the fourth MBS QoS flow configuration(s). In some embodiments, CU-UP172B determines whether to modify or reconfigure the resource of a specific MRB among the MRB(s) based on the fourth MBS QoS flow configuration(s). For example, if the resource of the first MRB among the MRB(s) in event 562 still satisfies the specific configuration(s) of the fourth MBS QoS flow configuration(s) of the specific MBS QoS flow(s) mapped to the first MRB, CU-UP172B does not modify or reconfigure the resource of the first MRB. Otherwise, CU-UP172B modifies or reconfigures the resource of the first MRB based on the specific MBS QoS flow configuration(s).

[0089] In Fig. 5A, events 504, 560, 562, 506, 508, 510, 512, 514, 564, 566, 516, and 518 are collectively referred to as the MBS session resource set-up procedure 592A.

[0090] In some embodiments, the CN 110 transmits (520) a third CN-BS message indicating that the UE 102 participates in the first MBS session to the CU-CP 172A. In some embodiments, the CN 110 includes in the third CN-BS message a first MBS session ID and / or one or more MBS QoS flow identifiers that respectively identify the first MBS session and the one or more MBS QoS flows associated with the first MBS session. In response to the third CN-BS message, the CU-CP 172A transmits (527) a third BS-CN message to the CN 110. In some embodiments, after receiving the third CN-BS message, the CU-CP 172A transmits (522) a UE context request message to the DU 174 regarding the UE 102. In some embodiments, the CU-CP 172A includes one or more MRB IDs in the UE context request message. In further embodiments, the CU-CP 172A determines the one or more MRB IDs based on the first MBS session ID and / or the one or more MBS QoS flow identifiers received in the third CN-BS message. In some embodiments, the CU-CP 172A does not include the first MBS session ID in the UE context request message.

[0091] In response to the UE context request message of event 522, DU174 transmits (524) a UE context response message including multicast configuration parameters for UE102A to receive MBS data of the first MBS session via one or more MRBs to CU-CP172A. In some embodiments, some or all of the multicast configuration parameters may be associated with one or more MRBs and / or one or more MRB IDs. In some embodiments, DU174 generates a DU configuration (i.e., a first DU configuration) to include the multicast configuration parameters (i.e., the first multicast configuration parameters), and includes the DU configuration in the UE context response message. In some embodiments, the DU configuration is a CellGroupConfig IE. In other embodiments, the DU configuration is an MBS-specific IE. In some embodiments, the multicast configuration parameters configure one or more logical channels (LCs) for one or more MRBs. For example, the multicast configuration parameters include one or more logical channel IDs (LCIDs) to configure one or more logical channels. Each of the LCIDs identifies a specific logical channel among one or more logical channels. In some embodiments, the third CN~BS message and the third BS~CN message are a PDU session resource modification request message and a PDU session resource modification response message, respectively. In other embodiments, the third CN~BS message and the third BS~CN message are a PDU session resource setup request message and a PDU session resource setup response message, respectively. In some embodiments, the third CN~BS message and the third BS~CN message are UE-related messages (e.g., the messages are associated with a specific UE102).

[0092] In some embodiments, the UE context request message and the UE context response message are, respectively, the UE context setup request message and the UE context setup response message. In other embodiments, the UE context request message and the UE context response message are, respectively, the UE context modification request message and the UE context modification response message.

[0093] In some embodiments, after receiving the third CN~BS message, the CU-CP 172A executes a bearer context procedure (e.g., a UE-specific bearer context procedure) with the CU-UP 172B. In the bearer context procedure, the CU-CP 172A transmits a bearer context request message to the CU-UP 172B to request the establishment or modification of a bearer context (e.g., a unicast bearer context) for the UE 102. In response, the CU-UP 172B establishes or modifies the bearer context of the UE 102 and transmits a bearer context modification response message to the CU-CP 172A. In other embodiments, when receiving the third CN~BS message, the CU-CP 172A refrains from executing a bearer context procedure for the UE 102 with the CU-UP 172B. In some embodiments, the bearer context procedure is a bearer context setup procedure (e.g., defined in Section 8.3.1 of 3GPP (Registered Trademark) Specification 37.483 or 38.463). In some such cases, the bearer context request message and the bearer context setup message are, respectively, the bearer context setup request message and the bearer context setup response message. In other embodiments, the bearer context procedure is a bearer context modification procedure (e.g., defined in Section 8.3.2 of 3GPP Specification 37.483 or 38.463). In some such cases, the bearer context request message and the bearer context setup message are, respectively, the bearer context modification request message and the bearer context modification response message.

[0094] After receiving the UE context response message (524), 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 (s)), and transmits the RRC reconfiguration message to the DU 174 (526). The first MRB configuration (s) constitutes the MRB(s) (e.g., MRB(s) 1, …, N). In some embodiments, the first MRB configuration (s) includes the MRB ID(s) and the PDCP configuration(s). Next, the DU 174 transmits the RRC reconfiguration message to the UE 102 operating in the connected state (528). Then, the connected UE 102 transmits an RRC reconfiguration complete message to the DU 174 (530), and then the DU 174 transmits the RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the CU-CP 172A (531).

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

[0096] In Figure 5A, events 520, 522, 524, 526, 527 (described below), 528, 530, and 531 are collectively referred to as the UE-specific MBS session configuration procedure 594. The CN 110 and / or the CU-CP 172A executes the procedure 594 for each of the UEs (e.g., the UE 102A and the UE 102B) participating in the first MBS session. In some scenarios or embodiments, the procedure 594 is performed before the procedure 592A. In other scenarios or embodiments, the procedure 594 is performed after the procedure 592A. In still other scenarios or embodiments, the procedure 594 overlaps with the procedure 592A.

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

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

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

[0100] When CU-UP172B receives MBS data of the first MBS session from CN110 (532), CU-UP172B then transmits the MBS data to DU174 via the first CU-DU common tunnel and / or an additional CU-DU common DL tunnel (i.e., according to the first and / or additional DU transport layer configuration(s)) (534). In some cases where some of the MBS QoS flow(s) identified by the MBS QoS flow identifier(s) are associated with the MBS data, CU-UP172B determines the CU-DU common DL tunnel(s) to be used to transmit the MBS data to DU174 based on the MBS QoS flow identifier(s). For example, when CU-UP172B receives from CN110 the first MBS data packet associated with the first MBS flow identifier among the MBS QoS flow identifier(s), CU-UP172B transmits the first MBS data packet to DU174 via the first CU-DU common DL tunnel. When CU-UP172B receives from CN110 the second MBS data packet associated with the second MBS QoS flow identifier among the MBS QoS flow identifier(s), CU-UP172B transmits the second MBS data packet to DU174 via one of the additional CU-DU common tunnel(s). In some embodiments, CU-UP172B generates tunnel packets each containing a specific MBS data packet and transmits the MBS data packet via the first CU-DU common tunnel and / or an additional CU-DU common DL tunnel. In the case where CU-UP172B transmits one of the tunnel packets via the first CU-DU common tunnel, CU-UP172B sets the source IP address, target IP address, and TEID in the header of the tunnel packet to the IP address of the second CU transport layer configuration, the IP address of the first DU transport layer configuration, and the TEID of the first DU transport layer configuration, respectively.In such an embodiment, the IP address of the second CU transport layer configuration, the IP address of the first DU transport layer configuration, and the TEID of the first DU transport layer configuration identify the first CU-DU common DL tunnel. In the case where CU-UP172B transmits one of the tunnel packets via an additional CU-DU common tunnel, CU-UP172B sets the source IP address, the target IP address, and the TEID in the header of the tunnel packet to the IP address of the second CU transport layer configuration, the IP address of the additional DU transport layer configuration, and the TEID of the additional DU transport layer configuration, respectively. In such an embodiment, the IP address of the second CU transport layer configuration, the IP address of the additional DU transport layer configuration, and the TEID of the additional DU transport layer configuration identify the first CU-DU common DL tunnel.

[0101] When DU174 receives MBS data from CU-UP172B (534), DU174 transmits the MBS data to UE102 (e.g., via multicast or unicast) via one or more logical channels (536). UE102 receives the MBS data via one or more logical channels (536). For example, CU-UP172B receives an MBS data packet (532), generates a PDCP PDU including the MBS data packet, and transmits the PDCP PDU to DU174 (534). Next, DU174 generates a MAC PDU including a logical channel ID and the PDCP PDU, and transmits the MAC PDU to UE102 via multicast or unicast (536). UE102 receives the MAC PDU via multicast or unicast (536), obtains the PDCP PDU and the logical channel ID from the MAC PDU, identifies the PDCP PDU associated with the MRB according to the logical channel ID, and obtains the MBS data packet from the PDCP PDU according to the PDCP configuration within the MRB configuration. In some embodiments, DU174 transmits the MBS data or the MAC PDU to UE102 as described above via one or more multicast transmissions (e.g., dynamic multicast transmission(s) or SPS multicast transmission(s)) (536). In some such cases, UE102 receives the MBS data or the MAC PDU from DU174 as described above via one or more multicast transmissions (536). In some embodiments, UE102 uses a MAC entity to receive the MAC PDU or the MBS data (536), and uses a PDCP entity(ies) to process the PDCP PDU to obtain the MBS data.

[0102] In some embodiments, CU-CP 172A requests DU 174 to configure a CU-DU UE-specific DL tunnel for UE 102 in an event 522 UE context request message. In some embodiments, CU-CP 172A includes a CU transport layer configuration in the UE context request message to request a CU-DU UE-specific DL tunnel for UE 102. The CU transport layer configuration includes a CU transport layer address (e.g., an IP address) to identify the CU-DU UE-specific DL tunnel. In some embodiments, the CU transport layer configuration further includes the TEID of CU-UP 172B. In response, DU 174 includes a DU transport layer configuration that configures the CU-DU UE-specific DL 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). In some embodiments, 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 a further embodiment, CU-UP 172B sends (534) MBS data to DU 174 via the CU-DU UE-specific DL tunnel.

[0103] In some embodiments, the multicast configuration parameters also include one or more RLC bearer configurations each associated with a particular MRB. Each of the MRB configuration(s) includes an MRB ID, a PDCP configuration, a first MBS session ID, a PDCP re - establishment indication (e.g., reestablishPDCP), and / or a PDCP recovery indication (e.g., recoveryPDCP). In some embodiments, the PDCP configuration is the PDCP - Config IE of a DRB. In further embodiments, the RLC bearer configuration is the RLC - BearerConfig IE. In some embodiments, the RLC bearer configuration includes a logical channel (LC) ID that configures a logical channel. In some embodiments, the logical channel is an MBS traffic channel (MTCH). In other embodiments, the logical channel is a dedicated traffic channel (DTCH). In some embodiments, the multicast configuration parameters include a logical channel configuration (e.g., LogicalChannelConfig IE) that configures a logical channel. In some embodiments, the RLC bearer configuration includes an MRB ID.

[0104] In some embodiments, CU - CP172A configures the MRB as a DL - dedicated RB in the MRB configuration. For example, CU - CP172A refrains from including UL configuration parameters in the PDCP configuration within the MRB configuration to configure the MRB as a DL - dedicated RB. CU - CP172A includes only DL configuration parameters in the MRB configuration (e.g., as described above). In such a case, CU - CP172A configures UE102 such that UE102 does not transmit UL PDCP data PDUs to DU174 and / or CU - CP172A via the MRB by excluding the UL configuration parameters of the MRB from the PDCP configuration within the MRB configuration. In other examples, DU174 refrains from including UL configuration parameters in the RLC bearer configuration. In such a case, DU174 configures UE102 such that UE102 does not transmit control PDU(s) to the base station 104 via the logical channel by excluding the UL configuration parameters from the RLC bearer configuration.

[0105] In the case where DU174 includes UL configuration parameter(s) in the RLC bearer configuration, UE102 uses the UL configuration parameter(s) to transmit control PDU(s) (e.g., PDCP control PDU(s) and / or RLC control PDU(s)) to DU174 via a logical channel. In some embodiments, when the control PDU is a PDCP control PDU, DU174 transmits the PDCP control PDU to CU-UP172B. For example, CU-CP172A configures UE102 to receive MBS data using a compression or decompression protocol (e.g., the Robust Header Compression (ROHC) protocol). In such a case, when CU-UP172B receives an MBS data packet from CN110 (532), CU-UP172B compresses the MBS data packet using the compression protocol to obtain compressed MBS data packet(s), and transmits a PDCP PDU including the compressed MBS data packet to DU174 via the first or additional CU~DU common DL tunnel (534). Next, DU174 transmits the PDCP PDU to UE102 via the logical channel (e.g., in multicast or unicast) (536). When UE102 receives the PDCP PDU via the logical channel, UE102 obtains the compressed MBS data packet from the PDCP PDU. UE102 decompresses the compressed MBS data packet(s) using the compression or decompression protocol to obtain the original MBS data packet. In some such cases, UE102 transmits a PDCP control PDU including header compression protocol feedback (e.g., sporadic ROHC feedback) for the operation of the header compression or decompression protocol to DU174 via the logical channel. Next, DU174 transmits the PDCP control PDU to CU-UP172B via the UL tunnel. In some embodiments, the UL tunnel is a first DU~CU common tunnel configured with a first DU transport layer configuration and a second CU transport layer configuration. For example, the IP address of the first DU transport layer configuration, and the IP address and TEID of the second CU transport layer configuration identify the first DU~CU common tunnel.In other embodiments, the UL tunnel is specific to UE102. In some embodiments, CU-CP172A includes, in the UE context request message, the CU transport layer configuration that constitutes the UE-specific UL tunnel. The CU transport layer configuration includes a CU transport layer address (e.g., Internet Protocol (IP) address) and a TEID to identify the UE-specific UL tunnel. DU174 includes, in the UE context response message, the DU transport layer configuration that constitutes the UE-specific UL tunnel. The DU transport layer configuration includes a DU transport layer address (e.g., IP address and / or TEID). For example, the IP address of the DU transport layer configuration, and the IP address and TEID of the CU transport layer configuration identify a first common UL tunnel.

[0106] In some embodiments, the MRB configuration is an MRB-ToAddMod IE that includes an MRB ID (e.g., mrb-Identity or MRB-Identity). The MRB ID identifies a specific MRB among the MRB(s). In some cases where CU-CP 172A wants to configure DRB(s) for UE 102 for unicast data communication, CU-CP 172A sets one or more of the MRB ID(s) to a value different from the DRB ID(s) of the DRB(s). In some such cases, UE 102 and CU-CP 172A distinguish whether an RB is an MRB or a DRB according to the RB ID of the RB. In other embodiments, CU-CP sets the MAC of one of the MRB ID(s) to a value that is the same as the DRB ID(s). In some such cases, UE 102 and CU-CP 172A distinguish whether an RB is an MRB or a DRB according to the RB ID of the RB and the RRC IE that configures the RB. For example, the DRB configuration that configures a DRB is a DRB-ToAddMod IE that includes a DRB identifier (e.g., drb-Identity or DRB-Identity) and a PDCP configuration. Thus, in some such embodiments, UE 102 determines that an RB is a DRB when UE 102 receives a DRB-ToAddMod IE that configures the RB, and determines that an RB is an MRB when UE 102 receives an MRB-ToAddMod IE that configures the RB. Similarly, CU-CP 172A determines that an RB is a DRB when CU-CP 172A transmits a DRB-ToAddMod IE that configures the RB to UE 102, and determines that an RB is an MRB when CU-CP 172A transmits an MRB-ToAddMod IE that configures the RB to UE 102.

[0107] In some embodiments, the multicast configuration parameters for receiving MBS data of the first MBS session include one or more logical channel (LC) IDs to configure one or more logical channels. In some embodiments, the logical channel(s) is / are dedicated traffic channel(s) (DTCH(s)). In other embodiments, the logical channel(s) is / are multicast traffic channel(s) (MTCH(s)).

[0108] In some embodiments, the multicast configuration parameters include dynamic scheduling multicast configuration parameter(s) for UE102 to receive multicast transmissions, each of which includes MBS data or a specific part of MBS data. In some embodiments, the dynamic scheduling multicast configuration parameter(s) includes at least one of the following configuration parameters. A first exemplary parameter is a Group Radio Network Temporary Identifier (G-RNTI), with respect to which DU174 generates a DCI, scrambles the cyclic redundancy check (CRC) of the DCI with the G-RNTI, and transmits the DCI and the scrambled CRC on a PDCCH to dynamically schedule each multicast transmission for UE102 that includes a specific MAC PDU. In some embodiments, the MAC PDU includes an MBS data packet or a part of an MBS data packet. UE102 receives the DCI and the scrambled CRC on the PDCCH and verifies the scrambled CRC with the G-RNTI. After UE102 verifies that the CRC is valid for each multicast transmission, UE102 receives the multicast transmission according to the corresponding DCI and obtains the specific MAC PDU from the multicast transmission. In such cases, each multicast transmission is a dynamic scheduling multicast transmission used in the following description. In some embodiments, each DCI includes configuration parameters that configure dynamic scheduling multicast radio resources for scheduling the corresponding multicast transmission. In some embodiments, the configuration parameters include at least one of the following parameters. The configuration parameters of each DCI include (i) frequency domain resource allocation, (ii) time domain resource allocation, (iii) mapping from 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 allocation index, and / or (ix) PUCCH resource indicator, and include the same value and / or different values for the above configuration parameters.Another exemplary parameter is the HARQ codebook (ID), which indicates the HARQ ACK codebook index of the corresponding HARQ acknowledgement (ACK) codebook for the dynamic scheduling multicast transmission received by UE102. DU174 uses the HARQ codebook (ID) to receive HARQ ACK. In some cases where the configuration parameter does not include the HARQ codebook (ID), UE102 and DU174 use the HARQ codebook (ID) for unicast transmission. In some embodiments, UE102 receives the HARQ codebook (ID) for unicast transmission from DU174 in the DU configuration. In other embodiments, similar to events 516, 518, and 520, UE102 receives the HARQ codebook (ID) for unicast transmission from DU174 in other DU configurations. Another exemplary parameter is the PUCCH resource configuration, which indicates the HARQ resources on the PUCCH on which UE102 transmits HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for the dynamic scheduling multicast transmission. In some cases where the configuration parameter does not include the PUCCH resource configuration, UE102 and DU174 use the PUCCH resource configuration for unicast transmission to communicate HARQ feedback. Another exemplary parameter is the HARQ NACK-only indication, which configures UE102 to perform only the transmission of HARQ negative ACK (NACK) for the dynamic scheduling multicast transmission in which UE102 fails to receive and obtain the transport block from DU174. In some embodiments, UE102 fails to obtain the transport block because UE102 fails the cyclic redundancy check (CRC) of the transport block or UE102 does not receive the dynamic scheduling multicast transmission. In accordance with the indication, UE102 refrains from transmitting HARQ ACK to DU174 for the dynamic scheduling multicast transmission in which UE102 has received and obtained the transport block successfully.In some cases where the configuration parameter does not include an indication, UE102 transmits a HARQ ACK to DU174 for dynamic scheduling multicast transmissions that UE102 has successfully received and obtained the transport block. Another exemplary parameter is the HARQ ACK / NACK indication, which configures UE102 to transmit a HARQ NACK for dynamic scheduling multicast transmissions where UE102 was unable to obtain the transport block, and configures UE102 to transmit a HARQ ACK for dynamic scheduling multicast transmissions that UE102 has successfully received and obtained the transport block. In cases where the configuration parameter does not include an indication, UE102 refrains from transmitting a HARQ ACK to DU174 for dynamic scheduling multicast transmissions that UE102 has successfully received and obtained the transport block. In some such cases, UE102 only transmits a HARQ NACK to DU174 for dynamic scheduling multicast transmissions where UE102 was unable to obtain the transport block. Another exemplary parameter is the HARQ ACK indication, which configures UE102 to transmit a HARQ ACK for dynamic scheduling multicast transmissions that UE102 has successfully received and obtained the transport block. In cases where the configuration parameter does not include an indication, UE102 refrains from transmitting a HARQ ACK to DU174 for dynamic scheduling multicast transmissions that UE102 has successfully obtained the transport block. In such cases, UE102 only transmits a HARQ NACK to DU174 for dynamic scheduling multicast transmissions where UE102 was unable to obtain the transport block. In some embodiments, DU174 includes any one of a HARQ NACK indication, a HARQ ACK / NACK indication, and / or a HARQ ACK indication.Another exemplary parameter is the modulation and coding scheme (MCS) configuration, which indicates an MCS table that the DU 174 uses to transmit dynamic scheduling multicast transmissions and that the UE 102 uses to receive dynamic scheduling multicast transmissions. For example, the MCS table is a specific MCS table (e.g., the table defined in 3GPP specification 38.214 (e.g., the low SE 64QAM table shown in Table 5.1.3.1-3 of 3GPP TS 38.214, or a new table specific to multicast transmissions)). In some embodiments, if the DU 174 does not include the MCS configuration in the DU configuration, the UE 102 and the DU 174 apply a predetermined MCS table (e.g., the table defined in 3GPP specification 38.214). For example, the predetermined MCS table is a 256QAM table or a 64QAM table (e.g., the table shown in Table 5.1.3.1-2 of specification 38.214, or the non-low SE 64QAM table shown in Table 5.1.3.1-1, respectively). In cases where the DU 174 does not include the MCS configuration in the DU configuration, the UE 102 and the DU 174 apply the MCS table to unicast transmissions to receive dynamic scheduling multicast transmissions from the DU 174. In some embodiments, the DU 174 includes in the DU configuration a PDSCH configuration (e.g., the PDSCH-Config IE) that configures the MCS table for unicast transmissions. In other embodiments, similar to events 516, 518, and 520, the DU 174 transmits to the UE 102 other DU configurations that include the PDSCH configuration. Another exemplary parameter is the aggregation factor, which is the number of repetitions of the dynamic scheduling multicast transmission(s). In some embodiments, the DU 174 transmits (e.g., multicasts) the dynamic scheduling multicast transmission according to the aggregation factor for the number of repetitions, and the UE 102 receives repetitively 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 applies the aggregation factor to unicast transmission(s) in some embodiments.In some embodiments, DU174 includes the aggregation factor(s) for unicast transmission(s) to UE102 in the DU configuration. In other embodiments, similar to events 516, 518, and 520, DU174 transmits other DU configurations that include the aggregation factor for unicast transmission to UE102.

[0109] The RRC reconfiguration message of the UE participating in the first MBS session includes the same multicast configuration parameters for receiving the MBS data of the first MBS session. In some embodiments, the RRC reconfiguration message of the UE includes the same or different configuration parameters for receiving non-MBS data.

[0110] In some embodiments, the multicast configuration parameters include at least one semi-persistent scheduling (SPS) multicast configuration for the UE102 to receive MBS data. In some embodiments, each of the SPS multicast configuration(s) includes at least one of the following parameters for SPS multicast transmission. An exemplary first parameter is the group configuration scheduling radio network temporary identifier (G-CS-RNTI), which is used to activate or release SPS multicast radio resources. In some embodiments, the DU174 generates an SPS multicast radio resource activation command (e.g., DCI), scrambles the CRC of the DCI with the G-CS-RNTI, and transmits the DCI and the scrambled CRC on the PDCCH to activate the SPS multicast radio resources for the UE102. After activating the SPS multicast radio resources, the DU174 periodically transmits multicast transmissions on the SPS multicast radio resources according to the DCI. The UE102 receives the DCI and the scrambled CRC on the PDCCH and verifies the scrambled CRC with the G-CS-RNTI. After the UE102 verifies that the CRC is valid, the UE102 activates the SPS multicast radio resources in response to the DCI (e.g., starts receiving on the SPS multicast radio resources) and periodically receives multicast transmissions on the SPS multicast radio resources according to the SPS multicast radio resource activation command (e.g., DCI) before the UE102 deactivates the SPS multicast radio resources. In such cases, the multicast transmission is the SPS multicast transmission used in the following description. In some embodiments, the DU174 generates an SPS multicast radio resource deactivation command (e.g., DCI), scrambles the CRC of the DCI with the G-CS-RNTI, and transmits the DCI and the scrambled CRC on the PDCCH to deactivate or release the SPS multicast radio resources.UE 102 receives DCI and scrambled CRC on the PDCCH and verifies the scrambled CRC using the G-CS-RNTI. After the UE 102 verifies that the CRC is valid, the UE 102 deactivates the SPS multicast radio resources (e.g., stops receiving on the SPS multicast radio resources). In some embodiments, each of the SPS multicast transmissions includes a specific MAC PDU, which includes an MBS data packet or a portion of an MBS data packet. In some embodiments, the SPS multicast radio resource activation command (e.g., DCI) includes configuration parameters that configure the SPS multicast radio resources. In some embodiments, the configuration parameters include at least one of the following parameters: (i) frequency domain resource allocation, (ii) time domain resource allocation, (iii) mapping from 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 allocation index, and / or (ix) PUCCH resource indicator. Another exemplary parameter is the period, which indicates the period of the SPS multicast radio resources.

[0111] Another exemplary parameter is the number of HARQ processes, which indicates the number of HARQ processes for communicating SPS multicast transmissions. DU174 uses a maximum of the specified number of HARQ processes to transmit SPS multicast transmissions, and UE102 uses a maximum of the specified number of HARQ processes to receive SPS multicast transmissions. Another exemplary parameter is the HARQ codebook ID, which indicates the HARQ ACK codebook index of the corresponding HARQ confirmation ACK codebook for an SPS multicast transmission received by UE102 or an SPS multicast radio resource deactivate command. In some cases where the configuration parameter does not include the HARQ codebook (ID), UE102 uses the HARQ codebook (ID) for dynamically scheduled multicast transmissions as described above. Alternatively, UE102 uses the HARQ codebook (ID) for unicast transmissions. In some embodiments, UE102 receives the HARQ codebook (ID) for unicast transmissions in the DU configuration from DU174 as described above. Another exemplary parameter is the HARQ process ID offset, which indicates the offset used to derive the HARQ process ID for DU174 to transmit SPS multicast transmissions and the HARQ process ID for UE102 to receive SPS multicast transmissions. Another exemplary parameter is the PUCCH resource configuration for SPS multicast transmissions, which indicates the HARQ resources on the PUCCH for UE102 to transmit HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for SPS multicast transmissions. In some cases where the configuration parameter does not include the PUCCH resource configuration for SPS multicast transmissions, UE102 and DU174 use the PUCCH resource configuration for dynamically scheduled multicast transmissions to communicate HARQ feedback as described above. Alternatively, UE102 uses the PUCCH resource configuration for unicast transmissions. In some embodiments, UE102 uses the PUCCH resource configuration for unicast transmissions as described above.Another exemplary parameter is the HARQ NACK-only indication, which configures the UE 102 to perform only the transmission of HARQ negative ACK (NACK) for SPS multicast transmissions where the UE 102 fails to receive from the DU 174 and obtain the transport block. In some embodiments, the UE 102 fails the cyclic redundancy check (CRC) of the transport block, or the UE 102 does not receive dynamic scheduling multicast transmissions, so the UE 102 cannot obtain the transport block. In accordance with the indication, the UE 102 refrains from sending HARQ ACK to the DU 174 for SPS multicast transmissions where the UE 102 has successfully received and obtained the transport block. In some cases where the configuration parameter does not include the indication, the UE 102 sends HARQ ACK to the DU 174 for SPS multicast transmissions where the UE 102 has successfully received and obtained the transport block. Another exemplary parameter is the HARQ ACK / NACK indication, which configures the UE 102 to send HARQ NACK for SPS multicast transmissions where the UE 102 fails to obtain the transport block, and configures the UE 102 to send HARQ ACK for SPS multicast transmissions where the UE 102 has successfully received and obtained the transport block. In cases where the configuration parameter does not include the indication, the UE 102 refrains from sending HARQ ACK to the DU 174 for SPS multicast transmissions where the UE 102 has successfully received and obtained the transport block. In such cases, the UE 102 performs only the transmission of HARQ NACK to the DU 174 for SPS multicast transmissions where the UE 102 fails to obtain the transport block. Another exemplary parameter is the HARQ ACK indication, which configures the UE 102 to send HARQ ACK for SPS multicast transmissions where the UE 102 has successfully received and obtained the transport block. In cases where the configuration parameter does not include the indication, the UE 102 refrains from sending HARQ ACK to the DU 174 for SPS multicast transmissions where the UE 102 has successfully obtained the transport block.In such cases, the UE 102 only transmits a HARQ NACK to the DU 174 regarding SPS multicast transmissions for which the UE 102 was unable to obtain a transport block. In some embodiments, the DU 174 includes any one of a HARQ NACK indication, a HARQ ACK / NACK indication, and / or a HARQ ACK indication. Another exemplary parameter is the aggregation factor, which is the number of repetitions of the SPS multicast transmission(s). The DU 174 transmits the number of repetitions, the SPS multicast transmission according to the aggregation factor, and the UE 102 receives repetitively 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 to dynamic scheduling multicast transmissions as described above. Alternatively, the UE 102 and the DU 174 apply the aggregation factor to unicast transmission(s). In some embodiments, the UE 102 and the DU 174 apply the aggregation factor to unicast transmission(s) as described above. Another exemplary parameter is the MCS configuration, which indicates the MCS table that the DU 174 uses to transmit the SPS multicast transmission and that the UE 102 uses to receive the SPS multicast transmission. For example, the MCS table is a specific MCS table (e.g., the table defined in 3GPP specification 38.214 (e.g., the low SE 64QAM table shown in Table 5.1.3.1-3 of 3GPP TS 38.214, or a new table specific to multicast transmissions)). In some embodiments, if the DU 174 does not include the MCS configuration in the DU configuration, the UE 102 and the DU 174 apply a predetermined MCS table (e.g., the table defined in 3GPP specification 38.214). For example, the predetermined MCS table is a 256QAM table or a 64QAM table (e.g., the table shown in Table 5.1.3.1-2 of specification 38.214, or the non-low SE 64QAM table shown in Table 5.1.3.1-1, respectively).In some cases where DU174 does not include the MCS configuration within the DU configuration, UE102 and DU174, in other embodiments, apply the MCS table to the dynamic scheduling multicast transmission in order to receive the SPS multicast transmission from DU174 as described above. Alternatively, UE102 and DU174 apply the MCS table to the unicast transmission in order to receive the SPS multicast transmission from DU174. In some embodiments, UE102 and DU174 apply the MCS table to the unicast transmission in order to receive the SPS multicast transmission from DU174 as described above. In some embodiments, DU174 includes in the DU configuration a PDSCH configuration (e.g., PDSCH-Config IE) that configures the MCS table for unicast transmission. In other embodiments, similar to events 516, 518, and 520, DU174 transmits to UE102 another DU configuration that includes the PDSCH configuration.

[0112] In some embodiments, CU-CP172A includes in the RRC reconfiguration message an MBS session participation response message. In further embodiments, UE102 includes in the RRC reconfiguration complete message an MBS session participation complete message. Alternatively, UE102 transmits to CU-CP172A via DU174 a UL RRC message that includes the MBS session participation complete message. Depending on the embodiment, the UL RRC message can be a ULInformationTransfer message or any suitable RRC message that can include a UL NAS PDU. In some embodiments, CU-CP172A includes in the second BS~CN message an MBS session participation complete message. Alternatively, CU-CP172A transmits to CN110 a BS~CN message (e.g., UPLINK NAS TRANSPORT message) that includes the MBS session participation complete message.

[0113] In other embodiments, the CU-CP 172A transmits a DL RRC message including an MBS session participation response message to the UE 102. Depending on the embodiment, the DL RRC message can be a DL Information Transfer message, another RRC reconfiguration message, or any suitable RRC message that can include a DL NAS PDU. In some embodiments, the UE 102 transmits a UL RRC message including an MBS session participation completion message to the CU-CP 172A via the DU 174. In further embodiments, the UL RRC message can be a UL Information Transfer message, another RRC reconfiguration completion message, or any suitable RRC message that can include a UL NAS PDU.

[0114] In Figure 5A, events 532, 534, and 536 are collectively referred to as the MBS session data transmission procedure 596.

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

[0116] Figure 5B shows an exemplary scenario 500B similar to scenario 500A shown in Figure 5A. In scenario 500B, CN110 includes the first MBS QoS flow configuration(s) in the second CN~BS message of event 514. In some such cases, CN110 does not include the first MBS QoS flow configuration(s) in the first CN~BS message. After receiving the second CN~BS message, CU-CP172A performs the transmission of the first CP~UP message (560) to CU-UP172B and the transmission of the first CU~DU message (506) to DU174, respectively. In other words, CU-CP172A delays the transmission of the first CP~UP message and the first CU~DU message (e.g., delays the execution of the MC bearer context setup procedure and the multicast context setup procedure) until it receives the first MBS QoS flow configuration(s) or the second CN~BS message.

[0117] In Figure 5B, events 502, 512, 514, 560, 562, 506, 508, 510, 564, 566, 516, and 518 are collectively referred to as the MBS session resource setup procedure 592B.

[0118] In some embodiments, CN110 includes the first slice information in the second CN~BS message of event 514. In some such cases, CN110 does not include the first slice information in the first CN~BS message. In some embodiments, CN110 includes the first MBS area information in the second CN~BS message of event 514. In some such cases, CN110 does not include the first MBS area information in the first CN~BS message.

[0119] Figure 5C shows an exemplary scenario 500C similar to scenarios 500A and 500B shown in Figures 5A and 5B respectively. In scenario 500C, CN110 includes a first MBS QoS flow configuration(s) in the third CN~BS message of event 520. After receiving the third CN~BS message, CN110, CU-CP172A, CU-UP172B, and DU174 execute an MBS session resource configuration procedure (592A or 592B), where CU-CP172A generates a second MBS QoS flow configuration(s) based on the first MBS QoS flow configuration(s) received in the third CN~BS message of event 520. In some embodiments, events 504 and 518 of procedures 592A or 592B may be omitted in scenario 500C. In some embodiments, before, during, or after procedures 592A or 592B, CU-CP172A sends a third BS~CN message to CN110 (527).

[0120] In Figure 5C, events 520, 527, and 592A or 592B are collectively referred to as an MBS session resource setup procedure 592C.

[0121] In some embodiments, CN110 includes first slice information in the third CN~BS message of event 520. In some such cases, CN110 does not include first slice information in the first CN~BS message. In some embodiments, CN110 includes first MBS area information in the third CN~BS message of event 520. In some such cases, CN110 does not include first MBS area information in the first CN~BS message.

[0122] Figure 5D shows an exemplary scenario 500D in which CN110 and base station 104 manage the transmission of downlink data of an MBS session for a UE operating in a connected state and an inactive state. In some embodiments of scenario 500D, while UE102 communicates with base station 104 (596), CU-CP172A determines (542) to transition UE102 from the connected state to the inactive state based on the data inactivity of UE102 (i.e., based on the fact that UE102 in the connected state has no data activity with base station 104 other than receiving MBS data). In some embodiments, such as when UE102 communicates with base station 104, UE102 identifies or detects data inactivity and transmits UE assistance information (e.g., UE Assistance Information message) indicating that UE102 desires or requests a transition to the inactive state or disconnection from the connected state to DU174 (535). Next, DU174 transmits an UL RRC message transfer message including the UE assistance information to CU-CP172A (537). Thus, in some such embodiments, CU-CP172A identifies that UE102 indicates data inactivity based on the UE assistance information.

[0123] In other embodiments, DU174 performs data inactivity monitoring for UE102. In some such embodiments, CU-CP172A transmits a CU~DU message (e.g., a UE context setup request message or a UE context modification request message) to DU174 to request or instruct DU174 to perform data inactivity monitoring. In some cases where DU174 detects or identifies that UE102 indicates data inactivity during the monitoring, DU174 transmits an inactivity notification (e.g., a UE inactivity notification message) to CU-CP172A (538). Thus, CU-CP172A identifies that UE102 indicates data inactivity based on the inactivity notification received from DU174.

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

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

[0126] In response to identifying that UE102 indicates data inactivity (e.g., for a certain period), or after identifying it, or in response to determining to transition UE102 to an inactive state, or after determining it, CU-CP172A sends a bearer context modification request message to CP-UP172B to suspend unicast data transmission to UE102 (544). In response to this, CU-UP172B suspends data transmission to UE102 and sends a bearer context modification response message to CU-CP172A (546). In some embodiments, in response to identifying that UE102 indicates data inactivity, or after identifying it, or in response to determining to transition UE102 to an inactive state, or after determining it, CU-CP172A sends a CU-DU message (e.g., a UE context modification request message) to instruct DU174 to provide multicast configuration parameter(s) for the inactive state (548). In some embodiments, CU-CP172A includes a multicast request indication (e.g., a multicast indication for the inactive state) requesting multicast configuration parameter(s) for the inactive state in the CU-DU message of event 548.

[0127] In a further embodiment, in response to a multicast request indication or a CU-DU message, DU 174 transmits (550) a DU-CU message (e.g., a UE context modification response message) including multicast configuration parameter(s) for the inactive state (i.e., a second multicast configuration parameter(s) for a UE 102 operating in the inactive state to receive a multicast transmission including MBS data from DU 174) to CU-CP 172A. Alternatively, DU 174 does not include the second multicast configuration parameter(s) in the DU-CU message of event 548. Instead, DU 174 transmits an additional DU-CU message (e.g., a UE context modification request received message) including the second multicast configuration parameter(s) to CU-CP 172A after receiving the CU-DU message of event 548 or after transmitting the DU-CU message of event 550. In some embodiments, CU-CP 172A transmits an additional CU-DU message (e.g., a UE context modification confirmation message) to DU 174 in response to the additional CU-DU message.

[0128] In some embodiments, in response to determining to transition UE102 to the inactive state, CU-CP172A generates an RRC release message (e.g., an RRCRelease message or an RRCConnectionRelease message) to transition UE102 to the inactive state. In some embodiments, CU-CP172A includes second multicast configuration parameter(s) for the inactive state (e.g., if obtained from DU174), and / or an MRB configuration for the inactive state (e.g., a second MRB configuration) in the RRC release message. CU-CP172A then transmits a CU-DU message (e.g., a UE context release command message, a UE context modification request message, or a DL RRC message transfer message) including the RRC release message to DU174 (552). Next, DU174 transmits the RRC release message or a PDCP PDU to UE102 (554). In some embodiments, DU174 generates a MAC PDU including the RRC release message and transmits the MAC PDU to UE102 (554). The RRC release message instructs UE102 to transition to the inactive state. Upon receiving the RRC release message, UE102 transitions from the connected state to the inactive state (556). In some embodiments, UE102 stops or suspends receiving unicast data from DU174 in response to the RRC release message or in response to the transition 556 to the inactive state. For example, the unicast data includes data associated with one or more SRBs and / or one or more DRBs. In some embodiments, UE102 stops monitoring the PDCCH using one or more UE-specific radio network temporary identifier(s) (RNTI(s)) (e.g., RNTI(s) specific to UE102) in response to the RRC release message or in response to the transition 556 to the inactive state. In some embodiments, the one or more UE-specific RNTI(s) includes the C-RNTI of UE102.

[0129] In FIG. 5D, events 535, 537, 538, 540, 542, 544, 546, 548, 550, 552, and 554 are collectively referred to as UE-specific RRC state transition procedure 588.

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

[0131] In other embodiments, UE102 stops or suspends receiving MBS data from DU174 in response to an RRC release message or in response to a transition 556 to the inactive state. In some such embodiments, the inactive UE102 stops monitoring the PDCCH using the G-RNTI and / or G-CS-RNTI in response to, or upon, stopping or suspending the reception of MBS data. In some embodiments, when DU174 receives MBS data (e.g., event 561), DU174 sends a multicast reception indication to UE102 (e.g., via multicast or broadcast) (557) to instruct UE102 to receive multicast transmissions. In a further embodiment, after receiving the multicast reception indication, the inactive UE102 begins, or attempts to begin, receiving MBS data for the first MBS session, as described below. In some embodiments, the multicast reception indication is a paging message (e.g., including the first MBS session ID). In other embodiments, the multicast reception indication is a DCI (e.g., a short message) including a specific field that instructs UE102 to receive multicast transmissions. In some embodiments, to send the DCI, DU174 generates a CRC for the DCI, scrambles the CRC with a paging radio network temporary identifier (P-RNTI), and transmits the DCI and the scrambled CRC on the PDCCH that UE102 monitors. UE102 receives the DCI and the scrambled CRC on the PDCCH and verifies whether the scrambled CRC is valid. If UE102 verifies that the scrambled CRC is valid, UE102 begins, or attempts to begin, receiving MBS data for the first MBS session from DU174. Otherwise, if UE102 verifies that the scrambled CRC is invalid, UE102 continues to stop or suspend receiving MBS data from DU174.

[0132] In some embodiments, in response to the CU-DU message of event 552, DU174 holds the second multicast configuration parameter(s), and releases the unicast configuration parameter (e.g., the configuration parameter for unicast communication) configured by DU174 for UE102. Alternatively, DU174 releases the second multicast configuration parameter(s). In some embodiments, in response to the CU-DU message of event 552, DU174 sends a DU-CU message (e.g., a UE context release completion message or a UE context modification response message) to CU-CP172A.

[0133] After transitioning UE102 to the inactive state or while UE102 is operating in the inactive state, CU-UP172B receives (559) MBS data of the first MBS session from CN110, sends (561) the MBS data to DU174, and these operations are similar to events 532 and 534 respectively. DU174 sends (563) the MBS data to UE102 (e.g., via multicast), similar to event 536. For example, the MBS data includes one or more MBS data packets, and DU174 sends one or more multicast transmissions each containing a specific MBS data packet(s) (563). The inactive UE102 receives the MBS data or the multicast transmission(s) (563) according to the second multicast configuration parameter(s).

[0134] In some embodiments, the foregoing examples or embodiments regarding the first multicast configuration parameter(s) also apply to the second multicast configuration parameter(s). In some embodiments, the second multicast configuration parameter(s) extend the first multicast configuration parameter(s). In such embodiments, UE102 extends the first multicast configuration parameter(s) according to the second multicast configuration parameter(s). Thus, the non-active UE102 receives MBS data (563) according to the second multicast configuration parameter(s) and the configuration parameter(s) of the first multicast configuration parameter(s) that are not extended by the second multicast configuration parameter(s). In some embodiments, UE102 holds the configuration parameter(s) (e.g., value(s)) extended by the second multicast configuration parameter(s). In some such embodiments, DU174 or CU-CP172A holds the configuration parameter(s) extended by the second multicast configuration parameter(s) of UE102. In some embodiments, when UE102 transitions from the non-active state to the connected state, UE102 uses the held configuration parameter(s) to receive MBS data of the first MBS session from DU174. Alternatively, UE102 releases the configuration parameter(s) extended by the second multicast configuration parameter(s).

[0135] In some embodiments, the first multicast configuration parameter(s) includes a first configuration(s) that configures UE102 to transmit HARQ feedback for multicast transmissions (e.g., including MBS data), and the second multicast configuration parameter(s) releases the first configuration(s). In some embodiments, the second multicast configuration parameter(s) includes a second configuration(s) that releases or invalidates the first configuration(s). In response to the second configuration(s), UE102 releases or invalidates the first configuration(s). In further embodiments, the second multicast configuration parameter(s) excludes the first configuration(s) and instructs UE102 to release or invalidate the first configuration(s). In response to the second multicast configuration parameter(s) excluding the first configuration(s), UE102 releases or invalidates the first configuration(s).

[0136] In other embodiments, UE102 receives MBS data (563) using the second multicast configuration parameter(s) instead of the first multicast configuration parameter(s). In some such cases, UE102 retains the first multicast configuration parameter(s). In further embodiments, when UE102 transitions from an inactive state to a connected state, UE102 receives MBS data for a first MBS session from DU174 using the first multicast configuration parameter(s) instead of the second multicast configuration parameter(s). Alternatively, UE102 releases the first multicast configuration parameter(s) in response to an RRC release message.

[0137] In some embodiments, the second MRB configuration indicates or constitutes the MRB(s). For example, the second MRB configuration includes MRB ID(s) that each identify the MRB(s). UE102 receives MBS data (563) using the indicated or configured MRB(s). In other embodiments, the RRC release message does not include an MRB configuration for indicating or constituting the MRB(s). In such embodiments, UE102 receives MBS data (563) using all of the MRB(s) configured in step 594.

[0138] Figure 5E shows an exemplary scenario 500E similar to scenario 500D shown in Figure 5D. In some embodiments of scenario 500E, after CU-CP172A receives the second multicast configuration parameter(s) from DU174, instead of an RRC release message, it generates an RRC reconfiguration message that includes the second multicast configuration parameter(s). CU-CP172A transmits a CU-DU message including the RRC reconfiguration message to DU174 (567), and DU174 then transmits the RRC reconfiguration message to UE102 (568), and these operations are similar to events 526 and 528 respectively. In response, UE102 transmits an RRC reconfiguration complete message to DU174 (570), and DU174 then transmits a DU-CU message including the RRC reconfiguration complete message to CU-CP172A (572). In some embodiments, DU174 generates the second multicast configuration parameter(s) in the same format as the first multicast configuration parameter, and the RRC reconfiguration message does not indicate the multicast configuration parameter(s). In some such cases, UE102 does not recognize that the second multicast configuration parameter(s) are specific to the inactive state, and a connected UE receives MBS data of the first MBS session from DU174 according to the second multicast configuration parameter(s).

[0139] In some embodiments, in response to determining to transition UE102 to the inactive state, CU-CP172A generates an RRC release message (e.g., an RRCRelease message or an RRCConnectionRelease message) to transition UE102 to the inactive state. In some embodiments, CU-CP172A includes in the RRC release message an indication (e.g., a multicast inactive activation indication) indicating that UE102 is to receive or continue to receive MBS data after transitioning to the inactive state. Similar to event 552, CU-CP172A transmits the RRC release message to DU174 (553). Next, DU174 transmits the RRC release message to UE102 (555), similar to event 554. When CU-CP172A transmits an RRC reconfiguration message (567), CU-CP172A transmits the RRC release message (553) after receiving an RRC reconfiguration complete message (570). In response to receiving the RRC release message, or upon receiving the RRC release message, UE102 transitions from the connected state to the inactive state (556).

[0140] In Figure 5E, events 535, 537, 538, 540, 542, 544, 546, 548, 550, 553, and 555 are collectively referred to as UE-specific RRC state transition procedure 589.

[0141] UE102 determines to continue to receive or attempt to receive MBS data in response to the indication (e.g., a multicast inactive activation indication) (558). If the RRC release message does not include the indication (e.g., a multicast inactive activation indication), UE102 determines not to receive MBS data after receiving the RRC release message or after transitioning to the inactive state, or stops receiving MBS data.

[0142] When CU-CP172A does not send the second multicast configuration parameter(s) to UE102 (e.g., events 567, 568, 570, and 572 are omitted), the inactive UE102 continues to receive MBS data using the first multicast configuration parameter (563). Alternatively, in such a case, the inactive UE102 receives MBS data using the first part of the first multicast configuration parameter (563) and refrains from receiving MBS data using the second part or the remaining part of the first multicast configuration parameter (563).

[0143] Referring now to FIGS. 6-11, these figures generally illustrate various ways in which a UE is configured with multicast configuration parameters (e.g., PDCP configuration and / or MAC configuration) and receives MBS data packets from a RAN node during an inactive or connected state according to the corresponding multicast configuration parameters. FIGS. 6-7 illustrate that a UE is configured to receive MBS data in an inactive or connected state. FIGS. 8-11 illustrate that a UE is configured with multicast configuration parameters (e.g., PDCP configuration and / or MAC configuration) and receives MBS data in an inactive state or only in a connected state.

[0144] Referring first to FIG. 6, a UE (e.g., UE102) may implement method 600 to receive MBS data packet(s) from a RAN (e.g., base station 104 or RAN105) while operating in an inactive state.

[0145] Method 600 begins at block 602, where the UE receives at least one RRC message including a first multicast configuration from the RAN while operating in the connected state (e.g., events 528, 594, 554, 568, 555). At block 604, the UE transitions from the connected state to the inactive state (e.g., events 554, 555). At block 606, the UE receives a multicast transmission from the RAN according to the first multicast configuration while operating in the inactive state (e.g., events 563, 597).

[0146] In some embodiments, the first multicast configuration includes multicast configuration parameters (e.g., first multicast configuration parameters and / or second multicast configuration parameters (if any)) and / or an indication (e.g., a multicast inactive activation indication) described with respect to FIGS. 5A - 5E.

[0147] In some embodiments, at least one first RRC message includes an RRC reconfiguration message(s) and / or an RRC release message. In some embodiments, at least one first RRC message includes an RRC release message that causes the UE to transition from the connected state to the inactive state. The UE transitions to the inactive state at block 604 in response to the RRC release message.

[0148] In other embodiments, at least one RRC message includes an RRC reconfiguration message(s) and does not include an RRC release message. In such embodiments, the UE further receives an RRC release message that causes the UE to transition from the connected state to the inactive state, and the RRC release message does not include a multicast configuration (e.g., a configuration for receiving multicast transmissions). The UE transitions to the inactive state at block 604 in response to the RRC release message.

[0149] In some embodiments, the UE receives multicast transmissions from the RAN according to a first multicast configuration while operating in a connected state (e.g., event 536). In some further embodiments, the UE receives an additional multicast configuration(s) for receiving multicast transmissions from the RAN while operating in a connected state. In such cases, the UE receives multicast transmissions from the RAN according to the first multicast configuration and the additional multicast configuration(s) while operating in a connected state (e.g., events 536, 596). For example, the additional multicast configuration(s) includes HARQ feedback configuration parameter(s) that configure HARQ feedback for the multicast transmissions (e.g., HARQ ACK and / or NACK), and the first multicast configuration does not include HARQ feedback configuration parameter(s).

[0150] In some embodiments, the UE indicates support for receiving multicast transmissions or receiving multicast MBS in the inactive state directly to the RAN or via the CN to the RAN. In some embodiments, the UE transmits a UE capability information message including a UE capability IE (e.g., UE-NR-Capability or UE-6G-Capability) to the RAN, and the UE capability IE includes a first multicast capability indicating support for receiving multicast transmissions or receiving multicast MBS in the inactive state. In some embodiments, the UE capability IE includes a second multicast capability indicating support for receiving multicast transmissions or receiving multicast MBS in the connected state. In some embodiments, the RAN forwards the UE capability IE to the CN, and the CN stores the UE capability IE in storage. In some embodiments, when the UE disconnects from the RAN and the CN and the UE reconnects to the CN via the RAN, the CN transmits the UE capability IE to the RAN, and the RAN does not initiate a UE capability inquiry procedure to obtain the UE capability from the UE. In other embodiments, the UE transmits a NAS message (e.g., a registration request message or a registration completion message) including a UE capability ID that identifies the UE capability IE stored in the CN (e.g., stored during the registration procedure to the CN) to the CN via the RAN. The CN uses the UE capability ID to retrieve the UE capability IE from storage and transmits the UE capability IE to the RAN. Based on the first multicast capability, the RAN determines to configure the UE to receive multicast transmissions or multicast MBS in the inactive state. Based on the second multicast capability, the RAN determines to configure the UE to receive multicast transmissions in the connected state. In an alternative embodiment, the RAN determines to configure the UE to receive multicast transmissions in the connected state based on the first multicast capability. In such an embodiment, if the UE supports receiving multicast transmissions or multicast MBS in the inactive state, the UE also supports receiving multicast transmissions or multicast MBS in the connected state.

[0151] Next, referring to FIG. 7, a UE (e.g., UE102) may implement method 700 to receive MBS data packet(s) from a RAN node (e.g., BS104 or RAN105) while operating in an inactive state and / or a connected state.

[0152] Method 700 begins at block 702, where the UE receives, from the RAN node, first multicast configuration parameters for receiving multicast transmissions (e.g., events 528, 594). At block 704, while operating in a connected state, the UE receives multicast transmissions from the RAN according to the first multicast configuration parameters (e.g., events 536, 596). At block 706, the UE receives, from the RAN node, second multicast configuration parameters for receiving MBS data (e.g., events 554, 568). At block 708, while operating in an inactive state, the UE receives multicast transmissions from the RAN according to the second multicast configuration parameters (e.g., events 563, 597).

[0153] Referring to FIG. 8, a UE (e.g., UE102) may implement method 800 to determine whether to receive MBS data packet(s) from a RAN node (e.g., BS104 or RAN105) while operating in an inactive state and / or a connected state.

[0154] Method 800 begins at block 802, where, while operating in a connected state, the UE receives from the RAN a first RRC message including first multicast configuration parameters (e.g., events 528, 594, 568). At block 804, while operating in a connected state, the UE receives from the RAN a multicast transmission (e.g., including MBS data packet(s) of an MBS session) according to the first multicast configuration parameters (e.g., events 536, 596). At block 806, the UE receives from the RAN a second RRC message that transitions the UE from the connected state to the inactive state (e.g., events 554, 555). At block 808, the UE determines whether the second RRC message configures reception of multicast transmissions in the inactive state. If, at block 808, the UE determines that the second RRC message configures reception of multicast transmissions in the inactive state, the flow proceeds to block 810, where, in response to the second RRC message, while operating in the inactive state, the UE receives from the RAN a multicast transmission (e.g., including MBS data packet(s) of an MBS session) (e.g., events 563, 597).

[0155] If, at block 808, the RAN node determines that the second RRC message does not configure reception of multicast transmissions in the inactive state, the flow proceeds to block 812, where, in response to the second RRC message, the UE stops receiving multicast transmissions from the RAN.

[0156] In some embodiments, the first RRC message and the second RRC message are an RRC reconfiguration message and an RRC release message, respectively.

[0157] In some embodiments, at block 810, the UE receives multicast transmissions from the RAN according to the first multicast configuration parameters. If the second RRC message includes the second multicast configuration parameter(s), the UE receives multicast transmissions from the RAN according to the second multicast configuration parameter(s), as described with respect to FIG. 5D.

[0158] Referring to FIG. 9, a UE (e.g., UE 102) may implement method 900 to receive MBS data packet(s) from a RAN node (e.g., base station 104 or RAN 105) while operating in an inactive state and / or a connected state.

[0159] Method 900 begins at block 902, where the UE receives, from the RAN, a first RRC message that configures an MRB while operating in a connected state (e.g., events 528, 594, 568). At block 904, the UE receives, via the MRB, MBS data packet(s) from the RAN while operating in a connected state (e.g., events 536, 596). At block 906, the UE receives, from the RAN, a second RRC message that transitions the UE to an inactive state (e.g., events 554, 555). At block 908, the UE transitions from the connected state to the inactive state in response to the second RRC message. At block 910, the UE determines whether the second RRC message configures reception of multicast transmissions in the inactive state. If, at block 910, the UE determines that the second RRC message configures reception of multicast transmissions in the inactive state, the flow proceeds to block 912, where, after transitioning to the inactive state, the UE continues to receive or receives MBS data packet(s) from the RAN via the MRB (e.g., events 563, 597).

[0160] If at block 910, the RAN node determines that the second RRC message does not configure reception of multicast transmission in the inactive state, the flow proceeds to block 914, where the UE suspends the MRB in response to the second RRC message.

[0161] In some embodiments, the first RRC message and the second RRC message are an RRC reconfiguration message and an RRC release message, respectively. In some embodiments, method 900 is combined with method 800.

[0162] Referring to FIG. 10, a UE (e.g., UE 102) may implement method 1000 to receive MBS data packet(s) from a RAN node (e.g., base station 104 or RAN 105) in the inactive state and / or the connected state.

[0163] Method 1000 starts from block 1002. At block 1002, the UE receives, from the RAN, a first RRC message including a PDCP configuration for receiving MBS data packet(s) while operating in the connected state (e.g., events 528, 594, 568). At block 1003, the UE configures (e.g., establishes) a PDCP entity according to the PDCP configuration. At block 1004, the UE uses the PDCP entity to receive MBS data packet(s) from the RAN while operating in the connected state (e.g., events 536, 596). At block 1006, the UE receives, from the RAN, a second RRC message that transitions the UE to the inactive state (e.g., events 554, 555). At block 1008, the UE transitions from the connected state to the inactive state in response to the second RRC message. At block 1010, the UE determines whether the second RRC message configures reception of multicast transmissions in the inactive state (e.g., whether the second RRC message configures the UE to receive multicast transmissions in the inactive state). If, at block 1010, the UE determines that the second RRC message configures reception of multicast transmissions in the inactive state, the flow proceeds to block 1012. At block 1012, after transitioning to the inactive state, the UE continues to receive or receives MBS data packet(s) from the RAN via the PDCP entity (e.g., events 563, 597).

[0164] If, at block 1010, the RAN node determines that the second RRC message does not configure reception of multicast transmissions in the inactive state, the flow proceeds to block 1014. At block 1014, the UE suspends the PDCP entity in response to the second RRC message.

[0165] In some embodiments, the first RRC message and the second RRC message are an RRC reconfiguration message and an RRC release message, respectively. In some embodiments, the PDCP configuration is a PDCP-Config IE (e.g., defined in 3GPP specification 38.331). In some embodiments, method 1000 is combined with method 800 and / or method 900.

[0166] Referring to FIG. 11, a UE (e.g., UE 102) may perform method 1100 to receive MBS data packet(s) from a RAN node (e.g., base station 104 or RAN 105) in an inactive state and / or a connected state.

[0167] Method 1100 starts from block 1102. At block 1102, the UE receives, from the RAN, a first RRC message including a MAC configuration for receiving MBS data packet(s) while operating in the connected state (e.g., events 528, 594, 568). At block 1103, the UE configures a MAC entity according to the MAC configuration. At block 1104, the UE uses the MAC entity to receive MBS data packet(s) from the RAN while operating in the connected state (e.g., events 536, 596). At block 1106, the UE receives, from the RAN, a second RRC message for transitioning the UE to the inactive state (e.g., events 554, 555). At block 1108, the UE transitions from the connected state to the inactive state in response to the second RRC message. At block 1110, the UE determines whether the second RRC message configures reception of multicast transmission in the inactive state (e.g., whether the second RRC message configures the UE to receive multicast transmission in the inactive state). If, at block 1110, the UE determines that the second RRC message configures reception of multicast transmission in the inactive state, the flow proceeds to block 1112. At block 1112, after transitioning to the inactive state, the UE continues to receive or receives MBS data packet(s) from the RAN via the MAC entity (e.g., events 563, 597). Next, the flow proceeds from block 1112 to block 1111 where the UE awaits resetting the MAC entity in response to the second RRC message, or from block 1112 to block 1113 where the UE awaits resetting the HARQ process for unicast communication and resetting the HARQ process(es) for multicast communication. The HARQ process for unicast communication and the HARQ process(es) for multicast communication are associated with or belong to the MAC entity.

[0168] If the RAN node determines at block 1110 that the second RRC message does not configure reception of multicast transmission in the inactive state, the flow proceeds to block 1114, where the UE resets the MAC entity in response to the second RRC message. In some embodiments, when the UE resets the MAC entity at block 1114, the UE also resets the HARQ processes associated with or belonging to the MAC entity and used for unicast and multicast communications.

[0169] In some embodiments, the first RRC message and the second RRC message are an RRC reconfiguration message and an RRC release message, respectively. In some embodiments, the MAC configuration is a MAC-CellGroupConfig IE (e.g., defined in 3GPP specification 38.331). In some embodiments, method 1100 is combined with method 800, method 900, and / or method 1000.

[0170] In some embodiments, when the UE resets a HARQ process (e.g., an UL HARQ process), the UE sets the new data indicator (NDI) of the UL HARQ process to value 0. In some embodiments, when the UE resets a HARQ process (e.g., a DL HARQ process), the UE flushes the soft buffer of the DL HARQ process.

[0171] The following list of examples reflects various embodiments explicitly contemplated by the present disclosure.

[0172] Example 1 A multicast and / or broadcast service (MBS) communication method implemented in a user equipment (UE), the method comprising: receiving a first multicast configuration including a first MBS radio bearer (MRB) configuration for receiving MBS in a connected state; receiving first MBS data in the connected state according to the first multicast configuration; receiving a second multicast configuration including a second MRB configuration for receiving MBS data in a non-active state; and receiving second MBS data in the non-active state according to the second multicast configuration.

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

[0174] Generally, the description regarding one of the above figures is applicable to the other figures among the above figures. The aforementioned events or blocks may be optional or may be omitted. For example, the events or blocks depicted by dashed lines in the figure may be optional or may be omitted. In some cases, even the events or blocks depicted by solid lines in the figure may be optional or may be omitted if the events or blocks are unnecessary. In some embodiments, "message" is used, but it may be replaced with "information element (IE)". In some embodiments, "IE" is used, but it may be replaced with "field". In some embodiments, "configuration" may be replaced with "multiple configurations" or configuration parameters. In some embodiments, "MBS" may be replaced with "multicast" or "multicast MBS". In some embodiments, "MBS data" may be replaced with "multicast transmission(s)". In some embodiments, "multicast MBS" and "multicast transmission(s)" are interchangeable. In some embodiments, "multicast communication", "multicast reception", and "multicast transmission" are interchangeable. In some embodiments, "SPS multicast" may be replaced with "multicast SPS". Similarly, "dynamic scheduling multicast" may be replaced with "multicast dynamic". In some embodiments, "identifier" may be replaced with "identity". In some embodiments, "CFR" is used, but it may be replaced with "MBS BWP". In some embodiments, the term "transport layer configuration" may be replaced with "tunnel information" or "transport layer information". In some embodiments, "in accordance with" may be replaced with "using". In some embodiments, "unicast communication" may be replaced with "unicast data communication".

[0175] A user device (e.g., UE102A, 102B, or UE103) capable of implementing the techniques of the present disclosure can be any suitable device capable of wireless communication, such as a smartphone, tablet computer, laptop computer, mobile game console, point-of-sale (POS) terminal, health monitoring device, drone, camera, media streaming dongle or other personal media device, wearable device such as a smartwatch, wireless hotspot, femtocell, or broadband router, etc. Further, in some cases, the user device can be embedded in an electronic system such as a vehicle head unit or an advanced driver assistance system (ADAS). Further, the user device can operate as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0176] Certain embodiments are described in this disclosure as including logic, or some components or modules. A module can be a software module (e.g., code stored in a non-transitory machine-readable medium), or a hardware module. A hardware module is a tangible unit capable of performing certain operations and can be configured or arranged in a particular manner. For example, a hardware module can include dedicated circuitry or dedicated 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 can also include programmable logic or programmable circuitry that is temporarily configured by software to perform certain operations (e.g., included within a general-purpose processor or other programmable processor). The decision of whether to implement a hardware module in a permanently configured dedicated circuit or in a temporarily configured (e.g., software-configured) circuit can be made considering cost and time.

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

[0178] Upon reading this disclosure, those skilled in the art will appreciate additional alternative structural and functional designs for performing HARQ processes to transmit MBS data through the principles disclosed herein. Thus, while specific embodiments and applications have been illustrated and described, it should be understood that the disclosed embodiments are not limited to the detailed structures and components disclosed herein. Various modifications, changes, and variations apparent to those skilled in the art may be made to the arrangement, operation, and details of the methods and apparatuses disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims

1. A multicast and / or broadcast service (MBS) communication method implemented in a radio access network (RAN), comprising: transmitting, to a UE operating in the connected state, a first multicast configuration including a first MBS radio bearer (MRB) configuration for receiving MBS data in the connected state; transmitting first MBS data to the UE operating in the connected state according to the first multicast configuration; transmitting, to the UE, a second multicast configuration including a second MRB configuration for receiving MBS data in the inactive state; transmitting second MBS data to the UE operating in the inactive state according to the second MRB configuration; A method comprising the above.

2. The transmitting the first multicast configuration to the second UE includes: transmitting a radio resource control (RRC) reconfiguration command including the first multicast configuration; The method according to claim 1, comprising the above.

3. The transmitting the second multicast configuration to the UE includes: transmitting an RRC release command including the second multicast configuration; The method according to any one of claims 1 or 2, comprising the above.

4. The method according to any one of claims 1 to 3, wherein the MRB configuration includes an MBS session identifier.

5. The method according to any one of claims 1 to 4, wherein the first multicast configuration includes parameters of a multicast traffic channel (MTCH).

6. The method according to any one of claims 1 to 5, wherein the first multicast configuration includes scheduling parameters.

7. The method according to any one of claims 1 to 6, wherein the first multicast configuration and the second multicast configuration include parameters of a multicast traffic channel (MTCH).

8. A multicast and / or broadcast service (MBS) communication method implemented in a user equipment (UE), comprising: receiving, from a radio access network (RAN), a first radio resource control (RRC) message including a multicast configuration for receiving MBS data in the connected state; receiving first MBS data in the connected state according to the multicast configuration; Receiving, from the RAN, a second RRC message indicating that the UE transitions to an inactive state; In response to a determination that the second RRC message configures the UE to receive second MBS data in the inactive state, receiving the second MBS data in the inactive state; Or, in response to a determination that the second RRC message does not configure the UE to receive the second MBS data in the inactive state, stopping reception of MBS data in the inactive state; A method comprising.

9. The multicast configuration is a first multicast configuration, Receiving the second MBS data in the inactive state includes receiving the second MBS data in the inactive state according to a second multicast configuration received in the second RRC message. The method according to claim 8.

10. The first multicast configuration includes a first MRB configuration, The second multicast configuration includes a second MRB configuration. The method according to claim 9.

11. The first RRC message is an RRC reconfiguration command. The method according to any one of claims 8 to 10.

12. The second RRC message is an RRC release command. The method according to any one of claims 8 to 11.

13. The multicast configuration includes parameters of a multicast traffic channel (MTCH). The method according to any one of claims 8.

14. The first multicast configuration includes scheduling parameters. The method according to any one of claims 8.

15. A transceiver; Processing hardware configured to implement the method according to any one of claims 1 to 14; An apparatus comprising.

Images