A compression processing method and apparatus

Abstract

The application provides a compression processing method and device, and relates to the technical field of mobile communication. The method comprises the following steps: according to first indication information, a data packet is transmitted without performing packet header compression. In the application, the compression end transmits the data packet without performing packet header compression according to the first indication information, so that the compression end and the decompression end are consistent in understanding the packet header compression state of the data packet, and the packet header decompression failure of the data packet is avoided.

Description

[0001] This application is a divisional application of application No. 202180000140.7, titled "Compression processing method and device", filed on January 13, 2021. TECHNICAL FIELD

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

[0003] In the related art, when the network side configures a compression function for a compression end of a user terminal, such as a protocol entity, and instructs the user terminal to reestablish the entity, in the case where the compression function cannot continue, the compression end and the decompression end are prone to inconsistent understanding of the header compression state of a data packet, thereby causing the header decompression of the data packet to fail. SUMMARY

[0004] The compression processing method and device provided in the present application solve the problem of inconsistent understanding of the header compression state of a data packet by the compression end and the decompression end in the related art, thereby causing the header decompression of the data packet to fail.

[0005] The first aspect embodiment of the present application provides a compression processing method applied to a compression end, which comprises: obtaining first indication information, wherein the first indication information comprises: information for indicating reestablishment of the compression end; information for indicating configuration of a header compression function for the compression end; information for indicating that the header compression function is not continuously used; and a header integrity identifier for identifying that a data packet that has not been subjected to header compression comprises a complete header.

[0006] The second aspect embodiment of the present application provides another compression processing method applied to a decompression end, which comprises: obtaining second indication information, wherein the second indication information comprises: information for indicating reestablishment of the decompression end; information for indicating configuration of a header compression function for the decompression end; information for indicating that the header compression function is not continuously used; and a header integrity identifier for identifying that a data packet that has not been subjected to header compression comprises a complete header.

[0007] The third aspect embodiment of the present application provides a compression processing device applied to a compression end, which is configured to: obtain first indication information, wherein the first indication information comprises: information for indicating reestablishment of the compression end; information for indicating configuration of a header compression function for the compression end; information for indicating that the header compression function is not continuously used; and a header integrity identifier for identifying that a data packet that has not been subjected to header compression comprises a complete header.

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

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

[0010] The sixth aspect embodiment of the present application provides a decompression end, which includes 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, which includes 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, which includes 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, which includes: at least one processor; and a memory connected with the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the compression processing method 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 the computer executable instructions are executed by a processor to implement 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. BRIEF DESCRIPTION OF DRAWINGS

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

[0016] Figure 1 A flowchart of a compression processing method provided by the embodiments of the present application is shown;

[0017] Figure 2A structure diagram of a data packet not compressed by EHC;

[0018] Figure 3 A flowchart of another compression processing method provided by the embodiment of the application;

[0019] Figure 4 A flowchart of another compression processing method provided by the embodiment of the application;

[0020] Figure 5 A structure diagram of an EHC compressed data packet;

[0021] Figure 6 A structure diagram of an EHC feedback data packet;

[0022] Figure 7 A flowchart of another compression processing method provided by the embodiment of the application;

[0023] Figure 8 A flowchart of another compression processing method provided by the embodiment of the application;

[0024] Figure 9 A structure diagram of a compression processing device provided by the embodiment of the application;

[0025] Figure 10 A structure diagram of another compression processing device provided by the embodiment of the application;

[0026] Figure 11 A structure diagram of an electronic device provided by the embodiment of the application. DETAILED DESCRIPTION

[0027] Embodiments of the present application are described in detail below with reference to the accompanying drawings. Examples of the embodiments are shown in the drawings, in which the same or similar components are denoted by the same or similar reference numerals throughout. The embodiments described below by reference to the drawings are exemplary and are intended to explain the present application, and should not be understood as limiting the present application.

[0028] The terms used in the embodiments of the present disclosure are merely used to describe particular embodiments, and are not intended to limit the embodiments of the present disclosure. The singular forms "a," "an," and "the" used in the embodiments of the present disclosure and the appended claims are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be understood by those skilled in the art that the term "and / or" as 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. can be employed in describing various information in the embodiments of the present disclosure, the information should not be limited to these terms. These terms are only used to differentiate one piece of information from another piece of information of the same type. For example, without departing from the scope of the embodiments of the present disclosure, the first information can also be referred to as the second information, and similarly, the second information can also be referred to as the first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "upon" or "in response to determining".

[0030] The base station and the user terminal involved in the embodiments of the present application are described as follows: The base station is deployed in a wireless access network and provides wireless access function for the user terminal. The base station can perform wireless communication with the user terminal via one or more antennas. The base station can provide communication coverage for a geographic area where it is located. The base station can include different types such as macro base station, micro base station, relay station, access point, etc. In some embodiments, the base station can be referred to as base transceiver station, wireless base station, access point, wireless transceiver, basic service set (BSS), extended service set (ESS), node B (NodeB), evolved node B (eNB or eNodeB), or some other appropriate term by those skilled in the art. Exemplarily, in a 5G system, the base station is referred to as gNB. For the convenience of description, the above-mentioned device providing wireless communication function for the user terminal is collectively referred to as base station in the embodiments of the present application.

[0031] The user terminal can be scattered in the whole mobile communication system, and each user terminal can be stationary or mobile. The user terminal can also be referred to as mobile station, user station, mobile unit, user unit, wireless unit, remote unit, mobile device, terminal device, wireless device, wireless communication device, remote device, mobile user station, access user equipment, mobile user equipment, wireless user equipment, remote user equipment, handheld device, user agent, mobile client, client, or some other appropriate term by those skilled in the art. The user terminal can be a cellular phone, a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a tablet computer, a laptop computer, a cordless phone, a wireless local loop (WLL) station, etc., which can communicate with the base station in the mobile communication system.

[0032] Figure 1 A flowchart of a compression processing method provided in the embodiments of the present application is executed by a compression end, as shown in Figure 1 The compression processing method includes the following steps:

[0033] S101, according to the first indication information, sending a data packet without header compression.

[0034] Specifically, the compression end and the decompression end can be a function module in a network entity, such as a packet data convergence protocol (PDCP) entity, or an independent network entity. In addition to existing in base stations and terminal devices, the compression end and the decompression end can also exist between network devices, such as between routers, between gateways and base stations, and between gateways.

[0035] As a feasible implementation, the compression end can send a data packet without header compression before establishing a new compression context according to the agreement of the communication protocol, instead of sending a compressed data packet with header compression, to avoid the decompression end from failing to obtain the compression state of the current data packet in the case that the compression function cannot continue, thereby leading to inconsistent understanding of the compression state of the data packet header between the compression end and the decompression end, and further leading to failure of decompression of the data packet header.

[0036] As another feasible implementation, the compression end can send a data packet without header compression before establishing a new compression context according to the first indication information configured by the network side, such as a base station, instead of sending a compressed data packet with header compression, to avoid the decompression end from failing to obtain the compression state of the current data packet in the case that the compression function cannot continue, thereby leading to inconsistent understanding of the compression state of the data packet header between the compression end and the decompression end, and further leading to failure of decompression of the data packet header.

[0037] For example, a user terminal is switched from a base station gNB-1 to a base station gNB-2, and the network side entity corresponding to the user terminal is changed from gNB-1 to gNB-2. Both gNB-1 and gNB-2 are configured with compression functions, but gNB-2 cannot obtain the compression state of the header compression of the entity of gNB-1 (including compression context information), so gNB-2 cannot continue to use the compression context of the header compression of gNB-1 for decompression.

[0038] It should be noted that the header compression in the embodiments of the present application can include, but is not limited to, Ethernet header compression (EHC) and the like.

[0039] Optionally, the first indication information can include, but is not limited to, at least one of the following: information indicating that the network side configures the compression end with a header compression function; information indicating that the terminal device re-establishes the compression end; and information indicating that the network side does not indicate continuous use of the header compression function.

[0040] For example, the network side can indicate to the compression end that the Ethernet header of the uplink data is compressed by ehc-Uplink. The terminal device can be instructed to reestablish the PDCP compression end by reestablish PDCP.

[0041] The header of the data packet that is not compressed can include, but is not limited to, a header integrity identifier for identifying that the data packet includes a complete header. Figure 2 The structure of the data packet that is not compressed by EHC is shown in FIG. 2. Figure 2 As shown in FIG. 2, the header integrity identifier "F / C" field value of the data packet that is not compressed by EHC (EHC Compressed Header, EHC CH for short) is set to "0", which is used to identify that the data packet includes a complete header, i.e., is not compressed. The CID (Context Identity) is an identifier for marking a compression context, i.e., a compression context identifier. The Ethernet header is an Ethernet header, and the PAYLOAD (+PAD) is a payload.

[0042] In the embodiment of the present application, the compression end sends the data packet that is not compressed according to the first indication information before establishing a new compression context, instead of sending the compressed data packet that is compressed, which can avoid the situation that the decompression end cannot obtain the compression state of the current data packet in the case that the compression function cannot continue, thereby leading to the inconsistency between the compression end and the decompression end in understanding the header compression state of the data packet, and further leading to the failure of the header decompression of the data packet.

[0043] Figure 3 The flowchart of another compression processing method provided by the embodiment of the present application is executed by the compression end. As shown in FIG. 3, the compression processing method includes the following steps. Figure 3

[0044] S301, discarding the established compression context according to the first indication information.

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

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

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

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

[0049] Specifically, after discarding the previously established compression context, 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 from failing to obtain the compression state of the current data packet in the case where the compression function cannot continue, thereby leading to inconsistency in understanding the header compression state of the data packet with the compression end, and further leading to failure in decompressing the header of the data packet.

[0050] For example, the user terminal is switched from the base station gNB-1 to the base station gNB-2, and the network side entity corresponding to the user terminal is changed from gNB-1 to gNB-2, then both gNB-1 and gNB-2 are configured with the compression function, but gNB-2 cannot obtain the compression state (including compression context information) of the header compression of the entity of gNB-1, so gNB-2 cannot continue to use the compression context of the header compression of gNB-1 for decompression.

[0051] It should be noted that the header compression in the embodiments of the present application can include, but is not limited to, Ethernet header compression (EHC) and the like.

[0052] Optionally, the first indication information can include, but is not limited to, at least one of the following: information indicating that the network side configures the compression end with the header compression function; information indicating that the terminal device reestablishes the compression end; and information indicating that the network side does not indicate continuous use of the header compression function.

[0053] For example, ehc-Uplink can be used to indicate that the network side configures the compression end to compress the Ethernet header of the uplink data. reestablish PDCP can be used to indicate that the terminal device reestablishes the PDCP compression end.

[0054] The header of the data packet without header compression can include, but is not limited to, a header integrity identifier for identifying that the data packet includes a complete header. Figure 2 The structure of the data packet without header compression for EHC is shown in the following figure: Figure 2As shown, the EHC header integrity identifier "F / C" field value in the data packet not compressed by the EHC (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, i.e. not compressed. The CID is an identifier used to mark the compression context, i.e. the compression context identifier. The Ethernet header is an Ethernet header, and the PAYLOAD (+ PAD) is a payload.

[0055] Optionally, the first indication information can further include a first length of the compression context identifier or the data stream identifier corresponding to the current compression, and a second length of the compression context identifier or the data stream identifier corresponding to the last compression. For example, the ehc-CID-Length can be used to indicate the length of the compression context identifier corresponding to the current compression and the last compression, for example, 7 bits or 15 bits.

[0056] As shown in the above step S302, the data packet not compressed by the EHC header can include the following steps S401 or S402 or S403. Figure 4

[0057] S401, in response to the first length being different from the second length, the compression context identifier or the data stream identifier with the first length is used to send the data packet not compressed by the EHC header.

[0058] Specifically, if the first length of the compression context identifier or the data stream identifier corresponding to the current compression is different from the second length of the compression context identifier or the data stream identifier corresponding to the last compression, i.e. the length of the compression context identifier or the data stream identifier is changed, the compression context identifier or the data stream identifier with the first length is used to send the data packet not compressed by the EHC header, i.e. the length of the identifier used to identify the compression context in the header of the data packet not compressed by the EHC header is the first length, and the header includes the 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 last compression is 7 bits, and the data packet not compressed by the EHC header is sent as shown in the following table. Figure 2 As shown in the data packet not compressed by the EHC header, the length of the compression context identifier CID 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, the compression context identifier or the data stream identifier with the first length and the same as the compression context identifier or the data stream identifier corresponding to the last compression is used to send the data packet not compressed by the EHC header.

[0060] ​Specifically, if the first length of the compression context identifier or the data stream identifier corresponding to the current compression in the first indication information is the same as the second length of the compression context identifier or the data stream identifier corresponding to the last compression, that is, the length of the compression context identifier or the data stream identifier does not change, the compression context identifier or the data stream identifier with the first length and different from the compression context identifier or the data stream identifier corresponding to the last compression is used to send the data packet without header compression, that is, the length of the identifier used to identify the compression context or the data stream in the header of the sent data packet without header compression is the first length, and the identifier used to identify the compression context or the data stream is different from the compression context identifier corresponding to the last compression, and the header includes the 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 last compression is 7 bits. The length of the compression context identifier CID-1 in the data packet without header compression shown in FIG. 6 is 7 bits, and the value of the "F / C" field is set to "0". Figure 2 The length of the compression context identifier CID-2 in the data packet without header compression shown in FIG. 7 is 7 bits, and the value of the "F / C" field is set to "1".

[0061] For the case that the decompression end does not discard the compression context, the compression end sends the data packet without header compression by using the compression context identifier or the data stream identifier corresponding to the last compression, so that the decompression end can re-establish the compression context.

[0062] S403, in response to the first length being the same as the second length, the compression context identifier or the data stream identifier with the first length and different from the compression context identifier or the data stream identifier corresponding to the last compression is used to send the data packet without header compression.

[0063] Specifically, if the first length of the compression context identifier or the data stream identifier corresponding to the current compression in the first indication information is the same as the second length of the compression context identifier or the data stream identifier corresponding to the last compression, that is, the length of the compression context identifier or the data stream identifier does not change, the compression context identifier or the data stream identifier with the first length and different from the compression context identifier or the data stream identifier corresponding to the last compression is used to send the data packet without header compression, that is, the length of the identifier used to identify the compression context or the data stream in the header of the sent data packet without header compression is the first length, and the identifier used to identify the compression context or the data stream is different from the compression context identifier corresponding to the last compression, and the header includes the 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 last compression is 7 bits. The length of the compression context identifier CID-2 in the data packet without header compression shown in FIG. 7 is 7 bits, and the value of the "F / C" field is set to "1". Figure 2The compression context identifier CID-2 in the data packet without header compression is 7 bits long, 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 sending the data packet without header compression in step S302, the compression processing method of this embodiment may further include the following step: receiving decompression failure information, wherein the decompression failure information includes a failure type indication, such as decompression failure, and a compression context identifier, such as CID-1, of the header-compressed compressed data packet that failed to decompress. The decompression failure information is used to instruct the compression end not to send the compressed data packet corresponding to the compression context identifier that failed to decompress.

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

[0066] Those skilled in the art will understand that the EHC compression context establishment process is as follows: The compression end sends an uncompressed Ethernet data packet (i.e., an EHC FH packet) without Ethernet header compression to the decompression end. Upon receiving the "EHC FH packet," the decompression end sends back a reception confirmation message (e.g., ...). Figure 6 The diagram illustrates the structure of the EHC feedback data packet, where R is the feedback identifier. The compression end sends compressed Ethernet packets (i.e., EHCCH packets) with compressed Ethernet headers to the decompression end. This establishes a compression context between the compression and decompression ends, identified by a CID. This compression context stores the Ethernet header information before and after compression. The compression end then sends compressed Ethernet packets based on this compression context, and the decompression end uses the same context to reconstruct the uncompressed Ethernet packets from the compressed packets.

[0067] In this embodiment of the application, the compression end discards the established compression context before establishing a new compression context according to the first instruction information, and sends a data packet without header compression instead of a compressed data packet with header compression. This can avoid the decompression end failing to decompress the data packet header because it cannot obtain the current data packet compression status when the compression function cannot continue, which would lead to a misunderstanding of the data packet header compression status between the compression end and the decompression end.

[0068] The embodiment of the present application provides another compression processing method, which is executed by a compression end, and the compression processing method comprises the following steps:

[0069] The first indication information comprises the following information: information for indicating that the compression end is re-established; information for indicating that the compression end is configured with a header compression function; information for indicating that the header compression function is not continuously used; and information for indicating that the header of a data packet which is not compressed by the header compression function comprises a header integrity identifier for identifying that the data packet comprises a complete header.

[0070] The embodiment of the present application provides another compression processing method, which is executed by a compression end, and the compression processing method comprises the following steps:

[0071] The first indication information comprises the following information: information for indicating that the compression end is re-established; information for indicating that the compression end is configured with a header compression function; information for indicating that the header compression function is not continuously used; and information for indicating that the header of a data packet which is not compressed by the header compression function comprises a header integrity identifier for identifying that the data packet comprises a complete header; and discarding the established compression context according to the first indication information.

[0072] The embodiment of the present application provides another compression processing method, which is executed by a compression end, and the compression processing method comprises the following steps:

[0073] The first indication information comprises the following information: information for indicating that the compression end is re-established; information for indicating that the compression end is configured with a header compression function; information for indicating that the header compression function is not continuously used; and information for indicating that the header of a data packet which is not compressed by the header compression function comprises a header integrity identifier for identifying that the data packet comprises a complete header; and sending the data packet which is not compressed by the header compression function.

[0074] As a feasible implementation, the data packet which is not compressed by the header compression function comprises a compression context identifier, which is a context identifier CID of the compressed data packet, and the compression processing method of the embodiment of the present application can further comprise the following steps:

[0075] The data packet which is not compressed by the header compression function and comprises the compression context identifier is sent, wherein the compression context identifier corresponding to the compression this time is the same as the compression context identifier corresponding to the compression last time.

[0076] As another feasible implementation, before the data packet which is not compressed by the header compression function is sent, the compression processing method of the embodiment of the present application can further comprise the following steps:

[0077] The decompression failure information is received, wherein the decompression failure information comprises a failure type indication and a compression context identifier of the compressed data packet which is compressed by the header compression function and fails in decompression.

[0078] It should be noted that the packet header compression in the embodiments of the present application can include, but is not limited to, Ethernet header compression (EHC) and the like. The compression end in the embodiments of the present application can be a packet data convergence protocol (PDCP) entity, a network entity, a terminal, a network device, a base station, a router, a gateway, and the like.

[0079] Figure 7 Another flowchart of a compression processing method provided by the embodiments of the present application is executed by a decompression end. As shown in the flowchart, the compression processing method includes the following steps: Figure 7

[0080] S701, discarding 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, for example, a packet data convergence protocol (PDCP) entity, or an independent network entity. In addition to being present in a base station and a terminal device, the compression end and the decompression end can also be present in a network device, such as between routers, between a gateway and a base station, and between gateways.

[0082] As a feasible implementation, the decompression end can discard the previously established compression context before establishing a new compression context according to the agreement of a communication protocol, so as to successfully receive the data packet without packet header compression sent by the compression end in the case that the compression function cannot continue, and avoid the inconsistency in understanding the packet header compression state of the data packet with the compression end due to the inability to obtain the compression state of the current data packet, thereby causing the packet header decompression failure.

[0083] As another feasible implementation, the decompression end can discard the previously established compression context before establishing a new compression context according to the second indication information configured by the network side, such as a base station, so as to successfully receive the data packet without packet header compression sent by the compression end in the case that the compression function cannot continue, and avoid the inconsistency in understanding the packet header compression state of the data packet with the compression end due to the inability to obtain the compression state of the current data packet, thereby causing the packet header decompression failure.

[0084] ​The compression function cannot continue, for example, the user terminal is switched from the base station gNB-1 to the base station gNB-2, the network side entity corresponding to the user terminal is changed from gNB-1 to gNB-2, gNB-1 and gNB-2 are configured with the compression function, but gNB-2 cannot obtain the compression state (including compression context information) of the packet header compression of gNB-1 entity, so gNB-2 cannot continue to use the compression context of the packet header compression of gNB-1 for decompression.

[0085] It should be noted that the packet header compression in the embodiments of the present application can include but is not limited to Ethernet header compression (EHC) and the like.

[0086] Optionally, the second indication information can include but is not limited to at least one of the following: information for indicating that the network side configures the packet header compression function for the decompression end; information for indicating that the terminal device reestablishes the decompression end; and information for indicating that the network side does not indicate the continuous use of the packet header compression function.

[0087] For example, ehc-Downlink can be used to indicate that the network side configures the Ethernet packet header compression for the downlink data of the decompression end. reestablish PDCP can be used to indicate that the terminal device reestablishes the PDCP decompression end.

[0088] The compression processing method provided in the embodiments of the present application discards the established compression context according to the second indication information, so as to successfully receive the data packet without packet header compression sent by the compression end in the case that the compression function cannot continue, and avoids the inconsistency in understanding the packet header compression state of the data packet with the compression end due to the failure to obtain the compression state of the current data packet, thereby avoiding the failure of packet header decompression of the data packet.

[0089] Figure 8 Another flowchart of the compression processing method provided in the embodiments of the present application is executed by the decompression end. As shown in the figure, the compression processing method includes the following steps: Figure 8

[0090] S801, according to the second indication information, discarding the established compression context.

[0091] Specifically, the compression end and the decompression end can be functional modules in network entities, such as packet data convergence protocol (PDCP) entities, or independent network entities. In addition to existing in base stations and terminal devices, the compression end and the decompression end can also exist in network devices, such as between routers, between gateways and base stations, and between gateways. ​

[0092] As a feasible implementation, 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 in the case that the compression function cannot continue, and avoid the inconsistency of the understanding of the header compression state of the data packet between the compression end and the decompression end due to the failure to obtain the compression state of the current data packet, thereby causing the failure of the header decompression of the data packet.

[0093] As another feasible implementation, the decompression end can discard the previously established compression context before establishing a new compression context according to the second indication information configured by the network side such as a base station, so as to successfully receive the data packet without header compression sent by the compression end in the case that the compression function cannot continue, and avoid the inconsistency of the understanding of the header compression state of the data packet between the compression end and the decompression end due to the failure to obtain the compression state of the current data packet, thereby causing the failure of the header decompression of the data packet.

[0094] For example, the user terminal is switched from the base station gNB-1 to the base station gNB-2, and the network side entity corresponding to the user terminal is changed from gNB-1 to gNB-2, then the gNB-1 and the gNB-2 are both configured with the compression function, but the gNB-2 cannot obtain the compression state (including the compression context information) of the header compression of the entity of the gNB-1, so the gNB-2 cannot continue to use the compression context of the header compression of the gNB-1 for decompression.

[0095] It should be noted that the header compression in the embodiments of the present application can include but is not limited to Ethernet header compression (EHC) and the like.

[0096] Optionally, the second indication information can include but is not limited to at least one of the following: information for indicating that the network side configures the decompression end with the header compression function; information for indicating that the terminal device reestablishes the decompression end; and information for indicating that the network side does not indicate the continuous use of the header compression function.

[0097] For example, the ehc-Downlink can be used to indicate that the network side configures the decompression end with the Ethernet header compression for the downlink data. The reestablish PDCP can be used to indicate that the terminal device reestablishes the PDCP decompression end.

[0098] S802, receiving a compressed data packet subjected to header compression, wherein before receiving the compressed data packet subjected to header compression, no data packet without header compression with the same compression context identifier as the compressed data packet is received.

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

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

[0101] For example, the decompression end receives a compressed data packet with a compression context identifier of CID-1 sent by the entity, and before receiving the compressed data packet with the compression context identifier of CID-1, no data packet without header compression with the compression context identifier of CID-1 is received, the decompression failure processing operation is performed.

[0102] The header of the data packet without header compression can specifically include but is not limited to a header integrity identifier for identifying that the data packet includes a complete header, etc. Figure 2 The structure diagram of the EHC data packet without header compression is as shown in Figure 2 As shown in the figure, the header integrity identifier "F / C" field value of the EHC data packet without header compression (EHC Compressed Header, EHC CH for short) is set to "0", which is used to identify that the data packet includes a complete header, i.e. not compressed. CID is an identifier for marking a compression context, i.e. a compression context identifier. Ethernet header is an Ethernet header, and PAYLOAD(+PAD) is a payload.

[0103] The header of the data packet without header compression can specifically include but is not limited to a header integrity identifier for identifying that the data packet includes a complete header, etc. Figure 5 The structure diagram of the EHC data packet without header compression is as shown in Figure 5 As shown in the figure, the header integrity identifier "F / C" field value of the EHC data packet without header compression (EHC Compressed Header, EHC CH for short) is set to "0", which is used to identify that the data packet includes a complete header, i.e. not compressed. CID is an identifier for marking a compression context, i.e. a compression context identifier. Ethernet header is an Ethernet header, and PAYLOAD(+PAD) is a payload.

[0104] Those skilled in the art can understand that the establishment process of the EHC compression context is as follows: the compression end sends a non-compressed Ethernet data packet without Ethernet header compression (i.e. EHC FH packet) to the decompression end. After the decompression end receives the "EHC FH packet", a reception confirmation message (such as Figure 6As shown, R is a feedback identifier) to the compression end. The compression end sends the decompression end a compressed Ethernet data packet (i.e., an EHC CH packet) that has been compressed with an Ethernet header. Further, a compression context is established between the compression end and the decompression end, and the compression context is marked by a CID. The compression context stores the pre-compression and post-compression Ethernet header information. Then, the compression end sends the compressed Ethernet data packet according to the compression context, and the decompression end recovers the compressed Ethernet data packet into a non-compressed Ethernet data packet according to the compression context.

[0105] The step S803 of performing the decompression failure processing operation specifically can 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, for example, decompression failure.

[0106] Optionally, the decompression failure information can further include at least one of the following: a compression context identifier of the compressed data packet, for example, CID-1; a data flow identifier of the compressed data packet, for example, QoS flow-1; and a bearer identifier of the compressed data packet, for example, DRB-1.

[0107] Optionally, before discarding the established compression context in the step S801, the compression processing method of the embodiments of the present application can further include the following steps: receiving third indication information configured by the network side, wherein the third indication information includes a preset compression context identifier corresponding to a packet header integrity identifier in a header of a data packet that has not been compressed, the packet header integrity identifier being used to identify that the data packet includes a complete packet header; and 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 has not been compressed.

[0108] Specifically, the decompression end receives third indication information configured by the network side, wherein the third indication information includes a preset compression context identifier corresponding to a packet header integrity identifier in a header of a data packet that has not been compressed, the packet header integrity identifier being used to identify that the data packet includes a complete packet header, i.e., the third indication information is used to indicate that, for a data packet that has not been compressed and has a preset compression context identifier, the packet header integrity identifier in the header of the data packet indicates that the data packet includes a complete packet header, and 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 has not been compressed.

[0109] The compression processing method of the embodiments of the present application can discard the established compression context according to the second indication information, so as to successfully receive the data packet that has not been compressed and that is sent by the compression end in a case where the compression function cannot continue, thereby avoiding the inconsistency in understanding the packet header compression state of the data packet between the compression end and the decompression end due to the failure to obtain the compression state of the current data packet, and further avoiding the decompression failure of the packet header.

[0110] The compression processing method provided by the embodiment of the present application is executed by the decompression end, and comprises the following steps:

[0111] The second indication information is obtained, and the second indication information comprises: information for indicating that the decompression end is re-established; information for indicating that the header compression function is configured for the decompression end; information for indicating that the header compression function is not continuously used; and information for indicating that the header integrity identifier for identifying that the data packet comprises a complete header is comprised in the header of the data packet which is not compressed.

[0112] The compression processing method provided by the embodiment of the present application is executed by the decompression end, and comprises the following steps:

[0113] The second indication information is obtained, and the second indication information comprises: information for indicating that the decompression end is re-established; information for indicating that the header compression function is configured for the decompression end; information for indicating that the header compression function is not continuously used; and information for indicating that the header integrity identifier for identifying that the data packet comprises a complete header is comprised in the header of the data packet which is not compressed; and the established compression context is discarded according to the second indication information.

[0114] The compression processing method provided by the embodiment of the present application is executed by the decompression end, and comprises the following steps:

[0115] The second indication information is obtained, and the second indication information comprises: information for indicating that the decompression end is re-established; information for indicating that the header compression function is configured for the decompression end; information for indicating that the header compression function is not continuously used; and information for indicating that the header integrity identifier for identifying that the data packet comprises a complete header is comprised in the header of the data packet which is not compressed; and the data packet which is not compressed is received.

[0116] As a feasible implementation, the data packet which is not compressed comprises a compression context identifier, and the compression context identifier is a context identifier CID of the compressed data packet, and the compression processing method provided by the embodiment of the present application can further comprise the following steps:

[0117] The data packet which is not compressed and comprises the compression context identifier 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, after the established compression context is discarded, the compression processing method provided by the embodiment of the present application can further comprise the following steps:

[0119] receive the compressed data packet subjected to the header compression, wherein, before receiving the compressed data packet subjected to the header compression, no data packet subjected to no header compression with the same compression context identifier as that of the compressed data packet is received; and perform a decompression failure processing operation.

[0120] Optionally, the decompression failure processing operation comprises at least one of the following operations:

[0121] discard the compressed data packet; and send decompression failure information, wherein the decompression failure information comprises a failure type indication.

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

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

[0124] It should be noted that the header compression in the embodiments of the present application can include, but is not limited to, Ethernet header compression (EHC) and the like. The decompression end in the embodiments of the present application can be a packet data convergence protocol (PDCP) entity, a network entity, a terminal, a network device, a base station, a router, a gateway, and the like.

[0125] Corresponding to the compression processing method provided in the above several embodiments, the present application further provides a compression processing apparatus applied to a compression end. Since the compression processing apparatus provided in the embodiments of the present application corresponds to the compression processing method provided in the above embodiments, the implementation of the compression processing method is also applicable to the compression processing apparatus provided in the embodiments of the present application, which will not be described in detail in the embodiments. Figures 1-4

[0126] Figure 9 A structural schematic diagram of the compression processing apparatus provided in the embodiments of the present application is shown in FIG. 9.

[0127] As shown in FIG. 9, the compression processing apparatus 900 comprises a sending module 910. Wherein: Figure 9 The sending module 910 is configured to send a data packet subjected to no header compression according to the first indication information.

[0128] Optionally, the header compression is Ethernet header compression.

[0129] Optionally, the first indication information comprises at least one of the following: information used for indicating that the network side configures the compression end with a header compression function; information used for indicating that the terminal device re-establishes the compression end; and information used for indicating that the network side does not indicate continuous use of the header compression function.

[0130] ​​

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

[0132] Optionally, the header of the data packet without header compression comprises a header integrity identifier for identifying that the data packet comprises a complete header.

[0133] Optionally, the first indication information comprises a first length of a compression context identifier or a data stream identifier corresponding to the current compression and a second length of a compression context identifier or a data stream identifier corresponding to the last compression; and the sending module is specifically configured to: in response to the first length being different from the second length, send the data packet without header compression by using the compression context identifier or the data stream identifier of the first length; or, in response to the first length being the same as the second length, send the data packet without header compression by using the compression context identifier or the data stream identifier of the first length and the same as the compression context identifier or the data stream identifier corresponding to the last compression; or, in response to the first length being the same as the second length, send the data packet without header compression by using the compression context identifier or the data stream identifier of the first length and different from the compression context identifier or the data stream identifier corresponding to the last compression.

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

[0135] The compression processing device provided in the embodiments of the present application can avoid the decompression end from failing in decompression of the header of the data packet due to the compression function being unable to continue and the compression end and the decompression end failing to understand the header compression state of the data packet, by discarding the established compression context and sending the data packet without header compression according to the first indication information before establishing a new compression context.

[0136] The embodiments of the present application provide another compression processing device applied to a compression end, which is configured to:

[0137] obtain first indication information, which specifically comprises: information for indicating re-establishment of the compression end; information for indicating that the compression end is configured with a header compression function; information for indicating that the header compression function is not continuously used; and information for indicating that the header of the data packet without header compression comprises a header integrity identifier for identifying that the data packet comprises a complete header.

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

[0139] The first indication information specifically comprises: information used for indicating that the compression end is re-established; information used for indicating that the compression end is configured with a header compression function; information used for indicating that the header compression function is not continuously used; and a header integrity identifier used for identifying that a data packet comprises a complete header in a header of the data packet which is not subjected to header compression; and the compression processing device is further configured to discard an established compression context according to the first indication information.

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

[0141] The first indication information specifically comprises: information used for indicating that the compression end is re-established; information used for indicating that the compression end is configured with a header compression function; information used for indicating that the header compression function is not continuously used; and a header integrity identifier used for identifying that a data packet comprises a complete header in a header of the data packet which is not subjected to header compression; and the compression processing device is further configured to discard an established compression context according to the first indication information.

[0142] As a feasible implementation, the data packet which is not subjected to header compression comprises a compression context identifier, which is a context identifier CID of the compressed data packet, and the sending module can be further configured to:

[0143] The data packet which is not subjected to header compression and comprises the compression context identifier is sent, wherein the compression context identifier corresponding to the current compression is the same as the compression context identifier corresponding to the last compression.

[0144] As another feasible implementation, the sending module can be further configured to:

[0145] Before the data packet which is not subjected to header compression is sent, decompression failure information is received, wherein the decompression failure information comprises a failure type indication and a compression context identifier of the compressed data packet which is subjected to header compression and is subjected to decompression failure.

[0146] It should be noted that the header compression in the embodiment of the present application can specifically include but is not limited to Ethernet header compression (EHC) and the like. The compression end in the embodiment of the present application can be a packet data convergence protocol (PDCP) entity, a network entity, a terminal, a network device, a base station, a router, a gateway and the like.

[0147] Corresponding to the compression methods provided in the above embodiments, this application also provides a compression device. The compression device is applied to a user terminal. Because the compression device provided in this application is different from the methods described above… Figures 7-8 The compression processing method provided in this embodiment corresponds to the compression processing device provided in this embodiment, and will not be described in detail in this embodiment.

[0148] Figure 10 This is a schematic diagram of the compression processing apparatus provided in an embodiment of this application.

[0149] like Figure 10 As shown, the compression processing device 1000 includes: a discard module 1010, wherein:

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

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

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

[0153] Optionally, the compression processing apparatus in this application embodiment may further include: a receiving module, configured to receive a compressed data packet with header compression after the discarding module 1010 discards the established compression context, wherein, before receiving the compressed data packet with header compression, no uncompressed data packet with the same compression context identifier as the compressed data packet is received; and to perform a decompression failure handling operation.

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

[0155] Optionally, the decompression failure information may also include at least one of the following: the compression context identifier of the compressed data packet; the data stream identifier of the compressed data packet; and the 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 by the network side, the third indication information including a preset compression context identifier corresponding to a packet header integrity identifier used for identifying that a data packet includes a complete packet header; and 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 has not been subjected to packet header compression.

[0157] The compression processing apparatus provided in the embodiments of the present application can discard the established compression context according to the second indication information, so that the data packet that has not been subjected to packet header compression and that is sent by the compression end in the case where the compression function cannot continue can be successfully received, and the inconsistency in understanding the packet header compression state of the data packet between the compression end and the decompression end due to the failure to obtain the compression state of the current data packet can be avoided, and thus the failure of packet header decompression of the data packet can be avoided.

[0158] Another compression processing apparatus is provided in the embodiments of the present application, and is applied to a decompression end, and the compression processing apparatus is configured to:

[0159] obtain second indication information, the second indication information including: information used for indicating that the decompression end is re-established; information used for indicating that the packet header compression function is configured for the decompression end; information used for indicating that the packet header compression function is not continuously used; and information used for indicating that a packet header integrity identifier used for identifying that a data packet includes a complete packet header is included in a packet header of a data packet that has not been subjected to packet header compression.

[0160] Another compression processing apparatus is provided in the embodiments of the present application, and is applied to a decompression end, and the compression processing apparatus is configured to:

[0161] obtain second indication information, the second indication information including: information used for indicating that the decompression end is re-established; information used for indicating that the packet header compression function is configured for the decompression end; information used for indicating that the packet header compression function is not continuously used; and information used for indicating that a packet header integrity identifier used for identifying that a data packet includes a complete packet header is included in a packet header of a data packet that has not been subjected to packet header compression; and discard an established compression context according to the second indication information.

[0162] Another compression processing apparatus is provided in the embodiments of the present application, and is applied to a decompression end, and the compression processing apparatus is configured to:

[0163] The second indication information includes: information indicating re-establishment of the decompression end; information indicating that the packet header compression function is configured for the decompression end; information indicating that the packet header compression function is not continuously used; and information indicating that the packet header of a data packet not compressed by the packet header compression function includes a packet header integrity identifier identifying that the data packet includes a complete packet header. The compression processing device further includes a receiving module configured to receive the data packet not compressed by the packet header compression function.

[0164] As a possible implementation, the data packet not compressed by the packet header compression function includes a compression context identifier, which is a context identifier CID of the compressed data packet. The receiving module can be further configured to:

[0165] receive the data packet not compressed by the packet header compression function and including the compression context identifier, wherein the compression context identifier of the received data packet is the same as a preset compression context identifier.

[0166] As another possible implementation, the receiving module can be further configured to:

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

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

[0169] discard the compressed data packet; and send 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 contents:

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

[0172] It should be noted that the packet header compression in the embodiments of the present application can include, but is not limited to, Ethernet header compression (EHC) and the like. The decompression end in the embodiments of the present application can be a packet data convergence protocol (PDCP) entity, a network entity, a terminal, a network device, a base station, a router, a gateway, and the like.

[0173] According to the embodiments of the present application, the present application further provides a compression end including the compression processing device 900 provided by the embodiments 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 transmits a data packet without header compression instead of transmitting a compressed data packet with header compression, so that the decompression end can avoid the inconsistency in understanding the header compression state of the data packet with the compression end due to the failure to obtain the compression state of the current data packet in the case that the compression function cannot continue, and thus the header decompression of the data packet fails.

[0175] According to the embodiment of the present application, the present application further provides a decompression end comprising the compression processing device 1000 provided by 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 to successfully receive the data packet without header compression transmitted by the compression end in the case that the compression function cannot continue, so that the inconsistency in understanding the header compression state of the data packet with the compression end due to the failure to obtain the compression state of the current data packet can be avoided, and thus the header decompression of the data packet fails.

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

[0178] As shown in Figure 11 , it is a block diagram of an electronic device according to the embodiment of the present application. The electronic device is intended to represent various forms of digital computers, such as laptops, desktops, tablets, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown in the figures, their connections and relationships, and their functions, are meant to be examples only, and are not intended to limit the implementations of the present application described and / or claimed in this document.

[0179] As shown in Figure 11As shown, the electronic device includes one or more processors 1100, memory 1200, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components are interconnected by different buses, and can be mounted on a common motherboard or otherwise mounted as appropriate. The processor can process instructions for execution within the electronic device, including instructions stored in the memory or on the memory to display graphical information for a GUI on an external input / output device, such as a display device coupled to the interface. In other implementations, multiple processors and / or multiple buses can be employed as appropriate, as well as multiple memories and types of memory. Also, various components can be connected by various interfaces, not only the interface shown. The electronic device can be a server, a desktop computer, a laptop computer, a tablet computer, a personal digital assistant (PDA), a cellular telephone, a smartphone, or other electronic devices. Figure 11 The processor 1100 is taken as an example in the embodiment.

[0180] The memory 1200 is a non-transitory computer readable storage medium provided by the present application. The memory stores instructions executable by at least one processor, so that the at least one processor executes the compression processing method provided by the present application. The non-transitory computer readable storage medium of the present application stores computer instructions for causing a computer to execute the compression processing method provided by the present application.

[0181] The memory 1200 is a non-transitory computer readable storage medium, which can be used to store non-transitory software programs, non-transitory computer executable programs and modules, such as program instructions / modules of the compression processing method in the embodiment of the present application (for example, the sending module 910 shown in the embodiment). The processor 1100 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions and modules stored in the memory 1200, that is, implements the compression processing method in the method embodiment. Figure 9 The sending module 910 shown in the embodiment). The processor 1100 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions and modules stored in the memory 1200, that is, implements the compression processing method in the method embodiment.

[0182] The memory 1200 can include a program storage area and a data storage area, wherein the program storage area can store an operating system, application programs required by at least one function; the data storage area can store data created according to the use of the positioning electronic device, etc. In addition, the memory 1200 can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. Optionally, the memory 1200 can include a memory remotely arranged with respect to the processor 1100, which can be connected to the positioning electronic device through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0183] The electronic device can 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 can be connected through a bus or other means, Figure 11 The connection through the bus is taken as an example.

[0184] The input device 1300 can receive input digital or character information and generate key signal input related to user's setting and function control of positioning the electronic device, such as a touch screen, a keypad, a mouse, a trackpad, a touchpad, a pointing stick, one or more mouse buttons, a trackball, a joystick, etc. The output device 1400 can include a display device, an auxiliary lighting device (e.g., an LED), a tactile feedback device (e.g., a vibration motor), etc. The display device can 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 can be a touch screen.

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

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

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

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

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

[0190] It should be understood that the various forms of flow shown above can be re-ordered, added to, or deleted from without departing from the spirit of the present disclosure. For example, the steps recited in the present application can be performed in parallel, sequentially, or in different orders, as long as the desired results of the technology disclosed in the present application are achieved, and the present application is not limited herein.

Claims

1. A compression processing method characterized by, The method applied to a compression end comprises: discarding an established compression context according to first indication information, the first indication information comprises: information for indicating re-establishment of the compression end; information for indicating configuration of an Ethernet header compression (EHC) function for the compression end; and information for indicating that the EHC function is not continuously used.

2. The method of claim 1, wherein, The method further comprises: after discarding the established compression context, sending a data packet without header compression.

3. The method of claim 1, wherein, The method further comprises: before establishing a new compression context, discarding a previously established compression context.

4. The method of claim 1, wherein, The method further comprises: sending a data packet without header compression comprising a context identification (CID), wherein the CID corresponding to the current compression is the same as the CID corresponding to the previous compression.

5. The method of claim 1, wherein, The EHC function comprises an EHC function for uplink.

6. The method of claim 1, wherein, After the discarding of the established compression context, the method further comprises: sending a compressed data packet with header compression, wherein before the sending of the compressed data packet with header compression, no data packet without header compression with the same context identification (CID) as the compressed data packet is sent; receiving decompression failure information.

7. The method of claim 6, wherein, The decompression failure information comprises at least one of: a decompression failure type indication; a compression context identification of the compressed data packet; a data flow identification of the compressed data packet; or a bearer identification of the compressed data packet.

8. The method of claim 1, wherein, The data packet of the Ethernet header compression (EHC) comprises a data packet without header compression or a data packet with header compression; the header of the data packet without header compression is an EHC full header (FH), and the EHC FH comprises an "F / C" field for identifying that the data packet comprises a full header (FH), a context identification (CID) for identifying a compressed data packet context, an Ethernet header, and a payload ( + PAD); the header of the data packet with header compression is an EHC compressed header (CH), and the EHC CH comprises an "F / C" field for identifying that the data packet comprises a compressed header (CH), a context identification (CID) for identifying a compressed data packet context, and a payload ( + PAD).

9. The method according to any one of claims 1 to 8, characterized in that, The compression end comprises any one of a packet data convergence protocol (PDCP) entity, a network entity, a terminal, a user equipment (UE), a network device, a base station, a router, and a gateway.

10. A compression processing method characterized by, The method applied to a decompression end comprises: discarding an established compression context according to second indication information, the second indication information comprises: information for indicating re-establishment of the decompression end; information for indicating configuration of an Ethernet header compression (EHC) function for the decompression end; and information for indicating that the EHC function is not continuously used.

11. The method of claim 10, wherein, The method further comprises: after discarding the established compression context, receiving a data packet without header compression.

12. The method of claim 10, wherein, The method further comprises: before establishing a new compression context, discarding a previously established compression context.

13. The method of claim 10, wherein, The method further comprises: receive a data packet without header compression, wherein a context identification CID corresponding to the current decompression is the same as a context identification CID corresponding to the last decompression.

14. The method of claim 10, wherein, The EHC function includes an EHC function for uplink.

15. The method of claim 10, wherein, After the established compression context is discarded, the method further includes: receiving a compressed data packet with header compression, wherein before the compressed data packet with header compression is received, no data packet without header compression with the same context identification CID as the compressed data packet is received; performing a decompression failure processing operation.

16. The method of claim 15, wherein, The decompression failure processing operation includes at least one of: discarding the compressed data packet; or sending decompression failure information.

17. The method of claim 16, wherein, The decompression failure information includes at least one of: a decompression failure type indication; a compression context identification of the compressed data packet; a data stream identification of the compressed data packet; or a bearer identification of the compressed data packet.

18. The method of claim 10, wherein, The data packet of the Ethernet header compression (EHC) includes a data packet without header compression or a data packet with header compression; The header of the data packet without header compression is an EHC full header (FH), and the EHC FH includes an "F / C" field for identifying that the data packet includes a full header (FH), a context identification (CID) for identifying a compressed data packet context, an Ethernet header, and a payload (PAD); The header of the data packet with header compression is an EHC compressed header (CH), and the EHC CH includes an "F / C" field for identifying that the data packet includes a compressed header (CH), a context identification (CID) for identifying a compressed data packet context, and a payload (PAD).

19. The method according to any one of claims 10-18, characterized in that, The decompression end includes any of a packet data convergence protocol (PDCP) entity, a network entity, a terminal, a user equipment (UE), a network device, a base station, a router, and a gateway.

20. A compression processing device, characterized by, The device is configured to be applied to a compression end, and the device is configured to: discard an established compression context according to first indication information, The first indication information includes: information for indicating that the compression end is re-established; information for indicating that an Ethernet header compression (EHC) function is configured for the compression end; and information for indicating that the EHC function is not continuously used.

21. The apparatus of claim 20, wherein, The device is configured to: send a data packet without header compression after the established compression context is discarded.

22. The apparatus of claim 20, wherein, The device is configured to: discard a previously established compression context before a new compression context is established.

23. The apparatus of claim 20, wherein, The device is further configured to: send a data packet without header compression including a context identification (CID), wherein a CID corresponding to the current compression is the same as a CID corresponding to the last compression.

24. The apparatus of claim 20, wherein, The EHC function includes an EHC function for uplink.

25. The apparatus of claim 20, wherein, The device is further configured to: After discarding the established compression context, a compressed data packet with header compression is sent, wherein before the sending of the compressed data packet with header compression, no data packet without header compression with a same context identification CID as the compressed data packet is not sent; Receiving decompression failure information.

26. The apparatus of claim 25, wherein, The decompression failure information comprises at least one of: a decompression failure type indication; a compression context identification of the compressed data packet; a data flow identification of the compressed data packet; or a bearer identification of the compressed data packet.

27. The apparatus of claim 20, wherein, The data packet of the Ethernet header compression EHC comprises a data packet without header compression or a data packet with header compression; The header of the data packet without header compression is an EHC full header FH, and the EHC FH comprises an "F / C" field for identifying that the data packet comprises a full header FH, a context identification CID for identifying a compressed data packet context, an Ethernet header, and a payload PAYLOAD (+PAD); The header of the data packet with header compression is an EHC compressed header CH, and the EHC CH comprises an "F / C" field for identifying that the data packet comprises a compressed header CH, a context identification CID for identifying a compressed data packet context, and a payload PAYLOAD (+PAD).

28. The apparatus of any one of claims 20-27, wherein, The compression end comprises any one of a packet data convergence protocol PDCP entity, a network entity, a terminal, a user equipment UE, a network device, a base station, a router, and a gateway.

29. A compression processing device, characterized by Applied to a decompression end, the apparatus is configured to: discard an established compression context according to second indication information, The second indication information comprises: information for indicating that the decompression end is re-established; information for indicating that an Ethernet header compression EHC function is configured for the decompression end; and information for indicating that the EHC function is not continuously used.

30. The apparatus of claim 29, wherein, The apparatus is configured to: after discarding the established compression context, receive a data packet without header compression.

31. The apparatus of claim 29, wherein, The apparatus is further configured to: discard a previously established compression context before a new compression context is established.

32. The apparatus of claim 29, wherein, The apparatus is further configured to: receive a data packet without header compression comprising a context identification CID, wherein a CID corresponding to the current decompression is the same as a CID corresponding to the last decompression.

33. The apparatus of claim 29, wherein, The EHC function comprises an EHC function for uplink.

34. The apparatus of claim 29, wherein, The apparatus is further configured to: after discarding the established compression context, receive a compressed data packet with header compression, wherein before the receiving of the compressed data packet with header compression, no data packet without header compression with a same context identification CID as the compressed data packet is not received; perform a decompression failure processing operation.

35. The apparatus of claim 34, wherein, The performing of the decompression failure processing operation comprises at least one of: discarding the compressed data packet; or sending decompression failure information.

36. The device of claim 35, wherein, The decompression failure information comprises at least one of: a decompression failure type indication; a compression context identification of the compressed data packet; a data flow identification of the compressed data packet; or a bearer identification of the compressed data packet. a data stream identifier of the compressed data packet; or a bearer identifier of the compressed data packet.

37. The apparatus of claim 29, wherein, The data packet of the Ethernet header compression (EHC) includes a data packet without packet header compression or a data packet with packet header compression. The packet header of the data packet without packet header compression is an EHC full header (FH), and the EHC FH includes an "F / C" field for identifying that the data packet includes the full header (FH), a context identifier (CID) for identifying a compressed data packet context, an Ethernet header, and a payload (PAYLOAD (+PAD)). The packet header of the data packet with packet header compression is an EHC compressed header (CH), and the EHC CH includes an "F / C" field for identifying that the data packet includes the compressed header (CH), a context identifier (CID) for identifying a compressed data packet context, and a payload (PAYLOAD (+PAD)).

38. The device of any one of claims 29-37, wherein, The decompression end includes any one of the following: a packet data convergence protocol (PDCP) entity, a network entity, a terminal, a user equipment (UE), a network device, a base station, a router, and a gateway.

39. A compression end, characterized by The compression processing apparatus comprises: The compression processing apparatus according to any one of claims 20-28.

40. A decompression end, comprising: The compression processing apparatus comprises: The compression processing apparatus according to any one of claims 29-38.

41. A terminal, characterized by The compression processing apparatus comprises: The compression processing apparatus according to any one of claims 20-28, or the compression processing apparatus according to any one of claims 29-38.

42. A network device, comprising: The compression processing apparatus comprises: The compression processing apparatus according to any one of claims 20-28, or the compression processing apparatus according to any one of claims 29-38.

43. An electronic device, comprising: The compression processing apparatus comprises: at least one processor; and a memory connected to the at least one processor in communication; 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 according to any one of claims 1-9, or the compression processing method according to any one of claims 10-19.

44. A computer readable storage medium having stored thereon computer instructions, wherein: The computer instructions are used to enable the computer to perform the compression processing method according to any one of claims 1-9, or the compression processing method according to any one of claims 10-19.

45. A compression processing system characterized by, The compression processing apparatus comprises a compression end configured to perform the compression processing method according to any one of claims 1-9, and a decompression end configured to perform the compression processing method according to any one of claims 10-19.

Images