CN111132225B - 一种am模式下的rlc实体的接收侧及其接收数据的方法 - Google Patents

一种am模式下的rlc实体的接收侧及其接收数据的方法 Download PDF

Info

Publication number
CN111132225B
CN111132225B CN201911005886.8A CN201911005886A CN111132225B CN 111132225 B CN111132225 B CN 111132225B CN 201911005886 A CN201911005886 A CN 201911005886A CN 111132225 B CN111132225 B CN 111132225B
Authority
CN
China
Prior art keywords
receiving
unit
data
pdu
window
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.)
Active
Application number
CN201911005886.8A
Other languages
English (en)
Other versions
CN111132225A (zh
Inventor
高鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Aojie Intelligent Technology Shanghai Co ltd
Original Assignee
Aojie Intelligent Technology Shanghai Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Aojie Intelligent Technology Shanghai Co ltd filed Critical Aojie Intelligent Technology Shanghai Co ltd
Priority to CN201911005886.8A priority Critical patent/CN111132225B/zh
Publication of CN111132225A publication Critical patent/CN111132225A/zh
Application granted granted Critical
Publication of CN111132225B publication Critical patent/CN111132225B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0236—Traffic management, e.g. flow control or congestion control based on communication conditions radio quality, e.g. interference, losses or delay
    • 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
    • H04L1/1657—Implicit acknowledgement of correct or incorrect reception, e.g. with a moving window
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/29—Flow control; Congestion control using a combination of thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • 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/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种AM模式下的RLC实体的接收侧。RLC控制单元用来从路由单元接收RLC控制PDU。路由单元用来从底层接收数据PDU并传输给接收窗单元。接收窗单元用来将路由单元传来的数据PDU与接收窗进行判断。重排序单元用来将缓存的数据PDU按照接收序列号的升序进行排列。滑动窗判决单元用来对排序后的数据PDU进行组包；还用来在接收的数据PDU无漏包时正常更新接收窗，还用来在接收的数据PDU有漏包时在符合特定条件下强制更新接收窗。SDU重组单元将分段的数据SDU重新组合成一个完整的数据SDU。本申请通过新增的强制更新接收窗的操作，减小了实时业务的延时；还具有减小内存消耗、改善TCP流量控制的优点。

Description

一种AM模式下的RLC实体的接收侧及其接收数据的方法
技术领域
本申请涉及一种移动通讯***中的RLC实体，特别是涉及一种AM模式下的RLC实体的接收侧及其接收方法。
背景技术
LTE(Long-Term Evolution，长期演进技术)移动通讯***的RLC(Radio LinkControl，无线链路控制)实体有三种工作模式，其中AM(Acknowledged Mode，确认模式)主要用于可靠数据传输。
AM模式下的RLC实体(RLC entity)被划分为接收侧(receiving side)和发送侧(transmitting side)。为保证数据可靠传输即不乱序、不丢包，在接收数据时，接收侧会用到重排序(reordering)功能。接收侧将底层收到的PDU(Protocol Data Unit，协议数据单元)按照接收序列号(receiving SN)的升序由接收窗(receiving window)缓存。如果出现漏包，接收侧会发送状态包(STATUS PDU)请求重传，并一直等待，直到漏包成功接收，或发生其他异常释放链路。接收侧在等待漏包的时候，不会再向上层传递数据。如果等待时间过长，会造成如下问题。
第一，缓存数据消耗过多内存。由于缓存数据不会传递给上层，最极端的情况下，AM模式下的RLC实体的接收侧会缓存接收窗的大小减一个PDU，每个PDU有数千字节，因此造成内存消耗过于巨大，这对一些成本敏感的产品例如通讯芯片等是不可接受的。
第二，导致TCP(Transmission Control Protocol，传输控制协议)吞吐率下降。由于缓存数据不会向上层传递，TCP接收端也不会进行应答(ACK)，TCP发送端超过一定时间阈值没有收到应答消息后就会启动流量控制、快速重传等措施，使TCP吞吐率出现波动、甚至掉坑等情况。
第三，实时业务质量很差。AM模式下的RLC实体被用来承载语音、视频聊天等实时业务。如果接收侧的缓存时间过长，势必造成上层防抖动缓存区(Jitter Buffer)超时丢包，导致实时业务质量随丢包率变化很大。
因此在保证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)表示接收侧的当前丢包率，计算公式如下：
Figure BDA0002242765010000021
所述滑动窗判决单元还用来将更新后的接收窗信息通知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)。
Figure BDA0002242765010000031
步骤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(Service Data Unit，服务数据单元，业务数据单元)重组单元160。
所述RLC控制单元110用来从路由单元120接收RLC控制PDU(RLC Control PDU)。所述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)是一个变量，表示接收侧的当前丢包率(Loss Rate)，初始化设置为0。VR(LR)的计算公式如下。
Figure BDA0002242765010000051
常量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实现。
Figure BDA0002242765010000071
步骤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，Round Trip Time)。现有方法强制保证丢包率，但会增大RTT，如果RTT过大也会造成TCP流控。本申请通过常量A控制在保证TCP不流控的前提下最多等待强制组包的时间，可以在丢包率和RTT之间找到一个平衡，改善TCP流量控制的情况。
第三，传输实时数据也有较低的延迟。现有方法由于强制保证丢包率为0，数据会在接收窗缓存较长时间，造成实时数据延迟过高，很有可能数据在到达应用层以后已经失去时效性。本申请可以在丢包率和延迟时间之间找到一个平衡，降低实时数据延迟，改善实时业务的卡顿现象。
以上仅为本申请的优选实施例，并不用于限定本申请。对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种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)；常量A表示强制更新接收窗的一个判定条件中的阈值；如果VR(LR)＜丢包率阈值，则强制更新接收窗；这是指将新的VR(R)设定为现有的VR(H)，同步调整VR(MR)，这使接收窗的下沿和上沿同步地向上增大VR(H)－VR(R)值；其中，VR(LR)表示接收侧的当前丢包率，计算公式如下：
Figure FDA0003260689280000011
所述滑动窗判决单元还用来将更新后的接收窗信息通知RLC控制单元；
所述SDU重组单元将分段的数据SDU重新组合成一个完整的数据SDU。
2.根据权利要求1所述的AM模式下的RLC实体的接收侧，其特征是，所述接收窗单元收到的PDU如果出现漏包，那么滑动窗判决单元将从数据PDU中解析出数据SDU或者数据SDU的分段，并将能够从数据PDU中解析出的数据SDU或数据SDU的分段交给SDU重组单元；当符合强制更新接收窗的条件时，滑动窗判决单元强制更新接收窗；此后，如果接收窗单元又收到之前漏掉的数据PDU，则丢弃该PDU。
3.根据权利要求1所述的AM模式下的RLC实体的接收侧，其特征是，所述常量A设为200到300之间；常量A的取值越小，则接收窗所占用的内存资源就越小。
4.根据权利要求1所述的AM模式下的RLC实体的接收侧，其特征是，VR(H)－VR(R)≥A改为VR(H)－VR(R)≤A。
5.根据权利要求1所述的AM模式下的RLC实体的接收侧，其特征是，所述丢包率阈值设置为大于0且小于或等于5％。
6.一种AM模式下的RLC实体接收数据的方法，其特征是，包括如下步骤：
步骤S210：从底层接收数据PDU；
步骤S220：将收到的数据PDU与接收窗进行判断；如果收到的PDU的接收序列号位于接收窗之内，则缓存该PDU；如果收到的PDU的接收序列号位于接收窗之外，将该PDU丢弃；
步骤S230：将缓存的数据PDU按照接收序列号的升序排列；
步骤S240：判断VR(R)是否等于VR(H)；如果是，则进入步骤S290；否则进入步骤S250；其中，VR(R)表示接收侧已连续接收到PDU的最大的接收序列号紧挨着的下一个接收序列号；VR(H)表示接收侧已接收到PDU的最大的接收序列号紧挨着的下一个接收序列号；
步骤S250：判断VR(H)－VR(R)是否大于或等于常量A；如果是，进入步骤S260；否则退出流程，本次接收结束；
步骤S260：根据VR(R)和VR(H)计算当前丢包率VR(LR)；
Figure FDA0003260689280000021
步骤S270：判断VR(LR)是否大于或等于丢包率阈值；如果是，则退出流程，本次接收结束；否则进入步骤S280；
步骤S280：对VR(R)到VR(H)之间收到的数据PDU进行组包，并将解析出的数据SDU或数据SDU的分段交给上层，丢弃所有无法解析的SDU或SDU分段；同时强制更新接收窗，即将新的VR(R)设定为现有的VR(H)，同步调整VR(MR)，这使接收窗的下沿和上沿同步地向上增大VR(H)－VR(R)值；VR(MR)为VR(R)与接收窗的固定长度之和；随后进入步骤S295；
步骤S290：对收到的数据PDU进行组包，并将解析出的数据SDU或数据SDU的分段交给上层，丢弃所有无法解析的SDU或SDU分段；同时正常更新接收窗，即如果从VR(R)开始连续地收到k个数据PDU，则使接收窗的下沿VR(R)和上沿VR(MR)同步地向上增大k值；
步骤S295：将分段的数据SDU重新组合成一个完整的数据SDU。
7.根据权利要求6所述的AM模式下的RLC实体接收数据的方法，其特征是，所述步骤S230中，如果发现缓存的数据PDU存在漏包，则启动重排序定时器等待；如果超时还没收到，就发送状态包请求发送端重传。
8.根据权利要求7所述的AM模式下的RLC实体接收数据的方法，其特征是，如果在步骤S230中启动了重排序定时器，则在步骤S280中关闭重排序定时器。
9.根据权利要求6所述的AM模式下的RLC实体接收数据的方法，其特征是，所述步骤S250中，“VR(H)－VR(R)是否大于或等于常量A”改为“VR(H)－VR(R)是否小于或等于常量A”。
10.根据权利要求6所述的AM模式下的RLC实体接收数据的方法，其特征是，所述步骤S210由AM模式下的RLC实体中的路由单元实现；
所述步骤S220由AM模式下的RLC实体中的接收窗单元实现；
所述步骤S230由AM模式下的RLC实体中的重排序单元实现；
所述步骤S240至步骤S290由AM模式下的RLC实体中的滑动窗判决单元实现；
所述步骤S295由AM模式下的RLC实体中的SDU重组单元实现。
CN201911005886.8A 2019-10-22 2019-10-22 一种am模式下的rlc实体的接收侧及其接收数据的方法 Active CN111132225B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911005886.8A CN111132225B (zh) 2019-10-22 2019-10-22 一种am模式下的rlc实体的接收侧及其接收数据的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911005886.8A CN111132225B (zh) 2019-10-22 2019-10-22 一种am模式下的rlc实体的接收侧及其接收数据的方法

Publications (2)

Publication Number Publication Date
CN111132225A CN111132225A (zh) 2020-05-08
CN111132225B true CN111132225B (zh) 2021-12-31

Family

ID=70495405

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911005886.8A Active CN111132225B (zh) 2019-10-22 2019-10-22 一种am模式下的rlc实体的接收侧及其接收数据的方法

Country Status (1)

Country Link
CN (1) CN111132225B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115515180B (zh) * 2022-08-29 2023-09-15 翱捷科技股份有限公司 一种更新am模式的nr rlc接收窗口的方法及装置
CN118118134A (zh) * 2022-11-30 2024-05-31 维沃移动通信有限公司 数据接收方法、装置、网络侧设备及终端设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043302A (zh) * 2006-03-22 2007-09-26 华为技术有限公司 一种无线网络通信装置
CN102868504A (zh) * 2012-08-24 2013-01-09 中兴通讯股份有限公司 一种发送状态报告的方法和rlc接收实体
CN103856287A (zh) * 2012-12-03 2014-06-11 电信科学技术研究院 一种无线通信数据包传输方法和设备
CN107659959A (zh) * 2016-07-25 2018-02-02 普天信息技术有限公司 一种专网无线通信***中上报接收数据状态的方法
CN107801200A (zh) * 2016-09-06 2018-03-13 中兴通讯股份有限公司 状态报告的发送方法及装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3443697B1 (en) * 2016-05-13 2022-08-24 Sony Group Corporation Apparatuses and methods for using arq processes in a relay device

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043302A (zh) * 2006-03-22 2007-09-26 华为技术有限公司 一种无线网络通信装置
CN102868504A (zh) * 2012-08-24 2013-01-09 中兴通讯股份有限公司 一种发送状态报告的方法和rlc接收实体
CN103856287A (zh) * 2012-12-03 2014-06-11 电信科学技术研究院 一种无线通信数据包传输方法和设备
CN107659959A (zh) * 2016-07-25 2018-02-02 普天信息技术有限公司 一种专网无线通信***中上报接收数据状态的方法
CN107801200A (zh) * 2016-09-06 2018-03-13 中兴通讯股份有限公司 状态报告的发送方法及装置

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
LTE协议栈RLC层ARQ机制的研究及分析;杨星宇，李小文，谢伟;《广东通信技术》;20100430;全文 *
LTE***中RLC层发送过程与接收过程的详细研究及测试;陈发堂，朱明;《广东通信技术》;20130228;全文 *
R2-073901，Combined RLC ARQ text proposals;Nokia Corporation, Nokia Siemens Networks;《3GPP TSG-RAN WG2 Meeting #59bis》;20071002;全文 *

Also Published As

Publication number Publication date
CN111132225A (zh) 2020-05-08

Similar Documents

Publication Publication Date Title
EP1876779B1 (en) Congestion and delay handling in a packet data network
US8169909B2 (en) Optimization of a transfer layer protocol connection
RU2543996C2 (ru) Управление перегрузкой в сети связи
US9686716B2 (en) Introducing simple RLC functionality to Node B
US20080165766A1 (en) Method and apparatus to indicate maximum scheduling delay for jitter buffer implementations
CN102239666A (zh) 电信网络中能够实现拥塞指示的方法和装置
US11129048B2 (en) Data transmission method, base station, and wireless communications device
US9900802B2 (en) Data transmission method and apparatus, base station, and user equipment
EP1471695B1 (en) Method for flow control in a communication system
Paul et al. An AQM based congestion control for eNB RLC in 4G/LTE network
CN112352449B (zh) 无线通信网络中的拥塞管理
EP2040423A1 (en) Improved utilization of data links
WO2013139165A1 (zh) 确认包的处理方法、设备及***
CN111132225B (zh) 一种am模式下的rlc实体的接收侧及其接收数据的方法
US9641447B2 (en) Adaptive relative bitrate manager for TCP depending flow control
CN112995048A (zh) 数据中心网络的阻塞控制与调度融合方法及终端设备
US9385931B1 (en) Determining a reordering timer
US20170324674A1 (en) Active queue management for a wireless communication network
WO2015186332A1 (ja) 送信データ量制御装置、制御システム、制御方法および制御プログラム
WO2017051860A1 (ja) データ通信装置、データ通信制御方法及びプログラム
CN117295108A (zh) 一种数据传输方法、装置及设备
JP2005057620A (ja) 通信品質制御方法およびその装置

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