Method and apparatus for improving mbs dtx mechanism
By improving the HARQ RTT timer and ACK/NACK feedback mechanism and optimizing the DRX mechanism, the problems of resource allocation and energy consumption management in the 5G MBS system were solved, and more efficient UE multicast support and broadcast unicast resource sharing optimization were achieved.
Patent Information
- Application Number
- CN202280086187.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-01-10
- Publication Date
- 2025-11-21
- Estimated Expiration
- 2042-01-10
AI Technical Summary
The existing 5G MBS mechanism suffers from inefficiency and energy consumption problems in resource allocation and UE energy management, especially in terms of insufficient UE multicast support in RRC_INACTIVE state, and the resource sharing between broadcast and unicast services is not optimized.
By improving the setting method of HARQ RTT timer, combining the ACK/NACK feedback mechanism and the PDCCH/C-RNTI monitoring mechanism, the DRX mechanism is optimized to support flexible switching between PTM and PTP transmission modes, thereby achieving flexibility in UE-specific PDCCH/C-RNTI monitoring and HARQ feedback configuration.
It improves the resource utilization efficiency of the MBS system, reduces the power consumption of terminal devices, supports UE multicast in RRC_INACTIVE state, and optimizes resource sharing between broadcast and unicast services.
Smart Images

Figure CN118451782B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present invention relates to wireless communications, and more specifically, to multicast and broadcast services (MBS) systems. BACKGROUND
[0002] Multicast and broadcast communications require resource-efficient transmission to multiple end users receiving the same content. Due to this obvious advantage, in 5G Release 17 (Rel-17), 3GPP started building functional support for MBS on top of the existing 5G standard framework.
[0003] MBS aims to enable various services, including public safety and mission critical, vehicle-to-everything (V2X) applications, transparent IPV4 / IPV6 multicast transmission, IPTV, wireless software delivery, group communication, and Internet of Things applications. Service requirements for different use cases of MBS vary in terms of reliability, latency, QOS handling, service area coverage, service continuity, and security. Therefore, it is of utmost importance to establish a comprehensive mechanism for MBS to meet these different requirements.
[0004] In REL-17, two delivery modes for MBS have been agreed, delivery mode 1 (only for groupcast) is able to address higher QOS services, while delivery mode 2 (only for broadcast) focuses on lower QOS services.
[0005] In REL-17, the radio access network (RAN) only specifies groupcast for user equipment (UE) in RRC_CONNECTED state, but this does not fully meet the requirements of mission critical services, especially for cells with a large number of UEs according to TR 23.774. In addition, it is not energy efficient to always keep UEs in RRC_CONNECTED state. When no multicast data is expected to arrive, a multicast session can be deactivated, and UEs belonging to the multicast group can then transition to RRC_INACTIVE or IDLE state. These UEs must re-enter RRC_CONNECTED state when the multicast session is about to be reactivated. Therefore, it is very important to support groupcast for UEs in RRC_INACTIVE state.
[0006] From the RAN perspective, in the case of shared delivery, there are two delivery methods available for transmitting MBS packet flows over the air:
[0007] • Point-to-point (PTP) delivery method: the RAN node delivers individual copies of MBS packets to individual UEs over the air.
[0008] • Point-to-multipoint (POINT-TO-MULTIPOInt, PTM) transmission method: the RAN node transmits a single copy of the MBS data packet to a group of UEs over the air.
[0009] The RAN node can use a combination of PTP / PTM to transmit MBS data packets to UEs. In addition, if the users at the edge of the cell with poor channel quality need reliable transmission, the PTM (point-to-multipoint) transmission can be switched to the PTP (point-to-point) leg.
[0010] In REL-17, the NR MBS broadcast solution allows UEs to receive broadcast services only in downlink mode, i.e., to perform broadcast reception without prior access to the network. However, in traditional use cases of broadcasting, UEs can simultaneously receive broadcast services and unicast services from the network of the same operator or other operators, and certain UEs can share hardware resources between broadcast and unicast. Therefore, the unicast connection can be affected by the broadcast reception of such UEs. However, REL-17 is not optimized for this case.
[0011] Since REL-17 MBS has already provided basic functions to support MBS services, the main goal of REL-18 should be to enable better deployment of MBS, for example, to further improve resource efficiency and capacity based on the provisions of REL-17 MBS.
[0012] Therefore, there is a need for systems and methods to improve MBS mechanisms.
[0013] Technical problem
[0014] The following summary is provided for illustrative purposes only and is not limiting in any way. That is, the following summary is provided to introduce a few concepts, highlights, advantages, and advantages of the novel and advanced technologies described herein. Selected embodiments are further described in the detailed description below. Therefore, the following summary is not intended to determine the essential characteristics of the claimed subject matter, nor is it intended to determine the scope of the claimed subject matter.
[0015] The present invention aims to study a method for improving the MBS DRX mechanism in the next generation wireless communication network.
[0016] According to one aspect of the present invention, a method of setting a HARQ RTT timer is provided. The method includes transmitting a HARQ-ACK feedback based on UE-specific ACK / NACK.
[0017] In one embodiment, the GNB decides and instructs the UE to start the HARQ RTT timer at the end of the GC-PDCCH / GC-PDSCH reception.
[0018] In another embodiment, the UE decides to start the HARQ RTT timer when the GC-PDCCH / GC-PDSCH reception ends.
[0019] In another embodiment, the GNB instructs the UE to start a HARQ RTT timer at the end of GC-PDCCH / GC-PDSCH reception under certain conditions, and the UE still triggers the HARQ RTT timer after a NACK transmission based on UE-specific PUCCH resources.
[0020] According to another aspect of the present invention, a method for monitoring a UE-specific PDCCH / C-RNTI is provided. If the retransmission is PTP, the UE-specific PDCCH / C-RNTI is monitored while the DRX-ONDURATIONTIMERPTM parameter, DRX-INACTIVITYTIMERPTM parameter, or DRX-RETRANSMISSIONTIMERDLPTM parameter is running.
[0021] The abstract of the application does not necessarily disclose all the features necessary to define the invention; the invention may exist in sub-combinations of the disclosed features. Attached Figure Description
[0022] Figure 1 An example of a long DRX cycle for PTM is shown.
[0023] Figure 2 An embodiment of the disclosed method for UE-specific PDCCH / C-RNTI monitoring is illustrated.
[0024] Figure 3 This illustration depicts another embodiment of the publicly disclosed UE monitoring UE-specific PDCCH / C-RNTI method.
[0025] Figure 4 A schematic diagram illustrating the disclosed method for instructing a UE to start a HARQ RTT timer for GNB is shown.
[0026] Figure 5 A schematic diagram (without GNB indication) illustrates an embodiment of the disclosed method for a UE to initiate a HARQ RTT timer.
[0027] Figure 6 A schematic diagram illustrating an embodiment of the disclosed method for starting a HARQ RTT timer for a GNB or UE is shown.
[0028] Figure 7 Draw a schematic diagram of the communication system. Detailed Implementation
[0029] The present invention relates to improvements in MBS mechanisms. The following description is presented to enable one of ordinary skill in the art to make and use the invention as provided in the context of a particular application and its requirements. Various modifications to the preferred embodiment will be apparent to those with skill in the art, and the general principles defined herein can be applied to other embodiments. Therefore, the present invention is not intended to be limited to the particular
[0030] The following description is of preferred embodiments only and is not intended to limit the application to the features as presented in the application.
[0031] In 5G system applications, reducing the power consumption of the terminal is a great challenge. Like LTE, NR also supports DRX (Discontinuous Reception) as a technical function for UE power saving.
[0032] To save power, the concept of discontinuous reception (DRX) is introduced. DRX can be used to enable a wireless device (e.g., user equipment) to monitor a control channel (e.g., a physical downlink control channel (PDCCH)) discontinuously, which is used to communicate with a base station (e.g., a next generation node B (GNB)). Because the receiver on the UE can be turned off, discontinuous reception can save a significant amount of power consumption on the UE.
[0033] Similar to LTE, there are two states for discontinuous reception (DRX) in 5G, i.e., RRC_IDLE / RRC_INACTIVE state and RRC_CONNECTED state. In the RRC_IDLE / RRC_INACTIVE state, the UE will periodically wake up to monitor the paging message, and if the paging message is not suitable, it will return to sleep mode.
[0034] DRX in 5G allows the UE to periodically enter a "sleep" state (idle / inactive duration) during which it does not need to monitor the PDCCH, thus improving UE battery power consumption. To monitor the PDCCH for possible downlink / uplink data, the UE is allowed to periodically wake up and remain "awake" (connected duration) for a certain time, and then enter the "sleep" state again. In addition, the UE can need to wake up occasionally to monitor the PDCCH, which is to receive possible retransmissions.
[0035] In one embodiment, the UE can communicate with the GNB to negotiate a period of time during which the UE can receive communications from the GNB. During the negotiated period of time in which no information is received, the UE can turn off its receiver and enter a low power state or enter a sleep state. These sleep states can last for a millisecond to hundreds of milliseconds or more. The duration and time of the sleep state can be negotiated between the UE and the GNB.
[0036] RRC signaling can be used to manage DRX usage by setting various parameters. The following table illustrates examples of parameters that can be set in the RRC_CONNECTED state.
[0037]
[0038] Figure 1 This example illustrates a long DRX cycle for the PTM. In this example, the long DRX cycle parameters are shown relative to DRX-ONDURATIONTIMERPTM, the overlapping DRX-INACTIVITYTIMERPTM, DRX-HARQ-RTT-TIMERPTM, and DRX-RETRANSMISSIONTIMERPTM. DRX-HARQ-RTT-TIMERPTM is initiated after the PDCCH decoding delay.
[0039] During each DRX cycle, the RF modem can open multiple consecutive subframes set by the ON DURATION TIMER to listen for the control channel.
[0040] The inactivity timer can be specified for a continuous number of transmission time intervals (TTI). During this period, the UE monitors the PDCCH after successfully decoding it, indicating uplink or downlink data transmission. During data transmission, the inactivity timer can keep the UE awake for a period of time, even after the ON-DURATION TIMER has expired. In the downlink, the inactivity timer typically triggers during the ON-DURATION period. If the ON-DURATION duration is long, the inactivity timer may start and expire during the wake-up period. The inactivity timer can only be triggered for new transmissions in the uplink and downlink, not for retransmissions.
[0041] Another function of DRX relates to power saving during HARQ retransmissions. For example, when the UE is unable to decode a transport block of a HARQ active process, the UE assumes that the next retransmission will occur after the DRX retransmission timer. This allows the UE to enter a power-saving state without listening to the PDCCH. The HARQ round-trip time (RTT) timer can be started 1ms after the PDCCH (for decoding delay) to indicate downlink shared channel (PDSCH) transmission. The HARQ RTT timer can be started for each downlink shared channel transmission.
[0042] Please note how the HARQ retransmission mechanism affects the DRX mechanism. Figure 1There is one HARQ RTT timer and one DRX retransmission timer. The HARQ RTT timer indicates when the HARQ retransmission arrives earliest. When a HARQ decoding error occurs, this usually affects the transmission process, so the HARQ RTT timer is started. HARQ retransmission only starts after the HARQ RTT timer expires, which means that the DRX mechanism can continue during the HARQ RTT. The DRX-RETRANSMISSION timer is started after the HARQ RTT timer expires. After starting, the DRX mechanism will pause and wait for retransmission. The DRX mechanism will return after the retransmission time expires. This is a mechanism designed for retransmission.
[0043] The UE will turn off the receiver only when neither the DRX-INACTIVITYTIMER PTM nor the DRX-RETRANSMISSIONTIMER DLPTM is active. That is, even if the DRX-INACTIVITYTIMER PTM expires, but the DRX-RETRANSMISSIONTIMER DLPTM is still running, the receiver still needs to be turned on to wait for the HARQ retransmission mechanism.
[0044] Supporting HARQ-ACK feedback and HARQ retransmission can achieve high reliability for groupcast mode. GNB needs HARQ-ACK feedback to know the reception status of UE and perform retransmission. But when there are multiple UEs for groupcast session, the feedback resource in PUCCH can be overloaded. In addition, one of the UEs can fail to receive when the reception retransmission condition is met. Based on these factors, the configuration flexibility of HARQ-ACK feedback options is as follows:
[0045] ACK / NACK-based HARQ-ACK feedback: UE feedbacks ACK or NACK through UE-specific PUCCH resource. This mechanism is very effective when the number of UEs receiving groupcast data is small.
[0046] NACK-only based HARQ-ACK feedback: UE only feedbacks NACK for common PUCCH resource shared with other UEs in the same group. This mechanism is resource-efficient, but GNB cannot detect the case where UE cannot decode PDCCH information.
[0047] No HARQ-ACK feedback: UE will not send any feedback for received data. GNB can use this option to save PUCCH resource when the QOS requirement of UE groupcast data is low. GNB can dynamically switch between ACK / NACK-based HARQ-ACK feedback and no HARQ-ACK feedback through RRC signaling or downlink control information (DCI).
[0048] After the initial transmission of PTM type to multiple UEs, the HARQ retransmission has further flexibility that either PTM type or PTP type retransmission can be used. The PTM type retransmission is the typical retransmission to the same receivers of the initial transmission using a shared G-RNTI (Group RNTI, RNTI stands for Radio Network Temporary Identifier). In contrast, the PTP type retransmission is a dedicated retransmission to a single UE using the UE's C-RNTI (Cell RNTI). This PTP type of retransmission would be beneficial when the best resource configuration (such as Modulation and Coding Scheme (MCS)) is available for the retransmission.
[0049] There is one issue to be solved: how the UE monitors the UE-specific PDCCH / C-RNTI for PTP transmission of PTM HARQ retransmission in the active time of groupcast DRX.
[0050] If the DRX is configured for PTM as Figure 1 , the UEs in the same group will monitor the G-RNTI according to the pattern in Figure 1 in case the retransmission is PTM. How the UE monitors the UE-specific PDCCH / C-RNTI if the retransmission is PTP is introduced as follows.
[0051] In one embodiment, the UE monitors the UE-specific PDCCH / C-RNTI when the DRX-ON DURATION TIMER PTM or the DRX-INACTIVITY TIMER PTM or the DRX-RETRANSMISSION TIMER DL PTM is running, as shown in Figure 2 .
[0052] In another embodiment, the UE monitors the UE-specific PDCCH / C-RNTI only when the DRX-RETRANSMISSION TIMER DL PTM is running, as shown in Figure 3 . For example, when the DRX-ON DURATION TIMER PTM and the DRX-INACTIVITY TIMER PTM are running, but the DRX-RETRANSMISSION TIMER DL PTM is not running, the UE does not monitor the UE-specific PDCCH / C-RNTI.
[0053] In another embodiment, the UE monitors the UE-specific PDCCH / C-RNTI only in the active time of unicast DRX. The RTT timer of unicast DRX can be started when the PTP retransmission is expected.
[0054] How to set the HARQ RTT timer will be discussed below. There are two cases: (1) ACK / NACK based HARQ-ACK feedback; (2) NACK only based HARQ-ACK feedback.
[0055] (1) UE-specific ACK / NACK based HARQ-ACK feedback
[0056] In this case, there are 3 methods to set the HARQ RTT timer.
[0057] (I) GNB decides and indicates the UE to start the HARQ RTT timer at the end of GC-PDCCH / GC-PDSCH reception.
[0058] The first method is to let the GNB decide whether the UE should start the HARQ RTT timer at the end of GC-PDCCH / GC-PDSCH. For example, there are 3 UEs in a common group (GROUP COMMON, GC). If 1, 2 or all 3 UEs fail to decode the GC-PDCCH / GC-PDSCH, the GNB can decide whether the UE should start the HARQ RTT timer. Figure 4 A schematic diagram of the method of the GNB for indicating the UE to start the HARQ RTT timer is shown in FIG. 1. In addition, the GNB can decide and indicate all UEs to start the HARQ RTT timer, or decide and indicate a certain UE or several specific UEs to start the HARQ RTT timer, but the present application is not limited thereto.
[0059] (II) UE decides to start the HARQ RTT timer at the end of GC-PDCCH / GC-PDSCH reception.
[0060] The second method is for the UE to decide whether it should start the HARQ RTT timer according to whether it successfully decodes the GC-PDCCH / GC-PDSCH, and the GNB does not make a decision. For example, there are 3 UEs in a GC group, and UEs 1 and 2 successfully decode the GC-PDCCH / GC-PDSCH, but UE 3 fails to decode. If the UE is configured to transmit HARQ feedback through a UE-specific PUCCH resource, UEs 1 and 2 will send ACK, and UE 3 will send NACK, while UE 3 will start the HARQ RTT timer. The GNB is informed that UE 3 failed to decode the GC-PDCCH / GC-PDSCH, so the GNB will retransmit the lost data packet. All 3 UEs will receive the retransmitted data packet. UEs 1 and 2 know that this is a retransmitted data packet through the new data indicator (NEW DATA INDICATOR, NDI), and they will discard this data packet, while UE 3 will perform HARQ soft combining after receiving the retransmitted data packet. Figure 5Figure illustrating the method of the embodiment of the application for UE to start HARQ RTT timer by itself (without GNB indication).
[0061] (III) GNB indicates UE to start HARQ RTT timer at the end of GC-PDCCH / GC-PDSCH reception under certain conditions, and UE still triggers HARQ RTT timer after NACK transmission based on UE specific PUCCH resource.
[0062] The third way is a combination of the first and second ways. In some conditions, GNB decides to start HARQ RTT timer, and in other conditions, UE decides to start HARQ RTT timer by itself. For example, the condition can be the number of UEs in the group. When the number of UEs in the group exceeds a threshold, GNB decides to start HARQ RTT timer, and when the number of UEs in the group is less than the threshold, UE can decide to start HARQ RTT timer by itself. In another embodiment, the condition can also be the number of UEs in the group reporting NACK. It should be noted that the above conditions are for reference only. This application is not limited to the examples. Figure 6 Figure illustrating the method of the embodiment of the application for GNB or UE to start HARQ RTT timer.
[0063] As for how to calculate HARQ RTT timer, HARQ RTT timer can start counting from the start of groupcast GC-PDCCH / GC-PDSCH reception, or start counting from the reception of the indication from GNB.
[0064] (2) Only for NACK-based HARQ-ACK feedback
[0065] For common group PTM groupcast HARQ PUCCH resource (only NACK feedback), the same group of UEs has consistent HARQ RTT and DL retransmission timer configuration. HARQ RTT timer starts counting from the end of NACK transmission based on common PUCCH resource (i.e. the same as unicast DRX behavior).
[0066] In this case, the network cannot know which UEs reported NACK and need retransmission. Therefore, in this case, only PTM retransmission is supported, and PTP retransmission is not supported.
[0067] Reference Figure 4 Figure illustrating a communication system implementing the method of the embodiment of the application. The communication system includes UE 10 and GNB 20. Figure 4The illustrated is non-limiting, the system can include more UEs and GNBS. Connections between devices and device components are shown as lines and arrows in the figures. The UE 10 can include a processor 11, a memory 12, and a transceiver 13. The GNB 20 can include a processor 21, a memory 22, and a transceiver 23. Each of the processors 11, 21 can be configured to implement the proposed functions, procedures, and / or methods described in this description. Radio interface protocol layers can be implemented in the processors 11, 21. Each memory 12, 22 is operable to store various programs and information for operating the connected processor. Each transceiver 13, 23 is operably coupled with the connected processor for transmitting and / or receiving radio signals. The GNB 20 can be one of an ENB, a GNB, or other radio node.
[0068] Each processor 11, 21 can include a general-purpose central processing unit (CPU), an application-specific integrated circuit (ASIC), other chip sets, logic circuits, and / or a data processing device. Each memory 12, 22 can include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media and / or other storage devices. Each transceiver 13, 23 can include baseband circuitry and radio frequency (RF) circuitry to process radio frequency signals. When the embodiments are implemented in software, the techniques described herein can be implemented with modules, procedures, functions, entities, etc. that perform the techniques described herein. These modules can be stored in memory and executed by a processor. The memory can be implemented within the processor or external to the processor, in which case those can be communicatively coupled to the processor by various means known in the art.
[0069] The background section of this patent document can include background information not constituting the prior art. Thus, the inclusion of material in the background section is not an admission that the prior art is prior art.
[0070] Reference in the specification to "one embodiment" or "an alternative" means that a particular feature, structure, or characteristic described is included in at least one embodiment of the application. The appearance of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are they necessarily referring to a single alternative embodiment. Furthermore, the described features, advantages, characteristics, etc. can be combined in any suitable manner in one or more embodiments.
[0071] While the application has been described in connection with what is presently considered to be the most practical and preferred embodiments, it is to be understood that the application is not to be limited to the disclosed embodiments, but on the contrary, is intended to cover various arrangements included within the spirit and scope of the appended claims, which are to be accorded the broadest interpretation so as to encompass all equivalent combinations.
Claims
1. A method for setting a HARQ RTT timer, which can be executed in a base station gNB, comprising: Receive HARQ-ACK feedback based on UE-specific ACK / NACK; When the number of UEs reporting NACK in the group exceeds a threshold, the UE is instructed to start the HARQ RTT timer. The HARQ RTT timer starts counting from the group shared physical downlink control channel GC-PDCCH / group shared physical downlink shared channel GC-PDSCH received from the multicast of the group. When the number of UEs reporting NACK does not exceed the threshold, the system does not instruct the UE to start the HARQ RTT timer, allowing the UE to decide for itself whether to start the HARQ RTT timer.
2. A base station gNB, comprising: A processor configured to invoke and run a computer program stored in memory to cause a device with a chip mounted to perform the method of claim 1.
3. A chip, comprising: A processor configured to invoke and run a computer program stored in memory to cause a device with a chip mounted to perform the method of claim 1.
4. A computer-readable storage medium storing a computer program, wherein the computer program causes a computer to perform the method of claim 1.
5. A computer program product comprising a computer program, wherein the computer program causes a computer to perform the method of claim 1.