CN111278060B

CN111278060B - Ethernet frame transmission method and related equipment

Info

Publication number: CN111278060B
Application number: CN201910056743.3A
Authority: CN
Inventors: 张艳霞; 吴昱民
Original assignee: Vivo Mobile Communication Co Ltd
Current assignee: Vivo Mobile Communication Co Ltd
Priority date: 2019-01-18
Filing date: 2019-01-18
Publication date: 2023-10-24
Anticipated expiration: 2039-01-18
Also published as: CN111278060A

Abstract

The embodiment of the invention provides an Ethernet frame transmission method and related equipment, wherein the method comprises the following steps: acquiring a first data packet, wherein the first data packet comprises a compressed Ethernet frame header, a QoS (quality of service) stream identifier and an SDF (secure digital interface) identifier; and sending the first data packet to a receiving end. The embodiment of the invention can reduce the resource overhead required by the Ethernet frame transmission.

Description

Ethernet frame transmission method and related equipment

Technical Field

The present invention relates to the field of communications technologies, and in particular, to an ethernet frame transmission method and related devices.

Background

Data transmission in a communication system is supported using ethernet encapsulation techniques and data transmitted over ethernet links is referred to as ethernet frames. The ethernet frame usually includes at least one or more of an ethernet frame header and data (data), where the ethernet frame header includes at least a media access control (Media Access Control, MAC) source address and a MAC destination address, and possibly a Type field (Type), a length field (length), a tag field (Q-tag), a priority code point (Priority Code Point, PCP), a discard Identifier (Drop Eligible Indicator, DEI), a virtual local area network Identifier (VID), etc., in an industrial environment, the payload carried by most ethernet frames is relatively small (e.g., 20-50 bytes), and for a certain data at the transmitting end, the fields in the ethernet frames are mostly fixed, so that if each transmission, the ethernet frame carries a complete ethernet frame header, the required resource overhead for the ethernet frame transmission is relatively large.

Disclosure of Invention

The embodiment of the invention provides an Ethernet frame transmission method and related equipment, which are used for solving the problem of relatively large resource overhead required by Ethernet frame transmission.

In a first aspect, an embodiment of the present invention provides an ethernet frame transmission method, applied to a transmitting end, including:

acquiring a first data packet comprising a compressed ethernet header, a quality of service (Quality of Service, qoS) flow identification, and a traffic data flow (Service Data Flow, SDF) identification;

and sending the first data packet to a receiving end.

In a second aspect, an embodiment of the present invention provides an ethernet frame transmission method, applied to a receiving end, including:

receiving a first data packet sent by a sending end, wherein the first data packet comprises a compressed Ethernet frame header, a quality of service QoS flow identifier and a service data flow SDF identifier;

decompressing the Ethernet frame header.

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

the acquisition module is used for acquiring a first data packet, wherein the first data packet comprises a compressed Ethernet frame header, a QoS flow identifier and an SDF identifier;

and the first sending module is used for sending the first data packet to the receiving end.

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

the first receiving module is used for receiving a first data packet sent by a sending end, wherein the first data packet comprises a compressed Ethernet frame header, a quality of service QoS flow identifier and a service data flow SDF identifier;

and the first decompression module is used for decompressing the Ethernet frame header.

In a fifth aspect, an embodiment of the present invention provides a communication device, including: the method comprises a memory, a processor and a program stored in the memory and capable of running on the processor, wherein the program is executed by the processor to realize the steps in the ethernet frame transmission method provided in the first aspect, or the program is executed by the processor to realize the steps in the ethernet frame transmission method provided in the second aspect.

In a sixth 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, where the computer program when executed by a processor implements the steps in the ethernet frame transmission method provided in the first aspect, or where the program when executed by the processor implements the steps in the ethernet frame transmission method provided in the second aspect.

In the embodiment of the invention, a first data packet is acquired, wherein the first data packet comprises a compressed Ethernet frame header, a QoS (quality of service) flow identifier and an SDF (standard deviation function) identifier; and sending the first data packet to a receiving end. Since the compressed ethernet header is transmitted, the resource overhead required for ethernet frame transmission can be reduced.

Drawings

Fig. 1 is a schematic diagram of a wireless communication system to which embodiments of the present invention are applicable;

fig. 2 is a flowchart of an ethernet frame transmission method according to an embodiment of the present invention;

fig. 3 is a flowchart of another ethernet frame transmission method according to an embodiment of the present invention;

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

fig. 5 is a block diagram of another transmitting end according to an embodiment of the present invention;

fig. 6 is a block diagram of another transmitting end according to an embodiment of the present invention;

fig. 7 is a block diagram of another transmitting end according to an embodiment of the present invention;

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

fig. 9 is a block diagram of another receiving end according to an embodiment of the present invention;

fig. 10 is a block diagram of another receiving end according to an embodiment of the present invention;

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

Fig. 12 is a block diagram of a communication device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

The terms "comprises," "comprising," or any other variation thereof, 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 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 at least one of the connected objects, e.g., a and/or B, meaning that it includes a single a, a single B, and that there are three cases of a and B.

In embodiments of the invention, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g." in an embodiment should not be taken as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

Embodiments of the present invention are described below with reference to the accompanying drawings. The method and the related equipment for transmitting the Ethernet frames 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 (Evolved Long Term Evolution, elet) system, or an LTE system, or a subsequent evolved communication system.

Referring to fig. 1, fig. 1 is a schematic diagram of an architecture of a wireless communication system to which an embodiment of the present invention is applicable, where a terminal (for example, a UE) and a wireless communication network form a bridge, as shown by a dashed box, and the bridge is a virtual bridge. The bridge includes a terminal (UE, for example), a New Radio-Radio Access Network, NG-RAN, an access mobility management function (Access Management Function, AMF), a session management function (Session Management Function, SMF), a policy control function (Policy Control Function, PCF), and a user plane function (User Plane Function, UPF). Wherein for downstream data, the UE is the exit device of the Bridge (Bridge) and the UPF is the entrance device of the Bridge. For upstream data, the UE is the ingress device of the bridge and the UPF is the egress device of the bridge. In addition, the UE may establish a connection with the first external device, and the UPF may establish a connection with the second external device, which should be noted that in the embodiment of the present invention, the external device is not limited, and any device capable of establishing a connection with the UE or the UPF may be used.

In the embodiment of the present invention, the terminal may be a User Equipment (UE) or other terminal side devices, for example: terminal-side devices such as a mobile phone, a tablet (Tablet PersonalComputer), a Laptop (Laptop Computer), a personal digital assistant (personal digital assistant, PDA for short), a mobile internet Device (Mobile Internet Device, MID) or a Wearable Device (weardable Device), it should be noted that the specific type of the terminal 11 is not limited in the embodiment of the present invention.

In the embodiment of the present invention, the core network element (CN network element) may include, but is not limited to, at least one of the following: core network equipment, core network nodes, core network functions, core network elements, mobility management entities (Mobility Management Entity, MME), access mobility management functions (Access Management Function, AMF), session management functions (Session Management Function, SMF), user plane functions (User Plane Function, UPF), serving Gateways (SGW), PDN gateways (PDN gateway Way, PDN gateway), policy control functions (Policy Control Function, PCF), policy and charging rules function units (Policy and Charging Rules Function, PCRF), GPRS service support nodes (Serving GPRS Support Node, SGSN), gateway GPRS support nodes (Gateway GPRS Support Node, GGSN), and radio access network equipment.

In the embodiment of the present invention, the RAN network element may include, but is not limited to, at least one of the following: a radio Access network device, a radio Access network Node, a radio Access network function, a radio Access network Unit, a 3GPP radio Access network, a Non-3GPP radio Access network, a Centralized Unit (CU), a Distributed Unit (DU), a base station, an evolved Node B (eNB), a 5G base station (gNB), a radio network controller (Radio Network Controller, RNC), a base station (NodeB), a Non-3GPP interoperability function (Non-3GPP Inter Working Function,N3IWF), an Access control (Access Controller, AC) Node, an Access Point (AP) device, or a wireless local area network (Wireless Local Area Networks, WLAN) Node.

In the embodiment of the present invention, the transmitting end may be a transmitting device, for example: may be a terminal or a RAN network element, and the receiving end may be a receiving device, for example: RAN network elements or terminals.

In addition, the embodiment of the present invention is not limited to be applied to the network architecture shown in fig. 1, for example: but also to communication system architectures in which no bridge exists.

Referring to fig. 2, fig. 2 is a flowchart of an ethernet frame transmission method according to an embodiment of the present invention, where the method is applied to a transmitting end, as shown in fig. 2, and includes the following steps:

Step 201, a first data packet is acquired, where the first data packet includes a compressed ethernet frame header, a QoS flow identifier, and an SDF identifier.

The first data packet may be obtained by compressing an ethernet frame by a transmitting end, or may be obtained by receiving a data packet including a compressed ethernet frame header sent by another device, for example: and receiving the data packet of the compressed Ethernet frame header sent by the core network element.

The SDF identifier may be a unique identifier in a protocol data unit session (Protocol Data Unit session, PDU session), or may be a unique identifier in a QoS flow (QoS flow), or may be a unique identifier in a data radio bearer (data radio bearer, DRB).

In addition, the acquiring the first data packet may be acquired by the receiving end, or may be acquired by an entity that is the receiving end, for example: a packet data convergence protocol (Packet Data Convergence Protocol, PDCP) entity obtains.

Step 202, sending the first data packet to a receiving end.

In the above step, since the first data packet includes the compressed ethernet header and includes the QoS flow identifier and the SDF identifier, the receiving end receives the first data packet, and can identify the service data flow and the QoS flow to which the first data packet belongs according to the QoS flow identifier and the SDF identifier, so as to decompress the ethernet header correspondingly.

In the method provided by the embodiment of the invention, the compressed Ethernet frame header is transmitted, so that the resource cost required by Ethernet frame transmission can be reduced.

In an alternative embodiment, the compressed ethernet header is an ethernet header with a specific ethernet field removed.

Wherein the specific ethernet frame field may include at least one of:

a MAC source address field, a MAC destination address field, a type field, an outer TAG (S-TAG) field, a TAG protocol identifier (Tag Protocol Identifier, TPID) field, a PCP field, a DEI field, and a VID field.

Of course, the specific ethernet frame field may further include an encapsulation header of an ethernet upper layer protocol, for example, when the ethernet upper layer protocol is encapsulated by using the 802.2 protocol, the specific ethernet frame field may further include a destination service access point (Destination Service Access Point, DSAP), a source service access point (Source Service Access Point, SSAP), and the like; at least one of the MAC source address field, the MAC destination address field, the type field, the S-TAG field, the TPID field, the PCP field, the DEI field, and the VID field may be protocol-specific or network-configurable, i.e., it may be protocol-specific or network-configurable to specifically compress which ethernet frame fields.

It should be noted that the type field, the S-TAG field, the TPID field, the PCP field, the DEI field, and the VID field are not necessarily included in some ethernet headers, that is, the type field, the S-TAG field, the TPID field, the PCP field, the DEI field, and the VID field may be removed only when the ethernet headers are included, which is, of course, not limited thereto. For example: in some embodiments, one or more of the ethernet header type field, the PCP field, the DEI field, and the VID field may not be removed or portions may not be removed if one or more of the fields are not necessarily removed.

In this embodiment, the specific ethernet frame field may be removed, so that the resource overhead required for ethernet frame transmission may be reduced.

As an optional implementation manner, the acquiring the first data packet includes:

the PDCP entity compresses the Ethernet frame head to obtain the first data packet.

In this embodiment, the PDCP entity may perform ethernet header compression as a functional entity in the case where the terminal and the RAN network element are anchor points. For example: in the case that the transmitting end is a terminal, ethernet header compression may be performed on uplink data by the PDCP entity, and in the case that the transmitting end is a RAN network element, ethernet header compression may be performed on downlink data by the PDCP entity.

In this embodiment, since the ethernet header may be directly compressed by the PDCP entity at the transmitting end, the PDCP entity may accurately determine the position of the TCP/IP sub-header (e.g., the position in the SDAP PDU), so that the ethernet header compression flexibility may be improved. In addition, in this embodiment, since the PDCP entity compresses the ethernet header, for example: the ethernet header of a particular ethernet frame field is removed. And the packet header of the transport ethernet upper layer protocol package can be reserved, and if the SDAP sub-header exists, the SDAP sub-header can be reserved.

In this embodiment, since the ethernet header compression functional entity is in the PDCP layer, the PDCP layer may determine the QoS flow and the service data flow to which each data packet received by the PDCP layer belongs (where the service data flow is a certain data flow between ethernet transceiver devices that needs to be transmitted by the 5GS system), so that ethernet header compression is performed for each service data flow. For example: the PDCP entity compresses an ethernet header to obtain the first data packet, including:

the PDCP entity receives a service data adaptation protocol (Service Data Adapt Protocol, SDAP) data packet transmitted by an SDAP entity, wherein the SDAP data packet carries the QoS flow identifier and the SDF identifier;

The PDCP entity compresses an Ethernet frame header carried in the SDAP data packet to obtain the first data packet.

The SDAP packet carries the QoS flow identifier and the SDF identifier, which may be carried in an SDAP sub-header. For example: when delivering a data packet to a lower layer, an SDAP entity of a sending end carries a QoS flow to which the data packet belongs and an SDF identifier to which the QoS flow belongs, for example, a QoS ID and an SDF ID are carried in an SDAP sub-header.

In this embodiment, the ethernet frame may be uplink data or downlink data.

Optionally, before compressing the ethernet header to obtain the first data packet, the method further includes:

and sending a second data packet to the receiving end, wherein the second data packet comprises an uncompressed Ethernet frame header, the QoS flow identifier and the SDF identifier.

In this embodiment, since the uncompressed ethernet header having the same QoS flow identifier and SDF identifier is sent before the first packet is sent, after the receiving end receives the second packet, the receiving end may determine the content of the uncompressed ethernet header corresponding to the QoS flow identifier and SDF identifier, and after the receiving end receives the first packet, may decompress the compressed ethernet header in the first packet based on the content of the uncompressed ethernet header in the second packet. In this way, the content of the compressed ethernet header, that is, the value of the removed specific ethernet frame field, does not need to be additionally configured, so that the transmission overhead can be further saved.

Further, the compressing the ethernet header to obtain the first data packet may include:

and if the feedback message fed back by the receiving end is received, compressing the Ethernet frame header to obtain the first data packet, wherein the feedback message is used for indicating that the data packet containing the uncompressed Ethernet frame header is successfully received.

The successful reception of the data packet containing the uncompressed ethernet header may be successful reception of the data packet corresponding to the QoS flow identifier and the SDF identifier, where the data packet contains the uncompressed ethernet header.

In this embodiment, it may be ensured that the receiving end transmits the compressed ethernet header after successfully receiving the uncompressed ethernet header, so as to avoid occurrence of errors.

For example: PDCP entity at the transmitting end: receiving data from the SDAP entity at the corresponding upper layer, if the data packet is received from the service data stream for the first time, the PDCP entity does not compress the Ethernet frame and sends the complete Ethernet frame sub-hair to the receiving end; if the data packet containing the complete Ethernet sub-header is not successfully received by the receiving end, the Ethernet sub-header is not compressed when the data packet corresponding to the service data stream is subsequently transmitted, and the complete Ethernet sub-header is sent to the receiving end; if the successful receiving of the data packet containing the complete ethernet frame sub-header fed back by the receiving end is received, the PDCP entity sends the compressed ethernet frame sub-header to the receiving end for the subsequent packet of the service data stream.

Optionally, the SDAP entity transfers the SDAP data packet to the PDCP entity through a first data radio bearer DRB;

in the case where the SDF identification in the QoS flow is unique in the PDU session and the SDAP entity delivers the SDAP packet in the QoS flow to the PDCP entity through a second DRB, the SDAP entity reuses the SDF identification in the first DRB in the second DRB; or alternatively

In the case that the SDF identification in the QoS flow is unique in the QoS flow, and the SDAP entity delivers the SDAP packet in the QoS flow to the PDCP entity through a third DRB, the SDAP entity allocates the SDF identification unique in the third DRB to the service data flow in the QoS flow;

wherein the QoS flow corresponds to the QoS flow identifier.

In this embodiment, when the QoS flow is remapped, if the SDF identifier in the QoS flow is unique in the PDU session, the corresponding service data flow identifier is reused on the new DRB, thereby reducing complexity.

And when the remapping of the QoS flow can be realized, if the SDF identification in the QoS flow is unique in the QoS flow, the unique SDF identification in the new DRB is allocated to the service data flow in the QoS flow, so that the occurrence of errors with data packets of other service data flows on the new DRB can be avoided. For example: the third DRB already has data packet transmissions of SDF id 1, SDF id 2, and SDF id 3, so that SDF id 4 is allocated for transmission to avoid errors.

and receiving a data packet which is sent by a core network element and carries the SDF identification and the uncompressed Ethernet frame header.

In this embodiment, the data packet is a downlink data packet to transmit downlink data, and in this embodiment, the transmitting end is a RAN network element. For example: in the case that the terminal and the RAN network element are anchor points, the PDCP entity performs ethernet header compression on the downlink data as a functional entity, which may specifically be: when a core network element (such as UPF) sends data to a RAN network element through a channel (such as GTP-U) between the core network and the RAN, an SDF identifier is added in an encapsulation packet header, wherein the identifier can be only in the whole PDU session or only in one QoS flow; after receiving the data, the SDAP entity of the RAN network element transmits an SDAP data packet to the PDCP entity, and simultaneously carries a QoS flow identifier and an SDF identifier, and the PDCP entity compresses an Ethernet frame header carried in the SDAP data packet to obtain the first data packet.

In this embodiment, ethernet header compression of the downlink data may be implemented to reduce transmission overhead.

Optionally, the compressing the ethernet frame header by the PDCP entity includes:

the PDCP entity compresses the ethernet frame header according to a compression configuration, wherein the compression configuration is used for at least one of:

configuring Ethernet frame header compression for downlink data;

configuring Ethernet frame header compression for uplink data;

and (3) performing Ethernet header compression on the uplink data and the downlink data.

The compression configuration may be configured by a network, or preconfigured by a transmitting end, or agreed by a protocol. Since the compression is performed according to the compression configuration, the ethernet header compression of different data can be flexibly implemented.

In addition, the configuration granularity of the compression configuration is DRB, or QoS flow. This can be achieved in that the configuration granularity of the compression configuration is configured in DRB units (per DRB configuration), for example: qoS flow 1 and QoS flow 2 are transmitted through DRB1, DRB1 configures Ethernet header compression, PDCP entity performs Ethernet header compression on data packets of QoS flow 1 and QoS flow 2. Alternatively, configuration in units of QoS flows may be implemented, for example: qoS flow 1 configures ethernet header compression, qoS flow 2 does not configure ethernet header compression, and QoS flow 1 and QoS flow 2 are transmitted through the same DRB, then PDCP entity performs ethernet header compression on the packets of QoS flow 1, but not on the packets of QoS flow 2.

In addition, if a certain DRB is configured with an ethernet header compression function, a subheader is configured for an SDAP entity associated with the DRB, for example: the SDAP entity configures an SDAP subheader to carry the QoS flow identifier and the SDF identifier.

the SDAP entity obtains a third data packet, wherein the third data packet comprises a compressed Ethernet frame header, and the third data packet further comprises the SDF identifier and/or the QoS flow identifier;

the SDAP entity transmits an SDAP packet corresponding to the third data packet to the PDCP entity;

the PDCP entity obtains the first data packet based on the SDAP packet.

Wherein the third data packet may be received from a core network element, for example: for downlink transmission, the RAN network element receives the third data packet from the core network element. Or the third data packet is transmitted by an ethernet frame compression entity above the PDCP entity of the sender. The ethernet frame compression entity may be an SDAP entity, or a protocol entity added in the embodiment of the present invention. In addition, the core network element and the ethernet frame compression entity can configure ethernet frame header compression by taking PDU session or QoS flow as configuration granularity.

In addition, the SDAP packet may carry the QoS flow identifier and the SDF identifier.

The PDCP entity may obtain the first data packet based on the SDAP packet by compressing a TCP/IP header carried in the SDAP packet.

In this embodiment, since the SDAP entity can obtain the compressed Ethernet frame header, the cost of the PDCP entity or the transmitting end can be reduced.

Optionally, the SDAP packet includes the compressed ethernet header and an uncompressed TCP/IP header, and carries the QoS flow identifier and the SDF identifier, and the PDCP entity obtains the first packet based on the SDAP packet, including:

the PDCP entity compresses the TCP/IP header to obtain the first data packet.

In this embodiment, the TCP/IP header may be further compressed to further save transmission overhead.

Optionally, the PDCP entity compresses the TCP/IP header, including:

and determining the position of the TCP/IP header in the SDAP packet, and compressing the TCP/IP header according to the position.

The above determination of the position of the TCP/IP header in the SDAP packet may be determined according to the length of the compressed ethernet frame sub-header, that is, if the ethernet frame header compressed functional entity is above the PDCP layer, so that the PDCP entity needs to know the length of the compressed ethernet frame sub-header, so that the PDCP layer performs TCP/IP header compression. The length of the compressed ethernet frame sub-header may be configured in the relationship information, or the length of the compressed ethernet frame sub-header may be a fixed length, or the length of the compressed ethernet frame may be indicated by the compression entity.

Optionally, in the case that the compressed ethernet header is an ethernet header from which a specific ethernet domain is removed, the sending end obtains first relationship information corresponding to the SDF identifier, where the first relationship information includes a value of the specific ethernet domain.

So that the value of a particular ethernet frame field can be determined from the first relationship information.

Further, the first relationship information further includes length information of the compressed ethernet header, and the determining the position of the TCP/IP header in the SDAP packet includes:

based on the length information of the object to be processed, determining the position of the TCP/IP header in the SDAP packet.

The first relationship information may be a core network element configuration, for example: and the transmitting end receives the first relation information in the PDU session establishment or modification process. Specifically, the first relationship information may be received through a QoS profile command or a QoS rule command in PDU session establishment or modification. This reduces transmission overhead by not adding additional flows.

Referring to fig. 3, fig. 3 is a flowchart of another ethernet frame transmission method according to an embodiment of the present invention, where the method is applied to a receiving end, as shown in fig. 3, and includes the following steps:

step 301, a first data packet sent by a sending end is received, where the first data packet includes a compressed ethernet header, a QoS flow identifier, and an SDF identifier.

The ethernet header, qoS flow identifier, and SDF identifier may be referred to the corresponding descriptions of the embodiment shown in fig. 2, which are not described herein.

Step 302, decompressing the ethernet frame header.

Step 302 may be to decompress the ethernet header according to the QoS flow identification and SDF identification, for example: the data packets belonging to the same SDF are determined according to the QoS flow identification and the SDF identification, and the values of the fields which are not transmitted in the Ethernet frame heads in the data packets belonging to the same SDF are determined, or the data packets with the same Ethernet frame heads are determined according to the QoS flow identification and the SDF identification, and the values of the fields which are not transmitted in the Ethernet frame heads in the data packets are determined.

The decompression may be to add a value of a field that is not transmitted in the ethernet header.

Since the compressed ethernet header is transmitted, the resource overhead required for ethernet frame transmission can be reduced.

As an optional implementation manner, the decompressing the ethernet header includes:

and adding the value of the specific untransmitted Ethernet frame domain in the Ethernet frame header.

The value of the specific ethernet frame field may be determined by pre-configured relationship information, or may be determined by an uncompressed ethernet frame header.

Optionally, the specific ethernet frame field includes at least one of:

a MAC source address field, a MAC destination address field, a type field, an S-TAG field, a TPID field, a PCP field, a DEI field, and a VID field.

Optionally, the adding the value of the specific ethernet frame field that is not transmitted in the ethernet frame header includes:

determining the value of the specific Ethernet frame domain which is not transmitted in the Ethernet frame header according to the second relation information corresponding to the SDF identification, and adding the value of the specific Ethernet frame domain into the Ethernet frame header;

wherein the second relationship information includes a correspondence of the SDF identification and an uncompressed ethernet header.

In this embodiment, the corresponding relationship between the SDF identifier and the uncompressed ethernet header may determine the value of the specific ethernet field of the uncompressed ethernet header through the SDF identifier. Of course, further, the second relationship information includes the correspondence between the SDF identifier and the QoS flow identifier and the uncompressed ethernet header, that is, the data packets with the same ethernet header are identified by the SDF identifier and the QoS flow identifier.

Optionally, before the receiving the first data packet sent by the sending end, the method further includes:

receiving a second data packet sent by the sending end, wherein the second data packet comprises an uncompressed Ethernet frame header, the QoS flow identifier and the SDF identifier;

and storing the corresponding relation between the SDF identification and the uncompressed Ethernet frame header to obtain the second relation information.

The second data packet and the corresponding implementation manner may refer to the corresponding description of the embodiment shown in fig. 2, which is not repeated herein, and may achieve the same beneficial effects.

Optionally, after the receiving the second data packet sent by the sending end, the method further includes:

and feeding back a message to the sending end, wherein the feedback message is used for indicating that the data packet containing the uncompressed Ethernet frame header is successfully received.

The feedback message may refer to the corresponding description of the embodiment shown in fig. 2, which is not repeated herein, and may achieve the same beneficial effects.

Optionally, the first data packet further includes a compressed TCP/IP header, and after the receiving the first data packet sent by the sending end, the method further includes:

And determining the decompression position of the TCP/IP header, and decompressing the TCP/IP header according to the position.

The above description of determining the location of the decompression of the TCP/IP header in the SDAP packet may be referred to in the embodiment shown in fig. 2, which is not described herein.

Optionally, the receiving end obtains first relation information corresponding to the SDF identifier, where the first relation information includes a value of the specific ethernet frame domain;

the adding the value of the specific untransmitted Ethernet frame domain in the Ethernet frame header comprises the following steps:

and the Ethernet frame decompression entity determines the value of the specific Ethernet frame domain which is not transmitted in the Ethernet frame header according to the first relation information, and adds the value of the specific Ethernet frame domain in the Ethernet frame header.

The ethernet frame decompression entity may be an entity above PDCP, for example: the newly added protocol entity or SDAP entity of the embodiment of the invention.

Optionally, the first relationship information further includes length information of the compressed ethernet header, and determining the decompressed position of the TCP/IP header includes:

and determining the decompressed position of the TCP/IP head according to the length information.

Optionally, the receiving end receives the first relation information in a PDU session establishment or modification process.

The description of the first relationship information may be referred to the corresponding description in the embodiment shown in fig. 2, which is not repeated herein.

In this embodiment, a first data packet sent by a sending end is received, where the first data packet includes a compressed ethernet frame header, a QoS flow identifier, and an SDF identifier; step 302, decompressing the ethernet frame header. Since the compressed ethernet header is transmitted, the resource overhead required for ethernet frame transmission can be reduced.

The following illustrates the ethernet frame transmission method provided by the embodiment of the present invention by using a terminal as UE and a RAN network element as gNB:

example 1:

in this embodiment, with UE and gNB as anchor points, the PDCP entity performs ethernet header compression on uplink data as a functional entity to exemplify:

among other things, the ethernet frame compression configuration may include the following:

1. the Ethernet header compression function can be configured to only carry out the Ethernet header compression on the uplink data, or the Ethernet header compression is configured to only carry out the Ethernet header compression on the downlink data, or the Ethernet header compression is configured to carry out the Ethernet header compression on both the uplink data and the downlink data;

2. Configuration granularity: per DRB configuration, or per QoS flow configuration;

3. if a certain DRB is configured with an Ethernet frame header compression function, a sub-header is configured for the SDAP associated with the DRB.

The ethernet header compression flow is as follows:

1. SDAP entity of transmitting end: when a data packet is submitted to a lower layer, carrying QoS flow to which the data packet belongs and Service Data Flow (SDF) identification information to which the QoS flow belongs in the QoS flow, for example, carrying QoS ID and SDF ID in an SDAP subheader;

2. PDCP entity at the transmitting end: receiving data from the SDAP entity at the corresponding upper layer, if the data packet is received from the service data stream for the first time, the PDCP entity does not compress the Ethernet frame and sends the complete Ethernet frame sub-hair to the receiving end; if the data packet containing the complete Ethernet sub-header is not successfully received by the receiving end, the Ethernet sub-header is not compressed when the data packet corresponding to the service data stream is subsequently transmitted, and the complete Ethernet sub-header is sent to the receiving end; if the successful receiving of the data packet containing the complete ethernet frame sub-header fed back by the receiving end is received, the PDCP entity sends the compressed ethernet frame sub-header to the receiving end for the subsequent packet of the service data stream. The method comprises the following steps: the MAC source address, MAC destination address, and TPID, PCP, DEI, VID in the TYPE field (TYPE), Q-tag may also be removed from the ethernet frame, where TPID, PCP, DEI, VID in the TYPE field (TYPE), Q-tag may be removed when these fields are included in the ethernet header. The packet header of the upper layer protocol package of the transmission Ethernet can be reserved;

3. PDCP entity at receiving end: when a data packet corresponding to a certain service data stream is received for the first time, the corresponding relation between the service data stream and the Ethernet sub-head is saved, and successful reception is fed back to a transmitting end through a PDCP (packet data protocol) state report; and if the data packet which corresponds to the service data stream and contains the compressed Ethernet sub-header is received, retrieving the corresponding value of each Ethernet field which is not transmitted from the stored corresponding relation table, and recovering the uncompressed Ethernet frame structure to complete decompression.

In addition, the process when remapping occurs for QoS flows may be as follows:

1. if the service data flow identification in the QoS flow is unique in the PDU session, the corresponding service data flow identification is reused on the new DRB;

2. if the service data flow identification in the QoS flow is unique in the QoS flow, the service data flow in the QoS flow is allocated with a service data flow identification unique in the new DRB.

Example 2:

in this embodiment, with UE and gNB as anchor points, the PDCP entity performs ethernet header compression on downlink data as a functional entity, and the specific flow is as follows:

when a core network element (such as UPF) sends data to a RAN network element through a channel (such as GTP-U) between the core network and the RAN, a service data flow identifier is added in an encapsulation packet header, wherein the identifier can be only in the whole PDU session or only in one QoS flow;

After receiving the data, the SDAP entity of the gNB performs the corresponding processing actions with the actions of the transmitting end (e.g., UE) in the first embodiment, where the actions of the receiving end (e.g., UE) in this embodiment are the same as the actions of the receiving end in the first embodiment, which are not described herein.

Example 3:

in this embodiment, the UE and the UPF are used as anchor points, and the newly added protocol entity is used as a functional entity to perform ethernet header compression on the downlink data.

Of course, the method of this embodiment is equally applicable to a scenario where UE and gNB are anchor points and SDAP is a functional entity, for example: functional entity performing ethernet header compression.

In this embodiment, the ethernet header compression-related configuration:

1. configuring an association relation table (namely the first relation information) for a receiving end, wherein the table comprises service data flow identifiers, values of corresponding Ethernet sub-header specific fields and compressed Ethernet sub-header lengths, and the specific fields comprise: a MAC source address, a MAC destination address, a Tag Protocol Identifier (TPID)/a Priority Code Point (PCP)/a drop identification (DEI)/a virtual local area network identifier (VID) (if any) in a TYPE field (TYPE)/Q-tag;

2. the table may be issued to the UE and RAN network element by QoS profile commands or QoS rule commands, respectively, in PDU session establishment or modification.

In this embodiment, the ethernet header compression flow:

before going to RAN network element through GTP tunnel, UPF removes specific Ethernet frame domain corresponding to association relation table from data packet of certain service data stream, and adds service data stream identification in package header;

after receiving a data packet corresponding to a certain service data flow, the RAN network element carries QoS ID and SDF ID in an SDAP subheader and delivers the SDF ID to a lower layer; the PDCP searches the association relation table to obtain the length of the sub-head of the Ethernet frame which is correspondingly compressed, and further determines the position for executing TCP/IP compression;

after receiving a data packet corresponding to certain service data, the PDCP entity of the UE searches the association relation table to obtain the length of the corresponding compressed Ethernet sub-frame, and further determines the position for executing TCP/IP decompression;

and before delivering the received data to an application layer, adding a protocol entity, obtaining the value of the compressed Ethernet frame domain by retrieving the association relation table, and recovering the Ethernet frame structure to complete decompression.

Example 4:

in this embodiment, the UE and the UPF are used as anchor points, and the newly added protocol entity is used as a functional entity to perform ethernet header compression on the uplink data.

When the UE submits the data from the upper layer application to the SDAP, indicating the service flow to which the data packet belongs;

The subsequent UE behavior is the same as the RAN network element behavior in embodiment 3;

when the RAN network element forwards the data packet to the UPF, a service data flow instruction needs to be added in an encapsulation packet header;

the behavior of the subsequent UPF is the same as the UE behavior in example 3;

the method in this embodiment is equally applicable to a scenario where UE and gNB are anchor points and an SDAP entity is a functional entity, which is not limited herein.

By adopting the method provided by the embodiment of the invention, the header compression processing in the Ethernet frame can be realized while the Ethernet frame is supported to be transmitted in the wireless mobile communication system, thereby reducing the resource overhead required by the 5G system for supporting the Ethernet frame to be transmitted.

Referring to fig. 4, fig. 4 is a block diagram of another transmitting end provided in an embodiment of the present invention, and as shown in fig. 4, a transmitting end 400 includes:

an obtaining module 401, configured to obtain a first data packet, where the first data packet includes a compressed ethernet header, a QoS flow identifier, and an SDF identifier;

a first sending module 402, configured to send the first data packet to a receiving end.

Optionally, the compressed ethernet header is an ethernet header from which a specific ethernet domain is removed.

Optionally, the specific ethernet frame field includes at least one of:

the media access control MAC source address field, MAC destination address field, type field, S-TAG field, TPID field, PCP field, drop identification DEI field and virtual local area network identifier VID field.

Optionally, the acquiring module 401 is configured to compress an ethernet header by the PDCP entity to obtain the first data packet.

Optionally, the obtaining module 401 is configured to receive, by the PDCP entity, an SDAP data packet delivered by a service data adaptation protocol SDAP entity, where the SDAP data packet carries the QoS flow identifier and the SDF identifier; and the PDCP entity is used for compressing the Ethernet frame header carried in the SDAP data packet so as to obtain the first data packet.

Optionally, as shown in fig. 5, the transmitting end 400 further includes:

a second sending module 403, configured to send a second data packet to the receiving end, where the second data packet includes an uncompressed ethernet header, the QoS flow identifier, and the SDF identifier.

Optionally, the obtaining module 401 is configured to compress the ethernet header to obtain the first data packet if a feedback message fed back by the receiving end is received, where the feedback message is used to indicate that a data packet including an uncompressed ethernet header is successfully received.

in the case where the SDF identity in the QoS flow is unique in the packet data unit session PDU session and the SDAP entity delivers the SDAP data packet in the QoS flow to the PDCP entity through a second DRB, the SDAP entity reuses the SDF identity in the first DRB in the second DRB; or alternatively

wherein the QoS flow corresponds to the QoS flow identifier.

Optionally, as shown in fig. 6, the transmitting end 400 further includes:

and a receiving module 404, configured to receive a data packet sent by a core network element and carrying the SDF identifier and the ethernet frame header that is not compressed.

Optionally, the acquiring module 401 is configured to compress the ethernet frame header by the PDCP entity according to a compression configuration, where the compression configuration is used for at least one of the following:

configuring Ethernet frame header compression for downlink data;

configuring Ethernet frame header compression for uplink data;

Optionally, the configuration granularity of the compression configuration is DRB, or QoS flow.

Alternatively, as shown in fig. 7, the acquisition module 401 includes:

a first obtaining unit 4011, configured to obtain a third data packet by an SDAP entity, where the third data packet includes a compressed ethernet header, and the third data packet further includes the SDF identifier and/or the QoS flow identifier;

A delivery unit 4012, configured to deliver, to the PDCP entity, an SDAP packet corresponding to the third data packet;

a second obtaining unit 4013, configured to obtain the first data packet based on the SDAP packet by the PDCP entity.

Optionally, the third data packet is received from a core network element, or the third data packet is delivered by an ethernet frame compression entity on the PDCP entity of the sender.

Optionally, the SDAP data packet includes the compressed ethernet header and an uncompressed TCP/IP header, and carries the QoS flow identifier and the SDF identifier, and the first obtaining unit 4013 is configured to compress the TCP/IP header by the PDCP entity to obtain the first data packet.

Optionally, the first obtaining unit 4013 is configured to determine a position of the TCP/IP header in the SDAP packet, and compress the TCP/IP header according to the position.

Optionally, the compressed ethernet header is an ethernet header from which a specific ethernet frame domain is removed, and the sending end obtains first relationship information corresponding to the SDF identifier, where the first relationship information includes a value of the specific ethernet frame domain.

Optionally, the first relationship information further includes length information of the compressed ethernet header, and the first obtaining unit 4013 is configured to determine, according to the length information, a position of the TCP/IP header in the SDAP packet.

Optionally, the sending end receives the first relation information in a PDU session establishment or modification process.

The transmitting end 400 can implement each process implemented by the transmitting end in the method embodiment of the present invention, and achieve the same beneficial effects, and in order to avoid repetition, a detailed description is omitted here.

Referring to fig. 8, fig. 8 is a block diagram of a receiving end according to an embodiment of the present invention, and as shown in fig. 8, a receiving end 800 includes:

a first receiving module 801, configured to receive a first data packet sent by a sending end, where the first data packet includes a compressed ethernet frame header, a quality of service QoS flow identifier, and a service data flow SDF identifier;

a first decompression module 802, configured to decompress the ethernet header.

Optionally, the first decompression module 802 is configured to add a value of a specific ethernet frame field that is not transmitted in the ethernet frame header.

Optionally, the specific ethernet frame field includes at least one of:

Optionally, the first decompression module 802 is configured to determine, according to the second relationship information corresponding to the SDF identifier, a value of the specific ethernet frame field that is not transmitted in the ethernet frame header, and add the value of the specific ethernet frame field to the ethernet frame header;

Optionally, as shown in fig. 9, the receiving end 800 further includes:

a second receiving module 803, configured to receive a second data packet sent by the sender, where the second data packet includes an uncompressed ethernet header, the QoS flow identifier, and the SDF identifier;

a storing module 804, configured to store a correspondence between the SDF identifier and the uncompressed ethernet header, so as to obtain the second relationship information.

Optionally, as shown in fig. 10, the receiving end 800 further includes:

a feedback module 805, configured to feedback a message to the sender, where the feedback message is used to indicate that a data packet including an uncompressed ethernet header is successfully received.

Optionally, as shown in fig. 11, the receiving end 800 further includes:

a second decompression module 806, configured to determine a location of decompression of the TCP/IP header, and decompress the TCP/IP header according to the location.

the second decompression module 806 is configured to determine, by the ethernet frame decompression entity according to the first relationship information, a value of the specific ethernet frame field that is not transmitted in the ethernet frame header, and add the value of the specific ethernet frame field to the ethernet frame header.

Optionally, the first relationship information further includes length information of the compressed ethernet header, and the second decompression module 806 is configured to determine a decompressed position of the TCP/IP header according to the length information.

The receiving end 800 can implement each process implemented by the receiving end in the method embodiment of the present invention, and achieve the same beneficial effects, and in order to avoid repetition, a description is omitted here.

Referring to figure 12 of the drawings in which, fig. 12 is a block diagram of a communication device according to an embodiment of the present invention. As shown in fig. 12, the communication apparatus 1200 includes: memory 1201, processor 1202, and computer program 12011 stored on memory 1201 and executable on processor 1202.

Wherein when the communication device 1200 is presented as a sender in the above-described method embodiment, the computer program 12011, when executed by the processor 1202, performs the steps of:

acquiring a first data packet, wherein the first data packet comprises a compressed Ethernet frame header, a quality of service QoS flow identifier and a service data flow SDF identifier;

and sending the first data packet to a receiving end.

Optionally, the specific ethernet frame field includes at least one of:

Optionally, the acquiring the first data packet performed by the processor 1202 includes:

Optionally, the PDCP entity executed by the processor 1202 compresses an ethernet header to obtain the first data packet, including:

the PDCP entity receives an SDAP data packet transmitted by a Service Data Adaptation Protocol (SDAP) entity, wherein the SDAP data packet carries the QoS flow identifier and the SDF identifier;

Optionally, before compressing the ethernet header to obtain the first data packet, the processor 1202 is further configured to:

Optionally, the compressing the ethernet header by the processor 1202 to obtain the first data packet includes:

wherein the QoS flow corresponds to the QoS flow identifier.

Optionally, the PDCP entity executed by the processor 1202 compresses an ethernet frame header, including:

configuring Ethernet frame header compression for downlink data;

configuring Ethernet frame header compression for uplink data;

Optionally, the configuration granularity of the compression configuration is DRB.

the PDCP entity obtains the first data packet based on the SDAP packet.

Optionally, the SDAP data packet includes the compressed ethernet header and an uncompressed TCP/IP header, and carries the QoS flow identifier and the SDF identifier, and the PDCP entity executed by the processor 1202 obtains the first data packet based on the SDAP packet, including:

the PDCP entity compresses the TCP/IP header to obtain the first data packet.

Optionally, the PDCP entity executed by the processor 1202 compresses the TCP/IP header, including:

Optionally, the first relationship information further includes length information of the compressed ethernet header, and the determining, performed by the processor 1202, the location of the TCP/IP header in the SDAP packet includes:

and determining the position of the TCP/IP header in the SDAP packet according to the length information.

When the communication device 1200 is embodied as a receiving end in the above-described method embodiment, the computer program 12011, when executed by the processor 1202, performs the steps of:

decompressing the Ethernet frame header.

Optionally, the decompressing the ethernet header performed by the processor 1202 includes:

Optionally, the specific ethernet frame field includes at least one of:

Optionally, the adding, by the processor 1202, a value of a specific ethernet frame field that is not transmitted in the ethernet frame header includes:

Optionally, before the receiving the first data packet sent by the sending end, the processor 1202 is further configured to:

Optionally, after receiving the second data packet sent by the sender, the processor 1202 is further configured to:

Optionally, the first data packet further includes a compressed TCP/IP header, and after the receiving the first data packet sent by the sending end, the processor 1202 is further configured to:

the adding, by the processor 1202, the value of the specific ethernet frame field that is not transmitted in the ethernet frame header includes:

Optionally, the first relationship information further includes length information of the compressed ethernet header, and the determining, performed by the processor 1202, a decompressed position of the TCP/IP header includes:

The communication device 1100 can implement each process implemented by the transmitting end and the receiving end in the above method embodiment, and in order to avoid repetition, a description is omitted here.

The embodiment of the invention also provides a computer readable storage medium, on which a computer program is stored, which when executed by a processor, implements each process of any of the above-mentioned ethernet frame transmission method embodiments, and can achieve the same technical effects, so that repetition is avoided, and no further description is given here. Wherein the computer readable storage medium is selected from Read-Only Memory (ROM), random access Memory (Random Access Memory, RAM), magnetic disk or 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 one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. ROM/RAM, magnetic disk, optical disk) comprising instructions for causing a terminal (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the method according to the embodiments of the present invention.

The embodiments of the present invention have been described above with reference to the accompanying drawings, but the present invention is not limited to the above-described embodiments, which are merely illustrative and not restrictive, and many forms may be made by those having ordinary skill in the art without departing from the spirit of the present invention and the scope of the claims, which are to be protected by the present invention.

Claims

1. An ethernet frame transmission method, applied to a transmitting end, is characterized in that the method comprises the following steps:

transmitting the first data packet to a receiving end;

the acquiring the first data packet includes:

the packet data convergence protocol PDCP entity compresses the Ethernet frame header to obtain the first data packet;

before the ethernet header is compressed to obtain the first data packet, the method further includes:

transmitting a second data packet to the receiving end, wherein the second data packet comprises an uncompressed Ethernet frame header, the QoS flow identifier and the SDF identifier;

The PDCP entity compresses an ethernet header to obtain the first data packet, including:

the PDCP entity compresses an Ethernet frame header carried in the SDAP data packet to obtain the first data packet;

wherein the SDAP entity transmits the SDAP data packet to the PDCP entity through a first data radio bearer DRB;

wherein the QoS flow corresponds to the QoS flow identifier.

2. The method of claim 1, wherein the compressed ethernet header is an ethernet header with a particular ethernet field removed.

3. The method of claim 2, wherein the particular ethernet frame field comprises at least one of:

the media access control MAC source address field, MAC destination address field, type field, outer label S-TAG field, label protocol identifier TPID field, priority code point PCP field, discard identity DEI field and virtual local area network identifier VID field.

4. The method of claim 1, wherein compressing the ethernet header to obtain the first data packet comprises:

5. The method of claim 1, wherein prior to compressing the ethernet header to obtain the first data packet, the method further comprises:

6. The method of claim 1, wherein the PDCP entity compresses an ethernet frame header, comprising:

configuring Ethernet frame header compression for downlink data;

configuring Ethernet frame header compression for uplink data;

7. The method of claim 6, wherein the configuration granularity of the compression configuration is DRB, or QoS flow.

8. A method according to any one of claims 1 to 3, wherein the acquiring the first data packet comprises:

the PDCP entity obtains the first data packet based on the SDAP packet.

9. The method of claim 8, wherein the third data packet is received from a core network element or is delivered by an ethernet frame compression entity over a PDCP entity of the sender.

10. The method of claim 9, wherein the SDAP data packet includes the compressed ethernet header and an uncompressed TCP/IP header and carries the QoS flow identification and the SDF identification, the PDCP entity obtaining the first data packet based on the SDAP packet, comprising:

the PDCP entity compresses the TCP/IP header to obtain the first data packet.

11. The method of claim 10, wherein the PDCP entity compresses the TCP/IP header, comprising:

12. The method of claim 11 wherein the compressed ethernet header is an ethernet header from which a particular ethernet field is removed, and the sender obtains first relationship information corresponding to the SDF identifier, where the first relationship information includes a value of the particular ethernet field.

13. The method of claim 12, wherein the first relationship information further comprises length information of the compressed ethernet header, the determining the location of the TCP/IP header in the SDAP packet comprising:

14. The method of claim 12, wherein the sender receives the first relationship information during PDU session establishment or modification.

15. An ethernet frame transmission method, applied to a receiving end, is characterized in that the method comprises the following steps:

decompressing the Ethernet frame header;

wherein said decompressing said ethernet header comprises:

wherein the second relationship information includes a correspondence of the SDF identification and an uncompressed ethernet header;

before the first data packet sent by the sending end is received, the method further comprises:

Storing the corresponding relation between the SDF identification and the uncompressed Ethernet frame header to obtain the second relation information;

the first data packet is a data packet determined by the transmitting end through the following modes:

a packet data convergence protocol PDCP entity receives an SDAP data packet transmitted by a service data adaptation protocol SDAP entity, wherein the SDAP data packet carries the QoS flow identifier and the SDF identifier;

Wherein the QoS flow corresponds to the QoS flow identifier.

16. The method of claim 15, wherein the particular ethernet frame domain comprises at least one of:

a MAC source address field, a MAC destination address field, a type field, an S-TAG field, a TPID field, a priority code point PCP field, a DEI field, and a VID field.

17. The method of claim 15, wherein after receiving the second data packet sent by the sender, the method further comprises:

18. The method according to claim 15 or 16, wherein the first data packet further comprises a compressed TCP/IP header, and the method further comprises, after the receiving the first data packet sent by the sender:

19. The method of claim 18, wherein the receiving end obtains first relationship information corresponding to the SDF identification, the first relationship information including a value of the particular ethernet frame domain;

20. The method of claim 19, wherein the first relationship information further comprises length information of the compressed ethernet header, the determining a location of decompression of the TCP/IP header comprising:

21. The method of claim 19, wherein the receiving end receives the first relationship information during PDU session establishment or modification.

22. A transmitting terminal, comprising:

the first sending module is used for sending the first data packet to a receiving end;

the acquiring module is configured to compress an ethernet header by using a packet data convergence protocol PDCP entity to obtain the first data packet;

The transmitting end further comprises:

a second sending module, configured to send a second data packet to the receiving end, where the second data packet includes an uncompressed ethernet frame header, the QoS flow identifier, and the SDF identifier;

Wherein the QoS flow corresponds to the QoS flow identifier.

23. A receiving terminal, comprising:

a first receiving module, configured to receive a first data packet sent by a sending end, the first data packet comprises a compressed Ethernet frame header, a quality of service QoS flow identifier and a service data flow SDF identifier;

the first decompression module is used for decompressing the Ethernet frame header;

the first decompression module is configured to determine a value of a specific ethernet frame field that is not transmitted in the ethernet frame header according to second relationship information corresponding to the SDF identifier, and add the value of the specific ethernet frame field to the ethernet frame header;

the receiving further comprises:

a second receiving module, configured to receive a second data packet sent by the sending end, where the second data packet includes an uncompressed ethernet frame header, the QoS flow identifier, and the SDF identifier;

wherein the QoS flow corresponds to the QoS flow identifier.

24. A communication device, comprising: memory, a processor and a program stored on the memory and executable on the processor, the program realizing the steps in the ethernet frame transmission method according to any of claims 1 to 14 when being executed by the processor, or the program realizing the steps in the ethernet frame transmission method according to any of claims 15 to 21 when being executed by the processor.

25. A computer readable storage medium, characterized in that the computer readable storage medium has stored thereon a computer program which, when executed by a processor, implements the steps of the ethernet frame transmission method according to any of claims 1 to 14 or which, when executed by the processor, implements the steps of the ethernet frame transmission method according to any of claims 15 to 21.