Multicast and broadcast service activation and transmission management

Abstract

To provide techniques for management of multicast and broadcast service activation and transmission.SOLUTION: In order to manage a multicast and / or broadcast service (MBS) with a radio access network (RAN), a core network (CN) receives (702), from an MBS network, an interface message associated with an MBS session identifier, and in response to receiving: (I) sending 706, to the RAN, a first CN-to-BS message to request an activation notification for the multicast session corresponding to the MBS session identifier, or (ii) sending 708, to the RAN, a second CN-to-BS message to request an activation notification for the broadcast session corresponding to the MBS session identifier.SELECTED DRAWING: Figure 1A

Description

[Technical Field]

[0001] The present disclosure relates to wireless communications, and more particularly to activating transmission and / or reception of one or more multicast and / or broadcast services (MBS). [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 art 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 telecommunications 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 layer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) air interface (see 3GPP® specification TS 36.323) and New Radio (NR) (see 3GPP specification TS 38.323) provides protocol data unit (PDU) sequencing in the uplink direction (from a user device, also known as user equipment (UE), to a base station) and in the downlink direction (from a base station to a UE). Additionally, the PDCP sublayer provides services for signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer. The PDCP sublayer also provides services for data radio bearers (DRBs) to the Service Data Adaptation Protocol (SDAP) sublayer or protocol layers such as the Internet Protocol (IP) layer, the Ethernet protocol layer, and the Internet Control Message Protocol (ICMP) layer. Generally, the UE and the base station may use SRBs to exchange RRC messages and non-access stratum (NAS) messages, and may use DRBs to transport data on the user plane.

[0004] Base stations operating in accordance with fifth-generation (5G) New Radio (NR) requirements support significantly larger bandwidths than fourth-generation (4G) base stations. Accordingly, the Third Generation Partnership Project (3GPP) proposes in Release 15 that user equipment units (UEs) support 100 MHz bandwidths in Frequency Range 1 (FR1) and 400 MHz bandwidths in Frequency Range 2 (FR2). Due to the relatively wide bandwidths of typical carriers, 3GPP proposes in Release 17 that 5G NR base stations can provide UEs with multicast and / or broadcast services (MBS), which can be useful in many content distribution applications, such as transparent IPv4 / IPv6 multicast distribution, IPTV, software distribution over wireless, group communications, IoT applications, V2X applications, and emergency messages related to public safety.

[0005] To provide multicast and / or broadcast services (MBS), a base station can configure multiple UEs with common frequency resources (CFRs) and a PDCCH configuration that configures a group-common physical downlink control channel (PDCCH). The base station can assign group-common radio network temporary identifiers (RNTIs) to these UEs to receive physical downlink shared channel (PDSCH) transmissions that include MBS data packets. The base station can then send downlink control information (DCI) with a cyclic redundancy check (CRC) scrambled by the group-common RNTI on the group-common PDCCH to schedule PDSCH transmissions that include MBS data packets.

[0006] However, it is unclear how the core network (CN) notifies the RAN of MBS activation, and furthermore, it is unclear how the RAN decides whether to allocate multicast or broadcast resources for the MBS. [Prior art documents] [Non-patent literature]

[0007] [Non-Patent Document 1] 3GPP specification TS 36.323 [Non-patent document 2] 3GPP specification TS 38.323 [Non-patent document 3] 3GPP Specification 38.413 Summary of the Invention [Means for solving the problem]

[0008] A radio access network (RAN) and / or a core network (CN) may implement the techniques of this disclosure for managing MBS activation and transmission. Initially, the MBS network sends an interface message to the CN to activate an MBS session with a UE operating in an idle or inactive state. In response, the CN sends a message to the RAN to establish the MBS session. Depending on the content of the interface message, the CN may send a message to the RAN for a specific purpose. In some implementations, if the interface message indicates that radio resources for the MBS session should be configured, the CN may send a message that causes the RAN to configure radio resources for the MBS session. In other implementations, if the interface message indicates that a notification to activate reception of the MBS session at the UE should be sent to the UE, the CN may send a message that causes the RAN to send a notification to the UE.

[0009] An exemplary embodiment of these techniques is a method in a CN for managing an MBS with a RAN, the method including receiving, from an MBS network, an interface message associated with an MBS session identifier, and, in response to the receiving, performing one of the following steps: sending, to the RAN, a first CN-to-BS message to request activation notification for a multicast session corresponding to the MBS session identifier; or sending, to the RAN, a second CN-to-BS message to request activation notification for a broadcast session corresponding to the MBS session identifier.

[0010] Another exemplary embodiment of these techniques is a CN comprising one or more computing devices and configured to implement the above methods.

[0011] Another example embodiment of these techniques is a method in a RAN node for managing an MBS, the method including receiving, from a CN, a CN-to-BS message that includes an MBS session identifier, and performing one of the following steps: performing one or more procedures to transition a plurality of user equipment units (UEs) to a connected state when the CN-to-BS message requests activation notification for a multicast session that corresponds to the MBS session identifier; or broadcasting an MBS resource configuration to a plurality of UEs, including refraining from transitioning the plurality of UEs to the connected state when the CN-to-BS message requests activation notification for a broadcast session that corresponds to the MBS session identifier.

[0012] Yet another exemplary embodiment of these techniques is a RAN node comprising one or more processors and configured to implement the above methods. [Brief explanation of the drawings]

[0013] [Figure 1A]FIG. 1 is a block diagram of an example wireless communication system in which the RAN and / or UE implement the techniques of this disclosure for managing the transmission and reception of MBSs. [Figure 1B] 1B is a block diagram of an exemplary base station including a central unit (CU) and a distributed unit (DU) capable of operating in the system of FIG. 1A. [Figure 2] 1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A communicates with a base station. [Figure 3A] 10 is an example message sequence for a base station to manage activation and transmission of an MBS session for one or more UEs operating in an idle or inactive state. [Figure 3B] 3B is an exemplary message sequence similar to that of FIG. 3A, but in which a base station sends a paging message to one or more UEs instead of a multicast control channel (MCCH) message. [Figure 4A] 3B, but in which one or more UEs transition from an idle state to a connected state to receive an MBS session. [Figure 4B] 4B is an exemplary message sequence similar to that of FIG. 4A, but in which one or more UEs transition from an inactive state to a connected state to receive an MBS session. [Figure 5A] FIG. 1C is a flow diagram of an example method by which the RAN node of FIG. 1A or FIG. 1B manages transmission of MBSs to one or more UEs operating in a connected state based on whether a message from the CN requests resources for a multicast session or a broadcast session. [Figure 5B]FIG. 5B is a flow diagram of an example method similar to that of FIG. 5A, but in which a RAN node manages transmission of an MBS based on whether the MBS session ID included in the message is associated with a multicast session or a broadcast session. [Figure 5C] FIG. 5B is a flow diagram of an example method similar to that of FIG. 5A, but in which a RAN node manages transmission of an MBS based on the value of an MBS Session ID. [Figure 5D] FIG. 5B is a flow diagram of an example method similar to that of FIG. 5A, but in which the RAN node manages transmission of MBSs based on whether the message requests an activation notification for a multicast session or a broadcast session. [Figure 6A] FIG. 1C is a flow diagram of an example method by which the RAN node of FIG. 1A or FIG. 1B manages activation of an MBS for one or more UEs based on whether a message from the CN requests resources for a multicast session or a broadcast session. [Figure 6B] FIG. 6B is a flow diagram of an example method similar to that of FIG. 6A, but in which a RAN node manages activation of an MBS based on whether the MBS session ID included in the message is associated with a multicast session or a broadcast session. [Figure 6C] FIG. 6B is a flow diagram of an example method similar to that of FIG. 6A, but in which the RAN node manages activation of an MBS based on the value of an MBS Session ID. [Figure 6D] FIG. 6B is a flow diagram of an example method similar to that of FIG. 6A, but in which the RAN node manages activation of an MBS based on whether the message requests activation notification for a multicast session or a broadcast session. [Figure 7A]FIG. 1B is a flow diagram of an example method in which the CN of FIG. 1A manages activation of an MBS for one or more UEs based on whether a message from the MBS network requests resources for a multicast session or a broadcast session. [Figure 7B] FIG. 7B is a flow diagram of an example method similar to that of FIG. 7A, but in which the CN manages activation of the MBS based on the value of the MBS Session ID included in the message. [Figure 7C] 7B is a flow diagram of an example method similar to that of FIG. 7A, but in which the CN manages activation of an MBS based on whether the QoS profile included in the message indicates a multicast or broadcast session. [Figure 8A] 1B is a flow diagram of an example method by which the CN of FIG. 1A configures resources for an MBS based on whether a message from the MBS network requests resources for a multicast session or a broadcast session. [Figure 8B] 8B is a flow diagram of an example method similar to that of FIG. 8A, but in which the CN configures resources for the MBS based on the value of the MBS Session ID included in the message. [Figure 8C] 8B is a flow diagram of an example method similar to that of FIG. 8A, but in which the CN configures resources for an MBS based on whether the QoS profile included in the message indicates a multicast or broadcast session. [Figure 9] FIG. 1C is a flow diagram of an example method by which the RAN node of FIG. 1A or FIG. 1B manages MBS with a UE. [Figure 10] FIG. 1B is a flow diagram of an exemplary method for the CN of FIG. 1A to manage MBS with the RAN. DETAILED DESCRIPTION OF THE INVENTION

[0014] Generally, the techniques of this disclosure enable UEs to receive MBS information via radio resources allocated by a base station of a RAN. To this end, the base station can configure different radio resources in one or more overlapping cells to multicast or broadcast MBS data (and associated control information) and / or unicast non-MBS data (and associated control information) to one or more UEs on the downlink (DL). Note that "transmitting" by a base station can interchangeably refer to "multicasting," "broadcasting," and / or "unicasting." The base station can also unicast MBS data (and associated control information) to the UEs on a dedicated DRB for the UE. One or more UEs can transmit non-MBS data to the base station on the uplink (UL).

[0015] Thus, a base station of the present disclosure can configure one or more radio bearers for transmitting MBS information (i.e., MBS data packets and / or control information) to a UE. The radio bearer carrying the MBS information to the UE can be a unicast DRB (i.e., a dedicated DRB for the UE) or a multicast DRB (i.e., a DRB that can be shared by multiple UEs, also referred to as an MBS radio bearer or MRB). For example, the base station can send unicast or multicast configuration parameters to the UE to configure the UE to receive MBS information via a unicast or multicast DRB, respectively. As used in this disclosure, the term DRB can refer to a unicast or multicast DRB unless otherwise specified.

[0016] 1A illustrates an example wireless communication system 100 in which the MBS operation techniques of the present disclosure can be implemented. The wireless communication system 100 includes a UE 102A and a UE 102B, as well as base stations 104, 106A, and 106B of a radio access network (RAN) (e.g., RAN 105) connected to a core network (CN) 110. For ease of reading, the UE 102 is used herein to represent the UE 102A, the UE 102B, or both the UE 102A and the UE 102B, unless otherwise specified. The base stations 104, 106A, and 106B 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), a 5G Node B (gNB), or a 6G base station. As a more specific example, the base station 104 may be an eNB or a gNB, and the base stations 106A and 106B may be gNBs.

[0017] Base station 104 supports cell 124, base station 106A supports cell 126A, and base station 106B supports cell 126B. Cell 124 partially overlaps with both cells 126A and 126B, such that UE 102 can be within range to communicate with base station 104 while simultaneously being within range to communicate with either base station 106A or 106B (or within range to detect or measure signals from both base stations 106A and 106B). The overlap can enable, for example, UE 102 to handover between cells (e.g., from cell 124 to cell 126A or 126B) or between base stations (e.g., from base station 104 to base station 106A or 106B) before UE 102 experiences a radio link failure. Additionally, the overlap can enable UE 102 to operate with dual connectivity (DC) with RAN 105. For example, the UE 102 may communicate in DC with the base station 104 (acting as a master node (MN)) and the base station 106A (acting as a secondary node (SN)), and after a handover to the base station 106B is completed, the UE 102 may communicate with the base station 106B (acting as an MN). As another example, the UE 102 may communicate in DC with the base station 104 (acting as an MN) and the base station 106A (acting as an SN), and after a SN change is completed, the UE 102 may communicate with the base station 104 (acting as an MN) and the base station 106B (acting as an SN).

[0018] More specifically, when the UE 102 is in DC with the base station 104 and the base station 106A, 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 106A operates as a secondary gNB (SgNB) or a secondary ng-eNB (Sng-eNB).

[0019] In non-MBS (i.e., unicast) operation, the UE 102 may use radio bearers (e.g., DRBs or SRBs) that terminate at the MN (e.g., base station 104) or SN (e.g., base station 106) at different times. For example, after a handover or SN change to base station 106B, the UE 102 may use radio bearers (e.g., DRBs or SRBs) that terminate at the base station 106B at different times. The UE 102 may apply one or more security keys when communicating on a radio bearer in the uplink (UL) direction (i.e., from the UE 102 to the base station) and / or the downlink (DL) direction (i.e., from the base station to the UE 102). In non-MBS operation, the UE 102 transmits data to a base station via a radio bearer on (i.e., within) the uplink BWP of a cell and / or receives data from a base station via a radio bearer on (i.e., within) the DL BWP of a 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 102 can receive paging, system information, public alert messages, or random access responses over the DL BWP. In such non-MBS operation, the UE 102 can be in a connected state. Alternatively, if the UE 102 supports small data transmission in the idle or inactive state, the UE 102 can be in an idle or inactive state.

[0020] In MBS operation, the UE 102 may use a radio bearer (e.g., a DRB or an MRB) that terminates at the MN (e.g., the base station 104) or the SN (e.g., the base station 106A) at different times. For example, after a handover or SN change to the base station 106B, the UE 102 may use a radio bearer (e.g., a DRB or an MRB) that terminates at the base station 106B, which may be the MN or the SN, at different times. The base station may utilize the radio bearer to transmit application-level messages, such as security keys, to the UE 102. In some implementations, the base station (e.g., the MN or the SN) may transmit MBS data to the UE 102 (e.g., via a DRB or an MRB) over dedicated radio resources (i.e., radio resources dedicated to the UE 102). In such implementations, the base station may apply one or more security keys to protect the integrity of the MBS data and / or encrypt the MBS data and transmit the encrypted and / or integrity-protected MBS data to the UE 102 over the dedicated radio resources. Correspondingly, when the UE 102 receives the MBS data on a radio bearer in the downlink direction (from the base station to the UE 102), it can apply one or more security keys to decode the MBS data and / or check the integrity of the MBS data. In other implementations, the base station (e.g., the MN or the SN) can transmit the MBS data from the base station to the UE 102 (e.g., via a DRB or MRB) via a common radio resource (i.e., a radio resource common to the UE 102 and other UEs, such as a common frequency resource (CFR)) or a DL BWP of the cell. The DL BWP can be an initial DL BWP, a dedicated DL BWP, or an MBS DL BWP (i.e., a DL BWP specific to the MBS rather than unicast). In such implementations, the base station can refrain from applying security keys to the MBS data and transmit the MBS data on the radio bearer. Correspondingly, the UE 102 can omit applying security keys to the MBS data received on the radio bearer.The UE 102 may apply the application level security key received from the CN 110 or the MBS server to the MBS data received on the radio bearer.

[0021] 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 the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 130 in the example implementation of FIG. 1A includes a base station MBS controller 132 configured to manage or control transmission of MBS information received from the CN 110 or edge server. For example, the base station MBS controller 132 may be configured to support radio resource control (RRC) configurations, procedures, and messaging associated with MBS procedures, as discussed below, and / or to support required operations (e.g., MBS activation notification). The processing hardware 130 may include a base station non-MBS controller 134 configured to manage or control one or more RRC configurations and / or RRC procedures when the base station 104 operates as an MN or SN during non-MBS operation.

[0022] The base station 106A includes processing hardware 140, which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory storing 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 a base station MBS controller 142 configured to manage or control transmission of MBS information received from the CN 110 or edge server. For example, the base station MBS controller 142 may be configured to support RRC configurations, procedures, and messaging associated with MBS procedures and / or to support necessary operations (e.g., MBS activation notification), as discussed below. The processing hardware 140 may include a base station non-MBS controller 144 configured to manage or control one or more RRC configurations and / or RRC procedures when the base station 106A operates as an MN or SN during non-MBS operation. Although not shown in FIG. 1A, the base station 106B may include processing hardware similar to the processing hardware 130 of the base station 104 or the processing hardware 140 of the base station 106A.

[0023] The UE 102 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 special-purpose processing units. The processing hardware 150 in the example implementation of FIG. 1A includes a UE MBS controller 152 configured to manage or control reception of MBS information. For example, the UE MBS controller 152 may be configured to support RRC configurations, procedures, and messaging associated with MBS procedures and / or to support necessary operations (e.g., MBS activation notification), as discussed below. The processing hardware 150 may include a UE non-MBS controller 154 configured to manage or control one or more RRC configurations and / or RRC procedures according to any of the implementations discussed below when the UE 102 communicates with the MN and / or SN during non-MBS operation.

[0024] The CN 110 can 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 can 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 air interface and an NG interface for communicating with the 5GC 160. The base station 106A can be a 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 air interface and an NG interface to the 5GC 160, or an ng-eNB supporting an EUTRA air interface and an NG interface to the 5GC 160. The base stations 104, 106A, and 106B can support an X2 or Xn interface to directly exchange messages with each other during the scenarios discussed below.

[0025] 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 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 configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions. 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 configure MBS sessions or PDU sessions for MBS for the UE 102. 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 unicast services and MBS, or for MBS only.

[0026] In general, the wireless communication network 100 may include any suitable number of base stations supporting NR and / or EUTRA cells. More particularly, the EPC 111 or 5GC 160 may be connected to any suitable number of base stations supporting NR and / or EUTRA cells. While the following examples refer specifically to particular 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 technologies, such as, for example, sixth-generation (6G) radio access and / or a 6G core network or a 5G NR-6G DC.

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

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

[0029] 1A , the CN 110 communicatively connects the UE 102 to the MBS network 170 via the RAN 105. The MBS network 170 can provide multicast and / or broadcast services (MBS) to the UE 102, which can be useful in many content distribution applications, such as transparent IPv4 / IPv6 multicast distribution, IPTV, software distribution over wireless, group communications, IoT applications, V2X applications, and emergency messages related to public safety. To this end, entities (e.g., servers or groups of servers) operating in the MBS network 170 support packet exchanges with the UE. The packets can carry signaling (such as Session Initiation Protocol (SIP) messages, IP messages, or other suitable messages) as well as data (or “media”) such as text messages, audio, and / or video.

[0030] 1B illustrates an exemplary distributed implementation of any one or more of the base stations 104, 106A, 106B. In this implementation, the base station 104, 106A, or 106B includes 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 processor(s), and / or dedicated processing units. For example, the CU 172 may include processing hardware 130 or 140 of FIG. 1A.

[0031] Each of the DUs 174 also includes processing hardware that may include one or more general-purpose processors (e.g., CPUs), computer-readable memory that stores machine-readable instructions executable on the 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 106A) operates as an MN or SN. The processing hardware may also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0032] In some implementations, the CU 172 may include a logical node CU-CP 172A that hosts a control plane portion of a Packet Data Convergence Protocol (PDCP) protocol for the CU 172 and / or a Radio Resource Control (RRC) protocol for the CU 172. The CU 172 may also include a logical node CU-UP 172B that hosts a user plane portion of the PDCP protocol and / or a Service Data Adaptation Protocol (SDAP) protocol for 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.

[0033] 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 102. 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 DUs 174 is established by the CU-CP 172A using a bearer context management function.

[0034] FIG. 2 illustrates in a simplified manner an exemplary protocol stack 200 according to which a UE 102 can communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106A, 106B).

[0035] In the example stack 200, a EUTRA physical layer (PHY) 202A provides transport channels to a EUTRA MAC sublayer 204A, which provides logical channels to a EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A provides RLC channels to a EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, a NR PHY 202B provides transport channels to an NR MAC sublayer 204B, which provides logical channels to an NR RLC sublayer 206B. The NR RLC sublayer 206B provides RLC channels to the NR PDCP sublayer 210. In some implementations, a UE 102 supports both EUTRA and NR stacks as shown in FIG. 2 to support handover between EUTRA and NR base stations and / or to support DC over EUTRA and NR interfaces. Additionally, as shown in FIG. 2, the UE 102 may support layering of an NR PDCP sublayer 210 on the EUTRA RLC sublayer 206A, and an SDAP sublayer 212 on the NR PDCP sublayer 210.

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

[0037] On the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide SRBs to exchange, for example, 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 SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0038] In a scenario in which the UE 102 operates in EN-DC with the base station 104 acting as an MeNB and the base station 106A acting as an SgNB, the wireless communication system 100 may provide the UE 102 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 102 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.

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

[0040] To simplify the following description, UE 102 represents UE 102A and UE 102B unless explicitly stated otherwise.

[0041] 3A-4B are messaging diagrams of example scenarios in which one or more UEs, a RAN, a CN, and an MBS network implement techniques of the present disclosure for managing MBS transmission and reception. Generally, events in FIGS. 3A-4B that are similar are labeled with like reference numbers, and differences are discussed below, where appropriate. Except for the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to particular events (e.g., for messaging and processing) may be applied to events labeled with like reference numbers in the other figures.

[0042] Referring now to scenario 300A shown in FIG. 3A , UE 102 (e.g., UE 102A and / or UE 102B) initially operates in an idle state (e.g., RRC_IDLE state) or an inactive state (e.g., RRC_INACTIVE state) with RAN 105 (302). In the following description, RAN 105 may include base station 104, base station 106, cell 124 of base station 104, and / or cell 126 of base station 106. For example, UE 102 operating in the idle or inactive state camps on cell 124 of base station 104 of RAN 105. MBS network 170 sends an MBS session initiation message (sometimes referred to as an “MBS session initiation request message”) to CN 110 (e.g., AMF 164) to request activation of an MBS session (304). MBS network 170 includes an MBS session ID, which identifies the MBS session, in the MBS session initiation message. In some implementations, the MBS session ID is allocated by the CN 110. In other implementations, the MBS session ID is allocated by the MBS network 170. In some implementations, the MBS session ID includes or is a Temporary Mobile Group Identity (TMGI). In other implementations, the MBS session ID is associated with a TMGI.

[0043] In response to the MBS session start message, the CN 110 can notify the UE of the activation of the MBS session. To notify the UE of the MBS session activation, the CN 110 generates a CN-to-BS message including the MBS session ID and sends the CN-to-BS message to the RAN 105 (306). In some implementations, the CN-to-BS message can be an existing message defined in 3GPP specification 38.413 or a new Next Generation Application Protocol (NGAP) message (defined specifically for the purpose of notifying the UE of the MBS session activation). For example, the existing NGAP message can be an NGAP paging message. In another example, the new NGAP message can be an MBS session notification request, an MBS session notification message, or an MBS session activation notification message. In other implementations, the CN-to-BS message can be a 6G Application Protocol (6GAP) message.

[0044] Upon receiving the CN-to-BS message (306), the RAN 105 extracts the MBS session ID from the CN-to-BS message and generates a message including the MBS session ID to be transmitted on a (first) multicast control channel (MCCH) (i.e., hereinafter referred to as an MCCH message). The RAN 105 then transmits the MCCH message on radio resources (i.e., via broadcast) (308), for example, in the cell 124. In some implementations, the RAN 105 generates a DCI and generates a CRC of the DCI based on the DCI to transmit the MCCH message. The RAN 105 scrambles the CRC with a specific Radio Network Temporary Identifier (RNTI). For example, the RNTI can be an MCCH-RNTI or an MBS-RNTI. The RAN 105 can broadcast system information (e.g., a System Information Block (SIB)), for example, in the cell 124. The RAN 105 can include a downlink assignment in the DCI indicating radio resources for transmission of the MCCH message. The RAN 105 transmits the DCI and scrambled CRC on the PDCCH to the UE 102, and can then transmit the MCCH message on the indicated radio resources. When the UE 102 receives the DCI and scrambled CRC on the PDCCH, the UE 102 verifies the scrambled CRC using the RNTI. If the UE 102 verifies that the scrambled CRC is valid, the UE 102 receives or attempts to receive the MCCH message on the radio resources according to the DCI (308). In other implementations, the RAN 105 does not transmit DCI to allocate radio resources for transmitting the MCCH message. Instead, the RAN 105 can broadcast system information (e.g., SIBs) including the configuration of radio resources, for example, over the cell 124.

[0045] Events 304 , 306 and 308 collectively define an MBS session activation notification procedure 390 .

[0046] After receiving (304) the MBS session start message, the CN 110 may send (310) to the RAN 105 an MBS resource setup request message (e.g., an MBS session resource setup request message) including the MBS session ID to request the RAN 105 to allocate resources on the air interface (e.g., Uu) and resources on the network interface (e.g., NG-U) between the RAN 105 and the CN 110 for the MBS session identified by the MBS session ID. In some implementations, the CN 110 may include a quality of service (QoS) profile in the MBS resource setup request message to indicate QoS parameters associated with the MBS session. In some implementations, the CN 110 sends the MBS resource setup request message in response to receiving the MBS session start message. In one implementation, the CN 110 sends the MBS resource setup request message after sending (306) the CN-to-BS message. In another implementation, the CN 110 sends the MBS resource setup request message before sending (306) the CN-to-BS message.

[0047] In response to the MBS session resource setup message, the RAN 105 may allocate radio resources for broadcasting data for the MBS session and transmit (312) an MBS resource setup response message (e.g., an MBS session resource setup response message) to the CN 110. The radio resources include time resources (e.g., time slots or OFDM symbols) and / or frequency resources (e.g., resource blocks) for one or more control channels and / or one or more data channels. The RAN 105 may broadcast (316), for example, over the cell 124, an MBS resource configuration to indicate or configure the radio resources. The RAN 105 may transmit a PDSCH transmission including the MBS data packet in accordance with the MBS resource configuration. For example, the MBS resource configuration includes a PDCCH configuration, a search space configuration, and / or a control resource set (CORESET) configuration. The RAN 105 may send downlink control information (DCI) having a cyclic redundancy check (CRC) scrambled by the RNTI (e.g., a group RNTI or an MBS RNTI) on the PDCCH to schedule PDSCH transmissions including MBS data packets in accordance with the PDCCH configuration, search space configuration, and / or CORESET configuration. In another example, the MBS resource configuration may include a modulation and coding scheme (MCS), repetition, and / or hybrid automatic repeat request (HARQ) transmission scheme for broadcasting data for the MBS session. The RAN 105 may transmit PDSCH transmissions including MBS data packets in accordance with the configured MCS, repetition, and / or HARQ transmission scheme. In some implementations, the RAN 105 may broadcast (316) system information including the MBS resource configuration on a broadcast control channel (BCCH), for example, in the cell 124. In other implementations, the RAN 105 may broadcast 316 the MBS resource configuration on the first MCCH or the second MCCH, for example, over the cell 124.The CN 110 may send (314) an MBS session start acknowledgement message to the MBS network 170 in response to the MBS session start message. In some implementations, the CN 110 may send the MBS session start acknowledgement message after receiving the MBS resource setup response message. In other implementations, the CN 110 may send the MBS session acknowledgement message to the MBS network regardless of whether the MBS resource setup response message is received.

[0048] Events 310 and 312 collectively define an MBS resource setup procedure 392 .

[0049] After sending the MBS session start message or receiving the MBS session start acknowledgement message, the MBS network 170 can transmit (318) MBS data (e.g., one or more MBS data packets) for the MBS session to the CN 110, which transmits (320) the MBS data to the RAN 105. The RAN 105 then broadcasts (322) the MBS data on radio resources configured by the MBS resource configuration, e.g., over the cell 124.

[0050] After or in response to receiving 308 the MCCH message, the UE 102 in an idle or inactive state activates (e.g., starts) reception of the MBS session identified by the MBS session ID (318). The UE 102 receives 322 the MBS data according to the MBS resource configuration. For example, the UE 102 receives 322 one or more DL transmissions including the MBS data on radio resources configured by the MBS configuration and decodes 322 the DL transmissions according to the MCS to obtain the MBS data.

[0051] Events 318 , 320 , and 322 collectively define an MBS data transmission procedure 394 .

[0052] Referring to FIG. 3B, scenario 300B is similar to scenario 300A, except that instead of transmitting an MCCH message (308) to notify the activation of the MBS session, the RAN 105 transmits a paging message including an MBS session ID (307). The RAN 105 may transmit the paging message on a paging control channel (PCCH). In some implementations, the RAN 105 may generate a DCI and a CRC of the DCI from the DCI and transmit the paging message. The RAN 105 scrambles the CRC with a paging radio network temporary identifier (P-RNTI). The RAN 105 may include a downlink assignment in the DCI indicating radio resources for transmission of the paging message. The RAN 105 may transmit the DCI and the scrambled CRC on a PDCCH to the UE 102 over the cell 124 and transmit the paging message on the indicated radio resources. When the UE 102 receives the DCI and scrambled CRC on the PDCCH, the UE 102 verifies the scrambled CRC using the P-RNTI. If the UE 102 verifies that the scrambled CRC is valid, the UE 102 receives or attempts to receive (307) a paging message on radio resources according to the DCI. After or in response to receiving (307) the paging message, the UE 102, which is in an idle or inactive state, activates (318) (e.g., starts) reception of the MBS session identified by the MBS session ID.

[0053] 4A and 4B are example message sequences similar to those of FIGS. 3A and 3B, but in which the UE 102 transitions from an inactive state and an idle state, respectively, to a connected state.

[0054] 4A , in scenario 400A, UE 102 initially operates in an idle state (402). While in the idle state, UE 102 receives an MBS activation notification message (i.e., an MCCH message or a paging message) in an MBS session activation notification procedure 490, which is similar to MBS session activation notification procedure 390 or 391. In some implementations, the MBS session ID in FIG. 4A identifies a multicast session, while the MBS session ID in FIGS. 3A and 3B identifies a broadcast session.

[0055] In response to the activation 490, the UE 102 performs an RRC connection establishment procedure with the RAN 105 (426). The UE 102 transitions to a connected state (e.g., an RRC_CONNECTED state) in response to the RRC connection establishment procedure (428). To perform the RRC connection establishment procedure (426), the UE 102 performs a random access procedure with the RAN 105 (424) to synchronize with the RAN 105 in uplink transmissions if the UE 102 is not uplink synchronized with the RAN 105 (i.e., the UE 102 does not have a valid timing advance command or value with the RAN 105). The random access procedure can be a two-step or four-step random access procedure. To perform the RRC connection establishment procedure (426), the UE 102 sends an RRC request message (e.g., an RRCSetupRequest message or an RRCConnectionRequest message) to the RAN 105. If the UE 102 performs 424 a two-step random access procedure, the UE 102 may transmit an RRC request message in message A of the two-step random access procedure. If the UE 102 performs 424 a four-step random access procedure, the UE 102 may transmit an RRC request message in message 3 of the four-step random access procedure. If the UE 102 is uplink synchronized with the RAN 105 and has a configuration grant configuration for the idle state, the UE 102 may skip or omit the random access procedure. In such a case, the UE 102 may transmit an RRC request message using the configuration grant configured by the configuration grant configuration. In response to the RRC request message, the RAN 105 may transmit an RRC response message (e.g., an RRCSetup message or an RRCConnectionSetup message) to the UE 102. In response, the UE 102 transitions 428 to a connected state and transmits an RRC completion message (e.g., an RRCSetupComplete message or an RRCConnectionSetupComplete message) to the RAN 105.In some implementations, the UE 102 configures a first SRB (e.g., SRB1) for communicating RRC messages with the RAN 105 in response to the RRC response message. In such implementations, the UE 102 transmits an RRC complete message to the RAN 105 via the first SRB. In some implementations, the UE 102 can send a service request message to the CN 110 via the RAN 105 after transitioning to the connected state (428). In one implementation, the UE 102 can include the service request message in the RRC complete message. The RAN 105 extracts the service request message from the RRC complete message and sends a first BS-to-CN message (e.g., an Initial UE Message message) including the service request message to the CN 110.

[0056] After performing 426 an RRC connection establishment procedure with the UE 102 or transitioning 428 to the connected state, the RAN 105 may perform 430 a security activation procedure (e.g., an RRC security mode procedure) with the UE 102 to activate security (e.g., integrity protection / integrity check and / or encryption / decryption) for communications with the UE 102. In particular, the RAN 105 may send a security activation command message (e.g., a SecurityModeCommand message) to the UE 102, e.g., via an SRB, to perform 430 the security activation procedure. In response, the UE 102 activates security (e.g., integrity protection and / or encryption) for communications with the RAN 105 and sends a security activation complete message (e.g., SecurityModeComplete) to the RAN 105, e.g., via an SRB. After activating security, the RAN 105 may perform an RRC reconfiguration (not shown in FIG. 4A ) with the UE 102 to configure a second SRB (e.g., SRB2) and / or a DRB for exchanging RRC and / or NAS messages with the UE 102.

[0057] After transitioning to the connected state (428) or after performing the security activation procedure (430), the UE 102 may perform (432) an MBS session join procedure (also referred to as an MBS session activation procedure or an MBS session establishment procedure) with the CN 110 via the RAN 105 to indicate that the UE 102 requests to join an MBS session. In some implementations, the UE 102 may do so (or determine to do so) if it does not have an MBS context for receiving the MBS session. If the UE 102 has an MBS context for receiving the MBS session before receiving the message including the MBS session ID in the MBS session activation notification procedure 490, the UE 102 may skip, omit, or refrain from performing the MBS session join procedure. To perform the MBS session join procedure (432), the UE 102 may send an MBS session join request message (also referred to as an MBS session activation request message or an MBS session establishment request message) to the CN 110 via the RAN 105. In response, the CN 110 can send an MBS session join accept message (also referred to as an MBS session activation accept message or an MBS session establishment accept message) to the UE 102 via the RAN 105. In some implementations, the UE 102 can perform the MBS session join procedure after activating security (430). Thus, the MBS session join procedure is protected by security. Upon receiving the MBS session join request message from the UE 102, the RAN 105 can send a second BS-to-CN message (e.g., an uplink NAS transport message) to the CN 110 that includes the MBS session join request message. In other implementations, the UE 102 can perform the MBS session join procedure after transitioning to the connected state (428) and before activating security. In one implementation, the UE 102 can include the MBS session join request message in an RRC complete message.The RAN 105 extracts the MBS session join request from the RRC complete message and sends a first BS-to-CN message containing the MBS session join request message to the CN 110. In this implementation, the UE 102 may decide not to send a service request message.

[0058] Alternatively, the UE 102 may perform the MBS session join procedure with the MBS network 170 via the CN 110 and the RAN 105, rather than the CN 110. In such a case, the CN 110 sends an MBS session join request message to the MBS network 170 and receives an MBS session join accept message from the MBS network 170, respectively.

[0059] In some implementations, the MBS context includes an MBS session ID. In further implementations, the MBS context can include a QoS profile for the MBS session, an IP address for the MBS session, and / or one or more MRB configurations that configure one or more MRBs.

[0060] In some implementations, the CN 110 can initiate an MBS resource setup procedure (492) in response to or after receiving the first BS-to-CN message or the second BS-to-CN message. In response to or after receiving the MBS resource setup request message, the RAN 105 can perform an RRC reconfiguration procedure (434) with the UE 102 to configure radio resources for the UE 102 to receive MBS data for the MBS session (494). To perform the RRC reconfiguration procedure (434), the RAN 105 sends an RRC reconfiguration message to the UE 102. The RAN 105 can include configuration parameters in the RRC reconfiguration message for the UE 102 to receive MBS data for the MBS session (494). In some implementations, the RAN 105 can set the configuration parameters according to a QoS profile. The UE 102 receives the MBS data in an MBS data transmission procedure 494 according to the configuration parameters. In some implementations, the configuration parameters may include physical layer configuration parameters, MAC configuration parameters, RLC configuration parameters, PDCP configuration parameters, SDAP configuration parameters, and / or MRB configuration parameters. The MRB configuration parameters may configure one or more MRBs associated with an MBS session.

[0061] In response to the RRC reconfiguration message, the UE 102 may send an RRC reconfiguration complete message to the RAN 105. After or in response to receiving the MBS resource setup request message, the RAN 105 may send an MBS resource setup response message to the CN 110. In some implementations, the RAN 105 may send the MBS resource setup response message to the CN 110 before or after receiving the RRC reconfiguration complete message. In other implementations, the CN 110 may perform (492) the MBS resource setup procedure with the RAN 105 before receiving the first BS-to-CN message or the second BS-to-CN message. In still other implementations, the CN 110 may perform (492) the MBS resource setup procedure with the RAN 105 regardless of whether it receives the first BS-to-CN message or performs an MBS session join procedure.

[0062] After receiving (414) the MBS session start acknowledgement message, the MBS network 170 may perform (494) an MBS data transmission procedure to send the MBS data to the UE 102. When the RAN 105 receives the MBS data from the CN 110 during the MBS data transmission procedure, the RAN 105 may transmit the MBS data to the UE 102 via multicast. After performing the RRC reconfiguration procedure, the UE 102 uses the configuration parameters to receive (322) the MBS data from the RAN 105. In some implementations, the RAN 105 may transmit the MBS data to the UE 102 via one or more MRBs, and the UE 102 may receive the MBS data via one or more MRBs.

[0063] 4B , scenario 400B is similar to scenario 400A, except that the UE 102 initially operates in an inactive state (e.g., RRC_INACTIVE) (403), and in response to receiving an MBS activation notification message, the UE 102 performs an RRC resumption procedure rather than an RRC connection establishment procedure. In some scenarios and implementations, before the UE 102 operated in the inactive state (403), the UE 102 was in a connected state with the RAN 105. A UE 102 in a connected state communicates data with the RAN 105, for example, via one or more radio bearers (RBs). In some implementations, a UE 102 in a connected state communicates control plane (CP) data via one or more signaling RBs (SRBs). In some implementations, a UE 102 in a connected state communicates user plane (UP) data via one or more data RBs (DRBs). After a period of data inactivity for the UE 102, the RAN 105 may determine that neither the RAN 105 nor the UE 102 has transmitted any data in the downlink or uplink direction, respectively, for the period of time. In response to the determination, the RAN 105 may send an RRC release message (e.g., an RRCRelease message or an RRCConnectionRelease message) to the UE 102 to instruct the UE 102 to transition to an inactive state. The UE 102 transitions to the inactive state upon receiving the RRC release message. The RAN 105 may assign an I-RNTI or a resumption ID to the UE 102 and include the assigned value in the RRC release message. In some embodiments, after the UE 102 transitions to the inactive state, the UE 102 may perform one or more RAN Notification Area (RNA) updates with the RAN 105 without a state transition.

[0064] In response to the activation 418, the UE 102 may perform (427) an RRC resumption procedure with the RAN 105. The UE 102 transitions (428) to a connected state (e.g., an RRC_CONNECTED state) in response to the RRC resumption procedure. To perform (427) the RRC resumption procedure, the UE 102 may perform (424) a random access procedure with the RAN 105, and synchronizes with the RAN 105 in uplink transmissions if the UE 102 is not uplink synchronized with the RAN 105 (i.e., the UE 102 does not have a valid timing advance command or value with the RAN 105). The random access procedure may be a two-step or four-step random access procedure. To perform (427) the RRC resumption procedure, the UE 102 sends an RRC request message (e.g., an RRCResumeRequest message or an RRCConnectionResumeRequest message) to the RAN 105. If the UE 102 performs 424 a two-step random access procedure, the UE 102 may send an RRC request message in message A of the two-step random access procedure. If the UE 102 performs 424 a four-step random access procedure, the UE 102 may send an RRC request message in message 3 of the four-step random access procedure. If the UE 102 is uplink synchronized with the RAN 105 and has a configuration grant configuration for the idle state, the UE 102 may skip or omit the random access procedure. In such a case, the UE 102 may send an RRC request message using the configuration grant configured by the configuration grant configuration. In response to the RRC request message, the RAN 105 may send an RRC response message (e.g., an RRCResume message or an RRCConnectionResume message) to the UE 102. In response, the UE 102 transitions 418 to a connected state and sends an RRC completion message (eg, an RRCResumeComplete message or an RRCConnectionResumeComplete message) to the RAN 105.In some implementations, the UE 102 operating in the inactive state (403) suspends the first SRB (e.g., SRB1), the second SRB, and / or one or more DRBs. In such implementations, the UE 102 resumes the first SRB to receive an RRC response message and sends an RRC completion message over the first SRB to the RAN 105 in response to or after transmitting an RRC request message. The UE 102 can resume the second SRB in response to the RRC response message. In some implementations, the UE 102 resumes one or more DRBs in response to the RRC response message if the RAN 105 does not indicate the release of the one or more DRBs. In some implementations, the UE 102 may not send a service request message to the CN 110 via the RAN 105 after transitioning to the connected state (428), unlike in FIG. 4A .

[0065] In some implementations, the UE 102 operating in an inactive state (403) has an MBS context for the MBS session as described with respect to FIG. 4A. The UE 102 in the inactive state suspends one or more MRBs in the MBS context. In such implementations, the UE 102 resumes one or more MRBs in response to an RRC response message if the RAN 105 does not indicate release of the one or more MRBs in the RRC response message.

[0066] In some implementations, the UE 102 in the MBS data transmission procedure 494 can receive MBS data of the MBS session (i.e., the first MBS session) via one, some, or all of the one or more MRBs that the UE 102 resumed in response to the RRC resume procedure. In such implementations, the UE 102 refrains from performing an MBS session join procedure for active reception of the MBS session. In other implementations, the UE 102 performs the MBS session join procedure (432) when the UE 102 does not have an MBS context for the MBS session. In some scenarios and implementations, the UE 102 may have an MBS context for the second MBS session and resume one or more MRBs for the second MBS session in response to the RRC resume procedure or an RRC response message. In such cases, the UE 102 cannot receive MBS data of the first MBS session via one or more MRBs of the MBS context for the second MBS session. Accordingly, the UE 102 performs an MBS session join procedure to cause the RAN 105 to perform an RRC reconfiguration procedure to configure radio resources for the UE 102 to receive MBS data for the first MBS session (434). The UE 102 receives the MBS data in an MBS data transmission procedure 494 according to the configuration parameters. In some implementations, the configuration parameters may include physical layer configuration parameters, MAC configuration parameters, RLC configuration parameters, PDCP configuration parameters, SDAP configuration parameters, and / or MRB configuration parameters.

[0067] 5A-6D are flow diagrams illustrating an example method that a RAN node (e.g., a base station 104, 106A, or 106B, or a CU 172) may implement to activate transmission of an MBS. FIG. 7A-8C are flow diagrams illustrating an example method that a CN (e.g., a CN 110) may implement to activate transmission of an MBS.

[0068] Like blocks in Figures 5A-5D are labeled with like reference numbers.

[0069] 5A is a flow diagram of an example method 500A for activating transmission of an MBS. In block 502, the RAN node receives a CN-to-BS message including an MBS session ID from the CN (e.g., events 306, 310, 490, 492). In block 504, the RAN node determines whether the CN-to-BS message requests resources for a multicast session or a broadcast session. If the CN-to-BS message requests resources for a multicast session, flow proceeds to blocks 506 and 508. In block 506, the RAN node performs one or more procedures with multiple UEs to transition the multiple UEs to a connected state (e.g., events 424, 426, 427, 428). In block 508, the RAN node transmits MBS data associated with the MBS session ID to multiple UEs operating in a connected state (e.g., event 494). If the CN-to-BS message requests resources for a broadcast session, flow proceeds to block 510. At block 510, the RAN node transmits MBS data associated with the MBS session ID to the multiple UEs without transitioning the multiple UEs to a connected state (eg, event 322).

[0070] In some implementations, the CN-to-BS message may include an indication indicating a multicast session for the MBS Session ID or a broadcast session for the MBS Session ID. If the indication indicates a multicast session for the MBS Session ID or the CN-to-BS message excludes an indication indicating a broadcast session for the MBS Session ID, the RAN node may determine that the CN-to-BS message requests resources for a multicast session. If the indication indicates a broadcast session or the CN-to-BS message excludes an indication indicating a multicast session for the MBS Session ID, the RAN node may determine that the CN-to-BS message requests resources for a broadcast session for the MBS Session ID.

[0071] In other implementations, the CN-to-BS message may include a QoS profile. The RAN node may determine that the CN-to-BS message requests resources for a multicast session for the MBS Session ID or a broadcast session for the MBS Session ID according to the QoS profile. If the QoS profile indicates a multicast session for the MBS Session ID, the RAN node may determine that the CN-to-BS message requests resources for a multicast session. If the QoS profile indicates a broadcast session, the RAN node may determine that the CN-to-BS message requests resources for a broadcast session for the MBS Session ID.

[0072] 5B is a flow diagram of an example method 500B for activating transmission of an MBS. In block 505, the RAN node determines whether the MBS session ID is associated with a multicast session or a broadcast session. If the MBS session ID is associated with a multicast session, flow proceeds to blocks 506 and 508. If the MBS session ID is associated with a broadcast session, flow proceeds to block 510.

[0073] 5C is a flow diagram of an example method 500C for activating transmission of an MBS. In block 503, the RAN node determines whether the MBS session ID is associated with a first MBS session ID or a second MBS session ID. If the MBS session ID is associated with the first MBS session ID, flow proceeds to blocks 506 and 508. If the MBS session ID is associated with a second MBS session ID, flow proceeds to block 510.

[0074] In some implementations, the first and second MBS Session IDs may be associated with a multicast session and a broadcast session, respectively. In other implementations, the first and second MBS Session IDs may be associated with a first MBS (session) and a second MBS (session), respectively, having different QoS requirements. For example, the first MBS (session) requires higher QoS requirements (e.g., more reliable transmission, a lower block error rate, less latency, and / or a higher data rate) than the second MBS (session). Therefore, the RAN node transitions multiple UEs to a connected state to provide the multiple UEs with configuration parameters for enforcing the QoS requirements for the first MBS.

[0075] 5D is a flow diagram of an example method 500D for activating transmission of an MBS. In block 514, the RAN node determines whether the CN-to-BS message requests an activation notification for a multicast session or a broadcast session. If the CN-to-BS message requests an activation notification for a multicast session, flow proceeds to blocks 506 and 508. If the CN-to-BS message requests an activation notification for a broadcast session, flow proceeds to block 510.

[0076] Blocks in Figures 6A-6D that are the same are labeled with the same reference numbers. The examples and implementations of Figures 5A-5D are applicable to Figures 6A-6D.

[0077] 6A is a flow diagram of an example method 600A for activating transmission of an MBS. In block 602, the RAN node receives a CN-to-BS message from the CN that includes an MBS session ID (e.g., events 306, 310, 490, 492). In block 604, the RAN node determines whether the CN-to-BS message requests resources for a multicast session or a broadcast session. If the CN-to-BS message requests resources for a multicast session, flow proceeds to block 606. In block 606, the RAN node transmits (e.g., via broadcast and / or on the PCCH) a paging message that includes the MBS session ID (e.g., event 307). If the CN-to-BS message requests resources for a broadcast session, flow proceeds to block 608. In block 608, the RAN node transmits (e.g., via broadcast) an MCCH message that includes the MBS session ID (e.g., event 308).

[0078] 6B is a flow diagram of an example method 600B for activating transmission of an MBS. In block 605, the RAN node determines whether the MBS session ID is associated with a multicast session or a broadcast session. If the MBS session ID is associated with a multicast session, flow proceeds to block 606. If the MBS session ID is associated with a broadcast session, flow proceeds to block 608.

[0079] 6C is a flow diagram of an example method 600C for activating transmission of an MBS. In block 603, the RAN node determines whether the MBS session ID is the first MBS session ID or the second MBS session ID. If the MBS session ID is the first MBS session ID, flow proceeds to block 606. If the MBS session ID is the second MBS session ID, flow proceeds to block 608.

[0080] In some implementations, the first and second MBS Session IDs may be associated with a multicast session and a broadcast session, respectively. In other implementations, the first and second MBS Session IDs may be associated with a first MBS (session) and a second MBS (session), respectively, having different QoS requirements. For example, the first MBS (session) requires higher QoS requirements (e.g., more reliable transmission, a lower block error rate, less latency, and / or a higher data rate) than the second MBS (session). Therefore, the RAN node transitions multiple UEs to a connected state to provide the multiple UEs with configuration parameters for enforcing the QoS requirements for the first MBS.

[0081] 6D is a flow diagram of an example method 600D for activating transmission of an MBS. In block 614, the RAN node determines whether the CN-to-BS message requests an activation notification for a multicast session or a broadcast session. If the CN-to-BS message requests an activation notification for a multicast session, flow proceeds to block 606. If the CN-to-BS message requests an activation notification for a broadcast session, flow proceeds to block 608.

[0082] Blocks in Figures 7A-7C that are the same are labeled with the same reference numbers.

[0083] 7A is a flow diagram of an example method 700A for activating transmission of an MBS. In block 702, the CN receives an interface message from the MBS network (e.g., events 304, 490). In block 704, the CN determines whether the interface message requests resources for a multicast session for the MBS Session ID or for a broadcast session for the MBS Session ID. If the interface message requests resources for a multicast session, flow proceeds to block 706. If the interface message requests resources for a broadcast session, flow proceeds to block 708. In block 706, the CN sends a first CN-to-BS message to the first RAN to request a multicast activation notification for the MBS Session ID (e.g., event 490). In block 708, the CN sends a second CN-to-BS message to the second RAN to request a broadcast activation notification for the MBS Session ID (e.g., event 306).

[0084] In some implementations, the first RAN and the second RAN can be the same RAN. In other implementations, the first RAN and the second RAN can be different RANs. For example, one of the first and second RANs can be an E-UTRAN, and the other can be an NG-RAN. In still other implementations, the first and second RANs can each include at least one first RAN node and at least one second RAN node. In one implementation, the at least one first RAN node and the at least one second RAN node can include one or more identical RAN nodes. In another implementation, the at least one first RAN node and the at least one second RAN node include completely different RAN nodes. The RAN nodes can include one or more base stations, CUs, and / or DUs operated by the same or different CUs. In some implementations, the CN can determine the at least one first RAN node according to the first MBS context and the at least one second RAN node according to the second MBS context, respectively. In some implementations, the first MBS context may include at least one first area identification (e.g., a tracking area identification or an MBS area identification). The CN can determine or derive the at least one first RAN node from the at least one first area identification. In other implementations, the first MBS context may include a first list of identifications of the at least one first RAN node. In some implementations, the second MBS context may include at least one second area identification (e.g., a tracking area identification or an MBS area identification). The CN can determine or derive the at least one second RAN node from the at least one second area identification. The at least one first area identification and the at least one second area identification include the same or different area identifications. In other implementations, the second MBS context may include a second list of identifications of the at least one second RAN node.The first and second lists may contain the same or different identifying information.

[0085] In some implementations, the first and second CN-to-BS messages can be the same message (e.g., NGAP messages) with different content, while in other implementations, the first and second CN-to-BS messages can be different messages (e.g., NGAP messages).

[0086] In some implementations, the first CN-to-BS message can include an indication indicating a multicast session for the MBS Session ID or excludes an indication indicating a broadcast session for the MBS Session ID. In some implementations, the second CN-to-BS message can include an indication indicating a broadcast session for the MBS Session ID or excludes an indication indicating a multicast session for the MBS Session ID.

[0087] In some implementations, the first CN-to-BS message can include a first QoS profile for the multicast session, and the second CN-to-BS message can include a second QoS profile for the broadcast session.

[0088] 7B is a flow diagram of an example method 700B for activating transmission of an MBS. In block 703, the CN determines whether the MBS session ID is associated with a multicast session or a broadcast session. If the MBS session ID is associated with a multicast session, flow proceeds to block 706. If the interface message requests resources for a broadcast session, flow proceeds to block 708.

[0089] 7C is a flow diagram of an example method 700C for activating transmission of an MBS. At block 702, the CN receives an interface message from the MBS network (e.g., events 304, 490). At block 705, the CN determines whether to configure resources for a multicast session for the MBS Session ID or for a broadcast session for the MBS Session ID based on the QoS profile. If the CN determines to configure resources for a multicast session for the MBS Session ID, flow proceeds to block 706. In this case, the CN determines, based on the QoS parameters in the QoS profile, that the MBS session identified by the MBS Session ID requires resources for a multicast session. If the CN determines to configure resources for a broadcast session for the MBS Session ID, flow proceeds to block 708. In this case, the CN determines, based on the QoS parameters in the QoS profile, that the MBS session identified by the MBS Session ID requires resources for a broadcast session.

[0090] Blocks in Figures 8A-8C that are the same are labeled with the same reference numbers. In some implementations, Figures 8A-8C can be combined with Figures 7A-7C, respectively. In one implementation, the first CN-to-BS message in block 706 and the first CN-to-BS message in block 806 can be the same message. In another implementation, the first CN-to-BS message in block 706 and the first CN-to-BS message in block 806 can be different messages. Similarly, the second CN-to-BS message in block 708 and the second CN-to-BS message in block 808 can be the same message or different messages. The examples and implementations of Figures 7A-7C can be applied to Figures 8A-8C.

[0091] 8A is a flow diagram of an example method 800A for activating transmission of an MBS. In block 802, the CN receives an interface message (i.e., a first interface message) from the MBS network (e.g., Event 304). In block 804, the CN determines whether the interface message requests resources for a multicast session for the MBS Session ID or a broadcast session for the MBS Session ID. If the interface message requests resources for a multicast session, flow proceeds to block 806. If the interface message requests resources for a broadcast session, flow proceeds to block 808. In block 806, the CN sends a first CN-to-BS message to the first RAN to request resources for multicasting an MBS associated with the MBS Session ID (e.g., Event 492). In block 808, the CN sends a second CN-to-BS message to the second RAN to request a broadcast activation notification for the MBS Session ID (e.g., Event 310).

[0092] In some implementations, the CN can send a second interface message to the MBS network in response to the first interface message (e.g., event 314). In some implementations, the CN can receive a first inter-BS-CN message from the first RAN in response to the first inter-CN-BS message (e.g., event 312). In some implementations, the CN can receive a second inter-BS-CN message from the second RAN in response to the second inter-CN-BS message. The CN can send a second interface message to the MBS network after receiving the first or second inter-BS-CN message.

[0093] 8B is a flow diagram of an example method 800B for activating transmission of an MBS. In block 803, the CN determines whether the MBS session ID is associated with a multicast session or a broadcast session. If the MBS session ID is associated with a multicast session, flow proceeds to block 806. If the interface message requests resources for a broadcast session, flow proceeds to block 808.

[0094] 8C is a flow diagram of an example method 800C for activating transmission of an MBS. At block 802, the CN receives an interface message from the MBS network (e.g., events 304, 490). At block 805, the CN determines whether the MBS session identified by the MBS session ID is a multicast session or a broadcast session based on the QoS profile. If the CN determines that the MBS session identified by the MBS session ID is a multicast session, flow proceeds to block 806. If the CN determines that the MBS session identified by the MBS session ID is a broadcast session, flow proceeds to block 808.

[0095] 9 is a flow diagram of an example method 900 that a RAN may implement to manage MBS with a UE. At block 902, the RAN receives a message associated with an MBS session identifier (e.g., events 306, 310, procedure 490; blocks 502, 602). At block 904, in response to the message, the RAN establishes an MBS session with the UE based on the MBS session identifier (e.g., events 308, 316, procedure 490; blocks 506, 510, 606, 608).

[0096] 10 is a flow diagram of an example method 1000 that a CN can implement to manage MBS with a RAN. At block 1002, the CN receives an interface message associated with an MBS session identifier from an MBS network (e.g., event 304, procedure 490; blocks 702, 802). At block 1004, the CN sends to the RAN a message to establish an MBS session with the UE based on the MBS session identifier (e.g., block 306, procedure 490; blocks 706, 708, 806, 808).

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

[0098] In some implementations, the UE can receive data of the MBS in the broadcast session without performing a session join procedure for receiving the MBS, i.e., the UE does not need to perform a session join procedure for the broadcast session. In other implementations, the UE can receive data of the MBS in the broadcast session according to configuration parameters broadcast by the RAN, i.e., without performing an RRC reconfiguration procedure to receive configuration parameters for receiving data of the MBS.

[0099] In some implementations, the UE must perform a session join procedure to receive data of the MBS in the multicast session, while in other implementations, the UE can receive data of the MBS in the multicast session only according to the configuration parameters received in the RRC reconfiguration message.

[0100] In some implementations, "MBS" can be replaced with "MBS session" and vice versa. In some implementations, "message" is used and can be replaced with "information element (IE)". In some implementations, "IE" is used and can be replaced with "field". In some implementations, the singular "configuration" can be replaced with the plural "configurations" or configuration parameters.

[0101] A user device (e.g., UE 102) in which the techniques of this disclosure may be implemented can 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 smartwatch, a wireless hotspot, a femtocell, or a broadband router. Furthermore, a 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, a user device can operate as an Internet of Things (IoT) device or a Mobile Internet Device (MID). Depending on the type, a 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.

[0102] Certain embodiments are described in this disclosure as including logic circuits 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 specific operations and may be configured or arranged in a specific way. A hardware module can comprise dedicated circuitry or logic circuitry permanently configured to perform specific operations (e.g., as a dedicated processor such as a field programmable gate array (FPGA) or application-specific integrated circuit (ASIC)). A hardware module may also comprise programmable logic circuitry or circuitry temporarily configured by software to perform specific operations (e.g., contained within a general-purpose processor or other programmable processor). The decision to implement a hardware module in dedicated, permanently configured circuitry or in temporarily configured (e.g., configured by software) circuitry may be driven by cost and time considerations.

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

[0104] The following list of examples reflects various additional embodiments expressly contemplated by this disclosure.

[0105] Example 1. A method in a radio access network (RAN) for managing multicast and / or broadcast services (MBS) with a user equipment (UE) while a radio connection between the UE and the RAN is not active, the method comprising: receiving, by processing hardware, from a core network (CN) a message associated with an MBS session identifier; and, in response to receiving the message, establishing, by the processing hardware, an MBS session with the UE based on the MBS session identifier.

[0106] Example 2. The method of Example 1, wherein the message includes at least one of an MBS session identifier or quality of service (QoS) information associated with the MBS session.

[0107] Example 3. The method of Example 2, wherein the establishing step includes determining that the message indicates configuring radio resources for the MBS session.

[0108] Example 4. The method of Example 3, wherein the establishing step includes, in response to the determining step, sending a notification to the UE to activate reception of the MBS session at the UE.

[0109] Example 5. The method of Example 2, wherein the establishing step includes determining that the message indicates sending a notification to the UE to activate reception of the MBS session at the UE, and, in response to the determining step, sending the notification to the UE.

[0110] Example 6. The method of any one of Examples 3 to 5, wherein the determining step includes detecting that the message indicates that the MBS session is a multicast session.

[0111] Example 7. The method of Example 6, wherein the detecting step includes detecting that the MBS session identifier is associated with the multicast session.

[0112] Example 8. The method of Example 6, wherein the detecting step includes detecting that QoS information is associated with the multicast session.

[0113] Example 9. The method of any one of Examples 6 to 8, wherein the notification includes a paging message that includes an MBS session ID.

[0114] Example 10. The method of any one of Examples 6 to 9, further comprising: activating a wireless connection between the UE and the RAN; and transmitting MBS data associated with the MBS session identifier when the wireless connection between the UE and the RAN is active.

[0115] Example 11. The method of any one of Examples 3 to 5, wherein the determining step includes detecting that the message indicates that the MBS session is a broadcast session.

[0116] Example 12. The method of Example 11, wherein the detecting step includes detecting that the MBS session identifier is associated with the broadcast session.

[0117] Example 13. The method of Example 11, wherein the detecting step includes detecting that QoS information is associated with the broadcast session.

[0118] Example 14. The method of any one of Examples 11 to 13, wherein the notification includes a Multicast Control Channel (MCCH) message that includes the MBS session ID.

[0119] Example 15. The method of any one of Examples 11 to 14, further comprising transmitting MBS data associated with the MBS session identifier while the radio connection between the UE and the RAN remains inactive.

[0120] Example 16. A RAN comprising processing hardware and configured to perform the method of any of the preceding examples.

[0121] Example 17. A method in a core network (CN) for managing multicast and / or broadcast services (MBS) with a radio access network (RAN), the method comprising: receiving, by processing hardware, an interface message associated with an MBS session identifier from the MBS network; and, in response to receiving the interface message, transmitting, by the processing hardware, to the RAN, a message for establishing an MBS session with a user equipment (UE) based on the MBS session identifier while a radio connection between the UE and the RAN is not active.

[0122] Example 18. The method of Example 17, wherein the interface message or at least one of the messages includes at least one of an MBS session identifier or quality of service (QoS) information associated with the MBS session.

[0123] Example 19. The method of Example 18, further comprising determining that the interface message indicates configuring radio resources for the MBS session.

[0124] Example 20. The method of Example 19, wherein the step of sending the message causes the RAN to send a notification to the UE to activate reception of the MBS session at the UE.

[0125] Example 21. The method of Example 19, wherein the step of transmitting the message causes the RAN to configure radio resources for the MBS session.

[0126] Example 22. The method of any one of Examples 19 to 21, wherein the determining step includes detecting that the interface message indicates that the MBS session is a multicast session.

[0127] Example 23. The method of Example 22, wherein the detecting step includes detecting that the MBS session identifier is associated with the multicast session.

[0128] Example 24. The method of Example 22, wherein the detecting step includes detecting that QoS information is associated with the multicast session.

[0129] Example 25. The method of any one of Examples 19 to 21, wherein the determining step includes detecting that the interface message indicates that the MBS session is a broadcast session.

[0130] Example 26. The method of Example 25, wherein the detecting step includes detecting that the MBS session identifier is associated with the broadcast session.

[0131] Example 27. The method of Example 25, wherein the detecting step includes detecting that QoS information is associated with the broadcast session.

[0132] Example 28. The method of any one of Examples 17 to 27, wherein the RAN includes a first RAN and a second RAN, the MBS session includes a first MBS session and a second MBS session, and the sending of the message includes (i) sending a first message to the first RAN to establish the first MBS session, and (ii) sending a second message to the second RAN to establish the second MBS session.

[0133] Example 29. A CN comprising processing hardware and configured to perform the method of any of Examples 17 to 28. [Explanation of symbols]

[0134] 100 Wireless Communication System 102UE 102A UE 102B UE 104 Base station, MeNB, Mng-eNB, MgNB 105 RAN 106 Base Station 106A base station, SgNB, Sng-eNB 106B base station 110 Core Network (CN), CN 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 126A cell 126B cell 130 Processing Hardware 132 Base Station MBS Controller 134 Base Station Non-MBS Controller 140 Processing Hardware 142 Base Station MBS Controller 144 Base Station Non-MBS Controller 150 Processing Hardware 152 UE MBS Controller 154 UE 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 170 MBS Network 172 Central Unit (CU), CU 172A Logical Node CU-CP, CU-CP 172B Logical nodes CU-UP, CU-UP 174 Distributed Unit (DU), DU 200 Protocol Stack, Stack 202A Physical Layer (PHY) 202B NR PHY 204A EUTRA MAC Sublayer 204B NR MAC sublayer 206A EUTRA RLC sublayer, RLC sublayer 206B NR RLC sublayer, RLC sublayer 208 EUTRA PDCP Sublayer, PDCP Sublayer 210 NR PDCP sublayer, PDCP sublayer 212 SDAP Sublayer 300A Scenario 300B Scenario 390 MBS Session Activation Notification Procedure 391 MBS Session Activation Notification Procedure 392 MBS Resource Setup Procedure 394 MBS data transmission procedure 400A Scenario 400B Scenario 490 MBS Session Activation Notification Procedure 500A method 500B method 500C method 500D method 600A Method 600B method 600C method 600D method 700A method 700B method 700C method 800A Method 800B method 800C method 900 ways 1000 ways

Claims

1. 1. A method in a Core Network (CN) for managing a Multicast and / or Broadcast Service (MBS) with a Radio Access Network (RAN), comprising: receiving an interface message associated with an MBS session identifier from an MBS network; In response to the receiving step, sending a first CN-to-BS message to the RAN to request activation notification for the multicast session corresponding to the MBS session identifier; or sending a second CN-to-BS message to the RAN to request activation notification for the broadcast session corresponding to the MBS session identifier; and performing one of the steps: A method comprising:

2. 10. The method of claim 1, wherein the first CN-to-BS message is a new Next Generation Application Protocol (NGAP) message.

3. The method of claim 1 or 2, wherein the second CN-to-BS message is an NGAP message.

4. The method of claim 1 , wherein the second CN-to-BS message includes a QoS profile.

5. The method of claim 1 , wherein the MBS session identifier comprises a Temporary Mobile Group Identity (TMGI).

6. transmitting the first CN-to-BS message in response to determining that the interface message includes a request for resources for the multicast session; transmitting the second CN-to-BS message in response to determining that the interface message includes a request for resources for the broadcast session; 6. The method of claim 1, further comprising:

7. A core network comprising one or more computing devices and configured to implement the method of any one of claims 1 to 6.

8. A method in a RAN node for managing MBS, comprising: receiving a CN-to-BS message from the CN, the message including the MBS session identifier; performing one or more procedures to transition a plurality of user equipment units (UEs) to a connected state when the CN-to-BS message requests activation notification for a multicast session corresponding to the MBS session identifier; or broadcasting an MBS resource configuration to the plurality of UEs, including refraining from transitioning the plurality of UEs to the connected state when the CN-to-BS message requests activation notification for a broadcast session corresponding to the MBS session identifier. and performing one of the steps: A method comprising:

9. 10. The method of claim 8, wherein broadcasting the MBS resource configuration includes using a multicast control channel (MCCH).

10. when the CN-to-BS message requests activation notification for the broadcast session; transmitting MBS data associated with the MBS session to the plurality of UEs using the MCCH; 10. The method of claim 9, further comprising:

11. The method of claim 8 , wherein the MBS session identifier comprises a Temporary Mobile Group Identity (TMGI).

12. 12. The method of claim 8, wherein the CN-to-BS message includes a QoS profile.

13. the CN-to-BS message requesting activation notification for the multicast session is a first NGAP CN-to-BS message; the CN-to-BS message requesting activation notification for the broadcast session is a second NGAP CN-to-BS message; 13. The method according to any one of claims 8 to 12.

14. the CN-BS message requesting activation notification for the broadcast session is a resource setup request message; The method of claim 13.

15. 15. A RAN node comprising one or more processors and configured to implement the method of any one of claims 8 to 14.

Images