CN111800371B

CN111800371B - Data processing method, sending end and receiving end

Info

Publication number: CN111800371B
Application number: CN201910606119.6A
Authority: CN
Inventors: 张艳霞; 吴昱民
Original assignee: Vivo Mobile Communication Co Ltd
Current assignee: Vivo Mobile Communication Co Ltd
Priority date: 2019-07-05
Filing date: 2019-07-05
Publication date: 2022-10-28
Anticipated expiration: 2039-07-05
Also published as: CN111800371A

Abstract

The invention provides a data processing method, a sending end and a receiving end, wherein the method corresponding to the sending end comprises the following steps: receiving a first data packet, wherein the first data packet comprises an Ethernet frame header and an IP series packet header; compressing at least the Ethernet frame header in the first data packet to obtain a second data packet, wherein the second data packet at least comprises a first compressed packet header; and the first compressed packet header is a compressed packet header obtained by compressing the Ethernet frame header. In the invention, the sending end can at least compress the Ethernet frame header in the Ethernet frame data, and the receiving end can decompress the compressed Ethernet frame data, so that the required transmission resources are reduced when the Ethernet frame data is transmitted between the sending end and the receiving end, thereby reducing the transmission resource overhead of the Ethernet frame data.

Description

Data processing method, sending end and receiving end

Technical Field

The present invention relates to the field of communications technologies, and in particular, to a data processing method, a transmitting end, and a receiving end.

Background

In industrial environments, data transmission typically employs ethernet encapsulation technology, and data transmitted over ethernet links is referred to as ethernet frames. The Ethernet frame includes an Ethernet header (Ethernet header) and an Ethernet payload (Ethernet payload) carrying valid data, where the valid data in the Ethernet payload may be IP-type data, and such data includes an IP-series header (e.g., an IP (Internet Protocol) header and a TCP (Transmission Control Protocol) header). In some cases, the length occupied by the header in the ethernet frame data is large, which causes a problem that the ethernet frame data transmission has a large resource overhead due to the large length occupied by the header.

Disclosure of Invention

Embodiments of the present invention provide a data processing method, a sending end, and a receiving end, so as to solve a problem that resource overhead is large due to a large occupied length of a header when ethernet frame data is transmitted.

In order to solve the technical problem, the invention is realized as follows:

in a first aspect, an embodiment of the present invention provides a data processing method applied to a sending end, where the method includes:

receiving a first data packet, wherein the first data packet comprises an Ethernet frame header and an IP series packet header;

compressing the Ethernet frame header in the first data packet to obtain a second data packet, wherein the second data packet at least comprises a first compressed packet header;

and the first compressed packet header is obtained by compressing the ethernet frame header.

In a second aspect, an embodiment of the present invention provides a data processing method, which is applied to a receiving end, where the method includes:

receiving a first data packet, wherein the first data packet at least comprises a first compressed packet header;

decompressing the compressed packet header in the first data packet to obtain a second data packet comprising an Ethernet frame header and an IP series packet header;

the first compressed packet header is obtained by compressing the ethernet frame header.

In a third aspect, an embodiment of the present invention provides a sending end, including:

a receiving module, configured to receive a first data packet, where the first data packet includes an ethernet header and an IP-series header;

a compressing module, configured to compress at least the ethernet header in the first data packet to obtain a second data packet, where the second data packet at least includes a first compressed packet header;

In a fourth aspect, an embodiment of the present invention provides a receiving end, including:

a receiving module, configured to receive a first data packet, where the first data packet at least includes a first compressed packet header;

a decompression module, configured to decompress the compressed packet header in the first data packet to obtain a second data packet including an ethernet frame header and an IP-series packet header;

the first compressed packet header is obtained by compressing an ethernet header.

In a fifth aspect, an embodiment of the present invention provides another sending end, including: the data processing method comprises a memory, a processor and a computer program stored on the memory and capable of running on the processor, wherein the computer program realizes the steps in the data processing method provided by the first aspect of the embodiment of the invention when being executed by the processor.

In a sixth aspect, an embodiment of the present invention provides another receiving end, including: a memory, a processor and a computer program stored on the memory and executable on the processor, the computer program, when executed by the processor, implementing the steps in the data processing method provided by the second aspect of the embodiments of the present invention.

In a seventh aspect, an embodiment of the present invention provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the computer program implements the steps in the data processing method provided in the first aspect of the embodiment of the present invention.

In an eighth aspect, the embodiment of the present invention provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and the computer program, when executed by a processor, implements the steps in the data processing method provided in the second aspect of the embodiment of the present invention.

In the embodiment of the invention, the sending end can at least compress the Ethernet frame header in the Ethernet frame data, and the receiving end can decompress the compressed Ethernet frame data, so that the required transmission resources are reduced when the Ethernet frame data is transmitted between the sending end and the receiving end, and the transmission resource overhead of the Ethernet frame data can be reduced.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments of the present invention will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive exercise.

Fig. 1 is a system diagram of a network system according to an embodiment of the present invention;

fig. 2 is a flowchart of a data processing method applied to a network system according to an embodiment of the present invention;

fig. 3 is a schematic structural diagram of ethernet frame data according to an embodiment of the present invention;

fig. 4 is a flowchart of a data processing method applied to a transmitting end according to an embodiment of the present invention;

FIG. 5 is a flow chart of a compression processing method according to an embodiment of the present invention;

FIG. 6 is a flow chart of another compression processing method according to an embodiment of the present invention;

fig. 7 is a flowchart of a data processing method applied to a receiving end according to an embodiment of the present invention;

fig. 8 is a flowchart of a decompression processing method according to an embodiment of the present invention;

fig. 9 is a flowchart of another decompression processing manner according to an embodiment of the present invention;

fig. 10 is a structural diagram of a transmitting end according to an embodiment of the present invention;

fig. 11 is a structural diagram of a receiving end according to an embodiment of the present invention;

fig. 12 is a hardware configuration diagram of a terminal according to an embodiment of the present invention;

fig. 13 is a hardware structure diagram of a network device according to an embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, not all, embodiments of the present invention. All other embodiments, which can be obtained by a person skilled in the art without inventive step based on the embodiments of the present invention, are within the scope of protection of the present invention.

The terms "comprises," "comprising," or any other variation thereof, in the description and claims of this application are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements explicitly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. Furthermore, the use of "and/or" in the specification and claims means that at least one of the connected objects, such as a and/or B, means that three cases, a alone, B alone, and both a and B, exist.

In the embodiments of the present invention, words such as "exemplary" or "for example" are used to mean serving as examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "e.g.," an embodiment of the present invention is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word "exemplary" or "such as" is intended to present concepts related in a concrete fashion.

Embodiments of the present invention are described below with reference to the accompanying drawings. The data processing method provided by the embodiment of the invention can be applied to a wireless communication system. The wireless communication system may be a 5G system, or an Evolved Long Term Evolution (lte) system, or a subsequent Evolved communication system.

Fig. 1 is a structural diagram of a network system according to an embodiment of the present invention, and as shown in fig. 1, the network system includes a terminal 11 and a network-side device 12. The terminal may be a mobile communication device, for example: the Mobile phone may be a Mobile phone, a Tablet Personal Computer (Tablet Personal Computer), a Laptop Computer (Laptop Computer), a Personal Digital Assistant (PDA), a Mobile Internet Device (MID), a Wearable Device (Wearable Device), or the like. The network side device may be a 5G network side device (e.g., a gNB, a 5G NR NB), or may be a 4G network side device (e.g., an eNB), or may be a 3G network side device (e.g., an NB), or a network side device in a subsequent evolved communication system, and so on.

During uplink transmission, the terminal 11 may serve as a sending end in the embodiment of the present invention, and the network side device 12 may serve as a receiving end in the embodiment of the present invention; during downlink transmission, the network side device 12 may serve as a sending end in the embodiment of the present invention, and the terminal 11 may serve as a receiving end in the embodiment of the present invention.

An embodiment of the present invention provides a data processing method applied to a network system shown in fig. 1, as shown in fig. 2, the method includes the following steps:

step 201: a sending end receives a first data packet, wherein the first data packet comprises an Ethernet frame header and an IP series packet header;

step 202: a sending end at least compresses the Ethernet header in the first data packet to obtain a second data packet, wherein the second data packet at least comprises a first compressed packet header; the first compressed packet header is obtained by compressing the Ethernet frame header;

step 203: the sending end sends the second data packet to a receiving end;

step 204: the receiving end receives the second data packet;

step 205: and the receiving end decompresses the compressed packet header in the second data packet to obtain a third data packet comprising the Ethernet frame header and the IP series packet header.

In LTE (Long Term Evolution) and NR (New Radio), a PDCP (Packet Data Convergence Protocol) sublayer may perform header compression and decompression functions. Therefore, in the embodiment of the present invention, the sending end may be a sending PDCP entity, and the receiving end may be a receiving PDCP entity.

In the embodiment of the present invention, any data packet (for example, the above-mentioned first data packet, second data packet, and the like) involved in the data processing process by the data processing method may be understood as ethernet frame data because the data packet includes an ethernet frame header or a compressed ethernet frame header. The data field carried by the ethernet frame data may be IP type data or non-IP (non-IP) type data. Fig. 3 is a schematic diagram of the structure of ethernet frame data when the data field of the ethernet frame data is IP type data.

The first data packet received by the transmitting end contains an Ethernet frame, wherein the Ethernet frame contains an Ethernet header and an Ethernet payload. The Ethernet frame payload carries payload data (e.g., ethernet data field) and, in some cases, a padding field (Ethernet PAD field), and may be data that includes an IP-based packet header. The IP series packet header may be an IP series packet header, a TCP header, an RTP (Real Time Protocol) header, or the like.

The first Data packet may further include an SDAP (Service Data attachment Protocol) subheader. If the first packet includes the SDAP subheader, the sender may separate (or remove or skip) the SDAP subheader from the first packet before compressing the first packet. After compressing the first Data packet, the sending end may add the previously separated SDAP subheader to the header of the Data packet with the compressed header and add the PDCP subheader to obtain a second Data packet including the SDAP subheader, the PDCP subheader, the first compressed header, and a second compressed header, where the second Data packet is a PDCP PDU (Protocol Data Unit). After receiving the second data packet, the receiving end may also separate the SDAP subheader and the PDCP subheader from the second data packet before decompressing the second data packet, and then decompress the second data packet. After decompression processing, the receiving end adds the SDAP subheader to the header of the data packet which does not contain the compressed packet header.

It should be noted that, the embodiments of the present invention are to provide a technical solution for performing compression processing and decompression processing on ethernet frame data, and mainly show how to perform compression processing and decompression processing on an ethernet frame header and an IP series packet header in the ethernet frame data. Therefore, the related processing of other parts in the ethernet frame data can be implemented in combination with the existing scheme, and is not described with emphasis in the embodiment of the present invention.

Fig. 4 is a flowchart of a data processing method according to an embodiment of the present invention. As shown in fig. 4, the data processing method is applied to a transmitting end, and the method includes the following steps:

step 401: a first data packet is received, the first data packet including an ethernet header and an IP family header.

As described above, in the embodiment of the present invention, the sending end may be a PDCP entity, and the sending end may compress the received data packet. The first packet may be understood as ethernet frame data, and the sending PDCP entity receives the first packet from the upper layer, where the first packet may or may not include the SDAP subheader. If the first data packet contains the SDAP subheader, the sending end may separate the SDAP subheader from the first data packet before compressing the first data packet. Of course, the SDAP subheader may not be separated from the first packet, and the ethernet header or the IP-series header in the first packet may be directly compressed.

It should be noted that the SDAP subheader is separated from the first data packet, and it is also understood that the SDAP subheader is removed from the first data packet, or the SDAP subheader is removed from the first data packet. In the embodiments of the present invention, the "separating a from a packet" may be understood as "separating a from a packet", or "removing a from a packet", and a description thereof will not be repeated.

Step 402: and at least compressing the Ethernet frame header in the first data packet to obtain a second data packet, wherein the second data packet at least comprises a first compressed packet header.

After step 402, the sending end may send the second data packet to the receiving end, and after receiving the second data packet, the receiving end may decompress the second data packet to obtain a data packet that does not include the compressed packet header. A specific manner of transmitting the ethernet frame data from the transmitting end to the receiving end will be described in detail below.

In the embodiment of the invention, the sending end can at least compress the Ethernet frame header in the Ethernet frame data, so that the required transmission resources are reduced when the Ethernet frame data is transmitted between the sending end and the receiving end, and the transmission resource overhead of the Ethernet frame data can be reduced.

In the embodiment of the present invention, the manner of compressing the first data packet by the sending end includes multiple manners, and each compression manner is described below.

The first method is as follows: and the sending end respectively compresses the Ethernet frame header and the IP series packet header in the first data packet to obtain a second data packet comprising the first compressed packet header and the second compressed packet header. The first compressed packet header is obtained by compressing the ethernet header, and the second compressed packet header is obtained by compressing the IP-series packet header.

In the first mode, the sending end is configured with an ethernet Header Compression function and an IP-series Header Compression function at the same time, for example, the sending end is configured with an ethernet frame Compression entity (or referred to as an ethernet frame Compression module) and an ROHC (RObust Header Compression) entity (or referred to as an ROHC module) at the same time, wherein the sending end may compress the ethernet Header in the first data packet through the ethernet frame Compression entity, and the sending end may compress the IP-series Header in the first data packet through the ROHC entity.

In the first mode, the sending end respectively compresses the ethernet header and the IP-series header in the first data packet, and may include a parallel compression processing mode and a serial compression processing mode.

For the parallel compression processing method, the compressing the ethernet header and the IP-series header respectively to obtain the second data packet including the first compressed header and the second compressed header may include the following steps:

compressing the Ethernet frame header through an Ethernet frame compression entity to obtain a first sub-data packet comprising a first compression packet header;

compressing the IP series packet header through an ROHC entity to obtain a second sub-packet comprising a second compressed packet header;

and combining the first sub-data packet and the second sub-data packet to obtain a second data packet comprising a first compressed packet header and a second compressed packet header.

In the parallel compression processing mode, the sending end may send the ethernet header and the IP-series packet header in the first data packet to the ethernet frame compression entity and the ROCH entity, respectively, or extract the ethernet header part and the IP-series packet header part from the first data packet through the ethernet frame compression entity and the ROHC entity, respectively, to implement the parallel compression processing of the ethernet header and the IP-series packet header. Because of the parallel compression processing, after the ethernet frame compression entity and the ROCH entity are respectively compressed, a first sub packet and a second sub packet including respective compression packet headers are obtained, and therefore, after the ethernet frame compression entity and the ROCH entity are respectively compressed, the first sub packet and the second sub packet need to be combined to obtain a second data packet including the first compression packet header and the second compression packet header. Here, combining the first sub-packet and the second sub-packet may be understood as reorganizing data according to a specific format, for example, placing the first compressed packet header at the header position of the second compressed packet header.

Optionally, before the compressing the ethernet header and the IP-series header, the method further includes:

separating the first data packet into a third data packet and a fourth data packet, wherein the third data packet comprises an Ethernet header, and the fourth data packet comprises an IP series packet header;

compressing the ethernet header by the ethernet frame compression entity to obtain a first sub-packet including a first compressed header, comprising:

compressing the Ethernet frame header in the third sub-packet through an Ethernet frame compression entity to obtain a first sub-packet comprising a first compressed packet header;

compressing the IP series packet header through the ROHC entity to obtain a second sub-packet comprising a second compressed packet header, wherein the second sub-packet comprises:

and compressing the IP series packet header in the fourth sub-packet by the ROHC entity to obtain a second sub-packet comprising a second compressed packet header.

In this optional embodiment, the first packet is separated into the third sub packet and the fourth sub packet, so as to separate the ethernet header and the IP-series packet header in the first packet, so that the separated ethernet header is sent to the ethernet frame compression entity for compression, and the separated IP-series packet header is sent to the ROHC entity for compression.

Here, the first data packet is separated into a third sub data packet and a fourth sub data packet, which may also be understood as dividing the first data packet to obtain the third sub data packet and the fourth sub data packet, or segmenting the first data packet to obtain the third sub data packet and the fourth sub data packet.

It should be noted that the third sub-packet is not limited to include an Ethernet header, and the fourth sub-packet is not limited to include an IP-series header, for example, the fourth sub-packet may include valid data (e.g., ethernet data field) in the Ethernet frame payload, which includes the IP-series header, and may also include a padding field (Ethernet PAD field).

As shown in fig. 5, the first packet includes an ethernet Header (E-Header), an IP-series Header (e.g., IP), and a payload (payload). It should be noted that the load in fig. 5 is different from the ethernet frame load, and the ethernet frame load actually refers to data including an IP-series header; and the payload in fig. 5 is data that does not contain an IP-series header.

The sending end separates the first data packet into a third data packet and a fourth data packet, wherein the third data packet comprises an Ethernet header, and the fourth data packet comprises an IP series packet header and a load. The sending end sends the third sub-packet to an ethernet frame compression Entity (EHC), and the ethernet frame header is Compressed by the ethernet frame compression entity to obtain a first sub-packet, i.e., a Compressed ethernet frame header (Compressed E-header). Correspondingly, the sending end sends the fourth sub-packet to the ROHC entity, and the ROHC entity compresses the IP-series packet header in the fourth sub-packet to obtain a second sub-packet, where the second sub-packet includes a Compressed IP-series packet header (Compressed IP-header) and a payload. Then, the sending end combines the first sub-packet and the second sub-packet to obtain a second data packet comprising a compressed Ethernet header, a compressed IP series packet header and a load. Before sending the second data packet to the receiving end, the sending end may further add a PDCP subheader and an SDAP subheader (if any) to the header of the second data packet.

It should be noted that, in the parallel compression processing manner, the ethernet frame compression entity performs compression processing on the ethernet frame header, and the ROHC entity performs compression processing on the IP series packet header, which belong to the same time sequence, but the execution time may be synchronous or asynchronous.

For the serial compression processing method, two alternative serial compression processing methods may be included, which are described in detail below.

In the first serial compression processing mode, the compressing the ethernet header and the IP-series header respectively to obtain the second data packet including the first compressed header and the second compressed header may include the following steps:

compressing the Ethernet frame header in the first data packet through an Ethernet frame compression entity to obtain a third data packet comprising a first compression packet header and an IP series packet header;

and compressing the IP series packet header in the third data packet through the ROHC entity to obtain a second data packet comprising the first compressed packet header and the second compressed packet header.

In the first serial compression processing method, the ethernet header is compressed first, and then the IP-series header is compressed. Specifically, first, the first data packet is sent to an ethernet frame compression entity, and an ethernet header in the first data packet is compressed to obtain a third data packet including the first compressed packet header and an IP-series packet header. Then, the third data packet is sent to the ROHC entity in a whole, and the ROHC entity extracts the IP series packet header from the third data packet and compresses the IP series packet header; or, the third data packet is sent to the ROHC entity as a whole, and the ROHC entity skips over the first compressed packet header at the head of the third data packet and compresses the IP-series packet header; or separating the first compressed packet header from the third data packet, and sending the third data packet to the ROHC entity for compressing the IP-series packet header. Therefore, sequential serial compression processing of the Ethernet header and the IP series header is realized.

Optionally, the compressing, by the ROHC entity, the IP series packet header in the third data packet to obtain a second data packet including the first compressed packet header and the second compressed packet header includes:

separating the first compressed packet header from the third data packet to obtain a fourth data packet including an IP series packet header;

compressing the IP series packet header in the fourth data packet through an ROHC entity to obtain a fifth data packet comprising a second compressed packet header;

and adding the first compressed packet header to the header of the fifth data packet to obtain a second data packet comprising the first compressed packet header and the second compressed packet header.

In this optional embodiment, after separating the first compressed packet header from the third data packet, the IP-series packet header may be located at the header of the third data packet, so that the ROHC entity may directly compress the IP-series packet header.

As shown in fig. 6, the first packet includes an ethernet header, an IP-series header, and a payload.

It should be noted that, the load in fig. 6 is different from the ethernet frame load, and the ethernet frame load actually refers to data including an IP-series header; and the payload in fig. 6 is data that does not contain an IP-series header.

The sending end sends the first data packet to an Ethernet frame compression entity, and the Ethernet frame header in the first data packet is compressed by the Ethernet frame compression entity to obtain a third data packet comprising a compressed Ethernet frame header and an uncompressed IP series packet header. And the sending end separates the compressed Ethernet header from the third data packet to obtain a fourth data packet comprising the IP series header and the load. And the transmitting end transmits the fourth data packet to the ROHC entity, and the ROHC entity compresses the IP series packet header in the fourth data packet to obtain a fifth data packet comprising the compressed IP series packet header and the load. Then, the sending end adds the compressed ethernet header separated before the fifth packet header, and obtains a second packet including the compressed ethernet header, the compressed IP-series packet header, and the payload. Before sending the second data packet to the receiving end, the sending end may further add a PDCP subheader and an SDAP subheader (if any) to the header of the second data packet.

In the second serial compression, the compressing the ethernet header and the IP-series header respectively to obtain a second data packet including the first compressed header and the second compressed header may include the following steps:

compressing the IP series packet header in the first data packet through an ROHC entity to obtain a third data packet comprising an Ethernet frame header and a second compressed packet header;

and compressing the Ethernet frame header in the third data packet through an Ethernet frame compression entity to obtain a second data packet comprising a first compressed packet header and a second compressed packet header.

In the second serial compression processing method, the header of the IP series packet is compressed first, and then the header of the ethernet frame is compressed. Specifically, first, the first data packet is sent to the ROHC entity as a whole, and the ROHC entity extracts the IP-series packet header from the first data packet and compresses the IP-series packet header; or the first data packet is sent to the ROHC entity in its entirety, and the ROHC entity skips over the Ethernet header at the head of the first data packet and compresses the IP series packet header; or separating the Ethernet frame header from the first data packet, and sending the first data packet to the ROHC entity to compress the IP series packet header. Then, the third data packet including the ethernet header and the second compressed header is sent to the ethernet frame compression entity, and the ethernet header is compressed. Therefore, the sequential serial compression processing of the IP series packet header and the Ethernet frame header is realized.

Optionally, the ROHC entity compresses the IP-series packet header in the first data packet to obtain a third data packet including an ethernet header and a second compressed packet header, including:

separating an Ethernet frame header from the first data packet to obtain a fourth data packet comprising an IP series packet header;

and adding an Ethernet frame header to the header of the fifth data packet to obtain a third data packet comprising the Ethernet frame header and the second compressed packet header.

In this optional embodiment, the ethernet header is separated from the first packet, so that the IP-series packet header can be located at the header of the fourth packet, thereby facilitating the ROHC entity to directly compress the IP-series packet header. After the compression processing of the IP series packet headers, the previously separated Ethernet frame headers are added to the headers of the data packets to obtain a third data packet comprising the Ethernet frame headers and the second compressed packet headers, and the third data packet is integrally sent to an Ethernet frame compression entity. Because the ethernet header is located at the head of the third packet, the ethernet frame compression entity can directly compress the ethernet header in the third packet.

The main difference between the second serial compression processing manner and the first serial compression processing manner lies in the compression sequence of the ethernet header and the IP-series header.

The second method comprises the following steps: and compressing the Ethernet frame header of the first data packet to obtain a second data packet comprising the first compressed packet header and the IP series packet header.

In this way, the sending end is configured with an ethernet header compression function, but is not configured with an IP series header compression function, for example, the sending end is configured with only an ethernet frame compression entity (or referred to as an ethernet frame compression module), and the sending end can compress the ethernet header in the first data packet through the ethernet frame compression entity.

In addition, the compression method of the ethernet frame data does not exclude the method of compressing only the IP-series packet header, and thus the second packet including the ethernet header and the second compressed packet header can be obtained.

In this way, the sending end is configured with an IP-series header compression function, but not with an ethernet header compression function, for example, the sending end is configured with only an ROHC entity (or referred to as ROHC module), and the sending end can compress the IP-series header in the first data packet through the ROHC entity.

In the embodiments of the present invention, the sending end may configure the ethernet header compression function and the IP-series header compression function at the same time, and may also configure the ethernet header compression function alone or configure the IP-series header compression function alone. For the way of configuring the ethernet header compression function and the IP-series header compression function at the same time, the ethernet header compression and the IP-series compression can be processed in parallel, and the ethernet header compression and the IP-series compression can also be processed in serial. In the embodiment of the invention, no matter what compression processing method is adopted, the transmission resource overhead of the Ethernet frame data can be reduced.

In the embodiment of the present invention, after the ethernet frame data is compressed, the receiving end needs to decompress the compressed ethernet frame data, and in order to enable the receiving end to better decompress the compressed ethernet frame data, the sending end may add some indication information to the compressed ethernet frame data.

In this embodiment of the present invention, a sending end may add first indication information in a first compressed packet header, where the first indication information is used to indicate an ethernet frame domain combination mode or a preset bit stream corresponding to a first data stream, where the preset bit stream is used to associate the ethernet frame domain combination corresponding to the first data stream, and the first data stream is a series of data packet sets with the same compression characteristic.

Here, the same compression characteristic may refer to the same ethernet frame format and the same ethernet frame field to be compressed, and each ethernet frame field to be compressed takes the same value. For example, these data packets all need to compress the Ethernet frame source MAC (media Access Control) address (Ethernet source address field) and the Ethernet frame destination MAC address (Ethernet destination address field), and the values of these fields to be compressed are the same. Further, the above-mentioned "ethernet frame combination manner" may be understood as the ethernet frame domain that needs to be compressed and the specific value of each ethernet frame domain that needs to be compressed. The "preset bit stream" may be understood as a bit stream formed by concatenating specific values of ethernet frame fields to be compressed.

Specifically, first indication information for identifying a compressed file of a certain data stream is added in the first compressed packet header, and the compressed file identified by the first indication information is associated with a specific group of ethernet frame field combinations or a specific group of bit streams. For example, the first indication information indicates that the MAC source field (assumed to take a value of "000000", where the bitstream associated with the MAC address field of the ethernet frame source is understood to be "000000"), the MAC destination field (assumed to take a value of "000001", where the bitstream associated with the MAC address field of the ethernet frame is understood to be "000001"), and the Q-tag field (assumed to take a value of "000010", where the bitstream associated with the Q-tag field of the ethernet frame is understood to be "000010") in the packet are compressed. In this example, the "preset bitstream" may be understood as a bitstream in which specific values of the ethernet frame fields to be compressed are concatenated, i.e., "000000000001000010". It should be noted that the values of the ethernet frame fields in the above examples are only for easy understanding, and do not represent the byte size occupied by the actual corresponding ethernet frame fields.

Further, the first indication information is further used to indicate an ethernet frame header format corresponding to the first data stream.

Therefore, the receiving end can determine the ethernet frame domain combination mode or the ethernet frame header format of the first data packet before compression according to the first indication information, so as to be beneficial for the receiving end to decompress the ethernet frame data better.

In this embodiment of the present invention, the sending end may further add second indication information to the second data packet, where the second indication information is used to indicate the length of the first compressed packet header. The second indication information may be added at any suitable position in the second packet, and in particular, the second indication information may be added in the PDCP subheader.

In this way, the receiving end can determine the length of the first compressed packet header according to the second indication information, so that the first compressed packet header can be intercepted (or extracted or identified) from the second data packet more accurately and more quickly.

In this embodiment of the present invention, if the first packet carries a length field (length field) or a PAD field (PAD field), the sending end may further remove at least one of the length field and the PAD field carried in the first packet by using an ethernet frame compression entity. Whether the length field and the padding field are removed or not can be agreed by a protocol or can be configured by a network side device. For example, the protocol provides for removing the length field and the padding field in the ethernet frame, so that the sender always processes the data packet containing the length field and/or the padding field when processing the data packet. In addition, the removal processing on the two domains may be performed simultaneously with the compression of the other ethernet frame domains, or may be performed non-simultaneously, for example, if the network side device configures an ethernet frame compression function for the sending end, when performing ethernet frame compression processing on a data packet of a certain data flow, the removal processing is performed on the length domain and/or the padding domain included in the ethernet frame. In some cases, several packets that are not subjected to ethernet frame compression may be sent before actually performing ethernet frame compression on a certain data stream, and for such packets, a removal process of the length field and/or the padding field may or may not be performed, and if the removal process is performed, indication information indicating whether the length field and/or the padding field is removed may be additionally carried. In addition, when the first data packet is processed, the removing timing of the length field or the padding field may be before the compression processing is performed on the first data packet, that is, after the sending end removes the length field or the padding field, the compression processing is performed on the first data packet.

By removing the length field or the padding field, the transmission resource overhead of the ethernet frame data may be further reduced.

In this embodiment of the present invention, the sending end may further add at least one of the following indication information to the second data packet:

adding third indication information in the second data packet, wherein the third indication information is used for indicating whether a length field carried in the first data packet is removed or not;

adding fourth indication information in the second data packet, wherein the fourth indication information is used for indicating whether the padding field carried in the first data packet is removed or not;

and adding fifth indication information in the second data packet, wherein the fifth indication information is used for indicating whether the length field and the padding field carried in the first data packet are removed or not.

In this way, the receiving end can determine whether the length field or the padding field is removed according to any indication information, so that in the decompression process, whether the removed length field or the padding field needs to be added can be determined more accurately and more quickly.

The above-mentioned data processing method applied to the transmitting end belongs to a compression processing method of ethernet frame data, and a decompression processing method of ethernet frame data will be specifically described below.

Fig. 7 is a flowchart of another data processing method according to an embodiment of the present invention. As shown in fig. 7, the data processing method is applied to a receiving end, and the method includes the following steps:

step 501: a first data packet is received, the first data packet including at least a first compressed packet header.

The first compressed packet header is obtained by compressing the ethernet header.

As described above, in the embodiment of the present invention, the receiving end may be a receiving PDCP entity, and the receiving end may decompress the data packet with the compressed header received by the receiving end. The first data packet may be understood as ethernet frame data having a compressed header, and the first data packet may be regarded as a second data packet compressed by the transmitting end in the aforementioned compression processing method.

In this step, the receiving PDCP entity receives the first data packet from the lower layer, where the data packet may include a PDCP subheader and an SDAP subheader (if any) in addition to the first compressed packet header or the second compressed packet header. If the first data packet includes the PDCP subheader and the SDAP subheader, the receiving end may separate the PDCP subheader and the SDAP subheader from the first data packet before decompressing the first data packet. Of course, the PDCP subheader and the SDAP subheader may not be separated from the first packet, but the ethernet header or the IP-series header in the first packet may be directly compressed.

It should be noted that, separating the PDCP subheader and the SDAP subheader from the first data packet may also be understood as removing the PDCP subheader and the SDAP subheader from the first data packet, or removing the PDCP subheader and the SDAP subheader from the first data packet. In the embodiments of the present invention, the "separating a from a packet" may be understood as "separating a from a packet", or "removing a from a packet", and a description thereof will not be repeated.

Step 502: and decompressing the compressed packet header in the first data packet to obtain a second data packet comprising an Ethernet frame header and an IP series packet header.

In the embodiment of the invention, the sending end can compress at least one of the Ethernet frame header and the IP series packet header in the Ethernet frame data, and the receiving end can decompress the compressed Ethernet frame data, so that the required transmission resources are reduced when the Ethernet frame data is transmitted between the sending end and the receiving end, and the transmission resource overhead of the Ethernet frame data can be reduced.

In this embodiment of the present invention, the first data packet may further include a second compressed packet header, where the second compressed packet header is a compressed packet header obtained by compressing an IP series packet header. In a case that the first data packet includes the first compressed packet header and the second compressed packet header, the receiving end may be configured with an ethernet header decompression function and an IP-series packet header decompression function at the same time, for example, the receiving end is configured with an ethernet frame decompression entity (or referred to as an ethernet frame decompression module) and an ROHC decompression entity (or referred to as an ROHC decompression module) at the same time, where the receiving end may decompress the ethernet header in the first data packet by the ethernet frame decompression entity, and the receiving end may decompress the IP-series packet header in the first data packet by the ROHC decompression entity.

The ways of decompressing the first compressed packet header and the second compressed packet header in the first data packet by the receiving end include multiple ways, and the following describes each way of decompressing.

The first method is as follows: decompressing the first compressed packet header and the second compressed packet header in the first data packet to obtain a second data packet including an ethernet header and an IP-series packet header, including:

decompressing the first compressed packet header through an ethernet frame decompressing entity to obtain a first sub packet including the ethernet frame header;

decompressing the second compressed packet header through the ROHC decompressing entity to obtain a second sub packet including the IP series packet header;

and combining the first sub-packet and the second sub-packet to obtain a second data packet comprising an Ethernet header and an IP series packet header.

The receiving end can respectively send the first compressed packet header and the second compressed packet header in the first data packet to the ethernet frame decompression entity and the ROCH decompression entity, or respectively extract the first compressed packet header and the second compressed packet header from the first data packet through the ethernet frame decompression entity and the ROHC decompression entity, so as to implement the parallel decompression processing of the first compressed packet header and the second compressed packet header. Because of the parallel decompression processing, after the ethernet frame decompression entity and the ROCH decompression entity respectively perform decompression processing, a first sub packet and a second sub packet after respective decompression are obtained, and therefore, after the ethernet frame decompression entity and the ROCH decompression entity respectively perform decompression processing, the first sub packet and the second sub packet need to be combined to obtain a second data packet including an ethernet header and an IP-series packet header. Here, combining the first sub-packet and the second sub-packet may be understood as recombining data.

Optionally, before performing decompression processing on the first compressed packet header and the second compressed packet header, the method further includes:

separating the first data packet into a third sub data packet and a fourth sub data packet, wherein the third sub data packet comprises the first compressed packet header, and the fourth sub data packet comprises the second compressed packet header;

decompressing the first compressed packet header by an ethernet frame decompressing entity to obtain a first sub packet including the ethernet frame header, including:

decompressing the first compressed packet header in the third sub packet by an ethernet frame decompressing entity to obtain a first sub packet including an ethernet frame header;

decompressing the second compressed packet header by an ROHC decompressing entity to obtain a second sub packet including an IP series packet header, including:

decompressing the second compressed packet header in the fourth sub packet by an ROHC decompressing entity to obtain a second sub packet including an IP series packet header.

In this optional embodiment, the first data packet is separated into a third sub data packet and a fourth sub data packet, so that the first compressed packet header and the second compressed packet header in the first data packet are separated, and thus the separated first compressed packet header is sent to the ethernet frame decompression entity for decompression processing, and the separated second compressed packet header is sent to the ROHC decompression entity for decompression processing.

It should be noted that the third sub-packet is not limited to include the first compressed packet header, and the fourth sub-packet is not limited to include the second compressed packet header, for example, the fourth sub-packet may further include a payload portion of the ethernet frame data.

As shown in fig. 8, the first data packet includes a compressed ethernet header, a compressed IP-family header (e.g., a compressed IP-family header), and a payload.

It should be noted that the load in fig. 8 is different from the ethernet frame load, and the ethernet frame load actually refers to data including an IP-series header; and the payload in fig. 8 is data that does not contain an IP-series header.

And the receiving end separates the first data packet into a third data packet and a fourth data packet, wherein the third data packet comprises a compressed Ethernet header, and the fourth data packet comprises a compressed IP series packet header and a load. The receiving end sends the third sub-data packet to the ethernet frame decompressing entity, and the ethernet frame decompressing entity decompresses the ethernet frame header compressed to obtain the first sub-data packet, i.e. the uncompressed ethernet frame header. Correspondingly, the receiving end sends the fourth sub-packet to the ROHC decompression entity, and the ROHC decompression entity decompresses the compressed IP series packet header in the fourth sub-packet to obtain a second sub-packet, where the second sub-packet includes an uncompressed IP and a payload. Then, the receiving end combines the first sub-packet and the second sub-packet to obtain a second data packet including an ethernet header, an IP series packet header and a load.

It should be noted that, in the parallel decompression processing manner, the ethernet frame decompression entity decompresses the first compression packet header, and the ROHC decompression entity decompresses the second compression packet header, which belong to the same time sequence, but the execution time may be synchronized or unsynchronized.

It should be noted that, if the sending end adopts a parallel compression processing mode, the receiving end may also adopt a parallel decompression processing mode; if the sending end adopts a serial compression processing mode, the receiving end can also adopt a parallel decompression processing mode. That is, the compression processing method adopted by the sending end does not limit the decompression processing method adopted by the receiving end.

The second method comprises the following steps: decompressing the first compressed packet header and the second compressed packet header in the first data packet to obtain a second data packet including an ethernet header and an IP-series packet header, including:

decompressing the second compressed packet header in the first data packet by an ROHC decompressing entity to obtain a third data packet including the first compressed packet header and an IP-series packet header;

and decompressing the first compressed packet header in the third data packet by an ethernet frame decompressing entity to obtain a second data packet comprising the ethernet frame header and the IP series packet header.

The method is a serial decompression processing method, and firstly decompresses the second compression packet header and then decompresses the first compression packet header. Specifically, first, the first data packet is sent to the ROHC decompression entity as a whole, and the ROHC decompression entity extracts the second compression packet header from the first data packet to perform decompression processing; or, the first data packet is sent to the ROHC decompression entity as a whole, and the ROHC decompression entity skips over the first compressed packet header at the head of the first data packet and decompresses the second compressed packet header; or, separating the first compressed packet header from the first data packet, and then sending the first data packet to the ROHC decompression entity to decompress the second compressed packet header. Then, the third data packet including the first compressed packet header and the IP series packet header is sent to the ethernet frame decompression entity, and the first compression entity is decompressed. Therefore, the sequential serial decompression processing of the first compressed packet header and the second compressed packet header is realized.

Optionally, decompressing, by an ROHC decompressing entity, the second compressed packet header in the first data packet to obtain a third data packet including the first compressed packet header and an IP-series packet header, where the third data packet includes:

separating the first compressed packet header from the first data packet to obtain a fourth data packet including the second compressed packet header;

decompressing the second compressed packet header in the fourth data packet by an ROHC decompressing entity to obtain a fifth data packet including an IP series packet header;

and adding the first compressed packet header to the header of the fifth data packet to obtain a third data packet comprising the first compressed packet header and the IP series packet header.

In this alternative embodiment, the first compressed packet header is separated from the first data packet, so that the second compressed packet header can be located at the header of the fourth data packet, thereby facilitating the ROHC decompression entity to directly decompress the second compressed packet header. After the second compression packet header is decompressed, the separated first compression packet header is added to the header of the data packet to obtain a third data packet including the first compression packet header and the IP series packet header, and the third data packet is sent to the ethernet frame decompression entity as a whole. Since the first compressed packet header is located at the head of the third data packet, the ethernet frame decompression entity can directly decompress the first compressed packet header in the third data packet.

As shown in fig. 9, the first data packet includes a first compressed packet header, a second compressed packet header, and a payload.

It should be noted that the load in fig. 9 is different from the ethernet frame load, and the ethernet frame load actually refers to data including an IP-series header; and the payload in fig. 9 is data that does not contain an IP-series header.

And the receiving end separates the first compressed packet header from the first data packet to obtain a fourth data packet comprising a second compressed packet header and a load, and then sends the fourth data packet to the ROHC decompression entity, and the ROHC decompression entity decompresses the second compressed packet header in the fourth data packet to obtain a fifth data packet comprising an uncompressed IP series packet header and the load. Then, the receiving end adds the first compressed packet header separated before the header of the fifth packet, and obtains a third packet including the first compressed packet header, an uncompressed IP-series packet header, and a payload. And the receiving end sends the third data packet to an Ethernet frame decompression entity, and the Ethernet frame decompression entity decompresses the first compressed packet header in the third data packet to obtain a second data packet comprising an Ethernet frame header, an IP series packet header and a load.

The third method comprises the following steps: decompressing the first compressed packet header and the second compressed packet header in the first data packet to obtain a second data packet including an ethernet header and an IP-series packet header, including:

decompressing the first compressed packet header in the first data packet by an ethernet frame decompressing entity to obtain a third data packet including an ethernet frame header and the second compressed packet header;

and decompressing the second compressed packet header in the third data packet by an ROHC decompression entity to obtain a second data packet comprising the Ethernet header and the IP series packet header.

The method is another serial decompression processing method, and firstly decompresses the first compressed packet header and then decompresses the second compressed packet header. Specifically, first, the first data packet is sent to an ethernet frame decompression entity, and the first compressed packet header in the first data packet is decompressed to obtain a third data packet including the ethernet header and the second compressed packet header. Then, the third data packet is sent to an ROHC decompression entity integrally, and the ROHC decompression entity extracts a second compression packet header from the third data packet for decompression; or, the third data packet is sent to the ROHC decompression entity as a whole, and the ROHC decompression entity skips over the ethernet header at the head of the third data packet and decompresses the second compressed packet header; or separating the ethernet header from the third data packet, and then sending the third data packet to the ROHC decompression entity for decompressing the second compressed packet header. Therefore, the sequential serial decompression processing of the first compressed packet header and the second compressed packet header is realized.

Optionally, decompressing, by an ROHC decompressing entity, the second compressed packet header in the third data packet to obtain a second data packet including the ethernet header and the IP-series packet header, where the method includes:

separating the ethernet header from the third data packet to obtain a fourth data packet including the second compressed packet header;

and adding the Ethernet frame header to the header of the fifth data packet to obtain a second data packet comprising the Ethernet frame header and the IP series packet header.

In this optional embodiment, after the ethernet header is separated from the third packet, the second compressed packet header may be located at the header of the third packet, so that the ROHC decompression entity can directly decompress the second compressed packet header.

The main difference between the two serial decompression processing manners is the decompression order of the first compressed packet header and the second compressed packet header, and as it is easy to understand, the embodiment of the present invention does not describe the second serial decompression processing manner too much.

It should be noted that, if the sending end adopts a parallel compression processing mode, the receiving end can adopt a serial decompression processing mode; if the sending end adopts a serial compression processing mode, the receiving end can also adopt a serial decompression processing mode. Moreover, the receiving end can adopt any one of two serial decompression processing modes. That is, the compression processing method adopted by the sending end does not limit the decompression processing method adopted by the receiving end.

Optionally, the first data packet includes a first compressed packet header;

before decompressing the first compressed packet header, the method further includes:

determining the length of the first compressed packet header;

and determining the first compressed packet header in the first data packet according to the length of the first compressed packet header.

Optionally, the length of the first compressed packet header is determined by at least one of:

first indication information carried in the first data packet, wherein the first indication information is used for indicating the length of the first compressed packet header;

a length of a first compressed packet header corresponding to an Ethernet frame header format of the first packet based on protocol conventions.

Optionally, the first compressed packet header carries second indication information, where the second indication information is used to indicate an ethernet frame domain combination mode corresponding to a first data stream or a preset bit stream, where the preset bit stream is used to associate the ethernet frame domain combination corresponding to the first data stream, and the first data stream is a series of data packet sets with the same compression characteristic.

Specifically, the compressed file identified by the second indication information is associated with a specific ethernet frame domain combination or a specific bitstream. For example, the second indication information indicates that the MAC source field (assumed to take a value of "000000", where the bitstream associated with the MAC address field of the ethernet frame source is understood to be "000000"), the MAC destination field (assumed to take a value of "000001", where the bitstream associated with the MAC address field of the ethernet frame is understood to be "000001"), and the Q-tag field (assumed to take a value of "000010", where the bitstream associated with the Q-tag field of the ethernet frame is understood to be "000010") in the packet are compressed. In this example, the "preset bitstream" may be understood as a bitstream in which specific values of the ethernet frame fields to be compressed are concatenated, i.e., "000000000001000010". It should be noted that the values of the ethernet frame fields in the above examples are only for easy understanding, and do not represent the byte size occupied by the actual corresponding ethernet frame fields.

Further, the second indication information is further used to indicate an ethernet frame header format corresponding to the first data stream.

Optionally, after decompressing the compressed packet header in the first data packet, the method further includes:

determining whether a length field needs to be added in the second data packet according to the second indication information;

if yes, adding the length field at a specific position of the second data packet through an Ethernet frame decompression entity;

wherein the specific location is determined based on the second indication information, the specific location being determined according to an Ethernet frame format of a high data packet.

determining whether a length field needs to be added in the second data packet according to third indication information carried in the first data packet;

wherein the third indication information is used to indicate whether the length field is removed from the first packet before compression.

determining whether a padding field needs to be added in the second data packet according to a minimum Ethernet frame size agreed by a protocol or according to fourth indication information carried in the first data packet;

if yes, adding a filling domain at the tail part of the second data packet through an Ethernet frame decompression entity;

wherein the fourth indication information is used to indicate whether the padding field is removed from the first packet before compression.

It should be noted that, since the length field in the Ethernet frame indicates the length of the valid data (i.e. Ethernet data field, i.e. data containing IP-series packet header) in the Ethernet frame payload, the Ethernet frame decompression entity needs to determine the specific value of the length field indication after the IP-series packet header decompression, and this may involve interaction between the Ethernet frame decompression entity and the ROHC decompression entity, for example, the ROCH decompression entity indicates the length of the decompressed data (i.e. Ethernet data field) containing IP-series packet header to the Ethernet frame decompression entity, but the interaction that necessarily requires two decompression entities may depend on the implementation. In addition, for the padding field, since the ethernet frame data packet has a minimum byte limit (e.g., 64 bytes), the specific number of bytes that the padding field needs to occupy needs to be determined after decompression and after length field addition (if needed).

In order to more clearly understand the technical solution of the embodiment of the present invention, the following description illustrates the whole process from the compression processing of the ethernet frame data by the sending end to the decompression processing of the ethernet frame data by the receiving end.

Example one: the sending PDCP entity carries out parallel compression processing on the Ethernet frame header and the IP series packet header in the data packet, and the receiving PDCP entity carries out parallel decompression processing on the first compression packet header and the second compression packet header in the data packet.

Step S1: the sending PDCP entity receives the packet containing the header from the upper layer, and removes the SDAP subheader (if any) contained in the packet, and the compressing of the packet with the SDAP subheader removed includes:

compressing the Ethernet frame header in the data packet with the SDAP subheader removed through an Ethernet frame compression entity to obtain a compressed Ethernet frame header; adding indication information for identifying a compressed file of a certain data stream in the obtained compressed ethernet header, where the compressed file identified by the indication information is associated with a group of specific ethernet frame domain combinations or a group of specific bit streams (for example, the specific ethernet frame domain combinations are MAC source =000000, MAC destination =000001, and Q-tag =000010, or the specific bit stream is 000000000001000010), and further, the indication information may also indicate an ethernet frame format or an ethernet header format corresponding to the data stream;

compressing the load part in the data packet with the SDAP subheader removed through an ROHC entity to obtain a data packet with a second compressed packet header;

and adding the compressed Ethernet header to the head of the obtained data packet with the second compressed header so as to obtain the data packet with the first compressed header and the second compressed header.

Additionally, if the protocol agreement or the network configuration removes the length field and/or the padding field carried in the data packet, before performing the compression processing, the compression processing behavior of the ethernet frame entity on the data packet with the SDAP subheader removed further includes:

and removing the length field and/or the filling field carried in the data packet with the SDAP subheader removed.

Step S2: and adding the SDAP subheader removed before the data packet header with the first compressed packet header and the second compressed packet header, and adding the PDCP subheader to obtain the PDCP PDU for delivering to the lower layer for transmission.

Additionally, the following information may also be carried in the PDCP PDU (as carried in the PDCP subheader):

length indication information of the Ethernet frame header, wherein the indication information is used for indicating the length of the compressed Ethernet frame header;

and step S3: the receiving PDCP entity receives a packet containing a compressed header from a lower layer, and removes a PDCP subheader and an SDAP subheader (if there is an SDAP subheader) from the packet, where the decompressing of the packet with the PDCP subheader and the SDAP subheader removed includes:

determining the length of the compressed Ethernet frame header, and decompressing the determined compressed Ethernet frame header through an Ethernet frame decompressing entity to obtain an uncompressed Ethernet frame header;

decompressing the load part of the Ethernet frame through an ROCH decompressing entity to obtain the uncompressed Ethernet frame load part;

and adding an uncompressed Ethernet frame load part at the tail part of the uncompressed Ethernet frame header to obtain a data packet without a compressed header.

Wherein, determining the length of the compressed ethernet frame header may include the following steps:

length indication information based on the Ethernet frame header carried in the received PDCP PDU;

the length information of the Ethernet frame after compression based on a certain Ethernet frame format agreed by the protocol.

Additionally, if the protocol convention or the network configuration removes the length field and/or the padding field carried in the data packet, the processing behavior of the ethernet frame decompression entity on the data packet without the compressed packet header further includes:

the Ethernet frame decompressing entity judges whether the decompressed data packet should have a length field based on the compressed file identification information of the data stream carried in the compressed packet header, if so, the length field is added at a specific position according to the Ethernet frame format associated with the compressed file of the data stream, wherein the length field indicates the length value of the data packet decompressed by the Ethernet frame decompressing entity indicated by the ROHC decompressing entity;

and judging whether a padding field is required to be carried according to the minimum Ethernet frame size agreed by the protocol, if so, adding the padding field at the tail of the decompressed data packet, wherein the length of the padding field is the length of the minimum data field agreed by the protocol minus the length of the actual Ethernet frame load.

And step S4: the upper layer is delivered with the SDAP subheader (if any) removed prior to the addition of the header of the data packet that does not contain the compressed header.

Example two: the sending PDCP entity carries out serial compression processing on the Ethernet frame header and the IP series packet header in the data packet, and the receiving PDCP entity carries out serial decompression processing on the first compression packet header and the second compression packet header in the data packet.

Step S1: the transmitting PDCP entity receives a packet including a header from an upper layer, removes an SDAP subheader (if any) included in the packet, and compresses the packet from which the SDAP subheader is removed.

Step S1.1: compressing the Ethernet frame header in the data packet with the SDAP subheader removed through an Ethernet frame compression entity to obtain a data packet containing the compressed Ethernet frame header; adding indication information identifying a compressed file of a certain data stream in a compressed ethernet header, where the compressed file identified by the indication information is associated with a specific group of ethernet field combinations or a specific group of bitstreams (e.g., the specific ethernet field combinations are MAC source =000000, MAC destination =000001, and Q-tag =000010, or the specific bitstream is 000000000001000010), and additionally, the indication information may also indicate an ethernet frame format or an ethernet header format corresponding to the data stream.

Additionally, if the protocol agreement or the network configuration removes the length field and/or the padding field carried in the data packet, the compressing act of the ethernet frame compressing entity on the data packet with the SDAP subheader removed further includes:

Step S1.2: removing the compressed Ethernet frame header from the data packet obtained in the step S1.1, and compressing the data packet without the compressed Ethernet frame header through an ROHC compression entity to obtain a data packet with a second compressed packet header; and adding the compressed Ethernet header to the header of the data packet containing the second compressed header to obtain the data packet with the first compressed header and the second compressed header.

Additionally, the following information may also be carried in the PDCP PDU (e.g., in the PDCP subheader):

and the length indication information of the Ethernet frame header is used for indicating the length of the compressed Ethernet frame header.

And step S3: the receiving PDCP entity receives a packet containing the first compressed packet header and the second compressed packet header from the lower layer, removes the PDCP subheader and the SDAP subheader (if there is an SDAP subheader) from the packet, and decompresses the packet from which the PDCP subheader and the SDAP subheader have been removed.

Step S3.1: determining the length of the compressed Ethernet frame header and removing the compressed Ethernet frame header, and decompressing the data packet from which the compressed Ethernet frame header is removed through an ROHC decompression entity to obtain a data packet containing an uncompressed IP series packet header; the compressed ethernet header removed before the header addition of the packet containing the uncompressed IP-series header results in a packet containing only the compressed ethernet header and is submitted to the ethernet frame decompression entity.

Step S3.2: the Ethernet frame decompression entity decompresses the Ethernet frame header in the data packet received from the ROHC entity based on the related compressed file, recovers the compressed Ethernet frame domain and obtains the data packet without the compressed packet header.

the length information of the ethernet frame compressed by a certain ethernet frame format based on protocol convention, for example, the header format of the ethernet frame can be known according to compressed file indication information identifying a certain data stream carried in the compressed ethernet frame header, and then the number of bytes occupied by the compressed ethernet frame header of the format, that is, the length of the compressed ethernet frame header, can be determined according to the protocol convention.

Additionally, if the protocol agreement or the network configuration removes the length field and/or the padding field carried in the packet, the processing of the packet received from the ROCH entity by the ethernet frame decompression entity further includes:

judging whether the Ethernet header should have a length field or not based on indication information carried in the first compressed header and identifying a compressed file of a certain data stream, if so, adding the length field at a specific position according to an Ethernet frame format associated with the compressed file of the data stream, wherein the length field indicates the length of the data field in the Ethernet frame;

and determining whether a padding field exists according to the minimum Ethernet frame agreed by the protocol, if so, adding the padding field at the tail of the decompressed data packet, wherein the length of the padding field is the length of the minimum data field agreed by the protocol minus the length of the actual data field.

And step S4: the upper layer is handed over with the SDAP subheader (if any) removed prior to the addition of the header of the packet that does not contain the compressed header.

Example three: the sending PDCP entity compresses the Ethernet frame header in the data packet without configuring the compression function of the IP series frame header; and the receiving PDCP entity decompresses the first compressed packet header in the data packet.

Step S1: the sending PDCP entity receives a data packet containing a packet header from an upper layer, removes an SDAP subheader (if the SDAP subheader exists) contained in the data packet, and processes the Ethernet frame subheader in the data packet with the SDAP subheader removed through an Ethernet frame header compression entity to obtain a data packet with a first compressed packet header; the first compressed packet header carries indication information identifying a compressed file of the data stream, where the compressed file identified by the indication information is associated with a specific group of ethernet frame field combinations or a specific group of bit streams (e.g., the specific ethernet frame field combinations are MAC source =000000, MAC destination =000001, and Q-tag =000010, or the specific bit stream is 000000000001000010), and additionally, the indication information may also indicate an ethernet frame format of the data stream.

Additionally, if the protocol convention or the network configuration removes the length field and/or the padding field carried in the data packet, the compressing of the data packet with the SDAP subheader removed by the ethernet frame compression entity further includes:

Step S2: and adding the SDAP subheader removed before adding the data packet header with the first compressed packet header, and adding the PDCP subheader to obtain the PDCP PDU and deliver the PDCP PDU to a lower layer.

Additionally, length indication information of the ethernet frame header may be carried in the PDCP PDU (e.g., carried in the PDCP subheader), and the indication information is used to indicate the length of the compressed ethernet frame header.

And step S3: the receiving PDCP entity receives a data packet containing a first compressed packet header from a lower layer, removes a PDCP subheader and an SDAP subheader (if the SDAP subheader exists) in the data packet, and the Ethernet frame decompression entity decompresses the Ethernet frame packet header in the data packet from which the PDCP subheader and the SDAP subheader are removed based on a compressed file associated with the packet, recovers a compressed Ethernet frame domain and obtains the data packet without the compressed packet header.

Additionally, if the protocol convention or the network configuration removes the length field and/or the padding field carried in the data packet, the processing action of the ethernet frame decompression entity on the data packet with the PDCP subheader and the SDAP subheader removed further includes:

judging whether the Ethernet frame header should have a length field or not based on indication information carried in the compressed header and identifying a compressed file of a certain data stream, if so, adding the length field at a specific position according to an Ethernet frame format associated with the compressed file of the data stream, wherein the length field indicates the length of the data field in the Ethernet frame;

And step S4: the upper layer is delivered with the SDAP subheader (if any) removed before the decompressed packet header is added.

Example four: the sending PDCP entity compresses the IP series packet header in the data packet without configuring the Ethernet frame header compression function; and the receiving PDCP entity decompresses the second compressed packet header in the data packet.

Step S1: the sending PDCP entity receives the packet containing the header from the upper layer, removes the SDAP subheader (if there is an SDAP subheader) and the ethernet subheader from the packet, and compresses the packet with the SDAP subheader and/or the ethernet subheader removed by the ROHC entity to obtain a packet with a second compressed header.

Step S2: the SDAP subheader (if any) and the Ethernet subheader removed before the addition of the data packet header with the second compressed header are added, and a PDCP subheader is added, resulting in a PDCP PDU and delivered to the lower layer.

And step S3: and the receiving PDCP entity receives the data packet containing the second compressed packet header from the lower layer, removes the PDCP subheader, the SDAP subheader (if the SDAP subheader exists) and the Ethernet frame subheader in the data packet, and decompresses the data packet from which the PDCP subheader, the SDAP subheader and the Ethernet frame subheader are removed through the ROHC decompression entity to obtain the decompressed data packet.

And step S4: the SDAP subheader and the Ethernet frame subheader removed before the decompressed packet header is added are delivered to the upper layer.

In summary, by using any of the data processing methods provided in the embodiments of the present invention, the ethernet frame data can be compressed, and the transmission resource overhead of the ethernet frame data can be reduced. In addition, the processing behaviors of the sending end and the receiving end on the compressed packet and the compression feedback are provided, and the compression efficiency and the decompression efficiency can be improved.

Fig. 10 is a structural diagram of a transmitting end according to an embodiment of the present invention, and as shown in fig. 10, the transmitting end 600 includes:

a receiving module 601, configured to receive a first data packet, where the first data packet includes an ethernet header and an IP-series header;

a compressing module 602, configured to compress at least the ethernet header in the first data packet to obtain a second data packet, where the second data packet at least includes a first compressed packet header;

and the first compressed packet header is a compressed packet header obtained by compressing the Ethernet frame header.

Optionally, the compression module 602 includes one of:

the first compression submodule is used for respectively compressing the Ethernet frame header and the IP series packet header to obtain a second data packet comprising the first compression packet header and a second compression packet header;

a second compression sub-module, configured to perform compression processing on the ethernet header to obtain a second data packet including the first compressed packet header and the IP-series packet header;

and the second compressed packet header is obtained by compressing the IP series packet header.

Optionally, the first compression sub-module includes:

a first compression unit, configured to compress the ethernet header through an ethernet frame compression entity to obtain a first sub-packet including the first compressed header;

a second compression unit, configured to compress the IP-series packet header by using a robust header compression ROHC entity, to obtain a second sub packet including the second compressed packet header;

a combining unit, configured to combine the first sub packet and the second sub packet to obtain a second data packet including the first compressed packet header and the second compressed packet header.

Optionally, the first compression sub-module further includes:

a separating unit, configured to separate the first data packet into a third data packet and a fourth data packet, where the third data packet includes the ethernet header, and the fourth data packet includes the IP-series packet header;

the first compression unit is specifically configured to:

compressing the ethernet header in the third sub-packet by an ethernet frame compression entity to obtain a first sub-packet including the first compressed header;

the second compression unit is specifically configured to:

and compressing the IP series packet header in the fourth sub-packet through an ROHC entity to obtain a second sub-packet comprising the second compressed packet header.

Optionally, the first compression sub-module includes:

a third compression unit, configured to compress the ethernet header in the first data packet through an ethernet frame compression entity, so as to obtain a third data packet including the first compressed packet header and the IP-series packet header;

a fourth compressing unit, configured to perform compression processing on the IP series packet header in the third data packet through an ROHC entity, so as to obtain a second data packet including the first compressed packet header and the second compressed packet header.

Optionally, the fourth compressing unit is specifically configured to:

removing and separating the first compressed packet header from the third data packet to obtain a fourth data packet comprising the IP series packet header;

compressing the IP series packet header in the fourth data packet through an ROHC entity to obtain a fifth data packet comprising the second compressed packet header;

Optionally, the first compression sub-module includes:

a fifth compression unit, configured to perform compression processing on the IP-series packet header in the first data packet through an ROHC entity, to obtain a third data packet including the ethernet header and the second compressed packet header;

a sixth compressing unit, configured to compress the ethernet header in the third data packet through an ethernet frame compressing entity, so as to obtain a second data packet including the first compressed packet header and the second compressed packet header.

Optionally, the fifth compressing unit is specifically configured to:

removing and separating the Ethernet header from the first data packet to obtain a fourth data packet comprising the IP series header;

and adding the Ethernet frame header to the head of the fifth data packet to obtain a third data packet comprising the Ethernet frame header and the second compressed packet header.

Optionally, the transmitting end 600 further includes:

a first adding module, configured to add first indication information to the first compressed packet header; the first indication information is used to indicate an ethernet frame domain combination mode or a preset bit stream corresponding to a first data stream, where the preset bit stream is used to associate the ethernet frame domain combination corresponding to the first data stream, and the first data stream is a data packet set with the same compression characteristic.

Optionally, the first indication information is further used to indicate an ethernet frame header format corresponding to the first data stream.

Optionally, the transmitting end 600 further includes:

a second adding module, configured to add second indication information to the second data packet, where the second indication information is used to indicate a length of the first compressed packet header.

Optionally, the transmitting end 600 further includes:

a removing module, configured to remove at least one of a length field and a padding field carried in the first packet by an ethernet frame compression entity.

Optionally, the sending end 600 further includes a third adding module, where the third adding module is configured to at least one of:

It should be noted that, in the embodiment of the present invention, the sending end 600 may be a sending end of any implementation manner in the method embodiment, and any implementation manner of the sending end in the method embodiment may be implemented by the sending end 600 in the embodiment of the present invention, and the same beneficial effects are achieved, and in order to avoid repetition, details are not described here again.

Fig. 11 is a structural diagram of a receiving end according to an embodiment of the present invention, and as shown in fig. 11, the receiving end 700 includes:

a receiving module 701, configured to receive a first data packet, where the first data packet at least includes a first compressed packet header;

a decompressing module 702, configured to decompress the compressed packet header in the first data packet to obtain a second data packet including an ethernet frame header and an IP-series packet header;

Optionally, the first data packet further includes a second compressed packet header, where the second compressed packet header is a compressed packet header obtained by compressing an IP series packet header;

the decompression module 702 includes:

the first decompression submodule is used for decompressing the first compressed packet header through an Ethernet frame decompression entity to obtain a first sub-packet comprising an Ethernet frame header;

the second decompression submodule is used for decompressing the second compressed packet header through the robust header compression ROHC decompression entity to obtain a second sub-packet comprising an IP series packet header;

and the combining submodule is used for combining the first sub-packet and the second sub-packet to obtain a second data packet comprising the Ethernet header and the IP series packet header.

Optionally, the decompression module 702 further includes:

a separation submodule, configured to separate the first data packet into a third data packet and a fourth data packet, where the third data packet includes the first compressed packet header, and the fourth data packet includes the second compressed packet header;

the first decompression submodule is specifically configured to:

the second decompression submodule is specifically configured to:

the decompression module 702 includes:

a third decompression submodule, configured to decompress the second compressed packet header in the first data packet by using an ROHC decompression entity, so as to obtain a third data packet including the first compressed packet header and an IP-series packet header;

and a fourth decompression sub-module, configured to decompress the first compressed packet header in the third data packet by an ethernet frame decompression entity, so as to obtain a second data packet including the ethernet frame header and the IP-series packet header.

Optionally, the third decompression sub-module is specifically configured to:

the decompression module 702 includes:

a fifth decompression sub-module, configured to decompress the first compressed packet header in the first data packet by an ethernet frame decompression entity, so as to obtain a third data packet including an ethernet frame header and the second compressed packet header;

and a sixth decompression sub-module, configured to decompress, by an ROHC decompression entity, the second compressed packet header in the third data packet to obtain a second data packet including the ethernet header and the IP-series packet header.

Optionally, the sixth decompression sub-module is specifically configured to:

Optionally, the first data packet includes a first compressed packet header;

the receiving end 700 further includes:

a first determining module, configured to determine a length of the first compressed packet header;

a second determining module, configured to determine the first compressed packet header in the first data packet according to the length of the first compressed packet header.

Optionally, the first compression packet header carries second indication information, where the second indication information is used to indicate an ethernet frame domain combination mode or a preset bit stream corresponding to a first data stream, where the preset bit stream is used to associate the ethernet frame domain combination corresponding to the first data stream, and the first data stream is a data packet set with the same compression characteristic.

Optionally, the second indication information is further configured to indicate an ethernet frame header format corresponding to the first data stream.

Optionally, the receiving end 700 further includes:

a third determining module, configured to determine whether a length field needs to be added to the second data packet according to the second indication information;

a first adding module, configured to add, if yes, the length field at a specific location of the second packet through an ethernet frame decompression entity;

wherein the specific location is determined based on the second indication information.

Optionally, the receiving end 700 further includes:

a fourth determining module, configured to determine whether a length field needs to be added to the second data packet according to third indication information carried in the first data packet;

a second adding module, configured to add, if yes, the length field at the specific location of the second packet through an ethernet frame decompression entity;

Optionally, the receiving end 700 further includes:

a fifth determining module, configured to determine whether a padding field needs to be added to the second data packet according to a minimum ethernet frame size agreed by a protocol or according to fourth indication information carried in the first data packet;

a third adding module, configured to add a padding field at a tail of the second packet through an ethernet frame decompression entity if the first packet is a first packet;

It should be noted that, in the embodiment of the present invention, the receiving end 900 may be a receiving end of any implementation manner in the method embodiment, and any implementation manner of the receiving end in the method embodiment may be implemented by the receiving end 700 in the embodiment of the present invention, and the same beneficial effects are achieved, and for avoiding repetition, details are not described here again.

Fig. 12 is a schematic diagram of a hardware structure of a terminal for implementing various embodiments of the present invention, where the terminal 800 includes, but is not limited to: a radio frequency unit 801, a network module 802, an audio output unit 803, an input unit 804, a sensor 805, a display unit 806, a user input unit 807, an interface unit 808, a memory 809, a processor 810, and a power supply 811. Those skilled in the art will appreciate that the configuration shown in fig. 12 does not constitute a limitation on the transmitting side, and that the terminal may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components. In the embodiment of the present invention, the terminal includes, but is not limited to, a mobile phone, a tablet computer, a notebook computer, a palm computer, a vehicle-mounted terminal, a wearable device, a pedometer, and the like.

The terminal 800 may serve as a transmitting end in the embodiment of the present invention, and may also serve as a receiving end in the embodiment of the present invention. During uplink transmission, the terminal 800 may serve as a sending end; in downlink transmission, the terminal 800 can be used as a receiving end.

In uplink transmission, terminal 800 serves as a transmitting end and performs the following data processing method.

The radio frequency unit 801 is configured to:

the processor 810 is configured to:

compressing at least the Ethernet frame header in the first data packet to obtain a second data packet, wherein the second data packet at least comprises a first compressed packet header;

Optionally, the processor 810 is specifically configured to:

respectively compressing the Ethernet frame header and the IP series packet header to obtain a second data packet comprising the first compressed packet header and the second compressed packet header;

compressing the Ethernet frame header to obtain a second data packet comprising the first compressed packet header and the IP series packet header;

Optionally, the processor 810 is specifically configured to:

compressing the Ethernet frame header through an Ethernet frame compression entity to obtain a first sub-packet comprising the first compressed packet header;

compressing the IP series packet header through a robustness header compression ROHC entity to obtain a second sub-packet comprising a second compressed packet header;

and combining the first sub data packet and the second sub data packet to obtain a second data packet comprising the first compressed packet header and the second compressed packet header.

Optionally, the processor 810 is further configured to:

separating the first data packet into a third data packet and a fourth data packet, wherein the third data packet comprises the Ethernet header, and the fourth data packet comprises the IP series packet header;

processor 810 is specifically configured to:

and compressing the IP series packet header in the fourth sub-packet by an ROHC entity to obtain a second sub-packet comprising the second compressed packet header.

Optionally, the processor 810 is specifically configured to:

compressing the Ethernet frame header in the first data packet through an Ethernet frame compression entity to obtain a third data packet comprising the first compression packet header and the IP series packet header;

and compressing the IP series packet header in the third data packet through an ROHC entity to obtain a second data packet comprising the first compressed packet header and the second compressed packet header.

Optionally, the processor 810 is specifically configured to:

separating the first compressed packet header from the third data packet to obtain a fourth data packet including the IP series packet header;

Optionally, the processor 810 is specifically configured to:

compressing the IP series packet header in the first data packet through an ROHC entity to obtain a third data packet comprising the Ethernet header and the second compressed packet header;

Optionally, the processor 810 is specifically configured to:

separating the Ethernet frame header from the first data packet to obtain a fourth data packet comprising the IP series packet header;

Optionally, the processor 810 is further configured to:

adding first indication information in the first compressed packet header; the first indication information is used to indicate an ethernet frame domain combination mode or a preset bit stream corresponding to a first data stream, where the preset bit stream is used to associate the ethernet frame domain combination corresponding to the first data stream, and the first data stream is a data packet set with the same compression characteristic.

Optionally, the first indication information is further configured to indicate an ethernet frame header format corresponding to the first data stream.

Optionally, the processor 810 is further configured to:

and adding second indication information in the second data packet, wherein the second indication information is used for indicating the length of the first compressed packet header.

Optionally, the processor 810 is further configured to:

removing at least one of a length field and a padding field carried in the first packet by an Ethernet frame compression entity.

Optionally, the processor 810 is further configured to at least one of:

In downlink transmission, terminal 800 serves as a receiving end and performs the following data processing method.

The radio frequency unit 801 is configured to:

the processor 810 is configured to:

processor 810 is specifically configured to:

decompressing the first compressed packet header through an ethernet frame decompressing entity to obtain a first sub packet including an ethernet frame header;

decompressing the second compressed packet header through a robust header compression ROHC decompression entity to obtain a second sub packet including an IP series packet header;

and sending the first sub data packet, the second Ethernet header and a second data packet of the IP series header.

Optionally, the processor 810 is further configured to:

processor 810 is specifically configured to:

Optionally, the processor 810 is specifically configured to:

processor 810 is specifically configured to:

Optionally, the processor 810 is specifically configured to:

separating the ethernet frame header from the third data packet to obtain a fourth data packet including the second compressed packet header;

Optionally, the first data packet includes a first compressed packet header;

processor 810 is further configured to:

determining the length of the first compressed packet header;

Optionally, the second indication information is further used to indicate an ethernet frame header format corresponding to the first data stream.

Optionally, the processor 810 is further configured to:

It should be understood that, in the embodiment of the present invention, the radio frequency unit 801 may be used for receiving and sending signals during a message sending and receiving process or a call process, and specifically, receives downlink data from a network-side device and then processes the received downlink data to the processor 810; in addition, the uplink data is sent to the network side equipment. In general, radio frequency unit 801 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, and the like. Further, the radio frequency unit 801 can also communicate with a network and other devices through a wireless communication system.

The sender provides the user with wireless broadband internet access through the network module 802, such as helping the user send and receive e-mails, browse webpages, access streaming media, and the like.

The audio output unit 803 may convert audio data received by the radio frequency unit 801 or the network module 802 or stored in the memory 809 into an audio signal and output as sound. Also, the audio output unit 803 may also provide audio output related to a specific function performed by the terminal 800 (e.g., a call signal reception sound, a message reception sound, etc.). The audio output unit 803 includes a speaker, a buzzer, a receiver, and the like.

The input unit 804 is used for receiving an audio or video signal. The input Unit 804 may include a Graphics Processing Unit (GPU) 8041 and a microphone 8042, and the Graphics processor 8041 processes image data of still pictures or video obtained by an image capturing device (such as a camera) in a video capturing mode or an image capturing mode. The processed image frames may be displayed on the display unit 806. The image frames processed by the graphics processor 8041 may be stored in the memory 809 (or other storage medium) or transmitted via the radio frequency unit 801 or the network module 802. The microphone 8042 can receive sound, and can process such sound into audio data. The processed audio data may be converted into a format output transmittable to a mobile communication network side device via the radio frequency unit 801 in the case of the phone call mode.

The terminal 800 also includes at least one sensor 805, such as light sensors, motion sensors, and other sensors. Specifically, the light sensor includes an ambient light sensor that adjusts the brightness of the display panel 8061 according to the brightness of ambient light, and a proximity sensor that turns off the display panel 8061 and the backlight when the terminal 800 moves to the ear. As one type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in each direction (generally three axes), can detect the magnitude and direction of gravity when stationary, and can be used for identifying the attitude of a transmitting end (such as horizontal and vertical screen switching, related games, magnetometer attitude calibration), vibration identification related functions (such as pedometer and tapping), and the like; the sensors 805 may also include fingerprint sensors, pressure sensors, iris sensors, molecular sensors, gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., which are not described in detail herein.

The display unit 806 is used to display information input by the user or information provided to the user. The Display unit 806 may include a Display panel 8061, and the Display panel 8061 may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like.

The user input unit 807 may be used to receive input numeric or character information and generate key signal inputs related to user setting and function control at the transmitting end. Specifically, the user input unit 807 includes a touch panel 8071 and other input devices 8072. The touch panel 8071, also referred to as a touch screen, may collect touch operations by a user on or near the touch panel 8071 (e.g., operations by a user on or near the touch panel 8071 using a finger, a stylus, or any other suitable object or accessory). The touch panel 8071 may include two portions of a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor 810, receives a command from the processor 810, and executes the command. In addition, the touch panel 8071 can be implemented by various types such as a resistive type, a capacitive type, an infrared ray, and a surface acoustic wave. In addition to the touch panel 8071, the user input unit 807 can include other input devices 8072. In particular, other input devices 8072 may include, but are not limited to, a physical keyboard, function keys (e.g., volume control keys, switch keys, etc.), a trackball, a mouse, and a joystick, which are not described in detail herein.

Further, the touch panel 8071 can be overlaid on the display panel 8071, and when the touch panel 8071 detects a touch operation on or near the touch panel 8071, the touch operation is transmitted to the processor 810 to determine the type of the touch event, and then the processor 810 provides a corresponding visual output on the display panel 8061 according to the type of the touch event. Although in fig. 9, the touch panel 8071 and the display panel 8061 are implemented as two separate components to implement the input and output functions of the transmitting end, in some embodiments, the touch panel 8071 and the display panel 8061 may be integrated to implement the input and output functions of the transmitting end, and the implementation is not limited herein.

The interface unit 808 is an interface for connecting an external device to the terminal 800. For example, the external device may include a wired or wireless headset port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device having an identification module, an audio input/output (I/O) port, a video I/O port, an earphone port, and the like. The interface unit 808 may be used to receive input (e.g., data information, power, etc.) from an external device and transmit the received input to one or more elements within the terminal 800 or may be used to transmit data between the terminal 800 and an external device.

The memory 809 may be used to store software programs as well as various data. The memory 809 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the cellular phone, etc. Further, the memory 809 can include high speed random access memory, and can also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.

The processor 810 is a control center of the transmitting end, connects various parts of the entire transmitting end by using various interfaces and lines, and executes various functions and processes data of the transmitting end by running or executing software programs and modules stored in the memory 809 and calling data stored in the memory 809, thereby integrally monitoring the transmitting end. Processor 810 may include one or more processing units; preferably, the processor 810 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into processor 810.

The terminal 800 may also include a power supply 811 (e.g., a battery) for powering the various components, and preferably, the power supply 811 may be logically coupled to the processor 810 via a power management system to provide management of charging, discharging, and power consumption via the power management system.

In addition, the terminal 800 includes some functional modules that are not shown, and are not described in detail herein.

Preferably, an embodiment of the present invention further provides a terminal, including a processor 810, a memory 809, and a computer program stored in the memory 809 and capable of running on the processor 810, where the computer program, when executed by the processor 810, implements each process of the foregoing data processing method embodiment, and can achieve the same technical effect, and for avoiding repetition, details are not described here again.

It should be noted that, in this embodiment, the terminal 800 may be a transmitting end in any implementation manner in the method embodiment of the present invention, or may also be a receiving end in any implementation manner in the method embodiment of the present invention, and any implementation manner of the transmitting end or the receiving end in the method embodiment of the present invention may be implemented by the terminal 800 in this embodiment, and the same beneficial effects are achieved, and details are not described here again.

Fig. 13 is a structural diagram of a network side device according to an embodiment of the present invention. As shown in fig. 13, the network-side device 900 includes: a processor 901, a transceiver 902, a memory 903 and a bus interface.

The network side device 900 may serve as a sending end in the embodiment of the present invention, and may also serve as a receiving end in the embodiment of the present invention. During uplink transmission, the network device 900 may serve as a receiving end; in downlink transmission, the network device 900 may serve as a transmitting end.

In the uplink transmission, the network device 900 serves as a receiving end and performs the following data processing method.

The transceiver 902 is configured to:

the processor 901 is configured to:

the processor 901 is specifically configured to:

with the first sub-packet and the first optional packet, the processor 901 is further configured to:

the processor 901 is specifically configured to:

decompressing the second compressed packet header in the fourth sub-packet by an ROHC decompressing entity to obtain a second sub-packet including an IP-series packet header.

the processor 901 is specifically configured to:

Optionally, the processor 901 is specifically configured to:

the processor 901 is specifically configured to:

Optionally, the processor 901 is specifically configured to:

Optionally, the first data packet includes a first compressed packet header;

the processor 901 is further configured to:

determining the length of the first compressed packet header;

Optionally, the processor 901 is further configured to:

In the downlink transmission, the network device 900 serves as a transmitting end and performs the following data processing method.

The transceiver 902 is configured to:

the processor 901 is configured to:

Optionally, the processor 901 is specifically configured to one of:

Optionally, the processor 901 is specifically configured to:

and transmitting the first sub data packet and a second data packet comprising the first compressed packet header and the second compressed packet header.

Optionally, the processor 901 is further configured to:

the processor 901 is specifically configured to:

Optionally, the processor 901 is specifically configured to:

compressing the Ethernet frame header in the first data packet by an Ethernet frame compression entity to obtain a third data packet comprising the first compressed packet header and the IP series packet header;

Optionally, the processor 901 is specifically configured to:

separating the Ethernet header from the first data packet to obtain a fourth data packet comprising the IP series header;

Optionally, the processor 901 is further configured to:

adding first indication information in the first compressed packet header; the first indication information is used to indicate an ethernet frame domain combination mode or a preset bit stream corresponding to a first data stream, where the preset bit stream is used to associate with the ethernet frame domain combination corresponding to the first data stream, and the first data stream is a data packet set with the same compression characteristic.

Optionally, the processor 901 is further configured to:

Optionally, the processor 901 is further configured to at least one of:

In fig. 13, the bus architecture may include any number of interconnected buses and bridges, with one or more processors represented by processor 901 and various circuits of memory represented by memory 903 being linked together. The bus architecture may also link together various other circuits such as peripherals, voltage regulators, power management circuits, and the like, which are well known in the art, and therefore, will not be described any further herein. The bus interface provides an interface. The transceiver 902 may be a number of elements including a transmitter and a receiver that provide a means for communicating with various other apparatus over a transmission medium. For different terminals, the user interface 904 may also be an interface capable of interfacing with a desired device, including but not limited to a keypad, display, speaker, microphone, joystick, etc.

The processor 901 is responsible for managing a bus architecture and general processing, and the memory 903 may store data used by the processor 901 in performing operations.

It should be noted that, in this embodiment, the network-side device 900 may be a sending end in any implementation manner in the method embodiment of the present invention, or may also be a receiving end in any implementation manner in the method embodiment of the present invention, and any implementation manner of the sending end or the receiving end in the method embodiment of the present invention may be implemented by the network-side device 900 in this embodiment, and the same beneficial effects are achieved, and details are not described here again.

An embodiment of the present invention further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the computer program implements the processes of the above embodiments corresponding to the sending end or the receiving end, and can achieve the same technical effects, and in order to avoid repetition, the computer program is not described herein again. The computer-readable storage medium may be a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising a … …" does not exclude the presence of another identical element in a process, method, article, or apparatus that comprises the element.

Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal (such as a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present invention.

The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily think of the changes or substitutions within the technical scope of the present invention, and shall cover the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A data processing method is applied to a sending end, and is characterized in that the method comprises the following steps:

the first compressed packet header is obtained by compressing the Ethernet frame header;

the method further comprises the following steps:

adding first indication information for identifying a compressed file of a first data stream in the first compressed packet header, wherein the first data stream is a data packet set with the same compression characteristic;

the same compression characteristic refers to the same ethernet frame format and the same ethernet frame domain to be compressed, and the values of the ethernet frame domains to be compressed are the same.

2. The method according to claim 1, wherein compressing at least the ethernet header in the first packet to obtain a second packet comprises one of:

respectively compressing the Ethernet frame header and the IP series packet header to obtain a second data packet comprising the first compressed packet header and a second compressed packet header;

and the second compressed packet header is a compressed packet header obtained by compressing the IP series packet header.

3. The method according to claim 2, wherein compressing the ethernet header and the IP-based packet header respectively to obtain a second packet including the first compressed packet header and a second compressed packet header comprises:

4. The method according to claim 3, wherein before the compressing the Ethernet header and the IP-series header, the method further comprises:

compressing the ethernet header by an ethernet frame compression entity to obtain a first sub-packet including the first compressed header, including:

compressing the IP series packet header by the ROHC entity to obtain a second sub packet including the second compressed packet header, including:

5. The method according to claim 2, wherein compressing the ethernet header and the IP-based packet header respectively to obtain a second packet including the first compressed packet header and a second compressed packet header comprises:

6. The method according to claim 5, wherein compressing the IP-series header in the third data packet by an ROHC entity to obtain a second data packet including the first compressed header and the second compressed header comprises:

7. The method according to claim 2, wherein compressing the ethernet header and the IP-based packet header respectively to obtain a second data packet including the first compressed packet header and the second compressed packet header comprises:

8. The method according to claim 7, wherein compressing the IP-based header of the first packet by an ROHC entity to obtain a third packet including the ethernet header and the second compressed header comprises:

9. The method of claim 1, wherein the first indication information is further used for indicating an ethernet frame header format corresponding to the first data stream.

10. The method according to any one of claims 1 to 8, further comprising:

11. The method according to any one of claims 1 to 8, further comprising:

12. The method according to any one of claims 1 to 8, further comprising at least one of:

and adding fifth indication information in the second data packet, wherein the fifth indication information is used for indicating whether the length field and the filling field carried in the first data packet are removed or not.

13. A data processing method is applied to a receiving end, and is characterized by comprising the following steps:

the first compressed packet header is obtained by compressing an Ethernet frame header;

the first compressed packet header carries second indication information for identifying a compressed file of a first data stream, wherein the first data stream is a data packet set with the same compression characteristic;

14. The method of claim 13, wherein the first data packet further comprises a second compressed packet header, and the second compressed packet header is obtained by compressing an IP-series packet header;

decompressing the compressed packet header in the first data packet to obtain a second data packet including an ethernet header and an IP-series packet header, including:

and combining the first sub data packet and the second sub data packet to obtain a second data packet comprising the Ethernet header and the IP series header.

15. The method of claim 14, wherein before decompressing the first compressed packet header and the second compressed packet header, the method further comprises:

16. The method according to claim 13, wherein the first data packet further includes a second compressed packet header, and the second compressed packet header is a compressed packet header obtained by compressing an IP-series packet header;

17. The method according to claim 16, wherein decompressing, by an ROHC decompression entity, the second compressed packet header in the first data packet to obtain a third data packet including the first compressed packet header and an IP-series packet header, includes:

18. The method according to claim 13, wherein the first data packet further includes a second compressed packet header, and the second compressed packet header is a compressed packet header obtained by compressing an IP-series packet header;

19. The method according to claim 18, wherein decompressing, by an ROHC decompression entity, the second compressed packet header in the third packet to obtain a second packet including the ethernet header and an IP-series packet header, comprises:

and adding the Ethernet frame header to the head of the fifth data packet to obtain a second data packet comprising the Ethernet frame header and the IP series packet header.

20. The method of any of claims 13 to 19, wherein the first data packet comprises a first compressed packet header;

determining the length of the first compressed packet header;

21. The method of claim 20, wherein the length of the first compressed packet header is determined by at least one of:

22. The method of claim 13, wherein the second indication information is further used for indicating an ethernet frame header format corresponding to the first data stream.

23. The method of claim 13, wherein after decompressing the compressed header of the first packet, the method further comprises:

24. The method according to any one of claims 13 to 19, wherein after decompressing the compressed header in the first data packet, the method further comprises:

25. The method according to any one of claims 13 to 19, wherein after decompressing the compressed header in the first data packet, the method further comprises:

26. A transmitting end, comprising:

the transmitting end further comprises:

a first adding module, configured to add first indication information identifying a compressed file of a first data stream in the first compressed packet header, where the first data stream is a set of data packets with the same compression characteristic;

27. A receiving end, comprising:

28. A transmitting end, comprising: memory, processor and computer program stored on the memory and executable on the processor, which computer program, when executed by the processor, carries out the steps in the data processing method according to any one of claims 1 to 12.

29. A receiving end, comprising: memory, processor and computer program stored on the memory and executable on the processor, which computer program, when executed by the processor, carries out the steps in the data processing method according to any one of claims 13 to 25.

30. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps in the data processing method according to any one of claims 1 to 12; or implementing steps in a data processing method according to any of claims 13 to 25.