HARQ process / entity-based uplink multiplexing
Simultaneous synchronous and asynchronous HARQ operations with dedicated resources and signaling optimize uplink transmission scheduling for diverse services, addressing latency and complexity issues in wireless communication systems.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2024-11-06
- Publication Date
- 2026-03-25
AI Technical Summary
Existing wireless communication systems face challenges in efficiently managing uplink transmission scheduling and HARQ processes, particularly for low-latency services like URLLC, due to increased complexity and latency introduced by conventional HARQ mechanisms.
Implementing simultaneous synchronous and asynchronous HARQ operations using multiple HARQ entities, each tailored for different service types, with dedicated resources and signaling to optimize latency and reliability for various services.
This approach enhances the efficiency and reliability of uplink transmissions by reducing latency and complexity, particularly for critical services, while maintaining flexibility for non-critical services, thereby improving overall system performance.
Smart Images

Figure 0007835260000001 
Figure 0007835260000002 
Figure 0007835260000003
Abstract
Description
Technical Field
[0001] The present invention relates to the field of mobile communication systems, and more particularly to techniques for checking or verifying whether information transmitted by a transmitter is correctly received by a receiver and initiating retransmission if the transmission of the information fails. Embodiments relate to the operation of Hybrid Automatic Repeat reQuest (HARQ) in network entities of a wireless communication system, such as a base station or a user equipment (UE). Some embodiments relate to HARQ process / entity-based uplink multiplexing.
Background Art
[0002] FIG. 1 is a schematic representation of an example of a terrestrial wireless network 100 including a core network 102 and one or more radio access networks RAN1, RAN2, … RAN N as shown in FIG. 1(a). FIG. 1(b) shows a radio access network RAN that may include one or more base stations gNB1 to gNB5, each serving a respective area surrounding the base stations schematically represented by cells 1061 to 1065. nThis is a schematic representation of an example. A base station is provided to serve users within a cell. One or more base stations may serve users on licensed and / or unlicensed bands. The term base station BS refers to gNB in 5G networks, eNB in UMTS / LTE / LTE-A / LTE-A Pro, or simply BS in other mobile communication standards. Users may be fixed devices or mobile devices. The wireless communication system may also be accessed by mobile or fixed IoT devices that connect to base stations or users. Mobile devices or IoT devices may include physical devices, ground-based vehicles such as robots or automobiles, aircraft such as manned or unmanned aircraft (UAVs), the latter also called drones, buildings, and electronics, software, sensors, actuators, etc., and other items or devices with embedded network connectivity that enable these devices to collect and exchange data across existing network infrastructure. Figure 1(b) shows an illustrative diagram of five cells, but RAN n This may include more or fewer such cells, and also, RAN nThis may include only one base station. Figure 1(b) shows two user UEs, UE1 and UE2, also called user equipment, located in cell 1062 and serviced by base station gNB2. Another user UE3 is shown in cell 1064, serviced by base station gNB4. Arrows 1081, 1082, and 1083 schematically represent uplink / downlink connections for transmitting data from user UE1, UE2, and UE3 to base stations gNB2, gNB4, or from base stations gNB2, gNB4 to user UE1, UE2, and UE3. This can be implemented on licensed or unlicensed band. Furthermore, Figure 1(b) shows two IoT devices 1101 and 1102 in cell 1064, which may be fixed or mobile devices. IoT device 1101 accesses the wireless communication system via base station gNB4 to send and receive data, as schematically represented by arrow 1121. The IoT device 1102 accesses the wireless communication system via the user UE3, as schematically represented by arrow 1122. Each base station gNB1-gNB5 may be connected to the core network 102 via their respective backhaul links 1141-1145, for example via the S1 interface, as schematically represented in Figure 1(b) by arrows pointing to “core”. The core network 102 may be connected to one or more external networks. Furthermore, some or all of the base stations gNB1-gNB5 may be connected to each other via their respective backhaul links 1161-1165, for example via the S1 or X2 or XN interface within the NR, as schematically represented in Figure 1(b) by arrows pointing to “gNB”. Sidelink channels enable direct communication between UEs, also known as device-to-device (D2D) communication. The sidelink interface in 3GPP® is named PC5.
[0003] A physical resource grid may be used for data transmission. The physical resource grid may include a set of resource elements to which various physical channels and physical signals are mapped. For example, physical channels may include physical downlink, uplink, and sidelink shared channels (PDSCH, PUSCH, PSSCH) that carry user-specific data, also known as downlink, uplink, and sidelink payload data; physical broadcast channels (PBCH) that carry one or more of the Master Information Block (MIB) and System Information Block (SIB); and physical downlink, uplink, and sidelink control channels (PDCCH, PUCCH, PSSCH) that carry downlink control information (DCI), uplink control information (UCI), and sidelink control information (SCI). It should be noted that the sidelink interface may support a two-stage SCI, which refers to a first control region containing several parts of the SCI, and optionally a second control region containing a second part of the control information.
[0004] In the case of an uplink, the physical channel may further include a physical random access channel (PRACH or RACH) used by the UE to access the network once the UE has synchronously acquired the MIB and SIB. The physical signals may include a reference signal or symbol (RS), a synchronization signal, etc. The resource grid may include a frame or radio frame having a specific duration in the time domain and a given bandwidth in the frequency domain. A frame may have a number of subframes of a predefined length, such as 1 ms. Each subframe may contain one or more slots of 12 or 14 OFDM symbols, depending on the cyclic prefix (CP) length. A frame may also consist of fewer OFDM symbols, for example, when utilizing a shortened transmit time interval (sTTI) or a minislot / non-slot-based frame structure containing only a few OFDM symbols.
[0005] The wireless communication system may be any single-tone or multi-carrier system using frequency division multiplexing, such as an orthogonal frequency division multiplexing (OFDM) system, an orthogonal frequency division multiplexing (OFDMA) system, or any other IFFT-based signal with or without CP, such as DFT-s-OFDM. Other waveforms may be used, such as non-orthogonal waveforms for multiple access, such as filter bank multicarrier (FBMC), general-purpose frequency division multiplexing (GFDM), or universal filter multicarrier (UFMC). The wireless communication system may operate according to, for example, the LTE-Advanced Pro standard, or the 5G or NR, New Radio standard, or the NR-U, New Radio Unlicensed standard.
[0006] The wireless network or communication system shown in Figure 1 may be a heterogeneous network having separate overlaid networks, such as a network of macrocells where each macrocell includes macro base stations such as base stations gNB1 to gNB5, and a network of small cell base stations such as femto or pico base stations (not shown in Figure 1).
[0007] In addition to the terrestrial wireless networks described above, there are also non-terrestrial wireless communication networks (NTNs) that include space transport transceivers such as satellites and / or air transport transceivers such as unmanned aerial vehicle systems. Non-terrestrial wireless communication networks or systems may operate in a similar manner to the terrestrial systems described above, with reference to Figure 1, for example, according to the LTE-Advanced Pro standard or 5G or NR nu-radio standard.
[0008] In a mobile communication network, such as an LTE or 5G / NR network, as described above with reference to Figure 1, there may be UEs that communicate directly with each other via one or more sidelink (SL) channels, for example, using the PC5 interface. UEs that communicate directly with each other via sidelinks may include vehicles communicating directly with other vehicles (V2V communication), and vehicles communicating with other entities in the wireless communication network, such as roadside entities like traffic lights, signals, or pedestrians (V2X communication). Other UEs do not have to be vehicle-related UEs and may include any of the devices described above. Such devices may communicate directly with each other (D2D communication) using SL channels.
[0009] Considering two UEs communicating directly with each other via a sidelink, both UEs may be serviced by the same base station, i.e., both UEs may be within the base station's coverage area, as in one of the base stations shown in Figure 1. This is called the “in-coverage” scenario. In another example, both UEs communicating via a sidelink may not be serviced by the base station, in what is called the “out-of-coverage” scenario. Note that “out-of-coverage” does not mean that the two UEs are not in one of the cells shown in Figure 1, but rather that these UEs are not connected to a base station, for example, not in an RRC connection state. Yet another scenario is called the “partial coverage” scenario, in which one of the two UEs communicating with each other via a sidelink is serviced by the base station, while the other UE is not.
[0010] Figure 2 is a schematic representation of a situation where two UEs communicating directly with each other are both within the coverage of a base station. The base station gNB has a coverage area schematically represented by circle 140, which essentially corresponds to the cells schematically represented in Figure 1. The UEs communicating directly with each other both include a first vehicle 142 and a second vehicle 144 within the coverage area 140 of the base station gNB. Both vehicles 140 and 142 are connected to the base station gNB and, in addition, are directly connected to each other via the PC5 interface. V2V traffic scheduling and / or interference management are assisted by the gNB via control signaling through the Uu interface, which is the radio interface between the base station and the UEs. The gNB allocates resources to be used for V2V communication via sidelinks. This configuration is also called a Mode 3 configuration.
[0011] Figure 3 is a schematic representation of a situation where the UEs are not within the base station's coverage; that is, each UE communicating directly with one another may physically exist within a cell of the wireless communication network but not be connected to a base station. Three vehicles 152, 154, and 156 are shown communicating directly with each other via sidelinks, for example, using the PC5 interface. V2V traffic scheduling and / or interference management are based on algorithms implemented between the vehicles. This configuration is also called a Mode 4 configuration. As mentioned above, the out-of-coverage scenario in Figure 3 does not mean that each Mode 4 UE is outside the base station's coverage 140, but rather that each Mode 4 UE is not serviced by a base station or is not connected to a base station in the coverage area. Therefore, within the coverage area 140 shown in Figure 2, there may be a situation where, in addition to the Mode 3 UEs 142 and 144, there are also Mode 4 UEs 152, 154, and 156.
[0012] It should be noted that the information in the above sections is intended solely to enhance the understanding of the background of the present invention and therefore may contain information that does not constitute prior art already known to those skilled in the art. [Prior art documents] [Non-patent literature]
[0013] [Non-Patent Document 1] TS 38.321, sections 5.3.2 and 5.4.2 [Non-Patent Document 2] NR Rel.15 TS38.331 [Overview of the project] [Problems that the invention aims to solve]
[0014] Starting with the conventional technologies described above, improvements or enhancements to uplink transmission scheduling may be necessary. [Means for solving the problem]
[0015] Next, embodiments of the present invention will be described in more detail with reference to the accompanying drawings. [Brief explanation of the drawing]
[0016] [Figure 1(a)] This is a schematic representation of an example of a wireless communication system. [Figure 1(b)] This is a schematic representation of an example of a wireless communication system. [Figure 2] This is a general description of a situation where two UEs communicating directly with each other are within the base station's coverage area. [Figure 3] This diagram illustrates a scenario where UEs communicating directly with each other are not within the base station's coverage, i.e., not connected to the base station. [Figure 4] This is a diagram showing the base station protocol stack. [Figure 5] This diagram provides a simplified representation of a conventional HARQ mechanism, which can also be derived from TS 38.321, sections 5.3.2 and 5.4.2, which describe HARQ operations and entities. [Figure 6]A diagram showing an 8-channel stop-and-wait HARQ protocol in which additional data packets are transmitted during a time period that can be the minimum time until a retransmission can be sent due to an ACK / NACK omission or a received NACK. [Figure 7] A diagram showing an embodiment of a layer structure for implementing synchronous and asynchronous HARQ operations in a base station or user equipment using a common MAC entity in the MAC layer. [Figure 8] A diagram showing a further embodiment of a layer structure for implementing synchronous and asynchronous HARQ operations in a base station or user equipment using separate MAC entities in the MAC layer. [Figure 9] A diagram showing details of a UE such as the UE described above while referring to FIG. 11, including an antenna ANTR, a signal processor 302a, and a transceiver 302b. [Figure 10] A diagram showing the above concept of using LL-PUCCH for feedback in the case of synchronous HARQ and multiplexing the feedback on a normal PUCCH in the case of asynchronous HARQ. [Figure 11] A diagram showing an 8-channel stop-and-wait HARQ protocol in which some of the HARQ processes are configured not to provide ACK / NACK feedback. [Figure 17] This is a schematic representation of a wireless communication system for communicating information between a transmitter and one or more receivers, according to an embodiment of the present invention. [Figure 18] This figure shows the VoIP transmission time interval (subframe) in a predefined resource block, where the UE's resources have a predefined format and a predefined period, and are pre-configured by the base station (e.g., gNB) on the uplink. [Figure 19] This figure shows an example of a computer system in which a unit or module may be executed, along with the steps of a method described according to the approach of the present invention. [Modes for carrying out the invention]
[0017] Next, embodiments of the present invention will be described in more detail with reference to the accompanying drawings, in which identical or similar elements are assigned the same reference numerals.
[0018] In the wireless communication system described above with reference to Figure 1, the UE and / or base station are configured to operate based on the communication protocol defined by their respective protocol stacks, such as in an LTE system or a 5G / NR system. For illustrative purposes, the base station protocol stack 120 will be described with reference to Figure 4.
[0019] As shown in Figure 4, the base station protocol stack 120 includes a control plane protocol stack 130 and a user plane protocol stack 132, which include a first layer 122, a second layer 124, and a third layer 126, respectively.
[0020] The first layer 122 of both the control plane protocol stack 130 and the user plane protocol stack 132 includes the PHY physical layer. The second layer 124 of both the control plane protocol stack 130 and the user plane protocol stack 132 includes MAC, media access control, (sub)layer, RLC, radio link control, (sub)layer, PDCP, packet data convergence protocol, (sub)layer, and SDAP, and the second layer 124 of the user plane protocol stack 132 further includes SDAP, service data adaptive protocol, (sub)layer. The third layer 126 of the control plane protocol stack 130 includes RRC, radio resource control, (sub)layer, SMF, session management functions, and AMF, access mobility management functions. The third layer 126 of the user plane protocol stack 132 includes UPF, user plane functions.
[0021] Figure 4 also shows channels or elements at different layers, such as the physical channels at the first layer 122, the transport channels, logical channels, RLC channels, signaling and data radio bearers at the second layer 124, and the QoS flow.
[0022] Furthermore, in wireless communication systems as described above with reference to Figure 1, an approach is implemented to check or verify whether a transmission sent by a transmitter such as a BS has correctly arrived at a receiver such as an UE, as in an LTE or 5G / NR system. This approach requests retransmission of information, or retransmission of one or more redundant versions of the information, in the event of an unsuccessful transmission. Naturally, such a process may also be implemented when transmitting from an UE to a BS, or from an UE to another UE. In other words, a mechanism for correcting errors is applied to handle error packets received by an UE or gNB. According to LTE or NR, a HARQ mechanism is implemented to correct error packets.
[0023] HARQ is a retransmission technique at the PHY / MAC layer (see Figure 4) where erroneous packets are not discarded, but sampled soft values or soft bits or hard bits from the received signal are stored and (in the case of soft values or soft bits) retransmitted and combined with the same packet. If the receiver is unable to decode the packet (e.g., a CRC check fails), the receiver stores the packet in its buffer or soft buffer and requests retransmission by sending a NACK. In LTE and NR, the ACK / NACK is typically sent over the uplink PUCCH or the sidelink PSFCH (Physical Sidelink Feedback Channel). The sender receives the NACK and sends another version of the same packet. When the same code block is sent, this technique is called chase synthesis (CC), and when different code blocks (or redundant versions) are sent, this technique is called incremental redundancy (IR).
[0024] Figure 5 briefly illustrates an example of a conventional HARQ mechanism, which can also be derived from TS 38.321, sections 5.3.2 and 5.4.2, which describe HARQ operation and entities. Figure 5 shows a transmitter, e.g., a gNB, sending data packet 1 to a receiver, e.g., a UE. Initially, data packet 1(1) is sent, and the receiver attempts to decode the received data packet. If the data packet is successfully decoded, the receiver delivers the data packet from the MAC / PHY layer to the upper layers (see Figure 4). If the data packet is not successfully decoded, the receiver buffers the data packet in a soft buffer, as shown by "1" in Figure 5. Furthermore, the receiver sends a NACK message to the transmitter, and in response to the NACK message, the transmitter sends a retransmission 1(2) of the data packet. The buffered initial transmission is combined with the retransmission, as shown by "2". Combination can use chase combination or incremental redundancy. As indicated by "3", if the synthesized data can be decoded, an ACK message is sent to the transmitter to indicate successful transmission.
[0025] In order for the receiver to combine old and new transmissions, each packet must be uniquely identified. In LTE and NR, this HARQ information is transmitted within the resource allocation of the downlink PDCCH channel.
[0026] LTE and NR use the N-channel stop-and-wait HARQ scheme. LTE uses up to 16 parallel HARQ processes (or channels), while NR uses eight processes. The same HARQ process can only be reused after an ACK has been received. Processes are identified by a HARQ process identifier (3 bits in the case of eight processes).
[0027] Figure 6 illustrates an 8-channel stop-and-wait HARQ protocol in which additional data packets are sent during a time period that may be the minimum time before a retransmission can be sent due to a missing ACK / NACK or a received NACK. In the latter case (received NACK), the time period is defined by the processing time at the receiver to decode the data packet and the processing time at the transmitter to decode the ACK / NACK message associated with the data packet. The gNB provides the UE with instructions on which HARQ process to use during each subframe in which resources are allocated, and their respective identifiers or HARQ process IDs may be included in the PDCCH transmission. Asynchronous HARQ processes require the inclusion of the HARQ process ID in the DCI or SCI message, which comes with increased signaling overhead, but offers increased flexibility because retransmissions do not need to be scheduled during every subframe.
[0028] In the synchronous HARQ scheme, HARQ processes are transmitted sequentially as shown in Figure 6. In this case, process identification may be strict with respect to the sequence frame number to save overhead signaling. LTE uplinks use synchronous HARQ. NR uses asynchronous HARQ, where the scheduler determines which HARQ processes are scheduled at what point in time.
[0029] The embodiments described herein are based on the assumption that HARQ processes / entities may consist of different HARQ behaviors, i.e., different HARQ behaviors for each HARQ process / entity.
[0030] According to the embodiment, synchronous HARQ can be implemented, for example, in NR for low-latency services such as URLLC. More specifically, scheduling each transmission of PDCCH on the uplink introduces additional delay, and on the downlink, it requires additional complexity, which needs to be avoided for URLLC services. Also, feedback bundling, which improves the spectral efficiency and reliability of the feedback channel, has the disadvantage of introducing additional latency. In the case of URLLC services, feedback is requested as quickly as possible, and therefore, according to the embodiment, dedicated resources are used for URLLC HARQ feedback. On the downlink, this corresponds to a HARQ indicator channel containing only acknowledgment / non-acknowledgment messages, ACK / NACK, and on the uplink, it corresponds to two specific PUCCH resources used for feedback or low-latency CSI, LL-CSI. According to the embodiment, there may be multiple hybrid ARQs, HARQs, entities, for example, two or more HARQ entities that perform different HARQ operations, such as an asynchronous HARQ for a delayed non-critical service like an eMBB service, and a synchronous HARQ for a delayed critical service like a URLLC service.
[0031] According to the embodiment, the communication system comprises a data flow across multiple layers, consisting of QoS flows, signaling and radio bearers, RLC flows, logical channels, transport channels, and physical channels. Services may correspond to QoS flows and be mapped to radio bearers. HARQ may reside at the MAC and / or PHY layers and may not be aware of any actual services at higher layers. The MAC layer may only know the logical channel to which a packet corresponds, so that HARQ entities may be selected for each logical channel.
[0032] In other words, the embodiment provides the possibility of supporting synchronous and asynchronous HARQ operation simultaneously, i.e., at the same time, thereby combining the advantages of each operation with respect to the service on which the transmission occurs. For example, synchronous HARQ has the advantage that scheduling retransmissions does not require an extra PDCCH, thereby avoiding the consumption of additional time, particularly for uplink transmissions, and reducing the burden of blind decoding. Synchronous HARQ operation uses a dedicated HARQ indicator channel for sending ACK / NACK messages, and NACK messages, depending on the initial transmission, automatically allocate predefined resources for retransmission, i.e., no additional time is spent scheduling resources for retransmission. For example, a UE may use synchronous HARQ operation when it recognizes that the transmission originates from a latency-critical service such as a URLLC service or a low-complexity service such as an mMTC service, but at the same time, the UE may also support transmissions from latency-noncritical or normal-complexity services such as an eMBB service, for which the UE may use a PDCCH to asynchronously schedule retransmissions. For example, when applying synchronous HARQ operation, a stop-and-wait HARQ mechanism may be used, while an asynchronous HARQ protocol may be selected and used for delayed non-critical services.
[0033] In addition, for downlink transmissions, the HARQ protocol may be used, which uses normal channel state information feedback for latency-noncritical transmissions, while for latency-critical services, a different HARQ protocol may be used, which uses a low-latency CSI feedback channel. These CSI feedbacks may be transmitted using PUCCH in different formats.
[0034] Figure 7 schematically shows a Layer 2 structure for implementing simultaneous synchronous and asynchronous HARQ operation in a base station or user equipment according to one embodiment. The MAC layer provides MAC entities that perform scheduling / prioritization processing 310 and multiplexing 312. The MAC entities further include a synchronous HARQ entity 314 for synchronous HARQ operation and an asynchronous HARQ entity 316 for asynchronous HARQ operation, so that, depending on the HARQ being used, either or both of the HARQ entities 314, 316 may be applied or used for transmitting one or more data packets. According to other embodiments, instead of providing a single MAC entity containing HARQ entities 314, 316, multiple MAC entities, each containing a HARQ entity, may be provided, as shown in Figure 8. In addition, a single HARQ entity can also support synchronous and asynchronous HARQ operation simultaneously, and the HARQ process can be shifted dynamically or reconfigured between HARQ operation modes, for example by RRC signaling.
[0035] Accordingly, the embodiments provide network entities and methods that support different retransmission protocols or procedures simultaneously or at the same time. While two retransmission procedures are referred to, it should be noted that the embodiments are not limited to such scenarios, and rather, three or more retransmission procedures may be supported simultaneously in the network entity. Furthermore, the embodiments are not limited to asynchronous and synchronous HARQ operations, and rather, other retransmission procedures such as ARQ procedures may be implemented.
[0036] According to the embodiment, the HARQ protocol used may be configured semi-statically via the RRC protocol. The configuration may set criteria for the UE or gNB to select which HARQ protocol to use, based on the service type, such as eMBB, URLLC, or mMTC, or based on specific 5QI attributes, such as latency or guaranteed bitrate GBR.
[0037] In further embodiments, different HARQ entities may be used for each of the supported HARQ protocols. HARQ entities may be constructed by signaling or hardcoded in the standard. Different HARQ entities may use different logical channels defined by logical channel identification, and different physical channels defined by different physical resources. Different physical resources may also use different subcarrier intervals.
[0038] Different HARQ entities may use different target block error rates (BLER) for different send / retransmissions and may be associated with different numbers of HARQ processes. Furthermore, redundant versions (RV) in different sequences may be applied.
[0039] In further embodiments, DCI signaling may be used to distinguish between HARQ entities / protocols. For example, a UE needs to determine which HARQ entity should be processed or which HARQ protocol should apply to a received authorization for transmission. This can be achieved by using a new specific DCI format, which may be a Radio Network Temporary Identifier, RNTI, or a compact format.
[0040] For example, when using RNTI, the UE can configure a new RNTI, for instance via RRC signaling, and the new RNTI is associated with a HARQ entity / protocol used for transmission. As a result, during a blind decoding process where all RNTIs are tested, the UE can determine which HARQ protocol should be applied.
[0041] The new DCI format may be used in particular for delayed critical transmissions, and since synchronous HARQ does not require a HARQ process ID, a new DCI format without a HARQ process ID may be provided. The DCI format may be called the URLLC DCI format in the case of URLLC services. A DCI format that includes a HARQ process ID may be called the eMBB DCI format, as it relates to asynchronous HARQ operation in, for example, eMBB services. According to this approach, a UE can test PDCCH candidates against its eMBB DCI format and URLLC DCI format, and the resulting embedded checksum indicates which DCI format, and therefore which HARQ entity / protocol, should apply. A DCI for signaling DL transmissions using synchronous HARQ may be called the compact DCI format 1_2, which is detected by blind decoding. The compact DCI format 1_2 may contain the same fields as DCI format 1_0, but does not contain the following fields: • HARQ process number - 4 bits • Downlink allocation index • PDSCH-to-HARQ_feedback timing indicator
[0042] In yet another embodiment, a dedicated PUCCH may be used for each HARQ entity / protocol. For example, each HARQ / protocol may receive its dedicated PUCCH to send feedback or LL-CSI on the uplink. This makes it possible to support low latency for URLLC HARQ protocols. Since eMBB HARQ protocols may use bundling techniques, more processing and longer transmission times are required, which are translated into longer PUCCHs accordingly. However, this is a bottleneck for URLLC HARQ procedures. Therefore, according to the embodiment, URLLC HARQ procedures use short PUCCHs with a single ACK / NACK feedback and / or LL-CSI.
[0043] In yet another embodiment, RRC signaling may be used to configure the number of HARQ processes and UE capabilities. In NR and LTE, only a single HARQ protocol is used for uplink and downlink, respectively. Therefore, it is sufficient to configure the number of HARQ processes for PDSCH, PUSCH, and PSSCH. In one embodiment, the gNB can tell the UE how many HARQ processes should be used for synchronous and asynchronous HARQ protocols; see Figure 7 above, which shows the respective HARQ processes in 314 and 316. The number of HARQ processes available for each protocol may be part of the UE capabilities that can be signaled to the gNB by the UE. An example of signaling for PDSCH is shown below; for asynchronous HARQ operation, see nrofHARQ-ProcessesForPDSCH; the number of HARQ processes for PDSCH, as well as the number of HARQ processes for PDSCH-URLLC, see nrofHARQ-ProcessesForPDSCH-URLLC. PDSCH-ServingCellConfig ::= SEQUENCE { codeBlockGroupTransmission SetupRelease {PDSCH-CodeBlockGroupTransmission} OPTIONAL xOverhead ENUMERATED { xOh6, xOh12, xOh18} OPTIONAL nrofHARQ-ProcessesForPDSCH ENUMERATED {n2, n4, n6, n10, n12, n16} OPTIONAL nrofHARQ-ProcessesForPDSCH-URLLC ENUMERATED {n2, n4, n6, n10, n12, n16} OPTIONAL pucch-Cell ServCellIndex OPTIONAL , -- Cond SCellAddOnly ...}
[0044] In yet another embodiment, DCI miss detection and rescheduling of retransmissions can be performed. For example, in the case of a downlink transmission, the UE may lose the initial scheduling of the transmission, in which case subsequent retransmissions will naturally also be lost. The gNB may, for example, detect a missing PUCCH, i.e., a missing feedback or a missing LL-SCI, depending on the indicated PUSCH format. If the gNB detects a missing DCI, the same transmission or the next redundant version is explicitly rescheduled using PDCCH at the next opportunity. For PUSH formats 0-1, the gNB may perform power thresholding to detect a missing PUCCH transmission, and for PUCCH formats 2-4, it may perform checksum detection where a mismatch in embedded checksums indicates a missing initial permission.
[0045] According to the embodiment, the base station gNB may schedule UL HARQ retransmissions. For example, adaptive retransmissions used in NRs may be applied, and the gNB may schedule UL resource allocations for retransmissions using the normal DCI format on the PDCCH to indicate the new location and format. Thus, complete signaling of HARQ control information, including, for example, process ID, RV, and NDI, is provided.
[0046] Furthermore, non-adaptive and synchronous ARQ retransmissions may be scheduled, and according to the embodiment, the gNB has different options for triggering retransmissions by the UE.
[0047] According to the first embodiment, a physical hybrid indicator channel, PHICH, which is limited to ACK / NACK, i.e., contains only ACK / NACK messages, may be used. When the UE receives a NACK, the UE retransmits it on the same resource in a fixed format and optionally fixes it to a predefined sequence of RVs. Fast ACK signaling is useful, for example, to stop autonomous retransmissions, and in URLLC scenarios, retransmissions may be sent without waiting for a NACK.
[0048] According to the second embodiment, a PDCCH having a new compact DCI format may be implemented so that only restricted control information can be transmitted, which can reduce the load compared to the normal DCI format. For example, it may not be necessary to transmit the process ID because the same resources as the initial transmission are used.
[0049] For example, a standard DCI may be used with detailed information for initial transmission, while later, for retransmission or initial transmission of new data, for example, when using a synchronization protocol, only the compact DCI format may be used.
[0050] Furthermore, if a UL ACK / NACK is not received in the first transmission—that is, if an ACK is not received, or a NACK is not received, or nothing is received—the gNB may request a new initial uplink transmission from the UE. Alternatively, the gNB may request a specific redundant version with a compact DCI.
[0051] Next, further embodiments for feedback, such as UE feedback for DL HARQ retransmission, will be described. Figure 9 shows the antenna ANT R Figure 11 shows details of the UE, such as the UE described above, including the signal processor 302a and the transceiver 302b. As shown in Figure 9, following the reception of the transmit, channel estimation can first be performed to generate a CQI using the reference signal in the transmit. Further PMI and RI may also be provided. An ACK / NACK message is generated only after the data has been processed to verify whether decoding was successful.
[0052] Embodiments suggest that in synchronous HARQ, for example, smaller transmission time intervals may be used to provide low-latency, LL-PUCCH signals that are sent more frequently than normal PUCCH signals. LL-PUCCH signals may not support HARQ ACK / NACK bundling because they must wait for the reception and decoding of multiple data packets. LL-PUCCH signals enable the immediate transmission of HARQ ACK / NACK signals, which may even outperform HARQ ACK / NACK signals in the asynchronous HARQ protocol, as ACK / NACK signals must always be sent in a FIFO (First-In, First-Out) sequence, as in the conventional case.
[0053] Asynchronous HARQ uses a standard PUSCH, and embodiments allow for multiplexing feedback to a standard PUSCH. Multiplexing to a PUSCH is beneficial when latency is not critical, for example, because PRBs are scheduled, allowing for better link adaptation, and providing larger payloads.
[0054] Figure 10 illustrates the above concept, where LL-PUCCH is used for feedback in the case of synchronous HARQ, and feedback is multiplexed to a regular PUCCH in the case of asynchronous HARQ.
[0055] According to further embodiments, LL-PUCCH may be used to transmit low-latency, LL, CSI to support RV selection and adaptive retransmission when the channel conditions estimated using DM-RS in the initial transmit were not favorable, and to transmit low-latency, LL, HARQ to provide a faster ACK / NACK compared to slower eMBB decoding, for example. For example, firstly, since LL-PUCCH is based on channel estimation rather than packet decoding, it is transmitted with fast CSI feedback based on a front-loaded DM-RS of a faster initial transmit. If fast CSI feedback is not received, for example, PDCCH resource allocation, and therefore DM-RS is not received, a new initial transmit may be transmitted. LL-CSI feedback may be interpreted or understood as PDCCH + DM-RS and / or an ACK of the data itself. Following the LL-CSI feedback, an LL-PUCCH containing an ACK / NACK may be transmitted. The feedback may be combined with one or more additional or incremental CSI feedbacks and may use the same or a different PUCCH format as the fast CSI feedback.
[0056] According to the embodiment, HARQ feedback can be enabled / disabled for each HARQ process / entity. The published concept is applicable to all types of HARQ behavior, but can be explained based on the example shown in Figure 11.
[0057] Figure 11 shows an 8-channel stop-and-wait HARQ protocol in which some of the HARQ processes are configured not to provide ACK / NACK feedback. For example, in Figure 11, HARQ processes IDs #1 and #2 are configured not to provide ACK / NACK feedback. This configuration is communicated from the gNB to the UE via the Radio Resource Protocol Layer (see Figure 4), and the gNB also notifies its lower layers.
[0058] For downlink transmissions, the gNB schedules per-packet resource allocations via the PDCCH. This resource allocation includes the HARQ process identification, NDI, and RV ID. The UE receiver must read the PDCCH before it can decode the data on the PDCCH data channel. From the process identification, the HARQ process is identified. Due to its RRC configuration, it is known that for the first packet on HARQ process identification #0, an ACK / NACK must be sent on the PDCCH. For the second packet on process identification #1, no ACK / NACK is expected to be sent. The same applies to process identification #2, etc.
[0059] Base station scheduling algorithms at the MAC layer can dynamically determine and multiplex which packets go into which HARQ process. This decision can be based on different criteria, such as how much latency is acceptable for a packet (and whether retransmission is possible) and what kind of reliability is required.
[0060] Figure 12 schematically shows a Layer 2 structure for implementing simultaneous synchronous and asynchronous HARQ operation in a base station or user equipment according to one embodiment. The MAC layer provides MAC entities that perform scheduling / prioritization processing 310 and multiplexing 312. The MAC entities further include a synchronous HARQ entity 314 for synchronous HARQ operation and an asynchronous HARQ entity 316 for asynchronous HARQ operation, so that, depending on the HARQ being used, either or both of the HARQ entities 314, 316 may be applied or used for transmitting one or more data packets. According to other embodiments, instead of providing a single MAC entity containing HARQ entities 314, 316, multiple MAC entities may be provided, each containing a HARQ entity. In addition, a single HARQ entity may also support synchronous and asynchronous HARQ operation simultaneously, and the HARQ process may be shifted dynamically or reconfigured between HARQ operation modes, for example by RRC signaling.
[0061] Note that Figure 12 shows an example of different HARQ behaviors for configuring HARQ entities / processes, with or without ACK / NACK feedback. Nevertheless, the same mechanism is applicable to different HARQ configurations. HARQ entities / processes may consist of, for example, different numbers of retransmissions, different processing times, different buffer sizes, etc.
[0062] For example, in one embodiment, one HARQ entity / process may use a stop-and-wait protocol, while other HARQ entities / processes use a window-based ARQ protocol.
[0063] For example, in this embodiment, one HARQ entity / process may use a synchronous protocol, while other HARQ entities / processes may use an asynchronous protocol.
[0064] For example, in this embodiment, one HARQ entity / process may use chase synthesis, while other HARQ entities / processes may use incremental redundancy.
[0065] For example, in this embodiment, one HARQ entity / process may send HARQ ACK / NACK feedback, while other HARQ entities / processes do not send such feedback.
[0066] For example, in this embodiment, HARQ entities / processes can be configured with different numbers of retransmissions, different processing times, different buffer sizes, and so on.
[0067] According to the embodiment, MAC multiplexing is supported. The MAC layer supports multiplexing different logical channels into a single MAC PDU within a single transmission time interval mapped to a specific data channel (PDSCH, PUSCH, or PSSCH), as shown as an example in Figure 13.
[0068] More specifically, Figure 13 shows a schematic representation of a MAC PDU 200 according to one embodiment. As shown in Figure 13, each MAC SDU 202, 204, and 206 in each logical channel is identified by a logical channel identifier (LCID) in the MAC subheaders 201, 203, and 205 that advance their respective MAC SDUs. Optionally, MAC control elements 210, 212, 214, and 216 may be included at the beginning of the MAC PDU 200. Finally, padding 220 and 222 may be optionally added to adapt the length of the MAC PDU 200 to the transport block size provided by the physical layer and selected by the MAC scheduler. The example shown in Figure 13 illustrates the transmission of several MAC CEs, the multiplexing of three logical channels, and the padding at the end of the MAC PDU.
[0069] An example of an uplink MAC control element is the Buffer Status Report (BSR), which will be explained in more detail below.
[0070] All scheduling decisions are made by the base station. This is a complex task, especially on uplinks. Before scheduling decisions are made, the gNB must know the buffer status and associated QoS requirements from all UEs, as well as the characteristics of the mobile channel for link adaptation. The principle procedure for uplink scheduling and link adaptation is shown in Figure 14.
[0071] In detail, Figure 14 shows a schematic representation of uplink scheduling and link adaptation between a BS (base station) and a UE (user equipment) in a wireless communication system. As shown in Figure 14, in the first step 242, the UE may signal its buffer status and QoS information to the BS. In the second step 244, the UE may transmit a reference signal in the data transmission tx or as a sounding. In the third step 246, the BS may measure the channel based on the reference signal and collect information from all UEs. In the fourth step, the BS may perform uplink scheduling, which includes 1) selecting UEs and data flows, 2) selecting resources and parameters, and 3) adapting the link to the channel. In the fifth step 250, the BS may signal permission and tx parameters to the UE. In the sixth step 252, the UE may apply the uplink tx parameters and transmit uplink data.
[0072] Therefore, the UE can transmit data after it requests resources for uplink transmission via a buffer state report (BSR) in the MAC control element, and the base station finally grants some resources on the PDCCH control channel, including downlink control information bits containing HARQ side information.
[0073] The embodiments described herein relate, in particular, to the sixth step 252 in which the UE actually transmits data on the uplink. Up to this point, it is mainly up to the UE implementation which data queues serve and which MAC SDU is chosen to build the MAC PDU.
[0074] Scheduling and buffer status reports are used by UEs to notify gNBs of their buffer status and request resources for uplinks. BSRs are used by UEs to request uplink resources from gNBs. gNBs receive scheduling requests and BSRs from all UEs in a cell, and the gNB scheduler makes scheduling decisions at each transmission time interval. Various formats exist. As an example, the short format of an LTE BSR consists of a logical channel group identifier followed by several bits that identify the amount of data pending in the buffer, as shown in Figure 15.
[0075] In contrast, the long BRS format provides information for all four logical channel groups according to the format shown in Figure 16.
[0076] In wireless communication systems or networks, as described above, the base station scheduler (e.g., gNB scheduler) schedules all uplink transmissions. More specifically, the scheduler determines almost everything related to HARQ while the UE is performing what the base station has decided. Within the PDCCH uplink authorization sent from the base station (e.g., gNB) to the UE, the base station tells the UE which HARQ process and redundant version should be used, as well as whether new data should be transmitted by NDI. Nevertheless, for each uplink authorization, it is up to the UE to select which logical channel (LC) should be served by this authorization. The UE can also multiplex packets from different radio bearers in a single MAC SDU.
[0077] In the past, multiplexing different packets from different logical channels and bearers wasn't a major issue because the same HARQ behavior applied in all cases. Different HARQ configurations result in very different packet data processing, leading to different resource usage, different packet processing, and so on. Ideally, the base station would have complete control over UE behavior, telling the UE which logical channel and bearer should serve each authorization. In practice, this would introduce a significant amount of signaling overhead.
[0078] The present invention provides improvements and enhancements to wireless communication systems or networks that address the aforementioned problems relating to uplink multiplexing. More specifically, embodiments of the present invention avoid signaling overhead in telling the UE which logical channel and bearer should be served for each authorization. Embodiments of the present invention can be implemented in a wireless communication system, such as the one shown in Figure 1, which includes a base station and users, such as a mobile terminal or IoT device. Figure 17 is a schematic representation of a wireless communication system including a transmitter 300, such as a base station, and one or more receivers 302, 304, such as user devices and UEs. The transmitter 300 and receivers 302, 304 can communicate via one or more wireless communication links or channels 306a, 306b, 308, such as radio links. The transmitter 300 has one or more antennas ANT, which have multiple antenna elements, signal processors 300a, and transceivers 300b coupled together. T or may include an antenna array. Receivers 302, 304 have one or more antennas coupled together, including multiple antennas, signal processors 302a, 304a, and transceivers 302b, 304b. UEor including an antenna array. The base station 300 and UEs 302, 304 communicate via their respective first wireless communication links 306a and 306b, such as radio links using the Uu interface, while UEs 302, 304 may communicate with each other via a second wireless communication link 308, such as radio links using the PC5 / sidelink (SL) interface. When UEs are not serviced by a base station, or are not connected to a base station, for example, when UEs are not in an RRC connection state, or more generally, when SL resource allocation configuration or support is not provided by the base station, UEs may communicate with each other via the sidelink (SL). The system or network of Figure 1, one or more UEs 302, 304, and base station 300 may operate in accordance with the teachings of the present invention described herein. A data transmission device such as a UE or BS that supports multiple HARQ processes.
[0079] The embodiment provides an apparatus, and the apparatus is • Multiple hybrid ARQ, HARQ, entities, each of which is configured to operate a HARQ process associated with one of several HARQ behaviors, and the multiple HARQ behaviors are different, multiple HARQ entities, and / or A hybrid ARQ, HARQ, entity configured to run multiple HARQ processes, where each HARQ process is associated with one of several HARQ behaviors, and these multiple HARQ behaviors are different. The device includes a hybrid ARQ, HARQ, identifier [e.g., HARQ process number] that identifies one HARQ behavior out of a plurality of HARQ behaviors or one HARQ process out of a plurality of HARQ processes, and one HARQ process is associated with a HARQ behavior. A device that receives data, such as a UE or BS, that supports multiple HARQ processes.
[0080] The embodiment provides an apparatus, and the apparatus is • Multiple hybrid ARQ, HARQ, entities, each of which is configured to operate a HARQ process associated with one of several HARQ behaviors, and these multiple HARQ behaviors are different, multiple HARQ entities, or A hybrid ARQ, HARQ, entity configured to operate multiple HARQ processes associated with one of several HARQ behaviors, where the multiple HARQ behaviors are different. The device includes a hybrid ARQ, HARQ, identifier [e.g., HARQ process number] that identifies one HARQ behavior out of a plurality of HARQ behaviors or one HARQ process out of a plurality of HARQ processes, and one HARQ process is associated with a HARQ behavior. Preferred Embodiments of a Data Transmitter and / or Data Receiving Device
[0081] In the embodiment, the device includes a plurality of different channels or elements, which are linked to one or more HARQ processes and / or behaviors from a plurality of HARQ processes and / or behaviors, according to the configuration of the channels or elements.
[0082] In this embodiment, multiple different channels or elements are, • Different logical channels, LCH, • Different logical channel groups, LCG, • Different wireless link controls, RLC, channel, • Different packet data convergence protocols, PDCP, channels, • Different wireless bearers or different quality of service, QoS, flow, Includes one or more of the following.
[0083] In this embodiment, multiple different channels or elements are linked one by one to multiple HARQ processes and / or behaviors, and / or multiple different protocol stack channels or elements are linked in groups to one of the multiple HARQ processes and / or behaviors.
[0084] In the embodiment, data packets from channels or elements linked to the same HARQ process and / or behavior are included in the same data transmission [e.g., uplink] [e.g., multiplexed into the same MAC physical data unit, PDU].
[0085] In the embodiment, channel or element data packets are associated with priority, and channel or element data packets linked to the same HARQ process and / or behavior are included in the same data transmission [e.g., uplink] [e.g., multiplexed into the same MAC physical data unit, PDU] based on their priority.
[0086] In the embodiment, data packets from channels or elements linked to the same HARQ process and / or behavior are multiplexed into the same data transmission [e.g., uplink] [e.g., multiplexed into the same MAC physical data unit, PDU] based on UE internal knowledge [e.g., service type, traffic characteristics, preferred bitrate, PBR].
[0087] In the embodiment, the configuration of a channel or element or HARQ process and / or behavior is predefined, and / or the configuration of a protocol stack channel or element or HARQ process and / or behavior is • Wireless resource control, RRC, signaling • Downlink control information, DCI, • Side link control information, SCI, • System Information Block (SIB) It is signaled by one or more of the following.
[0088] In this embodiment, the apparatus meets the following criteria: Traffic prioritization, • Service quality, • Latency or delay budget, Buffer status, • Sending history, • Configured thresholds, It is configured to determine at least part of the configuration of the protocol stack channels or elements or the HARQ process and / or behavior itself based on one or more of these.
[0089] In the embodiment, if a higher-priority data packet from a channel or element linked to a HARQ process and / or behavior not identified by the current HARQ identifier is available for transmission, and the higher-priority data packet is associated with a higher priority than a data packet from a protocol stack channel or element linked to a HARQ process and / or behavior identified by the current HARQ identifier, the device is configured to transmit the higher-priority data packet according to the identified HARQ process and / or behavior.
[0090] In the embodiment, transmitting a high-priority data packet includes a transmission request for a high-priority data packet in the transmission of the high-priority data packet [e.g., a buffer status report, BSR] [e.g., as a MAC control element in a MAC physical data unit, PDU].
[0091] In one embodiment, if the uplink transmit permission is greater than what is required for the available data packets of a channel or element linked to a HARQ process and / or behavior identified by the current HARQ identifier, one or more data packets of a channel or element linked to a HARQ process and / or behavior not identified by the current HARQ identifier will be included in the same data [e.g., uplink] transmit [e.g., multiplexed into the same MAC physical data unit, PDU].
[0092] In this embodiment, the apparatus is - To transmit one or more data packets to a transceiver in a wireless communication system in accordance with an identified HARQ process and / or behavior, wherein the one or more data packets are one or more data packets of a channel or element linked to the identified HARQ process and / or behavior, according to the configuration of the channel or element, and / or • Resending data packets in accordance with identified HARQ processes and / or behaviors, where retransmission may include receiving a request for retransmission of a data packet from a transmitter [e.g., a base station] if the transmission of the data packet was unsuccessful, and / or • Repeatedly sending data packets according to the identified HARQ process and / or behavior. It is configured to perform the following actions.
[0093] In this embodiment, the retransmitted data packet is a copy of the transmitted data packet, and / or the retransmitted data packet is a redundant version of the transmitted data packet.
[0094] In the embodiment, the retransmitted data packet is • [For example, using the same hopping pattern] on the same frequency resource, or [for example, using different hopping patterns] on different frequency resources. • [For example, depending on whether carrier aggregation or dual connectivity is configured] different bandwidth portions or carriers or cells are used. It will be resent.
[0095] In the embodiment, the HARQ process and / or behavior is: • One or more HARQ operations, and / or • Configuration of different HARQ operations Includes.
[0096] In this embodiment, multiple HARQ operations are performed. • Stop-and-wait HARQ and / or ARQ protocol, • Window-based HARQ and / or ARQ protocols, • A synchronous protocol, which schedules one or more retransmissions and / or one or more HARQ ACKs / NACKs within a predefined time instance after the initial transmission. • An asynchronous protocol is one that dynamically schedules one or more retransmissions and / or one or more HARQ ACKs / NACKs in time. • Retransmission schemes that cause retransmission without feedback, such as the HARQ blind transmission scheme, or the K-repetition scheme that sends data packets K times without waiting for feedback. Includes one or more of the following.
[0097] In the embodiment, if no new data arrives and there is an uplink resource allocation or configured permission opportunity, the device determines whether the data packet is scheduled for transmission based on locally available information about the data packet [e.g., buffer occupancy, timing information such as transmit timer, or service requirements for the data packet] and / or the configuration or parameters of the communication system [e.g., propagation delay or round-trip time (RTT)]. • Will it be sent? • Will it be destroyed? • [For example, using the same PHY parameters] may be replaced by different versions of the data packet, • Replaced by different versions of data packets, and different versions of data packets are transmitted according to different transmission parameters [e.g., modulation scheme, MIMO scheme, or transmission power], It is configured to determine this.
[0098] In the embodiment, the device is configured to transmit uplink control information to a transceiver in a wireless communication system using a control channel or a data channel, the uplink control information indicating different transmission parameters [e.g., different coding modulation schemes, MIMO schemes, aggregation factors] and / or information about different versions of data packets [e.g., redundant versions, new data indicators].
[0099] In the embodiment, when new data arrives and an uplink resource allocation or configured authorization opportunity exists, the device will · HARQ behavior and / or HARQ process for sending new data and sending data packets containing new data, and / or HARQ behavior and / or HARQ process according to the determined HARQ behavior and / or HARQ process, and / or • Modulation and coding schemes, and / or • MIMO method, and / or Aggregation Factor (AF) It is configured to determine this.
[0100] In the embodiment, the HARQ behavior identified by the HARQ identifier in the downlink control information, and / or the HARQ process, and / or the HARQ new data indicator, and / or the HARQ redundant version, as well as the determined HARQ behavior, and / or the HARQ process, and / or the HARQ new data indicator, and / or the HARQ redundant version are different, and / or the modulation and / or coding scheme signaled by the transmitter of the wireless communication system [e.g., a base station] [e.g., via downlink control information] is different from the determined modulation and / or coding scheme, and / or the MIMO scheme signaled by the transmitter of the wireless communication system [e.g., a base station] [e.g., via downlink control information] is different from the determined MIMO scheme, and / or the aggregation factor [e.g., blind retransmission] signaled by the transmitter of the wireless communication system [e.g., a base station] [e.g., via downlink control information] is different from the determined aggregation factor.
[0101] In the embodiment, the device is configured to transmit uplink control information to a transceiver in a wireless communication system using a control channel or a data channel, and the uplink control information is · Determined HARQ behavior, and / or HARQ process, and / or new HARQ data indicators, and / or HARQ redundant versions, and / or · The determined modulation and / or coding scheme, and / or • The determined MIMO scheme, and / or • Determined aggregation factor This indicates.
[0102] In this embodiment, the apparatus is • HARQ behavior for sending new data, and / or HARQ process, and / or HARQ new data indicator, and / or HARQ redundant version, and / or • Modulation and / or coding scheme, and / or • MIMO method, and / or Aggregation factor, This is based on a defined algorithm, or on information provided by a transceiver [e.g., a base station] in a wireless communication system. It is configured to make a decision.
[0103] In the embodiment, the wireless system includes two or more user devices, at least two of which communicate directly with each other [e.g., V2X, D2D] via sidelink communication [e.g., PC5] while in connected mode, idle mode, or inactive mode, and the device includes a UE. system
[0104] The embodiment provides a wireless communication network comprising at least one UE of the present invention and at least one base station of the present invention.
[0105] In this embodiment, UE is • Mobile devices, or • Fixed terminal, or • Mobile terminal, or • Cellular IoT-UE, or • IoT devices, or • Ground-based vehicles, or • Aircraft, or • Drone, or • Mobile base station, or • Roadside unit, or • Building, or • Any other item or device that is provided with network connectivity that allows it to communicate using a wireless communication network, such as a sensor or actuator. Includes one or more of the following.
[0106] In this embodiment, BS is • Macrocell base station, or • Microcell base station, or • Small cell base station, or • Central unit of the base station, or • Distributed units of base stations, or • Roadside unit, or ·UE, or • Remote radio head, or · AMF, or · SMF, or • Core network entity, or • Network slices such as NR or 5G core context, or Any transmit / receive point (TRP) on which an item or device can communicate using a wireless communication network, and which is provided with network connectivity for communicating using a wireless communication network, Includes one or more of the following.
[0107] Further embodiments provide a wireless communication network comprising at least two UEs of the present invention.
[0108] In this embodiment, UE is • Mobile devices, or • Fixed terminal, or • Mobile terminal, or • Cellular IoT-UE, or • IoT devices, or • Ground-based vehicles, or • Aircraft, or • Drone, or • Mobile base station, or • Roadside unit, or • Building, or • Any other item or device that is provided with network connectivity that allows it to communicate using a wireless communication network, such as a sensor or actuator. Includes one or more of the following. method
[0109] The embodiments are, • Multiple hybrid ARQ, HARQ, entities, each of which operates a HARQ process associated with one of multiple HARQ behaviors, and these multiple HARQ behaviors are different, or multiple HARQ entities, A hybrid ARQ entity that runs multiple HARQ processes, where each HARQ process is associated with one of several HARQ behaviors, and these HARQ behaviors are different. The steps to provide, The step of receiving control information [e.g., PDCCH uplink permission or PSCCH permission] from a transceiver in a wireless communication system, the control information being transmitted via a radio channel [e.g., PDCCH, PSCCH] of the wireless communication system, the control information including a hybrid ARQ, HARQ, identifier [e.g., HARQ process number] that identifies one HARQ behavior out of several HARQ behaviors or one HARQ process out of several HARQ processes, and one HARQ process being associated with a HARQ behavior, and the receiving step This provides a method that includes [something].
[0110] Further embodiments include: • Multiple hybrid ARQ, HARQ, entities, each of which operates a HARQ process associated with one of multiple HARQ behaviors, and these multiple HARQ behaviors are different, or multiple HARQ entities, A hybrid ARQ entity that operates multiple HARQ processes, where each HARQ process is associated with one of several HARQ behaviors, and these HARQ behaviors are different. The steps to provide, The step of transmitting control information [e.g., PDCCH uplink permission or PSCCH permission] from a transceiver in a wireless communication system, the control information being transmitted via a radio channel [e.g., PDCCH, PSCCH] of the wireless communication system, the control information including a hybrid ARQ, HARQ, identifier [e.g., HARQ process number] that identifies one HARQ behavior out of several HARQ behaviors or one HARQ process out of several HARQ processes, and one HARQ process being associated with a HARQ behavior, and the step of transmitting This provides a method that includes [something]. Computer program products
[0111] The present invention provides a computer program product that, when executed by a computer, includes instructions that cause the computer to perform one or more methods according to the present invention.
[0112] Therefore, the embodiments provide different ways of how UE behavior can be controlled. For all options, there are two possibilities: either what the UE must do is defined in the specification (pre-configured), or the behavior is configurable by the base station (e.g., gNB). Base station (e.g., gNB) configuration can be provided via RRC signaling, via broadcast, semi-statically via UE-specific signaling, or dynamically via PDCCH DCI. Via broadcast signaling, the configuration can be transmitted via an existing or new System Information Block (SIB). This may be effective for all UEs in a cell, or for all UEs using certain features, such as non-terrestrial networks (NTN) or extremely long coverage, which must read and apply this particular System Information Block. Semi-static UE-specific signaling can be provided via RRC messages sent to the UE, usually RRC reconfiguration messages. Once the RRC reconfiguration message is processed by the UE, the new configuration is applied with or without a certain delay. Alternatively, the configuration may be provided in the Downlink Control Information DCI on a per-transmission basis. Therefore, in the last case, the behavior of the HARQ process can change even to the instructions in DCI.
[0113] In one embodiment, a logical channel can be linked to a HARQ entity and / or process in each configuration of that logical channel. This means that when an authorization is received on a PDCCH, the UE reads the Downlink Control Information (DCI) of the PDCCH and recognizes the HARQ process identification. Based on the logical channel configuration (mapping between LCHs and HARQ processes and / or entities), the UE knows which logical channels can be served with this authorization. There can be a 1:1 mapping of LCHs to HARQ entities / processes, or an N:1 mapping of multiple LCHs to a HARQ entity / process. In the case of an N:1 mapping, the UE can multiplex packets of all LCHs mapped to this HARQ entity / process into a single MAC SDU. As usual, LCHs can be identified by the LCID in the MAC subheader.
[0114] In a preferred embodiment, data packets from different LCHs (Logical Channels) can be associated with priority values configured by the network. For example, a base station (e.g., a gNB) may configure priorities {1…16} for each LCH. Depending on resource allocation, multiple MAC SDUs may be transmitted within a single MAC PDU. The UE can select MAC SDUs from a buffer queue according to their priority values, where lower priority numbers indicate higher priority and higher priority values indicate lower priority. This behavior may be standardized or left to implementation. Implementation-specific behavior may be preferred because the UE may have some available information unknown to the network. Such UE internal knowledge may include information about service types and traffic characteristics. This prioritized scheduling can be extended by the concept of prioritized bitrates (PRBs). Also, each configured LCH PRB, for example configured per LCH, may be served first before serving a single LCH priority sequentially using absolute priority. This concept can be used to avoid exhaustion of a service by providing a minimum bitrate.
[0115] There are many LCHs, and this configuration can already introduce considerable overhead. One way to reduce this overhead is to group LCHs, or logical channels, into logical channel groups (LCGs). LCGs are also used in buffer status reports sent from the UE to the base station (e.g., gNB) to request resources. LTE has four LCGs, and NR has eight.
[0116] According to a preferred embodiment, logical channel groups or logical channels can be linked to HARQ entities / processes depending on their HARQ behavior (reported or unreported) (note that in the case of RRC configuration behavior, LCGs can be mapped to HARQ processes, and in the case of dynamic instructions in DCIs, LCGs can be mapped to HARQ behavior). Again, the base station (e.g., gNB) can signal this mapping to the UE via RRC reconfiguration or it can be hardcoded by the standard. If uplink packets need to be sent, the UE can send a buffer status report on the uplink, for example, via a MAC control element. The BSR indicates the amount of data pending for each logical channel group identified by the LCG ID. The base station (e.g., gNB) can make its scheduling decision and then schedule the UE. Once permission is received in the PDCCH identifying the HARQ process identification, the UE knows which logical channels of which logical channel groups will serve. In some embodiments, the UE can only multiplex data for logical channels within a logical channel group (e.g., RLC SDUs), but not outside of the logical channel group.
[0117] In alternative embodiments, one, more, or all signaling radio bearers may be linked to one set of HARQ entities / processes, while one, more, or all data radio bearers may be linked to another set of HARQ entities / processes depending on their HARQ behavior (reported or unreported). In addition to mapping LCH, LCG, SRB, and DRB to HARQ entities and processes, the same principle can be applied to map RLC channels and / or QoS flows to HARQ entities and processes. The concepts of prioritized scheduling and PRB rates may be applied to each variant of the mapping.
[0118] In further embodiments, the UE itself is one or more criteria, • Traffic prioritization; for example, high-priority traffic is sent only through HARQ. • Quality of service, for example, whether HARQ-less transmissions meet QoS requirements, and if not, whether only permissions associated with HARQ can be used, can be determined. • Delay budget, for example, can be used to determine if there is sufficient delay budget to perform retransmissions, and if not, HARQ-less transmission (permission associated with HARQ-less operation) may be used. Buffer status, • Sending history, • Received signal strength / quality measurement values, RSRP, RSRQ, SINR, etc., configured threshold values. Based on this, it is possible to decide to map a certain logical channel / logical channel group / signal radio bearer / data radio bearer to a certain HARQ process or HARQ behavior. Example RRC configuration based on NR Rel.15 TS38.331
[0119] For example, uplink LCHs and logical channels are associated with HARQ processes based on the following list. -- ASN1START -- TAG-LOGICALCHANNELCONFIG-START LogicalChannelConfig ::= SEQUENCE { ul-SpecificParameters SEQUENCE { priority INTEGER (1..16), prioritisedBitRate ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512, kBps1024, kBps2048, kBps4096, kBps8192, kBps16384, kBps32768, kBps65536, infinity}, bucketSizeDuration ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000, spare7, spare6, spare5, spare4, spare3,spare2, spare1}, allowedServingCells SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF ServCellIndex OPTIONAL, -- PDCP-CADuplication allowedSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing OPTIONAL, -- Need R maxPUSCH-Duration ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, ms0p25, ms0p5, spare2, spare1} OPTIONAL, -- Need R configuredGrantType1Allowed ENUMERATED {true} OPTIONAL, -- Need R logicalChannelGroup INTEGER (0..maxLCG-ID) OPTIONAL, -- Need R schedulingRequestID SchedulingRequestId OPTIONAL, -- Need R logicalChannelSR-Mask BOOLEAN, logicalChannelSR-DelayTimerApplied BOOLEAN, ..., bitRateQueryProhibitTimer ENUMERATED { s0, s0dot4, s0dot8, s1dot6, s3, s6, s12,s30} OPTIONAL -- Need R } OPTIONAL, -- Cond UL ... }
[0120] This uplink LCH configuration information element allows you to add the following additional parameters to associate the LCH with a HARQ process and / or entity. ·HARQ-process-bitmap BIT STRING (SIZE(16)) Here, the UE can determine which LCH should be serviced on the uplink from the HARQ process identification scheduled for uplink transmission on the downlink PDCCH.
[0121] In a preferred embodiment, the HARQ process itself is linked to a logical channel group. Different implementations can be foreseen, such as pre-configuring different HARQ entities, or pre-configuring different logical channel groups with different HARQ behaviors, such as on / off switching or dynamic feedback instructions via PDCCH DCI, based on the list below. HARQEntityConfig ::= SEQUENCE { HARQ-process-bitmap BIT STRING (SIZE(16)) HARQ-process-feedback ENUMERATED {on, dynamic, off} logicalChannelGroup INTEGER (0..maxLCG-ID) } LogicalChannelGroupConfig ::= SEQUENCE { HARQ-process-bitmap BIT STRING (SIZE(16)) HARQ-process-feedback ENUMERATED {on, off} }
[0122] Depending on the number of HARQ processes, the bitmap approach may or may not be appropriate. Alternatively, the HARQ processes can be assigned sequentially. In this case, only the number may be defined (e.g., 4), and the HARQ process identification may be implicitly derived (e.g., 5, 6, 7, 8). Logical channel prioritization mapping limits
[0123] By default, the UE will map the RLC SDU as a whole to the MAC PDU if it fits the permitted resources, rather than segmenting the RLC SDU.
[0124] For multiplexing and MAC PDU assembly, logical channel prioritization rules can be defined for the UE. In this case, too, these may be partially specified, partially configured by the RRC, and partially implemented independently in the UE.
[0125] RRC can control the scheduling of uplink data by signaling the configuration of each logical channel for each MAC entity. eNB RRC signaling can signal priority, preferred bitrate (PBR), and bucket size duration (BSD) (see ASN1 calculated from the LCH configuration) as part of the LCH configuration (see list above). MAC PDUs can be constructed by considering preferred bitrate priority first, and then priority values in descending order, so that lower priority values can represent higher priority. PBR can be calculated, for example, using a token bucket model.
[0126] As explained above, LCH may not be multiplexable with all HARQ processes, or with HARQ processes that use specific behaviors or feedback types. In this case, multiplexing and MAC PDU assembly may be limited by the RRC configuration. This limitation can be achieved by signaling the following permissible multiplexing options: ·AllowedHARQ-process-feedback ENUMERATED {on, dynamic, off} ·AllowedHARQ -process-bitmap BIT STRING (SIZE(16)) ·AllowedHARQ-process-behaviour-type ENUMERATED {regular, aggregation, single tx}
[0127] Alternatively, it may signal an unacceptable multiplexing option. In either case, once the UE receives an uplink authorization via PDCCH resource allocation, the UE must adhere to configured logical channel priority mapping restrictions, such as those configured by the base station (e.g., gNB), when assembling the MAC PDU for transmission. This means that the UE should select only logical channels per uplink authorization by signalable HARQ process identification that satisfies the configured conditions for HARQ process / entity use. Otherwise, in this case as well, logical channel prioritization follows absolute priority, also taking into account preferred bitrate in the token bucket model.
[0128] According to the embodiment, MAC control elements and RRC messages can be multiplexed. Depending on the HARQ behavior, the delivery time and reliability of the messages also change. This can also affect the delivery of MAC control elements (and / or RRC messages) mapped to MAC PDUs. Regardless of whether MAC CEs (and / or RRC messages) can be multiplexed to MAC PDUs, there may be some limitations configured per logical channel or per MAC entity. Furthermore, depending on the priority of MAC CEs (and / or RRC messages), some MAC CEs (and / or RRC messages) may be sent multiple times through different HARQ processes / entities, while others may be prohibited from being sent multiple times. If a prohibit timer is defined (limiting how often elements can be sent), the timer may be defined to run per HARQ process / entity or across all HARQ processes / entities. High-priority data arriving on the uplink while low-priority data is already scheduled.
[0129] One key principle is that the UE requests uplink resources based on BSR reports, such as logical channel group-based BSRs. Upon receiving a report, the base station (e.g., gNB) allocates resources, and using the resource allocation, the base station allocates HARQ processes corresponding to certain behaviors. This procedure introduces additional uplink scheduling delays, especially in networks with long propagation delays, such as non-terrestrial networks.
[0130] In the following example, suppose a gNB has scheduled some data for a low-priority service (or LCH or LCG, etc.), but in the meantime, high-priority data for a different service (or LCG or LCH, etc.) arrives at the UE. Following strict procedures, the UE cannot send the high-priority data and must stick to the low-priority data, which is optimized for this particular HARQ behavior. The UE must first send a BSR to the gNB requesting resources for the high-priority data. Upon receiving this BSR, the gNB allocates a HARQ process to support the high-priority LCG. Such high latency is unacceptable in non-terrestrial networks with very high latency.
[0131] Therefore, according to the embodiment, a high-priority service (or LCH or LCG, etc.) can overtake the resource allocation of a low-priority service. Furthermore, a new BSR can be added as MAC CE to the data being transmitted on the uplink. The base station (e.g., gNB) can also configure the UE by a kind of prioritization of which services (or LCH or LCG, etc.) will take over / override which other services (or LCH or LCG, etc.). Based on another UE configuration parameter configured by the base station (e.g., gNB), the UE may transmit data a second time upon receiving the "intended" uplink resources for a high-priority service, or the UE may not transmit data a second time. This allows the UE to transmit high-priority data immediately without waiting for another authorization to be received. At the same time, if the UE can transmit the packet at a different time with an appropriate HARQ process, higher reliability can be achieved for this packet (e.g., for control messages). Thus, one high-priority service may overtake the resource allocation of other low-priority services. In addition, to enhance reliability, highly reliable services may be sent multiple times using different HARQ processes with different resource allocations.
[0132] Furthermore, according to the embodiment, the UCI, uplink control information, and side information can be multiplexed into the PUSCH transmission indicating the presence of high-priority traffic, causing a base station (e.g., gNB) to apply a high-priority procedure, such as sending permission in a specific HARQ process or dynamically enabling a HARQ process for a specific transmission via PDCCH DCI. The received permission for uplink transmission is greater than required, and other data is pending.
[0133] In an approach where all uplink resources are controlled by the base station scheduler (e.g., the gNB scheduler), it can occur that the UE receives an over-authorized allocation. With a normal scheduler, this is not a problem because any service (or LCH or LCG, etc.) can be mapped to uplink resource allocations. In the method described above, there is a fixed mapping of services (or LCH or LCG, etc.) to HARQ processes / entities. With this fixed mapping, if more resources than needed are authorized, it is not possible to add data from other services (or LCH or LCG, etc.). The default approach is to add padding bits, which is not efficient at all from a resource utilization perspective.
[0134] Therefore, according to the embodiment, other services (or LCH or LCG, etc.) can be multiplexed on this HARQ process even if such mapping is not configured. Which services (or LCH or LCG, etc.) can be multiplexed with other services may be configurable by the RRC configuration or fixed by the specification, based on, for example, QoS, priority, delay budget, buffer status, signal measurement threshold, etc. HARQ behavior UE-based selection (process number, new data indicator, redundant version)
[0135] Typically, HARQ parameters are selected by the base station (e.g., gNB) and communicated to the UE, which must abide by the base station's (e.g., gNB's) decision. In normal scheduled uplink transmissions, this information is provided via PDCCH downlink control information. In the case of uplink configured permission, this is provided by the RRC configuration and derived by the formula specified herein, or configured by dynamic signaling via RRC plus PDCCH DCI. This behavior is not optimal in communication systems with high propagation delays, where only the UE has the best knowledge of which data has recently arrived in its buffer.
[0136] Therefore, according to one embodiment, the UE is given some autonomy in selecting the most appropriate HARQ behavior. This is achieved by defining an algorithm of the UE on which the decision is being made. The algorithm may take into account the following parameters: Buffer usage, • Arrival of uplink data, • Availability of HARQ processes, • Previous use of the HARQ process, • Round-trip time of the communication system, • In this HARQ process, some service requirements (e.g., latency and error rate) or service parameters for previously scheduled data, • Some service requirements (e.g., latency and error rate) or service parameters for the data scheduled in this HARQ process, • The time available to send a particular packet (for this purpose, the UE may mark each packet with a timer that starts when the packet arrives in the send buffer. When the send timer (send time) expires, the packet is typically removed from the send buffer and dropped).
[0137] A base station (e.g., a gNB) can control its behavior by configuring specific parameters that influence decision-making. These could be, for example, a certain threshold for buffer occupancy for a logical channel or logical channel group. The base station (e.g., a gNB) can also configure the number of HARQ processes and specific HARQ behaviors that influence the selection of HARQ transmission parameters.
[0138] Depending on some of the criteria mentioned above, the UE can then autonomously determine the HARQ transmission parameters for the next packet (according to a specified algorithm). For example, the UE may decide to send a new packet, send a retransmission to the base station, or even override the information provided by the base station. Preferred behaviors for different scenarios are described below.
[0139] According to the first scenario, no new data arrives, and uplink resource allocation / configured permission opportunities exist.
[0140] The UE has received a scheduled permission, or configured permission to transmit, for a given HARQ process. If no new data arrives, the UE will, in accordance with the base station's (e.g., gNB) decision, for example, transmit a retransmission, as sufficient time and transmission resources are usually available.
[0141] An exception to this behavior may be the transmission timer for each packet. This packet-specific timing information is not available at the base station (e.g., gNB). Buffer status reports received by the base station (e.g., gNB) may not be very meaningful in communication systems with large propagation delays.
[0142] Even if the transmit timer expires, a scheduling permission is received, or a configured permission for retransmission arrives, the packet may be dropped and not retransmitted. The UE may still replace this packet with a new transmit that is still relevant to the application. Information that retransmission was requested can still be used to select other transmit parameters, for example, to make the initial transmission of the next packet more reliable. This is because, • Modulation coding method, • MIMO scheme (for example, the number of users multiplexed in MU-MIMO, or the number of streams multiplexed in SU-MIMO, precoding, etc.) • Number of "blind" transmissions (aggregation factor) • Transmit power • etc. or any combination thereof This can be done by changing the settings.
[0143] The receiver, in this case the base station, is unaware that the packet is being transmitted with different transmission parameters. Therefore, the UE can multiplex these transmission parameters (the same as those normally transmitted over PDCCH DCI) onto the PUSCH data channel as uplink control information. This information can be encoded separately from the data and thus decoded by the base station (e.g., gNB). The base station (e.g., gNB) can first decode this information and, based on the uplink control information, decode the packet accurately, i.e., with the correct coding / modulation, MIMO scheme, etc.
[0144] According to the second scenario, no new data arrives, and uplink resource allocation / configured permission opportunities exist.
[0145] The UE has received a scheduled authorization or configured authorization transmission opportunity for a given HARQ process. If no new data arrives, the UE may autonomously decide to send a retransmission (for example, based on base station (e.g., gNB) scheduling information, e.g., NDI) or schedule a new packet (e.g., a high-priority packet) depending on one of the above criteria. For this purpose, the UE may override the HARQ information from the base station (e.g., gNB). If new data has arrived, a more important packet may be selected.
[0146] In this case as well, the receiver, in this case the base station, does not know whether the packet is a new transmission or a retransmission in this HARQ process, or may even expect a different transmission. The UE can multiplex the HARQ new data indicator as uplink control information into the PUSCH data channel. This information can be encoded separately from the data and therefore can be decoded by the base station (e.g., gNB). The base station (e.g., gNB) can first decode this information and, based on the uplink control information, decode the packet correctly, i.e., with or without soft synthesis and with or without soft buffer removal.
[0147] Similarly, the UE may select a HARQ process of its own accord, or, if commonly determined by the base station (e.g., gNB), it may select a different HARQ process instead of the one assigned by the base station (e.g., gNB). In this case as well, the UE may multiplex this information in the uplink control information to inform the base station (e.g., gNB) of the HARQ process used.
[0148] Furthermore, we can also consider behavior without associated UCI. In this case, the receiver does not know exactly which UE made the selection. The receiver must blindly decode the packet and apply different options for decoding. For example, without NDI uplink control information, the receiver does not know whether the packet is the same packet (in which case soft synthesis will be performed) or whether the packet is a new packet (in which case previously stored data will be deleted). The receiver must blindly apply both options to determine whether successful decoding is possible. Similarly, if the process is not signaled, the receiver may attempt decoding by soft synthesis of different HARQ processes. This may not be a preferred option as the additional effort can be time-consuming and power-consuming. However, despite this, the processing time may not be so critical due to the long propagation delay. Uplink configured permission configuration
[0149] Traditionally, uplink pre-configured authorization is used to support uplink data transmission, such as small packets transmitted periodically, like VoIP, while minimizing the PDCCH overhead of resource allocation. Resources for the UE are pre-configured on the uplink by the base station (e.g., gNB) in predefined resource blocks with a predefined format and predefined interval (e.g., 20ms for VoIP). When uplink data is available, the UE can begin transmitting on the pre-configured resources without needing to pre-read the PDCCH control channel. There are two types of pre-configured authorization. Type 1 pre-configured authorization (sometimes called authorization-free operation) involves pre-configuration of resources via RRC signaling only. Resources can be used immediately by the UE without activation / deactivation via PDCCH DCI. In Type 2 pre-configured authorization, the PDCCH control channel of the pre-configured resources can be transmitted using a predefined CS-RNTI. This signaling can be used to semi-permanently switch resources on / off.
[0150] Figure 18 shows the VoIP transmission time interval (subframe) in which the UE's resources are pre-configured by the base station (e.g., gNB) on the uplink in predefined resource blocks having a predefined format and a predefined period.
[0151] However, in 4G and 5G, uplink configured authorization has a problem in that it cannot support different types of HARQ behavior. Without this distinction, it is impossible to apply different HARQ behaviors to different service or system requirements. Uplink configured authorization is crucial for communication systems with high propagation latency because explicit scheduling is too time-consuming. Therefore, extensions to uplink configured authorization were needed to support different types of HARQ behavior in order to support different services (e.g., with different latency and / or error requirements) or different bearer types (e.g., signaling bearers with high-severity signaling).
[0152] As previously defined, there are pre-defined RRC configurations for HARQ processes with different HARQ behaviors. According to one embodiment, there are several RRC configurations for configured authorizations that extend for this purpose. In detail, according to one embodiment, different HARQ behaviors can be configured by RRC by assigning specific HARQ processes and HARQ behaviors to be used in the configured authorization configuration. Bitmaps of different lengths can define which HARQ processes are used by this configured authorization process and which are not. If the number of HARQ processes is very large, the overhead of the bitmaps can increase significantly. More sophisticated signaling methods, such as process assignment per block, can save some signaling overhead. For each configured uplink, specific HARQ behaviors can also be defined. Suppose only one behavioral HARQ process is used to achieve the intended behavior. If different HARQ behaviors are also required, a second configured authorization configuration must be configured using different HARQ processes. Further embodiments
[0153] While some aspects of the described concepts are described in the context of apparatus, it is clear that these aspects also represent descriptions of corresponding methods, where a block or device corresponds to a method step or a feature of a method step. Similarly, aspects described in the context of a method step also represent descriptions of corresponding blocks, items, or features of a corresponding apparatus.
[0154] Various elements and features of the present invention can be implemented in hardware using analog and / or digital circuits, in software, through the execution of instructions by one or more general-purpose or dedicated processors, or as a combination of hardware and software. For example, embodiments of the present invention can be implemented in the environment of a computer system or another processing system. Figure 19 shows an example of a computer system 350. Units or modules, and steps of the methods performed by these units, can be performed on one or more computer systems 350. The computer system 350 includes one or more processors 352, such as dedicated or general-purpose digital signal processors. The processors 352 are connected to a communication infrastructure 354, such as a bus or network. The computer system 350 includes main memory 356, for example, random access memory (RAM), and secondary memory 358, for example, a hard disk drive and / or removable storage drive. The secondary memory 358 may allow computer programs or other instructions to be loaded into the computer system 350. The computer system 350 may further include a communication interface 360 to allow software and data to be transferred between the computer system 350 and external devices. The communication may be an electronic signal, an electromagnetic signal, an optical signal, or any other signal that can be processed by a communication interface. The communication may use wired or cable, optical fiber, telephone line, cellular link, RF link, and other communication channels 362.
[0155] The terms “computer program medium” and “computer-readable medium” are generally used to refer to tangible storage media such as hard disks installed on removable storage units or hard disk drives. These computer program products are means for providing software to the computer system 350. The computer program, also called computer control logic, is stored in main memory 356 and / or secondary memory 358. The computer program may also be received via the communication interface 360. When executed, the computer program enables the computer system 350 to implement the present invention. Specifically, when executed, the computer program enables the processor 352 to implement a process of the present invention, such as any of the methods described herein. Thus, such a computer program may represent a controller of the computer system 350. If the present disclosure is implemented using software, the software may be stored in a computer program product and loaded into the computer system 350 using an interface such as a removable storage drive or the communication interface 360.
[0156] Hardware or software implementations may be carried out using digital storage media, such as cloud storage, floppy disks, DVDs, Blu-rays, CDs, ROMs, PROMs, EPROMs, EEPROMs, or flash memory, which store electronically readable control signals that cooperate (or can cooperate) with a programmable computer system to perform the respective methods. Thus, the digital storage media may be computer-readable.
[0157] Some embodiments of the present invention include a data carrier having an electronically readable control signal that can cooperate with a programmable computer system so that one of the methods described herein can be performed.
[0158] Generally, embodiments of the present invention can be implemented as a computer program product having program code, the program code being operable to perform one of the methods when the computer program product is executed on a computer. The program code may be stored, for example, in a machine-readable carrier.
[0159] Other embodiments include a computer program stored in a machine-readable carrier for performing one of the methods described herein. In other words, one embodiment of the method of the present invention is a computer program having program code for performing one of the methods described herein when the computer program is executed on a computer.
[0160] Accordingly, a further embodiment of the method of the present invention is a data carrier (or digital storage medium, or computer-readable medium) having a computer program for performing one of the methods described herein recorded thereon. Accordingly, a further embodiment of the method of the present invention is a data stream or sequence of signals representing a computer program for performing one of the methods described herein. The data stream or sequence of signals may be configured to be transmitted, for example, over a data communication connection, for example, over the Internet. A further embodiment includes processing means, for example, a computer or a programmable logic device, configured or adapted to perform one of the methods described herein. A further embodiment includes a computer on which a computer program for performing one of the methods described herein is installed.
[0161] In some embodiments, a programmable logic device (e.g., a field-programmable gate array) may be used to perform some or all of the functions of the methods described herein. In some embodiments, a field-programmable gate array may work with a microprocessor to perform one of the methods described herein. Generally, these methods are preferably performed by any hardware device.
[0162] The embodiments described above are merely for illustrating the principles of the present invention. Modifications and variations of the configurations and details described herein will be obvious to those skilled in the art. Therefore, it is intended that the invention be limited only by the imminent claims and not by the specific details presented in the descriptions and explanations of the embodiments herein.
[0163] List of acronyms and symbols V2X Vehicle-to-Everything 3GPP Third Generation Partnership Project D2D (Digital-to-Digital) BS base station eNB Advanced Node B (3G base station) UE User Equipment NR New Radio [Explanation of symbols]
[0164] 1 data packet 100 Terrestrial Wireless Networks 102 Core Network 106 cells 110 IoT devices 114 Backhaul Link 116 Backhaul Link 120 Base Station Protocol Stack 122 First Layer 124 Second Layer 126 The Third Layer 130 Control Plane Protocol Stack 132 User Plane Protocol Stack 140 coverage area 142 First vehicle 144 Second vehicle 152 vehicles 154 vehicles 156 vehicles 200 MAC PDU 201 MAC subheader 202 MAC SDU 203 MAC subheader 204 MAC SDU 205 MAC subheader 206 MAC SDU 210 MAC control elements 212 MAC control elements 214 MAC control elements 216 MAC control elements 220 padding 222 Padding 300 Transmitters 302 Receiver 302a Signal Processor 302b Transceiver 304 Receiver 304a Signal Processor 304b Transceiver 306 channels 306a First wireless communication link 306b First wireless communication link 308 channels 308 Second wireless communication link 310 Scheduling / Priority Processing 312 Multiplexing 314 Synchronized HARQ Entities 316 Asynchronous HARQ Entities 350 Computer Systems 352 processors 354 Communication Infrastructure 356 Main Memory 358 Secondary Memory 360 Communication Interface 362 communication channels
Claims
1. A user device that operates in a wireless communication system, The User device is - Multiple Hybrid ARQ (HARQ) entities, each of which is configured to operate a HARQ process associated with one of several HARQ behaviors, and which are different HARQ entities, or A HARQ entity configured to run multiple HARQ processes associated with one of several HARQ behaviors, wherein the multiple HARQ behaviors are different. Includes, The user device is configured to transmit control information to a transceiver in the wireless communication system, the control information is transmitted via a radio channel of the wireless communication system, and the control information includes a HARQ identifier that identifies one of the plurality of HARQ behaviors. HARQ behavior includes the corresponding HARQ operation. At least one HARQ behavior involves feedback behavior based on ACK / NACK, User equipment including a retransmission scheme that performs retransmission without feedback, which includes at least one HARQ operation including a HARQ blind transmit scheme and / or a K-repeat scheme that transmits a data packet K times without waiting for feedback.
2. The user device according to claim 1, wherein the user device includes a plurality of different channels or elements, and the plurality of different channels or elements are linked to one or more HARQ processes and / or behaviors among the plurality of HARQ processes and / or behaviors according to the configuration of the channels or elements.
3. The aforementioned multiple different channels or elements are • Different logical channels, • Different logical channel groups, • Different wireless link control channels, • Different packet data convergence protocol channels, • Different wireless bearers or different quality of service flows, The user device according to claim 2, comprising one or more of the above.
4. The aforementioned multiple different channels or elements are linked one by one to the aforementioned multiple HARQ processes and / or behaviors, and / or The user apparatus according to claim 2 or 3, wherein the plurality of different channels or elements are linked in groups to one of the plurality of HARQ processes and / or behaviors.
5. The user device according to any one of claims 2 to 4, wherein data packets of channels or elements linked to the same HARQ process and / or behavior are included in the same data transmission.
6. The data packets of a channel or element are associated with priority. The user apparatus according to claim 5, wherein data packets of channels or elements linked to the same HARQ process and / or behavior are included in the same data transmission based on their priority.
7. The user device according to claim 5 or 6, wherein the data packets of a channel or element linked to the same HARQ process and / or behavior are multiplexed into the same data transmission based on UE internal knowledge.
8. The configuration of the channel or element or HARQ process and / or behavior is predefined, and / or The configuration of the channel or element or HARQ process and / or behavior is, Wireless resource control signaling, Downlink control information, - Side link control information, System information block, A user device according to any one of claims 2 to 7, which is signaled by one or more of the following.
9. The user device described above meets the following criteria: Traffic prioritization, • Service quality, • Latency or delay budget, Buffer status, - Sending history, • Configured threshold, The user device according to any one of claims 2 to 8, configured to determine at least a portion of the configuration of the channel or element or the HARQ process and / or behavior itself based on one or more of the following.
10. The user device according to any one of claims 2 to 9, wherein if a higher-priority data packet of a channel or element linked to a HARQ process and / or behavior not identified by the current HARQ identifier is available for transmission, and the higher-priority data packet is associated with a higher priority than the data packet of the channel or element linked to the HARQ process and / or behavior identified by the current HARQ identifier, the user device is configured to transmit the higher-priority data packet according to the identified HARQ process and / or behavior.
11. The user device according to claim 10, wherein transmitting the high-priority data packet includes a request to transmit the high-priority data packet in the transmission of the high-priority data packet.
12. If the uplink transmit permission is greater than required for the available data packets of the channel or element linked to the HARQ process and / or behavior identified by the current HARQ identifier, one or more data packets of the channel or element linked to the HARQ process and / or behavior not identified by the current HARQ identifier are included in the same data transmission, the user device according to any one of claims 2 to 11.
13. If no new data arrives and there is an uplink resource allocation or configured permission opportunity, the user device will determine, based on locally available information regarding the data packet planned for transmission and / or the configuration or parameters of the wireless communication system, that the data packet is: - Will it be sent? - Will it be discarded? - Replaced by a different version of the aforementioned data packet, - Replaced by a different version of the data packet, and the different version of the data packet is transmitted according to different transmission parameters. A user device according to any one of claims 1 to 12, configured to determine the following.
14. The user device according to claim 13, wherein the user device is configured to transmit uplink control information to the transceiver in the wireless communication system using a control channel or a data channel, the uplink control information including the different transmission parameters and / or information about the different versions of the data packet.
15. When new data arrives and there is an opportunity for uplink resource allocation or configured authorization, the user device shall - HARQ behavior and / or HARQ process for sending the new data and / or for sending data packets containing the new data, in accordance with the determined HARQ behavior and / or HARQ process, and / or - Modulation and coding scheme, and / or MIMO method, and / or Aggregation factor A user device according to any one of claims 1 to 14, configured to determine the following.
16. The HARQ behavior and / or HARQ process and / or HARQ new data indicator and / or HARQ redundant version identified by the HARQ identifier of the downlink control information, and the determined HARQ behavior and / or HARQ process and / or HARQ new data indicator and / or HARQ redundant version are different, and / or The modulation and / or coding scheme signaled by the transmitter of the wireless communication system is different from the determined modulation and / or coding scheme, and / or The MIMO scheme signaled by the transmitter of the wireless communication system is different from the determined MIMO scheme, and / or The user device according to claim 15, wherein the aggregation factor signaled by the transmitter of the wireless communication system is different from the determined aggregation factor.
17. The user device is configured to transmit uplink control information to the transceiver in the wireless communication system using a control channel or a data channel, and the uplink control information is: - The determined HARQ behavior, and / or HARQ process, and / or new HARQ data indicator, and / or HARQ redundant version, and / or - The determined modulation and / or coding scheme, and / or - The MIMO scheme determined above, and / or - The aggregation factor determined above A user device according to claim 15 or 16, which shows the following.
18. The User device is - The HARQ behavior for the transmission of the new data, and / or the HARQ process, and / or the HARQ new data indicator, and / or the HARQ redundant version, and / or - The modulation and / or coding scheme, and / or - The aforementioned MIMO method, and / or - The aggregation factor, Based on a defined algorithm, or based on information provided by the transceiver in the wireless communication system, A user device according to any one of claims 15 to 17, configured to make a determination.
19. The wireless communication system comprises one or more base stations (BS) and one or more user devices (UEs), the UEs being serviced by one or more BSs or by direct communication with one or more other UEs while in connected mode, idle mode, or inactive mode, according to any one of claims 1 to 18.
Citation Information
Patent Citations
Method and Apparatus for Selecting Multiple Transport Formats and Sending Multiple Transport Blocks Simultaneously by Multiple h-arq Processes
JP2009522870A
Method, apparatus, and system for managing hybrid automatic retransmission requests
JP2018514124A
Data retransmission
JP2019504544A
Improved radio resource allocation for vehicular communications
JP2019509695A
Systems and methods for improved uplink coverage
US20140362832A1