CN115136571A

CN115136571A - Compression processing method and device

Info

Publication number: CN115136571A
Application number: CN202180000140.7A
Authority: CN
Inventors: 江小威
Original assignee: Beijing Xiaomi Mobile Software Co Ltd
Current assignee: Beijing Xiaomi Mobile Software Co Ltd
Priority date: 2021-01-13
Filing date: 2021-01-13
Publication date: 2022-09-30
Also published as: WO2022151105A1

Abstract

The application provides a compression processing method and a compression processing device, and relates to the technical field of mobile communication. The scheme is as follows: and sending the data packet without the header compression according to the first indication information. In the application, the compression end sends the data packet of which the packet header is not compressed according to the first indication information, so that the compression end and the decompression end have the same understanding on the compression state of the packet header of the data packet, and the decompression failure of the packet header of the data packet is avoided.

Description

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 apparatus.

Background

In the related art, when a network side configures a compression function for a compression end of a user terminal, such as a protocol entity, and instructs the user terminal to reconstruct the entity, for a situation that the compression function cannot be continued, it is easy to cause inconsistency in understanding of a packet header compression state of a data packet by the compression end and the decompression end, thereby causing a failure in decompressing a packet header of the data packet.

Disclosure of Invention

The compression processing method and the compression processing device are used for solving the problem that decompression failure of a data packet header is caused due to the fact that understanding of the compression state of the data packet header by a compression end and a decompression end in the related technology is inconsistent.

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

The embodiment of the second aspect of the present application provides another compression processing method, which is applied to a decompression end, and the method includes: based on the second indication information, the established compression context is discarded.

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

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

In a fifth aspect of the present application, there is provided a compression end including the compression processing apparatus according to the third aspect of the present application.

An embodiment of the sixth aspect of the present application provides a decompression end, which includes the compression processing apparatus described in the embodiment of the fourth aspect of the present application.

An embodiment of a seventh aspect of the present application provides an electronic device, including: 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, and the instructions are executed by the at least one processor to enable the at least one processor to execute the compression processing method according to the embodiment of the first aspect of the present application or the compression processing method according to the embodiment of the second aspect of the present application.

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

Drawings

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

fig. 1 is a schematic flow chart of a compression processing method according to an embodiment of the present disclosure;

FIG. 2 is a schematic diagram of a packet structure of an EHC without header compression;

fig. 3 is a schematic flow chart of another compression processing method according to an embodiment of the present application;

fig. 4 is a schematic flow chart of another compression processing method according to an embodiment of the present application;

FIG. 5 is a diagram of an EHC compressed packet;

FIG. 6 is a diagram of an EHC feedback packet;

fig. 7 is a schematic flowchart of another compression processing method according to an embodiment of the present application;

fig. 8 is a schematic flowchart of another compression processing method according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a compression processing apparatus according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of another compression processing apparatus according to 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 Description

Reference will now be made in detail to the embodiments of the present application, examples of which are illustrated in the accompanying drawings, wherein like 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 drawings are exemplary and intended to be used for explaining the present application and should not be construed as limiting the present application.

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

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information in the embodiments of the present disclosure, such information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of embodiments of the present disclosure. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The base station and the user terminal 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 a wireless access function for the user terminal. A base station may communicate wirelessly with user terminals via one or more antennas. A base station may provide communication coverage for the geographic area in which it is located. The base stations may include different types of macro base stations, micro base stations, relay stations, access points, and the like. In some embodiments, a base station may be referred to by those skilled in the art as a base transceiver station, a radio base station, an access point, a radio transceiver, a Basic Service Set (BSS), an Extended Service Set (ESS), a node B (NodeB), an evolved node B (eNB or eNodeB), or some other suitable terminology. Exemplarily, in a 5G system, a base station is referred to as a gNB. For convenience of description, in the embodiments of the present application, the above-mentioned apparatuses providing a wireless communication function for a user terminal are collectively referred to as a base station.

The 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, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a terminal device, a wireless communication device, a remote device, a mobile subscriber station, an access user device, a mobile user device, a wireless user device, a remote user device, a handset, a user agent, a mobile client, a client, or some other suitable terminology. 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 telephone, a Wireless Local Loop (WLL) station, etc., and is capable of communicating with a base station in a mobile communication system.

Fig. 1 is a schematic flow chart of a compression processing method provided in an embodiment of the present application, which is executed by a compression end, and as shown in fig. 1, the compression processing method includes the following steps:

and S101, sending the data packet without the header compression according to the first indication information.

Specifically, the compression end and the decompression end may be functional modules in a network entity, such as a Packet Data Convergence Protocol (PDCP) entity, or independent network entities. Besides existing in the base station and the terminal device, the compression end and the decompression end may also exist in the network device, such as: between the routers; between the gateway and the base station; a gateway and a gateway.

As a feasible implementation manner, the compression end may send a data packet without performing header compression instead of sending a compressed data packet with performing header compression before establishing a new compression context according to an agreement of a communication protocol, so as to avoid that, when the decompression end cannot continue the compression function, the decompression end may not obtain the compression state of the current data packet, which may result in inconsistency in understanding the compression state of the header of the data packet with the compression end, thereby resulting in a failure in decompressing the header of the data packet.

As another possible implementation, the compression end may send a data packet without performing header compression instead of sending a compressed data packet with performing header compression before establishing a new compression context according to the first indication information configured by the network side, for example, the base station, so as to avoid that the decompression end fails to decompress the packet header of the data packet due to the fact that the decompression end cannot acquire the compression state of the current data packet when the compression function cannot be continued, and thus the packet header compression state of the data packet is not understood consistently with the compression end.

When the compression function cannot be continued, for example, when the user terminal is switched from base station gNB-1 to base station gNB-2 and the entity on the network side corresponding to the user terminal is changed from gNB-1 to gNB-2, both gNB-1 and gNB-2 configure the compression function, but because gNB-2 cannot acquire the compression state (including compression context information) of the header compression of the entity of gNB-1, gNB-2 cannot continue to use the compression context of the header compression of gNB-1 to decompress the packet.

It should be noted that, the Header Compression in the embodiment of the present application may specifically include, but is not limited to, Ethernet Header Compression (EHC).

Optionally, the first indication information may specifically include, but is not limited to, at least one of the following: information used for indicating the network side to configure the header compression function for the compression end; information for instructing the terminal device to reestablish the compression side; and information for indicating that the network side does not indicate continuous use of the header compression function.

For example, ehc-Uplink may indicate that the network side configures compression of an ethernet packet header of the Uplink data for the compression end. The terminal equipment can be instructed to reestablish the PDCP compression end through the reattemplish PDCP.

The packet header of the data packet without header compression may specifically include, but is not limited to, a header integrity identifier for identifying that the data packet includes a complete packet header, and the like. Fig. 2 is a schematic structural diagram of a packet without Header compression by an EHC, and as shown in fig. 2, a Header integrity flag "F/C" field value in a packet (EHC Compressed Header, abbreviated as EHC CH) without Header compression by the EHC is set to "0" for indicating that the packet includes a complete Header, that is, the packet is not Compressed. Cid (context identity) is an identification used to tag the compression context, i.e. the compression context identification. The Ethernet header is the Ethernet header and the PAYLOAD (+ PAD) is the PAYLOAD.

In the embodiment of the application, the compression end sends the data packet without header compression instead of sending the compressed data packet with header compression before establishing a new compression context according to the first indication information, so that the situation that the decompression end cannot continue to compress the data packet due to the fact that the compression state of the current data packet cannot be obtained is avoided, and the header compression state of the data packet is not consistent with the header compression state of the data packet understood by the compression end, and the decompression of the packet header of the data packet fails.

Fig. 3 is a schematic flowchart of another compression processing method according to an embodiment of the present application, which is executed by a compression end. As shown in fig. 3, the compression processing method includes the steps of:

s301, discarding the established compression context according to the first indication information.

As a possible implementation manner, the compression end may discard the compression context that has been previously established before establishing the new compression context according to the convention of the communication protocol.

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

S302, the data packet without header compression is transmitted.

Specifically, after discarding the previously established compression context, the compression end sends a data packet without performing packet header compression, instead of sending a compressed data packet with performing packet header compression, so as to avoid that the decompression end cannot obtain the compression state of the current data packet under the condition that the compression function cannot be continued, so that the understanding of the compression state of the packet header of the data packet by the compression end is inconsistent, and further the decompression of the packet header of the data packet fails.

However, when the compression function cannot be continued, for example, when the user terminal is switched from the base station gNB-1 to the base station gNB-2 and the entity on the network side corresponding to the user terminal is changed from the gNB-1 to the gNB-2, both the gNB-1 and the gNB-2 configure the compression function, but since the gNB-2 cannot acquire the compression state (including the compression context information) of the header compression of the entity of the gNB-1, the gNB-2 cannot continue to use the compression context of the header compression of the gNB-1 to perform decompression.

For example, ehc-Uplink may indicate that the network side configures compression of the ethernet packet header of the Uplink data for the compression end. The terminal equipment can be instructed to reestablish the PDCP compression end through the reatestabilish PDCP.

The packet header of the data packet without header compression may specifically include, but is not limited to, a header integrity identifier for identifying that the data packet includes a complete packet header, and the like. Fig. 2 is a schematic structural diagram of a packet without Header compression by an EHC, and as shown in fig. 2, a Header integrity flag "F/C" field value in a packet (EHC Compressed Header, abbreviated as EHC CH) without Header compression by the EHC is set to "0" for indicating that the packet includes a complete Header, that is, the packet is not Compressed. The CID is an identifier for marking a compression context, i.e., a compression context identifier. The Ethernet header is the Ethernet header and the PAYLOAD (+ PAD) is the PAYLOAD.

Optionally, the first indication information may further include a first length of the context identifier or the data flow identifier corresponding to the current compression, and a second length of the context identifier or the data flow identifier corresponding to the last compression. For example, the Length of the compression context identifier corresponding to the present compression and the last compression can be indicated by ehc-CID-Length, for example, using 7 bits (bits) or 15 bits.

As shown in fig. 4, the step S302 of sending the data packet without header compression may specifically include the following steps S401, S402, or S403.

S401, in response to the first length being different from the second length, the data packet without header compression is sent by using the compression context identifier or the data flow identifier of the first length.

Specifically, if the first length of the compression context identifier or the 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 the data stream identifier corresponding to the previous compression, that is, the length of the compression context identifier or the data stream identifier is changed, the compression context identifier or the data stream identifier of the first length is used to send the data packet without header compression, that is, the length of the identifier used to identify the compression context in the header of the sent data packet without header compression is the first length, and the header includes a header integrity identifier used to identify that the data packet includes a complete header. For example, if the first length of the compression context identifier corresponding to the current compression is 15 bits, and the second length of the compression context identifier corresponding to the previous compression is 7 bits, the length of the compression context identifier CID in the data packet that is sent and is not subjected to header compression as shown in fig. 2 is 15 bits, and the field value of "F/C" is set to "0".

S402, responding to the first length being the same as the second length, adopting the compression context identifier or the data flow identifier with the first length and being the same as the compression context identifier or the data flow identifier corresponding to the last compression to send the data packet without the header compression.

Specifically, if the first length of the context identifier or the data flow identifier corresponding to the current compression in the first indication information is the same as the second length of the context identifier or the data flow identifier corresponding to the previous compression, that is, the length of the compression context identifier or the data stream identifier is not changed, the data packet without header compression is still transmitted by using the compression context identifier or the data stream identifier with the first length and the same as the compression context identifier or the data stream identifier corresponding to the last compression, that is, the length of the header of the transmitted data packet without header compression for identifying the compression context or the data stream is the second length, and the identifier for identifying the compression context or the data stream is the compression context or the data stream identifier corresponding to the last 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 the current compression is 7 bits, and the second length of the compression context identifier CID-1 corresponding to the last compression is 7 bits, the length of the compression context identifier CID-1 in the data packet shown in fig. 2 that is sent without header compression is 7 bits, and the field value of "F/C" is set to "0".

For the situation that the decompression end does not discard the compression context, the compression end sends the data packet without header compression by using the compression context identifier or the data flow identifier corresponding to the last compression, so that the decompression end can reestablish the compression context.

And S403, in response to that the first length is the same as the second length, sending the data packet without header compression by using the compression context identifier or the data flow identifier with the first length and different from the compression context identifier or the data flow identifier corresponding to the last compression.

Specifically, if the first length of the compression context identifier or the 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 the data stream identifier corresponding to the last compression, that is, the length of the compression context identifier or the data stream identifier is not changed, the data packet without header compression is transmitted by using the compression context or the data stream identifier with the first length and different from the compression context identifier or the data stream identifier corresponding to the last compression, that is, the length of the header of the transmitted data packet without header compression for identifying the compression context or the data stream is a first length, and the identifier for identifying the compression context or the data stream is different from the compression context identifier corresponding to the last compression, and the packet header includes a header integrity identifier for identifying that the data packet includes a complete packet header. For example, the first length of the compression context identifier CID-2 corresponding to the current compression is 7 bits, and the second length of the compression context identifier CID-1 corresponding to the last compression is 7 bits, then the length of the compression context identifier CID-2 in the data packet shown in fig. 2 that is sent without header compression is 7 bits, and the compression context identifier CID-2 is not CID-1 any more, and the field value of "F/C" is set to "0".

Optionally, before the step S302 sends the data packet without header compression, the compression processing method in the embodiment of the present application may further include the following steps: decompression failure information is received, wherein the decompression failure information comprises a failure type indication such as a compression context identifier, e.g., CID-1, of a compressed packet with a header compressed and a decompression failure. The decompression failure information is used for indicating the compression end not to send the compressed data packet corresponding to the compression context identifier of decompression failure.

Fig. 5 is a schematic structural diagram of an EHC compressed data packet, and as shown in fig. 5, a field value of a Header integrity identifier "F/C" in the EHC compressed data packet (EHC Full Header, EHC FH for short) is set to "1" for identifying that the data packet includes an incomplete Header, that is, the data packet is compressed. The CID is an identification for marking a compression context, i.e., a compression context identification. PAYLOAD (+ PAD) is the PAYLOAD.

Those skilled in the art will appreciate that the EHC compression context establishment procedure is as follows: the compression end sends the uncompressed Ethernet data packet (namely the EHC FH packet) which is not compressed by the Ethernet packet header to the decompression end. After receiving the "EHC FH packet", the decompressor feeds back a reception acknowledgement message (as shown in fig. 6, which is a schematic structural diagram of an EHC feedback packet, where R is a feedback identifier) to the compressor. The compression end sends the compressed ethernet data packet (i.e. EHC CH packet) with the ethernet header compressed to the decompression end. A compression context is then established between the compression side and the decompression side, the compression context being marked by the CID. Wherein, the compressed context stores the Ethernet packet head information before and after compression. The compression end sends the compressed ethernet data packet according to the compression context, and the decompression end restores the compressed ethernet data packet into a non-compressed ethernet data packet before compression according to the compression context.

In the embodiment of the application, the compression end discards the established compression context before establishing a new compression context according to the first indication information, and sends the data packet without header compression instead of sending the compressed data packet with header compression, so that the situation that the decompression end cannot continue in the compression function can be avoided, and the header compression state of the data packet is not consistent with the header compression state of the data packet at the compression end, so that the decompression failure of the packet header of the data packet is caused.

Fig. 7 is a flowchart illustrating another compression processing method according to an embodiment of the present application, which is executed by a decompression end. As shown in fig. 7, the compression processing method includes the steps of:

s701, discarding the established compression context according to the second indication information.

As a feasible implementation manner, the decompression end may discard the previously established compression context before establishing a new compression context according to the convention of the communication protocol, so as to successfully receive the data packet which is sent by the compression end and is not subjected to the header compression under the condition that the compression function cannot be continued, and avoid that the header compression state of the data packet is not understood to be consistent with the header compression state of the data packet at the compression end due to the fact that the compression state of the current data packet cannot be obtained, and further, the decompression of the packet header of the data packet fails.

As another possible implementation, the decompressing 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, for example, the base station, so as to successfully receive the data packet that is sent by the compressing end without performing the header compression under the condition that the compression function cannot be continued, thereby avoiding that the header compression state of the data packet is not consistent with the header compression state of the data packet at the compressing end due to failure to obtain the compression state of the current data packet, and further causing the header decompression failure of the data packet.

Optionally, the second indication information may specifically include, but is not limited to, at least one of the following: information used for indicating that the network side configures a packet header compression function for a decompression end; information for instructing the terminal device to reestablish the decompression side; and information for indicating that the network side does not indicate continuous use of the header compression function.

For example, ehc-Downlink may indicate that the network side configures the decompression end with compressing the ethernet packet header of the downstream data. The terminal equipment can be instructed to reestablish the PDCP decompression end through the reatestabilish PDCP.

According to the compression processing method, the decompression end discards the established compression context according to the second indication information, so that the data packet which is sent by the compression end and is not subjected to header compression under the condition that the compression function cannot be continued is successfully received, and the condition that understanding of the header compression state of the data packet is inconsistent with that of the compression end due to the fact that the compression state of the current data packet cannot be obtained, and further the packet header decompression failure of the data packet is avoided.

Fig. 8 is a flowchart illustrating another compression processing method according to an embodiment of the present application, which is executed by a decompression end. As shown in fig. 8, the compression processing method includes the steps of:

s801, discarding the established compression context according to the second indication information.

For example, ehc-Downlink may indicate that the network side configures the decompression side with compressing the ethernet packet header of the Downlink data. The terminal equipment can be instructed to reestablish the PDCP decompression end through the reatestabilish PDCP.

And S802, receiving the compressed data packet subjected to the header compression, wherein the data packet which is not subjected to the header compression and has the same compression context identifier as the compressed data packet is not received before the compressed data packet subjected to the header compression is received.

S803, a decompression failure processing operation is performed.

Specifically, if the decompression end receives a compressed data packet sent by the compression end and subjected to header compression, and does not receive a data packet which is not subjected to header compression and has the same compression context identifier as the compressed data packet before receiving the compressed data packet subjected to header compression, the decompression failure processing operation is performed.

For example, the decompressor receives a compressed packet with the compression context identifier CID-1 sent by the entity, and before receiving the compressed packet with the compression context identifier CID-1, does not receive a packet without header compression and with the compression context identifier CID-1, and then performs a decompression failure processing operation.

The packet header of the data packet without header compression may specifically include, but is not limited to, a header integrity identifier for identifying that the data packet includes a complete packet header, and the like. Fig. 2 is a schematic structural diagram of a packet without Header compression by an EHC, and as shown in fig. 2, a Header integrity flag "F/C" field value in a packet (EHC Compressed Header, abbreviated as EHC CH) without Header compression by the EHC is set to "0" for identifying that the packet includes a complete Header, that is, the packet is not Compressed. The CID is an identification for marking a compression context, i.e., a compression context identification. The Ethernet header is the Ethernet header and the PAYLOAD (+ PAD) is the PAYLOAD.

Those skilled in the art will appreciate that the EHC compression context is established as follows: the compression end sends the uncompressed Ethernet data packet (namely the EHC FH packet) which is not compressed by the Ethernet packet header to the decompression end. After receiving the "EHC FH packet", the decompressor feeds back a reception acknowledgement message (as shown in fig. 6, where R is a feedback identifier) to the compressor. The compression end sends the compressed ethernet data packet (i.e. EHC CH packet) with the ethernet header compressed to the decompression end. And a compression context is established between the compression end and the decompression end, and the compression context is marked by CID. Wherein, the compression context stores the Ethernet packet head information before and after compression. The compression end sends the compressed ethernet data packet according to the compression context, and the decompression end restores the compressed ethernet data packet into a non-compressed ethernet data packet before compression according to the compression context.

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

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

Optionally, before discarding the established compression context in step S801, the compression processing method according to the embodiment of the present application may further include the following steps: receiving third indication information configured by a network side, wherein the third indication information comprises a packet header integrity identifier for identifying that a data packet comprises a complete packet header, and the packet header integrity identifier corresponds to a preset compression context identifier and is not subjected to packet header compression; and determining that the received data packet is a data packet without header compression in response to that the compression context identifier of the received data packet is the same as the preset compression context identifier.

Specifically, the decompressing end receives third indication information configured by the network side, where the third indication information includes a header integrity identifier for identifying that the data packet includes a complete header, in a header of a data packet that is not subjected to header compression and corresponds to the preset compression context identifier, that is, the third indication information is used for indicating, and for a data packet that is not subjected to header compression and is identified by the header integrity identifier, the data packet includes the complete header, and if the compression context identifier of the received data packet is the same as the preset compression context identifier, the received data packet is determined to be a data packet that is not subjected to header compression.

According to the compression processing method, the decompression end discards the established compression context according to the second indication information, so that the data packet which is sent by the compression end under the condition that the compression function cannot be continued and is not subjected to packet header compression is successfully received, and the situation that the understanding of the packet header compression state of the data packet is inconsistent with the understanding of the packet header compression state of the data packet by the compression end and the decompression failure of the packet header of the data packet is avoided.

Corresponding to the compression processing methods provided in the foregoing several embodiments, the present application further provides a compression processing apparatus, where the compression processing apparatus is applied to a compression end, and since the compression processing apparatus provided in the embodiments of the present application corresponds to the compression processing method provided in the foregoing embodiments of fig. 1 to 4, an implementation manner of the compression processing method is also applicable to the compression processing apparatus provided in the present embodiment, and is not described in detail in the present embodiment.

Fig. 9 is a schematic structural diagram of a compression processing apparatus according to an embodiment of the present application.

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

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

Optionally, the header compression is ethernet header compression.

Optionally, the first indication information includes at least one of: information used for indicating the network side to configure the header compression function for the compression end; information for instructing the terminal device to reestablish the compression side; and information for indicating that the network side does not indicate continuous use of the packet header compression function.

Optionally, the sending module 910 is further configured to: the established compression context is discarded before sending packets that are not header compressed.

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

Optionally, the first indication information includes a first length of a compression context identifier or a data stream identifier corresponding to the current compression and a second length of a compression context identifier or a data stream identifier corresponding to the last compression; the sending module is specifically configured to: in response to that the first length is different from the second length, adopting a compression context identifier or a data flow identifier of the first length to send a data packet which is not subjected to header compression; or, in response to that the first length is the same as the second length, sending the data packet without header compression by using the compression context identifier or the data flow identifier which has the first length and is the same as the compression context identifier or the data flow identifier corresponding to the last compression; or, in response to that the first length is the same as the second length, sending the data packet without header compression by using the compression context identifier or the data flow identifier of the first length and different from the compression context identifier or the data flow identifier corresponding to the last compression.

Optionally, the sending module 910 is further configured to: before sending a data packet without header compression, receiving decompression failure information, wherein the decompression failure information comprises a failure type indication and a compression context identifier of a compressed data packet which is subjected to header compression and fails to be decompressed.

According to the compression processing device in the embodiment of the application, the compression end discards the established compression context before establishing a new compression context according to the first indication information, and sends the data packet without header compression instead of sending the compressed data packet with header compression, so that the situation that the decompression end cannot continue in the compression function can be avoided, and the header compression state of the data packet is not consistent with the header compression state of the data packet understood by the compression end, and the packet header decompression failure of the data packet is further caused.

Corresponding to the compression processing methods provided in the foregoing several embodiments, the present application also provides a compression processing apparatus, where the compression processing apparatus is applied to a user terminal, and since the compression processing apparatus provided in the embodiments of the present application corresponds to the compression processing method provided in the foregoing embodiments of fig. 7 to 8, an implementation manner of the compression processing method is also applied to the compression processing apparatus provided in the embodiments, and is not described in detail in the embodiments.

Fig. 10 is a schematic structural diagram of a compression processing apparatus according to an embodiment of the present application.

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

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

Optionally, the second indication information includes at least one of: information used for indicating that the network side configures a packet header compression function for a decompression end; information for instructing the terminal device to reestablish the decompression side; and information for indicating that the network side does not indicate continuous use of the packet header compression function.

Optionally, the header compression is ethernet header compression.

Optionally, the compression processing apparatus according to the embodiment of the present application may further include: a receiving module configured to receive the compressed data packet subjected to the header compression after the discarding module 1010 discards the established compression context, wherein the data packet not subjected to the header compression, which is the same as the compression context identifier of the compressed data packet, is not received before the compressed data packet subjected to the header compression is received; a decompression failure handling 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, wherein the decompression failure information comprises a failure type indication.

Optionally, the decompression failure information further includes at least one of the following: compressing context identification of the compressed data packet; compressing the data stream identification of the data packet; and the bearer identification of the compressed data packet.

Optionally, the receiving module is further configured to: before the discarding module 1010 discards the established compression context, receiving third indication information configured by the network side, where the third indication information includes a packet header integrity identifier for identifying that the data packet includes a complete packet header, in a packet header of a data packet which is not subjected to packet header compression and corresponds to a preset compression context identifier; and determining that the received data packet is a data packet without header compression in response to that the compression context identifier of the received data packet is the same as the preset compression context identifier.

According to the compression processing device in the embodiment of the application, the decompression end discards the established compression context according to the second indication information, so as to successfully receive the data packet which is sent by the compression end and is not subjected to header compression under the condition that the compression function cannot be continued, and avoid the situation that the header compression state of the data packet is not consistent with the header compression state of the data packet understood by the compression end, and further the decompression failure of the packet header of the data packet is caused.

According to an embodiment of the present application, the present application further provides a compression end, including the compression processing apparatus 900 provided in the embodiment of the present application.

According to the compression end of the embodiment of the application, before the new compression context is established, the established compression context is discarded and the data packet without header compression is sent instead of the compressed data packet with the header compression, so that the situation that the decompression end cannot continue in the compression function can be avoided, and the situation that the header compression state of the data packet is not consistent with the header compression state of the data packet by the compression end and the decompression failure of the packet header of the data packet is caused due to the fact that the compression state of the current data packet cannot be obtained.

According to an embodiment of the present application, the present application further provides a decompression end, which includes the compression processing apparatus 1000 provided in the embodiment of the present application.

The decompression end of the embodiment of the application discards the established compression context according to the second indication information so as to successfully receive the data packet which is sent by the compression end under the condition that the compression function cannot be continued and is not subjected to packet header compression, and avoid the situation that the understanding of the packet header compression state of the data packet is inconsistent with that of the compression end to the data packet due to the fact that the compression state of the current data packet cannot be obtained, and further the decompression failure of the packet header of the data packet is caused.

According to an embodiment of the present application, an electronic device and a readable storage medium are also provided.

As shown in fig. 11, 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, mainframes, and other appropriate computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular telephones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the present application that are described and/or claimed herein.

As shown in fig. 11, the electronic apparatus includes: one or more processors 1100, a memory 1200, and interfaces for connecting the 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 in other manners as desired. The processor may process instructions for execution within the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input/output apparatus (such as a display device coupled to the interface). In other embodiments, multiple processors and/or multiple buses may be used, along with multiple memories and multiple memories, if desired. Also, multiple electronic devices may be connected, with each device providing portions of the necessary operations (e.g., as a server array, a group of blade servers, or a multi-processor system). One processor 1100 is illustrated in fig. 11.

The memory 1200 is a non-transitory computer readable storage medium provided herein. The memory stores instructions executable by the at least one processor to cause the at least one processor to perform the compression processing method provided by the present application. The non-transitory computer-readable storage medium of the present application stores computer instructions for causing a computer to execute the compression processing method provided by the present application.

The memory 1200, which is a non-transitory computer-readable storage medium, may be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as program instructions/modules (e.g., the sending module 910 shown in fig. 9) corresponding to the compression processing method in the embodiments of the present application. The processor 1100 executes various functional applications of the server and data processing, i.e., implements the compression processing method in the above-described method embodiments, by executing non-transitory software programs, instructions, and modules stored in the memory 1200.

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 from use of the positioning electronic device, and the like. Further, the 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, which may be connected to the positioning electronics via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, 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 other means, and fig. 11 illustrates the connection by a bus as an example.

The input device 1300 may receive input numeric or character information and generate key signal inputs related to user settings and function controls of the pointing electronic device, such as a touch screen, keypad, mouse, track pad, touch pad, pointer stick, one or more mouse buttons, track ball, joystick, or other input device. The output device 1400 may include a display device, an auxiliary lighting device (e.g., an LED), a haptic feedback device (e.g., a vibration motor), 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 can be a touch screen.

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

These computer programs (also known as programs, software applications, or code) include machine instructions for a programmable processor, and may be implemented using high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

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

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.

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

It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present application may be executed in parallel, sequentially, or in different orders, and the present invention is not limited thereto as long as the desired results of the technical solutions disclosed in the present application can be achieved.

Claims

A compression processing method is applied to a compression end, and the method comprises the following steps:

and transmitting the data packet without the header compression according to the first indication information.
The method of claim 1, wherein the 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:

information for indicating that the network side configures a packet header compression function for the compression end;

information for instructing the terminal device to reestablish the compression side; and

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

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

in response to that the first length is different from the second length, sending the data packet without header compression by using a compression context identifier or a data stream identifier of the first length; or,

in response to that the first length is the same as the second length, sending the data packet without header compression by using a compression context identifier or a data flow identifier which has the first length and is the same as a compression context identifier or a data flow identifier corresponding to the last compression; or,

and in response to that the first length is the same as the second length, sending the data packet without header compression by using a compression context identifier or a data flow identifier which has the first length and is different from a compression context identifier or a data flow identifier corresponding to the last compression.
The method according to any one of claims 1-6, wherein before sending the data packet without header compression, further comprising:

receiving decompression failure information, wherein the decompression failure information comprises a failure type indication and a compression context identifier of a compressed data packet which fails decompression and is subjected to header compression.
A compression processing method is applied to a decompression end, and the method comprises the following steps:

based on the second indication information, the established compression context is discarded.
The method of claim 8, wherein the second indication information comprises at least one of:

information for indicating that the network side configures a packet header compression function for the decompression end;

information for instructing the terminal device to reestablish the decompression side; and

the information is used for indicating that the network side does not indicate continuous use of the packet header compression function.
The method of claim 9, wherein the header compression is ethernet header compression.
The method of any of claims 8-10, wherein after discarding the established compression context, the method further comprises:

receiving a compressed data packet subjected to header compression, wherein a data packet which is not subjected to header compression and has the same compression context identifier as the compressed data packet is not received before the compressed data packet subjected to header compression is received;

a decompression failure handling operation is performed.
The method of claim 11, wherein the performing decompression failure handling operations comprises at least one of:

discarding the compressed data packet; and

sending decompression failure information, wherein the decompression failure information comprises a failure type indication.
The method of claim 12, wherein the decompression failure information further comprises at least one of:

a compression context identification of the compressed data packet;

a data flow identification of the compressed data packet; and

and the bearing identification of the compressed data packet.
The method of any of claims 8-13, wherein prior to said discarding the established compression context, the method further comprises:

receiving third indication information configured by the network side, wherein the third indication information includes a packet header integrity identifier for identifying that the data packet includes a complete packet header, and the packet header of the data packet which is not subjected to packet header compression and corresponds to a preset compression context identifier;

and determining that the received data packet is the data packet without header compression in response to that the compression context identifier of the received data packet is the same as the preset compression context identifier.
A compression processing apparatus applied to a compression side, the apparatus comprising:

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

discarding the established compression context before said sending the data packet without header compression.
The apparatus according to claim 15 or 16, wherein the first indication information includes a first length of the compression context identifier or the data stream identifier corresponding to the current compression, and a second length of the compression context identifier or the data stream identifier corresponding to the last compression; the sending module is specifically configured to:

in response to that the first length is different from the second length, sending the data packet without header compression by using the compression context identifier or the data flow identifier of the first length; or,

in response to that the first length is the same as the second length, sending the data packet without header compression by using the compression context identifier or the data flow identifier which has the first length and is the same as the compression context identifier or the data flow identifier corresponding to the last compression; or,

and in response to that the first length is the same as the second length, sending the data packet without header compression by using a compression context identifier or a data flow identifier which has the first length and is different from a compression context identifier or a data flow identifier corresponding to the last compression.
The apparatus of any one of claims 15-17, wherein the transmitting module is further configured to:

before the data packet which is not subjected to the header compression is sent, decompression failure information is received, wherein the decompression failure information comprises a failure type indication and a compression context identifier of the compressed data packet which is subjected to the header compression and fails in decompression.
A compression processing apparatus, applied to a decompression end, the apparatus comprising:

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

a receiving module configured to receive a compressed data packet with a header compression after the discarding module discards the established compression context, wherein a data packet without a header compression, which is the same as a compression context identifier of the compressed data packet, is not received before the compressed data packet with a header compression is received; a decompression failure handling operation is performed.
The apparatus of claim 20, wherein the receiving module is specifically configured to perform at least one of:

discarding the compressed data packet; and

sending decompression failure information, wherein the decompression failure information comprises a failure type indication.
The apparatus of any one of claims 19-21, wherein the receiving module is further configured to:

before the discarding module discards the established compression context, receiving third indication information configured by the network side, where the third indication information includes a packet header integrity identifier for identifying that the data packet includes a complete packet header, in the packet header of the data packet corresponding to a preset compression context identifier; and determining the received data packet as the data packet in response to the fact that the compression context identifier of the received data packet is the same as the preset compression context identifier.
A compression end, comprising: a compression processing apparatus according to any one of claims 15 to 18, or a packet header compression processing apparatus according to any one of claims 19 to 22.
A decompression end, comprising: a packet header compression processing apparatus according to any one of claims 15 to 18, or a compression processing apparatus according to any one of claims 19 to 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 to enable the at least one processor to perform the compression processing method of any one of claims 1-7 or the compression processing method of any one of claims 8-14.
A computer-readable storage medium storing computer instructions for causing a computer to perform the compression processing method of any one of claims 1 to 7 or the compression processing method of any one of claims 8 to 14.