CN113711558B - Ethernet frame packet header compression processing method and device, user terminal, base station and medium - Google Patents

Abstract

The present disclosure proposes an Ethernet frame header compression processing method, device, user terminal, base station, and medium, wherein the method applied to the user terminal includes: when obtaining the packet data convergence protocol reconstruction instruction, if the transmission mode of the current bearer is confirmation mode, and the configuration file meets the preset conditions, and the current bearer includes a preset data packet, then at least one first complete data packet is sent to the base station; wherein, each first complete data packet includes context information, uncompressed header information and a first sequence number, and the context information is the context reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction information, the first sequence number is any sequence number that the base station has not received in the bearer. In this way, it can be ensured that the base station successfully obtains the reset context information, and normal data transmission is ensured.

Description

Ethernet frame header compression processing method, device, user terminal, base station and medium

technical field

The present disclosure relates to the technical fields of data processing and network transmission, and in particular to a method, device, user terminal, base station and medium for compressing and processing Ethernet frame headers.

Background technique

At present, when the user terminal communicates with the base station, if a packet data convergence protocol (Packet Data Convergence Protocol, PDCP for short) reconstruction request is received, the user terminal needs to perform a PDCP reconstruction process, and then perform normal PDCP layer data transmission after performing the reconstruction process.

However, if the configuration parameter drb-ContinueROHC in the configuration file is not assigned a value or is assigned a value of false, then when the transmission mode is the confirmation mode, and there are unsuccessfully sent data packets before reconstruction, the user terminal will reset the header compression context information, and correspondingly, the user terminal will send a PDCP protocol data unit (Protocol Data Unit, PDU) including complete header information and context information to the base station. If the sent data packet uses the sequence number (SN) of the PDCP PDU sent before reconstruction, the base station will consider that the data packet corresponding to the SN has been received, causing the base station to directly delete the PDCP PDU without further checking or obtaining the information in it, resulting in failure to obtain and/or store valid (new) header compression context information. Furthermore, since the base station does not have effective header compression context information, subsequent compressed packets sent by the user terminal cannot be decompressed, resulting in decompression failure and further data transmission failure.

public content

The disclosure proposes an Ethernet frame header compression processing method, device, user terminal, base station, and medium to ensure that the base station successfully obtains reset context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission, and is used to solve the technical problem that the base station cannot perform decompression in the prior art.

The embodiment of the first aspect of the present disclosure proposes an Ethernet frame header compression processing method, which is applied to a user terminal, including:

When the packet data convergence protocol reconstruction instruction is acquired, if the transmission mode of the current bearer is the confirmation mode, and the configuration file satisfies the preset condition, and the current bearer includes a preset data packet, then send at least one first complete data packet to the base station;

Wherein, each first complete data packet includes: context information, uncompressed packet header information, and a first sequence number, wherein the context information is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction, and the first sequence number is any sequence number that has not been received by the base station in the bearer.

In the Ethernet frame header compression processing method of the embodiment of the present disclosure, when the user terminal obtains the packet data convergence protocol reconstruction instruction, if the transmission mode of the current bearer is the confirmation mode, and the configuration file satisfies the preset conditions, and the current bearer includes the preset data packet, at least one first complete data packet is sent to the base station; wherein, each first complete data packet includes: context information, uncompressed packet header information, and a first sequence number. Any serial number not received in . In the present disclosure, the user terminal sends at least one first complete data packet to the base station. Since the first complete data packet includes a sequence number that the base station has not received in the bearer, it can be ensured that the base station successfully obtains the reset context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

The embodiment of the second aspect of the present disclosure proposes another Ethernet frame header compression processing method, which is applied to the base station, including:

When the packet data convergence protocol reconstruction request is obtained, if the transmission mode of the current session is confirmation mode, and the configuration file satisfies the preset condition, and the first sequence number in the first complete data packet obtained from the user terminal is a sequence number that has not been received by the base station in the current bearer, then saving the context information in the first complete data packet, so as to decompress the new compressed packet according to the context information in the first complete data packet;

Wherein, the first complete data packet is sent by the user terminal to the base station after obtaining the packet data convergence protocol reconstruction instruction.

In the Ethernet frame header compression processing method of the embodiment of the present disclosure, when the base station obtains the reconstruction request of the packet data convergence protocol, if the transmission mode of the current session is the confirmation mode and the configuration file meets the preset conditions, and the first sequence number in the first complete data packet obtained from the user terminal is a sequence number that the base station has not received in the current bearer, then the context information in the first complete data packet is saved, so as to decompress the new compressed packet according to the context information in the first complete data packet; Sent to the base station after the reconstruction command. In the present disclosure, it can be ensured that the base station successfully obtains the reset context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

The embodiment of the third aspect of the present disclosure proposes another Ethernet frame header compression processing method, which is applied to the base station, including:

When the packet data convergence protocol reconstruction request is obtained, if the transmission mode of the current session is the confirmation mode, and the configuration file satisfies the preset condition, and the second sequence number in the second complete data packet obtained from the user terminal is a sequence number that the base station has received in the current bearer, then save the context information in the second complete data packet.

In the Ethernet frame header compression processing method of the embodiment of the present disclosure, when the base station obtains the packet data convergence protocol reconstruction request, if the transmission mode of the current session is the confirmation mode, and the configuration file meets the preset conditions, and the second sequence number in the second complete data packet obtained from the user terminal is the sequence number that the base station has received in the current bearer, then the context information in the second complete data packet is saved. In this way, it can be ensured that the base station successfully acquires the context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

The embodiment of the fourth aspect of the present disclosure proposes an Ethernet frame header compression processing device, which is set in a user terminal and includes:

A sending module, configured to send at least one first complete data packet to the base station if the transmission mode of the current bearer is an acknowledgment mode, and the configuration file satisfies preset conditions, and the current bearer includes a preset data packet when the packet data convergence protocol reconstruction instruction is acquired;

Wherein, each first complete data packet includes: context information, uncompressed packet header information, and a first sequence number, wherein the context information is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction, and the first sequence number is any sequence number that has not been received by the base station in the bearer.

The Ethernet frame header compression processing device in the embodiment of the present disclosure, when the user terminal obtains the packet data convergence protocol reconstruction instruction, if the transmission mode of the current bearer is confirmation mode, and the configuration file satisfies the preset conditions, and the current bearer includes the preset data packet, then at least one first complete data packet is sent to the base station; wherein, each first complete data packet includes: context information, uncompressed packet header information and a first sequence number, wherein the context information is context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction, and the first sequence number is the base station carrying Any sequence number not used in . In the present disclosure, the user terminal sends at least one first complete data packet to the base station. Since the first complete data packet includes a sequence number that the base station has not received in the bearer, it can be ensured that the base station successfully obtains the reset context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

The embodiment of the fifth aspect of the present disclosure proposes another Ethernet frame header compression processing device, which is set at the base station and includes:

The saving module is configured to save the context information in the first complete data packet, so as to decompress the new compressed packet according to the context information in the first complete data packet, if the transmission mode of the current session is confirmation mode and the configuration file satisfies preset conditions, and the first sequence number in the first complete data packet obtained from the user terminal is a sequence number that has not been received by the base station in the current bearer when the packet data convergence protocol reconstruction request is obtained;

Wherein, the first complete data packet is sent by the user terminal to the base station after obtaining the packet data convergence protocol reconstruction instruction.

The Ethernet frame header compression processing device in the embodiment of the present disclosure, when the base station obtains the reconstruction request of the packet data convergence protocol, if the transmission mode of the current session is the confirmation mode and the configuration file meets the preset conditions, and the first sequence number in the first complete data packet obtained from the user terminal is a sequence number that the base station has not received in the current bearer, then the context information in the first complete data packet is saved, so as to decompress the new compressed packet according to the context information in the first complete data packet; Sent to the base station after the reconstruction command. In the present disclosure, it can be ensured that the base station successfully obtains the reset context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

The embodiment of the sixth aspect of the present disclosure proposes another Ethernet frame header compression processing device, which is set at the base station and includes:

The saving module is configured to save the context information in the second complete data packet if the transmission mode of the current session is the confirmation mode, and the configuration file satisfies the preset condition, and the second sequence number in the second complete data packet obtained from the user terminal is a sequence number that the base station has received in the current bearer when the packet data convergence protocol reconstruction request is obtained.

The Ethernet frame header compression processing device of the embodiment of the present disclosure, when the base station obtains the packet data convergence protocol reconstruction request, if the transmission mode of the current session is the confirmation mode, and the configuration file meets the preset conditions, and the second sequence number in the second complete data packet obtained from the user terminal is the sequence number that the base station has received in the current bearer, then the context information in the second complete data packet is saved. In this way, it can be ensured that the base station successfully acquires the context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

The embodiment of the seventh aspect of the present disclosure proposes a user terminal, including: a memory, a processor, and a computer program stored on the memory and operable on the processor. When the processor executes the program, it implements the Ethernet frame header compression processing method proposed in the embodiment of the first aspect of the present disclosure.

The embodiment of the eighth aspect of the present disclosure proposes a base station, including: a memory, a processor, and a computer program stored in the memory and operable on the processor. When the processor executes the program, it implements the Ethernet frame header compression processing method proposed in the embodiment of the second aspect of the present disclosure.

The embodiment of the ninth aspect of the present disclosure proposes a base station, including: a memory, a processor, and a computer program stored in the memory and operable on the processor. When the processor executes the program, it implements the Ethernet frame header compression processing method as proposed in the embodiment of the third aspect of the present disclosure.

The embodiment of the tenth aspect of the present disclosure provides a computer-readable storage medium on which a computer program is stored, and is characterized in that, when the program is executed by a processor, the Ethernet frame header compression processing method as proposed in the embodiment of the first aspect of the present disclosure is implemented, or, the Ethernet frame header compression processing method as proposed in the embodiment of the second aspect of the present disclosure is implemented, or, the Ethernet frame header compression processing method as proposed in the embodiment of the third aspect of the present disclosure is implemented.

Additional aspects and advantages of the disclosure will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the disclosure.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure, the following will briefly introduce the accompanying drawings used in the embodiments. Obviously, the accompanying drawings in the following description are some embodiments of the present disclosure. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative work.

FIG. 1 is a schematic flow diagram of an Ethernet frame header compression processing method provided by Embodiment 1 of the present disclosure;

FIG. 2 is a schematic diagram of an interaction process between a user terminal and a base station in an embodiment of the present disclosure;

FIG. 3 is a schematic flow diagram of the Ethernet frame header compression processing method provided by Embodiment 2 of the present disclosure;

4 is a schematic flow diagram of the Ethernet frame header compression processing method provided by Embodiment 3 of the present disclosure;

5 is a schematic structural diagram of an Ethernet frame header compression processing device provided in Embodiment 4 of the present disclosure;

6 is a schematic structural diagram of an Ethernet frame header compression processing device provided in Embodiment 5 of the present disclosure;

7 is a schematic structural diagram of an Ethernet frame header compression processing device provided in Embodiment 6 of the present disclosure;

FIG. 8 is a schematic structural diagram of an Ethernet frame header compression processing device provided by Embodiment 7 of the present disclosure.

Detailed ways

Embodiments of the present disclosure are described in detail below, examples of which are illustrated in the drawings, in which the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the figures are exemplary and are intended to explain the present disclosure and should not be construed as limiting the present disclosure.

In the 5G Industrial Internet of Things (IIoT for short), it is required to support the transmission of services such as Factory automation, Transport Industry, and Electrical Power Distribution in the 5G system. Based on its delay and reliability transmission requirements, IIoT introduces the concept of time-sensitive network TSN or TSC, and needs to perform header compression processing on TSN services. Wherein, the TSC service may be carried by an Ethernet frame (Ethernet frame), or may be carried by an IP data packet.

Among them, the introduction of the Ethernet frame issue is because the existing communication system only supports header compression for data packets whose PDU session is IP. In a 5G New Radio (NR) system, the type of PDU session can be not only an IP packet type, but also an Ethernet frame type. For example, for the PDU layer, when the PDU session type is Internet Protocol version 4 (Internet Protocol version 4, Pv4 for short) or IPv6 or IPv4v6, the PDU session corresponds to an IPv4 packet and/or IPv6 packet; when the PDU session type is Ethernet, the PDU session corresponds to an Ethernet frame.

Currently, the PDCP protocol introduces header compression and decompression functions to perform header compression on IP data packets. The current Robust Header Compression (RoHC for short) is configured for Data Radio Bearer (DRB for short). The compression end and the decompression end use different header compression and header compression parameters according to the configuration file, and use the RoHC protocol to perform compression and decompression processing. Wherein, it is configured in PDCP-config, and each PDCP-config corresponds to one DRB.

During PDCP reconstruction, if the drb-ContinueROHC parameter is configured in the configuration file, it means that the previous RoHC information will be used for compression and decompression after reconstruction. Otherwise, the state of compression and decompression will be reset, that is, the decompression end will have no valid context information and needs to receive new context information, the compression end needs to reset the compression state, and send an uncompressed data packet containing context information to the decompression end, that is, a complete data packet.

When the user terminal communicates with the base station, when receiving a PDCP re-establishment request from a higher layer, the user terminal needs to perform a PDCP re-establishment process, and then perform normal PDCP layer data transmission after performing the re-establishment process. If drb-ContinueROHC is not configured, or is false, during the reconstruction process, when the transmission mode is confirmation mode, if a PDCP PDU has been transmitted to the lower layer before reconstruction, but has not received the confirmation of successful transmission or failed transmission, then when the user terminal transmits or retransmits these data packets, it needs to use the SN used before PDCP reconstruction, but use the new header compression context information to send data packets, that is, delete the original context, reset the header compression status and context information, and use the new context information to send PDCP PDUs. Then, after receiving the re-establishment request, the user terminal needs to use the SN before re-establishment to send an uncompressed data packet containing new context information to the base station. Then, the corresponding PDCP PDU corresponding to the subsequent SN is sent.

When the base station receives the PDCP re-establishment request from the upper layer, it needs to process the PDCP PDU and subsequent PDU received from the lower layer due to the re-establishment. For the PDCP PDU received before the reconstruction request, the base station can decompress according to the original context information, and for the PDCP PDU received after the reconstruction request, the processing process includes: deleting the PDU with the same SN (that is, when the base station receives a PDU and finds that the SN corresponding to the PDU is the previously received SN, the base station will directly discard the data packet without further checking the information in the packet), reset the new context information, reset the decompression state, decompress according to the new context information, and receive the new PD after the reconstruction request U.

However, if the configuration parameter drb-ContinueROHC in the configuration file is not assigned a value or is assigned a value of false, then when the transmission mode is the confirmation mode and there are unsuccessful data packets before reconstruction, the user terminal will reset the header compression context information, and correspondingly, the user terminal will send a PDCP PDU containing complete header information and context information to the base station. If the sent data packet uses the sequence number (SN) of the PDCP PDU sent before reconstruction, the base station will consider that the data packet corresponding to the SN has been received, causing the base station to directly delete the PDCP PDU without further checking or obtaining the information in it, resulting in failure to obtain and/or store valid (new) header compression context information. Furthermore, since the base station does not have effective header compression context information, subsequent compressed packets sent by the user terminal cannot be decompressed, causing decompression failure and further data transmission failure.

Therefore, the present disclosure mainly aims at the technical problem that the above-mentioned base station cannot perform decompression, and proposes a method for compressing the packet header of the Ethernet frame.

In the Ethernet frame header compression processing method of the embodiment of the present disclosure, when the user terminal obtains the packet data convergence protocol reconstruction instruction, if the transmission mode of the current bearer is the confirmation mode, and the configuration file satisfies the preset conditions, and the current bearer includes the preset data packet, at least one first complete data packet is sent to the base station; wherein, each first complete data packet includes: context information, uncompressed packet header information, and a first sequence number. Any serial number not received in . In the present disclosure, the user terminal sends at least one first complete data packet to the base station. Since the first complete data packet includes a sequence number that the base station has not received in the bearer, it can be ensured that the base station successfully obtains the reset context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

The following describes the Ethernet frame header compression processing method, device, user terminal, base station and medium according to the embodiments of the present disclosure with reference to the accompanying drawings. Before specifically describing the embodiments of the present disclosure, for ease of understanding, firstly, the commonly used technical terms of the present disclosure are introduced:

Header compression refers to compressing the header of a data packet to improve the transmission efficiency of user data. Currently, in Long Term Evolution (LTE for short) and NR, at the PDCP layer, RoHC is used to perform header compression on the data packet header.

A full packet is an Ethernet packet, which includes complete Ethernet hearer header information and context information, such as context ID, indication information (used to indicate whether the data packet is a compressed packet or a complete data packet), and other possible but undetermined upper context information, such as profile ID. Among them, the context information is used for packet header compression and/or decompression. Specifically, when the compression end and the decompression end establish their context relationship, or the decompression end receives and saves valid context information (specifically, the effective context information includes: context identifier or indication, complete packet header information. Further, after the corresponding relationship between the context identifier or indication and the complete packet header information can be inferred or saved), the compressed packets can be exchanged between the two.

A compressed packet is an Ethernet packet, which includes compressed Ethernet hearer header information (not including header information, or only including part of header information), context information, and the like.

FIG. 1 is a schematic flow chart of the Ethernet frame header compression processing method provided by Embodiment 1 of the present disclosure.

The Ethernet frame header compression processing method in the embodiment of the present disclosure may be applied to a user terminal, and the user terminal may specifically be a compression end, that is, a PDCP sending entity. Correspondingly, the receiving end (decompression end, PDCP receiving entity) is a base station.

Of course, in another implementation manner, the Ethernet frame header compression processing method can be applied to the base station side, that is, the base station is the compression end, that is, the PDCP sending entity. Correspondingly, the receiving end (decompression end, PDCP receiving entity) is a user terminal.

The following description mainly takes the compression end to which the Ethernet frame header compression processing method is applied as the user terminal. The method in which the compression end is the base station is similar.

As shown in Figure 1, the Ethernet frame header compression processing method may include the following steps:

Step 101: When the packet data convergence protocol reconstruction instruction is obtained, if the transmission mode of the current bearer is the confirmation mode, the configuration file meets the preset conditions, and the current bearer includes preset data packets, then at least one first complete data packet is sent to the base station.

Wherein, each first complete data packet includes: context information, uncompressed packet header information, and a first sequence number, wherein the context information is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction, and the first sequence number is any sequence number that the base station has not received in the bearer.

In the embodiment of the present disclosure, the transmission mode may include a transparent mode (TM), an unacknowledged mode (UM) and an acknowledged mode (AM).

In the embodiment of the present disclosure, the configuration file meeting the preset condition may include: no value is assigned to the preset configuration parameter in the configuration file, or the value assigned to the preset configuration parameter in the configuration file is false. For example, the preset configuration parameter may be drb-ContinueROHC, and when drb-ContinueROHC is not assigned a value, or when drb-ContinueROHC is assigned a value of false, it is determined that the configuration parameter meets the preset condition.

In the embodiment of the present disclosure, the preset data packet may be a data packet that the user terminal failed to send before obtaining the reconstruction instruction, or the predetermined data packet may be a data packet that the user terminal has not obtained a transmission success confirmation or an unconfirmed sending status when obtaining the reconstruction instruction, or the preset data packet may also be a data packet lost when the user terminal obtains the reconstruction instruction, or the preset data packet may also be a data packet that the user terminal lost before obtaining the reconstruction instruction, which is not limited in this disclosure. For example, the preset data packet may be confirmed according to the PDCP status report, wherein the preset data packet may include at least one of the following: PDUs that have been successfully sent, PDUs that have not been successfully sent, missing (missing) PDUs, and PDUs with uncertain sending status.

In the embodiment of the present disclosure, each first complete data packet includes a first sequence number, and the first sequence numbers in different first complete data packets may be different. Wherein, the first sequence number may be a sequence number (SN), or the first sequence number may also be a count (COUNT). Among them, COUNT occupies 32 bits, and is composed of Hyper Frame Number (HFN for short) and PDCP SN, and SN is the low bit of COUNT.

In the embodiment of the present disclosure, the first sequence number in the first complete data packet is any sequence number that the base station has not received in the current bearer, where the sequence number that the base station has not received in the current bearer, that is, the first sequence number may be a sequence number that has not been used by the user terminal, or may be a sequence number that has been used by the user terminal, but the sequence number is a sequence number in a lost data packet (missing PDU), which is not limited.

As a possible implementation manner, when the serial numbers are generated sequentially, the first serial number may be the first of the unused serial numbers, or may be the Mth of the unused serial numbers. For example, the first sequence number may be an SN that has not been used or sent by the user terminal before PDCP re-establishment, or the first sequence number may be the next SN or the Mth SN after the last SN carried in the PDCP status report. For example, if the last SN carried in the PDCP status report is 10, the first sequence number may be 11, 12, 13, etc., or the first sequence number may also be the next SN or the Mth SN after the SN whose reception status has not been confirmed by the base station. limit.

As another possible implementation, when the serial numbers are randomly generated, that is, the serial numbers sent by the user terminal each time are not continuous, at this time, the serial numbers that have been used by the user terminal can be recorded, so that the unused serial numbers can be determined according to the used serial numbers. For example, if the serial numbers used by the user terminal are 1 and 10, the first serial numbers may be 3, 5, 15, 17 and so on.

In the embodiment of the present disclosure, when the user terminal receives the PDCP re-establishment instruction, or when the higher layer instructs the PDCP re-establishment, it can judge whether the transmission mode of the current bearer is confirmed mode, the configuration file satisfies the preset condition, and the current bearer includes the preset data packet. If these three conditions are met at the same time, the user terminal can send at least one first complete data packet to the base station, wherein each first complete data packet includes: context information, uncompressed header information and the first sequence number. The context information is reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction Context information, for example, the user terminal can update the existing context information, or reset the existing context information. The context information includes at least a context identifier; the first sequence number is any sequence number that has not been used by the base station in the bearer session.

It should be noted that before the user terminal resets the context information, the user terminal has sent a complete data packet and a compressed packet to the base station, and the context form and content in the complete data packet and the compressed packet may be different. After the user terminal receives the reconstruction instruction, it resets or updates according to the context in the original complete data packet, and obtains the reset context information.

It should be understood that, under the condition that the existing communication protocol remains unchanged, after receiving the PDCP re-establishment instruction, if the sequence number included in the complete data packet sent by the user terminal to the base station is the sequence number received by the base station in the current bearer, for example, the sequence number is the last SN carried in the PDCP status report. At this time, after receiving the complete data packet, the base station judges that the sequence number in the complete data packet has been received, and discards the complete data packet using the existing protocol. Therefore, in this disclosure, in order to prevent the base station from directly discarding the complete data packet without further checking or obtaining the information therein, resulting in failure to obtain and/or store valid context information, the sequence number in the complete data packet sent by the user terminal to the base station may be a sequence number that the base station has not received in the current bearer, thereby ensuring that the base station successfully obtains the reset context information, so that the base station can use the reset context information to perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

In the embodiment of the present disclosure, when there is a preset data packet that has not been successfully sent, and the preset data packet is not a lost data packet (such as a packet that fails to be received or is not acknowledged (NACK), the user terminal may also send a third complete data packet to the base station in an existing manner, wherein the third complete data packet includes uncompressed header information and a third sequence number in the preset data packet.

In the embodiment of the present disclosure, when the existing communication protocol remains unchanged, since the third complete data packet has a preset third sequence number of the data packet, that is, the sequence number used before reconstruction, if the user terminal only sends the third complete data packet, after receiving the third complete data packet, the base station can determine that the data packet corresponding to the third sequence number has been received according to the third sequence number in the third complete data packet, and the base station may directly delete the third complete data packet, resulting in failure to obtain and/or store valid (or new) context information. Therefore, in order to avoid the above problems, the user terminal may also send at least one first complete data packet to the base station, wherein the first complete data packet includes any sequence number that the base station has not received in the bearer, that is, the first sequence number, so that after receiving the first complete data packet, the base station can determine that the corresponding data packet has not been received according to the first sequence number. Perform decompression processing to ensure normal data transmission.

As an example, the sequence number is SN, and SN is an example of sequential generation. When the transmission mode of the current bearer is confirmation mode, the user terminal determines that the last SN contained in the PDCP PDU sent to the base station is SN=20, and the PDCP PDUs with SNs of 15, 17, 18, and 20 have not been successfully transmitted (for example, it can be determined according to the PDCP status report), and drb-ContinueROHC is not configured. Then the user terminal resets the header compression context information (new or valid context information), reset the header compression state, and use the new context information to resend PDCP PDUs with SNs of 15, 17, 18, 19, and 20 (the SN numbers are still the original 15, 17, 18, and 20). After the user terminal uses SN=21 (first sequence number) to send a new complete data packet containing new context information and a complete packet header, the user terminal can send compressed packets thereafter.

It should be noted that when the preset data packet is a lost data packet, the sequence number corresponding to the lost data packet has not been received by the base station, but is a sequence number used or sent by the user terminal. At this time, the first sequence number in the first complete data packet sent by the user terminal to the base station may specifically be the third sequence number in the preset data packet.

As another example, when the transmission mode of the current bearer is the confirmation mode, when the user terminal receives the PDCP re-establishment instruction, it determines that the PDU with the SN of 19 among the PDCP PDUs already sent to the base station is missing, and drb-ContinueROHC is not configured, then the user terminal resets the header compression context information (new or valid context information), resets the header compression state, and uses the new context information to resend the PDCP PDU with the SN of 19. After the user terminal uses SN=19 (the third sequence number) to send a new complete data packet containing new context information and a complete packet header, the user terminal can send compressed packets thereafter.

As yet another example, when the transmission mode of the current bearer is confirmation mode, when the user terminal receives the PDCP re-establishment instruction, it determines that the last SN contained in the PDCP PDU sent to the base station is SN=20, and the PDCP PDU with the SN of 15, 17, 18, and 20 is not successfully transmitted, and the PDU with the SN is 19 is missing, and drb-ContinueROHC is not configured, then the user terminal resets the header compression context information (new or valid context information), resets the header compression state, and uses the new The context information resends PDCP PDUs with SNs of 15, 17, 18, 19, and 20 (the SN numbers are still the original 15, 17, 18, and 20). After the user terminal uses SN=19 (third sequence number) and/or SN=21 (first sequence number) to send a new complete data packet containing new context information and a complete packet header, the user terminal then sends a compressed packet.

That is to say, when the preset data packet is a lost data packet, the user terminal may only send the first complete data packet to the base station, and the first sequence number included in the first complete data packet may specifically refer to the third sequence number in the preset data packet. When the preset data packet is a non-lost data packet, the user terminal may send the first complete data packet and the third complete data packet to the base station, and the third complete data packet includes uncompressed header information and the third sequence number in the preset data packet.

Further, in order to ensure that the base station obtains the corresponding context information, there may be multiple first complete data packets, and the first sequence numbers included in each first complete data packet may be different. For example, a certain SN that is not used by the user terminal and K SNs following the SN can be used, and each SN can be used as a first sequence number, so that the user terminal can send K+1 first complete data packets to the base station, so that the base station can successfully receive the reset context information. That is, there may be multiple first complete data packets sent by the user terminal to the base station, and the first sequence numbers corresponding to each first complete data packet are different. When the user terminal sends each first complete data packet to the base station, the base station can determine according to the first complete data packet that the first sequence number in the first complete data packet is a sequence number that has not been received in the current bearer. Therefore, valid context information in the first complete data packet will be saved, so that the base station can successfully receive the reset context information.

It should be noted that the number of the third complete data packets is the same as the number of preset data packets, that is, before reconstruction, several data packets failed to be sent, and after receiving the PDCP reconstruction instruction, the failed data packets can be resent to ensure the reliability and effectiveness of data transmission. Moreover, the reset context information may or may not be included in the third complete data packet. It should be understood that if the protocol of the base station is not modified, the base station will directly discard the data packet after receiving the data packet containing the repeated sequence number, so even if the third complete data packet contains the reset context information, it may be discarded. Therefore, in this disclosure, in order to reduce the number of bits of the data packet, the third complete data packet may not include the reset context information.

It should be noted that the reset context information may or may not be included in the third complete data packet. It should be understood that if the protocol of the base station is not modified, if the base station receives the data packet containing the third sequence number and determines that the SN corresponding to the data packet has not received it (such as the PDU of the corresponding SN is a lost data packet), then the base station will save the PDU and save the context information. At this time, the base station can obtain and store the context information reset by the user terminal after obtaining the PDCP re-establishment command, so that the compressed packet sent by the user terminal can be decompressed later according to the context information to ensure normal data transmission. Further, in order to ensure that the base station acquires the corresponding context information, the user terminal may also send the first complete data packet. The number of the first complete data packet is a non-negative integer.

In addition, the base station may send a feedback packet to the user terminal after saving the updated context information. After receiving the feedback packet, the user terminal can start to send the compressed packet.

In the Ethernet frame header compression processing method of the embodiment of the present disclosure, when the user terminal obtains the packet data convergence protocol reconstruction instruction, if the transmission mode of the current bearer is the confirmation mode, and the configuration file satisfies the preset conditions, and the current bearer includes the preset data packet, at least one first complete data packet is sent to the base station; wherein, each first complete data packet includes: context information, uncompressed packet header information, and a first sequence number. Any serial number not received in . In the present disclosure, the user terminal sends at least one first complete data packet to the base station. Since the first complete data packet includes a sequence number that the base station has not received in the bearer, it can be ensured that the base station successfully obtains the reset context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

As a possible implementation, when the protocol of the base station is not modified, when the base station receives the third complete data packet, and/or, at least one first complete data packet, the base station can determine whether there is a sequence number that has already been received in the current bearer in the received complete data packet, and if not, can store the reset context information in the complete data packet. Further, the base station sends a feedback packet to the user terminal, and the feedback packet may be sent by the base station after determining to receive a complete data packet including the context information; or, the feedback packet may be sent by the base station after saving the context information. Correspondingly, after receiving the feedback packet sent by the base station, the user terminal can send a compressed packet to the base station, wherein the compressed packet includes: context information, which is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction, so that the base station can decompress the compressed packet based on the reset context information to ensure normal data transmission.

As a possible implementation, when the protocol of the base station is modified, when the base station receives the third complete data packet and/or at least one first complete data packet, the base station can determine whether there is a sequence number already received in the current bearer in the received complete data packet, and if so, can store the reset context information in the complete data packet. Further, the base station sends a feedback packet to the user terminal, and the feedback packet may be sent by the base station after determining to receive a complete data packet including the context information; or, the feedback packet may be sent by the base station after saving the context information. Correspondingly, after receiving the feedback packet sent by the base station, the user terminal can send a compressed packet to the base station, wherein the compressed packet includes: context information, which is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction, so that the base station can decompress the compressed packet based on the reset context information to ensure normal data transmission.

As a possible implementation, after a preset period of time after receiving the PDCP rebuilding instruction, the user terminal may assume that the base station has received a complete data packet containing context information, or that the base station has saved the reset context information. At this time, the user terminal may send a compressed packet to the base station, wherein the compressed packet includes: context information, and the context information is context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction.

Specifically, after the first preset time interval, the user terminal may send the compressed packet to the base station. For example, assuming that the first preset time interval is 2 seconds, the user terminal receives the PDCP re-establishment command at 10:00:00, and it can be considered that the PDCP re-establishment process is completed at 10:00:02. At this time, the user terminal can send compressed packets to the base station.

As a possible implementation, after the user terminal completes the PDCP re-establishment process, it can send a PDCP re-establishment complete message to the upper layer or higher layers, and after sending the PDCP re-establishment complete message at a second preset time interval, it can send a compressed packet to the base station, wherein the compressed packet includes context information, and the context information is the context information reset by the user terminal after obtaining the packet data convergence protocol re-establishment instruction.

As an example, the processing flow of the uplink data packet is used as an example (the compression end is the user terminal, and the decompression end is the base station), and the processing of the downlink data packet (the compression end is the base station, and the decompression end is the user terminal) is similar, and will not be repeated here.

1. The first DRB can be configured with Ethernet header compression parameters on the network side, wherein drb-ContinueROHC is not configured or its value is false. Specifically, the message is indicated to the user terminal through a dedicated RRC, such as PDCP-config IE.

2. The user terminal performs header compression processing according to the configuration information during subsequent sending. Specifically, the user terminal sends a complete data packet including complete packet header information and context information, and sends a compressed packet to the base station after receiving a feedback packet or sending N packets containing complete data.

3. The base station receives the PDCP PDU from the user terminal, including complete data packets and compressed packets.

4. When the user terminal (UE) receives a PDCP re-establishment instruction from a higher layer (such as the RRC layer), or when a higher layer indicates PDCP re-establishment (for example, when the UE RRC receives a re-establishment instruction from the base station, the UE RRC requires the UE PDCP layer to perform PDCP re-establishment), if the transmission mode of the current bearer is the confirmation mode, and the configuration file meets the preset conditions, and the current bearer includes the preset data packet, the user terminal sends a complete data packet.

For example, when the transmission mode of the current bearer is confirmation mode, when the user terminal receives the PDCP re-establishment instruction, it determines that the last SN contained in the PDCP PDU that has been sent to the base station is SN=20, and the PDCP PDUs with SNs of 15, 17, 18, and 20 have not been successfully transmitted (for example, it can be determined according to the PDCP status report), and drb-ContinueROHC is not configured, then the user terminal resets the header compression context information (new or valid context information), resets the header compression status, and uses the new context information to resend Use PDCP PDUs with SNs of 15, 17, 18, and 20 (the third sequence number) (the SN numbers are still the original 15, 17, 18, and 20). After the user terminal uses SN=21 (first sequence number) to send a new complete data packet containing new context information and a complete packet header, the user terminal then sends a compressed packet.

For another example, when the transmission mode of the current bearer is the confirmed mode, the user terminal determines that the last SN contained in the PDCP PDU sent to the base station is SN=20 when receiving the PDCP re-establishment instruction, and drb-ContinueROHC is not configured, then the user terminal resets the header compression context information (new or valid context information), resets the header compression state, and uses the new context information to resend the PDU in the unacknowledged state. After the user terminal uses SN=21 to send a new complete data packet containing new context information and a complete packet header, and receives a feedback packet from the base station, the user terminal sends a compressed packet.

For another example, when the transmission mode of the current bearer is confirmation mode, when the user terminal receives the PDCP re-establishment instruction, it determines that the last SN contained in the PDCP PDU sent to the base station is SN=20, and PDCP PDUs with SNs of 15, 17, 18, and 20 have not been successfully transmitted (for example, it can be determined according to the PDCP status report), and the PDU with SN is 19 is missing, and drb-ContinueROHC is not configured, then the user terminal resets the header compression context information (new or valid context information), resets Header compression state, and use the new context information to resend PDCP PDUs with SNs of 15, 17, 18, 19, 20 (the third sequence number) (the SN numbers are still the original 15, 17, 18, 20). After the user terminal uses SN=19 (third sequence number) and/or SN=21 (first sequence number) to send a new complete data packet containing new context information and a complete packet header, the user terminal then sends a compressed packet.

5. After receiving the PDCP reconstruction request, the base station receives the complete data packet sent by the user terminal, acquires new context information, and saves it, so that the compressed packet can be decompressed later by using the new context information.

That is to say, referring to FIG. 2, when the user terminal receives the PDCP reconstruction instruction from the upper layer, if the transmission mode of the current bearer is confirmed mode, the configuration file satisfies the preset conditions, and the current bearer includes the preset data packets. The first sequence number is the sequence number corresponding to the lost data packet, and when the preset data packet is a non-lost data packet, the first complete data packet and the third complete data packet are sent. And if the transmission mode of the current bearer is the confirmation mode, the configuration file meets the preset conditions, and one of the three conditions is not satisfied, the user terminal sends the compressed packet to the base station.

Alternatively, the base station may also send a feedback packet to the user terminal after saving the updated context information. Correspondingly, after the user terminal receives the feedback packet, the user terminal can start to send the compressed packet to the base station.

In order to realize the above-mentioned embodiments, the present disclosure also proposes a method for compressing and processing Ethernet frame headers.

FIG. 3 is a schematic flowchart of a method for compressing and processing Ethernet frame headers provided by Embodiment 2 of the present disclosure.

As shown in Figure 3, the Ethernet frame header compression processing method may include the following steps:

The Ethernet frame header compression processing method in the embodiment of the present disclosure can be applied to a base station, and the base station can specifically be a decompression end, that is, a PDCP receiving entity. Correspondingly, the sending end (compressing end, PDCP sending entity) is a user terminal.

Of course, in another implementation manner, the Ethernet frame header compression processing method can be applied to the user terminal, and the base station is the compression end, that is, the PDCP sending entity. Correspondingly, the receiving end (decompression end, PDCP receiving entity) is a user terminal.

The following mainly takes the decompression end to which the Ethernet frame header compression processing method is applied as the base station for description. The method in which the decompression end is a user terminal is similar.

Step 201, when the packet data convergence protocol reconstruction request is obtained, if the transmission mode of the current session is confirmation mode, and the configuration file meets the preset conditions, and the first sequence number in the first complete data packet obtained from the user terminal is a sequence number that has not been received by the base station in the current bearer, then save the context information in the first complete data packet, so as to decompress the new compressed packet according to the context information in the first complete data packet.

Wherein, the first complete data packet is sent by the user terminal to the base station after obtaining the packet data convergence protocol reconstruction instruction.

In the embodiment of the present disclosure, the transmission mode may include a transparent mode (TM), an unacknowledged mode (UM) and an acknowledged mode (AM).

In the embodiment of the present disclosure, the configuration file meeting the preset condition may include: no value is assigned to the preset configuration parameter in the configuration file, or the value assigned to the preset configuration parameter in the configuration file is false. For example, the preset configuration parameter may be drb-ContinueROHC, and when drb-ContinueROHC is not assigned a value, or when drb-ContinueROHC is assigned a value of false, it is determined that the configuration parameter meets the preset condition.

In the embodiment of the present disclosure, the first sequence number in the first complete data packet is any sequence number that the base station has not received in the current bearer, where the sequence number that the base station has not received in the current bearer, that is, the first sequence number may be a sequence number that has not been used by the user terminal, or may be a sequence number that has been used by the user terminal, but the sequence number is a sequence number in a lost data packet (missing PDU), which is not limited. Wherein, the first sequence number may be a sequence number (SN), or the first sequence number may also be a count (COUNT). Among them, COUNT occupies 32 bits, and is composed of Hyper Frame Number (HFN for short) and PDCP SN, and SN is the low bit of COUNT.

As a possible implementation manner, when the serial numbers are generated sequentially, the first serial number may be the first of the unused serial numbers, or may be the Mth of the unused serial numbers. For example, the first sequence number may be an SN that has not been used or sent by the user terminal before PDCP re-establishment, or the first sequence number may be the next SN or the Mth SN after the last SN carried in the PDCP status report. For example, if the last SN carried in the PDCP status report is 10, the first sequence number may be 11, 12, 13, etc., or the first sequence number may also be the next SN or the Mth SN after the SN whose reception status has not been confirmed by the base station. limit.

As another possible implementation, when the serial numbers are randomly generated, that is, the serial numbers sent by the user terminal each time are not continuous, at this time, the serial numbers that have been used by the user terminal can be recorded, so that the unused serial numbers can be determined according to the used serial numbers. For example, if the serial numbers used by the user terminal are 1 and 10, the first serial numbers may be 3, 5, 15, 17 and so on.

In an embodiment of the present disclosure, when the base station receives a PDCP re-establishment request, or when a high-level layer instructs PDCP re-establishment, it can determine whether the above three conditions are met: the transmission mode of the current session is confirmation mode, the configuration file meets the preset conditions, and the first sequence number in the first complete data packet obtained from the user terminal is a sequence number that the base station has not received in the current bearer. Wherein, the first complete data packet corresponding to the first sequence number is received by the base station after receiving the PDCP reconstruction request from the upper layer, or the first complete data packet is received again from the lower layer due to PDCP.

Specifically, when the user terminal receives the PDCP re-establishment instruction, or when the higher layer instructs the PDCP re-establishment, it can determine whether the above-mentioned three conditions of the transmission mode of the current bearer being the confirmation mode, the configuration file meeting the preset condition, and the current bearer including the preset data packet are satisfied at the same time. Any sequence number that the base station has not received in the bearer. Wherein, the preset data packet may be a data packet that the user terminal fails to send before obtaining the rebuilding instruction, or the preset data packet may be a data packet that the user terminal does not obtain a transmission success confirmation or an unconfirmed sending status when obtaining the rebuilding instruction, or the preset data packet may also be a data packet lost when the user terminal obtains the rebuilding instruction, or the preset data packet may also be a data packet that the user terminal loses before obtaining the rebuilding instruction, which is not limited in this disclosure. For example, the preset data packet may be confirmed according to the PDCP status report, wherein the preset data packet may include at least one of the following: PDUs that have been successfully sent, PDUs that have not been successfully sent, missing (missing) PDUs, and PDUs with uncertain sending status.

Correspondingly, after receiving the first complete data packet, the base station determines that the corresponding data packet has not been received according to the first sequence number. At this time, the base station can analyze the received complete data packet, obtain and store the context information reset by the user terminal after obtaining the PDCP reconstruction request, so that the new compressed packet sent by the user terminal can be subsequently decompressed according to the context information to ensure normal data transmission.

In the embodiment of the present disclosure, when there is a preset data packet that has not been successfully sent, and the preset data packet is not a lost data packet (such as a packet that confirms reception failure or NACK), the user terminal may also send a third complete data packet to the base station in an existing manner, wherein the third complete data packet includes uncompressed header information and a third sequence number in the preset data packet.

That is to say, in the present disclosure, when the existing communication protocol remains unchanged, since the third complete data packet has a preset third sequence number of the data packet, that is, the sequence number used before reconstruction, if the user terminal only sends the third complete data packet, after receiving the third complete data packet, the base station can determine that the data packet corresponding to the third sequence number has been received according to the third sequence number in the third complete data packet, and the base station may directly delete the third complete data packet, resulting in failure to obtain and/or store valid (or new) context information. Therefore, in order to avoid the above problems, the user terminal may also send at least one first complete data packet to the base station, wherein the first complete data packet includes any sequence number that the base station has not received in the bearer, that is, the first sequence number, so that after receiving the first complete data packet, the base station can determine that the corresponding data packet has not been received according to the first sequence number. Perform decompression processing to ensure normal data transmission.

As an example, the sequence number is SN, and SN is an example of sequential generation. When the transmission mode of the current bearer is confirmation mode, the user terminal determines that the last SN contained in the PDCP PDU sent to the base station is SN=20, and the PDCP PDUs with SNs of 15, 17, 18, and 20 have not been successfully transmitted (for example, it can be determined according to the PDCP status report), and drb-ContinueROHC is not configured. Then the user terminal resets the header compression context information (new or valid context information), reset the header compression state, and use the new context information to resend PDCP PDUs with SNs of 15, 17, 18, 19, and 20 (the SN numbers are still the original 15, 17, 18, and 20). After the user terminal uses SN=21 (first sequence number) to send a new complete data packet containing new context information and a complete packet header, the user terminal then sends a compressed packet.

It should be noted that when the preset data packet is a lost data packet, the sequence number corresponding to the lost data packet has not been received by the base station, but is a sequence number used or sent by the user terminal. At this time, the first sequence number in the first complete data packet sent by the user terminal to the base station may specifically be the third sequence number in the preset data packet.

As another example, when the transmission mode of the current bearer is the confirmation mode, when the user terminal receives the PDCP re-establishment instruction, it determines that the PDU with the SN of 19 among the PDCP PDUs already sent to the base station is missing, and drb-ContinueROHC is not configured, then the user terminal resets the header compression context information (new or valid context information), resets the header compression state, and uses the new context information to resend the PDCP PDU with the SN of 19. After the user terminal uses SN=19 (the third sequence number) to send a new complete data packet containing new context information and a complete packet header, the user terminal then sends a compressed packet.

As another example, when the transmission mode of the current bearer is confirmation mode, when the user terminal receives the PDCP re-establishment instruction, it determines that the last SN contained in the PDCP PDU sent to the base station is SN=20, and the PDCP PDU with SN 15, 17, 18, and 20 is not successfully transmitted, and the PDU with SN is 19 is missing, and drb-ContinueROHC is not configured, then the user terminal resets the header compression context information (new or valid context information), resets the header compression state, and uses the new The context information resends PDCP PDUs with SNs of 15, 17, 18, 19, and 20 (the SN numbers are still the original 15, 17, 18, and 20). After the user terminal uses SN=19 (third sequence number) and/or SN=21 (first sequence number) to send a new complete data packet containing new context information and a complete packet header, the user terminal then sends a compressed packet.

Further, in order to ensure that the base station obtains the corresponding context information, there may be multiple first complete data packets, and the first sequence numbers included in each first complete data packet may be different. For example, a certain SN that is not used by the user terminal and K SNs following the SN can be used, and each SN can be used as a first sequence number, so that the user terminal can send K+i first complete data packets to the base station, so that the base station can successfully receive the reset context information. That is, there may be multiple first complete data packets sent by the user terminal to the base station, and the first sequence numbers corresponding to each first complete data packet are different. When the user terminal sends each first complete data packet to the base station, the base station can determine according to the first complete data packet that the first sequence number in the first complete data packet is a sequence number that has not been received in the current bearer. Therefore, valid context information in the first complete data packet will be saved, so that the base station can successfully receive the reset context information.

It should be noted that the number of the third complete data packets is the same as the number of preset data packets, that is, before reconstruction, several data packets failed to be sent, and after receiving the PDCP reconstruction instruction, the failed data packets can be resent to ensure the reliability and effectiveness of data transmission. Moreover, the reset context information may or may not be included in the third complete data packet. It should be understood that if the protocol of the base station is not modified, the base station will directly discard the data packet after receiving the data packet containing the repeated sequence number, so even if the third complete data packet contains the reset context information, it may be discarded. Therefore, in this disclosure, in order to reduce the number of bits of the data packet, the third complete data packet may not include the reset context information.

It should be noted that the reset context information may or may not be included in the third complete data packet. It should be understood that if the protocol of the base station is not modified, if the base station receives the data packet containing the third sequence number and determines that the SN corresponding to the data packet has not received it (such as the PDU of the corresponding SN is a lost data packet), then the base station will save the PDU and save the context information. At this time, the base station can obtain and store the context information reset by the user terminal after obtaining the PDCP re-establishment command, so that the compressed packet sent by the user terminal can be decompressed later according to the context information to ensure normal data transmission. Further, in order to ensure that the base station acquires the corresponding context information, the user terminal may also send the first complete data packet. The number of the first complete data packet is a non-negative integer.

In addition, the base station may send a feedback packet to the user terminal after saving the updated context information. After receiving the feedback packet, the user terminal can start to send the compressed packet.

In the Ethernet frame header compression processing method of the embodiment of the present disclosure, when the base station obtains the reconstruction request of the packet data convergence protocol, if the transmission mode of the current session is the confirmation mode and the configuration file meets the preset conditions, and the first sequence number in the first complete data packet obtained from the user terminal is a sequence number that the base station has not received in the current bearer, then the context information in the first complete data packet is saved, so as to decompress the new compressed packet according to the context information in the first complete data packet; Sent to the base station after the reconstruction command. In the present disclosure, it can be ensured that the base station successfully obtains the reset context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

In order to realize the above-mentioned embodiments, the present disclosure also proposes a method for compressing and processing Ethernet frame headers.

FIG. 4 is a schematic flowchart of a method for compressing and processing Ethernet frame headers provided by Embodiment 3 of the present disclosure.

As shown in Figure 4, the Ethernet frame header compression processing method may include the following steps:

The Ethernet frame header compression processing method in the embodiment of the present disclosure can be applied to a base station, and the base station can specifically be a decompression end, that is, a PDCP receiving entity. Correspondingly, the sending end (compressing end, PDCP sending entity) is a user terminal.

Of course, in another implementation manner, the Ethernet frame header compression process can be applied to the user terminal, and the base station is the compression end, that is, the PDCP sending entity. Correspondingly, the receiving end (decompression end, PDCP receiving entity) is a user terminal.

The following mainly takes the decompression end of the Ethernet frame header compression processing as the base station for description. The method in which the decompression end is a user terminal is similar.

Step 301, when the packet data convergence protocol reconstruction request is obtained, if the transmission mode of the current session is confirmation mode, and the configuration file satisfies the preset condition, and the second sequence number in the second complete data packet obtained from the user terminal is a sequence number that the base station has received in the current bearer, then save the context information in the second complete data packet.

In the embodiment of the present disclosure, the transmission mode may include a transparent mode (TM), an unacknowledged mode (UM) and an acknowledged mode (AM).

In the embodiment of the present disclosure, the configuration file meeting the preset condition may include: no value is assigned to the preset configuration parameter in the configuration file, or the value assigned to the preset configuration parameter in the configuration file is false. For example, the preset configuration parameter may be drb-ContinueROHC, and when drb-ContinueROHC is not assigned a value, or when drb-ContinueROHC is assigned a value of false, it is determined that the configuration parameter meets the preset condition.

In this embodiment of the present disclosure, the second serial number may be a serial number (SN), or the second serial number may also be a count (COUNT). Among them, COUNT occupies 32 bits and consists of HFN and PDCP SN, and SN is the low bit of COUNT.

In the embodiment of the present disclosure, when the base station receives a PDCP re-establishment request, or when high-level instructions indicate PDCP re-establishment, it can judge whether the transmission mode of the current session is confirmed mode, the configuration file meets the preset conditions, and the second sequence number in the second complete data packet obtained from the user terminal is a sequence number that the base station has received in the current bearer or a duplicate sequence number (such as a duplicate SN). If these three conditions are met at the same time, the base station can save the context information in the second complete data packet. The context information is decompressed. Wherein, the third complete data packet corresponding to the second sequence number is received by the base station after receiving the PDCP reconstruction request from the upper layer, or the second complete data packet is received again from the lower layer due to PDCP.

That is to say, the protocol of the base station (that is, the receiving end or the decompression end) can be modified. When receiving the PDCP reconstruction request, if the sequence number in the complete data packet received by the base station is received before, the context information in the complete data packet is saved, so that the subsequent base station can decompress the compressed packet sent by the user terminal according to the context information to ensure normal data transmission.

In addition, the base station can send a feedback packet to the user terminal after saving the context information. After receiving the feedback packet, the user terminal can start to send the compressed packet.

In the Ethernet frame header compression processing method of the embodiment of the present disclosure, when the base station obtains the packet data convergence protocol reconstruction request, if the transmission mode of the current session is the confirmation mode, and the configuration file meets the preset conditions, and the second sequence number in the second complete data packet obtained from the user terminal is the sequence number that the base station has received in the current bearer, then the context information in the second complete data packet is saved. In this way, it can be ensured that the base station successfully obtains the reset context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

As a possible implementation, the base station saves the context information in the second complete data packet, or the base station uses the context information to successfully decompress the received compressed packet, or, when the base station has valid context information, the base station can also send a feedback packet to the user terminal, where the feedback packet is used to indicate that the context information in the second complete data packet has been saved, or used to indicate that the base station has successfully decompressed the received compressed packet, or used to indicate that the base station has valid context information.

As a possible implementation manner, in order to prevent the base station from repeatedly storing the same context information, before the base station saves the context information in the second complete data packet, it needs to be determined that the base station does not store the context information in the second complete data packet. That is to say, it is determined that the context information stored in the base station is stored before the PDCP re-establishment request is obtained, so that when the context information in the second complete data packet is stored, it can be determined that there is no repeated context information in the stored data.

As a possible implementation, after the base station stores the context information in the second complete data packet, if the sequence number in the complete data packet sent by the user terminal to the base station, such as SN, is the sequence number that the base station has received in the current bearer, the complete data packet is discarded. Specifically, after the base station stores the context information in the second complete data packet, if the third sequence number in the third complete data packet newly acquired by the base station from the user terminal is the sequence number that the base station has received in the current bearer, the third complete data packet is discarded.

In the embodiment of the present disclosure, after the base station stores the context information in the second complete data packet, it can use an existing protocol to receive and store the data. Specifically, when the complete data packet received by the base station includes the previously received sequence number, the data packet may be discarded. That is to say, in the present disclosure, if the sequence number in the subsequent data packet received by the base station is the sequence number that the base station has already received in the current bearer, the base station can use the existing protocol to discard the data packet.

As a possible implementation, in order to prevent the base station from repeatedly storing the same context information, before the base station saves the context information in the second complete data packet, it needs to be determined that the base station has not sent a feedback packet to the user terminal after obtaining the PDCP reconstruction request, wherein the feedback packet is used to indicate that the base station successfully decompresses the obtained data packet, or that the base station has reset context information, or that the reset context information has been saved.

As an example, the processing flow of the uplink data packet is used as an example (the compression end is the user terminal, and the decompression end is the base station), and the processing of the downlink data packet (the compression end is the base station, and the decompression end is the user terminal) is similar, and will not be repeated here.

1. The first DRB can be configured with Ethernet header compression parameters on the network side, wherein drb-ContinueROHC is not configured or its value is false. Specifically, the message is indicated to the user terminal through a dedicated RRC, such as PDCP-config IE.

2. The user terminal performs header compression processing according to the configuration information during subsequent sending. Specifically, the user terminal sends a complete data packet including complete packet header information and context information, and sends a compressed packet to the base station after receiving a feedback packet or sending N packets containing complete data packets.

3. The base station receives the PDCP PDU from the user terminal, including complete data packets and compressed packets.

4. When the user terminal (UE) receives a PDCP re-establishment request from a higher layer (such as the RRC layer), for example, when the UE RRC receives a re-establishment request from the base station, when the UE RRC requires the UE PDCP layer to perform PDCP re-establishment, the transmission mode of the current bearer is confirmed mode, the user terminal resets the context information, resets the header compression state, and sends the PDCP PDU according to the new context information.

5. When the PDCP re-establishment request is received or the high layer instructs the PDCP re-establishment, the base station receives the data packet sent by the user terminal, acquires new context information and saves it. Specifically, after the base station receives the PDCP re-establishment request, the transmission mode of the current bearer is the confirmation mode, and when the SN corresponding to the received PDCP PDU is a duplicate SN or an SN that has been received before re-establishment, at least one of the following operations is performed:

1) Decompressing the PDCP PDU;

2) Save valid (new) context information. Specifically, if the PDCP PDU is a complete data packet, and/or, when there is complete header information and context information in the PDCP PDU, the base station considers the context contained therein as a valid (new) context and/or saves the context;

3) Sending a feedback packet to the user terminal, where the feedback packet is used to indicate that valid context information has been successfully established and/or saved.

Otherwise, the user terminal will adopt the existing protocol, that is, when the SN in the PDCP PDU is a received SN, the base station discards the PDCP PDU.

Afterwards, the base station can perform decompression processing according to the saved new context information. In particular, when it is necessary to send a feedback packet, the feedback packet sent by the base station is used to indicate that the base station has received and/or saved valid context information. After receiving the feedback packet, the user terminal can send the compressed packet.

For example, the transmission mode of the current session is confirmation mode. After receiving the PDCP re-establishment request, the base station receives a PDCP PDU with SN 10, and the data packet corresponding to the SN has been received before. Since drb-ContinueROHC is not configured, and the base station has no valid context at this time, the base station decompresses the PDU with SN 10. When it is determined that this PDU is a complete data packet, or that there is complete header information and context information in this PDCP PDU, the base station considers the context contained therein as valid (new) context information, and the base station will save the context for subsequent decompression when receiving compressed packets. In addition, if a PDU with an SN of 11 is subsequently received, and the data packet corresponding to the SN has been received before, the base station will use the existing protocol to discard the data packet because there is already valid context information at this time.

In order to realize the above embodiments, the present disclosure further proposes an Ethernet frame header compression processing device.

FIG. 5 is a schematic structural diagram of an Ethernet frame header compression processing device provided by Embodiment 4 of the present disclosure.

The Ethernet frame header compression processing apparatus in the embodiment of the present disclosure may be set in a user terminal, and the user terminal may specifically be a compression end, that is, a PDCP sending entity. Correspondingly, the receiving end (decompression end, PDCP receiving entity) is a base station.

Of course, in another implementation manner, the Ethernet frame header compression processing device may be set at the base station side, that is, the base station is the compression end, that is, the PDCP sending entity. Correspondingly, the receiving end (decompression end, PDCP receiving entity) is a user terminal.

The following description mainly takes the compression end where the Ethernet frame header compression processing device is set as the user terminal for description. A device whose compression end is a base station is similar.

As shown in FIG. 5 , the Ethernet frame header compression processing apparatus includes a sending module 501 .

Wherein, the sending module 501 is configured to send at least one first complete data packet to the base station when the packet data convergence protocol reconstruction request is obtained, if the transmission mode of the current bearer is the confirmation mode, and the configuration file satisfies the preset condition, and the current bearer includes a preset data packet.

Wherein, each first complete data packet includes: context information, uncompressed packet header information, and a first sequence number, wherein the context information is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction request, and the first sequence number is any sequence number that the base station has not received in the bearer.

As a possible implementation, the preset data packet is a data packet that the user terminal failed to send before obtaining the reconstruction instruction, or a data packet that the user terminal did not obtain a sending confirmation or an unconfirmed sending status when obtaining the reconstruction instruction, or a data packet that was lost when the user terminal obtained the reconstruction instruction or before obtaining the reconstruction instruction.

As a possible implementation manner, the configuration file satisfies a preset condition, including: no value is assigned to a preset configuration parameter in the configuration file; or, a value is assigned to a preset configuration parameter in the configuration file.

As a possible implementation, the sending module 401 is further configured to send a compressed packet to the base station if the feedback packet sent by the base station is obtained, wherein the compressed packet includes: context information, and the context information is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction request; wherein, the feedback packet is sent by the base station after determining to receive a complete data packet containing the context information; or, the feedback packet is sent by the base station after saving the context information.

As a possible implementation, the sending module 401 is further configured to send a compressed packet to the base station after the first preset time interval, wherein the compressed packet includes: context information, and the context information is context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction request.

As a possible implementation, after sending the packet data convergence protocol reconstruction complete message at the second preset time interval, send a compressed packet to the base station, wherein the compressed packet includes context information, and the context information is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction request.

As a possible implementation manner, the first serial number; or, the first serial number is a count.

It should be noted that the explanations of the Ethernet frame header compression processing method described above in the embodiments of FIGS. 1-2 are also applicable to the Ethernet frame header compression processing device. The implementation principles are similar and will not be repeated here.

The Ethernet frame header compression processing device in the embodiment of the present disclosure, when the user terminal obtains the packet data convergence protocol reconstruction request, if the transmission mode of the current bearer is the confirmation mode, and the configuration file meets the preset conditions, and the current bearer includes preset data packets, at least one first complete data packet is sent to the base station; wherein, each first complete data packet includes: context information, uncompressed packet header information, and a first sequence number, wherein the context information is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction request, and the first sequence number is the user terminal in Any sequence number not used in the bearer session. In the present disclosure, the user terminal sends at least one first complete data packet to the base station. Since the first complete data packet includes a sequence number that the base station has not received in the bearer, it can be ensured that the base station successfully obtains the reset context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

In order to realize the above embodiments, the present disclosure further proposes an Ethernet frame header compression processing device.

FIG. 6 is a schematic structural diagram of an Ethernet frame header compression processing device provided by Embodiment 5 of the present disclosure.

The Ethernet frame header compression processing apparatus in the embodiment of the present disclosure may be set in a base station, and the base station may specifically be a decompression end, that is, a PDCP receiving entity. Correspondingly, the sending end (compressing end, PDCP sending entity) is a user terminal.

Of course, in another implementation manner, the Ethernet frame header compression processing device may be set at the user terminal side, and the base station is the compression end, that is, the PDCP sending entity. Correspondingly, the receiving end (decompression end, PDCP receiving entity) is a user terminal.

The following mainly takes the decompression end where the Ethernet frame header compression processing device is set as the base station for description. The device in which the decompression end is a user terminal is similar.

As shown in FIG. 6 , the Ethernet frame header compression processing device includes: a saving module 601 .

Save module 601 to obtain the request for reconstruction of the group data convergence agreement, if the current session transmission mode is the confirmation mode, and the configuration file meets the preset conditions, and the first order number in the first complete data packet obtained from the user terminal is the unpaid number in the current carrying. The new compressed package is decompressed; among them, the first complete data packet sends the user terminal after obtaining the reconstruction instruction of the group data convergence agreement.

It should be noted that the above-mentioned explanation of the Ethernet frame header compression processing method in the embodiment of FIG. 3 is also applicable to the Ethernet frame header compression processing device, and its implementation principle is similar, so details are not repeated here.

The Ethernet frame header compression processing device in the embodiment of the present disclosure, when the base station obtains the reconstruction request of the packet data convergence protocol, if the transmission mode of the current session is the confirmation mode and the configuration file meets the preset conditions, and the first sequence number in the first complete data packet obtained from the user terminal is a sequence number that the base station has not received in the current bearer, then the context information in the first complete data packet is saved, so as to decompress the new compressed packet according to the context information in the first complete data packet; Sent to the base station after the reconstruction command. In the present disclosure, it can be ensured that the base station successfully obtains the reset context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal to ensure normal data transmission.

In order to realize the above embodiments, the present disclosure further proposes an Ethernet frame header compression processing device.

FIG. 7 is a schematic structural diagram of an Ethernet frame header compression processing device provided by Embodiment 6 of the present disclosure.

The Ethernet frame header compression processing apparatus in the embodiment of the present disclosure may be set in a base station, and the base station may specifically be a decompression end, that is, a PDCP receiving entity. Correspondingly, the sending end (compressing end, PDCP sending entity) is a user terminal.

Of course, in another implementation manner, the Ethernet frame header compression processing device may be set at the user terminal side, and the base station is the compression end, that is, the PDCP sending entity. Correspondingly, the receiving end (decompression end, PDCP receiving entity) is a user terminal.

The following mainly takes the decompression end where the Ethernet frame header compression processing device is set as the base station for description. The device in which the decompression end is a user terminal is similar.

As shown in FIG. 7 , the Ethernet frame header compression processing device includes: a saving module 701 .

Wherein, the saving module 701 is configured to save the context information in the second complete data packet when the packet data convergence protocol reconstruction request is obtained, if the transmission mode of the current session is the confirmation mode, and the configuration file satisfies the preset condition, and the second sequence number in the second complete data packet obtained from the user terminal is a sequence number that the base station has received in the current bearer.

As a possible implementation manner, the configuration file satisfies a preset condition, including: no value is assigned to a preset configuration parameter in the configuration file; or, a value is assigned to a preset configuration parameter in the configuration file.

In a possible implementation manner of an embodiment of the present disclosure, referring to FIG. 8, on the basis of the embodiment shown in FIG. 7, the Ethernet frame header compression processing method may further include:

The sending module 702 is configured to send a feedback packet to the user terminal, where the feedback packet is used to indicate that the context information in the second complete data packet has been saved.

A determining module 703, configured to determine that the context information in the second complete data packet is not stored in the base station.

The discarding module 704 is configured to discard the third complete data packet if the third sequence number in the third complete data packet newly acquired from the user terminal is the sequence number that the base station has received in the current bearer.

As a possible implementation, the determining module 703 is further configured to determine that the base station does not send a feedback packet to the user terminal after obtaining the packet data convergence protocol reconstruction request, and the feedback packet is used to indicate that the base station successfully decompresses the obtained data packet, or that the base station has reset context information, or that the reset context information has been saved.

It should be noted that the above-mentioned explanations of the method for compressing and processing Ethernet frame headers in the embodiment of FIG. 4 are also applicable to the device for compressing and processing Ethernet frame headers. The implementation principles are similar and will not be repeated here.

The Ethernet frame header compression processing device of the embodiment of the present disclosure, when the base station obtains the packet data convergence protocol reconstruction request, if the transmission mode of the current session is the confirmation mode, and the configuration file meets the preset conditions, and the second sequence number in the second complete data packet obtained from the user terminal is the sequence number that the base station has received in the current bearer, then the context information in the second complete data packet is saved. In this way, it can be ensured that the base station successfully obtains the context information, so that the base station can perform normal decompression processing on the compressed packet sent by the user terminal according to the context information, thereby ensuring normal data transmission.

In order to realize the above-mentioned embodiments, the present disclosure also proposes a user terminal, including: a memory, a processor, and a computer program stored in the memory and operable on the processor. When the processor executes the program, it implements the Ethernet frame header compression processing method proposed in the foregoing embodiments of FIGS. 1 to 2 of the present disclosure.

In order to implement the above embodiments, the present disclosure also proposes a base station, including: a memory, a processor, and a computer program stored in the memory and operable on the processor. When the processor executes the program, it implements the Ethernet frame packet header compression processing method as proposed in the aforementioned embodiment of FIG. 3 of the present disclosure.

In order to implement the above embodiments, the present disclosure also proposes another base station, including: a memory, a processor, and a computer program stored in the memory and operable on the processor. When the processor executes the program, it implements the Ethernet frame header compression processing method as proposed in the embodiment of FIG. 4 mentioned above in the present disclosure.

In order to realize the above-described embodiments, the present disclosure also proposes a computer-readable storage medium on which a computer program is stored. It is characterized in that, when the program is executed by a processor, it realizes the Ethernet frame header compression processing method proposed in the aforementioned embodiments of FIG. 1 to FIG.

In the description of this specification, descriptions referring to terms such as "one embodiment", "some embodiments", "example", "specific examples", or "some examples" mean that specific features, structures, materials or characteristics described in conjunction with this embodiment or example are included in at least one embodiment or example of the present disclosure. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the described specific features, structures, materials or characteristics may be combined in any suitable manner in any one or more embodiments or examples. In addition, those skilled in the art can combine and combine different embodiments or examples and features of different embodiments or examples described in this specification without conflicting with each other. In addition, the terms "first" and "second" are used for descriptive purposes only, and cannot be interpreted as indicating or implying relative importance or implicitly specifying the quantity of indicated technical features. Thus, the features defined as "first" and "second" may explicitly or implicitly include at least one of these features. In the description of the present disclosure, "plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

Any process or method descriptions in flowcharts or otherwise described herein may be understood to represent modules, segments or portions of code comprising one or more executable instructions for implementing custom logical functions or steps of a process, and the scope of the preferred embodiments of the present disclosure includes additional implementations in which functions may be performed out of the order shown or discussed, including substantially concurrently or in reverse order as the functions involved are understood by those skilled in the art to which embodiments of the present disclosure pertain.

The logic and/or steps represented in the flowcharts or otherwise described herein, for example, may be considered to be a sequenced listing of executable instructions for implementing logical functions, and may be embodied in any computer-readable medium for use by or in conjunction with an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, apparatus, or device and execute instructions). For purposes of this specification, a "computer-readable medium" may be any device that can contain, store, communicate, propagate, or transmit a program for use in or in conjunction with an instruction execution system, device, or device. More specific examples (non-exhaustive list) of computer-readable media include the following: electrical connections with one or more wires (electronic devices), portable computer disk cases (magnetic devices), random access memory (RAM), read-only memory, erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc ROMs. In addition, the computer readable medium may even be paper or other suitable medium on which the program can be printed, since the program can be obtained electronically, for example, by optical scanning of the paper or other medium, followed by editing, interpretation, or other suitable processing as necessary, and then stored in the computer memory.

It should be understood that various parts of the present disclosure may be implemented in hardware, software, firmware or a combination thereof. In the embodiments described above, various steps or methods may be implemented by software or firmware stored in memory and executed by a suitable instruction execution system. For example, if it is implemented by hardware as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit with logic gate circuits for implementing logic functions on data signals, an application-specific integrated circuit with suitable combinational logic gate circuits, programmable gate arrays, field programmable gate arrays, etc. Those of ordinary skill in the art can understand that all or part of the steps carried by the methods of the above embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one of the steps of the method embodiments or a combination thereof.

In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing module, or each unit may physically exist separately, or two or more units may be integrated into one module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software function modules. If the integrated modules are realized in the form of software function modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. The storage medium mentioned above may be a read-only memory, a magnetic disk or an optical disk, and the like. Although the embodiments of the present disclosure have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limiting the present disclosure, and those skilled in the art can make changes, modifications, replacements and modifications to the above embodiments within the scope of the present disclosure.

Claims (13)

1. A method for compressing the header of an Ethernet frame, applied to a user terminal, is characterized in that, comprising: When the packet data convergence protocol reconstruction instruction is acquired, if the transmission mode of the current bearer is the confirmation mode, and the configuration file satisfies the preset condition, and the current bearer includes the preset data packet, then send at least one first complete data packet to the base station; Wherein, each first complete data packet includes: context information, uncompressed packet header information, and a first sequence number, wherein the context information is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction, and the first sequence number is any sequence number that has not been received by the base station in the bearer; wherein the first sequence number includes a sequence number that has not been used by the user terminal; Wherein, when the at least one first complete data packet includes two or more first complete data packets, the first sequence numbers included in each first complete data packet are different. 2. The method of claim 1, wherein The preset data packet is a data packet that the user terminal failed to send before obtaining the reconstruction instruction, or a data packet that the user terminal did not obtain a transmission success confirmation or an unconfirmed transmission status when obtaining the reconstruction instruction, or a data packet that was lost when the user terminal obtained the reconstruction instruction or before obtaining the reconstruction instruction. 3. The method according to claim 1, wherein the configuration file satisfies preset conditions, including: The preset configuration parameters in the configuration file are not assigned; or, The preset configuration parameter in the configuration file is assigned a value of false. 4. The method according to claim 1, wherein, after sending the at least one first complete data packet to the base station, further comprising: If the feedback packet sent by the base station is acquired, a compressed packet is sent to the base station, wherein the compressed packet includes: context information, the context information is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction; Wherein, the feedback packet is sent by the base station after determining to receive a complete data packet including context information; or, the feedback packet is sent by the base station after saving the context information. 5. The method according to claim 1, further comprising: After the first preset time interval, a compressed packet is sent to the base station, wherein the compressed packet includes: context information, the context information is the context information reset by the user terminal after acquiring the packet data convergence protocol reconstruction instruction. 6. The method according to any one of claims 1-5, wherein after sending the at least one first complete data packet to the base station, further comprising: After sending the packet data convergence protocol reconstruction completion message for a second preset time interval, sending a compressed packet to the base station, wherein the compressed packet includes context information, and the context information is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction. 7. The method according to any one of claims 1-5, wherein the first serial number is a serial number; Alternatively, the first sequence number is a count. 8. A method for compressing the header of an Ethernet frame, applied to a base station, is characterized in that, comprising: When the packet data convergence protocol reconstruction request is obtained, if the transmission mode of the current session is confirmation mode, and the configuration file satisfies the preset condition, and the first sequence number in at least one first complete data packet obtained from the user terminal is a sequence number that has not been received by the base station in the current bearer, then saving the context information in the first complete data packet, so as to decompress the new compressed packet according to the context information in the first complete data packet; Wherein, the at least one first complete data packet is sent by the user terminal to the base station after obtaining the packet data convergence protocol reconstruction instruction, and the first sequence number includes a sequence number that has not been used by the user terminal; Wherein, when the at least one first complete data packet includes two or more first complete data packets, the first sequence numbers included in each first complete data packet are different. 9. A device for compressing and processing Ethernet frame headers, which is arranged on a user terminal, is characterized in that, comprising: The sending module is configured to send at least one first complete data packet to the base station if the transmission mode of the current bearer is an acknowledgment mode, and the configuration file satisfies preset conditions, and the current bearer includes a preset data packet when the packet data convergence protocol reconstruction instruction is acquired; Wherein, each first complete data packet includes: context information, uncompressed packet header information, and a first sequence number, wherein the context information is the context information reset by the user terminal after obtaining the packet data convergence protocol reconstruction instruction, and the first sequence number is any sequence number that has not been received by the base station in the bearer; wherein the first sequence number includes a sequence number that has not been used by the user terminal; Wherein, when the at least one first complete data packet includes two or more first complete data packets, the first sequence numbers included in each first complete data packet are different. 10. A device for compressing and processing Ethernet frame headers, which is arranged at a base station, is characterized in that it comprises: The saving module is configured to save the context information in the first complete data packet, so as to decompress the new compressed packet according to the context information in the first complete data packet, if the transmission mode of the current session is confirmation mode and the configuration file meets the preset conditions, and the first sequence number in at least one first complete data packet obtained from the user terminal is a sequence number that has not been received by the base station in the current bearer when the packet data convergence protocol reconstruction request is obtained; Wherein, the at least one first complete data packet is sent by the user terminal to the base station after obtaining the packet data convergence protocol reconstruction instruction; the first sequence number includes a sequence number that has not been used by the user terminal; Wherein, when the at least one first complete data packet includes two or more first complete data packets, the first sequence numbers included in each first complete data packet are different. 11. A user terminal, comprising: a memory, a processor and a computer program stored on the memory and operable on the processor, when the processor executes the program, it realizes the Ethernet frame header compression processing method according to any one of claims 1-7. 12. A base station, comprising: a memory, a processor, and a computer program stored on the memory and operable on the processor, when the processor executes the program, the Ethernet frame header compression processing method as claimed in claim 8 is realized. 13. A computer-readable storage medium, on which a computer program is stored, it is characterized in that, when the program is executed by a processor, it realizes the Ethernet frame packet header compression processing method as described in any one of claims 1-7, or realizes the Ethernet frame packet header compression processing method as claimed in claim 8.