一种AM模式下的RLC实体的接收侧及其接收数据的方法与流程

本申请涉及一种移动通讯系统中的rlc实体，特别是涉及一种am模式下的rlc实体的接收侧及其接收方法。

背景技术：

lte(long-termevolution，长期演进技术)移动通讯系统的rlc(radiolinkcontrol，无线链路控制)实体有三种工作模式，其中am(acknowledgedmode，确认模式)主要用于可靠数据传输。

am模式下的rlc实体(rlcentity)被划分为接收侧(receivingside)和发送侧(transmittingside)。为保证数据可靠传输即不乱序、不丢包，在接收数据时，接收侧会用到重排序(reordering)功能。接收侧将底层收到的pdu(protocoldataunit，协议数据单元)按照接收序列号(receivingsn)的升序由接收窗(receivingwindow)缓存。如果出现漏包，接收侧会发送状态包(statuspdu)请求重传，并一直等待，直到漏包成功接收，或发生其他异常释放链路。接收侧在等待漏包的时候，不会再向上层传递数据。如果等待时间过长，会造成如下问题。

第一，缓存数据消耗过多内存。由于缓存数据不会传递给上层，最极端的情况下，am模式下的rlc实体的接收侧会缓存接收窗的大小减一个pdu，每个pdu有数千字节，因此造成内存消耗过于巨大，这对一些成本敏感的产品例如通讯芯片等是不可接受的。

第二，导致tcp(transmissioncontrolprotocol，传输控制协议)吞吐率下降。由于缓存数据不会向上层传递，tcp接收端也不会进行应答(ack)，tcp发送端超过一定时间阈值没有收到应答消息后就会启动流量控制、快速重传等措施，使tcp吞吐率出现波动、甚至掉坑等情况。

第三，实时业务质量很差。am模式下的rlc实体被用来承载语音、视频聊天等实时业务。如果接收侧的缓存时间过长，势必造成上层防抖动缓存区(jitterbuffer)超时丢包，导致实时业务质量随丢包率变化很大。

因此在保证rlc协议功能不受影响的前提下，如何降低内存消耗，同时保证tcp吞吐率稳定和实时业务的服务质量就成为一个亟待解决的技术问题。

技术实现要素：

本申请所要解决的技术问题是提供一种am模式下的rlc实体的接收侧，能够解决现有am模式下的rlc实体的接收侧的上述缺陷。为此，本申请还要提供相应的am模式下的rlc实体的接收侧接收数据的方法。

为解决上述技术问题，本申请提供了一种am模式下的rlc实体的接收侧，包括rlc控制单元、路由单元、接收窗单元、重排序单元、滑动窗判决单元、sdu重组单元。所述rlc控制单元用来从路由单元接收rlc控制pdu，还用来从滑动窗判决单元接收更新后的接收窗信息，并作为上报rlc控制包的依据。所述路由单元用来从底层接收数据pdu并传输给接收窗单元，还用来从底层接收rlc控制pdu并传输给rlc控制单元。所述接收窗单元用来将路由单元传来的数据pdu与接收窗进行判断；所述接收窗的长度固定，其下沿为变量vr(r)，其上沿为变量vr(mr)；其中，vr(r)表示接收侧已连续接收到pdu的最大的接收序列号紧挨着的下一个接收序列号；vr(mr)为vr(r)与接收窗的固定长度之和；如果收到的pdu的接收序列号位于接收窗之外，将该pdu丢弃；如果收到的pdu的接收序列号位于接收窗之内，则缓存该pdu并提交给重排序单元。所述重排序单元用来将接收窗单元缓存的数据pdu按照接收序列号的升序进行排列。所述滑动窗判决单元用来对排序后的数据pdu进行组包，并将解析出的数据sdu或数据sdu的分段交给上层，丢弃所有无法解析的sdu或sdu分段。所述滑动窗判决单元还用来在vr(r)＝vr(h)时正常更新接收窗；这是指当从vr(r)开始连续地收到k个数据pdu时，则使接收窗的下沿vr(r)和上沿vr(mr)同步地向上增大k值；其中，vr(h)表示接收侧已接收到pdu的最大的接收序列号紧挨着的下一个接收序列号。所述滑动窗判决单元还用来在vr(r)≠vr(h)、且vr(h)－vr(r)≥a时计算当前丢包率vr(lr)；如果vr(lr)＜丢包率阈值，则强制更新接收窗；这是指将新的vr(r)设定为现有的vr(h)，同步调整vr(mr)，这使接收窗的下沿和上沿同步地向上增大vr(h)－vr(r)值；其中，vr(lr)表示接收侧的当前丢包率，计算公式如下：

所述滑动窗判决单元还用来将更新后的接收窗信息通知rlc控制单元。所述sdu重组单元将分段的数据sdu重新组合成一个完整的数据sdu。

上述am模式下的rlc实体的接收侧通过新增的强制更新接收窗的操作，减小了实时业务的延时。

进一步地，所述接收窗单元收到的pdu如果出现漏包，那么滑动窗判决单元将从数据pdu中解析出数据sdu或者数据sdu的分段，并将能够从数据pdu中解析出的数据sdu或数据sdu的分段交给sdu重组单元；当符合强制更新接收窗的条件时，滑动窗判决单元强制更新接收窗；此后，如果接收窗单元又收到之前漏掉的数据pdu，则丢弃该pdu。这是通过在vr(r)≠vr(h)时对数据pdu进行提前组包，降低了接收窗中缓存的数据对内存的占用。

进一步地，所述常量a设为200到300之间。常量a的取值越小，则接收窗所占用的内存资源就越小。这是一种优选的实现方式。

进一步地，vr(h)－vr(r)≥a改为vr(h)－vr(r)≤a。此时，常量a用于严格限定接收窗所占用的内存资源。

进一步地，所述丢包率阈值设置为大于0且小于或等于5％。这是一种优选的实现方式。

本申请还提供了一种am模式下的rlc实体接收数据的方法，包括如下步骤。

步骤s210：从底层接收数据pdu。步骤s220：将收到的数据pdu与接收窗进行判断；如果收到的pdu的接收序列号位于接收窗之内，则缓存该pdu；如果收到的pdu的接收序列号位于接收窗之外，将该pdu丢弃。步骤s230：将缓存的数据pdu按照接收序列号的升序排列。步骤s240：判断vr(r)是否等于vr(h)？如果是，则进入步骤s290；否则进入步骤s250。步骤s250：判断vr(h)－vr(r)是否大于或等于常量a？如果是，进入步骤s260；否则退出流程，本次接收结束。步骤s260：根据vr(r)和vr(h)计算当前丢包率vr(lr)。

步骤s270：判断vr(lr)是否大于或等于丢包率阈值？如果是，则退出流程，本次接收结束；否则进入步骤s280。步骤s280：对vr(r)到vr(h)之间收到的数据pdu进行组包，并将解析出的数据sdu或数据sdu的分段交给上层，丢弃所有无法解析的sdu或sdu分段；同时强制更新接收窗，即将新的vr(r)设定为现有的vr(h)，同步调整vr(mr)，这使接收窗的下沿和上沿同步地向上增大vr(h)－vr(r)值；随后进入步骤s295。步骤s290：对收到的数据pdu进行组包，并将解析出的数据sdu或数据sdu的分段交给上层，丢弃所有无法解析的sdu或sdu分段；同时正常更新接收窗，即如果从vr(r)开始连续地收到k个数据pdu，则使接收窗的下沿vr(r)和上沿vr(mr)同步地向上增大k值。步骤s295：将分段的数据sdu重新组合成一个完整的数据sdu。

上述am模式下的rlc实体接收数据的方法中，在vr(r)≠vr(h)时对数据pdu进行提前组包，降低了接收窗中缓存的数据对内存的占用；通过新增的强制更新接收窗的操作，减小了实时业务的延时。

进一步地，所述步骤s230中，如果发现缓存的数据pdu存在漏包，则启动重排序定时器等待；如果超时还没收到，就发送状态包请求发送端重传。这是一种可选的实现方式。实际上，由于本申请在步骤s280中会强制更新接收窗，因此对于漏包的处理显得不那么重要了。

进一步地，如果在步骤s230中启动了重排序定时器，则在步骤s280中关闭重排序定时器。这是一种可选的实现方式。

进一步地，所述步骤s250中，“vr(h)－vr(r)是否大于或等于常量a”改为“vr(h)－vr(r)是否小于或等于常量a”。此时，常量a用于严格限定接收窗所占用的内存资源。

进一步地，所述步骤s210由am模式下的rlc实体中的路由单元实现。所述步骤s220由am模式下的rlc实体中的接收窗单元实现。所述步骤s230由am模式下的rlc实体中的重排序单元实现。所述步骤s240至步骤s290由am模式下的rlc实体中的滑动窗判决单元实现。所述步骤s295由am模式下的rlc实体中的sdu重组单元实现。这是一种优选的实现方式。

本申请取得的技术效果是能够减小内存消耗、改善tcp流量控制、减少传输实时数据的延迟。

附图说明

图1是本申请提供的am模式下的rlc实体的接收侧的结构示意图。

图2是本申请提供的am模式下的rlc实体的接收侧接收数据的方法的流程图。

图中附图标记说明：100为am模式下的rlc实体的接收侧；110为rlc控制单元；120为路由单元；130为接收窗单元；140为重排序单元；150为滑动窗判决单元；160为sdu重组单元。

具体实施方式

请参阅图1，这是本申请提供的am模式下的rlc实体的接收侧的示意图。所述am模式下的rlc实体的接收侧100包括rlc控制单元110、路由单元120、接收窗单元130、重排序单元140、滑动窗判决单元150、sdu(servicedataunit，服务数据单元，业务数据单元)重组单元160。

所述rlc控制单元110用来从路由单元120接收rlc控制pdu(rlccontrolpdu)。所述rlc控制单元110还用来从滑动窗判决单元150接收更新后的接收窗信息，并作为上报rlc控制包的依据。

所述路由单元120用来从底层接收数据pdu并传输给接收窗单元130。所述路由单元120还用来从底层接收rlc控制pdu并传输给rlc控制单元110。

所述接收窗单元130用来将路由单元120传来的数据pdu与接收窗进行判断。如果收到的pdu的接收序列号位于接收窗之外，将该pdu丢弃。如果收到的pdu的接收序列号位于接收窗之内，则缓存该pdu并提交给重排序单元140。

所述接收窗的长度固定，其下沿为变量vr(r)，其上沿为变量vr(mr)。vr(r)表示接收侧已连续接收到pdu的最大的接收序列号紧挨着的下一个接收序列号。在vr(r)之前的pdu已经被接收侧连续收到，因此vr(r)表示接收窗中第一个未连续接收到的pdu的接收序列号，也是接收侧下一个希望收到的pdu的接收序列号。vr(mr)为vr(r)与接收窗的固定长度之和。

进一步地，所述接收窗单元130收到的pdu如果出现漏包，则交由滑动窗判决单元150判断是否组包与更新接收窗。

所述重排序单元140用来将接收窗单元130缓存的数据pdu(乱序的)按照接收序列号的升序进行排列。

进一步地，如果重排序单元140发现接收窗单元130缓存的数据pdu存在漏包，则启动重排序定时器等待。如果超时还没收到，就发送状态包请求发送端重传。

所述滑动窗判决单元150用来对排序后的数据pdu进行组包，所述组包是指从数据pdu中解析出数据sdu，或者根据数据pdu的报头(header)中的分段信息从数据pdu中解析出数据sdu的分段。然后滑动窗判决单元150将解析出的数据sdu或数据sdu的分段交给上层，并丢弃所有无法解析的sdu或sdu分段。

所述滑动窗判决单元150还用来在vr(r)＝vr(h)时正常更新接收窗。当vr(r)＝vr(h)则表明当前收到的数据pdu没有漏包。此时如果从vr(r)开始连续地收到k个数据pdu，则使接收窗的下沿vr(r)和上沿vr(mr)同步地向上增大k值。这是现有的协议定义的正常更新接收窗的操作。

所述滑动窗判决单元150还用来在vr(r)≠vr(h)、且vr(h)－vr(r)≥a时计算当前丢包率vr(lr)。如果vr(lr)＜丢包率阈值，则强制更新接收窗。所述强制更新接收窗是指将新的vr(r)设定为现有的vr(h)，同步调整vr(mr)，这使接收窗的下沿和上沿同步地向上增大vr(h)－vr(r)值。这是本申请所设计的在符合特定条件时进行的强制更新接收窗的操作。

所述vr(h)是一个变量，表示接收侧已接收到pdu的最大的接收序列号紧挨着的下一个接收序列号。

所述vr(lr)是一个变量，表示接收侧的当前丢包率(lossrate)，初始化设置为0。vr(lr)的计算公式如下。

常量a表示强制更新接收窗的一个判定条件中的阈值。一般情况下，数据pdu的发送端速率相对稳定，那么发送a个数据pdu的时间也是相对稳定的，即a表示一个时间跨度。接收窗的长度是固定的，通过调整常量a可以调整强制更新接收窗的条件，从而调整提前组包的条件。当a变小，则可以减少接收窗所占用的内存资源。优选地，常量a设为200到300之间。这样能够避免接收窗单元130中接收pdu的等待时间过长。

作为一种变形，强制更新接收窗的一个判定条件vr(h)－vr(r)≥a也可改为vr(h)－vr(r)≤a。此时，常量a用于严格限定接收窗所占用的内存资源。

优选地，丢包率阈值设置为大于0且小于或等于5％。这样能保证丢包率不至于造成tcp流量控制。

所述滑动窗判决单元150还用来将更新后的接收窗信息通知rlc控制单元110。

所述sdu重组单元160将分段的数据sdu重新组合成一个完整的数据sdu。

进一步地，如果接收窗单元130收到的数据pdu出现漏包，那么滑动窗判决单元150从数据pdu中解析出数据sdu，或者根据数据pdu的报头中的分段信息从数据pdu中解析出数据sdu的分段；然后将能够从数据pdu中解析出的数据sdu或数据sdu的分段交给sdu重组单元160。如何符合强制更新接收窗的条件，则滑动窗判决单元150强制更新接收窗。此后，如果接收窗单元130又收到之前漏掉的数据pdu。此时由于接收窗已更新，而之前漏掉的数据pdu的接收序列号必然落在新的接收窗之外，接收窗单元130丢弃该pdu。

请参阅图2，与图1所示的am模式下的rlc实体的接收侧相对应地，本申请还提供了一种am模式下的rlc实体接收数据的方法。所述方法包括如下步骤。

步骤s210：从底层接收数据pdu。这一步例如由am模式下的rlc实体中的路由单元120实现。

步骤s220：将收到的数据pdu与接收窗进行判断。如果收到的pdu的接收序列号位于接收窗之内，则缓存该pdu。如果收到的pdu的接收序列号位于接收窗之外，将该pdu丢弃。这一步例如由am模式下的rlc实体中的接收窗单元130实现。

步骤s230：将缓存的数据pdu(乱序的)按照接收序列号的升序排列。这一步例如由am模式下的rlc实体中的重排序单元140实现。

进一步地，这一步中如果发现缓存的数据pdu存在漏包，则启动重排序定时器等待。如果超时还没收到，就发送状态包请求发送端重传。

步骤s240：判断vr(r)是否等于vr(h)？如果是，则表明当前收到的数据pdu没有漏包，进入步骤s290。如果否，则表明当前收到的数据pdu存在漏包，进入步骤s250。这一步例如由am模式下的rlc实体中的滑动窗判决单元150实现。

步骤s250：判断vr(h)－vr(r)是否大于或等于常量a？如果是，进入步骤s260。如果否，则退出流程，本次接收结束。这一步例如由am模式下的rlc实体中的滑动窗判决单元150实现。

这一步中，作为一种变形，判定条件“vr(h)－vr(r)是否大于或等于常量a”可改为“vr(h)－vr(r)是否小于或等于常量a”。此时，常量a用于严格限定接收窗所占用的内存资源。

步骤s260：根据vr(r)和vr(h)计算当前丢包率vr(lr)。这一步例如由am模式下的rlc实体中的滑动窗判决单元150实现。

步骤s270：判断当前丢包率vr(lr)是否大于或等于丢包率阈值？如果是，则退出流程，本次接收结束。如果否，则进入步骤s280。这一步例如由am模式下的rlc实体中的滑动窗判决单元150实现。

步骤s280：对vr(r)到vr(h)之间收到的数据pdu进行组包，并将解析出的数据sdu或数据sdu的分段交给上层，并丢弃所有无法解析的sdu或sdu分段；同时强制更新接收窗，即将新的vr(r)设定为现有的vr(h)，同步调整vr(mr)，这使接收窗的下沿和上沿同步地向上增大vr(h)－vr(r)值。随后进入步骤s295。这一步例如由am模式下的rlc实体中的滑动窗判决单元150实现。

进一步地，如果在步骤s230中启动了重排序定时器，则这一步中关闭重排序定时器。

步骤s290：对收到的数据pdu进行组包，并将解析出的数据sdu或数据sdu的分段交给上层，丢弃所有无法解析的sdu或sdu分段；同时正常更新接收窗，即如果从vr(r)开始连续地收到k个数据pdu，则使接收窗的下沿vr(r)和上沿vr(mr)同步地向上增大k值。

步骤s295：将分段的数据sdu重新组合成一个完整的数据sdu。这一步例如由am模式下的rlc实体中的sdu重组单元160实现。

本申请提供的am模式下的rlc实体的接收侧及其接收数据的方法通过新增加的强制更新接收窗的操作，增强了重排序的功能实现，具有如下有益效果。

第一，能够减小内存消耗。接收窗需要缓存完整窗口尺寸的数据量即512个sdu或sdu分段，本申请可以在pdu有漏包的情况下提前组包，而无需等到pdu全部接收后再进行组包，这样可以缩小接收窗实际所需的缓存值。例如：选取常量a为200，则接收窗实际所需缓存值减少到原来的40％。根据常量a选取的值不同，减小内存消耗的效果也不同，可以根据需求进行调整。进一步地，常量a所涉及的判定条件还可由vr(h)－vr(r)≥a改为vr(h)－vr(r)≤a。此时，常量a用于严格限定接收窗所占用的内存资源。

第二，能够改善tcp流量控制。tcp流量控制取决于2个条件，一个是丢包率，一个是环回时间(rtt，roundtriptime)。现有方法强制保证丢包率，但会增大rtt，如果rtt过大也会造成tcp流控。本申请通过常量a控制在保证tcp不流控的前提下最多等待强制组包的时间，可以在丢包率和rtt之间找到一个平衡，改善tcp流量控制的情况。

第三，传输实时数据也有较低的延迟。现有方法由于强制保证丢包率为0，数据会在接收窗缓存较长时间，造成实时数据延迟过高，很有可能数据在到达应用层以后已经失去时效性。本申请可以在丢包率和延迟时间之间找到一个平衡，降低实时数据延迟，改善实时业务的卡顿现象。

以上仅为本申请的优选实施例，并不用于限定本申请。对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。