本发明涉及移动通信
技术领域：
：，尤其是涉及一种触发无线链路控制层确认模式(rlcam)状态报告的方法及相应通信系统。
背景技术：
：：rlc(radiolinkcontrol，无线链路控制)协议层在lte的无线接口协议栈中，是层2(l2)的一个子层，位于mac(mediaaccesscontrol，媒体接入控制)层之上，pdcp(packetdataconvergenceprotocol，包数据汇聚协议)层之下。rlc协议层的功能包括链接控制、用户数据传输(包括分段、级联、重分段、重排序、重组等)、纠错、协议错误检测和修复等，为用户面和控制面数据提供分段和重传业务。每个rlc协议实体由rrc(radioresourcecontrol，无线资源控制)层配置并以三种数据传输模式进行工作，分别为：透传模式(tm,transparentmode)、非确认模式(um,unacknowledgedmode)和确认模式(am,acknowledgedmode)。确认模式中的arq(automaticrepeatrequest,自动重传请求)是通过接收端向发送端反馈状态报告(statusreport)，发送端根据收到的statusreport中的ack_sn(状态报告截止的报文编号)和nack_sn(ack_sn之前未收到报文的报文编号)来判定哪些pdu(protocoldataunit，协议数据单元)已经被接收端确认收到，哪些pdu或pdu分片需要重传，从而保证数据传输的可靠性。36.322协议中，目前对确认模式下状态报告的触发过程涉及到了两个定时器，都用在rlc的数据传输接收端。首先是重排序定时器t-reordering，t-reordering用于检测底层数据的丢失情况，超时后向发送端发送状态报告。其次是状态报告禁止定时器t-statusprohibit，t-statusprohibit用于限制状态报告的发送频率，即两次状态报告的发送时刻需要满足一定的时间间隔，这个间隔就是该定时器时长。目前状态报告的触发有两种方式：1、rlc发送端通过轮询的方式触发；2、rlc接收端检测到pdu接收失败(重排序定时器超时)。这里主要介绍一下和本发明相关的第二种方式。首先，rlc接收端若检测到报文不是按照顺序到达的，就会立即启动重排序定时器t-reordering，t_reordering定时器超时会触发vr(ms)(maximumstatustransmitstatevariable，最大status状态报告反馈变量)的更新和状态报告的发送，vr(ms)在数据接收窗口中用于标识构造状态报告的截止位置，即前述ack_sn的取值，状态报告的发送必须在vr(ms)的更新之后触发。其次，状态报告的触发并不是毫无限制的，需要满足一定的发送间隔。若t-statusprohibit(statusprohibittimer，状态报告禁止定时器)没有运行，则在mac层指示的第一个传输机会到来时，构造statusreport并向底层发送；否则，在t-statusprohibit定时器超时之后的第一个mac层指示的传输机会到来时，构造statusreport并向底层发送。当一个状态报告已经向底层发送，rlcam实体接收端会启动t-statusprohibit定时器。可以知道，确认模式下报文的传输需要通过状态报告来进行确认。而状态报告的触发方式之一就是重排序定时器t-reordering超时，t-reordering实质上就是对由于底层harq(hybridautomaticrepeatrequest，混合自动重传请求)重传导致的乱序包进行排序过程的一个定时器，如果超时了，就认为底层harq已经无法解决问题了，这个时候对于这部分没有排好序的包(小于vr(ms))就可以通过发送状态报告的方式触发rlc发送端进行arq重传。基于协议的这一设计，在实际现网应用过程中，t-reordering配置时长通常是大于底层harq最大重传所需要消耗的时间的，于是就存在了一个时间差，当发送端底层达到harq最大重传仍没有成功的时候，接收端rlc层并不会立即触发状态报告回复而仍然等待harq重传直至t-reordering超时。针对高可靠性业务传输时，采用有反馈确认的双向链路传输需要正向和反向链路都具有较小的时延和可靠的传输性能。在高速率业务场景下，正向业务数据pdu传输和反向状态报告pdu传输的丢失都会导致rlc的arq重传，进而容易导致发送窗口满并影响业务速率。而反向状态报告回复的时延同样也会导致发送端发送窗口满无法发送新的pdu，影响业务速率。现有相关技术中，接收端rlc层检测底层数据丢失情况只能通过t-reordering超时来进行判断，实时性不佳，无法第一时间做出反馈。同时由于t-statusprohibit定时器的存在，当信道传输质量不佳时，容易造成窗口因被撑满而停滞的情况，此时可能至少需要等待一个状态禁止定时器周期才能解除窗口的停滞状态，从而造成空口数据传输延迟，时延增大，影响用户体验。因此本领域亟待相关解决方案出现。技术实现要素：本发明的主要目的在于克服现有技术，本发明提供了一种触发无线链路控制层确认模式状态报告的方法及相应通信系统，通过提高状态报告的实时性，解决由于状态报告回复不及时所引起的空口数据传输时延增大及发送端负荷较大的问题。本发明所采用的技术方案包括一种触发无线链路控制层确认模式状态报告的方法，执行以下步骤：1)基站mac层混合自动重传请求harq达最大重传时上报指示到rlc层；2)基站rlc接收端收到指示立即触发t-reordering定时器超时判断流程；3)判断此时t-statusprohibit是否超时，若超时进入步骤5，否则进入步骤4；4)判断此时rlc接收端接收窗口状态，若此时接收窗口处于拥塞状态，则进入步骤6，否则进入步骤7；5)进入t-statusprohibit超时处理流程，完成状态报告的调度组包并传输下去；6)窗口拥塞触发的t-statusprohibit超时处理流程，完成状态报告的调度组包并传输下去；7)等待t-statusprohibit超时以触发后续处理流程。而且，步骤1中，接收端mac上报发送端harq已达最大重传指示给rlc，以此触发t-reordering定时器超时判断流程，开启状态报告回复。而且，步骤4中，对于接收端rlc接收窗口进行拥塞状态判别，拥塞度定义如下：接收窗实时拥塞度＝接收窗口缓存量/接收窗口长度接收窗实时拥塞度高于设置的拥塞门限时，判断此时接收窗口处于拥塞状态。而且，对拥塞门限预设初始值，根据实际的业务及信道场景进行动态调整。而且，拥塞门限的初始值设置为0.9。本发明还提供一种通信系统，执行如上所述触发无线链路控制层确认模式状态报告的方法。对比现有技术，本发明提供了一种am模式下状态报告的触发方法及相应通信系统，能够较好的提高状态报告的实时性。该系统能够很好的避免信道传输质量不佳情况下，由于状态报告回复不及时所引起的空口数据传输时延增大及发送端负荷较大的问题，进一步提升用户体验。附图说明图1为本发明实施例提供的rlc接收端接收窗口拥塞状态判别示意图。图2为本发明实施例提供的rlc接收端状态报告触发流程示意图。具体实施方式以下结合附图和实施例说明本发明技术方案。现有技术中，状态报告的触发依赖于发送端的轮询或者重排序定时器及状态禁止定时器的超时触发，实时性不佳，在信道传输质量较差时，容易引起发送端拖窗的现象，从而造成时延增大，影响用户体验。本发明通过接收端上报发送端harq最大重传来主动触发状态报告用以提高状态报告的实时性，进一步的，通过接收窗口的拥塞程度判定，自适应调整状态禁止定时器，解决信道质量不佳的情况下由于状态报告回复不及时引发的拖窗问题，进一步提升用户体验。参见附图2，本发明实施例在接收端提供状态报告触发流程，包含在基站中执行下列步骤：1)基站mac层harq达最大重传时，上报指示到rlc层；接收端mac上报发送端harq已达最大重传指示给rlc，以此触发t-reordering定时器超时判断流程，开启状态报告回复；2)基站rlc接收端收到该指示，立即触发t-reordering定时器超时流程，也就是即使实际上t-reordering定时器未超时，但视同t-reordering定时器超时；3)判断此时t-statusprohibit是否超时，若超时进入步骤5，否则进入步骤4；协议上规定的只有当t-statusprohibit超时后才允许进入状态报告反馈流程，目的在于控制状态报告反馈的频率，如果太频繁势必会占用太多空口带宽资源。当t-reordering定时器超时，t-statusprohibit可能超时也可能未超时，如果超时马上开始状态报告反馈，如果没有超时，则此时需要进入拥塞度判别，如果处于拥塞状态，那就表示窗口即将撑满，此时即使t-statusprohibit没有超时，也要进入t-statusprohibit超时流程(即开始进行状态报告反馈)，如果不处于拥塞状态，则继续等待t-statusprohibit超时，待超时后触发后续的状态报告反馈；4)判断此时rlc接收端接收窗口状态：若此时接收窗口处于拥塞状态，则进入步骤6，否则进入步骤7；对于接收端rlc接收窗口进行拥塞状态判别，拥塞度定义如下：接收窗实时拥塞度＝接收窗口缓存量/接收窗口长度接收窗口可设置一个接收阈值(vr(h)/vr(mr))，作为一项可配参数，在不同的场景及信道环境下可以实现动态配置，减小传输时延，提高传输性能，提升用户传输体验。若此时vr(h)/vr(mr)达到一定阈值(例如0.8，阈值越接近1表示rlc接收窗口越接近撑满状态，需要通过对vr(r)尽快进行状态反馈来触发vr(r)重传以触发vr(r)更新驱动接收窗口前移。拥塞门限可根据实际的业务及信道场景进行动态调整，初始值优选设置为0.9。vr(h)-highestreceivedstatevariable，接收到的最高状态变量，表示接收到的最大pdu(协议业务单元)的sn(sequencenumber，序列号)+1。vr(mr)-maximumacceptablereceivestatevariable，最大可接受的状态变量，表示可接收窗口的边界，恒等于vr(r)+windowsize，vr(r)和vr(mr)代表了接收端可接收窗口的上下边界。实际接收的pdusn必须在接收窗口边界内，超出边界外的pdu不接收直接丢弃。所以vr(h)一定小于vr(mr)。最理想的情况下，接收窗口无缓存，即vr(h)＝vr(r)+1，所以此时的拥塞度＝1/recevingwindowsize；另一种极端，接收窗口缓存被塞满，那么拥塞度就等于1。当拥塞度达到0.9了，表示窗口即将被占满了，此时要启动快速反馈，尽量驱动窗口前移，避免由于窗口撑满而导致接收停滞，数据传输中断。参见图1，当接收端底层mac上报发送端harq达最大重传或者接收端自身t-reordering定时器超时时，对当前的rlc接收窗进行拥塞状态判别，如果当前处于拥塞状态(即实时拥塞度高于设置的拥塞门限，(接收窗口剩余缓存量/接收窗口长度)大于拥塞门限)，即设置当前承载rlcam接收窗处于拥塞状态，主动触发t-statusprohibit超时，立即进行状态报告回复，否则设置当前承载rlcam接收窗处于非拥塞状态，等待t-statusprohibit超时以触发后续流程。5)进入t-statusprohibit超时处理流程，完成状态报告的调度组包并传输下去；按标准协议，t-statusprohibit超时后的处理流程如下：1.构造statusreport2.按需重启t-reorderdingtmr6)窗口拥塞触发的t-statusprohibit超时处理流程，完成状态报告的调度组包并传输下去；由于此时是窗口处于拥塞状态触发的t-statusprohibit超时，所以与正常的超时相比，需要主动停止t-statusprohibit定时器，流程如下：1.stopt-statusprohibittmr2.构造statusreport3.按需重启t-reorderingtmr7)等待t-statusprohibit超时以触发后续处理流程；具体实施时，可以预先进行接收端rlc设置am接收窗口拥塞门限。该流程考虑了正常超时、等待超时以及未超时但是窗口拥塞情况下直接触发的超时，在窗口拥塞的情况下，就不考虑状态报告是否频繁，进行状态回复，尽快推动窗口前移，避免窗口撑满丢包断流。通过以上步骤实施，能够有效的提高信道传输质量不佳时rlcam状态报告的实时性，解决由于状态报告回复不及时所引起的空口数据传输时延增大及发送端负荷较大的问题，进一步提升用户体验。具体实施时，本发明所提供方法可基于软件技术实现自动运行流程，运行该方法的相应通信系统也在本发明保护范围内，本发明不予赘述。以上内容是结合具体的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属
技术领域：
：的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。当前第1页12当前第1页12