System and method for supporting multicast reception in rrcinactive state

Abstract

Systems and methods are presented for supporting multicast reception in a radio resource control inactive (RRCINACTIVE state. In one embodiment, a centralized unit, CU, of a wireless communication node may send a first signaling to a distributed unit, DU, of the wireless communication node, where the first signaling includes information about multicast reception of at least a first wireless communication device in an RRCINACTIVE state. The CU may receive a second signaling from the DU in response to the first signaling.

Description

Technical Field

[0001] This disclosure generally relates to wireless communications, including but not limited to systems and methods for supporting multicast reception in a Radio Resource Control (RRC_INACTIVE) state. Background Technology

[0002] The Third Generation Partnership Project (3GPP), a standards organization, is currently developing specifications for a new radio interface called 5G New Radio (5G NR) and the Next Generation Packet Core Network (NG-CN or NGC). 5G NR will have three main components: the 5G Access Network (5G-AN), the 5G Core Network (5GC), and User Equipment (UE). To facilitate the implementation of different data services and needs, the network elements (also known as network functions) of the 5GC have been simplified, with some implemented in software and others in hardware, so that they can be adjusted as needed. Summary of the Invention

[0003] The exemplary embodiments disclosed herein are intended to address one or more related problems existing in the related art and provide additional features that will be readily understood upon reading the following detailed description in conjunction with the accompanying drawings. Example systems, methods, apparatuses, and computer program products are disclosed herein according to various embodiments. However, it should be understood that these embodiments are presented by way of example and not as limiting, and it will be apparent to those skilled in the art, upon reading this disclosure, that various modifications can be made to the disclosed embodiments (e.g., including combinations of features / elements in different examples / embodiments / implementations) without departing from the scope of this disclosure.

[0004] At least one aspect relates to a system, method, apparatus, or computer-readable medium. A centralized unit (CU) of a wireless communication node (e.g., a base station (BS)) can send a first signaling to a distributed unit (DU) of the wireless communication node, wherein the first signaling includes information regarding multicast reception by at least a first wireless communication device (e.g., a UE) in an RRC_INACTIVE state. The CU can receive a second signaling from the DU in response to the first signaling. The first signaling can be used for the first wireless communication device (e.g., for each UE or specific to a UE). The information can include at least one of the following: indication information indicating that the first wireless communication device is configured for multicast reception in the RRC_INACTIVE state; a cause value indicating that the reason for releasing the first wireless communication device to the RRC_INACTIVE state is that the first wireless communication device is configured to receive multicast in the RRC_INACTIVE state; a multicast radio bearer (MRB) configuration for multicast reception in the RRC_INACTIVE state; or a cell identifier (ID) included in the indication information. The cell ID can indicate which cell the configuration applies to. The cell ID can also indicate which cell is configured for multicast reception in the RRC_INACTIVE state. The second signaling can include at least one of the following: information about the establishment of the MRB configuration; Point-to-Multipoint (PTM) configuration information, which may include information that can be used for multicast reception in the RRC_INACTIVE state; or indication information. The PTM configuration information can include lower-level PTM configurations. The PTM configuration information can be used for a session (e.g., for each session or specific to a session). The indication information can indicate that the PTM configuration used in the RRC_CONNECTED state will continue to be used in the RRC_INACTIVE state (e.g., when the wireless communication device is in or enters the RRC_INACTIVE state). The indication information can indicate that the PTM configuration to be used in the RRC_INACTIVE state will be obtained via the Multicast-Broadcast Service Control Channel (MCCH) (e.g., received in transmitted signaling). The indication information can be used (e.g., specifically for) a session.

[0005] In some embodiments, the CU can determine to release the first wireless communication device into the RRC_INACTIVE state based on a second signaling. The CU can send a Radio Resource Control Release (RRCRelease) message to the first wireless communication device, wherein the RRCCRelease message includes indication information indicating the PTM configuration to be used in the RRC_INACTIVE state. The CU's Control Plane (CP) (e.g., CU-CP) can send information about multicast reception in the RRC_INACTIVE state to the CU's User Plane (UP) (e.g., CU-UP) in E1 signaling for the session (e.g., via the E1 interface between CU-CP and CU-UP). Taking the above information into consideration, the CU can release the UE into the RRC_INACTIVE state. In this case, the second signaling can be a suggestion. The CU can accept or reject the suggestion. In some embodiments, the CU can always release the UE into the RRC_INACTIVE state according to the DU's request. In this case, the second signaling can be a command. The CU can only accept the command.

[0006] In some embodiments, the first signaling may be used for a session (e.g., for each session or specific to a session). The information may include at least one of the following: indication information indicating that the session will be configured for multicast reception in the RRC_INACTIVE state; a list of wireless communication devices that have joined the session and will be released (e.g., transitioned) to the RRC_INACTIVE state for multicast reception; a list of cells that will be triggered to perform multicast reception in the RRC_INACTIVE state; a list of MRB configurations to be used in the RRC_INACTIVE state; or an indication of at least one cell associated with at least one of the MRB configurations. A mapping relationship may exist between at least one cell and at least one of the MRB configurations. The second signaling may include at least one of the following: a response to accepting or rejecting a list of wireless communication devices; a response to accepting or rejecting a list of cells; a response to accepting or rejecting a list of MRB configurations; PTM configuration information that may be used for multicast reception in the RRC_INACTIVE state; or indication information. The PTM configuration information may include PTM configurations of a lower layer (or one or more specific layers). The PTM configuration information may be used for the session. Indication information can indicate that the PTM configuration used in the RRC_CONNECTED state (e.g., by a wireless communication device) will continue to be used in the RRC_INACTIVE state. Indication information can also indicate (e.g., specify or provide guidance) that the PTM configuration to be used in the RRC_INACTIVE state will be obtained via the MCCH. Indication information can be used for sessions. The DU can accept or reject some (or all or none) UEs in the list. The CU can provide a list of UEs / cells / MRBs planned for receiving multicast in the RRC_INACTIVE state. The DU has the authority to accept or reject, and therefore can provide a response message to provide this indication.

[0007] In some embodiments, the CU can determine, based on a second signaling, to release the first wireless communication device into the RRC_INACTIVE state. The CU can send an RRCLease message to the first wireless communication device, wherein the RRCLease message includes indication information indicating the PTM configuration to be used in the RRC_INACTIVE state. The CU's control plane can send information about multicast reception in the RRC_INACTIVE state to the CU's user plane in E1 signaling for the session.

[0008] In some embodiments, if the second signaling includes PTM configuration information, the CU can incorporate / insert / include / carry / send the PTM configuration in the RRC_CONNECTED message. If the second signaling includes indication that the PTM configuration used in the RRC_CONNECTED state will continue to be used in the RRC_INACTIVE state, the CU can incorporate / insert / include / carry / send this indication in the RRC_INACTIVE message. If the second signaling includes indication that the PTM configuration used in the RRC_INACTIVE state will be obtained through the MCCH, the CU can incorporate / insert / include / carry this indication in the RRC_INACTIVE message. The CU can incorporate / insert / include / carry a first indication for the session in the RRC_CONNECTED message to indicate whether the wireless communication device monitors the Group Radio Network Temporary Identifier (G-RNTI). The CU can merge / insert / include / carry the cell ID from the PTM configuration information in the RRCrease message.

[0009] In some embodiments, the first indication may indicate whether the session state is inactive or active. If the session state is active, the wireless communication device will (or may) monitor G-RNTI for multicast reception after transitioning to the RRC_INACTIVE state. If the session state is inactive, the first wireless communication device will not (or may not) monitor G-RNTI after transitioning to the RRC_INACTIVE state until it receives a corresponding activation indication from the wireless communication node.

[0010] In some embodiments, the first indication may indicate a PTM configuration. The PTM configuration may include at least one of the following: a pre-configuration used when a session is activated, or an in-process configuration used immediately after transitioning to the RRC_INACTIVE state to receive the corresponding active session. If the PTM configuration includes a pre-configuration, the first wireless communication device will (or may) store the pre-configuration, and / or use the pre-configuration to monitor G-RNTI after transitioning to the RRC_INACTIVE state until it receives the corresponding activation indication from the wireless communication node. If the PTM configuration includes an in-process configuration, the first wireless communication device will (or may) use the in-process configuration to monitor G-RNTI immediately after transitioning to the RRC_INACTIVE state.

[0011] In some embodiments, the first indication may indicate the behavior of the first wireless communication device in the RRC_INACTIVE state. The behavior may include the first wireless communication device monitoring G-RNTI (e.g., immediately) after transitioning to the RRC_INACTIVE state. The behavior may also include the first wireless communication device not (or possibly not monitoring) G-RNTI, for example, after transitioning to the RRC_INACTIVE state until receiving a corresponding activation indication from the wireless communication node. In some embodiments, the information may include at least one of the following: session state, including inactive or active; or configuration state, including pre-configured or in-process configuration.

[0012] In some embodiments, the CU may send an RRCRelease message, including a first indication for the session, to the first wireless communication device. The first indication may be used to indicate whether the wireless communication device should monitor the G-RNTI in the RRC_INACTIVE state. The first indication may indicate whether the session state is inactive or active. If the session state is active, the wireless communication device may monitor the G-RNTI for multicast reception after transitioning to the RRC_INACTIVE state (e.g., immediately). If the session state is inactive, the first wireless communication device, for example, does not (or may not) monitor the G-RNTI until it receives a corresponding activation indication from the wireless communication node after transitioning to the RRC_INACTIVE state.

[0013] In some embodiments, the first indication may indicate a PTM configuration. The PTM configuration may include at least one of the following: a pre-configuration used (or can be used) upon session activation, or an in-process configuration that the wireless communication device may begin monitoring the session after transitioning to the RRC_INACTIVE state (e.g., immediately). If the PTM configuration includes a pre-configuration, the first wireless communication device will (or may) store the pre-configuration, and / or, for example, after transitioning to the RRC_INACTIVE state, will not use the pre-configuration to monitor G-RNTI until a corresponding activation indication is received from the wireless communication node. The UE may not immediately monitor G-RNTI after transitioning to the RRC_INACTIVE state. If the UE receives an indication regarding session activation, the UE may begin monitoring G-RNTI. If the PTM configuration includes an in-process configuration, the first wireless communication device will (or may) immediately use the in-process configuration to monitor G-RNTI after transitioning to the RRC_INACTIVE state.

[0014] In some embodiments, the first indication may indicate the behavior of the first wireless communication device in the RRC_INACTIVE state. This behavior may include the first wireless communication device immediately monitoring G-RNTI after transitioning to the RRC_INACTIVE state. Alternatively, the behavior may include the first wireless communication device not (or possibly not) monitoring G-RNTI after transitioning to the RRC_INACTIVE state until receiving a corresponding activation indication from the wireless communication node. The CU may incorporate the cell ID from the PTM configuration information into the RRCRelease message. In some embodiments, the CU's control plane may send session status and / or configuration status to the CU's user plane in E1 signaling used for the session.

[0015] In some embodiments, the DU of a wireless communication node (e.g., a base station) can receive a first signaling from the CU of the wireless communication node. This first signaling includes information about multicast reception by at least a first wireless communication device (e.g., a UE) in the RRC_INACTIVE state. The DU can then send a second signaling to the CU in response to the first signaling. Attached Figure Description

[0016] Various exemplary embodiments of this solution are described in detail below with reference to the following figures and accompanying drawings. The drawings are provided for illustrative purposes only and depict only exemplary embodiments of this solution to aid the reader's understanding. Therefore, the drawings should not be considered as limitations on the breadth, scope, or applicability of this solution. It should be noted that these drawings are not necessarily drawn to scale for clarity and ease of explanation.

[0017] Figure 1 An example cellular communication network in which the techniques disclosed herein can be implemented according to embodiments of the present disclosure is shown;

[0018] Figure 2 Block diagrams of example base station and user equipment apparatuses according to some embodiments of the present disclosure are shown; and

[0019] Figure 3 A flowchart of an example method for supporting multicast reception in the RRC_INACTIVE state, according to an embodiment of this disclosure, is shown. Detailed Implementation

[0020] 1. Mobile communication technology and environment

[0021] Figure 1An example wireless communication network and / or system 100, in which the techniques disclosed herein may be implemented according to embodiments of the present disclosure, is illustrated. In the following discussion, wireless communication network 100 may be any wireless network, such as a cellular network or a narrowband Internet of Things (NB-IoT) network, and is referred to herein as "network 100". Such an example network 100 includes base station 102 (hereinafter referred to as "BS 102"; also referred to as a wireless communication node) and user equipment device 104 (hereinafter referred to as "UE 104"; also referred to as a wireless communication device), which can communicate with each other via communication link 110 (e.g., a wireless communication channel) and a cluster of cells 126, 130, 132, 134, 136, 138, and 140 covering a geographic area 101. Figure 1 In this context, BS 102 and UE 104 are contained within the corresponding geographical boundaries of cell 126. Each of the other cells 130, 132, 134, 136, 138, and 140 may include at least one base station that operates on its allocated bandwidth to provide sufficient radio coverage to its intended users.

[0022] For example, BS 102 can operate at the allocated channel transmission bandwidth to provide sufficient coverage to UE 104. BS 102 and UE 104 can communicate via downlink radio frame 118 and uplink radio frame 124, respectively. Each radio frame 118 / 124 can be further divided into subframes 120 / 127, which may include data symbols 122 / 128. In this disclosure, BS 102 and UE 104 are described herein as non-limiting examples of "communication nodes" that can generally practice the methods disclosed herein. According to various embodiments of this scheme, such communication nodes are capable of wireless and / or wired communication.

[0023] Figure 2 A block diagram of an example wireless communication system 200 for transmitting and receiving wireless communication signals (e.g., OFDM / OFDMA signals) according to some embodiments of this solution is shown. System 200 may include components and elements configured to support known or conventional operating characteristics (which do not need to be described in detail herein). In one illustrative embodiment, system 200 can be used in wireless communication environments (such as those described above) Figure 1 In a wireless communication environment 100, data symbols are transmitted (e.g., sent and received).

[0024] System 200 typically includes a base station 202 (hereinafter referred to as "BS 202") and a user equipment unit 204 (hereinafter referred to as "UE 204"). BS 202 includes a BS (base station) transceiver module 210, a BS antenna 212, a BS processor module 214, a BS memory module 216, and a network communication module 218, each module being coupled and interconnected with each other as needed via a data communication bus 220. UE 204 includes a UE transceiver module 230, a UE antenna 232, a UE memory module 234, and a UE processor module 236, each module being coupled and interconnected with each other as needed via a data communication bus 240. BS 202 communicates with UE 204 via a communication channel 250, which can be any wireless channel or other medium suitable for data transmission as described herein.

[0025] As those skilled in the art will understand, system 200 may also include, in addition to Figure 2 Any number of modules other than those shown herein. Those skilled in the art will understand that the various illustrative blocks, modules, circuits, and processing logic described in connection with the embodiments disclosed herein can be implemented in hardware, computer-readable software, firmware, or any practical combination thereof. To clearly illustrate this interchangeability and compatibility of hardware, firmware, and software, the various illustrative components, blocks, modules, circuits, and steps are described generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware, or software can depend on the specific application and design constraints imposed on the system as a whole. Those skilled in the art can implement such functionality in a suitable manner for each specific application; however, such implementation decisions should not be construed as limiting the scope of this disclosure.

[0026] According to some embodiments, UE transceiver 230 may be referred to herein as "uplink" transceiver 230, which includes a radio frequency (RF) transmitter and an RF receiver, each of which includes circuitry coupled to antenna 232. A duplex switch (not shown) may alternatively couple the uplink transmitter or receiver to the uplink antenna in a time-duplex manner. Similarly, according to some embodiments, BS transceiver 210 may be referred herein as "downlink" transceiver 210, which includes an RF transmitter and an RF receiver, each of which includes circuitry coupled to antenna 212. A downlink duplex switch may alternatively couple the downlink transmitter or receiver to downlink antenna 212 in a time-division duplex manner. The operations of the two transceiver modules 210 and 230 can be coordinated in time such that the uplink receiver circuitry is coupled to the uplink antenna 232 to receive transmissions via the wireless transmission link 250 while the downlink transmitter is coupled to the downlink antenna 212. Conversely, the operations of the two transceivers 210 and 230 can be coordinated in time such that the downlink receiver is coupled to the downlink antenna 212 to receive transmissions via the wireless transmission link 250 while the uplink transmitter is coupled to the uplink antenna 232. In some embodiments, there is tight time synchronization with a minimum guard time between changes in duplex direction.

[0027] UE transceiver 230 and base transceiver 210 are configured to communicate via wireless data communication link 250 and cooperate with RF antenna arrangements 212 / 232 that can be appropriately configured to support specific wireless communication protocols and modulation schemes. In some illustrative embodiments, UE transceiver 210 and base transceiver 210 are configured to support industry standards such as Long Term Evolution (LTE) and emerging 5G standards. However, it should be understood that this disclosure is not necessarily limited to specific standards and associated protocols in application. Rather, UE transceiver 230 and base transceiver 210 may be configured to support alternative or additional wireless data communication protocols, including future standards or variations thereof.

[0028] According to various embodiments, BS 202 may be, for example, an evolved node B (eNB), a serving eNB, a target eNB, a femtocell, or a picocell. In some embodiments, UE 204 may be embodied in various types of user equipment, such as mobile phones, smartphones, personal digital assistants (PDAs), tablets, laptops, wearable computing devices, etc. Processor modules 214 and 236 may be implemented or realized using a general-purpose processor, content-addressable memory, digital signal processor, application-specific integrated circuit, field-programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. In this way, the processor may be implemented as a microprocessor, a controller, a microcontroller, a state machine, etc. The processor may also be implemented as a combination of computing devices, such as a combination of a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors combined with a digital signal processor core, or any other such configuration.

[0029] Furthermore, the steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be directly embodied in hardware, firmware, software modules executed by processor modules 214 and 236 respectively, or any practical combination thereof. Memory modules 216 and 234 can be implemented as random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, removable disks, compact disc read-only memory (CD-ROM), or any other form of storage medium known in the art. In this regard, memory modules 216 and 234 can be coupled to processor modules 210 and 230 respectively, such that processor modules 210 and 230 can read information from and write information to memory modules 216 and 234 respectively. Memory modules 216 and 234 may also be integrated into their respective processor modules 210 and 230. In some embodiments, memory modules 216 and 234 may each include a cache memory for storing temporary variables or other intermediate information during the execution of instructions to be executed by processor modules 210 and 230, respectively. Memory modules 216 and 234 may also each include non-volatile memory for storing instructions to be executed by processor modules 210 and 230, respectively.

[0030] Network communication module 218 typically refers to the hardware, software, firmware, processing logic, and / or other components of base station 202 that enable bidirectional communication between base station transceiver 210 and other network components and communication nodes configured to communicate with base station 202. For example, network communication module 218 may be configured to support Internet or Worldwide Interoperability for Microwave Access (WiMAX) services. In typical deployments, but not limited to, network communication module 218 provides an 802.3 Ethernet interface, enabling base station transceiver 210 to communicate with traditional Ethernet-based computer networks. In this way, network communication module 218 may include a physical interface for connecting to a computer network (e.g., a Mobile Switching Center (MSC)). The terms “configured for,” “configured to,” and variations thereof used herein with respect to a specified operation or function refer to means a means, component, circuit, structure, machine, signal, etc., physically constructed, programmed, formatted, and / or arranged to perform the specified operation or function.

[0031] The Open Systems Interconnection (OSI) model (referred to herein as the "OSI model") is a conceptual and logical layout that defines network communications used by systems open to interconnect and communicate with other systems (e.g., wireless communication devices, wireless communication nodes). The model is divided into seven sub-components or layers, each representing a conceptual set of services provided to the layers above and below it. The OSI model also defines logical networks and efficiently describes computer packet transmissions using different layer protocols. The OSI model may also be referred to as the seven-layer OSI model or the seven-layer model. In some embodiments, the first layer may be the physical layer. In some embodiments, the second layer may be the Medium Access Control (MAC) layer. In some embodiments, the third layer may be the Radio Link Control (RLC) layer. In some embodiments, the fourth layer may be the Packet Data Convergence Protocol (PDCP) layer. In some embodiments, the fifth layer may be the Radio Resource Control (RRC) layer. In some embodiments, the sixth layer may be the Non-Access Stratum (NAS) layer or the Internet Protocol (IP) layer, and the seventh layer is other layers.

[0032] Various exemplary embodiments of this solution are described below with reference to the accompanying drawings to enable those skilled in the art to make and use this solution. It will be apparent to those skilled in the art that various changes or modifications can be made to the examples described herein without departing from the scope of this solution after reading this disclosure. Therefore, this solution is not limited to the exemplary embodiments and applications described and illustrated herein. Furthermore, the specific order or hierarchy of steps in the methods disclosed herein is merely an example method. Based on design preferences, the specific order or hierarchy of steps in the disclosed methods or processes can be rearranged while remaining within the scope of this solution. Therefore, those skilled in the art will understand that the methods and techniques disclosed herein present various steps or actions in an exemplary order, and this solution is not limited to the presented specific order or hierarchy unless explicitly stated otherwise.

[0033] 2. Systems and methods for supporting multicast reception in the RRC_INACTIVE state

[0034] Multicast and Broadcast Services (MBS) implemented in 5G NR and / or other systems can provide reliable, low-latency, and resource-efficient transmission to multiple terminals simultaneously. These services can support a wide range of applications in congested areas, such as concerts, stadiums, and racetracks. On one hand, there may be situations where video synchronization to terminals is necessary. On the other hand, there may be situations where multiple perspectives are needed / desired / beneficial. Additionally, MBS can facilitate large-scale virtual reality (VR) live broadcasts, where numerous users in the same cell can simultaneously watch and / or receive important information, such as updates on epidemics and disasters in a particular region, via an application or television. This raises the issue of how to handle cell congestion. Considering that the number of UEs connected to a cell and the service capacity carried by the cell may be limited, cell congestion can lead to service rejection or reduced transmission of other services or UEs.

[0035] In 5G NR, a UE can have three RRC states: RRC connected (RRC_CONNECTED), RRC idle (RRC_IDLE), and RRC inactive (RRC_INACTIVE). RRC_INACTIVE is a state defined in 5G NR. When a UE enters the RRC_INACTIVE state, it can retain some of the network's context. The core network may not be aware that the UE has transitioned to the RRC_INACTIVE state; in other words, this state may be transparent to the core network.

[0036] In the RRC_INACTIVE state, if there is data to be transmitted, the UE may need to transition to the RRC_CONNECTED state through a connection recovery procedure. Introducing the RRC_INACTIVE state not only saves energy but also ensures better control plane latency management. When the UE enters the RRC_INACTIVE state, compared to the RRC_IDLE state, the UE can transition to the RRC_CONNECTED state quickly with lower control plane latency.

[0037] In scenarios involving cell congestion or energy saving, one approach to enable or continue MBS multicast reception might be to transition some UEs that support or have already implemented MBS multicast to the RRC_INACTIVE state. Such UEs can transition from the RRC_CONNECTED state to the RRC_INACTIVE state to receive or continue receiving multicast sessions.

[0038] In NR MBS, the PTM configuration transmission method can be specified as follows: For multicast, dedicated signaling can be used; for broadcast, signaling similar to Single Cell (SC)-PTM can be used. For broadcast reception in a Secondary Cell (SCell), dedicated signaling can be used to transmit System Information Blocks (SIBx). For example, this can be used to provide indications / acknowledgments supporting multicast reception in the RRC_INACTIVE state. This disclosure provides a scheme for enabling a UE to receive and / or continue receiving MBS services in the RRC_INACTIVE state.

[0039] Example 1 of implementation: Indication of multicast reception in the RRCRelease message

[0040] To support MBS multicast reception in the RRC_INACTIVE state, this document discloses how to obtain the PTM configuration used in the RRC_INACTIVE state. Several methods are possible, and examples are discussed below. Method 1: Obtain the new PTM configuration from the RRC_INACTIVE message. Method 2: Continue using the PTM configuration used in the RRC_CONNECTED state. Method 3: Obtain an indication from the RRC_INACTIVE message that instructs the UE to obtain the PTM configuration by monitoring the MCCH.

[0041] There may be two states that allow multicast sessions to be received in the RRC_INACTIVE state: active multicast sessions or inactive multicast sessions.

[0042] In these schemes, the impact of different session states can be considered. For example, for inactive multicast sessions, the UE may not monitor the MCCH and / or MBS Traffic Channel (MTCH) before receiving the corresponding activation indication from the gNB. However, for active sessions, the UE (e.g., in RRC_INACTIVE state) can monitor the MCCH to obtain the updated PTM configuration and can immediately begin receiving data. For scheme 1, several aspects are disclosed herein, including the content of the PTM configuration and how to notify the UE of the cells to which the configuration can be applied.

[0043] The UE can receive each session indication from the BS in / using the RRCLease message. Each session indication tells the UE whether to monitor G-RNTI. The indication can be a session state, such as inactive or active. If the session state is active, the UE can monitor G-RNTI immediately after transitioning to the RRC_INACTIVE state for multicast reception. If the session state is inactive, the UE can, for example, not monitor G-RNTI until receiving the corresponding activation indication from the gNB after transitioning to the RRC_INACTIVE state.

[0044] The indication can indicate the configuration status. For example, the status (or type) of the PTM configuration can be a pre-configured state used when the session is activated, or an in-process configuration that the UE can begin monitoring the session after transitioning to the RRC_INACTIVE state (e.g., immediately). If the PTM configuration is pre-configured, the UE can store the PTM configuration but cannot use it to monitor G-RNTI, for example, until it receives the corresponding activation indication from the gNB when transitioning to the RRC_INACTIVE state. If the PTM configuration is in-process configuration, the UE can use the PTM configuration to monitor G-RNTI after transitioning to the RRC_INACTIVE state (e.g., immediately).

[0045] This indication can specify the behavior of the UE in the RRC_INACTIVE state. The UE may monitor G-RNTI after transitioning to the RRC_INACTIVE state (e.g., immediately), or the UE may not monitor G-RNTI after transitioning to the RRC_INACTIVE state until, for example, it receives a corresponding activation indication from the gNB.

[0046] The UE can receive the cell ID from the PTM configuration carried in the RRRCRelease message.

[0047] To support MBS multicast reception in the RRC_INACTIVE state, we consider how to obtain the PTM configuration used in the RRC_INACTIVE state.

[0048] Here are some example scenarios among these methods: Scenario 1: Obtain the new PTM configuration from the RRCLease message. Scenario 2: Continue using the PTM configuration used in RRC_CONNECTED. Scenario 3: Obtain an indication from the RRCLease message that instructs the UE to obtain the PTM configuration by monitoring the MCCH. There may be two states that allow multicast sessions to be received in the RRC_INACTIVE state: active multicast sessions or inactive multicast sessions.

[0049] The above schemes can be applied to different states of a multicast session. Scheme 1: Applied to active and inactive multicast sessions. Scheme 2: Applied to both active and inactive multicast sessions. Scheme 3: (e.g., only) Applied to active multicast sessions. These schemes consider the impact of different session states. It can be seen that the UE behavior can differ for the two states of a multicast session, which will be explained in detail below.

[0050] For active sessions, the UE (e.g., in RRC_INACTIVE state) can monitor G-RNTI for multicast reception after transitioning to RRC_INACTIVE state (e.g., immediately). If MCCH exists, the UE can monitor MCCH to obtain / receive updated PTM configuration. For inactive sessions, the RRC_INACTIVE UE may not monitor G-RNTI after transitioning to RRC_INACTIVE state until, for example, it receives a corresponding activation indication from the gNB. If MCCH exists, the UE may not monitor MCCH after transitioning to RRC_INACTIVE state until it receives a corresponding activation indication from the gNB.

[0051] For Schemes 1 and 2, without additional indication to the UE regarding session status, the UE may perform incorrect actions, such as performing unnecessary G-RNTI monitoring, unnecessary MCCH monitoring, or unnecessary RRC connection recovery requests for inactive sessions. To help the UE operate correctly, a behavior indication can be added to each inactive multicast session in the RCRelease message. Based on this indication, the UE can distinguish whether the session is inactive. The UE may not monitor G-RNTI until it receives a corresponding activation indication from the gNB. The content of this behavior indication may include session status (e.g., whether it is inactive), configuration status (e.g., whether it is pre-configured), or UE behavior indication (e.g., whether G-RNTI monitoring is performed). For Scheme 2, to let the UE know which cell the configuration can be applied to, the cell ID can be included in the PTM configuration transmitted via the RCRelease message.

[0052] Example Scenario 1: Continue using the configuration used in the RRC_CONNECTED state.

[0053] In the example method, the UE can suspend the corresponding PTM configuration used in the RRC_CONNECTED state when transitioning to the RRC_INACTIVE state. If the configuration used in the RRC_CONNECTED and RRC_INACTIVE states is the same, then configuration suspension and / or re-establishment are not required.

[0054] In one approach, for MBS multicast sessions that are allowed to be received in the RRC_INACTIVE state, the configuration used in RRC_CONNECTED can indicate that the configuration can be used in the RRC_INACTIVE state.

[0055] Because the UE behaves differently in these two multicast session states, a UE ready to receive multicast in the RRC_INACTIVE state can be indicated with a session state to help the UE perform the correct action. In some embodiments, a behavior indication can be added for each inactive multicast session in the RRCRelease message.

[0056] In some embodiments, the indication may include session status (e.g., 1 bit in the RRCRelease message). This indication may indicate whether the corresponding multicast session is inactive. In one example, the indication may include / include configuration status (e.g., 1 bit in the RRCRelease message). This indication may indicate whether the corresponding configuration is a pre-configured configuration for the corresponding multicast session. In one example, the indication may be a UE behavior indication (e.g., 1 bit in the RRCRelease message). This indication may indicate whether the UE can or will immediately monitor the G-RNTI of the corresponding multicast session.

[0057] In some embodiments, for an active MBS multicast session, upon receiving such an indication, when the UE transitions to the RRC_INACTIVE state, the UE may not suspend the PTM configuration for the corresponding MBS multicast session and may continue to use that PTM configuration (e.g., immediately) to receive the corresponding MBS multicast data in the RRC_INACTIVE state. If the MCCH exists, the UE may begin monitoring the MCCH to obtain an updated PTM configuration after transitioning to the RRC_INACTIVE state.

[0058] In one example, for an inactive MBS multicast session, the UE's behavior upon receiving such an indication may include the following options.

[0059] The UE can choose not to suspend the corresponding PTM configuration and can choose not to immediately monitor G-RNTI after transitioning to the RRC_INACTIVE state. The UE can continue to use the previous PTM configuration to receive multicast data when receiving an activation indication from the gNB.

[0060] The UE can suspend the corresponding PTM configuration and may not immediately monitor G-RNTI after transitioning to the RRC_INACTIVE state. The UE can restore the configuration upon receiving an activation indication from the gNB to receive the corresponding multicast session.

[0061] Example Scenario 2: New configuration carried in the RRCRelease message.

[0062] In one scenario, for MBS multicast sessions that are allowed to receive in the RRC_INACTIVE state, a new configuration can be carried in the RCRelease message. For the new configuration carried in the RCRelease message, UE behavior can depend on the corresponding multicast session state. To help / enable the UE perform the correct behavior, a UE ready to receive multicast in the RRC_INACTIVE state can be indicated by the session state. In one example, a behavior indication can be added for each inactive multicast session in the RCRelease message. In one example, the content of this indication can be a session indication (e.g., 1 bit in the RCRelease message). This indication can indicate whether the corresponding multicast session is inactive. In one example, the content of this indication can be a configuration indication (e.g., 1 bit in the RCRelease message). This indication can indicate whether the corresponding configuration is a pre-configured configuration for the corresponding multicast session. In one example, the content of this indication can be a UE behavior indication (e.g., 1 bit in the RCRelease message). This indication is used to indicate whether the UE can immediately monitor the G-RNTI of the corresponding multicast session. In one example, for an active MBS multicast session, upon receiving such an indication, the UE can suspend the previous PTM configuration and establish a new configuration based on the RRCLease message. The UE can begin monitoring the corresponding G-RNTI after transitioning to the RRC_INACTIVE state (e.g., immediately). If the MCCH exists, the UE can begin monitoring the MCCH after transitioning to the RRC_INACTIVE state to obtain the updated PTM configuration.

[0063] In one example, for an inactive MBS multicast session, upon receiving such an indication, the UE can suspend the previous PTM configuration and store the new PTM configuration carried in the RRCRelease message. The UE may not (e.g., immediately) monitor the corresponding G-RNTI after transitioning to the RRC_INACTIVE state. The UE can receive multicast data in the RRC_INACTIVE state using the new configuration when receiving an activation indication from the gNB.

[0064] To inform the UE which cell the new configuration applies to, the corresponding cell ID can be included in the PTM configuration transmitted via the RRRCRelease message. In one example, the cell ID indicating which cell the new configuration applies to can be included in the PTM configuration transmitted via the RRRCRelease message.

[0065] Example 2 of implementation: Interaction between CU and DU for multicast reception in RRC_INACTIVE state

[0066] To address cell congestion caused by a large number of UEs, multicast reception can be supported in the RRC_INACTIVE state. This document discloses the impact / methods on F1 signaling, such as who can trigger multicast reception in the RRC_INACTIVE state (e.g., gNB-DU or gNB-CU-CP).

[0067] To support multicast reception in the RRC_INACTIVE state, this implementation example addresses how to obtain the PTM configuration used in the RRC_INACTIVE state, providing several example solutions as follows: Solution 1: Obtain the new PTM configuration from the RRCLease message. Solution 2: Continue using the PTM configuration used in the RRC_CONNECTED state. Solution 3: Obtain an indication from the RRCLease message that tells the UE to obtain the PTM configuration by monitoring the MCCH.

[0068] The impact on signaling interactions between gNB-CU and gNB-DU can be discussed, such as who can decide the PTM configuration transmission method (e.g., gNB-DU or gNB-CU-CP) and who can trigger the generation of PTM configuration (e.g., gNB-DU, gNB-CU-CP) in the RRRCRelease message.

[0069] In some embodiments, the gNB-DU may send information about multicast reception triggered in the RRC_INACTIVE state via F1 signaling.

[0070] (1) Signaling can be performed according to UE.

[0071] ① The information may include at least one of the following:

[0072] 1) Indication information, indicating that the UE is released to the RRC_INACTIVE state to receive multicast.

[0073] 2) PTM configuration information, used to receive multicast in RRC_INACTIVE state.

[0074] a. The configuration information may include at least the lower-level PTM configuration.

[0075] b. Configuration information can be configured on a session-by-session basis.

[0076] 3) Indication information indicating that the PTM configuration used in RRC_CONNECTED can continue to be used in the RRC_INACTIVE state.

[0077] a. Instructions can be given on a session-by-session basis.

[0078] 4) Indication information: The PTM configuration used in the RRC_INACTIVE state can be obtained from the MCCH.

[0079] a. Instructions can be given on a session-by-session basis.

[0080] 5) Cause value, indicating that the reason for releasing the first wireless communication device to the RRC_INACTIVE state is that the first wireless communication device is configured to receive multicast in the RRC_INACTIVE state.

[0081] 6) The cell ID, included in the indication information, is used to indicate which cell to trigger for multicast reception in the RRC_INACTIVE state.

[0082] ②The behavior of the CU when receiving information:

[0083] 1) Considering the above information, the UE can be released to the RRC_INACTIVE state.

[0084] a. It can transmit indication information to the DU, which indicates in which cell the corresponding multicast session can be received in the RRC_INACTIVE state.

[0085] 2) DU may need to always release the UE to the RRC_INACTIVE state.

[0086] 3) The CU can transmit indication information about the PTM configuration used in the RRC_INACTIVE state in the RRC_INACTIVE message.

[0087] a. If the PTM configuration information is carried from the gNB-DU, the CU can transmit the PTM configuration to the UE via the RRRCRelease message.

[0088] b. If the indication information is carried from the gNB-DU, indicating that the PTM configuration used in RRC_CONNECTED can continue to be used in the RRC_INACTIVE state, then the CU can transmit the corresponding indication information to the UE through the RRCRelease message.

[0089] c. If the indication information is carried from the gNB-DU, and the PTM configuration used in the RRC_INACTIVE state can be obtained from the MCCH, then the CU can transmit the corresponding indication information to the UE through the RRCRelease message.

[0090] (2) Signaling can be performed on a session basis.

[0091] ① The information may include at least one of the following:

[0092] 1) Indication information indicating that the session is configured for multicast reception in the RRC_INACTIVE state.

[0093] 2) UE list, in which UEs in the list can be released into the RRC_INACTIVE state to receive multicast.

[0094] a. This can include the resource usage of each UE.

[0095] 3) Cell list, in which cells can be triggered to perform multicast reception in the RRC_INACTIVE state.

[0096] 4) PTM configuration list, where the PTM configurations in this list can be used in the RRC_INACTIVE state.

[0097] a. The cell ID can be included in the PTM configuration, indicating which cell the new configuration applies to.

[0098] 5) A list of instructions indicating that the PTM configuration used in RRC_CONNECTED can continue to be used in the RRC_INACTIVE state.

[0099] a. The cell ID can be included in the instruction information, indicating which cell the instruction applies to.

[0100] 6) Indicator information list, indicating that the PTM configuration used in the RRC_INACTIVE state can (or will) be obtained from the MCCH.

[0101] a. The cell ID can be included in the instruction information, indicating which cell the instruction applies to.

[0102] ②The behavior of the CU when receiving information:

[0103] 1) Considering the above information, the UE can be released to the RRC_INACTIVE state.

[0104] a. It can transmit indication information to the DU, which indicates in which cell the corresponding multicast session is received in the RRC_INACTIVE state.

[0105] 2) DU may need to always release the UE to the RRC_INACTIVE state.

[0106] 3) The CU can transmit indication information about the PTM configuration used in the RRC_INACTIVE state in the RRC_INACTIVE message.

[0107] a. If the PTM configuration information is carried from the gNB-DU, the CU can transmit the PTM configuration to the UE via the RRRCRelease message.

[0108] b. If the indication information is carried from the gNB-DU, indicating that the PTM configuration used in RRC_CONNECTED can continue to be used in the RRC_INACTIVE state, then the CU can transmit the corresponding indication information to the UE through the RRCRelease message.

[0109] c. If the indication information is carried from the gNB-DU, and the PTM configuration used in the RRC_INACTIVE state can be obtained from the MCCH, then the CU can transmit the corresponding indication information to the UE through the RRCRelease message.

[0110] (3) Signaling is about interface management.

[0111] ① The information may include at least one of the following:

[0112] 1) UE list, in which UEs in the list can be released into the RRC_INACTIVE state to receive multicast.

[0113] a. This can include the resource usage of each UE.

[0114] 2) Cell list, where cells in the list can be triggered to perform / support multicast reception in the RRC_INACTIVE state.

[0115] 3) Multicast session list, in which multicast sessions can be received in the RRC_INACTIVE state.

[0116] ②The behavior of the CU when receiving information:

[0117] 1) Taking the above information into account, release the UE to the RRC_INACTIVE state.

[0118] a. It can transmit indication information to the DU, which indicates in which cell the corresponding multicast session can be received in the RRC_INACTIVE state.

[0119] 2) DU may need to always release the UE to the RRC_INACTIVE state.

[0120] In some embodiments, gNB-CU-CP can send (e.g., to a wireless communication device) information about triggering multicast reception in the RRC_INACTIVE state via / using F1 signaling.

[0121] (1) Signaling can be performed according to UE.

[0122] ① The information may include at least one of the following:

[0123] 1) Indication information, indicating that the UE is configured to receive multicast in RRC_INACTIVE state.

[0124] 2) MRB configuration for multicast reception in RRC_INACTIVE state.

[0125] a. The cell ID can be included in the instruction information, which can indicate which cell the configuration applies to.

[0126] ②The behavior of DU when receiving information:

[0127] 1) The response message sent to gNB-CU-CP may include at least one of the following:

[0128] a. Response to accepting or rejecting (the MRB configuration used for establishment).

[0129] b. PTM configuration information, which can be used to receive multicast in the RRC_INACTIVE state.

[0130] a) Configuration information may include at least the lower-level PTM configuration.

[0131] b) Configuration information can be configured on a session-by-session basis.

[0132] c. Indication information indicating that the PTM configuration used in RRC_CONNECTED can continue to be used in the RRC_INACTIVE state.

[0133] a) Instructions can be given on a session-by-session basis.

[0134] d. Indication information indicating that the PTM configuration used in the RRC_INACTIVE state can be obtained from the MCCH.

[0135] a) Instructions can be given on a session-by-session basis.

[0136] ③CU's behavior:

[0137] 1) Taking the above information into account, the wireless communication device can release the UE to the RRC_INACTIVE state.

[0138] 2) It can be determined that the UE will always be released to the RRC_INACTIVE state.

[0139] 3) The CU can transmit / send indication information about the PTM configuration used in the RRC_INACTIVE state in the RRC_REALESS message. Based on the DU's response, if none of the MRBs are successfully established, the CU may not release the UE into the RRC_INACTIVE state. Based on the DU's response, if at least one of the MRBs is successfully established, the CU can release the UE into the RRC_INACTIVE state. Based on the DU's response, if the lower-layer configuration is carried in the DU's response message, the CU can include the lower-layer configuration in the RRC_REALESS message.

[0140] a. If the PTM configuration information is carried from the gNB-DU, the CU can transmit the PTM configuration to the UE via the RRCRelease message or in the RRCRelease message.

[0141] b. If the indication information is carried from the gNB-DU, indicating that the PTM configuration used in RRC_CONNECTED can continue to be used in the RRC_INACTIVE state, then the CU can transmit the corresponding indication information to the UE through the RRCRelease message.

[0142] c. If the indication information is carried from the gNB-DU, and the PTM configuration used in the RRC_INACTIVE state can be obtained from the MCCH, then the CU can transmit the corresponding indication information to the UE via / using the RRCLease message.

[0143] (2) Signaling can be performed on a session basis.

[0144] ① The information may include at least one of the following:

[0145] 1) Indication information indicating that the session is configured for multicast reception in the RRC_INACTIVE state.

[0146] 2) UE list, in which UEs in the list can be released into the RRC_INACTIVE state to receive multicast.

[0147] 3) Cell list, in which cells can be triggered to perform / support multicast reception in RRC_INACTIVE state.

[0148] 4) MRB configuration list, where the MRB configurations in this list can be used in the RRC_INACTIVE state.

[0149] a. The cell ID can be included in the indication information, which indicates which cell the configuration applies to.

[0150] ②The response message from DU to gNB-CU-CP may include at least one of the following:

[0151] 1) Response to accepting or rejecting some / all / no UEs in the UE list.

[0152] 2) Responses to accepting or rejecting some / all / no cells in the UE list.

[0153] 3) Responses to accepting or rejecting some / all / no MRB configurations in the MRB configuration list.

[0154] 4) PTM configuration information, which can be used to receive multicast in the RRC_INACTIVE state.

[0155] a. The configuration information may include at least the lower-level PTM configuration.

[0156] b. Configuration information can be configured on a session-by-session basis.

[0157] 5) Indication information indicating that the PTM configuration used in the RRC_CONNECTED state can continue to be used in the RRC_INACTIVE state.

[0158] a. Instructions can be given on a session-by-session basis.

[0159] 6) Indication information: The PTM configuration used in the RRC_INACTIVE state can be obtained from the MCCH.

[0160] a. Instructions can be given on a session-by-session basis.

[0161] ③CU's behavior:

[0162] 1) Considering the above information, the CU can determine to release the UE to the RRC_INACTIVE state.

[0163] 2) The CU can determine that the UE will always be released to the RRC_INACTIVE state.

[0164] 3) The CU can transmit indication information about the PTM configuration used in the RRC_INACTIVE state in the RRC_REALESS message. Based on the DU's response, if none of the MRBs are successfully established, the CU may not release the UE into the RRC_INACTIVE state. Based on the DU's response, if at least one of the MRBs is successfully established, the CU can release the UE into the RRC_INACTIVE state. Based on the DU's response, if the lower-layer configuration is carried in the DU's response message, the CU can include the lower-layer configuration in the RRC_REALESS message.

[0165] a. If the PTM configuration information is carried from the gNB-DU, the CU can transmit the PTM configuration to the UE via the RRRCRelease message.

[0166] b. If the indication information is carried from the gNB-DU, indicating that the PTM configuration used in RRC_CONNECTED can continue to be used in the RRC_INACTIVE state, then the CU can transmit the corresponding indication information to the UE through the RRCRelease message.

[0167] c. If the indication information is carried from the gNB-DU, and the PTM configuration used in the RRC_INACTIVE state can be obtained from the MCCH, then the CU can transmit the corresponding indication information to the UE through the RRCRelease message.

[0168] gNB-DU triggers multicast reception in RRC_INACTIVE state

[0169] gNB-DU can trigger multicast reception in the RRC_INACTIVE state. To address cell congestion caused by a large number of UEs, multicast reception can be supported in the RRC_INACTIVE state. This embodiment discloses the impact on F1 signaling, such as who can trigger multicast reception in the RRC_INACTIVE state (e.g., gNB-DU or gNB-CU-CP) in a CU-DU segmentation scenario.

[0170] Because the gNB-DU manages the RLC, MAC, and PHY layers of the gNB, it can understand the cell's resource usage. The gNB-DU can trigger multicast reception in the RRC_INACTIVE state.

[0171] UE-associated F1 signaling (DU-driven)

[0172] In one example, the gNB-DU can send information about triggering multicast reception in the RRC_INACTIVE state via the F1 signaling associated with the UE. An example method is as follows.

[0173] Add a new IE (gNB-DU initiated / triggered / driven) in the UE context release request (UE CONTEXT RELEASE REQUEST).

[0174] Add a new IE (gNB-CU initiated / triggered / driven) in the UE context setup response (UE CONTEXT SETUP RESPONSE) or UE context modification response (UE CONTEXT MODIFICATION RESPONSE).

[0175] Define the new UE associated F1 signaling (gNB-DU initiated / triggered / driven).

[0176] Add a new cause value (gNB-DU initiated / triggered / driven) to the UE context release request (UE CONTEXT RELEASE REQUEST).

[0177] In one example, indication information can be carried in the UE-associated F1 signaling from gNB-DU to gNB-CU-CP, indicating that the UE (will) be released into the RRC_INACTIVE state to receive multicast. In another example, if a new PTM configuration for a multicast session is received in the RRC_INACTIVE state, the gNB-DU can send this new PTM configuration to the gNB-CU. Therefore, a PTM configuration that can be used to receive multicast in the RRC_INACTIVE state can be carried in the UE-associated F1 signaling from gNB-DU to gNB-CU-CP. The configuration may include at least a lower-layer PTM configuration. Configuration can be performed on a session-by-session basis.

[0178] In one example, if there is no difference in the PTM configuration between the RRC_INACTIVE and RRC_CONNECTED states, an indication can be carried in the UE-associated F1 signaling from gNB-DU to gNB-CU-CP indicating that the PTM configuration used in the RRC_CONNECTED state can continue to be used in the RRC_INACTIVE state. This indication can be made per session. In another example, if the PTM configuration used in the RRC_INACTIVE state is (only) available from the MCCH message, an indication can be carried in the UE-associated F1 signaling from gNB-DU to gNB-CU-CP indicating that the PTM configuration used in the RRC_INACTIVE state is available from the MCCH.

[0179] In one example, after receiving such information from the gNB-DU via F1 signaling associated with the UE regarding triggering multicast reception in the RRC_INACTIVE state, the gNB-CU may consider whether to release the UE into the RRC_INACTIVE state to receive multicast. Two options are available for the gNB-CU.

[0180] Option 1: Accept the DU's suggestion and release the UE to the RRC_INACTIVE state to receive multicast.

[0181] Option 2: Reject DU's suggestion and keep the UE in the RRC_CONNECTED state to receive multicast.

[0182] In one example, after receiving such information about triggering multicast reception in the RRC_INACTIVE state from the gNB-DU via F1 signaling associated with the UE, the gNB-DU can always release the UE into the RRC_INACTIVE state to receive multicast.

[0183] In one example, if PTM configuration-related information is carried from the gNB-DU via the UE-associated F1 signaling, the gNB-CU can transmit information about the PTM configuration used in the RRC_INACTIVE state in the RRC_INACTIVE message, with three example options provided below.

[0184] If the PTM configuration information is carried from the gNB-DU, the CU can transmit the PTM configuration to the UE via the RRRCRelease message.

[0185] If the indication information is carried from the gNB-DU, indicating that the PTM configuration used in RRC_CONNECTED can continue to be used in the RRC_INACTIVE state, then the CU can transmit the corresponding indication information to the UE through the RRCRelease message.

[0186] If the indication information is carried from the gNB-DU, and the PTM configuration used in the RRC_INACTIVE state can be obtained from the MCCH, then the CU can transmit the corresponding indication information to the UE through the RRCLease message.

[0187] Session-associated F1 signaling (DU driver)

[0188] In one example, the gNB-DU can send information about triggering multicast reception in the RRC_INACTIVE state via session-associated F1 signaling. An example format is shown below.

[0189] Add a new IE in the Multicast Context SETUP RESPONSE or Multicast Context MODIFICATION RESPONSE.

[0190] Define the F1 signaling associated with the new multicast session (initiated by gNB-DU).

[0191] In one example, the indication information indicates that the session is configured for multicast reception in the RRC_INACTIVE state. In one example, a UE list may be carried in the session-associated F1 signaling from gNB-DU to gNB-CU-CP, where UEs in the list are released to the RRC_INACTIVE state to receive multicast. In one example, a cell list may be carried in the session-associated F1 signaling from gNB-DU to gNB-CU-CP, where cells in the list are triggered for multicast reception in the RRC_INACTIVE state. In one example, if a new PTM configuration for a multicast session is received in the RRC_INACTIVE state, the gNB-DU may send the new PTM configuration to the gNB-CU. Therefore, a list of PTM configurations may be carried in the session-associated F1 signaling from gNB-DU to gNB-CU-CP, where the PTM configurations in the list can be used to receive multicast in the RRC_INACTIVE state. The configuration may include at least a lower-layer PTM configuration. A cell ID may be included in the PTM configuration, indicating which cell the new configuration applies to.

[0192] In one example, if there is no difference in the PTM configuration between the RRC_INACTIVE and RRC_CONNECTED states, a list of indication information can be carried in the F1 signaling associated with the session from gNB-DU to gNB-CU-CP. This list of indication information indicates that the PTM configuration used in RRC_CONNECTED can continue to be used in the RRC_INACTIVE state. The cell ID can be included in the indication information, indicating which cell the indication applies to.

[0193] In one example, if the PTM configuration used in the RRC_INACTIVE state is or can only be obtained from the MCCH message, a list of indication information can be carried in the session-associated F1 signaling from the gNB-DU to the gNB-CU-CP. This list of indication information indicates that the PTM configuration used in the RRC_INACTIVE state is available from the MCCH. The cell ID can be included in the indication information, indicating which cell the indication applies to. In one example, after receiving such information from the gNB-DU via session-associated F1 signaling regarding triggering multicast reception in the RRC_INACTIVE state, the gNB-CU can consider whether to release the UE into the RRC_INACTIVE state to receive multicast. Several options are possible, such as the following two example options for the gNB-CU.

[0194] Option 1: Accept the DU's suggestion and release the UE to the RRC_INACTIVE state to receive multicast.

[0195] Option 2: Reject DU's suggestion and keep the UE in the RRC_CONNECTED state to receive multicast.

[0196] In one example, to inform the DU which cells are receiving the corresponding multicast session in the RRC_INACTIVE state, an indication message can be sent to the DU indicating which cells are receiving the corresponding multicast session in the RRC_INACTIVE state. In another example, after receiving such information from the gNB-DU via session-associated F1 signaling regarding triggering multicast reception in the RRC_INACTIVE state, the gNB-CU can always release the UEs in the list to the RRC_INACTIVE state to receive multicast.

[0197] In one example, if PTM configuration-related information is carried from the gNB-DU via session-associated F1 signaling, the gNB-CU can transmit information about the PTM configuration used in the RRC_INACTIVE state in the RRC_INACTIVE message according to one or more of the following options.

[0198] If the PTM configuration information is carried from the gNB-DU, the CU can transmit the PTM configuration to the UE via the RRRCRelease message.

[0199] If the indication information is carried from the gNB-DU, indicating that the PTM configuration used in RRC_CONNECTED can continue to be used in the RRC_INACTIVE state, then the CU can transmit the corresponding indication information to the UE through the RRCRelease message.

[0200] If the indication information is carried from the gNB-DU, and the PTM configuration used in the RRC_INACTIVE state can be obtained from the MCCH, then the CU can transmit the corresponding indication information to the UE through the RRCLease message.

[0201] Interface Management F1 Signaling (DU Driver)

[0202] In one example, the gNB-DU can send information about triggering multicast reception in the RRC_INACTIVE state via interface management F1 signaling (e.g., adding a new IE in the resource status response). To achieve this, a new bit is added to the report feature IE in the resource status request from the gNB-CU. If the new bit is set to 1, the gNB-DU can send information about triggering multicast reception in the RRC_INACTIVE state via interface management F1 signaling.

[0203] In one example, a UE list can be carried in the interface management F1 signaling from gNB-DU to gNB-CU-CP, where UEs in the list are released to the RRC_INACTIVE state to receive multicast. Resource usage for each UE can be included in the UE list.

[0204] In one example, a cell list can be carried in the interface management F1 signaling from gNB-DU to gNB-CU-CP, where cells in the list are triggered to perform multicast reception in the RRC_INACTIVE state. In another example, a session list can be carried in the interface management F1 signaling from gNB-DU to gNB-CU-CP, where sessions in the list are triggered to perform multicast reception in the RRC_INACTIVE state.

[0205] In one example, after receiving such information from the gNB-DU via interface management F1 signaling regarding triggering multicast reception in the RRC_INACTIVE state, the gNB-CU may consider whether to release the UE into the RRC_INACTIVE state to receive multicast. Various options are possible, such as the following two example options for the gNB-CU.

[0206] Option 1: Accept the DU's suggestion and release the UE to the RRC_INACTIVE state to receive multicast.

[0207] Option 2: Reject DU's suggestion and keep the UE in the RRC_CONNECTED state to receive multicast.

[0208] In one example, to let the DU know which multicast sessions are being received in which cells under the RRC_INACTIVE state, an indication message can be sent to the DU indicating which multicast sessions are being received in which cells under the RRC_INACTIVE state.

[0209] In one example, after receiving such information from the gNB-DU via the interface management F1 signaling regarding multicast reception in the RRC_INACTIVE state, the gNB-CU can always release the UEs in the list into the RRC_INACTIVE state to receive multicast.

[0210] gNB-DU triggers multicast reception in RRC_INACTIVE state

[0211] UE-associated F1 signaling (CU-driven)

[0212] In one example, the gNB-CU can send information about triggering multicast reception in the RRC_INACTIVE state via the UE-associated F1 signaling. Example methods may include the following.

[0213] Add a new IE (initiated by gNB-CU) in the UE context setup request (UE CONTEXT SETUP REQUEST) or UE context modification request (UE CONTEXT MODIFICATION REQUEST).

[0214] Add a reason value indicating that the reason for releasing the first wireless communication device to the RRC_INACTIVE state is that the first wireless communication device is configured to receive multicast in the RRC_INACTIVE state.

[0215] Define a new UE associated F1 signaling (initiated by gNB-CU).

[0216] In one example, indication information can be carried in the UE-associated F1 signaling from gNB-CU to gNB-DU, indicating that the UE is released to the RRC_INACTIVE state to receive multicast. In another example, an MRB configuration for multicast reception in the RRC_INACTIVE state can be carried in the UE-associated F1 signaling from gNB-CU to gNB-DU. The cell ID can be included in the MRB configuration information. The cell ID can indicate which cell the configuration applies to. The cell ID can also indicate which cell is configured for multicast reception in the RRC_INACTIVE state.

[0217] In one example, after receiving such information about triggering multicast reception in the RRC_INACTIVE state from the gNB-CU via F1 signaling associated with the UE, a response for MRB configuration establishment can be sent back to the gNB-CU. Various options are available, including the following three.

[0218] All multicast MRBs have been successfully established.

[0219] Some requests' multicast MRBs were successfully established, while others failed to be established.

[0220] All requested multicast MRBs failed to be established.

[0221] In one example, after receiving such information about triggering multicast reception in the RRC_INACTIVE state from the gNB-CU via UE-associated F1 signaling, if a new PTM configuration for a multicast session is received in the RRC_INACTIVE state, the gNB-DU can send this new PTM configuration to the gNB-CU. Therefore, the PTM configuration for receiving multicast in the RRC_INACTIVE state can be carried in the UE-associated F1 signaling from the gNB-DU to the gNB-CU-CP. The configuration may include at least a lower-layer PTM configuration. Configuration can be performed on a session-by-session basis.

[0222] In one example, after receiving such information about triggering multicast reception in the RRC_INACTIVE state from the gNB-CU via UE-associated F1 signaling, if there is no difference in the PTM configuration between the RRC_INACTIVE and RRC_CONNECTED states, an indication can be carried in the UE-associated F1 signaling from the gNB-DU to the gNB-CU-CP. This indication indicates that the PTM configuration used in the RRC_CONNECTED state can continue to be used in the RRC_INACTIVE state. The indication can be made per session.

[0223] In one example, after receiving such information about triggering multicast reception in the RRC_INACTIVE state from the gNB-CU via UE-associated F1 signaling, if the PTM configuration used in the RRC_INACTIVE state is (only) available from the MCCH message, an indication message can be carried in the UE-associated F1 signaling from the gNB-DU to the gNB-CU-CP indicating that the PTM configuration used in the RRC_INACTIVE state is available from the MCCH.

[0224] In one example, after receiving such a response from the gNB-DU via F1 signaling associated with the UE regarding triggering multicast reception in the RRC_INACTIVE state, the gNB-CU may consider whether to release the UE into the RRC_INACTIVE state to receive multicast. Various options are possible, such as the following two example options for the gNB-CU.

[0225] Option 1: Accept the DU's suggestion and release the UE to the RRC_INACTIVE state to receive multicast.

[0226] Option 2: Reject DU's suggestion and keep the UE in the RRC_CONNECTED state to receive multicast.

[0227] In one example, after receiving such a response message from the gNB-DU via UE-associated F1 signaling regarding triggering multicast reception in the RRC_INACTIVE state, the gNB-CU can always release the UE into the RRC_INACTIVE state to receive multicast. In another example, if PTM configuration-related information is carried from the gNB-DU via UE-associated F1 signaling, the gNB-CU can transmit information about the PTM configuration used in the RRC_INACTIVE state in the RCRelease message, with various (e.g., three) options as follows.

[0228] If the PTM configuration information is carried from the gNB-DU, the CU can transmit the PTM configuration to the UE via the RRRCRelease message.

[0229] If the indication information is carried from the gNB-DU, indicating that the PTM configuration used in RRC_CONNECTED can continue to be used in the RRC_INACTIVE state, then the CU can transmit the corresponding indication information to the UE through the RRCRelease message.

[0230] If the indication information is carried from the gNB-DU, and the PTM configuration used in the RRC_INACTIVE state can be obtained from the MCCH, then the CU can transmit the corresponding indication information to the UE through the RRCLease message.

[0231] Session-associated F1 signaling (CU-driven)

[0232] In one example, the gNB-CU can send information about triggering multicast reception in the RRC_INACTIVE state via session-associated F1 signaling. Example methods may include one or more of the following.

[0233] Add a new IE to the Multicast Context SETUP REQUEST or Multicast Context MODIFICATION REQUEST.

[0234] Define the F1 signaling associated with the new multicast session (initiated by gNB-CU).

[0235] In one example, the F1 signaling associated with the session from gNB-CU to gNB-DU may carry indication information indicating that the session is configured for multicast reception in the RRC_INACTIVE state. In another example, the F1 signaling associated with the session from gNB-CU to gNB-DU may carry a UE list, where UEs in the list are released to the RRC_INACTIVE state to receive multicast. In yet another example, the F1 signaling associated with the session from gNB-CU to gNB-DU may carry a cell list, where cells in the list are triggered to perform multicast reception in the RRC_INACTIVE state.

[0236] In one example, an MRB configuration list can be carried in the session-associated F1 signaling from gNB-CU to gNB-DU, where the MRB configurations in the list can be used for multicast reception in the RRC_INACTIVE state. A cell ID can be included in the MRB configuration information, indicating which cell the MRB configuration applies to. In one example, after receiving such information from gNB-CU via session-associated F1 signaling regarding triggering multicast reception in the RRC_INACTIVE state, a response for accepting or rejecting some / all / no UEs in the UE list can be sent back to gNB-CU.

[0237] In one example, after receiving such information from the gNB-CU via session-associated F1 signaling regarding multicast reception triggered in the RRC_INACTIVE state, a response established for the MRB configuration (e.g., accepting or rejecting some / all / no MRB configurations in the MRB configuration list) can be sent back to the gNB-CU. Various options are possible, such as one or more of the following.

[0238] All multicast MRBs have been successfully established.

[0239] Some requests' multicast MRBs were successfully established, while others failed to be established.

[0240] All requested multicast MRBs failed to be established.

[0241] In one example, after receiving such information about triggering multicast reception in the RRC_INACTIVE state from the gNB-CU via session-associated F1 signaling, if a new PTM configuration for the multicast session is received in the RRC_INACTIVE state, the gNB-DU can send that new PTM configuration to the gNB-CU. Therefore, a list of PTM configurations for receiving multicast in the RRC_INACTIVE state can be carried in the session-associated F1 signaling from the gNB-DU to the gNB-CU-CP. The configuration may include at least a lower-layer PTM configuration. A cell ID may be included in the PTM configuration, indicating which cell the new configuration applies to.

[0242] In one example, after receiving such information about triggering multicast reception in the RRC_INACTIVE state from the gNB-CU via UE-associated F1 signaling, if there is no difference in the PTM configuration between the RRC_INACTIVE and RRC_CONNECTED states, a list of indication information can be carried in the session-associated F1 signaling from the gNB-DU to the gNB-CU-CP. This list of indication information indicates that the PTM configuration used in the RRC_CONNECTED state can continue to be used in the RRC_INACTIVE state. The cell ID can be included in the PTM configuration, indicating which cell the new configuration applies to.

[0243] In one example, after receiving such information about triggering multicast reception in the RRC_INACTIVE state from gNB-CU via session-associated F1 signaling, if the PTM configuration used in the RRC_INACTIVE state is (only) available from the MCCH message, an indication message can be carried in the session-associated F1 signaling from gNB-DU to gNB-CU-CP indicating that the PTM configuration used in the RRC_INACTIVE state is available from the MCCH.

[0244] The cell ID can be included in the PTM configuration, and this cell ID indicates which cell the new configuration applies to.

[0245] In one example, after receiving such a response from the gNB-DU via session-associated F1 signaling regarding triggering multicast reception in the RRC_INACTIVE state, the gNB-CU may consider whether to release the UE into the RRC_INACTIVE state to receive multicast. The gNB-CU may have various options, such as the following.

[0246] Option 1: Accept the DU's suggestion and release the UE to the RRC_INACTIVE state to receive multicast.

[0247] Option 2: Reject DU's suggestion and keep the UE in the RRC_CONNECTED state to receive multicast.

[0248] In one example, after receiving such a response message from the gNB-DU via session-associated F1 signaling regarding triggering multicast reception in the RRC_INACTIVE state, the gNB-CU can (always) release the UE into the RRC_INACTIVE state to receive multicast. In another example, if PTM configuration-related information is carried from the gNB-DU via session-associated F1 signaling, the gNB-CU can transmit information about the PTM configuration used in the RRC_INACTIVE state in the RRCCRelease message, with various options, such as the following three.

[0249] If the PTM configuration information is carried from the gNB-DU, the CU can transmit the PTM configuration to the UE via the RRRCRelease message.

[0250] If the indication information is carried from the gNB-DU, indicating that the PTM configuration used in RRC_CONNECTED can continue to be used in the RRC_INACTIVE state, then the CU can transmit the corresponding indication information to the UE through the RRCRelease message.

[0251] If the indication information is carried from the gNB-DU, and the PTM configuration used in the RRC_INACTIVE state can be obtained from the MCCH, then the CU can transmit the corresponding indication information to the UE through the RRCLease message.

[0252] Example 3 of implementation: Interaction between CU-CP and CU-UP for multicast reception in RRC_INACTIVE state mutual

[0253] To help CU-UP better control multicast session resources, CU-CP can notify CU-UP of session status / configuration status.

[0254] The CU-CP can send session status / configuration status to the CU-UP via E1 signaling for each session. To support the transmission / sending of PTM configurations for inactive sessions allowed to be received in the RRC_INACTIVE state via RRCLease messages, the gNB-CU-CP can establish a multicast bearer context at the gNB-CU-UP. This embodiment discusses whether session status can be provided to the gNB-CU-UP.

[0255] If gNB-CU-UP can distinguish / identify pre-configurations for inactive multicast sessions, it can better control multicast session resources:

[0256] These pre-configured resources can be released first when resources are insufficient.

[0257] If resources are sufficient, gNB-CU-UP may not release these pre-configured settings if there is no data transmission for an extended period of time.

[0258] In one example, an indication (e.g., 1 bit in an MC Bearer Context SETUP REQUEST / MC Bearer Context MODIFICATION REQUEST) can be added to the E1 signaling from gNB-CU-CP for each session. This indication can be used to notify that the gNB-CU-UP multicast session is inactive and that a certain configuration is pre-configured. The context / content of the indication can be the session state (in progress / inactive / active / inactive) or the configuration state (pre-configured or not pre-configured).

[0259] It should be understood that one or more features from the above implementation examples are not exclusive to the specific implementation examples, but can be combined in any way (e.g., in any priority and / or order, concurrently or otherwise).

[0260] Figure 3 A flowchart of a method 300 for supporting multicast reception in the RRC_INACTIVE state is shown. Method 300 may utilize any one or more of the components and apparatus described in detail herein. Figures 1 to 2 This is implemented in a manner that, in general, in some embodiments, method 300 may be performed by the CU or DU of a wireless communication node (e.g., a base station). Depending on the embodiment, additional, fewer, or different operations may be performed in method 300. At least one aspect of the operations relates to a system, method, apparatus, or computer-readable medium.

[0261] A CU of a wireless communication node (e.g., a BS) can send a first signaling message to a DU of the same wireless communication node. This first signaling message includes information about multicast reception by at least a first wireless communication device (e.g., a UE) in the RRC_INACTIVE state. The CU can receive a second signaling message from the DU in response to the first signaling message. The first signaling message can be used for the first wireless communication device (e.g., for each UE or specific to a UE). The information can include at least one of the following: indication information indicating that the first wireless communication device will be configured for multicast reception in the RRC_INACTIVE state; an MRB configuration for multicast reception in the RRC_INACTIVE state; or a cell ID included in the indication information, indicating which cell the configuration applies to. The second signaling message can include at least one of the following: information about the establishment of the MRB configuration; PTM configuration information for multicast reception in the RRC_INACTIVE state; or indication information. The PTM configuration information can include lower-level PTM configurations. The PTM configuration information can be used for a session (e.g., for each session or specific to a session). The indication information can indicate that the PTM configuration used in the RRC_CONNECTED state will continue to be used in the RRC_INACTIVE state. The indication information can indicate that the PTM configuration to be used in the RRC_INACTIVE state will be acquired / received via the MCCH. The indication information can be used for sessions. The cell ID can indicate which cell the configuration applies to. The cell ID can indicate which cell is configured for multicast reception in the RRC_INACTIVE state.

[0262] In some embodiments, the CU can determine to release the first wireless communication device into the RRC_INACTIVE state based on the second signaling. The CU can send an RRCLease message to the first wireless communication device, wherein the RRCLease message includes indication information indicating the PTM configuration to be used in the RRC_INACTIVE state. The CU's control plane can send information about multicast reception in the RRC_INACTIVE state to the CU's user plane in E1 signaling for the session. Taking the above information into account, the CU can release the UE into the RRC_INACTIVE state. In this case, the second signaling can be a suggestion. The CU can accept or reject the suggestion. In some embodiments, the CU can always release the UE into the RRC_INACTIVE state according to the DU's request. In this case, the second signaling can be a command. The CU can only accept the command.

[0263] In some embodiments, the first signaling may be used for a session (e.g., for each session or specific to a session). The information may include at least one of the following: indication information indicating that the session will be configured for multicast reception in the RRC_INACTIVE state; a list of wireless communication devices to be released to the RRC_INACTIVE state for multicast reception; a list of cells to be triggered for multicast reception in the RRC_INACTIVE state; a list of MRB configurations to be used in the RRC_INACTIVE state; or an indication of at least one cell associated with at least one of the MRB configurations. A mapping relationship may exist between at least one cell and at least one of the MRB configurations. The second signaling may include at least one of the following: a response to accept or reject some / all / none of the list of wireless communication devices; a response to accept or reject some / all / none of the list of cells; a response to accept or reject some / all / none of the list of MRB configurations; PTM configuration information used for multicast reception in the RRC_INACTIVE state; or indication information. The PTM configuration information may include lower-level PTM configurations. The PTM configuration information may be used for the session. The indication information can indicate that the PTM configuration used in the RRC_CONNECTED state will continue to be used in the RRC_INACTIVE state. The indication information can also indicate that the PTM configuration to be used in the RRC_INACTIVE state will be obtained via the MCCH. The indication information can be used for sessions. The DU can accept or reject some UEs in the list. The CU can provide a list of UEs / cells / MRBs planned for receiving multicast in the RRC_INACTIVE state. The DU can have the right to accept or reject any part of the list, and therefore the DU can provide a response message.

[0264] In some embodiments, the CU can determine, based on a second signaling, to release the first wireless communication device into the RRC_INACTIVE state. The CU can send an RRCRelease message to the first wireless communication device, wherein the RRCRelease message includes indication information indicating the PTM configuration to be used in the RRC_INACTIVE state. The CU's control plane (e.g., CU-CP) can send information about multicast reception in the RRC_INACTIVE state to the CU's user plane (e.g., CU-UP) in E1 signaling for the session.

[0265] In some embodiments, if the second signaling includes PTM configuration information, the CU may incorporate / insert / include / carry / send the PTM configuration in the RRC_INACTIVE message. If the second signaling includes indication that the PTM configuration used in the RRC_CONNECTED state will continue to be used in the RRC_INACTIVE state, the CU may incorporate / insert / include / carry / send this indication in the RRC_INACTIVE message. If the second signaling includes indication that the PTM configuration used in the RRC_INACTIVE state will be obtained via the MCCH, the CU may incorporate / insert / include / carry this indication in the RRC_INACTIVE message. The CU may incorporate / insert / include / carry / send a first indication for the session in the RRC_INACTIVE message to indicate whether the wireless communication device will (or may) monitor G-RNTI immediately after transitioning to the RRC_INACTIVE state. The CU can merge / insert / include / carry the cell ID from the PTM configuration information in the RRCrease message.

[0266] In some embodiments, the first indication may indicate whether the session state is inactive or active. If the session state is active, the wireless communication device will (or may) monitor G-RNTI for multicast reception after transitioning to the RRC_INACTIVE state. If the session state is inactive, the first wireless communication device will not (or may not) monitor G-RNTI after transitioning to the RRC_INACTIVE state until it receives a corresponding activation indication from the wireless communication node.

[0267] In some embodiments, the first indication may indicate a PTM configuration. The PTM configuration may include at least one of the following: a pre-configuration used when a session is activated, or an in-process configuration used immediately after transitioning to the RRC_INACTIVE state to receive the corresponding active session. If the PTM configuration includes a pre-configuration, the first wireless communication device will (or may) store the pre-configuration, and / or will not use the pre-configuration to monitor G-RNTI after transitioning to the RRC_INACTIVE state until it receives the corresponding activation indication from the wireless communication node. If the PTM configuration includes an in-process configuration, the first wireless communication device will (or may) use the in-process configuration to monitor G-RNTI immediately after transitioning to the RRC_INACTIVE state.

[0268] In some embodiments, the first indication may indicate the behavior of the first wireless communication device in the RRC_INACTIVE state. The behavior may include the first wireless communication device monitoring G-RNTI immediately after transitioning to the RRC_INACTIVE state. The behavior may also include the first wireless communication device not monitoring G-RNTI until receiving a corresponding activation indication from the wireless communication node after transitioning to the RRC_INACTIVE state. In some embodiments, the information may include at least one of the following: session state, including inactive or active; or configuration state, including pre-configured or in-process configuration.

[0269] In some embodiments, the CU may send an RRCRelease message, including a first indication for the session, to the first wireless communication device. The first indication may be used to indicate whether the wireless communication device should (or may) monitor the G-RNTI in the RRC_INACTIVE state. The first indication may indicate whether the session state is inactive or active. If the session state is active, the wireless communication device will (or may) monitor the G-RNTI for multicast reception after transitioning to the RRC_INACTIVE state. If the session state is inactive, the first wireless communication device will not (or may not) monitor the G-RNTI after transitioning to the RRC_INACTIVE state until it receives a corresponding activation indication from the wireless communication node.

[0270] In some embodiments, the first indication may indicate a PTM configuration. The PTM configuration (state) may include at least one of the following: a pre-configuration used upon session activation, or an in-process configuration for monitoring the session immediately after transitioning to the RRC_INACTIVE state. If the PTM configuration includes a pre-configuration, the first wireless communication device will (or may) store the pre-configuration, and / or will not use the pre-configuration to monitor G-RNTI after transitioning to the RRC_INACTIVE state until it receives a corresponding activation indication from the wireless communication node. The UE may not immediately monitor G-RNTI after transitioning to the RRC_INACTIVE state. If the UE receives an indication regarding session activation, the UE may begin monitoring G-RNTI. If the PTM configuration includes an in-process configuration, the first wireless communication device will (or may) immediately use the in-process configuration to monitor G-RNTI after transitioning to the RRC_INACTIVE state.

[0271] In some embodiments, the first indication may indicate the behavior of the first wireless communication device in the RRC_INACTIVE state. The behavior may include the first wireless communication device monitoring G-RNTI immediately after transitioning to the RRC_INACTIVE state. The behavior may also include the first wireless communication device not monitoring G-RNTI after transitioning to the RRC_INACTIVE state until receiving a corresponding activation indication from the wireless communication node.

[0272] The CU can merge the cell ID from the PTM configuration information into the RRRCRelease message.

[0273] In some embodiments, the control plane of the CU can send session status and / or configuration status to the user plane of the CU in E1 signaling for the session.

[0274] In some embodiments, the DU of a wireless communication node (e.g., a base station) can receive a first signaling from the CU of the wireless communication node. This first signaling includes information about multicast reception by at least a first wireless communication device (e.g., a UE) in the RRC_INACTIVE state. The DU can then send a second signaling to the CU in response to the first signaling.

[0275] While various embodiments of the present solution have been described above, it should be understood that they are presented by way of example only and not by way of limitation. Similarly, the various figures may depict exemplary architectures or configurations provided to enable those skilled in the art to understand exemplary features and functionality of the present solution. However, those skilled in the art will understand that the solution is not limited to the exemplary architectures or configurations shown, but can be implemented using various alternative architectures and configurations. Furthermore, as those skilled in the art will understand, one or more features of one embodiment may be combined with one or more features of another embodiment described herein. Therefore, the breadth and scope of this disclosure should not be limited to any of the illustrative embodiments described above.

[0276] It should also be understood that any reference to elements in this document using names such as “first”, “second”, etc., generally does not restrict the number or order of those elements. Rather, these names may be used herein as a convenient means of distinguishing two or more elements or instances of elements. Therefore, references to the first element and the second element do not imply that only two elements may be used, or that the first element must somehow precede the second element.

[0277] Furthermore, those skilled in the art will understand that information and signals can be represented using any of a variety of different techniques and skills. For example, data, instructions, commands, information, signals, bits, and symbols that may be referenced in the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or light particles, or any combination thereof.

[0278] Those skilled in the art will further understand that any of the illustrative logic blocks, modules, processors, devices, circuits, methods, and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., digital implementation, analog implementation, or a combination of both), firmware, design code of various forms of programs or integrated instructions (which may be referred to herein as "software" or "software module" for convenience), or any combination of these technologies. To clearly illustrate this interchangeability of hardware, firmware, and software, the illustrative components, blocks, modules, circuits, and steps have been described above in general terms of their functionality. Whether such functionality is implemented as hardware, firmware, or software, or a combination of these technologies, depends on the specific application and the design constraints imposed on the system as a whole. Those skilled in the art can implement the described functionality in various ways for each specific application, but such implementation decisions do not depart from the scope of this disclosure.

[0279] Furthermore, those skilled in the art will understand that the various illustrative logic blocks, modules, devices, components, and circuits described herein can be implemented within or executed by an integrated circuit (IC), which may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, or any combination thereof. Logic blocks, modules, and circuits may also include antennas and / or transceivers for communicating with various components within a network or device. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors incorporating a DSP core, or any other suitable configuration for performing the functions described herein.

[0280] If implemented in software, these functions can be stored as one or more instructions or code on a computer-readable medium. Therefore, the steps of the methods or algorithms disclosed herein can be implemented as software stored on a computer-readable medium. Computer-readable media include both computer storage media and communication media, with communication media including any medium that enables the transfer of computer programs or code from one place to another. Storage media can be any available medium that is accessible to a computer. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, disk storage devices, or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and is accessible to a computer.

[0281] In this document, the term "module" as used herein refers to software, firmware, hardware, and any combination of such elements for performing the associated functions described herein. Furthermore, for purposes of discussion, individual modules are described as discrete modules; however, as will be apparent to those skilled in the art, two or more modules may be combined to form a single module that performs the associated functions according to embodiments of this solution.

[0282] Additionally, in embodiments of this solution, memory or other storage devices and communication components may be employed. It should be understood that, for clarity, embodiments of this solution have been described above with reference to different functional units and processors. However, it will be apparent that any suitable functional distribution among different functional units, processing logic elements, or domains may be used without departing from this solution. For example, functions shown to be performed by separate processing logic elements or controllers may be performed by the same processing logic element or controller. Therefore, references to specific functional units are merely references to suitable means for providing the described functions and not indications of a strict logical or physical structure or organization.

[0283] Various modifications to the embodiments described in this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the novel features and principles disclosed herein, as set forth in the appended claims.

Claims

1. A method comprising: A first signaling instruction is sent from the centralized unit (CU) to the distributed unit (DU) of the wireless communication node, wherein the first signaling instruction includes information regarding multicast reception of at least the first wireless communication device in the Radio Resource Control (RRC) inactive_INACTIVE state; and The CU receives a second signaling in response to the first signaling from the DU.

2. The method according to claim 1, wherein, The first signaling is used by the first wireless communication device.

3. The method according to claim 2, wherein, The first signaling includes at least one of the following: Indication information indicating that the first wireless communication device is configured for multicast reception in the RRC_INACTIVE state; The cause value indicates that the reason for releasing the first wireless communication device to the RRC_INACTIVE state is that the first wireless communication device is configured to receive multicast in the RRC_INACTIVE state; Multicast radio bearer (MRB) configuration for multicast reception in the RRC_INACTIVE state; or The cell identifier ID, included in the indication information, is used to indicate which cell to trigger for multicast reception in the RRC_INACTIVE state.

4. The method according to claim 2, wherein, The second signaling includes at least one of the following: Information regarding the establishment of a multicast radio bearer (MRB) configuration; Point-to-multipoint (PTM) configuration information for multicast reception in the RRC_INACTIVE state, wherein at least one of the following is included: The PTM configuration information includes the lower-level PTM configuration; or The PTM configuration information is used for the session; or Instruction information, wherein at least one of the following: The indication information indicates that the PTM configuration used in the Radio Resource Control (RRC) connection RRC_CONNECTED state will continue to be used in the RRC_INACTIVE state; The indication information indicates that the PTM configuration to be used in the RRC_INACTIVE state will be obtained through the Multicast-Broadcast Service Control Channel (MCCH); or The instruction information is used in the session.

5. The method according to claim 2 or 3, comprising at least one of the following: The CU determines, based on the second signaling, to release the first wireless communication device into the RRC_INACTIVE state; The CU sends a Radio Resource Control Release (RRCRelease) message to the first wireless communication device, wherein... The RRCRelease message includes indication information indicating the point-to-multipoint PTM configuration to be used in the RRC_INACTIVE state; or The control plane of the CU sends the information about multicast reception in the RRC_INACTIVE state to the user plane of the CU in E1 signaling for the session.

6. The method according to claim 1, wherein, The first signaling is used for the session.

7. The method according to claim 6, wherein, The information includes at least one of the following: Indication information indicating that the session is configured for multicast reception in the RRC_INACTIVE state; The list of wireless communication devices added to the session will be released to the RRC_INACTIVE state for multicast reception; A list of cells for which multicast reception is triggered in the RRC_INACTIVE state for the session; or A list of MRB configurations for the multicast radio bearer to be used in the RRC_INACTIVE state; or An indication of at least one cell associated with at least one of the MRB configurations.

8. The method according to claim 6, wherein, The second signaling includes at least one of the following: A response to accepting or rejecting one or more wireless communication devices in a list of wireless communication devices; A response to accepting or rejecting one or more cells in the cell list; A response indicating acceptance or rejection of one or more MRB configurations in the list of MRB configurations; Point-to-multipoint (PTM) configuration information for multicast reception in the RRC_INACTIVE state, wherein at least one of the following is included: The PTM configuration information includes the lower-level PTM configuration; or The PTM configuration information is used for the session; or Instruction information, wherein at least one of the following: The indication information indicates that the PTM configuration used in the RRC_CONNECTED state will continue to be used in the RRC_INACTIVE state; The indication information indicates that the PTM configuration to be used in the RRC_INACTIVE state will be obtained through the Multicast-Broadcast Service Control Channel (MCCH); or The instruction information is used in the session.

9. The method according to claim 6 or 7, comprising at least one of the following: The CU determines, based on the second signaling, to release the first wireless communication device into the RRC_INACTIVE state; The CU sends an RRRCRelease message to the first wireless communication device, wherein... The RRCRelease message includes indication information indicating the point-to-multipoint PTM configuration to be used in the RRC_INACTIVE state; or The control plane of the CU sends the information about multicast reception in the RRC_INACTIVE state to the user plane of the CU in E1 signaling for the session.

10. The method according to claim 5 or 9, comprising at least one of the following: If the second signaling includes the PTM configuration information, then the CU will incorporate the PTM configuration into the RRRCRelease message; If the second signaling includes indication information indicating that the PTM configuration used in the RRC_CONNECTED state will continue to be used in the RRC_INACTIVE state, then the CU will incorporate the indication information indicating that the PTM configuration used in the RRC_CONNECTED state will continue to be used in the RRC_INACTIVE state into the RRCRelease message; or If the second signaling includes indication information indicating that the PTM configuration used in the RRC_CINACTIVE state will be obtained through the MCCH, then the CU will incorporate the indication information indicating that the PTM configuration used in the RRC_CINACTIVE state will be obtained through the MCCH into the RRCRelease message; The CU incorporates a first indication for the session into the RRCRelease message to indicate whether the wireless communication device will immediately monitor the Group Radio Network Temporary Identifier (G-RNTI) in the RRC_INACTIVE state; or The CU merges the cell identifier ID from the PTM configuration information into the RRCRelease message.

11. The method according to claim 10, wherein, At least one of the following: The first indication is used to indicate whether the session state is inactive or active; If the session state is active, the wireless communication device immediately monitors G-RNTI for multicast reception after transitioning to the RRC_INACTIVE state; or If the session state is inactive, the first wireless communication device will not monitor the G-RNTI after transitioning to the RRC_INACTIVE state until it receives the corresponding activation indication from the wireless communication node.

12. The method according to claim 10, wherein, At least one of the following: The first indication is used to indicate the PTM configuration, wherein the PTM configuration includes at least one of the following: a pre-configuration used when the session is activated, or an in-process configuration used to receive the corresponding active session immediately after transitioning to the RRC_INACTIVE state; If the PTM configuration includes the pre-configuration, the first wireless communication device will store the pre-configuration and, after transitioning to the RRC_INACTIVE state, will not use the pre-configuration to monitor the G-RNTI until a corresponding activation indication is received from the wireless communication node; or If the PTM configuration includes the in-progress configuration, the first wireless communication device will immediately use the in-progress configuration to monitor the G-RNTI after transitioning to the RRC_INACTIVE state.

13. The method according to claim 10, wherein, At least one of the following: The first indication is used to indicate the behavior of the first wireless communication device in the RRC_INACTIVE state; The behavior includes the first wireless communication device monitoring the G-RNTI immediately after transitioning to the RRC_INACTIVE state; or The behavior includes the first wireless communication device not monitoring the G-RNTI after transitioning to the RRC_INACTIVE state until it receives a corresponding activation indication from the wireless communication node.

14. The method according to claim 5 or 9, wherein, The information includes at least one of the following: session state, including inactive or active; or configuration state, including pre-configured or in-process configuration.

15. The method according to claim 1, comprising: The CU sends a Radio Resource Control Release (RRCRelease) message to the first wireless communication device, wherein the RRCRelease message includes a first indication for the session, the first indication indicating whether the wireless communication device will monitor the Group Radio Network Temporary Identifier (G-RNTI) in the RRC_INACTIVE state.

16. The method according to claim 15, wherein, At least one of the following: The first indication is used to indicate whether the session state is inactive or active; If the session state is active, the wireless communication device immediately monitors G-RNTI for multicast reception after transitioning to the RRC_INACTIVE state; or If the session state is inactive, the first wireless communication device will not monitor the G-RNTI after transitioning to the RRC_INACTIVE state until it receives the corresponding activation indication from the wireless communication node.

17. The method according to claim 15, wherein, At least one of the following: The first indication is used to indicate a point-to-multipoint (PTM) configuration, wherein the PTM configuration includes at least one of the following: a pre-configuration used when a session is activated, or an in-process configuration that begins monitoring the session immediately after transitioning to the RRC_INACTIVE state; If the PTM configuration includes the pre-configuration, the first wireless communication device will store the pre-configuration and, after transitioning to the RRC_INACTIVE state, will not use the pre-configuration to monitor the G-RNTI until a corresponding activation indication is received from the wireless communication node; or If the PTM configuration includes the in-progress configuration, the first wireless communication device will immediately use the in-progress configuration to monitor the G-RNTI after transitioning to the RRC_INACTIVE state.

18. The method according to claim 15, wherein, At least one of the following: The first indication is used to indicate the behavior of the first wireless communication device in the RRC_INACTIVE state; The behavior includes the first wireless communication device monitoring the G-RNTI immediately after transitioning to the RRC_INACTIVE state; or The behavior includes the first wireless communication device not monitoring the G-RNTI after transitioning to the RRC_INACTIVE state until it receives a corresponding activation indication from the wireless communication node.

19. The method of claim 15, comprising: The CU merges the cell identifier ID from the PTM configuration information into the RRCRelease message.

20. The method of claim 1, comprising: The control plane of the CU sends the session status and / or configuration status to the user plane of the CU in E1 signaling for the session.

21. A method comprising: The distributed unit (DU) of the wireless communication node receives a first signaling from the centralized unit (CU), wherein the first signaling includes information regarding multicast reception by at least the first wireless communication device in the Radio Resource Control (RRC) inactive_INACTIVE state; and The DU sends a second signaling response to the first signaling to the CU.

22. A non-transitory computer-readable medium for storing instructions, wherein, When executed by at least one processor, the instructions cause the at least one processor to perform the method according to any one of claims 1 to 21.

23. An apparatus comprising: At least one processor is configured to perform the method according to any one of claims 1 to 21.

Images