CN104144043A - 一种混合自动重传请求合并的方法 - Google Patents

Abstract

本申请公开了一种混合自动重传请求合并的方法，对于每一个业务进程，分别设置与该业务进程对应的合并标志和合并缓存，接收端接收到正常业务的PDSCH数据后，根据PCFICH指示的进程号确定该数据属于哪个业务进程；判断该业务进程对应的合并标志是否为0，若是，对本帧接收的正常业务的PDSCH数据进行单独接收，否则将本帧接收的正常业务的PDSCH数据与该业务进程对应的合并缓存中的数据合并；如果数据解码正确，则通过PUCCH反馈ACK，将该业务进程对应的合并标志置0，将该业务进程对应的合并缓存设置全0并返回；如果数据解码错误，则通过物理上行控制信道PUCCH反馈NACK，本帧数据存入该业务进程对应的合并缓存，将该业务进程对应的合并标志置1。

Description

一种混合自动重传请求合并的方法

技术领域

本申请涉及移动通信技术领域，尤其涉及一种混合自动重传请求合并的方法。

背景技术

在移动通信中，随着通信业务的不断扩展和服务质量的提高，对通信的可靠性将提出更高的要求。而在移动通信***中，无线信道是一种变参信道，其所处的环境也非常复杂。对于接收端所接收的信号来说，衰落和各种干扰所造成的误码有随机差错和突发差错，会严重损伤通信质量。因此，在移动通信***中，必须采用差错控制技术来提高信号的传输质量，从而保证信息的可靠传输。目前广泛采用的差错控制技术为混合自动重传请求（HARQ）技术。

HARQ技术是自动重传请求（ARQ）技术和前向纠错码（FEC）技术相结合的差错控制方式。HARQ在ARQ***中引入一个FEC子***，FEC子***用来纠正常出现的传输错误以减少重传次数，即在纠错能力范围内自动纠正错误，超出纠错范围才需重发。

LTE***中的HARQ采用了停等协议（SW，Stop&Wait）。在SW机制中，发送端在每发完一个数据分组后等待一个肯定应答（ACK）或否定应答（NACK）。如果接收到ACK，发端发送下一个新数据分组，如果接收到NACK，重新发送上一个数据分组。为了防止ACK/NACK接收时的错误，传输新数据时，要发送下行控制信息（DCI），在DCI中包含了一个新数据指示信息（NDI），只有NDI为1时才会发起新数据的传输。由于DCI信息有循环冗余检验（CRC）校验机制，因此可以保证NDI的出错概率很低。这样就可以避免ACK/NACK信息传输出错的情况。

在专网通信***中，资源有限，设备简单。为了节省资源常常采用半静态的传输方式，即基站通过DCI给终端分配了上下行资源后，一般不再发送新的控制信息，终端将一直占用分配的资源进行传输直到被通知停止。传输数据的ACK/NACK信息由接收端返回给发送端，发送端再根据ACK/NACK信息判断发送新数据还是重传旧数据。

在某些专网通信***中，由于采用了半静态传输方式，在传输新数据时无法像LTE***一样通过DCI中的NDI信息来进行指示，而只能通过接收端反馈的ACK/NACK信息来进行判断。ACK/NACK信息在传输时可能会出错，即接收端返回了NACK，发送端却接收成了ACK，反之亦然。如果接收端返回的是ACK信息，而发送端接收到了NACK，这时发送端会重传接收端已经正确接收的数据，接收端重复接收相同的数据。这种情况下，接收端发现接收的数据重复后会丢掉重复的数据，所以不会产生问题。但如果接收端向发送端返回了NACK信息，发送端把NACK误检为ACK信息，这种情况就会产生严重的问题。这时，发送端发送新数据，而接收端却以为接收的是重传数据并把两次接收的数据进行合并，结果就会导致数据的无法正确接收。

要解决这个问题，可以采用较传统的两种方案：

第一种方案，LTE***中采用的方法，即在DCI中添加NDI信息，每次发送新数据时传送下来。由于物理下行控制信道（PDCCH）有CRC校验，因此可以避免上述的问题。但缺点是在专网***中，PDCCH的性能较差。专网的PDCCH可占用的资源较少，所以虽然传输的只是1比特的NDI信息，但加上CRC校验位后，就会使码率提高，PDCCH的接收性能降低，***效率也会随之降低。

第二种方案，接收端对重传数据不再合并，即每次重传数据都单独接收。这样也可以避免上述问题，带来的缺点就是会损失重传合并的分集增益。

发明内容

本申请提供了一种混合自动重传请求合并的方法，既不需要新旧数据指示信令支持，又可以达到提高传输性能的目的。

本申请实施例提供了一种混合自动重传请求合并的方法，对于每一个业务进程，分别设置与该业务进程对应的合并标志和合并缓存，并将初始的合并标志和合并缓存设置为0，该方法包括：

A、接收端接收到正常业务的物理下行共享信道PDSCH数据后，根据物理控制格式指示信道PCFICH指示的进程号确定该数据属于哪个业务进程；

B、判断该业务进程对应的合并标志是否为0，若是，执行步骤C，否则执行步骤D；

C、对本帧接收的正常业务的PDSCH数据进行单独接收，然后执行步骤E；

D、将本帧接收的正常业务的PDSCH数据与该业务进程对应的合并缓存中的数据合并，然后执行步骤E；

E、如果数据解码正确，则执行步骤F，如果数据解码错误，则通过物理上行控制信道PUCCH反馈NACK，本帧数据存入该业务进程对应的合并缓存，将该业务进程对应的合并标志置1，跳转至步骤G；

F、通过PUCCH反馈ACK，将该业务进程对应的合并标志置0，将该业务进程对应的合并缓存设置全0，返回步骤A；

G、判断该业务进程是否达到最大重传次数，如果没有，则返回步骤A，如果达到最大重传，则将该业务进程对应的合并标志置0，该业务进程对应的合并缓存设置全零，返回步骤A。

较佳地，步骤A之前进一步包括：

AA1、接收端判断接收到的PDSCH业务信息类型，若是***信息，则正常接收；如果是PDSCH正常业务信息，则执行所述步骤A。

较佳地，步骤AA1之前进一步包括：

接收端接收数据后，判断PDSCH业务是否被打断，如果PDSCH业务被其他业务打断，则将该业务对应的合并标志以及合并缓存置零，正常处理其他业务；否则，执行所述步骤AA1。

从以上技术方案可以看出，通过物理控制格式指示信道（PCFICH）指示进程号，针对相同业务进程的物理下行共享信道（PDSCH）数据，根据上次译码结果和最大重传次数判断合并标志，并把合并标志作为相同业务进程的数据是否进行HARQ合并的判断条件。本申请提出的HARQ重传机制确保重传的数据是完全重复的数据来进行HARQ合并检测，既不需要新旧数据指示信令支持，又可以达到提高传输性能的目的。

附图说明

图1为本申请实施例提供的混合自动重传请求合并的方法流程图；

图2为图1中的步骤105的详细流程图。

具体实施方式

为使本申请技术方案的技术原理、特点以及技术效果更加清楚，以下结合具体实施例对本申请技术方案进行详细阐述。

本申请提供的混合自动重传请求合并的方法中，收发两端已知最大重传次数，通过物理控制格式指示信道（PCFICH）指示进程号，针对相同业务进程的物理下行共享信道（PDSCH）数据，根据上次译码结果和最大重传次数判断合并标志，并把合并标志作为相同业务进程的数据是否进行HARQ合并的判断条件。较佳地，当采用Chase重传机制时，在需要进行合并的流程中，只需要将本次数据与合并缓存的数据直接进行叠加即可作为HARQ合并的输出。在不需要进行合并的流程中，本次数据即可作为HARQ合并的输出。

本申请实施例提供混合自动重传请求合并的方法的具体流程如图1所示，包括如下步骤：

步骤101：***启动后，初始化合并标志flag和合并缓存为零。

步骤102：接收端接收数据后，判断PDSCH业务是否被其他业务打断，若是，执行步骤103，否则执行步骤104。

步骤103：将合并标志flag置零，缓存buffer置零，正常处理其他业务，然后返回步骤102。

步骤104：判断PDSCH业务信息类型：如果是***信息，则正常接收；跳转步骤102。如果是PDSCH正常业务信息，则执行步骤105。

步骤105：根据PCFICH指示的进程号确定该数据属于哪个业务进程的业务，每个业务进程按照相同的步骤进行处理，处理完毕后返回步骤102。

如图2所示，以业务进程1为例，步骤105包括如下子步骤：

子步骤105-1：确定接收到的数据是业务进程1的数据后，判断业务进程1的合并标志flag1是否为零（不合并指示）；如果合并标志flag1为零，执行子步骤105-2，如果合并标志flag1为1（合并指示），执行子步骤105-5；

子步骤105-2：对本帧接收正常业务的PDSCH数据进行单独接收；

子步骤105-3：判断数据是否解码正确，若是表示数据能正确接收，则跳到步骤105-8；如果数据解码不正确，执行子步骤105-4；

子步骤105-4：通过PUCCH反馈NACK，本帧数据存入业务进程1的合并缓存buffer1，合并标志flag1置1（合并指示），表示本帧数据可以被合并；跳到步骤105-9；

子步骤105-5：本帧数据与缓存buffer1合并；

子步骤105-6：判断合并后的数据是否解码正确，若是，跳到步骤105-8；如果数据解码不正确，执行子步骤105-7；

子步骤105-7：通过PUCCH反馈NACK，本帧数据存入缓存buffer1，合并标志flag1置1，表示本帧数据可以被合并；跳到步骤105-9。

步骤105-8：PUCCH反馈ACK，合并标值flag1置0，缓存buffer1设置全零，返回步骤102。

步骤105-9：判断业务进程1是否达到最大重传次数，如果没有，则返回步骤102，如果达到最大重传，执行步骤105-10；

步骤105-10：合并标志flag1置0，缓存buffer1设置全零，返回步骤102。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请的保护范围，凡在本申请技术方案的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (3)

1.一种混合自动重传请求合并的方法，其特征在于，对于每一个业务进程，分别设置与该业务进程对应的合并标志和合并缓存，并将初始的合并标志和合并缓存设置为0，该方法包括：

A、接收端接收到正常业务的物理下行共享信道PDSCH数据后，根据物理控制格式指示信道PCFICH指示的进程号确定该数据属于哪个业务进程；

B、判断该业务进程对应的合并标志是否为0，若是，执行步骤C，否则执行步骤D；

C、对本帧接收的正常业务的PDSCH数据进行单独接收，然后执行步骤E；

D、将本帧接收的正常业务的PDSCH数据与该业务进程对应的合并缓存中的数据合并，然后执行步骤E；

E、如果数据解码正确，则执行步骤F，如果数据解码错误，则通过物理上行控制信道PUCCH反馈NACK，本帧数据存入该业务进程对应的合并缓存，将该业务进程对应的合并标志置1，跳转至步骤G；

F、通过PUCCH反馈ACK，将该业务进程对应的合并标志置0，将该业务进程对应的合并缓存设置全0，返回步骤A；

G、判断该业务进程是否达到最大重传次数，如果没有，则返回步骤A，如果达到最大重传，则将该业务进程对应的合并标志置0，该业务进程对应的合并缓存设置全零，返回步骤A。

2.根据权利要求1所述的方法，其特征在于，步骤A之前进一步包括：

AA1、接收端判断接收到的PDSCH业务信息类型，若是***信息，则正常接收；如果是PDSCH正常业务信息，则执行所述步骤A。

3.根据权利要求2所述的方法，其特征在于，步骤AA1之前进一步包括：

接收端接收数据后，判断PDSCH业务是否被打断，如果PDSCH业务被其他业务打断，则将该业务对应的合并标志以及合并缓存置零，正常处理其他业务；否则，执行所述步骤AA1。