CN107332909B - 一种实现数据传输的方法及装置 - Google Patents

一种实现数据传输的方法及装置 Download PDF

Info

Publication number
CN107332909B
CN107332909B CN201710532541.2A CN201710532541A CN107332909B CN 107332909 B CN107332909 B CN 107332909B CN 201710532541 A CN201710532541 A CN 201710532541A CN 107332909 B CN107332909 B CN 107332909B
Authority
CN
China
Prior art keywords
data packet
rule
data
compression
content
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.)
Active
Application number
CN201710532541.2A
Other languages
English (en)
Other versions
CN107332909A (zh
Inventor
张路
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CN201710532541.2A priority Critical patent/CN107332909B/zh
Publication of CN107332909A publication Critical patent/CN107332909A/zh
Priority to US16/628,653 priority patent/US11349962B2/en
Priority to EP18827476.5A priority patent/EP3651438B1/en
Priority to PCT/CN2018/081517 priority patent/WO2019007114A1/zh
Application granted granted Critical
Publication of CN107332909B publication Critical patent/CN107332909B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/3084—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method
    • H03M7/3091—Data deduplication
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/60—General implementation details not specific to a particular type of compression
    • H03M7/6064—Selection of Compressor
    • H03M7/607—Selection between different types of compressors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种数据传输方法及装置，该方法包括：利用预先获得的压缩策略对待发送的第一数据包进行处理，删除第一数据包中根据所述压缩策略指定的重复数据；将处理后的所述第一待数据包生成待发送的第二数据包，其中所述第二数据包中包括用于指示根据所述压缩策略删除重复数据的修改记录字段；将所述第二数据包发送给接收端。通过本发明提供的实现数据传输的方法，删除了待发送的数据包中重复发送的信息，减少了实际传输的数据量。本发明方法并不需要额外的硬件支持，就简单地实现了实际传输的数据量的减少，从而节约了成本。

Description

一种实现数据传输的方法及装置
技术领域
本发明涉及但不限于物联网通信技术，尤指一种实现数据传输的方法及装置。
背景技术
物联网(IoT，Internet of Things)是当前通信技术发展的重大趋势。近年来，一方面，无论是第三代合作伙伴计划(3GPP)等大型规范组织，还是各国网络运营商，终端厂商，都开始向低端挖掘，以寻求低速率，低带宽，低耗电的技术方向。另一方面，物联网对终端功耗的要求非常苛刻。因此，提高数据传输效率，降低功耗，延长终端设备的电池使用时间，是一个重要的研究方向。
再者，物联网应用场景的数据传输具有特殊性。
比如：物联网终端功能上的针对性决定了其传输数据包的规律性。如用于定位的Tracker类装置与网络侧交互的数据包大部分是用户的位置信息；用于计量的水电气表即Meter类装置，与网络侧交互的数据包大部分是计量数据的统计信息。而相对于移动终端如手机等这种复杂设备而言，这些物联网终端传输的数据的格式和类型相对都比较单一。
又如：物联网上行数据包内容比例较大。无线物联网终端和传感器是紧密相关的，通常都具有数据采集并上报服务器的特性。如抄表器定期发送计量数据、定位器上报位置信息等等。与移动终端如手机、ipad类产品在数据量上以及用户意图上以接收即下行数据为主不同的是，物联网终端常常需要上报传感器采集到的数据，因此上行数据的比例相对比较大，终端常常会在用户不主动干预的情况下，周期性、自发的与网络进行交互，一般是长年累月的不间断工作，这样一来，数据的总量就会非常庞大。而且相对于接收来说，发送数据对于接收而言，对终端的功耗更大，因此，对物联网上行数据传输的优化，对于整体系统的功耗优化是非常有意义的。
再如：物联网应用通常是客户端/服务器结构。应用提供商通常需要提供终端和应用服务器。随着技术上对物联网不断深入的研究，也出现了一些优化传输方面的新方案，但是基本上都需要终端和无线侧网元的配合才能实现，即需要网络运营商提供特殊硬件支持。这种技术实现起来相当复杂，一般需要国际大型协议组织和设备制造商大力推动才有可能实现。
相关技术方案中，基本就是标准的传输控制协议/网际协议(TCP/IP)和3GPP的无线协议传输方案。针对物联网特性，3GPP在增强机器类通信(eMTC)协议和基于蜂窝的窄带物联网(NB-IoT，Narrow Band Internet of Things)协议中也提出了一些针对传输方面的特性优化，比如：通过信令面传输小数据，以减少终端从空闲(Idle)态到连接态的无线承载建立次数，加快发送等。
在3GPP标准中，对于降功耗和优化传输效率的方法基本都有两个特性，第一是需要终端底层硬件支持，实现复杂；第二是需要终端和网络侧都有相应的功能模块实现才能支持，但是，这些是需要标准组织推动，网络运营商支持才能实现的功能，成本很高。
发明内容
为了解决上述技术问题，本发明提供一种数据传输方法及装置，能够简单地实现实际传输的数据量的减少，而且成本低。
为了达到本发明目的，本发明提供了一种数据传输方法，包括：
利用预先获得的压缩策略对待发送的第一数据包进行处理，删除第一数据包中根据所述压缩策略指定的重复数据；
将处理后的所述第一待数据包生成待发送的第二数据包，其中所述第二数据包中包括用于指示根据所述压缩策略删除重复数据的修改记录字段；
将所述第二数据包发送给接收端。
可选地，所述利用预设的压缩策略对待发送的第一数据包进行处理之前，还包括确认所述接收端支持压缩传输能力，包括：
向所述接收端发送查询请求，接收到所述接收端的回应后确定所述接收端支持压缩传输能力；或者，
查询与所述接收端的数据传输记录，根据存储记录确定所述接收端支持压缩传输能力。
可选地，所述方法还包括：
当确认所述接收端不支持压缩传输能力时，对所述第一数据包不进行处理，直接发送给所述接收端。
可选地，所述利用预先获得的压缩策略对待发送的第一数据包进行处理，删除第一数据包中压缩策略指定的重复数据包括：
周期性将所述第一数据包和所述压缩策略中与第一数据包的目的地址一致的规则进行比较，检查该第一数据包中的字段或内容是否与该规则中描述的相应字段或内容相同；
如果相同，删除该第一数据包中所述字段或者内容。
可选地，所述压缩策略包括协议类规则或内容类规则；所述协议类规则是通过协议类型来区分的规则，所述内容类规则是通过应用类型来区分的规则；
所述利用预先获得的压缩策略对待发送的第一数据包进行处理，删除第一数据包中压缩策略指定的重复数据包括：
如果所述压缩策略中存储有与所述第一数据包的目的地址一致的协议类规则，或者，如果所述压缩策略中未存储与所述第一数据包的目的地址一致的协议类规则，但存储有与所述第一数据包的目的地址一致的内容类规则，则，周期性将所述第一数据包和所述协议类规则进行比较，检查该第一数据包中的字段或内容是否与该协议类规则描述中的相应字段或内容相同；如果相同，删除该第一数据包中的所述字段或内容。
可选地，所述修改记录字段设置在所述第二数据包的负载的开始部分；
所述修改记录字段包括三个部分：
规则使能指示，用于表示该修改记录字段所在的数据包是否已执行过所述对待发送的数据包进行处理的步骤；
规则类型指示，用于表示对所述数据包的处理所采用的规则的类型；
规则号，用于表示对所述数据包的处理所使用的规则。
本申请还提供了一种数据传输方法，包括：
收到来自发送端的第二数据包，检查出第二数据包中携带有用于指示根据所述压缩策略删除重复数据的修改记录字段；
根据该修改记录字段以及生成的压缩策略对第二数据包进行恢复处理，以生成第一数据包。
可选地，还包括：
周期性的检测所述第二数据包，生成指定有重复数据的所述压缩策略。
可选地，所述生成压缩策略包括：
对所述第二数据包周期性或连续采样，对预设数量个第二数据包中的每个字段进行比对，提取出相同的字段信息作为所述压缩策略指定的重复数据；或者，
对特定应用程序的端口进行采样，对从该端口连续收到预设数量个第二数据包进行数据部分的比对，提取出相同的数据内容作为所述压缩策略指定的重复数据。
可选地，如果所述压缩策略发生变化，所述方法还包括：
向所述发送端发送更新请求消息，更新请求消息中携带有发生变化的规则和对应的规则号，以及新规则的内容。
可选地，所述修改记录字段设置在所述第二数据包的负载的开始部分；
所述修改记录字段包括三个部分：
规则使能指示，用于表示该修改记录字段所在的数据包是否已执行过所述对接收到的所述数据包进行处理的步骤；
规则类型指示，用于表示对所述数据包的处理所采用的规则的类型；
规则号，用于表示对所述数据包的处理所使用的规则。
可选地，所述根据该修改记录字段以及生成的压缩策略对数据包进行恢复处理，以生成第一数据包包括：
如果所述修改记录字段中的规则使能指示有效，则根据接收到的所述数据包的源地址和所述修改记录字段中的规则类型、规则号，查找所述服务器中对应的压缩策略，并利用该压缩策略指定的重复数据恢复接收到的所述第二数据包得到所述第一数据包。
本申请又提供了一种数据传输装置，包括压缩模块、处理模块、发送模块，以及用于存储压缩策略的第一存储模块；其中，
压缩模块，用于利用第一存储模块中的压缩策略对待发送的第一数据包进行处理，删除第一数据包中压缩策略指定的重复数据；
处理模块，用于将处理后的所述第一待数据包生成待发送的第二数据包，其中所述第二数据包中包括用于指示根据所述压缩策略删除重复数据的修改记录字段；
发送模块，用于发送第二数据包。
可选地，所述装置还包括：检测模块，用于确认所述接收端支持压缩传输能力并触发所述压缩模块进行处理；其中确认所述接收端支持压缩传输能力包括：
向所述接收端发送查询请求，接收到所述接收端的回应后确定所述接收端支持压缩传输能力；或者，
查询与所述接收端的数据传输记录，根据存储记录确定所述接收端支持压缩传输能力。
可选地，所述检测模块还用于：当确认所述接收端不支持压缩传输能力时，对所述第一数据包不进行处理，直接发送给所述接收端。
可选地，所述压缩模块具体用于：
周期性将所述第一数据包和所述压缩策略中与所述第一数据包的目的地址一致的规则进行比较，检查该第一数据包中的字段后内容是否与该规则描述中的相应字段或内容相同；
如果相同，删除该第一数据包中的所述字段或内容。
可选地，所述压缩策略包括协议类规则或内容类规则；所述协议类规则是通过协议类型来区分的规则，所述内容类规则是通过应用类型来区分的规则；
所述压缩模块具体用于：
如果所述压缩策略中存储有与所述第一数据包的目的地址一致的协议类规则，或者，如果所述压缩策略中未存储与所述第一数据包的目的地址一致的协议类规则，但存储有与所述第一数据包的目的地址一致的内容类规则，则，周期性将所述第一数据包和所述协议类规则进行比较，检查第一数据包中的字段或内容是否与该协议类规则描述中的相应字段或内容相同；如果相同，删除该第一数据包中的所述字段或内容。
可选地，所述修改记录字段设置在所述第二数据包的负载的开始部分；
所述修改记录字段包括三个部分：
规则使能指示，用于表示该修改记录字段所在的数据包是否已执行过所述对待发送的数据包进行处理的步骤；
规则类型指示，用于表示对所述数据包的处理所采用的规则的类型；
规则号，用于表示对所述数据包的处理所使用的规则。
本申请再提供了一种终端，包括上述任一项所述的数据传输装置。
与现有技术相比，本申请至少包括：利用预先获得的压缩策略对待发送的第一数据包进行处理，删除第一数据包中根据所述压缩策略指定的重复数据；将处理后的所述第一待数据包生成待发送的第二数据包，其中所述第二数据包中包括用于指示根据所述压缩策略删除重复数据的修改记录字段；将所述第二数据包发送给接收端。通过本发明提供的实现数据传输的方法，删除了待发送的数据包中重复发送的信息，减少了实际传输的数据量。本发明方法并不需要额外的硬件支持，就简单地实现了实际传输的数据量的减少，从而节约了成本。
本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1为本发明实施例中实现数据传输的一种方法的流程图；
图2为本发明实施例中实现数据传输的另一种方法的流程图；
图3为本发明实现数据传输的方法中实现压缩传输能力查询与压缩策略同步的实施例的流程示意图；
图4为本发明实施例中协议类规则的结构的示意图；
图5为本发明实施例中内容类规则的结构的示意图；
图6为本发明实施例中解压信息的结构的示意图；
图7为本发明实现数据传输的第一实施例的流程图示意图；
图8为本发明实现数据传输的第二实施例的流程图示意图；
图9为本发明实现数据传输的一种装置的组成结构示意图；
图10为本发明实现数据传输的另一种装置的组成结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。
图1为本发明实施例中实现数据传输的一种方法的流程图，图2所示方法可以适用于发送端如终端侧，如图1所示，包括以下步骤：
步骤100：利用预先获得的压缩策略对待发送的第一数据包进行处理，删除第一数据包中压缩策略指定的重复数据。
其中，压缩策略包括若干条规则，用来对比发送端即将发送的数据包是否包含有与之前发送的数据包有重复内容的依据信息，也是接收端用来恢复接收到的压缩后的第二数据包以形成原始的第一数据包的依据信息。
可选地，本步骤可以包括：
发送端有待发送的第一数据包时，周期性将第一数据包和压缩策略中与待发送的第一数据包的目的地址一致的规则进行比较，检查该第一数据包中的字段或内容是否与该规则描述中的相应字段或内容相同；
如果相同即检查第一数据包中的相关的字段或内容与压缩策略相匹配，删除该第一数据包中的所述字段或内容即与之前发送的数据包重复的内容。
可选地，如果检查出该数据包中的上述字段或内容与该规则描述中的相应字段或内容不相同，则删除压缩策略中的该条规则。
可选地，压缩策略至少包括：主要通过协议类型来区分的协议类规则，和主要通过应用类型来区分的内容类规则。
一个发送端针对一个目的IP地址，最多可包含两类规则，一个是协议类规则，一个是内容类规则。这两类规则内，协议类规则中包含一条或一条以上协议类的规则，内容类规则中包含一条或一条以上内容类的规则。一类规则内的多条规则以不相同的数字标记，称为规则号。
发送端如终端针对不同的目的IP地址，可以有多个压缩策略；而接收端如服务器针对不同终端，也有多个压缩策略。一个服务器和一个终端之间，具有对应的压缩策略，且服务器的压缩策略中各规则的规则号和终端的压缩策略中对应的规则的规则号完全一致。
当压缩策略包括协议类规则和内容类规则时，步骤100具体包括：
发送端有待发送的第一数据包时，如果压缩策略中存储有与待发送的第一数据包的目的地址一致的协议类规则，周期性将待发送的以数据包和压缩策略中与待发送的数据包的目的地址一致的协议类规则进行比较，检查该第一数据包中的字段或内容内容是否与该协议类规则描述中的相应字段或内容相同；如果相同即检查第一数据包中的相应字段或内容与压缩策略相匹配，删除该第一数据包中的相应字段或内容即与之前发送的数据包重复的内容；
如果压缩策略中未存储与待发送的第一数据包的目的地址一致的协议类规则，但存储有与待发送的第一数据包的目的地址一致的内容类规则，则周期性将待发送的第一数据包和压缩策略中与待发送的第一数据包的目的地址一致的内容类规则进行比较，检查该第一数据包中的指定内容是否与该内容类规则描述中的相应内容相同；如果相同即检查第一数据包中的指定字段或内容与压缩策略相匹配，删除该第一数据包中的相应字段或内容即与之前发送的数据包重复的内容。
步骤100中，在存在待发送的数据包之后，对待发送的数据包进行处理之前，还包括：
查询接收端是否支持压缩传输能力。具体包括：
向所述接收端发送查询请求，接收到所述接收端的回应后确定所述接收端支持压缩传输能力；或者，
查询与所述接收端的数据传输记录，根据存储记录确定所述接收端支持压缩传输能力。
对于第一种查询方式，发送端向接收端发送查询请求，如果发送端没有收到查询响应，则认为该接收端不支持压缩传输能力；如果发送端收到查询响应，则认为该接收端支持压缩传输能力。
对于第二种查询方式，如果发送端中存储有与接收端进行数据传输的记录，且记录显示该接收端支持压缩传输能力，继续执行步骤100；
如果发送端中未存储与该接收端进行数据传输的记录，则表明该发送端是首次与该待发送的第一数据包对应的目的IP地址进行通信，发送端需要通过控制通路查询接收端是否支持压缩传输能力：对于支持压缩传输能力的额手段，继续执行步骤100中的对待发送的第一数据包进行处理的步骤；对不支持压缩传输能力的接收端，结束本发明的流程，待发送的数据包采取相关技术中的普通数据传输方式发送。
较佳地，为了避免网络原因导致消息发送失败，查询接收端是否支持压缩传输能力还可以包括：
发送端按照预先设置的时间间隔如2秒向服务器发送预设次数如3次查询请求，如果发送端没有收到任何查询响应，则认为该接收端不支持压缩传输能力；如果发送端收到至少一个查询响应，则认为该接收端支持压缩传输能力。可选地，时间间隔和发送次数可以根据具体应用场景进行配置。
步骤100之前还包括：
发送端通过控制通路获取来自接收端的压缩策略。即实现了接收端与发送端之间的压缩策略中规则的同步。进一步地，发送端获得压缩策略后，可以向接收端返回确认信息。其中，控制通路是从TCP/IP的层面而言的，是区分于传输实际用户数据的通路；控制通路指的不是3GPP无线协议栈的控制面，控制通路仍是隶属于用户面的。这里，可以通过预先设置的固定的端口来确定控制通路。
步骤101：将处理后的所述第一待数据包生成待发送的第二数据包，其中所述第二数据包中包括用于指示根据所述压缩策略删除重复数据的修改记录字段。
其中，修改记录字段中的信息用于表示终端是按照压缩策略中的哪条规则对数据包进行处理的。修改记录字段占用一个字节。该修改记录字段可以设置在待发送的数据包的负载(Payload)的开始部分。
可选地，修改记录字段可以包括三个部分：
规则使能指示，用于表示该修改记录字段所在的数据包是否已经过步骤100的处理，比如：如果已经过处理，则规则使能指示有效，可以设置为1，如果未经过处理，则规则使能指示无效，可以设置为0；
规则类型指示，用于表示对数据包的处理所采用的规则的类型，比如，为0表示是采用协议类规则对数据包进行处理的，为1表示是采用内容类规则对数据包进行处理的；
规则号，用于表示对数据包的处理所使用的是哪条规则。
通过图1所示的本发明提供的实现数据传输的方法，删除了待发送的数据包中重复发送的信息，减少了实际传输的数据量；由于减少了实际传输的数据量，对运营商网络的用户面还有减轻负载的作用，因此，本发明技术方案的产品化是非常容易的。本发明方法直接应用在终端和服务器这两个最终节点之间，对网络运营商也是透明的，因此可直接应用，并不需要运营商额外增加软硬件成本，也不需要额外的硬件支持，因此，简单地实现了实际传输的数据量的减少，从而节约了成本。
图2为本发明实施例中实现数据传输的另一种方法的流程图，图2所示方法可以适用于服务器端，如图2所示，包括：
步骤200：收到来自发送端的第二数据包，检查出第二数据包中携带有用于指示根据所述压缩策略删除重复数据的修改记录字段。
步骤201：根据该修改记录字段以及生成的压缩策略对第二数据包进行恢复处理，以生成第一数据包。
修改记录字段为接收到的数据包的Payload的开始部分。如果修改记录字段中的规则使能指示有效，则根据第二数据包的源IP地址和修改记录字段中的规则类型、规则号信息，查找接收端的对应压缩策略，并利用该压缩策略指定的重复数据对第二数据包进行恢复处理，以生成原始的第一数据包。
可选地，接收端对接收到的数据包进行恢复处理之前，还包括：
接收端通过控制通路如预先设置的端口向发送端发送压缩策略。进一步地，接收端收到来自发送端的确认信息。举例来看，服务器周期性如以2秒为周期，向客户端重复发送携带有压缩策略的同步请求消息，并在收到来自终端的确认信息如一条同步请求响应消息时即认为同步完成；如果未收到来自终端的确认信息如同步请求响应消息，则会持续发送同步请求消息，直到终端完成同步并收到来自终端的同步请求响应消息为止。
可选地，当接收端收到来自发送端的查询接收端是否支持压缩传输能力的查询请求，如果自身支持，则向发送端回复查询响应。
通过图2所示的本发明提供的实现数据传输的方法，删除了待发送的数据包中重复发送的信息，减少了实际传输的数据量。本发明方法并不需要额外的硬件支持，就简单地实现了实际传输的数据量的减少，从而节约了成本。
本发明实现数据传输的方法还包括：
接收端周期性的检测收到的第二数据包，生成压缩策略；通过控制通路将生成的指定有重复数据的压缩策略发送给发送端。即实现了接收端与发送端之间的压缩策略中规则的同步。
可选地，接收端在检测过程中可以采取学习的方式生成压缩策略。对数据包的学习可以周期性或连续采样，对预设数量个数据包中的每个字段进行比对，提取出相同的字段信息作为压缩策略指定的重复数据；或者，对特定应用程序的端口进行采样，如果从这个端口连续收到预设数量个数据包进行数据部分的比对，提取出相同的数据内容作为压缩策略指定的重复数据。比如：服务器每收到连续的同一协议类型的预设数量如3个数据包，就对这3个数据包中的每个字段进行比对，提取出相同的字段信息作为成压缩策略指定的重复数据；对特定应用程序的端口如2001端口进行采样，如果从这个端口连续收到预设数量如3个数据包进行数据部分的比对，提取出相同的数据内容作为成压缩策略指定的重复数据。
如果接收端的压缩策略发生了变化，本发明方法还包括：
接收端向发送端发送更新请求消息，更新请求消息中携带有发生变化的规则和对应的规则号，以及新规则的具体内容等新的规则信息。即实现了接收端与发送端之间的压缩策略中规则的同步。
而发送端收到更新请求消息，获取更新请求消息中携带的新的规则信息，对压缩策略中的相应规则进行更新，并向接收端返回更新请求响应。
较佳地，为了避免网络原因导致消息发送失败，服务器按照预先设置的时间间隔如2秒向终端重复发送更新请求消息。只要收到一次来自终端的更新请求响应，则认为更新完成；如果未收到来自终端的更新请求响应，则服务器会持续发送更新请求消息，直到收到来自终端的更新请求响应。
通过图2所示的本发明提供的实现数据传输的方法，删除了待发送的数据包中重复发送的信息，减少了实际传输的数据量；由于减少了实际传输的数据量，对运营商网络的用户面还有减轻负载的作用，因此，本发明技术方案的产品化是非常容易的。本发明方法直接应用在终端和服务器这两个最终节点之间，对网络运营商也是透明的，因此可直接应用，并不需要运营商额外增加软硬件成本，也不需要额外的硬件支持，因此，简单地实现了实际传输的数据量的减少，从而节约了成本。
下面结合具体实施例对本发明技术方案进行详细描述。
图3为本发明实现数据传输的方法中实现压缩传输能力查询与压缩策略同步的实施例的流程示意图，本实施例中，通过控制通路来实现压缩传输能力查询与压缩策略同步。本实施例中假设通过指定的特定的两个端口来定义控制通路，在这两个端口之间传输的数据均视为控制数据。控制通路传送的数据主要是终端和服务器之间的压缩传输能力的查询请求/查询响应，以及规则同步时的具体规则内容。本实施例中，在规则同步完成后，一个终端和一个服务器之间，最多各自具有协议类规则和内容类规则各一对。即一对终端和服务器之间具有一一对应的压缩策略。如图3所示，包括：
步骤300～步骤301：终端在开始和一个新的服务器通信前，会通过控制通路向服务器发送查询请求以查询服务器是否支持压缩传输能力；服务器确认后向终端返回查询响应。
本实施例中，终端可以通过预先设置的端口3717和服务器的端口3718进行通信，视为数据通路。终端通过端口3717向服务器的端口3718发送一个TCP包，数据部分含有查询请求，服务器收到该查询请求后，通过端口3718向终端回复一个TCP包，数据部分携带查询响应，即表示服务器支持压缩传输能力。
较佳地，为了防止网络状态波动导致消息发送失败，终端可以间隔性的发送3次查询请求，如每次间隔2秒钟。如果3次都未收到来自服务器的查询响应，则认为是服务器不支持压缩传输；如果支持，服务器会向终端返回查询响应如确认(OK)消息。
步骤302～步骤303：支持压缩传输能力的服务器周期性的解析和统计收到的IP数据包，形成或更新压缩策略中的规则。如果服务器的压缩策略中的规则发生了变化，服务器向终端发送更新请求消息，在更新请求消息中携带有发生变化的规则和对应的规则号，以及新的规则的具体内容等。
步骤304：终端收到更新请求消息时，获取更新请求消息中携带的新的规则信息，对压缩策略中的相应规则进行更新，并向服务器返回更新请求响应。
同样，较佳地，为了避免网络原因导致消息发送失败，服务器可以按照预先设置的时间间隔如2秒向终端重复发送更新请求消息。只要收到一次来自终端的更新请求响应，则认为更新完成；如果未收到来自终端的更新请求响应，则服务器会持续发送更新请求消息，直到收到来自终端的更新请求响应。
图4为本发明实施例中协议类规则的结构的示意图，如图4所示，协议类规则可以以规则表的形式体现，规则表中容纳了多条协议类规则。终端针对每个服务器的IP地址，维护一个协议类规则表，该协议类规则表中的规则都是针对同一个服务器的；在终端结束和该服务器的通信后，将会释放针对该服务器的所有规则信息。位于同一规则表中的多条规则，具有唯一的规则号以区分开来。同理，服务器中也存储有和终端存储的规则表内容类似的协议类规则表，唯一不同的是服务器中规则表的IP地址是终端的IP地址，服务器为每个终端维护一个协议类的规则表，该规则表中的规则号以及规则描述与终端存储的是一致的。以图4为例，列出了终端中存储的3条规则，这3条规则的类型分别是超文本传输协议(HTTP)Get请求类型，因特网控制报文协议(ICMP)Ping请求类型，域名系统(DNS)请求类型。每条规则中最多支持对两个字段的重复描述，通过字段名/长度/值(Field/Len/Value)的格式的方法进行描述。
图5为本发明实施例中内容类规则的结构的示意图，如图5所示，与协议类规则类似，内容类规则可以以规则表的形式体现，终端针对每个服务器IP地址维护一个内容类的规则表，其中容纳了多条内容类规则，同一个规则表中，每条规则由唯一的规则号来区别。
服务器在生成和维护内容类规则时，为不同IP地址的终端维护不同的内容类规则表。对于同一个终端，会区分不同应用发来的不同数据流。区分数据流有很多种方式，比如可以采用端口号来区分。在与一个终端进行数据交互的过程中，服务器检测每个端口号，如在端口M上收到的数据将使用规则M进行匹配，在端口N上收到的数据使用规则N来进行匹配，这样避免了每收到一个数据包都要遍历规则表中的所有规则的问题。在终端和服务器上的内容类规则表中，端口号字段填充的都是服务器的端口号。另外，由于物联网应用中的数据传输过程中，某固定类型的端口上，通常发送的是固定格式和固定信息类型的数据。如GPS信息，仪表数据，车辆状态信息等等，因此，如图5所示，本发明实施例中的内容类的规则表的规则描述方法可以通过偏移值/长度/值(Offset/Len/Value)的方法来描述。
图6为本发明实施例中解压信息的结构的示意图，解压信息可以携带在待发送的数据包的一个字节的修改记录字段中，如图6所示，展示了修改记录字段的字段格式。本发明的终端在利用压缩策略对待发送的数据包进行处理，删除数据包中压缩策略指定的重复数据之后，会生成一个字节的修改记录字段信息，并将该修改记录字段放在该数据包的数据部分的首部；而服务器收到数据包后，会根据该修改记录字段的信息对数据包进行恢复。因此该修改记录字段是非常重要的。以图6为例，修改记录字段包含三个字段：1个比特bit的规则使能指示，表示该修改记录字段所在的数据包是否已经过上述利用压缩策略对待发送的数据包进行的处理，本实施例中，如果已经过处理，则规则使能指示有效，可以设置为1，如果未经过处理，则规则使能指示无效，可以设置为0；1个bit的规则类型指示，本实施例中，为0表示该数据包处理依据的规则是协议类规则，为1表示依据的规则是内容类规则；以及表示对数据包的处理所使用的是哪条规则的规则号。为了最大程度节省空间，并考虑到实际物联网场景中可能用到的规则数目，这里将规则数目最大设为64即规则号的取值范围为0～64。因此，该修改记录字段的最后6个bit可用于记录规则号。
图7为本发明实现数据传输的第一实施例的流程图示意图，本实施例中，如果找到匹配的协议类规则，待发送的数据包首先经过协议类规则的处理，处理后跳过内容类规则处理流程，直接发送；如果没有找到匹配的协议类规则，将进入内容类规则处理流程。如图7所示，包括：
步骤700：用户设备(UE)收到上层应用发来的IP包，获取目的IP地址和上层协议类型。
步骤701～步骤702：检查UE是否保存有与该目的IP地址对应的传输记录，如果有，则读取记录，根据读取的记录确定该服务器是否支持压缩传输机制，如果记录显示该服务器支持压缩传输，进入步骤704；如果没有对应的传输记录，说明UE是首次与该目的IP地址对应的服务器进行通信，需要先查询该服务器是否支持压缩传输，进入步骤703。
步骤703：判断目的IP地址对应的服务器是否支持压缩传输能力，如果不支持，进入步骤710；如果支持，进入步骤704。
步骤704：记录显示该目的IP地址对应的服务器是否支持压缩传输能力，如果是支持压缩传输能力的，进入步骤705；如果是不支持压缩传输能力的，进入步骤711。
步骤705：检查是否存在对应该目的IP地址的协议类规则，如果存在，进入步骤706；如果不存在，进入步骤713。
步骤706～步骤707：判断是否到达检测周期，本发明实施例中，可以通过如定时器T1或计数器C1来判定。如果未到达检测周期，则不检测，进入步骤707继续计时或计数并返回步骤706；如果到达检测周期，进入步骤708。
本实施例中，如果采用定时器，那么可以设置每10秒检测一次，如果采用计数器，那么可以设置每5个数据包检测一次。具体的阈值是可以根据具体应用需求，通过调整定时器T1或计数器C1的值来改变。
步骤708～步骤709：检测IP包中的字段内容，判断是否与对应规则描述中的Len和Value内容相匹配，如果二者相同即匹配，重置定时器T1或计数器C1，进入步骤710；如果二者不相同即不匹配，进入步骤712。
步骤710：按照规则处理IP包，删除重复数据，生成修改记录字段，并填充到原始的IP包中，修改更新IP包头部信息。
步骤711：将原始IP包不加处理的传递给无线协议栈发送给服务器。结束本流程。此时，可以采用相关技术中的普通数据传输方式发送数据包及对所述第一数据包不进行处理，直接发送给所述接收端。
步骤712：删除UE本地的该条协议类规则。
步骤713：转入将该IP包按内容类规则处理的流程进行进一步的处理。
图8为本发明实现数据传输的第二实施例的流程图示意图，本实施例是按内容类规则处理数据包的流程图。执行图8所示流程的数据包，是经过了协议类规则筛选而没有符合要求的协议类规则的数据包。如图8所示，包括：
步骤800：UE收到上层应用的原始IP包，获取目的IP地址和端口；检查是否有针对该目的IP地址和端口的内容类规则，如果没有，进入步骤805；如果存在对应的内容类规则，进入步骤802。
步骤802：检查IP包中特定位置的内容，是否与对应的规则中描述的内容相同，如果相同，进入步骤803；如果不同，进入步骤804。
步骤803：按照规则处理IP包，删除重复数据，生成修改记录字段，并填充到原始的IP包中，之后进入步骤806。
步骤804：删除UE本地的该条内容类规则。
步骤805：生成修改记录字段并填充为全0，将生成的修改记录字段填充到原始的IP包中。
步骤806：向服务器发送修改后的IP包。
为了更好的理解本发明提出的数据压缩传输方法，下面结合实际场景对本发明提供的技术方案的应用进行详细描述。本实施例中的UE以一个带定位功能的智能手表为例进行说明。该手表会定时以用户数据报协议(UDP)包的形式向服务器发送UE所在经纬度。也会间歇性的和网络进行HTTP交互，获取新闻简讯等业务内容。如果采用现有技术，那么，用户上层应用的每个数据包都会通过无线协议栈发送到网络侧，也就是说，应用产生多少数据量，终端就发送多少数据量。而采用了本发明提供的技术方案，可明显减少实际传输的数据量，具体实现详细描述如下：
假设用户当前在以陕西省西安市钟楼为中心，一环路以内活动。如下表1所示的数据包片段是智能手表依次向网络发送的IP包信息(本实施例中，下行包已经被过滤掉，这里仅显示上行的数据包)。序号和时间戳是叠加累计的，源IP是终端的IP地址，目的IP是服务器的IP地址。类型表示IP层以上的协议类型，本实施例中分别是HTTP和UDP两种。HTTP的用于和服务器的80端口之间通信，获取图片，新闻等等杂项业务内容。UDP包是终端发向服务器2001端口的，其中携带的信息是固定格式的，是终端的GPS经纬度信息，例如(34.2606986937,108.9444049731)。这些数据包的详细数据体将在后面展示。
Figure BDA0001339712600000171
Figure BDA0001339712600000181
表1
假设表1中1号HTTP包的负载内容如下：
Figure BDA0001339712600000182
其中，每行代表一个字段，冒号左边的是字段名称，冒号右边的是字段的值。可见，1号HTTP数据包含有多个字段，每个字段均含有特定的信息。比如，User-Agent字段描述终端用的什么操作系统(包括版本号)和浏览器(包括版本号)信息，Accept-Charset字段的信息则描述了浏览器支持的字符集，等等。关于其中各字段的名称和意义，是HTTP协议的标准规范，这里不再赘述。
假设表1中2号HTTP包的负载内容如下：
Figure BDA0001339712600000183
假设表1中5号HTTP包的负载内容如下：
Figure BDA0001339712600000191
在服务器分析统计这些数据包时，会统计出User-Agent和Accept-Charset两个字段始终没有变化，因此，服务器将生成一个针对此HTTP Get请求的，且针对源IP所对应的这个终端的协议类规则信息，并与终端进行同步，同步后，终端保存的协议类规则信息如表2所示：
Figure BDA0001339712600000192
表2
如表2所示，其中包括有一条规则即P-Policy1，规则P-Policy1的协议类型是HTTP(GET)类，还包括有两个字段的规则描述，即User-Agent字段和Accept-Charset字段，这两个字段的内容分别在规则中列出。实际上，发往该服务器的HTTP GET请求中的User-Agent字段和Accept-Charset字段的内容是不发生变化的。
这样，后续在UE传输符合HTTP Get类型的上述1、2、5号IP包过程中，将会利用规则P-Policy1删去IP包中的这两个字段，并在IP包的负载payload数据部分的首字节加上1个字节的修改记录字段，以告知服务器该IP包是经过压缩处理的，同时告诉服务器使用的是哪个规则进行压缩处理的，以便于服务器恢复。本实施例中，假设修改记录字段的值是0x81，每一位的分布如表3所示，规则使能指示的取值为1，表示该IP包已被压缩处理过；规则类型的取值为0，表示依据的规则是协议类规则；规则号代表了规则的编号，这个号码在UE和服务器是统一的，本实施例中假设是1。
Figure BDA0001339712600000201
表3
类似地，智能手表发送的第3、4、6号包是UDP包，假设是同一个应用发出的终端的GPS信息，均发往服务器203.209.232.6的端口2001。这三个消息携带的数据内容如下：
假设表1中3号UDP包携带的经纬度是(34.2606986937,108.9444049731)，如表4中所示，假设位于陕西省西安市莲湖区北院门1号：
Figure BDA0001339712600000202
表4
假设表1中4号UDP包携带的经纬度是(34.2584512637,108.9618120072)，如表5中所示，假设位于陕西省西安市碑林区西三道巷22号：
Figure BDA0001339712600000203
表5
假设表1中6号UDP包携带的经纬度是(34.2516250929,108.9479900409)，如表6中所示，假设位于陕西省西安市碑林区顺城南路东段：
Figure BDA0001339712600000211
表6
服务器周期性的统计端口2001上收到的UDP包，将针对该终端的IP生成一个内容类规则信息，并通过同步将该内容规则信息同步给终端，终端保存内容类规则信息如表7所示：
Figure BDA0001339712600000212
表7
如表7所示，目前只有一个规则C-Policy1，规则号为1。规则C-Policy1描述了两个内容字段的情况，分别位于相对于IP数据包负载payload数据偏移值为8和21、长度分别为4和6的两端数据，内容如表7所示，分别为“34.2”和“.108.9”。之所以会产生这两段数据，是因为该终端的用户在一段时间内的活动范围是在钟楼、城墙内的活动范围。普通用户在一段时间内，在一个特定范围内活动，这种场景是非常常见的，因此这种情况的内容类规则也是容易生成的。
这样，后续在UE传输符合规则C-Policy1的IP包的过程中，将会利用规则C-Policy1删去UDP内容中的这两个字段，并在IP包负载payload数据部分的首字节加上1个字节的修改记录字段，以告知服务器该IP包是经过压缩处理的，同时告诉服务器使用的是哪个规则进行压缩处理的，以便于服务器恢复。本实施例中，假设修改记录字段的值是0xC1，每一位的分布如表8所示，规则使能指示的取值为1，表示该IP包应用了规则；规则类型的取值为1，表示规则是内容类规则；规则号代表了规则的编号，这个号码在UE和服务器是统一的，本实施例中假设是1。
Figure BDA0001339712600000221
表8
至此，这两种规则均已生成。然后服务器会和UE进行规则同步。在规则同步后，UE在发送7号HTTP Get包时，会按HTTP Get协议类规则对其进行压缩处理，去掉协议中指定的项，处理后的包内容如表9所示，表9中划掉的信息是不传输的，相比原始数据包，少传输145字节的内容。即每个数据包都缩减掉36.7％的数据量。采用本发明的压缩传输方案后，去除了重复内容，提高了传输效率。
Figure BDA0001339712600000222
表9
从这个IP包的角度看，压缩前后的情况如表10所示，表10中下部分被斜杠划掉的字段：
Figure BDA0001339712600000223
表10
UE在发送8号UDP数据包时，会按照内容类规则去掉指定的数据，处理后的包内容如表11所示，表11中划掉的信息是不传输的。具体如表12所示下部分所示，本实施例中删除的数据为“34.2”和“.108.9”，处理后的IP数据包内容如下，相比原始数据包，少传输9字节的内容。即每个数据包缩减掉32.1％的数据量。采用本发明的压缩传输方案后，去除了重复内容，提高了传输效率。
Figure BDA0001339712600000231
表11
Figure BDA0001339712600000232
表12
上述结合实际场景对本发明提供的技术方案的应用的实施例中，在规则生成后，随着UE持续的工作，发包的数量会越来越多，利用本发明提供的技术方案在节省资源的效果上也会越来越显著。
本发明还提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行本发明任一项的实现数据传输的方法。
图9为本发明实现数据传输的一种装置的组成结构示意图，如图9所示，至少包括压缩模块、处理模块、发送模块，以及用于存储压缩策略的第一存储模块；其中，
压缩模块，用于利用第一存储模块中的压缩策略对待发送的第一数据包进行处理，删除第一数据包中压缩策略指定的重复数据；
处理模块，用于将处理后的所述第一待数据包生成待发送的第二数据包，其中所述第二数据包中包括用于指示根据所述压缩策略删除重复数据的修改记录字段；
发送模块，用于发送第二数据包。
其中，压缩策略包括若干条规则，用来对比发送端即将发送的第一数据包是否包含有与之前发送的数据包有重复内容的依据信息。
可选地，压缩模块具体用于：
有待发送的第一数据包时，周期性将所述第一数据包和所述压缩策略中与所述第一数据包的目的地址一致的规则进行比较，检查该第一数据包中的字段后内容是否与该规则描述中的相应字段或内容相同；
如果相同即检查第一数据包中的指定的字段或内容与压缩策略相匹配，删除该第一数据包中的所述字段或内容即与之前发送的数据包重复的内容。
可选地，压缩模块还用于：如果检查出该数据包中的上述字段或内容与该规则描述中的相应字段或内容不相同，则删除压缩策略中的该条规则。
可选地，压缩策略至少包括：主要通过协议类型来区分的协议类规则，和主要通过应用类型来区分的内容类规则。相应地，
压缩模块具体用于：
有待发送的第一数据包时，如果压缩策略中存储有与待发送的第一数据包的目的地址一致的协议类规则，周期性将待发送的数据包和压缩策略中与待发送的第一数据包的目的地址一致的协议类规则进行比较，检查该数据包中的字段或内容是否与该协议类规则描述中的相应字段或内容相同；如果相同即检查第一数据包中的指上述字段或内容与压缩策略相匹配，删除该第一数据包中的昂书字段或内容即与之前发送的数据包重复的内容；
如果压缩策略中未存储与待发送的第一数据包的目的地址一致的协议类规则，但存储有与待发送的第一数据包的目的地址一致的内容类规则，则周期性将待发送的第一数据包和压缩策略中与待发送的第一数据包的目的地址一致的内容类规则进行比较，检查该第一数据包中的指定内容是否与该内容类规则描述中的相应字段或内容相同；如果相同即检查第一数据包中的上述字段或内容与压缩策略相匹配，删除该数据包中的上述字段或内容即与之前发送的数据包重复的内容。
可选地，本发明装置还包括检测模块，用于确认所述接收端支持压缩传输能力，如果支持压缩传输能力，触发压缩模块进行处理；其中确认所述接收端支持压缩传输能力包括：
向所述接收端发送查询请求，接收到所述接收端的回应后确定所述接收端支持压缩传输能力；或者，
查询与所述接收端的数据传输记录，根据存储记录确定所述接收端支持压缩传输能力；
进一步地，
如果未存储与服务器进行数据传输的记录，则表明终端是首次与该待发送的数据包对应的目的IP地址进行通信，通过控制通路查询服务器是否支持压缩传输能力：对于支持压缩传输能力的服务器，触发压缩模块进行处理；当确认所述接收端不支持压缩传输能力时，对所述第一数据包不进行处理，直接发送给所述接收端。
较佳地，为了避免网络原因导致消息发送失败，查询接收端是否支持压缩传输能力还可以包括：
发送端按照预先设置的时间间隔如2秒向服务器发送预设次数如3次查询请求，如果发送端没有收到任何查询响应，则认为该接收端不支持压缩传输能力；如果发送端收到至少一个查询响应，则认为该接收端支持压缩传输能力。可选地，时间间隔和发送次数可以根据具体应用场景进行配置。
本发明装置还包括：获取模块，用于通过控制通路获取来自接收端的压缩策略。即实现了接收端与发送端之间的压缩策略中规则的同步。
进一步地，获取模块还用于：获得压缩策略后，可以向接收端返回确认信息。
其中，控制通路是从TCP/IP的层面而言的，是区分于传输实际用户数据的通路；控制通路指的不是3GPP无线协议栈的控制面，控制通路仍是隶属于用户面的。这里，可以通过预先设置的固定的端口来确定控制通路。
可选地，修改记录字段设置在所述第二数据包的负载的开始部分。
可选地，修改记录字段可以包括三个部分：
规则使能指示，用于表示该修改记录字段所在的数据包是否已经过步骤100的处理，比如：如果已经过处理，则规则使能指示有效，可以设置为1，如果未经过处理，则规则使能指示无效，可以设置为0；
规则类型指示，用于表示对数据包的处理所采用的规则的类型，比如，为0表示是采用协议类规则对数据包进行处理的，为1表示是采用内容类规则对数据包进行处理的；
规则号，用于表示对数据包的处理所使用的是哪条规则。
可选地，发送模块可以是eMTC/NB-IoT无线协议栈。
通过图9所示的本发明提供的实现数据传输的装置，删除了待发送的数据包中重复发送的信息，减少了实际传输的数据量；由于减少了实际传输的数据量，对运营商网络的用户面还有减轻负载的作用，因此，本发明技术方案的产品化是非常容易的。本发明装置直接应用在终端和服务器这两个最终节点之间，对网络运营商也是透明的，因此可直接应用，并不需要运营商额外增加软硬件成本，也不需要额外的硬件支持，因此，简单地实现了实际传输的数据量的减少，从而节约了成本。
本发明还提供一种终端，包括上述图9相关的任一项实现数据传输的装置。
图10为本发明实现数据传输的另一种装置的组成结构示意图，如图10所示，至少包括：接收模块、解压模块，以及用于存储压缩策略的第二存储模块；其中，
接收模块，用于收到来自发送端的第二数据包，检查出第二数据包中携带有用于指示根据所述压缩策略删除重复数据的修改记录字段；
解压模块，用于根据该修改记录字段以及第二存储模块中存储的压缩策略对第二数据包进行恢复处理，以生成第一数据包。
本发明装置还包括：生成模块、同步模块；其中，
生成模块，用于周期性的检测收到的数据包，生成压缩策略；
同步模块，用于通过控制通路将生成的指定有重复数据的压缩策略发送给发送端。
可选地，生成模块具体用于：
对预设数量个第二数据包周期性或连续采样，对预设数量个第二数据包中的每个字段进行比对，提取出相同的字段信息作为压缩策略指定的重复数据；或者，对特定应用程序的端口进行采样，如果从这个端口连续收到预设数量个第二数据包进行数据部分的比对，提取出相同的数据内容作为压缩策略指定的重复数据。
进一步地，生成模块还用于：压缩策略发生变化，将更新的压缩策略同步给发送端。
可选地，解压模块具体用于：
如果修改记录字段中的规则使能指示有效，则根据数据包的源IP地址和修改记录字段中的规则类型、规则号信息，查找服务器存储的对应压缩策略，并利用该压缩策略指定的重复数据对第二数据包进行恢复处理，以生成原始的第一数据包。
本发明还提供一种服务器，包括上述图10相关的任一项实现数据传输的装置。
以上所述，仅为本发明的较佳实例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (16)

1.一种数据传输方法，其特征在于，包括：
利用预先获得的压缩策略对待发送的第一数据包进行处理，删除第一数据包中根据所述压缩策略指定的重复数据；
将处理后的所述第一数据包生成待发送的第二数据包，其中所述第二数据包中包括用于指示根据所述压缩策略删除重复数据的修改记录字段；
将所述第二数据包发送给接收端；
其中，所述修改记录字段设置在所述第二数据包的负载的开始部分；
所述修改记录字段包括三个部分：
规则使能指示，用于表示该修改记录字段所在的数据包是否已执行过所述对待发送的数据包进行处理的步骤；
规则类型指示，用于表示对所述数据包的处理所采用的规则的类型；
规则号，用于表示对所述数据包的处理所使用的规则。
2.根据权利要求1所述的数据传输方法，其特征在于，所述利用预设的压缩策略对待发送的第一数据包进行处理之前，还包括确认所述接收端支持压缩传输能力，包括：
向所述接收端发送查询请求，接收到所述接收端的回应后确定所述接收端支持压缩传输能力；或者，
查询与所述接收端的数据传输记录，根据存储记录确定所述接收端支持压缩传输能力。
3.根据权利要求2所述的数据传输方法，其特征在于，所述方法还包括：
当确认所述接收端不支持压缩传输能力时，对所述第一数据包不进行处理，直接发送给所述接收端。
4.根据权利要求1～3任一项所述的数据传输方法，其特征在于，所述利用预先获得的压缩策略对待发送的第一数据包进行处理，删除第一数据包中压缩策略指定的重复数据包括：
周期性将所述第一数据包和所述压缩策略中与第一数据包的目的地址一致的规则进行比较，检查该第一数据包中的字段或内容是否与该规则中描述的相应字段或内容相同；
如果相同，删除该第一数据包中所述字段或者内容。
5.根据权利要求1～3任一项所述的数据传输方法，其特征在于，所述压缩策略包括协议类规则或内容类规则；所述协议类规则是通过协议类型来区分的规则，所述内容类规则是通过应用类型来区分的规则；
所述利用预先获得的压缩策略对待发送的第一数据包进行处理，删除第一数据包中压缩策略指定的重复数据包括：
如果所述压缩策略中存储有与所述第一数据包的目的地址一致的协议类规则，或者，如果所述压缩策略中未存储与所述第一数据包的目的地址一致的协议类规则，但存储有与所述第一数据包的目的地址一致的内容类规则，则，周期性将所述第一数据包和所述协议类规则进行比较，检查该第一数据包中的字段或内容是否与该协议类规则描述中的相应字段或内容相同；如果相同，删除该第一数据包中的所述字段或内容。
6.一种数据传输方法，其特征在于，包括：
收到来自发送端的第二数据包，检查出第二数据包中携带有用于指示根据压缩策略删除重复数据的修改记录字段；其中，所述修改记录字段设置在所述第二数据包的负载的开始部分；
所述修改记录字段包括三个部分：
规则使能指示，用于表示该修改记录字段所在的数据包是否已执行过对接收到的所述数据包进行处理的步骤；
规则类型指示，用于表示对所述数据包的处理所采用的规则的类型；
规则号，用于表示对所述数据包的处理所使用的规则；
根据该修改记录字段以及生成的压缩策略对第二数据包进行恢复处理，以生成第一数据包。
7.根据权利要求6所述的数据传输方法，其特征在于，还包括：
周期性的检测所述第二数据包，生成指定有重复数据的所述压缩策略。
8.根据权利要求7所述的数据传输方法，其特征在于，所述生成压缩策略包括：
对所述第二数据包周期性或连续采样，对预设数量个第二数据包中的每个字段进行比对，提取出相同的字段信息作为所述压缩策略指定的重复数据；或者，
对特定应用程序的端口进行采样，对从该端口连续收到预设数量个第二数据包进行数据部分的比对，提取出相同的数据内容作为所述压缩策略指定的重复数据。
9.根据权利要求6所述的数据传输方法，其特征在于，如果所述压缩策略发生变化，所述方法还包括：
向所述发送端发送更新请求消息，更新请求消息中携带有发生变化的规则和对应的规则号，以及新规则的内容。
10.根据权利要求7所述的数据传输方法，其特征在于，所述根据该修改记录字段以及生成的压缩策略对数据包进行恢复处理，以生成第一数据包包括：
如果所述修改记录字段中的规则使能指示有效，则根据接收到的所述数据包的源地址和所述修改记录字段中的规则类型、规则号，查找服务器中对应的压缩策略，并利用该压缩策略指定的重复数据恢复接收到的所述第二数据包得到所述第一数据包。
11.一种数据传输装置，其特征在于，包括压缩模块、处理模块、发送模块，以及用于存储压缩策略的第一存储模块；其中，
压缩模块，用于利用第一存储模块中的压缩策略对待发送的第一数据包进行处理，删除第一数据包中压缩策略指定的重复数据；
处理模块，用于将处理后的所述第一数据包生成待发送的第二数据包，其中所述第二数据包中包括用于指示根据所述压缩策略删除重复数据的修改记录字段；其中，所述修改记录字段设置在所述第二数据包的负载的开始部分；
所述修改记录字段包括三个部分：
规则使能指示，用于表示该修改记录字段所在的数据包是否已执行过所述对待发送的数据包进行处理的步骤；
规则类型指示，用于表示对所述数据包的处理所采用的规则的类型；
规则号，用于表示对所述数据包的处理所使用的规则
发送模块，用于发送第二数据包。
12.根据权利要求11所述的数据传输装置，其特征在于，所述装置还包括：检测模块，用于确认接收端支持压缩传输能力并触发所述压缩模块进行处理；其中确认所述接收端支持压缩传输能力包括：
向所述接收端发送查询请求，接收到所述接收端的回应后确定所述接收端支持压缩传输能力；或者，
查询与所述接收端的数据传输记录，根据存储记录确定所述接收端支持压缩传输能力。
13.根据权利要求12所述的数据传输装置，其特征在于，所述检测模块还用于：当确认所述接收端不支持压缩传输能力时，对所述第一数据包不进行处理，直接发送给所述接收端。
14.根据权利要求11～13任一项所述的数据传输装置，其特征在于，所述压缩模块具体用于：
周期性将所述第一数据包和所述压缩策略中与所述第一数据包的目的地址一致的规则进行比较，检查该第一数据包中的字段后内容是否与该规则描述中的相应字段或内容相同；
如果相同，删除该第一数据包中的所述字段或内容。
15.根据权利要求11～13任一项所述的数据传输装置，其特征在于，所述压缩策略包括协议类规则或内容类规则；所述协议类规则是通过协议类型来区分的规则，所述内容类规则是通过应用类型来区分的规则；
所述压缩模块具体用于：
如果所述压缩策略中存储有与所述第一数据包的目的地址一致的协议类规则，或者，如果所述压缩策略中未存储与所述第一数据包的目的地址一致的协议类规则，但存储有与所述第一数据包的目的地址一致的内容类规则，则，周期性将所述第一数据包和所述协议类规则进行比较，检查第一数据包中的字段或内容是否与该协议类规则描述中的相应字段或内容相同；如果相同，删除该第一数据包中的所述字段或内容。
16.一种终端，其特征在于，包括权利要求11～15任一项所述的数据传输装置。
CN201710532541.2A 2017-07-03 2017-07-03 一种实现数据传输的方法及装置 Active CN107332909B (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201710532541.2A CN107332909B (zh) 2017-07-03 2017-07-03 一种实现数据传输的方法及装置
US16/628,653 US11349962B2 (en) 2017-07-03 2018-04-02 Data transmission method and device
EP18827476.5A EP3651438B1 (en) 2017-07-03 2018-04-02 Data transmission based on application- and protocol-adaptive compression strategies
PCT/CN2018/081517 WO2019007114A1 (zh) 2017-07-03 2018-04-02 数据传输方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710532541.2A CN107332909B (zh) 2017-07-03 2017-07-03 一种实现数据传输的方法及装置

Publications (2)

Publication Number Publication Date
CN107332909A CN107332909A (zh) 2017-11-07
CN107332909B true CN107332909B (zh) 2020-03-31

Family

ID=60197774

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710532541.2A Active CN107332909B (zh) 2017-07-03 2017-07-03 一种实现数据传输的方法及装置

Country Status (4)

Country Link
US (1) US11349962B2 (zh)
EP (1) EP3651438B1 (zh)
CN (1) CN107332909B (zh)
WO (1) WO2019007114A1 (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107332909B (zh) * 2017-07-03 2020-03-31 中兴通讯股份有限公司 一种实现数据传输的方法及装置
CN108683565B (zh) * 2018-05-22 2021-11-16 珠海爱付科技有限公司 一种基于窄带物联网的数据处理系统
CN110661762B (zh) * 2018-06-29 2022-04-15 中兴通讯股份有限公司 一种交叉信息传输方法、装置和计算机存储介质
US11038990B2 (en) * 2018-12-28 2021-06-15 Intel Corporation Methods and apparatus to compress packets in a computing environment
CN109688606B (zh) * 2018-12-29 2022-03-25 京信网络系统股份有限公司 数据处理方法、装置、计算机设备及存储介质
WO2021007756A1 (zh) * 2019-07-15 2021-01-21 西门子股份公司 设备更新方法、系统及第一物联网设备和计算机可读介质
CN111313907B (zh) * 2020-02-19 2023-04-21 广西电网有限责任公司 一种海量电力数据压缩的方法及装置
CN112419698B (zh) * 2020-10-26 2022-05-17 浙江正泰仪器仪表有限责任公司 基于配电线报文规范的电能表数据传输方法、系统及装置
CN114531495B (zh) * 2022-02-25 2022-10-11 北方工业大学 一种数据包、数据包生成方法及数据包生成系统
CN115102951A (zh) * 2022-07-29 2022-09-23 上海电气风电集团股份有限公司 一种数据实时发布方法、装置和设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101577682A (zh) * 2009-06-15 2009-11-11 吴梅兰 数据包传输方法、装置及系统
US7995696B1 (en) * 2008-08-07 2011-08-09 Integrated Device Technology, Inc. System and method for deskewing data transmitted through data lanes
CN102487529A (zh) * 2010-12-01 2012-06-06 北京创毅视讯科技有限公司 一种提高物联网信息传输效率的方法和装置
CN106302245A (zh) * 2015-06-08 2017-01-04 中国移动通信集团公司 一种lte系统中数据包的压缩方法和装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5812202A (en) * 1995-03-24 1998-09-22 Minerva Systems, Inc. Method and apparatus performing inverse telecine for MPEG coding
JP2011254405A (ja) * 2010-06-03 2011-12-15 Canon Inc 画像処理装置及びその処理方法
EP2774340B1 (en) * 2011-11-03 2016-01-27 Telefonaktiebolaget L M Ericsson (publ) Unobtrusive content compression in a telecommunications network
US8867447B2 (en) 2012-08-28 2014-10-21 Verizon Patent And Licensing Inc. Dynamic header compression based on attributes of traffic
CN103873443B (zh) * 2012-12-13 2018-04-27 联想(北京)有限公司 信息处理方法、本地代理服务器和网络代理服务器
CN107179879B (zh) * 2016-03-11 2020-04-03 伊姆西Ip控股有限责任公司 用于存储设备的数据迁移的方法和装置
US10244071B2 (en) * 2016-11-21 2019-03-26 Intel Corporation Data management in an edge network
CN107332909B (zh) * 2017-07-03 2020-03-31 中兴通讯股份有限公司 一种实现数据传输的方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7995696B1 (en) * 2008-08-07 2011-08-09 Integrated Device Technology, Inc. System and method for deskewing data transmitted through data lanes
CN101577682A (zh) * 2009-06-15 2009-11-11 吴梅兰 数据包传输方法、装置及系统
CN102487529A (zh) * 2010-12-01 2012-06-06 北京创毅视讯科技有限公司 一种提高物联网信息传输效率的方法和装置
CN106302245A (zh) * 2015-06-08 2017-01-04 中国移动通信集团公司 一种lte系统中数据包的压缩方法和装置

Also Published As

Publication number Publication date
EP3651438A4 (en) 2021-01-13
EP3651438A1 (en) 2020-05-13
US11349962B2 (en) 2022-05-31
EP3651438B1 (en) 2023-12-13
US20210250427A1 (en) 2021-08-12
WO2019007114A1 (zh) 2019-01-10
CN107332909A (zh) 2017-11-07

Similar Documents

Publication Publication Date Title
CN107332909B (zh) 一种实现数据传输的方法及装置
Kovatsch et al. A low-power CoAP for Contiki
US11671868B2 (en) Methods and apparatus for optimizing tunneled traffic
EP3162020B1 (en) System and method for optimizing tunneled traffic
CN102255972B (zh) 6LoWPAN网络中面向HTTP协议的TCP首部压缩方法
Gundogan et al. ICNLoWPAN–named-data networking for low power IoT networks
Hahm et al. A named data network approach to energy efficiency in IoT
CN101523733A (zh) 消息压缩
EP2875616A1 (en) Content optimization based on real time network dynamics
Gündoğan et al. Designing a LoWPAN convergence layer for the Information Centric Internet of Things
CN109428916B (zh) 数据传输方法和装置、终端及服务器
Roth et al. Performance evaluation of mobile ipv6 over 6lowpan
CN103685030A (zh) 一种数据处理方法和设备
CN102056195A (zh) 一种业务质量的确定方法和无线接入网络设备
EP3340545A1 (en) Methods and apparatus for optimizing tunneled traffic
Cheng et al. Securing robust header compression (rohc)
US20220053309A1 (en) Apparatus, Method and Program for Transmitting and Receiving Data to and From IOT Device
CN105517142B (zh) 一种wlan的定位方法、终端和wlan接入服务器
CN117014951A (zh) 通信方法及通信装置
Koskela et al. Packet header compression for the internet of things
Majanen et al. Constrained application protocol profile for robust header compression framework
CN109559155B (zh) 一种基于NB-Iot的广告更新系统及其方法
Moons Multi-Level Interoperability in Heterogeneous Low Power Wide Area
Chan et al. Development of 6LoWPAN adaptation layer with fragmentation and reassembly mechanisms by using Qualnet Simulator
Wegner et al. Bundle protocol header compression

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
GR01 Patent grant
GR01 Patent grant