一种LTE数据面下行检错纠错方法与流程

本发明涉及一种LTE技术，尤其涉及一种LTE数据面下行检错纠错方法。

背景技术：

LTE是由3GPP组织制定的UMTS技术标准的长期演进。LTE系统结构可以分为接入层(AS)和非接入层(NAS)。其中，接入层包括L1、L2和L3三个部份。其中L2包括MAC(Medium Access Control，媒体接入层)、RLC(Radio Link Control，无线链路控制)和PDCP(Packet Data Convergence Protocal，分组数据汇聚协议)。

LTE数据面协议规定了L2各层的功能和数据的处理流程。在实际应用中，系统可能会由于长时间高负荷运行、温度过热导致硬件错误，或者其他系统软件模块设计缺陷导致内存覆盖，从而发生数据错误的情况。数据面协议并没有严格规定错误数据的处理方式，一般而言，如果数据面能够检测出数据错误，那么将错误数据丢弃即可。在某些情况下，还需要通知高层进行链路的重建。

实际环境下存在一种情况：当数据发生了错误，数据面无法判定丢弃。更严重的是，错误的数据接收将会导致后面正确的数据被错误的丢弃，并在较长一段时间都无法恢复正常，严重影响数据吞吐量。

1、以AM(Acknowledged Mode，确认模式)为例，当PDCP层接收到RLC层AMDRB(Data Radio Bearer carrying user plane data，数据无线承载携带用户面数据)数据时，不考虑头解压缩和解密过程，如图1所示，协议按如下流程处理：

a、条件1：如果接收到的PDCP SN–Last_Submitted_PDCP_RX_SN>Reordering_Window或者0<＝Last_Submitted_PDCP_RX_SN–接收到的PDCP SN<Recordering_Window：则丢弃此数据；

b、条件2：如果Next_PDCP_RX_SN–接收的PDCP SN>Reordering_Window：将Next_PDCP_RX_SN置为接收到的PDCP SN+1；缓存此数据待进一步处理

c、条件3：如果接收的PDCP SN–Next_PDCP_RX_SN>＝Reordering_Window：缓存此数据待进一步处理；

d、条件4：如果接收到的PDCP SN>＝Next_PDCP_RX_SN：将Next_PDCP_RX_SN置为接收到的PDCP SN+1；如果Next_PDCP_RX_SN大于Maximum_PDCP_SN：将Next_PDCP_RX_SN置为0；缓存此数据待进一步处理；

e、条件5：如果接收到的PDCP SN<Next_PDCP_RX_SN：缓存此数据待进一步处理；

对没有丢弃的数据进行解密和头解压缩处理，之后递交给高层。

将Last_Submitted_PDCP_RX_SN置为最后递交给高层的PDCP SDU的PDCP SN值。

其中，SN代表接收的PDCP序列号，Last_Submitted_PDCP_RX_SN表示上次PDCP递交给上层数据的SN；Reordering_Window表示序列号空间50％长度的重排序窗，对于AM DRB，其大小等于2048；Next_PDCP_RX_SN表示下一个预期接收的PDCP SN；Maximum_PDCP_SN在AM DRB情况下，等于4095。

其中，需要强调的条件3和5，这是在重建场景下才会出现的情况：重建之后，SN不连续的数据会先被缓存而不递交给高层，不更新Last_Submitted_PDCP_RX_SN，从而保证在重建之后可以接收到PDCP SN比重建时递交的PDCP SN更小的数据。下面描述的出错场景，是在非重建情况下产生的。

步骤一：如图2所示，假设当前Next_PDCP_RX_SN＝X，当PDCP从RLC接收到一个错误的下行数据，其PDCP SN原本为X，但由于异常情况被篡改成Y(并且Y>X)。此时，错误数据不满足上述条件1，而满足上述条件4(或条件2，示意图略)；

步骤二：如图3所示，PDCP无法得知PDCP SN＝Y的数据是错误数据，因此会处理并递交数据，并更新Last_Submitted_PDCP_RX_SN＝Y，Next_PDCP_RX_SN＝Y+1；

步骤三：正常非重建情况下，PDCP收到的下行数据是SN增序的。因此，如果PDCP收到下一个数据是正确的，那么其SN会大于等于步骤一时的 Next_PDCP_RX_SN(即为X)，即接收到的PDCP SN＝X+n(常规情况下n＝1)。

参考前述PDCP协议处理流程，可以发现当前的情况符合协议处理流程中的条件1，并且对于任何下行数据，其PDCP SN＝X+n，且X+n<＝Y，都会被按协议流程要求处理丢弃。而在真实场景下，这部分数据很可能是正确的。

因此，从以上流程可以得知，一旦数据的PDCP SN从X错误地变成Y，那么之后PDCP SN从X+1到Y之间的所有接收到的数据都会被丢弃。在最严重的情况下(Y-X＝2047)，PDCP一共将会丢弃2047个数据包。

2、以UM(Unacknowledged Mode，非确认模式)为例，当PDCP层接收到RLC层下行UM的DRB数据时，协议规定UE按如下流程处理：

a、如果接收到的PDCP SN<Next_PDCP_RX_SN：将RX_HFN增加1；使用基于RX_HFN的COUNT值与接收到的PDCP SN值，解密此PDCP Data PDU；将Next_PDCP_RX_SN置为接收到的PDCP SN值+1；

b、如果Next_PDCP_RX_SN>Maximum_PDCP_SN：将Next_PDCP_RX_SN置为0；将RX_HFN增加1；执行已解密PDCP Data PDU的头解压缩；

c、将最后产生的PDCP SDU递交给上层。

UM DRB数据处理流程相对简单，只需要判断接收到的PDCP SN和期望的PDCP SN之间的大小关系，据此来算出COUNT值。然后通过COUNT值来解密PDCP数据。以下描述一种出错场景：

由于UM模式下，协议设计不会有重发数据。因此正常情况下，一旦接受到PDCP SN小于期望的SN时，就会认为PDCP SN发生了翻转，RX_HFN需要更新加1。RX_HFN是计算COUNT值的参数之一(另一个是PDCP SN)，而COUNT值又是解密参数之一，如果COUNT值错误，那么解密势必就会出错。所以，一旦PDCP在收到一个错误的UM模式数据，而恰好其PDCP SN大于期望的SN，那么就会错误的更新COUNT值，导致后续所有数据都会解密失败。

技术实现要素：

为解决上述技术问题，本发明的目的是提供一种LTE数据面下行检错纠错方法，无论AM还是UM模式下，均用以防止数据在空口以及系统内部传输时发生错误，导致LTE数据面在一段时间内数据无法正常接收的情形，在保证LTE 数据面高度健壮性的同时，也能够及时监测错误并纠正，从而保证数据在高吞吐量下的正常传输。

本发明的LTE数据面下行检错纠错方法，包括以下步骤：

S1、接收PDCP数据包、并解析当前接收的PDCP数据包的SN号，判断其是否等于预期接收的PDCP数据包的SN号，若是则依次完成步骤S2和S5，若否则标记该PDCP数据包、并备份该PDCP数据包的上下文后进入步骤S2；

S2、按PDCP协议对该PDCP数据包执行解密和解头压缩过程后进入步骤S3；

S3、判断该PDCP数据包是否满足正确的IP协议报头格式，若是则进入步骤S5，若否则进入步骤S4；

S4、丢弃步骤S1中标记的PDCP数据包，并还原备份的PDCP数据包的上下文；

S5、按PDCP协议处理该PDCP数据包后递交给高层。

进一步的，所述PDCP数据包的上下文包括上次递交给高层的PDCP数据包的SN号、以及预期接收的PDCP数据包的SN号。

进一步的，所述步骤S3中对于PDCP数据包是否满足正确的IP协议报头格式的判断，按IP协议的IP报头结构分为ipv4包头格式比对和ipv6包头格式比对两种方式。

具体的，所述ipv4包头格式比对包括目的IP地址比对、源IP地址比对、版本号比对、头长度比对、服务类型比对、数据包长度比对、标识比对、df mf偏移量比对、生存时间比对、传输协议比对以及头标校验和比对，具体使用过程中ipv4包头格式比对过程可选择其中之一个或多个。

具体的，所述ipv6包头格式比对包括目的IP地址比对、源IP地址比对、版本号比对、优先级比对、流量标识比对、数据长度比对、跳数限制比对、以及下一包头比对，具体使用过程中ipv6包头格式比对过程可选择其中之一个或多个。

具体的，所述目的IP地址比对为将解析出PDCP数据包的目的IP地址与用户设备自身的IP地址进行比对。

进一步的，所述步骤S4还包括保持预期接收的PDCP数据包的SN号的过程。

进一步的，所述步骤S5还包括修改预期接收的PDCP数据包的SN号的过程。

借由上述方案，本发明至少具有以下优点：无论AM还是UM模式下，均用以防止数据在空口以及系统内部传输时发生错误，导致LTE数据面在一段时间内数据无法正常接收的情形，在保证LTE数据面高度健壮性的同时，也能够及时监测错误并纠正，从而保证数据在高吞吐量下的正常传输。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，并可依照说明书的内容予以实施，以下以本发明的较佳实施例并配合附图详细说明如后。

附图说明

图1是现有技术中AM模式下数据面下行检错纠错流程；

图2是现有技术中AM模式下出错场景步骤一的示意图；

图3是现有技术中AM模式下出错场景步骤二的示意图；

图4是现有技术中AM模式下出错场景步骤三的示意图；

图5是ipv4包头格式；

图6是ipv6包头格式；

图7是本发明LTE数据面下行检错纠错方法的流程图。

具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

实施例一

由于网络传输协议的架构设计原因，IP协议是TCP/IP体系中两个最重要的协议之一，也是最重要的因特网标准协议之一。LTE用户面承载的数据绝大部分都是IP数据。LTE UE下行用户面数据在经过PDCP的解密和头解压缩处理后，能够明确地得知IP报头的内容。由于IP数据有着固定的IP报头结构(如图5和图6所示)，如果下行数据在传输过程中发生异常错误，那么PDCP收到 的数据包内容很可能就不符合IP报头结构。

基于上述情况，如图7所示，本发明一较佳实施例的一种LTE数据面下行检错纠错方法，包括以下步骤：

S1、接收PDCP数据包、并解析当前接收的PDCP数据包的SN号，判断其是否等于预期接收的PDCP数据包的SN号，若是则依次完成步骤S2和S5，若否则标记该PDCP数据包、并备份该PDCP数据包的上下文后进入步骤S2；

S2、按PDCP协议对该PDCP数据包执行解密和解头压缩过程后进入步骤S3；

S3、判断该PDCP数据包是否满足正确的IP协议报头格式，若是则进入步骤S5，若否则进入步骤S4；

S4、丢弃步骤S1中标记的PDCP数据包，并还原备份的PDCP数据包的上下文；

S5、按PDCP协议处理该PDCP数据包后递交给高层。

本发明的LTE数据面下行检错纠错方法，PDCP数据包的上下文包括上次递交给高层的PDCP数据包的SN号、以及预期接收的PDCP数据包的SN号。

步骤S4还包括保持预期接收的PDCP数据包的SN号的过程。当PDCP数据包被丢弃时，在AM模式下，Last_Submitted_PDCP_RX_SN和Next_PDCP_RX_SN保持不变，等待接收下一个PDCP数据包；在UM模式下，Next_PDCP_RX_SN保持不变。

步骤S5还包括修改预期接收的PDCP数据包的SN号的过程。当当前接收的PDCP数据包的SN号等于预期接收的PDCP数据包的SN号，或者当前接收的PDCP数据包的SN号不等于预期接收的PDCP数据包的SN号、但是该PDCP数据包满足正确的IP协议报头格式时，在AM模式下，Last_Submitted_PDCP_RX_SN置为当前接收的PDCP SN号，Next_PDCP_RX_SN置为当前接收的PDCP SN号+1；在UM模式下，Next_PDCP_RX_SN置为当前接收的PDCP SN号+1，如果Next_PDCP_RX_SN>Maximum_PDCP_SN：将Next_PDCP_RX_SN置为0；将RX_HFN增加1；

本发明的LTE数据面下行检错纠错方法，步骤S3中对于PDCP数据包是否 满足正确的IP协议报头格式的判断，按IP协议的IP报头结构分为ipv4包头格式比对和ipv6包头格式比对两种方式。

具体而言，ipv4包头格式比对包括目的IP地址比对、源IP地址比对、版本号比对、头长度比对、服务类型比对、数据包长度比对、标识比对、df mf偏移量比对、生存时间比对、传输协议比对以及头标校验和比对，具体使用过程中ipv4包头格式比对过程可选择其中之一个或多个。

ipv6包头格式比对包括目的IP地址比对、源IP地址比对、版本号比对、优先级比对、流量标识比对、数据长度比对、跳数限制比对、以及下一包头比对，具体使用过程中ipv6包头格式比对过程可选择其中之一个或多个。

实施例二

本发明以目的IP地址比对为例做进一步说明，目的IP地址比对为将解析出PDCP数据包的目的IP地址与用户设备自身的IP地址进行比对。

当实际使用过程中，系统由于长时间高负荷运行、温度过热导致硬件错误，或者其他系统软件模块设计缺陷导致内存覆盖，发生下行数据在传输过程中异常错误的情况，PDCP模块从低层收到用户面PDCP数据包很可能不符合IP报头结构。

假设目的IP地址为111.121.131.1，而解析出下行数据的目的IP地址为220.101.5.87，比对后发现两者不匹配，那么可以判定该数据包在传输过程中发生过错误。

假设目的IP地址为111.121.131.1，而解析出下行数据的目的IP地址为111.121.131.1，比对后发现两者匹配，此时并不能直接判定该数据包在传输过程中未发生过错误，还可以对IP包头其它域的内容进行分析比对，以判断数据包是否出错。

以上所述仅是本发明的优选实施方式，并不用于限制本发明，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和变型，这些改进和变型也应视为本发明的保护范围。