Compression processing method and device

Abstract

The invention provides a compression processing method and device, and relates to the technical field of mobile communication. According to the scheme, a data packet of which the packet header is not compressed is sent according to 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 consistent understanding on the compression state of the packet header of the data packet, and the failure of decompression of the packet header of the data packet is avoided.

Description

[0001] This application is a divisional application of application number 202180000140.7, application date January 13, 2021, and invention name “A compression processing method and device”. Technical Field

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

[0003] In the related art, when the network side configures a compression function for the compression end of the user terminal, such as a protocol entity, and instructs the user terminal to rebuild the entity, if the compression function cannot continue, it is easy to cause the compression end and the decompression end to have inconsistent understandings of the compression status of the data packet header, thereby causing the data packet header decompression to fail. Summary of the invention

[0004] 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 understandings of the compression status of the packet header of the data packet, thereby causing the decompression of the packet header to fail.

[0005] The first aspect of the present application proposes a compression processing method, which is applied to a compression end, and the method includes: obtaining first indication information, the first indication information including: information used to indicate the re-establishment of the compression end; information used to indicate the configuration of a header compression function for the compression end; information used to indicate that the header compression function is not used continuously; and information used to indicate that the header of a data packet that has not undergone header compression includes a header integrity identifier used to identify that the data packet includes a complete header.

[0006] The second aspect embodiment of the present application proposes another compression processing method, which is applied to the decompression end, and the method includes: obtaining second indication information, the second indication information including: information used to indicate the re-establishment of the decompression end; information used to indicate the configuration of the header compression function for the decompression end; information used to indicate that the header compression function is not used continuously; and information used to indicate that the header of a data packet that has not undergone header compression includes a header integrity identifier used to identify that the data packet includes a complete header.

[0007] The third aspect embodiment of the present application proposes a compression processing device, which is applied to a compression end, and the device is used to: obtain first indication information, the first indication information including: information used to indicate the re-establishment of the compression end; information used to indicate the configuration of a header compression function for the compression end; information used to indicate that the header compression function is not used continuously; and information used to indicate that the header of a data packet that has not undergone header compression includes a header integrity identifier used to identify that the data packet includes a complete header.

[0008] The fourth aspect embodiment of the present application proposes another compression processing device, which is applied to the decompression end, and the device is used to: obtain second indication information, the second indication information including: information used to indicate the re-establishment of the decompression end; information used to indicate the configuration of the header compression function for the decompression end; information used to indicate that the header compression function is not used continuously; and information used to indicate that the header of a data packet that has not undergone header compression includes a header integrity identifier used to identify that the data packet includes a complete header.

[0009] The fifth aspect of the present application provides a compression end, including the compression processing device described in the third aspect of the present application.

[0010] The sixth aspect embodiment of the present application provides a decompression end, including the compression processing device described in the fourth aspect embodiment of the present application.

[0011] The seventh aspect embodiment of the present application provides a terminal, including the compression processing device described in the third aspect embodiment of the present application, or the compression processing device described in the fourth aspect embodiment of the present application.

[0012] The eighth aspect embodiment of the present application provides a network device, including the compression processing device described in the third aspect embodiment of the present application, or the compression processing device described in the fourth aspect embodiment of the present application.

[0013] The ninth aspect embodiment of the present application provides an electronic device, comprising: at least one processor; and a memory communicatively connected 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 so that the at least one processor can execute the compression processing method described in the first aspect embodiment of the present application, or the compression processing method described in the second aspect embodiment of the present application.

[0014] The tenth aspect embodiment 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 the processor, the compression processing method described in the first aspect embodiment of the present application, or the compression processing method described in the second aspect embodiment of the present application can be implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0016] Figure 1 A schematic diagram of a compression processing method provided in an embodiment of the present application;

[0017] Figure 2This is a schematic diagram of the structure of a data packet without header compression performed by EHC;

[0018] Figure 3 A schematic diagram of a flow chart of another compression processing method provided in an embodiment of the present application;

[0019] Figure 4 A schematic diagram of a flow chart of another compression processing method provided in an embodiment of the present application;

[0020] Figure 5 This is a schematic diagram of the structure of the EHC compressed data packet;

[0021] Figure 6 This is a schematic diagram of the structure of the EHC feedback data packet;

[0022] Figure 7 A schematic diagram of a flow chart of another compression processing method provided in an embodiment of the present application;

[0023] Figure 8 A schematic diagram of a flow chart of another compression processing method provided in an embodiment of the present application;

[0024] Fig. 9 A schematic diagram of the structure of a compression processing device provided in an embodiment of the present application;

[0025] Fig.10 A schematic diagram of the structure of another compression processing device provided in an embodiment of the present application;

[0026] Fig.11 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0028] The terms used in the disclosed embodiments are only for the purpose of describing specific embodiments and are not intended to limit the disclosed embodiments. The singular forms of "a", "an", "the" and "the" used in the disclosed embodiments and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0029] It should be understood that although the terms first, second, third, etc. may be used to describe various information in the disclosed embodiments, these 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 disclosed embodiments, 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 may be interpreted as "at the time of" or "when" or "in response to determining".

[0030] 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 the wireless access network to provide wireless access functions for the user terminal. The base station can communicate wirelessly with the user terminal via one or more antennas. The base station can provide communication coverage for its geographical area. The base station may include different types such as macro base stations, micro base stations, relay stations, access points, etc. In some embodiments, the base station may be referred to as a base station transceiver, a wireless base station, an access point, a wireless transceiver, a basic service set (Basic Service Set, BSS), an extended service set (Extended Service Set, ESS), a Node B (NodeB), an evolved Node B (evolved NodeB, eNB or eNodeB) or some other appropriate terms by those skilled in the art. Exemplarily, in a 5G system, the base station is referred to as a gNB. For the convenience of description, in the embodiments of the present application, the above-mentioned devices that provide wireless communication functions for user terminals are collectively referred to as base stations.

[0031] User terminals can be scattered throughout the mobile communication system, and each user terminal can be stationary or mobile. User terminals can also be referred to as mobile stations, user stations, mobile units, subscriber units, wireless units, remote units, mobile devices, terminal equipment, wireless devices, wireless communication devices, remote devices, mobile user stations, access user equipment, mobile user equipment, wireless user equipment, remote user equipment, handheld devices, user agents, mobile clients, clients or some other appropriate terms by those skilled in the art. User terminals can be cellular phones, personal digital assistants (PDAs), wireless modems, wireless communication devices, handheld devices, tablet computers, laptop computers, cordless phones, wireless local loops (WLL) stations, etc., and can communicate with base stations in mobile communication systems.

[0032] Figure 1 A schematic diagram of a compression processing method provided in an embodiment of the present application is shown in FIG. Figure 1 As shown, the compression processing method includes the following steps:

[0033] S101: Send a data packet without header compression according to first indication information.

[0034] Specifically, the compression end and the decompression end may be a network entity, such as a functional module in a Packet Data Convergence Protocol (PDCP) entity, or an independent network entity. In addition to being present in base stations and terminal devices, the compression end and the decompression end may also be present in network devices, such as: between routers; between gateways and base stations; between gateways.

[0035] As a feasible implementation method, the compression end can, in accordance with the agreement of the communication protocol, send a data packet without header compression before establishing a new compression context, instead of sending a compressed data packet with header compression, so as to avoid the situation where the decompression end cannot obtain the compression status of the current data packet when the compression function cannot continue, resulting in inconsistent understanding of the data packet header compression status with the compression end, and further causing the data packet header decompression failure.

[0036] As another feasible implementation, the compression end may, based on the first indication information configured by the network side, such as the base station, send a data packet without header compression before establishing a new compression context, instead of sending a compressed data packet with header compression, so as to avoid the decompression end being unable to obtain the compression status of the current data packet when the compression function cannot continue, resulting in inconsistent understanding of the data packet header compression status with the compression end, and further causing the data packet header decompression failure.

[0037] Among them, in the case where the compression function cannot continue, for example, the user terminal switches from base station gNB-1 to base station gNB-2, and the network side entity corresponding to the user terminal changes from gNB-1 to gNB-2, both gNB-1 and gNB-2 are configured with compression functions, but because gNB-2 cannot obtain the compression status of the packet header compression of the gNB-1 entity (including compression context information), gNB-2 cannot continue to use the compression context of the packet header compression of gNB-1 for decompression.

[0038] 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, referred to as EHC) and the like.

[0039] Optionally, the first indication information may specifically include but is not limited to at least one of the following: information used to indicate that the network side has configured a packet header compression function for the compression end; information used to indicate that the terminal device has re-established the compression end; and information used to indicate that the network side has not indicated the continuous use of the packet header compression function.

[0040] For example, ehc-Uplink can be used to indicate that the network side has configured the compression end to compress the Ethernet packet header of the uplink data. Reestablish PDCP can be used to instruct the terminal device to re-establish the PDCP compression end.

[0041] The packet header of the data packet that has not undergone 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. Figure 2 This is a schematic diagram of the structure of a data packet without header compression performed by EHC, such as Figure 2 As shown, the header integrity identifier "F / C" field value in the EHC uncompressed header data packet (EHC Compressed Header, referred to as EHC CH) is set to "0", which is used to identify that the data packet includes a complete header, that is, it has not been compressed. CID (Context Identity) is an identifier used to mark the compression context, that is, the compression context identifier. Ethernet header is the Ethernet header, and PAYLOAD (+PAD) is the payload.

[0042] In an embodiment of the present application, the compression end sends a data packet without header compression before establishing a new compression context based on the first indication information, instead of sending a compressed data packet with header compression. This can avoid the situation where the decompression end is unable to obtain the compression status of the current data packet when the compression function cannot continue, resulting in an inconsistent understanding of the data packet header compression status with the compression end, which in turn causes the data packet header decompression failure.

[0043] Figure 3 FIG. 1 is a flow chart of another compression processing method provided in an embodiment of the present application, which is executed by the compression end. Figure 3 As shown, the compression processing method includes the following steps:

[0044] S301: discard an established compression context according to first indication information.

[0045] Specifically, the compression end and the decompression end can be a functional module in a network entity such as a Packet Data Convergence Protocol (PDCP) entity, or an independent network entity. In addition to being present in base stations and terminal devices, the compression end and the decompression end can also be present in network devices, such as: between routers; between gateways and base stations; between gateways.

[0046] As a feasible implementation mode, the compressor may discard the previously established compression context before establishing a new compression context according to the agreement of the communication protocol.

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

[0048] S302, sending a data packet without header compression.

[0049] Specifically, after discarding the compression context established previously, the compression end sends a data packet without header compression instead of sending a compressed data packet with header compression, so as to avoid the decompression end being unable to obtain the compression status of the current data packet when the compression function cannot continue, resulting in inconsistent understanding of the data packet header compression status with the compression end, and further causing the data packet header decompression failure.

[0050] Among them, in the case where the compression function cannot continue, for example, the user terminal switches from base station gNB-1 to base station gNB-2, and the network side entity corresponding to the user terminal changes from gNB-1 to gNB-2, both gNB-1 and gNB-2 are configured with compression functions, but because gNB-2 cannot obtain the compression status of the packet header compression of the gNB-1 entity (including compression context information), gNB-2 cannot continue to use the compression context of the packet header compression of gNB-1 for decompression.

[0051] 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, referred to as EHC) and the like.

[0052] Optionally, the first indication information may specifically include but is not limited to at least one of the following: information used to indicate that the network side has configured a packet header compression function for the compression end; information used to indicate that the terminal device has re-established the compression end; and information used to indicate that the network side has not indicated the continuous use of the packet header compression function.

[0053] For example, ehc-Uplink can be used to indicate that the network side has configured the compression end to compress the Ethernet packet header of the uplink data. Reestablish PDCP can be used to instruct the terminal device to re-establish the PDCP compression end.

[0054] The packet header of the data packet that has not undergone 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. Figure 2 This is a schematic diagram of the structure of a data packet without header compression performed by EHC, such as Figure 2As shown in the figure, the header integrity identifier "F / C" field value in the EHC uncompressed header data packet (EHC Compressed Header, referred to as EHC CH) is set to "0", which is used to identify that the data packet includes a complete header, that is, it has not been compressed. CID is an identifier used to mark the compression context, that is, the compression context identifier. Ethernet header is the Ethernet header, and PAYLOAD (+PAD) is the payload.

[0055] Optionally, the first indication information may also include 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 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, using 7 bits or 15 bits.

[0056] like Figure 4 As shown, the above step S302 sends the data packet without header compression, which may specifically include the following steps S401 or S402 or S403.

[0057] S401: In response to a first length being different from a second length, a compression context identifier or a data flow identifier of a first length is used to send a data packet that is not subjected to header compression.

[0058] 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 length of the compression context identifier or data stream identifier has changed, then 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 length of the identifier used to identify the compression context in the header of the sent data packet without header compression uses the first length, and the header includes a header integrity identifier used to identify that the data packet includes a complete header. For example, 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, then the sent Figure 2 The length of the compression context identifier CID in the data packet without header compression is 15 bits, and the "F / C" field value is set to "0".

[0059] S402: In response to the first length being the same as the second length, sending a data packet without header compression using the first length and a compression context identifier or data flow identifier that is the same as the compression context identifier or data flow identifier corresponding to the previous compression.

[0060] 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 length of the compression context identifier or data stream identifier has not changed, then the compression context identifier or data stream identifier of the first length and the same as the compression context identifier or data stream identifier corresponding to the previous compression is still used to send the data packet without header compression, that is, the length of the identifier used to identify the compression context or data stream in the header of the sent data packet without header compression adopts the second length, and the identifier used to identify the compression context or data stream is the compression context or data stream identifier corresponding to the previous compression, and the header includes a header integrity identifier used to identify that the data packet includes a complete 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 previous compression is 7 bits, then the sent Figure 2 The length of the compression context identifier CID-1 in the data packet without header compression is 7 bits, and the "F / C" field value is set to "0".

[0061] If the decompression end does not discard the compression context, the compression end can re-establish the compression context by sending a data packet without header compression using the compression context identifier or data stream identifier corresponding to the last compression.

[0062] S403: In response to the first length being the same as the second length, sending a data packet without header compression using the first length and a compression context identifier or data flow identifier different from the compression context identifier or data flow identifier corresponding to the previous compression.

[0063] 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 length of the compression context identifier or data stream identifier has not changed, then a compression context identifier or data stream identifier of the first length and different from the compression context identifier or data stream identifier corresponding to the previous compression is used to send a data packet without header compression, that is, the length of the identifier used to identify the compression context or data stream in the header of the sent data packet without header compression uses the first length, and the identifier used to identify the compression context or data stream is different from the compression context identifier corresponding to the previous compression, and the header includes a header integrity identifier used to identify that the data packet includes a complete 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 previous compression is 7 bits, then the sent Figure 2The length of the compression context identifier CID-2 in the data packet without header compression 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".

[0064] Optionally, before step S302 sends the data packet without header compression, the compression processing method of the embodiment of the present application may further include the following steps: receiving decompression failure information, wherein the decompression failure information includes a failure type indication such as decompression failure and a compression context identifier of the compressed data packet with header compression that failed to decompress, such as CID-1. The decompression failure information is used to instruct the compression end not to send the compressed data packet corresponding to the compression context identifier of the decompression failure.

[0065] in, Figure 5 This is a schematic diagram of the structure of the EHC compressed data packet, such as Figure 5 As shown, the header integrity identifier "F / C" field value in the EHC compressed data packet (EHC FullHeader, referred to as EHC FH) is set to "1", which is used to identify that the data packet includes an incomplete header, that is, it has been compressed. CID is an identifier for marking the compression context, that is, the compression context identifier. PAYLOAD (+PAD) is the payload.

[0066] Those skilled in the art can understand that the process of establishing the EHC compression context is as follows: the compression end sends a non-compressed Ethernet data packet (i.e., an EHC FH packet) without Ethernet header compression to the decompression end. After receiving the "EHC FH packet", the decompression end feeds back a reception confirmation message (e.g., Figure 6 The figure shows 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 a compressed Ethernet data packet (i.e., EHCCH packet) with Ethernet header compression to the decompression end. Then a compression context is established between the compression end and the decompression end, and the compression context is marked by CID. Among them, the compression context stores the Ethernet header information before and after compression. The compression end sends a compressed Ethernet data packet according to the compression context, and the decompression end restores the compressed Ethernet data packet to a non-compressed Ethernet data packet before compression according to the compression context.

[0067] In an embodiment of the present application, the compression end discards the established compression context based on the first indication information before establishing a new compression context, and sends a data packet without header compression, instead of sending a compressed data packet with header compression. This can avoid the situation where the decompression end is unable to obtain the compression status of the current data packet when the compression function cannot continue, resulting in an inconsistent understanding of the data packet header compression status by the compression end, which in turn causes the data packet header decompression failure.

[0068] The present application embodiment provides another compression processing method, which is executed by a compression end. The compression processing method includes:

[0069] Obtain first indication information, which specifically includes: information used to indicate re-establishment of a compression end; information used to indicate configuration of a header compression function for the compression end; information used to indicate that the header compression function is not used continuously; and information used to indicate that the header of a data packet that has not undergone header compression includes a header integrity identifier for identifying that the data packet includes a complete header.

[0070] The present application embodiment provides another compression processing method, which is executed by a compression end. The compression processing method includes:

[0071] Obtain first indication information, which specifically includes: information used to indicate re-establishment of a compression end; information used to indicate configuration of a header compression function for the compression end; information used to indicate that the header compression function is not used continuously; and information used to indicate that a packet header that has not undergone header compression includes a header integrity identifier used to identify that the packet includes a complete header; based on the first indication information, discard the established compression context.

[0072] The present application embodiment provides another compression processing method, which is executed by a compression end. The compression processing method includes:

[0073] Obtain first indication information, which specifically includes: information for indicating re-establishing a compression end; information for indicating configuring a header compression function for the compression end; information for not indicating that the header compression function is used continuously; and information for indicating that a packet header that has not undergone header compression includes a header integrity identifier for identifying that the packet includes a complete header; and sending a packet that has not undergone header compression.

[0074] As a feasible implementation manner, the data packet that is not subjected to header compression includes a compression context identifier, and the compression context identifier is a context identifier CID of the compressed data packet. The compression processing method of the embodiment of the present application may further include the following steps:

[0075] A data packet including a compression context identifier and not subjected to header compression is sent, wherein the compression context identifier corresponding to the current compression is the same as the compression context identifier corresponding to the previous compression.

[0076] As another feasible implementation manner, before sending a data packet without header compression, the compression processing method in the embodiment of the present application may further include the following steps:

[0077] Decompression failure information is received, wherein the decompression failure information includes a failure type indication and a compression context identifier of a compressed data packet that has undergone header compression and has failed to be decompressed.

[0078] It should be noted here that the packet header compression in the embodiment of the present application may specifically include but is not limited to Ethernet Header Compression (EHC), etc. The compression end in the embodiment of the present application may be a Packet Data Convergence Protocol PDCP entity, a network entity, a terminal, a network device, a base station, a router, a gateway, etc.

[0079] Figure 7 FIG. 1 is a flow chart of another compression processing method provided in an embodiment of the present application, which is executed by the decompression end. Figure 7 As shown, the compression processing method includes the following steps:

[0080] S701: Discard the established compression context according to the second indication information.

[0081] Specifically, the compression end and the decompression end can be a functional module in a network entity such as a Packet Data Convergence Protocol (PDCP) entity, or an independent network entity. In addition to being present in base stations and terminal devices, the compression end and the decompression end can also be present in network devices, such as: between routers; between gateways and base stations; between gateways.

[0082] As a feasible implementation method, the decompression end 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 data packet without header compression sent by the compression end when the compression function cannot continue, thereby avoiding the inability to obtain the compression status of the current data packet, resulting in inconsistent understanding of the data packet header compression status with the compression end, and further causing the data packet header decompression failure.

[0083] As another feasible implementation, the decompression end may discard the previously established compression context before establishing a new compression context based on the second indication information configured by the network side, such as the base station, so as to successfully receive the data packet without header compression sent by the compression end when the compression function cannot continue, thereby avoiding the inability to obtain the compression status of the current data packet, resulting in inconsistent understanding of the data packet header compression status with the compression end, and further resulting in failure of data packet header decompression.

[0084] Among them, in the case where the compression function cannot continue, for example, the user terminal switches from base station gNB-1 to base station gNB-2, and the network side entity corresponding to the user terminal changes from gNB-1 to gNB-2, both gNB-1 and gNB-2 are configured with compression functions, but because gNB-2 cannot obtain the compression status of the packet header compression of the gNB-1 entity (including compression context information), gNB-2 cannot continue to use the compression context of the packet header compression of gNB-1 for decompression.

[0085] 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, referred to as EHC) and the like.

[0086] Optionally, the second indication information may specifically include but is not limited to at least one of the following: information used to indicate that the network side has configured the header compression function for the decompression end; information used to indicate that the terminal device re-establishes the decompression end; and information used to indicate that the network side has not indicated the continuous use of the header compression function.

[0087] For example, ehc-Downlink can be used to indicate that the network side has configured the decompression end to compress the Ethernet packet header of the downlink data. Reestablish PDCP can be used to indicate that the terminal device reestablishes the PDCP decompression end.

[0088] In the compression processing method 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, thereby avoiding the inability to obtain the compression status of the current data packet, resulting in inconsistent understanding of the data packet header compression status with the compression end, and further causing the data packet header decompression failure.

[0089] Figure 8 FIG. 1 is a flow chart of another compression processing method provided in an embodiment of the present application, which is executed by the decompression end. Figure 8 As shown, the compression processing method includes the following steps:

[0090] S801: Discard the established compression context according to the second indication information.

[0091] Specifically, the compression end and the decompression end can be a functional module in a network entity such as a Packet Data Convergence Protocol (PDCP) entity, or an independent network entity. In addition to being present in base stations and terminal devices, the compression end and the decompression end can also be present in network devices, such as: between routers; between gateways and base stations; between gateways.

[0092] As a feasible implementation method, the decompression end 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 data packet without header compression sent by the compression end when the compression function cannot continue, thereby avoiding the inability to obtain the compression status of the current data packet, resulting in inconsistent understanding of the data packet header compression status with the compression end, and further causing the data packet header decompression failure.

[0093] As another feasible implementation, the decompression end may discard the previously established compression context before establishing a new compression context based on the second indication information configured by the network side, such as the base station, so as to successfully receive the data packet without header compression sent by the compression end when the compression function cannot continue, thereby avoiding the inability to obtain the compression status of the current data packet, resulting in inconsistent understanding of the data packet header compression status with the compression end, and further resulting in failure of data packet header decompression.

[0094] Among them, in the case where the compression function cannot continue, for example, the user terminal switches from base station gNB-1 to base station gNB-2, and the network side entity corresponding to the user terminal changes from gNB-1 to gNB-2, both gNB-1 and gNB-2 are configured with compression functions, but because gNB-2 cannot obtain the compression status of the packet header compression of the gNB-1 entity (including compression context information), gNB-2 cannot continue to use the compression context of the packet header compression of gNB-1 for decompression.

[0095] 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, referred to as EHC) and the like.

[0096] Optionally, the second indication information may specifically include but is not limited to at least one of the following: information used to indicate that the network side has configured the header compression function for the decompression end; information used to indicate that the terminal device re-establishes the decompression end; and information used to indicate that the network side has not indicated the continuous use of the header compression function.

[0097] For example, ehc-Downlink can be used to indicate that the network side has configured the decompression end to compress the Ethernet packet header of the downlink data. Reestablish PDCP can be used to indicate that the terminal device reestablishes the PDCP decompression end.

[0098] S802, receiving a compressed data packet that has undergone header compression, wherein before receiving the compressed data packet that has undergone header compression, a data packet that has not undergone header compression and has the same compression context identifier as the compressed data packet has not been received.

[0099] S803, executing a decompression failure processing operation.

[0100] Specifically, if the decompression end receives a compressed data packet with header compression sent by the compression end, and before receiving the compressed data packet with header compression, it has not received a data packet without header compression that has the same compression context identifier as the compressed data packet, then a decompression failure processing operation is performed.

[0101] For example, if the decompression end receives a compressed data packet with a compression context identifier CID-1 sent by an entity, and before receiving the compressed data packet with the compression context identifier CID-1, it has not received a data packet with a compression context identifier CID-1 that has not been header compressed, then the decompression failure processing operation is performed.

[0102] The packet header of the data packet that has not undergone 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. Figure 2 This is a schematic diagram of the structure of a data packet without header compression performed by EHC, such as Figure 2 As shown in the figure, the header integrity identifier "F / C" field value in the EHC uncompressed header data packet (EHC Compressed Header, referred to as EHC CH) is set to "0", which is used to identify that the data packet includes a complete header, that is, it has not been compressed. CID is an identifier used to mark the compression context, that is, the compression context identifier. Ethernet header is the Ethernet header, and PAYLOAD (+PAD) is the payload.

[0103] in, Figure 5 This is a schematic diagram of the structure of the EHC compressed data packet, such as Figure 5 As shown, the header integrity identifier "F / C" field value in the EHC compressed data packet (EHC FullHeader, referred to as EHC FH) is set to "1", which is used to identify that the data packet includes an incomplete header, that is, it has been compressed. CID is an identifier for marking the compression context, that is, the compression context identifier. PAYLOAD (+PAD) is the payload.

[0104] Those skilled in the art can understand that the process of establishing the EHC compression context is as follows: the compression end sends a non-compressed Ethernet data packet (i.e., an EHC FH packet) without Ethernet header compression to the decompression end. After receiving the "EHC FH packet", the decompression end feeds back a reception confirmation message (e.g., Figure 6As shown, where R is a feedback identifier) ​​to the compression end. The compression end sends a compressed Ethernet data packet (i.e., EHC CH packet) that has been compressed in the Ethernet header to the decompression end. A compression context is then established between the compression end and the decompression end, and the compression context is marked by a CID. The compression context stores the Ethernet header information before and after compression. The compression end sends a compressed Ethernet data packet according to the compression context, and the decompression end restores the compressed Ethernet data packet to a non-compressed Ethernet data packet before compression according to the compression context.

[0105] The decompression failure processing operation performed 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.

[0106] 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.

[0107] Optionally, before discarding the established compression context in step S801, the compression processing method of the embodiment of the present application may further include the following steps: receiving third indication information configured on the network side, the third indication information including a header integrity identifier for identifying that the data packet includes a complete header in the header of a data packet that does not perform header compression corresponding to a preset compression context identifier; in response to the compression context identifier of the received data packet being the same as the preset compression context identifier, determining that the received data packet is a data packet that does not perform header compression.

[0108] Specifically, the decompression end receives the third indication information configured by the network side, and the third indication information includes a header integrity identifier for identifying that the data packet includes a complete header in the header of the data packet that does not perform header compression corresponding to a preset compression context identifier, that is, the third indication information is used to indicate that, for the data packet that does not perform header compression with a preset compression context identifier, the header integrity identifier is used in its header to indicate that the data packet includes a complete header. 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 that does not perform header compression.

[0109] In the compression processing method 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, thereby avoiding the inability to obtain the compression status of the current data packet, resulting in inconsistent understanding of the data packet header compression status with the compression end, and further causing the data packet header decompression failure.

[0110] The present application embodiment provides another compression processing method, which is executed by a decompression end. The compression processing method includes:

[0111] Obtain second indication information, the second indication information including: information for indicating re-establishing a decompression end; information for indicating configuring a header compression function for the decompression end; information for not indicating that the header compression function is used continuously; and information for indicating that a packet header that has not undergone header compression includes a header integrity identifier for identifying that the packet includes a complete header.

[0112] The present application embodiment provides another compression processing method, which is executed by a decompression end. The compression processing method includes:

[0113] Obtain second indication information, the second indication information including: information for indicating re-establishment of a decompression end; information for indicating configuration of a header compression function for the decompression end; information for not indicating that the header compression function is used continuously; and information for indicating that a packet header that has not undergone header compression includes a header integrity identifier for identifying that the packet includes a complete header; based on the second indication information, discard the established compression context.

[0114] The present application embodiment provides another compression processing method, which is executed by a decompression end. The compression processing method includes:

[0115] Obtain second indication information, the second indication information including: information for indicating re-establishing a decompression end; information for indicating configuring a header compression function for the decompression end; information for not indicating that the header compression function is used continuously; and information for indicating that a packet header that has not undergone header compression includes a header integrity identifier for identifying that the packet includes a complete header; and receive a packet that has not undergone header compression.

[0116] As a feasible implementation manner, the data packet that is not subjected to header compression includes a compression context identifier, and the compression context identifier is a context identifier CID of the compressed data packet. The compression processing method of the embodiment of the present application may further include the following steps:

[0117] A data packet including a compression context identifier and not subjected to header compression is received, wherein the compression context identifier of the received data packet is the same as a preset compression context identifier.

[0118] As another feasible implementation manner, after discarding the established compression context, the compression processing method in the embodiment of the present application may further include the following steps:

[0119] A compressed data packet that has been subjected to header compression is received, wherein, before receiving the compressed data packet that has been subjected to header compression, a data packet that has not been subjected to header compression and has the same compression context identifier as the compressed data packet is not received; and a decompression failure processing operation is performed.

[0120] Optionally, the above-mentioned decompression failure processing operation includes at least one of the following operations:

[0121] discarding the compressed data packet; and sending decompression failure information, wherein the decompression failure information includes a failure type indication.

[0122] Optionally, the decompression failure information further includes at least one of the following:

[0123] A compression context identifier of a compressed data packet; a data flow identifier of a compressed data packet; and a bearer identifier of a compressed data packet.

[0124] It should be noted here that the packet header compression in the embodiment of the present application may specifically include but is not limited to Ethernet Header Compression (EHC), etc. The decompression end in the embodiment of the present application may be a Packet Data Convergence Protocol PDCP entity, a network entity, a terminal, a network device, a base station, a router, a gateway, etc.

[0125] Corresponding to the compression processing methods provided in the above embodiments, the present application further provides a compression processing device, which is applied to the compression end. Figure 1-Figure 4 The compression processing method provided in the embodiment corresponds to the above, so the implementation of the compression processing method is also applicable to the compression processing device provided in this embodiment, and will not be described in detail in this embodiment.

[0126] Fig. 9 A schematic diagram of the structure of a compression processing device provided in an embodiment of the present application.

[0127] like Fig. 9 As shown, the compression processing device 900 includes: a sending module 910. Among them:

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

[0129] Optionally, the packet header compression is Ethernet header compression.

[0130] Optionally, the first indication information includes at least one of the following: information used to indicate that the network side has configured a packet header compression function for the compression end; information used to indicate that the terminal device has re-established the compression end; and information used to indicate that the network side has not indicated continuous use of the packet header compression function.

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

[0132] Optionally, the header of the data packet that has not undergone header compression includes a header integrity identifier used to identify that the data packet includes a complete header.

[0133] Optionally, the first indication information includes a first length of a compression context identifier or a data flow identifier corresponding to this compression and a second length of a compression context identifier or a data flow identifier corresponding to a previous compression; the sending module is specifically configured to: in response to the first length being different from the second length, use a compression context identifier or a data flow identifier of the first length to send a data packet that has not undergone header compression; or, in response to the first length being the same as the second length, use a compression context identifier or a data flow identifier of the first length and the same as the compression context identifier or data flow identifier corresponding to the previous compression to send a data packet that has not undergone header compression; or, in response to the first length being the same as the second length, use a compression context identifier or a data flow identifier of the first length and different from the compression context identifier or data flow identifier corresponding to the previous compression to send a data packet that has not undergone header compression.

[0134] Optionally, the sending module 910 is further configured to: before sending a data packet without header compression, receive decompression failure information, wherein the decompression failure information includes a failure type indication and a compression context identifier of a compressed data packet with header compression that failed to decompress.

[0135] In the compression processing device of the embodiment of the present application, the compression end discards the established compression context according to the first indication information before establishing a new compression context, and sends a data packet without header compression, instead of sending a compressed data packet with header compression. This can avoid the situation where the decompression end is unable to obtain the compression status of the current data packet when the compression function cannot continue, resulting in inconsistent understanding of the data packet header compression status with the compression end, thereby causing failure to decompress the data packet header.

[0136] The embodiment of the present application provides another compression processing device, which is applied to a compression end. The compression processing device is configured as follows:

[0137] Obtain first indication information, which specifically includes: information used to indicate re-establishment of a compression end; information used to indicate configuration of a header compression function for the compression end; information used to indicate that the header compression function is not used continuously; and information used to indicate that the header of a data packet that has not undergone header compression includes a header integrity identifier for identifying that the data packet includes a complete header.

[0138] The embodiment of the present application provides another compression processing device, which is applied to a compression end. The compression processing device is configured as follows:

[0139] Obtain first indication information, which specifically includes: information used to indicate re-establishment of a compression end; information used to indicate configuration of a header compression function for the compression end; information used to indicate that the header compression function is not used continuously; and information used to indicate that a packet header that has not undergone header compression includes a header integrity identifier used to identify that the packet includes a complete header; based on the first indication information, discard the established compression context.

[0140] The embodiment of the present application provides another compression processing device, which is applied to a compression end. The compression processing device is configured as follows:

[0141] Obtain first indication information, which specifically includes: information for indicating re-establishment of a compression end; information for indicating configuration of a header compression function for the compression end; information for not indicating that the header compression function is used continuously; and information for indicating that a packet header that has not undergone header compression includes a header integrity identifier for identifying that the packet includes a complete header; the compression processing device also includes a sending module, which is configured to: send a packet header that has not undergone header compression.

[0142] As a feasible implementation manner, the data packet that is not subjected to header compression includes a compression context identifier, and the compression context identifier is a context identifier CID of the compressed data packet. The sending module may also be configured as follows:

[0143] A data packet including a compression context identifier and not subjected to header compression is sent, wherein the compression context identifier corresponding to the current compression is the same as the compression context identifier corresponding to the previous compression.

[0144] As another feasible implementation, the sending module may also be configured as follows:

[0145] Before sending a data packet without header compression, decompression failure information is received, wherein the decompression failure information includes a failure type indication and a compression context identifier of a compressed data packet with header compression that failed to be decompressed.

[0146] It should be noted here that the packet header compression in the embodiment of the present application may specifically include but is not limited to Ethernet Header Compression (EHC), etc. The compression end in the embodiment of the present application may be a Packet Data Convergence Protocol PDCP entity, a network entity, a terminal, a network device, a base station, a router, a gateway, etc.

[0147] Corresponding to the compression processing methods provided in the above embodiments, the present application also provides a compression processing device, which is applied to a user terminal. Since the compression processing device provided in the embodiment of the present application is similar to the above embodiments, Figure 7-Figure 8 The compression processing method provided in the embodiment corresponds to the above, so the implementation of the compression processing method is also applicable to the compression processing device provided in this embodiment, and will not be described in detail in this embodiment.

[0148] Fig.10 A schematic diagram of the structure of a compression processing device provided in an embodiment of the present application.

[0149] like Fig.10 As shown, the compression processing device 1000 includes: a discarding module 1010, wherein:

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

[0151] Optionally, the second indication information includes at least one of the following: information used to indicate that the network side has configured the header compression function for the decompression end; information used to indicate that the terminal device re-establishes the decompression end; and information used to indicate that the network side has not indicated the continuous use of the header compression function.

[0152] Optionally, the packet header compression is Ethernet header compression.

[0153] Optionally, the compression processing device of the embodiment of the present application may further include: a receiving module, configured to receive a compressed data packet that has undergone header compression after the discarding module 1010 discards the established compression context, wherein before receiving the compressed data packet that has undergone header compression, a data packet that has not undergone header compression and has the same compression context identifier as the compressed data packet has not been received; and perform a decompression failure processing operation.

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

[0155] Optionally, the decompression failure information also 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.

[0156] Optionally, the receiving module is further configured to: before the discarding module 1010 discards the established compression context, receive third indication information configured on the network side, the third indication information including a header integrity identifier for identifying that the data packet includes a complete header in the header of the data packet that does not perform header compression corresponding to a preset compression context identifier; in response to the compression context identifier of the received data packet being the same as the preset compression context identifier, determine that the received data packet is a data packet that does not perform header compression.

[0157] In the compression processing device 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, thereby avoiding the inability to obtain the compression status of the current data packet, resulting in inconsistent understanding of the data packet header compression status with the compression end, and further causing the data packet header decompression failure.

[0158] The embodiment of the present application provides another compression processing device, which is applied to a decompression end. The compression processing device is configured as follows:

[0159] Obtain second indication information, the second indication information including: information for indicating re-establishing a decompression end; information for indicating configuring a header compression function for the decompression end; information for not indicating that the header compression function is used continuously; and information for indicating that a packet header that has not undergone header compression includes a header integrity identifier for identifying that the packet includes a complete header.

[0160] The embodiment of the present application provides another compression processing device, which is applied to a decompression end. The compression processing device is configured as follows:

[0161] Obtain second indication information, the second indication information including: information for indicating re-establishment of a decompression end; information for indicating configuration of a header compression function for the decompression end; information for not indicating that the header compression function is used continuously; and information for indicating that a packet header that has not undergone header compression includes a header integrity identifier for identifying that the packet includes a complete header; based on the second indication information, discard the established compression context.

[0162] The embodiment of the present application provides another compression processing device, which is applied to a decompression end. The compression processing device is configured as follows:

[0163] Obtain second indication information, the second indication information including: information for indicating re-establishment of a decompression end; information for indicating configuration of a header compression function for the decompression end; information for not indicating that the header compression function is used continuously; and information for indicating that a packet header that has not undergone header compression includes a header integrity identifier for identifying that the packet includes a complete header; the compression processing device also includes a receiving module, which is configured to: receive a packet header that has not undergone header compression.

[0164] As a feasible implementation manner, the data packet that is not subjected to header compression includes a compression context identifier, and the compression context identifier is a context identifier CID of the compressed data packet. The above-mentioned receiving module may also be configured as follows:

[0165] A data packet including a compression context identifier and not subjected to header compression is received, wherein the compression context identifier of the received data packet is the same as a preset compression context identifier.

[0166] As another feasible implementation, the above receiving module may also be configured as follows:

[0167] After discarding the established compression context, a compressed data packet with header compression is received, wherein, before receiving the compressed data packet with header compression, a data packet without header compression having the same compression context identifier as the compressed data packet is not received; and a decompression failure processing operation is performed.

[0168] Optionally, the above-mentioned decompression failure processing operation includes at least one of the following operations:

[0169] discarding the compressed data packet; and sending decompression failure information, wherein the decompression failure information includes a failure type indication.

[0170] Optionally, the decompression failure information further includes at least one of the following:

[0171] A compression context identifier of a compressed data packet; a data flow identifier of a compressed data packet; and a bearer identifier of a compressed data packet.

[0172] It should be noted here that the packet header compression in the embodiment of the present application may specifically include but is not limited to Ethernet Header Compression (EHC), etc. The decompression end in the embodiment of the present application may be a Packet Data Convergence Protocol PDCP entity, a network entity, a terminal, a network device, a base station, a router, a gateway, etc.

[0173] According to an embodiment of the present application, the present application also provides a compression end, including the compression processing device 900 provided in the embodiment of the present application.

[0174] The compression end of the embodiment of the present application discards the established compression context according to the first indication information before establishing a new compression context, and sends a data packet without header compression instead of sending a compressed data packet with header compression. This can avoid the situation where the decompression end is unable to obtain the compression status of the current data packet when the compression function cannot continue, resulting in inconsistent understanding of the data packet header compression status with the compression end, which in turn causes failure to decompress the data packet header.

[0175] According to an embodiment of the present application, the present application also provides a decompression end, including the compression processing device 1000 provided in the embodiment of the present application.

[0176] The decompression end of the 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, thereby avoiding the inability to obtain the compression status of the current data packet, resulting in inconsistent understanding of the data packet header compression status with the compression end, and further causing the data packet header decompression failure.

[0177] According to an embodiment of the present application, the present application also provides an electronic device and a readable storage medium.

[0178] like Fig.11 , is a block diagram of an electronic device according to an embodiment of the present application. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or required herein.

[0179] like Fig.11As shown, the electronic device includes: one or more processors 1100, a memory 1200, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are interconnected using different buses and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to an interface). In other embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Fig.11 A processor 1100 is taken as an example.

[0180] The memory 1200 is a non-transient computer-readable storage medium provided in the present application. The memory stores instructions executable by at least one processor to enable at least one processor to perform the compression processing method provided in the present application. The non-transient computer-readable storage medium of the present application stores computer instructions, which are used to enable a computer to perform the compression processing method provided in the present application.

[0181] The memory 1200 is a non-transient computer-readable storage medium that can be used to store non-transient software programs, non-transient computer executable programs and modules, such as program instructions / modules corresponding to the compression processing method in the embodiment of the present application (for example, the attached Fig. 9 The processor 1100 executes various functional applications and data processing of the server by running the non-transient software programs, instructions and modules stored in the memory 1200, that is, the compression processing method in the above method embodiment is implemented.

[0182] The memory 1200 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required by at least one function; the data storage area may store data created according to the use of the positioning electronic device, etc. In addition, the memory 1200 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. Optionally, the memory 1200 may optionally include a memory remotely arranged relative to the processor 1100, and these remote memories may be connected to the positioning electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0183] 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 via a bus or other means. Fig.11 The example of connecting through bus is taken in the following.

[0184] The input device 1300 can receive input digital or character information, and generate key signal input related to user settings and function control of the positioning electronic device, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator rod, one or more mouse buttons, a trackball, a joystick, and other input devices. The output device 1400 may include a display device, an auxiliary lighting device (e.g., an LED), and a tactile feedback device (e.g., a vibration motor). 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 embodiments, the display device may be a touch screen.

[0185] Various implementations of the systems and techniques described herein can be realized in digital electronic circuit systems, integrated circuit systems, dedicated ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can 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.

[0186] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for programmable processors and can 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, device, and / or means (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing 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 for providing machine instructions and / or data to a programmable processor.

[0187] To provide interaction with a user, the systems and techniques described herein 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 the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types 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 (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0188] The systems and techniques described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), and the Internet.

[0189] A computer system may 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 is generated by computer programs running on respective computers and having a client-server relationship to each other.

[0190] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this application can be executed in parallel, sequentially or in different orders, as long as the expected results of the technical solution disclosed in this application can be achieved, and this document is not limited here.

Claims

1. A compression processing method, characterized in that: Applied to the compression end, the method includes: Obtaining first indication information, where the first indication information includes: Information for indicating re-establishment of the compression end; Information used to indicate configuration of a packet header compression function for the compression end; Information for not indicating that the packet header compression function is continuously used; and The packet header for indicating that the packet header compression is not performed includes a packet header integrity identifier for identifying that the packet includes a complete packet header.

2. The method according to claim 1, characterized in that The packet header compression is Ethernet header compression.

3. The method according to claim 1, characterized in that The method further comprises: According to the first indication information, the established compression context is discarded.

4. The method according to claim 1, characterized in that: The method further comprises: The data packet without header compression is sent.

5. The method according to claim 1, characterized in that: The data packet that has not been subjected to header compression includes a compression context identifier, where the compression context identifier is a context identifier CID of the compressed data packet, and the method further includes: A data packet including the compression context identifier and not subjected to header compression is sent, wherein the compression context identifier corresponding to the current compression is the same as the compression context identifier corresponding to the previous compression.

6. The method according to any one of claims 1 to 5, characterized in that: The compression end includes any one of the following: a Packet Data Convergence Protocol PDCP entity, a network entity, a terminal, a network device, a base station, a router, and a gateway.

7. The method according to claim 1, characterized in that Before sending the data packet without header compression, the method further includes: Decompression failure information is received, wherein the decompression failure information includes a failure type indication and a compression context identifier of a compressed data packet that has undergone header compression and has failed to be decompressed.

8. A compression processing method, characterized in that: Applied to the decompression end, the method includes: Obtaining second indication information, where the second indication information includes: Information for instructing to re-establish the decompression end; Information used to indicate configuration of a packet header compression function for the decompression end; Information for not indicating that the packet header compression function is continuously used; and The packet header for indicating that the packet header compression is not performed includes a packet header integrity identifier for identifying that the packet includes a complete packet header.

9. The method according to claim 8, characterized in that The packet header compression is Ethernet header compression.

10. The method according to claim 8, characterized in that The method further comprises: According to the second indication information, the established compression context is discarded.

11. The method according to claim 8, characterized in that The method further comprises: The data packet without header compression is received.

12. The method according to claim 8, characterized in that The data packet that has not been subjected to header compression includes a compression context identifier, where the compression context identifier is a context identifier CID of the compressed data packet, and the method further includes: A data packet including the compression context identifier and not subjected to header compression is received, wherein the compression context identifier of the received data packet is the same as a preset compression context identifier.

13. The method according to any one of claims 8 to 12, characterized in that: The decompression end includes any one of the following: a Packet Data Convergence Protocol PDCP entity, a network entity, a terminal, a network device, a base station, a router, and a gateway.

14. The method according to claim 10, characterized in that After discarding the established compression context, the method further comprises: Receiving a compressed data packet that has been subjected to header compression, wherein, before receiving the compressed data packet that has been subjected to header compression, no data packet that has been subjected to header compression and has the same compression context identifier as the compressed data packet has been received; Perform decompression failure processing operations.

15. The method according to claim 14, characterized in that The decompression failure processing operation includes at least one of the following: discarding the compressed data packet; and Send decompression failure information, wherein the decompression failure information includes a failure type indication.

16. The method according to claim 15, characterized in that The decompression failure information also includes at least one of the following: A compression context identifier of the compressed data packet; A data stream identifier of the compressed data packet; and The bearer identifier of the compressed data packet.

17. A compression processing device, characterized in that: Applied to the compression end, the device is used to: Obtaining first indication information, where the first indication information includes: Information for indicating re-establishment of the compression end; Information used to indicate configuration of a packet header compression function for the compression end; Information for not indicating that the packet header compression function is continuously used; and The packet header for indicating that the packet header compression is not performed includes a packet header integrity identifier for identifying that the packet includes a complete packet header.

18. The device according to claim 17, characterized in that The packet header compression is Ethernet header compression.

19. The device according to claim 17, characterized in that The device comprises: The sending module is configured as follows: According to the first indication information, the established compression context is discarded.

20. The device according to claim 17, characterized in that The device comprises: The sending module is configured as follows: The data packet without header compression is sent.

21. The device according to claim 17, characterized in that The data packet that has not been subjected to header compression includes a compression context identifier, where the compression context identifier is a context identifier CID of the compressed data packet, and the sending module is further configured to: A data packet including the compression context identifier and not subjected to header compression is sent, wherein the compression context identifier corresponding to the current compression is the same as the compression context identifier corresponding to the previous compression.

22. The device according to any one of claims 17 to 21, characterized in that The compression end includes any one of the following: a Packet Data Convergence Protocol PDCP entity, a network entity, a terminal, a network device, a base station, a router, and a gateway.

23. The device according to claim 17, characterized in that The sending module is further configured as: Before sending the data packet without header compression, receiving decompression failure information, wherein the decompression failure information includes a failure type indication and a compression context identifier of the compressed data packet with header compression that failed to be decompressed.

24. A compression processing device, characterized in that: Applied to the decompression end, the device is used to: Obtaining second indication information, where the second indication information includes: Information for instructing to re-establish the decompression end; Information used to indicate configuration of a packet header compression function for the decompression end; Information for not indicating that the packet header compression function is continuously used; and The packet header for indicating that the packet header compression is not performed includes a packet header integrity identifier for identifying that the packet includes a complete packet header.

25. The device according to claim 24, characterized in that The packet header compression is Ethernet header compression.

26. The device according to claim 24, characterized in that The device is also used for: According to the second indication information, the established compression context is discarded.

27. The device according to claim 24, characterized in that The device comprises: The receiving module is configured as follows: The data packet without header compression is received.

28. The device according to claim 24, characterized in that The data packet that has not been subjected to header compression includes a compression context identifier, and the compression context identifier is a context identifier CID of the compressed data packet. The device includes: The receiving module is configured as follows: A data packet including the compression context identifier and not subjected to header compression is received, wherein the compression context identifier of the received data packet is the same as a preset compression context identifier.

29. The device according to any one of claims 24 to 28, characterized in that The decompression end includes any one of the following: a Packet Data Convergence Protocol PDCP entity, a network entity, a terminal, a network device, a base station, a router, and a gateway.

30. The device according to claim 26, characterized in that Also includes: A receiving module is configured to receive a compressed data packet that has undergone header compression after discarding the established compression context, wherein, before receiving the compressed data packet that has undergone header compression, no data packet that has undergone header compression and has the same compression context identifier as the compressed data packet has been received; and perform a decompression failure processing operation.

31. The device according to claim 30, characterized in that The receiving module is specifically configured to perform at least one of the following: discarding the compressed data packet; and Send decompression failure information, wherein the decompression failure information includes a failure type indication.

32. A compression end, characterized in that: include: A compression processing device as described in any one of claims 17 to 23.

33. A decompression end, characterized in that: include: A compression processing device as described in any one of claims 24-31.

34. A terminal, characterized in that: include: A compression processing device as described in any one of claims 17-23, or a compression processing device as described in any one of claims 24-31.

35. A network device, characterized in that: include: A compression processing device as described in any one of claims 17-23, or a compression processing device as described in any one of claims 24-31.

36. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively connected 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 perform the compression processing method described in any one of claims 1-7, or the compression processing method described in any one of claims 8-16.

37. A computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to enable the computer to execute the compression processing method according to any one of claims 1 to 7, or the compression processing method according to any one of claims 8 to 16.

Images