CN101030839A - 一种数据重传的方法 - Google Patents
一种数据重传的方法 Download PDFInfo
- Publication number
- CN101030839A CN101030839A CN 200710073312 CN200710073312A CN101030839A CN 101030839 A CN101030839 A CN 101030839A CN 200710073312 CN200710073312 CN 200710073312 CN 200710073312 A CN200710073312 A CN 200710073312A CN 101030839 A CN101030839 A CN 101030839A
- Authority
- CN
- China
- Prior art keywords
- rlc pdu
- receiver
- sender
- sequence number
- status report
- 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)
- Communication Control (AREA)
Abstract
本发明公开了一种数据重传的方法,若接收方检测到当前已接收的最大序列号RLC PDU不是当前正在接收的SDU的最后一个RLC PDU时,启动预先设定的定时器;在所述定时器超时前,若接收方接收到了下一个RLC PDU,则返回步骤A;否则,在所述定时器超时前若接收方没有接收到下一个RLC PDU,则接收方判断在传输过程中出现丢包,向发送方发送状态报告;发送方收到所述状态报告后,根据状态报告重新发送已丢失的数据。在本发明的技术方案中,接收方会主动检测传输过程中是否发生丢包的情况,当接收方检测出有丢包后就主动向发送方发送状态报告,相对于现有技术,接收方就不会再等到发送方的POLL后再进行检测并向发送方发送状态报告,这样,就杜绝了POLL过程所带来的时延,提高了业务的质量,提高了用户的满意度。
Description
技术领域
本发明涉及无线通信领域,尤其涉及无线通信领域中的数据传输。
背景技术
在无线通信领域中,无线承载RB(Radio Bear)是用户设备UE(UserEquipment)与无线网络控制器RNC(Radio Network Controller)之间的业务(Traffic)承载和信令(Signal)承载,根据其承载的业务类型,习惯将其称为TRB(Traffic RB)和SRB(Signal RB)。SRB不同于TRB,SRB对时延的要求较高,换言之SRB上传输时延越低越好,而且一般情况下,为了保证信令的正确无误传输,SRB可以采用非确认模式UM(Unacknowledged Mode)或者确认模式AM(Acknowledged Mode),在当前的各种实现中,SRB主要还是使用AM模式。
无线链路控制RLC(Radio Link Controll)子层在收到协议栈高层来的服务数据单元高层SDU(Service Data Unit)后,会根据高层SDU本身的大小以及RLC子层支持的协议数据单元PDU(Protocol Data Unit)的大小决定对所述高层SDU进行级联或者分段操作,具体为:如果高层SDU较大并超过了一个RLC PDU所能容纳的最大值,则RLC子层将其分段放置于若干RLC PDU中;如果一个RLC PDU足以放置一个从高层传下的高层SDU,则无须分段,甚至如果多个高层SDU才可装满一个RLC PDU,则将这几个高层SDU级联并置入一个RLCPDU中。
在AM模式下,通过重传、滑窗机制等实现数据的可靠、正确传输。具体过程如下:发送方每发送若干数据后会向数据接收方发送一个轮询(POLL),轮询的目的是为了通知接收方反馈一个关于前段时间收到的数据的正误情况的说明;对于接收到的数据的反馈,接收方通过向发送方发送状态报告(STATUSREPORT)完成,发送方根据接收方发送的状态报告获悉哪些数据已经正确收到以及哪些数据接收方没有收到需要重传。在这个过程中,发送方的POLL过程的触发有多种方式,主要包括以下几种:
1):当发送方的发送缓冲中还剩下“最后一个PDU”时,发送方要触发POLL通知接收方反馈数据接收的情况,所述的“最后一个PDU”主要分为如下两种情况:
A、当前时刻发送缓冲中只剩下最后一个RLC PDU需要发送,则在此RLC PDU发送时,RLC会将该RLC PDU中的POLL比特位置为1,从而触发一个POLL过程;
B、当前的发送窗口马上已满,当前发送缓冲中的待发送RLC PDU是被当前发送窗口所允许发送的最后一个RLC PDU;
2):当发送方的重传缓冲中还剩下“最后一个PDU”时,发送方要触发POLL通知接收方反馈数据接收的情况,所述的“最后一个PDU”主要分为如下两种情况:
A、当前时刻重传缓冲中只剩下最后一个RLC PDU需要重传,则在此RLC PDU重传时,RLC会将该RLC PDU中的POLL比特位置为1,从而触发一个POLL过程;
B、当前的发送窗口马上已满,因为重传的RLC PDU同样也要占用发送窗口,并且重传RLC PDU的发送优先级要高于首次发送的RLC PDU的优先级别,当前重传缓冲中的待发送RLC PDU是被当前发送窗口所允许发送的最后一个RLC PDU;
3):预先设置POLL PDU的大小,当发送方每发送POLL PDU个RLC PDU后就触发POLL过程,例如将POLL PDU配置为16,则发送方每发送16个RLC PDU后就触发POLL过程;
4):预先设置POLL高层SDU的大小,当发送方每发送POLL高层SDU个高层SDU后就触发POLL流程,一般POLL高层SDU配置为1,则发送方每发送1个高层SDU后就触发POLL过程;
5):预先设置一个定时器,则可以通过所述定时器来周期行的触发POLL过程。
不难看出,POLL过程的触发需要一定的时间为基础,无论是等到发送缓冲中的RLC PDU已经发完并尚未收到ACK,还是等待定时器超时触发POLL过程,换言之,发送方POLL过程的触发本身需要一个时间过程。而且,由上述描述可以看出,在AM模式下要进行数据的完整传输需要发送方和接收方多次的确认,因此对数据传输的效率会由很大的影响。
从上面过程可以看到,在AM模式下传输过程中发生丢包后,如果发送方配置了POLL,则在触发条件满足的情况下,从发送方触发POLL过程到接收方发送状态报告,再到发送方重传,这个过程所延续的时间长度可能会对实时性要求极高的信令产生消极影响。相对于TRB来讲,SRB的实时性、准确性要求都要高的多:设想某用户在尝试建立呼叫业务时,某信令高层SDU需要分为4个PDU发送,即SN分别为x,x+1,x+2,x+3,若最后一个SN为x+3的PDU接收方没有收到,则接收方虽然已经接收到前三个PDU,但由于尚缺乏最后一个PDU而导致在对端实体中,PDU无法完成重组,也就无法向高层传送相应高层SDU,与此同时,为了重新获取那个丢掉的PDU,双方不得不进行一次重传合作。首先发送方触发POLL过程,为了这个POLL过程,发送方需要付出一定的时间代价,接收方收到POLL后才组织状态报告给发送方。这个重传的过程所带来的时延有时会严重影响业务的质量甚至造成业务不可用。
发明内容
本发明的实施例提出一种数据重传的方法,用于解决因为接收方触发POLL过程而导致的数据重传时延较大的问题,极大的减少在AM模式下数据重传所带来的时延,提高业务的质量。该方法具体如下所述:
若接收方检测到当前已接收的最大序列号RLC PDU不是当前正在接收的SDU的最后一个RLC PDU时,启动预先设定的定时器;在所述定时器超时前,若接收方接收到了下一个RLC PDU,则返回步骤A;否则,在所述定时器超时前若接收方没有接收到下一个RLC PDU,则接收方判断在传输过程中出现丢包,向发送方发送状态报告;发送方收到所述状态报告后,根据状态报告重新发送已丢失的数据。
通过以上所描述的方案,可以知道在本发明实施例的技术方案中,接收方会主动检测传输过程中是否发生丢包的情况,当接收方检测出有丢包后就主动向发送方发送状态报告,相对于现有技术,接收方就不会再等到发送方的POLL后再进行检测并向发送方发送状态报告,这样,就杜绝了POLL过程所带来的时延,提高了业务的质量,提高了用户的满意度。
附图说明
图1协议定义的流量控制滑动窗口机制示意图;
图2为依照本发明原理的一个具体实施方式的流程图。
具体实施方式
当接收方检测到已接收的数据中有丢包的情况时,主动向发送方发送状态报告,而不用等到发送方触发POLL过程,这样便减短了原来由于发送方的POLL过程所带来的额外延时,保证了整个数据传输过程中尤其是信令传输过程中不会有太大的延时,保证了业务的QoS,提高了用户满意度。
在对本发明实施例进行详细说明之前,首先介绍一下流量控制的滑动窗口机制,具体如附图1所示:
在图1中,VT(A)、VT(S)、VT(MS)、VR(R)、VR(H)和VR(MR)为协议定义的状态变量。
在发送方的发送窗口中,VT(A)至VT(MS)之间的长度为发送窗口的大小,单位RLC PDU的数量;VT(A)之前为已经按照顺序被发送方确认正确接收的RLC PDU;VT(A)至VT(S)之间为已经至少发送过一次、但还没有收到接收方正确接收状态报告的RLC PDU;VT(S)至VT(MS)之间为允许发送的RLC PDU。如果发送方有新的RLC PDU需要发送时,VT(S)向后移动;如果发送方通过接收方的状态报告确定序列号为VT(A)的RLC PDU已被正确接收时,VT(A)向后移动,VT(MS)也相应地向后移动。
在接收方的接收窗口中,VR(R)至VR(MR)之间的长度为接收窗口的大小,单位为RLC PDU的数量;VR(R)之前为已经正确接收的RLC PDU;VR(R)至VR(MR)之间为允许接收的RLC PDU。如果接收方接收到序列号为VR(H)至VR(MR)之间的RLC PDU时,VR(H)向后移动;如果接收方接收到序列号为VR(R)的RLC PDU时,VR(R)向后移动,VR(MR)也相应地向后移动。接收方接收窗口的VR(R)、VR(H)和VR(MR)为协议定义的状态变量,其中,VR(R)为接收方当前期望接收的RLC PDU的序列号,VR(R)之前为已经正确接收的RLC PDU。
发送方RLC子层在收到高层传送来的高层SDU后,会根据高层SDU本身大小以及RLC子层支持的RLC PDU大小对所述高层SDU进行级联或者分段操作,在RLC PDU的格式中,协议规定了一个长度指示字段LI(Length Indicator),该字段只能出现在一个高层SDU在RLC PDU内部的结束部分。具体来讲分这样两种情况:
(1)、如果是对高层SDU进行分段操作,假设该高层SDU被分段为n个RLCPDU,则序列号为0至n-2号的属于该高层SDU的RLC PDU中没有LI字段,只有在最后一个属于该高层SDU的RLC PDU即序列号为n-1的RLC PDU中会有LI字段;
(2)、如果对高层SDU进行级联操作,即若某个RLC PDU中包括了一个或多个高层SDU,则在该RLC PDU中每个高层SDU的末尾都会有一个LI字段。
基于以上所述,本发明实施例提出了一种检测丢包的方案并在此基础上进行数据重传的方法,该方法具体如下:
接收方对已接收到的数据进行检测的时候,接收方对已接收到的序列号最大的RLC PDU进行检测,在实际应用中,由于接收方更新VR(H)的时间不同,所以,接收方当前接收的最大序列号RLC PDU可以为VR(H),也可以为VR(H)-1,如当接收方对每个接收到的RLC PDU处理完成后再更新VR(H)时,接收方当前接收的最大序列号RLC PDU为VR(H),当接收方在对每个接收到的RLCPDU处理前更新VR(H)时,则接收方当前接收的最大序列号RLC PDU为VR(H)-1。
判断该最大序列号的RLC PDU是否是当前正在接收的SDU的最后一个RLCPDU,即查看所述的最大序列号的RLC PDU是否包含LI字段,若包含LI字段则是当前正在接收的SDU的最后一个RLC PDU,若不包含LI字段,则该最大序列号的RLC PDU不是当前正在接收的SDU的最后一个RLC PDU。
如果判断出所述当前已接收到的最大序列号的RLC PDU不是正在接收的SDU的最后一个RLC PDU并且在此后的特定的一段时间内接收方还没有接收到下一个RLC PDU,则判断本次传输过程中出现丢包情况;当接收方判断已出现丢包的时候,接收方主动封装一个状态报告(STATUS REPORT)并将其发给发送方,则发送方根据所述的状态报告向接收方重传已丢失的数据。
若在所述的特定的一段时间内接收方收到了下一个RLC PDU,则重复上述步骤,判断所述的下一个RLC PDU即新的最大序列号的RLC PDU是否是当前正在接收的SDU的最后一个RLC PDU;若是则结束流程。
这里,所述特定的一段时间是表示接收方所能接受的两个连续应当被接收的RLC PDU之间的最大时延,若接收方在收到的某一RLC PDU后在所述的特定的一段时间内还没有接收到下一个RLC PDU,则接收方就判定为传输过程中出现了丢包的情况。所述的该特定的一段时间可以预先设定。
由此可以看出,本发明实施例的方案中,接收方并不是等到发送方触发POLL过程后再发状态报告,而是当接收方判断已出现丢包情况后则主动向发送方发状态报告,发送方接收到所述状态报告后就重传已丢失的数据,这样就杜绝了POLL过程所带来的时延,提高了业务的质量,提高了用户的满意度。
这里,所述的接收方可以是RNC,发送方可以是UE;当然,接收方也可以是UE,发送方可以是RNC。
下面,以发送方为UE,接收方为RNC为例,详细说明本发明的实施方式,如图2所示,其步骤如下:
步骤S20、RNC判断当前接收到的最大序列号的RLC PDU是否是正在接收的SDU的最后一个RLC PDU。
在某此数据传输过程中,UE向RNC发送数据,RNC接收所述的来自UE的数据,RNC在接收过程中对所述的数据进行检测,在本实施例中,RNC判断当前接收到的数据中最大序列号的RLC PDU是否是正在接收的SDU的最后一个RLCPDU;如上所述,所述序列号最大的RLC PDU可以是序列号为VR(H)-1的RLCPDU,也可以是序列号为VR(H)的RLC PDU;RNC查看所述序列号最大的RLC PDU是否包含LI字段,若包含LI字段则它是当前正在接收的SDU的最后一个RLCPDU,若不包含,则该RLC PDU不是当前正在接收的SDU的最后一个RLC PDU。
步骤S21、若RNC判断当前接收到的最大序列号的RLC PDU不是正在接收的SDU的最后一个RLC PDU,则启动预先设定的定时器。
在本实施例中,将该定时器命名为Timer_Segment_Interval_Margin,该定时器的周期可以由高层(RRC)根据实际传输情况进行配置,即RRC在不同的传输场景下进行配置,以期达到最高的传输效率,用户的时延感受最不明显;这里配置所述定时器的周期可以通过在高层同RLC子层间的消息如传输配置消息或是重传配置消息中加入新IE来实现,即高层将所述定时器的周期信息封装到传输配置消息或是重传配置消息中并将所述的传输配置消息或是重传配置消息下发到RLC子层,RLC子层根据所述传输配置消息或是重传配置消息中的定时器周期信息来配置所述定时器的周期。当然,也可以是新设定一个定时器设置消息,则高层并在配置好定时器周期后可以通过所述定时器设置消息将所述定时器周期信息发给RLC子层。
步骤S22、在所述定时器的定时周期内,若RNC接收到了下一个RLC PDU,则返回步骤S20;若在所述定时器超时的时候接收方还没有接收到下一个RLCPDU,则执行步骤S23。
若在所述定时器的定时周期内,RNC接收到了下一个RLC PDU,则转回步骤S20,重复上述过程,RNC判断所述接收到的下一个RLC PDU即新的最大序列号RLC PDU是否为当前正在接收的SDU的最后一个RLC PDU,若是则关闭所述定时器,结束流程;否则进入步骤S21,重新启动所述定时器。
若在所述定时器超时的时候RNC还没有接收到下一个RLC PDU,则接收方判断当前已经出现了丢包的情况,进入步骤S23;若在定时器周期内接收到了下一个RLC PDU,则返回步骤S20,如此重复。
步骤S23、RNC向UE发送状态报告。
当RNC判断当前已经出现了丢包的情况后,主动封装一个状态报告并将其发给UE。
步骤S24、UE重传已丢失数据。
UE在收到RNC发送过来的状态报告后,根据所述的状态报告获知已丢失的数据并重新向RNC发送已丢失的数据。
本发明实施例中所描述的发送方和接收方传输的数据既可以是业务数据也可以是信令,在实际应用中,尤其是对于发送方和接收方之间传递的信令来讲,本发明实施例提出的重传方案杜绝了POLL过程所带来的时延,保证信令传输的时延最小,保证业务QoS,提高了业务的质量,提高了用户的满意度。
以上所述的具体实施例,对本发明的目的、技术方案和有益效果进行了进一步的详细说明,所应理解的是,以上所述仅为本发明的具体实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (7)
1、一种数据重传的方法,其特征在于,包括:
A、若接收方检测到当前已接收的最大序列号RLC PDU不是当前正在接收的SDU的最后一个RLC PDU时,启动预先设定的定时器;
B、在所述定时器超时前,若接收方接收到了下一个RLC PDU,则返回步骤A;否则,在所述定时器超时前若接收方没有接收到下一个RLC PDU,则接收方判断在传输过程中出现丢包,向发送方发送状态报告;
C、发送方收到所述状态报告后,根据状态报告重新发送已丢失的数据。
2、如权利要求1所述的方法,其特征在于,所述的最大序列号RLC PDU为序列号为VR(H)的RLC PDU。
3、如权利要求1所述的方法,其特征在于,所述的最大序列号RLC PDU为序列号为VR(H)-1的RLC PDU。
4、如权利要求1所述的方法,其特征在于,所述接收方检测到当前已接收的最大序列号RLC PDU不是当前正在接收的SDU的最后一个RLC PDU具体为:
接收方检测所述的当前已接收的最大序列号RLC PDU是否包括长度指示LI字段,若包括则判断当前已接收的最大序列号RLC PDU是当前正在接收的SDU的最后一个RLC PDU;否则,判断当前已接收的最大序列号RLC PDU不是当前正在接收的SDU的最后一个RLC PDU。
5、如权利要求1所述的方法,其特征在于,所述预先设定定时器具体为:接收方高层配置好所述定时器周期信息后,将配置好的定时器周期信息承载在传输配置消息或重传配置消息中传给接收方RLC子层。
6、如权利要求1所述的方法,其特征在于,所述预先设定定时器具体为:
接收方高层配置好所述定时器周期信息后,将配置好的定时器周期信息承载在新设定的消息中传给接收方RLC子层。
7、如权利要求1至6中任一所述的方法,其特征在于,所述接收方为RNC、发送方为UE;或
所述接收方为UE、发送方为RNC。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200710073312 CN101030839A (zh) | 2007-02-13 | 2007-02-13 | 一种数据重传的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200710073312 CN101030839A (zh) | 2007-02-13 | 2007-02-13 | 一种数据重传的方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101030839A true CN101030839A (zh) | 2007-09-05 |
Family
ID=38715944
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 200710073312 Pending CN101030839A (zh) | 2007-02-13 | 2007-02-13 | 一种数据重传的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101030839A (zh) |
Cited By (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101800632A (zh) * | 2009-02-09 | 2010-08-11 | 中兴通讯股份有限公司 | 用户数据报协议传输模式下丢包补偿方法与装置 |
| CN101841856A (zh) * | 2010-04-12 | 2010-09-22 | 展讯通信(上海)有限公司 | 协议数据单元接收情况的状态报告发送方法及接收端 |
| CN101222311B (zh) * | 2008-01-29 | 2010-12-08 | 杭州华三通信技术有限公司 | 实时报文丢包恢复方法、系统及接收端单元 |
| CN101132376B (zh) * | 2007-09-28 | 2011-06-15 | 杭州华三通信技术有限公司 | 控制iSCSI报文发送、接收的方法和装置及相应系统 |
| WO2012000312A1 (zh) * | 2010-07-01 | 2012-01-05 | 中兴通讯股份有限公司 | 一种构造状态报告的方法与装置 |
| CN102595251A (zh) * | 2011-01-11 | 2012-07-18 | 中兴通讯股份有限公司 | 流媒体丢包重传实现方法和系统 |
| CN101714915B (zh) * | 2009-11-02 | 2013-03-27 | 清华大学 | 一种数据重传方法及系统 |
| CN103001885A (zh) * | 2012-12-25 | 2013-03-27 | 中国科学院深圳先进技术研究院 | 数据报文传输方法和系统 |
| CN103858372A (zh) * | 2011-10-07 | 2014-06-11 | 华为技术有限公司 | 用于通信系统中多点传输的系统和方法 |
| CN103957169A (zh) * | 2014-05-14 | 2014-07-30 | 上海复兰信息科技有限公司 | 一种基于反向请求的可靠udp的实现方法 |
| CN104580171A (zh) * | 2014-12-24 | 2015-04-29 | 北京高森明晨信息科技有限公司 | Tcp协议的传输方法、装置和系统 |
| WO2015143693A1 (en) * | 2014-03-28 | 2015-10-01 | Qualcomm Incorporated | Methods and apparatus for validating reconfiguration messages based on sdu lifetime |
| WO2015180066A1 (zh) * | 2014-05-28 | 2015-12-03 | 华为技术有限公司 | 一种无线链路控制传输方法及设备 |
| US9838089B2 (en) | 2011-10-07 | 2017-12-05 | Futurewei Technologies, Inc. | System and method for multiple point transmission in a communications system |
| CN107925665A (zh) * | 2015-08-31 | 2018-04-17 | 高通股份有限公司 | 避免不必要的协议数据单元(pdu)传输 |
| WO2018209682A1 (zh) * | 2017-05-19 | 2018-11-22 | Oppo广东移动通信有限公司 | 无线链路控制层的数据接收处理的方法和设备 |
| CN108881359A (zh) * | 2017-10-31 | 2018-11-23 | 北京视联动力国际信息技术有限公司 | 一种基于视联网的文件下载方法和装置 |
| CN108881140A (zh) * | 2017-10-31 | 2018-11-23 | 北京视联动力国际信息技术有限公司 | 一种基于视联网的文件下载方法及装置 |
| CN109391376A (zh) * | 2017-08-09 | 2019-02-26 | 华为技术有限公司 | 状态报告的发送方法、设备及系统 |
| WO2019085763A1 (zh) * | 2017-10-31 | 2019-05-09 | 夏普株式会社 | 无线通信方法和设备 |
| WO2019192425A1 (zh) * | 2018-04-03 | 2019-10-10 | 夏普株式会社 | 确认模式rlc实体及其发送/重传方法、通信设备 |
| CN111543079A (zh) * | 2018-01-08 | 2020-08-14 | 中兴通讯股份有限公司 | 无线链路控制(rlc)确认模式(am)数据接收 |
| WO2020191784A1 (zh) * | 2019-03-28 | 2020-10-01 | 华为技术有限公司 | 一种重传信息的传输方法及装置 |
| CN112969075A (zh) * | 2021-01-29 | 2021-06-15 | 北京字节跳动网络技术有限公司 | 直播过程中的补帧方法、装置及计算设备 |
| CN114424671A (zh) * | 2019-09-26 | 2022-04-29 | 华为技术有限公司 | 聚合多个无线通信信道实现灵活全双工通信的方法和装置 |
-
2007
- 2007-02-13 CN CN 200710073312 patent/CN101030839A/zh active Pending
Cited By (42)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101132376B (zh) * | 2007-09-28 | 2011-06-15 | 杭州华三通信技术有限公司 | 控制iSCSI报文发送、接收的方法和装置及相应系统 |
| CN101222311B (zh) * | 2008-01-29 | 2010-12-08 | 杭州华三通信技术有限公司 | 实时报文丢包恢复方法、系统及接收端单元 |
| CN101800632A (zh) * | 2009-02-09 | 2010-08-11 | 中兴通讯股份有限公司 | 用户数据报协议传输模式下丢包补偿方法与装置 |
| CN101714915B (zh) * | 2009-11-02 | 2013-03-27 | 清华大学 | 一种数据重传方法及系统 |
| CN101841856A (zh) * | 2010-04-12 | 2010-09-22 | 展讯通信(上海)有限公司 | 协议数据单元接收情况的状态报告发送方法及接收端 |
| WO2012000312A1 (zh) * | 2010-07-01 | 2012-01-05 | 中兴通讯股份有限公司 | 一种构造状态报告的方法与装置 |
| CN102595251B (zh) * | 2011-01-11 | 2016-07-27 | 中兴通讯股份有限公司 | 流媒体丢包重传实现方法和系统 |
| CN102595251A (zh) * | 2011-01-11 | 2012-07-18 | 中兴通讯股份有限公司 | 流媒体丢包重传实现方法和系统 |
| US9871736B2 (en) | 2011-10-07 | 2018-01-16 | Futurewei Technologies, Inc. | System and method for information delivery with multiple point transmission |
| US10257103B2 (en) | 2011-10-07 | 2019-04-09 | Futurewei Technologies, Inc. | System and method for information delivery with multiple point transmission |
| US11070482B2 (en) | 2011-10-07 | 2021-07-20 | Futurewei Technologies, Inc. | System and method for information delivery with multiple point transmission |
| US10116357B2 (en) | 2011-10-07 | 2018-10-30 | Futurewei Technologies, Inc. | System and method for multiple point transmission in a communications system |
| CN103858372A (zh) * | 2011-10-07 | 2014-06-11 | 华为技术有限公司 | 用于通信系统中多点传输的系统和方法 |
| US10090890B2 (en) | 2011-10-07 | 2018-10-02 | Futurewei Technologies, Inc. | System and method for multiple point transmission in a communications system |
| US9838089B2 (en) | 2011-10-07 | 2017-12-05 | Futurewei Technologies, Inc. | System and method for multiple point transmission in a communications system |
| CN103858372B (zh) * | 2011-10-07 | 2019-08-20 | 华为技术有限公司 | 用于通信系统中多点传输的系统和方法 |
| US10218414B2 (en) | 2011-10-07 | 2019-02-26 | Futurewei Technologies, Inc. | System and method for multiple point transmission in a communications system |
| US9882821B2 (en) | 2011-10-07 | 2018-01-30 | Futurewei Technologies, Inc. | System and method for information delivery with multiple point transmission |
| CN103001885A (zh) * | 2012-12-25 | 2013-03-27 | 中国科学院深圳先进技术研究院 | 数据报文传输方法和系统 |
| CN103001885B (zh) * | 2012-12-25 | 2015-08-26 | 中国科学院深圳先进技术研究院 | 数据报文传输方法和系统 |
| WO2015143693A1 (en) * | 2014-03-28 | 2015-10-01 | Qualcomm Incorporated | Methods and apparatus for validating reconfiguration messages based on sdu lifetime |
| CN106471764A (zh) * | 2014-03-28 | 2017-03-01 | 高通股份有限公司 | 用于基于sdu寿命来验证重配置消息的方法和装置 |
| CN103957169A (zh) * | 2014-05-14 | 2014-07-30 | 上海复兰信息科技有限公司 | 一种基于反向请求的可靠udp的实现方法 |
| WO2015180066A1 (zh) * | 2014-05-28 | 2015-12-03 | 华为技术有限公司 | 一种无线链路控制传输方法及设备 |
| CN104580171B (zh) * | 2014-12-24 | 2018-01-12 | 北京高森明晨信息科技有限公司 | Tcp协议的传输方法、装置和系统 |
| CN104580171A (zh) * | 2014-12-24 | 2015-04-29 | 北京高森明晨信息科技有限公司 | Tcp协议的传输方法、装置和系统 |
| CN107925665A (zh) * | 2015-08-31 | 2018-04-17 | 高通股份有限公司 | 避免不必要的协议数据单元(pdu)传输 |
| CN107925665B (zh) * | 2015-08-31 | 2019-05-14 | 高通股份有限公司 | 避免不必要的协议数据单元(pdu)传输 |
| US10873990B2 (en) | 2017-05-19 | 2020-12-22 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Method and device for receiving and processing data of radio link control layer |
| WO2018209682A1 (zh) * | 2017-05-19 | 2018-11-22 | Oppo广东移动通信有限公司 | 无线链路控制层的数据接收处理的方法和设备 |
| CN109391376B (zh) * | 2017-08-09 | 2020-12-01 | 华为技术有限公司 | 状态报告的发送方法、设备及系统 |
| CN109391376A (zh) * | 2017-08-09 | 2019-02-26 | 华为技术有限公司 | 状态报告的发送方法、设备及系统 |
| CN108881359A (zh) * | 2017-10-31 | 2018-11-23 | 北京视联动力国际信息技术有限公司 | 一种基于视联网的文件下载方法和装置 |
| WO2019085763A1 (zh) * | 2017-10-31 | 2019-05-09 | 夏普株式会社 | 无线通信方法和设备 |
| CN108881140A (zh) * | 2017-10-31 | 2018-11-23 | 北京视联动力国际信息技术有限公司 | 一种基于视联网的文件下载方法及装置 |
| US11637785B2 (en) | 2017-10-31 | 2023-04-25 | Sharp Kabushiki Kaisha | Wireless communication method and device |
| CN111543079A (zh) * | 2018-01-08 | 2020-08-14 | 中兴通讯股份有限公司 | 无线链路控制(rlc)确认模式(am)数据接收 |
| CN111543079B (zh) * | 2018-01-08 | 2022-04-15 | 中兴通讯股份有限公司 | 无线链路控制(rlc)确认模式(am)数据接收 |
| WO2019192425A1 (zh) * | 2018-04-03 | 2019-10-10 | 夏普株式会社 | 确认模式rlc实体及其发送/重传方法、通信设备 |
| WO2020191784A1 (zh) * | 2019-03-28 | 2020-10-01 | 华为技术有限公司 | 一种重传信息的传输方法及装置 |
| CN114424671A (zh) * | 2019-09-26 | 2022-04-29 | 华为技术有限公司 | 聚合多个无线通信信道实现灵活全双工通信的方法和装置 |
| CN112969075A (zh) * | 2021-01-29 | 2021-06-15 | 北京字节跳动网络技术有限公司 | 直播过程中的补帧方法、装置及计算设备 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101030839A (zh) | 一种数据重传的方法 | |
| CN100550671C (zh) | 在无线接入网络中移动接收窗口的方法 | |
| CN101779408B (zh) | 在移动通信系统中发送状态信息的方法及移动通信的接收机 | |
| JP5437216B2 (ja) | 無線通信におけるリンク制御のための方法および装置 | |
| EP2238707B1 (en) | Method of detecting and handling an endless rlc retransmission | |
| CN101361309B (zh) | 数据发送方法和数据重发方法 | |
| US8437306B2 (en) | Layer 2 tunneling of data during handover in a wireless communication system | |
| CN101589565B (zh) | 移动通信系统中无线链路控制层的数据发送的方法和装置 | |
| CN101478380B (zh) | 一种自动重传请求窗口管理方法 | |
| EP2255478B1 (en) | A method and a transceiver for reducing retransmissions in a telecommunications system | |
| CN1335003A (zh) | 自动重复请求协议 | |
| CN104836646A (zh) | 一种rlc am模式传输可靠性增强方法 | |
| KR101024461B1 (ko) | 전송 윈도우를 사용하는 통신 시스템에서의 최적화된 패킷 데이터 전송 프로토콜 | |
| CN101483507A (zh) | 基于lte系统的自动请求重传状态报告抑制方法 | |
| CN101924621A (zh) | 无线链路数据传输方法及无线通信网络节点 | |
| CN101453311B (zh) | 一种自动重传请求状态报告的触发方法 | |
| CN101064587A (zh) | 确认模式下无线链路控制协议的控制数据单元的重传方法 | |
| CN1852084A (zh) | 一种数据包丢失的检测方法和检测装置 | |
| CN101997641B (zh) | 一种提高分组传输速率的方法及系统 | |
| KR20080012136A (ko) | 이동통신 시스템에서 패킷 송수신 방법 및 장치 | |
| HK1107735A (zh) | 用於無線通信中的鏈路控制的方法和設備 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20070905 |