Method and apparatus for managing DRX active time for multicast reception in RRC inactive state in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Specifically, the present disclosure provides a method and apparatus for managing discontinuous reception (DRX) active time such that multicast and broadcast service (MBS) reception is efficiently performed in a radio resource control (RRC) inactive state.

Description

Technical Field

[0001] This disclosure relates to wireless communication systems (or mobile communication systems). More specifically, this disclosure relates to a method and apparatus in a wireless communication system (or mobile communication system) for managing discontinuous reception (DRX) activity time for multicast reception by a UE in a radio resource control (RRC) inactive state. Background Technology

[0002] 5G mobile communication technology defines a wide frequency band, enabling high transmission rates and new services. It can be implemented not only in "sub-6GHz" bands such as 3.5GHz, but also in "above 6GHz" bands, including 28GHz and 39GHz, known as mmWave. Furthermore, 6G mobile communication technology (referred to as "super 5G systems") is being considered in terahertz (THz) bands (e.g., the 95GHz to 3THz band) to achieve transmission rates fifty times faster than 5G and ultra-low latency one-tenth that of 5G.

[0003] At the outset of 5G mobile communication technology development, standardization was underway for the following technologies to support services and meet performance requirements associated with enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and massive machine-type communication (mMTC): beamforming and massive MIMO for mitigating radio wave path loss and increasing radio wave transmission distance in millimeter waves; dynamic operation supporting parameter sets (e.g., operating multiple subcarrier spacings) and time slot formats for efficient utilization of millimeter wave resources; initial access technologies supporting multi-beam transmission and broadband; definition and operation of BWP (bandwidth portion); new channel coding methods (such as LDPC (low-density parity-check) codes for large data transmissions and polar codes for highly reliable transmission of control information); L2 preprocessing; and network slicing for providing dedicated networks for specific services.

[0004] Currently, given the services that 5G mobile communication technology needs to support, discussions are underway regarding improvements and performance enhancements to the initial 5G mobile communication technology, and physical layer standardization already exists for technologies such as: V2X (Vehicle-to-Everything) for assisting autonomous vehicles in determining driving based on information about the location and status of vehicles transmitted by vehicles and for enhancing user convenience; NR-U (New Radio Unlicensed) designed to make system operation in unlicensed bands comply with various regulatory requirements; NR UE power saving; non-terrestrial networks (NTNs) for UE-satellite direct communication to provide coverage in areas where communication with terrestrial networks is unavailable; and positioning.

[0005] Furthermore, standardization is underway in the wireless interface architecture / protocol domain for technologies such as: Industrial Internet of Things (IIoT) to support new services through interoperability and convergence with other industries; IAB (Integrated Access and Backhaul) for nodes to provide network service area extension by supporting wireless backhaul and access links in an integrated manner; mobility enhancements including conditional handover and DAPS (Dual Active Stack) handover; and two-step random access (2-step RACH for NR) to simplify the random access process. In terms of system architecture / services, standardization is also underway for: 5G baseline architectures (e.g., service-based architectures or service-based interfaces) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies; and mobile edge computing (MEC) for UE location-based reception services.

[0006] With the commercialization of 5G mobile communication systems, the number of connected devices, which has already increased exponentially, will be connected to the communication network. Therefore, enhanced functionality and performance of 5G mobile communication systems, as well as the integrated operation of connected devices, are expected to be necessary. To this end, new research is planned related to: Extended Reality (XR) for effectively supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality), etc.; improving 5G performance and reducing 5G complexity by leveraging Artificial Intelligence (AI) and Machine Learning (ML); AI service support; Metaverse service support; and drone communication.

[0007] Furthermore, this development of 5G mobile communication systems will serve as a foundation for: not only developing new waveforms for providing terahertz band coverage for 6G mobile communication technologies, multi-antenna transmission technologies (such as full-dimensional MIMO (FD-MIMO), array antennas, and massive MIMO), metamaterial-based lenses and antennas for improving terahertz band signal coverage, high-dimensional spatial multiplexing technologies using OAM (orbital angular momentum), and RIS (reconfigurable smart surfaces), but also developing full-duplex technologies to improve the frequency efficiency of 6G mobile communication technologies and enhance system networks, AI-based communication technologies to achieve system optimization by leveraging satellites and AI (artificial intelligence) from the design phase and internalizing end-to-end AI support capabilities, and next-generation distributed computing technologies to achieve services at a complexity level exceeding the operational capabilities of UEs by utilizing ultra-high-performance communication and computing resources.

[0008] With the development of communication systems, the demand for various methods to effectively perform multicast sending and receiving is constantly increasing. Summary of the Invention

[0009] Solution to the problem

[0010] This disclosure provides a method and apparatus for managing discontinuous reception (DRX) activity time, enabling a UE in an RRC inactive state in a wireless communication system (or mobile communication system) to effectively perform multicast reception.

[0011] According to embodiments of this disclosure, a method performed by a terminal is provided. The method includes: receiving from a base station a Radio Resource Control (RRC) release message including a suspension configuration, wherein the suspension configuration includes a multicast and Broadcast Service (MBS) multicast configuration for an RRC inactive state; receiving from the base station, while the terminal is in an RRC inactive state, a multicast transmission based on the MBS multicast configuration for a Group Radio Network Temporary Identifier (G-RNTI); and, if a Hybrid Automatic Repeat Request Round-Trip Timer (drx-HARQ-RTT-TimerDL-PTM) for downlink point-to-multipoint discontinuous reception is included in the MBS multicast configuration for the RRC inactive state, initiating drx-HARQ-RTT-TimerDL-PTM after the multicast transmission has ended.

[0012] According to embodiments of this disclosure, a method performed by a base station is provided. The method includes: sending a Radio Resource Control (RRC) release message including a suspend configuration to a terminal, wherein the suspend configuration includes a multicast and Broadcast Service (MBS) multicast configuration for an RRC inactive state; and sending a multicast transmission based on the MBS multicast configuration for a Group Radio Network Temporary Identifier (G-RNTI) to the terminal in the RRC inactive state, wherein a downlink point-to-multipoint discontinuous reception Hybrid Automatic Repeat Request Round-Trip Timer (drx-HARQ-RTT-TimerDL-PTM) included in the MBS multicast configuration is started after the multicast transmission ends.

[0013] According to embodiments of this disclosure, a terminal is provided. The terminal includes: a transceiver; and a controller coupled to the transceiver and configured to: receive from a base station a Radio Resource Control (RRC) release message including a suspension configuration, wherein the suspension configuration includes a multicast and Broadcast Service (MBS) multicast configuration for an RRC inactive state; receive from the base station multicast transmission based on the MBS multicast configuration for a Group Radio Network Temporary Identifier (G-RNTI) when the terminal is in an RRC inactive state; and, if a Hybrid Automatic Repeat Request Round-Trip Timer (drx-HARQ-RTT-TimerDL-PTM) for discontinuous reception in the downlink point-to-multipoint manner is included in the MBS multicast configuration for the RRC inactive state, initiate drx-HARQ-RTT-TimerDL-PTM after the multicast transmission ends.

[0014] According to embodiments of this disclosure, a base station is provided. The base station includes: a transceiver; and a controller coupled to the transceiver and configured to: send a Radio Resource Control (RRC) release message to a terminal including a suspend configuration, wherein the suspend configuration includes a multicast and Broadcast Service (MBS) multicast configuration for an RRC inactive state, and to send a multicast transmission based on an MBS multicast configuration for a Group Radio Network Temporary Identifier (G-RNTI) to a terminal in an RRC inactive state, wherein a downlink point-to-multipoint discontinuous reception Hybrid Automatic Repeat Request Round-Trip Timer (drx-HARQ-RTT-TimerDL-PTM) included in the MBS multicast configuration is started after the multicast transmission ends.

[0015] The advantage of the various embodiments proposed in this disclosure is that the UE and gNB manage the DRX activity time, so that multicast reception of UEs in the RRC inactive state is effectively performed.

[0016] Before proceeding with the following detailed description, it may be advantageous to define certain words and phrases used throughout this patent document: the terms “comprising” and “including” and their derivatives mean including but not limited to; the term “or” is inclusive, referring to and / or; the phrases “associated with” and “associated with” and their derivatives may mean including, being included in, interconnected with, containing, being contained within, connected to or connected with, coupled to or coupled with, able to communicate with, cooperate with, interleaved, juxtaposed, proximate, bound to or bound with, having, having the properties of, etc.; and the term “controller” means any device, system, or part thereof that controls at least one operation, such a device may be implemented in hardware, firmware, or software, or some combination of at least two of these. It should be noted that the functionality associated with any particular controller can be centralized or distributed, whether local or remote.

[0017] Furthermore, the various functions described below can be implemented or supported by one or more computer programs, each computer program being formed by computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, associated data, or portions thereof suitable for implementation in appropriate computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium accessible by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, optical disc (CD), digital video disc (DVD), or any other type of storage. "Non-transitory" computer-readable media does not include wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable media includes media in which data can be permanently stored and media in which data can be stored and later rewritten, such as rewritable optical discs or erasable memory devices.

[0018] Definitions of certain words and phrases are provided throughout this patent document, and those skilled in the art will understand that, in many cases (if not most), such definitions apply to the prior and future use of the words and phrases defined in this way. Attached Figure Description

[0019] The above and other aspects, features and advantages of certain embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings, in which:

[0020] Figure 1 An operational scheme for multicast and broadcast service (MBS) communication according to embodiments of the present disclosure is illustrated;

[0021] Figure 2 Multicast DRX operation of a UE in RRC_connected mode according to an embodiment of this disclosure is illustrated;

[0022] Figure 3 Multicast DRX operation of a UE in RRC inactive mode according to another embodiment of this disclosure is illustrated;

[0023] Figure 4 Multicast DRX operation of a UE in RRC inactive mode according to another embodiment of this disclosure is illustrated;

[0024] Figure 5 Multicast DRX operation of a UE in RRC inactive mode according to another embodiment of this disclosure is illustrated;

[0025] Figure 6Multicast DRX operation of a UE in RRC inactive mode according to another embodiment of this disclosure is illustrated;

[0026] Figure 7 Multicast DRX operation of a UE in RRC inactive mode according to another embodiment of this disclosure is illustrated;

[0027] Figure 8 Multicast DRX operation of a UE in RRC inactive mode according to another embodiment of this disclosure is illustrated; and

[0028] Figure 9 Multicast DRX operation of a UE in RRC inactive mode is illustrated according to another embodiment of this disclosure.

[0029] Figure 10 The structure of a base station according to an embodiment of the present disclosure is shown; and

[0030] Figure 11 The structure of a UE according to an embodiment of the present disclosure is shown. Detailed Implementation

[0031] The following discussion Figures 1 to 11 The various embodiments used to describe the principles of this disclosure in this patent document are for illustrative purposes only and should not be construed as limiting the scope of this disclosure in any way. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged system or device.

[0032] In the following, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

[0033] In describing this disclosure below, detailed descriptions of known functions or configurations incorporated herein will be omitted where it is determined that the description may unnecessarily obscure the subject matter of this disclosure. Embodiments of this disclosure will be described below with reference to the accompanying drawings.

[0034] For the same reason, some elements may be exaggerated, omitted, or shown schematically in the accompanying drawings. Furthermore, the dimensions of each element do not perfectly reflect the actual dimensions. In the various drawings, the same or corresponding elements have the same reference numerals.

[0035] The advantages and features of this disclosure, as well as methods of implementing them, will become apparent from the embodiments described in detail below with reference to the accompanying drawings. However, this disclosure is not limited to the embodiments set forth below, but can be implemented in various different forms. The following embodiments are provided only to fully disclose this disclosure and to inform those skilled in the art of its scope, and this disclosure is limited only by the scope of the appended claims. Throughout the specification, the same or similar reference numerals denote the same or similar elements. Furthermore, in describing this disclosure, detailed descriptions of known functions or configurations incorporated herein are omitted where it is determined that the description may unnecessarily obscure the subject matter of the disclosure. The terminology described below is defined in consideration of the functions in this disclosure and may vary depending on the user, the user's intention, or custom. Therefore, the definition of the terminology should be based on the entire contents of the specification.

[0036] The following detailed description of embodiments of this disclosure is primarily directed to the New RAN (NR) as a radio access network and the Packet Core (5G system or 5G core network or next-generation core (NG core)) as a core network in the 5G mobile communication standard specified by the 3GPP (3rd Generation Partnership Project) mobile communication standardization organization. However, based on the determination of those skilled in the art, the main ideas of this disclosure can be applied to other communication systems with similar backgrounds with some modifications without significantly departing from the scope of this disclosure.

[0037] In the following description, for ease of description, some terms and names defined in 3GPP standards (standards for 5G, NR, LTE or similar systems) may be used. However, this disclosure is not limited to these terms and names and can be applied in the same manner to systems conforming to other standards.

[0038] In the following description, for ease of description, terms for identifying access nodes, referring to network entities, referring to messages, referring to interfaces between network entities, referring to various types of identification information, etc., are used illustratively. Therefore, this disclosure is not limited to the terminology used herein, and other terms that refer to subjects with equivalent technical meanings may be used.

[0039] In the following description, a base station is an entity that allocates resources to a terminal and can be at least one of a gNode B, eNode B, Node B, base station (BS), radio access unit, base station controller, and a node on a network. A terminal may include a user equipment (UE), a mobile station (MS), a cellular phone, a smartphone, a computer, or a multimedia system capable of performing communication functions. In this disclosure, "downlink (DL)" refers to a radio link through which a base station transmits signals to a terminal, and "uplink (UL)" refers to a radio link through which a terminal transmits signals to a base station.

[0040] In this document, it should be understood that each block of the flowchart illustration, and combinations of blocks in the flowchart illustration, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart blocks. These computer program instructions can also be stored in a computer-usable or computer-readable storage medium that can instruct the computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-usable or computer-readable storage medium produce an article of writing including instruction means for implementing the functions specified in one or more flowchart blocks. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus, thereby producing a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in the flowchart blocks.

[0041] Furthermore, each box in the flowchart can represent a module, segment, or section of code, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions mentioned in the boxes may occur out of order. For example, depending on the functions involved, two boxes shown consecutively may actually execute substantially simultaneously, or these boxes may sometimes execute in reverse order.

[0042] As used in the embodiments of this disclosure, "unit" refers to a software or hardware element that performs a predetermined function, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC). However, "unit" is not always limited to software or hardware. A "unit" may be configured to be stored in addressable storage media or to run one or more processors. Thus, a "unit" includes, for example, software elements, object-oriented software elements, class elements or task elements, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and parameters. The elements and functions provided by a "unit" may be combined into a smaller number of elements or "units," or divided into a larger number of elements or "units." Furthermore, elements and "units" may be implemented as one or more CPUs within a playback device or secure multimedia card. Additionally, a "unit" in the embodiments may include one or more processors.

[0043] In the following description, for ease of description, terms for identifying access nodes, referring to network entities, referring to messages, referring to interfaces between network entities, referring to various types of identification information, etc., are used illustratively. Therefore, this disclosure is not limited to the terms described below, and other terms that refer to subjects with equivalent technical meanings may also be used.

[0044] In the following description, the terms "physical channel" and "signal" may be used interchangeably with the terms "data" or "control signal." For example, the term "physical downlink shared channel (PDSCH)" refers to the physical channel on which data is transmitted, but PDSCH can also be used to refer to "data." That is, in this disclosure, the expression "transmitting physical channel" can be interpreted as having the same meaning as the expression "transmitting data or signals through a physical channel."

[0045] In the following description of this disclosure, upper-layer signaling refers to a signal transmission scheme from a base station to a terminal via a downlink data channel of the physical layer, or a signal transmission scheme from a terminal to a base station via an uplink data channel of the physical layer. Upper-layer signaling can also be understood as Radio Resource Control (RRC) signaling or Media Access Control (MAC) control elements (CE).

[0046] In the following description of this disclosure, for ease of description, the terms and names defined in the 3GPP New Radio (3GPP NR) or 3GPP Long Term Evolution (3GPP LTE) standards will be used. However, this disclosure is not limited to these terms and names and can be applied in the same manner to systems conforming to other standards. In this disclosure, for ease of description, the term "gNB" may be used interchangeably with the term "eNB." That is, a base station described as "eNB" may refer to a "gNB." Furthermore, the term "terminal" may refer not only to mobile phones, MTC devices, NB-IoT devices, and sensors, but also to other wireless communication devices.

[0047] In the following description, a base station (BS) is an entity that allocates resources to terminals and can be at least one of a gNode B (gNB), an eNode B (eNB), a Node B, a radio access unit, a base station controller, and a node on a network. Terminals can include user equipment (UE), mobile stations (MS), cellular phones, smartphones, computers, or multimedia systems capable of performing communication functions. Of course, examples of base stations and terminals are not limited to those mentioned above.

[0048] Specifically, this disclosure can be applied to 3GPP NR (5th generation mobile communication standard). Additionally, this disclosure can be applied to smart services based on 5G communication technology and IoT-related technologies (e.g., smart homes, smart buildings, smart cities, smart cars or connected cars, healthcare, digital education, retail businesses, security and safety-related services, etc.). In this disclosure, for ease of description, the term "eNB" can be used interchangeably with the term "gNB." That is, a base station described as "eNB" can refer to a "gNB." Furthermore, the term "terminal" can refer not only to mobile phones, NB-IoT devices, and sensors, but also to any other wireless communication device.

[0049] Wireless communication systems are evolving towards broadband wireless communication systems, using communication standards such as 3GPP High-Speed ​​Packet Access (HSPA), LTE (Long Term Evolution or Evolved Universal Terrestrial Radio Access (E-UTRA)), LTE-A Advanced, LTE-Pro, 3GPP2 High-Rate Packet Data (HRPD), Ultra Mobile Broadband (UMB), IEEE 802.16e, and typical voice-based services to provide high-speed and high-quality packet data services.

[0050] As a typical example of a broadband wireless communication system, the LTE system employs an Orthogonal Frequency Division Multiplexing (OFDM) scheme in the downlink (DL) and a Single-Carrier Frequency Division Multiple Access (SC-FDMA) scheme in the uplink (UL). The uplink refers to the radio link through which the UE transmits data or control signals to the base station or eNode B, and the downlink refers to the radio link through which the base station transmits data or control signals to the UE. These multiple access schemes separate the data or control information of each user by allocating and manipulating time-frequency resources for transmitting data or control information to each user, thus avoiding overlap and establishing orthogonality.

[0051] As a post-LTE communication system, 5G communication systems must freely reflect the various requirements of users, service providers, and others, and therefore must support services that meet diverse needs. Services considered in 5G communication systems include enhanced mobile broadband (eMBB) communication, massive machine-type communication (mMTC), and ultra-reliable low-latency communication (URLLC), among others.

[0052] According to some implementation schemes, eMBB may be designed to provide data rates higher than those supported by existing LTE, LTE-A, or LTE-Pro. For example, in 5G communication systems, eMBB must provide a peak data rate of 20 Gbps in the downlink and 10 Gbps in the uplink for a single base station. Furthermore, 5G communication systems must provide increased user-aware data rates to the UE, as well as a maximum data rate. To meet these requirements, improvements to transmit / receive technologies, including further enhanced multiple-input multiple-output (MIMO) transmission techniques, may be necessary. Alternatively, frequency bandwidths greater than 20 MHz can be used in the 3 to 6 GHz band or 6 GHz or higher to achieve the data rates required by 5G communication systems, instead of using up to 20 MHz of transmission bandwidth in the 2 GHz band used in LTE.

[0053] Furthermore, mMTC support for application services such as the Internet of Things (IoT) within 5G communication systems is being considered. To effectively deliver IoT, mMTC may have requirements such as supporting a large number of UEs within a cell, enhancing UE coverage, improving battery life, and reducing UE costs. Since IoT provides communication capabilities while being provided to various sensors and devices, it must support a large number of UEs within a cell (e.g., 1,000,000 UEs / km²). Additionally, UEs supporting mMTC may require wider coverage than other services provided by 5G communication systems because UEs may be located in shaded areas, such as building basements, which are not covered by the cell due to the nature of the service. UEs supporting mMTC must be configured to be inexpensive and may require very long battery lives, such as 10 to 15 years, due to the difficulty of frequently replacing UE batteries.

[0054] Finally, URLLC, as a cellular-based mission-critical wireless communication service, can be used for remote control of robots or machines, industrial automation, unmanned aerial vehicles, remote healthcare, emergency alarms, and more. Therefore, URLLC must provide communication with ultra-low latency and ultra-high reliability. For example, services supporting URLLC must meet an air interface latency of less than 0.5 ms, and may also require 10... -5 Or even lower packet error rates. Therefore, for services supporting URLLC, 5G systems must provide shorter transmission time intervals (TTIs) than other services, and may also require designs that allocate significant resources in the frequency band to ensure the reliability of the communication link.

[0055] The three services considered in 5G communication systems—eMBB, URLLC, and mMTC—can be multiplexed and transmitted within a single system. In this case, different transmit / receive technologies and parameters can be used between services to meet their varying requirements. However, mMTC, URLLC, and eMBB, as described above, are merely examples of different types of services, and the types of services to which this disclosure applies are not limited to those mentioned above.

[0056] In the following description of embodiments of this disclosure, LTE, LTE-A, LTE Pro, or 5G (or NR, next-generation mobile communication) systems will be described by way of example. However, embodiments of this disclosure can be applied to other communication systems with similar backgrounds or channel types. Furthermore, based on the determination of those skilled in the art, embodiments of this disclosure can be applied to other communication systems with some modifications without significantly departing from the scope of this disclosure.

[0057] Figure 1 An operational scheme for multicast and broadcast service (MBS) communication according to embodiments of the present disclosure is illustrated.

[0058] MBS communication refers to a communication scheme in a mobile communication system in which one transmitting device communicates with multiple receiving devices. Due to this scheme, MBS communication is also known as point-to-multipoint (PTM) communication. In MBS communication, the transmitting device can be a gNB, and each receiving device can be a UE. However, this disclosure is not limited to this, and the transmitting device can also be a UE.

[0059] Figure 1 The embodiment illustrates an example of performing MBS communication assuming gNB 110 is the transmitting device and UEs 120, 130, 140, 150, and 160 are the receiving devices. This MBS communication can be broadcast to multiple unspecified receiving devices, or it can be multicast to multiple specified receiving devices. If communication is performed in a multicast type, the gNB can configure only specific UEs to receive corresponding multicast packets. For this purpose, a group of UEs that should perform specific multicast communication can be configured, and such a group of UEs... Figure 1 In this embodiment, it is referred to as multicast group 170. Meanwhile, the one-to-one communication scheme between the gNB and the UE is referred to as unicast.

[0060] UEs in a multicast group can have the same Group-Radio Network Temporary Identifier (G-RNTI) (a separate resource identifier) ​​assigned to them, and can receive multicast data by decoding the control channel addressed by the G-RNTI. The G-RNTI is an RNTI shared by UEs in the multicast group, and a UE with its assigned G-RNTI can receive radio resources for MBS services from the gNB. Assuming in Figure 1 In this embodiment, UE 1 120, UE 2 130, UE 3 140, and UE 4 150 are configured as a multicast group 170, have a G-RNTI assigned to them, and therefore receive data from gNB 110 in multicast type. UE 5 160 is not included in multicast group 170 and therefore does not have a G-RNTI assigned to it. Therefore, UE 5 160 cannot receive data received from gNB by UE 1 120, UE 2 130, UE 3 140, and UE 4 150.

[0061] One or more multicast groups 170 can be configured within the coverage area of ​​gNB 110, and each multicast group 170 can be distinguished by each G-RNTI. A UE can have one or more G-RNTIs assigned to it by gNB 110. Not only in connected mode (RRC_connected mode), but also in RRC inactive mode, the UE can receive multicast data by using the G-RNTI value assigned to it in connected mode. In the UE's connected mode, G-RNTIs can be included and configured in at least one of RRC reconfiguration messages, RRC establishment messages, RRC reconstruction messages, and RRC release messages. However, this disclosure is not limited thereto, and G-RNTIs can be included as values ​​that the UE can receive from the System Information Block (SIB) or a separate Multicast Control Channel (MCCH) and then send to the UE from the gNB. A UE with G-RNTI values ​​configured in this way can subsequently apply the G-RNTI values.

[0062] If the gNB wants to perform multicast in connected mode, or if the gNB wants to transmit configuration information for multicast communication, including G-RNTI, to a UE in connected mode, the gNB may need to switch the UE in the multicast group to connected mode. As another example, if a UE currently receiving multicast services in inactive mode has difficulty receiving multicast services in inactive mode due to reduced signal strength, the UE may need to switch to connected mode. Figure 1In the illustrated embodiment, UE 1 120 and UE 2 130 are in connected mode among the UEs in multicast group 170, while UE 3 140 and UE 4 150 are in inactive mode. Thus, the gNB can instruct the UEs on multicast configuration, and UEs in connected or inactive mode can receive multicast services.

[0063] UEs in RRC_connected mode can apply a discontinuous reception (DRX) scheme to reduce power consumption, thereby monitoring the Physical Downlink Control Channel (PDCCH) only during the DRX's active period. In conjunction with DRX in RRC_connected mode, a DRX can be configured for each DRX group comprising one or more cells, and the DRX can determine whether to monitor RNTIs used for unicast transmission and UE connection state control, such as the Cell RNTI (C-RNTI) and the Configured Scheduling RNTI (CS-RNTI) in the PDCCH. Such a DRX can be referred to as a unicast DRX. On the other hand, to enable UEs performing multicast reception to receive the G-RNTI or G-CS-RNTI assigned to the multicast group, multicast DRX can be configured for UEs separate from unicast DRX. Multicast DRX can be configured for UEs in both RRC_connected and RRC_INACTIVE modes. Multicast DRX can be configured for UE RRC inactive modes using at least one of the following methods: RRC release message, SIB, and MCCH message. Multicast DRX can be configured for cells with multicast configured for this purpose, and a UE operating based on multicast DRX can determine whether to perform control channel monitoring based on RNTIs used for unicast transmission and UE connection state control (e.g., G-RNTI and Group Configuration Scheduling RNTI (G-CS-RNTI) in the PDCCH). Specifically, a UE with multicast DRX configured for it can monitor the PDCCH of the corresponding cell during the active period of multicast DRX by using the configured RNTI in G-RNTI and G-CS-RNTI. On the other hand, if it is not the active period of multicast DRX, the UE may not monitor the PDCCH by using G-RNTI or G-CS-RNTI. In conjunction with multicast DRX, it can be defined as the active period of multicast DRX if at least one of the following conditions is met.

[0064] -drx-onDurationTimerPTM runtime

[0065] -drx-InactivityTimerPTM runtime

[0066] -drx-RetransmissionTimerDLPTM runtime

[0067] Figure 2 Multicast DRX operation of a UE in RRC_connected mode according to an embodiment of this disclosure is illustrated.

[0068] After receiving multicast data (210), the UE in RRC_connected mode can send HARQ feedback to the gNB according to the Hybrid Automatic Repeat Request (HARQ) procedure to indicate whether the data has been successfully received (230). In an embodiment, the UE can send only negative acknowledgment (NACK) feedback to indicate failed reception (i.e., only NACK feedback). The time taken to send HARQ feedback after receiving multicast data can be represented by K1, and the value of K1 can be configured at the time slot level (220). Specifically, the UE can send HARQ feedback by using Physical Uplink Control Channel (PUCCH) resources configured from the time slot of the Medium Access Control Protocol Data Unit (MAC PDU) (or Transport Block (TB)) used to receive multicast data. The candidate groups for possible K1 values ​​can be configured via RRC configuration, and the value of one of the candidate groups can be indicated by the PDSCH-to-HARQ_feedback timing indicator field included in the downlink control information (DCI) of the PDCCH. This field indicates the scheduling of MAC PDUs (or TBs) for multicast data. The gNB can configure the candidate groups for K1 values ​​via RRC configuration messages, select one of the candidate group values, and indicate it to the UE via the DCI. The UE can then select the K1 value based on this.

[0069] exist Figure 2 In this embodiment, the K1 value is configured to represent three time slots, such that HARQ feedback (210, 220, and 230) has been sent after three time slots since the time of reception of the MAC PDU of the multicast data. In conjunction with the PUCCH resources used for sending HARQ feedback, if candidate groups of possible PUCCH resources are configured via RRC configuration, the value of one of the candidate groups can be indicated by the PUCCH resource indicator field included in the DCI of the PDCCH channel, which indicates the scheduling of the MAC PDU (or TB) of the multicast data. The gNB can configure the candidate groups of PUCCH resources used for sending HARQ feedback via RRC configuration messages and can select the value of one of the candidate groups and indicate it to the UE via the DCI. The UE can then send HARQ feedback using the indicated PUCCH resources for sending HARQ feedback.

[0070] To reduce the power consumption of UEs receiving multicast data, the gNB can configure multicast DRX for the UE. Multicast DRX can be configured for each G-RNTI of the UE, and the UE can operate according to the multicast DRX configured in the cell with the corresponding G-RNTI. If multicast DRX is configured for each G-RNTI, the values ​​included in the corresponding multicast DRX configuration can include at least one of the following: DRX period length, on-duration timer length (drx-onDurationTimerPTM), drx-InactivityTimerPTM, drx-HARQ-RTT-TimerDLPTM length, and drx-RetransmissionTimerDLPTM length. During multicast DRX configuration, the UE can have a predetermined on-duration timer for each configured DRX period, and the on-duration timer can be operated using drx-onDurationTimerPTM. The UE can initiate drx-InactivityTimerPTM when receiving a MAC PDU (or TB) via a G-RNTI or a connected G-CS-RNTI. In addition, the UE can initiate drx-HARQ-RTT-TimerDLPTM (240) corresponding to the G-RNTI used for receiving data in the first symbol after transmitting the HARQ feedback performed in step 230.

[0071] If the gNB instructs the UE not to send HARQ feedback, or if NACK-based HARQ feedback is configured to send feedback only in the event of data reception failure, and if no NACK is generated because data reception was successfully performed, then drx-HARQ-RTT-TimerDLPTM may not be initiated. After drx-HARQ-RTT-TimerDLPTM expires, the UE can initiate drx-RetransmissionTimerDLPTM (250) for multicast DRX with respect to the G-RNTI corresponding to drx-HARQ-RTT-TimerDLPTM. drx-RetransmissionTimerDLPTM can only be initiated if the corresponding multicast data fails to be successfully received (i.e., if decoding of the corresponding TB has failed). During multicast DRX operation, the UE can perform PDCCH monitoring only during the active time interval using the corresponding G-RNTI and G-CS-RNTI, and can perform PDCCH monitoring outside the active time interval without using the corresponding G-RNTI and G-CS-RNTI, thereby reducing power consumption. In conjunction with multicast DRX, an activity time can be defined if at least one of the following conditions is met.

[0072] -drx-onDurationTimerPTM is running.

[0073] -drx-InactivityTimerPTM is running.

[0074] -drx-RetransmissionTimerDLPTM is running.

[0075] exist Figure 2 In this embodiment, during the period when drx-RetransmissionTimerDLPTM is running, the UE can perform PDCCH monitoring by using G-RNTI and G-CS-RNTI, taking into account (or by considering) the fact that the cell for which G-RNTI is configured is active (260). This is advantageous because it enables the gNB to perform retransmissions while drx-RetransmissionTimerDLPTM is running, thereby reducing the HARQ retransmission delay time after performing the previous transmission 210.

[0076] Figure 3 Multicast DRX operation of a UE in RRC inactive mode is illustrated according to another embodiment of this disclosure.

[0077] After receiving multicast data (310), a UE in RRC inactive mode cannot send HARQ feedback to the gNB to indicate whether the data has been successfully received. This is because a UE in RRC inactive mode does not maintain uplink synchronization with the gNB and does not have the PUCCH resources configured for it to send HARQ feedback (330). Therefore, for a UE in RRC inactive mode, it is not necessary to configure the K1 value (e.g., Figure 2 The value in 220 indicates the time taken to send HARQ feedback after receiving multicast data. On the other hand, if a UE in RRC_connected mode fails to receive multicast data, the gNB can receive HARQ feedback from the UE in RRC_connected mode and perform HARQ retransmission based on it.

[0078] Furthermore, according to the embodiment, the gNB can perform arbitrary retransmission (blind retransmission) even if no HARQ feedback is received from the UE. In this case, even if multicast data (310) is not received, the UE in RRC inactive mode can still receive subsequently retransmitted data, thereby improving the quality of multicast service. For this purpose, drx-HARQ-RTT-TimerDLPTM and drx-RetransmissionTimerDLPTM need to be configured for UEs in RRC inactive mode to define procedures that facilitate multicast transmission / reception even in environments without HARQ feedback.

[0079] Figure 3 The embodiments described correspond to a method in which a UE in RRC inactive mode does not send HARQ feedback to the gNB, but instead specifies (or determines) a virtual HARQ feedback resource location, thereby initiating drx-HARQ-RTT-TimerDLPTM after the virtual HARQ feedback resource location. Specifically, the UE may consider (or assume) that HARQ feedback is sent in the PUCCH physical channel resources configured in a slot following a predetermined slot (e.g., virtual K1) initiated from the slot used to receive multicast data from the MAC PDU (or TB). A candidate group of possible K1 values ​​can be configured via RRC configuration (e.g., RRC release message or MCCH), and then the virtual K1 value is determined by selecting and indicating the value of one of the candidate groups through the PDSCH-to-HARQ_feedback timing indicator of the DCI field of the DCI of the scheduled PDCCH channel indicating multicast data. The gNB can configure candidate groups for virtual K1 values ​​via RRC configuration (e.g., RRC release messages or MCCH), and can select a value from one of the candidate groups and indicate it to the UE via DCI. The UE can then select a virtual K1 value based on this.

[0080] Figure 3The embodiment illustrates a scenario based on the assumption that the virtual K1 value is configured to represent three time slots (320) such that HARQ feedback exists three time slots after the time point from when the UE receives the MAC PDU (330) of the multicast data. Furthermore, the time point for sending the PUCCH resource for HARQ feedback can be virtually configured for the UE. Additionally, without configuring all PUCCH resource candidates for the virtual PUCCH resource, the gNB can also configure the time point for the UE for the virtual PUCCH resource used for virtual HARQ feedback to end in the time slot required for multicast DRX operation (e.g., symbol number 335). The gNB can configure a candidate group of possible PUCCH resources (e.g., the symbol number of the PUCCH resource end) via RRC configuration (e.g., RRC release message or MCCH), and can select and indicate the value of one of the candidate groups via the PUCCH resource indicator field included in the DCI of the PDCCH, which indicates the scheduling of the MAC PDU (or TB) of the multicast data. The gNB can configure candidate groups of PUCCH resources (e.g., the symbol number of the end of the PUCCH resource) for sending (or being assumed to be used for sending) HARQ feedback via RRC configuration messages, and can select a value from one of the candidate groups and indicate it to the UE via DCI. The UE can then use this to determine the timing of drx-HARQ_RTT-TimerDLPTM 340 startup.

[0081] According to an embodiment, the virtual K1 value (i.e., the slot length from PDSCH to virtual HARQ feedback) 320 can be configured via an RRC release message or MCCH message sent by the gNB to the UE. Alternatively, the gNB can configure the UE's virtual K1 value to a single value via the PDSCH-to-HARQ_feedback timing indicator field of the DCI.

[0082] According to an embodiment, the virtual PUCCH resource 330 information (e.g., the symbol number 335 indicating the end of the virtual PUCCH resource) can be configured in an RRC release message or MCCH message sent by the gNB to the UE. Alternatively, the virtual K1 value can be configured by the gNB in ​​the PUCCH resource indicator field of the DCI as a value for the UE.

[0083] To reduce the power consumption of UEs receiving multicast data, the gNB can configure multicast DRX for the UE. Multicast DRX can be configured for each G-RNTI of the UE, and the UE can operate according to the multicast DRX configured in the cell with the corresponding G-RNTI. If multicast DRX is configured for each G-RNTI, the values ​​included in the corresponding multicast DRX configuration can include at least one of the following: DRX period length, on-duration timer length (drx-onDurationTimerPTM), drx-InactivityTimerPTM, drx-HARQ-RTT-TimerDLPTM length, and drx-RetransmissionTimerDLPTM length. During multicast DRX configuration, the UE can have a predetermined on-duration timer for each configured DRX period, and the on-duration timer can be operated using drx-onDurationTimerPTM. The UE can initiate drx-InactivityTimerPTM when receiving a MAC PDU (or TB) via a G-RNTI or a connected G-CS-RNTI. In addition, the UE can initiate drx-HARQ-RTT-TimerDLPTM (340) corresponding to the G-RNTI used for receiving data in the first symbol after the virtual HARQ feedback resource (e.g., the symbol number at the end of the virtual PUCCH resource) in step 330.

[0084] according to Figure 3In this implementation scheme, a UE that does not send HARQ feedback can initiate drx-HARQ-RTT-TimerDLPTM. In this embodiment, drx-HARQ-RTT-TimerDLPTM can only be initiated if the UE fails to successfully receive multicast data (i.e., if the corresponding TB is not decoded). After drx-HARQ-RTT-TimerDLPTM expires, the UE can initiate drx-RetransmissionTimerDLPTM (350) for multicast DRX with respect to the G-RNTI corresponding to drx-HARQ-RTT-TimerDLPTM. drx-RetransmissionTimerDLPTM can only be initiated if the corresponding multicast data is not successfully received (i.e., if the decoding of the corresponding TB fails). During multicast DRX operation, the UE can perform PDCCH monitoring only during the active time interval using the corresponding G-RNTI and G-CS-RNTI, and can perform PDCCH monitoring outside the active time interval without using the corresponding G-RNTI and G-CS-RNTI, thereby reducing power consumption. In conjunction with multicast DRX, an activity time can be defined if at least one of the following conditions is met.

[0085] -drx-onDurationTimerPTM is running.

[0086] -drx-InactivityTimerPTM is running.

[0087] -drx-RetransmissionTimerDLPTM is running.

[0088] exist Figure 3 In this implementation, during the period when drx-RetransmissionTimerDLPTM is running, taking into account the fact that cells configured with G-RNTI are active (or considering the fact that cells configured with G-RNTI are active), the UE can perform PDCCH monitoring (360) using G-RNTI (and G-CS-RNTI). This is advantageous because it enables the gNB to perform retransmissions while drx-RetransmissionTimerDLPTM is running, thereby reducing the HARQ retransmission delay time after performing the previous transmission 310, and enabling UEs in RRC inactive mode to receive retransmissions.

[0089] Despite Figure 3 In the embodiments, it has been assumed that a UE in RRC inactive mode that does not send HARQ feedback performs multicast DRX operation, but Figure 3The implementation can also be applied to a UE in RRC_connected mode sending drx-HARQ-RTT-TimerDLPTM regardless of the HARQ feedback transmission operation.

[0090] Figure 4 Multicast DRX operation of a UE in RRC inactive mode according to an embodiment of this disclosure is illustrated.

[0091] After receiving multicast data (410), a UE in RRC inactive mode cannot send HARQ feedback to the gNB to indicate whether the data has been successfully received. This is because a UE in RRC inactive mode does not maintain uplink synchronization with the gNB and does not have the PUCCH resources configured for it to send HARQ feedback. Therefore, for UEs in RRC inactive mode, it is not necessary to configure the K1 value (e.g., Figure 2 The value in 220 indicates the time taken to send HARQ feedback after receiving multicast data. On the other hand, if a UE in RRC_connected mode fails to receive multicast data, the gNB can receive HARQ feedback from the UE in RRC_connected mode and perform HARQ retransmission based on it.

[0092] Furthermore, according to the embodiment, the gNB can perform arbitrary retransmissions even without receiving HARQ feedback (blind retransmission) from the UE. In this case, even if multicast data (410) is not received, the UE in RRC inactive mode can still receive subsequently retransmitted data, thereby improving the quality of multicast service. For this purpose, drx-HARQ-RTT-TimerDLPTM and drx-RetransmissionTimerDLPTM need to be configured for UEs in RRC inactive mode to define procedures that facilitate multicast transmission / reception even in environments without HARQ feedback.

[0093] Figure 4The embodiment described corresponds to a method for a UE in RRC inactive mode to initiate drx-HARQ-RTT-TimerDLPTM after a predetermined time slot. Specifically, the UE can initiate drx-HARQ-RTT-TimerDLPTM immediately after k time slots 420 determined after the time slot for receiving the MAC PDU (or TB) for multicast data (440). For the time slot k value, a candidate group of possible k values ​​can be configured via RRC configuration (e.g., RRC release message or MCCH), where the value of one candidate group can be indicated by the PDSCH-to-HARQ_feedback timing indicator field of the DCI of the scheduled PDCCH channel indicating the multicast data MAC PDU (or TB). The gNB can configure the candidate group of time slot k values ​​via RRC configuration (e.g., RRC release message or MCCH) messages and can select one of the candidate group values ​​and indicate it to the UE via the DCI. The UE can then select the time slot k value based on this. Figure 4 The embodiment illustrates a scenario where the virtual k value is configured to represent three time slots (420), such that drx-HARQ-RTT-TimerDLPTM is activated at the point in time when the MAC PDU for multicast data is received from the UE, after three time slots (i.e., at the start of the next time slot after three time slots). The UE can use this to determine the activation time of drx-HARQ_RTT-TimerDLPTM 440.

[0094] According to an embodiment, the slot k value 420 can be configured via an RRC release message or MCCH message sent by the gNB to the UE. Alternatively, the gNB can configure the UE's slot k value to a value via the PDSCH-to-HARQ_feedback timing indicator field of the DCI.

[0095] To reduce the power consumption of UEs receiving multicast data, the gNB can configure multicast DRX for the UE. Multicast DRX can be configured for each G-RNTI of the UE, and the UE can operate according to the multicast DRX configured in the cell with the corresponding G-RNTI. If multicast DRX is configured for each G-RNTI, the values ​​included in the corresponding multicast DRX configuration can include at least one of the following: DRX period length, on-duration timer length (drx-onDurationTimerPTM), drx-InactivityTimerPTM, drx-HARQ-RTT-TimerDLPTM length, and drx-RetransmissionTimerDLPTM length. During multicast DRX configuration, the UE can have a predetermined on-duration timer for each configured DRX period, and the on-duration timer can be operated using drx-onDurationTimerPTM. The UE can initiate drx-InactivityTimerPTM when receiving a MAC PDU (or TB) via a G-RNTI or a connected G-CS-RNTI. Furthermore, the UE can initiate drx-HARQ-RTT-TimerDLPTM (440) corresponding to the G-RNTI used for receiving data in the first symbol after k time slots 420.

[0096] according to Figure 4 In this implementation scheme, a UE that does not send HARQ feedback can initiate drx-HARQ-RTT-TimerDLPTM. In this embodiment, drx-HARQ-RTT-TimerDLPTM can only be initiated if the UE fails to successfully receive multicast data (i.e., if the corresponding TB is not decoded). After drx-HARQ-RTT-TimerDLPTM expires, the UE can initiate drx-RetransmissionTimerDLPTM (450) for multicast DRX with respect to the G-RNTI corresponding to drx-HARQ-RTT-TimerDLPTM. drx-RetransmissionTimerDLPTM can only be initiated if the corresponding multicast data is not successfully received (i.e., if the decoding of the corresponding TB fails). During multicast DRX operation, the UE can perform PDCCH monitoring only during the active time interval using the corresponding G-RNTI and G-CS-RNTI, and can perform PDCCH monitoring outside the active time interval without using the corresponding G-RNTI and G-CS-RNTI, thereby reducing power consumption. In conjunction with multicast DRX, an activity time can be defined if at least one of the following conditions is met.

[0097] -drx-onDurationTimerPTM is running.

[0098] -drx-InactivityTimerPTM is running.

[0099] -drx-RetransmissionTimerDLPTM is running.

[0100] exist Figure 4 In one embodiment, during the period when drx-RetransmissionTimerDLPTM is running, the UE can perform PDCCH monitoring by using G-RNTI (and G-CS-RNTI), taking into account (or by considering) the fact that the cell for which G-RNTI is configured is active (460). This is advantageous because it enables the gNB to perform retransmissions while drx-RetransmissionTimerDLPTM is running, thereby reducing the HARQ retransmission delay time after performing the previous transmission 410, and enabling UEs in RRC inactive mode to receive retransmissions.

[0101] Despite Figure 4 In the embodiments, it has been assumed that a UE in RRC inactive mode that does not send HARQ feedback performs multicast DRX operation, but Figure 4 The implementation can also be applied to a UE in RRC_connected mode sending drx-HARQ-RTT-TimerDLPTM regardless of the HARQ feedback transmission operation.

[0102] Figure 5 Multicast DRX operation of a UE in RRC inactive mode according to an embodiment of this disclosure is illustrated.

[0103] After receiving multicast data (510), a UE in RRC inactive mode cannot send HARQ feedback to the gNB to indicate whether the data has been successfully received. This is because a UE in RRC inactive mode does not maintain uplink synchronization with the gNB and does not have the PUCCH resources configured for it to send HARQ feedback. Therefore, for UEs in RRC inactive mode, it is not necessary to configure the K1 value (e.g., Figure 2 The value in 220 indicates the time taken to send HARQ feedback after receiving multicast data. On the other hand, if a UE in RRC_connected mode fails to receive multicast data, the gNB can receive HARQ feedback from the UE in RRC_connected mode and perform HARQ retransmission based on it.

[0104] Furthermore, according to the embodiment, the gNB can perform arbitrary retransmissions even without receiving HARQ feedback (blind retransmission) from the UE. In this case, even if multicast data (510) is not received, the UE in RRC inactive mode can still receive subsequently retransmitted data, thereby improving the quality of multicast service. For this purpose, drx-HARQ-RTT-TimerDLPTM and drx-RetransmissionTimerDLPTM need to be configured for UEs in RRC inactive mode to define procedures that facilitate multicast transmission / reception even in environments without HARQ feedback.

[0105] Figure 5 The embodiments described correspond to a method for a UE in RRC inactive mode to initiate drx-HARQ-RTT-TimerDLPTM after a predetermined time slot. Specifically, the UE can apply a virtual feedback time (520) starting from the next symbol immediately following the end of the radio resources (e.g., the Physical Downlink Shared Channel (PDSCH)) for receiving multicast data (e.g., the MAC PDU (or TB)). The virtual feedback time can refer to the time required for the UE in RRC inactive mode to send HARQ feedback and the time the UE waits to initiate drx-HARQ-RTT-TimerDLPTM. The virtual feedback time can be implemented as a timer operation, and the UE can initiate a timer immediately after the end of the resources for receiving multicast data (MAC PDU) for applying the virtual feedback time to the next symbol (or the next time slot). Subsequently, the UE can initiate drx-HARQ-RTT-TimerDLPTM (540) at the end of the virtual feedback time (or at the expiration time of the timer used to apply the virtual feedback time). For the virtual feedback time value, possible candidate groups can be configured via RRC configuration (e.g., RRC release message or MCCH), and the value of one of the candidate groups can be selected and indicated via the PDSCH-to-HARQ_feedback timing indicator field of the DCI of the scheduled PDCCH channel indicating multicast data (MAC PDU (or TB)). The gNB can configure the candidate groups for the virtual feedback time value for the UE via RRC configuration (e.g., RRC release message or MCCH) messages, and can select the value of one of the candidate groups and indicate it to the UE via the DCI. The UE can then select the virtual feedback time value based on this. Figure 5The embodiment illustrates a scenario where the virtual feedback time is configured to represent three time slots (520), such that drx-HARQ-RTT-TimerDLPTM is activated at the point in time when the MAC PDU for multicast data is received from the UE, after three time slots (i.e., at the start of the next time slot after three time slots). The UE can use this to determine the activation time of drx-HARQ_RTT-TimerDLPTM 540.

[0106] According to an embodiment, the virtual feedback time value 520 can be configured via an RRC release message or MCCH message sent by the gNB to the UE. Alternatively, the gNB can configure the UE's virtual feedback time value to a value via the PDSCH-to-HARQ_feedback timing indicator field of the DCI.

[0107] To reduce the power consumption of UEs receiving multicast data, the gNB can configure multicast DRX for the UE. Multicast DRX can be configured for each G-RNTI of the UE, and the UE can operate according to the multicast DRX configured in the cell with the corresponding G-RNTI. If multicast DRX is configured for each G-RNTI, the values ​​included in the corresponding multicast DRX configuration can include at least one of the following: DRX period length, on-duration timer length (drx-onDurationTimerPTM), drx-InactivityTimerPTM, drx-HARQ-RTT-TimerDLPTM length, and drx-RetransmissionTimerDLPTM length. During multicast DRX configuration, the UE can have a predetermined on-duration timer for each configured DRX period, and the on-duration timer can be operated using drx-onDurationTimerPTM. The UE can initiate drx-InactivityTimerPTM when receiving a MAC PDU (or TB) via a G-RNTI or a connected G-CS-RNTI. In addition, the UE can start the drx-HARQ-RTT-TimerDLPTM (540) corresponding to the G-RNTI used for receiving data immediately after the virtual feedback time 520 ends.

[0108] according to Figure 5In the implementation scheme, a UE that does not send HARQ feedback can initiate drx-HARQ-RTT-TimerDLPTM. In this embodiment, drx-HARQ-RTT-TimerDLPTM can only be initiated if the UE fails to successfully receive multicast data (i.e., if the corresponding TB is not decoded). If the virtual feedback time is implemented by a timer, the UE can only initiate the timer for applying the virtual feedback time if the UE fails to successfully receive multicast data (i.e., if the corresponding TB is not decoded). After drx-HARQ-RTT-TimerDLPTM expires, the UE can initiate drx-RetransmissionTimerDLPTM (550) for the multicast DRX of the G-RNTI corresponding to drx-HARQ-RTT-TimerDLPTM. drx-RetransmissionTimerDLPTM can only be initiated if the corresponding multicast data is not successfully received (i.e., if the decoding of the corresponding TB fails). During multicast DRX operation, the UE can perform PDCCH monitoring only during the active time interval by using the corresponding G-RNTI and G-CS-RNTI, and can perform PDCCH monitoring outside the active time interval without using the corresponding G-RNTI and G-CS-RNTI, thereby reducing power consumption. In conjunction with multicast DRX, an active time can be defined if at least one of the following conditions is met.

[0109] -drx-onDurationTimerPTM is running.

[0110] -drx-InactivityTimerPTM is running.

[0111] -drx-RetransmissionTimerDLPTM is running.

[0112] exist Figure 5 In the embodiment, during the period when drx-RetransmissionTimerDLPTM is running, the UE can perform PDCCH monitoring by using G-RNTI (and G-CS-RNTI), taking into account (or by considering) the fact that the cell for which G-RNTI is configured is active (560). This is advantageous because it enables the gNB to perform retransmissions while drx-RetransmissionTimerDLPTM is running, thereby reducing the HARQ retransmission delay time after performing the previous transmission 510, and enabling UEs in RRC inactive mode to receive retransmissions. Figure 5The virtual feedback time described in the embodiments can be configured by using at least one of symbol units, time slot units, subframe units, millisecond units, and microsecond units, or by using other time units.

[0113] Despite Figure 5 In the embodiments, it has been assumed that a UE in RRC inactive mode that does not send HARQ feedback performs multicast DRX operation, but Figure 5 The implementation can also be applied to a UE in RRC_connected mode sending drx-HARQ-RTT-TimerDLPTM regardless of the HARQ feedback transmission operation.

[0114] Figure 6 Multicast DRX operation of a UE in RRC inactive mode according to an embodiment of this disclosure is illustrated.

[0115] After receiving multicast data (610), a UE in RRC inactive mode cannot send HARQ feedback to the gNB to indicate whether the data has been successfully received. This is because a UE in RRC inactive mode does not maintain uplink synchronization with the gNB and does not have the PUCCH resources configured for it to send HARQ feedback. Therefore, for a UE in RRC inactive mode, it is not necessary to configure a K1 value (e.g., 220) to indicate the time spent sending HARQ feedback after receiving multicast data. On the other hand, if a UE in RRC_connected mode fails to receive multicast data, the gNB can receive HARQ feedback from the UE in RRC_connected mode and can perform HARQ retransmission based on this feedback.

[0116] Furthermore, according to the embodiment, the gNB can perform arbitrary retransmissions even without receiving HARQ feedback (blind retransmission) from the UE. In this case, even if multicast data (610) is not received, the UE in RRC inactive mode can still receive subsequently retransmitted data, thereby improving the quality of multicast service. For this purpose, drx-HARQ-RTT-TimerDLPTM and drx-RetransmissionTimerDLPTM need to be configured for UEs in RRC inactive mode to define procedures that facilitate multicast transmission / reception even in environments without HARQ feedback.

[0117] Figure 6The embodiment described corresponds to a method for a UE in RRC inactive mode to initiate drx-HARQ-RTT-TimerDLPTM after a predetermined time slot. Specifically, the UE can apply the virtual feedback time (620) starting from the next symbol immediately following the PDCCH resource 600 indicating the end of multicast data reception (or from the next time slot after the end of the PDCCH resource). The virtual feedback time can refer to the time required for the UE in RRC_connected mode to send HARQ feedback, and the time for the UE in RRC inactive mode to wait to initiate drx-HARQ-RTT-TimerDLPTM. The virtual feedback time can be implemented as a timer operation, and the UE can start a timer for applying the virtual feedback time from the next symbol immediately following the PDCCH resource indicating the end of multicast data reception (or from the next time slot after the end of the PDCCH resource). Thereafter, the UE can initiate drx-HARQ-RTT-TimerDLPTM at the end of the virtual feedback time (or at the time when the timer for applying the virtual feedback time expires) (640). For the virtual feedback time value, possible candidate groups can be configured via RRC configuration (e.g., RRC release message or MCCH), and the value of one of the candidate groups can be selected and indicated via the PDSCH-to-HARQ_feedback timing indicator field of the DCI of the scheduled PDCCH channel for multicast data MAC PDUs (or TBs). The gNB can configure the candidate groups for the virtual feedback time value for the UE via RRC configuration (e.g., RRC release message or MCCH) messages, and can select the value of one of the candidate groups and indicate it to the UE via the DCI. The UE can then select the virtual feedback time value based on this. Figure 6 The embodiment illustrates a scenario where the virtual feedback time is configured to represent four time slots (620), such that drx-HARQ-RTT-TimerDLPTM is initiated at a time point four time slots after the end of the PUCCH indicating the reception of multicast data (i.e., the start time of the next time slot after four time slots). The UE can use this to determine the initiation time of drx-HARQ_RTT-TimerDLPTM 640.

[0118] According to an embodiment, the virtual feedback time value 620 can be configured via an RRC release message or MCCH message sent by the gNB to the UE. Alternatively, the gNB can configure the UE's virtual feedback time value to a value via the PDSCH-to-HARQ_feedback timing indicator field of the DCI.

[0119] To reduce the power consumption of UEs receiving multicast data, the gNB can configure multicast DRX for the UE. Multicast DRX can be configured for each G-RNTI of the UE, and the UE can operate according to the multicast DRX configured in the cell with the corresponding G-RNTI. If multicast DRX is configured for each G-RNTI, the values ​​included in the corresponding multicast DRX configuration can include at least one of the following: DRX period length, on-duration timer length (drx-onDurationTimerPTM), drx-InactivityTimerPTM, drx-HARQ-RTT-TimerDLPTM length, and drx-RetransmissionTimerDLPTM length. During multicast DRX configuration, the UE can have a predetermined on-duration timer for each configured DRX period, and the on-duration timer can be operated using drx-onDurationTimerPTM. The UE can initiate drx-InactivityTimerPTM when receiving a MAC PDU (or TB) via a G-RNTI or a connected G-CS-RNTI. In addition, the UE can start drx-HARQ-RTT-TimerDLPTM (640) corresponding to the G-RNTI used for receiving data immediately after the virtual feedback time 620 ends.

[0120] according to Figure 6In the implementation scheme, a UE that does not send HARQ feedback can initiate drx-HARQ-RTT-TimerDLPTM. In this embodiment, drx-HARQ-RTT-TimerDLPTM can only be initiated if the UE fails to successfully receive multicast data (i.e., if the corresponding TB is not decoded). If the virtual feedback time is implemented by a timer, the UE can only initiate the timer for applying the virtual feedback time if the UE fails to successfully receive multicast data (i.e., if the corresponding TB is not decoded). If multicast data is successfully received despite the timer for applying the virtual feedback time being initiated, the UE can stop the timer. After drx-HARQ-RTT-TimerDLPTM expires, the UE can initiate drx-RetransmissionTimerDLPTM (650) for the multicast DRX of the G-RNTI corresponding to drx-HARQ-RTT-TimerDLPTM. drx-RetransmissionTimerDLPTM can only be initiated if the corresponding multicast data is not successfully received (i.e., if the decoding of the corresponding TB fails). During multicast DRX operation, the UE can perform PDCCH monitoring only during the active time interval by using the corresponding G-RNTI and G-CS-RNTI, and can perform PDCCH monitoring outside the active time interval without using the corresponding G-RNTI and G-CS-RNTI, thereby reducing power consumption. In conjunction with multicast DRX, an active time can be defined if at least one of the following conditions is met.

[0121] -drx-onDurationTimerPTM is running.

[0122] -drx-InactivityTimerPTM is running.

[0123] -drx-RetransmissionTimerDLPTM is running.

[0124] exist Figure 6 In one embodiment, during the period when drx-RetransmissionTimerDLPTM is running, the UE can perform PDCCH monitoring by using G-RNTI (and G-CS-RNTI), taking into account (or by considering) the fact that the cell for which G-RNTI is configured is active (660). This is advantageous because it enables the gNB to perform retransmissions while drx-RetransmissionTimerDLPTM is running, thereby reducing the HARQ retransmission delay time after performing the previous transmission 610, and enabling UEs in RRC inactive mode to receive retransmissions. Figure 6 The virtual feedback time described in the embodiments can be configured by using at least one of symbol units, time slot units, subframe units, millisecond units, and microsecond units, or by using other time units.

[0125] Despite Figure 6 In the embodiments, it has been assumed that a UE in RRC inactive mode that does not send HARQ feedback performs multicast DRX operation, but Figure 6 The implementation can also be applied to a UE in RRC_connected mode sending drx-HARQ-RTT-TimerDLPTM regardless of the HARQ feedback transmission operation.

[0126] Figure 7 Multicast DRX operation of a UE in RRC inactive mode according to an embodiment of this disclosure is illustrated.

[0127] After receiving multicast data (710), a UE in RRC inactive mode cannot send HARQ feedback to the gNB to indicate whether the data has been successfully received. This is because a UE in RRC inactive mode does not maintain uplink synchronization with the gNB and does not have the PUCCH resources configured for it to send HARQ feedback. Therefore, for UEs in RRC inactive mode, it is not necessary to configure the K1 value (e.g., Figure 2 The value in 220 indicates the time taken to send HARQ feedback after receiving multicast data. On the other hand, if a UE in RRC_connected mode fails to receive multicast data, the gNB can receive HARQ feedback from the UE in RRC_connected mode and perform HARQ retransmission based on it.

[0128] Furthermore, according to the embodiment, the gNB can perform arbitrary retransmissions even without receiving HARQ feedback (blind retransmission). In this case, even if multicast data (710) is not received, the UE in RRC inactive mode can still receive subsequently retransmitted data, thereby improving the quality of multicast service. For this purpose, drx-HARQ-RTT-TimerDLPTM and drx-RetransmissionTimerDLPTM need to be configured for UEs in RRC inactive mode to define procedures that facilitate multicast transmission / reception even in environments without HARQ feedback.

[0129] Figure 7The embodiment corresponds to a method in which a UE in RRC inactive mode starts a drx-HARQ-RTT-TimerDLPTM timer using a separate drx-HARQ-RTT-TimerDLPTM value. The UE in RRC inactive mode does not send HARQ feedback, but the duration of the drx-HARQ-RTT-TimerDLPTM timer can be determined by considering the HARQ feedback time, including the virtual feedback time 720 (740). Finally, the length of the drx-HARQ-RTT-TimerDLPTM timer can be determined by considering the virtual feedback time 720 and the expected gNB processing time 735 from HARQ feedback to retransmission resource allocation. In the example, the length of the drx-HARQ-RTT-TimerDLPTM timer can be configured as the sum of the virtual feedback time 720 and the expected gNB processing time 735 (740). A UE in RRC inactive mode can start drx-HARQ-RTT-TimerDLPTM by configuring the drx-HARQ-RTT-TimerDLPTM value to take into account the virtual feedback time and the expected gNB processing time immediately preceding the start of drx-HARQ-RTT-TimerDLPTM (e.g., sum). The UE can start the drx-HARQ-RTT-TimerDLPTM timer (740) by applying the above value from the next symbol immediately following the end of the radio resource (e.g., PDSCH resource) used to receive multicast data (MAC PDU (or TB)) (or the next time slot immediately following the end of the radio resource (e.g., PDSCH resource)). In an embodiment, the expected gNB processing time can be configured to be included in the drx-HARQ-RTT-TimerDLPTM value itself via an RRC release message or MCCH message, and a separate timer (e.g., drx-HARQ-RTT-TimerDLPTM-Inactive) can be configured as the sum of the drx-HARQ-RTT-TimerDLPTM value and the virtual feedback time.

[0130] According to an embodiment, the gNB can configure a possible candidate group for the virtual feedback time value for the UE via RRC configuration (e.g., an RRC release message or MCCH), and can select a value from one of the candidate groups and indicate it to the UE via the PDSCH-to-HARQ_feedback timing indicator field of the DCI of the scheduled PDCCH channel of the MACPDU (or TB) indicating multicast data. The gNB can configure the candidate group for the virtual feedback time value via RRC configuration (e.g., an RRC release message or MCCH) message, and can select a value from one of the candidate groups and indicate it to the UE via the DCI. The UE can then select a virtual feedback time value based on this.

[0131] According to an embodiment, the virtual feedback time can be configured individually using symbol units. For example, the entire virtual feedback time can be configured as the sum of the virtual feedback time indicated in the PDSCH-to-HARQ_feedback timing indicator field and the symbol unit virtual feedback time in the PUCCH resource indicator field. Combined with the symbol unit virtual feedback time, candidate groups of virtual feedback time values ​​can be configured via RRC configuration (e.g., RRC release message or MCCH message), and a value from one of the candidate groups can be selected and indicated to the UE via DCI. The UE can then select a symbol-unit virtual feedback time value based on this.

[0132] In this embodiment, the virtual feedback time 720 can be configured in the RRC release message or MCCH message sent by the gNB to the UE. Alternatively, the virtual feedback time can be configured by the gNB in ​​the PDSCH-to-HARQ_feedback timing indicator field of the DCI to a value for the UE.

[0133] In one embodiment, the symbol-unit virtual feedback time can be configured in an RRC release message or MCCH message sent by the gNB to the UE. Alternatively, the symbol-unit virtual feedback time can be configured by the gNB in ​​the PUCCH resource indicator field of the DCI as a value for the UE.

[0134] exist Figure 7 In the illustrated embodiment, the virtual feedback time is configured to correspond to three time slots (720), and the expected gNB processing time is configured to correspond to four time slots (735). Therefore, the entire duration of drx-HARQ-RTT-TimerDLPTM can correspond to seven time slots (740). Thus, drx-HARQ-RTT-TimerDLPTM can operate for a period of seven time slots after the time point 710 when the UE receives the MAC PDU of multicast data (740).

[0135] To reduce the power consumption of UEs receiving multicast data, the gNB can configure multicast DRX for the UE. Multicast DRX can be configured for each G-RNTI of the UE, and the UE can operate according to the multicast DRX configured in the cell with the corresponding G-RNTI. If multicast DRX is configured for each G-RNTI, the values ​​included in the corresponding multicast DRX configuration can include at least one of the following: DRX period length, on-duration timer length (drx-onDurationTimerPTM), drx-InactivityTimerPTM, drx-HARQ-RTT-TimerDLPTM length, and drx-RetransmissionTimerDLPTM length. During multicast DRX configuration, the UE can have a predetermined on-duration timer for each configured DRX period, and the on-duration timer can be operated using drx-onDurationTimerPTM. The UE can initiate drx-InactivityTimerPTM when receiving a MAC PDU (or TB) via a G-RNTI or a connected G-CS-RNTI. In some implementations, drx-HARQ-RTT-TimerDLPTM can only be initiated when the UE fails to successfully receive multicast data (i.e., if the corresponding TB is not decoded). After drx-HARQ-RTT-TimerDLPTM expires, the UE can initiate drx-RetransmissionTimerDLPTM (750) for multicast DRX with respect to the G-RNTI corresponding to drx-HARQ-RTT-TimerDLPTM. drx-RetransmissionTimerDLPTM can only be initiated when the corresponding multicast data is not successfully received (i.e., if the decoding of the corresponding TB fails). During multicast DRX operation, the UE can perform PDCCH monitoring only during the active time interval using the corresponding G-RNTI and G-CS-RNTI, and can perform PDCCH monitoring outside the active time interval without using the corresponding G-RNTI and G-CS-RNTI, thereby reducing power consumption. In conjunction with multicast DRX, an active time can be defined if at least one of the following conditions is met.

[0136] -drx-onDurationTimerPTM is running.

[0137] -drx-InactivityTimerPTM is running.

[0138] -drx-RetransmissionTimerDLPTM is running.

[0139] exist Figure 7 In one embodiment, during the period when drx-RetransmissionTimerDLPTM is running, the UE can perform PDCCH monitoring by using G-RNTI (and G-CS-RNTI), taking into account (or by considering) the fact that the cell for which G-RNTI is configured is active (760). This is advantageous because it enables the gNB to perform retransmissions while drx-RetransmissionTimerDLPTM is running, thereby reducing the HARQ retransmission delay time after performing the previous transmission 710, and enabling UEs in RRC inactive mode to receive retransmissions. Figure 7 The virtual feedback time 720 described in the embodiments can be configured by using at least one of symbol units, time slot units, subframe units, millisecond units, and microsecond units, or it can be configured by using other time units.

[0140] Despite Figure 7 In the embodiments, it has been assumed that a UE in RRC inactive mode that does not send HARQ feedback performs multicast DRX operation, but Figure 7 The implementation can also be applied to a UE in RRC_connected mode sending drx-HARQ-RTT-TimerDLPTM regardless of the HARQ feedback transmission operation.

[0141] Figure 8 Multicast DRX operation of a UE in RRC inactive mode according to an embodiment of this disclosure is illustrated.

[0142] After receiving multicast data (810), a UE in RRC inactive mode cannot send HARQ feedback to the gNB to indicate whether the data has been successfully received. This is because a UE in RRC inactive mode does not maintain uplink synchronization with the gNB and does not have the PUCCH resources configured for it to send HARQ feedback. Therefore, for UEs in RRC inactive mode, it is not necessary to configure the K1 value (e.g., Figure 2 The value in 220 indicates the time taken to send HARQ feedback after receiving multicast data. On the other hand, if a UE in RRC_connected mode fails to receive multicast data, the gNB can receive HARQ feedback from the UE in RRC_connected mode and perform HARQ retransmission based on it.

[0143] Furthermore, according to the embodiment, the gNB can perform arbitrary retransmissions even without receiving HARQ feedback (blind retransmission). In this case, even if multicast data (810) is not received, the UE in RRC inactive mode can still receive subsequently retransmitted data, thereby improving the quality of multicast service. For this purpose, drx-HARQ-RTT-TimerDLPTM and drx-RetransmissionTimerDLPTM need to be configured for UEs in RRC inactive mode to define procedures that facilitate multicast transmission / reception even in environments without HARQ feedback.

[0144] Figure 8 The embodiment corresponds to a method in which a UE in RRC inactive mode starts the drx-HARQ-RTT-TimerDLPTM timer using a separate drx-HARQ-RTT-TimerDLPTM value. The UE in RRC inactive mode does not send HARQ feedback, but the duration of the drx-HARQ-RTT-TimerDLPTM timer can be determined by taking into account the HARQ feedback time of the RRC_connected UE, including the virtual feedback time 820 (840). Finally, the length of the drx-HARQ-RTT-TimerDLPTM timer can be determined by taking into account the virtual feedback time 820 and the expected gNB processing time 835 from HARQ feedback to retransmission resource allocation. In the example, the length of the drx-HARQ-RTT-TimerDLPTM timer can be configured as the sum of the virtual feedback time 820 and the expected gNB processing time 835 (840). A UE in RRC inactive mode can initiate drx-HARQ-RTT-TimerDLPTM after configuring the drx-HARQ-RTT-TimerDLPTM value to take into account the virtual feedback time and the expected gNB processing time immediately preceding the initiation of drx-HARQ-RTT-TimerDLPTM (e.g., summation). The UE can apply and initiate the drx-HARQ-RTT-TimerDLPTM timer value (840) from the next symbol immediately following the PDCCH resource 800 indicating the end of multicast data transmission (or from the next time slot after the end of the PDCCH resource). In an embodiment, the expected gNB processing time can be configured to be included in the drx-HARQ-RTT-TimerDLPTM value itself via an RRC release message or MCCH message, and a separate timer (e.g., drx-HARQ-RTT-TimerDLPTM-Inactive) can be configured as the sum of the drx-HARQ-RTT-TimerDLPTM value and the virtual feedback time.

[0145] According to an embodiment, the gNB can configure a possible candidate group for the virtual feedback time value for the UE via RRC configuration (e.g., an RRC release message or MCCH), and can select a value from one of the candidate groups and indicate it to the UE via the PDSCH-to-HARQ_feedback timing indicator field of the DCI of the scheduled PDCCH channel of the MACPDU (or TB) indicating multicast data. The gNB can configure the candidate group for the virtual feedback time value via RRC configuration (e.g., an RRC release message or MCCH) message, and can select a value from one of the candidate groups and indicate it to the UE via the DCI. The UE can then select a virtual feedback time value based on this.

[0146] According to an embodiment, the virtual feedback time can be configured individually using symbol units. For example, the entire virtual feedback time can be configured as the sum of the virtual feedback time indicated in the PDSCH-to-HARQ_feedback timing indicator field and the symbol unit virtual feedback time in the PUCCH resource indicator field. Combined with the symbol unit virtual feedback time, candidate groups of virtual feedback time values ​​can be configured via RRC configuration (e.g., RRC release messages or MCCH messages), and a value from one of the candidate groups can be selected and indicated to the UE via DCI. The UE can then select a symbol-unit virtual feedback time value based on this.

[0147] In this embodiment, the virtual feedback time 820 can be configured in the RRC release message or MCCH message sent by the gNB to the UE. Alternatively, the virtual feedback time can be configured by the gNB as a value for the UE in the PDSCH-to-HARQ_feedback timing indicator field of the DCI.

[0148] In one embodiment, the symbol-unit virtual feedback time can be configured in the RRC release message or MCCH message sent by the gNB to the UE. Alternatively, the symbol-unit virtual feedback time can be configured by the gNB in ​​the PUCCH resource indicator field of the DCI as a value for the UE.

[0149] exist Figure 8 In the illustrated embodiment, the virtual feedback time is configured to correspond to four time slots (820), and the expected gNB processing time is configured to correspond to four time slots (835). Therefore, the entire duration of drx-HARQ-RTT-TimerDLPTM can correspond to eight time slots (840). Thus, the UE can run drx-HARQ-RTT-TimerDLPTM (840) for eight time slots after the PDCCH resource 800 indicating the end of multicast data reception.

[0150] To reduce the power consumption of UEs receiving multicast data, the gNB can configure multicast DRX for the UE. Multicast DRX can be configured for each G-RNTI of the UE, and the UE can operate according to the multicast DRX configured in the cell with the corresponding G-RNTI. If multicast DRX is configured for each G-RNTI, the values ​​included in the corresponding multicast DRX configuration can include at least one of the following: DRX period length, on-duration timer length (drx-onDurationTimerPTM), drx-InactivityTimerPTM, drx-HARQ-RTT-TimerDLPTM length, and drx-RetransmissionTimerDLPTM length. During multicast DRX configuration, the UE can have a predetermined on-duration timer for each configured DRX period, and the on-duration timer can be operated using drx-onDurationTimerPTM. The UE can initiate drx-InactivityTimerPTM when receiving a MAC PDU (or TB) via a G-RNTI or a connected G-CS-RNTI. In some implementations, drx-HARQ-RTT-TimerDLPTM can only be initiated when the UE fails to successfully receive multicast data (i.e., if the corresponding TB is not decoded). After drx-HARQ-RTT-TimerDLPTM expires, the UE can initiate drx-RetransmissionTimerDLPTM (850) for multicast DRX with respect to the G-RNTI corresponding to drx-HARQ-RTT-TimerDLPTM. drx-RetransmissionTimerDLPTM can only be initiated when the corresponding multicast data is not successfully received (i.e., if the decoding of the corresponding TB fails). During multicast DRX operation, the UE can perform PDCCH monitoring only during the active time interval by using the corresponding G-RNTI and G-CS-RNTI, and can perform PDCCH monitoring outside the active time interval without using the corresponding G-RNTI and G-CS-RNTI, thereby reducing power consumption. In conjunction with multicast DRX, an active time can be defined if at least one of the following conditions is met.

[0151] -drx-onDurationTimerPTM is running.

[0152] -drx-InactivityTimerPTM is running.

[0153] -drx-RetransmissionTimerDLPTM is running.

[0154] exist Figure 8 In one embodiment, during the period when drx-RetransmissionTimerDLPTM is running, the UE can perform PDCCH monitoring by using G-RNTI (and G-CS-RNTI), taking into account (or by considering) the fact that the cell for which G-RNTI is configured is active (860). This is advantageous because it enables the gNB to perform retransmissions while drx-RetransmissionTimerDLPTM is running, thereby reducing the HARQ retransmission delay time after performing the previous transmission 810, and enabling UEs in RRC inactive mode to receive retransmissions. Figure 8 The virtual feedback time 820 described in the embodiments can be configured by using at least one of symbol units, time slot units, subframe units, millisecond units, and microsecond units, or it can be configured by using other time units.

[0155] Despite Figure 8 In the embodiments, it has been assumed that a UE in RRC inactive mode that does not send HARQ feedback performs multicast DRX operation, but Figure 8 The implementation can also be applied to a UE in RRC_connected mode sending drx-HARQ-RTT-TimerDLPTM regardless of the HARQ feedback transmission operation.

[0156] Figure 9 Multicast DRX operation of a UE in RRC inactive mode according to an embodiment of this disclosure is illustrated.

[0157] If gNB 910 determines that UE 900 does not need to maintain the RRC_connected state, gNB 910 can send an RRC release message to UE 900, thereby instructing UE 900 to switch to RRC_idle mode or RRC inactive mode. To enable UE 900 to continuously receive multicast, the MBS radio bearer used for multicast needs to be configured, and since the radio bearer is released in RRC_idle mode, the UE needs to switch to the RRC inactive mode. For this purpose, gNB 910 can include suspension configuration information in the RRC release message, thereby instructing UE 900 to switch to RRC inactive mode (non-RRC_idle mode) (920). Information such as the MBS radio bearer used for multicast, multicast session information, and multicast DRX can be configured in the RRC release message, enabling UE 900 to receive multicast data in RRC inactive mode. The start time, start time slot, and start symbol of drx-HARQ-RTT-TimerDLPTM used by UE 900 to receive multicast data in RRC inactive mode can be determined based on this. Based on the determination made according to the received information, UE 900 can receive multicast data in RRC inactive mode (930).

[0158] Therefore, gNB 910 can send an MCCH message to UE 900, including information on the MBS radio bearer for multicast, information on the multicast session, and at least one piece of information from the multicast DRX, to update multicast reception information (940) regarding UE 900 in RRC inactive mode. UE 900 can determine the start time point, start time slot, start symbol, etc., of drx-HARQ-RTT-TimerDLPTM for receiving multicast data in RRC inactive mode. Based on the determination made according to the received information, UE 900 can receive multicast data in RRC inactive mode (950).

[0159] Figure 10 The structure of a base station according to an embodiment of the present disclosure is shown.

[0160] refer to Figure 10The base station may include a transceiver 1010, a base station controller 1020, and a memory 1030. As used herein, the base station controller 1020 may be defined as a circuit, an application-specific integrated circuit (ASIC), or at least one processor. The transceiver 1010 can transmit / receive signals with other network entities. For example, the transceiver 1010 can transmit system information to the UE, transmit synchronization signals, reference signals, and configuration information to the UE, and receive uplink signals from the UE. The base station controller 1020 can control the overall operation of the base station according to the embodiments presented in this disclosure. For example, the base station controller 1020 can control the signal flow between various blocks to perform operations according to the flowchart described above. The memory 1030 may store at least one of the information transmitted / received by the transceiver 1010 and the information generated by the base station controller 1020.

[0161] Figure 11 The structure of a UE according to an embodiment of the present disclosure is shown.

[0162] Reference Figure 11 The UE may include a transceiver 1110, a UE controller 1120, and a memory 1130. As used herein, the UE controller 1120 may be defined as a circuit, an application-specific integrated circuit (ASIC), or at least one processor. The transceiver 1110 can transmit / receive signals with other network entities. For example, the transceiver 1110 can receive system information from a base station, receive synchronization signals, reference signals, and configuration information from the base station, and transmit uplink signals to the base station. The UE controller 1120 can control the overall operation of the UE according to the embodiments presented in this disclosure. For example, the UE controller 1120 can control the signal flow between various blocks to perform operations according to the flowchart described above. The memory 1130 may store at least one of the information transmitted / received by the transceiver 1110 and the information generated by the UE controller 1120.

[0163] The methods disclosed in the claims and / or the methods of the embodiments described in this disclosure may be implemented by hardware, software, or a combination of hardware and software.

[0164] When the method is implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). The one or more programs stored in the computer-readable storage medium may be configured to be executed by one or more processors within an electronic device. The at least one program includes instructions to cause the electronic device to perform a method according to various embodiments of the present disclosure as defined by the appended claims and / or disclosed herein.

[0165] These programs (software modules or software) can be stored in non-volatile memory, including random access memory and flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), disk storage devices, optical disc ROM (CD-ROM), digital versatile optical disc (DVD), or other types of optical storage devices or magnetic tape cartridges. Alternatively, any combination of some or all of these can form a memory storing programs. Furthermore, multiple such memories can be included in an electronic device.

[0166] Furthermore, the program can be stored in an attachable storage device that can be accessed by the electronic device via a communication network such as the Internet, intranet, local area network (LAN), wide area network (WLAN), and storage area network (SAN), or a combination thereof. Such a storage device can access the electronic device via an external port. Additionally, a separate storage device on the communication network can access portable electronic devices.

[0167] In the detailed embodiments described above, elements included in this disclosure are represented in a singular or plural form according to the presented embodiments. However, for ease of description, the singular or plural form is suitably chosen for the presented situation, and this disclosure is not limited to elements represented in a singular or plural form. Thus, an element represented in a plural form may also include a single element, or an element represented in a singular form may include multiple elements.

[0168] Although specific embodiments have been described in the detailed description of this disclosure, it will be apparent that various modifications and changes can be made thereto without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the embodiments set forth herein, but should be defined by the appended claims and their equivalents.

[0169] In addition, above Figures 1 to 9 The methods described herein may include methods that combine one or more drawings according to various embodiments. For example, Figures 1 to 9 The embodiments described herein can be combined to form a process flow (execution). Additionally, all or part of the embodiments can be combined with all or part of one or more other embodiments for execution. This disclosure may include methods in which one or more drawings are combined according to various implementations.

[0170] Although this disclosure has been described with reference to various embodiments, various changes and modifications may be suggested to those skilled in the art. This disclosure is intended to cover such changes and modifications that fall within the scope of the appended claims.

Claims

1. A method performed by a terminal in a wireless communication system, the method comprising: Receive a Radio Resource Control (RRC) release message from the base station, including a suspension configuration, wherein the suspension configuration includes a multicast and Broadcast Service (MBS) multicast configuration for the RRC inactive state; When the terminal is in the RRC inactive state, it receives multicast transmissions from the base station based on the MBS multicast configuration; and When the drx-HARQ-RTT-TimerDL-PTM for discontinuous reception of downlink point-to-multipoint hybrid automatic repeat request round-trip timer for downlink is included in the MBS multicast configuration for the RRC inactive state, the drx-HARQ-RTT-TimerDL-PTM is started after the multicast transmission ends.

2. The method according to claim 1, wherein, The drx-HARQ-RTT-TimerDL-PTM is activated in the first symbol after the multicast transmission ends.

3. The method according to claim 1, wherein, The drx-HARQ-RTT-TimerDL-PTM includes multiple symbols.

4. The method according to claim 1, further comprising: If the drx-HARQ-RTT-TimerDL-PTM expires and the multicast data is not successfully decoded, a discontinuous retransmission timer (drx-RetransmissionTimerDL-PTM) for downlink point-to-multipoint transmission is started. and When the terminal is in the RRC inactive state, it receives the retransmission of the multicast transmission from the base station.

5. A method performed by a base station in a wireless communication system, the method comprising: Send a Radio Resource Control (RRC) release message to the terminal, including a suspend configuration, wherein the suspend configuration includes a multicast and Broadcast Service (MBS) multicast configuration for RRC inactivity; and Send a multicast transmission based on the MBS multicast configuration to the terminal that is in the RRC inactive state. The downlink point-to-multipoint discontinuous reception hybrid automatic repeat request round-trip timer (drx-HARQ-RTT-TimerDL-PTM) included in the MBS multicast configuration is started after the multicast transmission ends.

6. The method according to claim 5, wherein, The drx-HARQ-RTT-TimerDL-PTM is activated in the first symbol after the multicast transmission ends, and The drx-HARQ-RTT-TimerDL-PTM includes multiple symbols.

7. The method according to claim 5, wherein, Based on the expiration of the drx-HARQ-RTT-TimerDL-PTM and the decoding failure of the multicast transmission data, the downlink point-to-multipoint discontinuous retransmission timer (drx-RetransmissionTimerDL-PTM) is started, and The method further includes sending a retransmission of the multicast transmission to the terminal that is in the RRC inactive state.

8. A terminal in a wireless communication system, the terminal comprising: transceiver; and The controller, coupled to the transceiver, is configured to: Receive a Radio Resource Control (RRC) release message from the base station, including a suspension configuration, wherein the suspension configuration includes a multicast and Broadcast Service (MBS) multicast configuration for the RRC inactive state. When the terminal is in the RRC inactive state, it receives multicast transmissions from the base station based on the MBS multicast configuration, and When the drx-HARQ-RTT-TimerDL-PTM for discontinuous reception of downlink point-to-multipoint hybrid automatic repeat request round-trip timer for downlink is included in the MBS multicast configuration for the RRC inactive state, the drx-HARQ-RTT-TimerDL-PTM is started after the multicast transmission ends.

9. The terminal according to claim 8, wherein, The drx-HARQ-RTT-TimerDL-PTM is activated in the first symbol after the multicast transmission ends.

10. The terminal according to claim 8, wherein, The drx-HARQ-RTT-TimerDL-PTM includes multiple symbols.

11. The terminal according to claim 8, wherein, The controller is also configured to: If the drx-HARQ-RTT-TimerDL-PTM expires and the multicast data is not successfully decoded, a discontinuous retransmission timer (drx-RetransmissionTimerDL-PTM) for downlink point-to-multipoint transmission is started, and When the terminal is in the RRC inactive state, it receives the retransmission of the multicast transmission from the base station.

12. A base station in a wireless communication system, the base station comprising: transceiver; and The controller, coupled to the transceiver, is configured to: Send a Radio Resource Control (RRC) release message to the terminal, including a suspend configuration, wherein the suspend configuration includes a multicast and Broadcast Service (MBS) multicast configuration for the RRC inactive state, and Send a multicast transmission based on the MBS multicast configuration to the terminal that is in the RRC inactive state. The downlink point-to-multipoint discontinuous reception hybrid automatic repeat request round-trip timer (drx-HARQ-RTT-TimerDL-PTM) included in the MBS multicast configuration is started after the multicast transmission ends.

13. The base station according to claim 12, wherein, The drx-HARQ-RTT-TimerDL-PTM is activated in the first symbol after the multicast transmission ends.

14. The base station according to claim 12, wherein, The drx-HARQ-RTT-TimerDL-PTM includes multiple symbols.

15. The base station according to claim 12, wherein, Based on the expiration of the drx-HARQ-RTT-TimerDL-PTM and the decoding failure of the multicast transmission data, the downlink point-to-multipoint discontinuous retransmission timer (drx-RetransmissionTimerDL-PTM) is started, and The controller is also configured to send a retransmission of the multicast transmission to the terminal that is in the RRC inactive state.

Images