Method and user equipment for multicast / broadcast service data reception

Abstract

A method for receiving multicast service data is provided. The method determines whether a first physical downlink control channel (PDCCH) addressed by a first radio network temporary identifier (RNTI) is received on a first bandwidth part (BWP), the first PDCCH indicating downlink allocation of data for the multicast service. If a BWP deactivation timer and a default BWP are configured, and the first BWP is not the default BWP, the method (re)starts the BWP deactivation timer after determining that the first PDCCH is received on the first BWP, and when the BWP deactivation timer expires, switches from the first BWP to the default BWP. If a BWP deactivation timer is configured but a default BWP is not configured, and the first BWP is not an initial BWP, the method (re)starts the BWP deactivation timer after determining that the first PDCCH is received on the first BWP, and when the BWP deactivation timer expires, switches from the first BWP to the initial BWP.

Description

Technical Field

[0001] The present disclosure relates generally to wireless communications, and more particularly to a method and user equipment (UE) for receiving multicast / broadcast service (MBS) data. Background Art

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

[0003] The 5G NR system is designed to provide flexibility and configurability to optimize network services and types to suit different use cases, such as enhanced Mobile Broadband (eMBB), massive Machine-Type Communication (mMTC), and Ultra-Reliable and Low-Latency Communication (URLLC).

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

[0005] The present disclosure relates to a method and UE for MBS data reception.

[0006] According to a first aspect of the present disclosure, a method for receiving MBS data is provided. The method includes: receiving MBS-related control information from a base station (BS), the MBS-related control information indicating at least one of the following: a first radio network temporary identifier (RNTI) associated with the MBS, a control resource set (CORESET) configured for the MBS, a search space configured for the MBS, and frequency resources configured for the MBS; and receiving data for the MBS from the BS based on the MBS-related control information.

[0007] According to a second aspect of the present disclosure, a UE for MBS data reception is provided. The UE includes: a processor; and a memory coupled to the processor, wherein the memory stores a computer-executable program that, when executed by the processor, causes the processor to perform the method for MBS data reception according to various embodiments of the present disclosure.

[0008] According to a third aspect of the present disclosure, a method for receiving multicast service data performed by a user equipment (UE) is provided. The method includes: determining whether a first physical downlink control channel (PDCCH) addressed by a first radio network temporary identifier (RNTI) is received on a first bandwidth part (BWP), the first PDCCH indicating downlink allocation of data for a multicast service; if a BWP deactivation timer and a default BWP are configured and the first BWP is not the default BWP, after determining that the first PDCCH is received on the first BWP, starting or restarting the BWP deactivation timer, and switching from the first BWP to the default BWP when the BWP deactivation timer expires; and if the BWP deactivation timer is configured but the default BWP is not configured and the first BWP is not an initial BWP, after determining that the first PDCCH is received on the first BWP, starting or restarting the BWP deactivation timer, and switching from the first BWP to the initial BWP when the BWP deactivation timer expires.

[0009] In some embodiments of the third aspect of the present disclosure, the method further includes: receiving control information from a base station (BS); and receiving the data of the multicast service according to the control information, wherein the control information indicates at least one of the following: a control resource set (CORESET) configured for the multicast service, a search space configured for the multicast service, and a frequency resource configured for the multicast service.

[0010] In some embodiments of the third aspect of the present disclosure, the method further includes: receiving an indicator from a base station (BS), the indicator indicating whether hybrid automatic repeat request (HARQ)-acknowledgement (ACK) feedback transmission of the data for the multicast service is enabled.

[0011] In some embodiments of the third aspect of the present disclosure, the method further includes: receiving the data of the multicast service through a first radio link control (RLC) entity of the UE; and receiving a copy of the data of the multicast service through a second RLC entity of the UE, wherein the first RLC entity and the second RLC entity are associated with a common packet data convergence protocol (PDCP) entity of the UE.

[0012] In some embodiments of the third aspect of the present disclosure, the data of the multicast service is received from a base station (BS) in a point-to-multipoint (PTM) transmission mode, and the copy of the data of the multicast service is received from the BS in a point-to-point (PTP) transmission mode.

[0013] In some implementations of the third aspect of the present disclosure, the method further includes: transmitting to a base station (BS) an indication that the UE supports receiving the data of the multicast service.

[0014] In some embodiments of the third aspect of the present disclosure, the method further includes: determining whether there is an ongoing random access procedure associated with the serving cell; and after determining that there is no ongoing random access procedure associated with the serving cell, starting or restarting the BWP deactivation timer.

[0015] In some embodiments of the third aspect of the present disclosure, the method further includes: upon receiving a second PDCCH addressed by a second RNTI, determining whether an ongoing random access procedure associated with the serving cell is successfully completed; and after determining that the random access procedure is successfully completed, starting or restarting the BWP deactivation timer.

[0016] In some implementations of the third aspect of the present disclosure, the second RNTI is a cell-RNTI (C-RNTI).

[0017] According to a fourth aspect of the present disclosure, a user equipment (UE) for receiving multicast / broadcast service data is provided, the UE comprising: at least one processor; and at least one memory coupled to the at least one processor, wherein the at least one memory stores at least one computer executable program, and the at least one computer executable program, when executed by the at least one processor, causes the at least one processor to perform operations, including: determining whether a first physical downlink control channel (PDCCH) addressed by a first radio network temporary identifier (RNTI) is received on a first bandwidth part (BWP), the first PDCCH indicating a downlink allocation of data for a multicast service; and determining whether a first physical downlink control channel (PDCCH) addressed by a first radio network temporary identifier (RNTI) is received on a first bandwidth part (BWP); and determining whether a first physical downlink control channel (PDCCH) indicating a first physical downlink control channel (PDCCH) for a multicast service is received on a first bandwidth part (BWP); and determining whether ... In a case where a BWP deactivation timer and a default BWP are configured, and the first BWP is not the default BWP, after determining that the first PDCCH is received on the first BWP, the BWP deactivation timer is started or restarted, and when the BWP deactivation timer expires, switching from the first BWP to the default BWP is performed; and in a case where the BWP deactivation timer is configured but the default BWP is not configured, and the first BWP is not the initial BWP, after determining that the first PDCCH is received on the first BWP, the BWP deactivation timer is started or restarted, and when the BWP deactivation timer expires, switching from the first BWP to the initial BWP is performed.

[0018] In some embodiments of the fourth aspect of the present disclosure, the operation also includes: receiving control information from a base station (BS); and receiving the data of the multicast service based on the control information, wherein the control information indicates at least one of the following: a control resource set (CORESET) configured for the multicast service, a search space configured for the multicast service, and a frequency resource configured for the multicast service.

[0019] In some embodiments of the fourth aspect of the present disclosure, the operation further includes: receiving an indicator from a base station (BS), the indicator indicating whether hybrid automatic repeat request (HARQ)-acknowledgement (ACK) feedback transmission of the data for the multicast service is enabled.

[0020] In some embodiments of the fourth aspect of the present disclosure, the operation also includes: receiving the data of the multicast service through a first radio link control (RLC) entity of the UE; and receiving a copy of the data of the multicast service through a second RLC entity of the UE, wherein the first RLC entity and the second RLC entity are associated with a common packet data convergence protocol (PDCP) entity of the UE.

[0021] In some embodiments of the fourth aspect of the present disclosure, the data of the multicast service is received from a base station (BS) in a point-to-multipoint (PTM) transmission mode, and the copy of the data of the multicast service is received from the BS in a point-to-point (PTP) transmission mode.

[0022] In some implementations of the fourth aspect of the present disclosure, the operation further includes: transmitting an indication to a base station (BS) that the UE supports receiving the data of the multicast service.

[0023] In some embodiments of the fourth aspect of the present disclosure, the operation further includes: determining whether there is an ongoing random access process associated with the serving cell; and after determining that there is no ongoing random access process associated with the serving cell, starting or restarting the BWP deactivation timer.

[0024] In some embodiments of the fourth aspect of the present disclosure, the operation also includes: when receiving a second PDCCH addressed by a second RNTI, determining whether an ongoing random access procedure associated with the serving cell is successfully completed; and after determining that the random access procedure is successfully completed, starting or restarting the BWP deactivation timer.

[0025] In some implementations of the fourth aspect of the present disclosure, the second RNTI is a cell-RNTI (C-RNTI). BRIEF DESCRIPTION OF THE DRAWINGS

[0026] When combined with Figure 1 The aspects of the present disclosure are best understood from the following detailed disclosure when read together. Various features are not drawn to scale. The size of various features may be arbitrarily increased or decreased for clarity of discussion.

[0027] Figure 1 A flow chart of a method for MBS data reception according to an embodiment of the present disclosure is shown.

[0028] Figure 2 A flow chart of a method for MBS data reception according to an embodiment of the present disclosure is shown.

[0029] Figure 3 A flow chart of a method for MBS data reception according to an embodiment of the present disclosure is shown.

[0030] Figure 4 is a schematic diagram illustrating a common Packet Data Convergence Protocol (PDCP) entity associated with a first Radio Link Control (RLC) entity for receiving MBS data and a second RLC entity for receiving a copy / duplicate of the MBS data.

[0031] Figure 5 An example of resource allocation of an initial BWP configured for a UE and frequency resources indicated by MBS-related control information is shown.

[0032] Figure 6 A block diagram of a node for wireless communication is shown in accordance with various aspects of the present disclosure. DETAILED DESCRIPTION

[0033] The following description contains specific information related to exemplary embodiments of the present disclosure. The figures and the accompanying detailed description relate only to exemplary embodiments. However, the present disclosure is not limited to these exemplary embodiments. Those skilled in the art will recognize other variations and embodiments of the present disclosure. Unless otherwise indicated, identical or corresponding elements in the accompanying drawings may be represented by identical or corresponding reference numerals. Furthermore, the figures and illustrations in the present disclosure are generally not drawn to scale and are not intended to correspond to actual relative dimensions.

[0034] For consistency and ease of understanding, similar features are identified by reference numerals in the exemplary figures (but not shown in some examples). However, features in different embodiments may differ in other respects and should not be narrowly limited to what is shown in the figures.

[0035] References to "one embodiment," "an embodiment," "an exemplary embodiment," "various embodiments," "some embodiments," "embodiments of the present disclosure," and the like may indicate that the embodiments of the present disclosure so described may include a particular feature, structure, or characteristic, but not every possible embodiment of the present disclosure necessarily includes that particular feature, structure, or characteristic. Further, repeated use of the phrases "in one embodiment," "in an exemplary embodiment," or "an embodiment" does not necessarily refer to the same embodiment, although they may. In addition, any phrase like "an embodiment" used in conjunction with "the present disclosure" is by no means intended to characterize that all embodiments of the present disclosure must include a particular feature, structure, or characteristic, but rather should be understood to mean that "at least some embodiments of the present disclosure" include the recited particular feature, structure, or characteristic. The term "coupled" is defined as connected, whether directly or indirectly through intermediate components, and is not necessarily limited to physical connections. The term "comprising," when utilized, means "including, but not necessarily limited to," and specifically indicates open inclusion or membership in the combinations, groups, series, and equivalents so described. The terms "system" and "network" are used interchangeably in this disclosure.

[0036] The term "and / or" in this document simply describes the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone. "A and / or B and / or C" can mean that at least one of A, B, and C exists. The character " / " used here generally indicates that the previous associated object and the next associated object are in an "or" relationship.

[0037] In addition, for the purpose of explanation and non-limiting, 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 making the description unclear with unnecessary details.

[0038] Those skilled in the art will immediately recognize that any network function or algorithm can be implemented by hardware, software, or a combination of software and hardware. The functions described may correspond to modules, which may be software, hardware, firmware, or any combination thereof. Software implementations may include computer-executable instructions stored on a computer-readable medium such as a memory or other type of storage device. For example, one or more microprocessors or general-purpose computers with communication processing capabilities may be programmed using corresponding executable instructions and perform the described network functions or algorithms. These microprocessors or general-purpose computers may be formed by application-specific integrated circuits (ASICs), programmable logic arrays, and / or using one or more digital signal processors (DSPs). Although several exemplary embodiments described in this specification are for software installed and executed on computer hardware, alternative exemplary embodiments implemented as firmware or hardware or a combination of hardware and software are also within the scope of this disclosure.

[0039] 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 disc read-only memory (CD-ROM), cassettes, magnetic tapes, disk storage, or any other equivalent medium capable of storing computer-readable instructions.

[0040] The radio communication network architecture (e.g., Long Term Evolution (LTE) system, LTE-Advanced (LTE-A) system, LTE-Advanced Pro system) generally includes at least one base station (BS), at least one UE, and one or more optional network elements that provide connection to the network. The UE can communicate with the network (e.g., Core Network (CN), Evolved Packet Core (EPC), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Next-Generation Core (NGC), or the Internet) through the Radio Access Network (RAN) established by the BS.

[0041] In this disclosure, a UE may include, but is not limited to, a mobile station, a mobile terminal or device, or a user communication radio terminal. For example, a UE may be a portable radio device, including, but not limited to, a mobile phone, a tablet, a wearable device, a sensor, or a personal digital assistant (PDA) with wireless communication capabilities. A UE may be configured to receive signals over an air interface and transmit signals to one or more cells in a RAN.

[0042] The BS may include, but is not limited to, a Node B (NB) in the Universal Mobile Telecommunication System (UMTS), an evolved Node B (eNB) in LTE-A, a Radio Network Controller (RNC) in UMTS, a BS Controller (BSC) in the Global System for Mobile communication (GSM) / Enhanced Data rates for GSM Evolution (EDGE) RAN (GERAN), a Next Generation (NG)-eNB in ​​the Evolved Universal Terrestrial Radio Access (E-UTRA) BS connected to the 5GC, a Next Generation Node B (gNB) in the 5G-RAN, and any other device capable of controlling radio communications and managing radio resources within a cell. The BS may be connected via a radio interface to serve one or more UEs.

[0043] 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), GSM (commonly referred to as 2G), GERAN, General Packet Radio Service (GPRS), UMTS based on basic Wideband-Code Division Multiple Access (W-CDMA) (commonly referred to as 3G), High-Speed ​​Packet Access (HSPA), LTE, LTE-A, Evolved LTE (eLTE), New Radio (NR, commonly referred to as 5G), and / or LTE-A Pro. However, the scope of the present disclosure should not be limited to these protocols.

[0044] The BS is operable to provide radio coverage to a specific geographical area using multiple cells included in the RAN. The BS supports the operation of cells. Each cell is operable to provide services to at least one UE within its radio coverage. Specifically, each cell (commonly referred to as a serving cell) can provide services to serve one or more UEs within its radio coverage (e.g., each cell schedules downlink and optionally uplink resources to at least one UE within its radio coverage for downlink and optionally uplink packet transmission). The BS can communicate with one or more UEs in the radio communication system via multiple cells.

[0045] The cell can allocate sidelink (SL) resources to support proximity service (ProSe: ProximityService), LTE SL service and LTE / NR vehicle to everything (V2X: Vehicle to Everything) service. Each cell may have a coverage area that overlaps with other cells. In the case of multi-RAT dual connectivity (MR-DC), the main cell of the main cell group (MCG: MasterCell Group) or the secondary cell group (SCG: Secondary Cell Group) may be called a special cell (SpCell: Special Cell). The main cell (PCell: Primary Cell) may refer to the SpCell of the MCG. The primary SCG cell (PSCell: Primary SCG Cell) may refer to the SpCell of the SCG. MCG may refer to a service cell group associated with a master node (MN: Master Node), including SpCell and optionally one or more secondary cells (SCell). SCG may refer to a service cell group associated with a secondary node (SN: Secondary Node), including SpCell and optionally one or more Scells.

[0046] As described above, the frame structure for NR supports flexible configuration to adapt to various next-generation (e.g., 5G) communication requirements such as eMBB, mMTC, and URLLC, while meeting high reliability, high data rate, and low latency requirements. Orthogonal frequency division multiplexing (OFDM) technology as agreed 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 coding schemes are considered for NR: (1) Low Density Parity Check (LDPC) code and (2) polar code. Coding scheme adaptation can be configured based on channel conditions and / or service applications.

[0047] In addition, it is also considered that the transmission time interval of a single NR frame should include at least DL transmission data, protection period and UL transmission data, where the respective parts of DL transmission data, protection period and UL transmission data should also be configurable, for example, based on the dynamic configuration of the NR network. In addition, SL resources can also be provided via NR frames to support ProSe services.

[0048] In LTE, the transmission of Multimedia Broadcast Multicast Service (MBMS) in E-UTRAN can be performed via Multicast Broadcast Single Frequency Network (MBSFN) transmission or Single-cell Point-to-Multipoint (SC-PTM) transmission. The MBMS Coordination Entity (MCE) can determine whether SC-PTM or MBSFN is used for each MBMS session.

[0049] MBMS single-cell transmission may have the following characteristics:

[0050] -MBMS is transmitted within the coverage area of ​​a single cell;

[0051] -One Single Cell Multicast Control Channel (SC-MCCH) and at least one Single Cell Multicast Transport Channel (SC-MTCH) are mapped on the Downlink Shared Channel (DL-SCH);

[0052] - Scheduling is done by eNB;

[0053] -SC-MCCH and SC-MTCH transmissions are each indicated by a logical channel-specific RNTI on the Physical Downlink Control Channel (PDCCH) (there is a one-to-one mapping between the Temporary Mobile Group Identity (TMGI) and the Group RNTI (G-RNTI) for reception of the DL-SCH to which the SC-MTCH is mapped);

[0054] - A single transmission is used for the DL-SCH to which the SC-MCCH or SC-MTCH is mapped (e.g., neither blind Hybrid Automatic Repeat Request (HARQ) repetition nor Radio Link Control (RLC) fast repetition); and

[0055] -SC-MCCH and SC-MTCH use RLC-Unacknowledged Mode (UM) mode.

[0056] On the other hand, MBMS multi-cell transmission may have the following characteristics:

[0057] -Synchronous transmission of MBMS within its MBSFN area;

[0058] - Combination of MBMS transmissions from multiple cells is supported;

[0059] - The scheduling of each multicast channel (MCH) is completed by the MCE;

[0060] - A single transmission is used for the MCH (i.e., neither blind HARQ repetitions nor RLC fast repetitions);

[0061] - Use a single transport block (TB) per transmission time interval (TTI) for MCH transmission, where the TB can use all MBSFN resources in the subframe;

[0062] - Multicast Transport Channel (MTCH) and Multicast Control Channel (MCCH) can be multiplexed on the same MCH and mapped on the MCH for point-to-multipoint (PTM) transmission;

[0063] -MTCH and MCCH can use RLC-UM mode;

[0064] -The MAC subheader indicates the logical channel identity (LCID) used for MTCH and MCCH;

[0065] - MBSFN synchronization area, MBSFN area, and MBSFN cell are semi-statically configured, for example, by Operation & Maintenance (O&M); and

[0066] - MBSFN areas are static unless changed by O&M (ie, there is no dynamic change of areas).

[0067] However, support for broadcast / multicast features was not specified in the first two NR releases, Rel-15 and Rel-16. However, the existence of broadcast / multicast features can provide substantial improvements, especially in key use cases where system efficiency and user experience are important. Support for broadcast / multicast features can benefit resource utilization, as a single copy of an MBS data packet can be received by multiple UEs. Furthermore, communication mechanisms supporting broadcast / multicast features in next-generation networks are still lacking.

[0068] This disclosure provides various MBS-related operations, such as the transmission of UE-specific multicast / broadcast interest indications, the reception of MBS data during bandwidth part (BWP) switching operations, and the dynamic change of MBS delivery between multicast (e.g., PTM transmission mode) and unicast (e.g., point-to-point (PTP) transmission mode) for service continuity for a given UE. Compared to LTE, MBS-related operations are more flexible and better adapt to the requirements of different 5G scenarios (e.g., MBS-related scenarios).

[0069] UE capabilities

[0070] In some embodiments, a UE may report to a network (e.g., a BS) its ability to support receiving MBS (e.g., MBS with high Quality of Service (QoS) requirements) in the RRC_CONNECTED state (e.g., via a UE capability message). In some embodiments, a UE may report to a network (e.g., a BS) its ability to support receiving MBS in the RRC_INACTIVE state and / or the RRC_IDLE state (e.g., via a UE capability message). In some embodiments, a UE may report to a network (e.g., a BS) its ability to support receiving MBS (e.g., MBS with high QoS requirements) in at least one of the RRC_CONNECTED state, the RRC_INACTIVE state, and the RRC_IDLE state (e.g., via a UE capability message). In other words, the reported capability may indicate that the UE is capable of receiving MBS in at least one of the RRC_CONNECTED state, the RRC_INACTIVE state, and the RRC_IDLE state. The UE's support for receiving MBS may mean that the UE is capable of acquiring and processing data packets for the MBS. For simplicity, in this disclosure, MBS data may be referred to as "MBS data." In some embodiments, a UE in an RRC_CONNECTED state (which is referred to as an "RRC_CONNECTED UE") may report its capability of supporting a serving MBS (eg, an MBS with high QoS requirements) to a network (eg, a BS).

[0071] In some embodiments, the UE may report its ability to support receiving MBS in the RRC_INACTIVE state and / or the RRC_IDLE state via an RA procedure, via pre-configured PUSCH resources, based on network instructions, or based on predefined rules, where the network instructions may be transmitted via dedicated signaling or via system information broadcast by the network. For example, if the UE reports its ability to support receiving MBS in the RRC_CONNECTED state, but does not report its ability to support receiving MBS in the RRC_INACTIVE state and / or the RRC_IDLE state, the UE may need to remain in the RRC_CONNECTED state to receive the MBS, and / or the network may not instruct the UE to transition to the RRC_INACTIVE state or the RRC_IDLE state. Otherwise, in this case, the UE may not be able to receive MBS in the RRC_INACTIVE state and / or in the RRC_IDLE state.

[0072] In some embodiments, a UE in an RRC_INACTIVE state (referred to as an "RRC_INACTIVE UE") or in an RRC_IDLE state (referred to as an "RRC_IDLE UE") may report to the network its ability to support the reception of MBS (e.g., MBS with low QoS requirements). The UE's capabilities may be reported to the network via an RA procedure (e.g., a 2-step RA procedure or a 4-step RA procedure) or via pre-configured PUSCH resources, where the pre-configured PUSCH resources may be configured via dedicated signaling (e.g., via an RRC release message) or broadcast in system information. In some embodiments, an RRC_IDLE UE or an RRC_INACTIVE UE may report its ability to support the reception of MBS based on network instructions or predefined rules, where the network instructions may be provided by dedicated signaling and / or system information broadcast by the network.

[0073] In some embodiments, the UE may report its ability to support dynamic changes in MBS delivery between multicast and unicast. If the UE does not report its ability to support dynamic changes in MBS delivery between multicast and unicast, the UE may only receive MBS provided via multicast (e.g., from a multicast radio bearer or a multicast RLC bearer) or MBS provided via unicast (e.g., from a unicast radio bearer or a unicast RLC bearer). MBS delivery via multicast may mean that the network (e.g., a BS) transmits a single copy of the MBS data packet to a group of UEs over the radio (which may be referred to as PTM transmission or PTM transmission mode). MBS delivery via unicast may mean that the network (e.g., a BS) transmits independent copies of the MBS data packet to individual UEs over the radio (which may be referred to as PTP transmission or PTP transmission mode).

[0074] In some embodiments, the UE may report its ability to support dynamic changes in MBS delivery between multicast and unicast based on network instructions or predefined rules, where the network instructions may be provided by dedicated signaling and / or system information broadcast by the network.

[0075] In some embodiments, the UE may report its MBS-related capabilities in the RRC_INACTIVE state and / or the RRC_IDLE state. The MBS-related capabilities may include, but are not limited to: supporting MBS reception, supporting dynamic changes between multicast and unicast MBS delivery, supporting dynamic changes between multicast and unicast MBS delivery based on network instructions or predefined rules, and / or supporting simultaneous MBS reception from the network via the network's PTM transmission mode and PTP transmission mode.

[0076] In some embodiments, the UE may report MBS-related capabilities in the RRC_INACTIVE state and / or RRC_IDLE state via PUSCH resources (e.g., the PUSCH resources indicated in message A (MsgA) of the 2-step RA procedure, the PUSCH resources indicated in message 2 (Msg2) of the 4-step RA procedure, or any other pre-configured PUSCH resources).

[0077] In some embodiments, the UE may report to the network its MBS-related capability of supporting simultaneous PTM and PTP (e.g., receiving MBS data transmitted via both the PTM and PTP transmission modes simultaneously). For example, for a UE supporting simultaneous PTM and PTP, the UE may receive MBS data via a PTM RLC entity and a copy / duplicate of the MBS data via a PTP RLC entity. The PTM RLC entity and the PTP RLC entity may be associated with a common PDCP entity.

[0078] In some embodiments, the UE may report its capabilities regarding whether the UE can receive MBS or whether the UE can start / request MBS to obtain MBS data. For example, in the RRC_INACTIVE state, the UE may initiate / trigger a 4-step RA procedure and transmit an MBS-related message to the network (e.g., gNB / BS) during the initiated / triggered 4-step RA procedure (e.g., via Message 3 (Msg3) transmission). The MBS-related message may indicate the UE capabilities (e.g., MBS-related capabilities), the MBS of interest, and / or the currently received MBS.

[0079] In some embodiments, if an RRC_IDLE / RRC_INACTIVE UE sends an MBS request to the network to start / acquire / request an (interested) MBS, the UE may not move to the RRC_CONNECTED state. In some embodiments, an MBS may refer to a new network slice type, and the UE may report the corresponding Network Slice Selection Assistance Information (NSSAI) or Single Network Slice Selection Assistance Information (S-NSSAI) to the CN. In this case, when the UE is connected to a gNB with MBS capabilities, the UE may only report MBS-related capabilities.

[0080] In some embodiments, a UE may transmit its MBS-related capabilities, or its capabilities associated with an MBS, (only) when the serving cell supports the corresponding MBS. The serving cell may broadcast (e.g., via system information transmission) MBS-related control information indicating which MBS (e.g., an MBS with high QoS requirements or an MBS with low QoS requirements) is supported by the serving cell. For example, the serving cell may broadcast the MBS identity (ID) associated with the target MBS.

[0081] If the information broadcast by the serving cell indicates that the MBS (or the MBS is directed to) has high QoS requirements, the UE may transition to the RRC_CONNECTED state to receive the MBS. In another example, if the information broadcast by the serving cell indicates that the MBS (or the MBS is directed to) has low QoS requirements, the UE may not transition to the RRC_CONNECTED state to receive the MBS, but may receive the MBS in the RRC_IDLE or RRC_INACTIVE state. The RAN and the UE may be aware of the mapping between the MBS ID and the MBS of interest. After the MBS ID (of the MBS of interest) is broadcast by the serving cell, the UE may provide its MBS-related capabilities or capabilities associated with the MBS of interest. Conversely, if the MBS ID is not broadcast by the serving cell, the UE may not report its MBS-related capabilities or capabilities associated with the MBS of interest. The above rules may apply to UEs in the RRC_CONNECTED / RRC_INACITVE / RRC_IDLE states.

[0082] In some embodiments, the UE capabilities described in this disclosure may be frequency-dependent. For example, UE capabilities may be determined separately for Frequency Range 1 (FR1) and Frequency Range 2 (FR2). In some embodiments, the UE capabilities described in this disclosure may be determined separately for Time Division Duplex (TDD) and Frequency Division Duplex (FDD).

[0083] Identify MBS of interest

[0084] In some embodiments, a UE capable of receiving an MBS may determine / consider being interested in the MBS if the UE is receiving data of the MBS or is interested in receiving the MBS.

[0085] In some embodiments, an MBS may be considered an MBS of interest to the UE if at least one of the following conditions is met: the UE is capable of receiving an MBS, the UE is receiving data for the MBS or is interested in receiving the MBS, and the MBS is supported by the serving cell or the camped cell. In some embodiments, the cell may broadcast system information to indicate which MBS(s) are supported. The start time and / or stop time of the MBS may be broadcast to the UE by the cell in system information (e.g., in System Information Block 1 (SIB1) or other MBS-related system information blocks). In some embodiments, the start time and / or stop time of the MBS may be indicated by Coordinated Universal Time (UTC). In some embodiments, the start time and / or stop time of the MBS may be indicated by a System Frame Number (SFN). In some embodiments, the MBSs supported by the cell may be broadcast to the UE by the cell in system information (e.g., in SIB1 or other MBS-related system information blocks).

[0086] In some embodiments, the network may support the provision of a certain MBS but has not yet transmitted the MBS data to the UE. In this case, the UE (e.g., a UE interested in the MBS) may request the network to start transmitting the MBS data (e.g., by sending an MBS request to the network).

[0087] In some embodiments, the operating frequency (or frequency resource) of the MBS (e.g., a specific Absolute Radio Frequency Channel Number (ARFCN), Physical Resource Block (PRB), BWP, or Component Carrier (CC)) may be broadcast / unicast by the cell to the UE.

[0088] In some embodiments, an LTE cell or NR cell may broadcast the operating frequency (or frequency resource) of the NR MBS (e.g., a specific NR-ARFCN, PRB, BWP, CC, or other auxiliary information such as subcarrier spacing or cyclic prefix length). The NR cell may broadcast the operating frequency (e.g., a specific ARFCN / bandwidth) of the LTE MBS.

[0089] Multicast / Broadcast Interest Indication

[0090] In some embodiments, the UE may send a multicast / broadcast interest indication message to the network (e.g., gNB) to indicate the MBS of interest. The indication may be slice-specific information or include slice information corresponding to the MBS of interest. The UE may report the target MBS slice to the NW. The multicast / broadcast interest indication message may include identification information of the MBS of interest (e.g., Temporary Mobile Group Identity (TMGI)) and / or priority information associated with the MBS of interest. For example, the MBS of interest may be identified by the TMGI and / or the session ID associated with the MBS of interest. The priority information may be used to indicate whether MBS data reception takes precedence over unicast reception for the UE.

[0091] In some embodiments, a UE may request the network to provide an MBS (e.g., an MBS that is supported by the network but has not yet been multicast / broadcasted by the network). For example, the network may count the total number of UEs that are interested in a particular MBS and then transmit the content of the MBS (or MBS data) via a PTM transmission mode (or multicast mode) rather than a PTP transmission mode (or unicast mode).

[0092] In some embodiments, the UE may inform the network of which MBSs the UE is not interested in. For example, the UE may send slice information / MBS IDs to the network indicating one or more MBSs that the UE is not interested in. The network may determine that most UEs (or a specific number of UEs) are not interested in the MBSs and transmit the MBSs using the PTP transmission mode (or unicast mode) instead of the PTM transmission mode (or multicast mode).

[0093] In some implementations, the UE can notify the network of one or more MBSs that it does not need by transmitting slice information or MBS IDs to the network. After receiving the slice information with the MBS IDs, the network can know which MBSs the UE does not need. The network can then hand over the UE to another BWP.

[0094] MBS Reception During BWP Switching Operation

[0095] In some embodiments, the UE may be instructed by the network (eg, via RRC, MAC CE, or DCI signaling) to switch to a specific BWP (eg, MBS BWP) to receive MBS. Receiving an MBS may refer to receiving data of one or more MBSs.

[0096] For a UE, an MBS BWP may be a BWP used (at least or only) for MBS data reception. A UE capable of receiving MBS may be allowed to receive data of the MBS (of interest) on the MBS BWP in the RRC_INACTIVE / RRC_IDLE / RRC_CONNECTED state. In one embodiment, the MBS BWP may not be the initial BWP.

[0097] MBS BWP may also be referred to as multicast / broadcast BWP. MBS BWP and multicast / broadcast BWP are not currently uniformly named in the industry and are collectively referred to as "MBS BWP" in this disclosure.

[0098] For RRC_IDLE / RRC_INACTIVE / RRC_CONNECTED UEs, common frequency resources (or associated MBS BWP) for group-common PDCCH / Physical Downlink Shared Channel (PDSCH) may be configured or defined. Group-common PDCCH / PDSCH may be used for MBS data reception. If no common frequency resources are configured or defined, the UE may consider the initial BWP to be the default common frequency resource for group-common PDCCH / PDSCH.

[0099] For a PCell or camped cell, the initial BWP may be the BWP used for initial access. In one embodiment, the MBS BWP may overlap (or include) the initial BWP in the frequency domain. In one embodiment, the MBS BWP may be the same as the initial BWP. Information related to the (initial / configured / default) MBS BWP may be broadcast via system information or provided via dedicated signaling from the network. The MBS BWP information may include the corresponding BWP configuration and / or frequency resource allocation.

[0100] A BWP may be explicitly or implicitly configured by the network as an MBS BWP. For example, an MBS BWP may be associated with one or more MBSs or TMGIs or other MBS-related information. If a BWP is configured with a multicast / broadcast control channel (e.g., group-common PDCCH) or a multicast / broadcast data channel (e.g., group-common PDSCH) or other multicast / broadcast-related channel, the BWP may be considered an MBS BWP. In some embodiments, a BWP may be indicated as an MBS BWP via an associated BWP configuration. For example, a field or indication in an RRC message may be used to indicate whether the BWP is an MBS BWP. For example, if the field / indication is set to true, the BWP may be considered an MBS BWP. If the field is set to false or does not exist, the BWP may be considered a normal BWP.

[0101] In some embodiments, the UE may fall back to the default BWP due to the expiration of the BWP deactivation timer (which counts the duration in milliseconds (ms)). If the network releases the BWP deactivation timer configuration (or the UE receives a message indicating the release of the BWP deactivation timer configuration), the UE may stop the BWP deactivation timer without switching to the default BWP or the initial BWP (if the default BWP is not configured). The default BWP may be configured by the network. If the default BWP is not indicated by the network, the initial BWP may be considered the default BWP.

[0102] In one embodiment, once the UE switches to the MBS BWP, if a BWP deactivation timer is configured (which may be a cell-specific timer) and / or if the MBS BWP is not the default DL BWP, the UE (e.g., the MAC entity of the UE) may not switch to the default DL BWP even if the BWP deactivation timer expires.

[0103] In one embodiment, once the UE switches to the MBS BWP, if a BWP deactivation timer is configured (which may be a cell-specific timer) and / or if the MBS BWP is not the initial DL BWP, the UE (e.g., the MAC entity of the UE) may not switch to the initial DL BWP even if the BWP deactivation timer expires.

[0104] In some embodiments, once the UE switches to the MBS BWP, if a BWP deactivation timer is configured (which may be a cell-specific timer) and / or if the MBS BWP is not the default DL BWP, the UE (or the MAC entity of the UE) may not apply (or initiate) the BWP deactivation timer. For example, when the BWP deactivation timer is not applied, the BWP deactivation timer may be stopped by the UE or may not be started or restarted by the UE.

[0105] In some embodiments, once the UE switches to the MBS BWP, if a BWP deactivation timer is configured (which may be a cell-specific timer) and / or if the MBS BWP is not the initial DL BWP (and no default BWP is configured), the UE (or the MAC entity of the UE) may not apply (or initiate) the BWP deactivation timer. For example, when the BWP deactivation timer is not applied, the BWP deactivation timer may be stopped by the UE or may not be started or restarted by the UE.

[0106] In some embodiments, when the BWP deactivation timer is configured, the UE may start or restart the BWP deactivation timer if the activated BWP is not the default DL BWP and / or if a PDCCH indicating a DL allocation or UL grant addressed by the MBS-related RNTI is received by the UE on the BWP.

[0107] In some embodiments, when the BWP deactivation timer is configured, the UE may start or restart the BWP deactivation timer if the activated BWP is not the default DL BWP and / or if a PDCCH indicating a DL allocation or UL grant addressed by the MBS-related RNTI for the BWP is received by the UE.

[0108] In some embodiments, when the BWP deactivation timer is configured, if the activated BWP is not the initial DL BWP (and the default BWP is not configured) and / or if a PDCCH indicating a DL allocation or UL grant addressed by the MBS-related RNTI is received by the UE on the BWP, the UE may start or restart the BWP deactivation timer.

[0109] In some embodiments, when the BWP deactivation timer is configured, if the activated BWP is not the initial DL BWP (and the default DL BWP is not configured) / or if a PDCCH for indicating a DL allocation or UL grant addressed by the MBS-related RNTI for the BWP is received by the UE, the UE may start or restart the BWP deactivation timer.

[0110] For RRC_IDLE / RRC_INACTIVE UEs, a group-common PDCCH with a cyclic redundancy check (CRC) scrambled by a common RNTI may be configured and used to schedule a group-common PDSCH, where the group-common PDSCH may be scrambled based on the same common RNTI.

[0111] In some embodiments, the MBS-related RNTI may be a single cell RNTI (SC-RNTI: Single Cell RNTI) (used for dynamic scheduling of SC-PTM control information), a G-RNTI (used for dynamic scheduling of SC-PTM transmission), a single cell notification RNTI (SC-N-RNTI: Single Cell Notification RNTI) (used for SC-MCCH information change notification), an MBMS RNTI (M-RNTI) (used for MCCH information change notification), or a cell RNTI (C-RNTI). The MBS-related RNTI includes MBS-RNTI#1 and MBS-RNTI#2 (e.g., G-RNTI), where MBS-RNTI#1 may be used for MBS control information (e.g., control information on a PDCCH), and MBS-RNTI#2 may be used for MBS services / data (e.g., MBS services / data on a PDSCH). In some embodiments, an RRC_CONNECTED UE may be configured / instructed to use MBS-RNTI#1 to descramble MBS control information (e.g., control information (or DCI) on the PDCCH) and to use MBS-RNTI#2 to descramble MBS traffic / data (e.g., MBS traffic / data on the PDSCH). Otherwise, an RRC_CONNECTED UE may use the same common RNTI to descramble MBS control information and MBS traffic / data.

[0112] In one embodiment, when a UE operates in an MBS BWP, the UE may ignore the C-RNTI (e.g., for monitoring PDCCH or CORESET). Blind decoding (BD) and control channel element (CCE) restrictions may be adjusted. For example, the BD and CCE restrictions for an MBS BWP may be adjusted based on the UE's MBS-related capabilities. In one embodiment, a UE capable of receiving MBS data may have different BD and CCE restrictions than a UE not capable of receiving MBS data.

[0113] An example of UE (or MAC entity) operation is shown in Table 1.

[0114] Table 1

[0115]

[0116]

[0117] In some embodiments, the MBS BWP may be a paired BWP or a non-paired BWP, where UL resources may be scheduled by a specific CORESET for unicast services.

[0118] In some embodiments, the MBS BWP may be a pure DL-only BWP. For example, the MBS (DL) BWP may not be associated with a ULBWP.

[0119] In some embodiments, the MBS (DL) BWP may be associated with the initial (UL) BWP.

[0120] UE prioritization rules between initial BWP and MBS-BWP

[0121] In some embodiments, the UE may monitor both the initial BWP and the MBS BWP in the DL direction (e.g., when the MBS BWP is different from the initial BWP). However, in some cases, the UE may not be able to monitor both the initial BWP and the MBS BWP simultaneously (e.g., due to UE hardware limitations). In this case, the UE may only receive DL signaling or DL ​​packets from the initial BWP or the MBS BWP based on certain prioritization rules or network configurations. For example, at least one of the following rules (Rule #1, Rule #2, and Rule #3) may be configured for the UE:

[0122] Rule #1: The initial BWP may always have a higher priority than the MBS BWP. Therefore, the UE may switch from the MBS BWP to the initial BWP to receive all or part of the transmitted SSB burst set and physical channels (e.g., physical broadcast channel (PBCH), physical downlink control channel (PDCCH), etc.) based on the received SSB burst set configuration and / or search space configuration. Furthermore, for measurement purposes, the UE may switch to the initial BWP (e.g., to measure the DMRS multiplexed in the PBCH broadcast by the serving cell).

[0123] Rule #2: For DL ​​signaling / packet transmission, the initial BWP may have a higher priority than the MBS BWP. For example, the UE may switch only to the initial BWP for SSB burst set monitoring and / or for paging reception (e.g., based on a given SSB burst set configuration and / or discontinuous reception (DRX) cycle configuration associated with the initial BWP). The UE may monitor / acquire system information discontinuously. The UE may monitor / acquire system information only when triggered to monitor / acquire updated system information by paging reception, an SI (System Information) modification indication, or a warning system indication (e.g., when the systemInfoModification bit in a short message is set to 1 or the etwsAndCmasIndication bit in a short message is set to 1).

[0124] Rule #3: The MBS BWP may always have a higher priority than the initial BWP. For example, the UE may not switch to the initial BWP unless requested by upper layers. In some embodiments, the UE may switch from the MBS BWP to the initial BWP based on a request from upper layers (e.g., the non-access stratum (NAS)). For example, if the UE is requested by the NAS layer to use the initial (ProSe) sidelink or (NR / LTE) V2X service, the UE may switch from the MBS BWP to the initial BWP to receive broadcast system information for the service of interest. In some embodiments, the UE may switch from the MBS BWP to the initial BWP based on a request from the RRC layer. For example, the RRC layer may trigger RRC-related procedures such as the RRC connection establishment procedure, the RRC connection recovery procedure, or the RAN notification area update procedure.

[0125] The rules (Rule #1, Rule #2, and Rule #3) may be pre-installed in the Universal Subscriber Identity Module (USIM), predefined in the 3GPP Technical Specification (TS), and / or configured by the network. In some embodiments, the priority of the initial BWP and / or MBS BWP is configurable. In some embodiments, the priority rules may be configurable.

[0126] In some embodiments, the UE may switch from the MBS BWP to the initial BWP based on DL signaling transmitted on the MBS BWP. For example, an SSB burst set, a search space for system information, a short message, a paging message, and / or DMRS may be configured on the MBS BWP. In some embodiments, the UE may switch from the MBS BWP to the initial BWP when one of the following conditions (conditions (a), (b), and (c)) is met:

[0127] (a) The UE receives a paging message with the systemInfoModification bit set to 1 or the etwsAndCmasIndication bit set to 1 in the short message;

[0128] (b) the UE receives a paging message, in which the UE ID is included in the parameter pagingrecord; and

[0129] (c) When the UE is listening to an SSB burst set transmitted on an MBS BWP, the UE detects a beam failure event, wherein the UE may initiate a beam failure recovery procedure on the initial BWP.

[0130] In some implementations, the UE may perform cell-specific measurements based on the DMRS scrambled in the MBS-BWP instead of the DMRS scrambled in the initial BWP.

[0131] Receive MBS

[0132] In some embodiments, the network may provide MBS-related control information (or related configuration) via broadcast system information, MCCH, or dedicated signaling. For example, the network may configure the MBS-related control information or BWP-related configuration in RRC signaling. The UE (e.g., in the RRC_IDLE state or the RRC_INACTIVE state) may receive the MBS-related control information / related configuration via the Broadcast Control Channel (BCCH) and / or the MCCH. For example, a new SIB may be used to accommodate the configuration of the MBS-related control information.

[0133] For RRC_IDLE / RRC_INACTIVE UEs, one CORESET may be configured within the common frequency resources used for group-common PDCCH / PDSCH. In one embodiment, if the common frequency resources used for group-common PDCCH / PDSCH is the initial BWP and no other CORESET is configured for the UE, CORESET 0 may be used by default.

[0134] In some embodiments, a UE (eg, in RRC_IDLE or RRC_INACTIVE state) may receive MBS-related control information in CORESET 0 (eg, information transmitted on a group-common PDCCH or DCI) on an initial DLBWP.

[0135] In some embodiments, the UE may receive MBS-related control information (eg, information transmitted on a group-common PDCCH or DCI) in a CORESET configured for an MBS or an MBS BWP.

[0136] In some implementations, the UE may receive MBS-related control information in a CORESET configured for an MBS or an MBS BWP through MBS-related RNTI addressing.

[0137] In some implementations, the UE may receive MBS-related control information in a CORESET configured for the MBS on an initial DL BWP.

[0138] In some implementations, the UE may receive MBS-related control information in CORESET 0 on the initial DL BWP through C-RNTI addressing.

[0139] In some embodiments, the UE may receive MBS-related control information in CORESET 0 on the initial DL BWP via MBS control RNTI or MBS-related RNTI addressing.

[0140] In some embodiments, a new type of PDCCH common search space may be defined / configured. The UE may obtain MBS-related control information from the new type of PDCCH common search space, where the MBS-related control information may indicate at least one of a BWP on which MBS data is transmitted, a (starting) position of MBS data transmission, and a period of MBS data transmission.

[0141] In some embodiments, the UE may obtain MBS-related control information through a new search space / CORSET, through an existing NR search space / CORSET (e.g., Type0-PDCCH common search space / CORSET 0, or Type0A-PDCCH common search space / CORSET 0).

[0142] In some implementations, an RRC_INACTIVE / RRC_IDLE / RRC_CONNECTED UE may monitor MBS-related PDCCH / CORESET regardless of whether the UE is in the on-duration of a DRX cycle (or an opportunity for DRX). An RRC_C0NNECTED UE refers to a UE operating in the RRC_C0NNECTED state.

[0143] In some implementations, an RRC_INACTIVE / RRC_IDLE / RRC_CONNECTED UE may monitor the PDCCH / CORESET related to the MBS during the DRX-OFF period.

[0144] In some embodiments, the network may use separate / different CORESETs / search spaces (e.g., non-overlapping CORESETs / search spaces in the frequency domain) to transmit corresponding control information for different MBSs. For example, MBS #1 may be configured with CORESET #A and / or search space #A. MBS #2 may be configured with CORESET #B and / or search space #B.

[0145] In some embodiments, the UE may receive MBS-related control information in CORESET #1 (which may be provided by system information or dedicated signaling) on ​​an initial DL BWP. In some embodiments, the UE may receive MBS-related control information in CORESET #1 on an initial DL BWP addressed by a C-RNTI. In some embodiments, the UE may receive MBS-related control information in CORESET #1 on an initial DL BWP addressed by an MBS-Control-RNTI. In some embodiments, the UE may receive MBS-related control information in CORESET #1 on DL BWP #1 based on a configuration from the network. In some embodiments, if the UE is operating on DL BWP #1 (which may not be the initial DL BWP) and the CORESET associated with the MBS-related control information is not provided or does not exist, the UE may receive MBS-related control information in CORESET 0 on DL BWP #1. The MBS-Control-RNTI may be predefined and / or configurable.

[0146] In some embodiments, the MBS-related control information may indicate a CORESET and / or an associated search space for decoding a PDCCH addressed by an MBS-related RNTI for MBS data reception. In some embodiments, the MBS-related control information may include an RNTI associated with the MBS. In some embodiments, a common RNTI for all MBSs may be used, and data reception for different MBSs may be performed on a per-CORESET / per-search-space basis. In some embodiments, the MBS-related control information may include a QoS requirement for the MBS (e.g., a high QoS requirement or a low QoS requirement). For an MBS with a high QoS requirement, a HARQ operation may be required. For an MBS with a low QoS requirement, a HARQ operation may not be required. For example, if the received MBS-related control information indicates that the QoS requirement for the MBS is low, the UE receiving the MBS-related control information may not perform a HARQ operation for data reception for the MBS.

[0147] Support for dynamic change of MBS delivery between multicast and unicast

[0148] In some embodiments, the network may configure a threshold for MBS data reception to the UE. The threshold may be configured on a per-MBS basis. For example, the network may configure threshold #1 for MBS A and threshold #2 for MBS B. In some embodiments, the threshold for MBS data reception may be predefined or configurable.

[0149] In some embodiments, the UE may report an MBS status report to the network. The MBS status report may be reported periodically, where the reporting period may be configured by the network via dedicated signaling or broadcast system information. In some embodiments, the reporting of the MBS status report may be triggered by a specific event. For example, when the MBS status changes, the UE may transmit an MBS status report to the network (e.g., via a configured grant, dynamic grant, a 2-step RA procedure, or a 4-step RA procedure).

[0150] In some embodiments, the MBS status report may indicate the target MBS and whether the associated service reception condition is met / compliant. For example, a reference signal received power (RSRP: Reference Signal Received Power) / reference signal received quality (RSRQ: Reference Signal Received Quality) / received signal strength indicator (RSSI: Received Signal Strength Indicator) threshold may be provided for determining the service reception condition. For example, if the UE determines that the RSRP value of the DL path loss reference (e.g., MBS reference signal) is less than or equal to the RSRP threshold, the UE may report the MBS status report to the network to notify that the service reception condition of the MBS is not met / compliant. For example, if the UE determines that the RSRP value of the DL path loss reference (e.g., MBS reference signal) is greater than the RSRP threshold, the UE may report the MBS status report to the network to notify that the service reception condition of the MBS is met / compliant.

[0151] The network can determine whether to switch to PTP or PTM transmission mode based on information provided by the UE (e.g., MBS status report). Based on the received MBS status report, the network can adjust the modulation and coding scheme (MCS) used to transmit MBS data via PTM transmission mode (or multicast mode) or configure the UE to receive MBS via PTP transmission mode (or unicast mode).

[0152] Once the UE reports MBS Status Report #1 to the network, the UE may start or restart timer T1. Once timer T1 is started or restarted, the UE may be prohibited from reporting MBS Status Report #2 to the network until timer T1 expires. In one embodiment, if the second MBS Status Report #2 has different content from the previous MBS Status Report (e.g., MBS Status Report #1), the UE may be allowed to report MBS Status Report #2 to the network while timer T1 is still running.

[0153] In some embodiments, timer T1 may be started or restarted by the UE when at least one of the following conditions is met: the UE transmits an MBS status report, a BWP change is activated (e.g., from one MBS BWP to another), the value of timer T1 is reconfigured, and the threshold is reconfigured or released.

[0154] In some embodiments, the UE may request the network to transmit MBS data via the PTP transmission mode (or unicast mode). For example, when the associated service reception condition is not met / conformed (e.g., the signal strength of the service reception is less than or equal to a threshold), the UE may request the network to transmit the MBS via the PTP transmission mode (or unicast mode). The network may not respond to the UE's request for MBS data transmission via the PTP transmission mode. In some embodiments, the network may reject the UE's request by sending a rejection message to the UE via the PTP transmission mode. In this case, the network may instruct the UE to abort / stop sending the request for MBS data transmission via the PTP transmission mode. The network may redirect the UE to another cell. In some embodiments, the network may change the configuration of MBS data transmission via the PTM transmission mode to improve data reception performance. In some embodiments, the UE may request the network to stop transmitting MBS data via the PTP transmission mode (or unicast mode). For example, when the associated service reception condition is met / conformed (e.g., the signal strength is greater than or equal to a threshold), the UE may request the network to stop transmitting MBS data via the PTP transmission mode.

[0155] In some embodiments, when a UE requests the network to transmit MBS data using the PTP transmission mode (or unicast mode), the UE may start or restart timer T2. Once timer T2 is (re)started, the UE may be prohibited from requesting the network to transmit MBS data using the PTP transmission mode (or unicast mode) again until timer T2 expires. In some embodiments, if the requested MBS data has different content than the previously requested MBS data, the UE may be allowed to request the network to transmit MBS data using the PTP transmission mode (or unicast mode) while timer T2 is still running.

[0156] In some embodiments, timer T2 may be started or restarted by the UE when at least one of the following conditions is met: the UE transmits a request to the network to transmit MBS data or a request to stop transmitting MBS data; a BWP change is activated (e.g., from one BWP to another); the value of timer T2 is reconfigured; and the threshold is reconfigured or released.

[0157] UL feedback mechanism

[0158] In some embodiments, HARQ operation for MBS data reception may be supported. HARQ operation may be enabled or disabled by the network via DCI, MAC control element (CE: Control Element) and / or RRC signaling. For example, if the HARQ operation is enabled, the UE may report HARQ-ACK feedback for the corresponding MBS data reception to the network. If the HARQ operation is disabled, the UE may not report HARQ-ACK feedback for the corresponding MBS data reception to the network. In some embodiments, when the UE receives MBS data in the RRC_IDLE state or the RRC_INACITVE state, the HARQ operation may not be performed. In some embodiments, the UE may not perform HARQ operation for data reception of an MBS with low QoS requirements. In some embodiments, even if the MBS has high QoS requirements, the UE may not perform HARQ operation for data reception of the MBS.

[0159] In some embodiments, whether MBSs transmitted via PTM transmission mode (or multicast mode) support HARQ operations or other UL feedback mechanisms may be configurable. For example, for MBS#1, the network may configure (e.g., via an RRC message, MACCE, or DCI) one or more target UEs receiving MBS#1 to perform HARQ operations or other UL feedback mechanisms; while for MBS#2, the network may configure one or more target UEs receiving MBS#2 not to perform HARQ operations (or only implement a tracking combined HARQ protocol) or other UL feedback mechanisms.

[0160] In some embodiments, a reserved bit in an existing DCI may be used to indicate whether the current MBS supports HARQ operation or other UL feedback mechanisms. In some embodiments, the network may implicitly indicate whether the current MBS supports HARQ operation or other UL feedback mechanisms. For example, if the network transmits MBS-related control information to the UE via UE-specific DCI, the UE may know that the MBS corresponding to the MBS-related control information supports HARQ operation or other UL feedback mechanisms. Otherwise, the UE may determine that the current MBS does not support HARQ operation or other UL feedback mechanisms. The UE may determine whether the UE-specific DCI is used for the MBS based on several factors, such as the MBS-related RNTI that scrambles the UE-specific DCI, a field in the UE-specific DCI, and / or a separate CORESET / search space on which the UE-specific DCI is received.

[0161] In some embodiments, a UE receiving an MBS may be provided with a dedicated PUCCH resource for transmitting HARQ-ACK feedback (e.g., an acknowledgment (ACK) or a negative acknowledgment (NACK)) for corresponding MBS data reception. The dedicated PUCCH resource may be provided by the network through dedicated signaling. In some embodiments, the network may implicitly notify the UE of the dedicated PUCCH resource. For example, just after the end of the MBS transmission, the dedicated PUCCH resource may be provided in X OFDM symbols, where X is a predefined or configurable positive integer. For example, the UE may obtain the value of X through dedicated signaling or broadcast system information. In some embodiments, the network may provide different gap values ​​to different UEs, where each gap value represents the gap between the PUCCH position indicated by the DCI (and the DCI may also indicate the PDSCH resource carrying the MBS data) and the dedicated PUCCH position (each dedicated PUCCH position may be configured for a separate UE). For example, the network may provide gap values ​​to different UEs via predefined rules or UE-specific signaling. In some embodiments, dedicated PUCCH resources for the UE may be provided via dedicated signaling, and upon / after the UE receives the dedicated signaling, the dedicated PUCCH resources may be allowed to be used for HARQ feedback transmission (or HARQ operation). In this case, upon receiving the dedicated signaling, the UE may use the dedicated PUCCH resources for ACK / NACK transmission. In some embodiments, dedicated PUCCH resources for the UE may be provided via dedicated signaling, and upon / after the UE receives the dedicated signaling, the dedicated PUCCH resources may not be allowed to be used for HARQ feedback transmission (or HARQ operation). In this case, upon receiving the dedicated signaling, the UE may not use the dedicated PUCCH resources for ACK / NACK transmission. In some embodiments, the network may use DCI, MAC CE, or RRC signaling to activate (or deactivate) the configured PUCCH resources for ACK / NACK transmission for MBS. In some embodiments, the UL feedback mechanism may be performed on a UL BWP belonging to the original UL or the supplementary UL. In some embodiments, for RRC_INACTIVE / RRC_IDLE UEs, the feedback mechanism may be provided via a 2-step RA procedure or a 4-step RA procedure.

[0162] reliability

[0163] In some embodiments, a UE can simultaneously receive MBS data transmitted via a PTM transmission mode (or multicast mode) and MBS data transmitted via a PTP transmission mode (or unicast mode). For example, the UE can receive first MBS data via a PTM RLC entity and second MBS data via a PTP RLC entity, where the second MBS data is a copy / duplicate of the first MBS data. The PTM RLC entity and the PTP RLC entity can be associated with a common PDCP entity. In some embodiments, if the UE determines that the data reception conditions for PTP transmission (or unicast mode) are sufficiently good, the UE can automatically stop receiving MBS data transmitted via the PTM transmission mode (or multicast mode). In some embodiments, if the data reception conditions for PTP transmission (or unicast mode) (e.g., the strength / quality of the received signal is greater than or equal to a threshold) are met, the UE can stop receiving MBS data transmitted via the PTM transmission mode (or multicast mode). The threshold can be predefined or configured. For example, the threshold can be configured by the network through dedicated signaling or broadcast system information. For example, the threshold may be a signal quality based threshold, such as an RSRP threshold, an RSRQ threshold, an RSSI threshold, or a buffer size based threshold.

[0164] Figure 1 FIG. 1 is a flow chart showing a method 100 for MBS data reception according to an embodiment of the present disclosure. Although actions 102 and 104 are depicted as Figure 1 Individual actions are represented as separate boxes in the , but these individually depicted actions should not be construed as necessarily order-dependent. Figure 1 The order in which the actions are performed is not intended to be construed as a limitation, and any number of the disclosed blocks can be combined in any order to implement the method, or an alternate method.

[0165] In NR, since different MBSs may have different characteristics (e.g., data volume per packet or data delivery period) and / or QoS requirements, configuring CORESET, search space, and / or frequency resources to the UE based on the MBS may facilitate resource utilization and reduce the power consumption of the UE.

[0166] As in action 102, the UE may receive MBS-related control information from the BS. The MBS-related control information may indicate at least one of a first radio network temporary identifier (RNTI) associated with the MBS, a control resource set (CORESET) configured for the MBS, a search space configured for the MBS, and frequency resources configured for the MBS. In some other embodiments, the MBS-related control information may be the MBS-related control information described in various embodiments of the present disclosure.

[0167] In some embodiments, each of the CORESET and search space indicated by the MBS-related control information may be configured on a per-MBS basis.

[0168] In action 104, the UE may receive MBS data (which may also be referred to as "MBS data" in this disclosure) from the BS based on the MBS-related control information. For example, the UE may monitor and receive MBS data on the frequency resources indicated by the MBS-related control information. For example, the UE may receive MBS data on a PDSCH with a first CRC scrambled by a first RNTI indicated by the MBS-related control information, where the PDSCH may be indicated by a PDCCH with a second CRC scrambled by a second RNTI having an RNTI value different from the first RNTI. For example, the first RNTI may be a group RNTI, and the second RNTI may be a UE-specific RNTI.

[0169] As previously mentioned, different MBSs may have different characteristics (e.g., the amount of data per packet or the data transmission period) and / or QoS requirements. For example, an MBS with high QoS requirements may require high communication reliability, while an MBS with low QoS requirements may only require normal or low communication reliability. In order to meet various QoS / reliability requirements, a method may be required that can flexibly / dynamically enable or disable the HARQ operation of the MBS on the UE side, such as Figure 2 shown.

[0170] Figure 2 1 is a flow chart of a method 200 for MBS data reception according to an embodiment of the present disclosure. The method 200 may be performed independently or in combination with Figure 1 The method 100 shown is performed.

[0171] In action 202, the UE may receive an indicator indicating whether HARQ-ACK feedback transmission (or HARQ operation) for data of the MBS is enabled from the BS.

[0172] In action 204, the UE may determine whether HARQ-ACK feedback transmission for MBS data is enabled.

[0173] In action 206, if the result of the determination in action 204 is "yes", the UE may enable HARQ-ACK feedback transmission for the MBS data. For example, the UE may generate and transmit HARQ-ACK feedback (e.g., ACK / NACK) to indicate whether the reception of the MBS data is successful.

[0174] In action 208, if the result of the determination in action 204 is "No", the UE may disable HARQ-ACK feedback transmission for the MBS data. In this case, the UE may not generate or transmit HARQ-ACK feedback indicating whether the reception of the MBS data is successful.

[0175] In some embodiments, as Figure 3 As shown, duplication of MBS data / data packets may also be used to improve the reliability of MBS data transmission (due to frequency diversity and / or time diversity gains).

[0176] Figure 3 1 is a flow chart of a method 300 for MBS data reception according to an embodiment of the present disclosure. The method 300 may be performed independently or in combination with Figure 1 The method 100 and Figure 2 Execute any of the methods 200 described in .

[0177] In action 302 , the UE may receive MBS data through a first RLC entity of the UE.

[0178] In action 304, the UE may receive a copy of the data of the MBS through a second RLC entity of the UE, wherein the first RLC entity and the second RLC entity are associated with a common PDCP entity of the UE.

[0179] In some embodiments, as Figure 4 As shown in , data of the MBS may be transmitted by the BS in the PTM transmission mode (or multicast mode), and a copy of the data of the MBS may be transmitted by the BS in the PTP transmission mode (or unicast mode).

[0180] Figure 44 is a schematic diagram illustrating a common PDCP entity 402 associated with a first RLC entity 404 for receiving MBS data and a second RLC entity 406 for receiving a copy / duplicate of the MBS data. In an embodiment, the MBS data may be transmitted / delivered by the BS using a PTM transmission mode (or a multicast mode), and the copy / duplicate of the MBS data may be transmitted / delivered by the BS using a PTP transmission mode (or a unicast mode).

[0181] In legacy systems such as LTE, an RRC_IDLE UE or RRC_INACTIVE UE can receive DL data / signaling only on the initial DL BWP. However, the bandwidth of the initial DL BWP is limited and insufficient to support MBS data transmission. Therefore, allowing an RRC_IDLE UE or RRC_INACTIVE UE to receive MBS data on frequency resources that do not belong to the initial DL BWP can enhance resource utilization and improve system performance. In some embodiments, when a UE is operating in one of the RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED states, the UE can receive MBS data on frequency resources (indicated by MBS-related control information), where the frequency resources may not overlap with the initial BWP configured for the UE in the frequency domain.

[0182] Figure 5 An example of resource allocation of the initial BWP 502 configured for the UE and the frequency resource 504 indicated by the MBS-related control information is shown. The relative frequency positions of the initial BWP 502 and the frequency resource 504 are not limited to Figure 5 For example, the initial BWP 502 may be located in a higher or lower frequency band than the frequency resource 504 .

[0183] like Figure 5 As shown, the frequency resources 504 do not overlap in the frequency domain with the initial BWP 504. In some implementations, the frequency resources 504 may refer to a BWP, a portion of a BWP, or a set of resources collected from one or more BWPs.

[0184] Figure 6 FIG. 6 is a block diagram illustrating a node 600 for wireless communication according to an embodiment of the present disclosure. Figure 6 As shown, the node 600 may include a transceiver 606, a processor 608, a memory 602, one or more presentation components 604, and at least one antenna 610. The node 600 may also include an RF spectrum band module, a base station communication module, a network communication module, a system communication management module, an input / output (I / O) port, an I / O component, or a power supply (in the Figure 6Each of these components may communicate with each other directly or indirectly via one or more buses 624. In one embodiment, the node 600 may be a processor that executes Figures 1 to 5 A UE or BS with various disclosed functions is shown.

[0185] The transceiver 606, which may have a transmitter 616 (e.g., transmitting / transmission circuitry) and a receiver 618 (e.g., receiving / reception circuitry), may be configured to transmit and / or receive time and / or frequency resource partitioning information. In one embodiment, the transceiver 606 may be configured to transmit in different types of subframes and time slots, including but not limited to usable, unusable, and flexibly usable subframe and time slot formats. The transceiver 606 may be configured to receive data and control channels.

[0186] Node 600 may include a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by node 600, and include both volatile (and non-volatile) media and removable (and non-removable) media. By way of example and not limitation, computer-readable media may include computer storage media and communication media. Computer storage media include both volatile (and / or non-volatile) and removable (and / or non-removable) media, which can be implemented in any method or technology for storage information such as computer-readable.

[0187] Computer storage media include RAM, ROM, EEPROM, flash memory (or other storage technology), CD-ROM, Digital Versatile Disk (DVD) (or other optical disk storage devices), cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. Computer storage media do not include propagating data signals. Communication media may typically contain 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 transmission media. The term "modulated data signal" may refer to a signal that has one or more characteristics set or changed in such a way as to encode information in the signal. By way of example, and not limitation, communication media include wired media (such as a wired network or direct-wired connection) and wireless media (such as acoustic, RF, infrared and other wireless media). Combinations of any of the above media should also be included within the scope of computer-readable media.

[0188] The memory 602 may include computer storage media in the form of volatile and / or non-volatile memory. The memory 602 may be removable, non-removable, or a combination thereof. For example, the memory 602 may include solid-state memory, a hard drive, an optical drive, etc. Figure 6 As shown, the memory 602 may store computer-readable, computer-executable instructions 614 (e.g., software code) that, when executed, are configured to cause the processor 608 (e.g., processing circuitry) to perform various functions described in the present disclosure, such as referring to Figures 1 to 5 Alternatively, the instructions 614 may not be directly executable by the processor 608, but may be configured to cause the node 600 (eg, when compiled and executed) to perform the various functions described herein.

[0189] The processor 608 (e.g., having processing circuitry) may include an intelligent hardware device, such as a central processing unit (CPU), a microcontroller, an ASIC, or the like. The processor 608 may include memory. The processor 608 may process data 612 and instructions 614 received from the memory 602, as well as information transmitted through the transceiver 606, the baseband communication module, and / or the network communication module. The processor 608 may also process information to be sent to the transceiver 606 for transmission via the antenna 610, and information to be sent to the network communication module for transmission to the network.

[0190] One or more presentation components 604 can present data indications to a person or other device. Examples of presentation components 604 can include a display device, a speaker, a printing component, a vibration component, and the like.

[0191] As can be seen from this disclosure, various technologies can be used to realize these concepts without departing from the scope of the concepts described in this application. In addition, although the concepts have been described with specific reference to certain embodiments, those skilled in the art will recognize that changes can be made in form and detail without departing from the scope of these concepts. Therefore, the described embodiments should be considered to be illustrative and not restrictive in all aspects. It should also be understood that the application is not limited to the specific embodiments described above, but many rearrangements, modifications and replacements are possible without departing from the scope of this disclosure.

Claims

1. A method for receiving multicast service data, performed by a user equipment (UE), the method comprising: determining whether a first physical downlink control channel (PDCCH) addressed by a first radio network temporary identifier (RNTI) is received on a first bandwidth part (BWP), the first PDCCH indicating downlink allocation of data for a multicast service; In a case where a BWP deactivation timer and a default BWP are configured, and the first BWP is not the default BWP, After determining that the first PDCCH is received on the first BWP, starting or restarting the BWP deactivation timer, and When the BWP deactivation timer expires, switching from the first BWP to the default BWP; and In the case where the BWP deactivation timer is configured but the default BWP is not configured, and the first BWP is not the initial BWP, After determining that the first PDCCH is received on the first BWP, starting or restarting the BWP deactivation timer, and When the BWP deactivation timer expires, switching from the first BWP to the initial BWP, The method further comprises: receiving the data of the multicast service through a first radio link control (RLC) entity of the UE; receiving a copy of the data of the multicast service via a second RLC entity of the UE, wherein the first RLC entity and the second RLC entity are associated with a common Packet Data Convergence Protocol (PDCP) entity of the UE, and The data of the multicast service are received from a base station BS in a point-to-multipoint PTM transmission mode, while the copy of the data of the multicast service is received from the BS in a point-to-point PTP transmission mode.

2. The method according to claim 1, further comprising: receiving control information from the BS; as well as receiving the data of the multicast service according to the control information, The control information indicates at least one of the following: A control resource set CORESET configured for the multicast service; a search space configured for the multicast service; and Frequency resources configured for the multicast service.

3. The method according to claim 1, further comprising: An indicator is received from the BS, the indicator indicating whether hybrid automatic repeat request acknowledgement (HARQ-ACK) feedback transmission for the data of the multicast service is enabled.

4. The method according to claim 1, further comprising: An indication that the UE supports receiving the data of the multicast service is transmitted to the BS.

5. The method according to claim 1, further comprising: determining whether there is an ongoing random access procedure associated with the serving cell; as well as After determining that there is no ongoing random access procedure associated with the serving cell, the BWP deactivation timer is started or restarted.

6. The method according to claim 1, further comprising: upon receiving a second PDCCH addressed by the second RNTI, determining whether an ongoing random access procedure associated with the serving cell is successfully completed; as well as After determining that the random access procedure has been successfully completed, starting or restarting the BWP deactivation timer.

7. The method according to claim 6, characterized in that The second RNTI is a cell RNTI C-RNTI.

8. A user equipment (UE) for receiving multicast / broadcast service data, the UE comprising: at least one processor; as well as At least one memory coupled to the at least one processor, wherein the at least one memory stores at least one computer executable program, which, when executed by the at least one processor, causes the at least one processor to perform the method of any one of claims 1 to 7.

Images