CN113711627B

CN113711627B - 数据传输方法和装置

Info

Publication number: CN113711627B
Application number: CN201980095376.6A
Authority: CN
Inventors: 付喆; 卢前溪
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2019-09-30
Filing date: 2019-09-30
Publication date: 2023-03-24
Anticipated expiration: 2039-09-30
Also published as: WO2021062728A1; CN113711627A

Abstract

本发明实施例提供了一种数据传输方法和装置，其中所述方法包括：压缩端发送第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；所述压缩端发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息。上述方法能够实现以太头压缩的数据传输。

Description

数据传输方法和装置

技术领域

本发明涉及数据传输技术领域，特别涉及一种数据传输方法和装置。

背景技术

现有的通信系统中支持对PDU会话(PDU session，PDU即Protocol Data Unit，协议数据单元)中的IP数据包进行头压缩。PDCP((Packet Data Convergence Protocol，分组数据汇聚协议)中引入了头压缩和解压缩功能，该功能能够对IP数据包进行头压缩。当前的ROHC(Robust Header Compression，健壮性包头压缩)是针对DRB(Data Radio Bearer，数据无线承载)配置的，压缩端和解压缩端根据配置文件(profile)中确定的不同的头压缩以及头压缩参数，通过采用RoHC协议进行压缩和解压缩处理。当前的RoHC配置参数是在PDCP-config中配置的，其中每个 PDCP-config对应一个DRB。在一个实施例中，该RoHC配置参数可以为： rohc SEQUENCE{

maxCID INTEGER(1..16383) DEFAULT 15，

profiles SEQUENCE{

profile0x0001 BOOLEAN，

profile0x0002 BOOLEAN，

profile0x0003 BOOLEAN，

profile0x0004 BOOLEAN，

profile0x0006 BOOLEAN，

profile0x0101 BOOLEAN，

profile0x0102 BOOLEAN，

profile0x0103 BOOLEAN，

profile0x0104 BOOLEAN

}，

drb-ContinueROHC ENUMERATED{true} OPTIONAL--Need N

}，

uplinkOnlyROHC SEQUENCE{

maxCID INTEGER(1..16383) DEFAULT 15，

profiles SEQUENCE{

profile0x0006 BOOLEAN

}，

drb-ContinueROHC ENUMERATED{true} OPTIONAL--Need N

}，

现有技术中，PDU会话中无法对以太网包进行头压缩。

发明内容

为了解决相关技术中对于存在的多个问题中的至少一个问题，本发明实施例提出了一种数据传输方法和装置。所述技术方案如下：

第一方面，提供了一种数据传输方法，包括：

压缩端发送第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

所述压缩端发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息。

在一个实施例中，所述压缩端在第一状态下发送所述第一类型包；且所述压缩端在第二状态下发送所述第二类型包。

在一个实施例中，所述第一状态为初始状态或未压缩状态；和/或，所述第二状态为压缩状态。

在一个实施例中，所述第一类型包和/或所述第二类型包还包括：上下文标识和/或包类型标识符；

其中所述上下文标识用于标识所述第一类型包和/或所述第二类型包所对应的上下文，其中所述包类型标识符用于标识该包为所述第一类型包或所述第二类型包。

在一个实施例中，所述第一类型包为完整包；和/或，所述第二类型包为压缩包。

在一个实施例中，所述方法还包括：

当所述压缩端的上下文信息变更，或所述压缩端处于压缩状态第一时间长度后，所述压缩端从第二状态转换到第一状态。

在一个实施例中，所述方法还包括：

所述压缩端发送触发指示以请求接收具有ACK/NACK标识的第三类型包；

或

所述压缩端接收具有NACK标识的第三类型包；

或

所述压缩端接收具有ACK标识的第三类型包；

或

所述压缩端接收第三类型包，但所述第三类型包中不具有所述 ACK/NACK标识。

在一个实施例中，所述方法还包括：

当所述压缩端接收到第三类型包或具有NACK标识第三类型包时，所述压缩端从第二状态切换到第一状态，和/或，

当所述压缩端接收到第三类型包或具有ACK标识的第三类型包时，所述压缩端从第一状态切换到第二状态。

在一个实施例中，所述压缩端发送第一类型包具体包括：

所述压缩端发送第一预设数量的所述第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

其中所述第一预设数量为所述压缩端确定，或所述压缩端根据接收到的配置参数确定。

在一个实施例中，所述方法具体包括：

所述压缩端发送所述第一类型包；

当所述压缩端接收到第三类型包后，所述压缩端从第一状态切换到第二状态并发送所述第二类型包；

或

所述压缩端发送第一预设数量的所述第一类型包后，所述压缩端从第一状态切换到第二状态并发送所述第二类型包；

或

所述压缩端发送所述第一预设数量的第一类型包；

当所述压缩端在发送所述第一预设数量的所述第一类型包并接收到第三类型包后，所述压缩端从第一状态切换到第二状态并发送所述第二类型包。

在一个实施例中，所述第三类型包中至少包括上下文标识；其中所述上下文标识用于标识所述第三类型包所对应的上下文。

在一个实施例中，所述第三类型包中包括ACK/NACK标识，所述 ACK/NACK标识用于指示接收所述第一类型包和所述第二类型包的接收端对所述第一类型包和/或所述第二类型包的处理结果，或者，指示解压缩端的上下文信息是否保存。

在一个实施例中，所述压缩端通过单向链路发送所述第一类型包和所述第二类型包。

在一个实施例中，所述第二类型包内具有循环冗余校验。

第二方面，提供了一种数据传输方法，包括：

解压缩端接收第一类型包和/或第二类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；其中所述第二类型包内至少包括：压缩的以太网头的包头信息；

所述解压缩端根据接收到的所述第一类型包和所述第二类型包进行处理。

在一个实施例中，所述解压缩端在第三状态下接收所述第一类型包和 /或所述第二类型包。

在一个实施例中，所述解压缩端对所述第一类型包或所述第二类型包进行处理，并在处理成功后切换到第四状态。

在一个实施例中，所述第三状态为无上下文状态；和/或，所述第四状态为静态上下文状态或完全上下文状态。

在一个实施例中，在所述方法还包括：

所述解压缩端再次或重新接收到所述第一类型包后，从第四状态切换到第三状态。

在一个实施例中，所述方法还包括：

所述解压缩端判断对所述第一类型包和/或所述第二类型包进行处理是否成功；

如果成功则将ACK标识添加到第三类型包中并发送；

如果失败则将NACK标识添加到所述第三类型包中并发送。

在一个实施例中，所述方法还包括：

如果成功则将ACK标识添加到第三类型包中并发送；且所述解压缩端从第三状态切换到第四状态；

如果失败则将NACK标识添加到所述第三类型包中并发送；且所述解压缩端从所述第四状态切换到所述第三状态。

在一个实施例中，所述方法还包括：

如果成功则发送第三类型包；

如果失败则不发送所述第三类型包。

在一个实施例中，所述方法还包括：

如果失败则发送所述第三类型包；

如果成功则不发送所述第三类型包。

在一个实施例中，所述解压缩端接收第一类型包和/或第二类型包，具体包括：

所述解压缩端接收所述第一类型包；

所述解压缩端发送第三类型包以请求接收所述第二类型包；

所述解压缩端接收所述第二类型包。

所述解压缩端接收所述第二类型包；

所述解压缩端发送第三类型包以请求接收所述第一类型包；

所述解压缩端接收所述第一类型包。

在一个实施例中，所述解压缩端通过单向链路接收所述第一类型包和所述第二类型包。

在一个实施例中，所述方法还包括：

当所述解压缩端在第四状态下再次接收到所述第一类型包后，将所述解压缩端从所述第四状态切换到第三状态。

在一个实施例中，所述方法还包括：

当所述解压缩端在接收到触发指示后，发送第三类型包；

其中所述第三类型包内包括用于标识所述解压缩端对接收到的所述第一类型包或所述第二类型包的处理是否成功的ACK/NACK标识；

如果所述第三类型包内的标识为所述NACK标识时，所述解压缩端从第四状态转换到第三状态；或

如果所述第三类型包内的标识为所述ACK标识时，所述解压缩端从第三状态转换到第四状态。

在一个实施例中，所述方法还包括：所述解压缩端根据所述第二类型包中的循环冗余校验，用于确定解压缩是否成功和/或上下文是否有效。

第三方面，提供了一种数据传输方法，包括：

压缩端在第一状态下发送N个第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

当发送完所述N个第一类型包后，所述压缩端从所述第一状态切换到第二状态，并发送一个或多个第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息；

解压缩端在第三状态下接收所述第一类型包；

解压缩端在所述第三状态下接收第二类型包后，对所述第二类型包进行处理，并判断处理是否成功，如果是则所述解压缩端切换到第四状态，如果否则解压缩端在所述第三状态下发送第三类型包以使所述压缩端重新发送所述第一类型包。

在一个实施例中，所述方法还包括：

当所述压缩端的上下文信息变更，或所述压缩端处于所述第二状态达到第一时间长度后，所述压缩端从所述第二状态切换到所述第一状态，并发送所述第一类型包；

当所述解压缩端再次接收到所述第一类型包时，所述解压缩端从所述第四状态切换到所述第三状态并接收所述第一类型包。

在一个实施例中，所述方法还包括：

所述压缩端在上下文信息变更，或所述压缩端处于所述第二状态达到第一时间长度后，所述压缩端从所述第二状态切换到所述第一状态并重新发送所述第一类型包。

在一个实施例中，所述方法还包括：

所述压缩端向所述解压缩端发送触发请求，以请求所述解压缩端发送对所述第一类型包或所述第二类型包的处理结果；

所述解压缩端在接收到所述触发请求后，向所述压缩端发送所述第三类型包；当所述标识为处理失败时，所述解压缩端从所述第四状态切换到所述第三状态并接收所述第一类型包；当所述标识为处理成功时，所述解压缩端维持在所述第四状态。

在一个实施例中，所述方法还包括：

所述解压缩端向所述压缩端发送带有ACK标识的第三类型包；其中所述ACK标识用于指示所述解压缩端对所述第一类型包或所述第二类型包处理成功。

在一个实施例中，所述方法还包括：

所述解压缩端向所述压缩端发送带有NACK标识的第三类型包；其中所述NACK标识用于指示所述解压缩端对所述第一类型包或所述第二类型包处理失败。

在一个实施例中，所述第一状态为初始状态或未压缩状态；和/或，所述第二状态为压缩状态；和/或，所述第三状态为无上下文状态；和/或，所述第四状态为静态上下文状态或完全上下文状态。

在一个实施例中，所述第一类型包为完整包；和/或，所述第二类型包为压缩包；和/或，所述第三类型包为反馈包；

其中所述第一类型包和/或所述第二类型包还包括：上下文标识和/或包类型标识符；其中所述上下文标识用于标识所述第一类型包和/或所述第二类型包所对应的上下文，其中所述包类型标识用于标识该包为所述第一类型包或所述第二类型包。

其中所述第三类型包包括上下文标识；其中所述上下文标识用于标识第三类型包所对应的上下文。

在一个实施例中，所述第二类型包内具有循环冗余校验。

在一个实施例中，所述解压缩端根据所述第二类型包中的循环冗余校验，用于确定解压缩是否成功和/或上下文是否有效。

第四方面，提供了一种数据传输方法，包括：

压缩端在第一状态下发送第一类型包；其中所述第一类型包至少包括：未压缩的以太网头的包头信息；

解压缩端在第三状态下接收所述第一类型包；

所述解压缩端发送第三类型包以反馈对所述第一类型包的接收和/或处理结果；

所述压缩端发送第一预设数量的所述第一类型包并接收到所述解压缩端发送的所述第三类型包后，或所述压缩端发送所述第一类型包并接收到所述解压缩端发送的所述第三类型包后，或所述压缩端发送所述第一类型包并接收到所述解压缩端发送的包括ACK标识的第三类型包后，所述压缩端切换到第二状态，并发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息。

在一个实施例中，所述方法还包括：

所述解压缩端在接收到所述第一类型包后，发送所述第三类型包以反馈对所述第一类型包的接收和/或处理结果，所述第三类型包中至少包括上下文标识；其中所述上下文标识用于标识所述第三类型包所对应的上下文。

在一个实施例中，所述方法还包括：

所述压缩端在上下文信息变更，或所述压缩端处于所述第二状态达到第一时间长度后，所述压缩端从所述第二状态切换到所述第一状态，并重新发送所述第一类型包。

在一个实施例中，所述方法还包括：

所述解压缩端在接收到所述触发请求后，向所述压缩端发送所述第三类型包；当处理失败时，所述解压缩端从第四状态切换到所述第三状态，并重新接收所述压缩端在所述第一状态下发送的所述第一类型包；当处理成功时，所述解压缩端维持在所述第四状态。

在一个实施例中，所述方法还包括：

所述解压缩端向所述压缩端发送所述包括ACK标识的第三类型包；其中所述ACK标识用于指示所述解压缩端对所述第一类型包或所述第二类型包处理成功。

在一个实施例中，所述方法还包括：

在一个实施例中，所述第一状态为初始状态或未压缩状态；和/或，所述第二状态为压缩状态；和/或，所述第三状态为无上下文状态；和/或，第四状态为静态上下文状态或完全上下文状态。

其中所述第三类型包包括上下文标识；其中所述上下文标识用于标识所述第三类型包所对应的上下文。

第五方面，提供了一种数据传输方法，包括：

压缩端在第一状态下通过单向链路发送N个第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

解压缩端在第三状态下接收M个所述第一类型包后切换到第四状态，并对所述第一类型包和/或所述第二类型包进行处理。

在一个实施例中，所述方法还包括：

当所述解压缩端再次接收到所述第一类型包时，所述解压缩端从所述第四状态切换到所述第三状态。

在一个实施例中，所述第二类型包内具有循环冗余校验。

在一个实施例中，所述单向链路包括为以下至少一种：

配置了um-Uni-Directional-UL的链路；

配置了um-Uni-Directional-DL的链路；

multi-cast；或

sidelink。

第六方面，提供了一种数据传输装置，设置于压缩端，包括：

第一发送模块，用于发送第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

第二发送模块，用于发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息。

在一个实施例中，所述第一发送模块在第一状态下发送所述第一类型包；且所述第二发送模块在第二状态下发送所述第二类型包。

在一个实施例中，所述装置还包括：

更新模块，用于当所述压缩端的上下文信息变更，或所述压缩端处于压缩状态第一时间长度后，使所述压缩端从第二状态转换到第一状态。

在一个实施例中，所述装置还包括接收模块，所述接收模块用于执行以下操作：

发送触发指示以请求接收具有ACK/NACK标识的第三类型包；

或

接收具有NACK标识的第三类型包；

或

接收具有ACK标识的第三类型包；

或

接收第三类型包，所述第三类型包中不具有ACK/NACK标识。

在一个实施例中，所述装置还包括切换模块，所述切换模块用于执行以下操作：

当所述压缩端接收到第三类型包或具有NACK标识的第三类型包时，所述压缩端从第二状态切换到第一状态，和/或，

在一个实施例中，所述第一发送模块用于执行以下操作：

发送第一预设数量的所述第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

在一个实施例中，所述装置执行以下操作：

所述第一发送模块发送所述第一类型包；

接收模块接收到第三类型包后，切换模块将所述压缩端从第一状态切换到第二状态并通过所述第二发送模块发送所述第二类型包；

或

所述第一发送模块发送第一预设数量的所述第一类型包后，所述切换模块将所述压缩端从第一状态切换到第二状态并通过所述第二发送模块发送所述第二类型包；

或

所述第一发送模块发送第一预设数量的所述第一类型包；

当所述第一发送模块发送所述第一预设数量的所述第一类型包并且接收模块接收到第三类型包后，所述切换模块将所述压缩端从第一状态切换到第二状态通过所述第二发送模块发送所述第二类型包。

在一个实施例中，所述第二类型包内具有循环冗余校验。

第七方面，提供了一种数据传输装置，设置于解压缩端，包括：

第一接收模块，用于接收第一类型包和/或第二类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；其中所述第二类型包内至少包括：压缩的以太网头的包头信息；

处理模块，用于根据接收到的所述第一类型包和所述第二类型包进行处理。

在一个实施例中，所述第一接收模块，在第三状态下接收所述第一类型包和/或所述第二类型包。

在一个实施例中，所述处理模块用于对所述第一类型包或所述第二类型包进行处理，并在处理成功后切换到第四状态。

在一个实施例中，所述第一接收模块还用于执行以下操作：

在一个实施例中，所述处理模块还用于执行以下操作：

如果成功则将ACK标识添加到第三类型包中并发送；

如果失败则将NACK标识添加到所述第三类型包中并发送。

在一个实施例中，所述方法还包括：

在一个实施例中，所述处理模块还用于在执行以下操作：

判断对所述第一类型包和/或所述第二类型包进行处理是否成功；

如果成功则发送第三类型包；

如果失败则不发送所述第三类型包。

在一个实施例中，所述处理模块还用于在执行以下操作：

判断对第所述一类型包和/或所述第二类型包进行处理是否成功；

如果失败则发送第三类型包；

如果成功则不发送所述第三类型包。

在一个实施例中，所述第一接收模块用于执行以下操作：

接收所述第一类型包；

发送第三类型包以请求接收所述第二类型包；

接收第所述二类型包。

在一个实施例中，所述第一接收模块用于执行以下操作：

接收所述第二类型包；

发送第三类型包以请求接收所述第一类型包；

接收所述第一类型包。

在一个实施例中，所述第一接收模块还用于执行以下操作：

在一个实施例中，所述装置还包括发送模块；

所述发送模块用于当所述解压缩端在接收到触发指示后，发送第三类型包；

第八方面，提供了一种数据传输系统，包括压缩端和解压缩端：

解压缩端在第三状态下接收所述第一类型包；

解压缩端在所述第三状态下接收第二类型包后，对所述该第二类型包进行处理，并判断处理是否成功，如果是则所述解压缩端切换到第四状态，如果否则解压缩端在所述第三状态下发送第三类型包以使所述压缩端重新发送所述第一类型包。

在一个实施例中，所述系统中：

所述解压缩端在接收到所述触发请求后，向所述压缩端发送所述第三类型包；当标识为处理失败时，所述解压缩端从所述第四状态切换到所述第三状态并接收所述第一类型包；当所述标识为处理成功时，所述解压缩端维持在所述第四状态。

在一个实施例中，所述系统中：

在一个实施例中，所述第二类型包内具有循环冗余校验，用于确定解压缩是否成功和/或上下文是否有效。

第九方面，提供了一种数据传输系统，包括压缩端和解压缩端：

解压缩端在第三状态下接收所述第一类型包；

所述压缩端在发送第一预设数量的所述第一类型包并接收到所述解压缩端发送的所述第三类型包后，或所述压缩端发送第一类型包并接收到所述解压缩端发送的所述第三类型包后，或所述压缩端发送所述第一类型包并接收到所述解压缩端发送的包括ACK标识的第三类型包后，所述压缩端切换到第二状态，并发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息。

在一个实施例中，所述系统中：所述解压缩端在接收到所述第一类型包后，发送所述第三类型包以反馈对所述第一类型包的接收和/或处理结果，所述第三类型包中至少包括上下文标识；其中所述上下文标识用于标识所述第三类型包所对应的上下文。

在一个实施例中，所述系统中：所述压缩端在上下文信息变更，或所述压缩端处于所述第二状态达到第一时间长度后，所述压缩端从所述第二状态切换到所述第一状态，并重新发送所述第一类型包。

在一个实施例中，所述系统中：

所述解压缩端向所述压缩端发送所述包括ACK标识的第三类型包；其中所述ACK标识用于指示所述解压缩端对所述第一类型包或所述第二类型包处理成功；

或

第十方面，提供了一种数据传输系统，包括压缩端和解压缩端：

在一个实施例中，所述系统中：

当所述解压缩再次接收到所述第一类型包时，所述解压缩端从所述第四状态切换到所述第三状态。

在一个实施例中，所述第二类型包内具有循环冗余校验。

在一个实施例中，所述单向链路包括为以下至少一种：

配置了um-Uni-Directional-UL的链路；

配置了um-Uni-Directional-DL的链路；

multi-cast；或

sidelink。

本发明实施例提供的技术方案的有益效果是：上述实施例提出了一种数据传输方法，能够实现对以太头压缩的数据传输。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1本申请一个示例性实施例提供的一种数据传输方法的流程示意图；

图2本申请一个示例性实施例提供的另一种数据传输方法的流程示意图；

图3本申请一个示例性实施例提供的又一种数据传输方法的流程示意图；

图4本申请一个示例性实施例提供的再一种数据传输方法的流程示意图；

图5本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图6本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图7本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图8本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图9本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图10本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图11本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图12本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图13本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图14本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图15本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图16本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图17本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图18本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图19本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图20本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图21本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图22本申请一个示例性实施例提供的又再一种数据传输方法的流程示意图；

图23本申请一个示例性实施例提供的另一种数据传输装置的模块示意图；

图24本申请一个示例性实施例提供的又一种数据传输装置的模块示意图；

图25本申请一个示例性实施例提供的数据传输系统的模块示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

示例性的，本发明实施例的技术方案可以应用于工业物联网 (IndustrialInternet of Things，简称IIoT)领域。其中IIoT是将传感器数据流转化成有用的信息。随着5G技术的发展，5G IIoT的应用已经提上日程。5G IIoT中需求支持工业自动化(Factoryautomation)，传输自动化 (Transport Industry)，智能电力(Electrical PowerDistribution)等业务在5G系统的传输。基于其时延和可靠性的传输需求，IIoT引入了时间敏感性网络TSN网络或TSC的概念，并且需要对TSN业务进行头压缩处理。

由于因为现有的通信系统中仅支持对PDU会话(PDU session，PDU 即ProtocolData Unit，协议数据单元)中的IP数据包进行头压缩；而在 5G NR系统中的PDU session的类型不仅可以为IP包类型，也可以为以太帧Ethernet frame类型。具体而言，对于PDU层(PDU layer)来说，当 PDU Session类型为IPv4或IPv6或IPv4v6，则该PDU session对应的数据包为IPv4 packets和/或IPv6 packets；而当PDU Session类型为以太网 Ethernet的时候，则PDU session对应的数据包为以太帧(Ethernet frame)。

PDCP(Packet Data Convergence Protocol，分组数据汇聚协议)中引入了头压缩和解压缩功能，该功能能够对IP数据包进行头压缩。当前的 ROHC(Robust HeaderCompression，健壮性包头压缩)是针对DRB(Data Radio Bearer，数据无线承载)配置的，压缩端和解压缩端根据配置文件 (profile)中确定的不同的头压缩以及头压缩参数，通过采用RoHC协议进行压缩和解压缩处理。当前的RoHC配置参数是在PDCP-config中配置的，其中每个PDCP-config对应一个DRB。在一个实施例中，该RoHC 配置参数可以为：

rohc SEQUENCE{

maxCID INTEGER(1..16383) DEFAULT 15，

profiles SEQUENCE{

profile0x0001 BOOLEAN，

profile0x0002 BOOLEAN，

profile0x0003 BOOLEAN，

profile0x0004 BOOLEAN，

profile0x0006 BOOLEAN，

profile0x0101 BOOLEAN，

profile0x0102 BOOLEAN，

profile0x0103 BOOLEAN，

profile0x0104 BOOLEAN

}，

drb-ContinueROHC ENUMERATED{true} OPTIONAL--Need N

}，

uplinkOnlyROHC SEQUENCE{

maxCID INTEGER(1..16383) DEFAULT 15，

profiles SEQUENCE{

profile0x0006 BOOLEAN

}，

drb-ContinueROHC ENUMERATED{true} OPTIONAL--Need N

}。

TSC业务可以由以太帧(Ethernet frame)承载，也可由IP包承载。当由以太帧(Ethernet frame)承载时，Ethernet头压缩应当基于以下的前提：

1.以太头压缩(Ethernet Header Compression，EHC)是多个DRB配置的，且对于上行(UpLink，UL)和下行(DownLink，DL)是独立的(Ethernet Header Compression(EHC)isconfigured per DRB，separately for UL and DL)；

2.用上下文标识(context ID)概念，这样压缩端和解压端利用该 context ID来关联以太头上下文(Use context ID concept such that compressor and decompressorassociates a context ID with Ethernet header contents)；

3.压缩应用基于以下原理执行(Compression is done with followingprinciple)：

-对于最终建立新上下文的以太流，压缩端传输至少一个包括完整的头和上下文标识的至少一个包完整包(以在解压端建立上下文)；(For Ethernet flow resulting increation of new context，compressor transmits at least one packet with fullheader and context id(to establish context in decompressor).

-随后，压缩端开始传输压缩的包；当多重传输时进行FFS(For Further Study，进一步研究)和/或进行反馈。(After above，compressor starts transmits compressedpackets.FFS if multiple transmissions and/or feedback is needed)。

3.EHC头格式需要具有以下必须的字段：上下文标识(context ID)、头格式指示符(Indication of header format)(例如，完整的头和压缩的头)、 FFS其他字段，例如配置文件标识(profile ID)。(EHC header format is designed to include followingmandatory fields:Context ID，Indication of header format(i.e.full header andcompressed header)，FFS other field，e.g. profile ID)。

实施例1

在本发明的一个实施例中，提出了一种在以太头压缩(Ethernet HeaderCompression，EHC)中的数据传输方法如图1所示包括：

步骤1101、压缩端发送第一预设数量的第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

步骤1102、所述压缩端发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息。

在本发明的一个实施例中：其中第一类型包为完整包(full packet)，第二类型包为压缩包(compressed packet)。在发明的一个实施例中，所述完整包包括未压缩的以太网头的包头信息。在本发明的一个实施例中，该完整包里还可以包括：上下文标识(ContextID)和/或包类型标识符。进一步的还可以包括profile信息。在本发明的一个实施例中，其中上下文标识(Context ID)用于压缩端进行压缩和/或用于解压缩端进行解压缩。发明的一个实施例中，压缩包包括压缩的以太网头的包头信息。在本发明的一个实施例中，该压缩包里还可以包括：上下文标识(Context ID)和/ 或包类型标识符。进一步的还可以包括profile信息。在本发明的一个实施例中，其中上下文标识(Context ID)等上下文信息用于压缩端进行压缩和/或用于解压缩端进行解压缩。

进一步的，所述方法如图2所示包括：

步骤1101A、压缩端在第一状态下发送第一预设数量的完整包；其中所述完整包内至少包括：未压缩的以太网头的包头信息；

步骤1102A、所述压缩端切换到第二状态，并发送压缩包；其中所述压缩包内至少包括：压缩的以太网头的包头信息。

即，所述压缩端在发送完整包和压缩包时处于不同的状态。

在本发明的一个实施例中，该第一状态可以为初始状态IR

(initialization and Refresh)或未压缩状态UC(Uncompression)。其中，该第二状态可以为压缩状态CO(Compression order)。

即所述方法如图3所示具体包括：

步骤1101B、压缩端在初始状态IR或未压缩状态UC下，发送第一预设数量的完整包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

步骤1102B、所述压缩端切换到压缩状态CO，并发送的压缩包；其中所述压缩包内至少包括：压缩的以太网头的包头信息。

在本发明的以上的所有实施例和以下的所有实施例中，第一预设数量为N，该第一预设数量可以为任一个设备通过任何一种信令配置给压缩端的，也可以为压缩端自行确定的，还可以为预先存储在压缩端中的，本发明实施例并不对此做出任何限定。而压缩包可以为一个或多个，即可以在发送N个完整包后发送一个或多个压缩包。

在本发明的一个实施例中，所述数据传输方法还包括：

步骤1103、压缩端接收解压缩端返回的反馈包；当压缩端根据所述反馈包确定解压缩端处理不成功时，所述压缩端从压缩状态CO转换到初始状态IR或未压缩状态UC，并跳转到步骤1101或1101A或1101B。

在本发明的一个实施例中，该第三类型包中具有ACK/NACK标识，以标识出成功/失败；或所述压缩端接收具有NACK标识的第三类型包，则确定失败；或，所述压缩端接收具有ACK标识的第三类型包，以标识出成功；或，所述压缩端接收第三类型包，但第三类型包中不具有 ACK/NACK标识。

在本发明的一个实施例中，所述数据传输方法还包括：

步骤1104、当所述压缩端的上下文信息变更，或所述压缩端处于压缩状态CO第一时间长度后，所述压缩端从压缩状态CO转换到初始状态IR 或未压缩状态UC，并跳转到步骤1101或1101A或1101B。

在本发明的上述实施例中，该上下文信息变更发生在压缩端从初始状态IR或未压缩状态UC切换到压缩状态CO之后，也就是压缩端发送完第一预设数量的第一类型包之后，或是压缩端接收到解压缩端发送的反馈包之后。

在本发明的一个实施例中，所述数据传输方法还包括：

步骤1104A、压缩端发送触发指示以请求解压缩端返回反馈包；当压缩端确定解压缩端处理不成功时，所述压缩端从压缩状态CO转换到初始状态IR或未压缩状态UC，并跳转到步骤1101或1101A或1101B。

与前面实施例相同的，其中第一类型包为完整包(full packet)，第二类型包为压缩包(compressed packet)。其中，该第一状态可以为初始状态IR(initialization andRefresh)或未压缩状态UC(Uncompression)。其中，该第二状态可以为压缩状态CO(Compression order)。在本发明的一个实施例中，在步骤1104A中，该触发指示是由压缩端发送给解压缩端的用于请求反馈包的一个消息。当压缩端的上下文信息发生改变后，或是在压缩状态CO达到一定时间后，或是发送的触发指示得到的反馈包指示未能成功处理完整包和/或压缩包，则对解压缩端的上下文信息进行更新。此时压缩端重新切换到初始状态IR或未压缩状态UC，并重新执行步骤 1101-步骤1102或步骤1101A-步骤1102A或步骤1101B-步骤1102B的方法，重新发送上下文信息。在本发明的一个实施例中，该触发指示可以在前述的压缩包内发送，或是在前述的完整包内发送，或可以通过任何可能的信令发送。

具体的，所述压缩端发送触发指示以请求接收具有ACK/NACK标识的第三类型包；或，所述压缩端接收具有NACK标识的第三类型包；或，所述压缩端接收具有ACK标识的第三类型包；或，所述压缩端接收第三类型包，但第三类型包中不具有ACK/NACK标识。

即：在本发明的一个实施例中，所述解压缩端判断对第一类型包和/ 或第二类型包进行处理是否成功；如果成功则发送第三类型包；如果失败则将NACK标识添加到第三类型包中并发送。即：上述实施例中，如果压缩端接收到一个没有标识的第三类型包，则认为解压缩端处理成功了；如果压缩端接收到一个有NACK标识的第三类型包，则认为解压缩端处理失败了。

在本发明的一个实施例中，所述解压缩端判断对第一类型包和/或第二类型包进行处理是否成功；如果成功则步骤结束；如果失败则将NACK标识添加到第三类型包中并发送。即：上述实施例中，如果压缩端没有收到反馈包，则认为解压缩端处理成功了；如果压缩端接收到一个有NACK标识的第三类型包，则认为解压缩端处理失败了。

在本发明的一个实施例中，所述解压缩端判断对第一类型包和/或第二类型包进行处理是否成功；如果成功则将ACK标识添加到第三类型包中并发送；如果失败则步骤结束。即：上述实施例中，如果压缩端接收到一个有ACK标识的第三类型包，则认为解压缩端处理成功了；如果压缩端没有接收第三类型包，则认为解压缩端处理失败了。

在本发明的一个实施例中，所述解压缩端判断对第一类型包和/或第二类型包进行处理是否成功；如果失败则发送第三类型包；如果成功则不发送第三类型包。即：上述实施例中，如果压缩端接收到一个没有标识的第三类型包，则认为解压缩端处理成功了；如果压缩端接收到一个有NACK 标识的第三类型包，则认为解压缩端处理失败了。

当然，上面都只是举例说明，本发明实施例中可以包括很多种组合：

例如：第三类型包里一定有ACK/NACK标识。

例如：如果压缩端没有接收到第三类型包，则说明解压缩端处理成功了；相应的，如果接收到第三类型包，则无论第三类型包里是否包括标识都说明解压缩端处理失败了。

例如：如果压缩端没有接收到第三类型包，则说明解压缩端处理失败了；相应的，如果接收到第三类型包，则无论第三类型包里是否包括标识都说明解压缩端处理成功了。

例如：如果压缩端接收到无标识的第三类型包，则说明解压缩端处理成功了；相应的，如果接收到有标识(可以是ACK/NACK标识或是其他任意形式的标识)的第三类型包，则说明解压缩端处理失败了。

例如：如果压缩端接收到无标识的第三类型包，则说明解压缩端处理失败了；相应的，如果接收到有标识(可以是ACK/NACK标识或是其他任意形式的标识)的第三类型包，则说明解压缩端处理成功了。

在本发明的一个实施例中，反馈包(feedback packet)中至少包括上下文标识(Context ID)。在本发明的一个实施例中，其中上下文标识 (Context ID)用于标识出该反馈包对应的上下文，以使压缩端进行压缩和/或用于解压缩端进行解压缩。在本发明的一个实施例中，该反馈包中具有一个指示标识以指示解压缩端的反馈。在本发明的一个实施例中，该指示标识可以为ACK/NACK，以用于指示解压缩端的反馈。其中ACK用于指示所述解压缩端成功解压缩compressed packet，或所述解压缩端成功建立上下文，或所述解压缩端成功保存有效上下文；其中NACK用于指示所述解压缩端未能成功解压缩compressed packet，或所述解压缩端未能成功建立上下文，或所述解压缩端未能成功保存有效上下文。在本发明的一个实施例中，可以是解压缩端未能成功解压缩compressed packet、或未能成功建立上下文、或未能成功保存有效上下文时，才发送该具有NACK标识的反馈包；如果所述解压缩端成功解压缩compressed packet、或成功建立上下文、或成功保存有效上下文；则发送该具有ACK标识的反馈包，或是不发送反馈包。也就是说当压缩端未接收到任何反馈包时，该压缩端认为解压缩端已经成功解压缩compressed packet、或成功建立上下文、或成功保存有效上下文。

在发明的一个实施例中，上述的压缩包中还可以包括循环冗余校验 (CyclicRedundancy Check，CRC)，该CRC用于解压缩端在接收到压缩包后，根据压缩包中的CRC对压缩包进行校验以确定解压缩是成功和/或上下文是否有效。若确定解压缩失败和/或上下文无效，即CRC校验失败，解压缩端需要发送反馈包给压缩端。

在本发明的一个实施例中，所述数据传输方法如图4所示包括：

步骤2101、解压缩端接收第一类型包和/或第二类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；其中所述第二类型包内至少包括：压缩的以太网头的包头信息；

步骤2102、解压缩端根据接收到的第一类型包和/或第二类型包进行处理。

在本发明的一个实施例中，所述解压缩端在第三状态下接收第一类型包和/或第二类型包；且所述解压缩端根据对第一类型包和/或第二类型包进行处理，并在处理成功后切换到第四状态。

即所述方法如图5所示包括：

步骤2101A、解压缩端在第三状态下接收完整包和压缩包；其中所述完整包内至少包括：未压缩的以太网头的包头信息；其中所述压缩包内至少包括：压缩的以太网头的包头信息；

步骤2102A、解压缩端对接收到完整包和/或压缩包进行处理，并在成功处理后所述解压缩端从第三状态切换到第四状态。

在本发明的上述实施例中，其中，该第三状态可以为初始的无上下文状态NC(nocontext)；其中，第四状态可以为静态上下文状态SC(static context)或完全上下文状态FC(full context)。

进一步的，为了能够反馈处理成功，所述方法可以如图6所示具体包括：

步骤2101B、解压缩端在初始的无上下文状态NC下接收完整包和压缩包；其中所述完整包内至少包括：未压缩的以太网头的包头信息；其中所述压缩包内至少包括：压缩的以太网头的包头信息；

步骤2102B、解压缩端根据接收到完整包和压缩包进行处理，判断处理是否成功；如果处理失败，则发送第三类型包以反馈失败信息；如果处理成功，则发送第三类型包以反馈失败信息，且所述解压缩端从无上下文状态NC切换到静态上下文状态SC或完全上下文状态FC。

该第三类型包为反馈包(feedback packet)；该反馈包中至少包括上下文标识(Context ID)。其中上下文标识用于标识所属的上下文，以使压缩端进行压缩和/或用于解压缩端进行解压缩。在本发明的一个实施例中，该第三类型包中具有一个指示标识以指示解压缩端的反馈。在本发明的一个实施例中，该指示标识可以为ACK/NACK，以用于指示解压缩端的反馈。其中ACK用于指示所述解压缩端成功解压缩compressed packet，或所述解压缩端成功建立上下文，或所述解压缩端成功保存有效上下文；其中NACK用于指示所述解压缩端未能成功解压缩compressed packet，或所述解压缩端未能成功建立上下文，或所述解压缩端未能成功保存有效上下文。在本发明的一个实施例中，可以是解压缩端未能成功解压缩 compressed packet、或未能成功建立上下文、或未能成功保存有效上下文时，才发送该具有NACK标识的反馈包；如果所述解压缩端成功解压缩 compressed packet、或成功建立上下文、或成功保存有效上下文；则发送该具有ACK标识的反馈包，或是不发送反馈包。也就是说当压缩端未接收到任何反馈包时，该压缩端认为解压缩端已经成功解压缩compressed packet、或成功建立上下文、或成功保存有效上下文。

在本发明的一个实施例中，所述解压缩端判断对第一类型包和/或第二类型包进行处理是否成功；如果成功则发送第三类型包；如果失败则将 NACK标识添加到第三类型包中并发送。即：上述实施例中，如果压缩端接收到一个没有标识的第三类型包，则认为解压缩端处理成功了；如果压缩端接收到一个有NACK标识的第三类型包，则认为解压缩端处理失败了。

在本发明的一个实施例中，所述解压缩端判断对第一类型包和/或第二类型包进行处理是否成功；如果失败则发送第三类型包；如果成功则不发送第三类型包。即：上述实施例中，如果压缩端接收到一个没有标识的第三类型包，则认为解压缩端处理失败了；没收到就认为成功了。

在本发明的一个实施例中，所述解压缩端判断对第一类型包和/或第二类型包进行处理是否成功；如果成功则发送第三类型包；如果失败则不发送第三类型包。即：上述实施例中，如果压缩端接收到一个没有标识的第三类型包，则认为解压缩端处理成功了；没收到就认为失败了。

当然，上面都只是举例说明，本发明的所有实施例中都可以包括很多种组合来反馈处理结果：

例如：第三类型包里一定有ACK/NACK标识。

在本发明的一个实施例中，所述方法还包括上下文更新，即所述方法还包括：

步骤2103、当解压缩端在静态上下文状态SC或完全上下文状态FC 下再次接收到完整包和压缩包，所述解压缩端从静态上下文状态SC或完全上下文状态FC切换到无上下文状态NC，并跳转到步骤2102(或2102A 或2102B或2102C)。

其中步骤2103中解压缩端接收到的完整包和压缩包，是压缩端的上下文信息变更，或所述压缩端处于压缩状态CO第一时间长度后，或发送触发指示后，所述压缩端从压缩状态CO转换到初始状态IR或未压缩状态UC并发送的。这样可以保证压缩端和解压缩端数据的同步性。

在上述实施例中，如果反馈包feedback中是ACK标识时，该解压缩端从无上下文状态NC切换到静态上下文状态SC或完全上下文状态FC，即解压缩端已经得到了预定的上下文。而如果反馈包feedback中是NACK 标识时，该解压缩端维持在无上下文状态NC状态，即解压缩端没有得到预定的上下文，需要压缩端重新发送。

例如：第三类型包里一定有ACK/NACK标识。

在本发明的一个实施例中，前述的解压缩端对收到的第一类型包和第二类型包进行处理时的成功处理具体包括：解压缩端对压缩包进行解压缩成功，或解压缩端成功建立上下文，或解压缩端成功保存有效的上下文。当然，这些都只是举例说明，本领域内技术人员理解，对数据处理成功的方式可以包括很多种，本发明实施例中并不对此作出限定。

该第三类型包为反馈包(feedback packet)，该反馈包中至少包括上下文标识(Context ID)。其中上下文标识用于标识所属的上下文，以使压缩端进行压缩和/或用于解压缩端进行解压缩。在本发明的一个实施例中，该第三类型包中具有一个指示标识以指示解压缩端的反馈。在本发明的一个实施例中，该指示标识可以为ACK/NACK，以用于指示解压缩端的反馈。其中ACK用于指示所述解压缩端成功解压缩compressed packet，或所述解压缩端成功建立上下文，或所述解压缩端成功保存有效上下文；其中NACK用于指示所述解压缩端未能成功解压缩compressed packet，或所述解压缩端未能成功建立上下文，或所述解压缩端未能成功保存有效上下文。在本发明的一个实施例中，可以是解压缩端未能成功解压缩compressed packet、或未能成功建立上下文、或未能成功保存有效上下文时，才发送该具有NACK标识的反馈包；如果所述解压缩端成功解压缩 compressed packet、或成功建立上下文、或成功保存有效上下文；则发送该具有ACK标识的反馈包，或是不发送反馈包。也就是说当压缩端未接收到任何反馈包时，该压缩端认为解压缩端已经成功解压缩compressed packet、或成功建立上下文、或成功保存有效上下文。

在本发明的一个实施例中，基于上述的一些实施例，其压缩端和解压缩端协同工作的完整流程如图7所示的包括：

步骤101、压缩端在初始状态IR或未压缩状态UC下发送N个完整包；其中所述完整包内至少包括：未压缩的以太网头的包头信息；

步骤102、所述压缩端切换到压缩状态CO，并发送一个或多个压缩包；其中所述压缩包内至少包括：压缩的以太网头的包头信息；

其中所述完整包和/或压缩包还可以包括：上下文标识(Context ID) 和/或包类型标识符；进一步的还可以包括profile信息；其中上下文标识等上下文信息用于压缩端进行压缩和/或用于解压缩端进行解压缩；

步骤103、解压缩端在初始的无上下文状态NC下接收该完整包和/或压缩包后，对该完整包和/或压缩包进行处理，并根据处理结果进行反馈；如果处理成功，则解压缩端切换到静态上下文状态SC或完全上下文状态 FC，步骤结束；如果处理失败，则解压缩端维持在无上下文状态NC状态，并重新接收压缩端发送的完整包和/或压缩包；其中处理成功是指所述解压缩端成功解压缩所述压缩包，或所述解压缩端成功建立上下文，或所述解压缩端成功保存有效上下文。

本发明的所有实施例中都可以包括很多种组合来反馈处理结果：

例如：第三类型包里一定有ACK/NACK标识。

进一步的，该方法还包括上下文更新流程，即所述方法如图8所示还包括：

步骤104、当所述压缩端的上下文信息变更，或所述压缩端处于压缩状态CO第一时间长度后，或发送触发指示请求接收带有处理结果的反馈包后确定解压缩端未能成功处理完整包和/或压缩包，所述压缩端从压缩状态CO切换到初始状态IR或未压缩状态UC，压缩端在初始状态IR或未压缩状态UC下发送完整包；

步骤105、当解压缩再次接收到完整包时，所述解压缩端从静态上下文状态SC或完全上下文状态FC切换到无上下文状态NC，并跳转到步骤 101。

同样的，可以包括很多种组合来反馈处理结果，在此不再赘述。

实施例2

在本发明的一个实施例中，提出了一种数据传输方法如图9所示的包括：

步骤1201、压缩端发送第二类型包；其中所述第一类型包内至少包括：压缩的以太网头的包头信息；

步骤1202、在接收到反馈的第三类型包后，并发送第一类型包；其中所述第二类型包内至少包括：未压缩的以太网头的包头信息。

在本发明的另一个实施例中，提出了一种数据传输方法如图10所示的包括：

步骤1301、压缩端发送第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

步骤1302、在接收到反馈的第三类型包后，并发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息。

该第三类型包为反馈包(feedback packet)，该反馈包中至少包括上下文标识(Context ID)和/或包类型标识符。在本发明的一个实施例中，其中上下文标识用于标识所属的上下文，以使压缩端进行压缩和/或用于解压缩端进行解压缩。在本发明的一个实施例中，该第三类型包中具有一个指示标识以指示解压缩端的反馈。在本发明的一个实施例中，该指示标识可以为ACK/NACK，以用于指示解压缩端的反馈。其中ACK用于指示所述解压缩端成功收到full packet，或所述解压缩端成功建立上下文，或所述解压缩端成功保存有效上下文；其中NACK用于指示所述解压缩端未能成功收到full packet，或所述解压缩端未能成功建立上下文，或所述解压缩端未能成功保存有效上下文。在本发明的一个实施例中，可以是解压缩端未能成功收到full packet、或未能成功建立上下文、或未能成功保存有效上下文时，发送该具有NACK标识的反馈包，或不发送反馈包；如果所述解压缩端成功收到fullpacket、或成功建立上下文、或成功保存有效上下文，则发送反馈包(没有A/N标识)，或发送具有ACK标识的反馈包。也就是说当压缩端未接收到任何反馈包，或收到具有NACK标识的反馈包时，继续发生full packet，收到反馈包时或具有ACK标识的反馈包，该压缩端认为解压缩端已经收到full packet、或成功建立上下文、或成功保存有效上下文。

在本发明的一个实施例中，提出了一种数据传输方法如图11所示的包括：

步骤1201A、压缩端在第一状态下发送第二类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

步骤1202B、在接收到反馈的第三类型包后，所述压缩端切换到第二状态，并发送第而类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息。

在本发明的另一个实施例中，提出了一种数据传输方法如图12所示包括：

步骤1301、压缩端在第二状态下发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息；

步骤1302、在接收到反馈的第三类型包后，所述压缩端切换到第一状态，并发送第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信。

在本发明的一个实施例中，该第一状态可以为初始状态IR

例如：反馈包里一定有ACK/NACK标识。

例如：如果压缩端没有接收到反馈包，则说明解压缩端处理成功了；相应的，如果接收到反馈包，则无论反馈包里是否包括标识都说明解压缩端处理失败了。

例如：如果压缩端没有接收到反馈包，则说明解压缩端处理失败了；相应的，如果接收到反馈包，则无论反馈包里是否包括标识都说明解压缩端处理成功了。

例如：如果压缩端接收到无标识的反馈包，则说明解压缩端处理成功了；相应的，如果接收到有标识(可以是ACK/NACK标识或是其他任意形式的标识)的反馈包，则说明解压缩端处理失败了。

例如：如果压缩端接收到无标识的反馈包，则说明解压缩端处理失败了；相应的，如果接收到有标识(可以是ACK/NACK标识或是其他任意形式的标识)的反馈包，则说明解压缩端处理成功了。

在本发明的又一个实施例中，前述的解压缩端对收到的第一类型包和第二类型包进行处理时的成功处理具体包括：解压缩端对压缩包进行解压缩成功，或解压缩端成功建立上下文，或解压缩端成功保存有效的上下文。当然，这些都只是举例说明，本领域内技术人员理解，对数据处理成功的方式可以包括很多种，本发明实施例中并不对此作出限定。

在本发明的一个实施例中，可以是在发送完完整包并在接收到反馈包后发送压缩包，也可以是发送完整包时只要接收到反馈包就马上发送压缩包。

即本发明的一个实施例如图13所示的具体包括：

步骤1301A、压缩端在初始状态IR或未压缩状态UC下，发送第一预设数量的完整包；其中所述完整包内至少包括：未压缩的以太网头的包头信息；

步骤1302A、在发送完第一数量的完整包并在接收到反馈包后，所述压缩端切换到压缩状态CO，并发送压缩包；其中所述压缩包内至少包括：压缩的以太网头的包头信息；其中所述反馈包内至少包括：上下文标识 (Context ID)。

或所述方法如图14具体包括：

步骤1301B、压缩端在初始状态IR或未压缩状态UC下，发送完整包；其中所述完整包内至少包括：未压缩的以太网头的包头信息；

步骤1302B、在接收到反馈包后，所述压缩端切换到压缩状态CO，并发送压缩包；其中所述压缩包内至少包括：压缩的以太网头的包头信息；其中所述反馈包内至少包括：上下文标识(Context ID)。

即，所述步骤1302A和步骤1302B的差别在于，压缩端是发送完预定数量的完整包并接收到反馈包后才发送压缩包；还是压缩端无论发送了多少完整包，只要接收到反馈包就开始发送压缩包。

进一步的，该方法还包括上下文更新流程，即所述方法还包括：

步骤1303、当所述压缩端的上下文信息变更，或所述压缩端处于压缩状态CO第一时间长度后，所述压缩端从压缩状态CO转换到初始状态IR 或未压缩状态UC，并跳转到步骤1301或1301A。

在本发明的一个实施例中，在步骤1303中，当压缩端的上下文信息发生改变后，或是达到一定时间后，则对解压缩端的上下文信息进行更新。此时压缩端重新切换到初始状态IR或未压缩状态UC，并重新执行步骤 1301-步骤1302或步骤1301A-步骤1302A的方法，重新发送上下文信息。

在本发明的一个实施例中，提出了一种数据传输方法如图15所示包括：

步骤2301、解压缩端在接收第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

步骤2302、解压缩端发送第三类型包以反馈对所述第一类型包的接收和/或处理结果，所述第三类型包中至少包括上下文标识(Context ID)；

步骤2303、解压缩端接收第二类型包，其中所述第二类型包中至少包括：压缩的以太网头的包头信息。

该第三类型包为反馈包(feedback packet)；该反馈包中至少包括上下文标识(Context ID)和/或包类型标识符。在本发明的一个实施例中，其中上下文标识用于标识所属的上下文，以使压缩端进行压缩和/或用于解压缩端进行解压缩。在本发明的一个实施例中，该第三类型包中具有一个指示标识以指示解压缩端的反馈。在本发明的一个实施例中，该指示标识可以为ACK/NACK，以用于指示解压缩端的反馈。其中ACK用于指示所述解压缩端成功收到full packet，或所述解压缩端成功建立上下文，或所述解压缩端成功保存有效上下文；其中NACK用于指示所述解压缩端未能成功收到full packet，或所述解压缩端未能成功建立上下文，或所述解压缩端未能成功保存有效上下文。在本发明的一个实施例中，可以是解压缩端未能成功收到full packet、或未能成功建立上下文、或未能成功保存有效上下文时，发送该具有NACK标识的反馈包，或不发送反馈包；如果所述解压缩端成功收到fullpacket、或成功建立上下文、或成功保存有效上下文，则发送反馈包(没有A/N标识)，或发送具有ACK标识的反馈包。也就是说当压缩端未接收到任何反馈包，或收到具有NACK标识的反馈包时，继续发生full packet，收到反馈包时或具有ACK标识的反馈包，该压缩端认为解压缩端已经收到full packet、或成功建立上下文、或成功保存有效上下文。

在本发明的一个实施例中，提出了一种数据传输方法包括：

步骤2301A、解压缩端在第一状态下接收完整包；其中所述完整包内至少包括：未压缩的以太网头的包头信息；

步骤2302A、解压缩端发送反馈包以反馈对所述完整包的接收和/或处理结果，所述反馈包中至少包括上下文标识(Context ID)；

步骤2303A、解压缩端接收压缩包，其中所述压缩包至少包括：压缩的以太网头的包头信息。

在一个实施例中，上述方法还包括：解压缩端根据接收到的完整包和 /或压缩包进行处理；如果处理成功则，则解压缩端切换到第四状态；如果处理失败，则在第三状态下重新接收完整包和/或压缩包。

在本发明的实施例中，该解压缩端切换到第四状态可以在上述步骤 2301A-2303A之间的任何时间点；只要解压缩端确认对完整包和/或压缩包进行处理成功，则解压缩端切换到第四状态。本发明所有实施例中都不对解压缩端切换到第四状态的时间点进行限定。

在本发明的上述实施例中，其中，该第三状态可以为初始的无上下文状态NC(nocontext)；其中，第四状态可以为静态上下文状态SC(static context)或完全上下文状态FC(full context)。即，所述方法具体包括；

步骤2301B、解压缩端在无上下文状态NC下接收完整包；其中所述完整包至少包括：未压缩的以太网头的包头信息；

步骤2302B、解压缩端发送反馈包以反馈对所述完整包的接收和/或处理结果，所述反馈包中至少包括上下文标识(Context ID)；

步骤2303B、解压缩端接收压缩包，其中所述压缩包中至少包括：压缩的以太网头的包头信息。

在一个实施例中，上述方法还包括：解压缩端根据接收到的完整包和 /或压缩包进行处理；如果处理成功，则解压缩端切换到第四状态；如果处理失败，则在第三状态下重新接收完整包和/或压缩包。

在本发明的实施例中，该解压缩端切换到第四状态可以在上述步骤 2301B-2303B之间的任何时间点；只要解压缩端确认对完整包和/或压缩包进行处理成功，则解压缩端切换到第四状态。本发明所有实施例中都不对解压缩端切换到第四状态的时间点进行限定。

在上述实施例，该反馈包中可以包括用于标识结果的ACK/NACK标识符，也可以不包括该ACK/NACK标识符。即本发明的所有实施例中都可以包括很多种组合来反馈处理结果：

例如：第三类型包里一定有ACK/NACK标识。

进一步的，该方法还包括上下文更新流程，即所述方法在步骤2305 或2305A之后还包括：

步骤2306、当解压缩端在静态上下文状态SC或完全上下文状态FC 下再次接收到完整包和/或压缩包后，将所述解压缩端切换到无上下文状态 NC，并重新接收完整包和/或压缩包。

其中步骤2306中解压缩端接收到的完整包和压缩包，是压缩端的上下文信息变更，或所述压缩端处于压缩状态CO第一时间长度后，所述压缩端从压缩状态CO转换到初始状态IR或未压缩状态UC并发送的。这样可以保证压缩端和解压缩端数据的同步性。

其中，该上下文更新流程还可以为：

步骤2306A、解压缩端在接收到的触发请求时，发送反馈包；所述反馈包中包括用于标识对完整包和/或压缩包进行处理是否成功的标识；如果失败时该解压缩端维持在无上下文状态NC状态，并重新接收完整包和/ 或压缩包；如果成功时，所述解压缩端从无上下文状态NC切换到静态上下文状态SC或完全上下文状态FC。

其中步骤2306和步骤2306A中解压缩端接收到的完整包和压缩包，是压缩端的上下文信息变更，或所述压缩端处于压缩状态CO第一时间长度后，所述压缩端从压缩状态CO转换到初始状态IR或未压缩状态UC并发送的。这样可以保证压缩端和解压缩端数据的同步性。或，步骤2306A 中解压缩端接收到的完整包和压缩包，是在压缩端发送了一个用于请求反馈包的触发指示后，在接收到的解压缩端基于该出发请求发送的反馈包中显示解压缩端对前一次发送的完整包和/或压缩包进行处理不成功时，压缩端重新发送的完整包和/或压缩包。在上述实施例中，如果反馈包feedback 中是ACK标识时，该解压缩端从无上下文状态NC切换到静态上下文状态SC或完全上下文状态FC，即解压缩端已经得到了预定的上下文。而如果反馈包feedback中是NACK标识时，该解压缩端维持在无上下文状态 NC状态，即解压缩端没有得到预定的上下文，需要压缩端重新发送。

当然，也可以先接收压缩包后接收完整包，其流程可参考前述实施例，在此不再赘述。

在本发明的一个实施例中，基于上述的一些实施例，其压缩端和解压缩端协同工作的完整流程如图16所示的包括：

步骤201、压缩端在初始状态IR或未压缩状态UC下，发送完整包；其中所述完整包至少包括：未压缩的以太网头的包头信息；

步骤202、解压缩端在无上下文状态NC下接收完整包；其中所述完整包至少包括：未压缩的以太网头的包头信息；

步骤203、解压缩端发送反馈包以反馈对所述完整包的接收和/或处理结果，所述反馈包中至少包括上下文标识(Context ID)；该反馈包中可以包括用于标识结果的ACK/NACK标识符，也可以不包括该ACK/NACK 标识符；

步骤204、压缩端在发送完第一预设数量的完整包并在接收到反馈包后，或压缩端发送完整包时接收到反馈包后，所述压缩端切换到压缩状态 CO，并发送压缩包；其中所述压缩包内至少包括：压缩的以太网头的包头信息；

步骤205、解压缩端在接收到完整包和压缩包后，发送反馈包以反馈对所述完整包和压缩包的接收和/或处理结果，所述反馈包中至少包括上下文标识；该反馈包中可以包括用于标识结果的ACK/NACK标识符，也可以不包括该ACK/NACK标识符。

当然，也可以先发送压缩包后发送完整包，其流程可参考前述实施例，在此不再赘述。

进一步的，该方法还包括上下文更新流程，即所述方法如图17所示还包括：

步骤206、当所述压缩端的上下文信息变更，或所述压缩端处于压缩状态CO第一时间长度后，或发送触发指示得到的反馈包确定解压缩端未能成功处理完整包和/或压缩包，所述压缩端从压缩状态CO切换到初始状态IR或未压缩状态UC，压缩端在初始状态IR或未压缩状态UC下发送完整包；

步骤207、当解压缩端再次接收到完整包时，所述解压缩端从静态上下文状态SC或完全上下文状态FC切换到无上下文状态NC，并跳转到步骤201。

在本发明的另一个实施例中，基于上述的一些实施例，其压缩端和解压缩端协同工作的完整流程可以为：

步骤201A、压缩端在压缩状态CO下发送压缩包；其中所述压缩包内至少包括：压缩的以太网头的包头信息；

步骤202A、解压缩端在无上下文状态NC下接收压缩包；其中所述完整包至少包括：未压缩的以太网头的包头信息；

步骤203A、解压缩端发送反馈包以反馈对所述压缩包的接收和/或处理结果，所述反馈包中至少包括上下文标识(Context ID)；该反馈包中可以包括用于标识结果的ACK/NACK标识符，也可以不包括该 ACK/NACK标识符；

步骤204A、压缩端切换到初始状态IR或未压缩状态UC下，发送完整包；其中所述完整包至少包括：未压缩的以太网头的包头信息；

步骤205A、解压缩端在接收到完整包和压缩包后，发送反馈包以反馈对所述完整包和压缩包的接收和/或处理结果，所述反馈包中至少包括上下文标识；该反馈包中可以包括用于标识结果的ACK/NACK标识符，也可以不包括该ACK/NACK标识符。

步骤206A、当所述压缩端的上下文信息变更，或所述压缩端处于压缩状态CO第一时间长度后，或发送触发指示得到的反馈包确定解压缩端未能成功处理完整包和/或压缩包，所述压缩端发送压缩包；

步骤207A、当解压缩端再次接收到完整包时，所述解压缩端从静态上下文状态SC或完全上下文状态FC切换到无上下文状态NC，并跳转到步骤201A。

例如：第三类型包里一定有ACK/NACK标识。

实施例3

在本发明的一个实施例中，当所述压缩端与解压缩端通过单向链路或是没有反向链路连接时(例如，sidelink，multi-case，当DRB是配置单向无线链路控制(Radio LinkControl，RLC)的非确认模式(unacknowledged mode，UM)下时)，提出了一种数据传输方法如图18所示的包括：

步骤1401、压缩端在通过单向链路发送第一预设数量的第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

步骤1402、当发送完第一预设数量的第一类型包后，发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息。

在本发明的一个实施例中，压缩端可以在第一状态下发送第一类型包，在第二状态下发送第二类型包。即所述方法如图19所示的具体包括：

步骤1401A、压缩端在初始状态IR或未压缩状态UC下，通过单向链路发送第一预设数量的完整包；其中所述完整包内至少包括：未压缩的以太网头的包头信息；

步骤1402、当发送完第一预设数量的第一类型包后，压缩端切换到第二状态并发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息。

其中，该第一状态可以为初始状态IR(initialization and Refresh)或未压缩状态UC(Uncompression)。其中，该第二状态可以为压缩状态CO (Compression order)。即所述方法包括：

步骤1401B、压缩端在初始状态IR或未压缩状态UC下，通过单向链路发送第一预设数量的完整包；其中所述完整包内至少包括：未压缩的以太网头的包头信息；

步骤1402B、在发送完第一数量的完整包后，所述压缩端从初始状态 IR或未压缩状态UC切换到压缩状态CO，并发送压缩包；其中所述压缩包内至少包括：压缩的以太网头的包头信息。

在本发明的一个实施例中，所述方法还上下文更新机制，即在所述步骤1402或1402A或1402B之后还包括：

步骤1403、当所述压缩端的上下文信息变更，或所述压缩端处于压缩状态CO第一时间长度后，所述压缩端从压缩状态CO转换到初始状态IR 或未压缩状态UC，并跳转到步骤1401或1401A或1401B。

在本发明的一个实施例中，在步骤1403中，当压缩端的上下文信息发生改变后，或是达到一定时间后，则对压缩端的上下文信息进行更新；此时的上下文信息可以和前次一样，也可以和前次不一样。此时压缩端重新切换到初始状态IR或未压缩状态UC，并重新执行步骤1401-步骤1402 或步骤1401A-步骤1402A的方法，重新发送上下文信息。

在本发明的上述实施例中，该上下文信息变更发生在压缩端从初始状态IR或未压缩状态UC切换到压缩状态CO之后，也就是压缩端发送完第一预设数量的第一类型包之后，或状态转换后。

在本发明的一个实施例中，所述数据传输方法如图20所示的包括：

步骤2401、解压缩端在第三状态下，通过单向链路接收第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

步骤2402、解压缩端在接收到M个第一类型包后，所述解压缩端切换到第四状态。

进一步的，所述方法还包括：

步骤2403、解压缩端接收第二类型包，所述第二类型包至少包括：未压缩的以太网头的包头信息。

在本发明的实施例中，该解压缩端切换到第四状态可以在上述步骤的任何时间点；只要解压缩端确认对完整包和/或压缩包进行处理成功，则解压缩端切换到第四状态。本发明所有实施例中都不对解压缩端切换到第四状态的时间点进行限定。

在本发明的上述实施例中，其中，该第三状态可以为初始的无上下文 NC(nocontext)；其中，第四状态可以为静态上下文状态SC(static context) 或完全上下文状态FC(full context)。

在本发明的一个实施例中，前述的解压缩端对收到的第一类型包进行处理时的成功处理具体包括：解压缩端成功接收至少一个full packet，或解压缩端成功建立上下文，或解压缩端成功保存有效的上下文。当然，这些都只是举例说明，本领域内技术人员理解，对数据处理成功的方式可以包括很多种，本发明实施例中并不对此作出限定。

即所述方法具体包括：

步骤2401A、解压缩端在无上下文NC下通过单向链路接收完整包；其中所述完整包内至少包括：未压缩的以太网头的包头信息；步骤2402A、解压缩端根据接收到完整包进行处理，并在成功处理后所述解压缩端从无上下文NC切换到静态上下文状态SC或完全上下文状态FC。

进一步的，所述方法还包括；

步骤2403A、解压缩端接收第二类型包，所述第二类型包至少包括：未压缩的以太网头的包头信息。

由于是单向链路，因此本发明的这一实施例中没有反馈机制。

在本发明的一个实施例中，所述数据传输方法还上下文更新，即所述方法在步骤2402或2402A之后包括：

步骤2404、当解压缩端在且静态上下文状态SC或完全上下文状态FC 下再次接收到完整包，所述解压缩端从静态上下文状态SC或完全上下文状态FC切换到无上下文NC，并跳转到步骤2401或2401A。

其中步骤2404中解压缩端接收到的完整包和/或压缩包，是压缩端的上下文信息变更，或所述压缩端处于压缩状态CO第一时间长度后，或发送触发指示后，所述压缩端从压缩状态CO转换到初始状态IR或未压缩状态UC并发送的。这样可以保证压缩端和解压缩端数据的同步性。

在本发明的一个实施例中，基于上述的一些实施例，其压缩端和解压缩端协同工作的完整流程如图21所示的具体包括：

步骤301、压缩端在初始状态IR或未压缩状态UC下通过单向链路发送N个完整包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；完整包还可以包括：上下文标识(Context ID)和/或包类型标识符；

步骤302、当发送完N个完整包后，所述压缩端从初始状态IR或未压缩状态UC切换到压缩状态CO，并通过单向链路发送一个或多个压缩包；其中所述压缩包内至少包括：压缩的以太网头的包头信息；

步骤303、解压缩端在初始的无上下文状态NC下通过单向链路接收该完整包后，对该完整包和压缩包进行处理；如果处理成功，则解压缩端切换到静态上下文状态SC或完全上下文状态FC。

进一步的，该方法还包括上下文更新流程，即所述方法如图22还包括：

步骤304、当所述压缩端的上下文信息变更，或所述压缩端处于压缩状态CO第一时间长度后，所述压缩端从压缩状态CO切换到初始状态IR 或未压缩状态UC，压缩端在初始状态IR或未压缩状态UC下通过单向链路发送完整包；

步骤305、当解压缩通过单向链路再次接收到完整包时，所述解压缩端从静态上下文状态SC或完全上下文状态FC切换到无上下文状态NC，以重新接收完整包。

实施例4

在本发明的一个实施例中，提出了一种数据传输方法，包括：

-压缩端初始状态为IR(initialization and Refresh)或未压缩状态UC(Uncompression)。解压缩端初始状态为NC(no context)。

-压缩端发送N个full packet后，即发送compressed packet。相应的，压缩端的状态从IR或UC转换到压缩状态CO(Compression order)。其中，N可以是网络配置，也可以是压缩端自行确定的。

-当解压缩端成功解压缩compressed packet后或者建立上下文后或者保存有效上下文后，解压缩端可以发送feedback packet，也可以不发送 feedback packet。相应的，解压缩端的状态从NC转换为静态上下文状态 SC(static context)或完全上下文状态FC(full context)。其中，feedback packet中至少携带context ID，可以携带ACK/NACK(此情况下取值或指示为ACK)，也可不携带ACK/NACK。

-当解压缩端解压缩compressed packet失败后或者未成功建立上下文后或者未保存有效上下文后，解压缩端发送feedback packet。相应的，解压缩端状态不转换。其中，feedback packet中至少携带context ID，可以携带ACK/NACK(此情况下取值或指示为NACK)，也可不携带ACK/NACK (当上一条，成功建立时不发送feedback packet)。相应的，压缩端收到该feedback packet后，重新发送full packet，对应的压缩端状态从CO转换到IR或UC。

-当上下文信息变更时或处于CO状态第一时间后或发送触发指示后，处于CO状态的压缩端重新发送full packet，相应的状态从CO转换到IR或UC。

-当处于SC或FC状态的解压缩端再次收到M个full packet时(M>＝1， M<N)或收到触发指示后，解压缩端状态从SC或FC转换为NC，解压缩端需要更新上下文。

在本发明的一个实施例中，压缩端可以为终端设备UE，解压缩端可以为基站。当然，这只是为了举例说明，而非对本发明实施例的一个限定。在本发明实施例中，压缩端和解压缩端可以为任何设备。

本发明实施例的流程可以为：

1、t1时刻UE处于压缩端初始状态为IR或UC状态。gNB处于NC 状态。

2、从t2时刻起，UE开始发送full packet。当UE发送N个full packet 后(t3时刻)，UE开始发送compressed packet。相应的，UE的压缩状态从IR或UC转换到压缩状态CO。其中，N可以是网络配置，也可以是压缩端自行确定的。

3、t4时刻，基站未成功解压缩compressed packet，基站发送feedback packet。相应的，基站的解压缩状态不转换。其中，feedback packet中携带context ID，ACK/NACK(此情况下取值或指示为NACK)。

4、t5时刻，UE收到feedback packet，确认解压缩未成功。UE的压缩状态从CO转换到IR或UC，重新发送full packet。在发送N个full packet 后(t6时刻)后，UE开始发送compressed packet。

5、t7时刻，基站成功解压缩compressed packet。基站的解压缩状态从NC转换到SC或FC。

t8时刻，发生上下文信息变更情况。UE状态从CO转换到IR或UC，重选发送fullpacket。

6、t9时刻，基站又收到full packet，基站状态从SC或FC转为NC，认为上下文需要更新。

7、t10时刻，UE已发送N个full packet，UE开始发送compressed packet。相应的状态从CO转换到IR或UC。

8、t11时刻，基站成功解压缩compressed packet。基站的解压缩状态从NC转换到SC或FC。

实施例5

在本发明实施例还提出了一种数据传输方法；其中压缩端发送full packet且收到feedback packet后发送compressed packet。在上下文更新时，重新发送full packet。本发明实施例的流程具体为：

-压缩端发送full packet且收到feedback packet后，发送compressed packet(或者，也可是发送K个full packet且收到feedback packet后，发送compressed packet)。相应的，压缩端的状态从IR或UC转换到压缩状态CO(Compression order)。

-当解压缩端建立上下文后或者保存有效上下文后，解压缩端可以发送 feedbackpacket。相应的，解压缩端的状态从NC转换为静态上下文状态 SC(static context)或完全上下文状态FC(full context)。其中，feedback packet中至少携带context ID，可以携带ACK/NACK(此情况下取值或指示为ACK)，也可不携带ACK/NACK。

-当处于SC或FC状态的解压缩端再次收到M个full packet时(M>＝1) 或收到触发指示后，解压缩端状态从SC或FC转换为NC，解压缩端需要更新上下文。

本发明实施例的流程可以为：

2、从t2时刻起，UE开始发送full packet。

3、t3时刻，基站收到full packet，在建立上下文后，基站发送feedback packet。基站的解压缩的状态从NC转换为SC或FC。其中，feedback packet 中携带context ID，可不携带ACK/NACK。

4、t4时刻UE收到feedback packet，UE状态转换从IR或UC到CO，开始发送compressed packet。

5、t5时刻，发生上下文信息变更情况。UE状态从CO转换到IR或 UC，重选发送fullpacket。

6、t6时刻，基站又收到full packet，基站状态从SC或FC转为NC，认为上下文需要更新。

7、t7时刻，基站建立新的上下文，发送feedback packet，基站的解压缩状态从NC转换到SC或FC。

8、t8时刻，UE收到feedback packet，UE状态转换从IR或UC到 CO，开始发送compressed packet。

实施例6

在本发明实施例还提出了一种数据传输方法；其中压缩端通过单向链路连接解压缩端。本发明实施例的方法具体包括：

-当解压缩端收到N个full packet后或者建立上下文后或者保存有效上下文后，解压缩端的状态从NC转换为静态上下文状态SC(static context) 或完全上下文状态FC(full context)。

本发明实施例的流程可以为：

3、t4时刻，基站收到N个full packet，基站认为上下文建立成功。基站的解压缩状态从NC转换到SC或FC。

4、t5时刻，发生上下文信息变更情况。UE状态从CO转换到IR或 UC，重选发送fullpacket。

5、t6时刻，基站又收到full packet，基站状态从SC或FC转为NC，认为上下文需要更新。

6、t7时刻，UE已发送N个full packet，UE开始发送compressed packet。相应的状态从CO转换到IR或UC。

7、t8时刻，基站收到N个full packet，基站认为上下文更新成功。基站的解压缩状态从NC转换到SC或FC。

实施例7

本发明实施例提出了一种数据传输装置，设置于压缩端，如图23所示的包括：

在本发明的一个实施例中，所述第一发送模块在第一状态下发送所述第一类型包；且所述第二发送模块在第二状态下发送所述第二类型包。

在本发明的一个实施例中，所述第一状态为初始状态或未压缩状态；和/或，所述第二状态为压缩状态。

在本发明的一个实施例中，所述第一类型包和/或第二类型包还包括：上下文标识和/或包类型标识符；

在本发明的一个实施例中，所述第一类型包为完整包；和/或，所述第二类型包为压缩包。

在本发明的一个实施例中，所述装置还包括：

在本发明的一个实施例中，所述装置还包括接收模块，所述接收模块用于执行以下操作：

发送触发指示以请求接收具有ACK/NACK标识的第三类型包；

或

接收具有NACK标识的第三类型包；

或

接收具有ACK标识的第三类型包；

或

接收第三类型包，所述第三类型包中不具有ACK/NACK标识。

在本发明的一个实施例中，所述装置还包括切换模块，所述切换模块用于执行以下操作：

在本发明的一个实施例中，所述第一发送模块用于执行以下操作：

在本发明的一个实施例中，所述装置执行以下操作：

所述第一发送模块发送所述第一类型包；

或

所述第一发送模块发送第一预设数量的所述第一类型包；

在本发明的一个实施例中，所述第三类型包中至少包括上下文标识；其中所述上下文标识用于标识所述第三类型包所对应的上下文。

在本发明的一个实施例中，所述第三类型包中包括ACK/NACK标识，所述ACK/NACK标识用于指示接收所述第一类型包和所述第二类型包的接收端对所述第一类型包和/或所述第二类型包的处理结果，或者，指示解压缩端的上下文信息是否保存。

在本发明的一个实施例中，所述压缩端通过单向链路发送所述第一类型包和所述第二类型包。

在本发明的一个实施例中，所述第二类型包内具有循环冗余校验。

本领域内技术人员可以理解，本发明上述实施例的装置用于执行前述的所有实施例中的方法，因此相应的内容不再赘述，请参见实施例。

本发明实施例还提出了一种数据传输装置，设置于解压缩端，如图24 所示的包括：

在本发明的一个实施例中，所述第一接收模块，在第三状态下接收所述第一类型包和/或所述第二类型包。

在本发明的一个实施例中，所述处理模块用于对所述第一类型包或所述第二类型包进行处理，并在处理成功后切换到第四状态。

在本发明的一个实施例中，所述第三状态为无上下文状态；和/或，所述第四状态为静态上下文状态或完全上下文状态。

在本发明的一个实施例中，所述第一类型包和/或所述第二类型包还包括：上下文标识和/或包类型标识符；

其中所述上下文标识用于标识所述第一类型包和/或所述第二类型包所对应的上下文，其中所述包类型标识用于标识该包为所述第一类型包或所述第二类型包。

在本发明的一个实施例中，所述第一接收模块还用于执行以下操作：

在本发明的一个实施例中，所述处理模块还用于执行以下操作：

在本发明的一个实施例中，所述处理模块还用于在执行以下操作：

如果成功则发送第三类型包；

如果失败则不发送所述第三类型包。

如果失败则发送第三类型包；

如果成功则不发送所述第三类型包。

在本发明的一个实施例中，第三类型包中至少包括上下文标识；其中所述上下文标识用于标识所述第三类型包所对应的上下文。

在本发明的一个实施例中，所述第一接收模块用于执行以下操作：

接收所述第一类型包；

发送第三类型包以请求接收所述第二类型包；

接收所述第二类型包。

接收所述第二类型包；

发送第三类型包以请求接收所述第一类型包；

接收所述第一类型包。

在本发明的一个实施例中，所述解压缩端通过单向链路接收所述第一类型包和所述第二类型包。

在本发明的一个实施例中，所述装置还包括发送模块；

如果所述第三类型包内的标识为所述ACK标识时，所述解压缩端从所述第三状态转换到所述第四状态。

在本发明的一个实施例中，所述解压缩端根据所述第二类型包中的循环冗余校验，用于确定解压缩是否成功和/或上下文是否有效。

本发明实施例还提出了一种数据传输系统，如图25所示的包括压缩端和解压缩端：

解压缩端在第三状态下接收所述该第一类型包；

在本发明的一个实施例中，所述系统中：

在本发明的一个实施例中，所述第二类型包内具有循环冗余校验，用于确定解压缩是否成功和/或上下文是否有效。

本发明实施例还提出了一种数据传输系统，包括压缩端和解压缩端：

解压缩端在第三状态下接收所述第一类型包；

所述压缩端在发送第一预设数量的所述第一类型包并接收到所述解压缩端发送的所述第三类型包后，或所述压缩端发送所述第一类型包并接收到所述解压缩端发送的所述第三类型包后，或所述压缩端发送所述第一类型包并接收到所述解压缩端发送的包括ACK标识的第三类型包后，所述压缩端切换到第二状态，并发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息。

在本发明的一个实施例中，所述解压缩端在接收到所述第一类型包后，发送所述第三类型包以反馈对所述第一类型包的接收和/或处理结果，所述第三类型包中至少包括上下文标识；其中所述上下文标识用于标识所述第三类型包所对应的上下文。

在本发明的一个实施例中，所述系统中：

或

在本发明的一个实施例中，所述系统中：

当所述解压缩端再次接收到所述第一类型包时，所述解压缩端从第四状态切换到所述第三状态。

在本发明的一个实施例中，所述单向链路包括为以下至少一种：

配置了um-Uni-Directional-UL的链路；

配置了um-Uni-Directional-DL的链路；

multi-cast；或

sidelink。

在本发明的所有实施例中，压缩端可以为任意设备或任意虚拟设备 (例如虚拟机)或任意程序，且解压缩端可以为任意设备或任意虚拟设备 (例如虚拟机)或任意程序。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，可以仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对相关技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种数据传输方法，其特征在于，包括：

当发送完所述N个第一类型包后，所述压缩端不需要接收解压缩端发送的反馈信息而直接从所述第一状态切换到第二状态并发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息；所述第一状态为初始状态或未压缩状态，所述第二状态为压缩状态；

所述方法还包括：

当所述压缩端处于所述第二状态第一时间长度后，所述压缩端从所述第二状态转换到所述第一状态，并再次发送所述第一类型包。

2.根据权利要求1所述的数据传输方法，其特征在于，所述第一类型包和/或所述第二类型包还包括：上下文标识和/或包类型标识符；

3.根据权利要求1或2所述的数据传输方法，其特征在于，所述第一类型包为完整包；和/或，所述第二类型包为压缩包。

4.根据权利要求1或2所述的数据传输方法，其特征在于，所述第二类型包内具有循环冗余校验。

5.一种数据传输装置，设置于压缩端，其特征在于，包括：

第一发送模块，用于在第一状态下发送第一类型包；其中所述第一类型包内至少包括：未压缩的以太网头的包头信息；

第二发送模块，用于在第二状态下发送第二类型包；其中所述第二类型包内至少包括：压缩的以太网头的包头信息；所述第一状态为初始状态或未压缩状态，所述第二状态为压缩状态；

所述装置还包括更新模块、切换模块和接收模块；

所述装置还用于执行以下操作：

所述切换模块在所述第一发送模块发送N个所述第一类型包后，不需要接收解压缩端发送的反馈信息而直接将所述压缩端从所述第一状态切换到所述第二状态并通过所述第二发送模块发送所述第二类型包；

所述装置还用于执行以下操作：

当所述压缩端处于所述第二状态第一时间长度后，所述更新模块使所述压缩端从所述第二状态转换到所述第一状态，并通过所述第一发送模块再次发送所述第一类型包。

6.根据权利要求5所述的数据传输装置，其特征在于，所述第一类型包和/或所述第二类型包还包括：上下文标识和/或包类型标识符；

7.根据权利要求5或6所述的数据传输装置，其特征在于，所述第一类型包为完整包；和/或，所述第二类型包为压缩包。

8.根据权利要求5或6所述的数据传输装置，其特征在于，所述第二类型包内具有循环冗余校验。