CN107734547A - 状态报告生成和系统，及状态报告接收方法 - Google Patents
状态报告生成和系统，及状态报告接收方法 Download PDFInfo
- Publication number
- CN107734547A CN107734547A CN201610665206.5A CN201610665206A CN107734547A CN 107734547 A CN107734547 A CN 107734547A CN 201610665206 A CN201610665206 A CN 201610665206A CN 107734547 A CN107734547 A CN 107734547A
- Authority
- CN
- China
- Prior art keywords
- bitmap
- packet
- state report
- information
- loss
- 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
Classifications
-
- 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/18—Automatic repetition systems, e.g. Van Duuren systems
-
- 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/0278—Traffic management, e.g. flow control or congestion control using buffer status reports
-
- 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/10—Flow control between communication endpoints
- H04W28/14—Flow control between communication endpoints using intermediate storage
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
本发明提供了一种状态报告生成和系统，及状态报告接收方法，其中该状态报告生成方法包括：接收端设备生成状态报告，其中，该状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；该接收端设备向发送端设备发送该状态报告。采用上述技术方案，解决了相关技术中在数据存在传输错误时，接收端设备发送的状态报告占用空间大的问题，大幅减少了状态报告的传输占用空间。
Description
技术领域
本发明涉及通信领域，具体而言，涉及一种状态报告生成和系统，及状态报告接收方法。
背景技术
在相关技术中，用户面状态报告机制应用于针对某些需要接收端进行接收确认的无线承载的情况，接收端对数据的接收状态进行反馈，通过接收端的反馈，来通知发送端的用户面相关实体在重建完成时接收端已接收到的数据包信息，以减少发送端用户面相关实体重建完成后不必要的重复数据包传输。
在相关技术中的4G通信网络中，用户面实体如分组数据汇聚协议(Packet DataConvergence Protocol，简称为PDCP)的反馈状态报告采用位图文件bitmap的形式，在未来5G通信网络，随着业务量及数据传输速率的增加，数据包的序列号SN长度也随之增加，比如SN长度采用18比特或更长，用户面实体的收发窗口将相应扩大，从而用户面实体如PDCP状态报告中的bitmap域的比特长度也会相应增加，特别是在承载分离bear split的场景下，在某个分支数据传输链路不稳定的时候，可能会出现某段连续的SN号出问题，并且SN号间跨度很大的情况，按照目前PDCP状态报告的格式生成PDCP状态报告时，需要用足够大的bitmap域才能表示某个时间片段的PDCP PDU传输状态，甚至导致状态PDU的大小超过PDCP控制PDU的上限。
比如，在高频、低频bear split的时候或者高频、WLAN bear split的时候，如果速率慢的那个分支PDCP数据包丢了，按照现在bitmap的定义，状态协议数据单元(ProtocolData Unit，简称为PDU)的大小可能会超过PDCP PDU的上限。具体来说，如果在数据传输中丢了SN＝X的包和SN＝Y包，那么状态PDU需要携带的比特数是Y-X，考虑到SN可以是18比特，哪怕只丢了2个包，这个值可能会很大，会占用很大一块bitmap域，甚至会超过PDU大小的上限，使得状态PDU的生成及解析效率低，比特开销大。
针对相关技术中在数据存在传输错误时，接收端设备发送的状态报告占用空间大的问题，目前还没有有效的解决方案。
发明内容
本发明实施例提供了一种状态报告生成和系统，及状态报告接收方法，以至少解决相关技术中在数据存在传输错误时，接收端设备发送的状态报告占用空间大的问题。
根据本发明的一个实施例，提供了一种状态报告生成方法，包括：
接收端设备生成状态报告，其中，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
所述接收端设备向发送端设备发送所述状态报告。
可选地，接收端设备生成状态报告，包括：
确定所述数据包的位图文件bitmap信息所属的bitmap分段；
依据所述bitmap分段生成所述状态报告。
可选地，根据以下信息确定所述数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息。
可选地，所述起点位置信息用于指示每个分段第一个丢失的数据包序列号SN。
可选地，所述长度信息用于指示分段的bitmap域的比特长度，其中，所述bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
可选地，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息，包括：
在接收端设备未将所述丢失的数据包进行分段的情况下，所述状态报告中携带有每一个丢失的数据包的序列号。
根据本发明的另一个实施例，提供了一种状态报告接收方法，其特征在于，包括：
发送端设备接收接收端设备发送的状态报告，其中，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
所述发送端设备依据所述指示信息向所述接收端设备发送所述丢失的数据包。
可选地，发送端设备接收接收端设备发送的状态报告之前，所述接收端设备通过以下方式生成所述状态报告：
确定所述数据包的位图文件bitmap信息所属的bitmap分段；
依据所述bitmap分段生成所述状态报告。
可选地，所述接收端设备根据以下信息确定所述数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息，其中，所述起点位置信息用于指示每个分段第一个丢失的数据包序列号SN，所述长度信息用于指示分段的bitmap域的比特长度，其中，所述bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
根据本发明的另一个实施例，还提供了一种状态报告生成系统，其特征在于，包括：接收端设备，发送端设备，其中，所述接收端设备包括第一处理器和第一通信模块，所述发送端设备包括第二处理器和第二通信模块；
所述第一处理器生成状态报告，其中，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
所述第一通信模块向所述第二通信模块发送所述状态报告；
所述第二处理器依据所述指示信息通过所述第二通信模块向所述第一通信模块发送所述丢失的数据包。
可选地，所述第一处理器生成状态报告，包括：
确定所述数据包的位图文件bitmap信息所属的bitmap分段；
依据所述bitmap分段生成所述状态报告。
可选地，所述第一处理器根据以下信息确定所述数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息，其中，所述起点位置信息用于指示每个分段第一个丢失的数据包序列号SN，所述长度信息用于指示分段的bitmap域的比特长度，其中，所述bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
根据本发明的另一个实施例，还提供了一种接收端设备，其特征在于，包括：第一处理器和第一通信模块；
所述第一处理器生成状态报告，其中，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
所述第一通信模块向发送端设备发送所述状态报告。
可选地，所述第一处理器生成状态报告，包括：
确定所述数据包的位图文件bitmap信息所属的bitmap分段；
依据所述bitmap分段生成所述状态报告。
可选地，所述第一处理器根据以下信息确定所述数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息，其中，所述起点位置信息用于指示每个分段第一个丢失的数据包序列号SN，所述长度信息用于指示分段的bitmap域的比特长度，其中，所述bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
可选地，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息，包括：
在所述接收端设备未将所述丢失的数据包进行分段的情况下，所述状态报告中携带有每一个丢失的数据包的序列号。
根据本发明的另一个实施例，还提供了一种发送端设备，其特征在于，包括：第二处理器和第二通信模块；
所述第二通信模块接收接收端设备发送的状态报告，其中，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
所述第二处理器依据所述指示信息向所述接收端设备发送所述丢失的数据包。
可选地，所述第二通信模块接收接收端设备发送的状态报告之前，所述接收端设备通过以下方式生成所述状态报告：
确定所述数据包的位图文件bitmap信息所属的bitmap分段；
依据所述bitmap分段生成所述状态报告。
可选地，所述接收端设备根据以下信息确定所述数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息，其中，所述起点位置信息用于指示每个分段第一个丢失的数据包序列号SN，所述长度信息用于指示分段的bitmap域的比特长度，其中，所述bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
根据本发明的又一个实施例，还提供了一种存储介质。该存储介质设置为存储用于执行以下步骤的程序代码：
接收端设备生成状态报告，其中，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
所述接收端设备向发送端设备发送所述状态报告。
可选地，存储介质还设置为存储用于执行以下步骤的程序代码：
发送端设备接收接收端设备发送的状态报告，其中，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
所述发送端设备依据所述指示信息向所述接收端设备发送所述丢失的数据包
通过本发明，发送端设备在向接收端设备发送数据之后，接收端设备在检测到数据包中存在传输错误的情况下，接收端设备生成携带有用于指示丢失的数据包的指示信息的状态报告，即该指示信息尽可能只携带有指示丢失的数据包的信息，不夹杂有传输正确的数据包，占用较小的传输空间，将该状态报告传输到发送端设备，发送端设备可以将传输错误的数据包重新发送。解决了相关技术中在数据存在传输错误时，接收端设备发送的状态报告占用空间大的问题，大幅减少了状态报告的传输占用空间。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据本发明实施例的一种状态报告生成方法流程图；
图2是根据本发明实施例提供的bear split承载分离架构示意图；
图3是根据相关技术中的PDCP(序列号15bit)状态报告格式示意图；
图4是根据具体实施例1的基于分段bitmap的PDCP(序列号15bit)状态报告格式示意图；
图5是根据具体实施例2的不使用bitmap的PDCP(序列号15bit)状态报告格式示意图；
图6是根据本发明实施例的一种接收端设备的硬件结构框图；
图7是根据本发明实施例的一种发送端设备的硬件结构框图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
实施例1
本申请文件中记载的实施例可以运行于5G系统中，接收端设备可以是终端或者网路侧设备，发送端设备对应的可以是网络侧设备或者终端设备，即终端在接收到网络侧设备下发的数据包之后可以生成本申请文件中记载的状态报告，或者，网络侧设备也可以在接收到终端上传的数据包之后生成状态报告。本申请文件中记载的实施例存在上述两种场景。
图1是根据本发明实施例的一种状态报告生成方法流程图，如图1所示，该流程包括以下步骤：
S102，接收端设备生成状态报告，其中，该状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
S104，该接收端设备向发送端设备发送该状态报告。
通过上述步骤，发送端设备在向接收端设备发送数据之后，接收端设备在检测到数据包中存在传输错误的情况下，接收端设备生成携带有用于指示丢失的数据包的指示信息的状态报告，即该指示信息尽可能只携带有指示丢失的数据包的信息，不夹杂有传输正确的数据包，占用较小的传输空间，将该状态报告传输到发送端设备，发送端设备可以将传输错误的数据包重新发送。解决了相关技术中在数据存在传输错误时，接收端设备发送的状态报告占用空间大的问题，大幅减少了状态报告的传输占用空间。
可选地，接收端设备生成状态报告，包括：确定该数据包的位图文件bitmap信息所属的bitmap分段；依据该bitmap分段生成该状态报告。
可选地，根据以下信息确定该数据包的位图bitmap信息所属的bitmap分段：每个分段的起点位置信息，每个分段的长度信息。
可选地，该起点位置信息用于指示每个分段第一个丢失的数据包序列号SN。
可选地，该长度信息用于指示分段的bitmap域的比特长度，其中，该bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
可选地，在接收端设备未将该丢失的数据包进行分段的情况下，该状态报告中携带有每一个丢失的数据包的序列号。
根据本发明的另一个实施例，提供了一种状态报告接收方法，该方法是发送端一侧撰写的实施例，步骤如下：
发送端设备接收接收端设备发送的状态报告，其中，该状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
该发送端设备依据该指示信息向该接收端设备发送该丢失的数据包。
可选地，发送端设备接收接收端设备发送的状态报告之前，该接收端设备通过以下方式生成该状态报告：
确定该数据包的位图文件bitmap信息所属的bitmap分段；
依据该bitmap分段生成该状态报告。
可选地，该接收端设备根据以下信息确定该数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息，其中，该起点位置信息用于指示每个分段第一个丢失的数据包序列号SN，该长度信息用于指示分段的bitmap域的比特长度，其中，该bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
以下结合本发明的优选实施例进行详细说明：
与相关技术相比，在未来无线通信网络中，随着业务量以及数据传输速率的增加，数据包的序列号SN及用户面实体的收发窗大小随之扩大，用户面非正确接收指示数据包格式中的bitmap的长度会很长，特别是在承载分离bear split的场景下，在某个分支出现问题的时候，可能会是某段连续的SN号出现问题，并且SN号间跨度很大的情况，需要用足够大的bitmap域来指示用户面数据的非正常接收，因此，比特开销大，反馈数据包的生成和解析效率也低。基于此问题，在未来5G无线通信用户面协议设计中，本申请文件通过采用分段bitmap的方式来解决反馈比特开销大的问题。
在用户面数据接收状态反馈格式中采用分段bitmap方式的主要思想是反馈端不需要在生成的状态报告中携带所有乱序数据包的bitmap信息。分段bitmap方式的具体特征包括在反馈的状态报告中增加一个和/或多个丢失的数据包的起点位置信息、长度信息及bitmap信息，生成新的用户面状态报告，用来指示一个和/或多个丢失的数据包。
本发明优选实施例的详细流程包括以下内容：
在介绍优选实施例之前，需要说明的是，终端和网路用户面实体都可以作为上述实施例中的接收端设备，即在二者之间进行数据传输的情况下，都可以生成状态报告，另一方可以相应的接收状态报告。
高层(如RRC)配置终端和/或网络用户面实体发送状态报告，终端和/或网络用户面实体在生成状态报告时采用分段的bitmap方式。
在本申请文件中描述的该分段bitmap方式包括以下两种方式：
方式1，在该状态报告格式中增加新的字段，该新增字段包括一个和/或多个丢失的数据包的起点位置信息、长度信息及bitmap信息，具体的说，方式1是分段传输的方式，增加新的字段即包含该分段的第一丢失的数据包的序列号，以及该分段包含有N个数据包，即长度信息，从第一个丢失的数据包之后开始数，N个之内(包括第N个)的数据包都是该分段的内容。
方式2，在该状态报告格式中增加新的字段，该新增字段包括下一个丢失的数据包序列号，无长度信息及bitmap信息。方式2是一种分段传输的极限思维，即每个丢失的数据包都是一个分段，当然在丢失的数据包较多的情况，分段过多同样会占用额外的传输空间，要在分段数目和每个分段尽可能多的包含丢失的数据包之间，寻找一个最优的处理方法。
该丢失的数据包的起点位置信息用于指示某个和/或某分段第一个丢失的数据包的序列号。其占用的比特数与数据包SN的长度相关。
该长度信息用于指示bitmap域的比特长度，其占用的比特数与数据包SN的长度相关。
该bitmap域的比特长度可变，其长度等于从每个分段的第一个丢失的PDCP SDU的下一个PDCP SDU开始到每个分段的最后一个乱序的PDCP SDU为止，bitmap域的长度向上取整到8的整数倍。
该状态报告用于表征用户面数据包的接收状态，发往对端，指示数据包是否需要对端重传。
需要补充的是，该用户面实体根据协议过程处理接收到的数据包，按对端可以理解的格式进行数据包的封装。
以下结合具体实施方式进行说明。
图2是根据本发明实施例提供的bear split承载分离架构示意图，如图2所示，其中，所有的用户面数据都经由主基站MeNB路由、缓存，辅基站SeNB用户面数据来源于MeNB。下行：MeNB中的PDCP实体具有路由选择功能，选择是到哪个eNB的RLC实体；上行：PDCP实体对接收到的数据进行重排序。对照图2，可以更好的理解上文所提到的承载分离bear split的场景。
图3是根据相关技术中的PDCP(序列号15bit)状态报告格式示意图，图3是参考36323-c00协议编制而成。并给出了简单的例子来说明随着SN长度的增加，Bitmap域的比特长度会很长。在有少数几个PDCP SDU丢失，但SN号跨度很大的情况，比方说图3中该的两个丢失的数据包之间跨度有近10000个乱序的PDCP SDU，那么，需要用足够大的bitmap域才能反馈PDCP PDU传输的状态，这样会导致该PDCP状态报告的生成和解析效率很低。
如前文所述，由于PDCP的反馈状态PDU采用bitmap的形式，在未来5G无线网络中要求更高的数据传输速率、更短传输时延和更好的用户体验，驱动整个网络架构设计的革新，用户面协议架构也需要做相应的设计以适应未来业务多样性的需求，随着PDCP SN号的增加，PDCP收发窗口将扩大，bitmap域的比特长度会很长，PDCP状态报告的生成和解析效率将降低，特别是在bear split的场景下，bear split架构如图2所示，在某个分支数据传输链路不稳定的时候，可能会出现某段SN号出问题，并且SN号间跨度很大的情况，按照目前PDCP状态PDU的格式生成PDCP状态报告时，需要用足够大的bitmap域才能表示某个时间片段的PDCP PDU传输状态，甚至可能导致PDCP状态报告的大小超过PDCP控制PDU的上限，因此，需要对PDCP状态报告格式进行增强，引入分段bitmap方法，以适应SN号越来越长的情况，并减少bitmap域的比特开销，提高PDCP状态报告生成及解析效率低。
具体实施例1
具体实施例1对应上述优选实施例中的方式1。
图4是根据具体实施例1的基于分段bitmap的PDCP(序列号15bit)状态报告格式示意图。其中，图4是在假定PDCP序列号长度为15的基础上展开讨论的，因此，最大PDCP序列号Maximum_PDCP_SN为32767，即序列号SN的范围为0～32767，重排序窗口的长度为PDCP序列号长度15比特空间的一半，即16384。当接收的数据包为PDCP重建时RLC乱序递交的数据包，且由于乱序不满足向高层递交的条件时，将数据包存入缓存，暂不向高层递交，这种非正确接收数据包的状态报告的生成将以此为依据。
在图4的PDCP状态报告格式中，分段bitmap里面不包括接收端连续接收到的不需要对端重传的PDCP SDU的序列号对应的指示信息，具体实现方法是在PDCP状态报告里增加一个和/或多个丢失PDU的起始点位置信息、长度信息、bitmap信息以及扩展比特。由于bitmap信息里无需承载连续多个正确接收的PDCP SDU的对应的序列号指示信息，减少了bitmap开销，避免PDCP状态报告过大甚至超过PDCP状态PDU允许的最大字节数。上述bitmap分段方法适用于丢失的数据包SN号间跨度很大的场景。图4中各个字段的说明如下：
NMS域占用15比特长，为可选字段，定义下一个分段丢失的PDCP SDU的起点位置，是否使用该字段由是否对bitmap域分段决定。该NMS用于对所占比特长度很长，且有不需重传的连续区域存在的bitmap域进行分段，用于对bitmap比特映射的基准调整，使得下一个分段bitmap以该NMS为基准进行移位计算SDU的SN号。NMS的取值为下一个Bitmap指示的第一个PDCP SDU序列号减1，如图4所示，第一个分段bitmap以FMS为起点，假设FMS＝100，Bitmap域第一个比特对应的PDCP SDU的SN＝101至Bitmap域最后一个比特对应的PDCP SDU的SN＝200丢失，但PDCP SDU SN＝201～5000的数据包不需要对端重传，而后续的PDCP SDU需要重传，因此，下一个分段bitmap将跳过SN＝201～5000不需要重传的PDCP SDU，仅携带需要重传的PDCP SDU序列号指示信息，因此，这里的NMS相应取5001，NMS对应的Bitmap域第一个比特指示的PDCP SDU的SN＝5002,Bitmap域最后一个比特指示的PDCP SDU的SN＝5100。以此方式，对bitmap域进行若干分段，bitmap不携带无需对端重传的PDCP SDU序列号对应的指示信息，减少bitmap的比特开销。其中，乱序接收的PDCP SDU的序列号SN在分段bitmap域中对应的计算公式为：PDCP SDU序列号SN＝(FMS+bit position)％(Maximum_PDCP_SN+1)，或者，SN＝(NMS+bit position)％(Maximum_PDCP_SN+1)，公式中，bitposition表示bitmap中的第一个比特位到第N比特位，第一个比特位的bit position为1，第N个比特位的bit position为N。
如果遇到SN＝X，X+2，X+5，X+5000，X+5001,X+5002，X+5010的数据包需重传的情况，可以采用具体实施例1的分段bitmap方式，跳过SN＝X+5与SN＝X+5000之间的不需重传的数据包，用两个分段bitmap分别来承载X与X+5之间，以及X+5001,X+5002，X+5010之间的数据包信息。具体来说，设置FMS＝X，再用5个有效bitmap承载该区间的数据包状态，以及设置NMS＝X+5000，再用10个有效bitmap承载该区间的数据包状态。
可选的，设置bitmap域分段门限。终端和/或网络在进行PDCP状态报告生成过程中，计算bitmap域的长度，与bitmap域分段门限值进行比较，如果计算的bitmap域比特长度超过该的bitmap域分段门限时，按照图4的PDCP状态报告格式进行PDCP状态报告的生成分段bitmap。如果计算的bitmap域比特长度未超过该的bitmap域分段门限时，按照图3的PDCP状态报告格式进行PDCP状态报告的生成。其中，该分段门限可配置。
在图4显示的状态报告格式中，D/C占1比特，用“0”或“1”表示，“0”指示PDU是控制PDU，“1”指示PDU是数据PDU。PDU类型占3比特，如“000”表示PDU类型为PDCP状态报告。5个预留比特R，以便后续之用，设置为“0”，接收端解析时对其忽略。扩展比特E占用1比特，用于指示E的下一个域是否为L字段，E＝1，表示E的下一个域为L字段。长度指示L占15比特，为可选字段，由是否对bitmap域分段决定。该长度指示L用于指示紧随其后分段bitmap域的比特长度。FMS域占15比特，用于指示第一个没有收到的PDCP SDU的PDCP序列号。
Bitmap域比特长度可变，其长度等于从每个分段的第一个丢失的PDCP SDU的下一个PDCP SDU开始到每个分段的最后一个乱序的PDCP SDU(即最后一个丢失的数据包)为止，需要说明的是，bitmap域的长度向上取整到8的整数倍。以第一个字节为例，用MSB(MostSignificant Bit)表示bitmap域第一个字节的最高有效位，用于指示SN＝(FMS/NMS+1)％(Maximum_PDCP_SN+1)的PDCP SDU是否已经成功接收，如果配置了头压缩的话，也表示该SN对应的PDCP SDU解头压缩是否正确。用LSB(Least Significant Bit)表示bitmap域第一个字节的最低有效位，用于指示SN＝(FMS/NMS+8)％(Maximum_PDCP_SN+1)的PDCP SDU是否已经收到，需要补充的是，在本具体实施例中(FMS/NMS)表示FMS或者NMS的含义，在代入公式计算时，采用的是其中两者之一。如FMS/NMS果配置了头压缩的话，也表示该SN对应的PDCPSDU解头压缩是否正确。针对每个分段bitmap域，接收端对没有接收到的PDCP SDU在bitmap域中的对应比特位上填“0”，针对配置了头压缩的情况，对已收到的但解头压缩失败的PDCPSDU也在bitmap域中对应的比特为上填“0”。在bitmap域中其他比特位上填“1”。总的来说，PDCP SDU序列号SN＝(FMS/NMS+bit position)％(Maximum_PDCP_SN+1)为0，表示该数据包需要重传；PDCP SDU序列号SN＝(FMS/NMS+bit position)％(Maximum_PDCP_SN+1)为1，表示该数据包不需要重传。其中，bit position表示bitmap中的第一个比特位到第N比特位，第一个比特位的bit position为1，第N个比特位的bit position为N。
具体实施例1以SN＝15进行状态报告的生成，仅为了更好的说明分段bitmap的主要思想，并不对具体的字段、字段的位置及分段方式进行限定。SN可以为其他值，相应的其他字段也可以增加、删除或修改。
具体实施例2
具体实施例2对应于上述优选实施例中的方式2。
图5是根据具体实施例2的不使用bitmap的PDCP(序列号15bit)状态报告格式示意图。当需要对端重传的数据包SN号跨度很大，且需要重传的数据包稀疏零散分布时，为减少比特开销，需要对现有技术中的PDCP状态报告格式进行增强，即不需要bitmap承载乱序的数据包，仅用NMS指示单个数据包的序列号SN。比如，如果遇到SN＝100，300，500，1000的数据包丢了，每个丢失的数据包之间跨度很大，并且分布很稀疏，不适合采用分段bitmap的方式进行状态报告的生成。针对这种场景，直接用PDCP SDU对应的序列号SN指示，如图5所示，用FMS和NMS表示每个丢失的数据包，跳过不需要重传的数据包。
其中，NMS表示下一个丢失的PDCP序列号，为可选字段，随着需要重传的数据包个数的增加而增加。扩展比特E用于指示FMS和/或NMS后是否有NMS跟随。其他D/C，PDU类型，预留比特R与具体实施例1中的说明一致。具体实施例2仅为了更好的说明生成状态报告的思想，并不受图示中各个字段的限制。
采用本申请文件中记载的技术方案，在用户面状态报告生成过程中，引入分段bitmap方式，无需携带所有数据包的bitmap信息，减少了bitmap的比特开销，提高了用户面状态报告的生成和解析效率，避免用户面状态报告的大小超出上限。
表1是根据本发明实施例的技术术语一览表，如表1所示，记载了申请文件中用到的技术术语中英文全称。
表1
| 缩写 | 英文全称 | 中文释义 |
| 4G/5G | Fourth/Fifth Generation | 第四/第五代移动通信 |
| WLAN | Wireless Local Area Networks | 无线局域网 |
| PDCP | Packet Data Convergence Protocol | 分组数据汇聚协议 |
| SN | Sequence Number | 序列号 |
| FMS | First Missing PDCP SN | 第一个丢失的PDCP序列号 |
| NMS | Next Missing PDCP SN | 下一个丢失的PDCP序列号 |
| SDU | Service Data Unit | 业务数据单元 |
| PDU | Protocol Data Unit | 协议数据单元 |
| RRC | Radio Resource Control | 无线资源控制 |
| D/C | Data/Control PDU | 数据/控制PDU |
| R | Reserved | 预留的 |
| L | Length | 长度指示 |
| MSB | Most significant Bit | 最高有效位 |
| LSB | Least significant Bit | 最低有效位 |
| MeNB | Master evolved Node B | 主演进型节点B |
| SeNB | Secondary evolved Node B | 辅演进型节点B |
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例该的方法。
实施例2
根据本发明的另一个实施例，还提供了一种状态报告生成系统，其特征在于，包括：接收端设备，发送端设备，其中，该接收端设备包括第一处理器和第一通信模块，该发送端设备包括第二处理器和第二通信模块；
该第一处理器生成状态报告，其中，该状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
该第一通信模块向该第二通信模块发送该状态报告；
该第二处理器依据该指示信息通过该第二通信模块向该第一通信模块发送该丢失的数据包。
可选地，该第一处理器生成状态报告，包括以下步骤：确定该数据包的位图文件bitmap信息所属的bitmap分段；依据该bitmap分段生成该状态报告。
可选地，该第一处理器根据以下信息确定该数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息，其中，该起点位置信息用于指示每个分段第一个丢失的数据包序列号SN，该长度信息用于指示分段的bitmap域的比特长度，其中，该bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
实施例3
图6是根据本发明实施例的一种接收端设备的硬件结构框图，如图6所示，该接收端设备60包括：第一处理器62和第一通信模块64；
该第一处理器62生成状态报告，其中，该状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
该第一通信模块64向发送端设备发送该状态报告。
可选地，该第一处理器62生成状态报告，包括：
确定该数据包的位图文件bitmap信息所属的bitmap分段；
依据该bitmap分段生成该状态报告。
可选地，该第一处理器62根据以下信息确定该数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息，其中，该起点位置信息用于指示每个分段第一个丢失的数据包序列号SN，该长度信息用于指示分段的bitmap域的比特长度，其中，该bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
可选地，在该接收端设备60未将该丢失的数据包进行分段的情况下，该状态报告中携带有每一个丢失的数据包的序列号。
图7是根据本发明实施例的一种发送端设备的硬件结构框图，如图7所示，该发送端设备70包括：第二处理器72和第二通信模块74；
该第二通信模块74接收接收端设备发送的状态报告，其中，该状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
该第二处理器72依据该指示信息向该接收端设备发送该丢失的数据包。
可选地，该第二通信模块74接收接收端设备发送的状态报告之前，该接收端设备通过以下方式生成该状态报告：
确定该数据包的位图文件bitmap信息所属的bitmap分段；
依据该bitmap分段生成该状态报告。
可选地，该接收端设备60根据以下信息确定该数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息，其中，该起点位置信息用于指示每个分段第一个丢失的数据包序列号SN，该长度信息用于指示分段的bitmap域的比特长度，其中，该bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
实施例4
本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：
S1，接收端设备生成状态报告，其中，该状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
S2，该接收端设备向发送端设备发送该状态报告。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：
S3，发送端设备接收接收端设备发送的状态报告，其中，该状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
S4，该发送端设备依据该指示信息向该接收端设备发送该丢失的数据包。
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行上述实施例中方法步骤。
可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (19)
1.一种状态报告生成方法，其特征在于，包括：
接收端设备生成状态报告，其中，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
所述接收端设备向发送端设备发送所述状态报告。
2.根据权利要求1所述的方法，其特征在于，接收端设备生成状态报告，包括：
确定所述数据包的位图文件bitmap信息所属的bitmap分段；
依据所述bitmap分段生成所述状态报告。
3.根据权利要求2所述的方法，其特征在于，根据以下信息确定所述数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息。
4.根据权利要求3所述的方法，其特征在于，包括：
所述起点位置信息用于指示每个分段第一个丢失的数据包序列号SN。
5.根据权利要求3所述的方法，其特征在于，包括：
所述长度信息用于指示分段的bitmap域的比特长度，其中，所述bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
6.根据权利要求1所述的方法，其特征在于，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息，包括：
在接收端设备未将所述丢失的数据包进行分段的情况下，所述状态报告中携带有每一个丢失的数据包的序列号。
7.一种状态报告接收方法，其特征在于，包括：
发送端设备接收接收端设备发送的状态报告，其中，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
所述发送端设备依据所述指示信息向所述接收端设备发送所述丢失的数据包。
8.根据权利要求7所述的方法，其特征在于，发送端设备接收接收端设备发送的状态报告之前，所述接收端设备通过以下方式生成所述状态报告：
确定所述数据包的位图文件bitmap信息所属的bitmap分段；
依据所述bitmap分段生成所述状态报告。
9.根据权利要求8所述的方法，其特征在于，所述接收端设备根据以下信息确定所述数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息，其中，所述起点位置信息用于指示每个分段第一个丢失的数据包序列号SN，所述长度信息用于指示分段的bitmap域的比特长度，其中，所述bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
10.一种状态报告生成系统，其特征在于，包括：接收端设备，发送端设备，其中，所述接收端设备包括第一处理器和第一通信模块，所述发送端设备包括第二处理器和第二通信模块；
所述第一处理器生成状态报告，其中，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
所述第一通信模块向所述第二通信模块发送所述状态报告；
所述第二处理器依据所述指示信息通过所述第二通信模块向所述第一通信模块发送所述丢失的数据包。
11.根据权利要求10所述的系统，其特征在于，所述第一处理器生成状态报告，包括：
确定所述数据包的位图文件bitmap信息所属的bitmap分段；
依据所述bitmap分段生成所述状态报告。
12.根据权利要求10所述的系统，其特征在于，所述第一处理器根据以下信息确定所述数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息，其中，所述起点位置信息用于指示每个分段第一个丢失的数据包序列号SN，所述长度信息用于指示分段的bitmap域的比特长度，其中，所述bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
13.一种接收端设备，其特征在于，包括：第一处理器和第一通信模块；
所述第一处理器生成状态报告，其中，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
所述第一通信模块向发送端设备发送所述状态报告。
14.根据权利要求13所述的接收端设备，其特征在于，所述第一处理器生成状态报告，包括：
确定所述数据包的位图文件bitmap信息所属的bitmap分段；
依据所述bitmap分段生成所述状态报告。
15.根据权利要求13所述的接收端设备，其特征在于，所述第一处理器根据以下信息确定所述数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息，其中，所述起点位置信息用于指示每个分段第一个丢失的数据包序列号SN，所述长度信息用于指示分段的bitmap域的比特长度，其中，所述bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
16.根据权利要求13所述的接收端设备，其特征在于，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息，包括：
在所述接收端设备未将所述丢失的数据包进行分段的情况下，所述状态报告中携带有每一个丢失的数据包的序列号。
17.一种发送端设备，其特征在于，包括：第二处理器和第二通信模块；
所述第二通信模块接收接收端设备发送的状态报告，其中，所述状态报告中携带有用于指示一个或多个丢失的数据包的指示信息；
所述第二处理器依据所述指示信息向所述接收端设备发送所述丢失的数据包。
18.根据权利要求17所述的发送端设备，其特征在于，所述第二通信模块接收接收端设备发送的状态报告之前，所述接收端设备通过以下方式生成所述状态报告：
确定所述数据包的位图文件bitmap信息所属的bitmap分段；
依据所述bitmap分段生成所述状态报告。
19.根据权利要求18所述的发送端设备，其特征在于，所述接收端设备根据以下信息确定所述数据包的位图bitmap信息所属的bitmap分段：
每个分段的起点位置信息，每个分段的长度信息，其中，所述起点位置信息用于指示每个分段第一个丢失的数据包序列号SN，所述长度信息用于指示分段的bitmap域的比特长度，其中，所述bitmap域的比特长度等于该分段的第一个丢失的数据包到该分段最后一个丢失的数据包的长度。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610665206.5A CN107734547A (zh) | 2016-08-12 | 2016-08-12 | 状态报告生成和系统，及状态报告接收方法 |
| PCT/CN2017/097219 WO2018028697A1 (zh) | 2016-08-12 | 2017-08-11 | 状态报告生成方法和系统，及状态报告接收方法、设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610665206.5A CN107734547A (zh) | 2016-08-12 | 2016-08-12 | 状态报告生成和系统，及状态报告接收方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN107734547A true CN107734547A (zh) | 2018-02-23 |
Family
ID=61161783
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610665206.5A Pending CN107734547A (zh) | 2016-08-12 | 2016-08-12 | 状态报告生成和系统，及状态报告接收方法 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN107734547A (zh) |
| WO (1) | WO2018028697A1 (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110557229A (zh) * | 2018-05-31 | 2019-12-10 | 中国移动通信有限公司研究院 | 一种数据发送方法、接收方法、发送端及接收端 |
| WO2020063501A1 (zh) * | 2018-09-27 | 2020-04-02 | 华为技术有限公司 | 传输确认报文的方法和通信设备 |
| CN111262648A (zh) * | 2018-11-30 | 2020-06-09 | 华为技术有限公司 | 通信方法和装置 |
| WO2020155161A1 (en) * | 2019-02-02 | 2020-08-06 | Zte Corporation | Method and apparatus for performing data packet retransmission in wireless communication system |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101145892A (zh) * | 2006-09-11 | 2008-03-19 | 华为技术有限公司 | 一种快速应答的方法、系统、接收端和发送端 |
| US7720070B1 (en) * | 2007-02-15 | 2010-05-18 | Apacewave Technologies Corporation | Hybrid acknowledgement map format for data communication networks |
| CN101827016A (zh) * | 2010-01-28 | 2010-09-08 | 北京天碁科技有限公司 | 一种生成接收数据的状态报告的方法和装置 |
| CN104518853A (zh) * | 2013-09-27 | 2015-04-15 | 北京新媒传信科技有限公司 | 一种数据重传的方法、接收端及系统 |
| CN104579573A (zh) * | 2015-01-19 | 2015-04-29 | 北京华力创通科技股份有限公司 | 数据传输的反馈信息的编码、解码方法及发送端和接收端 |
| WO2015154523A1 (zh) * | 2014-09-03 | 2015-10-15 | 中兴通讯股份有限公司 | 丢失数据的恢复处理方法及装置 |
| WO2016123293A1 (en) * | 2015-01-28 | 2016-08-04 | Umbra Technologies Ltd. | System and method for a global virtual network |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060034274A1 (en) * | 2004-07-30 | 2006-02-16 | Nokia Corporation | System and method for variable length acknowledgements in a shared resource network |
| CN101222516B (zh) * | 2007-01-09 | 2011-12-07 | 华为技术有限公司 | Mac层数据处理方法、发送装置及接收装置 |
-
2016
- 2016-08-12 CN CN201610665206.5A patent/CN107734547A/zh active Pending
-
2017
- 2017-08-11 WO PCT/CN2017/097219 patent/WO2018028697A1/zh active Application Filing
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101145892A (zh) * | 2006-09-11 | 2008-03-19 | 华为技术有限公司 | 一种快速应答的方法、系统、接收端和发送端 |
| US7720070B1 (en) * | 2007-02-15 | 2010-05-18 | Apacewave Technologies Corporation | Hybrid acknowledgement map format for data communication networks |
| CN101827016A (zh) * | 2010-01-28 | 2010-09-08 | 北京天碁科技有限公司 | 一种生成接收数据的状态报告的方法和装置 |
| CN104518853A (zh) * | 2013-09-27 | 2015-04-15 | 北京新媒传信科技有限公司 | 一种数据重传的方法、接收端及系统 |
| WO2015154523A1 (zh) * | 2014-09-03 | 2015-10-15 | 中兴通讯股份有限公司 | 丢失数据的恢复处理方法及装置 |
| CN104579573A (zh) * | 2015-01-19 | 2015-04-29 | 北京华力创通科技股份有限公司 | 数据传输的反馈信息的编码、解码方法及发送端和接收端 |
| WO2016123293A1 (en) * | 2015-01-28 | 2016-08-04 | Umbra Technologies Ltd. | System and method for a global virtual network |
Non-Patent Citations (1)
| Title |
|---|
| ""CT68_CRpacks_v002"", 《3GPP TSG_CT\TSG_CT》 * |
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110557229B (zh) * | 2018-05-31 | 2022-04-29 | 中国移动通信有限公司研究院 | 一种数据发送方法、接收方法、发送端及接收端 |
| CN110557229A (zh) * | 2018-05-31 | 2019-12-10 | 中国移动通信有限公司研究院 | 一种数据发送方法、接收方法、发送端及接收端 |
| US11533657B2 (en) * | 2018-09-27 | 2022-12-20 | Huawei Technologies Co., Ltd. | Acknowledgment packet transmission method and communications device |
| JP2021532636A (ja) * | 2018-09-27 | 2021-11-25 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | 確認パケット伝送方法および通信デバイス |
| CN110958084B (zh) * | 2018-09-27 | 2021-12-14 | 华为技术有限公司 | 传输确认报文的方法和通信设备 |
| CN110958084A (zh) * | 2018-09-27 | 2020-04-03 | 华为技术有限公司 | 传输确认报文的方法和通信设备 |
| WO2020063501A1 (zh) * | 2018-09-27 | 2020-04-02 | 华为技术有限公司 | 传输确认报文的方法和通信设备 |
| JP7210867B2 (ja) | 2018-09-27 | 2023-01-24 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | 確認パケット伝送方法および通信デバイス |
| CN111262648A (zh) * | 2018-11-30 | 2020-06-09 | 华为技术有限公司 | 通信方法和装置 |
| CN111262648B (zh) * | 2018-11-30 | 2021-09-07 | 华为技术有限公司 | 通信方法和装置 |
| US11936472B2 (en) | 2018-11-30 | 2024-03-19 | Huawei Technologies Co., Ltd. | Communication method and communications apparatus for improving reliability of data transmission |
| WO2020155161A1 (en) * | 2019-02-02 | 2020-08-06 | Zte Corporation | Method and apparatus for performing data packet retransmission in wireless communication system |
| US11968048B2 (en) | 2019-02-02 | 2024-04-23 | Zte Corporation | Method and apparatus for performing data packet retransmission in wireless communication system |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2018028697A1 (zh) | 2018-02-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11290221B2 (en) | Method and apparatus for transmitting and receiving data in a communication system | |
| CN104137458B (zh) | 用于块确收压缩的装置和方法 | |
| US20050213605A1 (en) | Method for efficiently utilizing radio resources in a mobile telecommunication system providing VoIP service | |
| EP2445250A1 (en) | Data packet sending, receiving and transmission method and device | |
| CN1265591C (zh) | 无线通信网中载送分组语音和数据的方法和设备 | |
| US10469210B2 (en) | Acknowledgment data unit for data unit fragment | |
| CN107734547A (zh) | 状态报告生成和系统，及状态报告接收方法 | |
| EP2672743B1 (en) | Non-i/q data transmission method and device for common public radio interface | |
| CN111698067B (zh) | 数据传输方法及装置 | |
| US20200145145A1 (en) | Acknowledgment data unit for data unit fragment | |
| CN108847919B (zh) | 一种数据传输的方法、基站和无线通信设备 | |
| EP3790213B1 (en) | Mac-based hybrid automatic repeat request (harq) | |
| CN102088715B (zh) | 一种数据包分段方法及设备 | |
| CN101242402A (zh) | 构成无线链路控制层的协议数据单元的方法和装置 | |
| JP7297678B2 (ja) | データが破損しているかどうかを判断するための方法および装置 | |
| CN112188553A (zh) | 一种5g系统的数据传输方法及装置 | |
| CN101990241B (zh) | 一种分组数据传输系统和方法 | |
| CN107612871B (zh) | 一种数据传输处理方法、用户终端、网络设备和系统 | |
| CN103916386A (zh) | 数据发送和数据接收方法 | |
| CN111416689B (zh) | 数据传输方法及通信设备 | |
| CN109587728B (zh) | 拥塞检测的方法和装置 | |
| CN110233697A (zh) | 一种信息数据块的处理方法和发送端 | |
| CN113141631B (zh) | 双连接数据分流方法、装置、设备及存储介质 | |
| EP4380297A1 (en) | Method for performing medium access control protocol data unit dispatch control in multi-link operation architecture, and associated apparatus | |
| US20240098016A1 (en) | Method for performing adaptive multi-link aggregation dispatching control in multi-link operation architecture, and associated apparatus |
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 | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20180223 |
|
| RJ01 | Rejection of invention patent application after publication |