Method and apparatus for multicast data reception

Abstract

Methods and apparatus for multicast data reception are provided. A method performed by a user equipment (UE) includes receiving, from a base station (BS), a radio resource control (RRC) release message including a suspend configuration indicating at least one multicast session, data of the multicast session being allowed to be received by the UE in an RRC inactive state; receiving first data of a first multicast session of the at least one multicast session in the RRC inactive state based on a first configuration associated with the first multicast session and included in the RRC release message; determining whether the reception quality of the first data of the first multicast session is lower than a first threshold; and triggering an RRC connection recovery process when the reception quality of the first data of the first multicast session is lower than the first threshold.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This disclosure claims the benefit of and priority to U.S. Provisional Patent Application Serial No. 63 / 412,101, filed on September 30, 2022, entitled “MECHANISM FOR MULTICAST SERVICEDATA RECEPTION IN RRC_INACTIVE STATE,” the contents of which are hereby incorporated by reference into this disclosure in their entirety for all purposes. Technical Field

[0002] The present disclosure relates generally to wireless communications, and more particularly to methods and apparatus for multicast data reception. Background Art

[0003] With the substantial growth in the number of connected devices and the rapid increase in user / network (NW) traffic, various efforts have been made to improve different aspects of wireless communications in next-generation wireless communication systems, such as fifth-generation (5G) New Radio (NR), for example by improving data rate, latency, reliability, and mobility.

[0004] The 5G NR system is designed to provide flexibility and configurability to optimize NW services and types, thus adapting to various use cases such as enhanced mobile broadband (eMBB), massive machine type communication (mMTC), and ultra-reliable low latency communication (URLLC).

[0005] However, as the demand for radio access continues to increase, there is a need to further improve wireless communications in next generation wireless communication systems. Summary of the invention

[0006] The present disclosure relates to methods and apparatus for multicast data reception.

[0007] According to a first aspect of the present disclosure, a method for receiving multicast data performed by a user equipment (UE) is provided. The method includes: receiving a radio resource control (RRC) release message including a suspension configuration from a base station (BS), the suspension configuration indicating at least one multicast session, the data of which is allowed to be received by the UE in an RRC inactive state; receiving first data of the first multicast session in the RRC inactive state based on a first configuration associated with a first multicast session in the at least one multicast session and included in the RRC release message; determining whether the reception quality of the first data of the first multicast session is lower than a first threshold; and triggering an RRC connection recovery process if the reception quality of the first data of the first multicast session is lower than the first threshold.

[0008] In some specific implementations of the first aspect of the present disclosure, the first threshold is included in an RRC release message.

[0009] In some specific implementations of the first aspect of the present disclosure, the method further includes: when the reception quality of the first data of the first multicast session is lower than a first threshold, stopping receiving the first data of the first multicast session.

[0010] In some specific implementations of the first aspect of the present disclosure, the first threshold includes at least one of a reference signal received power (RSRP) threshold or a reference signal received quality (RSRQ) threshold.

[0011] In some specific implementations of the first aspect of the present disclosure, the method further includes: configuring a first threshold for the first multicast session; and configuring a second threshold for a second multicast session in the at least one multicast session.

[0012] In some specific implementations of the first aspect of the present disclosure, the method further includes: triggering an RRC connection recovery process when the UE does not have a valid configuration for receiving the first data of the first multicast session.

[0013] In some implementations of the first aspect of the present disclosure, the method also includes: receiving a second configuration of a neighboring cell for receiving first data of a first multicast session via broadcast system information, wherein the second configuration is associated with the first multicast session; performing a cell reselection process to join the reselected cell; and triggering an RRC connection recovery process if the second configuration associated with the first multicast session is not available for the first multicast session in the reselected cell.

[0014] According to a second aspect of the present disclosure, a UE is provided. The UE includes one or more processors, and at least one memory coupled to at least one of the one or more processors. The at least one memory stores a computer executable program, which, when executed by the at least one of the one or more processors, enables the UE to receive an RRC release message including a suspension configuration from a BS, the suspension configuration indicating at least one multicast session, the data of which is allowed to be received by the UE in an RRC inactive state; based on a first configuration associated with a first multicast session in the at least one multicast session and included in the RRC release message, receive first data of the first multicast session in an RRC inactive state; determine whether the reception quality of the first data of the first multicast session is lower than a first threshold; and trigger an RRC connection recovery process when the reception quality of the first data of the first multicast session is lower than the first threshold.

[0015] In some specific implementations of the second aspect of the present disclosure, the first threshold is included in the RRC release message.

[0016] In some specific implementations of the second aspect of the present disclosure, the computer executable program, when executed by at least one of the one or more processors, also causes the UE to: stop receiving the first data of the first multicast session when the reception quality of the first data of the first multicast session is lower than a first threshold.

[0017] In some specific implementations of the second aspect of the present disclosure, the first threshold includes at least one of an RSRP threshold or an RSRQ threshold.

[0018] In some specific implementations of the second aspect of the present disclosure, when the computer executable program is executed by at least one of the one or more processors, it also causes the UE to: configure a first threshold for the first multicast session; and configure a second threshold for the second multicast session in the at least one multicast session.

[0019] In some specific implementations of the second aspect of the present disclosure, the computer executable program, when executed by at least one of the one or more processors, also enables the UE to: trigger an RRC connection recovery process when the UE does not have a valid configuration for receiving the first data of the first multicast session.

[0020] In some specific implementations of the second aspect of the present disclosure, the computer executable program, when executed by at least one of the one or more processors, further causes the UE to: receive a second configuration of a neighboring cell for receiving first data of a first multicast session via broadcast system information, wherein the second configuration is associated with the first multicast session; perform a cell reselection process to join the reselected cell; and trigger an RRC connection recovery process if the second configuration associated with the first multicast session is not available for the first multicast session in the reselected cell.

[0021] According to a third aspect of the present disclosure, a BS is provided. The BS includes one or more processors, and at least one memory coupled to at least one of the one or more processors. The at least one memory stores a computer executable program, which, when executed by the at least one of the one or more processors, enables the BS to send an RRC release message including a suspension configuration to a UE, the suspension configuration indicating at least one multicast session, and the data of the multicast session is allowed to be received by the UE in an RRC inactive state. The RRC release message also includes at least one configuration associated with the at least one multicast session, and enables the UE to: receive the first data of the first multicast session in an RRC inactive state based on a first configuration associated with a first multicast session in the at least one multicast session, wherein the first configuration is included in the RRC release message; determine whether the reception quality of the first data of the first multicast session is lower than a first threshold; and trigger the RRC connection recovery process when the reception quality of the first data of the first multicast session is lower than the first threshold.

[0022] In some specific implementations of the third aspect of the present disclosure, the first threshold is included in the RRC release message.

[0023] In some specific implementations of the third aspect of the present disclosure, the RRC release message further enables the UE to stop receiving the first data of the first multicast session when the reception quality of the first data of the first multicast session is lower than a first threshold.

[0024] In some specific implementations of the third aspect of the present disclosure, the first threshold includes at least one of an RSRP threshold or an RSRQ threshold.

[0025] In some specific implementations of the third aspect of the present disclosure, the RRC release message further enables the UE to: configure a first threshold for the first multicast session; and configure a second threshold for a second multicast session in the at least one multicast session.

[0026] In some specific implementations of the third aspect of the present disclosure, the RRC release message further enables the UE to: trigger an RRC connection recovery process when the UE does not have a valid configuration for receiving the first data of the first multicast session. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The various aspects of the present example disclosure can be best understood from the following detailed description when read in conjunction with the accompanying drawings. The various features are not drawn to scale. The sizes of the various features may be arbitrarily increased or decreased for clarity of discussion. Figure 1 is a flowchart illustrating a method for multicast data reception according to an example implementation of the present disclosure. Figure 2is a block diagram illustrating a node for wireless communication according to an example implementation of the present disclosure. DETAILED DESCRIPTION

[0028] The following description contains specific information about example implementations in the present disclosure. The drawings in the present disclosure and the detailed descriptions attached thereto are only for example implementations. However, the present disclosure is not limited to these example implementations. Other variations and implementations of the present disclosure will occur to those skilled in the art. Unless otherwise indicated, identical or corresponding elements in the drawings may be represented by identical or corresponding reference numerals. In addition, the drawings and illustrations in the present disclosure are generally not drawn to scale and are not intended to correspond to actual relative sizes.

[0029] For the purpose of consistency and ease of understanding, similar features may be identified by the same numerals in the example drawings (although not shown in some examples). However, features in different implementations may differ in other aspects, and therefore should not be narrowly limited to what is shown in the drawings.

[0030] The description uses the phrase "in some specific implementations", which can each refer to one or more of the same or different specific implementations. The term "coupled" is defined as connected, whether directly or indirectly through intermediate components, and is not necessarily limited to physical connections. When used, the term "comprising" means "including but not necessarily limited to"; it specifically represents open inclusion or membership in the described combinations, groups, series, and equivalents. The expressions "at least one of A, B, and C", "at least one of the following: A, B, and C", "at least one of A, B, or C", and "at least one of the following: A, B, or C" mean "only A, or only B, or only C, or any combination of A, B, and C".

[0031] Additionally, for the purpose of explanation rather than limitation, specific details such as functional entities, technologies, protocols, standards, etc. are set forth to provide an understanding of the described technology. In other examples, detailed descriptions of well-known methods, technologies, systems, architectures, etc. are omitted to avoid obscuring the description with unnecessary details.

[0032] Those skilled in the art will immediately recognize that any NW function or algorithm described in this disclosure can be implemented by hardware, software, or a combination of software and hardware. The described functions may correspond to each module, which may be software, hardware, firmware, or any combination thereof. Software implementations may include computer executable instructions stored on computer-readable media such as memory or other types of storage devices. For example, one or more microprocessors or general-purpose computers with communication processing capabilities may be programmed with corresponding executable instructions and perform the described NW functions or algorithms. A microprocessor or general-purpose computer may be formed by an application specific integrated circuit (ASIC), a programmable logic array, and / or one or more digital signal processors (DSPs). Although some exemplary implementations described in this specification are software for installation and execution on computer hardware, however, alternative exemplary implementations implemented as firmware, hardware, or a combination of hardware and software are also within the scope of this disclosure.

[0033] Computer readable media include, but are not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, compact disk read-only memory (CD-ROM), cassettes, magnetic tape, disk storage, or any other equivalent medium capable of storing computer readable instructions.

[0034] A radio communication NW architecture (e.g., a long term evolution (LTE) system, an advanced LTE (LTE-NW system, an advanced LTE Pro system, or a 5G new radio (NR) radio access network (RAN)) typically includes at least one base station (BS), at least one user equipment (UE), and one or more optional NW elements that provide a connection toward the NW. The UE communicates with the NW (e.g., a core network (CN), an evolved packet core (EPC) NW, an evolved universal terrestrial radio access network (E-UTRAN), a 5G core (5GC), or the Internet) through the RAN established by one or more BSs.

[0035] It should be noted that in the present application, UE may include but is not limited to a mobile station, a mobile terminal or device, or a user communication radio terminal. For example, UE may be a portable radio equipment, which includes but is not limited to a mobile phone, a tablet computer, a wearable device, a sensor, a vehicle, or a personal digital assistant (PDA) with wireless communication capabilities. UE is configured to receive and send signals over an air interface relative to one or more cells in a radio access NW.

[0036] The BS may be configured to provide communication services according to at least one of the following radio access technologies (RATs): Worldwide Interoperability for Microwave Access (WiMAX), Global System for Mobile Communications (GSM, commonly referred to as 2G), GSM Enhanced Data Rates for GSM Evolution (EDGE), Radio Access Network (GERAN), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS, commonly referred to as 3G) based on basic Wideband Code Division Multiple Access (W-CDMA), High Speed ​​Packet Access (HSPA), LTE, LTE-A, eLTE (Evolved LTE, e.g., LTE connected to 5GC), NR (commonly referred to as 5G) and / or LTE-A Pro. However, the scope of the present application should not be limited to the above protocols.

[0037] The BS may include, but is not limited to, a Node B (NB) as in UMTS, an evolved Node B (eNB) as in LTE or LTE-A, a Radio Network Controller (RNC) as in UMTS, a Base Station Controller (BSC) as in GSM / GERAN, an ng-eNB as in an Evolved Universal Terrestrial Radio Access (E-UTRA) BS in conjunction with 5GC, a Next Generation Node B (gNB) as in 5G-RAN, and any other device capable of controlling radio communications and managing radio resources within a cell. The BS may serve one or more UEs via a radio interface.

[0038] The BS is operable to provide radio coverage to a specific geographic area using multiple cells forming a radio access NW. The BS supports the operation of the cells. Each cell is operable to provide services to at least one UE within its radio coverage. For example, each cell (commonly referred to as a serving cell) provides services to serve one or more UEs within its radio coverage (e.g., each cell schedules downlink (DL) and optionally uplink (UL) resources to at least one UE within its radio coverage for DL ​​packet transmission and optionally UL packet transmission). The BS can communicate with one or more UEs in the radio communication system through the multiple cells. The cell may allocate side link (SL) resources for supporting proximity services (ProSe) or vehicle-to-everything (V2X) services. Each cell may have a coverage area that overlaps with other cells.

[0039] As discussed above, the frame structure of NR will support flexible configuration to accommodate various next-generation (e.g., 5G) communication requirements, such as enhanced mobile broadband (eMBB), massive machine type communication (mMTC), ultra-reliable and low latency communication (URLLC), while meeting high reliability, high data rate, and low latency requirements. The orthogonal frequency division multiplexing (OFDM) technology agreed upon in the Third Generation Partnership Project (3GPP) can be used as a baseline for the NR waveform. Scalable OFDM parameter sets, such as adaptive subcarrier spacing, channel bandwidth, and cyclic prefix (CP) can also be used. In addition, two decoding schemes are considered for NR: (1) low-density parity check (LDPC) codes and (2) polar codes. The coding scheme adaptation can be configured based on channel conditions and / or service applications.

[0040] In addition, it is also considered that in the transmission time interval TX of a single NR frame, at least DL transmission data, protection period and UL transmission data should be included, wherein the corresponding parts of DL transmission data, protection period and UL transmission data should also be configurable, such as based on NR NW dynamics. In addition, SL resources can also be provided in the NR frame to support ProSe services or V2X services.

[0041] In addition, the terms "system" and "NW" in this article are used interchangeably. The term "and / or" in this article is only used to describe the association relationship of associated objects, and indicates that three relationships may exist. For example, A and / or B may indicate that A exists alone, A and B exist at the same time, or B exists alone. In addition, the character " / " here usually indicates that the previous and next associated objects are in an "or" relationship. Multiple PLMNs can operate on unlicensed spectrum. Multiple PLMNs can share the same unlicensed carrier. PLMNs can be public or private. Public PLMNs can be (but not limited to) operators or virtual operators that provide radio services to public users. Public PLMNs can own licensed spectrum and also support radio access technologies on licensed spectrum. Private PLMNs can be (but not limited to) micro operators, factories or enterprises that provide radio services to their private users (e.g., employees or machines). In some implementations, the public PLMN may support more deployment scenarios (e.g., carrier aggregation between licensed band NR (PCell) and NR-U (SCell), dual connectivity between licensed band LTE (PCell) and NR-U (PSCell), independent NR-U, NR cell with DL in unlicensed band and UL in licensed band, dual connectivity between licensed band NR (PCell) and NR-U (PSCell)). In some implementations, the private PLMN mainly supports (but is not limited to) independent unlicensed radio access technology (e.g., independent NR-U).

[0042] Some of the terms, definitions and abbreviations given in this document have been imported from existing documents (European Telecommunications Standards Institute (ETSI), International Telecommunication Union (ITU) or elsewhere) or have been newly created by 3GPP experts when precise vocabulary is needed.

[0043] To improve the efficiency of resource delivery, 3GPP introduced a mechanism for supporting NR broadcast and multicast services in Release 17 (e.g., TS 38.300v17.0.0).

[0044] Broadcast services are considered to be communication services with lower quality of service (QoS). For broadcast services, the same content data is provided to all UEs in a specific geographic area simultaneously through a broadcast session, and the UEs can receive data of the broadcast services in RRC idle (e.g., RRC_IDLE), RRC inactive (e.g., RRC_INACTIVE), or RRC connected (e.g., RRC_CONNECTED) states.

[0045] On the other hand, multicast services are considered to be communication services with higher QoS. For multicast services, the same content data is provided simultaneously to a dedicated group of UEs (e.g., UEs authorized to receive multicast data) through a multicast session, and the UEs within the dedicated group of UEs can receive the data of the multicast service only in the RRC connected state. In addition, the network (NW) or the serving base station may send one or more different multicast multicast and broadcast service (MBS) radio bearer (MRB) configurations in dedicated RRC signaling to configure the UE to receive the data of the multicast service via a point-to-point (PTP) delivery mode or a point-to-multipoint (PTM) delivery mode. Here, a multicast MRB is a radio bearer configured for multicast delivery / service / session.

[0046] The one or more multicast MRB configurations may include a configuration of at least one of the following: Multicast MRB utilizing a DL-only Radio Link Control - Unacknowledged Mode (RLC-UM) entity or utilizing a bidirectional RLC-UM entity for PTP transmission; Multicast MRB using Radio Link Control-Acknowledged Mode (RLC-AM) entity for PTP transmission; Multicast MRB using DL-only RLC-UM entity for PTM transmission; Multicast MRB utilizing two RLC-UM entities (e.g., including a DL-only RLC-UM entity for PTP transmission and a DL-only RLC-UM entity for PTM transmission); Multicast MRB using three RLC-UM entities (e.g., including a DL RLC-UM entity for PTP transmission, a UL RLC-UM entity for PTP transmission, and a DL-only RLC-UM entity for PTM transmission); Multicast MRB utilizing two RLC entities (eg, including an RLC-AM entity for PTP transmission and a DL-only RLC-UM entity for PTM transmission).

[0047] To guarantee higher QoS, Hybrid Automatic Repeat Request (HARQ) feedback / retransmission may be applied to both PTP transmission and PTM transmission.

[0048] However, limiting the UE to receive data for multicast services / sessions only in the RRC connected state may not be beneficial for NW capacity, latency reduction, and power saving purposes. For example, for a cell with a large number of UEs, if there is an ongoing multicast service as a mission-critical service, the NW may not be able to serve all these UEs at the same time because all these UEs need to be in the RRC connected state. In addition, the UE may need to perform a connection establishment process to transition to the RRC connected state, resulting in increased signaling overhead and exacerbated random access (RA) contention. Therefore, some UEs may temporarily experience RA failures, resulting in the inability to meet the requirements for receiving such mission-critical service data. In addition, staying in the RRC connected state consumes more power than staying in the RRC inactive state or the RRC idle state.

[0049] If it is allowed to receive data of multicast service / session in RRC inactive state, it may be necessary to further consider issues related to mobility (e.g., cell (re)selection) to ensure service continuity and reduce unnecessary RRC recovery procedures. The issues considered may be, for example, receiving / updating the relevant MBS configuration when the UE moves to another cell where it resides and lacks a valid MBS configuration for multicast service data reception in RRC inactive state. That is, for power saving purposes and service continuity, a new mechanism for receiving multicast service data in RRC inactive state needs to be supported.

[0050] Several specific implementations of the method for introducing support for multicast service data reception in RRC inactive state are described below, including MBS configuration delivery / update, signaling design, and corresponding UE behavior after cell (re)selection. Mechanism to support MBS multicast reception in RRC_INACTIVE state

[0051] In some specific implementations, the UE may receive (e.g., in an RRC inactive state or an RRC connected state) an RRC release message with a suspension configuration indicating at least one of: at least one MBS multicast service / session whose data is allowed to be received in the RRC inactive state, or an associated configuration to be applied when receiving data for the multicast service / session in the RRC inactive state.

[0052] In some specific implementations, the UE may receive (e.g., in an RRC inactive state or an RRC connected state) an RRC release message with a suspension configuration, the suspension configuration indicating at least one of the following: at least one MBS multicast service / session whose data is allowed to be received in the RRC inactive state, or an associated configuration to be applied when the UE camps on a cell from which the UE receives the RRC release message with the suspension configuration. When the UE in the RRC inactive state intends to receive data of the MBS multicast service / session, the UE may apply the associated configuration to receive the data of the MBS multicast service / session.

[0053] In some specific implementations, the UE may (e.g., in an RRC inactive state or an RRC connected state) receive an RRC release message with a suspension configuration, which indicates at least one of: allowing data of a currently (interested) activated MBS multicast service / session to be received in the RRC inactive state, or an associated configuration to be applied when receiving data of an MBS multicast service / session in the RRC inactive state.

[0054] In some specific implementations, the UE may (e.g., in an RRC inactive state or an RRC connected state) receive an RRC release message with a suspension configuration, the suspension configuration indicating at least one of: allowing the reception of data of the currently (interested) activated MBS multicast service / session in the RRC inactive state, or an associated configuration to be applied when the UE camps on a cell from which the UE receives the RRC release message with the suspension configuration. When the UE in the RRC inactive state intends to receive data of the MBS multicast service / session, the UE may apply the associated configuration to receive the data of the MBS multicast service / session.

[0055] In some implementations, the UE may transition from the RRC connected state to the RRC inactive state after receiving an RRC release message with a suspension configuration.

[0056] In some specific implementations, the UE may receive a configuration (e.g., including at least one of a BWP configuration, a PDCCH configuration, a PDSCH configuration, a MCCH configuration, or a MTCH configuration) for receiving data for an MBS multicast service / session in an RRC inactive state via dedicated signaling or broadcast system information (e.g., in a system information block (SIB) related to the MBS).

[0057] In some implementations, a portion of the configuration for receiving data for MBS multicast services / sessions in RRC inactive state may be provided via dedicated signaling, and a portion of the configuration for receiving data for MBS multicast services / sessions in RRC inactive state may be provided via broadcast system information.

[0058] In some implementations, in the event that a specific portion of the configuration for receiving data for an MBS multicast service / session in an RRC inactive state does not exist (or does not exist) in dedicated signaling, the UE may obtain relevant information via broadcast system information.

[0059] In some specific implementations, in the case where the UE cannot receive a complete configuration for receiving data of the MBS multicast service / session in the RRC inactive state from the dedicated signaling and the broadcast system information, the UE may stop receiving the data of the MBS multicast service / session in the RRC inactive state, and may release the stored information related to the configuration. The configuration for receiving data of the MBS multicast service / session in the RRC inactive state may be, for example, a configuration valid only for the cell currently camped on, or a configuration valid for a configured area (e.g., a cell list or an area defined by a RAN notification area). The definition of the RAN notification area may, for example, follow the definition introduced in TS 38.331 V17.1.0.

[0060] In some implementations, a cell or its associated base station may provide at least one of the following: a configuration for receiving data of an MBS multicast service / session in an RRC inactive state within its network coverage, or a configuration for receiving data of a multicast service / session in an RRC inactive state in a neighboring cell. For example, when a UE resides on a first cell, the UE may receive a first configuration of the first cell for receiving data of a first multicast service / session, and when the UE resides on a second cell, the UE may also receive a second configuration of a second (e.g., neighboring) cell for receiving data of the first multicast service / session. The second configuration may be provided via dedicated signaling (e.g., an RRC release message from the first cell) or via broadcast system information (e.g., a SIB broadcast by the first cell or a SIB broadcast by the second cell).

[0061] In some implementations, the UE may receive at least one of the following via dedicated signaling (e.g., an RRC release message with a suspension configuration): a configuration applicable to receiving data of an MBS multicast service / session in a current serving cell, or a configuration applicable to receiving data of a multicast service / session in a neighboring cell. In some implementations, the UE may receive at least one of the following via broadcast system information (e.g., an MBS-related SIB broadcasted by the current serving cell): a configuration applicable to receiving data of a multicast service / session in a current serving cell, or a configuration applicable to receiving data of a multicast service / session in a neighboring cell. MBS multicast reception in RRC_INACTIVE state within the region

[0062] In some implementations, the UE may receive a configuration applicable to receiving data for an MBS multicast service / session within an area (e.g., a cell list or an area defined by a RAN notification area). In some implementations, the serving cell or its associated base station may provide an MBS validity area (or an associated temporary mobile group identity (TMGI)) associated with the multicast service / session. In some implementations, the serving cell or its associated base station may provide an MBS validity area (or an associated TMGI) associated with the configuration for receiving data for a multicast service / session.

[0063] For example, the UE may receive a configuration for receiving data of an MBS multicast service / session having an associated MBS valid area from a first cell, wherein the associated MBS valid area includes the first cell, the second cell, and the third cell. In the case where the UE camps on the second cell after selection, the UE may consider the received configuration to be valid for receiving data of the MBS multicast service / session unless the received configuration becomes invalid based on an instruction (e.g., a paging message), a notification (e.g., a SIB update notification), or a pre-configuration (e.g., based on a timer) of the network.

[0064] In some implementations, the MBS validity area associated with the MBS multicast service / session may be a frequency list. That is, when the UE is camped on a cell operating on a frequency included in the frequency list, the UE may receive data of the MBS multicast service / session based on the received configuration.

[0065] For example, assume that the first frequency and the second frequency are in a frequency list associated with the first MBS. When the UE resides in a first cell operating on the first frequency, the UE may receive data of the first MBS based on the received configuration. When the UE resides in a second cell operating on a third frequency not included in the frequency list, the UE may stop receiving data of the first MBS based on the received configuration. In this case, the UE may consider the received configuration invalid. Therefore, the UE may reacquire the SIB related to the MBS to update the configuration, or initiate an RRC recovery process to receive a new configuration.

[0066] In some cases, the UE may first check whether there is a SIB (or required configuration) related to the MBS. If there is a SIB (or required configuration) related to the MBS, the UE may obtain the SIB (or required configuration) related to the MBS to update the configuration. After updating the configuration from the SIB, the UE may start receiving data for the first MBS based on the updated configuration. If there is no SIB (or required configuration) related to the MBS, the UE may initiate an RRC recovery procedure to request a new configuration. After receiving the configuration from the dedicated signaling, the UE may start receiving data for the first MBS based on the updated configuration, for example, in an RRC connected state or an RRC inactive state.

[0067] In some implementations, when performing cell (re)selection, a frequency in a frequency list of MBS validity associated with an MBS multicast service / session may be considered as a frequency with a higher priority (e.g., if the UE wants to receive data of the MBS multicast service / session in an RRC inactive state). For example, assuming that a first frequency and a second frequency are in a frequency list associated with a first MBS. When performing cell (re)selection, the first frequency and the second frequency may be considered as higher priority frequencies. That is, the UE may consider operating on cells with higher rankings, the first frequency and the second frequency, to camp on.

[0068] In some implementations, the MBS validity area associated with the MBS multicast service / session may be a list of cell IDs (e.g., physical cell IDs). That is, when the UE is camped on a cell having a cell ID included in the cell ID list, the UE may receive data of the MBS multicast service / session based on the received configuration.

[0069] For example, assume that the first cell ID and the second cell ID are in the cell ID list associated with the first MBS. When the UE resides on a cell with the first cell ID, the UE may receive data of the first MBS based on the received configuration. When the UE resides on a cell with a third cell ID that is not included in the cell ID list, the UE may stop receiving data of the first MBS based on the received configuration. In this case, the UE may consider the received configuration invalid. Therefore, the UE may reacquire the SIB related to the MBS to update the configuration, or initiate an RRC recovery process to receive a new configuration.

[0070] In some cases, the UE may first check whether there is a SIB (or required configuration) related to the MBS. If there is a SIB (or required configuration) related to the MBS, the UE may obtain the SIB (or required configuration) related to the MBS to update the configuration. After updating the configuration from the SIB, the UE may start receiving data for the first MBS based on the updated configuration. If there is no SIB (or required configuration) related to the MBS, the UE may initiate an RRC recovery procedure to request a new configuration. After receiving the configuration from the dedicated signaling, the UE may start receiving data for the first MBS based on the updated configuration, for example, in an RRC connected state or an RRC inactive state.

[0071] In some implementations, the MBS validity area associated with the MBS multicast service / session may be a frequency list, and each entry of the frequency list may be associated with a cell ID list. That is, when the UE camps on a cell operating on a frequency included in the frequency list and the cell ID of the cell is included in the corresponding cell ID list, the UE may receive data for the multicast service / session based on the received configuration.

[0072] For example, assume that the first frequency and the second frequency are in a frequency list associated with the first MBS. In addition, the first frequency is associated with the first cell ID list {#ID1, #ID2}, and the second frequency is associated with the second cell ID list {#ID4, #ID5}. When the UE resides in a cell with cell ID #ID1 operating on the first frequency, the UE may receive data of the first MBS based on the received configuration. When the UE resides in a cell with cell ID #ID3 operating on the first frequency, the UE may stop receiving data of the first MBS based on the received configuration. In this case, the UE may consider the received configuration invalid. Therefore, the UE may re-acquire the SIB related to the MBS to update the configuration, or initiate an RRC recovery process to receive a new configuration.

[0073] In some cases, the UE may first check whether there is a SIB (or required configuration) related to the MBS. If there is a SIB (or required configuration) related to the MBS, the UE may obtain the SIB (or required configuration) related to the MBS to update the configuration. After updating the configuration from the SIB, the UE may start receiving data for the first MBS based on the updated configuration. If there is no SIB (or required configuration) related to the MBS, the UE may initiate an RRC recovery procedure to request a new configuration. After receiving the configuration from the dedicated signaling, the UE may start receiving data for the first MBS based on the updated configuration, for example, in an RRC connected state or an RRC inactive state. MBS multicast reception in RRC_INACTIVE state after / during cell (re)selection

[0074] In some implementations, a cell or its associated base station may broadcast an indication to indicate whether reception of MBS multicast services / sessions is allowed in the RRC inactive state.

[0075] For example, the UE may receive a configuration from a previously camped cell to receive data for an MBS multicast service / session. After cell (re)selection, the UE may camp on a new cell and may check an indication received from the new cell and associated with the MBS multicast service / session. If the indication is set to a specific first value (e.g., true or 1), the UE may determine that it is allowed to receive data for the MBS multicast service / session in an RRC inactive state while camping on the new cell. If the indication is set to a specific second value (e.g., false or 0), the UE may determine that it is not allowed to receive data for the MBS multicast service / session in an RRC inactive state while camping on the new cell.

[0076] In case the indication indicates that reception of MBS multicast service / session in RRC inactive state is allowed when camping on the cell and the UE has a valid configuration for receiving MBS multicast service / session data under RRC_INACITVE in the cell, the UE may keep receiving data of the MBS multicast service / session in the RRC inactive state.

[0077] In a case where the indication indicates that reception of data for the MBS multicast service / session is allowed in the RRC inactive state when camped on the cell but the UE does not have a valid configuration for receiving data for the MBS multicast service / session under RRC_INACITVE in the cell, the UE may stop receiving data for the MBS multicast service / session and may start / initiate a procedure requiring a valid configuration (e.g., re-acquiring SIBs related to the MBS, or initiating an RRC recovery procedure).

[0078] In the case where the indication indicates that reception of data of the MBS multicast service / session is not allowed in the RRC inactive state when camping on the cell, the UE may initiate an RRC recovery procedure to request a new configuration. After receiving the configuration from the dedicated signaling, the UE may start receiving data of the (interested) MBS multicast service / session based on the updated configuration, for example in the RRC connected state or the RRC inactive state.

[0079] In some cases, the RRC recovery process initiated by the UE may fail (e.g., timer T300 expires). In this case, the UE may transition back to the RRC idle state, and the lower layer of the UE (e.g., the RRC layer) may notify the upper layer of the UE (e.g., the NAS layer) of the release cause "RRC recovery failure". Alternatively, the UE may transition back to the RRC idle state, and the lower layer of the UE (e.g., the RRC layer) may notify the upper layer of the UE (e.g., the NAS layer) of the release cause to indicate that the MBS multicast reception failed.

[0080] In some implementations where there is no explicit indication from the new cell, if the UE has a valid configuration for receiving data for the MBS multicast service / session under RRC_INACITVE in the cell, then the reception of the MBS multicast service / session in the RRC inactive state may be allowed. If the UE does not have a valid configuration for receiving data for the MBS multicast service / session under RRC_INACITVE in the cell, then the UE may not be allowed to receive data for the MBS multicast service / session under RRC_INACITVE in the cell. Whether the UE has a valid configuration for receiving data for the MBS multicast service / session under RRC_INACITVE in the cell may be determined by, but not limited to, a UE implementation, NW configuration, or NW policy. For example, the received configuration may become invalid based on an instruction of the network (e.g., a paging message), a notification (e.g., a SIB update notification), or a pre-configuration (e.g., based on a timer).

[0081] In some implementations, a cell or its associated base station may broadcast an indication to indicate whether an MBS multicast service / session is activated or supported by the cell.

[0082] For example, the UE may receive a configuration from a previously camped cell to receive data for an MBS multicast service / session. After cell (re)selection, the UE may camp on a new cell and may check an indication received from the new cell and associated with the MBS multicast service / session. If the indication is set to a specific first value (e.g., true or 1), the UE may determine that the MBS multicast service / session is activated. If the indication is set to a specific second value (e.g., false or 0), the UE may determine that the MBS multicast service / session is deactivated.

[0083] In case the indication indicates that the MBS multicast service / session is activated and the UE has a valid configuration for receiving data of the MBS multicast service / session under RRC_INACITVE in the cell, the UE may keep receiving data of the MBS multicast service / session in the RRC inactive state.

[0084] In the case where the indication indicates that the MBS multicast service / session is activated but the UE does not have a valid configuration for receiving data of the MBS multicast service / session under RRC_INACITVE in the cell, the UE may stop receiving data of the MBS multicast service / session and may start / initiate a process requiring a valid configuration (e.g., re-acquiring SIBs related to the MBS, or initiating an RRC recovery process).

[0085] In case the indication indicates that the MBS multicast service / session is deactivated, the UE may stop receiving data of the MBS multicast service / session. In some instances, in case the indication indicates that the MBS multicast service / session is deactivated, the UE may initiate an RRC recovery procedure to request a new configuration. After receiving the configuration from the dedicated signaling, the UE may start receiving data of the (interested) MBS multicast service / session based on the updated configuration, for example in the RRC connected state or the RRC inactive state.

[0086] In some cases, the RRC recovery process initiated by the UE may fail (e.g., timer T300 expires). In this case, the UE may transition back to the RRC idle state, and the lower layer of the UE (e.g., the RRC layer) may notify the upper layer of the UE (e.g., the NAS layer) of the release cause "RRC recovery failure". Alternatively, the UE may transition back to the RRC idle state, and the lower layer of the UE (e.g., the RRC layer) may notify the upper layer of the UE (e.g., the NAS layer) of the release cause to indicate that the MBS multicast reception failed.

[0087] In some implementations, a cell or its associated base station may broadcast an indication (eg, using one or more bits) to indicate whether reception of an MBS multicast service / session is allowed in an RRC inactive state and whether the MBS multicast service / session is activated or supported by the cell.

[0088] In some implementations, a first bit (e.g., in the broadcast system information) may indicate whether reception of the MBS multicast service / session is allowed in the RRC inactive state, and a second bit (e.g., in the broadcast system information) may indicate whether the MBS multicast service / session is activated or supported by the cell.

[0089] For example, the UE may receive a configuration from a previously camped cell to receive data for an MBS multicast service / session. After cell (re)selection, the UE may camp on a new cell and may check the first and second bits received from the new cell. If the first bit is set to a specific first value (e.g., 1), the UE may determine that it is allowed to receive data for an MBS multicast service / session in an RRC inactive state while camping on the cell. If the first bit is set to a specific second value (e.g., 0), the UE may determine that it is not allowed to receive data for an MBS multicast service / session in an RRC inactive state while camping on the cell. If the second bit is set to a specific first value (e.g., 1), the UE may determine that the MBS multicast service / session is activated. If the second bit is set to a specific second value (e.g., 0), the UE may determine that the MBS multicast service / session is deactivated.

[0090] When the first bit indicates that reception of data of the MBS multicast service / session is allowed in the RRC inactive state when camping on the cell, the second bit indicates that the data of the MBS multicast service / session is activated, and the UE has a valid configuration for receiving data of the MBS multicast service / session under RRC_INACITVE in the cell, the UE may continue to receive data of the MBS multicast service / session in the RRC inactive state.

[0091] In the case where the first bit indicates that the reception of data of the MBS multicast service / session is not allowed in the RRC inactive state when camping on the cell, or the second bit indicates that the MBS multicast service / session is deactivated, or the UE does not have a valid configuration for receiving data of the MBS multicast service / session in the RRC_INACITVE in the cell, the UE may stop receiving data of the MBS multicast service / session and may start a process requiring a valid configuration (e.g., re-acquiring SIBs related to the MBS, or initiating an RRC recovery process). In some instances, after receiving the configuration from dedicated signaling (e.g., when initiating the RRC recovery process), the UE may start receiving data of the (interested) MBS multicast service / session based on the updated configuration, for example, in the RRC connected state or the RRC inactive state. In some instances, after receiving the configuration from broadcast information (e.g., when re-acquiring SIBs related to the MBS), the UE may start receiving data of the (interested) MBS multicast service / session based on the updated configuration, for example, in the RRC connected state or the RRC inactive state.

[0092] In some cases, the RRC recovery process initiated by the UE may fail (e.g., timer T300 expires). In this case, the UE may transition back to the RRC idle state, and the lower layer of the UE (e.g., the RRC layer) may notify the upper layer of the UE (e.g., the NAS layer) of the release cause "RRC recovery failure". Alternatively, the UE may transition back to the RRC idle state, and the lower layer of the UE (e.g., the RRC layer) may notify the upper layer of the UE (e.g., the NAS layer) of the release cause to indicate that the MBS multicast reception failed.

[0093] In some specific implementations, a third bit (e.g., in the broadcast system information) may indicate that the reception of the MBS multicast service / session is allowed in the RRC inactive state, and the MBS multicast service / session is also activated (or supported by the cell). In this case, if the third bit is set to a specific first value (e.g., 1), the UE may determine that the reception of the MBS multicast service / session is allowed in the RRC inactive state, and the MBS multicast service / session is also activated (or supported by the cell). If the third bit is set to a specific second value (i.e., 0), the UE may determine that the reception of the MBS multicast service / session is not allowed in the RRC inactive state, or the MBS multicast service / session is deactivated (or not supported by the cell).

[0094] For example, the UE may receive a configuration from a previously camped cell to receive data of an MBS multicast service / session. After cell (re)selection, the UE may camp on a new cell and may check the third bit received from the new cell. In the case where the third bit indicates that reception of the MBS multicast service / session is allowed in an RRC inactive state and the MBS multicast service / session is activated (or supported by the cell) and the UE has a valid configuration for receiving data of the MBS multicast service / session in RRC_INACITVE in the cell, the UE may remain in the RRC inactive state to receive data of the MBS multicast service / session. In the case where the third bit indicates that reception of the MBS multicast service / session is not allowed in an RRC inactive state or the MBS multicast service / session is deactivated (or not supported by the cell) or the UE does not have a valid configuration for receiving data of the MBS multicast service / session in RRC_INACITVE in the cell, the UE may stop receiving data of the MBS multicast service / session and may start a process requiring a valid configuration (e.g., re-acquiring SIBs related to the MBS, or initiating an RRC recovery process). In some instances, after receiving the configuration from dedicated signaling (e.g., when initiating the RRC recovery procedure), the UE may start receiving data of the (interested) MBS multicast service / session based on the updated configuration in the RRC connected state or the RRC inactive state. In some instances, after receiving the configuration from broadcast information (e.g., when reacquiring the SIBs related to the MBS), the UE may start receiving data of the (interested) MBS multicast service / session based on the updated configuration, for example, in the RRC connected state or the RRC inactive state.

[0095] In some cases, the RRC recovery process initiated by the UE may fail (e.g., timer T300 expires). In this case, the UE may transition back to the RRC idle state, and the lower layer of the UE (e.g., the RRC layer) may notify the upper layer of the UE (e.g., the NAS layer) of the release cause "RRC recovery failure". Alternatively, the UE may transition back to the RRC idle state, and the lower layer of the UE (e.g., the RRC layer) may notify the upper layer of the UE (e.g., the NAS layer) of the release cause to indicate that the MBS multicast reception failed. Validity of configuration of stored data for receiving MBS multicast services / sessions in RRC_INACTIVE state

[0096] In some implementations, before the UE starts receiving data for the MBS multicast service / session in the RRC inactive state based on the stored configuration, the UE may check whether the stored configuration for receiving data for the MBS multicast service / session in the RRC inactive state is valid. The stored configuration for receiving data for the MBS multicast service / session in the RRC inactive state may be received, for example, via dedicated signaling (e.g., an RRC release message with a suspended configuration) or via broadcast system information.

[0097] In some implementations, the configuration for receiving data of an MBS multicast service / session in an RRC inactive state may be associated with a version number or a value tag. If the version number or the value tag of the stored configuration for receiving data of an MBS multicast service / session is different from the version number or the value tag of the second configuration for receiving data of the same MBS multicast service / session currently received from dedicated signaling or broadcast system information, the UE may replace the stored configuration for receiving data of an MBS multicast service / session with the second configuration for receiving data of the same MBS multicast service / session.

[0098] For example, the UE may receive a configuration for receiving data of a first MBS from a first cell, and the associated version number or value tag is "001". After cell (re)selection, the UE may camp on a new second cell, and may check the version number or value tag of the configuration for receiving data of the first MBS broadcast by the second cell. If the associated version number or value tag of the configuration for receiving data of the first MBS broadcast by the second cell is also "001", the UE may keep receiving data of the first MBS using the stored configuration (e.g., received from the first cell) while camping on the second cell. Otherwise, if the associated version number or value tag of the configuration for receiving data of the first MBS broadcast by the second cell is not "001" (e.g., is "010"), the UE may stop receiving data of the first MBS using the stored configuration (e.g., received from the first cell) while camping on the second cell. The UE may start / initiate a process requiring a valid configuration (e.g., re-acquiring SIBs related to the MBS, or initiating an RRC recovery process).

[0099] In some specific implementations, if the UE initiates the RRC recovery process because it wants to receive data of the first MBS, the UE may set the recovery cause to a specified cause, such as MBSreception. For example, if the UE does not have a valid configuration of the first MBS, the cell in which it resides does not allow the UE to receive information of the first MBS, or the information reception quality in the RRC inactive state is less than or equal to a configured threshold, the UE may initiate the RRC recovery process and / or set the recovery cause to a specified cause, such as MBSreception. State transition for receiving data of MBS multicast service / session in RRC_INACTIVE state

[0100] In some implementations, for at least one of the following conditions (1) to (3), the UE may initiate an RRC recovery procedure to receive data of the MBS multicast service / session in the RRC_CONNEED state.

[0101] Case 1: The UE does not have a valid configuration for receiving data of an MBS multicast service / session in the RRC inactive state.

[0102] For example, the UE may be notified (eg, via a paging DCI, a short message, or a paging message) to resume the connection (eg, for updating the configuration of the MBS multicast service / session).

[0103] For example, the UE may leave the configured validity area to receive data of the MBS multicast service / session in the RRC inactive state. For example, after cell (re)selection, the UE may camp on a cell that does not belong to the configured validity area of ​​the MBS multicast service / session of interest. In this case, the UE may consider the currently stored configuration of the MBS multicast service / session of interest to be invalid.

[0104] Condition (2): The cell in which the UE resides does not allow the UE to receive data of the MBS multicast service / session in the RRC inactive state.

[0105] For example, the camped cell may broadcast an indication to indicate whether reception of data of the MBS multicast service / session is allowed in the RRC inactive state.

[0106] Condition (3): The data reception quality of the MBS multicast service / session in the RRC inactive state is less than (or equal to) the configured threshold.

[0107] In some implementations, the network may configure the thresholds for the multicast session. For example, at least one of a reference signal received power (RSRP) threshold, a reference signal received quality (RSRQ) threshold, or a received signal strength indication (RSSI) threshold may be provided (e.g., via dedicated signaling or broadcast system information).

[0108] For example, when the UE is in the RRC inactive state, if the UE determines that the service reception condition of the MBS multicast service / session is good (for example, by comparing with a threshold configured for the MBS multicast service / session), the UE may continue to receive data of the MBS multicast service / session in the RRC inactive state. For example, if the measured RSRP or RSRQ is greater than (or equal to) a received RSRP or RSRQ threshold associated with the MBS multicast service / session, the UE is allowed to receive data of the MBS multicast service / session in the RRC inactive state based on the associated (valid) configuration.

[0109] If the UE determines that the service reception condition of the MBS multicast service / session is poor (e.g., by comparing with a configured threshold value of the MBS multicast service / session), the UE may stop receiving data of the MBS multicast service / session in the RRC inactive state, and may initiate an RRC recovery procedure. For example, if the measured RSRP or RSRQ is less than (or equal to) a received RSRP or RSRQ threshold value associated with the MBS multicast service / session, the UE is not allowed to receive data of the MBS multicast service / session in the RRC inactive state.

[0110] In some implementations, different thresholds may be configured for different multicast sessions. For example, the network may configure a first threshold for a first multicast session and a second threshold for a second multicast session.

[0111] In some implementations, the network may update the thresholds for associated MBS multicast services / sessions via dedicated signaling (eg, RRC release message with suspension configuration) or via broadcast system information (eg, MBS-related SIBs).

[0112] In some implementations, if the UE determines that the stored SIB related to the MBS becomes invalid, the UE may re-acquire the SIB related to the MBS and may update the threshold accordingly.

[0113] In some implementations, if the threshold value for the MBS multicast service / session does not exist (e.g., does not exist in the received dedicated signal, or does not exist in the broadcast system information of the currently camped cell), the UE may reuse the stored threshold value when receiving the MBS multicast service / session in the RRC inactive state. If the UE determines that the service reception condition of the MBS multicast service / session is good (e.g., by comparing with the stored threshold value for the MBS multicast service / session), the UE may continue to receive the data of the MBS multicast service / session in the RRC inactive state. If the UE determines that the service reception condition of the MBS multicast service / session is poor (e.g., by comparing with the stored threshold value for the MBS multicast service / session), the UE may stop receiving the data of the MBS multicast service / session in the RRC inactive state, and may initiate an RRC recovery procedure.

[0114] In some specific implementations, if the threshold for the MBS multicast service / session does not exist (for example, does not exist in the received dedicated signal, or does not exist in the broadcast system information of the cell currently resident), the UE may determine whether to initiate an RRC recovery procedure to receive the MBS multicast service / session in the RRC connected state based on its specific implementation, network policy, or pre-configuration from the network.

[0115] In some implementations, the UE may report a status report to the network to indicate an unacceptable service reception condition for an associated multicast session. For example, when the service reception condition for one or more MBS multicast services / sessions becomes unacceptable, the UE may send a multicast / broadcast service status report to the network (e.g., via a configured grant, a dynamic grant, a 2-step RA procedure, or a 4-step RA procedure) to indicate that the service reception condition for the one or more multicast sessions is unacceptable. For example, if the UE determines that the RSRP or RSRQ of a downlink path loss reference (e.g., a multicast / broadcast service reference signal) of an MBS multicast service / session is less than (or equal to) an associated RSRP or RSRQ threshold, the UE may report a multicast / broadcast service status report to the network to notify that the service reception condition for the MBS multicast service / session is unacceptable.

[0116] Figure 1 is a flow chart of a method 100 for multicast data reception according to an example implementation of the present disclosure.

[0117] It should be noted that although actions S110, S120, S130, S140 and S150 are illustrated as Figure 1 Although separate actions are shown as separate boxes in the example, these separate illustrated actions should not be construed as necessarily being performed in sequence. Figure 1The order in which the actions are performed is not intended to be construed as a limitation, and any number of the disclosed blocks may be combined in any order to implement the method or an alternative method. In addition, each of actions S110, S120, S130, S140, and S150 may be performed independently of the other actions and may be omitted in some specific implementations of the present disclosure.

[0118] In action S110 , the UE may receive an RRC release message including a suspension configuration from the BS, the suspension configuration indicating at least one multicast session whose data is allowed to be received by the UE in the RRC inactive state.

[0119] Specifically, for example, a UE in an RRC connected state or an RRC inactive state may receive an RRC release message with a suspension configuration, and the suspension configuration may indicate one or more multicast sessions, and data of the multicast sessions is allowed to be received by the UE in the RRC inactive state. In other words, the UE may be allowed to receive data of one or more multicast sessions indicated in the suspension configuration included in the RRC release message.

[0120] In some implementations, the RRC release message may include one or more configurations corresponding to the indicated one or more multicast sessions. For example, the one or more multicast sessions may include a first multicast session and a second multicast session, and the RRC release message may include a first configuration corresponding to the first multicast session and a second configuration corresponding to the second multicast session.

[0121] In some implementations, the RRC release message may include one or more thresholds (e.g., RSRP or RSRQ thresholds) corresponding to the indicated one or more multicast sessions. For example, the one or more multicast sessions may include a first multicast session and a second multicast session, and the RRC release message may include a first threshold corresponding to the first multicast session and a second threshold corresponding to the second multicast session. In this way, the UE may configure the first threshold for the first multicast session and the second threshold for the second multicast session. In some cases, the first threshold may be equal to the second threshold. In some cases, the first threshold may not be equal to the second threshold.

[0122] However, the present disclosure does not limit the means for measuring signal quality.For example, the RRC release message may include at least one of an RSRP threshold, an RSRQ threshold, or an RSSI threshold.

[0123] In some specific implementations, the UE may receive a configuration (e.g., a third configuration) of a neighboring cell for receiving the first data of the first multicast session from the base station. The configuration may, for example, be associated with the first multicast session and received via broadcast system information. For example, the UE may receive a list of cell IDs supporting reception of data of the multicast session in an RRC inactive state from the base station.

[0124] In action S120, the UE may receive first data of a first multicast session in the RRC inactive state based on a first configuration associated with the first multicast session of the at least one multicast session and included in the RRC release message. The first multicast session may be, for example, a multicast session of interest to the UE.

[0125] Specifically, the first multicast session may be one of the one or more multicast sessions indicated in the suspension configuration included in the RRC release message received in action S110; therefore, the UE is allowed to receive data of the first multicast session.

[0126] Specifically, the first configuration associated with the first multicast session is also included in the RRC release message received in action S110 .

[0127] In action S130, the UE may determine whether to initiate or trigger an RRC connection recovery procedure. It should be noted that in the present disclosure, the RRC connection recovery procedure may also be referred to as an RRC recovery procedure.

[0128] Specifically, the UE may determine whether to initiate or trigger the RRC recovery process if the UE cannot receive data of a multicast session that the UE wants. In the previous paragraphs, several scenarios of this situation are described as specific implementations.

[0129] In some specific implementations, the UE may determine whether to initiate or trigger the RRC recovery process based at least on the reception quality of the first data of the received first multicast session. For example, if the reception quality is lower than (or equal to) a configured threshold (e.g., a first threshold) associated with the first multicast session, the UE may determine to initiate or trigger the RRC recovery process.

[0130] In some implementations, the UE may determine whether to initiate or trigger an RRC recovery procedure based on whether the UE has a valid configuration for receiving the first data of the first multicast session. For example, if the UE does not have a valid configuration for receiving the first data of the first multicast session, the UE may determine to initiate or trigger an RRC recovery procedure.

[0131] In some specific implementations, the UE may determine whether to initiate or trigger the RRC recovery process based on whether the first data of the first multicast session is allowed to be received in the RRC inactive state. For example, if the first data of the first multicast session is not allowed to be received in the RRC inactive state, the UE may determine to initiate or trigger the RRC recovery process.

[0132] In some specific implementations, the UE may perform a cell (re)selection procedure and join the reselected cell. In this case, the UE may need a new configuration for the reselected cell. In the case where the UE has received a specific configuration (e.g., a third configuration associated with the first multicast session) of a neighboring cell for receiving the first data of the first multicast session via broadcast system information, when the specific configuration is not available for the first multicast session in the reselected cell, the UE may determine to initiate or trigger the RRC recovery procedure.

[0133] In some implementations, just before or after the UE determines to initiate or trigger the RRC recovery process, the UE may stop receiving the first data of the first multicast session.

[0134] If the UE determines to initiate or trigger an RRC resumption procedure, action S140 may be performed. In action S140, the UE may initiate or trigger an RRC resumption procedure (e.g., for transitioning to an RRC connected state, or receiving a configuration for receiving first data for a first multicast session in an RRC connected state or an RRC inactive state).

[0135] In case the UE determines not to initiate or trigger the RRC resumption procedure, action S150 may be performed. In action S150, the UE may keep receiving the first data of the first multi-session in the RRC inactive state based on the first configuration (or updated / stored configuration).

[0136] Figure 2 is a block diagram illustrating a node 200 for wireless communication according to an example implementation of the present disclosure. Figure 2 As illustrated, the node 200 may include a transceiver 220, a processor 228, a memory 234, one or more presentation components 238, and at least one antenna 236. The node 200 may also include a radio frequency (RF) band module, a BS communication module, a NW communication module, and a system communication management module, an input / output (I / O) port, an I / O component, and a power supply ( Figure 2 not shown).

[0137] Each of these components may communicate with each other directly or indirectly via one or more buses 240. Node 200 may be a processor that executes a reference Figure 1 Disclose various functions of UE or BS.

[0138] A transceiver 220 having a transmitter 222 (e.g., a transmitting circuit) and a receiver 224 (e.g., a receiving circuit) may be configured to transmit and / or receive time and / or frequency resource partitioning information. The transceiver 220 may be configured to transmit in different types of subframes and time slots, including but not limited to available, unavailable, and flexibly usable subframe and time slot formats. The transceiver 220 may be configured to receive data and control channels.

[0139] Node 200 may include various computer-readable media. Computer-readable media may be any available media that can be accessed by node 200, and includes volatile (and / or non-volatile) media and removable (and / or non-removable) media.

[0140] Computer readable media may include computer storage media and communication media. Computer storage media may include volatile (and / or non-volatile) media and removable (and / or non-removable) media implemented in any method or technology for storing information such as computer readable instructions, data structures, program modules or data.

[0141] Computer storage media may include RAM, ROM, EPROM, EEPROM, flash memory (or other storage technology), CD-ROM, digital versatile disk (DVD) (or other optical disk storage), cassettes, magnetic tape, magnetic disk storage (or other magnetic storage devices), etc. Computer storage media may not include propagated data signals. Communication media may generally be embodied as computer readable instructions, data structures, program modules or other data in a modulated data signal (such as a carrier wave), or other transport mechanism, and include any information delivery media.

[0142] The term "modulated data signal" may refer to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Communication media may include wired media such as a wired NW or direct-wired connection and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the previously listed components should also be included within the scope of computer-readable media.

[0143] The memory 234 may include computer storage media in the form of volatile and / or non-volatile memory. The memory 234 may be removable, non-removable, or a combination thereof. Example memories may include solid-state memory, hard drives, optical drives, etc. Figure 2 As illustrated, the memory 234 may store computer-readable and / or computer-executable instructions 232 (e.g., software codes or parameters) that, when executed, are configured to cause the processor 228 to perform the operations described herein, for example, with reference to Figure 17. Alternatively, instructions 232 may not be directly executable by processor 228, but may be configured to cause node 200 (eg, when compiled and executed) to perform various functions disclosed herein.

[0144] The processor 228 (e.g., having a processing circuit) may include an intelligent hardware device, such as a central processing unit (CPU), a microcontroller, an ASIC, etc. The processor 228 may include a memory. The processor 228 may process data 230 and instructions 232 received from the memory 234, as well as information sent and received via the transceiver 220, the baseband communication module, and / or the NW communication module. The processor 228 may also process information transmitted to the transceiver 220 for transmission to the NW communication module via the antenna 236 for transmission to the core network (CN).

[0145] One or more presentation components 238 can present the data indication to a person or another device. Examples of presentation components 238 can include a display device, a speaker, a printing component, a vibration component, etc.

[0146] In view of the present disclosure, various techniques may be used to implement the disclosed concepts without departing from the scope of those concepts. In addition, although these concepts have been disclosed with specific reference to certain specific implementations, those of ordinary skill in the art will recognize that changes may be made in form and detail without departing from the scope of these concepts. Therefore, the disclosed specific implementations are considered to be illustrative and not restrictive in all respects. It should also be understood that the present disclosure is not limited to the disclosed specific implementations. Nevertheless, many rearrangements, modifications, and substitutions are possible without departing from the scope of the present disclosure.

Claims

1. A method for receiving multicast data performed by a user equipment (UE), the method comprising: receiving a radio resource control (RRC) release message including a suspension configuration from a base station (BS), the suspension configuration indicating at least one multicast session, data of the multicast session being allowed to be received by the UE in an RRC inactive state; receiving first data of a first multicast session of the at least one multicast session in the RRC inactive state based on a first configuration associated with the first multicast session, wherein the first configuration is included in the RRC release message; determining whether a reception quality of the first data of the first multicast session is lower than a first threshold; as well as In a case where the reception quality of the first data of the first multicast session is lower than the first threshold, an RRC connection recovery procedure is triggered.

2. The method according to claim 1, wherein the first threshold is included in the RRC release message.

3. The method according to claim 1, further comprising: When the reception quality of the first data of the first multicast session is lower than the first threshold, stop receiving the first data of the first multicast session.

4. The method of claim 1, wherein the first threshold comprises at least one of a reference signal received power (RSRP) threshold or a reference signal received quality (RSRQ) threshold.

5. The method according to claim 1, further comprising: configuring the first threshold for the first multicast session; as well as A second threshold is configured for a second multicast session in the at least one multicast session.

6. The method according to claim 1, further comprising: In case the UE does not have a valid configuration for receiving the first data of the first multicast session, the RRC connection recovery procedure is triggered.

7. The method according to claim 1, further comprising: receiving, via broadcast system information, a second configuration of a neighboring cell for receiving the first data of the first multicast session, wherein the second configuration is associated with the first multicast session; performing a cell reselection process to join a reselected cell; as well as In case that the second configuration associated with the first multicast session is not available for the first multicast session in the reselected cell, the RRC connection recovery procedure is triggered.

8. A user equipment (UE), the UE comprising: one or more processors; and at least one memory coupled to at least one of the one or more processors, wherein the at least one memory stores a computer executable program that, when executed by the at least one of the one or more processors, causes the UE to: receiving a radio resource control (RRC) release message including a suspension configuration from a base station (BS), the suspension configuration indicating at least one multicast session, data of the multicast session being allowed to be received by the UE in an RRC inactive state; receiving first data of a first multicast session of the at least one multicast session in the RRC inactive state based on a first configuration associated with the first multicast session, wherein the first configuration is included in the RRC release message; determining whether a reception quality of the first data of the first multicast session is lower than a first threshold; as well as In a case where the reception quality of the first data of the first multicast session is lower than the first threshold, an RRC connection recovery procedure is triggered.

9. The UE according to claim 8, wherein the first threshold is included in the RRC release message.

10. The UE of claim 8, wherein the one or more computer executable instructions, when executed by the at least one processor of the one or more processors, further cause the UE to: When the reception quality of the first data of the first multicast session is lower than the first threshold, stop receiving the first data of the first multicast session.

11. The UE of claim 8, wherein the first threshold comprises at least one of a reference signal received power (RSRP) threshold or a reference signal received quality (RSRQ) threshold.

12. The UE of claim 8, wherein the one or more computer executable instructions, when executed by the at least one processor of the one or more processors, further cause the UE to: configuring the first threshold for the first multicast session; and A second threshold is configured for a second multicast session in the at least one multicast session.

13. The UE of claim 8, wherein the one or more computer executable instructions, when executed by the at least one processor of the one or more processors, further cause the UE to: In case the UE does not have a valid configuration for receiving the first data of the first multicast session, the RRC connection recovery procedure is triggered.

14. The UE of claim 8, wherein the one or more computer executable instructions, when executed by the at least one processor of the one or more processors, further cause the UE to: receiving, via broadcast system information, a second configuration of a neighboring cell for receiving the first data of the first multicast session, wherein the second configuration is associated with the first multicast session; performing a cell reselection process to join a reselected cell; as well as In case that the second configuration associated with the first multicast session is not available for the first multicast session in the reselected cell, the RRC connection recovery procedure is triggered.

15. A base station (BS), the BS comprising: one or more processors; and at least one memory coupled to at least one of the one or more processors, wherein the at least one memory stores a computer executable program that, when executed by the at least one of the one or more processors, causes the BS to: sending a radio resource control (RRC) release message including a suspension configuration to a user equipment (UE), the suspension configuration indicating at least one multicast session, data of the multicast session being allowed to be received by the UE in an RRC inactive state, wherein the RRC release message also includes at least one configuration associated with the at least one multicast session, and causing the UE to: receiving first data of a first multicast session of the at least one multicast session in the RRC inactive state based on a first configuration associated with the first multicast session, wherein the first configuration is included in the RRC release message; determining whether a reception quality of the first data of the first multicast session is lower than a first threshold; as well as In a case where the reception quality of the first data of the first multicast session is lower than the first threshold, an RRC connection recovery procedure is triggered. The BS of claim 15 , wherein the first threshold is included in the RRC release message.

17. The BS according to claim 15, wherein the RRC release message further causes the UE to: When the reception quality of the first data of the first multicast session is lower than the first threshold, stop receiving the first data of the first multicast session.

18. The BS of claim 15, wherein the first threshold comprises at least one of a reference signal received power (RSRP) threshold or a reference signal received quality (RSRQ) threshold.

19. The BS according to claim 15, wherein the RRC release message further causes the UE to: configuring the first threshold for the first multicast session; and A second threshold is configured for a second multicast session in the at least one multicast session.

20. The BS according to claim 15, wherein the RRC release message further causes the UE to: In case the UE does not have a valid configuration for receiving the first data of the first multicast session, the RRC connection recovery procedure is triggered.

Images