WO2019007114A1 - 数据传输方法及装置 - Google Patents

数据传输方法及装置 Download PDF

Info

Publication number
WO2019007114A1
WO2019007114A1 PCT/CN2018/081517 CN2018081517W WO2019007114A1 WO 2019007114 A1 WO2019007114 A1 WO 2019007114A1 CN 2018081517 W CN2018081517 W CN 2018081517W WO 2019007114 A1 WO2019007114 A1 WO 2019007114A1
Authority
WO
WIPO (PCT)
Prior art keywords
data packet
rule
data
content
receiving end
Prior art date
Application number
PCT/CN2018/081517
Other languages
English (en)
French (fr)
Inventor
张路
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to US16/628,653 priority Critical patent/US11349962B2/en
Priority to EP18827476.5A priority patent/EP3651438B1/en
Publication of WO2019007114A1 publication Critical patent/WO2019007114A1/zh

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]

Definitions

  • the present disclosure relates to the field of Internet of Things communication technologies, for example, to a data transmission method and apparatus.
  • the Internet of Things is a major trend in the development of communication technologies.
  • 3GPP 3rd Generation Partnership Project
  • 3GPP 3rd Generation Partnership Project
  • national network operators and terminal manufacturers are beginning to seek low-speed, low-bandwidth, and low-power technologies.
  • the Internet of Things has very strict requirements on terminal power consumption. Therefore, improving data transmission efficiency, reducing power consumption, and extending battery life of terminal devices is an important research direction.
  • the basic transmission control protocol/internet protocol (TCP/IP) and the 3GPP wireless protocol transmission scheme are basically.
  • 3GPP has also proposed some optimizations for transmission characteristics in the Enhanced Machine-Type Communication (eMTC) protocol and the Cell-based Narrow Band Internet of Things (NB-IoT) protocol, such as:
  • eMTC Enhanced Machine-Type Communication
  • NB-IoT Cell-based Narrow Band Internet of Things
  • the small data is transmitted to reduce the number of times the terminal establishes the radio bearer from the idle (Idle) state to the connected state, and accelerates the transmission.
  • the underlying hardware support of the terminal is required, and the implementation is complicated.
  • the second is that the terminal and the network side have corresponding functional modules to implement. Support, however, these are functions that need to be promoted by standard organizations and supported by network operators, and are costly.
  • the embodiment of the invention provides a data transmission method and device, which can easily realize the reduction of the amount of data actually transmitted, and the cost is low.
  • the embodiment of the invention provides a data transmission method, including:
  • the embodiment of the invention further provides a data transmission method, including:
  • the embodiment of the present invention further provides a data transmission apparatus, including a compression module, a processing module, a sending module, and a first storage module configured to store a compression policy obtained in advance from the receiving end;
  • the compression module is configured to: process, by using a compression policy in the first storage module, a first data packet to be sent, and delete the specified duplicate data included in the compression policy in the first data packet;
  • the processing module is configured to: generate, by using the processed first data packet, a second data packet to be sent, where the second data packet includes a modified record field for indicating the deleted duplicate data. ;
  • the sending module is configured to: send the second data packet.
  • the embodiment of the present invention further provides a terminal, including the data transmission apparatus provided by any of the foregoing embodiments.
  • the embodiment of the invention further provides a computer readable storage medium storing computer executable instructions for performing the above method.
  • the data transmission method provided by the embodiment of the present invention deletes the information repeatedly transmitted in the data packet to be sent, and reduces the amount of data actually transmitted.
  • the method provided by the embodiment of the present invention does not require additional hardware support, and simply reduces the amount of data actually transmitted, thereby saving cost.
  • FIG. 1 is a flowchart of a data transmission method according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a data transmission method according to another embodiment of the present invention.
  • FIG. 3 is a schematic flowchart of synchronizing a compression transmission capability query and a compression policy in a data transmission method according to an embodiment of the present invention
  • FIG. 4 is a schematic diagram of a structure of a protocol type rule according to an embodiment of the present invention.
  • FIG. 5 is a schematic diagram of a structure of a content class rule according to an embodiment of the present invention.
  • FIG. 6 is a schematic diagram of a structure of decompression information according to an embodiment of the present invention.
  • FIG. 7 is a flowchart of a data transmission method according to another embodiment of the present invention.
  • FIG. 8 is a flowchart of a data transmission method according to another embodiment of the present invention.
  • FIG. 9 is a schematic structural diagram of a data transmission apparatus according to an embodiment of the present invention.
  • FIG. 10 is a schematic structural diagram of a data transmission apparatus according to another embodiment of the present invention.
  • the data transmission of the Internet of Things application scenario has special characteristics.
  • the pertinence of the function of the Internet of Things terminal determines the regularity of its transmission of data packets.
  • the data packet that the Tracker-type device used for positioning interacts with the network side is mostly the location information of the user; the water and electricity meter used for metering is the Meter-type device, and the data packet that interacts with the network side is mostly the statistical information of the measurement data. .
  • the format and type of data transmitted by these IoT terminals are relatively simple.
  • the content ratio of the uplink data packet of the Internet of Things is large.
  • Wireless IoT terminals and sensors are closely related and typically have the characteristics of data collection and reporting to the server.
  • the meter reader periodically sends metering data or the positioner reports position information and the like.
  • IoT terminals Different from mobile terminals such as mobile phones and ipad products in terms of data volume and user intent to receive data, that is, downlink data, IoT terminals often need to report data collected by sensors, so the proportion of uplink data is relatively large.
  • Internet of Things terminals often interact with the network periodically and spontaneously without the user's active intervention. Generally, they are uninterrupted work for many years. As a result, the total amount of data will be very large.
  • the transmission data has higher power consumption for the terminal for reception. Therefore, the optimization of the uplink data transmission of the Internet of Things is very meaningful for the optimization of the power consumption of the overall system.
  • IoT applications are usually client/server architectures.
  • Application providers typically need to provide terminal and application servers.
  • Some new solutions for optimizing transmission have emerged, but basically all need to cooperate with the terminal and the wireless side network element to achieve, that is, the network operator needs to provide special hardware support.
  • This kind of technology is quite complicated to implement, and it is generally required to be promoted by large international agreement organizations and equipment manufacturers.
  • FIG. 1 is a flowchart of a method for implementing data transmission according to an embodiment of the present invention.
  • the method shown in FIG. 1 can be applied to a sending end (such as a terminal side).
  • the method provided in this embodiment includes the following steps.
  • Step 100 Process the first data packet to be sent by using a compression policy obtained in advance from the receiving end, and delete the specified duplicate data included in the compression policy in the first data packet.
  • the compression policy includes a plurality of rules, which are used to compare whether the first data packet to be sent by the sending end has duplicate content with the previously sent data packet, and is also used by the receiving end to recover the compressed second received data.
  • the data packet forms the basis information of the original first data packet.
  • this step may include:
  • the first data packet and the destination address in the compression policy are periodically compared with the destination address of the first data packet to be sent, and the first data packet is checked for existence.
  • the rule in the compression policy is deleted.
  • the compression policy includes at least: a protocol class rule distinguished by a protocol type, and a content class rule distinguished by an application type.
  • a sender can address up to two types of rules for a destination IP (Internet Protocol) address.
  • One is a protocol class rule and the other is a content class rule.
  • a protocol class rule contains one or more rules of a protocol class
  • a content class rule includes one or more rules of a content class. Multiple rules within a class of rules are marked with different numbers, called rule numbers.
  • the sender (such as a terminal) may have multiple compression policies for different destination IP addresses; and the receiver (such as a server) has multiple compression policies for different terminals.
  • a server and a terminal have corresponding compression policies, and the rule number of each rule in the compression policy of the server is the same as the rule number of the corresponding rule in the compression policy of the terminal.
  • step 100 includes:
  • the compression policy stores a protocol type rule whose destination address is consistent with the destination address of the first data packet to be sent
  • the first data packet to be sent and the compression policy are periodically The destination address is compared with a protocol type rule that is consistent with the destination address of the first data packet to be sent, and whether the field or content with the same field or content described in the protocol rule exists in the first data packet; if yes, That is, the corresponding field or content in the first data packet is matched with the compression policy, and the same field or content in the first data packet as described in the protocol class rule is deleted, that is, the first data is deleted.
  • the periodicity is Comparing the first data packet to be sent and the content class rule in the compression policy that matches the destination address of the first data packet to be sent, and checking whether the specified content in the first data packet is related to the content class rule
  • the corresponding content in the same is the same; if the same, it is checked that the specified field or content in the first data packet matches the compression policy, and the corresponding field or content in the first data packet is deleted, that is, the first data packet is deleted
  • the content of the previously sent packet is duplicated.
  • step 100 before the first data packet to be sent is processed after the first data packet to be sent, the method further includes:
  • the receiving end supports the compressed transmission capability, including:
  • the sender sends a query request to the receiver. If the sender does not receive the query response, the receiver does not support the compressed transmission capability. If the sender receives the query response, the receiver considers that the receiver supports Compressed transmission capacity.
  • step 100 For the second query mode, if the sender has a record for data transmission with the receiving end, and the record shows that the receiving end supports the compressed transmission capability, proceed to step 100;
  • the transmitting end needs to query whether the receiving end is through the control path.
  • Supporting the compression transmission capability for the receiving end supporting the compressed transmission capability, the step of processing the first data packet to be sent in step 100 is performed; and the receiving end of the embodiment of the present invention is terminated for the receiving end that does not support the compressed transmission capability.
  • the first data packet to be sent is sent by a common data transmission method in the related art.
  • the querying whether the receiving end supports the compressed transmission capability may further include:
  • the sending end sends a preset number of times (for example, 3 times) to the server according to a preset time interval (for example, 2 seconds). If the sending end does not receive any query response, the receiving end does not support the compressed transmission capability; When the terminal receives at least one query response, it considers that the receiving end supports the compressed transmission capability.
  • the time interval and the number of transmissions may be configured according to an application scenario.
  • step 100 it also includes:
  • the transmitting end acquires a compression policy from the receiving end through the control path. That is, the synchronization of rules in the compression policy between the receiving end and the transmitting end is implemented.
  • the sending end may return the confirmation information to the receiving end.
  • the control path is from the TCP/IP level, and is a path that distinguishes between actual user data.
  • the control path refers not to the control plane of the 3GPP wireless protocol stack, and the control path still belongs to the user plane.
  • the control path can be determined by a preset port.
  • Step 101 Generate a second data packet to be sent by using the processed first data packet, where the second data packet includes a modified record field for indicating duplicate data of the deletion.
  • the information in the modified record field is used to indicate that the sender processes the first data packet to be sent according to which rule in the compression policy.
  • the modified record field occupies one byte.
  • the modified record field can be set at the beginning of the payload (Payload) of the second data packet to be transmitted.
  • modifying the record field may include:
  • the rule enable indication is used to indicate whether the second data packet in which the modified record field is located has been processed by step 100. For example, if the processing has been processed, the rule enable indication is valid, and may be set to 1, if not processed, The rule enable indication is invalid and can be set to 0.
  • the rule type indication is used to indicate the type of the rule to be used for the processing of the first data packet to be sent. For example, the rule type indication is 0, indicating that the first data packet is processed by using the protocol type rule, and the rule type indication is 1, indicating that the first data packet is processed by using a content class rule;
  • Step 102 Send the second data packet to the receiving end.
  • the data transmission method provided by the embodiment of the present invention shown in FIG. 1 deletes the information repeatedly transmitted in the data packet to be transmitted, thereby reducing the amount of data actually transmitted; and reducing the amount of data actually transmitted, to the carrier network.
  • the user plane also has the effect of mitigating the load, and therefore, the productization of the technical solution of the embodiment of the present invention is very easy.
  • the method provided by the embodiment of the present invention is directly applied between the terminal nodes and the server, and is transparent to the network operator, so that the application can be directly applied, and the operator does not need to additionally increase the hardware and software costs, and does not need additional Hardware support, therefore, simply reduces the amount of data actually transferred, thereby saving costs.
  • FIG. 2 is a flowchart of a data transmission method according to another embodiment of the present invention.
  • the method shown in FIG. 2 can be applied to a receiving end (such as a server end).
  • the method provided in this embodiment includes:
  • Step 200 Receive a second data packet from the sending end, and check that the second data packet carries a modified record field for indicating that the sending end deletes the duplicate data according to the compression policy.
  • Step 201 Perform recovery processing on the second data packet according to the modified record field and the compression policy to generate a first data packet.
  • the modified record field is the beginning of the load (Payload) of the received second data packet. If the rule enable indication in the modified record field is valid, the corresponding compression policy of the receiving end is searched according to the source IP address of the second data packet and the rule type and the rule number information in the modified record field, and the repeated specified by the compression policy is used. The data is restored to the second data packet to generate the original first data packet.
  • the receiving end before the receiving end recovers the received second data packet, the receiving end further includes:
  • the receiving end sends a compression policy to the transmitting end through a control path such as a preset port.
  • the receiving end receives confirmation information from the transmitting end.
  • the server periodically sends a synchronization request message carrying a compression policy to the client periodically in a period of 2 seconds, and considers that the synchronization is completed when receiving confirmation information (such as a synchronization request response message) from the terminal. If the confirmation message from the terminal (such as the synchronization request response message) is not received, the synchronization request message is continuously sent until the terminal completes the synchronization and receives the synchronization request response message from the terminal.
  • the receiving end when the receiving end receives a query request from the sending end of the query whether the receiving end supports the compressed transmission capability, if it supports itself, it replies to the sending end with the query response.
  • the information repeatedly transmitted in the data packet to be transmitted is deleted, and the amount of data actually transmitted is reduced.
  • the method provided by the embodiment of the present invention does not require additional hardware support, and simply reduces the amount of data actually transmitted, thereby saving cost.
  • the received second data packet from the transmitting end includes a plurality of second data packets.
  • the receiving end periodically detects the received multiple second data packets to generate a compression policy, and sends the generated compression policy including the specified repeated data to the sending end through the control path. That is, the synchronization of rules in the compression policy between the receiving end and the transmitting end is implemented.
  • the receiving end may generate a compression policy in a learning manner during the detecting process.
  • the learning of the data packet may be periodically or continuously sampled, and each field in the preset number of second data packets is compared, and the same field information is extracted as the specified repeated data included in the compression policy; or,
  • the port of the application samples, compares the data parts of the preset number of second data packets continuously received from the port, and extracts the same data content as the specified duplicate data included in the compression policy. For example, each time the server receives a preset number of consecutive same protocol types, such as three data packets, compares each of the three data packets, and extracts the same field information as the specified one of the compression policies.
  • Duplicate data sample the port of a specific application, such as port 2001, compare the data parts of the preset number received from this port, such as 3 packets, and extract the same data content as the specification included in the compression policy. Duplicate data.
  • the method provided by the embodiment of the present invention may further include:
  • the receiving end sends an update request message to the sending end, where the update request message carries the rule number corresponding to the changed rule, and the new rule information such as the specific content of the new rule. That is, the synchronization of rules in the compression policy between the receiving end and the transmitting end is implemented.
  • the sender receives the update request message, obtains the new rule information carried in the update request message, updates the corresponding rule in the compression policy, and returns an update request response to the receiver.
  • the server in order to avoid the failure of the message transmission caused by the network, the server repeatedly sends the update request message to the terminal according to a preset time interval (for example, 2 seconds).
  • the server considers that the update is completed as soon as it receives an update request response from the terminal; if the update request response from the terminal is not received, the server continues to send the update request message until an update request response from the terminal is received.
  • the data transmission method provided by the embodiment of the present invention shown in FIG. 2 deletes the repeatedly transmitted information in the data packet to be sent, thereby reducing the amount of data actually transmitted; and reducing the actual amount of data transmitted,
  • the user plane of the quotient network also has the effect of reducing the load. Therefore, the productization of the technical solution of the embodiment of the present invention is very easy.
  • the method provided by the embodiment of the present invention is directly applied between the terminal nodes and the server, and is transparent to the network operator, so that the application can be directly applied, and the operator does not need to additionally increase the hardware and software costs, and does not need additional Hardware support, therefore, simply reduces the amount of data actually transferred, thereby saving costs.
  • FIG. 3 is a schematic flowchart of synchronizing a compression transmission capability query and a compression policy in a data transmission method according to an embodiment of the present invention.
  • a compression transmission capability query and a compression policy synchronization are implemented through a control path.
  • a control path is defined by two designated ports, and data transmitted between the two ports is regarded as control data.
  • the data transmitted by the control path is mainly the query request/query response of the compressed transmission capability between the terminal and the server, and the specific rule content when the rule is synchronized.
  • the compression transmission capability query and compression policy synchronization between the terminal and the server includes:
  • Step 300 to step 301 Before starting communication with a new server, the terminal sends a query request to the server through the control path to query whether the server supports the compressed transmission capability. After receiving the query request, the server returns a query response to the terminal.
  • the terminal can communicate with the port 3718 of the server through the preset port 3717, and is regarded as a control path.
  • the terminal sends a Transmission Control Protocol (TCP) packet to the port 3718 of the server through the port 3718.
  • TCP Transmission Control Protocol
  • the data part of the TCP packet contains a query request.
  • the server replies to the terminal with a TCP packet through the port 3718.
  • the TCP packet The data part carries the query response, which means that the server supports compressed transmission capability.
  • the terminal may send a preset number of times (eg, 3 times) of the query request at intervals (eg, 2 seconds apart). If the terminal does not receive the query response from the server 3 times, it is considered that the server does not support the compressed transmission capability; if the server supports the compressed transmission capability, the server returns a query response such as an acknowledgment (OK) message to the terminal.
  • a preset number of times eg, 3 times
  • the server does not support the compressed transmission capability
  • the server returns a query response such as an acknowledgment (OK) message to the terminal.
  • Step 302 to step 303 The server supporting the compressed transmission capability periodically parses and counts the received IP data packet to form or update a rule in the compression policy. If the rule in the compression policy of the server changes, the server sends an update request message to the terminal, where the update request message carries the rule number corresponding to the changed rule, and the specific content of the new rule.
  • Step 304 When receiving the update request message, the terminal acquires new rule information carried in the update request message, updates the corresponding rule in the compression policy, and returns an update request response to the server.
  • the server may repeatedly send the update request message to the terminal according to a preset time interval (for example, 2 seconds).
  • a preset time interval for example, 2 seconds. The server considers that the update is complete as soon as it receives an update request response from the terminal; if the update request response from the terminal is not received, the server continues to send the update request message until an update request response from the terminal is received.
  • FIG. 4 is a schematic diagram of a structure of a protocol class rule according to an embodiment of the present invention.
  • a protocol class rule may be embodied in the form of a rule table, where a plurality of protocol class rules are accommodated in the rule table.
  • the terminal maintains a protocol class rule table for each server's IP address, and the rules in the protocol class rule table are all for the same server; after the terminal ends the communication with the server, all the servers for the server will be released. Rule information. Multiple rules in the same rule table have unique rule numbers to distinguish multiple rules by rule number.
  • the server also stores a protocol rule table similar to the content of the rule table stored by the terminal.
  • FIG. 4 lists three rules stored in the terminal.
  • the types of the three rules are Hypertext Transfer Protocol (HTTP) GET request type, and Internet Control Message Protocol (ICMP) Ping request type.
  • ICMP Internet Control Message Protocol
  • DNS Domain Name System
  • FIG. 5 is a schematic diagram of a structure of a content class rule according to an embodiment of the present invention.
  • a content class rule may be embodied in the form of a rule table, and the terminal maintains one IP address for each server.
  • each rule is distinguished by a unique rule number.
  • the server When generating and maintaining content class rules, the server maintains different content class rule tables for terminals with different IP addresses. For the same terminal, different data streams from different applications are distinguished. There are many ways to distinguish data streams, such as port numbers.
  • the server detects each port number. For example, the data packets received on port M will be matched using rule M, and the data packets received on port N will be matched using rule N. This avoids the problem of traversing all the rules in the rules table every time a packet is received.
  • the port number field is populated with the port number of the server.
  • the rule description method of the content table of the content class in the embodiment of the present invention may be offset value/length/value (Offset/Len/ Value) method to describe.
  • FIG. 6 is a schematic diagram of a structure of decompression information in an embodiment of the present invention, where decompression information may be carried in a modified record field of one byte of a second data packet to be sent, as shown in FIG. 6, and FIG. 6 shows a modified record field. Field format.
  • the terminal in the embodiment of the present invention processes the first data packet to be sent by using the compression policy, and after deleting the specified duplicate data included in the compression policy in the first data packet, generates a modified record field information of one byte, and the The modified record field is placed in the header of the data portion of the first data packet to generate a second data packet; and after receiving the second data packet, the server restores the second data packet according to the information of the modified record field. Therefore, it is very important to modify the record field.
  • the modified record field includes three fields: a rule enable indicator of 1 bit (bit), indicating whether the second data packet in which the modified record field is located has passed the first data to be sent by using the compression policy.
  • bit a rule enable indicator of 1 bit
  • the rule enable indication is valid and can be set to 1. If not, the rule enable indication is invalid, and can be set to 0; the rule type of 1 bit
  • the rule type indication is 0, indicating that the rule for processing the first data packet by the sending end is a protocol type rule, and the rule type indicating that the rule is 1 indicates that the rule for processing the first data packet by the sending end is a content class rule.
  • a rule number indicating which rule is used by the sender for processing the first packet.
  • the maximum number of rules is set to 64, that is, the rule number ranges from 0 to 64. Therefore, the last 6 bits of the modified record field can be used to record the rule number.
  • FIG. 7 is a flowchart of a data transmission method according to another embodiment of the present invention.
  • the first data packet to be sent is first processed by a protocol class rule. After skipping the content class rule processing flow, the processed first data packet is directly generated into the second data packet and the second data packet is sent; if no matching protocol class rule is found, the content class rule processing flow is entered.
  • the data transmission method provided in this embodiment includes:
  • Step 700 The user equipment (UE) receives the IP packet sent by the upper layer application, and acquires the destination IP address and the upper layer protocol type.
  • Step 701 to step 702 Check whether the UE saves the transmission record corresponding to the destination IP address, and if so, reads the record, and proceeds to step 704; if there is no corresponding transmission record, the UE corresponds to the destination IP address for the first time.
  • the server needs to query whether the server supports compressed transmission first, and proceeds to step 703.
  • Step 703 Determine whether the server corresponding to the destination IP address supports the compressed transmission capability. If not, go to step 714; if yes, go to step 705.
  • Step 704 Record whether the server corresponding to the destination IP address supports the compressed transmission capability. If the compression transmission capability is supported, the process proceeds to step 705. If the compression transmission capability is not supported, the process proceeds to step 714.
  • Step 705 Check whether there is a protocol class rule corresponding to the destination IP address and the upper layer protocol type. If yes, go to step 706; if not, go to step 713.
  • Step 706 to step 707 It is determined whether the detection period is reached. In the embodiment of the present invention, whether the detection period is reached can be determined by, for example, the timer T1 or the counter C1. If the detection period has not been reached, then no detection is made, proceeding to step 707 to continue counting or counting and performing step 710; if the detection period is reached, proceeding to step 708.
  • a timer if a timer is used, it can be set to be detected every 10 seconds. If a counter is used, then every 5 data packets can be set to be detected once.
  • the specific threshold can be changed by adjusting the value of the timer T1 or the counter C1 according to the application requirements.
  • Step 708 to step 709 Detect the content of the field in the IP packet, and determine whether it matches the Len and Value contents in the description of the corresponding protocol class rule. If the two are the same, that is, match, reset the timer T1 or the counter C1, and enter the step. 710; if the two are not the same, that is, the matching does not match, and the process proceeds to step 712.
  • Step 710 Process the IP packet according to the rule, delete the duplicate data, generate a modified record field, fill the original IP packet, and modify the updated IP packet header information.
  • Step 711 Send the processed IP packet to the server.
  • Step 712 Delete the protocol class rule locally of the UE.
  • Step 713 Transfer to the process of processing the IP packet according to the content class rule for further processing.
  • Step 714 Send the original IP packet to the server without processing. End this process.
  • the data packet may be sent by using a common data transmission method in the related art, that is, the first data packet is not processed, and is directly sent to the receiving end.
  • FIG. 8 is a schematic flowchart of a data transmission method according to another embodiment of the present invention.
  • This embodiment is a flowchart of processing a data packet according to a content class rule.
  • the data packet that executes the process shown in FIG. 8 is a data packet that has been filtered by the protocol class rule and does not meet the required protocol class rules.
  • the method provided in this embodiment includes:
  • Step 800 The UE receives the original IP packet of the upper layer application, obtains the destination IP address and port, and checks whether there is a content class rule for the destination IP address and port. If not, go to step 805; if there is a corresponding content class rule, Go to step 802.
  • Step 802 Check whether the content of the specific location in the IP packet is the same as the content described in the corresponding rule. If yes, go to step 803; if not, go to step 804.
  • Step 803 Process the IP packet according to the rule, delete the duplicate data, generate a modified record field, and fill it into the original IP packet, and then proceed to step 806.
  • Step 804 Delete the content class rule locally of the UE.
  • Step 805 Generate a modified record field and fill it with all 0s, and fill the generated modified record field into the original IP packet.
  • Step 806 Send the modified IP packet to the server.
  • the application of the technical solution provided by the embodiment of the present invention is described below in conjunction with an actual scenario.
  • the UE in this embodiment is described by taking a smart watch with a positioning function as an example.
  • the watch periodically sends the latitude and longitude of the UE to the server in the form of a User Datagram Protocol (UDP) packet. It also intermittently interacts with the network HTTP to obtain business content such as newsletters.
  • UDP User Datagram Protocol
  • each data packet of the user's upper application is sent to the network side through the wireless protocol stack, that is, how much data is generated by the application, and how much data the terminal sends.
  • the technical solution provided by the embodiment of the present invention can significantly reduce the amount of data actually transmitted.
  • the packet fragment shown in Table 1 below is the IP packet information that the smart watch sequentially sends to the network (in this embodiment, the downlink packet has been filtered out, and only the uplink packet is displayed here).
  • the serial number and time stamp are superimposed, the source IP address is the IP address of the terminal, and the destination IP address is the IP address of the server.
  • the type indicates the protocol type above the IP layer. In this embodiment, the types include HTTP GET and UDP.
  • the HTTP packet is used to communicate with the port 80 of the server to obtain miscellaneous business content such as pictures and news.
  • the UDP packet is a packet sent by the terminal to the port of the server 2001, and the information carried therein is in a fixed format and is the GPS latitude and longitude information of the terminal, for example, (34.2606986937, 108.9444049731). The data in these packets will be shown later.
  • HTTP data 1 contains multiple fields, each of which contains specific information.
  • the User-Agent field describes what operating system (including version number) and browser (including version number) information used by the terminal
  • the information of the Accept-Charset field describes the character set supported by the browser, and so on.
  • the name and meaning of each field is the standard specification of the HTTP protocol, and will not be described here.
  • the server When the server analyzes and counts these data packets, it will be counted that the User-Agent and Accept-Charset fields have not changed at all. Therefore, the server will generate a request for this HTTP Get and for the terminal corresponding to the source IP address. Protocol-type rule information, and the protocol-type rule information is synchronized to the terminal. After synchronization, the protocol-type rule information saved by the terminal is as shown in Table 2:
  • the protocol type of the rule P-Policy1 is HTTP GET type. It also includes a rule description with two fields, namely the User-Agent field and the Accept-Charset field. The contents of the two fields are listed separately in the rule. In fact, the contents of the User-Agent field and the Accept-Charset field in the HTTP GET request sent to the server are unchanged.
  • the UE will use the rule P-Policy1 to delete the two fields in the HTTP packet, and in the payload data portion of the HTTP packet.
  • the first byte plus a 1-byte modified record field to inform the server that the HTTP packet is compressed, and tells the server which rule to use for compression, so that the server can recover.
  • the value of the modified record field is 0x81, the distribution of each bit is as shown in Table 3, and the value of the rule enable indication is 1, indicating that the HTTP packet has been compressed; the value of the rule type 0, indicating that the rule according to the compression processing of the HTTP packet is a protocol type rule; the rule number represents the number of the rule, and the number is unified in the UE and the server.
  • the HTTP packet is assumed to be compressed and processed.
  • the rule number of the rule is 1.
  • packets Nos. 3, 4, and 6 sent by the smart watch are UDP packets, and it is assumed that the GPS information of the terminal sent by the same application is sent to the port 2001 of the server 203.29.132.6.
  • the three data contents carried by the UDP packet are as follows:
  • the server periodically collects the UDP packet received on the port 2001, and generates a content class rule information for the IP address of the terminal, and synchronizes the content rule information to the terminal.
  • the terminal saves the content class rule information as shown in Table 7:
  • the rule C-Policy1 describes the case of two content fields, which are respectively located at the data of the two ends of the UDP packet payload data offset values of 8 and 21 and lengths of 4 and 6, respectively, as shown in Table 7, respectively. "34.2” and ".108.9".
  • the reason for these two pieces of data is that the user of the terminal has a range of activities within a clock tower or city wall for a period of time. It is very common for a normal user to be active within a certain range for a certain period of time, so the content class rules of this case are also easy to generate.
  • the two fields in the content of the UDP packet are deleted by using the rule C-Policy1, and the first byte of the payload data portion of the UDP packet is loaded.
  • Add a 1-byte modified record field to inform the server that the UDP packet is compressed, and tell the server which rule to use for compression, so that the server can recover the UDP packet.
  • the value of the modified record field is 0xC1
  • the distribution of each bit is as shown in Table 8
  • the value of the rule enable indication is 1, indicating that the UDP packet has been compressed
  • the value of the rule type A rule indicating that the UDP packet is compressed is a content class rule
  • the rule number represents the number of the rule, and the number is unified between the UE and the server.
  • the rule number is assumed to be 1.
  • the server then synchronizes the rules with the UE.
  • the rule is synchronized, when the UE sends the HTTP packet No. 7, it will compress it according to the HTTP GET protocol rule, and remove the specified item in the protocol.
  • the content of the processed HTTP packet is shown in Table 9, and the table 9 is drawn.
  • the dropped information is not transmitted, and 145 bytes of content are transmitted less than the original packet. That is, the processed data packet is reduced by 36.7% of the data amount.
  • the duplicate content is removed, and the transmission efficiency is improved.
  • the specified data is removed according to the content class rule.
  • the content of the processed UDP packet is shown in Table 11, and the information that is crossed out in Table 11 is not transmitted.
  • the data deleted in this embodiment is "34.2" and ".108.9”
  • the processed UDP packet contents are as follows, and less than 9 bytes of content are transmitted compared to the original data packet. That is, the processed UDP packet reduces the amount of data by 32.1%.
  • the number of sent data packets will be more and more as the UE continues to work, and the technical solution provided by the embodiment of the present invention saves resources. The effect will be more and more significant.
  • the source address and the source IP address in the above embodiment have the same meaning, and the destination address and the destination IP address have the same meaning.
  • the embodiment of the present invention further provides a computer readable storage medium storing computer executable instructions for performing a data transmission method provided by any embodiment of the present invention.
  • FIG. 9 is a schematic structural diagram of a structure for implementing a data transmission apparatus according to an embodiment of the present invention. As shown in FIG. 9, at least a compression module 910, a processing module 920, a sending module 930, and a first storage configured to store a compression policy are provided. Module 940; wherein
  • the compression module 910 is configured to: process the first data packet to be sent by using the compression policy in the first storage module 940, and delete the specified duplicate data included in the compression policy in the first data packet;
  • the processing module 920 is configured to: generate the second data packet to be sent by using the processed first data packet, where the second data packet includes a modified record for indicating duplicate data deleted according to the compression policy Field
  • the sending module 930 is configured to: send the second data packet.
  • the compression policy includes a plurality of rules for comparing whether the first data packet to be sent by the sending end includes the basis information that has duplicate content with the previously sent data packet.
  • the compression module 910 is configured to:
  • the first data packet to be sent is periodically compared, the first data packet and the destination address in the compression policy are compared with the destination address of the first data packet, and the first data packet is checked.
  • the compression module 910 is further configured to delete the rule in the compression policy if it is checked that the above field or content in the first data packet is different from the corresponding field or content in the rule description.
  • the compression policy includes at least: a protocol class rule that is mainly distinguished by a protocol type, and a content class rule that is mainly distinguished by an application type.
  • the compression module 910 is configured to:
  • the compression policy stores a protocol type rule in which the destination address is consistent with the destination address of the first data packet to be sent
  • the first data packet to be sent and the destination address in the compression policy are periodically periodically. Comparing with a protocol class rule that is consistent with a destination address of the first data packet to be sent, checking whether there is a field or content in the first data packet that is the same as the field or content described in the protocol class rule; if yes, Checking that the foregoing field or content in the first data packet matches the compression policy, deleting the same field or content in the first data packet as the field or content described in the protocol class rule, that is, deleting the first data The content of the packet that is duplicated with the previously sent packet;
  • the periodicity is Comparing the first data packet to be sent and the content class rule in the compression policy that matches the destination address of the first data packet to be sent, and checking whether the specified content in the first data packet is related to the content class rule
  • the corresponding field or content in the same is the same; if the same, that is, the above field or content in the first data packet is matched with the compression policy, deleting the above field or content in the first data packet, that is, deleting the first data packet The content that is duplicated with the previously sent packet.
  • the apparatus provided by the embodiment of the present invention further includes a detecting module 950, configured to: confirm that the receiving end supports a compressed transmission capability, and if the compressed transmission capability is supported, trigger the compression module to perform processing;
  • the detecting module 950 is configured to: send a query request to the receiving end, and determine that the receiving end supports the compressed transmission capability after receiving the response from the receiving end; or
  • the triggering module 950 performs processing; when it is confirmed that the receiving end does not support the compressed transmission capability, the first data packet is not processed and directly sent to the receiving end.
  • the querying whether the receiving end supports the compressed transmission capability may further include:
  • the sending end sends a preset number of times (for example, 3 times) to the server according to a preset time interval (for example, 2 seconds). If the sending end does not receive any query response, the receiving end does not support the compressed transmission capability; When the terminal receives at least one query response, it considers that the receiving end supports the compressed transmission capability.
  • the time interval and the number of transmissions may be configured according to an application scenario.
  • the apparatus provided by the embodiment of the present invention further includes: an obtaining module 960, configured to: acquire a compression policy from the receiving end by using a control path. That is, the synchronization of rules in the compression policy between the receiving end and the transmitting end is implemented.
  • the obtaining module 960 is further configured to: after obtaining the compression policy, return the confirmation information to the receiving end.
  • the control path is from the TCP/IP level, and is a path that distinguishes between actual user data.
  • the control path refers not to the control plane of the 3GPP wireless protocol stack, and the control path still belongs to the user plane.
  • the control path can be determined by a fixed port set in advance.
  • the modified record field is set at the beginning of the load of the second data packet.
  • modifying the record field may include:
  • the rule enable indication is used to indicate whether the second data packet in which the modified record field is located has been processed by step 100. For example, if the processing has been processed, the rule enable indication is valid, and may be set to 1, if not processed, The rule enable indication is invalid and can be set to 0.
  • the rule type indication is used to indicate the type of the rule to be used for the processing of the first data packet to be sent. For example, the rule type indication is 0, indicating that the first data packet is processed by using the protocol type rule, and the rule type indication is 1, indicating that the first data packet is processed by using a content class rule;
  • the transmitting module 930 may be an enhanced machine type communication/narrowband Internet of Things (eMTC/NB-IoT) wireless protocol stack.
  • eMTC/NB-IoT enhanced machine type communication/narrowband Internet of Things
  • the apparatus for implementing data transmission provided by the embodiment of the present invention shown in FIG. 9 deletes the repeatedly transmitted information in the data packet to be transmitted, thereby reducing the amount of data actually transmitted; and reducing the actual amount of data transmitted, operating
  • the user plane of the quotient network also has the effect of mitigating the load. Therefore, the productization of the technical solution provided by the embodiment of the present invention is very easy.
  • the device in the embodiment of the present invention is directly applied between the terminal nodes and the server, and is transparent to the network operator, so that the device can be directly applied, and the operator does not need to add additional hardware and software costs, and does not need additional hardware support. Therefore, the reduction in the amount of data actually transmitted is simply achieved, thereby saving costs.
  • the embodiment of the present invention further provides a terminal, including any device for implementing data transmission related to FIG. 9 above.
  • the method includes at least a receiving module 1010, a decompression module 1020, and a second storage module 1030 configured to store a compression policy.
  • the receiving module 1010 is configured to: receive the second data packet from the sending end, and check that the second data packet carries a modified record field for indicating that the sending end deletes the duplicate data according to the compression policy;
  • the decompression module 1020 is configured to: perform recovery processing on the second data packet according to the modified record field and the compression policy stored in the second storage module to generate the first data packet.
  • the device provided by the embodiment of the present invention further includes: a generating module 1040 and a synchronization module 1050; wherein
  • the generating module 1040 is configured to: periodically detect the received data packet, and generate a compression policy
  • the synchronization module 1050 is configured to: send the generated compression policy including the specified duplicate data to the sending end through the control path.
  • the generating module 1040 is configured to:
  • the generating module 1040 is further configured to: change the compression policy, and synchronize the updated compression policy to the transmitting end.
  • the decompression module 1020 is configured to:
  • the corresponding compression policy stored by the server is searched according to the source IP address of the data packet and the rule type in the modified record field, and the rule number information, and the repeated specified by the compression policy is utilized.
  • the data is restored to the second data packet to generate the original first data packet.
  • the embodiment of the present invention further provides a server, including any of the implementation data transmission devices related to FIG. 10 described above.
  • the embodiment of the present invention deletes the data repeatedly sent in the data packet to be sent, which reduces the amount of data actually transmitted; at the same time, the operator does not need to additionally increase the hardware and software cost, and does not need additional hardware support, so the implementation is simply implemented. The amount of data actually transmitted is reduced, thereby saving costs.

Abstract

一种数据传输方法及装置，该方法包括：利用从接收端预先获得的压缩策略对待发送的第一数据包进行处理，删除第一数据包中所述压缩策略包括的指定的重复数据；将处理后的所述第一待数据包生成待发送的第二数据包，其中所述第二数据包中包括用于指示删除的重复数据的修改记录字段；将所述第二数据包发送给接收端。

Description

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

Claims (22)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
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

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO2019007114A1 true WO2019007114A1 (zh) 2019-01-10

Family

ID=60197774

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/081517 WO2019007114A1 (zh) 2017-07-03 2018-04-02 数据传输方法及装置

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 (5)

* 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系统中数据包的压缩方法和装置
CN107332909A (zh) * 2017-07-03 2017-11-07 中兴通讯股份有限公司 一种实现数据传输的方法及装置

Family Cites Families (7)

* 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 画像処理装置及びその処理方法
WO2013064185A1 (en) * 2011-11-03 2013-05-10 Telefonaktiebolaget Lm 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控股有限责任公司 用于存储设备的数据迁移的方法和装置
US10785341B2 (en) * 2016-11-21 2020-09-22 Intel Corporation Processing and caching in an information-centric network

Patent Citations (5)

* 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系统中数据包的压缩方法和装置
CN107332909A (zh) * 2017-07-03 2017-11-07 中兴通讯股份有限公司 一种实现数据传输的方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3651438A4 *

Also Published As

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

Similar Documents

Publication Publication Date Title
WO2019007114A1 (zh) 数据传输方法及装置
Kovatsch et al. A low-power CoAP for Contiki
US10212654B2 (en) Neighbor discovery to support sleepy nodes
US10708885B2 (en) Methods and nodes for enabling context-awareness in CoAP
US20160219125A1 (en) Method and apparatus for implementing subscription notification
CN104348811A (zh) 分布式拒绝服务攻击检测方法及装置
CN105357283B (zh) 智能可佩戴设备的长连接建立方法及服务器、终端
EP2817941A1 (en) Method and apparatus for dynamic server!client controlled connectivity logic
EP3138020A1 (en) Search engine optimization for resource directory
Hahm et al. A named data network approach to energy efficiency in IoT
EP3828669A1 (en) Communication between client device and server
CN106209325A (zh) 一种tcp ack报文处理方法及装置
Skjegstad et al. Mist: A reliable and delay-tolerant publish/subscribe solution for dynamic networks
KR101634822B1 (ko) 상이한 네트워크들을 통해 데이터를 동기화하기 위한 어댑터
CN103647666A (zh) 一种统计呼叫详细记录报文并实时输出结果的方法及装置
US20220053309A1 (en) Apparatus, Method and Program for Transmitting and Receiving Data to and From IOT Device
CN102594611B (zh) 一种网管代理更新Trap会话链表的方法
Kangasharju et al. XML messaging for mobile devices: From requirements to implementation
CN109922159B (zh) 一种物联网设备间云端双向虚拟连接的方法
CN107548105B (zh) 一种基于udp的数据传输确认方法和基站
Kaisar Smartphone traffic characteristics and context dependencies
Savolainen et al. Measuring energy consumption for RESTful interactions in 3GPP IoT nodes
JPWO2019189597A1 (ja) サーバ、通信システム、通信方法及びプログラム
RU2013104425A (ru) Способ активации, устройство активации и система связи
CN114189565B (zh) 一种头域还原系统、方法及相关设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18827476

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018827476

Country of ref document: EP

Effective date: 20200203