一种报文的非按序递交方法及RLC实体、基站与流程

本申请涉及电子信息领域，尤其涉及一种报文的非按序递交方法及rlc实体、基站。

背景技术：

无线通信中的无线链路控制(radiolinkcontrol,rlc)协议的主要功能是将数据交付给对端的rlc实体。如图1所示，基站的逻辑通信架构均包括4层结构，其中，使用rlc协议的rlc层位于分组数据汇聚协议(packetdataconvergenceprotocol，pdcp)层和媒体接入控制(mediumaccesscontrol，mac)层之间，与pdcp层和mac层进行报文的交互。终端的逻辑通信架构为5层，除了高层(upperlayer，包括ip层及传输层(tcp层/udp层)、应用层)之外，其它4层与基站相同。

图1中基站与终端之间的每个逻辑信道都有一个rlc实体(rlcentity)。rlc层的功能由rlc实体实现，每个rlc实体由无线资源控制(radioresourcecontrol，rrc)层(图1未画出)配置，对应某个终端的某个业务。rlc实体从pdcp层接收到的数据，或发往pdcp层的数据被称作rlc业务数据单元(servicedataunit，sdu)。rlc实体从媒体访问控制(mediaaccesscontrol，mac)层接收到的数据，或发往mac层的数据被称作rlc协议数据单元(protocoldataunit，pdu)。

根据现有的协议3gppts36.322，rlc层对于从mac层接收的rlcpdu，重组出的rlcsdu需要按序递交(in-sequencedelivery)到pdcp层，按序递交的基本思想是，将当前接收到的序号为x的rlcpdu存放在rlc层缓存中，直到序号小于x的所有rlcpdu都已成功接收并重组为rlcsdu递送给pdcp层后，下一个rlcpdu才会被进行重组。以图2为例，如果rlc层已经收到序号23之前的所有rlcpdu和序号25-27的rlcpdu，由于pdu24还未接收到(可能丢包)，需要一直等待，直到pdu24成功接收，才会进行rlcsdu的重组以及递交。

可见，报文的按序递交方法因为要等待接收缺失的报文，会导致较大的时延，容易降低传输性能。为了避免这个问题，产生了报文的非按序递交方法：只要接收到的rlcpdu足够重组出部分rlcsdu，则无需等待缺失的报文，将重组出对于时序不敏感的rlcsdu递交到pdcp层。以图3为例，如果rlc层已经收到序号23之前的所有rlcpdu和序号25-27的rlcpdu，还未接收到pdu24，不会等待接收pdu24，而利用接收到的rlcpdu，重组出rlcsdu10、11、13和14(依据pdu与sdu的重组映射关系重组)，并向pdcp层递交重组出的rlcsdu中对乱序不敏感的报文。

然而，需要依据报文的包信息确定报文是否为对乱序不敏感的报文，对于加密的报文而言，无法直接获取报文的包信息，因此，现有的报文的非按序递交方法，不适用于加密的报文。

技术实现要素：

本申请提供了一种报文的非按序递交方法及rlc实体、基站，目的在于解决现有的报文的非按序递交方法不适用于加密的报文的问题。

为了实现上述目的，本申请提供了以下技术方案：

本申请的第一方面提供了一种报文的非按序递交方法，包括：基站获取上行无线链路控制协议数据单元rlcpdu序列，所述上行rlcpdu序列中缺少至少一个rlcpdu。所述基站依据预设的rlcpdu与rlcsdu之间的重组映射关系，使用所述上行rlcpdu序列重组出上行无线链路控制业务数据单元rlcsdu。如果所述上行rlcsdu为预设加密类型的报文，所述基站根据所述基站发送的下行报文的特征，确定所述上行rlcsdu的报文类型。在所述上行rlcsdu的报文类型为预设的非按序递交类型的情况下，所述基站将所述上行rlcsdu进行非按序递交。可见，使用基站发送的下行报文的特征确定由接收到的上行rlcpdu序列重组而成的上行rlcsdu的报文类型，使得加密类型的报文也可以实现非按序递交。

本申请的第二方面提供了一种rlc实体，包括：获取模块、重组模块、确定模块和递交模块。其中，获取模块用于获取上行无线链路控制协议数据单元rlcpdu序列，所述上行rlcpdu序列中缺少至少一个rlcpdu。重组模块用于依据预设的rlcpdu与rlcsdu之间的重组映射关系，使用所述上行rlcpdu序列重组出上行rlcsdu。确定模块用于如果所述上行rlcsdu为预设加密类型的报文，根据发送的下行报文的特征，确定所述上行rlcsdu的报文类型。递交模块用于在所述上行rlcsdu的报文类型为预设的非按序递交类型的情况下，将所述上行rlcsdu进行非按序递交。所述rlc实体能够实现加密类型的报文的非按序递交。

本申请的第三方面提供了一种rlc实体，包括：存储器和处理器。所述存储器用于应用程序。所述处理器用于运行所述应用程序，以实现以下功能：获取上行无线链路控制协议数据单元rlcpdu序列，所述上行rlcpdu序列中缺少至少一个rlcpdu。依据预设的rlcpdu与rlcsdu之间的重组映射关系，使用所述上行rlcpdu序列重组出无线链路控制业务数据单元上行rlcsdu。如果所述上行rlcsdu为预设加密类型的报文，根据发送的下行报文的特征，确定所述上行rlcsdu的报文类型。在所述上行rlcsdu的报文类型为预设的非按序递交类型的情况下，将所述上行rlcsdu进行非按序递交。

本申请的第四方面提供了一种基站，包括上述rlc实体。

在一个实现方式中，所述预设加密类型包括：快速udp互联网连接quic，从而使得非按序递交扩展到quic领域。

在一个实现方式中，所述根据所述基站发送的报文的特征，确定所述上行rlcsdu的报文类型包括：如果所述发送的下行报文的特征包括以下至少一项，则确定所述上行rlcsdu的报文类型为quicack：所述发送的下行报文为预设类型以及预设数量；或者，所述发送的下行报文为预设数量；或者，发送所述下行报文后持续预设时长；或者，所述发送的下行报文为预设大小。上述条件依据quic协议设置，能够依据下行报文的特征自动确定上行报文的报文类型。

在一个实现方式中，确定所述上行rlcsdu的报文类型为预设的非按序递交类型的过程包括：如果在预设的非按序递交类型集合中查询到所述上行rlcsdu的报文类型，则确定所述上行rlcsdu的报文类型为预设的非按序递交类型。

在一个实现方式中，还包括：如果所述上行rlcsdu为非加密类型的报文，依据所述上行rlcsdu的信息，确定所述上行rlcsdu的报文类型。非加密类型的报文的信息能够被方便获取到，因此，无需依据下行报文的特征确定，而直接依据报文的信息确定即可，能够提高执行速度，并节省资源。

附图说明

图1为基站和终端的逻辑通信架构的示意图；

图2为非按序递交的示意图；

图3为本申请实施例公开的一种报文的非按序递交方法适用的场景的示意图；

图4为本申请实施例公开的一种报文的非按序递交方法的流程图；

图5为本申请实施例公开的又一种报文的非按序递交方法的流程图；

图6为本申请实施例公开的一种rlc实体的结构示意图。

具体实施方式

图3为本申请实施例公开的一种报文的非按序递交方法适用的场景，其中，基站作为无线网设备，与终端、其它基站以及核心网设备进行数据传输。

图3中所示的基站与图1中所示的基站具有相同的4层结构。其中，各层的功能分别为：

pdcp层：头部压缩和解压缩，加密/解密，完整性保护，传输用户数据和控制面数据，切换时的重排序和重传处理，由于超时而丢弃用户面数据。

rlc层：将来自pdcp层的数据进行分段，通过前向自动重传请求(automaticrepeatrequest，arq)进行纠错，将来自mac层的数据进行重排序、重复包检测和重分段。

mac层：匹配逻辑信道和传输信道，逻辑信道复用和解复用，harq纠错，调度，调度信息上报，随机接入过程处理，逻辑信道优先级处理等。

物理层(physicallayer，phy)：进行信道编解码，mimo预编码和解调，信道估计，调制/解调等。

本申请所述的报文的非按序递交方法的目的在于，在基站处理终端发送的报文的过程中，实现预设类型的加密报文的非按序递交。该功能在rlc层的处理过程中完成。

需要说明的是，上述4层结构仅为逻辑结构，在基站实体中，上述4层结构的功能可以由处理器运行代码实现。

下面将结合附图，对本申请实施例提出的技术方案进行详细的说明。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图4为本申请实施例公开的一种报文的非按序递交方法，由基站执行，具体的，由基站中的rlc实体执行，包括以下步骤：

s401：获取上行rlcpdu序列，上行rlcpdu序列中缺少至少一个rlcpdu。

具体的，基站接收到终端发送的上行报文后，分别对上行报文进行phy层处理和mac层处理，rlc层从mac层接收到的经过处理后的报文，称为上行rlcpdu序列。上行rlcpdu序列中包括多个rlcpdu，每个rlcpdu具有唯一的序号。

图2所示的rlcpdu序列缺少一个rlcpdu，可以看出，其中缺少序号为24的rlcpdu。

s402：依据预设的rlcpdu与rlcsdu之间的重组映射关系，使用接收到的上行rlcpdu序列重组出上行rlcsdu。

其中，重组映射关系是指，哪些rlcpdu对应重组哪些rlcsdu的关系。以图2为例，pdu21和pdu22重组sdu10，pdu23重组sdu11等。具体的，重组映射关系可以使用pdu的分段起始标志或序号与sdu的序号之间的对应关系表示。

s403：判断重组出的上行rlcsdu是否为预设加密类型的报文，如果是，执行s404，如果否，结束流程。

本实施例中，预设加密类型包括快速用户数据报协议互联网连接(quickuserdatagramprotocolinternetconnection，quic)。

quic是一种新的多路复用和安全传输用户数据报协议(userdatagramprotocol，udp)，重新设计和优化了http/2语义。quic将http/2作为主要的应用程序协议。quic建立在几十年的传输和安全的实践经验基础上，并实现了一套具有巨大吸引力的现代通用传输的机制。quic提供等效于http/2的多路复用和流控制，等效于传输层安全(transportlayersecurity，tls)的安全性，以及等效于tcp的连接语义，可靠性和拥塞控制。quic协议中报文加密程度高，在网络侧对于quic业务的优化研究还比较少。

s404：根据发送的下行报文的特征，确定重组出的上行rlcsdu的报文类型。

具体的，以quicack报文类型为例，quic协议规定接收端在三种条件下会触发ack反馈：接收端收到2个可重传包、接收端收到20个任意包、以及接收端定时器超时预设时长(例如25ms)。

基于上述协议规定，基站作为发送端，终端作为接收端的情况下，基站可以通过上述条件识别收到的上行quic包类型：基站下行发送2个可重传包后从终端收到的quic报文为quic应答消息(acknowledgement，ack)类型；基站下行发送20个任意包后，从终端收到的上行quic报文为quicack类型；基站下行发送报文后启动的定时器计时超过预设时长(例如定时器计时大于25ms)后，从终端收到的上行quic报文为quicack类型。

也就是说，下行发送的报文的特征包括：下行发送的报文为预设类型以及预设数量、下行发送的报文为预设数量、下行发送报文后持续预设时长。

可选的，有些类型的报文的大小明显与其它类型的报文的大小不同，因此，上述特征中还可以包括：下行发送的报文的大小。

综上所述，发送的报文的特征包括以下至少一项：

1、下行发送的报文为预设类型以及预设数量，例如，发送的报文为2个可重传包。

2、下行发送的报文为预设数量，例如，发送的报文为20个。

3、下行发送报文后持续预设时长，例如，发送报文后持续25ms。

4、发送的下行报文为预设大小。

需要说明的是，本实施例中以quicack报文为例，除此之外，还可以依据实际需求，增加报文类型，理论上说，只要能够从下行发送的报文的特征区别出的报文类型，均可作为s404中待识别的上行报文类型。

在图3所示的场景下，基站从核心网设备接收报文，并向终端发送报文，基站发送的报文可以为从核心网设备接收到的报文，即下行发送的报文的特征，可以为从核心网设备接收到的报文的特征。

s405：查询重组出的上行rlcsdu的报文类型是否为非按序递交类型，如果是，执行s406，如果否，执行s407。

具体的，可以预先设置非按序递交类型集合，该集合中包括可以非按序递交的报文类型，也就是说，该集合中包括对于非按序递交不敏感的报文类型。例如，非按序递交类型集合中包括quicack报文类型。可以依据实际需求，灵活配置非按序递交类型集合。

在获取到重组的上行rlcsdu的报文类型为quicack后，从非按序递交类型集合中查询是否存在quicack报文类型。

s406：将重组的上行rlcsdu递交到pdcp层，并对非按序递交的rlcsdu进行后续处理。

后续处理的过程可参见现有技术，这里不再赘述。

因为高层(应用层)可能有不同的乱序处理机制，比如对于tcp报文的乱序，tcp收端可能会回复重复ack，触发发端重传，传输性能反而下降。所以并非所有的rlcsdu都可以非按序递交到高层，可见，识别出特定类型的报文，是本方案的一个重要手段，这里quic报文中对非按序递交不敏感的报文主要包括quicack报文等。

s407：等待接收到上行rlcpdu序列中的全部rlcpdu后，再使用上行rlcpdu序列重组出上行rlcsdu，并将重组的上行rlcsdu按序递交到pdcp层，并对按序递交的rlcsdu进行后续处理。

图4所示的方法，针对加密报文，根据发送的报文的特征判断接收到的加密报文的类型，使得加密报文也可以实现非按序递交。本实施例中，以quicack报文为例，将rlc非按序递交的方案创新地用于quic业务。该方案在quic业务上行rlcpdu接收乱序的情况下生效。对于乱序率较高场景下的quic业务有增益，显著减少上行反馈包传输时延、减少因数据突发造成的上层节点丢包，从而提升网络quic业务下行吞吐率和下行用户体验。

图4所示的方法可以与现有的非按序递交的方法兼容，作为现有方案的补充，扩展了非按序递交方案的适用领域。

图5为本申请实施例公开的又一种报文的非按序递交方法，包括以下步骤：

s501：获取上行rlcpdu序列，上行rlcpdu序列中缺少至少一个rlcpdu。

可选的，在接收到上行rlcpdu序列后，还可以判断上行rlcpdu序列中上行rlcpdu的完整性，并缓存完整的上行rlcpdu，更新rlc状态变量等。

s502：依据预设的rlcpdu与rlcsdu之间的重组映射关系，使用接收到的上行rlcpdu序列重组出上行rlcsdu。

s503：判断重组出的上行rlcsdu的荷载类型，如果为quic，执行s504，如果为tcp或者udp，执行s505。

s504：依据发送的下行报文的特征，确定重组出的上行rlcsdu的报文类型。

s505：依据重组出的上行rlcsdu的信息，确定重组出的上行rlcsdu的报文类型。

具体的确定方法可以参见现有技术，这里不再赘述。

s506：查询重组出的上行rlcsdu的报文类型是否为非按序递交类型，如果是，执行s507，如果否，执行s508。

s507：将重组的上行rlcsdu递交到pdcp层，并对非按序递交的rlcsdu进行后续处理。

s508：等待接收到上行rlcpdu序列中的全部rlcpdu后，再使用上行rlcpdu序列重组出上行rlcsdu，并将重组的上行rlcsdu按序递交到pdcp层，并对按序递交的rlcsdu进行后续处理。

可见，如果rlcsdu为加密类型报文，则使用下行发送报文的特征识别出重组出的上行rlcsdu的报文类型，如果rlcsdu为tcp或者udp，则可以直接确定重组出的rlcsdu的报文类型。因此，将非按序递交的方式扩展到加密报文。

图6为本申请实施例公开的一种rlc实体，包括获取模块、重组模块、确定模块和递交模块。

其中，获取模块用于获取无线链路控制协议数据单元上行rlcpdu序列，所述上行rlcpdu序列中缺少至少一个rlcpdu。重组模块用于依据预设的rlcpdu与rlcsdu之间的重组映射关系，使用所述上行rlcpdu序列重组出上行rlcsdu。确定模块用于如果所述上行rlcsdu为预设加密类型的报文，根据发送的下行报文的特征，确定所述上行rlcsdu的报文类型。递交模块用于在所述上行rlcsdu的报文类型为预设的非按序递交类型的情况下，将所述上行rlcsdu进行非按序递交。

各模块的功能的具体实现方式，可以参见上述方法实施例，这里不再赘述。

所述rlc实体能够实现加密类型的报文的非按序递交。

本申请实施例还公开了一种rlc实体，包括存储器和处理器。

存储器用于存储应用程序。处理器用于运行所述应用程序，以实现图4或图5所示的功能。

所述处理器可以是通用处理器、数字信号处理器(dsp)、专用集成电路(asic)，现场可编程门阵列(fpga)或者其他可编程逻辑器件、晶体管逻辑器件，硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等等。

本申请实施例还公开了一种基站，包括上述rlc实体。所述基站可以实现加密类型的报文的非按序递交。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本申请的保护范围之内。