Management of multicast services during handover - Patents.com

Abstract

A method for managing MBS communication implemented by a RAN node includes receiving a handover request message from a network node, the handover request message including a first MRB identifier associated with a first MRB for an MBS session, and transmitting a handover request confirmation message including an RRC reconfiguration message to the network node. The RRC reconfiguration message indicates that the UE should release the first MRB and add a second MRB associated with a second MRB identifier. The method also includes transmitting MBS data of the MBS session to the UE.

Description

[Technical field]

[0001] The present disclosure relates to wireless communications, and more particularly, to enabling setup or modification of radio resources for multicast and / or broadcast services (MBS) for handover. [Background technology]

[0002] The discussion of the background art provided herein is intended to provide a general context for the present disclosure. The work of the presently named inventors, to the extent that it is described in this background section, is not admitted expressly or impliedly as prior art to the present disclosure, as are aspects of the present disclosure that may not, in some cases, be considered prior art at the time of filing.

[0003] In telecommunication systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as transport, encryption, and integrity protection of user plane data. For example, the PDCP sublayer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) air interface (see 3rd Generation Partnership Project (3GPP®) specification TS 36.323) and New Radio (NR) (see 3GPP® specification TS 38.323) provides sequencing of protocol data units (PDUs) in the uplink direction from a user device (also known as user equipment or "UE") to a base station, and in the downlink direction from a base station to a UE. The PDCP sublayer also provides services for signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer. The PDCP sublayer further provides services for data radio bearers (DRBs) to the Service Data Adaptation Protocol (SDAP) sublayer or to protocol layers such as the Internet Protocol (IP) layer, the Ethernet protocol layer, or the Internet Control Message Protocol (ICMP) layer. In general, a UE and a base station may use an SRB to exchange RRC messages and non-access stratum (NAS) messages, and may use a DRB to transport data on the user plane.

[0004] A UE in some scenarios can simultaneously utilize resources of multiple nodes (e.g., base stations or components of distributed or disaggregated base stations) of a radio access network (RAN) interconnected by a backhaul. When these network nodes support different radio access technologies (RATs), this type of connectivity is called multi-radio dual connectivity (MR-DC). When operating in MR-DC, cells associated with a base station operating as a master node (MN) define a master cell group (MCG) and cells associated with a base station operating as a secondary node (SN) define a secondary cell group (SCG). The MCG covers a primary cell (PCell) and zero, one, or more secondary cells (SCells), and the SCG covers a primary secondary cell (PSCell) and zero, one, or more SCells. The UE communicates with the MN (through the MCG) and the SN (through the SCG). In other scenarios, the UE utilizes resources of one base station at a time in single connectivity (SC). A UE in an SC communicates only with the MN via the MCG. The base station and / or the UE decide when the UE should establish a radio connection with another base station. For example, the base station may decide to handover the UE to another base station and initiate a handover procedure. A UE in another scenario may simultaneously utilize resources of another RAN node (e.g., a base station, or a component of a distributed or separate base station) interconnected by a backhaul.

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

[0006] The UE may perform handover procedures to switch from one cell to another cell, whether in SC or DC operation. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. The UE may handover from a cell of a serving base station to a target cell of a target base station, or from a cell of a first distributed unit (DU) of the serving base station to a target cell of a second DU of the same base station, depending on the scenario. In a DC scenario, the UE may perform PSCell change procedures to change the PSCell. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. The UE may perform a PSCell change from a PSCell of a serving SN to a target PSCell of a target SN, or from a PSCell of a source DU of a base station to a PSCell of a target DU of the same base station, depending on the scenario. Additionally, the UE may perform handover or PSCell change within a cell for synchronous reconfiguration.

[0007] Base stations operating according to the fifth generation (5G) New Radio (NR) requirements support significantly larger bandwidths than fourth generation (4G) base stations. Thus, the 3rd Generation Partnership Project (3GPP®) proposes for Release 15 that UEs support 100 MHz bandwidth in Frequency Range 1 (FR1) and 400 MHz bandwidth in Frequency Range 2 (FR2). Due to the relatively wide bandwidth of a typical carrier in 5G NR, 3GPP® proposes for Release 17 that 5G NR base stations are capable of providing multicast and / or broadcast services (MBS) to UEs. MBS can be useful in many content distribution applications, such as, for example, transparent IPv4 / IPv6 multicast distribution, IPTV, software distribution over wireless, group communication, Internet of Things (IoT) applications, V2X applications, and emergency messages related to public safety.

[0008] 5G NR provides both point-to-point (PTP) and point-to-multipoint (PTM) distribution methods for the transmission of MBS packet flows over the air interface. In PTP communication, the RAN node transmits different copies of each MBS data packet to different UEs over the air interface, whereas in PTM communication, the RAN node transmits a single copy of each MBS data packet to multiple UEs over the air interface. However, in some scenarios, such as mobility scenarios, it is unclear how the base station and / or core network (CN) handle the MBS communication. [Prior art documents] [Non-patent literature]

[0009] [Non-Patent Document 1] 3rd Generation Partnership Project (3GPP) Specification TS 36.323 [Non-Patent Document 2] 3GPP (registered trademark) specification TS 38.323 Summary of the Invention [Means for solving the problem]

[0010] In one aspect of the disclosure, a method for managing MBS communication implemented by a RAN node includes receiving a handover request message from a network node, the handover request message including a first MRB identifier associated with a first MRB for an MBS session, and transmitting a handover request confirmation message including an RRC reconfiguration message to the network node. The RRC reconfiguration message indicates that the UE should release the first MRB and add a second MRB associated with a second MRB identifier. The method also includes transmitting MBS data of the MBS session to the UE.

[0011] In another aspect, a method for managing MBS communication implemented by a network node includes sending a handover request message to a RAN node, the handover request message including a first MRB identifier associated with a first MRB for an MBS session, and receiving a handover request confirmation message from the RAN node, the handover request confirmation message including an RRC reconfiguration message. The RRC reconfiguration message indicates that the UE should release the first MRB and add a second MRB associated with a second MRB identifier. The method also includes sending the RRC reconfiguration message to the UE.

[0012] In another aspect, a method for managing MBS communications implemented by a UE includes receiving MBS data of an MBS session from a first RAN node via a first MRB, receiving an RRC message from the first RAN node, and releasing the first MRB and adding a second MRB based on the RRC message. The method also includes receiving other MBS data of the MBS session from a second RAN node via the second MRB.

[0013] In another aspect, a method for managing MBS communication performed by a RAN node includes configuring a DRB associated with a PDU session for a UE, configuring an MRB associated with an MBS session for the UE, transmitting MBS data to the UE via the MRB, releasing the MRB, and after the releasing step, transmitting other MBS data to the UE via the DRB. [Brief description of the drawings]

[0014] [Figure 1A] 1 is a block diagram of an example system in which techniques of the present disclosure for managing the transmission and reception of MBS information may be implemented. [Figure 1B] FIG. 1B is a block diagram of an exemplary base station in which the central unit (CU) and distributed units (DU) can operate in the system of FIG. 1A. [Figure 2A]1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A can communicate with the base station of FIG. 1A. [Figure 2B] FIG. 1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A can communicate with the DU and CU of the base station. [Diagram 3] FIG. 1 is a block diagram illustrating an example tunnel architecture for MBS and PDU sessions. [Figure 4A] A messaging diagram of an example scenario in which a CN and a base station establish a common downlink (DL) tunnel or a UE-specific DL tunnel, through which the CN can send MBS data of an MBS session for one or more UEs to the base station, and the base station sends the MBS data to one or more UEs via an MRB or DRB. [Figure 4B] A messaging diagram of an example scenario in which a CN and a base station establish a common downlink (DL) tunnel or a UE-specific DL tunnel, through which the CN can send MBS data of an MBS session for one or more UEs to the base station, and the base station sends the MBS data to one or more UEs via an MRB or DRB. [Figure 5A] 1 is a messaging diagram of an example scenario in which the RAN configures or reconfigures radio resources for an MBS session during handover preparation. [Figure 5B] 1 is a messaging diagram of an example scenario in which the RAN configures or reconfigures radio resources for an MBS session during handover preparation. [Figure 5C] 1 is a messaging diagram of an example scenario in which the RAN configures or reconfigures radio resources for an MBS session during handover preparation. [Figure 5D] 1 is a messaging diagram of an example scenario in which the RAN configures or reconfigures radio resources for an MBS session during handover preparation. [Figure 6]FIG. 1B is a flow diagram of an example method for configuring multiple RAN nodes to assign the same MRB ID for a particular MBS Session ID, which may be implemented in the Core Network (CN) of FIG. 1A or in a network node (e.g., an Operations, Administration, and Maintenance (OAM) node, not shown in FIG. 1A ). [Figure 7] 1B is a flow diagram of an example method for configuring an MRB ID for a particular MBS session ID, which may be implemented in the base station of FIG. 1A or the CU of FIG. [Figure 8] 1B is a flow diagram of an example method for managing configurations for MBS reception in handover preparation, which may be implemented in the base station of FIG. 1A or the CU of FIG. 1B. [Figure 9] 1B is a flow diagram of an example method for managing configurations for MBS reception in handover preparation, which may be implemented in the base station of FIG. 1A or the CU of FIG. 1B. [Figure 10] 1B is a flow diagram of an example method for managing configurations for MBS reception in handover preparation, which may be implemented in the base station of FIG. 1A or the CU of FIG. 1B. [Figure 11] 1B is a flow diagram of an example method for managing configurations for MBS reception in handover preparation, which may be implemented in the base station of FIG. 1A or the CU of FIG. 1B. [Figure 12] 1B is a flow diagram of an example method for receiving MBS data that may be implemented in the UE of FIG. 1A. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] In general, a radio access network (RAN) and / or a core network (CN) may implement the techniques of this disclosure to manage transmission of multicast and / or broadcast services (MBS). The CN may request that the base station configure a common downlink (DL) tunnel through which the CN may transmit MBS data for an MBS session for multiple user equipments (UEs) to the base station. In response to the request, the base station transmits the 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)).

[0016] The base station may also configure one or more logical channels toward the UE and / or one or more MBS Radio Bearers (MRBs) associated with the MBS session, where there may be a one-to-one mapping between each logical channel and each MRB. After receiving MBS data for the MBS session via the common DL tunnel, the base station may transmit the MBS data via one or more logical channels to one or more UEs participating in the MBS session. In some implementations, the base station transmits the MBS data to multiple UEs via a single logical channel. Furthermore, when 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.

[0017] The CN can have the base station configure a common DL tunnel before or after the UE joins the MBS session. If additional UEs join the MBS session after the tunnel is configured, the CN can use the same common DL tunnel to transmit MBS data for multiple UEs to the base station.

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

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

[0020] In non-MBS (unicast) operation, the UE 102A may use a radio bearer (e.g., DRB or SRB) that terminates at 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 to the base station 106, the UE 102A may use a radio bearer (e.g., DRB or SRB) that terminates at the base station 106. The UE 102A may apply one or more security keys when communicating on a radio bearer in an uplink (UE 102A to base station) direction and / or a downlink (base station to UE 102A) direction. In non-MBS operation, the UE 102A transmits data to a base station via a radio bearer on the uplink (UL) bandwidth part (BWP) of the cell (i.e., within the UL BWP) and / or receives data from the base station via a radio bearer on the downlink (DL) BWP of the cell. The UL BWP can be an initial UL BWP or a dedicated UL BWP, and the DL BWP can be an initial DL BWP or a dedicated DL BWP. The UE 102A can receive paging, system information, public alert messages, or random access responses on the DL BWP. In this non-MBS operation, the UE 102A can be in a connected state. Alternatively, the UE 102A can be in an idle or inactive state if the UE 102A supports small data transmission (sometimes referred to as "early data transmission") in the idle or inactive state.

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

[0022] The base station 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., central processing units (CPUs)) and computer-readable memory that stores machine-readable instructions executable on one or more general-purpose processors and / or special-purpose processing units. The processing hardware 130 in the example implementation of FIG. 1A includes an MBS controller 132 configured to manage or control transmission of MBS information received from the CN 110 or edge server. For example, 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 a MN or SN during non-MBS operation.

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

[0024] The UE 102A includes processing hardware 150, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory that stores machine-readable instructions executable on the general-purpose processors and / or dedicated processing units. The processing hardware 150 in the example implementation of FIG. 1A includes an MBS controller 152 configured to manage or control 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. The processing hardware 150 may also include a non-MBS controller 154 configured to manage or control one or more RRC configurations and / or RRC procedures according to any of the implementations described below when the UE 102A communicates with the MN and / or SN during non-MBS operation. Although not shown in FIG. 1A, the UEs 102B, 103 may each include processing hardware similar to the processing hardware 150 of the UE 102A.

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

[0026] Among other components, the EPC 111 may include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. The SGW 112 is generally configured to forward user plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE (e.g., UE 102A or 102B) to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 160 includes a User Plane Function (UPF) 162, an Access and Mobility Management (AMF) 164, and / or a Session Management Function (SMF) 166. The UPF 162 is generally configured to forward user plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is generally configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is generally configured to manage PDU sessions.

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

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

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

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

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

[0032] Each of the DUs 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory that stores machine-readable instructions executable on one or more general-purpose processors and / or special-purpose processing units. For example, the processing hardware may include a medium 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 the base station (e.g., base station 104) operates as a MN or SN. The processing hardware may also include a physical (PHY) layer controller configured to manage or control one or more PHY layer operations or procedures.

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

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

[0035] The above description is applicable to UEs 102B and 103.

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

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

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

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

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

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

[0042] 3, which illustrates an example architecture 300 for MBS and PDU sessions, an MBS session 302A may include a tunnel 312A having endpoints at the CN 110 and the base station 104 / 106 (i.e., the base station 104 or the base station 106). The MBS session 302A may correspond to a particular session ID, such as, for example, a Temporary Mobile Group Identification (TMGI). The MBS data may include, for example, IP packets, TCP / IP packets, UDP / IP packets, Real-time Transport Protocol (RTP) / UDP / IP packets, or RTP / TCP / IP packets.

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

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

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

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

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

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

[0049] 4A, in an example scenario 400A, in response to a CN requesting resources for an MBS session, a base station (BS) 104 configures a common tunnel for MBS data. In the following description, a UE 102 can represent a UE 102A and / or a UE 102B.

[0050] The UE 102 first performs a PDU session establishment procedure 490 with the CN 110 via the base station 104 to establish a PDU session for receiving the MBS. More specifically, the UE 102 sends a PDU Session Establishment Request message to the base station 104 (402), and the base station 104 sends a PDU Session Establishment Request message (including an inter-BS-CN message) to the CN 110 (404). In response, the CN 110 can send a PDU Session Establishment Accept message (including an inter-CN-BS message) to the base station 104 (406), and the base station 104 sends a PDU Session Establishment Accept message to the UE 102 (408). In response to the PDU Session Establishment Accept message, the UE 102 sends a PDU Session Establishment Complete message to the base station 104 (410), and the base station 104 sends a PDU Session Establishment Complete message (including an inter-BS-CN message) to the CN 110 (412).

[0051] In some implementations, the UE 102 may generate a container message including a PDU Session Establishment Request message and transmit (402, 404) the container message to the CN 110 via the base station 104. Similarly, the CN 110 may generate a container message including a PDU Session Establishment Accept message and transmit (406, 408) the container message to the UE 102 via the base station 104. Similarly, the UE 102 may generate a container message including a PDU Session Establishment Complete message and transmit (410, 412) the container message to the CN 110 via the base station 104.

[0052] To simplify the following description, the PDU Session Establishment Request message, the PDU Session Establishment Accept message, and the PDU Session Establishment Complete message may represent respective container messages.

[0053] In some implementations, the UE 102 may include in the PDU Session Establishment Request message a PDU Session ID that identifies the PDU session, slice information associated with the MBS session of event 422, and / or a specific Data Network Name (DNN) (e.g., "MBS" or "mbs") In some implementations, the CN 110 may include the PDU Session ID in the PDU Session Establishment Accept message.

[0054] In response to or after receiving the message (406), the CN 110 can send (414) a CN-to-BS message (e.g., a PDU Session Resource Setup Request message) to the base station 104 to request the base station 104 to configure resources for the PDU session. In some implementations, the CN 110 can include a PDU session ID in the CN-to-BS message. In response to the CN-to-BS message, the base station 104 can send (416) an RRC reconfiguration message including unicast configuration parameters to the UE 102. In response, the UE 102 sends (418) an RRC reconfiguration complete message to the base station 104. The base station 104 can send (420) a BS-to-CN message (e.g., a PDU Session Resource Setup Response message) to the CN 110 after or before receiving (420) the RRC reconfiguration complete message. In some implementations, the CN 110 may include in the CN-to-BS message of event 406 or event 414 a UL transport layer configuration that configures a UE-specific UL tunnel for a PDU session with the UE 102. Alternatively, the CN 110 refrains from configuring a UE-specific UL tunnel for a PDU session with the UE 102. The UL transport layer configuration includes a transport layer address (e.g., IP address) and / or a TEID for identifying the UE-specific UL tunnel. In some implementations, the base station 104 may include in the BS-to-CN message of event 412 or event 420 a DL transport layer configuration that configures a UE-specific DL tunnel for a PDU session with the UE 102. The DL transport layer configuration includes a transport layer address (e.g., IP address) and / or a TEID for identifying the UE-specific DL tunnel.

[0055] In some implementations, the CN-BS message of event 406 and the CN-BS message of event 414 may be combined into a single CN-BS message. For example, the CN 110 may include a PDU Session Establishment Accept message in the CN-BS message of event 414, and event 406 may be omitted. In some implementations, the base station 104 may include a PDU Session Establishment Accept message in the RRC reconfiguration message of event 416, or may send the PDU Session Establishment Accept message after sending (416) the RRC reconfiguration message. In such a case, the UE 102 may include a PDU Session Establishment Complete message in the RRC reconfiguration complete message of event 418, or may send the PDU Session Establishment Complete message before or after sending (418) the RRC reconfiguration complete message. In some implementations, the base station 104 may include a PDU Session Establishment Complete message in the BS-CN message of event 420.

[0056] In some implementations, the unicast configuration parameters may include a (first) DRB configuration (e.g., DRB-ToAddMod IE) and a first lower layer configuration. The DRB configuration configures the (first) DRB. The DRB configuration includes a DRB ID (e.g., drb-Identity or DRB-Identity) that identifies the DRB, and includes a PDU session ID to indicate that the DRB (ID) is associated with a PDU session (ID). The DRB configuration may also include a PDCP configuration and / or an SDAP configuration.

[0057] In some implementations, the (first) lower layer configuration is associated with the DRB configuration. The lower layer configuration includes a (first) logical channel identity (ID) (e.g., LogicalChannelIdentity IE) that identifies a logical channel (e.g., a Dedicated Traffic Channel (DTCH)), an RLC configuration (e.g., an RLC-Config IE), and / or a logical channel configuration (e.g., a LogicalChannelConfig IE). In some implementations, the base station 104 can exclude the logical channel configuration from the RRC reconfiguration message 416. In some implementations, the lower layer configuration can be or include an RLC bearer configuration (e.g., an RLC-BearerConfig IE), and the RLC bearer configuration can include a DRB ID, a logical channel ID, an RLC configuration, and / or a logical channel configuration. In some implementations, the lower layer configuration can be a cell group configuration (e.g., a CellGroupConfig IE). In some implementations, the lower layer configuration includes a MAC configuration (eg, a MAC-CellGroupConfig IE) or a physical layer configuration (eg, a PhysicalCellGroupConfig IE).

[0058] After performing the PDU session establishment procedure 490, the UE 102 performs an MBS session join procedure 422 with the CN 110 via the base station 104 to join a particular MBS session (e.g., a first MBS session). To perform the MBS session join procedure 422, the UE 102, in some implementations, sends an MBS session join request message to the base station 104, which in turn sends the MBS session join request message to the CN 110. In response, the CN 110 can send an MBS session join response message to the UE 102 via the base station 104 to allow the UE 102 to access the MBS session. In some implementations, the UE 102 can include a (first) MBS session ID of the MBS session in the MBS session join request message. The CN 110 includes the MBS session ID in the MBS session join response message in some cases. In some implementations, the UE 102 can send an MBS session join complete message to the CN 110 via the base station 104 in response to the MBS session join response message. In some implementations, the UE 102 may include the MBS Session ID in the PDU Session Establishment Request message of event 402 or the PDU Session Establishment Complete message of event 410.

[0059] In some implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message may be a Session Initiation Protocol (SIP) message. In other implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message may be a NAS message, such as a 5G Mobility Management (5GMM) message or a 5G Session Management message (5GSM). For a 5GSM message, the UE 102 may send a (first) UL container message including the MBS session join request message to the CN 110 via the base station 104, the CN 110 may send a DL container message including the MBS session join response message to the UE 102 via the base station 104, and the UE 102 may send a (second) UL container message including the MBS session join complete message to the CN 110 via the base station 104. These container messages may be 5GMM messages. In some implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message may be a PDU Session Modification Request message, a PDU Session Modification Command message, and a PDU Session Modification Complete message, respectively. To simplify the following description, the MBS session join request message, the MBS session join response message, and / or the MBS session join complete message may represent their respective container messages.

[0060] During the MBS session join procedure 422, the UE 102 can communicate the PDU session ID with the CN 110 via the base station 104. For example, the UE 102 can include the PDU session ID in an MBS session join request message or an MBS session join complete message, and / or the CN 110 can include the PDU session ID in an MBS session join response message. In some implementations, the PDU session IDs of the UE 102A and the UE 102B can be the same (i.e., have the same value). In other implementations, the PDU session IDs of the UE 102A and the UE 102B can be different (i.e., have different values).

[0061] Before, during, or after the MBS session join procedure 422, the CN 110 can send (424) a (first) CN-to-BS message including an MBS Session ID and / or a PDU Session ID to the base station 104 to request the base station 104 to configure resources for the MBS session. The CN 110 can additionally include a quality of service (QoS) configuration for the MBS session in the CN-to-BS message. In response, the base station 104 can send (426) (decide to) a (first) BS-to-CN message including a DL transport layer configuration to configure a common DL tunnel for the CN 110 to send MBS data to the base station 104. The DL transport layer configuration includes a transport layer address (e.g., an IP address) and / or a TEID to identify the common DL tunnel. The base station 104 can include the MBS Session ID and / or the PDU Session ID in the BS-to-CN message. If the base station 104 has configured a common DL tunnel for the MBS session before receiving the inter-BS-CN message, the base station 104 decides not to send the inter-BS-CN message, i.e., in such a case, the base station 104 refrains from sending the inter-BS-CN message.

[0062] In some implementations, the CN-BS message of event 424 may be a generic or 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 of event 426 is a generic or dedicated NGAP message specifically defined to convey resources for an MBS session (e.g., an MBS session resource setup response message). In such cases, the CN-BS message of event 424 and the BS-CN message of event 426 may be non-UE specific messages.

[0063] In some implementations, the CN 110 may indicate in the CN-BS message of event 424 a list of UEs participating in the MBS session. In other implementations, the CN 110 may send (430) a second CN-BS message to the base station 104 indicating a list of UEs participating in the MBS session. The CN 110 may include an MBS session ID and / or a PDU session ID in the second CN-BS message. The base station 104 may send (434) a second BS-CN message to the CN 110 in response to the second CN-BS message 430. In such a case, the second CN-BS message and the second BS-CN message may be non-UE specific messages. In this scenario, the list of UEs may include the UE 102A and / or the UE 102B. To indicate the list of UEs, the CN 110 may include a list of (CN UE interface ID, RAN UE interface ID) pairs, each of which identifies a particular one of the UEs. For example, the list of pairs includes a first pair that identifies the UE 102A (first CN UE interface ID, first RAN UE interface ID) and a second pair that identifies the UE 102B (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 CN 110 can include a list of UE IDs, each of which identifies a specific UE in the set of UEs. In some implementations, the CN 110 can assign UE IDs and send each of the UE IDs to a specific one of the UEs in a NAS procedure (e.g., a registration procedure) that the CN 110 performs with the specific UE. For example, the list of UE IDs can include a first UE ID of the UE 102A and a second UE ID of the UE 102B. In some implementations, the UE ID is an S-Temporary Mobile Subscriber Identity (S-TMSI) (e.g., 5G-S-TMSI).

[0064] In some alternative implementations, the CN 110 may send (430) another second inter-CN-BS message to the base station 104 indicating that the UE 102 (e.g., a single UE such as UE 102A or UE 102B) will join the first MBS session. The base station 104 may send (434) another second inter-BS-CN message to the CN 110 in response to the second inter-CN-BS message of event 430. In such a case, the CN 110 may include in the second inter-CN-BS message an MBS session join response message for the UE 102. The base station 104 may include in the second inter-CN-BS message a first CN UE interface ID and a first RAN UE interface ID that identify the UE 102. In some implementations, the second inter-CN-BS message and the second inter-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.

[0065] In other implementations, the first CN-to-BS message may be a UE-specific NGAP message (e.g., a PDU Session Resource Modify Request message) indicating that the UE 102 (e.g., a single UE such as UE 102A or UE 102B) joins the MBS session. The CN 110 may include an MBS session join response message for the UE 102 in the first CN-to-BS message. The base station 104 may include a first CN UE interface ID and a first RAN UE interface ID that identify the UE 102 in the first CN-to-BS message. In some implementations, the first BS-to-CN message may be a generic NGAP message or a dedicated NGAP message (e.g., an MBS Session Resource Setup Indication message or a RAN Configuration Update message) specifically defined to convey resources for the MBS session. In such a case, the CN 110 may send (430) a second inter-CN-BS message (e.g., an MBS Session Resource Setup Confirm message or a RAN Configuration Update Acknowledge message) to the base station 104 in response to the first inter-CN-BS message. Alternatively, the base station 104 may send (434) a second inter-BS-CN message (e.g., a PDU Session Resource Modify Response message) to the CN 110 in response to the first inter-CN-BS message.

[0066] In some implementations, the CN 110 may include the MBS session join response message for the UE 102 in another CN-BS message instead of the first CN-BS message or the second CN-BS message.

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

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

[0069] After or in response to receiving (424), receiving (430), or transmitting (426) the first CN-to-BS message, the base station 104 generates an RRC reconfiguration message (e.g., an RRCReconfiguration message) that includes MBS configuration parameters for the UE 102 to receive MBS data for the MBS session. The base station 104 then transmits (428) the RRC reconfiguration message to the UE 102. In response, the UE 102 transmits (432) an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the base station 104. The base station 104 can send (434) the second BS-to-CN message to the CN 110 before or after receiving (432) the RRC reconfiguration complete message.

[0070] In some implementations, the MBS configuration parameters may include one or more MRB configurations and / or one or more RLC bearer configurations, each associated with a particular MRB. Each of the MRB configurations may include a (first) MRB ID (e.g., MRB ID 1), a PDCP configuration, an MBS session ID, a PDCP re-establishment indication (e.g., reestablishPDCP), and / or a PDCP restoration indication (e.g., recoveryPDCP). In some implementations, the PDCP configuration may be a PDCP-Config IE for the 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 that configures a logical channel (e.g., MBS traffic channel (MTCH)). In some implementations, the configuration parameters or the MRB configuration may include a logical channel configuration (e.g., LogicalChannelConfig IE) that configures a logical channel. In some implementations, the RLC bearer configuration may include an MRB ID. In some implementations, the base station 104 can set the MRB ID to the same value as the DRB ID of the event 416. Thus, the UE 102 and the base station 104 can associate the MRB with the DRB or PDU session. In other implementations, the base station 104 can set the MRB ID to a value different from the DRB ID of the event 416. Since the UE 102 associates the MBS session (ID) with the PDU session (ID), the UE 102 can associate the MRB (ID) with the MBS session (ID) according to the MRB configuration and identify that the MRB (ID) is associated with the DRB (ID).

[0071] In some implementations, the UE 102 can perform an MBS session exit procedure with the CN 110 via the base station 104 to exit the MBS session. In the MBS session exit procedure, the UE 102 sends an MBS session exit request message to the CN 110 via the base station 104 to exit the MBS session. In response, the CN 110 sends an MBS session exit response message to the UE 102 via the base station 104. In response to the MBS session exit response message, the UE 102 may send an MBS session exit complete message to the CN 110 via the base station 104. For example, the MBS session exit request message, the MBS session exit response message, and / or the MBS session exit complete message may be a SIP message. In another example, the MBS session exit request message, the MBS session exit response message, and / or the MBS session exit complete message may be a PDU Session Modification Request message, a PDU Session Modification Command message, and a PDU Session Modification Complete message, respectively. In some implementations, the MBS session exit request message, the MBS session exit response message, and / or the MBS session exit complete message may be included in separate container messages as described for the MBS session join procedure 422 above. To simplify the following description, the MBS session exit request message, the MBS session exit response message, and / or the MBS session exit complete message may represent their respective container messages. The UE 102 may include an MBS session ID and / or a PDU session ID in the MBS session exit request message. The CN 110 may include an MBS session ID and / or a PDU session ID in the MBS session exit response message to allow the UE 102 to exit the MBS session.If the UE 102 participates in the MBS session and another MBS session, the UE 102 can include the MBS session ID of the other MBS session in the MBS session leave request message. In this way, the UE 102 performs a single MBS session procedure with the CN 110 via the base station 104 to release all MBS sessions in which the UE 102 participates.

[0072] In some implementations, the CN 110 initiates the release of the MBS session by sending an MBS Session Leave Response message including the MBS Session ID to the UE 102 via the base station 104. In response, the UE 102 releases the MBS session and sends an MBS Session Leave Complete message to the CN 110 via the base station 104.

[0073] In some implementations, the UE 102 may perform a PDU session release procedure with the CN 110 to simultaneously release the PDU session and all MBS sessions associated with the PDU session without performing an MBS session release procedure. In the PDU session release procedure, the UE 102 may send a PDU Session Release Request message including a PDU session ID to the CN 110 via the base station 104. In response, the CN 110 may send a PDU Session Release Command message to the UE 102. In response to the PDU Session Release Command message, the UE 102 may release the PDU session and all MBS sessions and send a PDU Session Release Complete message to the base station 104. In some implementations, the PDU Session Release Request message, the PDU Session Release Command message, and / or the PDU Session Release Complete message may be included in separate container messages as described above for the PDU session establishment procedure. To simplify the following description, the PDU Session Release Request message, the PDU Session Release Command message, and / or the PDU Session Release Complete message may represent their respective container messages.

[0074] In some implementations, the UE 102 may not include the MBS session ID in the PDU Session Release Request message. In other implementations, the UE 102 may include the MBS session ID in the PDU Session Release Request message. The CN 110 may or may not include the PDU session ID and / or the MBS session ID in the PDU Session Release Command message. In some implementations, the CN 110 may initiate releasing the PDU session by sending a PDU Session Release Command message including the PDU session ID to the UE 102 via the base station 104. In response, the UE 102 releases the PDU session and the MBS session and sends a PDU Session Release Complete message to the CN 110 via the base station 104. In such implementations, the CN 110 may or may not include the MBS session ID in the PDU Session Release Command message.

[0075] In some implementations, the base station 104 can configure the MRB as a DL-only RB in the MRB configuration. For example, the base station 104 can refrain from including UL configuration parameters in the PDCP configuration in the MRB configuration to configure the MRB as a DL-only RB. The base station 104 can include only DL configuration parameters in the MRB configuration, for example, as described above. In such a case, the base station 104 configures the UE 102 not to transmit UL PDCP data PDUs to the base station 104 over the MRB by excluding UL configuration parameters for the MRB in the PDCP configuration in the MRB configuration. In another example, the base station 104 refrains from including UL configuration parameters in the RLC bearer configuration. In such a case, the base station 104 configures the UE 102 not to transmit control PDUs to the base station 104 over a logical channel by excluding UL configuration parameters from the RLC bearer configuration.

[0076] If the base station 104 includes the UL configuration parameters in the RLC bearer configuration, the UE 102 may transmit a control PDU (e.g., a PDCP control PDU and / or an RLC control PDU) to the base station 104 via a logical channel using the UL configuration parameters. For example, the base station 104 may configure the UE 102 to receive MBS data using a (de)compression protocol (e.g., a Robust Header Compression (ROHC) protocol). In this case, when the base station 104 receives (436) an MBS data packet from the CN 110, the base station 104 compresses the MBS data packet using the compression protocol to obtain a compressed MBS data packet and transmits (438) a PDCP PDU including the compressed MBS data packet to the UE 102. When the UE 102 receives (438) the compressed MBS data packet, the UE 102 decompresses the compressed MBS data packet using the (de)compression protocol to obtain the original MBS data packet. In such cases, the UE 102 may transmit a PDCP control PDU including header compression protocol feedback (eg, interspersed ROHC feedback) about the operation of the header compression (decompression) protocol to the base station 104 over a logical channel.

[0077] 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 particular MRB among the MRBs. The base station 104 sets the MRB ID to a different value. If the base station 104 configures a DRB for the UE 102 for unicast data communication, the base station 104 may set the MRB ID to a different value than the DRB ID of the DRB in some implementations. In such a case, the UE 102 and the base station 104 may distinguish whether an RB is an MRB or a DRB according to the RB ID of the RB. In other implementations, the base station 104 may set one or more of the MRB IDs to a value that is the same as one or more of the DRB IDs. In such a case, the UE 102 and the base station 104 may distinguish whether an RB is an MRB or a DRB according to the RB ID of the RB and the RRC IE that configures the RB.

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

[0079] In some implementations, the base station 104 can include the MBS session join response message in the RRC reconfiguration message that the base station 104 sends (428) to the UE 102. The UE 102 can include the MBS session join complete message in the RRC reconfiguration complete message of event 432. Alternatively, the UE 102 can send a UL RRC message including the MBS session join complete message to the base station 104. The UL RRC message can be any suitable RRC message that can include a UL Information Transfer message or a UL NAS PDU. The base station 104 can include the MBS session join complete message in a second inter-BS-CN message of event 434. Alternatively, the base station 104 can send another inter-BS-CN message (e.g., an UPLINK NAS TRANSPORT message) including the MBS session join complete message to the CN 110.

[0080] In other implementations, the base station 104 sends a DL RRC message including an MBS Session Join Response message to the UE 102. The DL RRC message may be a DL Information Transfer message, another RRC reconfiguration message, or any suitable RRC message that may include a DL NAS PDU. The UE 102 may send a UL RRC message including an MBS Session Join Complete message to the base station 104. The UL RRC message may be a UL Information Transfer message, another RRC reconfiguration complete message, or any suitable RRC message that may include a UL NAS PDU.

[0081] After receiving the first BS-to-CN message (426) or after receiving the second BS-to-CN message (434), the CN 110 can send the MBS data to the base station 104 via the UE-specific DL tunnel and / or the common DL tunnel (436), and the base station 104 transmits (e.g., multicast or unicast) the MBS data to the UE 102 via the MRB or DRB (i.e., via one or more logical channels associated with the MRB or DRB) (438). If the CN 110 can send the MBS data to the base station 104 via the UE-specific DL tunnel (436), the base station 104 transmits (e.g., multicast or unicast) the MBS data to the UE 102 via the DRB (i.e., via a logical channel associated with the DRB) (438). If the CN 110 is able to transmit the MBS data to the base station 104 via the common DL tunnel (436), the base station 104 transmits (e.g., multicast or unicast) the MBS data to the UE 102 via the MRB (i.e., via a logical channel associated with the MRB) (438).

[0082] The UE 102 receives the MBS data via one or more logical channels (438). For example, the base station 104 receives the MBS data packet from the CN 110 (436), generates a PDCP PDU including the MBS data packet according to the PDCP configuration in the MRB configuration, generates a MAC PDU including the logical channel ID and the PDCP PDU, and transmits the MAC PDU to the UE 102 via unicast or multicast (438). The UE 102 receives the MAC PDU (438), extracts the PDCP PDU and the logical channel ID from the MAC PDU, identifies the PDCP PDU associated with the MRB or DRB according to the logical channel ID, and extracts the MBS data packet from the PDCP PDU according to the PDCP configuration in the MRB or DRB configuration. More specifically, if the logical channel ID is associated with a DRB, the UE 102 retrieves the MBS data packets from the PDCP PDU according to the PDCP configuration in the DRB configuration, and if the logical channel ID is associated with an MRB, the UE 102 instead retrieves the MBS data packets from the PDCP PDU according to the PDCP configuration in the MRB configuration.

[0083] Events 424, 426, 428, 430, 432, 434, 436, and 438 are collectively referred to as an MBS transmission procedure 492 in FIG. 4A.

[0084] As shown in FIG. 3, the base station 104 can map data packets of a particular MBS session via a particular common DL tunnel to one or more MRBs, each corresponding to a respective logical channel. As described above, the base station 104 at event 426 configures the common DL tunnel, and the base station 104 at event 428 configures an MRB(ID) for the MBS session(ID) and configures a logical channel (ID) for (each of) the MRB(ID). In this manner, the base station 104 can map data packets of the MBS session via the common DL tunnel to MRBs, each corresponding to a respective logical channel.

[0085]

[0033] Referring now to Figure 4B, a scenario 400B is illustrated that is generally similar to scenario 400A. Events in scenario 400B that are similar to those described above for scenario 400A are labeled with the same reference numbers, and examples and implementations for Figure 4A can be applied to Figure 4B. Differences between the scenarios of Figure 4A and Figure 4B are described below.

[0086] In some implementations, the CN 110 may or may not send (424) a CN-to-BS message, for example, in response to or after receiving an MBS session join request message of the MBS session join procedure 422. If the CN 110 sends (424) a CN-to-BS message to the base station 104, the base station 104 may send (429) an RRC reconfiguration message including unicast configuration parameters to the UE 102 (instead of the MBS configuration parameters in event 428). In such a case, the base station 104 may not configure a common DL tunnel for the MBS session. In some implementations, the base station 104 may include in the BS-to-CN message of event 434 a DL transport layer configuration that configures a UE-specific DL tunnel. The DL transport layer configuration may include a transport layer address (e.g., an IP address) and / or a TEID to identify the UE-specific DL tunnel. In such a case, the CN 110 may or may not include in the CN-to-BS message 424 a UL transport layer configuration that configures a UE-specific UL tunnel.

[0087] In some implementations, the base station 104 can generate unicast configuration parameters to be included in a message for event 429 to update the unicast configuration parameters for event 416 and / or to configure another (second) DRB.

[0088] In some implementations, the unicast configuration parameters may include a (second) DRB configuration (e.g., DRB-ToAddMod IE) and a first lower layer configuration. The DRB configuration configures the (second) DRB. The DRB configuration includes a (second) DRB ID (e.g., drb-Identity or DRB-Identity) that identifies the DRB, and includes a PDU session ID to indicate that the DRB (ID) is associated with a PDU session (ID). The DRB configuration may also include a PDCP configuration and / or an SDAP configuration.

[0089] In some implementations, the (second) lower layer configuration is associated with the DRB configuration. The lower layer configuration includes a (second) logical channel identity (ID) (e.g., LogicalChannelIdentity IE) that identifies a logical channel (e.g., DTCH), an RLC configuration (e.g., RLC-Config IE), and / or a logical channel configuration (e.g., LogicalChannelConfig IE). In some implementations, the base station 104 can exclude the logical channel configuration from the RRC reconfiguration message 416. In some implementations, the lower layer configuration can be or include an RLC bearer configuration (e.g., RLC-BearerConfig IE), and the RLC bearer configuration can include a DRB ID, a logical channel ID, an RLC configuration, and / or a logical channel configuration. In some implementations, the lower layer configuration can be a cell group configuration (e.g., CellGroupConfig IE). In some implementations, the lower layer configuration includes a MAC configuration (e.g., MAC-CellGroupConfig IE) or a physical layer configuration (e.g., PhysicalCellGroupConfig IE).

[0090] In some implementations, the unicast configuration parameters (some of them) of event 429 and the unicast configuration parameters (some of them) of event 428 may have the same values. In other implementations, the unicast configuration parameters (some of them) of event 429 and the unicast configuration parameters (some of them) of event 428 may have different values.

[0091] Alternatively, the base station 104 refrains from sending (429) an RRC reconfiguration message to the UE 102, and event 432 is omitted.

[0092] After receiving the BS-CN message (434), the CN 110 can send (437) the MBS data via the UE-specific DL tunnel (i.e., configured in the BS-CN message 434) to the base station 104, which transmits (439) the MBS data via the second DRB (i.e., via the logical channel associated with the second DRB) to the UE 102. After receiving the BS-CN message (434) or after the MBS session join procedure 422, the CN 110 can send (437) the MBS data via the UE-specific DL tunnel (i.e., configured in event 420) to the base station 104, which transmits (439) the MBS data via the first DRB (i.e., via the logical channel associated with the first DRB).

[0093] As shown in FIG. 3, the base station 104 can map data packets of a particular MBS session via a particular UE-specific DL tunnel to one or more DRBs, each corresponding to a respective logical channel. As described above, the base station 104 at event 434 configures a UE-specific DL tunnel, and the base station 104 at events 490, 429 configures a DRB(ID) for the MBS session(ID) and configures a logical channel(ID) for (each of) the DRB(ID). In this manner, the base station 104 can map data packets of the MBS session via the UE-specific DL tunnel to a first DRB and / or a second DRB, each corresponding to a respective logical channel.

[0094] Events 424, 429, 434, 437, and 439 are collectively referred to as transmit MBS procedure 496 in FIG. 4B.

[0095] 5A next illustrates an example scenario 500A in which a base station (BS) 104 transmits (i.e., multicasts) MBS data to a UE 102 via a first MRB and later hands over the UE 102 to a BS 106. In the following description, a UE 102 can represent a UE 102A and / or a UE 102B.

[0096] First, the UE 102 performs a PDU session establishment procedure 590 with the CN 110 via the BS 104, similar to event 490. The UE 102 performs an MBS session participation procedure 522 with the CN 110 via the BS 104 to participate in the MBS session, similar to event 422. After event 522, the CN 110 can perform an MBS transmission procedure 592 with the BS 104 and the UE 102, in which the CN 110 can transmit MBS data of the MBS session to the BS 104, and the BS 104 transmits the MBS data to the UE 102 via the first MRB (identified by the first MRB ID), similar to event 492.

[0097] Similarly, the UE 103 performs a PDU session establishment procedure 591 with the CN 110 via the BS 106, similar to event 490. The UE 103 performs an MBS session join procedure 523 with the CN 110 via the BS 106 to join the MBS session (identified by the MBS session ID), similar to event 422. After event 523, the CN 110 can perform an MBS transmission procedure 593 with the BS 106 and the UE 102, in which the CN 110 can transmit MBS data of the MBS session to the BS 106, and the BS 106 transmits the MBS data to the UE 102 via the first MRB, similar to event 492.

[0098] Later, the BS 104 decides to handover the UE 102 to the BS 106. In response to the decision, the BS 104 sends a Handover Request message including the first MRB ID and the MBS session ID to the BS 106 (502). The BS 104 can include a PDU session ID and / or a DRB ID in the Handover Request message. The DRB ID identifying the DRB for the UE 102 is configured in procedure 590. In some implementations, the BS 104 can include an MRB configuration of the first MRB in the Handover Request message. Since the BS 106 has configured the first MRB (ID) for the MBS session (ID), the BS 106 may refrain from reconfiguring the first MRB for the UE 102. In response to the Handover Request message, the BS 106 sends a Handover Request Acknowledge message including an RRC reconfiguration message to the BS 104 to handover the UE 102 to the BS 106 (504). The BS 104 then extracts (506) the RRC reconfiguration message from the Handover Request Acknowledge message and transmits the RRC reconfiguration message to the UE 102. In response to or after receiving the RRC reconfiguration message, the UE 102 performs a random access procedure 508 with the BS 106 via the cell 126. The UE 102 can transmit (510) an RRC reconfiguration complete message to the BS 106 during or after the random access procedure 508.

[0099] In some implementations, the BS 106 may indicate in an RRC reconfiguration message that the first MRB and the DRB are to be handed over to the BS 106.

[0100] After the BS 106 detects that the UE 102 has successfully connected to the BS 106 via the cell 126, the BS 106 may send a Path Switch Request message to the CN 110 to indicate to the CN 110 that the UE 102 has connected to the BS 106. In response, the CN 110 may send a Path Switch Request Acknowledge message to the BS 106. After the UE 102 has successfully handed over to the BS 106, the BS 106 receives the MBS data via the common DL tunnel (established during procedure 593) (512). The BS 106 then transmits the MBS data to the UE 102 and the UE 103 via multicast and the first MRB (e.g., the logical channel (ID), RLC configuration, and / or PDCP configuration associated with the first MRB) (514).

[0101] If BS104 and BS106 use different G-RNTIs (e.g., a first G-RNTI and a second G-RNTI used by BS104 and BS106, respectively) to schedule transmission of MBS data for an MBS session, BS106 may include the second G-RNTI in the RRC reconfiguration message to replace the first G-RNTI. When UE102 receives the second G-RNTI in the RRC reconfiguration message, UE102 replaces the first G-RNTI with the second G-RNTI.

[0102] In some implementations, the BS 104 can perform handover preparation involving the CN 110 instead of handover preparation not involving the CN 110 (i.e., instead of events 502, 504). In handover preparation involving the CN 110, the BS 104 sends a handover required message including the first MRB ID and the MBS session ID to the CN 110. In response to or after receiving the handover required message, the CN 110 can send a handover request message (e.g., an NGAP message) including the first MRB ID and the MBS session ID to the BS 106. In some implementations, the BS 104 can include the DRB ID and the PDU session ID in the handover required message, and the CN 110 can include the DRB ID and the PDU session ID in the handover request message. In response to or after receiving the handover request message from the CN 110, the BS 106 may send a handover request confirmation message (e.g., an NGAP message) including an RRC reconfiguration message to the CN 110, which is similar to the handover request confirmation message 504. The CN 110 may then send a handover command message (e.g., an NGAP message) including the RRC reconfiguration message to the BS 104.

[0103]

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

[0104] After event 523, the CN 110 may perform an MBS transmission procedure 594 with the BS 106 and the UE 102 instead of the MBS transmission procedure 593. In procedure 594, the BS 106 configures a second MRB, identified by a second MRB ID, for the MBS session. During the MBS transmission procedure 594, the CN 110 may transmit MBS data for the MBS session to the BS 106, which transmits the MBS data to the UE 102 via the second MRB, similar to event 492.

[0105] When the BS 106 receives the first MRB ID (502), the BS 106 identifies that the BS 106 does not configure the first MRB ID for the MBS session (ID). In response to the identification, the BS 106 can generate an RRC reconfiguration message to indicate releasing the first MRB and adding a second MRB. For example, the BS 106 can generate an MRB release configuration (e.g., MRB-ToRelease IE or MRB-ToReleaseList IE) including the first MRB ID to indicate releasing the first MRB, and generate an MRB configuration (e.g., MRB-ToAddMod IE) to configure the second MRB. The BS 106 can include the MRB release configuration and the MRB configuration in the RRC reconfiguration message. The BS 106 then transmits a Handover Request Acknowledge message including the RRC reconfiguration message to the BS 104 (505). The BS 104 then sends an RRC reconfiguration message to the UE 102 (507).

[0106] In response to or after receiving the RRC reconfiguration message, the UE 102 releases the first MRB and adds the second MRB. More specifically, the UE 102 releases the first MRB in response to the MRB release configuration and adds (i.e., configures) the second MRB according to the MRB configuration. After event 512, the BS 106 transmits (513) MBS data to the UE 102 and the UE 103 via multicast and the second MRB (e.g., a logical channel, an RLC configuration, and / or a PDCP configuration associated with the second MRB).

[0107] Referring now to Figure 5C, a scenario 500C is illustrated that is generally similar to scenarios 500A and 500B. Events in scenario 500C that are similar to events described above in scenario 500A and / or scenario 500B are labeled with the same reference numbers, and examples and implementations for Figures 5A-5B can be applied to Figure 5C. Differences between the scenarios of Figures 5A-5C are described below.

[0108] After receiving the Handover Request message (502), the BS 106 releases the first MRB and refrains from configuring a second MRB for the UE 102. If the configuration (e.g., logical channel (ID), RLC configuration, and / or PDCP configuration) associated with the first MRB is different from the configuration (e.g., logical channel (ID), RLC configuration, and / or PDCP configuration) associated with the second MRB, the BS 106 can include the configuration associated with the second MRB in the RRC reconfiguration message. In this way, the UE 102 applies the configuration associated with the second MRB to receive MBS data via the second MRB (513). However, the BS 106 does not change the first MRB ID to the second MRB ID in the RRC reconfiguration message.

[0109] Referring now to Figure 5D, a scenario 500D is illustrated that is generally similar to scenarios 500A, 500B, and 500C. Events in scenario 500D that are similar to events described above for scenarios 500A, 500B, and / or 500C are labeled with the same reference numbers, and examples and implementations for Figures 5A-5C can be applied to Figure 5D. Differences between the scenarios of Figures 5A-5D are described below.

[0110] After receiving the Handover Request message (502), the BS 106 decides to release the first MRB since the BS 106 has not configured an MRB and / or resources (e.g., a common DL tunnel) for the MBS session. In response to the decision, the BS 106 indicates in an RRC reconfiguration message for handover that it will release the first MRB, as described with respect to FIG. 5B. The BS 106 then sends a Handover Request Acknowledge message including the RRC reconfiguration message to the BS 104 (503). The BS 104 then sends an RRC reconfiguration message to the UE 102 (517). After the UE 102 successfully hands over to the BS 106, the BS 106 receives the MBS data via the common DL tunnel (established during procedure 593) (512). The BS 106 then transmits the MBS data to the UE 102 via unicast and the DRB (e.g., a logical channel, an RLC (bearer) configuration, and / or a PDCP configuration associated with the DRB) (515). In some implementations, the UE 102 receives a DRB configuration from the BS 104 during procedure 590 to configure the DRB, similar to procedure 490 or event 416. In such a case, the BS 106 indicates to the UE 102 that the DRB is handed over to the BS 106. The BS 106 can include configuration parameters in an RRC reconfiguration message 503, 517 to reconfigure the DRB configuration or a configuration associated with the DRB. In other implementations, the RRC reconfiguration message includes a (new) DRB configuration to configure the DRB (i.e., a new DRB). In such a case, the BS 106 generates a DRB configuration and a configuration associated with the DRB to configure the DRB. In some implementations, the configuration includes an RLC (bearer) configuration (eg, an RLC-BearerConfig IE or an RLC-Config IE) and / or a logical channel ID that identifies a logical channel.

[0111] Later, the BS 106 may perform an MBS transmission procedure 595 to transmit MBS data for the MBS session over the MRB, similar to procedure 492 .

[0112] Next, some exemplary scenarios that may be implemented / performed by the device shown in Figure 1A will be described with reference to Figures 6-12. Each of these methods may be implemented by one or more processors executing a set of instructions stored on a non-transitory computer-readable medium. Blocks with dashed lines may be optional.

[0113] 6, a network node, such as the CN 110, the AMF 164, or an OAM node, may implement / perform a method 600 to receive MBS data. The method 600 begins at block 602, where the network node generates a list of MBS session IDs and MRB IDs. At block 604, the network node sends the list to multiple RAN nodes (e.g., CUs and / or base stations). Each of the MRB IDs corresponds to a particular MBS session ID. The list may be a mapping table.

[0114] [Table 1]

[0115] In some implementations, a network node (e.g., OAM or CN) sends a message containing the list to multiple RAN nodes, so that the multiple RAN nodes use the same MRB ID associated with the same MBS Session ID.

[0116] Referring now to FIG. 7, a RAN node, such as the CU 172 or base station 104 / 106, may implement / perform a method 700 to determine the MRB ID.

[0117] The method 700 begins at block 702, where the RAN node obtains a list of MBS session IDs and MRB IDs. At block 704, the RAN node decides to configure resources for the MBS session ID. For example, the RAN node may receive a CN-to-BS message including the MBS session ID from the CN to request resources for the MBS session ID. At block 706, the RAN node determines (e.g., selects or identifies) an MRB ID for the MBS session ID from the list (e.g., a mapping table). For example, if the MBS session ID is MBS session ID 2, the RAN node determines MRB ID 2 for MBS session ID 2 according to the mapping table. At block 708, the RAN node transmits the MRB configuration including the MRB ID and the MBS session ID to one or more UEs.

[0118] In some implementations, the RAN node receives a list of MBS session IDs and MRB IDs from a network node (e.g., CN or OAM). In other implementations, the RAN node is pre-configured to store the list of MBS session IDs and MRB IDs.

[0119] Referring now to FIG. 8, a RAN node, such as the CU 172 or base station 104 / 106, may implement / perform a method 800 to release or configure an MRB in handover preparation.

[0120] In block 802, the RAN node configures one or more UEs to receive MBS data via an MRB for an MBS session identified by a first MRB ID and an MBS session ID, respectively. In block 804, the RAN node receives a handover request message for a particular UE from a network node (e.g., another RAN node such as a base station or a CU, or a CN node such as an AMF), the handover request message including an MBS session ID and a second MRB ID. In block 806, the RAN node determines whether the first MRB ID and the second MRB ID have different values. If the first MRB ID and the second MRB ID have different values, the flow proceeds to block 808. In block 808, the RAN node generates an MRB release configuration including the first MRB ID. In block 810, the RAN node generates an MRB configuration including the second MRB ID. In block 812, the RAN node generates a first RRC reconfiguration message including the MRB release configuration and the MRB configuration. At block 814, the RAN node sends a handover request confirm message including the first RRC reconfiguration message to the network node in response to the handover request message.

[0121] If the first MRB ID and the second MRB ID have the same value, the flow proceeds instead to block 816. In block 816, the RAN node generates a second RRC reconfiguration message. In block 818, the RAN node transmits a handover request confirmation message including the second RRC reconfiguration message to the network node in response to the handover request message.

[0122] Referring now to FIG. 9, a RAN node, such as the CU 172 or base station 104 / 106, may implement / perform a method 900 to release or configure an MRB in handover preparation.

[0123] In block 902, the RAN node receives a handover request message including an MBS session ID and an MRB ID from a network node (e.g., another RAN node such as a base station or a CU, or a CN node such as an AMF) for a UE. In block 904, the RAN node determines whether a common DL tunnel for the MBS session ID is established. If the RAN node has established a common DL tunnel for the MBS session ID, the flow proceeds to block 906. In block 906, the RAN node determines whether the RAN node has configured an MRB ID for the MBS session. If the RAN node has not configured an MRB ID for the MBS session, the flow proceeds to block 908. In block 908, the RAN node generates an MRB release configuration including the MRB ID to release the MRB. In block 910, the RAN node generates an MRB configuration including the MRB ID associated with the MBS session. For example, the RAN node can include the MBS session ID in the MRB configuration. In some implementations, the MRB identified by the MRB ID in the MRB configuration is associated with a common DL tunnel as described for Figure 3. In block 912, the RAN node generates a first RRC reconfiguration message including the MRB release configuration and the MRB configuration. In block 914, the RAN node transmits a handover request confirmation message including the first RRC reconfiguration message to the network node in response to the handover request message.

[0124] If the RAN node has not established a common DL tunnel for the MBS session ID, the flow proceeds instead to block 916. In block 916, the RAN node generates an MRB release configuration including the MRB ID to release the MRB. In block 918, the RAN node generates a second RRC reconfiguration message including the MRB release configuration. In block 920, the RAN node transmits a handover request confirmation message including the second RRC reconfiguration message to the network node in response to the handover request message.

[0125] If the RAN node has configured an MRB ID for the MBS session, the flow proceeds to block 922. In block 922, the RAN node generates a third RRC reconfiguration message, and in block 924, the RAN node transmits a handover request confirm message including the third RRC reconfiguration message to the network node in response to the handover request message.

[0126] Referring now to FIG. 10, a RAN node, such as the CU 172 or base station 104 / 106, may implement / perform a method 1000 to transmit MBS data over an MRB and / or a DRB.

[0127] In block 1002, the RAN node configures a DRB associated with the PDU session for the UE. In block 1004, the RAN node configures an MRB associated with the MBS session for the UE. In block 1006, the RAN node transmits MBS data to the UE via the MRB. In block 1008, the RAN node releases the MRB. In block 1010, the RAN node transmits MBS data to the UE via the DRB, for example, after releasing the MRB.

[0128] 11, a RAN node, such as the CU 172 or base station 104 / 106, may implement / perform a method 1100 to release an MRB and transmit MBS data over a DRB.

[0129] In block 1102, the RAN node receives a handover request message from the network node for the UE, the handover request message including a DRB ID and an MRB ID. In block 1104, the RAN node generates an RRC reconfiguration message to release the MRB identified by the MRB ID. In block 1106, the RAN node transmits the RRC reconfiguration message to the UE via the network node. In block 1108, the RAN node transmits MBS data to the UE via the DRB identified by the DRB ID.

[0130] Referring now to FIG. 12, a UE, such as the UE 102, may implement / perform a method 1200 to receive MBS data via an MRB or a DRB.

[0131] In block 1202, the UE configures a DRB associated with the PDU session. In block 1204, the UE configures an MRB associated with the MBS session. In block 1206, the UE receives MBS data via the MRB. In block 1208, the UE releases the MRB. In block 1210, the UE receives (continues to receive) MBS data via the DRB, for example, after releasing the MRB.

[0132] The following list of examples reflects various implementations expressly contemplated by this disclosure.

[0133] Example 1. A method for managing multicast and / or broadcast service (MBS) communications implemented by a radio access network (RAN) node, comprising: receiving a handover request message from a network node, the handover request message including a first MBS radio bearer (MRB) identifier associated with a first MBS radio bearer (MRB) for an MBS session; sending a handover request confirmation message to the network node, the handover request confirmation message including a radio resource control (RRC) reconfiguration message, the RRC reconfiguration message indicating that a user equipment (UE) should release the first MRB and add a second MRB associated with a second MRB identifier; and sending MBS data for the MBS session to the UE.

[0134] Example 2. The method of Example 1, further including: before receiving the handover request message, performing an MBS session join procedure with a core network (CN) for another user equipment (UE) to join the MBS session; and transmitting other MBS data of the MBS session to the other UE via a second MRB.

[0135] Example 3. The method of Example 2, further comprising performing a random access procedure with the UE after sending the handover request confirmation message and before sending the MBS data to the UE.

[0136] Example 4. The method of any one of Examples 1-3, wherein the RRC reconfiguration message includes an MRB release configuration including a first MRB identifier and an MRB configuration including a second MRB identifier.

[0137] Example 5. The method of any one of Examples 1-4, further comprising: after receiving a handover request message, determining that the first MRB identifier and the second MRB identifier have different values; and based on the determining step, generating an RRC reconfiguration indicating that the UE should release the first MRB and add the second MRB.

[0138] Example 6. The method of any one of Examples 1 to 5, wherein the RAN node is a target base station and the network node is a source base station.

[0139] Example 7. The method of any one of Examples 1 to 5, wherein the RAN node is a target base station and the network node is a core network (CN).

[0140] Example 8. A method for managing multicast and / or broadcast service (MBS) communications implemented by a network node, comprising: sending a handover request message to a radio access network (RAN) node, the handover request message including a first MRB identifier associated with a first MBS radio bearer (MRB) for an MBS session; receiving a handover request confirmation message from the RAN node, the handover request confirmation message including a radio resource control (RRC) reconfiguration message, the RRC reconfiguration message indicating that a user equipment (UE) should release the first MRB and add a second MRB associated with a second MRB identifier; and sending the RRC reconfiguration message to the UE.

[0141] Example 9. The method of Example 8, further including: performing an MBS session join procedure with a core network (CN) for the UE to join the MBS session before sending the handover request message; and sending MBS data of the MBS session to the UE via the first MRB.

[0142] Example 10. The method of example 8 or 9, wherein the network node is a source base station and the RAN node is a target base station.

[0143] Example 11. The method of any one of Examples 8-10, wherein the first MRB identifier is different from the second MRB identifier.

[0144] Example 12. The method of any one of Examples 8-11, wherein the RRC reconfiguration message includes an MRB release configuration including a first MRB identifier and an MRB configuration including a second MRB identifier.

[0145] Example 13. A network node configured to implement the method of any one of Examples 1-12.

[0146] Example 14. A method for managing multicast and / or broadcast service (MBS) communications implemented by a user equipment (UE), comprising: receiving MBS data of an MBS session from a first radio access network (RAN) node via a first MBS radio bearer (MRB); receiving a radio resource control (RRC) message from the first RAN node; releasing the first MRB and adding a second MRB based on the RRC message; and receiving other MBS data of the MBS session from the second RAN node via the second MRB.

[0147] Example 15. The method of Example 14, further comprising performing an MBS session join procedure with the first RAN node to join the MBS session before receiving the MBS data.

[0148] Example 16. The method of example 14 or 15, wherein the first MRB is associated with a first MRB identifier and the second MRB is associated with a second MRB identifier that is different from the first MRB identifier.

[0149] Example 17. The method of example 15, wherein the RRC reconfiguration message includes an MRB release configuration including the first MRB identifier and an MRB configuration including the second MRB identifier.

[0150] Example 18. The method of any one of Examples 14-17, further comprising performing a random access procedure with the second RAN node after receiving the RRC reconfiguration message and before receiving the other MBS data.

[0151] Example 19. A user equipment (UE) configured to implement the method of any one of Examples 14-18.

[0152] Example 20. A method for managing multicast and / or broadcast service (MBS) communications implemented by a radio access network (RAN) node, comprising the steps of configuring a data radio bearer (DRB) associated with a protocol data unit (PDU) session for a user equipment (UE), configuring an MBS radio bearer (MRB) associated with the MBS session for the UE, transmitting MBS data to the UE via the MRB, releasing the MRB, and after the releasing step, transmitting other MBS data to the UE via the DRB.

[0153] Example 21. The method of example 20, wherein the RAN node is a base station.

[0154] Example 22. A RAN node configured to implement the method of example 20 or 21.

[0155] Example 23. A method for managing multicast and / or broadcast service (MBS) communications implemented by a radio access network (RAN) node, comprising: receiving a handover request message from the network node for a user equipment (UE), the handover request message including a first MBS radio bearer (MRB) identifier, the first MRB identifier being associated with a first MRB of an MBS session and an MBS session identifier being associated with the MBS session; generating a radio resource control (RRC) reconfiguration message including or not including an MRB release configuration including the first MRB identifier based on one or both of: (i) the RAN node has or has not configured the first MRB ID for the MBS session, and (ii) the RAN node has or has not established a common downlink tunnel for the MBS session identifier; and transmitting a handover request confirmation message including the RRC reconfiguration message to the network node.

[0156] Example 24. The method of example 23, comprising generating an RRC reconfiguration message including an MRB release configuration including the first MRB identifier when the RAN node has not configured the first MRB ID for the MBS session.

[0157] Example 25. The method of Example 24, further comprising the steps of: configuring one or more UEs to receive MBS data via a second MRB associated with a second MRB identifier prior to receiving the handover request message; and determining that the first MRB identifier and the second MRB identifier have different values, and wherein the step of generating an RRC reconfiguration message including an MRB release configuration including the first MRB identifier is based on the determining step.

[0158] Example 26. The method of example 25, comprising, when the RAN node has not configured a first MRB ID for the MBS session, generating an RRC reconfiguration message including (i) an MRB release configuration including the first MRB identifier, and (ii) an MRB configuration including the second MRB identifier.

[0159] Example 27. The method of example 23, comprising, when the RAN node configures a first MRB ID for the MBS session, generating an RRC reconfiguration message that does not include an MRB release configuration that includes the first MRB identifier.

[0160] Example 28. The method of Example 27, further comprising the steps of: configuring one or more UEs to receive MBS data via a second MRB associated with a second MRB identifier before receiving a handover request message; and determining that the first MRB identifier and the second MRB identifier have the same value, and wherein the step of generating an RRC reconfiguration message that does not include an MRB release configuration including the first MRB identifier is based on the determining step.

[0161] Example 29. The method of example 23, comprising generating an RRC reconfiguration message including an MRB release configuration including the first MRB identifier when the RAN node has not established a common downlink tunnel for the MBS session identifier.

[0162] Example 30. The method of example 23, comprising generating an RRC reconfiguration message including an MRB release configuration including a first MRB identifier when the RAN node has established a common downlink tunnel for the MBS session identifier and the RAN node has not configured a first MRB ID for the MBS session.

[0163] Example 31. The method of example 30, comprising, when the RAN node has established a common downlink tunnel for an MBS session identifier and the RAN node has not configured a first MRB ID for the MBS session, generating an RRC reconfiguration message including (i) an MRB release configuration including the first MRB identifier, and (ii) an MRB configuration including a second MRB identifier associated with a second MRB.

[0164] Example 32. The method of example 23, comprising, when the RAN node has established a common downlink tunnel for the MBS session identifier and the RAN node has configured a first MRB ID for the MBS session, generating an RRC reconfiguration message that does not include an MRB release configuration that includes the first MRB identifier.

[0165] Example 33. The method of any one of Examples 23-32, wherein the RAN node is a target base station for the handover and the network node is a source base station for the handover.

[0166] Example 34. The method of any one of Examples 23-32, wherein the RAN node is a target base station for handover and the network node is a core network (CN) node.

[0167] Example 35. A method for managing multicast and / or broadcast service (MBS) communications implemented by a radio access network (RAN) node, comprising: receiving a handover request message from a network node including a first MBS radio bearer (MRB) identifier when the RAN node has not previously configured a first MBS radio bearer (MRB) identifier for an MBS session, the first MRB identifier being associated with a first MRB for the MBS session; generating a radio resource control (RRC) reconfiguration message omitting the MRB release configuration including the first MRB identifier; and transmitting a handover request confirmation message including the RRC reconfiguration message to the network node.

[0168] Example 36. The method of Example 35, further comprising the step of transmitting MBS data to a user equipment (UE) via a second MRB of the MBS session before receiving the handover request message, the second MRB being associated with a second MRB identifier different from the first MRB identifier.

[0169] Example 37. The method of Example 36, further comprising: after sending the handover request confirmation message, sending MBS data to another UE via the second MRB.

[0170] Example 38. The method of any one of Examples 35-37, wherein the RAN node is a target base station for the handover and the network node is a source base station for the handover.

[0171] Example 39. The method of any one of Examples 35-37, wherein the RAN node is a target base station for handover and the network node is a core network (CN) node.

[0172] Example 40. A method for managing multicast and / or broadcast service (MBS) communications implemented by a radio access network (RAN) node, comprising: receiving a handover request message from a network node, the handover request message including a data radio bearer (DRB) identifier and an MBS radio bearer (MRB) identifier; generating a radio resource control (RRC) reconfiguration message including an MRB release configuration including the MRB identifier; transmitting the RRC reconfiguration message to a user equipment (UE) via the network node; and transmitting MBS data to the UE via the DRB associated with the DRB identifier.

[0173] Example 41. The method of example 40, wherein the step of sending an RRC reconfiguration message to the UE via the network node includes sending a handover request confirmation message to the network node that includes the RRC reconfiguration message.

[0174] Example 42. The method of example 40 or 41, wherein the RAN node is a target base station for the handover and the network node is a source base station for the handover.

[0175] Example 43. The method of example 40 or 41, wherein the RAN node is a target base station for handover and the network node is a core network (CN) node.

[0176] Example 44. A radio access network (RAN) node configured to implement the method of any one of Examples 23-43.

[0177] Example 45. A method for managing multicast and / or broadcast service (MBS) communications implemented by a network node, the method comprising: generating a list of one or more MBS session identifiers and one or more MBS radio bearer (MRB) identifiers, each of the one or more MBS session identifiers corresponding to a particular MRB identifier of the one or more MRB identifiers; and transmitting the list to a plurality of radio access network (RAN) nodes.

[0178] Example 46. The method of example 45, wherein the network node is a core network node.

[0179] Example 47. The method of example 45, wherein the network node is an operations, administration, and maintenance (OAM) node.

[0180] Example 48. The method of any one of Examples 45-47, wherein the multiple RAN nodes include multiple base stations.

[0181] Example 49. The method of any one of Examples 45-47, wherein the plurality of RAN nodes includes a plurality of central units (CUs) of a distributed base station.

[0182] Example 50. Any one of Examples 45-47, where the list is a mapping table.

[0183] Example 51. A network node configured to implement the method of any one of Examples 45-50.

[0184] Example 52. A method for determining a Multicast and / or Broadcast Service (MBS) Radio Bearer (MRB) identifier implemented by a Radio Access Network (RAN) node, comprising: obtaining a list of one or more MBS session identifiers and one or more MRB identifiers, each of the one or more MBS session identifiers corresponding to a particular MRB identifier of the one or more MRB identifiers; determining to configure resources for the particular MBS session identifier; determining a particular MRB identifier associated with the particular MBS session identifier based on the list; and transmitting an MRB configuration including the MRB identifier and the MBS session identifier to one or more user equipments (UEs).

[0185] Example 53. The method of example 52, wherein obtaining the list includes receiving the list from a network node.

[0186] Example 54. The method of example 53, wherein the network node is a core network node.

[0187] Example 55. The method of example 53, wherein the network node is an operations, administration, and maintenance (OAM) node.

[0188] Example 56. The method of any one of Examples 52-55, wherein the RAN node is a base station.

[0189] Example 57. The method of any one of Examples 52-55, wherein the RAN node is a central unit (CU) of a distributed base station.

[0190] Example 58. Any one of Examples 52 through 57, where the list is a mapping table.

[0191] Example 59. A radio access network (RAN) node configured to implement the method of any one of Examples 52-58.

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

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

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

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

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

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

[0198] 100 Wireless communication system 102, 102A, 102B UE 103UE 104 base station (BS), base station, BS, MeNB, Mng-eNB, MgNB 105 RAN 106 BS, base station, SgNB, Sng-eNB 110CN 111 Evolved 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 Controller 150 Processing Hardware 152 MBS Controller 154 Non-MBS Controller 160 5th Generation Core (5GC), 5GC 162 User Plane Function (UPF), UPF 164 Access and Mobility Management (AMF), AMF 166 Session Management Facility (SMF), SMF 172 CU 172A CU-CP 172B CU-UP 174 DU 200 Protocol Stack 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 Stack 300 Architecture 302A, 302B MBS Sessions 304A PDU Sessions 312A, 312B Tunnels 314A-1, 314A-2, 314A-N Radio Bearers 314A MRB 314B, 314B-1, 314B-2, 314B-N MRB Set of 316 flows 316A, 316B, 316L QoS Flows 322A UE-specific DL tunnel and / or UE-specific UL tunnel 324A-1, 324A-2, 324A-N DRB 400A Scenario 400B Scenario 402 Events 406 Events 412 Events 414 Events 416 Event, RRC reconfiguration message 418 Events 420 Events 422 Event and MBS Session Participation Procedures 424 Events, CN-BS messages 426 Events 428 Events 429 Events 430 Events 432 Events 434 Event, BS-CN message 436 Events 437 Events 438 Events 439 Events 490 PDU Session Establishment Procedures, Events, and Steps 492 MBS Transmission Procedures, Events, and Procedures 496 MBS Transmission Procedure 500A Scenario 500B Scenario 500C Scenario 500D Scenario 502 Events 503 RRC Reconfiguration Message 504 Event, Handover Request Confirmation Message 508 Random Access Procedure 512 Events 517 RRC Reconfiguration Message 522 MBS Session Participation Procedures, Events 523 MBS Session Participation Procedures, Events 590 PDU Session Establishment Procedure 591 PDU Session Establishment Procedure 592 MBS Transmission Procedure 593 MBS Transmission Procedure 594 MBS Transmission Procedures, Procedures 595 MBS Transmission Procedure 600 ways 700 methods 800 ways 900 methods 1000 ways 1100 methods 1200 methods

Claims

1. 1. A method for managing multicast and / or broadcast service (MBS) communications implemented by a Radio Access Network (RAN) node, comprising: receiving a handover request message from a network node, the handover request message including a first MBS Radio Bearer (MRB) identifier associated with a first MBS session; sending a handover request confirmation message to the network node, the handover request confirmation message including a Radio Resource Control (RRC) reconfiguration message, the RRC reconfiguration message indicating that the user equipment (UE) should release the first MRB and add a second MRB associated with a second MRB identifier; transmitting MBS data of the MBS session to the UE; A method comprising:

2. before receiving the handover request message, performing an MBS session participation procedure with a core network (CN) for another user equipment (UE) to participate in the MBS session; transmitting other MBS data of the MBS session to the other UE via the second MRB; The method of claim 1, further comprising:

3. After sending the handover request confirmation message and before sending the MBS data to the UE, performing a random access procedure with the UE.

3. The method of claim 2, further comprising:

4. The method of claim 1, wherein the RRC reconfiguration message includes an MRB release configuration including the first MRB identifier and an MRB configuration including the second MRB identifier.

5. After receiving the handover request message, determining that the first MRB identifier and the second MRB identifier have different values; generating the RRC reconfiguration message indicating that the UE should release the first MRB and add the second MRB based on the determining step; The method of claim 1, further comprising:

6. 2. The method of claim 1, wherein the RAN node is a target base station and the network node is a source base station.

7. 2. The method of claim 1, wherein the RAN node is a target base station and the network node is a core network (CN).

8. 1. A method for managing multicast and / or broadcast service (MBS) communications implemented by a network node, comprising: sending a handover request message to a radio access network (RAN) node, the handover request message including a first MBS radio bearer (MRB) identifier associated with a first MBS radio bearer (MRB) for the MBS session; receiving a handover request confirmation message from the RAN node, the handover request confirmation message including a Radio Resource Control (RRC) reconfiguration message, the RRC reconfiguration message indicating that a user equipment (UE) should release the first MRB and add a second MRB associated with a second MRB identifier; sending the RRC reconfiguration message to the UE; A method comprising:

9. before transmitting the handover request message, performing an MBS session participation procedure with a core network (CN) for the UE to participate in the MBS session; transmitting MBS data of the MBS session to the UE via the first MRB; 9. The method of claim 8, further comprising:

10. 9. The method of claim 8, wherein the network node is a source base station and the RAN node is a target base station.

11. The method of claim 8 , wherein the first MRB identifier is different from the second MRB identifier.

12. The method of claim 8, wherein the RRC reconfiguration message includes an MRB release configuration including the first MRB identifier and an MRB configuration including the second MRB identifier.

13. A network node configured to implement a method according to any one of claims 1 to 12.

14. 1. A method for managing multicast and / or broadcast service (MBS) communications implemented by a user equipment (UE), comprising: receiving MBS data of an MBS session from a first Radio Access Network (RAN) node via a first MBS Radio Bearer (MRB), the first MRB being associated with a first MRB identifier; receiving a radio resource control (RRC) reconfiguration message from the first RAN node, the RRC reconfiguration message including an MRB release configuration including a first MRB identifier and an MRB configuration including a second MRB identifier associated with a second MRB, the second MRB identifier being different from the first MRB identifier; Releasing the first MRB and adding the second MRB based on the RRC reconfiguration message; receiving other MBS data of the MBS session from a second RAN node via the second MRB; A method comprising:

15. Before receiving the MBS data, performing an MBS session join procedure with the first RAN node to join the MBS session.

15. The method of claim 14, further comprising:

16. after receiving the RRC reconfiguration message and before receiving the other MBS data; performing a random access procedure with the second RAN node.

15. The method of claim 14, further comprising:

17. A user equipment (UE) configured to implement a method according to any one of claims 14 to 16.

Images