CN116074394A

CN116074394A - Message compression transmission method and system

Info

Publication number: CN116074394A
Application number: CN202211117240.0A
Authority: CN
Inventors: 赵春平; 张锦; 郝登峰; 钱国良; 李巍; 彭海波
Original assignee: State Grid Sigi Ziguang Qingdao Microelectronics Technology Co ltd
Current assignee: State Grid Sigi Ziguang Qingdao Microelectronics Technology Co ltd
Priority date: 2022-09-14
Filing date: 2022-09-14
Publication date: 2023-05-05

Abstract

The embodiment of the invention provides a message compression transmission method and a message compression transmission system, and belongs to the technical field of wireless communication. The method is executed by a compression end, and comprises the following steps: generating an original message based on the request service; performing first compression on the original message to obtain a first compressed message; encapsulating the first compressed message based on an IPSec tunnel mode, and performing second compression on the encapsulated first compressed message to obtain a second compressed message; determining a transmission network of the second compressed message, and adding a corresponding network label to the second compressed message to obtain a third compressed message; and transmitting the third compressed message to a corresponding decompression end based on the determined transmission network. The scheme of the invention realizes the compression processing of the original IP header and the IPSec header in the IPSec security and tunnel encapsulation processing, thereby improving the transmission efficiency of the air interface and the load-bearing transmission efficiency of the network side.

Description

Message compression transmission method and system

Technical Field

The invention relates to the technical field of wireless communication, in particular to a message compression transmission method and a message compression transmission system.

Background

IPv6 (Internet Protocol Version, internet protocol version 6) is used as a next generation network protocol, has the advantages of rich address resources, automatic address configuration, high safety and the like, and can meet the requirements of the next generation communication network on IP addresses. The complete IPv6 header is 40 bytes long, the UDP (User Datagram Protoco, user datagram protocol) header is 8 bytes long, and the effective data transmission rate is lower for small data packet transmission with the length not exceeding 100 bytes in the scenes of industry private network and the like. In order to ensure the safety of industry private network communication, an IPSec tunnel mode is used for protecting the safe transmission of all original IP data messages, wherein the IPSec tunnel mode is used for packaging new IP headers on the basis of the original IP messages, which is equivalent to adding the IP headers with the length of 40 bytes on the basis of the original IP messages, so that the effective data transmission rate is lower, and obviously, the header compression has very important practical significance.

For message header compression, there are some methods for implementing ethernet message header compression and decompression functions at PDCP (Packet Data Convergence Protocol ) layer, and there are also methods for implementing compression context feedback through MAC CE. In summary, the existing message compression mechanism is mainly focused on header such as single-layer IP, and optimization of PDCP layer compression mechanism of ethernet message air interface, and does not consider compression problem of two-layer IP header in IPSec ESP (IPsec Encapsulating Security Payload, encapsulating security load protocol) tunnel mode. Even if the existing method for header compression is adopted, the compression effect is still prioritized, and the method is not applicable to the IPv6 efficient transmission. Aiming at the problem that the existing message compression method can not realize efficient header compression, a new message compression transmission method needs to be created.

Disclosure of Invention

The embodiment of the invention aims to provide a message compression transmission method and a system, which at least solve the problem that the existing message compression method can not realize efficient header compression.

In order to achieve the above object, a first aspect of the present invention provides a method for packet compression transmission, where the method is performed by a compression end, and the method includes: generating an original message based on the request service; performing first compression on the original message to obtain a first compressed message; encapsulating the first compressed message based on an IPSec tunnel mode, and performing second compression on the encapsulated first compressed message to obtain a second compressed message; determining a transmission network of the second compressed message, and adding a corresponding network label to the second compressed message to obtain a third compressed message; and transmitting the third compressed message to a corresponding decompression end based on the determined transmission network.

Optionally, the request service includes: the service request type initiated by the user terminal or the service request type fed back by the application server.

Optionally, before the first compression is performed on the original packet, the method further includes: judging whether an application server address matched with a destination IP address in the original message exists or not; if so, executing the first compression; and if the message does not exist, packaging the original message, and performing second compression on the packaged original message to obtain a second compressed message.

Optionally, performing first compression on the original message to obtain a first compressed message, including: identifying a destination IP address and a source IP address in the original message; and deleting the destination IP address and the source IP address from the original message to obtain a first compressed message.

Optionally, the performing the second compression on the encapsulated first compressed packet to obtain a second compressed packet includes: and deleting the IP address of the IPSec server and the IP address of the IPSec client in the packaged first compressed message to obtain a second compressed message.

Optionally, when the request service is a service request type fed back by the application server, determining a transmission network of the second compressed packet includes: and determining an LTE network or a 5G network as a transmission network of the second compressed message.

Optionally, the adding the corresponding network tag to the second compressed packet to obtain a third compressed packet includes: and adding the VLAN Tag of the service application group of the current application server into the second compressed message to obtain a third compressed message.

Optionally, when the request service is a service request type initiated by the user terminal, determining the transmission network of the second compressed packet includes: determining a corresponding network access mode based on the second compressed message; based on the pre-built ESP bearing/QoS flow or the real-time built ESP bearing/QoS flow and the determined network connection mode, performing PDCP layer compression on the second compressed message, and sending the second compressed message compressed by the PDCP layer to a corresponding decompression end.

Optionally, the network access mode includes: either of the APN mode and the DNN mode.

Optionally, the selection rules of the pre-built ESP bearer/QoS flow and the real-time built ESP bearer/QoS flow are: judging whether a network access mode session is established currently; if the network access mode session is established, further judging whether an EPS bearing/QoS flow matched with a service forwarding descriptor of the second compressed message exists currently; if so, using the EPS bearing/QoS flow matched with the service forwarding descriptor of the second compressed message as the pre-built ESP bearing/QoS flow to compress the PDCP layer of the second compressed message; if not, the service forwarding descriptor based on the second compressed message builds EPS bearing/QoS flow in real time, and compresses the PDCP layer of the second compressed message by using the ESP bearing/QoS flow built in real time; if the network access mode session is not established, establishing the network access mode session, and setting up EPS bearing/QoS flow in real time based on a service forwarding descriptor of the second compressed message, and compressing the PDCP layer of the second compressed message by using the ESP bearing/QoS flow set up in real time.

Optionally, the adding the corresponding network tag to the second compressed packet to obtain a third compressed packet includes: searching whether a service application group corresponding to the ESP bearing/QoS flow carrying the second compressed message exists or not; if so, searching the IP address of the terminal corresponding to the ESP bearing/QoS flow and the VLAN Tag of the corresponding service application group, and adding the search result into the second compressed message to obtain a third compressed message.

The second aspect of the present invention provides a method for packet compression transmission, where the method is performed by a decompression end, and the method includes: receiving a third compressed message sent by a compression end based on a request service type, and deleting a network tag in the third compressed message to obtain a second compressed message; decompressing the second compressed message for the first time, and decompressing the decompressed second compressed message based on an IPSec tunnel mode to obtain a first compressed message; and decompressing the first compressed message for the second time to obtain an original message.

Optionally, the request service type includes: the service request type initiated by the user terminal or the service request type fed back by the application server.

Optionally, when the request service type is a service request type initiated by the user terminal, decompressing the second compressed packet for the first time includes: acquiring a service application group identifier of a second compressed message; locally retrieving an IPSec server IP address based on the service application group identification; and adding the IP address of the IPSec server to the second compressed message to finish the first decompression of the second compressed message.

Optionally, decompressing the first compressed message for the second time to obtain an original message, including: taking the IP address of the corresponding application server as a destination IP address and taking the IP address of the IPSec client as a source IP address; and adding the destination IP address and the source IP address into the first compressed message to obtain an original message.

Optionally, when the request service type is a service request type fed back by the application server, before the first decompression is performed on the second compressed packet, the method further includes: obtaining a second compressed message, including: judging whether PDN connection and EPS bearing corresponding to the current decompression end exist or not based on parameters of a service application group corresponding to an application server; if yes, judging whether the current EPS bearing meets the requirement or not; if the request is met, acquiring a second compression message based on the current EPS bearing; if the request is not met, a new EPS bearing is established, and a second compression message is acquired based on the new EPS bearing; if not, establishing PDN connection and EPS bearing of the access APN, and acquiring a second compression message based on the established EPS bearing.

Optionally, the first decompressing of the second compressed packet includes: acquiring a service application group identifier of a second compressed message; based on the service application group identification, locally searching an IPSec server address and a decompression end IP address corresponding to the service application group; and adding the IPSec server address and the decompression end IP address into the second compressed message to finish the first decompression.

Optionally, decompressing the first compressed message for the second time to obtain an original message, including: based on the service application group identification, locally searching an application server address and a decompression end IP address; and adding the address of the application server and the IP address of the decompression end into the first compressed message to obtain an original message.

A third aspect of the present invention provides a compression end, configured to execute the foregoing packet compression transmission method, where the compression end includes: the generating unit is used for generating an original message based on the request service; the compression unit is used for carrying out first compression on the original message to obtain a first compressed message; the encapsulation unit is used for encapsulating the first compressed message based on the IPSec tunnel mode; the compression unit is also used for carrying out second compression on the packaged first compressed message to obtain a second compressed message; a processing unit for: determining a transmission network of the second compressed message, and adding a corresponding network label to the second compressed message to obtain a third compressed message; and transmitting the third compressed message to a corresponding decompression end based on the determined transmission network.

A fourth aspect of the present invention provides a compression end decompression end, configured to execute the foregoing packet compression transmission method, where the decompression end includes: the acquisition unit is used for receiving a third compressed message sent by the compression end based on the request service type, deleting a network tag in the third compressed message and obtaining a second compressed message; the decompression unit is used for decompressing the second compressed message for the first time; the unpacking unit is used for unpacking the first decompressed second compressed message based on the IPSec tunnel mode to obtain a first compressed message; the decompression unit is further configured to decompress the first compressed message for a second time, to obtain an original message.

A fifth aspect of the present invention provides a packet compression transmission system, where the system includes the compression end and the decompression end.

Optionally, the decompression end and the compression end are user terminals or IPSec servers; when the compression end is a user terminal, the corresponding decompression end is an IPSec server; when the compression end is an IPSec server, the corresponding decompression end is a user terminal.

In another aspect, the present invention provides a computer readable storage medium having instructions stored thereon, which when executed on a computer cause the computer to perform the above-mentioned packet compression transmission method.

By the technical scheme, for a data sender, in an IPSec tunnel mode, the original message header compression processing is carried out before the IPSec security and tunnel encapsulation processing, and the IPSec header compression processing is carried out after the IPSec security and tunnel encapsulation processing. For the data receiver, in the IPSec tunnel mode, an IPSec header decompression process is performed before the IPSec security and tunnel encapsulation process, and an original packet header decompression process is performed after the IPSec security and tunnel encapsulation process. And then, on the premise of keeping compression and decompression means of the PDCP layer, the header compression efficiency is greatly realized, and the compression processing of the original IP header and the IPSec header is realized in IPSec security and tunnel encapsulation processing, so that the air interface transmission efficiency is improved, and the network side bearing transmission efficiency is also improved.

Additional features and advantages of embodiments of the invention will be set forth in the detailed description which follows.

Drawings

The accompanying drawings are included to provide a further understanding of embodiments of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain, without limitation, the embodiments of the invention. In the drawings:

FIG. 1 is a flowchart illustrating steps of a message compression transmission method according to an embodiment of the present invention;

fig. 2 is a diagram illustrating a message format change during uplink data transmission according to an embodiment of the present invention;

fig. 3 is a diagram illustrating a message format change during downlink data transmission according to an embodiment of the present invention;

FIG. 4 is a schematic view of a compression end according to one embodiment of the present invention;

fig. 5 is a schematic structural diagram of a decompression end according to an embodiment of the present invention.

Detailed Description

The following describes specific embodiments of the present invention in detail with reference to the drawings. It should be understood that the detailed description and specific examples, while indicating and illustrating the invention, are not intended to limit the invention.

The IPv6 (Internet Protocol Version 6) is used as a next generation network protocol, has the advantages of rich address resources, automatic address configuration, high safety and the like, and can meet the requirements of the next generation communication network on IP addresses. The complete IPv6 header is 40 bytes long, the UDP header is 8 bytes long, and the effective data transmission rate is lower for small data packet transmission with the length not exceeding 100 bytes in the scenes such as industry private network and the like. In order to ensure the safety of industry private network communication, an IPSec tunnel mode is used for protecting the safe transmission of all original IP data messages, wherein the IPSec tunnel mode is used for packaging new IP headers on the basis of the original IP messages, which is equivalent to adding the IP headers with the length of 40 bytes on the basis of the original IP messages, so that the effective data transmission rate is lower, and obviously, the header compression has very important practical significance.

A PDCP (Packet Data Convergence Protocol ) sublayer, which specifies a radio interface protocol stack in an LTE/5G system, supports a robust header compression protocol (ROHC) defined by IETF (internet engineering task force) for header compression and decompression in order to save radio bandwidth resources and improve efficiency of data transmission.

ROHC (Robust Header Compression ) is a relatively sophisticated header compression mechanism. RFC3095 defines three states for the ROHC compression end: an IR (Initialization and Refresh, initial refresh) state, a FO (First Order) state, and a SO (Second Order) state; the decompression side has three states: NC (No Context), SC (Static Context), and FC (Full Context) states. The compression end gradually rises from the lowest compression state IR to the highest compression state SO. When the compression end is in an IR state, transmitting complete header information to the decompression end; when the decompression end successfully establishes the static context (context) of the header, the state of the compression end is converted from IR to FO, and the compression end sends partial compressed header information; when the compression end is in the SO state, only the dynamic information of the header is transmitted. Similarly, the decompression end also performs corresponding compression state upgrade: NC- (SC-) FC. If the context established by the decompression end is not matched with the received compressed packet information, the states of the compression end and the decompression end are switched from a higher state to a lower state. The PDCP layer in the LTE/5G system only realizes header compression and decompression of the air interface transmission message, and in the IPSec tunnel mode, the PDCP layer in the LTE/5G system only can compress and decompress the outer IPSec header, but cannot compress and decompress the inner original IP header, so that the header compression efficiency of the data message is lower, and the system transmission cost is higher.

For message header compression, there are some methods for implementing ethernet message header compression and decompression functions in PDCP layer, and there are also methods for implementing compression context feedback through MAC CE. In general, the existing message compression mechanism is mainly focused on header such as single-layer IP, and optimization of PDCP layer compression mechanism of ethernet message air interface, and compression problem of two-layer IP header in IPSec ESP tunnel mode is not considered. Even if the existing method for header compression is adopted, the compression effect is still prioritized, and the method is not applicable to the IPv6 efficient transmission. Aiming at the problem that the existing message compression method can not realize efficient header compression, a new message compression transmission method needs to be created.

The message compression transmission method provided by the scheme of the invention realizes the original IP header compression and the outer IPSec header compression in the IPSec tunnel mode respectively through two compression and decompression processes, thereby achieving the purposes of improving the compression efficiency and reducing the transmission overhead of LTE/5G air interfaces and the network transmission overhead.

For convenience of explanation of the scheme, first, a system architecture is described in detail, and a corresponding compression method needs to be implemented based on the architecture. First, a service application group is identified by a service application group identifier and an application server address unique identifier. A service application group corresponds to a "service application group descriptor", which includes a service application group identifier, an application server address, an IPSec server end address, and a service forwarding descriptor (mainly describing QoS requirements for service transmission). The LTE/5G user acquires parameters of the service application group by signing the service application group for establishing compression context, and one LTE/5G user can sign a plurality of service application groups.

When the LTE/5G user signs up for one or more service application groups, the LTE/5G air interface protocol stack processing unit receives one or more service application group descriptors from the network side, and each service application group descriptor comprises a service application group identifier, APN (Access Point Name)/DNN (Data Network Name), an application server address, an IPSec server end address and a service forwarding descriptor. The LTE/5G air interface protocol stack processing unit stores the received service application group descriptor, and simultaneously sends the service application group identifier, the application server address and the IPSec server end address to the IPSec processing unit, and the IPSec processing unit receives and stores the service application group identifier, the application server address and the IPSec server end address.

In a possible implementation manner, when the compression end is a user terminal, the corresponding decompression end is an IPSec server; when the compression end is an IPSec server, the corresponding decompression end is a user terminal. The compression end is mapped into the corresponding hardware structure. The generating unit may be an IP layer processing unit; the encapsulation unit is a security and tunnel protocol encapsulation unit; the processing unit is an LTE/5G air interface protocol stack processing unit. Because these units are all common architecture units in the application scenario of the IPv6 network protocol, the solution explanation based on these units is only for convenience of solution explanation, and does not limit the solution itself, so long as multiple header compression schemes before and after IPSec encapsulation are satisfied, and all the solutions should fall into the protection scope of the solution of the present invention.

Fig. 1 is a flow chart of a method for message compression transmission according to an embodiment of the present invention. As shown in fig. 1, an embodiment of the present invention provides a method for packet compression transmission, where the method includes:

step S10: the compression end compresses the original message for the first time to obtain a first compressed message.

Specifically, because information interaction exists between the user terminal and the server, that is, the angle of the user terminal is fixed, there is a distinction between uplink and downlink data. When the data transmission is uplink, that is, the user terminal needs to perform data long-range transmission, the compression end is the user terminal, and the corresponding decompression end is the server end. When the data transmission is downlink, the compression end is the server end, and the corresponding decompression end is the user terminal. There are different compression and decompression processes for different output transmission modes.

In a possible implementation manner, as shown in fig. 2, when the data transmission is uplink, the upper layer application generates a service message and sends the service message to the IP layer processing unit, and the IP layer processing unit generates an original IP message, which is denoted as an IP message U1. The IP layer processing unit sends an 'IP message U1' to the IPSec processing unit, the IPSec processing unit firstly searches SPD strategy and SA, then sends the 'IP message U1' to the compression unit, and the compression unit judges whether the destination IP address in the original IP message is the same as the address of an application server in a certain business application descriptor. If the same application server address exists, the corresponding connection with the server address is established directly, the IP address corresponding to the executability becomes superfluous, and the IP address can be deleted at this time, so that the transmission bytes are saved.

Specifically, identifying a destination IP address and a source IP address in the original message; and deleting the destination IP address and the source IP address from the original message to obtain a first compressed message.

In another possible implementation, as shown in fig. 3, when the data transmission is downlink, the application server of the service application group sends an original IP packet (denoted as an IP packet D1) to the IP layer processing unit of the IPSec server, the IP layer processing unit sends the IP packet D1 to the IPSec processing unit, the IPSec processing unit first retrieves the SPD policy and the SA, and then sends an "IP packet D1" to the compression unit, the compression unit locally retrieves the source IP address in the original IP packet corresponding to the service application group and the VLAN Tag, and deletes the destination IP address and the source IP address in the IP packet D1 to form an "IP packet D2", where the "IP packet D2" is the first compressed packet.

Step S20: and packaging the first message based on the IPSec tunnel mode, and performing second compression on the packaged message to obtain a second compressed message.

Specifically, when using the IPSec tunnel mode, IPSec encrypts the IP header and the payload, whereas the transport mode encrypts only the IP payload. The tunnel mode provides protection for the entire IP packet by treating it as an AH or ESP payload. When tunnel mode is used, the entire IP packet is encapsulated by the AH or ESP header with other IP headers. The IP address of the outer IP header is the tunnel termination point and the IP address of the encapsulated IP header is the final source address and destination address. IPSec tunnel mode is useful for protecting communications between different networks when the communications must pass through an intermediate untrusted network.

In one possible implementation, when the data transmission is uplink, the IP layer processing unit sends an "IP packet U1" to the IPSec processing unit, and the IPSec processing unit first retrieves the SPD policy and the SA, and then sends the "IP packet U1" to the compression unit, where the compression unit determines whether the destination IP address in the original IP packet is the same as the address of the application server in a certain service application descriptor. If the same application server address exists, the current message guidance can be directly performed based on the address, the address information carried by the application server address can be directly deleted, and bytes occupied by the corresponding IP address can be directly saved, so that byte saving is effectively realized.

If the same application server address exists, as shown in fig. 2, the compression unit deletes the destination IP address and the source IP address information in the "IP packet U1" to generate an "IP packet U2", and sends the "IP packet U2" to the security and tunneling protocol encapsulation unit, where the security and tunneling protocol encapsulation unit performs related security and tunneling protocol encapsulation processing (such as IPSec ESP) to generate an "IP packet U3". The compression unit compresses the IP address of the IPSec server and the IP address of the IPSec client in the "IP packet U3" to generate an "IP packet U4" as a second compressed packet. Otherwise, the address information of the message needs to be reserved, and the compression unit does not compress the message, and directly and transparently transmits the IP message U1 to the security and tunnel protocol encapsulation processing unit.

In another possible implementation manner, as shown in fig. 3, when the data transmission is downlink, the "IP packet D2" is sent to the security and tunneling protocol encapsulation processing unit, and the security and tunneling protocol encapsulation processing unit forms the "IP packet D3" after processing, and sends the "IP packet D3" to the compression unit, and the compression unit deletes the IPSec server IP address and the IPSec client IP address in the "IP packet D3" to form the "IP packet D4" as the second compressed packet.

Step S30: and carrying out transmission network determination on the second compressed message, and adding a corresponding network label into the second compressed message to obtain a third compressed message.

In a possible implementation manner, when the data transmission is uplink, after obtaining the second compressed packet, the compression unit needs to send the service application group identifier and the "IP packet U4" to the service forwarding unit, and the service forwarding unit sends the service application group identifier and the "IP packet U4" to the LTE/5G air interface protocol stack processing unit through the "IPSec service packet forwarding" interface. The service forwarding unit and the LTE/5G air interface protocol stack processing unit are integrated in the processing unit. After the LTE/5G air interface protocol stack processing unit receives the IPSec service message forwarding interface, the APN/DNN and the service forwarding descriptor corresponding to the service application group identifier are locally indexed, and whether PDN connection/PDU session of the APN/DNN corresponding to the service application group is established or not is locally searched. Preferably, the scheme of the invention also compresses the PDCP layer so as to further ensure the compression effect.

If PDN connection/PDU session of APN/DNN corresponding to the service application group is established, further judging whether EPS bearing/QoS flow matched with the service forwarding descriptor exists, if so, using the ESP bearing/QoS flow to send 'IP message U4', and executing compression function of PDCP layer. Otherwise, the EPS bearing/QoS flow establishing process is started, after the establishment is successful, the LTE/5G air interface protocol stack processing unit establishes a corresponding relation of 'service application group identification-EPS bearing ID', 'service application group identification-QoS flow', then the new established EPS bearing/QoS flow is used for sending 'IP message U4', and the compression function of the PDCP layer is executed.

If PDN connection/PDU session of APN/DNN corresponding to the service application group is not established, then PDN connection/PDU session of accessing the APN corresponding to the service application is started to be established, after establishment is successful, EPS bearing/QoS flow meeting QoS requirement of the service application is established, LTE/5G air interface protocol stack processing unit establishes a corresponding relation of service application group identification-EPS bearing ID/service application group identification-QoS flow, then uses the newly established EPS bearing/QoS flow to send 'IP message U4', and executes compression function of PDCP layer.

In another possible implementation manner, when the data transmission is downlink, the service application group identifier and the "IP packet D4" are sent to the VLAN processing unit, the VLAN processing unit adds the VLAN Tag corresponding to the service application group to form the "packet D5", and finally sends the "packet D5" to the LTE network. The LTE-based network is directly transmitted to the user terminal.

Step S40: the decompression terminal receives a third compressed message sent by the compression terminal based on the request service type, and deletes the network tag in the third compressed message to obtain a second compressed message.

Specifically, after determining the corresponding network transmission method, the obtained third compressed message may be transmitted to the corresponding decompression end for performing decompression. Because the invention deletes the address information and the encapsulated address information existing in the original message, the transmission efficiency is high. When decompression is performed, in order to obtain the original message, the deleted information needs to be supplemented to ensure that the original message obtained by decompression is consistent with the original message compressed previously. Of course, when the decompression step is performed, it is still necessary to distinguish between the data uplink and the data downlink, so as to determine whether the terminal performing the decompression is a user terminal or an IPSec server.

In a possible implementation manner, as shown in fig. 2, when data transmission is uplink, in the process of PDN connection/PDU connection of APN corresponding to a service application group and EPS bearer/QoS flow establishment, the network side establishes a correspondence of "EPS bearer ID/QoS flow ID-service application group identifier-IPSec server address-IPSec client IP address-VLAN Tag". After the network side receives the message U4 from the EPS bearer/QoS flow, it locally retrieves whether there is a service application group corresponding to the EPS bearer/QoS flow: if so, continuing to search the IP address of the terminal corresponding to the EPS bearing/QoS flow (namely, the IP address of the IPSec client) and the VLAN Tag corresponding to the service application group, then adding the IP address of the IPSec client to the message U4 to form a message U41, and finally adding the VLAN Tag to the message U41 to form a message U5 and sending the message U5 to the IPSec server. If not, directly forwarding the received message.

After receiving the message U5, the VLAN processing unit of the IPSec server identifies VLAN Tag in the Ethernet header, locally retrieves the service application group identifier corresponding to the VLAN Tag, and then removes the Ethernet header and restores the message U41 to obtain a second compressed message.

In another possible implementation manner, as shown in fig. 3, when the data transmission is downlink, determining whether there is a PDN connection and an EPS bearer corresponding to the current decompression end based on parameters of the service application group corresponding to the application server; if yes, judging whether the current EPS bearing meets the requirement or not; if yes, acquiring a second compression message based on the EPS bearing; if not, a new EPS bearing is established, and a second compression message is acquired based on the new EPS bearing; if not, establishing PDN connection and EPS bearing of the access APN, and acquiring a second compression message based on the established EPS bearing.

Specifically, after receiving the "message D5", the LTE network removes the VLAN Tag to obtain the "IP message D4", and deletes the IP address of the IPSec client to generate the "IP message D41" (i.e. the second compressed message). And judging whether PDN connection and EPS bearing corresponding to the service application group application exist or not according to the parameters of the service application group corresponding to the VLAN Tag local index and then judging the terminal corresponding to the IPSec client IP address.

If yes, further judging whether the EPS bearing meets the requirement of a service forwarding descriptor, and if yes, using the existing EPS bearing to send an IP message D41; otherwise, an EPS bearing is established, after the establishment is successful, a network side establishes a corresponding relation of 'EPS bearer ID-virtual private group identifier-VPN server address corresponding to the service application group-VLAN Tag', and an LTE air interface protocol stack processing unit side establishes a corresponding relation of 'service application group identifier-EPS bearing ID', and sends an 'IP message D41' by using the EPS bearing.

If not, establishing PDN connection and EPS bearing of access APN, after successful establishment, establishing 'EPS bearer ID-service application group ID-VPN server address-VLAN Tag' corresponding to service application group by network side, establishing 'service application group ID-EPS bearing ID' by LTE air interface protocol stack processing unit side, and transmitting 'IP message D41' by using the EPS bearing.

Step S50: and decompressing the second compressed message for the first time, and decompressing the decompressed second compressed message based on the IPSec tunnel mode to obtain the first compressed message.

In one possible implementation manner, when the data transmission is uplink, the decompression unit locally retrieves the IP address of the IPSec server corresponding to the service application group, adds the IP address of the IPSec server to the "IP packet U41" and then restores the IP packet to the "IP packet U3", and then sends the "IP packet U3" to the security and tunneling protocol encapsulation processing unit, and after security verification and decapsulation processing, the "IP packet U2", that is, the first compressed packet, is obtained.

In another possible implementation manner, when the data transmission is downlink, the LTE air interface protocol stack processing unit receives the data packet D41 from the EPS bearer, compares the EPS bearer ID with the EPS bearer ID of the locally stored service application group, and if the EPS bearer ID is consistent with the EPS bearer ID of a certain locally stored service application group, the LTE air interface protocol stack processing unit first performs PDCP layer decompression, and then uses the "service application group service packet forwarding" interface to send the service application group identifier and the "IP packet D41" together to the IPSec service packet forwarding unit. The IPSec service message forwarding unit sends the service application group identifier and the IP message D41 to the decompression unit, the decompression unit locally retrieves the IPSec server address and the local terminal IP address corresponding to the service application group, adds the IPSec server address and the local terminal IP address to the IP message D41 to form an IP message D3, and then the decompression unit sends the IP message D3 to the security and tunneling protocol decapsulation processing unit, and generates an IP message D2, namely a first compressed message after processing is completed.

Step S60: and decompressing the first compressed message for the second time to obtain an original message.

Specifically, in one possible implementation manner, when the data transmission is uplink, the decompression unit adds the destination IP address as the IP address of the application server to the "IP packet U2", obtains the "IP packet U1" (original packet) after the source IP address is the IP address of the IPSec client, and then sends the IP packet U1 to the IP layer processing unit, and the IP layer processing unit sends the IP packet U1 to the application server.

In another possible implementation manner, when the data transmission is downlink, the decompression unit locally retrieves the application server address and the IP address of the terminal corresponding to the service application group identifier, adds the application server address and the IP address of the terminal to the IP packet D2 to recover the original IP packet (i.e., the IP packet D1), and then sends the "IP packet D1" to the IP layer processing unit.

In the embodiment of the invention, the key point of the scheme is that for a data sender, in an IPSec tunnel mode, the original message header compression processing is performed before the IPSec security and tunnel encapsulation processing, and the IPSec header compression processing is performed after the IPSec security and tunnel encapsulation processing. For the data receiver, in the IPSec tunnel mode, an IPSec header decompression process is performed before the IPSec security and tunnel encapsulation process, and an original packet header decompression process is performed after the IPSec security and tunnel encapsulation process. And then, on the premise of keeping compression and decompression means of the PDCP layer, the header compression efficiency is greatly realized, and the compression processing of the original IP header and the IPSec header is realized in IPSec security and tunnel encapsulation processing, so that the air interface transmission efficiency is improved, and the network side bearing transmission efficiency is also improved.

Fig. 4 is a block diagram of a compression end provided in one embodiment of the present invention. As shown in fig. 4, an embodiment of the present invention provides a compression end, configured to execute the above method for packet compression transmission, where the compression end includes: the generating unit is used for generating an original message based on the request service; the compression unit is used for carrying out first compression on the original message to obtain a first compressed message; the encapsulation unit is used for encapsulating the first compressed message based on the IPSec tunnel mode; the compression unit is also used for carrying out second compression on the packaged first compressed message to obtain a second compressed message; a processing unit for: determining a transmission network of the second compressed message, and adding a corresponding network label to the second compressed message to obtain a third compressed message; and transmitting the third compressed message to a corresponding decompression end based on the determined transmission network.

Fig. 5 is a block diagram of a decompression end according to an embodiment of the present invention. As shown in fig. 5, an embodiment of the present invention provides a decompression end, configured to execute the above method for packet compression transmission, where the decompression end includes: the acquisition unit is used for receiving a third compressed message sent by the compression end based on the request service type, deleting a network tag in the third compressed message and obtaining a second compressed message; the decompression unit is used for decompressing the second compressed message for the first time; the unpacking unit is used for unpacking the first decompressed second compressed message based on the IPSec tunnel mode to obtain a first compressed message; the decompression unit is further configured to decompress the first compressed message for a second time, to obtain an original message.

The invention also provides a message compression transmission system, which comprises the compression end and the decompression end.

Preferably, the decompression end and the compression end are user terminals or IPSec servers; when the compression end is a user terminal, the corresponding decompression end is an IPSec server; when the compression end is an IPSec server, the corresponding decompression end is a user terminal.

The embodiment of the invention also provides a computer readable storage medium, wherein the computer readable storage medium stores instructions, and when the computer readable storage medium runs on a computer, the computer is caused to execute the message compression transmission method.

Those skilled in the art will appreciate that all or part of the steps in a method for implementing the above embodiments may be implemented by a program stored in a storage medium, where the program includes several instructions for causing a single-chip microcomputer, chip or processor (processor) to perform all or part of the steps in a method according to the embodiments of the invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The alternative embodiments of the present invention have been described in detail above with reference to the accompanying drawings, but the embodiments of the present invention are not limited to the specific details of the above embodiments, and various simple modifications may be made to the technical solutions of the embodiments of the present invention within the scope of the technical concept of the embodiments of the present invention, and all the simple modifications belong to the protection scope of the embodiments of the present invention. In addition, the specific features described in the above embodiments may be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, the various possible combinations of embodiments of the invention are not described in detail.

In addition, any combination of the various embodiments of the present invention may be made, so long as it does not deviate from the idea of the embodiments of the present invention, and it should also be regarded as what is disclosed in the embodiments of the present invention.

Claims

1. A method for packet compression transmission, the method being performed by a compression end, the method comprising:

generating an original message based on the request service;

performing first compression on the original message to obtain a first compressed message;

Encapsulating the first compressed message based on an IPSec tunnel mode, and performing second compression on the encapsulated first compressed message to obtain a second compressed message;

determining a transmission network of the second compressed message, and adding a corresponding network label to the second compressed message to obtain a third compressed message;

and transmitting the third compressed message to a corresponding decompression end based on the determined transmission network.

2. The method of claim 1, wherein requesting traffic comprises:

the service request type initiated by the user terminal or the service request type fed back by the application server.

3. The method of claim 1, wherein prior to the first compression of the original message, the method further comprises:

judging whether an application server address matched with a destination IP address in the original message exists or not;

if so, executing the first compression;

and if the message does not exist, packaging the original message, and performing second compression on the packaged original message to obtain a second compressed message.

4. The method of claim 1, wherein performing a first compression on the original message to obtain a first compressed message comprises:

Identifying a destination IP address and a source IP address in the original message;

and deleting the destination IP address and the source IP address from the original message to obtain a first compressed message.

5. The method of claim 1, wherein the performing the second compression on the encapsulated first compressed packet to obtain a second compressed packet includes:

and deleting the IP address of the IPSec server and the IP address of the IPSec client in the packaged first compressed message to obtain a second compressed message.

6. The method of claim 2, wherein when the requested service is a service request type fed back by an application server, determining the transmission network of the second compressed packet includes:

and determining an LTE network or a 5G network as a transmission network of the second compressed message.

7. The method of claim 6, wherein adding the corresponding network tag to the second compressed message to obtain a third compressed message comprises:

and adding the VLAN Tag of the service application group of the current application server into the second compressed message to obtain a third compressed message.

8. The method according to claim 2, wherein when the requested service is a service request type initiated by a user terminal, determining the transmission network of the second compressed packet includes:

Determining a corresponding network access mode based on the second compressed message;

based on the pre-built ESP bearing/QoS flow or the real-time built ESP bearing/QoS flow and the determined network connection mode, performing PDCP layer compression on the second compressed message, and sending the second compressed message compressed by the PDCP layer to a corresponding decompression end.

9. The method of claim 8, wherein the networking mode comprises:

either of the APN mode and the DNN mode.

10. The method of claim 8, wherein the selection rules of the pre-built ESP bearer/QoS flows and the real-time built ESP bearer/QoS flows are:

judging whether a network access mode session is established currently;

if the network access mode session is established, further judging whether an EPS bearing/QoS flow matched with a service forwarding descriptor of the second compressed message exists currently;

if so, using the EPS bearing/QoS flow matched with the service forwarding descriptor of the second compressed message as the pre-built ESP bearing/QoS flow to compress the PDCP layer of the second compressed message;

if not, the service forwarding descriptor based on the second compressed message builds EPS bearing/QoS flow in real time, and compresses the PDCP layer of the second compressed message by using the ESP bearing/QoS flow built in real time;

If the network access mode session is not established, establishing the network access mode session, and setting up EPS bearing/QoS flow in real time based on a service forwarding descriptor of the second compressed message, and compressing the PDCP layer of the second compressed message by using the ESP bearing/QoS flow set up in real time.

11. The method of claim 8, wherein adding the corresponding network tag to the second compressed message to obtain a third compressed message comprises:

searching whether a service application group corresponding to the ESP bearing/QoS flow carrying the second compressed message exists or not;

if so, searching the IP address of the terminal corresponding to the ESP bearing/QoS flow and the VLAN Tag of the corresponding service application group, and adding the search result into the second compressed message to obtain a third compressed message.

12. A method for packet compression transmission, the method being performed by a decompression terminal, the method comprising:

receiving a third compressed message sent by a compression end based on a request service type, and deleting a network tag in the third compressed message to obtain a second compressed message;

decompressing the second compressed message for the first time, and decompressing the decompressed second compressed message based on an IPSec tunnel mode to obtain a first compressed message;

And decompressing the first compressed message for the second time to obtain an original message.

13. The method of claim 12, wherein the request traffic type comprises:

14. The method of claim 13, wherein when the requested service type is a service request type initiated by a user terminal, decompressing the second compressed message for the first time comprises:

acquiring a service application group identifier of a second compressed message;

locally retrieving an IPSec server IP address based on the service application group identification;

and adding the IP address of the IPSec server to the second compressed message to finish the first decompression of the second compressed message.

15. The method of claim 14, wherein decompressing the first compressed message a second time to obtain an original message comprises:

taking the IP address of the corresponding application server as a destination IP address and taking the IP address of the IPSec client as a source IP address;

and adding the destination IP address and the source IP address into the first compressed message to obtain an original message.

16. The method of claim 13, wherein when the requested service type is a service request type fed back by an application server, before decompressing the second compressed message for the first time, the method further comprises:

obtaining a second compressed message, including:

judging whether PDN connection and EPS bearing corresponding to the current decompression end exist or not based on parameters of a service application group corresponding to an application server;

if yes, judging whether the current EPS bearing meets the requirement or not;

if the request is met, acquiring a second compression message based on the current EPS bearing;

if the request is not met, a new EPS bearing is established, and a second compression message is acquired based on the new EPS bearing;

if not, establishing PDN connection and EPS bearing of the access APN, and acquiring a second compression message based on the established EPS bearing.

17. The method of claim 16, wherein decompressing the second compressed message for the first time comprises:

based on the service application group identification, locally searching an IPSec server address and a decompression end IP address corresponding to the service application group;

And adding the IPSec server address and the decompression end IP address into the second compressed message to finish the first decompression.

18. The method of claim 17, wherein decompressing the first compressed message a second time to obtain an original message comprises:

based on the service application group identification, locally searching an application server address and a decompression end IP address;

and adding the address of the application server and the IP address of the decompression end into the first compressed message to obtain an original message.

19. A compression end for performing the method for packet compression transmission according to any one of claims 1 to 11, wherein the compression end includes:

the generating unit is used for generating an original message based on the request service;

the compression unit is used for carrying out first compression on the original message to obtain a first compressed message;

the encapsulation unit is used for encapsulating the first compressed message based on the IPSec tunnel mode;

the compression unit is also used for carrying out second compression on the packaged first compressed message to obtain a second compressed message;

a processing unit for:

20. A decompression terminal for performing the packet compression transmission method according to any one of claims 12 to 18, wherein the decompression terminal comprises:

the acquisition unit is used for receiving a third compressed message sent by the compression end based on the request service type, deleting a network tag in the third compressed message and obtaining a second compressed message;

the decompression unit is used for decompressing the second compressed message for the first time;

the unpacking unit is used for unpacking the first decompressed second compressed message based on the IPSec tunnel mode to obtain a first compressed message;

the decompression unit is further configured to decompress the first compressed message for a second time, to obtain an original message.

21. A message compression transmission system, comprising a compression end according to claim 19 and a decompression end according to claim 20.

22. The system of claim 21, wherein the system further comprises a controller configured to control the controller,

the decompression end and the compression end are user terminals or IPSec servers;

when the compression end is a user terminal, the corresponding decompression end is an IPSec server;

When the compression end is an IPSec server, the corresponding decompression end is a user terminal.

23. A computer readable storage medium having instructions stored thereon, which when run on a computer cause the computer to perform the message compression transmission method of any of claims 1-18.