CN107659959A - 一种专网无线通信***中上报接收数据状态的方法 - Google Patents
一种专网无线通信***中上报接收数据状态的方法 Download PDFInfo
- Publication number
- CN107659959A CN107659959A CN201610592860.8A CN201610592860A CN107659959A CN 107659959 A CN107659959 A CN 107659959A CN 201610592860 A CN201610592860 A CN 201610592860A CN 107659959 A CN107659959 A CN 107659959A
- Authority
- CN
- China
- Prior art keywords
- packet
- timer
- status
- pdu
- data
- 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.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明提供一种专网无线通信***中上报接收数据状态的方法,包括:在重排序定时器超时后,如满足下述发送条件则发送状态PDU:条件1,VR‑MS至VR‑H之间接收数据的丢包率低;且条件2,状态禁止定时器处于关闭状态或已开启一定时间。该方法能够更多的反馈接收情况,避免占用过多的发送空口资源,也不会错误上报VR‑MS和VR‑H之间的接收状态,并且未破坏原有的协议架构和层次划分,可实现复杂度低。
Description
技术领域
本发明涉及通信技术领域,更具体地,涉及一种专网无线通信***中上报接收数据状态的方法。
背景技术
目前230MHz频段主要应用于数传电台,承担远程数据的采集工作。因该频段提供的速率很低,只能使用一些简单的通信应用,所以无法满足智能电网和传感网日益增长的业务多样化和数据大流量的需求。根据国家电网未来的规划,需要寻找一种新的宽带通信技术,满足其配网自动化、负荷管理、用电信息采集、智能电网用户服务、应急抢修以及特殊区域视频监控六大领域的业务需求。
基于TD-LTE(Time Division-Long Term Evolution)技术的230MHz频段专网无线通信***为上述需求提供了较好的解决方案,构成了新一代低功耗、高频谱利用率和高可靠性的灵活多业务通信***。从而,能够最大程度地满足电力负荷监控***的业务要求,同时为国家电网下一代网络规划提供了坚实的技术积累和应用示范。
其中,无线链路层控制协议(Radio Link Control,RLC)应用于GPRS、WCDMA、TD-SCDMA和LTE等无线通信***中。在TD-LTE***中,RLC层位于MAC层之上,属于L2的一部分,为用户和控制数据提供分段和重传业务。
在RLC确认模式(Acknowledged Mode,AM)下,所有数据接收后都需要通过状态协议数据单元(Status Protocol Data Unit,PDU)反馈目前的接收状态至对侧,用以驱动对端RLC发送窗滑动。如有未收到的数据包,则反馈该数据包序列号(Sequence Number,SN)为否定性确认(Negative Acknowledgement,NACK)。而对侧根据反馈的NACK的SN号进行重传。状态PDU发送时间会根据相关定时器进行限制,以避免发送太频繁,影响空口速率。
目前,LTE230专网***中RLC状态PDU的发送会独占一帧的发送侧资源,而状态PDU是否发送会根据接收数据中上下文所带的P域是否为1来判定。但是状态PDU发送时间受限于状态禁止定时器和重排序定时器,前者发送状态PDU后开启,避免状态PDU发送过于频繁,占用发送侧空口资源;后者在数据包未按序收到后开启。只要其中一个处于开启状态,状态PDU都需要延迟触发等待其超时或关闭后再进行发送,以上报此时的接收情况。目前状态禁止定时器设置时间较长,其间均不能发送状态PDU。
另外,目前芯片因接收解调处理能力有限,在高阶MCS情况下,接收数据解错的情况偶有发生,导致RLC层出现丢包现象。当某包丢失后,RLC接收窗缓冲后续接收的数据,直到通过状态PDU告知基站重传此包数据并接收到之后,才能进一步处理缓冲的数据PDU。若是出现此情况,接收侧积攒的数据较多,使得重组函数一次需要处理很多SDU数据并递交给高层,导致芯片处理量瞬时增大。同时,若是处理语音业务,此种情况会进一步导致语音有严重的延时现象。
发明内容
本发明提供一种克服上述问题或者至少部分地解决上述问题的专网无线通信***中上报接收数据状态的方法。
根据本发明的一个方面,提供一种专网无线通信***在数据丢失情况下,快速上报接收状态的方法,包括:
在重排序定时器超时后,如满足下述发送条件则发送状态PDU:
条件1,VR-MS至VR-H之间接收数据的丢包率低;且
条件2,状态禁止定时器处于关闭状态或已开启一定时间。
其中,所述丢包率低是指未收到的数据包少于M个,M大于等于1。其中,所述状态PDU的上报内容为收到数据包中最后一包位置之前的接收反馈数据。
其中,所述方法包括:
步骤1,接收端接收到数据之后,确定该接收的数据没有相对于上一个数据包按照顺序接收到;
步骤2,开启重排序定时器,然后等待重排序定时器超时;
步骤3,重排序定时器超时后,基于满足所述发送条件,发送快速状态PDU。
其中,所述方法还包括:
在重排序定时器超时后,VR-MS更新后,状态禁止定时器处于开启状态且开启时间短,则不发送状态PDU;
等待接收到P域为1的数据包后进入正常的状态PDU发送流程。
其中,所述方法还包括:
VR-MS至VR-H之间接收状态差时,其间未接收到的数据包多于M个,则不发送所述状态PDU;
待接收窗进一步接收,并等待接收到P域为1的数据包后进入正常的状态PDU发送流程。
其中,所述方法具体还包括:
本发明针对原有缺点,在重排序定时器超时后,无论状态禁止定时器是否开启,在满足一定条件下都会发送状态PDU,以加快接收情况的反馈,使未收到数据包的尽快重传。
原有重排序定时器超时后发送的状态PDU会在RLC窗中更新VR-MS(开启重排序定时器的数据包位置)变量后,上报VR-MS之前的数据包。目前,修改为直接上报VR-H(收到数据包中最后的一包位置)之前的数据,这样能够更多的反馈接收情况,但仅限于此种重排序定时器超时发送的状态PDU。
在重排序定时器超时后,为避免占用过多的发送侧资源,该种状态PDU是否发送要取决于状态禁止定时器开启时间和VR-MS至VR-H的接收情况。例如,状态禁止定时器刚刚开启或VR-MS至VR-H的接收情况并不理想时,则不发送此种状态PDU,这样既避免占用过多的发送空口资源,也不会上报VR-MS和VR-H之间错误的接收状态。
本申请的方法未破坏原有的协议架构和层次划分,处理过程较清晰,可实现复杂度低。
附图说明
图1为根据本发明实施例的通信***中上报接收数据状态的方法流程图;
图2为根据本发明实施例的通信***中接收窗的时序状态示意图。
具体实施方式
下面结合附图和实施例,对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明,但不用来限制本发明的范围。
缩略语说明:
用户设备:User Equipment,UE;
协议数据单元:Protocol Data Unit,PDU;
无线链路控制:Radio Link Control,RLC;
确定模式:Acknowledged Mode,AM;
确认:Acknowledgement,ACK;
否定性确认:Negative Acknowledgement,NACK;
状态变量说明:
接收状态变量:Receive state variable,VR-R或者VR(R);位于窗口下边沿,是指连续接收到的最高序列号PDU的下一个PDU的序列号;
最大可接收状态变量:Maximum acceptable state variable,VR-MR或者VR(MR);位于窗口上边沿;
t_Reordering状态变量:t-Reordering state variable,VR-X或者VR(X);对应重排序定时器t_Reordering,是指触发重排序定时器的PDU的下一个PDU的序列号;
最大发送状态变量:Maximum STATUS transmit state variable,VR-MS或者VR(MS);用于状态PDU的生成,ACK_SN的上限,最有可能作为ACK_SN;
最高接收状态变量:Highest received state variable,VR-H或者VR(H);是指接收到的最高PDU的下一个PDU的序列号;
下面结合附图并以UE下行作为实施例,对本发明的具体实施方式作进一步的详细描述。以下实施例用于说明本发明,但不用来限制本发明的范围。
如前所述,现有处理流程中,根据AM模式下数据包中的P域指示AM RLC实体的发送侧是否向对端AM RLC实体请求一个状态报告,在检测到下行数据包中P域为1后,则需要发送状态PDU。原有的状态PDU发送时间受限于状态禁止定时器和重排序定时器,前者发送状态PDU后开启避免状态PDU发送过于频繁占用发送侧空口资源,后者在数据包未按序收到后开启,只有在两种定时器都未开启的状态下,才可发送状态PDU。由于状态PDU的发送需占用发送侧空口资源,故状态禁止定时器设置时间较长,导致在很多情况下,RLC层出现某包数据未收到。而重排序定时器超时后,状态禁止定时器依旧处于开启状态,故其间未收到的丢失数据数据包不能及时的反馈给对端,造成UE下行资源阻塞。
所以,为了能够及时将UE有丢包情况的接收状态反馈给eNB,现基于原有的状态PDU发送方式添加一个快速状态PDU的方式。无论状态禁止定时器是否超时,都会判定是否发送该状态PDU,如果满足条件则发送并刷新状态禁止定时器重新计时。
图1示出根据本发明实施例的加速上报接收状态的方法的流程图,如图1所示,包括以下步骤:
S1,接收端接收到数据之后,判断该接收的数据是否相对于上一个数据包按照顺序接收到;如果按序接收到,转S2;如果没有按序接收到,转S3;
S2,判断此时接收数据的上下文中所带的P域是否为1;如果不是,返回继续接收数据;如果是,转S4;
S3,开启重排序定时器,然后等待重排序定时器超时;判断是否满足状态PDU的发送条件,如果满足,则发送状态PDU,转S5;如果不满足,返回继续接收数据;
S4,判断状态禁止定时器是否开启,如果开启则返回继续接收数据;如果没有开启则发送状态PDU,转S6;
S5,判断状态禁止定时器是否开启,如果开启则状态禁止定时器重新计时,转S7;如果没有开启,转S6;
S6,开启状态禁止定时器,转S7;
S7,状态禁止定时器超时关闭,判断状态禁止定时器开启期间是否接收到P域为1的数据包,如果没有接收到则返回继续接收数据;如果接收到该数据包,则发送状态PDU。
可以看到,图中线框部分为新增加的处理方式,该状态PDU的发送不需要考虑状态禁止定时器是否开启,仅考虑重排序定时器的状态和发送条件。
在步骤S3中,在重排序定时器超时后判断是否满足条件发送该种状态PDU取决于状态禁止定时器开启时间和VR-MS至VR-H之间的接收情况,具体如下:
1、如果在重排序定时器超时,VR-MS更新后,状态禁止定时器处于开启状态且开启时间较短,则不发送该种状态PDU,等待接收到P域为1的数据包后进入正常状态PDU发送流程以避免占用过多的发送侧空口资源;
2、如果VR-MS至VR-H之间接收状态不好,其间未接收到的数据包多于M个,则不上报该种状态PDU,待接收窗进一步接收,并等待接收到P域为1的数据包后进入正常状态PDU发送流程,以避免上报错误的NACK数据包;
且如果满足条件发送了该种状态PDU,无论是否状态禁止定时器超时,该定时器都会开启并重新计时。
换句话说,本申请的方法在重排序定时器超时后无论其间是否收到P域为1的数据包且无论状态禁止定时器是否处于开启状态,如满足条件都会发送状态PDU;该状态PDU的发送条件是:(1)VR-MS至VR-H的之间接收数据情况良好(未收到的数据包少于M个);(2)状态禁止定时器处于关闭状态或已开启一定时间。
对于该状态PDU除发送机制上的改进,在对反馈内容也进行了优化。RLC层AM模式下如遇未收到数据包,接收窗以图2为例,如下方式:
STEP 1:数据包在收到SN=0的数据包后通过状态PDU反馈ACK后RLC窗口下边沿VR-R滑至SN=1的位置,但随后并未继续收到SN=1的数据包,而是直接收到了SN=2的数据包,此时VR-MS至SN=1的位置,随即开启重排序定时器,VR-H至SN=3的位置标记最高收到的数据包的下一包;
STEP 2-3:之后继续接收数据包,相关标记位按规则滑动,待重排序定时器超时后,VR-MS滑至下一个未收到的数据包的位置(即SN=5的位置),VR-H随接收继续滑动至最高收到的数据包的下一包(即SN=15)的位置;
STEP 4:随着重排序定时器的超时和VR-MS的滑动,重排序定时器重新开启。
在其中的反馈内容上,原有的状态PDU反馈模式是如果在重排序定时器开启时间内收到P域为1的数据包,该状态PDU会待重排序定时器超时后发送,如果此时状态禁止定时器处于开启状态,还要等待状态禁止定时器超时后上报状态PDU,上报内容为更新后的VR-MS之前的数据,未收到的数据包填入NACK表中,ACK位置填写VR-MS的位置。
本申请的方案中,根据数据包接收状态和状态禁止定时器以及重排序定时器设置时长的特点,修改为在重排序定时器超时后,无论在重排序定时器开启时间内是否接收到P域为1的数据,都会判定发送一种状态PDU,且发送的该种状态PDU,会上报VR-H之前的接收状态,该种状态PDU如遇上图2数据接收情况,会相对加快上报SN号为5至14的接收状态。
从而,本申请的方法利用重排序定时器超时后达到一定条件发送快速状态PDU,使RLC在AM模式下加速上报接收数据状态的方法,且该不影响正常流程下状态PDU的上报方式。总之,对于本发明不仅适用于UE下行接收侧,也同样适用于eNB上行接收侧,该种上报方式是基于原有上报状态PDU的方式加入一种新的状态PDU判断条件,用以达到加速上报接收数据状态的目的。
从而可以看到,本申请的方法改变了原有的重排序定时器超时后发送的状态PDU判决方式,将其受限于状态禁止定时器本身改为取决于状态禁止定时器开启时间和VR-MS至VR-H之间的接收情况,加速了该时段状态PDU的上报速度。
且该状态PDU的上报内容也由原来的上报VR-MS之前的接收状态改为上报VR-H之前的接收情况,使该种状态PDU更加有效的上报数据接收状态,从而让未收到数据包的重传更加及时,加速了RLC接收窗的滑动。且在加入该种状态PDU的发送模式后,正常状态PDU的上报除重排序定时器超时后的状态PDU被修改,其他并未收到任何影响。
可以看到,本申请的接收状态上报机制不仅仅适用于专网,可以更普遍适用于无线通信***。
最后,本申请的方法所讨论的应用于无线通信***的加速上报接收状态实现机制,仅为较佳的实施方案,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (7)
1.一种专网无线通信***中上报接收数据状态的方法,其特征在于,包括:
在重排序定时器超时后,如满足下述发送条件则发送状态PDU:
条件1,VR-MS至VR-H之间接收数据的丢包率低;且
条件2,状态禁止定时器处于关闭状态或已开启一定时间。
2.根据权利要求1所述的方法,其特征在于,所述丢包率低是指未收到的数据包少于M个,M大于等于1。
3.根据权利要求1所述的方法,其特征在于,所述状态PDU的上报内容为收到数据包中最后一包位置之前的接收反馈数据。
4.根据权利要求1所述的方法,其特征在于,所述方法包括:
步骤1,接收端接收到数据之后,确定该接收的数据没有相对于上一个数据包按照顺序接收到;
步骤2,开启重排序定时器,然后等待重排序定时器超时;
步骤3,重排序定时器超时后,基于满足所述发送条件,发送状态PDU。
5.根据权利要求1所述的方法,其特征在于,所述方法还包括:
在重排序定时器超时后,VR-MS更新后,状态禁止定时器处于开启状态且开启时间短,则不发送状态PDU;
等待接收到P域为1的数据包后进入正常的状态PDU发送流程。
6.根据权利要求2所述的方法,其特征在于,所述方法还包括:
VR-MS至VR-H之间接收状态差时,其间未接收到的数据包多于M个,则不发送所述状态PDU;
待接收窗进一步接收,并等待接收到P域为1的数据包后进入正常的状态PDU发送流程。
7.根据权利要求1所述的方法,其特征在于,所述方法对适用于UE下行接收侧,同样适用于eNB上行接收侧。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610592860.8A CN107659959B (zh) | 2016-07-25 | 2016-07-25 | 一种专网无线通信***中上报接收数据状态的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610592860.8A CN107659959B (zh) | 2016-07-25 | 2016-07-25 | 一种专网无线通信***中上报接收数据状态的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107659959A true CN107659959A (zh) | 2018-02-02 |
CN107659959B CN107659959B (zh) | 2020-10-30 |
Family
ID=61127102
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610592860.8A Expired - Fee Related CN107659959B (zh) | 2016-07-25 | 2016-07-25 | 一种专网无线通信***中上报接收数据状态的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107659959B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108566264A (zh) * | 2018-04-13 | 2018-09-21 | 武汉虹信通信技术有限责任公司 | 触发无线链路控制层确认模式状态报告的方法及通信*** |
CN111132225A (zh) * | 2019-10-22 | 2020-05-08 | 翱捷智能科技(上海)有限公司 | 一种am模式下的rlc实体的接收侧及其接收数据的方法 |
WO2021249190A1 (zh) * | 2020-06-08 | 2021-12-16 | 中兴通讯股份有限公司 | 协议数据单元处理方法、装置、发送设备及存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1889414A (zh) * | 2005-06-30 | 2007-01-03 | 华为技术有限公司 | 一种基于丢失pdu检测机制发送状态pdu的方法 |
CN101989899A (zh) * | 2009-07-31 | 2011-03-23 | 中兴通讯股份有限公司 | 一种无线链路控制层触发状态报告的方法及接收侧装置 |
CN102957522A (zh) * | 2011-08-24 | 2013-03-06 | 中兴通讯股份有限公司 | 一种rlc am状态报告处理的方法和*** |
WO2015165418A1 (zh) * | 2014-04-30 | 2015-11-05 | 夏普株式会社 | Pdcp发送实体、辅基站、用户设备及其方法 |
-
2016
- 2016-07-25 CN CN201610592860.8A patent/CN107659959B/zh not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1889414A (zh) * | 2005-06-30 | 2007-01-03 | 华为技术有限公司 | 一种基于丢失pdu检测机制发送状态pdu的方法 |
CN101989899A (zh) * | 2009-07-31 | 2011-03-23 | 中兴通讯股份有限公司 | 一种无线链路控制层触发状态报告的方法及接收侧装置 |
CN102957522A (zh) * | 2011-08-24 | 2013-03-06 | 中兴通讯股份有限公司 | 一种rlc am状态报告处理的方法和*** |
WO2015165418A1 (zh) * | 2014-04-30 | 2015-11-05 | 夏普株式会社 | Pdcp发送实体、辅基站、用户设备及其方法 |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108566264A (zh) * | 2018-04-13 | 2018-09-21 | 武汉虹信通信技术有限责任公司 | 触发无线链路控制层确认模式状态报告的方法及通信*** |
CN108566264B (zh) * | 2018-04-13 | 2021-03-16 | 武汉虹信科技发展有限责任公司 | 触发无线链路控制层确认模式状态报告的方法及通信*** |
CN111132225A (zh) * | 2019-10-22 | 2020-05-08 | 翱捷智能科技(上海)有限公司 | 一种am模式下的rlc实体的接收侧及其接收数据的方法 |
CN111132225B (zh) * | 2019-10-22 | 2021-12-31 | 翱捷智能科技(上海)有限公司 | 一种am模式下的rlc实体的接收侧及其接收数据的方法 |
WO2021249190A1 (zh) * | 2020-06-08 | 2021-12-16 | 中兴通讯股份有限公司 | 协议数据单元处理方法、装置、发送设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN107659959B (zh) | 2020-10-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108541360B (zh) | 通信*** | |
EP1976176B1 (en) | A method and apparatus for data retransmission | |
EP2315383B1 (en) | Method and apparatus for transmitting a status report | |
KR101199044B1 (ko) | 고속 업링크 패킷 접속 방식의 개선 | |
CN104247543B (zh) | 数据块传输的处理时间相关控制 | |
CN104080121B (zh) | 一种传输数据的方法及*** | |
CN104170303B (zh) | 一种数据传输方法、设备和*** | |
CN109923902A (zh) | 毫米波无线电通信中的阻塞探测 | |
CN104170341B (zh) | 一种数据传输方法、设备和*** | |
CN104812000A (zh) | 一种实现数据传输的方法及装置 | |
CN101009537A (zh) | 一种数据重传方法及*** | |
CN107370575A (zh) | 一种自动重传的调度方法、终端及网络侧设备 | |
WO2007024099A2 (en) | Method of transmitting control information for scheduling | |
CN102355336B (zh) | 一种bsr触发方法、装置及用户设备 | |
EP2063547B1 (en) | Adaptive power control for EDCH | |
JP5911977B2 (ja) | バッファ状態レポート方法および装置 | |
CN106171004A (zh) | 一种rlc数据包分流方法及基站 | |
CN102037669B (zh) | 增强恢复过程 | |
CN101222479A (zh) | 一种主动重传和周期应答的无线链路控制层实现方法 | |
CN107659959A (zh) | 一种专网无线通信***中上报接收数据状态的方法 | |
US11228399B2 (en) | Base station and data retransmission method thereof | |
CN101990240B (zh) | 一种无线链路控制层的数据发送方法及数据发送*** | |
CN108024288A (zh) | 一种信息处理方法及装置 | |
CN107302415A (zh) | 一种非正交数据重传模式的选择方法及装置 | |
CN101360262B (zh) | 通讯***中共享资源的控制方法及控制装置 |
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 | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20201030 |
|
CF01 | Termination of patent right due to non-payment of annual fee |