CN101132261A - 一种数据包重传方法和*** - Google Patents
一种数据包重传方法和*** Download PDFInfo
- Publication number
- CN101132261A CN101132261A CNA2006101115313A CN200610111531A CN101132261A CN 101132261 A CN101132261 A CN 101132261A CN A2006101115313 A CNA2006101115313 A CN A2006101115313A CN 200610111531 A CN200610111531 A CN 200610111531A CN 101132261 A CN101132261 A CN 101132261A
- Authority
- CN
- China
- Prior art keywords
- last packet
- transmitting terminal
- status report
- receiving terminal
- receiving
- 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.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明提供一种数据包重传方法和***,本发明中的发送端在发送最后一个数据包、且接收到最后一个数据包对应的确认消息后,主动向接收端发送请求,以触发状态报告;接收端根据其接收的请求向发送端发送状态报告;发送端根据其接收的状态报告进行重传处理。发送端通过主动触发状态报告,使接收端能够快速、准确的接收到最后一个数据包,有效解决了最后一个数据包丢失的问题;本发明发送端的主动重传可以通过多种方式来实现,如直接主动重传、间接主动重传、无条件主动重传、附条件主动重传等;从而通过本发明提供的技术方案实现了降低数据包的重传时延,提高数据包重传效率的目的。
Description
技术领域
本发明涉及网络通讯技术领域,具体涉及一种数据包重传方法和***。
背景技术
WCDMA(宽带码分多址接入)的研究工作是从20世纪90年代初开始的。从98年开始到现在,WCDMA***的技术规范已经走过了Release 99、Release 4、Release 5、Release 6这几个阶段,目前关于Release 7的标准化工作已经开始实施,与此同时,LTE(Long Term Evolution长期演进)的研究也已经开始逐渐成为标准化工作的新热点。
在Release 99的WCDMA***中,上下行均采用专用信道,能够到达的最大速率为384kbps。在Release 4中,开始将MSC(Mobile Service Switch Center,移动业务交换中心)***为MSC Server和MGW(Multi-media GateWay,多媒体网关),从而将控制和业务分开。在Release 5中,引入了IMS(IP Multi-mediaSubsystem,IP多媒体子网)的概念、以及基于IP的传输层,并在无线接入技术上引入了HSDPA(High Speed Downlink Packet Access,高速下行分组接入),使得WCDMA***的下行速率可以达到14.4Mbps。在Release 6中,引入HSUPA(High Speed Uplink Packet Access,高速上行分组接入)技术,使得WCDMA***的上行速率能够达到5.76Mbps。
上述四个标准基本上已经比较稳定,目前,Release 7协议的目标是:在Release 6的基础上进行小的改动,以改善WCDMA***性能。LTE从***框架到物理层都将是全新的,LTE旨在为用户提供更高速率、更好性能的服务。目前LTE中的UTRAN被称为E-UTRAN(evolved UMTS Terrestrial Radio AccessNetwork,演进的UMTS陆地无线接入网)。
E-UTRAN***架构如附图1所示。
图1中,aGW处于核心网,一个核心网中可以有多个aGW,一个aGW(accessgateway,接入网关)可以同时与多个eNodeB进行通信。AGW主要负责寻呼发起、LTE_IDLE的状态管理、用户面加密,PDCP(Packet Data ConvergenceProtocol,分组数据汇聚协议)、SAE(System Architecture Evolution,***架构演进)承载控制、NAS(Non Access stratum,非接入层)信令的安全及完整性保护等功能。
图1中的eNodeB位于接入网,与aGW相连,eNodeB主要负责寻呼信息的调度及传输、广播信息的调度及传输、上下行资源的分配、无线承载控制、无线管理控制、LTE_ACTIVE状态下的连接移动性控制等。
EUTRAN用户面的协议栈架构如附图2所示。
图2中,UE(用户设备)的协议栈包括:PHY(物理层)、MAC(媒质接入控制层)、RLC(无线链路控制层)、PDCP(分组数据汇聚协议)。ENodeB的协议栈包括:PHY(物理层)、MAC(媒质接入控制层)、RLC(无线链路控制层)。aGW通过PDCP与UE进行通信。
在WCDMA***中,接收端在接收到不正确的数据时,需要发送端重传。按照从高层到低层的顺序,传输错误的业务数据的重传分为:服务器重传、RLC层重传和物理层重传。物理层重传的是传输错误的物理帧,RLC层重传的是传输错误的RLC PDU,服务器重传的是TCP数据包。重传所处的协议层越高,重传消耗的时间就越长,业务时延也就越长,用户的感受也就越差。
对于RLC层而言,有3种业务模式:透明模式(Transparent Mode)、非确认模式(Non-acknowledgement Mode)和确认模式(Acknowledgement Mode),只有确认模式的业务才有RLC层重传,其他模式的业务即使传输错误了,也不会进行RLC层重传。
在确认模式中,RLC层重传的具体实现过程为:接收端在接收到正确的数据包时,向发送端发送ACK(确认)消息,发送端在接收到ACK消息后,删除相应的数据包。接收端在接收到错误的数据包时,向发送端发送NACK(非确认)消息,发送端在接收到NACK消息后,重发相应的数据包。
在HARQ重传过程中,会出现NACK->ACK的现象,即接收端发送的是NACK消息,由于传输异常,发送端接收到ACK消息,这样,发送端会根据其接收到的ACK消息删除相应的数据包,从而导致接收端无法接收到正确的数据包。这个丢失的数据包将由ARQ重传恢复。
目前,接收端判断数据包是否发生NACK->ACK的方法如附图3所示。
图3中,接收端的HARQ(混合自动重传)实体根据下一个数据包的接收状况判断上一个数据包是否发生了NACK->ACK情况,如在上一个TTI(传输时间间隔)接收端发出的是NACK,但是,在本次TTI,接收端接收到的是新数据,那么,接收端可以认为上一个TTI发送的数据发生了NACK->ACK现象。
接收端在检测到NACK->ACK现象时,可以向发送端发送NACK->ACK错误报告,以请求发送端RLC的高层ARQ(自动重传请求)实体重传相应数据。
在上述方法中,由于接收端是根据下一个数据包的接收状况来判断NACK->ACK现象的,因此,对于最后一个数据包,如果发生了NACK->ACK状况,则接收端不能够判断出最后一个数据包是否发生了NACK->ACK现象,从而导致数据丢失。
为解决最后一个数据包的NACK->ACK现象,在WCDMA***中,接收端的ARQ实体在等待一定时间后,如果仍然没有接收到最后一个数据包,则确定最后一个数据包发生了NACK->ACK现象,此时,接收端触发状态报告,以请求发送端重传最后一个数据包。
该方法虽然能够检测出最后一个数据包的NACK->ACK现象,但是,需要等待一定的时间间隔才能检测出最后一个数据包的NACK->ACK现象,因此,需要使用较长时间才能重传最后一个数据包,增加了数据包的重传时延。而如果应用的是异步HARQ,由于调度的时间很难掌握,上述等待的时间间隔很难设定,而且由于接收端无法知道哪个是最后一个数据包,因此,对于接收错误的数据包,接收端都需启动定时器,增加了***的复杂性。
发明内容
本发明的目的在于,提供一种数据包重传方法和***,有效解决了最后一个数据包丢失的问题,降低了数据包的重传时延。
为达到上述目的,本发明提供的一种数据包重传方法,包括:
a、发送端在发送最后一个数据包、且接收到最后一个数据包对应的确认消息后,主动向接收端发送请求,以触发状态报告;
b、接收端根据其接收的请求向发送端发送状态报告;
c、发送端根据其接收的状态报告进行数据包重传处理。
所述步骤a中主动向接收端发送请求的步骤包括:
发送端无条件主动向接收端发送请求;或者
发送端在条件满足时主动向接收端发送请求。
发送端通过用户数据、信令向接收端发送请求。
所述最后一个数据包中含有触发RLC层状态报告的信息,且所述步骤a具体包括:
发送端HARQ在发送最后一个数据包、且接收到最后一个数据包对应的ACK后,不删除所述最后一个数据包,并无条件主动重传所述最后一个数据包。
所述最后一个数据包中含有触发RLC层状态报告的信息,且所述步骤a具体包括:
发送端HARQ在发送最后一个数据包、且接收到最后一个数据包对应的ACK后,不删除最后一个数据包,发送端HARQ在第一预定时间间隔内没有接收到状态报告,则主动重传所述最后一个数据包。
所述步骤a还包括:
发送端在接收到状态报告或者所述最后一个数据包超过最大重传次数后,删除所述最后一个数据包。
所述步骤a具体包括:
发送端HARQ在发送最后一个数据包、且接收到最后一个数据包对应的ACK后,删除最后一个数据包;
发送端ARQ无条件主动向接收端ARQ发送请求,以触发接收端RLC层状态报告;所述数据包为:含有/不含有触发RLC层状态报告信息的数据包。
所述步骤a具体包括:
发送端HARQ在发送最后一个数据包、且接收到最后一个数据包对应的ACK后,删除最后一个数据包;
发送端ARQ在第二预定时间间隔内没有接收到状态报告,则向接收端ARQ发送请求,以触发状态报告。
所述步骤b包括:接收端在第三预定时间间隔内接收到多个触发状态报告的请求,向发送端发送一次状态报告。
本发明还提供一种数据包重传***,包括:发送端和接收端,发送端中设置有请求重传模块和重传模块,接收端中设置有发送模块;
请求重传模块:在发送端发送最后一个数据包、且接收到最后一个数据包对应的ACK后,主动向接收端发送请求,以触发状态报告;
发送模块:根据接收端接收的请求向发送端发送状态报告;
重传模块:根据发送端接收的状态报告进行数据包重传处理。
通过上述技术方案的描述可知,发送端通过主动触发接收端的状态报告,相对于现有技术中接收端在预定时间间隔后才能检测出最后一个数据包发生了NACK-ACK现象的技术方案而言,本发明能够快速触发接收端RLC层的状态报告,使接收端能够快速检测出最后一个数据包是否发生了丢失现象,这样,发送端就能够根据接收端的状态报告及时、准确的将丢失的最后一个数据包传输至接收端,使接收端能够快速、准确的接收到最后一个数据包,有效解决了最后一个数据包丢失的问题,同时降低了数据包的重传时延;本发明的接收端不需要为每个接收错误的数据包均设置定时器,降低了***实现的复杂度;本发明发送端的主动触发状态报告的过程可以通过多种方式来实现,如无条件主动触发、附条件主动触发等;从而通过本发明提供的技术方案实现了提高数据包重传效率、提高***重传性能的目的。
附图说明
图1是E-UTRAN***架构示意图;
图2是EUTRAN用户面的协议栈架构示意图;
图3是现有技术中的接收端检测数据包发生NACK->ACK的方法流程图;
图4是本发明实施例的数据包重传流程图。
具体实施方式
从现有技术方案的描述中可以看出,现有技术方案中的发送端采用被动重传的方法来重传最后一个数据包,也就是说,只有在接收端检测出最后一个数据包发生了NACK->ACK现象,并请求发送端重传最后一个数据包时,发送端才会重传最后一个数据包。
在本发明提供的技术方案中,发送端采用了主动重传的方法来重传最后一个数据包,即发送端在发送最后一个数据包、且接收到最后一个数据包对应的ACK后,主动触发接收端的状态报告,这样,发送端可以根据其主动触发的状态报告来进行数据包的重传过程。
本发明的数据包重传的过程如附图4所示。
图4中,在步骤400、发送端在发送最后一个数据包、且接收到最后一个数据包对应的确认消息后,主动向接收端发送请求。发送端可以采用持续发送、定时发送等方式发送触发状态报告的请求。
到步骤410、接收端根据其接收的请求向发送端发送包含最后一个数据包接收情况的状态报告。当接收端在一定的时间间隔内接收到多个针对最后一个数据包触发状态报告的请求时,接收端可以只向发送端发送一个状态报告。
到步骤420、发送端根据其接收的状态报告进行判断,判断接收端是否正确接收到最后一个数据包,如果接收端正确接收到最后一个数据包,则到步骤421,本次最后一个数据包的重传过程结束。
在步骤420,如果接收端没有正确接收端最后一个数据包,则到步骤422,发送端进行数据包重传。
本发明中的主动触发状态报告的具体表现形式有多种,如无条件主动触发、附条件主动触发等。
无条件主动触发即发送端在发送了最后一个数据包、且接收到最后一个数据包对应的ACK后,不进行条件判断,直接向接收端发送请求,触发接收端的状态报告,以实现最后一个数据包的主动重传。
在无条件主动触发的实现过程中,本发明可以由发送端的ARQ实体向接收端的ARQ实体发送请求,也可以由发送端的HARQ实体向接收端的HARQ实体发送请求。
当最后一个数据包中包含有触发状态报告信息时,最后一个数据包可以作为发送端HARQ发送的触发状态报告的请求,此时,发送端HARQ在发送了最后一个数据包、且接收到最后一个数据包对应的ACK后,不删除最后一个数据包,直接将最后一个数据包发送至接收端的HARQ。
本发明的发送端如HARQ实体、ARQ实体也可以通过其他方式来发送触发状态报告的请求,如通过用户数据、信令等方式发送触发状态报告的请求,这里的信令如RRC信令、物理层信令等,这里的用户数据如RLC PDU、MAC控制PDU、最后一个数据包等。当发送端HARQ实体采用除最后一个数据包之外的其他用户数据、信令等发送请求时,发送端HARQ实体可以删除最后一个数据包。
当发送端采用无条件主动触发方式时,接收端会接收到至少一个触发状态报告的请求,如接收端会接收到至少一个最后一个数据包,再如接收端会接收到至少一个携带有触发状态报告的用户数据、信令等,接收端可以在第三预定时间间隔内接收到多个触发状态报告的请求如多个最后一个数据包后,仅向发送端回复一个状态报告。当然,本发明也不排除接收端针对其接收到的多个触发状态报告的请求如接收到多个最后一个数据包,而向发送端回复多个状态报告的技术方案。
在上述无条件主动触发实现过程的描述中,本发明中的发送端和接收端均不需要判断最后一个数据包是否发生了NACK->ACK现象,发送端在发送了最后一个数据包、且接收到最后一个数据包对应的ACK后,直接将触发状态报告的请求发送至接收端,这样,接收端会根据该请求生成状态报告,并发送至发送端,从而避免了接收端等待一定的时间间隔来检测最后一个数据包的NACK->ACK现象的过程,减小了数据包重传时延。
附条件主动触发即发送端在发送了最后一个数据包、且接收到最后一个数据包对应的ACK后,进行条件判断,并在预先设定的条件满足时,向接收端发送请求,触发接收端的状态报告,以实现最后一个数据包的主动重传。
当最后一个数据包中包含有触发状态报告信息时,最后一个数据包可以作为发送端HARQ发送的触发状态报告的请求,此时,发送端HARQ在发送了最后一个数据包、且接收到最后一个数据包对应的ACK后,不删除最后一个数据包,直接将最后一个数据包发送至接收端的HARQ。
本发明的发送端如HARQ实体、ARQ实体也可以通过其他方式来发送触发状态报告的请求,如通过用户数据、信令等方式发送触发状态报告的请求,这里的信令如RRC信令、物理层信令等,这里的用户数据如RLC PDU、MAC控制PDU、最后一个数据包等。
这里的条件可以是目前通用的多种形式,而且,条件可以根据实际应用来设置,如设置时间条件等,本发明不限制条件的表现形式。下面以时间条件为例进行说明。
在附条件主动触发过程中,发送端在发送了最后一个数据包、且接收到最后一个数据包对应的ACK后,需要在一定的时间间隔内判断其是否接收到包含最后一个数据包接收情况的状态报告,如果发送端在一定的时间间隔内接收到包含最后一个数据包接收情况的状态报告时,则不向接收端发送触发状态报告的请求;如果发送端在一定的时间间隔内没有接收到包含最后一个数据包接收情况的状态报告,则发送端向接收端发送触发状态报告的请求。这样,接收端会根据该请求生成状态报告,并发送至发送端,从而避免了接收端等待一定的时间间隔来检测最后一个数据包的NACK->ACK现象的过程,减小了重传时延。
在附条件主动触发的实现过程中,本发明可以由发送端的ARQ实体进行条件判断,并向接收端的ARQ实体发送请求,也可以由发送端的HARQ实体进行条件判断,并向接收端的HARQ实体发送请求。
在附条件主动触发的实现过程中,当最后一个数据包中包含有触发状态报告信息时,最后一个数据包可以作为发送端HARQ发送的触发状态报告的请求,此时,发送端HARQ在发送了最后一个数据包、且接收到最后一个数据包对应的ACK后,不删除最后一个数据包,在第一预定时间间隔内,如果发送端没有接收到包含最后一个数据包接收情况的状态报告,则发送端HARQ将最后一个数据包发送至接收端的HARQ。
本发明的发送端也可以通过其他方式来发送触发状态报告的请求,如通过用户数据、信令等方式发送触发状态报告的请求,这里的信令如RRC信令、物理层信令等,这里的用户数据如RLC PDU、MAC控制PDU、最后一个数据包等。此时,发送端HARQ在发送了最后一个数据包、且接收到最后一个数据包对应的ACK后,删除最后一个数据包,如果发送端在第二预定时间间隔内接收到包含最后一个数据包接收情况的状态报告,则发送端ARQ不发送触发状态报告的请求;如果发送端在第二预定时间间隔没有接收到包含最后一个数据包接收情况的状态报告,则发送端ARQ将触发状态报告的请求发送至接收端的ARQ。
当发送端采用附条件主动触发方式时,接收端同样会接收到至少一个触发状态报告的请求,接收端可以在第三预定时间间隔内接收到多个触发状态报告的请求后,仅向发送端回复一个包含最后一个数据包接收情况的状态报告。当然,本发明也不排除接收端针对其接收到的多个触发状态报告的请求如接收到多个最后一个数据包,而向发送端回复多个状态报告的技术方案。
在上述附条件主动触发实现过程的描述中,本发明中的发送端和接收端均不需要判断最后一个数据包是否发生了NACK->ACK现象,从而避免了接收端等待一定的时间间隔来检测最后一个数据包的NACK->ACK现象的过程,减小了数据包重传时延。
在本发明的技术方案中,虽然发送端也是根据接收端发送来的状态报告来实现数据包的重传的,但是,该方法和现有技术中的方法在本质上是完全不同的,其不同之处主要体现在:在现有技术中,发送端完全是被动的等待接收端的状态报告,也就是说,状态报告是否需要发送完全由接收端来决定;而在本发明的技术方案中,状态报告是应发送端的主动请求而发送的,也就是说,状态报告是否需要发送是由发送端来决定。
下面以五种具体的实现方式为例,对本发明提供的RLC层的数据包重传技术方案进行说明。
实施方式1、无条件主动触发方式。
当发送端HARQ发送最后一个含有触发状态报告信息如polling比特的数据包、且接收到最后一个数据包对应的ACK后,则主动无条件的重传该最后一个数据包。这样,接收端HARQ会接收到多于一个的最后一个数据包。为避免接收端针对最后一个数据包向发送端回复多次状态报告,则接收端可以设置一个预定时间间隔,即设定第三预定时间间隔status prohibit timer,如果接收端确定其在status prohibit timer内接收到多于一个的polling比特信息,则接收端只针对最后一个数据包向发送端发送一次状态报告;如果接收端确定其在statusprohibit timer内接只收到一个的polling比特信息,则接收端针对最后一个数据包向发送端发送状态报告。也就是说,接收端无论在status prohibit timer内接收到几个polling比特信息,均向发送端发送一次状态报告。发送端在接收到最后一个数据包对应的状态报告、且得知接收端已正确接收到最后一个数据包,则删除最后一个数据包,发送端在接收到最后一个数据包对应的状态报告、且得知接收端没有正确接收到最后一个数据包,则重传最后一个数据包。
实施方式2、附条件主动触发方式。
当发送端HARQ发送最后一个含有触发状态报告信息如polling比特的数据包、且接收到最后一个数据包对应的ACK后,不删除该最后一个数据包,而是在第一预定时间间隔内等待接收端的状态报告,如果在第一预定时间间隔内没有接收到接收端发送的状态报告,则发送端HARQ重传该最后一个数据包,接收端无论在status prohibit timer内接收到几个polling比特信息,均向发送端发送一次状态报告。如果发送端在第一预定时间间隔内接收到接收端发送来的状态报告、且得知接收端已正确接收到最后一个数据包,则删除该数据包;如果发送端在第一预定时间间隔内接收到接收端发送来的状态报告、且得知接收端没有正确接收到最后一个数据包,则重传最后一个数据包。这里的第一预定时间间隔timer可以根据实际应用来设置,如设置timer为1个TTI或者2个TTI等。
实施方式3、无条件主动触发方式。
当发送端HARQ发送最后一个不合有触发状态报告信息如polling比特的数据包、且接收到最后一个数据包对应的ACK后,删除最后一个数据包,发送端ARQ通过RRC信令、或者MAC控制PDU、或者RLC控制PDU、或者物理层信令等使接收端高层RLC中的ARQ实体生成状态报告,接收端无论在status prohibittimer内接收到几个触发状态报告的请求,均向发送端发送一次状态报告。接收端在根据请求发送状态报告后,发送端根据其接收的状态报告来判断哪些RLCPDU需要重传,并进行相应的重传处理。
实施方式4、无条件主动触发方式。
当发送端HARQ发送最后一个含有触发状态报告信息如polling比特的数据包、且接收到最后一个数据包对应的ACK后,删除该最后一个数据包,发送端ARQ通过RRC信令、或者物理层信令、或者MAC控制PDU、或者RLC控制PDU等使接收端高层RLC中的ARQ实体生成状态报告,接收端无论在status prohibittimer内接收到几个触发状态报告的请求,均向发送端发送一次状态报告。接收端在根据请求发送状态报告后,发送端根据其接收的状态报告来判断哪些RLCPDU需要重传,并进行相应的重传处理。
实施方式5、附条件主动触发方式。
当发送端HARQ发送最后一个含有触发状态报告信息如polling比特的数据包、且接收到最后一个数据包对应的ACK后,删除该最后一个数据包,发送端ARQ在第二预定时间间隔内等待接收端的状态报告,如果发送端在第二预定时间间隔内没有接收到接收端发送的状态报告,则发送端通过RRC信令、或者MAC控制PDU、或者RLC控制PDU、或者物理层信令等使接收端高层RLC中的ARQ实体生成状态报告,接收端无论在status prohibit timer内接收到几个触发状态报告的请求,均向发送端发送一次状态报告。接收端在根据请求发送状态报告后,发送端根据其接收的状态报告来判断哪些RLC PDU需要重传,并进行相应的重传处理。
上述第一预定时间间隔、第二预定时间间隔、第三预定时间间隔可以相同,也可以不相同。
本发明提供的数据包重传***包括:发送端和接收端,发送端中设置有请求重传模块和重传模块,接收端中设置有发送模块。
请求重传模块主要用于在发送端发送最后一个数据包、且接收到最后一个数据包对应的ACK后,主动向接收端发送请求,以触发接收端的状态报告。请求重传模块发送的请求可以为包含触发状态报告信息的最后一个数据包,也可以为用户数据或信令。请求重传模块可以采用无条件触发、附条件触发等多种方式触发接收端的状态报告,具体如上述方法中的描述。
发送模块主要用于根据接收端接收的请求向发送端发送状态报告。发送模块可以在第三预定时间间隔内接收到多个请求时,仅向发送端发送一个状态报告;具体如上述方法中的描述。
重传模块主要用于根据发送端接收的状态报告进行数据包重传处理,即重传模块根据状态报告判断接收端是否正确接收到最后一个数据包,并根据判断结果进行相应的操作,具体如上述方法中的描述。
虽然通过实施例描绘了本发明,本领域普通技术人员知道,本发明有许多变形和变化而不脱离本发明的精神,本发明的申请文件的权利要求包括这些变形和变化。
Claims (10)
1.一种数据包重传方法,其特征在于,所述方法包括步骤:
a、发送端在发送最后一个数据包、且接收到最后一个数据包对应的确认消息后,主动向接收端发送请求,以触发状态报告;
b、接收端根据其接收的请求向发送端发送状态报告;
c、发送端根据其接收的状态报告进行数据包重传处理。
2.如权利要求1所述的方法,其特征在于,所述步骤a中主动向接收端发送请求的步骤包括:
发送端无条件主动向接收端发送请求;或者
发送端在条件满足时主动向接收端发送请求。
3.如权利要求1或2所述的方法,其特征在于,发送端通过用户数据、信令向接收端发送请求。
4.如权利要求3所述的方法,其特征在于,所述最后一个数据包中含有触发RLC层状态报告的信息,且所述步骤a具体包括:
发送端HARQ在发送最后一个数据包、且接收到最后一个数据包对应的ACK后,不删除所述最后一个数据包,并无条件主动重传所述最后一个数据包。
5.如权利要求3所述的方法,其特征在于,所述最后一个数据包中含有触发RLC层状态报告的信息,且所述步骤a具体包括:
发送端HARQ在发送最后一个数据包、且接收到最后一个数据包对应的ACK后,不删除最后一个数据包,发送端HARQ在第一预定时间间隔内没有接收到状态报告,则主动重传所述最后一个数据包。
6.如权利要求4或5所述的方法,其特征在于,所述步骤a还包括:
发送端在接收到状态报告或者所述最后一个数据包超过最大重传次数后,删除所述最后一个数据包。
7.如权利要求3所述的方法,其特征在于,所述步骤a具体包括:
发送端HARQ在发送最后一个数据包、且接收到最后一个数据包对应的ACK后,删除最后一个数据包;
发送端ARQ无条件主动向接收端ARQ发送请求,以触发接收端RLC层状态报告;所述数据包为:含有/不含有触发RLC层状态报告信息的数据包。
8.如权利要求3所述的方法,其特征在于,所述步骤a具体包括:
发送端HARQ在发送最后一个数据包、且接收到最后一个数据包对应的ACK后,删除最后一个数据包;
发送端ARQ在第二预定时间间隔内没有接收到状态报告,则向接收端ARQ发送请求,以触发状态报告。
9.如权利要求1或2所述的方法,其特征在于,所述步骤b包括:
接收端在第三预定时间间隔内接收到多个触发状态报告的请求,向发送端发送一次状态报告。
10.一种数据包重传***,包括:发送端和接收端,其特征在于,发送端中设置有请求重传模块和重传模块,接收端中设置有发送模块;
请求重传模块:在发送端发送最后一个数据包、且接收到最后一个数据包对应的ACK后,主动向接收端发送请求,以触发状态报告;
发送模块:根据接收端接收的请求向发送端发送状态报告;
重传模块:根据发送端接收的状态报告进行数据包重传处理。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2006101115313A CN101132261A (zh) | 2006-08-21 | 2006-08-21 | 一种数据包重传方法和*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2006101115313A CN101132261A (zh) | 2006-08-21 | 2006-08-21 | 一种数据包重传方法和*** |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101132261A true CN101132261A (zh) | 2008-02-27 |
Family
ID=39129395
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2006101115313A Pending CN101132261A (zh) | 2006-08-21 | 2006-08-21 | 一种数据包重传方法和*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101132261A (zh) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011057559A1 (zh) * | 2009-11-10 | 2011-05-19 | 中兴通讯股份有限公司 | 分组数据会聚协议状态报告的获取方法和分组数据会聚协议实体 |
CN103107870A (zh) * | 2011-11-11 | 2013-05-15 | 智邦科技股份有限公司 | 无线网络装置及其自动设定参数方法 |
CN103607263A (zh) * | 2008-05-30 | 2014-02-26 | 交互数字专利控股公司 | Wtru、在wtru中实施的接收切换消息的方法及集成电路 |
CN104137507A (zh) * | 2013-01-31 | 2014-11-05 | 华为技术有限公司 | 反馈丢包的消息处理方法及装置 |
CN106160955A (zh) * | 2015-03-26 | 2016-11-23 | 瑞昱半导体股份有限公司 | 控制无线用户设备主动重传无线资源控制信息的控制电路 |
CN107959554A (zh) * | 2016-10-14 | 2018-04-24 | ***通信有限公司研究院 | 一种数据的重传方法及装置 |
CN109845317A (zh) * | 2016-10-18 | 2019-06-04 | 华为技术有限公司 | 数据传输方法及设备 |
CN110213024A (zh) * | 2018-04-26 | 2019-09-06 | 腾讯科技(深圳)有限公司 | 数据包重传方法、装置及设备 |
CN112996052A (zh) * | 2021-02-08 | 2021-06-18 | 展讯通信(上海)有限公司 | 数据发送控制方法及装置、终端、基站和介质 |
-
2006
- 2006-08-21 CN CNA2006101115313A patent/CN101132261A/zh active Pending
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103607263B (zh) * | 2008-05-30 | 2017-08-01 | 交互数字专利控股公司 | Wtru、在wtru中实施的接收切换消息的方法及集成电路 |
CN103607263A (zh) * | 2008-05-30 | 2014-02-26 | 交互数字专利控股公司 | Wtru、在wtru中实施的接收切换消息的方法及集成电路 |
CN102056226B (zh) * | 2009-11-10 | 2016-03-02 | 中兴通讯股份有限公司 | Pdcp状态报告的获取方法和pdcp实体 |
US8743831B2 (en) | 2009-11-10 | 2014-06-03 | Zte Corporation | Method for acquiring packet data convergence protocol status report and packet data convergence protocol entity |
WO2011057559A1 (zh) * | 2009-11-10 | 2011-05-19 | 中兴通讯股份有限公司 | 分组数据会聚协议状态报告的获取方法和分组数据会聚协议实体 |
CN103107870B (zh) * | 2011-11-11 | 2016-08-10 | 智邦科技股份有限公司 | 无线网络装置及其自动设定参数方法 |
CN103107870A (zh) * | 2011-11-11 | 2013-05-15 | 智邦科技股份有限公司 | 无线网络装置及其自动设定参数方法 |
CN104137507A (zh) * | 2013-01-31 | 2014-11-05 | 华为技术有限公司 | 反馈丢包的消息处理方法及装置 |
CN106160955A (zh) * | 2015-03-26 | 2016-11-23 | 瑞昱半导体股份有限公司 | 控制无线用户设备主动重传无线资源控制信息的控制电路 |
CN107959554A (zh) * | 2016-10-14 | 2018-04-24 | ***通信有限公司研究院 | 一种数据的重传方法及装置 |
CN107959554B (zh) * | 2016-10-14 | 2019-08-20 | ***通信有限公司研究院 | 一种数据的重传方法及装置 |
CN109845317A (zh) * | 2016-10-18 | 2019-06-04 | 华为技术有限公司 | 数据传输方法及设备 |
CN110213024A (zh) * | 2018-04-26 | 2019-09-06 | 腾讯科技(深圳)有限公司 | 数据包重传方法、装置及设备 |
CN112996052A (zh) * | 2021-02-08 | 2021-06-18 | 展讯通信(上海)有限公司 | 数据发送控制方法及装置、终端、基站和介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8208394B2 (en) | Service data unit discard timers | |
JP4981904B2 (ja) | 媒体アクセス制御破棄通知 | |
EP2618517B1 (en) | Method of supporting data retransmission in a mobile communication system | |
KR101273407B1 (ko) | 멀티캐리어 lte 시스템들을 위한 rlc | |
US8649279B2 (en) | Apparatus and method for adaptive TSP setting to minimize duplicate packet transmissions | |
KR101098592B1 (ko) | 무선 통신 시스템상에서 점대다 서비스를 수신하는 방법 | |
CN101132261A (zh) | 一种数据包重传方法和*** | |
JP5048135B2 (ja) | 無線通信システムにおけるポーリング手順の実行方法 | |
KR20170108006A (ko) | 무선 링크 제어 스위칭을 위한 방법들 및 장치 | |
KR20100053625A (ko) | 무선 통신 시스템에서의 핸드오버 동안 데이터의 계층 2 터널링 | |
KR20090083867A (ko) | Rlc 무한 재전송 오류를 검출하고 처리하는 방법 | |
CN101132257B (zh) | 一种状态报告的传输方法和发送端设备 | |
US8194559B2 (en) | Method of controlling data retransmission in a wireless communication system | |
US9306710B2 (en) | RCC connection establishment method and apparatus in communication system background of the invention | |
KR101470638B1 (ko) | 이동통신 시스템에서의 무선자원 향상 방법, 상태정보 보고방법 및 수신장치 | |
Meyer et al. | ARQ concept for the UMTS long-term evolution | |
WO2007137509A1 (fr) | Procédé de transmission d'informations d'ordonnancement sur un canal spécialisé amélioré et terminal utilisateur | |
KR20100002111A (ko) | 피어 엔티티의 전송 상태 정보를 이용한 데이터 유닛 재전송 방법 | |
Ali-Yahiya et al. | LTE Radio Layer Design |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Open date: 20080227 |