Managing the reception of multicast and / or broadcast services after state transitions.

Abstract

In a method for managing multicast and / or broadcast service (MBS) communications after a state transition, while the UE is in a connected state with the RAN, the UE receives MBS data from the RAN using MBS configuration parameters. The UE transitions from the connected state to an idle or inactive state. While the UE is in the idle or inactive state, based on whether the MBS configuration parameters are for receiving a broadcast MBS session or a non-broadcast MBS session, the UE continues to receive or does not receive MBS data using the MBS configuration parameters, respectively.

Description

Technical Field

[0001] The present disclosure relates to wireless communication, and more particularly, to managing configuration parameters for multicast and / or broadcast services (MBS) and reception of MBS after a state transition.

Background Art

[0002] The description of the background art provided herein is for the purpose of schematically presenting the context of the present disclosure. The research of the inventors, as currently named, is not, as far as it is described in this background art section, necessarily regarded as prior art at the time of filing in some cases, in the same way as aspects of this specification that may not be regarded as prior art. Neither explicitly nor implicitly is it admitted as prior art to the present disclosure.

[0003] In telecommunications systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as the transfer, encryption, and integrity protection of user plane data. For example, the PDCP layer defined for Advanced Universal Terrestrial Radio Access (EUTRA) radio interfaces (see 3GPP specification TS 36.323) and New Radio (NR) (see 3GPP specification TS 38.323) provides sequencing of protocol data units (PDUs) in the uplink direction (from user devices, also known as user equipment (UEs), to base stations) and in the downlink direction (from base stations to UEs). Furthermore, the PDCP sublayer provides services for signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer. The PDCP sublayer also provides services for data radio bearers (DRBs) to protocol layers such as the Service Data Adaptive Protocol (SDAP) sublayer or the Internet Protocol (IP) layer, Ethernet Protocol layer, or Internet Control Message Protocol (ICMP) layer. Generally, UEs and base stations can use SRBs to exchange RRC and non-access layer (NAS) messages, and DRBs to transport data over the user plane.

[0004] The RRC sublayer specifies the RRC_IDLE state, in which the UE does not have an active radio connection with a base station; the RRC_CONNECTED state, in which the UE has an active radio connection with a base station; and the RRC_INACTIVE state, which allows the UE to transition back to the RRC_CONNECTED state more quickly through base station coordination and RAN paging procedures at the Radio Access Network (RAN) level.

[0005] In some scenarios, a UE can operate in a state where its radio resource control connection with the RAN is inactive (e.g., RRC_IDLE or RRC_INACTIVE) and then transition to a connected state. Generally, in an inactive state, the radio connection between the UE and the RAN is suspended. Later, when the UE is triggered to send data (e.g., an outgoing phone call, a browser launch) or receives a paging message from the base station, the UE can then transition to a connected state. To perform this transition, the UE can request the base station to establish a radio connection (e.g., by sending an RRC setup request message to the base station) or resume the suspended radio connection (e.g., by sending an RRC resume request message to the base station), and as a result, the base station can configure the UE to operate in a connected state.

[0006] In some cases, a UE in the RRC_IDLE or RRC_INACTIVE state has only one packet (or a relatively small packet) to send, or a base station has only one packet (or a relatively small packet) to send to a UE operating in the RRC_IDLE or RRC_INACTIVE state. In these cases, a UE in the RRC_IDLE or RRC_INACTIVE state can perform early data communication without transitioning to the RRC_CONNECTED state by using, for example, the techniques specified in 3GPP specification 36.300 v16.4.0 sections 7.3a-7.3d.

[0007] Base stations operating in accordance with the requirements for 5G New Radio (NR) support significantly larger bandwidths than 4G base stations. Therefore, the 3G Partnership Project (3GPP®) proposes for Release 15 that UEs support 100MHz bandwidth in frequency range 1 (FR1) and 400MHz bandwidth in frequency range 2 (FR2). Due to the relatively wide bandwidth of typical carriers in 5G NR, 3GPP® proposes for Release 17 that 5G NR base stations can provide multicast and / or broadcast services (MBS) to UEs. MBS can be useful in many content delivery applications, such as transparent IPv4 / IPv6 multicast distribution, IPTV, software distribution over wireless, group communications, Internet of Things (IoT) applications, V2X applications, and emergency messaging related to public safety.

[0008] 5G NR provides both point-to-point (PTP) and point-to-multipoint (PTM) distribution methods for transmitting MBS packet flows over a radio interface. In PTP communication, a RAN node sends different copies of each MBS data packet to different UEs over the radio interface, while in PTM communication, a RAN node sends a single copy of each MBS data packet to multiple UEs over the radio interface. However, it is unclear how base stations and UEs handle configuration parameters in some scenarios when an UE transitions from one state to another, for example, from the RRC_CONNECTED state to the RRC_IDLE or RRC_INACTIVE state, or from the RRC_INACTIVE state to the RRC_IDLE state. [Prior art documents] [Non-patent literature]

[0009] [Non-Patent Document 1] 3GPP specification TS 36.323 [Non-Patent Document 2] 3GPP specification TS 38.323 [Non-Patent Document 3] 3GPP specification 36.300 v16.4.0 sections 7.3a~7.3d [Overview of the project] [Means for solving the problem]

[0010] In one aspect of the present disclosure, a method implemented by a UE for managing MBS communication after a state transition includes the steps of: receiving MBS data from the RAN using MBS configuration parameters while the UE is in a connected state with the RAN; transitioning from the connected state to an idle or inactive state; and while the UE is in an idle or inactive state, continuing to receive or ceasing to receive MBS data using MBS configuration parameters, based on whether the MBS configuration parameters are for receiving a broadcast MBS session or a non-broadcast MBS session, respectively.

[0011] In another aspect of the present disclosure, a method implemented by a UE for managing MBS communication after a state transition includes the steps of: receiving MBS data from the RAN via a first MRB and / or a second MRB while the UE is in a connected state with the RAN; receiving an RRC release message from the RAN while the UE is in a connected state; and, in response to the RRC release message, (i) transitioning from a connected state to an idle or inactive state; and (ii) releasing or suspending the first MRB. The method further includes the step of receiving further MBS data from the RAN via a second MRB while the UE is in an idle or inactive RRC state.

[0012] In another aspect of the present disclosure, a method implemented by a UE for managing MBS communication after a state transition includes the steps of receiving MBS data from the RAN using the MBS configuration parameter while the UE is in an inactive state and holding the unicast configuration parameter, and transitioning from the inactive state to an idle state. The method also includes, in response to the transition step, the steps of releasing the unicast configuration parameter and receiving further MBS data from the RAN using the MBS configuration parameter while the UE is in an idle state.

[0013] In another aspect of the present disclosure, a method for managing MBS communications, implemented by a RAN node, includes the steps of: transmitting MBS data to a UE via an MRB; deciding to release the MRB for the UE; and, after the deciding step, not sending or sending an RRC release message to the UE, depending on whether the UE is configured with a DRB or not.

[0014] In another aspect of the present disclosure, a method for managing MBS communications, implemented by a base station CU, includes the steps of transmitting MBS data to a UE via the base station's DU and MRB, and deciding to release the MRB for the UE. The method also includes, after the deciding step, the step of not sending or sending a first CU-DU message to the DU indicating that the DU should release the UE context for the UE, based on whether the UE is configured with a DRB or not. [Brief explanation of the drawing]

[0015] [Figure 1A] This is a block diagram of an exemplary wireless communication system in which techniques for managing the transmission and reception of MBS information may be implemented. [Figure 1B] Figure 1A is a block diagram of an exemplary distributed base station in which a central unit (CU) and distributed units (DUs) can operate. [Figure 2A]Accordingly, Figure 1A is a block diagram of an exemplary protocol stack that enables the UE to communicate with the base station in Figure 1A. [Figure 2B] Accordingly, Figure 1A is a block diagram of an exemplary protocol stack that enables the UE to communicate with the DU and CU of the distributed base station. [Figure 3] This block diagram shows an exemplary tunnel architecture for MBS and PDU sessions. [Figure 4] This block shows exemplary MRBs and DRBs that distributed base stations can be configured to communicate with UEs (Unified Entity) for multicast traffic, broadcast traffic, and / or unicast traffic. [Figure 5] This is a messaging diagram illustrating an exemplary scenario in which a CN and distributed base stations configure resources for transmitting MBS data for one or more MBS sessions to multiple UEs. [Figure 6] This is a messaging diagram illustrating an exemplary scenario in which a CN and distributed base stations configure resources for transmitting MBS data for one or more MBS sessions to multiple UEs. [Figure 7A] Figure 1A is a flowchart illustrating an exemplary method for managing MBS configuration parameters and MBS data reception after state transitions, which can be implemented in the UE. [Figure 7B] Figure 1A is a flowchart illustrating an exemplary method for managing MBS configuration parameters and MBS data reception after state transitions, which can be implemented in the UE. [Figure 8] Figure 1A is a flowchart illustrating an exemplary method for managing MBS configuration parameters and MBS data reception after state transitions, which can be implemented in the UE. [Figure 9A] Figure 1A is a flowchart illustrating an exemplary method for managing MBS configuration parameters and MBS data reception after state transitions, which can be implemented in the UE. [Figure 9B]A flowchart of an exemplary method for managing MBS configuration parameters and MBS data reception after a state transition, which can be implemented in the UE of FIG. 1A. [Figure 10A] A flowchart of an exemplary method for managing MBS configuration parameters and MBS data reception after a state transition, which can be implemented in the UE of FIG. 1A. [Figure 10B] A flowchart of an exemplary method for managing MBS configuration parameters and MBS data reception after a state transition, which can be implemented in the UE of FIG. 1A. [Figure 11A] A flowchart of an exemplary method for managing MBS configuration parameters, which can be implemented in the base station of FIG. 1A or in the DU of FIG. 1B. [Figure 11B] A flowchart of an exemplary method for managing MBS configuration parameters, which can be implemented in the base station of FIG. 1A or in the DU of FIG. 1B. [Figure 12A] A flowchart of an exemplary method for managing MBS configuration parameters, which can be implemented in the base station of FIG. 1A or in the DU of FIG. 1B. [Figure 12B] A flowchart of an exemplary method for managing MBS configuration parameters, which can be implemented in the base station of FIG. 1A or in the DU of FIG. 1B.

Mode for Carrying Out the Invention

[0016] Generally, a radio access network (RAN) and / or core network (CN) implements the techniques of this disclosure to manage the transmission of multicast and / or broadcast services (MBS). The CN may request that a base station configure a common downlink (DL) tunnel through which the CN can transmit MBS data for MBS sessions to multiple UEs. In response to the request, the base station transmits a configuration of the common DL tunnel to the CN. The configuration may include transport layer information such as an Internet Protocol (IP) address and a tunnel identifier (e.g., a tunnel endpoint identifier (TEID)).

[0017] The base station can also configure one or more logical channels toward the UE and / or one or more MBS radio bearers (MRBs) associated with the MBS session, provided there is a one-to-one mapping between each logical channel and each MRB. After receiving MBS data for the MBS session from the CN via a common DL tunnel, the base station can transmit the MBS data through one or more logical channels to one or more UEs participating in the MBS session. In some implementations, the base station transmits MBS data to multiple UEs through a single logical channel. Furthermore, if there are multiple quality of service (QoS) flows for the MBS session, a single logical channel may be associated with multiple QoS flows, or there may be a one-to-one mapping between each QoS flow and each logical channel.

[0018] Before or after a UE joins an MBS session, the CN can have the base station configure a common DL tunnel. If additional UEs join the MBS session after the tunnel has been configured, the CN can use the same common DL tunnel to send MBS data to the base station for multiple UEs.

[0019] Figure 1A illustrates an exemplary wireless communication system 100 in which the techniques of this disclosure for managing the transmission and reception of MBS information may be implemented. The wireless communication system 100 includes base stations 104, 106 of UE 102A, 102B, 103 and RAN 105 connected to CN 110. In other implementations or scenarios, the wireless communication system 100 may instead include more or fewer UEs and / or more or fewer base stations than shown in Figure 1A. Base stations 104, 106 may be any preferred one or more types of base stations, such as advanced node B (eNB), next-generation eNB (ng-eNB), or 5G node B (gNB). In a more specific example, base station 104 may be an eNB or a gNB, and base station 106 may be a gNB.

[0020] Base station 104 supports cell 124, and base station 106 supports cell 126. Cell 124 partially overlaps with cell 126, and as a result, UE102A can be within range of base station 104 while simultaneously being within range of base station 104 (or within range of detecting or measuring signals from base station 106). This overlap can, for example, allow UE102A to hand over between cells (e.g., from cell 124 to cell 126) or between base stations (e.g., from base station 104 to base station 106) before UE102A experiences a radio link failure. Furthermore, this overlap enables various dual connectivity (DC) scenarios. For example, UE102A can communicate in DC with base station 104 (acting as a master node (MN)) and base station 106 (acting as a secondary node (SN)). When UE102A is in DC with base stations 104 and 106, base station 104 operates as a master eNB (MeNB), master ng-eNB (Mng-eNB), or master gNB (MgNB), and base station 106 operates as a secondary gNB (SgNB) or secondary ng-eNB (Sng-eNB).

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

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

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

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

[0025] UE102A includes processing hardware 150, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory for storing machine-readable instructions executable on the general-purpose processors and / or dedicated processing units. In the exemplary implementation shown in Figure 1A, processing hardware 150 includes an MBS controller 152 configured to manage or control the reception of MBS information. For example, the MBS controller 152 may be configured to support RRC configurations, procedures, and messaging associated with MBS procedures, and / or other operations associated with those configurations and / or procedures, as described below. Processing hardware 150 may also include a non-MBS controller 154 configured to manage or control one or more RRC configurations and / or RRC procedures according to one of the implementations described below when UE102A communicates with MN and / or SN during non-MBS operation. Although not shown in Figure 1A, UE102B and 103 may each include processing hardware similar to that of UE102A.

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

[0027] Among its components, the EPC111 may include a Serving Gateway (SGW)112, a Mobility Management Entity (MME)114, and a Packet Data Network Gateway (PGW)116. The SGW112 is generally configured to forward user plane packets related to audio calls, video calls, internet traffic, etc., and the MME114 is configured to manage authentication, registration, paging, and other related functions. The PGW116 provides connectivity from the UE (e.g., UE102A or 102B) to one or more external packet data networks, such as the Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC160 includes User Plane Functions (UPF)162, Access and Mobility Management (AMF)164, and / or Session Management Functions (SMF)166. UPF162 is generally configured to forward user plane packets related to audio calls, video calls, internet traffic, etc., AMF164 is generally configured to manage authentication, registration, paging, and other related functions, and SMF166 is generally configured to manage PDU sessions.

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

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

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

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

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

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

[0034] In some implementations, CU172 may include one or more logical nodes (CU-CP172A) 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-UP172B) that host the user plane portion of the PDCP protocol and / or the Service Data Adaptive Protocol (SDAP) protocol of CU172. As described herein, CU-CP172A may transmit non-MBS control information and MBS control information, and CU-UP172B may transmit non-MBS data packets and MBS data packets.

[0035] A CU-CP172A can be connected to multiple CU-UP172Bs via the E1 interface. The CU-CP172A selects the appropriate CU-UP172B for the requested service for the UE102A. In some implementations, a single CU-UP172B can be connected to multiple CU-CP172As via the E1 interface. A CU-CP172A can be connected to one or more DU174s via the F1-C interface. A CU-UP172B can be connected to one or more DU174s via the F1-U interface under the control of the same CU-CP172A. In some implementations, a single DU174 can be connected to multiple CU-UP172Bs under the control of the same CU-CP172A. In such implementations, connectivity between the CU-UP172B and DU174 is established by the CU-CP172A using bearer context management functionality.

[0036] The above description can be applied to UE102B and / or 103, just as it is to UE102A.

[0037] Figure 2A shows a simplified exemplary protocol stack 200 accordingly, which enables a UE (e.g., UE102A, 102B, or 103) to communicate with an eNB / ng-eNB or a gNB / en-gNB (e.g., one or both of base stations 104, 106). In the exemplary protocol stack 200, the EUTRA PHY sublayer 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides RLC channels to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. Next, the NR RLC sublayer 206B provides an RLC channel to the NR PDCP sublayer 210. In some implementations, the UE 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 DC via EUTRA and NR interfaces. Furthermore, as shown in Figure 2A, the UE can support layering of the NR PDCP 210 on top of the EUTRA RLC 206A, and the SDAP sublayer 212 on top of the NR PDCP sublayer 210. Sublayers are sometimes simply referred to as "layers" in this specification.

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

[0039] On the control plane, the EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide an SRB for exchanging, for example, RRC messages or Non-Access Layer (NAS) messages. On the user plane, the EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide a DRB to support data exchange. The data exchanged on the NR PDCP sublayer 210 may be, for example, SDAP PDUs, IP packets, or Ethernet packets.

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

[0041] In some implementations, a base station (e.g., base station 104 or 106) broadcasts MBS data packets via one or more MRBs, and the UE then receives the MBS data packets via the MRBs. The base station can include the configuration of the MRBs in the multicast configuration parameters (sometimes called MBS configuration parameters) described below. In some implementations, the base station broadcasts MBS data packets via RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and the UE correspondingly receives the MBS data packets using PHY sublayer 202, MAC sublayer 204, and RLC sublayer 206. In such implementations, the base station and UE do not need to use PDCP sublayer 208 and SDAP sublayer 212 to communicate the MBS data packets. In other implementations, the base station transmits MBS data packets via PDCP sublayer 208, RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and the UE receives MBS data packets in response using PHY sublayer 202, MAC sublayer 204, RLC sublayer 206, and PDCP sublayer 208. In such implementations, the base station and UE do not need to use SDAP sublayer 212 to communicate MBS data packets. In yet another implementation, the base station transmits MBS data packets via SDAP sublayer 212, PDCP sublayer 208, RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and the UE receives MBS data packets in response using PHY sublayer 202, MAC sublayer 204, RLC sublayer 206, PDCP sublayer 208, and SDAP sublayer 212.

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

[0043] Next, referring to Figure 3, which illustrates an exemplary tunnel architecture 300 for MBS and PDU sessions, an MBS session 302A may include a tunnel 312A having endpoints at CN110 and base stations 104 / 106 (i.e., base station 104 or base station 106). An MBS session 302A may correspond to a specific session ID, such as Temporary Mobile Group Identification Information (TMGI). MBS data may include, for example, IP packets, TCP / IP packets, UDP / IP packets, Real-time Transport Protocol (RTP) / UDP / IP packets, or RTP / TCP / IP packets.

[0044] In some cases, CN110 and / or base stations 104 / 106 configure tunnel 312A solely for MBS traffic directed from CN110 to base stations 104 / 106, and tunnel 312A may be referred to as a downlink (DL) tunnel. However, in other cases, CN110 and base stations 104 / 106 use tunnel 312A for both downlink MBS traffic and uplink (UL) MBS traffic, for example, to support commands or service requests from UEs. Furthermore, since base stations 104 / 106 can direct MBS traffic arriving via tunnel 312A to multiple UEs, tunnel 312A may be referred to as a common tunnel or common DL tunnel.

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

[0046] As shown in Figure 3, base stations 104 / 106 map the traffic in tunnel 312A to N radio bearers 314A-1, 314A-2, ... 314A-N, which can be configured as MBS radio bearers, i.e., MRBs, where N ≥ 1. Each MRB can correspond to its respective logical channel. As described above, the PDCP sublayer provides support for radio bearers such as SRBs, DRBs, and MRBs, and the EUTRA MAC sublayer or NR MAC sublayer provides logical channels to the EUTRA RLC sublayer or NR RLC sublayer. Each MRB 314A can correspond to, for example, its respective MBS traffic channel (MTCH). Base stations 104 / 106 and CN 110 can also maintain another MBS session 302B, which likewise can contain tunnel 312B corresponding to MRBs 314B-1, 314B-2, ... 314B-N, where N ≥ 1. Each MRB314B can correspond to its respective logic channel.

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

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

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

[0050] Next, referring to Figure 4, which illustrates exemplary MRBs and DRBs when base stations (e.g., base stations 104 or 106) are implemented in a distributed manner, CU172 and DU174 can establish tunnels for downlink and / or uplink data associated with the MRB or DRB. The MRB314A-1 described above may be implemented as an MRB402A connecting CU172 to multiple UEs (e.g., UE102A and 102B). The MRB402A may include a DL tunnel 412A connecting CU172 and DU174, and a DL logical channel 422A corresponding to the DL tunnel 412A. In detail, DU174 may map downlink traffic received via the DL tunnel 412A to the DL logical channel 422A, which may be, for example, an MTCH or DTCH. The DL tunnel 412A may be a common DL tunnel through which CU172 transmits MBS data packets to multiple UEs. Alternatively, DL tunnel 412A could be a UE-specific DL tunnel through which CU172 transmits MBS data packets to a specific UE.

[0051] Optionally, the MRB402A also includes a UL tunnel 413A connecting the CU172 and DU174, and a UL logical channel 423A corresponding to the UL tunnel 413A. The UL logical channel 423A may be, for example, a DTCH. The DU174 can map uplink traffic received via the UL logical channel 423A to the UL tunnel 413A.

[0052] Tunnels 412A and 413A can operate at the transport layer or sublayer of the F1-U interface. More specifically, CU172 and DU174 can utilize F1-U for user plane traffic, and tunnels 412A and 413A can be associated with the GTP-U protocol layered on top of UDP / IP, where IP is layered on top of the preferred data link layer and physical (PHY) layer. Furthermore, in at least some cases, MRB402 and / or DRB404 additionally support control plane traffic. More specifically, CU172 and DU174 can exchange F1-AP messages via an F1-C interface relying on the Stream Control Transmission Protocol (SCTP) layered on top of IP, where IP, like F1-U, is layered on top of the preferred data link layer and PHY layer.

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

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

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

[0056] In some implementations, one of the DU174 assigns a specific logical channel ID (value) to each logical channel associated with an MRB that is associated with the same or different MBS sessions. In other implementations, the DU assigns the same logical channel ID (value) to each logical channel associated with an MRB that is associated with different MBS sessions. In some implementations, the DU assigns a specific logical channel ID (value) to each logical channel associated with a DRB. In some implementations, the DU sets the logical channel IDs associated with the MRB and DRB to different values, respectively. In other implementations, the DU sets the logical channel IDs associated with the MRB and DRB to the same value, respectively.

[0057] Figures 5 and 6 are messaging diagrams of exemplary scenarios in which a CN and a distributed base station configure resources for transmitting MBS data for one or more MBS sessions to multiple UEs. Generally, similar events in Figures 5 and 6 are denoted with similar reference numbers (for example, event 501 in Figure 5 is similar to event 601 in Figure 6), and differences are described below where necessary. Except for the differences shown in the figures and described below, any of the alternative implementation forms described for a particular event (e.g., relating to messaging and processing) can be applied to events denoted with similar reference numbers in other figures, and can be applied to both integrated and distributed base stations.

[0058] Figure 5 shows an exemplary scenario 500 in which base station 104 is a distributed base station including CU172 and DU174 (where "DU174" refers to a single DU from DU174 in Figure 1B) and constitutes resources for transmitting MBS data for one or more MBS sessions via broadcast.

[0059] First, UE102 operates in a connected state (e.g., RRC_CONNECTED state) (501). Although Figures 5 and 6 illustrate only a single "UE102", it should be understood that this could be either UE102A, 102B, or both (each). In a connected state, UE102 can perform the (first) MBS session join procedure 502 with CN110 via base station 104 in order to join a particular MBS session (i.e., the first MBS session). Since base station 104 constitutes a common DL tunnel for MBS traffic rather than a UE-specific tunnel, as described below, procedures 502 and (described below) 590 can be performed in either order. In other words, base station 104 can constitute a common DL tunnel even before a single UE joins an MBS session.

[0060] In some implementations, UE102 can establish a PDU session by performing a PDU session establishment procedure with CN110 via base station 104 in order to perform the (first) MBS session participation procedure 502. During the PDU session establishment procedure, UE102 can communicate the PDU session ID of the PDU session with CN110 via base station 104.

[0061] To perform the MBS session join procedure 502, in some implementations, UE102 sends an MBS session join request message to CN110 via base station 104. In response, CN110 may send an MBS session join response message to UE102 via base station 104 to allow UE102 to access the first MBS session. In some implementations, UE102 may include the first MBS session ID (e.g., MBS session ID 1) and / or PDU session ID of the first MBS session in the MBS session join request message. In some cases, CN110 may include the first MBS session ID and / or PDU session ID in the MBS session join response message. In some implementations, UE102 may, in response to the MBS session join response message, send an MBS session join complete message to CN110 via base station 104.

[0062] In some implementations, the MBS session join request message, MBS session join response message, and MBS session join completion message may be IP packets, HTTP packets, or Session Initiation Protocol (SIP) messages. In such cases, these messages may not include the PDU session ID. In other implementations, the MBS session join request message, MBS session join response message, and MBS session join completion message may be NAS messages such as 5G Mobility Management (5GMM) messages or 5G Session Management (5GSM) messages. In the case of 5GSM messages, UE102 may send a (first) UL container message containing the MBS session join request message to CN110 via base station 104, CN110 may send a DL container message containing the MBS session join response message to UE102 (via base station 104), and UE102 may send a (second) UL container message containing the MBS session join completion message to CN110 via base station 104. These container messages may be 5GMM messages. In some implementations, the MBS session join request message, MBS session join response message, and MBS session join completion message may be the PDU Session Modification Request message, PDU Session Modification Command message, and PDU Session Modification Complete message, respectively. To simplify the following explanation, the MBS session join request message, MBS session join response message, and / or MBS session join completion message may represent their respective container messages.

[0063] Following the first MBS session join procedure 502, the connected UE 102 can communicate data with the CU 172 via one or more SRBs and / or one or more DRBs with the base station 104 and / or CN 110 (503). In some implementations, the UE 102 may have one or more state transitions between connected state, idle state (e.g., RRC_IDLE state), and / or inactive state (e.g., RRC_INACTIVE state) after performing the MBS session join procedure 502 and before performing data communication 503.

[0064] Prior to, during, or after the first MBS session join procedure (event 502), CN110 may send a (first) CN-BS message to CU172 (504) that includes the first MBS session ID (e.g., MBS session ID 1) and / or the PDU session ID, requesting CU172 to configure resources for the first MBS session. Additionally, CN110 may include a QoS configuration for the first MBS session in the first CN-BS message. In response to receiving the first CN-BS message (504), CU172 may send a CU-DU message to DU174 (506) to request the setup of the MBS context and / or a common DL tunnel for the first MBS session (i.e., a CU-DU common DL tunnel).

[0065] In response to receiving a CU-DU message (506), DU174 may send a DU-CU message to CU172 (508) containing a first DL transport layer configuration for configuring a common CU-DU DL tunnel for a first MBS session to an MRB identified by one of the MRB IDs. DU174 may include additional DL transport layer configurations in the DU-CU message for configuring additional common CU-DU DL tunnels to additional MRBs identified by additional MRB IDs among the MRB IDs. In some implementations, DU174 may include MRB IDs associated with the first DL transport layer configuration and / or additional DL transport layer configurations in the DU-CU message. In some implementations, the CU-DU message is a generic F1AP message or a dedicated F1AP message specifically defined to convey this type of request (e.g., an MBS context setup request message). In some implementations, the DU-CU message of event 508 is a generic F1AP message or a dedicated F1AP message specifically defined for this purpose (e.g., an MBS context setup response message). Additionally, CN110 may include a QoS configuration for the first MBS session. In such cases, CU172 may include the QoS configuration in the CU-DU message (event 506). In some implementations, the CU-DU message and the DU-CU message may be non-UE specific messages.

[0066] CU172 responds to the message of event 504 by sending a first BS-CN message (e.g., an MBS session resource setup response message) (510). CU172 may include a first MBS session ID and / or PDU session ID in the first BS-CN message. The first BS-CN message may include a DL transport layer configuration to establish a common DL tunnel for CN110 (i.e., a CN-BS common DL tunnel) for sending MBS data to CU172. The DL transport layer configuration includes transport layer information such as a transport layer address (e.g., an IP address) and / or TEID to identify the common DL tunnel. In some implementations, the CN-BS message of event 504 is a generic NGAP message or a dedicated NGAP message specifically defined to request resources for an MBS session (e.g., an MBS session resource setup request message). In some implementations, the BS-CN message for event 510 is a generic NGAP message or a dedicated NGAP message specifically defined to communicate resources for an MBS session (e.g., an MBS session resource setup response message). In such cases, the CN-BS message for event 504 and the BS-CN message for event 510 may be non-UE specific messages.

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

[0068] Events 504, 506, 508, and 510 are collectively referred to as the MBS resource setup procedure 590 in Figure 5A. When UE102 performs the MBS session join procedure 502 to join the first MBS session, CN110 may perform procedure 590 with base station 104 before, during, or after the (first) MBS session join procedure 502.

[0069] In some implementations, CN110 may refrain from including the UL transport layer configuration for the first MBS session in the first CN-BS message. In such cases, CU172 may refrain from including the UL transport layer configuration for the first MBS session in the CU-DU message.

[0070] Before, during, or after the MBS resource setup procedure 590, DU174 transmits (e.g., broadcasts) system information (e.g., one or more system information blocks (SIBs)) including the MBS control channel (MCCH) configuration on one or more cells (e.g., cell 124 and / or other cells operated by DU174) (512). DU174 also transmits (e.g., broadcasts) the MBS configuration via the MCCH configured by the MCCH configuration (i.e., according to the MCCH configuration) (514). UE102 may receive (512) the system information and / or the MBS configuration (514) before or after performing the data communication 503.

[0071] In some implementations, the MCCH configuration includes configuration parameters such as the window start slot, window duration, change period, and / or repetition period and offset. The window duration indicates the duration (i.e., an MCCH transmission window in units of (consecutive) slots) that begins from the slot indicated by the window start slot, during which transmissions of MCCH information (i.e., transmissions of MBS configurations via MCCH) can be scheduled. The change period defines periodically occurring boundaries, i.e., radio frames, during which the change period is equal to 0 for its SFN mod. The content of different transmissions of MCCH information can only differ if there is at least one such boundary between those transmissions. The repetition period and offset parameters define the length and offset of the MCCH repetition period. Transmissions of MCCH information are scheduled in radio frames during which the repetition period length offset of the repetition period is equal to the MCCH repetition period offset for its system frame number (SFN) mod.

[0072] In some implementations, the MBS configuration includes an MBS session information list, which includes a list of MBS session information IE (i.e., information relating to one or more MBS sessions, including a first MBS session). For example, the MBS session information IE in the list may include an MBS session ID, G-RNTI, MRB configuration, RLC configuration, and / or DRX information. If the MBS session ID identifies an MBS session, the G-RNTI is used to schedule the transmission of MBS data for the MBS session, the MRB configuration constitutes one or more MRBs, the RLC configuration constitutes the RLC parameters for the MRBs, and the DRX information constitutes the DRX-related parameters for the transmission of MBS data for the MBS session. Each of the MRB configurations can constitute an MRB. For example, the MRB configuration may include a PDCP configuration for the MRBs. In Scenario 500, the MBS session information IE in the list (i.e., the first MBS session information IE) includes the first MBS session ID, the MRB configuration comprising one or more MRBs for the first MBS session, the (first) G-RNTI used by DU174 to schedule the transmission of MBS data for the MRB or the first MBS session, the RLC configuration for the MRB, and / or DRX information comprising DRX-related parameters for the transmission of MBS data for the MRB or the first MBS session.

[0073] In some implementations, DU174 may initiate sending system information (512) in response to having performed the MBS resource setup procedure (590). In some implementations, CU172 generates the system information and sends it to DU174. In other implementations, DU174 generates the system information.

[0074] In some implementations, DU174 may initiate sending the MBS configuration (514) in response to having performed the MBS resource setup procedure (590). In some implementations, CU172 generates the MBS configuration and sends it to DU174. In other implementations, DU174 generates the MBS configuration, as described below. In yet another implementation, CU172 generates the (first) part of the MBS configuration and DU174 generates the (second) part (i.e., the remainder) of the MBS configuration. Details of these different implementations are described below.

[0075] In some implementations, CU172 can send a CU-DU message to DU174 containing configuration parameters for a first MBS session, such as the first MBS session ID, QoS configuration, DRX cycle configuration, MRB ID, and / or PDCP configuration of the MRB. In some implementations, DU174 can generate MBS session information IE according to the configuration parameters. In some implementations, DU174 can generate at least a portion of the MBS session information IE according to pre-configured values, for example. For example, DU174 can generate an MRB configuration including the PDCP configuration, MRB ID, and / or first MBS session ID received from CU172. Alternatively, DU174 can generate an MRB configuration including the PDCP configuration, MRB ID, and / or first MBS session ID using pre-configured values. In some implementations, DU174 does not need to include the MRB ID in the MRB configuration. For example, DU174 can generate an RLC configuration for an MRB (including, for example, the MRB ID) according to the QoS configuration and / or MRB ID. Alternatively, DU174 can generate an RLC configuration using pre-configured RLC parameters. DU174 can assign a logical channel ID for an MRB and include the logical channel ID in the MBS session information IE or RLC configuration. In another example, DU174 can generate DRX information that constitutes a DRX cycle according to a DRX cycle configuration received from CU172. Alternatively, DU174 can determine a DRX cycle according to a QoS configuration received from CU172. In yet another example, DU174 can assign a G-RNTI and associate the G-RNTI with a first MBS session ID. In such a case, DU174 can generate MBS session information and an MBS configuration (e.g., an MBS broadcast configuration message) containing the MBS session information and transmit the MBS configuration over one or more cells via MCCH (514).In some implementations, the CU-DU message may be a CU-DU message from MBS resource setup procedure 590, similar to event 506. In other implementations, the CU-DU message may be a (second) message other than the CU-DU message from MBS resource setup procedure 590.

[0076] In other implementations, DU174 can send a DU-CU message to CU172 containing the RLC bearer configuration, DRX information, and G-RNTI. In such implementations, CU172 generates an MRB configuration containing the PDCP configuration, MRB ID, and / or a first MBS session ID. After receiving the DU-CU message, CU172 generates MBS session information and an MBS configuration (e.g., an MBS broadcast configuration message) containing the MBS session information for one or more cells (each of them). CU172 then sends a CU-DU message to DU174 containing the MBS configuration. After receiving the MBS configuration from CU172, DU174 sends the MRB configuration via MCCH (513). In some implementations, CU172 can send a CU-DU message to DU174 to request that DU174 send a DU-CU message. In such cases, DU174 responds to the CU-DU message by sending a DU-CU message to CU172.

[0077] In some implementations, DU174 may send a DU-CU message to CU172 (508) after sending system information (512) and / or MBS configuration (514). In other implementations, DU174 may send a DU-CU message to CU172 (508) before sending system information (512) and / or MBS configuration (514).

[0078] After receiving a first BS-CN message (510), transmitting system information (512), and / or transmitting an MBS configuration (514), CN110 may send MBS data for a first MBS session (e.g., one or more MBS data packets) to CU172 via a common CN-BS DL tunnel (i.e., a first common CN-BS DL tunnel) (516), and CU172 sends the MBS data to DU174 via a common CU-DU DL tunnel (i.e., a first CU-DU common DL tunnel) according to the PDCP configuration (518). DU174 transmits (e.g., broadcasts) the MBS data via MRB (i.e., via a logical channel identified by a logical channel ID, and / or using an RLC configuration and / or G-RNTI) (520). UE102, operating in connection with base station 104, receives MBS data from DU174 via MRB (i.e., according to the first MBS session information IE) (520). For example, CU172 may receive an MBS data packet (516), generate a PDCP PDU containing the MBS data packet using the PDCP configuration, and transmit the PDCP PDU to DU174 via the first common CU-DU DL tunnel (518). DU174 then generates a MAC PDU containing the logical channel ID and the PDCP PDU, and transmits the MAC PDU to UE102 via broadcast using the first G-RNTI (520). UE102 receives the MAC PDU using the first G-RNTI (520), extracts the PDCP PDU and logical channel ID from the MAC PDU, identifies the PDCP PDU associated with the MRB, and extracts the MBS data packet from the PDCP PDU using the PDCP configuration.

[0079] Continuing to refer to Figure 5, CU172 may decide to release the connection with UE102 (i.e., the SRB and DRB) (522). In response to decision 522, CU172 generates an RRC release message for UE102 (e.g., an RRCRelease message) and sends a UE Context Release Command message containing the RRC release message to DU174 (524). DU174 then sends the RRC release message to UE102 (526). In response to the RRC release message, UE102 transitions to an idle or inactive state (530) and continues to receive MBS data via the MRB. Before or after sending the RRC release message (526), ​​DU174 may send a UE Context Release Complete message to CU172 in response to the UE Context Release Command message (528).

[0080] In some implementations, CU172 generates a PDCP PDU containing an RRC release message and sends a UE Context Release Command message containing the PDCP PDU to DU174 (524). DU174 extracts the PDCP PDU from the UE Context Release Command message and sends it to UE102 via RLC layer 206B, MAC layer 204B, and PHY layer 202B (526). UE102 receives the PDCP PDU from DU174 via PHY layer 202B, MAC layer 204B, and RLC layer 206B (526). For example, DU174 may generate an RLC PDU containing the PDCP PDU, generate a MAC PDU containing the RLC PDU and a logical channel ID associated with an SRB (e.g., SRB1), and send the MAC PDU to UE102 via PHY layer 202B (526). UE102 receives the MAC PDU via PHY layer 202B (526), ​​extracts the RLC PDU and logical channel ID, identifies the RLC PDU associated with the SRB according to the logical channel ID, extracts the PDCP PDU from the RLC PDU, extracts the RRC release message from the PDCP PDU, and processes the RRC release message.

[0081] After UE102 transitions to an idle or inactive state (530), CN110 sends MBS data for the first MBS session to CU172 via the first common CN-BS DL tunnel, similar to event 516 (534). Next, CU172 sends the MBS data to DU174 via the first common CU-DU DL tunnel, similar to event 518 (536). Then, DU174 transmits (e.g., broadcasts) the MBS data, similar to event 520 (538). UE102 receives the MBS data according to the first MBS session information 514, similar to event 520 (538).

[0082] Next, Figure 6 shows an exemplary scenario 600 in which base station 104, including CU172 and DU174, configures resources for transmitting MBS data for one or more MBS sessions via multicast or unicast.

[0083] UE102 (i.e., each of UE102A and / or UE102B) first performs the (second) MBS session join procedure 602 with CN110 via base station 104 in order to join a particular MBS session (i.e., the second MBS session identified by the second MBS session ID), similar to procedure 502.

[0084] Prior to, during, or after the (second) MBS session join procedure 602, CN110 may send a (first) CN-BS message containing the MBS session ID and / or PDU session ID to CU172 to request CU172 to configure resources for the MBS session (604). CN110 may, in addition, include a QoS configuration for the MBS session in the CN-BS message. In response, CU172 may decide to send a (first) BS-CN message containing a DL transport layer configuration for configuring a common DL tunnel for CN110 (i.e., a first common CN-BS DL tunnel) to send MBS data to CU172 (606). The DL transport layer configuration includes a transport layer address (e.g., an IP address) and / or TEID to identify the common DL tunnel. CU172 may include the MBS session ID and / or PDU session ID in the BS-CN message. If CU172 has configured a common DL tunnel for the MBS session before receiving a BS-CN message, CU172 decides not to send a BS-CN message. In other words, CU172 refrains from sending a BS-CN message.

[0085] In some implementations, the CN-BS message in event 604 may be a generic NGAP message or a dedicated NGAP message specifically defined to request resources for an MBS session (e.g., an MBS session resource setup request message). In some implementations, the BS-CN message in event 606 may be a generic NGAP message or a dedicated NGAP message specifically defined to communicate resources for an MBS session (e.g., an MBS session resource setup response message). In such cases, the CN-BS message in event 604 and the BS-CN message in event 606 may be non-UE specific messages.

[0086] In some implementations, CN110 may indicate a list of UEs participating in the MBS session in the CN-BS message of event 604. In other implementations, CN110 may send a second CN-BS message to CU172 (608) indicating a list of UEs participating in the MBS session. CN110 may include the MBS session ID and / or PDU session ID in the second CN-BS message. CU172 may send a second BS-CN message to CN110 in response to the second CN-BS message 608 (619). In such cases, the second CN-BS message and the second BS-CN message may be non-UE specific messages. For example, the list of UEs may include UE102A and / or UE102B. To indicate a list of UEs, CN110 may include a list of pairs (CN UE interface ID, RAN UE interface ID) each identifying a specific UE among the UEs. For example, the list of pairs includes a first pair identifying UE102A (first CN UE interface ID, first RAN UE interface ID) and a second pair identifying UE102B (second CN UE interface ID, second RAN UE interface ID). In some implementations, the "CN UE interface ID" can be an "AMF UE NGAP ID" and the "RAN UE interface ID" can be a "RAN UE NGAP ID". In other implementations, the CN110 may include a list of UE IDs, each identifying a specific UE in a set of UEs. In some implementations, the CN110 may assign UE IDs in a NAS procedure (e.g., a registration procedure) that the CN110 performs with a specific UE, and send each of the UE IDs to a specific UE among the UEs. For example, the list of UE IDs may include the first UE ID for UE102A and the second UE ID for UE102B. In some implementations, the UE ID is the S-Temporary Mobile Subscriber Identification Information (S-TMSI) (e.g., 5G-S-TMSI).

[0087] In some alternative implementations, CN110 may send another second CN-BS message to CU172 indicating that UE102 (for example, a single UE such as UE102A or UE102B) is joining the MBS session (608). CU172 may respond to the second CN-BS message 608 by sending another second BS-CN message to CN110 (619). In such a case, CN110 may include an MBS session join response message for UE102 in the second CN-BS message. CU172 may include a first CN UE interface ID and a first RAN UE interface ID identifying UE102 in the second CN-BS message. In some implementations, the second CN-BS message and the second BS-CN message may be UE-specific NGAP messages, such as a PDU Session Resource Modify Request message and a PDU Session Resource Modify Response message, respectively.

[0088] In other implementations, the first CN-BS message may be a UE-specific NGAP message (e.g., a PDU Session Resource Modify Request message) indicating that UE102 (e.g., a single UE such as UE102A or UE102B) is joining an MBS session. CN110 may include an MBS session join response message for UE102 in the first CN-BS message. CU172 may include a first CN UE interface ID and a first RAN UE interface ID identifying UE102 in the first CN-BS message. In some implementations, the first BS-CN message may be a generic NGAP message or a dedicated NGAP message specifically defined to communicate resources for an MBS session (e.g., an MBS Session Resource Setup Indication message or a RAN Configuration Update message). CN110 may, in response to the first BS-CN message, send another second CN-BS message (for example, an MBS Session Resource Setup Confirm message or a RAN Configuration Update Acknowledge message) to CU172 (608). CU172 may, in response to the first CN-BS message, send another second BS-CN message (for example, a PDU Session Resource Modify Response message) to CN110 (619).

[0089] In some implementations, CN110 may include the MBS session join response message for UE102 in a separate CN-BS message instead of the first CN-BS message or the second CN-BS message.

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

[0091] If CU172 establishes a common DL tunnel for the MBS session as described above, CU172 may refrain from including the DL transport layer configuration for the MBS session in the second BS-CN message. In such a case, CN110 may refrain from including the UL transport layer configuration for the MBS session in the first CN-BS message and / or the second CN-BS message.

[0092] In response to receiving a first CN-BS message (604), sending a first CN-BS message (606), or receiving a second CN-BS message (608), or thereafter, CU172 may send a CU-DU message to DU174 (610) to request the setup of the MBS context and / or a common DL tunnel for the MBS session. In response to receiving the CU-DU message (610), DU174 may send a DU-CU message to CU172 (612) containing a first DU DL transport layer configuration for setting up a common CU-DU DL tunnel for the MBS session (i.e., a first CU-DU common DL tunnel). In some implementations, the CU-DU message is a generic F1AP message or a dedicated F1AP message specifically defined to convey this type of request (e.g., an MBS context setup request message). In some implementations, the DU-CU message for event 612 is a generic F1AP message or a dedicated F1AP message specifically defined for this purpose (e.g., an MBS context setup response message). In such cases, CU172 can include the QoS configuration in the CU-DU message (event 610). In some implementations, the CU-DU message and the DU-CU message may be non-UE specific messages.

[0093] In response to or after receiving a first CN-BS message (604), sending a first CN-BS message (606), receiving a second CN-BS message (608), sending a CU-DU message (610), or receiving a DU-CU message (612), CU172 may send a UE context request message for UE102 to DU174 (614). In some implementations, CU172 may include the MBS session ID and / or the MRB ID of the MRB associated with the MBS session (ID) in the UE context request message. In response to the UE context request message, DU174 sends a UE context response message to CU172 (616) containing configuration parameters for UE102A to receive MBS data for the MBS session. In some implementations, CU172 may include the QoS configuration in the UE context request message. In such cases, CU172 may or may not include the QoS configuration in the CU-DU message. Some of the configuration parameters may be associated with an MRB / MRB ID. In some implementations, DU174 generates a DU configuration to include the configuration parameters and includes the DU configuration in the UE context response message. In some implementations, the DU configuration may be a CellGroupConfig IE. In other implementations, the DU configuration may be an MBS-specific IE. In some implementations, the configuration parameters constitute one or more logical channels (LCs). For example, the configuration parameters include one or more logical channel IDs (LCIDs) to constitute one or more logical channels. Each LCID identifies a specific logical channel among the one or more logical channels.

[0094] In some implementations, instead of DU174 sending a DU-CU message (612) in response to receiving a UE context request message (614) (in addition to sending a UE context response message (616)), DU174 sends a DU-CU message (612) in response to receiving a UE context request message (614) (in addition to sending a UE context response message (616)). CU172 can then send a CU-DU response message to DU174 in response to the DU-CU message. In such cases, the DU-CU message and CU-DU response message can be non-UE related messages, i.e., the messages are not associated with a particular UE.

[0095] In some implementations, CN110 includes the QoS configuration in the second CN-BS message. In such cases, CN110 may include the QoS configuration in the first CN-BS message or omit the QoS configuration altogether. In some implementations, DU174 generates configuration parameters for UE102 to receive MBS data for the MBS session in response to receiving a CU-DU message or a UE context request message. In some implementations, CU172 includes the QoS configuration in the UE context request message and / or the CU-DU message. DU174 can determine the content of the configuration parameters according to the QoS configuration. When CU172 does not include the QoS configuration in either the CU-DU message or the UE context request message, DU174 can determine the values ​​of the configuration parameters according to a given QoS configuration.

[0096] In some implementations, the UE context request message and UE context response message are the UE Context Setup Request message and UE Context Setup Response message, respectively. In other implementations, the UE context request message and UE context response message are the UE Context Modification Request message and UE Context Modification Response message, respectively.

[0097] After receiving the UE context response message (616), CU172 generates an RRC reconfiguration message containing configuration parameters and one or more MRB configurations and sends the RRC reconfiguration message to DU174 (618). DU174 then sends the RRC reconfiguration message to UE102 (620). In response, UE102 then sends an RRC reconfiguration complete message to DU174 (621), and DU174 sends the RRC reconfiguration complete message to CU172 (623).

[0098] In some implementations, CU172 generates a PDCP PDU containing an RRC reconfiguration message and sends a CU-DU message containing the PDCP PDU to DU174 (618). DU174 extracts the PDCP PDU from the CU-DU message and sends it to UE102 via RLC layer 206B, MAC layer 204B, and PHY layer 202B (620). UE102 receives the PDCP PDU from DU174 via PHY layer 202B, MAC layer 204B, and RLC layer 206B (620). In some implementations, UE102 generates a PDCP PDU containing an RRC reconfiguration complete message and sends it to DU174 via RLC layer 206B, MAC layer 204B, and PHY layer 202B (621). DU174 receives a PDCP PDU from UE102 via PHY layer 202B, MAC layer 204B, and RLC layer 206B (621), and sends a DU-CU message containing the PDCP PDU to CU172 (623). CU172 extracts the PDCP PDU from the DU-CU message and extracts an RRC reconstruction complete message from the PDCP PDU.

[0099] Before or after receiving the UE context response message (616), CU172 may send a second BS-CN message to CN110 in response to the second CN-BS message of event 612 (619). In some implementations, CU172 sends the second BS-CN message to CN110 (619) before receiving the RRC reconfiguration complete message (623). In other implementations, CU172 sends the second BS-CN message to CN110 (619) after receiving the RRC reconfiguration complete message (623). CU172 may include the first CN UE interface ID and the first RAN UE interface ID in the second BS-CN message. Alternatively, CU172 may include the first UE ID in the second BS-CN message.

[0100] Events 604, 606, 608, 612, 614, 616, 618, 619, 620, 622, and 623 are collectively referred to as the MBS resource setup and UE-specific MBS session configuration procedure 694 in Figure 6. In some implementations, each instance of event 604 or 608, 614, 616, 618, 619, 620, 622, and 623 occurs for UE102A and UE102B respectively. The configuration parameters for UE102A and UE102B to receive MBS data for the MBS session may be the same. In some implementations, the MBS session join procedure 602 includes the UE-specific MBS session resource setup procedure 694.

[0101] After receiving the first BS-CN message (606) or the second BS-CN message (619), CN110 may send MBS data (e.g., one or more MBS data packets) to CU172 via the first common CN-BS DL tunnel (634) (as in events 516 or 534), and CU172 may send the MBS data to DU174 via the first common CU-DU DL tunnel (636) (as in events 518 or 536). DU174 may send the MBS data to UE102 (i.e., UE102A and / or UE102B) via one or more logical channels (e.g., multicast or unicast) (638) (as in events 520 or 538). UE102 may receive the MBS data via one or more logical channels (638) (as in events 520 or 538). For example, CU172 may receive an MBS data packet (634), generate a PDCP PDU containing the MBS data packet using a PDCP configuration, and send the PDCP PDU to DU174 via a first common CU-DU DL tunnel (636). DU174 then generates a MAC PDU containing a logical channel ID and the PDCP PDU, and sends the MAC PDU to UE102 via multicast or unicast (638). UE102 receives the MAC PDU via multicast or unicast (638), extracts the PDCP PDU and logical channel ID from the MAC PDU, identifies the PDCP PDU associated with the MRB according to the logical channel ID, and extracts the MBS data packet from the PDCP PDU according to the PDCP configuration in the MRB configuration.

[0102] In some implementations, CU172 may, in response to receiving a first or second CN-BS message, decide to configure a UE-specific CN-BS DL tunnel for UE102. In such cases, CU172 may omit event 606 and include a DL transport layer configuration for configuring the UE-specific DL tunnel in the second BS-CN message. CN110 can then transmit MBS data to CU172 via the UE-specific CN-BS DL tunnel (634). In some implementations, CU172 may, in response to receiving a first or second CN-BS message, decide to configure a UE-specific CU-DU DL tunnel for UE102. In such cases, CU172 may omit event 610 and include a DL transport layer configuration for configuring the UE-specific CU-DU DL tunnel in the UE context response message. In such cases, CU172 can then transmit MBS data to DU174 via the UE-specific CU-DU DL tunnel (636).

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

[0104] In some implementations, CU172 can configure the MRB as a DL-only RB in an MRB configuration. For example, CU172 may refrain from including the UL configuration parameter in the PDCP configuration within the MRB configuration in order to configure the MRB as a DL-only RB. Instead, CU172 may include only the DL configuration parameter in the MRB configuration, as described above. In such a case, CU172 configures UE102 not to send UL PDCP data PDUs over the MRB to DU174 and / or CU172 by excluding the UL configuration parameter for the MRB in the PDCP configuration within the MRB configuration. In another example, DU174 refrains from including the UL configuration parameter in the RLC bearer configuration. In such a case, DU174 configures UE102 not to send control PDUs over the logical channel to DU174 by excluding the UL configuration parameter from the RLC bearer configuration.

[0105] If DU174 includes UL configuration parameters in the RLC bearer configuration, UE102 may use the UL configuration parameters to send a control PDU (e.g., a PDCP control PDU and / or an RLC control PDU) to DU174 via a logical channel. If the control PDU is a PDCP control PDU, DU174 can send the PDCP control PDU to CU172. For example, CU172 may configure the UE to receive MBS data using a compression (decompression) protocol (e.g., a Robust Header Compression (ROHC) protocol), for example in an MRB configuration. In this case, when CU172 receives an MBS data packet from CN110 (634), CU172 compresses the MBS data packet using the compression protocol to obtain the compressed MBS data packet and sends a PDCP PDU containing the compressed MBS data packet to DU174 via a common CU-DU DL tunnel (636). Next, DU174 sends the PDCP PDU to UE102 via a logical channel (e.g., multicast or unicast) (638). When UE102 receives the PDCP PDU via the logical channel (638), UE102 extracts the compressed MBS data packet from the PDCP PDU. UE102 decompresses the compressed MBS data packet using a compression (decompression) protocol to obtain the original MBS data packet. In such a case, UE102 may send a PDCP control PDU to DU174 via the logical channel, containing header compression protocol feedback (e.g., scattered ROHC feedback) about the operation of the header compression (decompression) protocol. DU174 then sends the PDCP control PDU to CU172 via a UE-specific UL tunnel, i.e., the UL tunnel is specific to UE102 (e.g., UE102A). In some implementations, CU172 may include a CU UL transport layer configuration in the UE context request message that constitutes the UE-specific UL tunnel. The CU UL transport layer configuration includes a CU transport layer address (e.g., an Internet Protocol (IP) address) and a CU UL TEID to identify the UE-specific UL tunnel.

[0106] In some implementations, the MRB configuration may be 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 MRBs. CU172 sets the MRB ID to a different value. If CU172 configures a DRB for UE102 for unicast data communication, CU172 may, in some implementations, set the MRB ID to a different value from the DRB's DRB ID. In such cases, UE102 and CU172 can distinguish whether an RB is an MRB or a DRB according to the RB's RB ID. In other implementations, CU172 may set one or more of the MRB IDs to a value that may be the same as one or more of the DRB IDs. In such cases, UE102 and CU172 can distinguish whether an RB is an MRB or a DRB according to the RB's RB ID and the RRC IE that constitutes the RB. For example, a DRB configuration that constitutes a DRB is a DRB-ToAddMod IE that includes DRB identification information (e.g., drb-Identity or DRB-Identity) and a PDCP configuration. Therefore, UE102 can determine that an RB is a DRB if it receives a DRB-ToAddMod IE that constitutes an RB, and can determine that an RB is an MRB if it receives an MRB-ToAddMod IE that constitutes an RB. Similarly, CU172 can determine that an RB is a DRB if it sends a DRB-ToAddMod IE that constitutes an RB to UE102, and can determine that an RB is an MRB if it sends an MRB-ToAddMod IE that constitutes an RB to UE102.

[0107] In some implementations, the configuration parameters for receiving MBS data in an MBS session include one or more logical channel (LC) IDs for configuring one or more logical channels. In some implementations, the logical channels may be DTCHs. In other implementations, the logical channels may be MTCHs. In some implementations, the configuration parameters may or may not include a Group Radio Network Temporary Identifier (G-RNTI). The RRC reconfiguration message for UEs participating in an MBS session (e.g., UE102A and UE102B) includes the same configuration parameters as those for receiving MBS data in an MBS session. In some implementations, the RRC reconfiguration message for UEs may include the same or different configuration parameters as those for receiving non-MBS data.

[0108] In some implementations, CU172 can include the MBS session join response message in the RRC reconfiguration message. UE102 can include the MBS session join completion message in the RRC reconfiguration completion message. Alternatively, UE102 can send a UL RRC message containing the MBS session join completion message to CU172 via DU174. The UL RRC message can be any suitable RRC message that can include a ULInformationTransfer message or a UL NAS PDU. CU172 can include the MBS session join completion message in a second BS-CN message. Alternatively, CU172 can send a BS-CN message (e.g., an UPLINK NAS TRANSPORT message) containing the MBS session join completion message to CN110.

[0109] In other implementations, CU172 sends a DL RRC message containing an MBS session join response message to UE102 via DU174. The DL RRC message can be any suitable RRC message that may include a DLInformationTransfer message, another RRC reconfiguration message, or a DL NAS PDU. UE102 can send a UL RRC message containing an MBS session join completion message to CU172 via DU174. The UL RRC message can be any suitable RRC message that may include a ULInformationTransfer message, another RRC reconfiguration completion message, or a UL NAS PDU.

[0110] Continuing to refer to Figure 6, CU172 may decide to release the connection with UE102 (i.e., the SRB and DRB) (622). In response to decision 622, CU172 generates an RRC release message for UE102 (e.g., an RRCRelease message) and sends a UE Context Release Command message containing the RRC release message to DU174 (624). DU174 then sends the RRC release message to UE102 (626). In response to the RRC release message, UE102 transitions to an idle or inactive state (630) and stops receiving MBS data via the MRB (633) (or suspends). Before or after sending the RRC release message (626), DU174 may send a UE Context Release Complete message to CU172 in response to the UE Context Release Command message (628).

[0111] In some implementations, CU172 generates a PDCP PDU containing an RRC release message and sends a UE Context Release Command message containing the PDCP PDU to DU174 (624). DU174 extracts the PDCP PDU from the UE Context Release Command message and sends it to UE102 via RLC layer 206B, MAC layer 204B, and PHY layer 202B (626). UE102 receives the PDCP PDU from DU174 via PHY layer 202B, MAC layer 204B, and RLC layer 206B (626). For example, DU174 may generate an RLC PDU containing the PDCP PDU and a MAC PDU containing the RLC PDU and a logical channel ID associated with an SRB (e.g., SRB1), and send the MAC PDU to UE102 via PHY layer 202B (626). UE102 receives the MAC PDU via PHY layer 202B (626), extracts the RLC PDU and logical channel ID, identifies the RLC PDU associated with the SRB according to the logical channel ID, extracts the PDCP PDU from the RLC PDU, extracts the RRC release message from the PDCP PDU, and processes the RRC release message.

[0112] After UE102 transitions to an idle or inactive state (630), CN110 can send MBS data for the MBS session to CU172 via the first common CN-BS DL tunnel, similar to event 516. CU172 then sends the MBS data to DU174 via the first common CU-DU DL tunnel, similar to event 518. DU174 then transmits (e.g., broadcasts) the MBS data, similar to event 520. However, since UE102 has stopped receiving MBS data when it transitions to an idle or inactive state (630), UE102 operating in an idle or inactive state does not receive MBS data.

[0113] Next, several exemplary methods that may be implemented in a UE (e.g., UE102A), RAN (e.g., RAN105), or base station (e.g., base station 104) are described with reference to Figures 7A to 12B. Each of these methods may be implemented using processing hardware such as one or more processors for executing instructions stored on a non-temporary computer-readable medium such as computer memory.

[0114] Referring first to Figure 7A, Method 700A may be implemented in a preferred UE (implemented by a preferred UE). For clarity, Method 700A will be described with specific reference to RAN105 and UE102 (i.e., UE102A or 102B).

[0115] In block 702, UE102 receives MBS data from RAN105 using the MBS configuration parameter while UE102 is operating in a connected state (e.g., event 520 in Figure 5 or event 638 in Figure 6). In some implementations, the MBS configuration parameter includes at least one of the following: MRB configuration, RLC configuration associated with the MRB configuration, G-RNTI, MBS BWP configuration, and / or MBS common frequency range configuration. In block 704, UE102 receives an RRC release message from RAN105 while UE102 is operating in a connected state (e.g., event 526 in Figure 5 or event 626 in Figure 6). In block 706, UE102 transitions to an idle state in response to the RRC release message. Then, in block 708, UE102 determines whether the MBS configuration parameter is used to receive (or was used to receive) a broadcast MBS session or not used to receive (or was not used to receive) a broadcast MBS session. If the MBS configuration parameter is not used or was not used to receive a broadcast MBS session (i.e., the MBS configuration parameter is used or was used to receive a unicast or multicast MBS session), the flow proceeds to block 714 where UE102 releases the MBS configuration parameter (e.g., event 633 in Figure 6). However, if the MBS configuration parameter is used or was used to receive a broadcast MBS session, the flow proceeds to block 710. In block 710, UE102 holds the MBS configuration parameter. In block 712, UE102 continues to receive MBS data using the MBS configuration parameter while operating in the idle state (e.g., event 532 in Figure 5). Blocks 706, 708, 710, 712, and 714 are collectively referred to as the idle state transition procedure 750 in Figure 7A.

[0116] Referring now to Figure 7B, Method 700B is almost identical to Method 700A, except that UE102 transitions to an inactive state in response to the RRC release message. The differences between the method in Figure 7A and the method in Figure 7B will be explained in more detail below.

[0117] In block 707, UE102 transitions to an inactive state rather than the idle state of block 706 in response to the RRC release message. In block 710, UE102 holds the MBS configuration parameter while operating in the inactive state (i.e., after transitioning to the inactive state). Then, in block 708, UE102 determines whether the MBS configuration parameter is used to receive broadcast MBS sessions or not used to receive broadcast MBS sessions. If the MBS configuration parameter is not used to receive broadcast MBS sessions (i.e., the MBS configuration parameter is used to receive unicast or multicast MBS sessions), the flow proceeds to block 715 where UE102 discontinues using the MBS configuration parameter (e.g., event 633 in Figure 6). However, if the MBS configuration parameter is used to receive broadcast MBS sessions, the flow proceeds to block 713. In block 713, UE102 continues to receive MBS data using MBS configuration parameters while operating in an inactive state (for example, event 532 in Figure 5). Blocks 707, 710, 708, 713, and 715 are collectively referred to as the inactive state transition procedure 751 in Figure 7A.

[0118] Next, referring to Figure 8, Method 800 may be implemented (carried out by) a preferred UE. For clarity, Method 800 will be described with reference to RAN 105 and UE 102 (i.e., UE 102A or 102B).

[0119] In block 802, UE102 receives MBS data from RAN105 using MBS configuration parameters while UE102 is operating in the connected state (e.g., event 520 in Figure 5 or event 638 in Figure 6). In block 804, UE102 receives an RRC release message from RAN105 while operating in the connected state (e.g., event 526 in Figure 5 or event 626 in Figure 6). Then, in block 806, UE102 decides whether the RRC release message indicates a transition to the inactive state or not. If the RRC release message indicates a transition to the inactive state, the flow proceeds to block 808 where UE102 performs the inactive state transition procedure 751. If the RRC release message does not indicate a transition to the inactive state (i.e., it transitions to the idle state), the flow proceeds to block 810 where UE performs the idle state transition procedure 750.

[0120] Next, referring to Figure 9A, Method 900A may be implemented in a preferred UE (performed by a preferred UE). For clarity, Method 900A will be described with specific reference to RAN105 and UE102.

[0121] In block 902, UE102 receives MBS data from RAN105 via the first MRB and the second MRB while UE102 is operating in the connected state (e.g., event 520 in Figure 5 or event 638 in Figure 6). In block 904, UE102 receives an RRC release message from RAN105 while UE102 is operating in the connected state (e.g., event 526 in Figure 5 or event 626 in Figure 6). In block 906, UE102 transitions to the idle state in response to the RRC release message. Then, in block 908, UE102 releases the first MRB in response to transitioning to the idle state (e.g., event 633 in Figure 6). In block 910, UE102 holds the second MRB in response to transitioning to the idle state. In block 912, UE102 continues to receive MBS data via the second MRB while operating in an idle state (for example, event 532 in Figure 5).

[0122] Next, referring to Figure 9B, Method 900B is almost identical to Method 900A, except that UE102 transitions to an inactive state in response to the RRC release message. The differences between the method in Figure 9A and the method in Figure 9B will be explained in more detail below.

[0123] While UE102 is operating in the connected state, after UE102 receives an RRC release message from RAN105, the flow continues to block 907. In block 907, UE102 transitions to an inactive state (rather than the idle state in method 900A) in response to the RRC release message. Then, in block 909, UE102 interrupts the first MRB in response to transitioning to the inactive state (e.g., event 633 in Figure 6). In block 911, UE102 retains the second MRB in response to transitioning to the inactive state. In block 913, UE102 continues to receive MBS data using the MBS configuration parameters while operating in the idle state (e.g., event 532 in Figure 5).

[0124] Next, referring to Figure 10A, Method 1000A may be implemented (carried out by) a suitable UE. For clarity, Method 1000A will be described with reference to RAN 105 and UE 102 (i.e., UE 102A or 102B).

[0125] In block 1002, UE102 holds the unicast configuration parameter while operating in an inactive state. In block 1004, UE102 receives MBS data from RAN105 using the MBS configuration parameter while UE102 is operating in an inactive state. In block 1006, UE102 transitions from an inactive state to an idle state. Then, in block 1008, UE102 releases the unicast configuration parameter in response to the transition to the idle state. In block 1010, UE102 holds the MBS configuration parameter in response to the transition to the idle state. In block 1012, UE102 continues to receive MBS data from RAN105 using the MBS configuration parameter while UE102 is operating in an idle state.

[0126] Referring now to Figure 10B, Method 1000B is almost identical to Method 1000A, except that the MBS configuration parameters may be released in response to UE102 transitioning to an idle state. The differences between the method in Figure 10A and the method in Figure 10B will be explained in more detail below.

[0127] After UE102 releases the unicast configuration parameter in response to transitioning to an idle state (in block 1008), the flow proceeds to block 1009. In block 1009, UE102 determines whether the MBS configuration parameter is used to receive broadcast MBS sessions or not used to receive broadcast MBS sessions. If the MBS configuration parameter is used to receive broadcast MBS sessions, the flow proceeds to block 1010, where UE102 holds the MBS configuration parameter in response to transitioning to an idle state. In block 1012, UE102 continues to receive MBS data from RAN105 using the MBS configuration parameter while UE102 is operating in an idle state. If the MBS configuration parameter is not used to receive broadcast MBS sessions (i.e., the MBS configuration parameter is used to receive unicast or multicast MBS sessions), the flow proceeds to block 1014. In block 1014, UE102 releases the MBS configuration parameters in response to transitioning to an idle state.

[0128] Referring next to Figure 11A, Method 1100A may be implemented (implemented by) a base station of a preferred RAN. For clarity, Method 1100A will be described with reference to base station 104, RAN 105, and UE 102 (i.e., UE 102A or 102B).

[0129] In block 1102, RAN105 configures the MRB for UE102 (e.g., event 620 in Figure 6). In block 1104, RAN105 sends MBS data to UE102 via the MRB (e.g., event 638 in Figure 6). In block 1106, RAN105 decides to release the MRB for UE102. Then, in block 1108, RAN105 decides whether UE102 is configured with a DRB or not. If UE102 is configured with a DRB, the flow proceeds to block 1110, in which RAN105, in response to the decision, causes UE102 to release the MRB by sending an RRC reconfiguration message to UE102. If UE102 is not configured with a DRB, the flow proceeds to block 1112. In block 1112, in response to the decision, RAN 105 does not cause UE 102 to release the MRB, but instead sends an RRC release message to UE 102 (for example, event 626 in Figure 6).

[0130] Referring now to Figure 11B, Method 1100B is almost identical to Method 1100A, except that RAN105 sends an RRC reconfiguration message to UE102 to release the MRB regardless of the DRB configuration. The differences between the method in Figure 11A and the method in Figure 11B will be explained in more detail below.

[0131] After deciding to release the MRB for UE102 in block 1106, the flow proceeds to block 1110. In block 1110, in response to the decision, RAN105 causes UE102 to release the MRB by sending an RRC reconfiguration message to UE102, regardless of whether UE102 is configured with a DRB. Then, in block 1108, RAN105 decides whether UE102 is configured with a DRB or not. If UE102 is configured with a DRB, the flow proceeds to block 1114, where the procedure ends. However, if UE102 is not configured with a DRB, the flow proceeds to block 1112. In block 1112, in response to the decision, RAN105 sends an RRC release message to the UE (for example, event 626 in Figure 6).

[0132] Next, referring to Figure 12A, Method 1200A may be implemented in a suitable CU of a base station (implemented by a suitable CU of a base station). For clarity, Method 1200A will be described with reference to base station 104, CU 172, DU 174, RAN 105, and UE 102 (i.e., UE 102A or 102B).

[0133] In block 1202, CU172 configures an MRB with DU174 for UE102 (e.g., event 618 or event 620 in Figure 6). In block 1204, CU172 sends MBS data to UE102 via the MRB and DU174 (e.g., event 636 or event 638 in Figure 6). In block 1206, CU172 decides to release the MRB for UE102. Then, in block 1208, CU172 decides whether UE102 is configured with a DRB or not. If UE102 is configured with a DRB, the flow continues to block 1210, in response to the decision, by causing DU174 to release the configuration parameters associated with the MRB for UE102 by sending a first CU-DU inter-message to DU174. In some implementations, the flow continues from block 1210 to block 1212. In block 1212, CU172 receives a first DU-CU message from DU174 in response to a first CU-DU message. In some implementations, the first CU-DU message and the first DU-CU message are a UE context change request message and a UE context change response message, respectively. In other implementations, the first CU-DU message and the first DU-CU message are a UE context setup request message and a UE context setup response message, respectively.

[0134] If UE102 is not configured with DRB, the flow proceeds to block 1214. In block 1214, in response to the decision, CU172 causes DU174 to release the UE context of UE102 by sending a second CU-DU message to DU174 (e.g., event 624 in Figure 6). In some implementations, the flow continues from block 1214 to block 1216. In block 1216, CU172 receives a second DU-CU message from DU174 in response to the second CU-DU message (e.g., event 624 in Figure 6). In some implementations, the second CU-DU message and the second DU-CU message are the UE context release command message and the UE context release complete message, respectively.

[0135] Referring now to Figure 12B, Method 1200B is almost identical to Method 1200A, except that CU172 sends a first CU-DU message to DU174 to release the MRB regardless of the DRB configuration. The differences between the method in Figure 12A and the method in Figure 12B will be explained in more detail below.

[0136] After deciding to release the MRB for UE102 in block 1206, the flow proceeds to block 1210. In block 1210, in response to the decision, CU172 causes DU174 to release the configuration parameters associated with the MRB for UE102 by sending a first CU-DU message to DU174, regardless of whether UE102 is configured with a DRB. Then, in block 1208, CU172 decides whether UE102 is configured with a DRB or not. If UE102 is configured with a DRB, the flow proceeds to block 1213, where the procedure ends. If UE102 is not configured with a DRB, the flow proceeds to block 1214. In block 1214, in response to the decision, CU172 causes DU174 to release the UE context for UE102 by sending a second CU-DU message to DU174 (e.g., event 624 in Figure 6). In some implementations, the flow proceeds from block 1214 to block 1216. In block 1216, CU172 receives a second DU-CU message from DU174 in response to the second CU-DU message (for example, event 624 in Figure 6).

[0137] The following list of examples reflects the various implementations explicitly intended by this disclosure.

[0138] Example 1. A method for managing multicast and / or broadcast service (MBS) communications after a state transition, performed by a user device (UE), the method comprising: receiving MBS data from a radio access network (RAN) using MBS configuration parameters while the UE is in a connected state with the RAN; transitioning from the connected state to an idle or inactive state; and, while the UE is in an idle or inactive state, continuing to receive or ceasing to receive MBS data using MBS configuration parameters, based on whether the MBS configuration parameters are for receiving a broadcast MBS session or a non-broadcast MBS session, respectively.

[0139] Example 2. The method of Example 1, wherein the transition step includes a step of transitioning from a connected state to an idle state.

[0140] Example 3. The method of Example 2, wherein the method includes the steps of: holding the MBS configuration parameter and continuing to receive MBS data using the MBS configuration parameter when the MBS configuration parameter is for receiving a broadcast MBS session; and releasing the MBS configuration parameter when the MBS configuration parameter is for receiving a non-broadcast MBS session.

[0141] Example 4. The method of Example 1, wherein the transition step includes a step of transitioning from a connected state to an inactive state.

[0142] Example 5. The method of Example 4, wherein the method includes the steps of: retaining the MBS configuration parameter and continuing to receive MBS data using the MBS configuration parameter when the MBS configuration parameter is for receiving a broadcast MBS session; and retaining the MBS configuration parameter and discontinuing the use of the MBS configuration parameter when the MBS configuration parameter is for receiving a non-broadcast MBS session.

[0143] Example 6. The method of Example 1, further comprising the step of receiving a radio resource control (RRC) release message from a RAN, wherein the step to which the transition occurs is in response to the RRC release message.

[0144] Example 7. The method of Example 6, wherein when an RRC release message indicates a transition to an idle state, (i) the transition step includes a step of transitioning to an idle state, and (ii) the method includes a step of holding or releasing an MBS configuration parameter, based on whether the MBS configuration parameter is for receiving a broadcast MBS session or a non-broadcast MBS session, respectively.

[0145] Example 8. The method of Example 6, wherein when an RRC release message indicates a transition to an inactive state, (i) the transition step includes a step of transitioning to an inactive state, and (ii) the method includes a step of retaining an MBS configuration parameter and continuing to use or not using the MBS configuration parameter to receive MBS data, based on whether the MBS configuration parameter is for receiving a broadcast MBS session or a non-broadcast MBS session, respectively.

[0146] Example 9. Any one of Examples 1 through 8, including a step of not continuing to receive MBS data using the MBS configuration parameter when the MBS configuration parameter is for receiving a multicast MBS session.

[0147] Example 10. Any one of Examples 1 through 8, including a step of not continuing to receive MBS data using the MBS configuration parameter when the MBS configuration parameter is for receiving a unicast MBS session.

[0148] Example 11. A method for managing multicast and / or broadcast service (MBS) communications after a state transition, performed by a user device (UE), comprising: receiving MBS data from a radio access network (RAN) via a first MBS radio bearer (MRB) and / or a second MRB while the UE is connected to the RAN; receiving an RRC release message from the RAN while the UE is connected; and in response to the RRC release message, (i) transitioning from a connected state to an idle or inactive state; (ii) releasing or suspending the first MRB; and receiving further MBS data from the RAN via a second MRB while the UE is in an idle or inactive RRC state.

[0149] Example 12. The method of Example 11, which in response to an RRC release message, includes the steps of (i) transitioning from a connected state to an idle state, and (ii) releasing a first MRB, wherein further MBS data is received via a second MRB, while the UE is in an idle state.

[0150] Example 13. The method of Example 11, which in response to an RRC release message, includes the steps of (i) transitioning from a connected state to an inactive state, and (ii) interrupting a first MRB, wherein the UE is in an inactive state, the UE is in an inactive state, and

[0151] Example 14. A method for managing multicast and / or broadcast service (MBS) communications after a state transition, performed by a user device (UE), comprising: receiving MBS data from a radio access network (RAN) using the MBS configuration parameter while the UE is in an inactive state and holding the unicast configuration parameter; transitioning from an inactive state to an idle state; releasing the unicast configuration parameter in response to the transition step; and receiving further MBS data from the RAN using the MBS configuration parameter while the UE is idle.

[0152] Example 15. The method of Example 14, including the step of receiving additional MBS data using MBS configuration parameters, when the MBS configuration parameters are for receiving a broadcast MBS session rather than a non-broadcast MBS session.

[0153] Example 16. The method of Example 15, including the step of using MBS configuration parameters to receive additional MBS data, when the MBS configuration parameters are for receiving a broadcast MBS session rather than a multicast or unicast MBS session.

[0154] Example 17. User equipment (UE) configured to implement one of the methods from Examples 1 through 16.

[0155] Example 18. A method for managing multicast and / or broadcast service (MBS) communications performed by a radio access network (RAN) node, comprising the steps of: transmitting MBS data to a user device (UE) via an MBS radio bearer (MRB); deciding to release the MRB for the UE; and, after the deciding step, not sending or sending a radio resource control (RRC) release message to the UE, depending on whether the UE is configured with a data radio bearer (DRB), respectively.

[0156] Example 19. The method of Example 18, which includes the step of causing the UE to release the MRB by sending an RRC reconfiguration message to the UE when the UE is configured with a DRB, and the step of causing the UE to release the MRB by sending an RRC release message to the UE when the UE is not configured with a DRB.

[0157] Example 20. The method of Example 18, further including the step of causing the UE to release the MRB by sending an RRC reconfiguration message to the UE, regardless of whether the UE is configured with a DRB.

[0158] Example 21. One of the methods from Examples 18 through 20, where the RAN node is a RAN base station.

[0159] Example 22. A radio access network (RAN) node configured to implement one of the methods from Examples 18 through 21.

[0160] Example 23. A method for managing multicast and / or broadcast service (MBS) communications performed by a base station central unit (CU), comprising the steps of: transmitting MBS data to a user device (UE) via a base station distributed unit (DU) and an MBS radio bearer (MRB); deciding to release the MRB for the UE; and, after the deciding step, not sending or sending a first CU-DU message to the DU indicating that the DU should release the UE context for the UE, based on whether the UE is configured with a data radio bearer (DRB), respectively.

[0161] Example 24. The method of Example 23, which includes the steps of: when the UE is configured with a DRB, sending a second CU-DU message to the DU to cause the DU to release the configuration parameters associated with the MRB; and when the UE is not configured with a DRB, sending a first CU-DU message to the DU to cause the DU to release the UE context of the UE.

[0162] Example 25. The method of Example 24, further comprising the steps of: when the UE is not configured with DRB, having the DU release the UE context of the UE and then receiving a first DU-CU message from the DU; and when the UE is configured with DRB, having the DU release the configuration parameters and then receiving a second DU-CU message from the DU.

[0163] Example 26. The method of Example 25, wherein the first CU-DU message is a UE context release command request message, the first DU-CU message is a UE context release completion message, the second CU-DU message is a UE context change request message, and the second DU-CU message is a UE context change response message.

[0164] Example 27. The method of Example 25, wherein the first CU-DU message is a UE context release command request message, the first DU-CU message is a UE context release completion message, the second CU-DU message is a UE context setup request message, and the second DU-CU message is a UE context setup response message.

[0165] Example 28. The method of Example 23, which includes the steps of sending a second CU-DU message to the DU to cause the DU to release the configuration parameters associated with the MRB, regardless of whether the UE is configured with a DRB, and sending a first CU-DU message to the DU to cause the DU to release the UE context of the UE, when the UE is not configured with a DRB.

[0166] Example 29. The method of Example 28, further including the step of receiving a first DU-CU message from the DU after causing the DU to release the UE context of the UE when the UE is not configured with DRB.

[0167] Example 30. The method of Example 29, wherein the first CU-DU message is a UE context release command message, and the first DU-CU message is a UE context release completion message.

[0168] Example 31. One of the methods from Examples 23 to 30, further including the step of configuring the MRB with the DU for the UE before sending the MBS data.

[0169] Example 32. A central unit (CU) of a base station, configured to implement one of the methods in Examples 23 to 31.

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

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

[0172] User devices (e.g., UE102A or 102B) on which the techniques of this disclosure may be implemented may be any suitable wirelessly communicating device, 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. Furthermore, in some cases, the user device may be embedded in an electronic system such as a vehicle or an advanced driver-assistance system (ADAS) head unit. Moreover, the user device may operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0173] Certain embodiments described in this disclosure include logic or several components or modules. A module may be a software module (e.g., code stored on a non-temporary machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing a particular operation and may be configured or arranged in a particular manner. A hardware module may comprise a dedicated circuit configuration or logic permanently configured to perform a particular operation (e.g., as a dedicated processor such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC)). A hardware module may also comprise a programmable logic or circuit configuration temporarily configured by software to perform a particular operation (e.g., contained within a general-purpose processor or other programmable processor). The decision to implement a hardware module in a dedicated, permanently configured circuit configuration or in a temporarily configured circuit configuration (e.g., configured by software) may be driven by cost and time considerations.

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

[0175] 100 Wireless Communication Systems 102, 102A, 102B UE 103 UE 104 Base station, MeNB, Mng-eNB, MgNB 105 RAN 106 Base station, SgNB, Sng-eNB 110 CN 111 Advanced Packet Core (EPC), EPC 112 Serving Gateway (SGW), SGW 114 Mobility Management Entity (MME), MME 116 Packet Data Network Gateway (PGW), PGW 124 cells 126 cells 130 Processing Hardware 132 MBS controller, controller 134 Non-MBS controller, controller 140 Processing Hardware 142 MBS controller 144 Non-MBS controllers 150 Processing Hardware 152 MBS controller 154 Non-MBS controllers 160 5th generation Core (5GC), 5GC 162 User Plane Function (UPF), UPF 164 Access and Mobility Management (AMF), AMF 166 Session Management Function (SMF), SMF 172 CU 172A CU-CP 172B CU-UP 174 DU 200 protocol stacks 202 PHY sublayer 202A PHY sublayer 202B NR PHY, PHY layer 204 MAC sublayer 204A EUTRA MAC Sublayer 204B NR MAC sublayer, NR MAC, MAC layer 206 RLC sublayer 206A EUTRA RLC sublayer, EUTRA RLC, RLC layer 206B NR RLC sublayer, NR RLC, RLC layer 208 EUTRA PDCP sublayer, PDCP sublayer, PDCP layer 210 NR PDCP sublayer, NR PDCP, PDCP layer 212 SDAP sublayer, SDAP 214 RRC 250 protocol stacks 300 Tunnel Architectures 302A, 302B MBS sessions 304A PDU Session 312A, 312B Tunnel 314A-1, 314A-2, 314A-N Wireless Bearer 314A MRB 314B, 314B-1, 314B-2, 314B-N MRB Set of 316 flows 316A, 316B, 316L QoS Flow 322A UE-specific DL tunnels and / or UE-specific UL tunnels 324A-1, 324A-2, 324A-N DRB 402, 402A, 402B MRB 404, 404A, 404B DRB 412A DL Tunnel, Tunnel 412B DL ​​Tunnel 413A UL Tunnel, Tunnel 413B UL Tunnel 422A, 422B DL ​​Logical Channels 423A, 423B UL Logical Channels 432A UE specific DL tunnel, DL tunnel 432B UE-specific DL tunnel 433A UE specific UL tunnel, UL tunnel 433B UE-specific UL tunnel 442A, 442B DL ​​Logical Channels 443A, 443B UL Logical Channels 500 Scenarios 501 Event 502 (First) MBS Session Participation Procedure, Procedure, MBS Session Participation Procedure, First MBS Session Participation Procedure 503 Data Communication 504 Event 506 Events 508 Events 510 Events 514 Information for the first MBS session 516 Events 518 Events 520 events 526 Events 532 Events 534 Events 536 Events 538 Events 590 Steps, MBS Resource Setup Procedure 600 Scenarios 601 Event 602 (Second) MBS Session Participation Procedure, MBS Session Participation Procedure 604 Event 606 Events 608 Second CN-BS inter-message, event 610 Events 612 Events 614 Events 616 Events 618 Events 619 Events 620 events 622 Events 623 Events 624 Events 626 Events 633 Events 636 Events 638 Events 694 MBS Resource Setup and UE-Specific MBS Session Configuration Procedures, UE-Specific MBS Session Resource Setup Procedures 700A, 700B method 750 Idle State Transition Procedure 751 Inactive State Transition Procedure 800 ways 900A, 900B method 1000A, 1000B method 1100A, 1100B method 1200A, 1200B method

Claims

1. A method for managing multicast and / or broadcast service (MBS) communications after state transitions, performed by user equipment (UE), The steps include: receiving MBS data from a wireless access network (RAN) using MBS configuration parameters while the UE is connected to the RAN; The step of transitioning from the aforementioned connected state to an idle state, While the UE is in the idle state, the UE may take steps to continue receiving or not receive MBS data using the MBS configuration parameter, based on whether the MBS configuration parameter is for (i) receiving broadcast MBS sessions or (ii) receiving unicast or multicast MBS sessions. Includes, The method described above is When the MBS configuration parameter is for receiving a broadcast MBS session, the steps include: retaining the MBS configuration parameter and continuing to receive MBS data using the MBS configuration parameter; When the MBS configuration parameter is for receiving a unicast or multicast MBS session, the steps include releasing the MBS configuration parameter and Methods that include...

2. When the aforementioned MBS configuration parameter is for receiving a multicast MBS session, the step of not continuing to receive MBS data using the aforementioned MBS configuration parameter. The method according to claim 1, including the method described in claim 1.

3. When the MBS configuration parameter is for receiving a unicast MBS session, the step of not continuing to receive MBS data using the MBS configuration parameter. The method according to claim 1, including the method described in claim 1.

4. A method for managing multicast and / or broadcast service (MBS) communications after state transitions, performed by user equipment (UE), The steps include: receiving MBS data from a wireless access network (RAN) using MBS configuration parameters while the UE is connected to the RAN; The step of transitioning from the connected state to an inactive state, While the UE is in the inactive state, the steps of continuing to receive or not receiving MBS data using the MBS configuration parameter, based on whether the MBS configuration parameter is for (i) receiving a broadcast MBS session or (ii) receiving a unicast or multicast MBS session, respectively, Includes, The method described above is When the MBS configuration parameter is for receiving a broadcast MBS session, the steps include: retaining the MBS configuration parameter and continuing to receive MBS data using the MBS configuration parameter; When the MBS configuration parameter is for receiving a unicast or multicast MBS session, the steps include: retaining the MBS configuration parameter and suspending the use of the MBS configuration parameter. Methods that include...

5. When the aforementioned MBS configuration parameter is for receiving a multicast MBS session, the step of not continuing to receive MBS data using the aforementioned MBS configuration parameter. The method according to claim 4, including the method described in claim 4.

6. When the MBS configuration parameter is for receiving a unicast MBS session, the step of not continuing to receive MBS data using the MBS configuration parameter. The method according to claim 4, including the method described in claim 4.

7. A method for managing multicast and / or broadcast service (MBS) communications after state transitions, performed by user equipment (UE), The steps include: receiving MBS data from a wireless access network (RAN) using MBS configuration parameters while the UE is connected to the RAN; The steps include receiving a radio resource control (RRC) release message from the aforementioned RAN, The steps include transitioning from the connected state to an idle state or an inactive state in response to the RRC release message, While the UE is in the idle state or the inactive state, the steps of continuing to receive or not receiving MBS data using the MBS configuration parameter, based on whether the MBS configuration parameter is for (i) receiving broadcast MBS sessions or (ii) receiving unicast or multicast MBS sessions, respectively, Includes, The method described above is When the RRC release message indicates a transition to the idle state, (i) the transition step includes a step of transitioning to the idle state, and (ii) the method includes a step of holding or releasing the MBS configuration parameter, based on whether the MBS configuration parameter is for (i) receiving a broadcast MBS session or (ii) receiving a unicast or multicast MBS session, method.

8. When the RRC release message indicates a transition to the inactive state, (i) the transition step includes a step of transitioning to the inactive state, and (ii) the method includes a step of holding the MBS configuration parameter and continuing to use or not using the MBS configuration parameter to receive MBS data, based on whether the MBS configuration parameter is for (i) receiving a broadcast MBS session or (ii) receiving a unicast or multicast MBS session, respectively. The method according to claim 7.

9. When the aforementioned MBS configuration parameter is for receiving a multicast MBS session, the step of not continuing to receive MBS data using the aforementioned MBS configuration parameter. The method according to claim 7, including the method described in claim 7.

10. When the MBS configuration parameter is for receiving a unicast MBS session, the step of not continuing to receive MBS data using the MBS configuration parameter. The method according to claim 7, including the method described in claim 7.

11. A user device (UE) configured to carry out the method described in any one of claims 1 to 10.

Images