WO2022151105A1

WO2022151105A1 - Compression processing method and apparatus

Info

Publication number: WO2022151105A1
Application number: PCT/CN2021/071611
Authority: WO
Inventors: 江小威
Original assignee: 北京小米移动软件有限公司
Priority date: 2021-01-13
Filing date: 2021-01-13
Publication date: 2022-07-21
Also published as: CN115136571A

Abstract

Provided are a compression processing method and apparatus, which relate to the technical field of mobile communications. The solution comprises: according to first indication information, sending a data packet which has not been subjected to header compression. By means of the present application, a compression terminal sends, according to first indication information, a data packet which has not been subjected to header compression, such that the compression terminal and a decompression terminal have the same understanding of the compression status of the header of the data packet, and failure of decompression of the header of the data packet is avoided.

Description

A compression processing method and device

technical field

The present application relates to the field of mobile communications, and in particular, to a compression processing method and device.

Background technique

In the related art, when the network side configures the compression function for the compression end of the user terminal, such as the protocol entity, and instructs the user terminal to rebuild the entity, for the situation that the compression function cannot continue, it is easy to cause the compression end and the decompression end to compress the packet header of the data packet. State comprehension is inconsistent, resulting in packet header decompression failure.

SUMMARY OF THE INVENTION

The compression processing method and device proposed in the present application are used to solve the problem in the related art that the compression end and the decompression end have inconsistent understanding of the compression state of the packet header of the data packet, which leads to the failure of decompressing the packet header of the data packet.

An embodiment of the first aspect of the present application proposes a compression processing method, which is applied to a compression end. The method includes: sending a data packet without header compression according to the first indication information.

The embodiment of the second aspect of the present application proposes another compression processing method, which is applied to the decompression end. The method includes: discarding the established compression context according to the second indication information.

The embodiment of the third aspect of the present application proposes a compression processing apparatus, which is applied to a compression end. The apparatus includes: a sending module configured to send a data packet without header compression according to the first indication information.

The embodiment of the fourth aspect of the present application proposes another compression processing apparatus, which is applied to the decompression end. The apparatus includes: a discarding module configured to discard the established compression context according to the second indication information.

Embodiments of the fifth aspect of the present application provide a compression end, including the compression processing apparatus described in the embodiments of the third aspect of the present application.

Embodiments of the sixth aspect of the present application provide a decompression end, including the compression processing apparatus described in the embodiments of the fourth aspect of the present application.

Embodiments of the seventh aspect of the present application provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores data that can be executed by the at least one processor The instruction is executed by the at least one processor, so that the at least one processor can execute the compression processing method described in the embodiment of the first aspect of the present application, or the embodiment of the second aspect of the present application. Compression processing method.

An embodiment of the eighth aspect of the present application provides a computer storage medium, wherein the computer storage medium stores computer-executable instructions, and after the computer-executable instructions are executed by a processor, the embodiment of the first aspect of the present application can be implemented The compression processing method described above, or the compression processing method described in the embodiments of the second aspect of the present application.

Description of drawings

The above and/or additional aspects and advantages of the present application will become apparent and readily understood from the following description of embodiments taken in conjunction with the accompanying drawings, wherein:

1 is a schematic flowchart of a compression processing method provided by an embodiment of the present application;

Fig. 2 is the structural representation of the data packet that EHC does not carry out packet header compression;

3 is a schematic flowchart of another compression processing method provided by an embodiment of the present application;

FIG. 4 is a schematic flowchart of another compression processing method provided by an embodiment of the present application;

Fig. 5 is the structural representation of EHC compressed data packet;

Fig. 6 is the structural representation of EHC feedback data packet;

FIG. 7 is a schematic flowchart of another compression processing method provided by an embodiment of the present application;

FIG. 8 is a schematic flowchart of another compression processing method provided by an embodiment of the present application;

FIG. 9 is a schematic structural diagram of a compression processing apparatus provided by an embodiment of the present application;

FIG. 10 is a schematic structural diagram of another compression processing apparatus provided by an embodiment of the present application;

FIG. 11 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed ways

Embodiments of the present application are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals refer to the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary, and are intended to be used to explain the present application, but should not be construed as a limitation to the present application.

The terms used in the embodiments of the present disclosure are only for the purpose of describing particular embodiments, and are not intended to limit the embodiments of the present disclosure. As used in the embodiments of the present disclosure and the appended claims, the singular forms "a," "" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in embodiments of the present disclosure to describe various pieces of information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the embodiments of the present disclosure, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determining."

The base stations and user terminals involved in the embodiments of the present application are specifically described as follows: The base station is deployed in a wireless access network and provides wireless access functions for user terminals. The base station may wirelessly communicate with the user terminal via one or more antennas. A base station can provide communication coverage for its geographic area. Base stations may include different types such as macro base stations, micro base stations, relay stations, and access points. In some embodiments, a base station may be referred to by those skilled in the art as a base station transceiver, wireless base station, access point, wireless transceiver, Basic Service Set (BSS), Extended Service Set (ESS) ), Node B (NodeB), evolved Node B (evolved NodeB, eNB or eNodeB) or some other appropriate term. Exemplarily, in a 5G system, a base station is called a gNB. For convenience of description, in the embodiments of the present application, the above-mentioned apparatuses for providing wireless communication functions for user terminals are collectively referred to as base stations.

User terminals may be dispersed throughout the mobile communication system, and each user terminal may be stationary or mobile. A user terminal may also be referred to by those skilled in the art as a mobile station, subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, terminal device, wireless device, wireless communication device, remote device, mobile subscriber station, receiver. Inbound User Equipment, Mobile User Equipment, Wireless User Equipment, Remote User Equipment, Handheld Device, User Agent, Mobile Client, Client, or some other appropriate term. The user terminal may be a cellular phone, a Personal Digital Assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a tablet computer, a laptop computer, a cordless phone, a Wireless Local Loop (WLL) A station, etc., capable of communicating with a base station in a mobile communication system.

1 is a schematic flowchart of a compression processing method provided by an embodiment of the present application, which is executed by a compression end. As shown in FIG. 1 , the compression processing method includes the following steps:

S101, according to the first indication information, send a data packet without packet header compression.

Specifically, the compression end and the decompression end may be network entities, such as functional modules in a Packet Data Convergence Protocol (PDCP for short) entity, or independent network entities. In addition to the base station and the terminal device, the compression end and the decompression end can also exist in network devices, such as between routers; between gateways and base stations; between gateways and gateways.

As a feasible implementation manner, the compression end may, according to the agreement of the communication protocol, send the data packet without header compression before establishing a new compression context, instead of sending the compressed data packet with the header compression, so as to avoid the decompression end in the If the compression function cannot be continued, the compression state of the current data packet cannot be obtained, resulting in inconsistent understanding of the compression state of the data packet header with the compression end, resulting in failure to decompress the data packet header.

As another feasible implementation manner, the compression end may, according to the first indication information configured by the network side, for example, the base station, send data packets without header compression, instead of sending compressed data with header compression, before establishing a new compression context In order to avoid that when the compression function cannot continue, the decompression end cannot obtain the compression state of the current data packet, which leads to inconsistent understanding of the compression state of the packet header with the compression end, and then causes the decompression of the packet header to fail.

Among them, when the compression function cannot continue, for example, the user terminal switches from the base station gNB-1 to the base station gNB-2, and the network side entity corresponding to the user terminal changes from gNB-1 to gNB-2, then gNB-1 and gNB-2 Both are configured with the compression function, but since gNB-2 cannot obtain the compression status (including compression context information) of the packet header compression of the gNB-1 entity, gNB-2 cannot continue to use the compression context compressed by the packet header of gNB-1 for decompression. .

It should be noted here that the packet header compression in this embodiment of the present application may specifically include, but is not limited to, Ethernet Header Compression (Ethernet Header Compression, EHC for short) and the like.

Optionally, the first indication information may specifically include, but is not limited to, at least one of the following: information used to instruct the network side to configure the header compression function for the compression end; information used to instruct the terminal device to re-establish the compression end; Information indicating that the network side does not instruct the continuous use of the packet header compression function.

For example, the network side can be instructed through ehc-Uplink that the compression end is configured to compress the Ethernet packet header of the uplink data. The terminal device can be instructed to re-establish the PDCP compressor through reestablish PDCP.

Wherein, the packet header of the data packet without packet header compression may specifically include, but is not limited to, a packet header integrity identifier used to identify that the data packet includes a complete packet header, and the like. Figure 2 is a schematic structural diagram of a data packet without header compression by EHC. As shown in Figure 2, the header integrity identifier "F/C" field value in the data packet without header compression by EHC (EHC Compressed Header, referred to as EHC CH) Set to "0" to indicate that the packet includes a complete header, that is, it is not compressed. CID (Context Identity) is an identifier used to mark a compression context, that is, a compression context identifier. The Ethernet header is the Ethernet header, and PAYLOAD(+PAD) is the payload.

In this embodiment of the present application, according to the first indication information, the compression end sends a data packet without header compression before establishing a new compression context, instead of sending a compressed data packet with header compression, which can prevent the decompression end from being unable to perform the compression function. In the case of continuing, because the compression state of the current data packet cannot be obtained, the compression state of the packet header of the data packet is inconsistently understood by the compression end, and the decompression of the data packet header fails.

FIG. 3 is a schematic flowchart of another compression processing method provided by an embodiment of the present application, which is executed by a compression end. As shown in Figure 3, the compression processing method includes the following steps:

S301, according to the first indication information, discard the established compression context.

Specifically, the compression end and the decompression end may be functional modules in a network entity such as a Packet Data Convergence Protocol (PDCP for short) entity, or an independent network entity. In addition to the base station and the terminal device, the compression end and the decompression end can also exist in network devices, such as between routers; between gateways and base stations; between gateways and gateways.

As a feasible implementation manner, the compression end may discard the previously established compression context before establishing the new compression context according to the agreement of the communication protocol.

As another feasible implementation manner, the compression end may discard the previously established compression context before establishing the new compression context according to the first indication information configured by the network side, for example, the base station.

S302: Send the data packet without packet header compression.

Specifically, after discarding the previously established compression context, the compressor sends the data packet without header compression instead of sending the compressed data packet with header compression, so as to avoid the decompression end in the case where the compression function cannot continue, due to The compression state of the current data packet cannot be obtained, resulting in inconsistent understanding of the compression state of the data packet header with the compression end, resulting in failure to decompress the data packet header.

Wherein, the packet header of the data packet without packet header compression may specifically include, but is not limited to, a packet header integrity identifier used to identify that the data packet includes a complete packet header, and the like. Figure 2 is a schematic structural diagram of a data packet without header compression by EHC. As shown in Figure 2, the header integrity identifier "F/C" field value in the data packet without header compression by EHC (EHC Compressed Header, referred to as EHC CH) Set to "0" to indicate that the packet includes a complete header, that is, it is not compressed. The CID is an identifier for marking a compression context, that is, a compression context identifier. The Ethernet header is the Ethernet header, and PAYLOAD(+PAD) is the payload.

Optionally, the first indication information may further include the first length of the compression context identifier or data stream identifier corresponding to the current compression, and the second length of the compression context identifier or data stream identifier corresponding to the previous compression. For example, the length of the compression context identifier corresponding to the current compression and the previous compression may be indicated by ehc-CID-Length, for example, 7 bits (bit) or 15 bits are used.

As shown in FIG. 4 , the above-mentioned step S302 sends a data packet without packet header compression, which may specifically include the following steps S401 or S402 or S403.

S401, in response to the difference between the first length and the second length, use a compression context identifier or a data stream identifier of the first length to send a data packet without header compression.

Specifically, if the first length of the compression context identifier or data stream identifier corresponding to the current compression in the first indication information is different from the second length of the compression context identifier or data stream identifier corresponding to the previous compression, that is, the compression context identifier or If the length of the data stream identifier is changed, the compression context identifier or data stream identifier of the first length is used to send the data packet without header compression, that is, the header of the sent data packet without header compression is used to identify the compression context. The length of the identifier adopts the first length, and the packet header includes a packet header integrity identifier for identifying that the data packet includes a complete packet header. For example, if the first length of the compression context identifier corresponding to this compression is 15 bits, and the second length of the compression context identifier corresponding to the previous compression is 7 bits, then the compression context in the data packet without header compression shown in FIG. 2 is sent. The length of the identification CID is 15 bits, and the "F/C" field value is set to "0".

S402, in response to the first length being the same as the second length, use the first length and the same compression context identifier or data stream identifier as the compression context identifier or data stream identifier corresponding to the previous compression to send the data packet without header compression.

Specifically, if the first length of the compression context identifier or data stream identifier corresponding to the current compression in the first indication information is the same as the second length of the compression context identifier or data stream identifier corresponding to the previous compression, that is, the compression context identifier or data stream identifier If the length of the stream identifier has not changed, the first length and the same compression context identifier or data stream identifier as the compression context identifier or data stream identifier corresponding to the previous compression are still used to send the data packets without header compression, that is, the data packets without header compression are sent. In the packet header of the packet header compressed, the length of the identifier used to identify the compression context or the data stream adopts the second length, and the identifier used to identify the compression context or the data stream is the compression context or data stream identifier corresponding to the previous compression, And the packet header includes a packet header integrity identifier for identifying that the data packet includes a complete packet header. For example, if the first length of the compression context identifier CID-2 corresponding to this compression is 7 bits, and the second length of the compression context identifier CID-1 corresponding to the previous compression is 7 bits, then the packet header shown in Figure 2 is sent without header compression. The length of the compression context identifier CID-1 in the data packet is 7 bits, and the value of the "F/C" field is set to "0".

In the case where the decompression end does not discard the compression context, the decompression end can re-establish the compression context by using the compression context identifier or data stream identifier corresponding to the previous compression to send the data packet without header compression.

S403, in response to the first length being the same as the second length, use a compression context identifier or data stream identifier of the first length that is different from the compression context identifier or data stream identifier corresponding to the previous compression to send the data packet without header compression.

Specifically, if the first length of the compression context identifier or data stream identifier corresponding to the current compression in the first indication information is the same as the second length of the compression context identifier or data stream identifier corresponding to the previous compression, that is, the compression context identifier or data stream identifier If the length of the stream identifier has not changed, the first length and the compression context or data stream identifier corresponding to the previous compression are used to send the data packet without header compression, that is, the packet is sent without header compression. The length of the identifier used to identify the compression context or the data stream in the header of the compressed data packet adopts the first length, and the identifier used to identify the compression context or the data stream is different from the compression context identifier corresponding to the previous compression, and the header includes: A header integrity flag used to identify that the data packet includes a complete header. For example, if the first length of the compression context identifier CID-2 corresponding to this compression is 7 bits, and the second length of the compression context identifier CID-1 corresponding to the previous compression is 7 bits, then the packet header shown in Figure 2 is sent without header compression. The length of the compression context identifier CID-2 in the data packet is 7 bits, and the compression context identifier is CID-2 instead of CID-1, and the "F/C" field value is set to "0".

Optionally, before sending the data packet without header compression in step S302, the compression processing method in this embodiment of the present application may further include the following steps: receiving decompression failure information, where the decompression failure information includes a failure type indication, such as a decompression failure. and the compression context identifier such as CID-1 of the compressed data packet that has undergone header compression that fails to be decompressed. The decompression failure information is used to indicate that the compression end does not send the compressed data packet corresponding to the compression context identifier of the decompression failure.

Among them, Figure 5 is a schematic structural diagram of an EHC compressed data packet. As shown in Figure 5, the packet header integrity identifier "F/C" field value in the EHC compressed data packet (EHC Full Header, referred to as EHC FH) is set to "1", Used to identify that the data packet includes an incomplete header, that is, it is compressed. The CID is an identifier for marking a compression context, that is, a compression context identifier. PAYLOAD(+PAD) is the payload.

Those skilled in the art can understand that the establishment process of the EHC compression context is as follows: the compression end sends an uncompressed Ethernet data packet (that is, an EHC FH packet) without Ethernet header compression to the decompression end. After the decompression end receives the "EHC FH packet", it feeds back a reception confirmation message (as shown in Figure 6 is a schematic diagram of the structure of the EHC feedback data packet, where R is the feedback identifier) to the compression end. The compression end sends the compressed Ethernet data packet (that is, the EHC CH packet) with the Ethernet packet header compressed to the decompression end. Further, a compression context is established between the compression end and the decompression end, and the compression context is marked by a CID. Wherein, the compression context stores the Ethernet packet header information before and after compression. Then, the compression end sends the compressed Ethernet data packet according to the compression context, and the decompression end restores the compressed Ethernet data packet to the uncompressed Ethernet data packet before compression according to the compression context.

In this embodiment of the present application, before establishing a new compression context, the compression end discards the established compression context and sends a data packet without header compression instead of sending a compressed data packet with header compression according to the first indication information. It can avoid that when the compression function cannot continue, the decompression end cannot obtain the compression state of the current data packet, resulting in inconsistent understanding of the compression state of the data packet header with the compression end, resulting in the failure of the decompression of the data packet header.

FIG. 7 is a schematic flowchart of another compression processing method provided by an embodiment of the present application, which is executed by a decompression end. As shown in Figure 7, the compression processing method includes the following steps:

S701, according to the second indication information, discard the established compression context.

As a feasible implementation manner, the decompressor can discard the previously established compression context before establishing a new compression context according to the agreement of the communication protocol, so as to successfully receive the uncompressed data sent by the compressor when the compression function cannot continue. The data packet that is compressed by the packet header avoids that the compression state of the current data packet cannot be obtained, which leads to inconsistent understanding of the packet header compression state of the data packet with the compression end, and thus causes the packet header to fail to be decompressed.

As another feasible implementation manner, the decompression end may discard the previously established compression context before establishing a new compression context according to the second indication information configured by the network side such as the base station, so as to successfully receive the compression end when the compression function fails. In the case of continuing, the data packets without header compression are sent to avoid the inability to obtain the compression state of the current data packet, which will lead to inconsistent understanding of the data packet header compression state with the compression end, which will lead to the failure of packet header decompression.

It should be noted here that the packet header compression in the embodiments of the present application may specifically include, but is not limited to, Ethernet Header Compression (Ethernet Header Compression, EHC for short), and the like.

Optionally, the second indication information may specifically include but is not limited to at least one of the following: information used to instruct the network side to configure the packet header compression function for the decompression end; information used to instruct the terminal device to re-establish the decompression end; and, Information used to indicate that the network side does not instruct the continuous use of the packet header compression function.

For example, ehc-Downlink can be used to instruct the network side to configure the decompression end to compress the Ethernet packet header of the downlink data. The terminal device can be instructed to re-establish the PDCP decompression end through reestablish PDCP.

In the compression processing method of this embodiment of the present application, the decompression end discards the established compression context according to the second indication information, so as to successfully receive the data packets without header compression sent by the compression end when the compression function cannot continue, avoiding the The compression state of the current data packet cannot be obtained, resulting in inconsistent understanding of the compression state of the data packet header with the compression end, resulting in failure to decompress the data packet header.

FIG. 8 is a schematic flowchart of another compression processing method provided by an embodiment of the present application, which is executed by a decompression end. As shown in Figure 8, the compression processing method includes the following steps:

S801, according to the second indication information, discard the established compression context.

S802: Receive the compressed data packet that has undergone header compression, wherein, before receiving the compressed data packet that has undergone header compression, a data packet that is identical to the compression context identifier of the compressed data packet and has not been subjected to header compression has not been received.

S803: Execute a decompression failure processing operation.

Specifically, if the decompression end receives the compressed data packet sent by the compression end with header compression, and before receiving the compressed data packet with header compression, it does not receive the same compression context identifier as the compressed data packet. For data packets without header compression, the decompression failure processing operation is performed.

For example, the decompressor receives the compressed data packet with the compression context identifier CID-1 sent by the entity, and does not receive the compression context identifier CID-1 before receiving the compressed data packet with the compression context identifier CID-1 If there is no packet header compression, the decompression failure processing operation will be performed.

Those skilled in the art can understand that the establishment process of the EHC compression context is as follows: the compression end sends an uncompressed Ethernet data packet (that is, an EHC FH packet) without Ethernet header compression to the decompression end. After the decompression end receives the "EHC FH packet", it feeds back a reception confirmation message (as shown in Figure 6, where R is the feedback identifier) to the compression end. The compression end sends the compressed Ethernet data packet (that is, the EHC CH packet) with the Ethernet packet header compressed to the decompression end. Further, a compression context is established between the compression end and the decompression end, and the compression context is marked by a CID. Wherein, the compression context stores the Ethernet packet header information before and after compression. Then, the compression end sends the compressed Ethernet data packet according to the compression context, and the decompression end restores the compressed Ethernet data packet to the uncompressed Ethernet data packet before compression according to the compression context.

Wherein, performing the decompression failure processing operation in step S803 may specifically include, but is not limited to, at least one of the following: discarding the compressed data packet; and sending decompression failure information, wherein the decompression failure information includes a failure type indication such as decompression failure.

Optionally, the decompression failure information may also include at least one of the following: a compression context identifier of the compressed data packet, such as CID-1; a data flow identifier of the compressed data packet, such as QoS flow-1; and a bearer identifier of the compressed data packet, such as DRB -1.

Optionally, before discarding the established compression context in step S801, the compression processing method in this embodiment of the present application may further include the following steps: receiving third indication information configured by the network side, where the third indication information includes a preset compression context. The packet header of the corresponding packet without packet header compression includes a packet header integrity identifier for identifying that the packet includes a complete packet header; in response to the received packet's compression context identifier being the same as the preset compression context identifier, determine The received packet is a packet without header compression.

Specifically, the decompression end receives third indication information configured by the network side, where the third indication information includes a preset compression context identifier corresponding to the data packet without header compression. The packet header integrity identifier, that is, the third indication information is used to indicate that, for the data packet that has not undergone packet header compression with the preset compression context identifier, the packet header is used to indicate that the packet includes the complete packet header through the packet header integrity identifier. If the compression context identifier of the received data packet is the same as the preset compression context identifier, it is determined that the received data packet is a data packet without header compression.

Corresponding to the compression processing methods provided by the above-mentioned embodiments, the present application further provides a compression processing device, which is applied to the compression end. The compression processing method provided in the example corresponds to the compression processing method, so the implementation of the compression processing method is also applicable to the compression processing apparatus provided in this embodiment, and will not be described in detail in this embodiment.

FIG. 9 is a schematic structural diagram of a compression processing apparatus provided by an embodiment of the present application.

As shown in FIG. 9 , the compression processing apparatus 900 includes: a sending module 910 . in:

The sending module 910 is configured to send the data packet without packet header compression according to the first indication information.

Optionally, the packet header is compressed as an Ethernet header.

Optionally, the first indication information includes at least one of the following: information used to instruct the network side to configure the packet header compression function for the compression end; information used to instruct the terminal device to re-establish the compression end; and information used to indicate that the network side does not indicate the packet header Information that the compression function uses continuously.

Optionally, the sending module 910 is further configured to discard the established compression context before sending the data packet without header compression.

Optionally, the packet header of the data packet without packet header compression includes a packet header integrity identifier for identifying that the data packet includes a complete packet header.

Optionally, the first indication information includes the first length of the compression context identifier or data stream identifier corresponding to the current compression and the second length of the compression context identifier or data stream identifier corresponding to the previous compression; the sending module is specifically configured as: In response to the first length being different from the second length, use the compression context identifier or data stream identifier of the first length to send the data packet without header compression; or, in response to the first length being the same as the second length, using the first length And the same compression context identifier or data stream identifier as the compression context identifier or data stream identifier corresponding to the last compression sends the data packet without header compression; or, in response to the first length being the same as the second length, the first length and A compression context identifier or data stream identifier different from the compression context identifier or data stream identifier corresponding to the previous compression sends a data packet without header compression.

Optionally, the sending module 910 is further configured to: before sending the data packet without header compression, receive decompression failure information, wherein the decompression failure information includes a failure type indication and the decompression failed compressed data with header compression. Compression context identifier for the package.

In the compression processing apparatus of this embodiment of the present application, the compression end discards the established compression context before establishing a new compression context according to the first indication information, and sends a data packet without header compression instead of sending the compression with header compression. Data packets, which can prevent the decompression end from being able to obtain the compression state of the current data packet when the compression function cannot continue, resulting in inconsistent understanding of the compression state of the data packet header with the compression end, resulting in packet header decompression failure. .

Corresponding to the compression processing methods provided by the above-mentioned embodiments, the present application further provides a compression processing apparatus, which is applied to a user terminal. The compression processing method provided in the example corresponds to the compression processing method, so the implementation of the compression processing method is also applicable to the compression processing apparatus provided in this embodiment, and will not be described in detail in this embodiment.

FIG. 10 is a schematic structural diagram of a compression processing apparatus provided by an embodiment of the present application.

As shown in FIG. 10, the compression processing apparatus 1000 includes: a discarding module 1010, wherein:

The discarding module 1010 is configured to discard the established compression context according to the second indication information.

Optionally, the second indication information includes at least one of the following: information used to instruct the network side to configure the packet header compression function for the decompression end; information used to instruct the terminal device to re-establish the decompression end; and information used to indicate that the network side has not Information indicating the continuous use of the header compression function.

Optionally, the packet header is compressed as an Ethernet header.

Optionally, the compression processing apparatus in the embodiment of the present application may further include: a receiving module configured to receive a compressed data packet with header compression after the discarding module 1010 discards the established compression context, wherein the receiving module 1010 performs header compression. Before the compressed compressed data packet, a data packet with the same compression context identifier as the compressed data packet without header compression has not been received; the decompression failure processing operation is performed.

Optionally, the receiving module is specifically configured to perform at least one of the following: discarding the compressed data packet; and sending decompression failure information, where the decompression failure information includes a failure type indication.

Optionally, the decompression failure information further includes at least one of the following: a compression context identifier of the compressed data packet; a data flow identifier of the compressed data packet; and a bearer identifier of the compressed data packet.

Optionally, the receiving module is further configured to: before the discarding module 1010 discards the established compression context, receive third indication information configured by the network side, where the third indication information includes the preset compression context identifier corresponding to the uncompressed header. The packet header of the data packet includes a packet header integrity identifier for identifying that the packet includes a complete packet header; in response to the compression context identifier of the received packet being the same as the preset compression context identifier, it is determined that the received packet is unidentified. Header-compressed packets.

In the compression processing apparatus of the embodiment of the present application, the decompression end discards the established compression context according to the second indication information, so as to successfully receive the data packet without header compression sent by the compression end when the compression function cannot continue, avoiding the The compression state of the current data packet cannot be obtained, resulting in inconsistent understanding of the compression state of the data packet header with the compression end, resulting in failure to decompress the data packet header.

According to the embodiments of the present application, the present application further provides a compression end, including the compression processing apparatus 900 provided by the embodiments of the present application.

The compressor in the embodiment of the present application, according to the first indication information, before establishing a new compression context, discards the established compression context, and sends a data packet without header compression, instead of sending a compressed data packet with header compression, It can avoid that when the compression function cannot continue, the decompression end cannot obtain the compression state of the current data packet, resulting in inconsistent understanding of the compression state of the data packet header with the compression end, resulting in the failure of the decompression of the data packet header.

According to the embodiments of the present application, the present application further provides a decompression terminal, including the compression processing apparatus 1000 provided by the embodiments of the present application.

The decompression end in this embodiment of the present application discards the established compression context according to the second indication information, so as to successfully receive the data packet without header compression sent by the compression end when the compression function cannot continue, so as to avoid the failure to obtain the current The compression state of the data packet, which leads to inconsistent understanding of the compression state of the data packet header with the compression end, which in turn causes the packet header decompression failure.

According to the embodiments of the present application, the present application further provides an electronic device and a readable storage medium.

As shown in FIG. 11 , it is a block diagram of an electronic device according to an embodiment of the present application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are by way of example only, and are not intended to limit implementations of the application described and/or claimed herein.

As shown in FIG. 11, the electronic device includes: one or more processors 1100, a memory 1200, and interfaces for connecting various components, including a high-speed interface and a low-speed interface. The various components are interconnected using different buses and may be mounted on a common motherboard or otherwise as desired. The processor may process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of the GUI on an external input/output device, such as a display device coupled to the interface. In other embodiments, multiple processors and/or multiple buses may be used with multiple memories and multiple memories, if desired. Likewise, multiple electronic devices may be connected, each providing some of the necessary operations (eg, as a server array, a group of blade servers, or a multiprocessor system). A processor 1100 is taken as an example in FIG. 11 .

The memory 1200 is the non-transitory computer-readable storage medium provided by the present application. The memory stores instructions executable by at least one processor, so that the at least one processor executes the compression processing method provided by the present application. The non-transitory computer-readable storage medium of the present application stores computer instructions, and the computer instructions are used to cause the computer to execute the compression processing method provided by the present application.

As a non-transitory computer-readable storage medium, the memory 1200 can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as program instructions/modules corresponding to the compression processing methods in the embodiments of the present application (for example, appendix The sending module 910 shown in FIG. 9 ). The processor 1100 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions and modules stored in the memory 1200, ie, implements the compression processing methods in the above method embodiments.

The memory 1200 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to the use of the positioning electronic device, and the like. Additionally, memory 1200 may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid-state storage device. Optionally, the memory 1200 may optionally include memory located remotely from the processor 1100, and these remote memories may be connected to the positioning electronic device through a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

The electronic device may further include: an input device 1300 and an output device 1400 . The processor 1100 , the memory 1200 , the input device 1300 and the output device 1400 may be connected by a bus or in other ways, and the connection by a bus is taken as an example in FIG. 11 .

The input device 1300 can receive input numerical or character information and generate key signal input related to user settings and functional control of the positioning electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, pointing stick, one or more Input devices such as mouse buttons, trackballs, joysticks, etc. The output device 1400 may include a display device, auxiliary lighting devices (eg, LEDs), haptic feedback devices (eg, vibration motors), and the like. The display device may include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display, and a plasma display. In some implementations, the display device may be a touch screen.

Various implementations of the systems and techniques described herein can be implemented in digital electronic circuitry, integrated circuit systems, application specific ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include being implemented in one or more computer programs executable and/or interpretable on a programmable system including at least one programmable processor that The processor, which may be a special purpose or general-purpose programmable processor, may receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device an output device.

These computational programs (also referred to as programs, software, software applications, or codes) include machine instructions for programmable processors, and may be implemented using high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages calculation program. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or apparatus for providing machine instructions and/or data to a programmable processor ( For example, magnetic disks, optical disks, memories, programmable logic devices (PLDs), including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide interaction with a user, the systems and techniques described herein may be implemented on a computer having a display device (eg, a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user ); and a keyboard and pointing device (eg, a mouse or trackball) through which a user can provide input to the computer. Other kinds of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (eg, visual feedback, auditory feedback, or tactile feedback); and can be in any form (including acoustic input, voice input, or tactile input) to receive input from the user.

The systems and techniques described herein may be implemented on a computing system that includes back-end components (eg, as a data server), or a computing system that includes middleware components (eg, an application server), or a computing system that includes front-end components (eg, a user computer having a graphical user interface or web browser through which a user may interact with implementations of the systems and techniques described herein), or including such backend components, middleware components, Or any combination of front-end components in a computing system. The components of the system may be interconnected by any form or medium of digital data communication (eg, a communication network). Examples of communication networks include: Local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.

A computer system can include clients and servers. Clients and servers are generally remote from each other and usually interact through a communication network. The relationship of client and server arises by computer programs running on the respective computers and having a client-server relationship to each other.

It should be understood that steps may be reordered, added or deleted using the various forms of flow shown above. For example, the steps described in the present application can be performed in parallel, sequentially or in different orders, and as long as the desired results of the technical solutions disclosed in the present application can be achieved, no limitation is imposed herein.

Claims

A compression processing method, characterized in that, applied to a compression end, the method comprising:

According to the first indication information, a data packet without packet header compression is sent.
The method according to claim 1, wherein the packet header compression is Ethernet header compression.
The method according to any one of claims 1 or 2, wherein the first indication information comprises at least one of the following:

Information used to indicate that the network side configures the header compression function for the compression end;

information for instructing the terminal device to re-establish the compressor; and

Information used to indicate that the network side does not instruct the continuous use of the packet header compression function.
The method according to any one of claims 1-3, wherein before the sending the data packet without packet header compression, the method further comprises:

The established compression context is discarded.
The method according to any one of claims 1-4, wherein the packet header of the data packet without packet header compression includes a packet header integrity identifier for identifying that the data packet includes a complete packet header.
The method according to any one of claims 1-5, wherein the first indication information includes the compression context identifier or the first length of the data stream identifier corresponding to the current compression, and the compression context corresponding to the previous compression The second length of the identifier or the data stream identifier; the sending of the data packet without header compression includes:

In response to the first length being different from the second length, use the compression context identifier or data flow identifier of the first length to send the data packet without header compression; or,

In response to the first length being the same as the second length, using the first length and the same compression context identifier or data stream identifier as the compression context identifier or data stream identifier corresponding to the last compression to send the unreported data stream. Packets with header compression; or,

In response to the first length being the same as the second length, a compression context identifier or data stream identifier of the first length that is different from the compression context identifier or data stream identifier corresponding to the last compression is used to send the unreported data stream. Header-compressed packets.
The method according to any one of claims 1-6, wherein before the sending the data packet without packet header compression, the method further comprises:

Decompression failure information is received, wherein the decompression failure information includes a failure type indication and a compression context identifier of the header-compressed compressed data packet that fails to be decompressed.
A compression processing method, characterized in that, applied to a decompression end, the method comprising:

According to the second indication information, the established compression context is discarded.
The method according to claim 8, wherein the second indication information comprises at least one of the following:

Information used to instruct the network side to configure the packet header compression function for the decompression end;

information for instructing the terminal device to re-establish the decompression end; and

Information used to indicate that the network side does not instruct the continuous use of the packet header compression function.
The method according to claim 9, wherein the packet header compression is Ethernet header compression.
The method according to any one of claims 8-10, wherein after discarding the established compression context, the method further comprises:

receiving a compressed data packet with header compression, wherein before receiving the compressed data packet with header compression, a data packet without header compression that is identical to the compression context identifier of the compressed data packet is not received;

Perform decompression failure handling operations.
The method according to claim 11, wherein the performing an operation of processing a decompression failure comprises at least one of the following:

discarding the compressed data packet; and

Decompression failure information is sent, wherein the decompression failure information includes a failure type indication.
The method according to claim 12, wherein the decompression failure information further comprises at least one of the following:

the compression context identifier of the compressed data packet;

a data flow identification of the compressed data packet; and

The bearer identifier of the compressed data packet.
The method according to any one of claims 8-13, characterized in that before discarding the established compression context, the method further comprises:

Receive third indication information configured by the network side, where the third indication information includes a preset compression context identifier corresponding to the packet header of the data packet without header compression including a packet header for identifying that the data packet includes a complete packet header. Packet header integrity identification;

In response to the compression context identifier of the received data packet being the same as the preset compression context identifier, it is determined that the received data packet is the data packet without header compression.
A compression processing device, characterized in that, applied to a compression end, the device comprising:

The sending module is configured to send the data packet without packet header compression according to the first indication information.
The apparatus according to claim 15, wherein the sending module is further configured to:

Before the sending of the data packet without header compression, the established compression context is discarded.
The apparatus according to claim 15 or 16, wherein the first indication information comprises the first length of the compression context identifier or data stream identifier corresponding to the current compression, and the compression context identifier or data corresponding to the previous compression The second length of the stream identifier; the sending module is specifically configured as:

In response to the first length being different from the second length, use the compression context identifier or data flow identifier of the first length to send the data packet without header compression; or,

In response to the first length being the same as the second length, using the first length and the same compression context identifier or data stream identifier as the compression context identifier or data stream identifier corresponding to the last compression to send the unreported data stream. Packets with header compression; or,

In response to the first length being the same as the second length, a compression context identifier or data stream identifier of the first length that is different from the compression context identifier or data stream identifier corresponding to the last compression is used to send the unreported data stream. Header-compressed packets.
The device according to any one of claims 15-17, wherein the sending module is further configured to:

Before the sending of the data packet without header compression, the decompression failure information is received, wherein the decompression failure information includes a failure type indication and a compression context identifier of the compressed data packet with header compression that fails to be decompressed.
A compression processing device, characterized in that, applied to a decompression end, the device comprising:

The discarding module is configured to discard the established compression context according to the second indication information.
The apparatus of claim 19, further comprising:

The receiving module is configured to receive the compressed data packet with header compression after the discarding module discards the established compression context, wherein before receiving the compressed data packet with header compression The compression context of the compressed data packets identifies the same data packets without header compression; and a decompression failure processing operation is performed.
The apparatus according to claim 20, wherein the receiving module is specifically configured to perform at least one of the following:

discarding the compressed data packet; and

Decompression failure information is sent, wherein the decompression failure information includes a failure type indication.
The device according to any one of claims 19-21, wherein the receiving module is further configured to:

Before the discarding module discards the established compression context, receive third indication information configured by the network side, where the third indication information includes a preset compression context identifier corresponding to the packet header of the data packet including for identifying that the data packet includes a header integrity identifier of a complete header; in response to the received data packet having the same compression context identifier as the preset compression context identifier, determine that the received data packet is the data packet .
A compression end, characterized by comprising: the compression processing apparatus according to any one of claims 15-18, or the data packet header compression processing apparatus according to any one of claims 19-22.
A decompression end, characterized by comprising: the data packet header compression processing device according to any one of claims 15-18, or the compression processing device according to any one of claims 19-22.
An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the execution of any of claims 1-7 The compression processing method described above, or the compression processing method according to any one of claims 8-14.
A computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to execute the compression processing method according to any one of claims 1-7, or the compression processing method as claimed in claim 8 The compression processing method described in any one of -14.