一种数据压缩的方法及基站与流程

本申请涉及工业控制领域和通信技术领域，尤其涉及一种数据压缩的方法及基站。

背景技术：

现有无线通信系统中，数据包经过用户设备(userequipment，简称ue)——基站——用户面功能实体(userplanefunction，简称upf)接入外部网络，需要经过的节点比较多，时延也较大，为此，工业控制引入了控制节点下沉的架构，将作为工业控制节点的可编程逻辑控制器(programmablelogiccontroller，简称plc)放到无线接入网(radioaccessnetwork，简称ran)内部。这样，基站可判断业务的类型，来确定数据包的出口。对于下行，基站从plc接收工业控制数据，传给ue，从upf接收其它业务的数据，传给ue；对于上行，基站从ue接收数据后，判断其业务类型，如果是工业控制相关的数据，基站将其路由至plc，如果是其它类型的业务相关的数据，基站则将其路由至upf。数据包在传输过程中，为了控制路由或分段重组等目的，各个网元都可能对数据包增加包头，所以，数据包到了空口，可能会携带了一些包头。为减少空口传输的数据量，需要对空口传输的数据包进行压缩，包括对数据包头的压缩，以及对数据包本身的压缩。

在现有的无线通信系统中，针对上行数据引入了上行数据压缩(uplinkdatacompression，简称udc)的方式进行处理。采用udc，可以对数据包头和数据包本身一同进行压缩。基站首先为数据无线承载(dataradiobearer，简称drb)配置一个预先定义的字典(dictionary)，现有两种类型的字典:会话初始协议sessioninitiationprotocol，sip)类型、运营商自定义类型。ue侧根据预定义的字典，将相应的数据块预先存储在自己的本地缓存中，基站侧也将相同的数据块存储在自己的本地缓存中。用户数据包到达时，ue将收到的数据包与本地缓存中存储的内容进行比较，确定哪些内容可以压缩，将数据包进行压缩，再将本地缓存更新，将压缩后的数据包传到基站。基站收到后，根据自己的本地缓存的内容，将数据包恢复成压缩前的状态，同时更新自己的本地缓存的内容。这种方式需要采用预先定义好的字典，而在工业私网中，数据传输链路发生变化，无法直接使用现有的udc的方式来对数据包进行压缩。

技术实现要素：

本申请实施例所要解决的技术问题在于，提供一种数据压缩的方法及基站，以解决工业私网中无法使用udc的方式对数据包进行压缩的问题。

第一方面，本申请的实施例提供了一种数据压缩的方法，可包括：

基站获取数据压缩设备和/或数据解压缩设备的标识信息；

根据所述标识信息生成字典；

将所述字典发送给所述数据压缩设备和所述数据解压缩设备，以便所述数据压缩设备和所述数据解压缩设备根据接收到的字典进行数据压缩和数据传输。

在一种可能的实现方式中，在所述将所述字典发送给所述数据压缩设备和所述数据解压缩设备之后，所述方法还包括：

将所述字典发送给第三方控制设备进行保存；

当所述基站下电后再次上电时，从所述第三方控制设备获取所述字典。

在一种可能的实现方式中，在所述基站获取数据压缩设备和/或数据解压缩设备的标识信息之前，所述方法还包括：

所述基站接收所述数据解压缩设备或第三方控制设备发送的业务开始消息；

根据所述业务开始消息所指示的数据包头的类型确定使用的数据压缩算法，所述数据压缩算法包括基于上行数据传输udc的算法。

在一种可能的实现方式中，所述数据包头的类型以数据承载为粒度进行区分和/或以流flow为粒度进行区分；

若以数据承载为粒度进行区分，则所述数据包头的类型包括以下任意一种：ip地址结合以太网地址、非结构化数据结合以太网地址、显性指示数据压缩算法。

以流flow为粒度进行区分，则所述数据包头的类型包括以下任意一种：ip地址、以太网地址、非结构化数据、ip地址结合以太网地址、非结构化数据结合以太网地址、显性指示数据压缩算法。

在一种可能的实现方式中，所述方法还包括：

对于周期性业务，所述基站指示所述数据压缩设备在一个周期内需要存入内存的待存储数据包，以便所述数据压缩设备在发送一个周期内的所有数据包时将所述待存储数据包存入内存，所述数据解压缩设备接收到所述一个周期内发送的所有数据包之后进行校验，当校验通过时将所述待存储数据包存入内存。

在一种可能的实现方式中，对于周期性业务，当一个或多个周期结束时，所述数据解压缩设备根据数据包接收结果向所述数据压缩设备发送反馈状态报告，通知所述数据压缩设备重传丢失的数据包或通知所述数据压缩设备将丢失的数据包移出内存，确保所述数据解压缩设备和所述数据压缩设备的内存中udc缓存相同。

在一种可能的实现方式中，所述标识信息包括以下至少一种：

以太网地址、ip地址、接口信息或虚拟局域网标识。

在一种可能的实现方式中，所述标识信息还包括所述数据解压缩设备发送给所述数据压缩设备的应用层命令。

第二方面，本申请的实施例提供了一种基站，可包括：

收发单元，用于获取数据压缩设备和/或数据解压缩设备的标识信息；

处理单元，用于根据所述标识信息生成字典；

所述收发单元还用于将所述字典发送给所述数据压缩设备和所述数据解压缩设备，以便所述数据压缩设备和所述数据解压缩设备根据接收到的字典进行数据压缩和数据传输。

在一种可能的实现方式中，所述收发单元还用于：

将所述字典发送给第三方控制设备进行保存；

当所述基站下电后再次上电时，从所述第三方控制设备获取所述字典。

在一种可能的实现方式中，所述收发单元还用于：

接收所述数据解压缩设备或第三方控制设备发送的业务开始消息；

所述处理单元还用于：

根据所述业务开始消息所指示的数据包头的类型确定使用的数据压缩算法，所述数据压缩算法包括基于上行数据传输udc的算法。

在一种可能的实现方式中，所述数据包头的类型以数据承载为粒度进行区分和/或以流flow为粒度进行区分；

若以数据承载为粒度进行区分，则所述数据包头的类型包括以下任意一种：ip地址结合以太网地址、非结构化数据结合以太网地址、显性指示数据压缩算法。

以流flow为粒度进行区分，则所述数据包头的类型包括以下任意一种：ip地址、以太网地址、非结构化数据、ip地址结合以太网地址、非结构化数据结合以太网地址、显性指示数据压缩算法。

在一种可能的实现方式中，对于周期性业务，所述收发单元还用于指示所述数据压缩设备在一个周期内需要存入内存的待存储数据包，以便所述数据压缩设备在发送一个周期内的所有数据包时将所述待存储数据包存入内存，所述数据解压缩设备接收到所述一个周期内发送的所有数据包之后进行校验，当校验通过时将所述待存储数据包存入内存。

在一种可能的实现方式中，对于周期性业务，当一个或多个周期结束时，所述数据解压缩设备根据数据包接收结果向所述数据压缩设备发送反馈状态报告，通知所述数据压缩设备重传丢失的数据包或通知所述数据压缩设备将丢失的数据包移出内存，确保所述数据解压缩设备和所述数据压缩设备的内存中udc缓存相同。

在一种可能的实现方式中，所述标识信息包括以下至少一种：

以太网地址、ip地址、接口信息或虚拟局域网标识。

在一种可能的实现方式中，所述标识信息还包括所述数据解压缩设备发送给所述数据压缩设备的应用层命令。

第三方面，本申请的实施例提供了一种基站，可包括：

处理器、存储器和总线，所述处理器和存储器通过总线连接，其中，所述存储器用于存储一组程序代码，所述处理器用于调用所述存储器中存储的程序代码，执行本申请实施例第一方面或第一方面任一实现方式中的步骤。

第四方面，本申请的实施例提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，实现上述第一方面或第一方面任一实现方式所述的方法。

附图说明

为了更清楚地说明本申请实施例或背景技术中的技术方案，下面将对本申请实施例或背景技术中所需要使用的附图进行说明。

图1为本申请实施例提供的一种工业私网的架构示意图；

图2为本申请实施例提供的一种数据压缩的方法的流程示意图；

图3为本申请实施例提供的另一种数据压缩的方法的流程示意图；

图4为本申请实施例提供的又一种数据压缩的方法的流程示意图；

图5为本申请实施例提供的又一种数据压缩的方法的流程示意图；

图6为本申请实施例提供的又一种数据压缩的方法的流程示意图

图7为本申请实施例提供的一种基站的组成示意图；

图8为本申请实施例提供的另一种基站的组成示意图。

具体实施方式

下面结合本申请实施例中的附图对本申请的实施例进行描述。

本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

请参照图1，为本申请实施例提供的一种工业私网的架构示意图，在图1所示架构下，由基站(gnb)10、plc20、终端30(操作臂)、upf40、访问和移动性管理功能实体(accessandmobilitymanagementfunction，简称amf)(图未示)、会话管理功能实体(sessionmanagementfunction，简称smf)(图未示)和第三方控制设备50等组成。

其中，ue又可以称为终端、用户终端、终端设备等，在工业控制中，可以以操作臂这种常见的形式呈现。基站可以判断业务的类型，确定数据包的出口。对于下行，基站可以，从plc接收工业控制数据，传给ue，从upf接收其它业务的数据，传给ue；对于上行，基站从ue接收数据后，判断其业务类型，如果是工业控制，基站将其路由至plc，如果是其它类型的业务，基站将其路由至upf。

smf和amf为控制面网络节点。amf负责移动性管理，并与操作臂相连。smf负责会话管理，并与amf相连。第三方控制设备可用于全局控制，与基站相连。

第三方控制设备50是网络侧的一种网元设备，也可称为控制中心、控制服务器、第三方设备等，可用于保存配置信息如字典或其他的配置数据，还可以用于生成控制指令并发送给基站10或终端30，来对基站10或终端30进行控制。其可以与现有的工业私网系统集成设置，也可以通过外挂的方式与现有工业私网系统独立设置，本申请实施例不作任何限定。

在本申请实施例中，基站/plc/第三方控制设备可以收集ue和/或plc的以太网(ethernet)地址来生成用于udc的字典，从而实现在工业私网中使用udc来对数据包进行压缩，降低链路资源的消耗，提升数据传输效率。

需要说明的是，虽然本申请中采用了udc的方式来描述和说明，但在本申请实施例中不仅可以对上行数据包进行udc的方式压缩，对于下行数据包同样可以采用类似的方式进行压缩。当传输上行数据时，终端为数据压缩设备，plc为数据解压缩设备，此外根据数据的传输路径基站或网络侧的节点设备也可以是数据解压缩设备。当传输下行数据时，plc为数据压缩设备，终端为数据解压缩设备，此外根据数据的传输路径基站或网络侧的节点设备也可以是数据压缩设备。

请参照图1，为本申请实施例提供的一种数据压缩的方法的流程示意图；具体包括如下步骤：

s101.基站获取数据压缩设备和/或数据解压缩设备的标识信息。

s102.根据所述标识信息生成字典。

s103.将所述字典发送给所述数据压缩设备和所述数据解压缩设备，以便所述数据压缩设备和所述数据解压缩设备根据接收到的字典进行数据压缩和数据传输。

其中，参照前文描述，根据上行或下行的区分，数据压缩设备和数据解压缩设备对应的设备实体不同。

基站在生成字典时，可以只获取数据压缩设备的标识信息，也可以只获取数据解压缩设备的标识信息，或者还可以同时获取二者的标识信息，本申请实施例不作任何限定。

可选地，标识信息可以包括以下至少一种：

以太网地址、ip地址、接口信息或虚拟局域网标识。

除了上述的静态标识信息之外，还可以根据生产任务的不同来获取动态标识信息如数据解压缩设备发送给数据压缩设备的应用层命令等来生成字典或对字典进行更新。

为了便于描述和说明，本申请以下实施例主要基于基站收集各个设备的标识信息如以太网地址并生成字典，终端对上行数据包压缩进行描述，此时，终端为数据压缩设备，plc为数据解压缩设备。plc/第三方控制设备收集以太网地址并生成字典，plc和终端对下行数据包进行压缩的方法类似，不再赘述。

下面结合图3-图6对本申请数据压缩的方法进行详细描述。

请参见图3，图3为本申请实施例提供的另一种数据压缩的方法的流程示意图；具体包括如下步骤：

s201.基站获取终端的以太网地址和可编程逻辑控制器plc的以太网地址。

s202.根据所述信息生成字典。

s203.将所述字典发送给所述终端和所述plc，以便所述终端和所述plc根据接收到的字典进行数据压缩和数据传输。

在本实施例中，设备上电后，plc和终端可以将自己的ethernet地址通知基站，基站收到后，可以生成一个公共的用于udc的字典，然后将字典发送给终端和plc，终端和plc将字典存储在自己的本地缓存中。以实现终端和plc之间数据包传输的压缩。每个终端及plc都使用相同的字典，此后每次收到数据包，每个终端和plc都更新字典。

可选地，除了上报ethernet地址之外，还可以上报虚拟局域网(virtuallocalareanetwork,简称vlan)标识、接口(port)信息、ip地址或其他信息中的至少一项。

可选地，除了使用公共的字典之外，所述字典也可以包括所述终端使用的第一字典和所述plc使用的第二字典；

所述第一字典和所述第二字典不同。

实际上，终端和基站之间的空口情况、基站与plc之间的空口情况可能大不相同，针对这种区别，基站可以针对所有终端生成一个字典，针对plc生成一个字典。

可选地，所述终端的数目大于或等于一，当所述终端的数目大于一时，所述基站可以为每个终端生成独立的字典；或者所述基站为同一工作组的终端生成独立的字典。

当然，除了由基站生成字典之外，也可以由第三方控制设备生成字典。例如，基站在收集到终端和plc的以太网地址之后，可以将所有设备的以太网地址列表发送给第三方控制设备，由第三方控制设备生成字典后发送给基站，再由基站分发给终端和plc。或者也可以由plc接收基站发送的以太网地址列表来生成字典或直接自己收集以太网地址来生成字典，此处不再赘述。

需要说明的是，在工业私网中，多个终端可以组成一个工作组或操作组由plc统一管理和控制，因此，终端在向基站上报ethernet地址时，也可以采用“组标识(groupid)结合ethernet地址”的方式上报，这样，基站在生成字典时，可以为每个组(group)生成字典。

在本申请实施例中，通过获取终端和plc的以太网地址来生成用于udc的字典，从而无需使用现有的sip类型的字典或运营商自定义的字典，因此使得终端和plc可以在工业私网中使用基于udc的压缩算法来进行数据压缩，提升了系统的压缩效率和压缩效果，降低了对上下行通信资源的使用，利于业务的快速执行，提高工业生产效率。

参见图4，图4为本申请实施例提供的又一种数据压缩的方法的流程示意图；在本实施例中，步骤s301-s303与步骤s201-s203相同，在步骤s203之后，还包括：

s304.将所述字典发送给第三方控制设备进行保存。

s305.当所述基站下电后再次上电时，从所述第三方控制设备获取所述字典。

在初次上电时，基站可以收集各个终端和plc的以太网地址生成字典后，可以将字典上报第三方控制设备，由第三方控制设备保存。下次上电后，由第三方控制设备直接将字典传给基站，再由基站传给各个终端及plc，不需要再进行收集。从而提升系统的工作效率。

可选地，若是为每个终端生成独立的字典，则基站可以发送终端标识或基站标识来获取基站上报的字典，若是为同一个工作组的终端生成独立的字典，则基站可以发送组标识或基站标识来获取基站上报的字典，若是为所有设备生成一个公共的字典，则基站可以发送基站标识来获取基站上报的字典。

通过将字典上报给第三方控制设备，使得在下次上电时无需再次收集以太网地址来生成字典，提升了系统的工作效率。

与上下电类似地，当需要更换生产任务时，也可以将字典上报给第三方控制设备后再从第三方控制设备获取字典。当然，如果字典不仅包括了ethernet地址等静态信息，还包括了plc发出的应用层命令等信息，由于不同的生产任务所对应的应用层命令通常不同，则此时可以再次生成新的字典。其中，所述应用层命令用于根据生产任务的需求，指示终端执行应用层命令所指示的操作。例如，plc通知终端“向上移动10厘米”、“向左转动15度”、“顺时针转动180度”等等。

需要说明的是，在数据发送的过程中，字典可以是静态/半静态的，静态是指数据包的传输过程中不需更新字典；半静态是字典只能由显式信令来更新，比如生产线完成第一项生产任务后，采用显式信令更新字典，开始第二项生产任务。静态/半静态/动态字典由网络侧设备配置，比如由基站配置，或由plc配置。静态或半静态字典，主要用于限定字典的更新方式，而对于字典的来源，静态或半静态字典可以是由数据压缩和解压缩双方共同协商生成的，也可以是由其它节点如第三方控制设备或后台人工配置的数据库等提供的。本申请不作任何限定。

请参见图5，图5为本申请实施例提供的又一种数据压缩的方法的流程示意图；在本实施例中，步骤s403-s407与步骤s301-s305相同，在步骤s403之前，可包括：

s401.所述基站接收所述plc或第三方控制设备发送的业务开始消息。

s402.根据所述业务开始消息所指示的数据包头的类型确定使用的数据压缩算法，所述数据压缩算法包括基于上行数据传输udc的算法。

在业务开始之前，第三方控制设备或plc向基站发起业务开始消息时，也就是配置会话(session)时，可以向基站指示该session数据包头的类型。基站收到该指示后，就可以根据指示来配置该业务使用的压缩算法如常见的rohc算法、基于udc的算法等。由于在工业私网中，数据包头的格式中增加了ethernet包头，因此现有的基于rohc协议的rohc算法无法进行压缩。因此可以在配置会话时，指示不再为业务配置rohc算法而采用基于udc的算法。其中，基于udc的算法可以是zlib、deflate、，自适应分组数据压缩(adaptivepacketdatacompression，简称apdc)等各种算法，可以基于udc这种压缩方式或者称为网络特性来进行压缩，本申请实施例不作任何限定。

可选地，所述数据包头的类型以数据承载为粒度进行区分和/或以流flow为粒度进行区分；

若以数据承载为粒度进行区分，则所述数据包头的类型包括以下任意一种：ip地址结合以太网地址、非结构化数据结合以太网地址、显性指示数据压缩算法。

例如，数据包头的类型可以通过“ipv4+ethernet”或“ipv6+ethernet”或“ipv4v6+ethernet”或“非结构化数据(unstructureddata)+ethernet”或其它指示，如显性指式数据压缩算法为“该业务使用udc压缩算法”，可通过0或1指示。

若以流flow为粒度进行区分，则所述数据包头的类型包括以下任意一种：ip地址、以太网地址、非结构化数据、ip地址结合以太网地址、非结构化数据结合以太网地址、显性指示数据压缩算法。

例如，配置某个服务质量(qualityofservice，简称qos)流(flow)的数据包头类型是ipv4、ipv6、ipv4v6、ethernet、unstructureddata、ipv4+ethernet、ipv6+ethernet、ipv4v6+ethernet、unstructureddata+ethernet中的一种或多种。

当然，上述两种指示方式可以单独使用也可以混合使用。

例如，一个session内包含三个qosflow：flowa/flowb/flowc，配置时，可以指示基站:session级的数据包头类型是ipv4,其中flowb的数据包头类型是ipv6+ethernet。这样，基站就认为flowa和flowc的数据包头类型是ipv4，flowb的数据包头类型是ipv6+ethernet。

需要说明的是，udc的原意是指上行数据压缩，解决的问题是上行覆盖受限，在本申请实施例中，由于是应用在工业控制场景中，因此相应的压缩算法既可以应用于上行数据，也可以应用于下行数据，所以，配置时可以统一配置上下行的数据包头类型，也可以分别配置上下行的数据包头类型。对于统一配置的方式，只向基站指示一种数据包头的类型，基站认为上行和下行的数据包头类型都是配置的这一种类型；对于分别配置的方式，需要向基站指示上行数据包头的类型和下行数据包头的类型。

上述指示的方式可以在上行和下行中混合使用，例如：上行可以按session配置数据包头的类型，下行可以按qosflow配置数据包头的类型，也可以是别的结合方式，此处不再赘述。

在本申请实施例中，通过上级节点向基站指示数据包头的类型，基站收到指示后，可以为该数据承载/flow配置指示的基于udc的算法，可以与现有系统相结合，当需要使用传统的压缩算法时，可以指示采用传统的压缩算法，当需要使用基于udc的算法时，可以指示采用基于udc的算法，从而提升系统的灵活性。

当然，除了本申请实施例描述的基于udc的算法之外，也可以指示采用其他的算法，且如果想采用默认的一种算法进行压缩时，此处也可以不进行任何指示，直接默认采用某种算法如基于udc的算法进行压缩即可。

在一种可能实施方式中，为了更加贴合工业私网中业务的周期性特点以及进一步提升系统的工作效率，在本申请实施例中，可以在一个周期的数据处理完成之后，再集中更新udc缓存(buffer)

在现有技术中，基于常规的udc方式，作为数据压缩设备的终端每获取到一个包，会根据内存中的udc缓存情况，生成一个校验码(checksum)，然后压缩这个包，将校验码附着在压缩后的包中，数据压缩设备更新内存通常有两种方式：一种是压缩数据包中的一段，更新一下内存，再压缩一段、再更新一下内存；第二种是先压缩完整个包，再更新内存。作为数据解压缩设备的plc收到后，先根据其原来的内存状态，生成校验码，与接收到的数据包中带来的校验码比较，如果相同，就将数据包解压缩，同时更新自己的内存。

但工业控制中，对于周期性业务，所述基站可以指示所述终端在一个周期内需要存入内存的待存储数据包，以便所述终端在发送一个周期内的所有数据包时将所述待存储数据包存入内存，所述plc接收到所述一个周期内发送的所有数据包之后进行校验，当校验通过时将所述待存储数据包存入内存。

即这种情况下，可以对同一周期的一个或多个数据包更新一次内存中的udc缓存就可以了。也就是说，发送方针对同一周期内的多个包，依次生成校验码后，再将各个包压缩并依次存储在内存中。接收方收到一个周期内的所有包后，依次检验数据包中的校验码，如果确认无误，则解压缩这一批包，并将这一批包存储在自己的内存中。

可选地，基站可以向所述终端发送控制面信令来进行指示，也可以通过现有的其他信令进行指示或者构造新的信令进行指示，本申请实施例不作任何限定。

其中，基站指示存入内存的待存储数据包可以是部分数据包也可以是全部数据包，当需要存入全部数据包时，也可以不进行指示，默认存入所有数据包。当指示存储部分数据包时，发送方和接收方只将一部分数据包存入内存中，用于对后续数据包计算校验码，并在周期结束后统一进行校验。例如，基站可以通知终端：将每个周期的第一个数据包存入内存，其它的数据包无需存入内存。

需要说明的是，以上主要描述了数据包的下行过程，对于上行的数据包同样可以采用这种处理方式。此时，可以由终端通知基站，需要存入内存的数据包。例如全部存入或者每个周期的第一个数据包存入内存，其它的数据不存入内存等。

通过对同一周期的一批包进行统一处理，可以避免频繁读写内存中的udc缓存，降低读写次数，提升内存使用寿命，提高系统的工作效率。

请参见图6，图6为本申请实施例提供的又一种数据压缩的方法的流程示意图；在本实施例中，步骤s501-s507与步骤s401-s407相同，在s507之后，还包括如下步骤：

s508.当一个周期结束时，所述plc根据数据包接收结果向所述终端发送反馈状态报告,通知所述终端重传丢失的数据包或通知所述终端将丢失的数据包移出内存。

可选地，也可以选择预设的多个周期结束时再发送反馈状态报告。

s509.终端重传丢失的数据包或将丢失的数据包移出内存，确保所述plc和所述终端的内存中udc缓存相同。

可选地，反馈状态包括可以是无线链路控制(radiolinkcontrol，简称rlc)状态报告，也可以是数据汇聚协议(packetdataconvergenceprotocol，简称pdcp)状态报告，或mac层的反馈等。以rlc状态报告为例，由于工业控制的时延要求很严苛，所以，rlc重传的包，对应用层基本没有用。所以，工业控制通常采用rlcum模式，但是，rlcum模式不保证每个包都能正确收到。如果某个包没能正确收到，无法将这个丢失的数据包存入内存，导致收发双方的内存中存储的内容不一致，会影响后续数据包的udc的校验。因此，在本申请实施例中，在每个周期结束时，接收方可以向发送方发送rlc状态报告，通知发送方：“本周期没有收齐所有的数据包”(前提是接收方知道一个周期有几个数据包传输，具体可以是一个布尔类型的参数)、或“本周期收到几个数据包”(具体可以是一个数字)、或“本周期收到哪几个数据包”(具体可以是一个比特位图或其它格式)。如果发生丢包，发送方重传该周期内所有的包，或只重传丢失的包。接收方收到后，将这些重传包解压缩并按顺序存入本地的udc缓存，这样，保证收发双方的udc缓存中的内容一致。当收到下一个周期的数据时，校验可以正常进行。这个过程中，重传的包只为了更新接收方的udc缓存，不向应用层递交，对于这些包，底层传输时可以不需要遵守qos所要求时延，在下一个周期的新数据到来之前传输到接收方就可以了。

当反馈状态报告为pdcp状态报告时，例如，接收方可以通过媒体接入控制(mediaaccesscontrol，简称mac)用户边缘设备(customeredge，简称ce)通知发送方：“本周期没有收齐所有的数据包”、或“本周期收到几个数据包”、或“本周期收到哪几个数据包”。当反馈状态报文为mac层的混合自动重传请求(hybridautomaticrepeatrequest，简称harq)反馈，例如，对每一个传输块，接收方发送harq反馈，告诉发送方是否收到。发送方如果发现接收方没有正确收到哪一个传输块，就重传哪一个传输块。接收方收到重传的传输块后，接收正确，则更新接收方的udc缓存，不向应用层递交这些数据包。

可选地，除了通知发送方重传丢失的包之外，为了让发送方和接收方的udc缓存内容一致，还可以通知发送方：哪几个包没有正确收到，这样，发送方可以不把丢失的这些包放进自己的udc缓存中，已放入的可删除。通过这种方法，也能达到同样的目的。

可选地，接收方的反馈可以是如下几种：

“本周期没有收齐所有的数据包”。这种情况下，发送方将该周期内的所有数据包都不写入udc缓存，对于已写入的相关数据包可以进行删除。

“本周期收到哪几个数据包”。这种情况下，接收方反馈哪几个包没有收到，发送方就不把这些包放入自己的udc缓存，对于已写入的相关数据包可以进行删除。

通过上述方式，可以确保数据收发双方的udc缓存一致。确保数据压缩的正常进行。

需要说明的是，在本申请图2-图5的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。一些实施例中与其他实施例不同的步骤可以单独执行，也可以与其他实施例的步骤相结合。

请参照图7，为本申请实施例提供的一种基站的组成示意图；可包括：

收发单元100，用于获取数据压缩设备和/或数据解压缩设备的标识信息；

处理单元200，用于根据所述标识信息生成字典；

所述收发单元100还用于将所述字典发送给所述数据压缩设备和所述数据解压缩设备，以便所述数据压缩设备和所述数据解压缩设备根据接收到的字典进行数据压缩和数据传输。

可选地，所述收发单元100还用于：

将所述字典发送给第三方控制设备进行保存；

当所述基站下电后再次上电时，从所述第三方控制设备获取所述字典。

可选地，所述收发单元100还用于：

接收所述数据解压缩设备或第三方控制设备发送的业务开始消息；

所述处理单元还用于：

根据所述业务开始消息所指示的数据包头的类型确定使用的数据压缩算法，所述数据压缩算法包括基于上行数据传输udc的算法。

可选地，所述数据包头的类型以数据承载为粒度进行区分和/或以流flow为粒度进行区分；

若以数据承载为粒度进行区分，则所述数据包头的类型包括以下任意一种：ip地址结合以太网地址、非结构化数据结合以太网地址、显性指示数据压缩算法。

若以流flow为粒度进行区分，则所述数据包头的类型包括以下任意一种：ip地址、以太网地址、非结构化数据、ip地址结合以太网地址、非结构化数据结合以太网地址、显性指示数据压缩算法。

可选地，对于周期性业务，所述收发单元100还用于指示所述数据压缩设备在一个周期内需要存入内存的待存储数据包，以便所述数据压缩设备在发送一个周期内的所有数据包时将所述待存储数据包存入内存，所述数据解压缩设备接收到所述一个周期内发送的所有数据包之后进行校验，当校验通过时将所述待存储数据包存入内存。

可选地，对于周期性业务，当一个或多个周期结束时，所述数据解压缩设备根据数据包接收结果向所述数据压缩设备发送反馈状态报告，通知所述数据压缩设备重传丢失的数据包或通知所述数据压缩设备将丢失的数据包移出内存，确保所述数据解压缩设备和所述数据压缩设备的内存中udc缓存相同。

可选地，所述标识信息包括以下至少一种：

以太网地址、ip地址、接口信息或虚拟局域网标识。

可选地，所述标识信息还包括所述数据解压缩设备发送给所述数据压缩设备的应用层命令。

可选地，所述字典包括所述终端使用的第一字典和所述plc使用的第二字典；

所述第一字典和所述第二字典不同。

可选地，所述终端的数目大于或等于一，当所述终端的数目大于一时，所述基站为每个终端生成独立的字典；或者所述基站为同一工作组的终端生成独立的字典。

该基站所涉及的与本申请实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法实施例中关于这些内容的描述，此处不做赘述。

请参照图8，为本申请实施例提供的另一种基站的组成示意图；如图7所示，该基站可以包括处理器110、存储器120和总线130。处理器110和存储器120通过总线130连接，该存储器120用于存储指令，该处理器110用于执行该存储器120存储的指令，以实现如上图2-图5对应的方法中的步骤。

进一步的，该基站还可以包括、输入口140和输出口150。其中，处理器110、存储器120、输入口140和输出口150可以通过总线130相连。

处理器110用于执行该存储器120存储的指令，以控制输入口140接收信号，并控制输出口150发送信号，完成上述方法中装置执行的步骤。其中，输入口140和输出口150可以为相同或者不同的物理实体。为相同的物理实体时，可以统称为输入输出口。所述存储器120可以集成在所述处理器110中，也可以与所述处理器110分开设置。

作为一种实现方式，输入口140和输出口150的功能可以考虑通过收发电路或者收发的专用芯片实现。处理器110可以考虑通过专用处理芯片、处理电路、处理器或者通用芯片实现。

作为另一种实现方式，可以考虑使用通用计算机的方式来实现本申请实施例提供的基站。即将实现处理器110，输入口140和输出口150功能的程序代码存储在存储器中，通用处理器通过执行存储器中的代码来实现处理器110，输入口140和输出口150的功能。

该基站所涉及的与本申请实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。

本领域技术人员可以理解，为了便于说明，图8仅示出了一个存储器和处理器。在实际的控制器中，可以存在多个处理器和存储器。存储器也可以称为存储介质或者存储设备等，本申请实施例对此不做限制。

应理解，在本申请实施例中，处理器可以是中央处理单元(centralprocessingunit，简称cpu)，该处理器还可以是其他通用处理器、数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现成可编程门阵列(field－programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。

该存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器的一部分还可以包括非易失性随机存取存储器。

该总线除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线。

在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。

根据本申请实施例提供的方法，本申请实施例还提供一种系统，其包括前述的基站、终端、plc，第三方控制设备等。

在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

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

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

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘)等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。