CN108768597A - 一种复用harq进程的方法 - Google Patents
一种复用harq进程的方法 Download PDFInfo
- Publication number
- CN108768597A CN108768597A CN201810551657.5A CN201810551657A CN108768597A CN 108768597 A CN108768597 A CN 108768597A CN 201810551657 A CN201810551657 A CN 201810551657A CN 108768597 A CN108768597 A CN 108768597A
- Authority
- CN
- China
- Prior art keywords
- physics
- harq processes
- storage table
- harq
- logic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1835—Buffer management
- H04L1/1845—Combining techniques, e.g. code combining
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/04—Error control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0023—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
- H04L1/0027—Scheduling of signalling, e.g. occurrence thereof
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Abstract
本发明提供的一种复用混合自动重传请求HARQ进程的方法,属于移动通信技术领域。本方法在用户端将HARQ进程分为物理HARQ进程和逻辑HARQ进程,并建立物理进程存储表和逻辑进程存储表。在物理进程存储表记录每个物理HARQ进程的状态、与逻辑HARQ进程的映射关系以及缓存软比特的空间地址;逻辑进程存储表存储用户端期待接收的NDI;用户下行传输接收失败时,选择可用的物理进程缓存软比特,记录逻辑进程和物理进程之间的映射关系,保持逻辑进程的期待接收NDI不变;下行传输接收成功时,只翻转该逻辑HARQ进程对应的期待接收NDI,不缓存软比特。本发明节省了用户端需要的HARQ进程数量和缓存空间。
Description
技术领域
本发明属于移动通信领域,涉及一种复用混合自动重传请求(Hybrid AutomaticRepeat reQuest,HARQ)进程的方法。
背景技术
在LTE(Long Term Evolution,长期演进)通信系统中,从Release 8起采用多进程停等HARQ传输协议,在频分双工FDD模式下使用8个并行的HARQ进程,在时分双工TDD模式下,使用的HARQ进程数与上下行子帧配比有关。用户在每一个HARQ进程中缓存数据的软比特,并对初传和多次重传的软比特进行合并以提高接收的可靠性。为了保证用户端对数据包的传输进行正确的合并,基站对于同一个数据包的初传和重传采用相同的HARQ进程进行发送,并在下行控制信息DCI中指示HARQ进程号以及NDI(New Data Indicator,新数据指示符)。对于同一HARQ进程,若NDI翻转,表示当前传输是新的数据包,用户直接对当前接收的数据进行解调解码,若失败则将软比特保存在相应HARQ进程的缓存之中;若NDI没有翻转,表示当前传输是对之前数据包的重传,用户将当前接收到的数据与对应HARQ进程中的软比特进行合并。
然而,随着一些新的通信技术的出现,传统LTE中的HARQ进程数量不能满足新的需求。例如在以下场景中,按照传统的方法,用户需要更多的HARQ进程以及相应的软比特缓存来支持下行数据的接收。
1)载波聚合。在LTE R10中引入了载波聚合技术,将多个连续或非连续的载波聚合在一起提供更大的带宽。在载波聚合中一个用户最多可以支持聚合5个分量载波,每个载波有独立的HARQ实体和HARQ进程,按照传统的方法,以FDD为例,用户端需要配置最多40个HARQ进程以及相应的软比特缓存来支持下行数据的接收。在之后的R13中进一步提出增强的载波聚合技术,单个用户可以支持最多32个分量载波。载波聚合技术给用户端的HARQ进程的数量提出了更高的需求。
2)sTTI。在目前针对短传输时间间隔sTTI的相关研究中指出,由于采用sTTI的HARQ往返时延(以sTTI为单位)可能比采用传统的1ms传输时间间隔TTI的HARQ往返时延更大,例如,FDD的HARQ往返时延为8个TTI的长度,导致采用sTTI时需要更多的HARQ进程。例如,在正交频分复用OFDM系统中,长度为2个OFDM符号的sTTI的HARQ往返时延为12个sTTI,则用户需要12个HARQ进程支持下行sTTI的传输[参考文献1:ZTE,ZTE Microelectronics,R1-1702384,“HARQ to support dynamic switching between 1ms TTI and sTTI”,Athens,Greece13th-17th February 2017.]。
3)具有高可靠性要求的多播传输。在LTE R13中引入了单小区点到多点(SingleCell Point To Multiploint,简称SC-PTM)多播技术,[2]以组无线网络临时标识group-RNTI加扰的物理下行控制信道PDCCH和物理下行共享信道PDSCH在单播子帧上发送调度信息和多播数据[参考文献2:3GPP TR 36.890,“Study on single-cell point-to-multipoint transmission”,June 2015.]。传统的多播业务对传输的可靠性要求不高,因此在目前的SC-PTM传输中暂不支持HARQ反馈机制。然而,在最近的研究中,提出使用SC-PTM机制传输一些对可靠性要求更高的业务,例如在车联网技术V2X中,基站向一组用户转发来自某一用户或V2X应用服务器的消息。对于这类具有高可靠性要求的下行多播传输,提出需要引入对HARQ反馈机制的支持。由于一个用户可能支持多种SC-PTM业务,即对应多个group-RNTI,导致用户需要增加大量的HARQ进程。
在上述的三个场景中,需要在用户端增加更多的HARQ进程和相应的软比特缓存来支持下行数据的缓存和合并。事实上,只需要针对接收失败的数据对软比特进行缓存,以提高重传时接收的成功率;对于已经成功接收的数据,将其放入软比特进行缓存是不必要的。考虑到用户对于大部分的下行数据在初传时就可以接收成功,例如采用自适应编码调制(Adaptive Modulation and Coding,AMC)技术可以将初次传输的成功率提高至90%,因此可以认为,用户为所有的HARQ进程固定配置软比特缓存是不必要的。对于以上需要增加HARQ进程的场景,可以在用户端采用较少的HARQ缓存来支持较多的HARQ进程,从而降低用户终端的成本。
综上,本发明期望解决的问题可以总结如下:在载波聚合、sTTI和支持HARQ的多播传输等场景下,用户端需要更多的HARQ进程和缓存空间。在载波聚合中,用户最多需要40个HARQ进程来支持5个分量载波上的下行数据传输;在sTTI中,用户需要12个HARQ进程支持度为两个OFDM符号的sTTI传输;在SC-PTM中,需要增加用于多播的HARQ进程,数量与用户支持的多播业务和每个业务所需的HARQ进程数有关。而事实上对于成功接收的数据,将相应的软比特放入HARQ缓存是不必要的,因此为每个HARQ进程分配固定的软比特缓存是对缓存资源的浪费,会增加用户终端的成本。
发明内容
本发明的目的是为了解决由于载波聚合、sTTI、支持HARQ反馈重传的SC-PTM等技术的引入,需要在用户端增加更多的HARQ进程和缓存空间的问题。而事实上对于成功接收的数据,软比特的缓存是不必要的,而且在目前的通信系统中,大部分的数据在初传时可以被成功接收,为解决上述问题,本发明中提出一种在用户端复用HARQ进程的方法,可以用更少的HARQ进程和缓存空间支持在上述场景中的下行传输。
本发明提供的一种在用户端复用HARQ进程的方法,具体包括:
将HARQ进程分为物理HARQ进程和逻辑HARQ进程,其中,物理HARQ进程是用户端实际存在的软比特缓存空间,逻辑HARQ进程是用户端在基站发送的下行控制信息DCI中获得的HARQ进程号;
在用户端建立物理进程存储表和逻辑进程存储表;所述的物理进程存储表包括每个物理HARQ进程的状态、物理HARQ进程与逻辑HARQ进程的映射关系、以及物理HARQ进程对应的缓存地址。所述的逻辑进程存储表存储在用户端的各逻辑HARQ进程的期待接收NDI;NDI为新数据指示符;
所述的每个物理HARQ进程的状态分为两种:ACK和NACK;ACK表示最近一次数据接收或接收合并成功;NACK表示最近一次数据接收或接收合并失败;
用户下行传输接收失败时,在本地选择可用的物理HARQ进程缓存软比特,并在物理进程存储表中记录逻辑HARQ进程和物理HARQ进程之间的映射关系,在逻辑进程存储表中保持该逻辑HARQ进程的期待接收NDI不变;用户下行传输接收成功时,只在逻辑进程存储表中翻转该逻辑HARQ进程对应的期待接收NDI,不缓存软比特。
所述的可用的物理HARQ进程为状态为ACK的物理HARQ进程。
在用户下行传输接收失败时,若物理进程存储表中没有状态为ACK的物理HARQ进程时,则采用以下两种处理方式:(1)不缓存当前接收失败的数据;(2)选择一个状态为NACK的物理HARQ进程,并用当前接收失败的新数据覆盖该进程中原有的软比特。
所述的物理进程存储表,还存储有物理HARQ进程对应的逻辑HARQ进程的数据重传次数和数据优先级。
在用户下行传输接收失败时,若物理进程存储表中没有状态为ACK的物理HARQ进程时,在状态为NACK的物理HARQ进程中,选取重传次数最少的物理HARQ进程,作为可用的物理HARQ进程。或者,对当前接收失败的下行传输的数据优先级与状态为NACK的各物理HARQ进程的数据优先级进行比较,如果当前接收失败的下行传输的数据优先级最低,放弃缓存该数据,否则选取数据优先级最低的物理HARQ进程,作为可用的物理HARQ进程。
本发明方法中,用户端对下行传输的处理过程包括:
步骤1、当用户接收到下行传输时,判断下行传输中的NDI是否与用户端逻辑进程表中存储的与下行传输中包含的逻辑HARQ进程所对应的期待接收NDI相同;若不相同,放弃接收本次传输;若相同,继续执行下一步;
步骤2、在物理进程存储表中查找该下行传输中包含的逻辑HARQ进程所对应的物理HARQ进程,若没有查找到,则执行步骤3,若查找到,执行步骤4;
步骤3、用户接收本次下行传输,若接收成功,在逻辑进程存储表中将该逻辑HARQ进程的期待接收NDI翻转;若接收失败,保持逻辑进程存储表中该逻辑HARQ进程的期待接收NDI不变,选择可用的物理HARQ进程缓存本次下行传输的软比特,并在物理进程存储表中存储物理HARQ进程与逻辑HARQ进程的映射关系、重传次数和数据优先级,更新所选物理HARQ进程的状态;结束对本次下行传输的处理;
步骤4、将本次下行传输数据与物理进程存储表中对应的物理缓存的软比特进行合并,继续执行下一步;
步骤5、若本次下行传输对应的物理缓存的软比特合并成功,下行传输数据接收成功,则清空物理进程存储表中该物理进程对应的缓存内容,翻转逻辑进程存储表中下行传输对应的逻辑HARQ进程的期待接收NDI;否则,在物理进程存储表中缓存本次下行传输的软比特,保持逻辑进程存储表中的该逻辑HARQ进程的期待接收NDI不变;结束对本次下行传输的处理。
本发明的优点与积极效果在于:
(1)通过本发明提出的方法,节省了用户端需要的HARQ进程数量;
(2)通过本发明提出的方法,节省了用户端需要的缓存空间,适用于载波聚合、sTTI、支持HARQ反馈重传的SC-PTM等场景。
附图说明
图1是本发明实施例中载波聚合用户N个物理HARQ进程的状态示意图;
图2是本发明在图1情况下载波聚合用户选择HARQ进程的方式示意图;
图3是本发明在图2情况下载波聚合用户物理HARQ进程到逻辑HARQ进程的映射表示意图;
图4是本发明实施例中sTTI用户的8个物理HARQ进程的状态示意图;
图5是本发明在图4情况下sTTI用户选择物理HARQ进程的方式示意图;
图6是本发明在图5情况下sTTI用户物理HARQ进程到逻辑HARQ进程的映射表示意图;
图7是本发明实施例一个多播用户组中三个用户的物理HARQ进程状态示意图;
图8是本发明在图7情况下多播用户选择物理HARQ进程的方式示意图;
图9是本发明在图8情况下多播用户物理HARQ进程到逻辑HARQ进程的映射表示意图;
图10是本发明用户更新逻辑HARQ进程对应期待NDI的方式示意图;
图11是本发明用户端对下行传输的处理流程图;
图12是本发明传统用户端HARQ相关存储示意图;
图13是本发明用户端物理HARQ进程对应存储表示意图;
图14是本发明用户端逻辑HARQ进程对应存储表示意图;
图15是本发明重传接收成功情况下物理HARQ进程对应存储表变化示意图;
图16是本发明NACK进程被覆盖情况下物理HARQ进程对应存储表变化示意图。
具体实施方式
下面将结合附图和实施例对本发明作进一步的详细说明。
在现有的LTE标准中,基站在DCI中指示HARQ进程号以及新数据指示符NDI,对于同一进程NDI没有翻转表示当前传输是对之前数据包的重传,用户将当前接收到的数据与对应HARQ进程中的软比特进行合并;若NDI翻转表示当前传输是新的数据包,用户清空对应HARQ进程中旧的软比特,并存入新数据包的软比特。事实上,用户只需要对接收失败的数据缓存软比特,对于成功接收的数据,不需要接收额外的重传,即不需要缓存相应的软比特。而对于大部分数据,用户在初传时可以成功接收。
本发明提出了一种复用HARQ进程的方法,将HARQ进程分为逻辑HARQ进程和物理HARQ进程两种。物理HARQ进程是在用户端实际存在的软比特缓存,下面简称物理进程。逻辑HARQ进程是用户端在基站发送的下行控制信息DCI中获得的HARQ进程号,下面简称逻辑进程。基站按照传统的方式对同一数据包的初传和重传指示采用相同的HARQ进程号进行发送。用户对于接收到的下行传输,将DCI中的HARQ进程号视为逻辑进程号,并不需要将数据的软比特缓存在这个逻辑进程号对应的缓存空间中,而是缓存在用户自己选择的一个物理进程中,并在用户端建立物理进程和逻辑进程的映射关系,且对于成功接收的数据包,不缓存软比特。通过这样的方式,基站在DCI中指示的多个逻辑进程在用户端可以复用为更少的物理进程。例如在长度为两个OFDM符号的sTTI传输场景下,以FDD为例,12个逻辑进程可以复用现有的8个物理进程,例如,对于DCI中指示的逻辑进程号为X(0≤X≤11)的下行数据,若用户接收成功则不缓存该数据,若接收失败可以将软比特缓存在某个可用的物理进程中,其中,当某个物理进程的最近一次接收合并正确时被认为是可用的物理进程。
本发明的复用HARQ进程的方法,在用户端的实现技术手段具体是:将HARQ进程分为逻辑进程和物理进程,在用户端建立物理进程存储表和逻辑进程存储表,分别用于存储与物理进程和逻辑进程相关的信息。
在物理进程存储表中,至少存储的数据包括:用户端每个HARQ物理进程的状态,以及各物理进程与逻辑进程的映射关系、各物理进程缓存软比特的空间地址。物理进程存储表中的每个物理进程都对应一个缓存软比特的空间。所述的映射关系即物理进程对应要缓存的逻辑进程。在逻辑进程存储表中存储在用户端的各逻辑进程的期待接收的NDI。
每个HARQ物理进程的状态具体标记为两种:ACK:表示最近一次数据接收或接收合并成功;NACK:表示最近一次数据接收或接收合并失败。
当用户接收下行传输失败时,用户在本地寻找可用的物理进程,优先选取标记为ACK的进程进行缓存,并建立物理进程到逻辑进程的映射关系。当接收下行传输成功时,用户不缓存数据,也不需要建立物理进程即逻辑进程的映射关系。
以下分别对载波聚合、sTTI、SCPTM场景下的应用进行阐述。
1)载波聚合。对于载波聚合的场景,用户端需要的物理进程数量,与它所能支持的分量载波数量有关,假设一个支持5个分量载波的用户,它的物理进程数为N,当前各个物理进程的状态如图1所示,在下行数据到来时,如图2所示,用户将各个分量载波DCI中指示的HARQ进程号都当作逻辑进程,将传输失败的数据存储在自己选择的可用物理进程中,并建立物理进程和逻辑进程以及分量载波编号直接的映射关系,映射表如图3所示。
图2示例中,分量载波CC1的DCI中指示的HARQ进程0接收成功,分量载波CC2的DCI中指示的HARQ进程1接收失败,将HARQ进程1的数据存储在所选择的可用物理进程2中,并在映射表中记载,如图3所示。
2)sTTI。对于sTTI的场景,在本发明中假定可以复用现有的8个物理进程来支持12个HARQ进程。假设一个sTTI用户当前的物理进程状态如图4所示,在下行数据到来时,如图5所示,用户将DCI中指示的HARQ进程号当作逻辑进程,将传输失败的数据存储在自己选择的可用物理进程中,并建立物理进程和逻辑进程间的映射关系,映射表如图6所示。
如图5所示,用户接收标记HARQ进程9的下行数据失败,将传输失败的数据存储在选择的物理进程4中,并在映射表中记载,如图6所示。
3)多播传输。对于多播传输的场景,由于多播业务需要的HARQ进程较少,因此本发明中假定多播业务复用现有的8个HARQ进程即可。以组内的三个用户为例,它们当前的物理进程状态如图7所示,当下行数据到来时,如图8所示,用户将多播和单播DCI中指示的HARQ进程号都当作逻辑进程,将传输失败的数据存储在自己选择的可用物理进程中,并建立对应的映射表如图9所示。
如图8所示,对于DCI中指示为HARQ进程0的多播下行数据,组内三个用户都接收失败,用户1将传输失败的数据存储到物理进程4中,用户2将数据存储到物理进程1中,用户3将传输失败的数据存储到物理进程4中。而同时,DCI中指示为HARQ进程0的单播下行数据传输给用户3也失败,用户3将该单播数据存储到物理进程3中。3个用户在本地的映射表如图9所示。
在上述场景中,若用户当前接收数据失败但没有可用的状态为ACK的物理进程时,则有以下两种处理方式:
(1)不缓存当前接收失败的数据;
(2)选择一个状态为NACK的物理进程,并用当前接收失败的新数据覆盖该物理进程中原有的软比特。
用户可以根据业务的类型或优先级选择丢弃接收当前数据,或覆盖某一状态为NACK的物理进程中的软比特。例如,对于V2X业务,DCI中可能会包含数据的优先级信息,对于优先级低的数据,用户可选择丢弃当前数据,对于优先级高的数据,用户可在状态为NACK的物理进程中选择优先级较低的进程,并覆盖掉该进程中存储的内容。另外,对于NACK物理进程的选择,可以考虑选择重传次数较少的进程,因为重传次数较少意味着用户端积累的软比特较少,则覆盖该NACK进程带来的浪费或造成的影响更小。对于多播传输的场景,优先选择覆盖单播业务所使用的状态为NACK的物理进程似乎更为合理,因为多播的传输涉及到多个用户,若被覆盖,会增加后续处理的复杂度。因此,为了解决用户端没有可用ACK进程时选择覆盖哪个NACK进程的问题,可以在用户端存储的物理进程存储表中还存储有每个物理进程对应的逻辑进程的数据重传次数和数据优先级。
对于NDI的处理,在传统方法中,用户通过比较DCI中的NDI和用户端相应进程的NDI,若翻转则为新传,用户清空进程中之前的软比特并存入新的软比特;若不翻转则为重传,用户将接收到的数据与之前的软比特进行合并。而在本发明中,对于成功接收的数据,不在物理进程中进行缓存,且一些逻辑进程与物理进程的映射关系和缓存可能被后来的传输所覆盖,因此在本发明中不在物理进程存储表中存储接收到的NDI,而对逻辑进程存储表中存储用户期待接收的NDI,避免用户在成功接收数据后,尤其是在多播传输中,接收后续不必要的重传。对于成功接收的数据,用户期待翻转的NDI,对于接收失败的数据,用户期待不变的NDI。以SC-PTM场景为例,如图10所示,若用户当前某逻辑进程的期待NDI为0,当接收到该逻辑进程的下行传输时,若接收成功则将该逻辑进程的期待NDI存为1;若接收失败则继续将期待NDI存为0。
在下行传输接收失败时,用户在本地选择合适的物理进程缓存软比特,并建立逻辑进程和物理进程之间的映射关系,保持该逻辑进程对应的期待NDI不变。用户在下行传输接收成功时,只翻转该逻辑进程对应的期待NDI,不缓存软比特。
本发明涉及的用户端对下行传输的处理流程如图11所示,用户在接收到下行传输,包括物理下行控制信道PDCCH和物理下行数据信道PDSCH时,查找下行控制信息中包含的NDI是否存在用户端的逻辑进程存储表中,将接收的NDI依次与逻辑进程存储表中记载的期待接收的NDI进行比较。如果存在,则是期待接收的下行传输,如果不存在则不是用户端期待接收的下行传输。
若用户判断本次下行传输不是用户端期待的下行传输,则放弃接收本次传输;
若用户端判断本次下行传输是用户期待接收的下行传输,则尝试在物理进程存储表中查找该下行传输的下行控制信息中包含的逻辑HARQ进程与物理HARQ进程的映射关系;
若没有在物理进程存储表中找到该逻辑HARQ进程对应的物理HARQ进程,则用户接收这次下行传输;若接收成功,用户翻转逻辑进程存储表中该逻辑进程的期待接收NDI;
若接收失败,用户端保持逻辑进程存储表中该逻辑进程的期待接收NDI不变,用户端自发选择可用的物理HARQ进程,并在物理进程存储表中存储物理HARQ进程与逻辑HARQ进程的映射关系、数据的软比特、重传次数、数据优先级,并更新所选物理进程的状态;
若在物理进程存储表中找到该逻辑HARQ进程对应的物理HARQ进程,则将本次下行传输与物理进程存储表中缓存的软比特进行合并;
若接收成功,用户清空物理进程存储表中该物理进程对应的存储内容,并翻转逻辑进程存储表中的期待NDI;
若接收失败,用户在物理进程存储表中缓存本次下行传输的软比特,并保持逻辑进程存储表中的期待NDI不变。
综上所述,在传统HARQ进程处理中,如图12所示用户,每一个物理进程存储软比特和NDI。而在本发明中将这个存储表拆分为物理进程存储表和逻辑进程存储表,分别如图13、图14所示(以SC-PTM场景为例),在如图13所示的物理进程存储表中,记录物理缓存的编号、存储物理进程到逻辑进程的映射关系、软比特缓存位置、进程状态、以及重传次数、数据优先级等,在逻辑进程存储表中存储用户期待接收的NDI。用户在下行传输接收成功时,不缓存软比特,不建立物理进程与逻辑进程之间的映射关系,只翻转该逻辑进程对应的期待NDI;在下行传输接收失败时,用户在本地选择合适的物理进程缓存软比特,并建立逻辑进程和物理进程之间的映射关系,保持该逻辑进程对应的期待NDI不变。如图15所示,当接收失败的数据在之后的重传中接收成功,则清空该物理进程中的软比特,并删除该物理进程与逻辑进程间的映射关系,以及该物理进程对应的重传次数和优先级信息等。另外,如图16所示,当NACK进程被覆盖时,该物理进程原有的映射关系、缓存软比特、重传次数、优先级信息等均被新数据的信息所覆盖。
Claims (8)
1.一种复用混合自动重传请求HARQ进程的方法,其特征在于,该方法包括:
将HARQ进程分为物理HARQ进程和逻辑HARQ进程,其中,物理HARQ进程是用户端实际存在的软比特缓存空间,逻辑HARQ进程是用户端在基站发送的下行控制信息DCI中获得的HARQ进程号;
在用户端建立物理进程存储表和逻辑进程存储表;所述的物理进程存储表包括每个物理HARQ进程的状态、物理HARQ进程与逻辑HARQ进程的映射关系以及各物理HARQ进程缓存软比特的空间地址;所述的逻辑进程存储表存储在用户端的各逻辑HARQ进程的期待接收NDI;NDI为新数据指示符;
所述的每个物理HARQ进程的状态分为两种:ACK和NACK;ACK表示最近一次数据接收或接收合并成功;NACK表示最近一次数据接收或接收合并失败;
用户下行传输接收失败时,在本地选择可用的物理HARQ进程缓存软比特,并在物理进程存储表中记录逻辑HARQ进程和物理HARQ进程之间的映射关系,在逻辑进程存储表中保持该逻辑HARQ进程的期待接收NDI不变;用户下行传输接收成功时,只在逻辑进程存储表中翻转该逻辑HARQ进程对应的期待接收NDI,不缓存软比特。
2.根据权利要求1所述的方法,其特征在于,所述的可用的物理HARQ进程为状态为ACK的物理HARQ进程。
3.根据权利要求1或2所述的方法,其特征在于,所述的方法在用户下行传输接收失败时,若物理进程存储表中没有状态为ACK的物理HARQ进程时,则采用以下两种处理方式:(1)不缓存当前接收失败的数据;(2)选择一个状态为NACK的物理HARQ进程,并用当前接收失败的新数据覆盖该进程中原有的软比特。
4.根据权利要求1所述的方法,其特征在于,所述的物理进程存储表,还存储有物理HARQ进程对应的逻辑HARQ进程的数据重传次数和数据优先级。
5.根据权利要求4所述的方法,其特征在于,所述的方法在用户下行传输接收失败时,若物理进程存储表中没有状态为ACK的物理HARQ进程时,在状态为NACK的物理HARQ进程中,选取重传次数最少的物理HARQ进程,作为可用的物理HARQ进程。
6.根据权利要求4所述的方法,其特征在于,所述的方法在用户下行传输接收失败时,若物理进程存储表中没有状态为ACK的物理HARQ进程时,对当前接收失败的下行传输的数据优先级与状态为NACK的各物理HARQ进程的数据优先级进行比较,如果当前接收失败的下行传输的数据优先级最低,放弃缓存该数据,否则选取数据优先级最低的物理HARQ进程,作为可用的物理HARQ进程。
7.根据权利要求3所述的方法,其特征在于,所述的方法应用在多播传输场景时,当在用户下行传输接收失败时,物理进程存储表中没有状态为ACK的物理HARQ进程时,优先选择覆盖单播业务所使用的状态为NACK的物理进程。
8.根据权利要求1所述的方法,其特征在于,所述的方法,用户端对下行传输的处理过程包括:
步骤1、当用户接收到下行传输时,判断下行传输中的NDI是否与用户端逻辑进程表中存储的与下行传输中包含的逻辑HARQ进程所对应的期待接收NDI相同;若不相同,放弃接收本次传输;若相同,继续执行下一步;
步骤2、在物理进程存储表中查找该下行传输中包含的逻辑HARQ进程所对应的物理HARQ进程,若没有查找到,则执行步骤3,若查找到,执行步骤4;
步骤3、用户接收本次下行传输,若接收成功,在逻辑进程存储表中将该逻辑HARQ进程的期待接收NDI翻转;若接收失败,保持逻辑进程存储表中该逻辑HARQ进程的期待接收NDI不变,选择可用的物理HARQ进程缓存本次下行传输的软比特,并在物理进程存储表中存储物理HARQ进程与逻辑HARQ进程的映射关系、重传次数和数据优先级,更新所选物理HARQ进程的状态;结束对本次下行传输的处理;
步骤4、将本次下行传输数据与物理进程存储表中对应的物理缓存的软比特进行合并,继续执行下一步;
步骤5、若本次下行传输对应的物理缓存的软比特合并成功,下行传输数据接收成功,则清空物理进程存储表中该物理HARQ进程对应的存储信息,修改该物理HARQ进程的状态为ACK,翻转逻辑进程存储表中下行传输对应的逻辑HARQ进程的期待接收NDI;否则,在物理进程存储表中缓存本次下行传输的软比特,保持逻辑进程存储表中的该逻辑HARQ进程的期待接收NDI不变;结束对本次下行传输的处理。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810551657.5A CN108768597B (zh) | 2018-05-31 | 2018-05-31 | 一种复用harq进程的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810551657.5A CN108768597B (zh) | 2018-05-31 | 2018-05-31 | 一种复用harq进程的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108768597A true CN108768597A (zh) | 2018-11-06 |
CN108768597B CN108768597B (zh) | 2020-09-25 |
Family
ID=64001289
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810551657.5A Active CN108768597B (zh) | 2018-05-31 | 2018-05-31 | 一种复用harq进程的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108768597B (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2020133235A1 (zh) * | 2018-12-28 | 2020-07-02 | 华为技术有限公司 | 下行控制信息处理方法、装置、终端设备及通信系统 |
CN111385064A (zh) * | 2020-03-31 | 2020-07-07 | 展讯通信(上海)有限公司 | 数据传输方法、装置、电子设备及存储介质 |
WO2021164036A1 (zh) * | 2020-02-21 | 2021-08-26 | 华为技术有限公司 | 一种数据传输方法及装置 |
CN113395733A (zh) * | 2021-07-30 | 2021-09-14 | 上海瀚讯信息技术股份有限公司 | 基于优化harq缓存利用率的提升基站用户容量的方法 |
WO2021218949A1 (zh) * | 2020-04-30 | 2021-11-04 | 华为技术有限公司 | 通信方法和装置 |
CN113875178A (zh) * | 2019-09-30 | 2021-12-31 | 华为技术有限公司 | 一种通信方法及装置 |
WO2022099514A1 (zh) * | 2020-11-11 | 2022-05-19 | Oppo广东移动通信有限公司 | 无线通信方法和设备 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102158330A (zh) * | 2011-04-22 | 2011-08-17 | 中兴通讯股份有限公司 | Harq合并存储空间的处理方法及装置 |
CN103078721A (zh) * | 2011-10-25 | 2013-05-01 | 联芯科技有限公司 | 混合自适应重传请求方法及终端 |
CN104158639A (zh) * | 2013-05-14 | 2014-11-19 | 电信科学技术研究院 | 一种码合并缓存分配方法及装置 |
US20180092071A1 (en) * | 2016-09-24 | 2018-03-29 | Ofinno Technologies, Llc | Transport block transmission in a wireless device and wireless network |
-
2018
- 2018-05-31 CN CN201810551657.5A patent/CN108768597B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102158330A (zh) * | 2011-04-22 | 2011-08-17 | 中兴通讯股份有限公司 | Harq合并存储空间的处理方法及装置 |
CN103078721A (zh) * | 2011-10-25 | 2013-05-01 | 联芯科技有限公司 | 混合自适应重传请求方法及终端 |
CN104158639A (zh) * | 2013-05-14 | 2014-11-19 | 电信科学技术研究院 | 一种码合并缓存分配方法及装置 |
US20180092071A1 (en) * | 2016-09-24 | 2018-03-29 | Ofinno Technologies, Llc | Transport block transmission in a wireless device and wireless network |
Non-Patent Citations (1)
Title |
---|
KAZUAKI TAKEDA ; YUTA SAGAE ; NAOTO OHKUBO ; HIROYUKI ISHII: ""Investigation on Rate Matching and Soft Buffer Splitting for LTE-Advanced Carrier Aggregation"", 《2012 IEEE 75TH VEHICULAR TECHNOLOGY CONFERENCE》 * |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113169818B (zh) * | 2018-12-28 | 2023-04-18 | 华为技术有限公司 | 下行控制信息处理方法、装置、终端设备及通信系统 |
CN113169818A (zh) * | 2018-12-28 | 2021-07-23 | 华为技术有限公司 | 下行控制信息处理方法、装置、终端设备及通信系统 |
WO2020133235A1 (zh) * | 2018-12-28 | 2020-07-02 | 华为技术有限公司 | 下行控制信息处理方法、装置、终端设备及通信系统 |
CN113875178A (zh) * | 2019-09-30 | 2021-12-31 | 华为技术有限公司 | 一种通信方法及装置 |
CN113875178B (zh) * | 2019-09-30 | 2023-09-29 | 华为技术有限公司 | 一种通信方法及装置 |
CN115088215A (zh) * | 2020-02-21 | 2022-09-20 | 华为技术有限公司 | 一种数据传输方法及装置 |
WO2021164036A1 (zh) * | 2020-02-21 | 2021-08-26 | 华为技术有限公司 | 一种数据传输方法及装置 |
CN115088215B (zh) * | 2020-02-21 | 2024-01-02 | 华为技术有限公司 | 一种数据传输方法及装置 |
CN111385064B (zh) * | 2020-03-31 | 2021-01-05 | 展讯通信(上海)有限公司 | 数据传输方法、装置、电子设备及存储介质 |
CN111385064A (zh) * | 2020-03-31 | 2020-07-07 | 展讯通信(上海)有限公司 | 数据传输方法、装置、电子设备及存储介质 |
WO2021218949A1 (zh) * | 2020-04-30 | 2021-11-04 | 华为技术有限公司 | 通信方法和装置 |
WO2022099514A1 (zh) * | 2020-11-11 | 2022-05-19 | Oppo广东移动通信有限公司 | 无线通信方法和设备 |
CN113395733A (zh) * | 2021-07-30 | 2021-09-14 | 上海瀚讯信息技术股份有限公司 | 基于优化harq缓存利用率的提升基站用户容量的方法 |
CN113395733B (zh) * | 2021-07-30 | 2023-11-21 | 上海瀚讯信息技术股份有限公司 | 基于优化harq缓存利用率的提升基站用户容量的方法 |
Also Published As
Publication number | Publication date |
---|---|
CN108768597B (zh) | 2020-09-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108768597A (zh) | 一种复用harq进程的方法 | |
US10841045B2 (en) | Method for skipping an UL transmission in a wireless communication system and device therefor | |
US9515803B2 (en) | Apparatus and method for processing configuration information received from a base station in a wireless communication system | |
JP5721443B2 (ja) | 無線通信システムにおけるharq実行方法 | |
KR101086820B1 (ko) | 이동통신 시스템에서 복합 재전송 방법과 이를 위한 수신방법 및 장치 | |
US9425925B2 (en) | Method for operating HARQ to change dynamic resource of wiress resource in wireless communication system, and apparatus therefor | |
US8359506B2 (en) | Method of transmitting data using a plurality of HARQ process channels sequentially | |
CN102439892B (zh) | Ofdma系统中用于载波聚合的ulharq反馈格式设定方法、用户设备及基站 | |
CN104253671A (zh) | 通信方法以及无线通信终端 | |
CN101772073A (zh) | 基于时分双工系统的混合自动重传请求的实现方法和装置 | |
KR20080065880A (ko) | 무선 통신 시스템에서의 arq/harq 지원 방법 | |
KR20080065475A (ko) | 무선 통신 시스템에서의 arq/harq 지원 방법 | |
KR100975697B1 (ko) | 이동통신 시스템에서 방송 데이터의 송수신 장치 및 방법 | |
CN101615988B (zh) | 混合自动重传请求的调度方法 | |
CN108039939A (zh) | 物联网组播业务的harq反馈方法及装置 | |
KR100937299B1 (ko) | 무선통신 시스템에서 harq 수행 방법 | |
JP4940115B2 (ja) | 無線通信システム、無線端末および無線基地局 | |
CN101686434A (zh) | 一种mbms传输的反馈方法、系统及设备 | |
CN101610138B (zh) | 上行混合自动重传请求的实现方法和系统 | |
US10135577B2 (en) | Scalable service in a wireless communication system | |
CN114666026A (zh) | 一种被用于无线通信的节点中的方法和装置 | |
CN101599817B (zh) | 一种提高同步非自适应混合自动重传性能的方法 | |
CN101442795B (zh) | 上行控制信道的功率控制方法 | |
CN102342060B (zh) | 一种混合自动重传请求多进程数据管理的方法和装置 | |
CN112688763B (zh) | 一种被用于无线通信的节点中的方法和装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |