WO2021062728A1 - Procédé et dispositif de transmission de données - Google Patents

Procédé et dispositif de transmission de données Download PDF

Info

Publication number
WO2021062728A1
WO2021062728A1 PCT/CN2019/109639 CN2019109639W WO2021062728A1 WO 2021062728 A1 WO2021062728 A1 WO 2021062728A1 CN 2019109639 W CN2019109639 W CN 2019109639W WO 2021062728 A1 WO2021062728 A1 WO 2021062728A1
Authority
WO
WIPO (PCT)
Prior art keywords
type
packet
state
package
decompression
Prior art date
Application number
PCT/CN2019/109639
Other languages
English (en)
Chinese (zh)
Inventor
付喆
卢前溪
Original Assignee
Oppo广东移动通信有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oppo广东移动通信有限公司 filed Critical Oppo广东移动通信有限公司
Priority to PCT/CN2019/109639 priority Critical patent/WO2021062728A1/fr
Priority to CN201980095376.6A priority patent/CN113711627B/zh
Publication of WO2021062728A1 publication Critical patent/WO2021062728A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals

Definitions

  • the present invention relates to the field of data transmission technology, in particular to a data transmission method and device.
  • the existing communication system supports header compression for IP data packets in a PDU session (PDU session, PDU, namely Protocol Data Unit, protocol data unit).
  • PDU session PDU
  • PDU Protocol Data Unit
  • PDCP Packet Data Convergence Protocol
  • the current ROHC Robot Header Compression
  • DRB Data Radio Bearer, data radio bearer
  • the current RoHC configuration parameters are In the configuration in PDCP-config, each PDCP-config corresponds to a DRB.
  • the RoHC configuration parameter may be:
  • header compression cannot be performed on the Ethernet packet in the PDU session.
  • embodiments of the present invention provide a data transmission method and device.
  • the technical solution is as follows:
  • a data transmission method including:
  • the compression end sends a first-type packet; wherein the first-type packet includes at least: header information of an uncompressed Ethernet header;
  • the compression end sends a second-type packet; wherein the second-type packet includes at least: header information of the compressed Ethernet header.
  • the compression end sends a first type packet in a first state; and the compression end sends a second type packet in a second state.
  • the first state is an initial state or an uncompressed state; and/or, the second state is a compressed state.
  • the first type package and/or the second type package further include: a context identifier and/or a package type identifier;
  • the context identifier is used to identify the context corresponding to the first type package and/or the second type package
  • the package type identifier is used to identify the package as the first type package or the second type package.
  • the first type package is a complete package; and/or the second type package is a compressed package.
  • the method further includes:
  • the compression end transitions from the second state to the first state.
  • the method further includes:
  • the compression end sends a trigger indication to request to receive a third type packet with an ACK/NACK identifier
  • the compression end receives a third type packet with a NACK identifier
  • the compression end receives a third type packet with an ACK identifier
  • the compression end receives the third type of packet, but the third type of packet does not have an ACK/NACK identifier.
  • the method further includes:
  • the compression end When the compression end receives a third type packet or a third type packet with NACK, the compression end switches from the second state to the first state, and/or,
  • the compression end When the compression end receives a third type packet or a third type packet with an ACK, the compression end switches from the first state to the second state.
  • sending the first type of packet at the compression end specifically includes:
  • the compression end sends a first preset number of packets of the first type; wherein the packets of the first type at least include: header information of an uncompressed Ethernet header;
  • the first preset number is determined by the compression end, or the compression end is determined according to received configuration parameters.
  • the method specifically includes:
  • the compression end sends a first type packet
  • the compression end After the compression end receives the third type packet, the compression end switches from the first state to the second state and sends the second type packet;
  • the compression end After the compression end sends a first preset number of packets of the first type, the compression end switches from the first state to the second state and sends the second type packets;
  • the compression end sends a first preset number of packets of the first type
  • the compressing end After the compressing end sends a first preset number of packets of the first type and receives the third type of packets, the compressing end switches from the first state to the second state to send the second type of packets.
  • the third-type package includes at least a context identifier; wherein the context identifier is used to identify the context corresponding to the third-type package.
  • the third type packet includes an ACK/NACK identifier, and the ACK/NACK identifier is used to indicate that the receiving end receiving the first type packet and the second type packet responds to the first type packet And/or the processing result of the second type packet, or indicating whether the context information of the decompression end is saved.
  • the compression end sends the first type packet and the second type packet through a unidirectional link.
  • the second type packet has a cyclic redundancy check.
  • a data transmission method including:
  • the decompression end receives the first type packet and/or the second type packet; wherein the first type packet includes at least: uncompressed Ethernet header header information; wherein the second type packet includes at least: compressed The packet header information of the Ethernet header;
  • the decompression terminal performs processing according to the received first-type packet and second-type packet.
  • the decompression end receives the first type packet and/or the second type packet in the third state.
  • the decompression end processes the first type packet or the second type packet, and switches to the fourth state after the processing is successful.
  • the third state is a contextless state; and/or, the fourth state is a static context state or a full context state.
  • the first type package and/or the second type package further include: a context identifier and/or a package type identifier;
  • the context identifier is used to identify the context corresponding to the first type package and/or the second type package
  • the package type identifier is used to identify the package as the first type package or the second type package.
  • the first type package is a complete package; and/or the second type package is a compressed package.
  • the method further includes:
  • the decompression switches from the fourth state to the third state after receiving the first-type packet again or again.
  • the method further includes:
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful
  • the NACK flag is added to the third type packet and sent.
  • the method further includes:
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful
  • the NACK identifier is added to the third type packet and sent; and the decompression end switches from the fourth state to the third state.
  • the method further includes:
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful
  • the third type packet is not sent.
  • the method further includes:
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful
  • the third type packet is not sent.
  • the third-type package includes at least a context identifier; wherein the context identifier is used to identify the context corresponding to the third-type package.
  • the decompression end receiving the first type packet and/or the second type packet specifically includes:
  • the decompression end receives the first type packet
  • the decompression end sends a third-type packet to request to receive the second-type packet
  • the decompression end receives the second type packet.
  • the decompression end receiving the first type packet and/or the second type packet specifically includes:
  • the decompression end receives the second type packet
  • the decompression end sends a third type of packet to request to receive the first type of packet
  • the decompression end receives the first type packet.
  • the decompression end receives the first type packet and the second type packet through a unidirectional link.
  • the method further includes:
  • the decompression terminal After the decompression terminal receives the first type packet again in the fourth state, the decompression terminal switches the decompression terminal from the fourth type to the third state.
  • the method further includes:
  • the third type packet includes an ACK/NACK identifier used to identify whether the processing of the received first type packet or the second type packet by the decompression end is successful;
  • the decompression end transitions from the fourth state to the third state
  • the decompression end transitions from the third state to the fourth state.
  • the method further includes: the decompression end is used to determine whether the decompression is successful and/or the context is valid according to the cyclic redundancy check in the second type of packet.
  • a data transmission method including:
  • the compression end sends N packets of the first type in the first state; wherein the packet of the first type includes at least: header information of an uncompressed Ethernet header;
  • the compression terminal After sending N packets of the first type, the compression terminal switches from the first state to the second state, and sends one or more packets of the second type; wherein the second type of packets at least include: compressed ether The header information of the net header;
  • the decompression end receives the first type packet in the third state
  • the decompression end After the decompression end receives the second type packet in the third state, it processes the second type packet and determines whether the processing is successful. If so, the decompression end switches to the fourth state, if otherwise, the decompression end is in the third state.
  • the third type of packet is sent in the state so that the compression end retransmits the first type of packet.
  • the method further includes:
  • the compression terminal switches from the second state to the first state, and sends the first type packet
  • the decompressor When the decompressor receives the first type packet again, the decompressor switches from the fourth state to the third state and receives the first type packet.
  • the method further includes:
  • the compression end After the context information is changed by the compression end, or after the compression end is in the second state for the first time period, the compression end switches from the second state to the first state and resends the first type of packet.
  • the method further includes:
  • the compression end sends a trigger request to the decompression end to request the decompression end to send the processing result of the first type packet or the second type packet;
  • the decompression end After receiving the trigger request, the decompression end sends a third type packet to the compression end; when the identification is a processing failure, the decompression end switches from the fourth state to the third state and receives The first type of packet; when the identifier is processed successfully, the decompression end maintains the fourth state.
  • the method further includes:
  • the decompression end sends a third type packet with an ACK identifier to the compression end; where the ACK identifier is used to indicate that the decompression end successfully processed the first type packet or the second type packet.
  • the method further includes:
  • the decompression end sends a third type packet with a NACK identifier to the compression end; the NACK identifier is used to indicate that the decompression end fails to process the first type packet or the second type packet.
  • the first state is an initial state or an uncompressed state; and/or, the second state is a compressed state; and/or, the third state is a contextless state; and/or, The fourth state is a static context state or a full context state.
  • the first type package is a complete package; and/or the second type package is a compressed package; and/or the third type package is a feedback package;
  • the first type package and/or the second type package further include: a context identifier and/or a package type identifier; wherein the context identifier is used to identify the context corresponding to the first type package and/or the second type package , Wherein the package type identifier is used to identify the package as a first-type package or a second-type package.
  • the third type package includes a context identifier; wherein the context identifier is used to identify the context corresponding to the third type package.
  • the second type packet contains a cyclic redundancy check code.
  • the decompression end is used to determine whether the decompression is successful and/or the context is valid according to the cyclic redundancy check in the second type of packet.
  • a data transmission method including:
  • the compression end sends the first type of packet in the first state; wherein the first type of packet at least includes: header information of an uncompressed Ethernet header;
  • the decompression end receives the first type packet in the third state
  • the decompression end sends a third-type packet to feed back the reception and/or processing result of the first-type packet;
  • the compression end After the compression end receives a first preset number of packets of the first type and receives the third type packet sent by the decompression end, or after the compression end sends the first type packet and receives the third type packet sent by the decompression end, or After the compression end sends the first type packet and receives the third type packet including the ACK identifier sent by the decompression end, the compression end switches to the second state and sends the second type packet; wherein the second type packet is At least include: the header information of the compressed Ethernet header.
  • the method further includes:
  • the decompression end After receiving the first type of packet, the decompression end sends a third type of packet to feed back the reception and/or processing result of the first type of packet.
  • the feedback packet includes at least a context identifier; wherein the context identifier is used To identify the context corresponding to the third type of package.
  • the method further includes:
  • the compression end After the context information is changed by the compression end, or after the compression end is in the second state for the first time period, the compression end switches from the second state to the first state, and resends the first type of packet.
  • the method further includes:
  • the compression end sends a trigger request to the decompression end to request the decompression end to send the processing result of the first type packet or the second type packet;
  • the decompression end After receiving the trigger request, the decompression end sends a third type packet to the compression end; when the processing fails, the decompression end switches from the fourth state to the third state, and receives the compression end again The first type of packet sent in the first state; when the processing is successful, the decompression end maintains the fourth state.
  • the method further includes:
  • the decompression end sends a third type packet with an ACK identifier to the compression end; where the ACK identifier is used to indicate that the decompression end successfully processed the first type packet or the second type packet.
  • the method further includes:
  • the decompression end sends a third type packet with a NACK identifier to the compression end; wherein the NACK identifier is used to indicate that the decompression end fails to process the first type packet or the second type packet.
  • the first state is an initial state or an uncompressed state; and/or, the second state is a compressed state; and/or, the third state is a contextless state; and/or, The fourth state is a static context state or a full context state.
  • the first type package is a complete package; and/or the second type package is a compressed package; and/or the third type package is a feedback package;
  • the first type package and/or the second type package further include: a context identifier and/or a package type identifier; wherein the context identifier is used to identify the context corresponding to the first type package and/or the second type package , Wherein the package type identifier is used to identify the package as a first-type package or a second-type package.
  • the third type package includes a context identifier; wherein the context identifier is used to identify the context corresponding to the third type package.
  • a data transmission method including:
  • the compression end sends N packets of the first type through a unidirectional link in the first state; wherein the packets of the first type include at least: header information of an uncompressed Ethernet header;
  • the compression terminal After sending N packets of the first type, the compression terminal switches from the first state to the second state, and sends one or more packets of the second type; wherein the second type of packets at least include: compressed ether The header information of the net header;
  • the decompression end After receiving M packets of the first type in the third state, the decompression end switches to the fourth state, and processes the first type packets and/or the second type packets.
  • the method further includes:
  • the compression terminal switches from the second state to the first state, and sends the first type packet
  • the decompression end switches from the fourth state to the third state.
  • the first state is an initial state or an uncompressed state; and/or, the second state is a compressed state; and/or, the third state is a contextless state; and/or, The fourth state is a static context state or a full context state.
  • the first type package is a complete package; and/or the second type package is a compressed package; and/or the third type package is a feedback package;
  • the first type package and/or the second type package further include: a context identifier and/or a package type identifier; wherein the context identifier is used to identify the context corresponding to the first type package and/or the second type package , Wherein the package type identifier is used to identify the package as a first-type package or a second-type package.
  • the third type package includes a context identifier; wherein the context identifier is used to identify the context corresponding to the third type package.
  • the second type packet has a cyclic redundancy check.
  • the unidirectional link includes at least one of the following:
  • a data transmission device which is arranged at the compression end, and includes:
  • the first sending module is configured to send a first type of packet; wherein the first type of packet includes at least: header information of an uncompressed Ethernet header;
  • the second sending module is configured to send a second type of packet; wherein the second type of packet includes at least: header information of a compressed Ethernet header.
  • the first sending module sends the first type of packet in the first state; and the second sending module sends the second type of packet in the second state.
  • the first state is an initial state or an uncompressed state; and/or, the second state is a compressed state.
  • the first type package and/or the second type package further include: a context identifier and/or a package type identifier;
  • the context identifier is used to identify the context corresponding to the first type package and/or the second type package
  • the package type identifier is used to identify the package as the first type package or the second type package.
  • the first type package is a complete package; and/or the second type package is a compressed package.
  • the device further includes:
  • the update module is used to make the compression end switch from the second state to the first state when the context information of the compression end changes, or the compression end is in the compression state for a first period of time.
  • the device further includes a receiving module, and the receiving module is configured to perform the following operations:
  • the device further includes a switching module, and the switching module is configured to perform the following operations:
  • the compression end When the compression end receives a third type packet or a third type packet with NACK, the compression end switches from the second state to the first state, and/or,
  • the compression end When the compression end receives a third type packet or a third type packet with an ACK, the compression end switches from the first state to the second state.
  • the first sending module is configured to perform the following operations:
  • the first preset number is determined by the compression end, or the compression end is determined according to received configuration parameters.
  • the device performs the following operations:
  • the first sending module sends the first type of packet
  • the switching module switches the compression terminal from the first state to the second state and sends the second type packet through the second sending module;
  • the switching module switches the compression end from the first state to the second state and sends the second type of packets through the second sending module;
  • the first sending module sends a first preset number of packets of the first type
  • the switching module switches the compression end from the first state to the second state and sends the first packet through the second sending module Two types of packages.
  • the third-type package includes at least a context identifier; wherein the context identifier is used to identify the context corresponding to the third-type package.
  • the third type packet includes an ACK/NACK identifier, and the ACK/NACK identifier is used to indicate that the receiving end receiving the first type packet and the second type packet responds to the first type packet And/or the processing result of the second type packet, or indicating whether the context information of the decompression end is saved.
  • the compression end sends the first type packet and the second type packet through a unidirectional link.
  • the second type packet has a cyclic redundancy check.
  • a data transmission device which is arranged at the decompression end, and includes:
  • the first receiving module is configured to receive a first type packet and/or a second type packet; wherein the first type packet includes at least: uncompressed Ethernet header header information; wherein the second type packet includes at least Including: the header information of the compressed Ethernet header;
  • the processing module is used to process the received packets of the first type and the second type.
  • the first receiving module receives the first type packet and/or the second type packet in the third state.
  • the processing module is configured to process the first type of packet or the second type of packet, and switch to the fourth state after the processing is successful.
  • the third state is a contextless state; and/or, the fourth state is a static context state or a full context state.
  • the first type package and/or the second type package further include: a context identifier and/or a package type identifier;
  • the context identifier is used to identify the context corresponding to the first type package and/or the second type package
  • the package type identifier is used to identify the package as the first type package or the second type package.
  • the first type package is a complete package; and/or the second type package is a compressed package.
  • the receiving module is further configured to perform the following operations:
  • the decompression switches from the fourth state to the third state after receiving the first-type packet again or again.
  • processing module is further configured to perform the following operations:
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful
  • the NACK flag is added to the third type packet and sent.
  • the method further includes:
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful
  • the NACK identifier is added to the third type packet and sent; and the decompression end switches from the fourth state to the third state.
  • processing module is further configured to perform the following operations:
  • the third type packet is not sent.
  • processing module is further configured to perform the following operations:
  • the third type packet is not sent.
  • the third-type package includes at least a context identifier; wherein the context identifier is used to identify the context corresponding to the third-type package.
  • the first receiving module is configured to perform the following operations:
  • the first receiving module is configured to perform the following operations:
  • the decompression end receives the first type packet and the second type packet through a unidirectional link.
  • the first receiving module is further configured to perform the following operations:
  • the decompression terminal After the decompression terminal receives the first type packet again in the fourth state, the decompression terminal switches the decompression terminal from the fourth type to the third state.
  • the device further includes a sending module
  • the sending module is configured to send a third type packet after the decompression end receives a trigger instruction
  • the third type packet includes an ACK/NACK identifier used to identify whether the processing of the received first type packet or the second type packet by the decompression end is successful;
  • the decompression end transitions from the fourth state to the third state
  • the decompression end transitions from the third state to the fourth state.
  • the decompression end is used to determine whether the decompression is successful and/or the context is valid according to the cyclic redundancy check in the second type of packet.
  • a data transmission system including a compression end and a decompression end:
  • the compression end sends N packets of the first type in the first state; wherein the packet of the first type includes at least: header information of an uncompressed Ethernet header;
  • the compression terminal After sending N packets of the first type, the compression terminal switches from the first state to the second state, and sends one or more packets of the second type; wherein the second type of packets at least include: compressed ether The header information of the net header;
  • the decompression end receives the first type packet in the third state
  • the decompression end After the decompression end receives the second type packet in the third state, it processes the second type packet and determines whether the processing is successful. If so, the decompression end switches to the fourth state, if otherwise, the decompression end is in the third state.
  • the third type of packet is sent in the state so that the compression end retransmits the first type of packet.
  • the compression terminal switches from the second state to the first state, and sends the first type packet
  • the decompression end switches from the fourth state to the third state and receives the first type packet.
  • the compression end sends a trigger request to the decompression end to request the decompression end to send the processing result of the first type packet or the second type packet;
  • the decompression end After receiving the trigger request, the decompression end sends a third type packet to the compression end; when the identification is a processing failure, the decompression end switches from the fourth state to the third state and receives The first type of packet; when the identifier is processed successfully, the decompression end maintains the fourth state.
  • the decompression end sends a third type packet with an ACK identifier to the compression end; where the ACK identifier is used to indicate that the decompression end successfully processed the first type packet or the second type packet.
  • the decompression end sends a third type packet with a NACK identifier to the compression end; the NACK identifier is used to indicate that the decompression end fails to process the first type packet or the second type packet.
  • a data transmission system including a compression end and a decompression end:
  • the compression end sends the first type of packet in the first state; wherein the first type of packet at least includes: header information of an uncompressed Ethernet header;
  • the decompression end receives the first type packet in the third state
  • the decompression end sends a third-type packet to feed back the reception and/or processing result of the first-type packet;
  • the compression end After the compression end receives a first preset number of packets of the first type and receives the third type packet sent by the decompression end, or after the compression end sends the first type packet and receives the third type packet sent by the decompression end, or After the compression end sends the first type packet and receives the third type packet including the ACK identifier sent by the decompression end, the compression end switches to the second state and sends the second type packet; wherein the second type packet is At least include: the header information of the compressed Ethernet header.
  • the decompression end after receiving the first type of packet, sends a third type of packet to feed back the reception and/or processing result of the first type of packet, and the feedback packet It includes at least a context identifier; wherein the context identifier is used to identify the context corresponding to the third type of package.
  • the compression terminal switches from the second state to the first state after the context information changes, or the compression terminal is in the second state for a first time period, And resend the first type packet.
  • the compression end sends a trigger request to the decompression end to request the decompression end to send the processing result of the first type packet or the second type packet;
  • the decompression end After receiving the trigger request, the decompression end sends a third type packet to the compression end; when the processing fails, the decompression end switches from the fourth state to the third state, and receives the compression end again The first type of packet sent in the first state; when the processing is successful, the decompression end maintains the fourth state.
  • the decompression end sends a third type packet with an ACK identifier to the compression end; where the ACK identifier is used to indicate that the decompression end successfully processed the first type packet or the second type packet;
  • the decompression end sends a third type packet with a NACK identifier to the compression end; the NACK identifier is used to indicate that the decompression end fails to process the first type packet or the second type packet.
  • a data transmission system including a compression end and a decompression end:
  • the compression end sends N packets of the first type through a unidirectional link in the first state; wherein the packets of the first type include at least: header information of an uncompressed Ethernet header;
  • the compression terminal After sending N packets of the first type, the compression terminal switches from the first state to the second state, and sends one or more packets of the second type; wherein the second type of packets at least include: compressed ether The header information of the net header;
  • the decompression end After receiving M packets of the first type in the third state, the decompression end switches to the fourth state, and processes the first type packets and/or the second type packets.
  • the compression terminal switches from the second state to the first state, and sends the first type packet
  • the decompression end switches from the fourth state to the third state.
  • the second type packet has a cyclic redundancy check.
  • the unidirectional link includes at least one of the following:
  • the beneficial effect of the technical solution provided by the embodiment of the present invention is that the above-mentioned embodiment proposes a data transmission method, which can realize the data transmission of the Ethernet header compression.
  • Fig. 1 is a schematic flowchart of a data transmission method provided by an exemplary embodiment of the present application
  • Fig. 2 is a schematic flowchart of another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 3 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 4 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 5 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 6 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 7 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 8 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 9 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 10 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 11 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 12 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 13 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 14 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 15 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 16 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 17 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 18 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 19 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 20 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 21 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 22 is a schematic flowchart of yet another data transmission method provided by an exemplary embodiment of the present application.
  • FIG. 23 is a schematic diagram of modules of another data transmission device provided by an exemplary embodiment of the present application.
  • FIG. 24 is a schematic diagram of modules of yet another data transmission device provided by an exemplary embodiment of the present application.
  • FIG. 25 is a schematic diagram of modules of a data transmission system provided by an exemplary embodiment of the present application.
  • the technical solutions of the embodiments of the present invention may be applied to the field of Industrial Internet of Things (IIoT).
  • IIoT is the conversion of sensor data streams into useful information.
  • 5G IIoT needs to support the transmission of services such as Factory automation, Transport Industry, and Electrical Power Distribution in 5G systems.
  • IIoT introduces the concept of time-sensitive network TSN network or TSC, and requires header compression processing for TSN services.
  • the IP packet type can also be the Ethernet frame type.
  • the data packets corresponding to the PDU session are IPv4 packets and/or IPv6 packets; and when the PDU session type is IPv4 or IPv6 or IPv4v6,
  • the session type is Ethernet
  • the data packet corresponding to the PDU session is an Ethernet frame.
  • PDCP Packet Data Convergence Protocol, Packet Data Convergence Protocol introduces header compression and decompression functions, which can perform header compression on IP data packets.
  • the current ROHC Robot Header Compression
  • DRB Data Radio Bearer, data radio bearer
  • the current RoHC configuration parameters are In the configuration in PDCP-config, each PDCP-config corresponds to a DRB.
  • the RoHC configuration parameter may be:
  • TSC services can be carried by Ethernet frames or IP packets.
  • Ethernet header compression should be based on the following premises:
  • Ethernet Header Compression is configured by multiple DRBs, and is independent for upstream (UpLink, UL) and downstream (DownLink, DL) (Ethernet Header Compression (EHC) is configured per DRB, separately) for UL and DL);
  • context ID Context ID
  • context ID concept such that compressor and decompressor associates a context ID with Ethernet header contents
  • the compression end transmits at least one complete packet including a complete header and a context identifier (to establish a context on the decompression end); (For Ethernet flow resulting in creation of new context, compressortransmits at least one packet with full header and context id (to establish context in decompressor).
  • the compression end starts to transmit the compressed packet; when multiple transmissions are performed, FFS (For Further Study) and/or feedback are performed. (After above, compressor starts transmits compressed packets.FFS if multiple transmissions and/or feedback is needed.)
  • the EHC header format needs to have the following necessary fields: context ID, indication of header format (for example, complete header and compressed header), and other fields of FFS, such as configuration file identifier ( profile ID).
  • EHC header format is designed to include following mandatory fields: Context ID, Indication of header format (i.e. full header and compressed header), FFS other field, e.g. profile ID).
  • Ethernet Header Compression (EHC)
  • FIG. 1 a data transmission method in Ethernet Header Compression (EHC) is proposed, as shown in FIG. 1, including:
  • Step 1101 The compression end sends a first preset number of packets of the first type; wherein the packets of the first type include at least: header information of an uncompressed Ethernet header;
  • Step 1102 The compression end sends a second-type packet; wherein the second-type packet includes at least: header information of the compressed Ethernet header.
  • the first type of packet is a full packet
  • the second type of packet is a compressed packet.
  • the complete packet includes header information of an uncompressed Ethernet header.
  • the complete package may also include: Context ID and/or package type identifier. It may further include profile information.
  • the context ID (Context ID) is used for compression at the compression end and/or used for decompression at the decompression end.
  • the compressed packet includes header information of the compressed Ethernet header.
  • the compressed package may further include: a context ID and/or a package type identifier. It may further include profile information.
  • context information such as a context ID (Context ID) is used for compression at the compression end and/or used for decompression at the decompression end.
  • the method as shown in FIG. 2 includes:
  • Step 1101A The compression end sends a first preset number of complete packets in the first state; wherein the complete packet includes at least: header information of an uncompressed Ethernet header;
  • Step 1102A The compression end switches to the second state and sends a compressed packet; wherein the compressed packet includes at least: header information of the compressed Ethernet header.
  • the compression end is in a different state when sending the complete package and the compressed package.
  • the first state may be an initial state IR (initialization and Refresh) or an uncompressed state UC (Uncompression).
  • the second state may be a compression state CO (Compression order).
  • the method as shown in Fig. 3 specifically includes:
  • Step 1101B The compression end sends a first preset number of complete packets in the initial state IR or the uncompressed state UC; wherein the first type of packet includes at least: uncompressed Ethernet header header information;
  • Step 1102B The compression end switches to the compression state CO and sends the compressed packet; wherein the compressed packet includes at least: header information of the compressed Ethernet header.
  • the first preset number is N, and the first preset number can be configured by any device to the compression end through any kind of signaling, or it can be
  • the compression terminal determines by itself, or may be pre-stored in the compression terminal, which is not limited in the embodiment of the present invention.
  • the compressed package can be one or more, that is, one or more compressed packages can be sent after N complete packages are sent.
  • the data transmission method further includes:
  • Step 1103 The compression end receives the feedback packet returned by the decompression end; when the compression end determines that the processing of the decompression end is unsuccessful according to the feedback packet, the compression end switches from the compressed state CO to the initial state IR or the uncompressed state UC, And jump to step 1101 or 1101A or 1101B.
  • the third-type packet has an ACK/NACK identifier to identify success/failure; or the compression end receives a third-type packet with a NACK identifier, then it is determined; or, the The compression terminal receives the third type packet with the ACK identifier to identify success; or, the compression terminal receives the third type packet, but the third type packet does not have the ACK/NACK identifier.
  • the data transmission method further includes:
  • Step 1104 When the context information of the compression end changes, or the compression end is in the compressed state CO for a first period of time, the compression end switches from the compressed state CO to the initial state IR or the uncompressed state UC, and jumps to Step 1101 or 1101A or 1101B.
  • the context information change occurs after the compression end switches from the initial state IR or the uncompressed state UC to the compressed state CO, that is, after the compression end sends the first preset number of packets of the first type , Or after the compression end receives the feedback packet sent by the decompression end.
  • the data transmission method further includes:
  • Step 1104A the compression end sends a trigger instruction to request the decompression end to return a feedback packet; when the compression end determines that the decompression end has not processed successfully, the compression end switches from the compressed state CO to the initial state IR or the uncompressed state UC, and skips Go to step 1101 or 1101A or 1101B.
  • the first type of packet is a full packet
  • the second type of packet is a compressed packet
  • the first state may be an initial state IR (initialization and Refresh) or an uncompressed state UC (Uncompression).
  • the second state may be a compression state CO (Compression order).
  • the trigger indication is a message sent by the compression end to the decompression end for requesting a feedback packet.
  • the context information of the compression end changes, or after the compression state CO reaches a certain time, or the feedback packet obtained by the sent trigger indication indicates that the complete packet and/or the compressed packet has not been successfully processed, the context information of the decompression end Update.
  • the compression end switches to the initial state IR or the uncompressed state UC again, and re-executes the method of step 1101-step 1102 or step 1101A-step 1102A or step 1101B-step 1102B to resend the context information.
  • the trigger indication can be sent in the aforementioned compressed packet, or sent in the aforementioned complete packet, or can be sent through any possible signaling.
  • the compression end sends a trigger indication to request to receive a third type packet with an ACK/NACK identifier; or, the compression end receives a third type packet with a NACK identifier; or, the compression end receives a packet with an ACK identifier
  • the decompression end determines whether the processing of the first type packet and/or the second type packet is successful; if it succeeds, the third type packet is sent; if it fails, the NACK flag is added To the third type of packet and send. That is: in the above-mentioned embodiment, if the compression end receives a third type packet with no identification, it is considered that the decompression end has processed successfully; if the compression end receives a third type packet with a NACK flag, it is considered that the decompression end The processing failed.
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it succeeds, the step ends; if it fails, the NACK flag is added to the third type packet And send. That is, in the above embodiment, if the compression end does not receive the feedback packet, it is considered that the decompression end has processed successfully; if the compression end receives a third type packet with a NACK flag, it is considered that the decompression end has failed in processing.
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it succeeds, the ACK identifier is added to the third type packet and sent; if it fails Then the step ends. That is, in the above embodiment, if the compression end receives a third type packet with an ACK identifier, it is considered that the decompression end has processed successfully; if the compression end does not receive the third type packet, it is considered that the decompression end has failed in processing.
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it fails, the third type packet is sent; if it succeeds, the third type packet is not sent . That is: in the above-mentioned embodiment, if the compression end receives a third type packet with no identification, it is considered that the decompression end has processed successfully; if the compression end receives a third type packet with a NACK flag, it is considered that the decompression end The processing failed.
  • the compression end does not receive the third type of packet, it means that the decompression end has processed successfully; correspondingly, if the third type of packet is received, regardless of whether the third type of packet includes an identifier, the decompression end has failed to process Up.
  • the compression end does not receive the third type of packet, it means that the decompression end has failed to process; correspondingly, if the third type of packet is received, regardless of whether the third type of packet includes an identifier, it means that the decompression end has processed successfully Up.
  • the compression end receives the third type packet without identification, it means that the decompression end has processed successfully; correspondingly, if it receives the third type with identification (it can be an ACK/NACK identification or any other form of identification) Type package, it means that the decompression end processing failed.
  • the compression end receives the third type packet without identification, it means that the decompression end has failed to process; correspondingly, if it receives the third type with an identification (it can be an ACK/NACK identification or any other form of identification) Type package, it means that the decompression end processing is successful.
  • the feedback packet includes at least a context ID (Context ID).
  • the context ID (Context ID) is used to identify the context corresponding to the feedback packet, so that the compression end can perform compression and/or the decompression end can perform decompression.
  • the feedback packet has an indicator to indicate the feedback of the decompression end.
  • the indication identifier may be ACK/NACK to indicate feedback from the decompression end.
  • ACK is used to indicate that the decompression end successfully decompresses the compressed packet, or the decompression end successfully establishes a context, or the decompression end successfully saves a valid context
  • NACK is used to indicate that the decompression end failed Decompress the compressed packet, or the decompression end fails to successfully establish a context, or the decompression end fails to successfully save a valid context
  • the decompression end may not successfully decompress the compressed packet, or fail to successfully establish the context, or fail to successfully save the valid context, then send the feedback packet with the NACK flag; if all The decompression end successfully decompresses the compressed packet, or successfully establishes the context, or successfully saves the valid context; then the feedback packet with the ACK identifier is sent, or the feedback packet is not sent. That is to say, when the compression end does not receive any feedback packet, the compression end considers that the decompression end has successfully decompressed the compressed packet, or successfully established the context, or successfully saved the valid context.
  • the above-mentioned compressed package may also include a cyclic redundancy check (Cyclic Redundancy Check, CRC), which is used by the decompressor to determine the CRC according to the CRC in the compressed package after receiving the compressed package.
  • CRC Cyclic Redundancy Check
  • the compressed package is checked to determine whether the decompression is successful and/or the context is valid. If it is determined that the decompression fails and/or the context is invalid, that is, the CRC check fails, the decompression end needs to send a feedback packet to the compression end.
  • the data transmission method as shown in FIG. 4 includes:
  • Step 2101 The decompression end receives the first type packet and/or the second type packet; wherein the first type packet includes at least: uncompressed Ethernet header header information; wherein the second type packet includes at least : The header information of the compressed Ethernet header;
  • Step 2102 The decompression end performs processing according to the received first-type packet and/or second-type packet.
  • the first type of packet is a full packet
  • the second type of packet is a compressed packet.
  • the complete packet includes header information of an uncompressed Ethernet header.
  • the complete package may also include: Context ID and/or package type identifier. It may further include profile information.
  • the context ID (Context ID) is used for compression at the compression end and/or used for decompression at the decompression end.
  • the compressed packet includes header information of the compressed Ethernet header.
  • the compressed package may further include: a context ID and/or a package type identifier. It may further include profile information.
  • context information such as context ID (Context ID) is used for compression at the compression end and/or used for decompression at the decompression end.
  • the decompression end receives the first type packet and/or the second type packet in the third state; and the decompression end receives the first type packet and/or the second type packet according to the The packet is processed and switched to the fourth state after the processing is successful.
  • the method shown in Figure 5 includes:
  • Step 2101A The decompression end receives the complete packet and the compressed packet in the third state; wherein the complete packet includes at least: uncompressed Ethernet header header information; wherein the compressed packet includes at least: compressed Ethernet Header information;
  • Step 2102A The decompression end processes the received complete package and/or compressed package, and after successful processing, the decompression end switches from the third state to the fourth state.
  • the third state may be an initial no context state NC (no context); wherein, the fourth state may be a static context state SC (static context) or a full context state FC (full context state). context).
  • NC no context
  • SC static context
  • FC full context state
  • the method may specifically include as shown in FIG. 6:
  • Step 2101B The decompression end receives the complete packet and the compressed packet in the initial non-context state NC; wherein the complete packet includes at least: uncompressed Ethernet header header information; wherein the compressed packet includes at least: compression The packet header information of the Ethernet header;
  • Step 2102B the decompression end processes according to the received complete package and compressed package, and judges whether the processing is successful; if the processing fails, the third type of package is sent to feedback failure information; if the processing is successful, the third type of package is sent to feedback the failure Information, and the decompression end switches from the non-context state NC to the static context state SC or the full context state FC.
  • the third type of packet is a feedback packet; the feedback packet includes at least a context ID (Context ID).
  • the context identifier is used to identify the context to which it belongs, so that the compression end can perform compression and/or the decompression end can perform decompression.
  • the third type packet has an indicator to indicate feedback from the decompression end.
  • the indication identifier may be ACK/NACK to indicate feedback from the decompression end.
  • ACK is used to indicate that the decompression end successfully decompresses the compressed packet, or the decompression end successfully establishes a context, or the decompression end successfully saves a valid context
  • NACK is used to indicate that the decompression end failed Decompress the compressed packet, or the decompression end fails to successfully establish a context, or the decompression end fails to successfully save a valid context
  • the decompression end may not successfully decompress the compressed packet, or fail to successfully establish the context, or fail to successfully save the valid context, then send the feedback packet with the NACK flag; if all The decompression end successfully decompresses the compressed packet, or successfully establishes the context, or successfully saves the valid context; then the feedback packet with the ACK identifier is sent, or the feedback packet is not sent. That is to say, when the compression end does not receive any feedback packet, the compression end considers that the decompression end has successfully decompressed the compressed packet, or successfully established the context, or successfully saved the valid context.
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it succeeds, the third type packet is sent; if it fails, the NACK flag is added to the first type packet.
  • Three types of packages are sent and sent. That is: in the above-mentioned embodiment, if the compression end receives a third type packet with no identification, it is considered that the decompression end has processed successfully; if the compression end receives a third type packet with a NACK flag, it is considered that the decompression end The processing failed.
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it succeeds, the step ends; if it fails, the NACK flag is added to the third type packet And send. That is, in the above embodiment, if the compression end does not receive the feedback packet, it is considered that the decompression end has processed successfully; if the compression end receives a third type packet with a NACK flag, it is considered that the decompression end has failed in processing.
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it succeeds, the ACK identifier is added to the third type packet and sent; if it fails Then the step ends. That is, in the above embodiment, if the compression end receives a third type packet with an ACK identifier, it is considered that the decompression end has processed successfully; if the compression end does not receive the third type packet, it is considered that the decompression end has failed in processing.
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it fails, the third type packet is sent; if it succeeds, the third type packet is not sent . That is, in the above-mentioned embodiment, if the compression end receives an unidentified third-type packet, it is considered that the processing of the decompression end has failed; if it is not received, it is considered a success.
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it succeeds, the third type packet is sent; if it fails, the third type packet is not sent . That is, in the above-mentioned embodiment, if the compression end receives a third-type packet with no identification, it is considered that the processing of the decompression end is successful; if it is not received, it is considered a failure.
  • the compression end does not receive the third type of packet, it means that the decompression end has processed successfully; correspondingly, if the third type of packet is received, regardless of whether the third type of packet includes an identifier, the decompression end has failed to process Up.
  • the compression end does not receive the third type of packet, it means that the decompression end has failed to process; correspondingly, if the third type of packet is received, regardless of whether the third type of packet includes an identifier, it means that the decompression end has processed successfully Up.
  • the compression end receives the third type packet without identification, it means that the decompression end has processed successfully; correspondingly, if it receives the third type with identification (it can be an ACK/NACK identification or any other form of identification) Type package, it means that the decompression end processing failed.
  • the compression end receives the third type packet without identification, it means that the decompression end has failed to process; correspondingly, if it receives the third type with an identification (it can be an ACK/NACK identification or any other form of identification) Type package, it means that the decompression end processing is successful.
  • the method further includes context updating, that is, the method further includes:
  • Step 2103 When the decompression end receives the complete package and the compressed package again in the static context state SC or the full context state FC, the decompression end switches from the static context state SC or the full context state FC to the non-context state NC, And jump to step 2102 (or 2102A or 2102B or 2102C).
  • the complete package and compressed package received by the decompression end in step 2103 are changes in the context information of the compression end, or the compression end is in the compressed state for the first period of time after CO, or after sending a trigger indication, the compression end from the compression
  • the state CO is transferred to the initial state IR or the uncompressed state UC and sent. In this way, the data synchronization between the compression and decompression ends can be ensured.
  • the decompression end switches from the non-context state NC to the static context state SC or the full context state FC, that is, the decompression end has obtained the predetermined context. And if the feedback packet contains the NACK flag, the decompression end maintains the NC state without context, that is, the decompression end does not get the predetermined context and needs to be retransmitted by the compression end.
  • the compression end sends a trigger indication to request to receive a third type packet with an ACK/NACK identifier; or, the compression end receives a third type packet with a NACK identifier; or, the compression end receives a packet with an ACK identifier
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it succeeds, the third type packet is sent; if it fails, the NACK flag is added to the first type packet.
  • Three types of packages are sent and sent. That is: in the above-mentioned embodiment, if the compression end receives a third type packet with no identification, it is considered that the decompression end has processed successfully; if the compression end receives a third type packet with a NACK flag, it is considered that the decompression end The processing failed.
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it succeeds, the step ends; if it fails, the NACK flag is added to the third type packet And send. That is, in the above embodiment, if the compression end does not receive the feedback packet, it is considered that the decompression end has processed successfully; if the compression end receives a third type packet with a NACK flag, it is considered that the decompression end has failed in processing.
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it succeeds, the ACK identifier is added to the third type packet and sent; if it fails Then the step ends. That is, in the above embodiment, if the compression end receives a third type packet with an ACK identifier, it is considered that the decompression end has processed successfully; if the compression end does not receive the third type packet, it is considered that the decompression end has failed in processing.
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it fails, the third type packet is sent; if it succeeds, the third type packet is not sent . That is, in the above-mentioned embodiment, if the compression end receives an unidentified third-type packet, it is considered that the processing of the decompression end has failed; if it is not received, it is considered a success.
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful; if it succeeds, the third type packet is sent; if it fails, the third type packet is not sent . That is, in the above-mentioned embodiment, if the compression end receives a third-type packet with no identification, it is considered that the processing of the decompression end is successful; if it is not received, it is considered a failure.
  • the compression end does not receive the third type of packet, it means that the decompression end has processed successfully; correspondingly, if the third type of packet is received, regardless of whether the third type of packet includes an identifier, the decompression end has failed to process Up.
  • the compression end does not receive the third type of packet, it means that the decompression end has failed to process; correspondingly, if the third type of packet is received, regardless of whether the third type of packet includes an identifier, it means that the decompression end has processed successfully Up.
  • the compression end receives the third type packet without identification, it means that the decompression end has processed successfully; correspondingly, if it receives the third type with identification (it can be an ACK/NACK identification or any other form of identification) Type package, it means that the decompression end processing failed.
  • the compression end receives the third type packet without identification, it means that the decompression end has failed to process; correspondingly, if it receives the third type with an identification (it can be an ACK/NACK identification or any other form of identification) Type package, it means that the decompression end processing is successful.
  • the aforementioned successful processing when the decompression end processes the received first type packet and the second type packet specifically includes: the decompression end successfully decompresses the compressed package, or decompresses the compressed package.
  • the third type of packet is a feedback packet; the feedback packet includes at least a context ID (Context ID).
  • the context identifier is used to identify the context to which it belongs, so that the compression end can perform compression and/or the decompression end can perform decompression.
  • the third type packet has an indicator to indicate feedback from the decompression end.
  • the indication identifier may be ACK/NACK to indicate feedback from the decompression end.
  • ACK is used to indicate that the decompression end successfully decompresses the compressed packet, or the decompression end successfully establishes a context, or the decompression end successfully saves a valid context
  • NACK is used to indicate that the decompression end failed Decompress the compressed packet, or the decompression end fails to successfully establish a context, or the decompression end fails to successfully save a valid context
  • the decompression end may not successfully decompress the compressed packet, or fail to successfully establish the context, or fail to successfully save the valid context, then send the feedback packet with the NACK flag; if all The decompression end successfully decompresses the compressed packet, or successfully establishes the context, or successfully saves the valid context; then the feedback packet with the ACK identifier is sent, or the feedback packet is not sent. That is to say, when the compression end does not receive any feedback packet, the compression end considers that the decompression end has successfully decompressed the compressed packet, or successfully established the context, or successfully saved the valid context.
  • the above-mentioned compressed package may also include a cyclic redundancy check (Cyclic Redundancy Check, CRC), which is used by the decompressor to determine the CRC according to the CRC in the compressed package after receiving the compressed package.
  • CRC Cyclic Redundancy Check
  • the compressed package is checked to determine whether the decompression is successful and/or the context is valid. If it is determined that the decompression fails and/or the context is invalid, that is, the CRC check fails, the decompression end needs to send a feedback packet to the compression end.
  • the complete process of the collaborative work of the compression end and the decompression end includes:
  • Step 101 The compression end sends N complete packets in the initial state IR or the uncompressed state UC; wherein the complete packet includes at least: header information of the uncompressed Ethernet header;
  • Step 102 The compression end switches to the compressed state CO, and sends one or more compressed packets; wherein the compressed packet includes at least: header information of the compressed Ethernet header;
  • the complete package and/or compressed package may also include: Context ID and/or package type identifier; further may include profile information; wherein context information such as the context identifier is used for compression and/or compression at the compression end. Or used for decompression on the decompression side;
  • Step 103 After receiving the complete package and/or compressed package in the initial non-context state NC, the decompression end processes the complete package and/or compressed package, and gives feedback according to the processing result; if the processing is successful, the decompression The compression end switches to the static context state SC or the full context state FC, and the step ends; if the processing fails, the decompression end maintains the non-context state NC state, and re-receives the complete package and/or compressed package sent by the compression end; where processing Success means that the decompression end successfully decompresses the compressed package, or the decompression end successfully establishes a context, or the decompression end successfully saves a valid context.
  • the compression end does not receive the third type of packet, it means that the decompression end has processed successfully; correspondingly, if the third type of packet is received, regardless of whether the third type of packet includes an identifier, the decompression end has failed to process Up.
  • the compression end does not receive the third type of packet, it means that the decompression end has failed to process; correspondingly, if the third type of packet is received, regardless of whether the third type of packet includes an identifier, it means that the decompression end has processed successfully Up.
  • the compression end receives the third type packet without identification, it means that the decompression end has processed successfully; correspondingly, if it receives the third type with identification (it can be an ACK/NACK identification or any other form of identification) Type package, it means that the decompression end processing failed.
  • the compression end receives the third type packet without identification, it means that the decompression end has failed to process; correspondingly, if it receives the third type with an identification (it can be an ACK/NACK identification or any other form of identification) Type package, it means that the decompression end processing is successful.
  • the method further includes a context update process, that is, as shown in FIG. 8, the method further includes:
  • Step 104 When the context information of the compression terminal is changed, or the compression terminal is in the compressed state for the first period of time, or after sending a trigger indication requesting to receive the feedback packet with the processing result, it is determined that the decompression terminal has failed to complete the processing successfully Package and/or compressed package, the compression terminal switches from the compressed state CO to the initial state IR or the uncompressed state UC, and the compression terminal sends the complete package in the initial state IR or the uncompressed state UC;
  • Step 105 When the decompression receives the complete package again, the decompression end switches from the static context state SC or the full context state FC to the non-context state NC, and jumps to step 101.
  • the above-mentioned compressed package may also include a cyclic redundancy check (Cyclic Redundancy Check, CRC), which is used by the decompressor to determine the CRC according to the CRC in the compressed package after receiving the compressed package.
  • CRC Cyclic Redundancy Check
  • the compressed package is checked to determine whether the decompression is successful and/or the context is valid. If it is determined that the decompression fails and/or the context is invalid, that is, the CRC check fails, the decompression end needs to send a feedback packet to the compression end.
  • a data transmission method is proposed, as shown in FIG. 9, including:
  • Step 1201 The compression end sends a second-type packet; wherein the first-type packet at least includes: header information of the compressed Ethernet header;
  • Step 1202 After receiving the feedback of the third type of packet, send the first type of packet; wherein the second type of packet includes at least: header information of an uncompressed Ethernet header.
  • FIG. 10 a data transmission method is proposed, as shown in FIG. 10, including:
  • Step 1301 The compression end sends a first-type packet; wherein the first-type packet includes at least: header information of an uncompressed Ethernet header;
  • Step 1302 After receiving the feedback of the third type of packet, send the second type of packet; wherein the second type of packet includes at least: header information of the compressed Ethernet header.
  • the first type of packet is a full packet
  • the second type of packet is a compressed packet.
  • the complete packet includes header information of an uncompressed Ethernet header.
  • the complete package may also include: Context ID and/or package type identifier. It may further include profile information.
  • the context ID (Context ID) is used for compression at the compression end and/or used for decompression at the decompression end.
  • the compressed packet includes header information of the compressed Ethernet header.
  • the compressed package may further include: a context ID and/or a package type identifier. It may further include profile information.
  • context information such as context ID (Context ID) is used for compression at the compression end and/or used for decompression at the decompression end.
  • the third type of packet is a feedback packet; the feedback packet includes at least a context ID (Context ID) and/or a packet type identifier.
  • the context identifier is used to identify the context to which it belongs, so that the compression end can perform compression and/or the decompression end can perform decompression.
  • the third type packet has an indicator to indicate feedback from the decompression end.
  • the indication identifier may be ACK/NACK to indicate feedback from the decompression end.
  • ACK is used to indicate that the decompression end has successfully received the full packet, or the decompression end has successfully established a context, or the decompression end has successfully saved a valid context
  • NACK is used to indicate that the decompression end has not succeeded A full packet is received, or the decompression end fails to establish a context, or the decompression end fails to save a valid context.
  • the decompression end when the decompression end fails to receive the full packet, fails to successfully establish the context, or fails to successfully save the valid context, it may send the feedback packet with the NACK flag, or not send Feedback packet; if the decompression end successfully receives the full packet, or successfully establishes the context, or successfully saves the valid context, then send the feedback packet (without the A/N flag), or send the feedback packet with the ACK flag. That is to say, when the compression end does not receive any feedback packet, or receives the feedback packet with the NACK flag, the full packet continues to occur. When the feedback packet or the feedback packet with the ACK flag is received, the compression end considers that the decompression end has been A full packet is received, or a context is successfully established, or a valid context is successfully saved.
  • a data transmission method is proposed, as shown in FIG. 11, including:
  • Step 1201A The compression end sends a second-type packet in the first state; wherein the first-type packet includes at least: header information of an uncompressed Ethernet header;
  • Step 1202B After receiving the feedback of the third type of packet, the compression end switches to the second state and sends the second type of packet; wherein the second type of packet includes at least: header information of the compressed Ethernet header .
  • a data transmission method is proposed, as shown in FIG. 12, including:
  • Step 1301 The compression end sends a second-type packet in a second state; wherein the second-type packet includes at least: header information of a compressed Ethernet header;
  • Step 1302 After receiving the feedback of the third type of packet, the compression end switches to the first state and sends the first type of packet; wherein the first type of packet includes at least: the header of an uncompressed Ethernet header letter.
  • the first state may be an initial state IR (initialization and Refresh) or an uncompressed state UC (Uncompression).
  • the second state may be a compression state CO (Compression order).
  • the compression end does not receive the feedback packet, it means that the decompression end has processed successfully; correspondingly, if the feedback packet is received, regardless of whether the feedback packet includes an identifier, it indicates that the decompression end has failed in processing.
  • the compression end does not receive the feedback packet, it means that the decompression end processing has failed; correspondingly, if the feedback packet is received, regardless of whether the feedback packet includes an identifier, it indicates that the decompression end has processed successfully.
  • the compression end receives an unidentified feedback packet, it means that the decompression end has successfully processed it; accordingly, if it receives an identified (ACK/NACK identification or any other form of identification) feedback packet, then It indicates that the processing on the decompression side failed.
  • the compression end receives an unidentified feedback packet, it means that the decompression end has failed to process; correspondingly, if it receives an unidentified feedback packet (which can be an ACK/NACK or any other form of identification), then It shows that the decompression end processing was successful.
  • an unidentified feedback packet which can be an ACK/NACK or any other form of identification
  • the successful processing when the aforementioned decompression end processes the received first type packet and the second type packet specifically includes: the decompression end successfully decompresses the compressed package, or the decompression end successfully decompresses the compressed package, or decompresses the compressed package.
  • the compression side successfully establishes the context, or the decompression side successfully saves a valid context.
  • the compressed package may be sent after the complete package is sent and the feedback package is received, or the compressed package may be sent as soon as the feedback package is received when the complete package is sent.
  • an embodiment of the present invention shown in FIG. 13 specifically includes:
  • Step 1301A The compression end sends a first preset number of complete packets in the initial state IR or the uncompressed state UC; wherein the complete packet includes at least: header information of the uncompressed Ethernet header;
  • Step 1302A After sending the first number of complete packets and receiving the feedback packet, the compression end switches to the compressed state CO and sends the compressed packet; wherein the compressed packet includes at least: the compressed Ethernet header Packet header information; wherein the feedback packet includes at least: Context ID (Context ID).
  • Step 1301B the compression end sends a complete packet in the initial state IR or the uncompressed state UC; wherein the complete packet includes at least: header information of the uncompressed Ethernet header;
  • Step 1302B After receiving the feedback packet, the compression end switches to the compressed state CO and sends the compressed packet; wherein the compressed packet includes at least: the header information of the compressed Ethernet header; wherein the feedback packet contains at least Including: Context ID (Context ID).
  • step 1302A the difference between step 1302A and step 1302B is that the compression end sends the compressed package after sending a predetermined number of complete packets and receives the feedback packet; or the compression end does not matter how many complete packets are sent, as long as the feedback packet is received Start sending the compressed package.
  • the method further includes a context update process, that is, the method further includes:
  • Step 1303 When the context information of the compression end changes, or the compression end is in the compressed state CO for a first period of time, the compression end switches from the compressed state CO to the initial state IR or the uncompressed state UC, and jumps to Step 1301 or 1301A.
  • step 1303 when the context information of the compression end is changed, or after a certain period of time, the context information of the decompression end is updated. At this time, the compression end switches to the initial state IR or the uncompressed state UC again, and re-executes the method of step 1301 to step 1302 or step 1301A to step 1302A to resend the context information.
  • the context information change occurs after the compression end switches from the initial state IR or the uncompressed state UC to the compressed state CO, that is, after the compression end sends the first preset number of packets of the first type , Or after the compression end receives the feedback packet sent by the decompression end.
  • a data transmission method is proposed, as shown in FIG. 15, including:
  • Step 2301 The decompression end is receiving a first type packet; wherein the first type packet at least includes: header information of an uncompressed Ethernet header;
  • Step 2302 The decompression end sends a third-type packet to feed back the reception and/or processing result of the first-type packet, and the third-type packet includes at least a context ID (Context ID);
  • Step 2303 The decompression end receives a second-type packet, where the second-type packet at least includes: header information of a compressed Ethernet header.
  • the first type of packet is a full packet
  • the second type of packet is a compressed packet.
  • the complete packet includes header information of an uncompressed Ethernet header.
  • the complete package may also include: Context ID and/or package type identifier. It may further include profile information.
  • the context ID (Context ID) is used for compression at the compression end and/or used for decompression at the decompression end.
  • the compressed packet includes header information of the compressed Ethernet header.
  • the compressed package may further include: a context ID and/or a package type identifier. It may further include profile information.
  • context information such as context ID (Context ID) is used for compression at the compression end and/or used for decompression at the decompression end.
  • the third type of packet is a feedback packet; the feedback packet includes at least a context ID (Context ID) and/or a packet type identifier.
  • the context identifier is used to identify the context to which it belongs, so that the compression end can perform compression and/or the decompression end can perform decompression.
  • the third type packet has an indicator to indicate feedback from the decompression end.
  • the indication identifier may be ACK/NACK to indicate feedback from the decompression end.
  • ACK is used to indicate that the decompression end has successfully received the full packet, or the decompression end has successfully established a context, or the decompression end has successfully saved a valid context
  • NACK is used to indicate that the decompression end has not succeeded A full packet is received, or the decompression end fails to establish a context, or the decompression end fails to save a valid context.
  • the decompression end when the decompression end fails to receive the full packet, fails to successfully establish the context, or fails to successfully save the valid context, it may send the feedback packet with the NACK flag, or not send Feedback packet; if the decompression end successfully receives the full packet, or successfully establishes the context, or successfully saves the valid context, then send the feedback packet (without the A/N flag), or send the feedback packet with the ACK flag. That is to say, when the compression end does not receive any feedback packet, or receives the feedback packet with the NACK flag, the full packet continues to occur. When the feedback packet or the feedback packet with the ACK flag is received, the compression end considers that the decompression end has been A full packet is received, or a context is successfully established, or a valid context is successfully saved.
  • a data transmission method including:
  • Step 2301A The decompression end receives the complete packet in the first state; wherein the complete packet includes at least: header information of the uncompressed Ethernet header;
  • Step 2302A The decompression end sends a feedback packet to feed back the reception and/or processing result of the complete packet, and the feedback packet includes at least a context ID (Context ID);
  • Step 2303A The decompression end receives the compressed packet, where the compressed packet at least includes: header information of the compressed Ethernet header.
  • the above method further includes: the decompression terminal performs processing according to the received complete package and/or compressed package; if the processing is successful, the decompression terminal switches to the fourth state; if the processing fails, the first Re-receive the complete package and/or compressed package in the three states.
  • the decompression end can switch to the fourth state at any point in time between the above steps 2301A-2303A; as long as the decompression end confirms that the complete package and/or the compressed package is successfully processed, the decompression end The compression end switches to the fourth state.
  • the time point when the decompression end switches to the fourth state is not limited.
  • the third state may be an initial no context state NC (no context); wherein, the fourth state may be a static context state SC (static context) or a full context state FC (full context state). context). That is, the method specifically includes;
  • Step 2301B The decompression end receives the complete packet in the contextless state NC; wherein the complete packet includes at least: header information of the uncompressed Ethernet header;
  • Step 2302B The decompression end sends a feedback packet to feed back the reception and/or processing result of the complete packet, and the feedback packet includes at least a context ID (Context ID);
  • Step 2303B The decompression end receives the compressed packet, where the compressed packet at least includes: header information of the compressed Ethernet header.
  • the above method further includes: the decompression terminal performs processing according to the received complete package and/or compressed package; if the processing is successful, the decompression terminal switches to the fourth state; if the processing fails, the first Re-receive the complete package and/or compressed package in the three states.
  • the decompression end can switch to the fourth state at any point in time between the above steps 2301B-2303B; as long as the decompression end confirms that the complete package and/or the compressed package is successfully processed, the decompression end The compression end switches to the fourth state.
  • the time point when the decompression end switches to the fourth state is not limited.
  • the feedback packet may include an ACK/NACK identifier for identifying the result, or may not include the ACK/NACK identifier. That is, all embodiments of the present invention can include many combinations to feed back processing results:
  • the compression end does not receive the third type of packet, it means that the decompression end has processed successfully; correspondingly, if the third type of packet is received, regardless of whether the third type of packet includes an identifier, the decompression end has failed to process Up.
  • the compression end does not receive the third type of packet, it means that the decompression end has failed to process; correspondingly, if the third type of packet is received, regardless of whether the third type of packet includes an identifier, it means that the decompression end has processed successfully Up.
  • the compression end receives the third type packet without identification, it means that the decompression end has processed successfully; correspondingly, if it receives the third type with identification (it can be an ACK/NACK identification or any other form of identification) Type package, it means that the decompression end processing failed.
  • the compression end receives the third type packet without identification, it means that the decompression end has failed to process; correspondingly, if it receives the third type with an identification (it can be an ACK/NACK identification or any other form of identification) Type package, it means that the decompression end processing is successful.
  • the method also includes a context update process, that is, the method further includes after step 2305 or 2305A:
  • Step 2306 When the decompression end receives the complete package and/or compressed package again in the static context state SC or the full context state FC, the decompression end switches to the non-context state NC, and receives the complete package and/or again. Or compressed package.
  • the complete package and compressed package received by the decompression end in step 2306 are changes in the context information of the compression end, or after the compression end is in the compressed state CO for the first period of time, the compression end switches from the compressed state CO to the initial state IR or uncompressed state UC and sent. In this way, the data synchronization between the compression and decompression ends can be ensured.
  • the context update process can also be:
  • Step 2306A When receiving the trigger request, the decompression end sends a feedback package; the feedback package includes an identifier for identifying whether the processing of the complete package and/or the compressed package is successful; if it fails, the decompression end maintains In the non-context state NC state, and re-receive the complete package and/or compressed package; if successful, the decompression end switches from the non-context state NC to the static context state SC or the full context state FC.
  • the feedback package includes an identifier for identifying whether the processing of the complete package and/or the compressed package is successful; if it fails, the decompression end maintains In the non-context state NC state, and re-receive the complete package and/or compressed package; if successful, the decompression end switches from the non-context state NC to the static context state SC or the full context state FC.
  • the complete package and compressed package received by the decompression end in step 2306 and step 2306A are changes in the context information of the compression end, or after the compression end is in the compressed state CO for the first length of time, the compression end switches from the compressed state CO To the initial state IR or uncompressed state UC and sent. In this way, the data synchronization between the compression and decompression ends can be ensured.
  • the complete package and compressed package received by the decompression end in step 2306A are the feedback packets sent by the decompression end based on the start request after the compression end sends a trigger instruction for requesting a feedback packet. Displays the complete package and/or compressed package re-sent by the compressor when the decompressing terminal fails to process the complete package and/or compressed package previously sent.
  • the decompression end switches from the non-context state NC to the static context state SC or the full context state FC, that is, the decompression end has obtained the predetermined context. If the feedback packet contains the NACK flag, the decompression end maintains the NC state without context, that is, the decompression end does not get the predetermined context and needs to be retransmitted by the compression end.
  • the complete process of the collaborative work of the compression end and the decompression end includes:
  • Step 201 The compression end sends a complete packet in the initial state IR or the uncompressed state UC; wherein the complete packet includes at least: header information of the uncompressed Ethernet header;
  • Step 202 The decompression end receives the complete packet in the contextless state NC; wherein the complete packet includes at least: header information of the uncompressed Ethernet header;
  • Step 203 The decompression end sends a feedback packet to feed back the reception and/or processing result of the complete packet, the feedback packet includes at least a context ID (Context ID); the feedback packet may include an ACK for identifying the result /NACK identifier, or not including the ACK/NACK identifier;
  • Context ID a context ID
  • the feedback packet may include an ACK for identifying the result /NACK identifier, or not including the ACK/NACK identifier;
  • Step 204 After the compression end sends the first preset number of complete packets and receives the feedback packet, or after the compression end receives the feedback packet when the complete packet is sent, the compression end switches to the compressed state CO and sends the compressed Package; wherein the compressed package includes at least: the header information of the compressed Ethernet header;
  • Step 205 After receiving the complete package and the compressed package, the decompression end sends a feedback package to feed back the reception and/or processing result of the complete package and the compressed package.
  • the feedback package includes at least a context identifier; the feedback package
  • the ACK/NACK identifier used to identify the result may or may not be included in the ACK/NACK identifier.
  • the method also includes a context update process, that is, as shown in FIG. 17, the method further includes:
  • Step 206 When the context information of the compression terminal is changed, or the compression terminal is in the compressed state CO for the first period of time, or the feedback packet obtained by sending a trigger indication determines that the decompression terminal has not successfully processed the complete package and/or the compressed package , The compression end switches from the compressed state CO to the initial state IR or the uncompressed state UC, and the compression end sends the complete packet in the initial state IR or the uncompressed state UC;
  • Step 207 When the decompression end receives the complete packet again, the decompression end switches from the static context state SC or the full context state FC to the non-context state NC, and jumps to step 201.
  • the complete process of the collaborative work of the compression end and the decompression end may be:
  • Step 201A The compression end sends the compressed packet in the compressed state CO; wherein the compressed packet includes at least: header information of the compressed Ethernet header;
  • Step 202A The decompression end receives the compressed packet in the contextless state NC; wherein the complete packet includes at least: header information of the uncompressed Ethernet header;
  • Step 203A The decompression end sends a feedback packet to feed back the reception and/or processing result of the compressed packet, the feedback packet includes at least a context ID (Context ID); the feedback packet may include an ACK for identifying the result /NACK identifier, or not including the ACK/NACK identifier;
  • Context ID a context ID
  • the feedback packet may include an ACK for identifying the result /NACK identifier, or not including the ACK/NACK identifier;
  • Step 204A The compression end switches to the initial state IR or the uncompressed state UC, and sends a complete packet; wherein the complete packet includes at least: header information of an uncompressed Ethernet header;
  • Step 205A After receiving the complete package and the compressed package, the decompression end sends a feedback package to feed back the reception and/or processing result of the complete package and the compressed package, the feedback package includes at least a context identifier; the feedback package The ACK/NACK identifier used to identify the result may or may not be included in the ACK/NACK identifier.
  • the method further includes a context update process, that is, the method further includes:
  • Step 206A When the context information of the compression terminal is changed, or the compression terminal is in the compressed state CO for the first period of time, or the feedback packet obtained by sending a trigger indication determines that the decompression terminal has not successfully processed the complete package and/or compressed package , The compression end sends a compressed package;
  • Step 207A When the decompression end receives the complete package again, the decompression end switches from the static context state SC or the full context state FC to the non-context state NC, and jumps to step 201A.
  • the feedback packet may include an ACK/NACK identifier for identifying the result, or may not include the ACK/NACK identifier. That is, all embodiments of the present invention can include many combinations to feed back processing results:
  • the compression end does not receive the third type of packet, it means that the decompression end has processed successfully; correspondingly, if the third type of packet is received, regardless of whether the third type of packet includes an identifier, the decompression end has failed to process Up.
  • the compression end does not receive the third type of packet, it means that the decompression end has failed to process; correspondingly, if the third type of packet is received, regardless of whether the third type of packet includes an identifier, it means that the decompression end has processed successfully Up.
  • the compression end receives the third type packet without identification, it means that the decompression end has processed successfully; correspondingly, if it receives the third type with identification (it can be an ACK/NACK identification or any other form of identification) Type package, it means that the decompression end processing failed.
  • the compression end receives the third type packet without identification, it means that the decompression end has failed to process; correspondingly, if it receives the third type with an identification (it can be an ACK/NACK identification or any other form of identification) Type package, it means that the decompression end processing is successful.
  • Step 1401 The compression end sends a first preset number of packets of the first type through a unidirectional link; wherein the packets of the first type include at least: header information of an uncompressed Ethernet header;
  • Step 1402 After sending the first preset number of packets of the first type, send a second type of packet; wherein the second type of packet includes at least: header information of the compressed Ethernet header.
  • the first type of packet is a full packet
  • the second type of packet is a compressed packet.
  • the complete packet includes header information of an uncompressed Ethernet header.
  • the complete package may also include: Context ID and/or package type identifier. It may further include profile information.
  • the context ID (Context ID) is used for compression at the compression end and/or used for decompression at the decompression end.
  • the compressed packet includes header information of the compressed Ethernet header.
  • the compressed package may further include: a context ID and/or a package type identifier. It may further include profile information.
  • context information such as context ID (Context ID) is used for compression at the compression end and/or used for decompression at the decompression end.
  • the first type of packet is a full packet
  • the second type of packet is a compressed packet.
  • the complete packet includes header information of an uncompressed Ethernet header.
  • the complete package may also include: Context ID and/or package type identifier. It may further include profile information.
  • the context ID (Context ID) is used for compression at the compression end and/or used for decompression at the decompression end.
  • the compressed packet includes header information of the compressed Ethernet header.
  • the compressed package may further include: a context ID and/or a package type identifier. It may further include profile information.
  • context information such as context ID (Context ID) is used for compression at the compression end and/or used for decompression at the decompression end.
  • the compression end may send the first type of packet in the first state, and send the second type of packet in the second state. That is, the method shown in FIG. 19 specifically includes:
  • Step 1401A The compression end sends a first preset number of complete packets through a unidirectional link in the initial state IR or the uncompressed state UC; wherein the complete packet includes at least: header information of the uncompressed Ethernet header;
  • Step 1402 After sending the first preset number of packets of the first type, the compression end switches to the second state and sends the second type of packets; wherein the second type of packets at least includes: a packet header of a compressed Ethernet header information.
  • the first state may be an initial state IR (initialization and Refresh) or an uncompressed state UC (Uncompression).
  • the second state may be a compression state CO (Compression order). That is, the method includes:
  • Step 1401B In the initial state IR or the uncompressed state UC, the compression end sends a first preset number of complete packets through a one-way link; wherein the complete packet includes at least: header information of an uncompressed Ethernet header;
  • Step 1402B After sending the first number of complete packets, the compression end switches from the initial state IR or the uncompressed state UC to the compressed state CO, and sends the compressed packet; wherein the compressed packet includes at least: compressed ether The header information of the net header.
  • the third state may be an initial no context state NC (no context); wherein, the fourth state may be a static context state SC (static context) or a full context state FC (full context state). context).
  • NC no context
  • SC static context
  • FC full context state
  • the method further includes a context update mechanism, that is, after the step 1402 or 1402A or 1402B, it further includes:
  • Step 1403 When the context information of the compression terminal changes, or the compression terminal is in the compressed state CO for a first period of time, the compression terminal switches from the compressed state CO to the initial state IR or the uncompressed state UC, and jumps to Step 1401 or 1401A or 1401B.
  • step 1403 when the context information of the compression end is changed, or after a certain period of time, the context information of the compression end is updated; the context information at this time can be the same as the previous time. It can also be different from the previous time.
  • the compression end switches to the initial state IR or the uncompressed state UC again, and re-executes the method of step 1401 to step 1402 or step 1401A to step 1402A to resend the context information.
  • the context information change occurs after the compression end switches from the initial state IR or the uncompressed state UC to the compressed state CO, that is, after the compression end sends the first preset number of packets of the first type , Or after state transition.
  • the above-mentioned compressed package may also include a cyclic redundancy check (Cyclic Redundancy Check, CRC), which is used by the decompressor to determine the CRC according to the CRC in the compressed package after receiving the compressed package.
  • CRC Cyclic Redundancy Check
  • the compressed package is checked to determine whether the decompression is successful and/or the context is valid. If it is determined that the decompression fails and/or the context is invalid, that is, the CRC check fails, the decompression end needs to send a feedback packet to the compression end.
  • the data transmission method as shown in FIG. 20 includes:
  • Step 2401 The decompression end receives a first type packet through a unidirectional link in a third state; wherein the first type packet includes at least: header information of an uncompressed Ethernet header;
  • Step 2402 after the decompression end receives M packets of the first type, the decompression end switches to the fourth state.
  • the method further includes:
  • Step 2403 The decompression end receives a second-type packet, where the second-type packet at least includes: header information of an uncompressed Ethernet header.
  • the above method further includes: the decompression terminal performs processing according to the received complete package and/or compressed package; if the processing is successful, the decompression terminal switches to the fourth state; if the processing fails, the first Re-receive the complete package and/or compressed package in the three states.
  • the decompression end can switch to the fourth state at any point in the above steps; as long as the decompression end confirms that the complete package and/or the compressed package is successfully processed, the decompression end switches to the first state.
  • the decompression end switches to the first state.
  • the third state may be an initial no context NC (no context); wherein, the fourth state may be a static context state SC (static context) or a full context state FC (full context). ).
  • the aforementioned successful processing when the decompression end processes the received first type packet specifically includes: the decompression end successfully receives at least one full packet, or the decompression end successfully establishes the context, or The decompression end successfully saves a valid context.
  • the decompression end successfully receives at least one full packet
  • the decompression end successfully establishes the context
  • the decompression end successfully saves a valid context.
  • the method specifically includes:
  • Step 2401A the decompression end receives the complete packet through the unidirectional link under the context-free NC; wherein the complete packet includes at least: header information of the uncompressed Ethernet header; step 2402A, the decompression end receives the complete packet according to Perform processing, and after successful processing, the decompression end switches from the non-context NC to the static context state SC or the full context state FC.
  • the method also includes;
  • Step 2403A The decompression end receives a second type packet, where the second type packet at least includes: header information of an uncompressed Ethernet header.
  • the data transmission method further updates the context, that is, the method includes after step 2402 or 2402A:
  • Step 2404 When the decompression end receives the complete package again in the static context state SC or the full context state FC, the decompression end switches from the static context state SC or the full context state FC to the non-context NC, and jumps to Step 2401 or 2401A.
  • the complete package and/or compressed package received by the decompression end in step 2404 is the change of the context information of the compression end, or the compression end is in the compressed state for the first period of time CO, or after the triggering instruction is sent, the compression end Transmitted from the compressed state CO to the initial state IR or uncompressed state UC. In this way, the data synchronization between the compression and decompression ends can be ensured.
  • the above-mentioned compressed package may also include a cyclic redundancy check (Cyclic Redundancy Check, CRC), which is used by the decompressor to determine the CRC according to the CRC in the compressed package after receiving the compressed package.
  • CRC Cyclic Redundancy Check
  • the compressed package is checked to determine whether the decompression is successful and/or the context is valid. If it is determined that the decompression fails and/or the context is invalid, that is, the CRC check fails, the decompression end needs to send a feedback packet to the compression end.
  • the complete process of the collaborative work of the compression end and the decompression end specifically includes:
  • Step 301 The compression end sends N complete packets through a unidirectional link in the initial state IR or the uncompressed state UC; wherein the first type of packet includes at least: the header information of the uncompressed Ethernet header; the complete packet is also May include: Context ID and/or package type identifier;
  • Step 302 After sending N complete packets, the compression end switches from the initial state IR or the uncompressed state UC to the compressed state CO, and sends one or more compressed packets through a one-way link; wherein the compressed packet At least include: the header information of the compressed Ethernet header;
  • Step 303 After receiving the complete package through the unidirectional link in the initial non-context state NC, the decompression end processes the complete package and the compressed package; if the processing is successful, the decompression end switches to the static context state SC or Full context state FC.
  • the method also includes a context update process, that is, the method as shown in FIG. 22 also includes:
  • Step 304 When the context information of the compression end changes, or the compression end is in the compressed state CO for a first period of time, the compression end switches from the compressed state CO to the initial state IR or the uncompressed state UC, and the compression end is in the initial state. Send a complete packet through a unidirectional link in the state IR or the uncompressed state UC;
  • Step 305 When the decompression receives the complete packet again via the unidirectional link, the decompression end switches from the static context state SC or the full context state FC to the non-context state NC to receive the complete packet again.
  • the above-mentioned compressed package may also include a cyclic redundancy check (Cyclic Redundancy Check, CRC), which is used by the decompressor to determine the CRC according to the CRC in the compressed package after receiving the compressed package.
  • CRC Cyclic Redundancy Check
  • the compressed package is checked to determine whether the decompression is successful and/or the context is valid. If it is determined that the decompression fails and/or the context is invalid, that is, the CRC check fails, the decompression end needs to send a feedback packet to the compression end.
  • a data transmission method including:
  • the initial state of the compression end is IR (initialization and Refresh) or uncompressed state UC (Uncompression).
  • the initial state of the decompression terminal is NC (no context).
  • N can be the network configuration, or it can be determined by the compression end itself.
  • the decompressing end can send the feedback packet or not.
  • the state of the decompression end is changed from NC to static context state SC (static context) or full context state FC (full context).
  • the feedback packet carries at least the context ID, which may carry ACK/NACK (in this case, the value or indication is ACK), or it may not carry ACK/NACK.
  • the decompression end sends a feedback packet.
  • the state of the decompression end does not change.
  • the feedback packet carries at least the context ID, which can carry ACK/NACK (in this case, the value or indication is NACK), or it does not need to carry ACK/NACK (as the previous one, no feedback packet is sent when it is successfully established).
  • the compression end resends the full packet, and the corresponding compression end state changes from CO to IR or UC.
  • the compression end in the CO state retransmits the full packet, and the corresponding state changes from CO to IR or UC.
  • the compression end may be a terminal device UE, and the decompression end may be a base station.
  • the compression end and the decompression end may be any devices.
  • the UE is in the initial state of the compression end as IR or UC state.
  • gNB is in NC state.
  • N can be the network configuration, or it can be determined by the compression end itself.
  • the base station fails to successfully decompress the compressed packet, and the base station sends a feedback packet.
  • the decompression state of the base station does not change.
  • the feedback packet carries context ID, ACK/NACK (in this case, the value or indication is NACK).
  • the UE receives the feedback packet and confirms that the decompression is unsuccessful.
  • the compression state of the UE is switched from CO to IR or UC, and the full packet is retransmitted.
  • the UE After sending N full packets (at time t6), the UE starts to send compressed packets.
  • the base station successfully decompressed the compressed packet.
  • the decompression state of the base station is switched from NC to SC or FC.
  • the context information changes.
  • the UE state changes from CO to IR or UC, and reselects to send the full packet.
  • the base station receives the full packet again, and the base station status changes from SC or FC to NC, and considers that the context needs to be updated.
  • the UE has sent N full packets, and the UE starts to send compressed packets.
  • the corresponding state changes from CO to IR or UC.
  • the base station successfully decompressed the compressed packet.
  • the decompression state of the base station is switched from NC to SC or FC.
  • An embodiment of the present invention also proposes a data transmission method; wherein the compression end sends a full packet and sends a compressed packet after receiving the feedback packet. When the context is updated, the full packet is re-sent.
  • the process of the embodiment of the present invention is specifically as follows:
  • the initial state of the compression end is IR (initialization and Refresh) or uncompressed state UC (Uncompression).
  • the initial state of the decompression terminal is NC (no context).
  • the compression end After the compression end sends a full packet and receives a feedback packet, it sends a compressed packet (or, after sending K full packets and receiving a feedback packet, it sends compressed packet). Correspondingly, the state of the compression end changes from IR or UC to the compression state CO (Compression order).
  • the decompression end can send a feedback packet.
  • the state of the decompression end is changed from NC to static context state SC (static context) or full context state FC (full context).
  • the feedback packet carries at least the context ID, which may carry ACK/NACK (in this case, the value or indication is ACK), or it may not carry ACK/NACK.
  • the compression end in the CO state retransmits the full packet, and the corresponding state changes from CO to IR or UC.
  • the compression end may be a terminal device UE, and the decompression end may be a base station.
  • the compression end and the decompression end may be any devices.
  • the UE is in the initial state of the compression end as IR or UC state.
  • gNB is in NC state.
  • the base station receives the full packet, and after establishing the context, the base station sends a feedback packet.
  • the decompressed state of the base station is converted from NC to SC or FC.
  • the context ID is carried in the feedback packet, but ACK/NACK may not be carried.
  • the UE receives the feedback packet, and the UE state changes from IR or UC to CO, and starts to send compressed packets.
  • the context information changes.
  • the UE state changes from CO to IR or UC, and reselects to send the full packet.
  • the base station receives the full packet again, and the base station status changes from SC or FC to NC, and considers that the context needs to be updated.
  • the base station establishes a new context and sends a feedback packet, and the decompression state of the base station is switched from NC to SC or FC.
  • the UE receives the feedback packet, and the UE state changes from IR or UC to CO, and starts to send compressed packets.
  • An embodiment of the present invention also provides a data transmission method; wherein the compression end is connected to the decompression end through a unidirectional link.
  • the method of the embodiment of the present invention specifically includes:
  • the initial state of the compression end is IR (initialization and Refresh) or uncompressed state UC (Uncompression).
  • the initial state of the decompression terminal is NC (no context).
  • N can be the network configuration, or it can be determined by the compression end itself.
  • the state of the decompression end changes from NC to static context state SC (static context) or full context state FC (full context).
  • the compression end in the CO state retransmits the full packet, and the corresponding state changes from CO to IR or UC.
  • the compression end may be a terminal device UE, and the decompression end may be a base station.
  • the compression end and the decompression end may be any devices.
  • the UE is in the initial state of the compression end as IR or UC state.
  • gNB is in NC state.
  • N can be the network configuration, or it can be determined by the compression end itself.
  • the base station receives N full packets, and the base station considers that the context is successfully established.
  • the decompression state of the base station is switched from NC to SC or FC.
  • the context information changes.
  • the UE state changes from CO to IR or UC, and reselects to send the full packet.
  • the base station receives the full packet again, and the base station status changes from SC or FC to NC, and considers that the context needs to be updated.
  • the UE has sent N full packets, and the UE starts to send compressed packets.
  • the corresponding state changes from CO to IR or UC.
  • the base station receives N full packets, and the base station considers that the context update is successful.
  • the decompression state of the base station is switched from NC to SC or FC.
  • the embodiment of the present invention provides a data transmission device, which is arranged at the compression end, as shown in FIG. 23, includes:
  • the first sending module is configured to send a first type of packet; wherein the first type of packet includes at least: header information of an uncompressed Ethernet header;
  • the second sending module is configured to send a second type of packet; wherein the second type of packet includes at least: header information of a compressed Ethernet header.
  • the first sending module sends a first type packet in a first state; and the second sending module sends a second type packet in a second state.
  • the first state is an initial state or an uncompressed state; and/or, the second state is a compressed state.
  • the first type package and/or the second type package further include: a context identifier and/or a package type identifier;
  • the context identifier is used to identify the context corresponding to the first type package and/or the second type package
  • the package type identifier is used to identify the package as the first type package or the second type package.
  • the first type package is a complete package; and/or, the second type package is a compressed package.
  • the device further includes:
  • the update module is used to make the compression end switch from the second state to the first state when the context information of the compression end changes, or the compression end is in the compression state for a first period of time.
  • the device further includes a receiving module, and the receiving module is configured to perform the following operations:
  • the device further includes a switching module, and the switching module is configured to perform the following operations:
  • the compression end When the compression end receives a third type packet or a third type packet with NACK, the compression end switches from the second state to the first state, and/or,
  • the compression end When the compression end receives a third type packet or a third type packet with an ACK, the compression end switches from the first state to the second state.
  • the first sending module is configured to perform the following operations:
  • the first preset number is determined by the compression end, or the compression end is determined according to received configuration parameters.
  • the device performs the following operations:
  • the first sending module sends the first type of packet
  • the switching module switches the compression terminal from the first state to the second state and sends the second type packet through the second sending module;
  • the switching module switches the compression end from the first state to the second state and sends the second type of packets through the second sending module;
  • the first sending module sends a first preset number of packets of the first type
  • the switching module switches the compression end from the first state to the second state and sends the first packet through the second sending module Two types of packages.
  • the third type package includes at least a context identifier; wherein the context identifier is used to identify the context corresponding to the third type package.
  • the third type packet includes an ACK/NACK identifier, and the ACK/NACK identifier is used to indicate that the receiving end receiving the first type packet and the second type packet responds to the first type packet and the second type packet.
  • the compression end sends the first type packet and the second type packet through a unidirectional link.
  • the second type packet has a cyclic redundancy check.
  • the embodiment of the present invention also provides a data transmission device, which is arranged at the decompression end, as shown in FIG. 24, including:
  • the first receiving module is configured to receive a first type packet and/or a second type packet; wherein the first type packet includes at least: uncompressed Ethernet header header information; wherein the second type packet includes at least Including: the header information of the compressed Ethernet header;
  • the processing module is used to process the received packets of the first type and the second type.
  • the first receiving module receives the first type packet and/or the second type packet in the third state.
  • the processing module is used to process the first type packet or the second type packet, and switch to the fourth state after the processing is successful.
  • the third state is a contextless state; and/or, the fourth state is a static context state or a full context state.
  • the first type package and/or the second type package further include: a context identifier and/or a package type identifier;
  • the context identifier is used to identify the context corresponding to the first type package and/or the second type package
  • the package type identifier is used to identify the package as the first type package or the second type package.
  • the first type package is a complete package; and/or, the second type package is a compressed package.
  • the receiving module is further configured to perform the following operations:
  • the decompression switches from the fourth state to the third state after receiving the first-type packet again or again.
  • the processing module is further configured to perform the following operations:
  • the decompression end judges whether the processing of the first type packet and/or the second type packet is successful
  • the NACK identifier is added to the third type packet and sent; and the decompression end switches from the fourth state to the third state.
  • the processing module is further configured to perform the following operations:
  • the third type packet is not sent.
  • the processing module is further configured to perform the following operations:
  • the third type packet is not sent.
  • the third type package includes at least a context identifier; wherein the context identifier is used to identify the context corresponding to the third type package.
  • the first receiving module is configured to perform the following operations:
  • the first receiving module is configured to perform the following operations:
  • the decompression end receives the first type packet and the second type packet through a unidirectional link.
  • the first receiving module is further configured to perform the following operations:
  • the decompression terminal After the decompression terminal receives the first type packet again in the fourth state, the decompression terminal switches the decompression terminal from the fourth type to the third state.
  • the device further includes a sending module
  • the sending module is configured to send a third type packet after the decompression end receives a trigger instruction
  • the third type packet includes an ACK/NACK identifier used to identify whether the processing of the received first type packet or the second type packet by the decompression end is successful;
  • the decompression end transitions from the fourth state to the third state
  • the decompression end transitions from the third state to the fourth state.
  • the decompression end is used to determine whether the decompression is successful and/or the context is valid according to the cyclic redundancy check in the second type of packet.
  • the embodiment of the present invention also proposes a data transmission system, as shown in FIG. 25, including a compression end and a decompression end:
  • the compression end sends N packets of the first type in the first state; wherein the packet of the first type includes at least: header information of an uncompressed Ethernet header;
  • the compression terminal After sending N packets of the first type, the compression terminal switches from the first state to the second state, and sends one or more packets of the second type; wherein the second type of packets at least include: compressed ether The header information of the net header;
  • the decompression end receives the first type packet in the third state
  • the decompression end After the decompression end receives the second type packet in the third state, it processes the second type packet and determines whether the processing is successful. If so, the decompression end switches to the fourth state, if otherwise, the decompression end is in the third state.
  • the third type of packet is sent in the state so that the compression end retransmits the first type of packet.
  • the compression terminal switches from the second state to the first state, and sends the first type packet
  • the decompression end switches from the fourth state to the third state and receives the first type packet.
  • the compression end sends a trigger request to the decompression end to request the decompression end to send the processing result of the first type packet or the second type packet;
  • the decompression end After receiving the trigger request, the decompression end sends a third type packet to the compression end; when the identification is a processing failure, the decompression end switches from the fourth state to the third state and receives The first type of packet; when the identifier is processed successfully, the decompression end maintains the fourth state.
  • the decompression end sends a third type packet with an ACK identifier to the compression end; where the ACK identifier is used to indicate that the decompression end successfully processed the first type packet or the second type packet.
  • the decompression end sends a third type packet with a NACK identifier to the compression end; the NACK identifier is used to indicate that the decompression end fails to process the first type packet or the second type packet.
  • a cyclic redundancy check in the second type packet, which is used to determine whether the decompression is successful and/or whether the context is valid.
  • the embodiment of the present invention also proposes a data transmission system, including a compression end and a decompression end:
  • the compression end sends the first type of packet in the first state; wherein the first type of packet at least includes: header information of an uncompressed Ethernet header;
  • the decompression end receives the first type packet in the third state
  • the decompression end sends a third-type packet to feed back the reception and/or processing result of the first-type packet;
  • the compression end After the compression end receives a first preset number of packets of the first type and receives the third type packet sent by the decompression end, or after the compression end sends the first type packet and receives the third type packet sent by the decompression end, or After the compression end sends the first type packet and receives the third type packet including the ACK identifier sent by the decompression end, the compression end switches to the second state and sends the second type packet; wherein the second type packet is At least include: the header information of the compressed Ethernet header.
  • the decompression end after receiving the first type of packet, sends a third type of packet to feed back the reception and/or processing result of the first type of packet, and the feedback packet includes at least Context identifier; wherein the context identifier is used to identify the context corresponding to the third type of package.
  • the compression end After the context information is changed by the compression end, or after the compression end is in the second state for the first time period, the compression end switches from the second state to the first state, and resends the first type of packet.
  • the compression end sends a trigger request to the decompression end to request the decompression end to send the processing result of the first type packet or the second type packet;
  • the decompression end After receiving the trigger request, the decompression end sends a third type packet to the compression end; when the processing fails, the decompression end switches from the fourth state to the third state, and receives the compression end again The first type of packet sent in the first state; when the processing is successful, the decompression end maintains the fourth state.
  • the decompression end sends a third type packet with an ACK identifier to the compression end; where the ACK identifier is used to indicate that the decompression end successfully processed the first type packet or the second type packet;
  • the decompression end sends a third type packet with a NACK identifier to the compression end; the NACK identifier is used to indicate that the decompression end fails to process the first type packet or the second type packet.
  • the embodiment of the present invention also proposes a data transmission system, including a compression end and a decompression end:
  • the compression end sends N packets of the first type through a unidirectional link in the first state; wherein the packets of the first type include at least: header information of an uncompressed Ethernet header;
  • the compression terminal After sending N packets of the first type, the compression terminal switches from the first state to the second state, and sends one or more packets of the second type; wherein the second type of packets at least include: compressed ether The header information of the net header;
  • the decompression end After receiving M packets of the first type in the third state, the decompression end switches to the fourth state, and processes the first type packets and/or the second type packets.
  • the compression terminal switches from the second state to the first state, and sends the first type packet
  • the decompression end switches from the fourth state to the third state.
  • the second type packet has a cyclic redundancy check.
  • the unidirectional link includes at least one of the following:
  • the compression terminal can be any device or any virtual device (such as a virtual machine) or any program
  • the decompression terminal can be any device or any virtual device (such as a virtual machine) or any program.
  • the disclosed system, device, and method may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units may only be a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components may be combined. Or it can be integrated into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
  • the functional units in the various embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.
  • the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium.
  • the technical solution of the present invention essentially or the part that contributes to the related technology or the part of the technical solution can be embodied in the form of a software product.
  • the computer software product is stored in a storage medium, including several
  • the instructions are used to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in the various embodiments of the present invention.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program code .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

Des modes de réalisation de la présente invention concernent un procédé de transmission de données et un dispositif. Le procédé comprend : une extrémité de compression envoyant un paquet de premier type, le paquet de premier type comprenant au moins des informations d'en-tête d'un en-tête Ethernet non compressé ; et l'extrémité de compression envoyant un paquet de second type, le paquet de second type comprenant au moins des informations d'en-tête d'un en-tête Ethernet compressé. Le procédé permet d'obtenir une transmission de données pour une compression d'en-tête Ethernet.
PCT/CN2019/109639 2019-09-30 2019-09-30 Procédé et dispositif de transmission de données WO2021062728A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2019/109639 WO2021062728A1 (fr) 2019-09-30 2019-09-30 Procédé et dispositif de transmission de données
CN201980095376.6A CN113711627B (zh) 2019-09-30 2019-09-30 数据传输方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2019/109639 WO2021062728A1 (fr) 2019-09-30 2019-09-30 Procédé et dispositif de transmission de données

Publications (1)

Publication Number Publication Date
WO2021062728A1 true WO2021062728A1 (fr) 2021-04-08

Family

ID=75336317

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/109639 WO2021062728A1 (fr) 2019-09-30 2019-09-30 Procédé et dispositif de transmission de données

Country Status (2)

Country Link
CN (1) CN113711627B (fr)
WO (1) WO2021062728A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023283051A1 (fr) * 2021-07-09 2023-01-12 Qualcomm Incorporated Transmission de paquets préalablement compressés pour éviter une chute de débit

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101453298B (zh) * 2007-12-07 2013-06-05 华为技术有限公司 一种无线网络中头压缩的处理方法及系统、装置
CN109218995B (zh) * 2018-10-08 2021-08-20 腾讯科技（深圳）有限公司 通信方法、装置、计算机可读介质及电子设备

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
MEDIATEK INC.: "Details of Ethernet Header Compression", 3GPP DRAFT; R2-1907074 - DETAILS OF ETHERNET HEADER COMPRESSION, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Reno, USA; 20190513 - 20190517, 13 May 2019 (2019-05-13), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP051730524 *
QUALCOMM INCORPORATED: "RoHC based Header Compression for TSN", 3GPP DRAFT; R2-1817913_ROHC BASED HEADER COMPRESSION FOR ETHERNET, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Spokane, Washington; 20181101, 12 November 2018 (2018-11-12), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP051557425 *
SONY: "PDCP based Ethernet Header Compression", 3GPP DRAFT; R2-1907041_EHC, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Reno, USA; 20190513 - 20190517, 13 May 2019 (2019-05-13), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP051730491 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023283051A1 (fr) * 2021-07-09 2023-01-12 Qualcomm Incorporated Transmission de paquets préalablement compressés pour éviter une chute de débit

Also Published As

Publication number Publication date
CN113711627A (zh) 2021-11-26
CN113711627B (zh) 2023-03-24

Similar Documents

Publication Publication Date Title
US9072006B2 (en) Mobile communication method and system
JP4065277B2 (ja) マルチメディア放送／マルチキャストサービスシステムでヘッダー復元動作を再開する方法
CN110603803B (zh) 用于云局域网环境中网络实体之间通信的方法和设备
EP1928130A2 (fr) Appareils et procédés pour initialiser le protocole de convergence de données en paquet PDCP dans un système de communication mobile
JP2003283592A (ja) ワイヤレスコミュニケーションシステムのデータ伝送確認方法
US7346077B2 (en) Processing of erroneous data in telecommunications system providing packet-switched data transfer
CN111385268B (zh) 一种数据包头压缩确认方法及通信设备
US9923695B2 (en) Call processing method and apparatus for use in LTE system
US8976814B2 (en) Method of transporting data from sending node to destination node
WO2021062728A1 (fr) Procédé et dispositif de transmission de données
EP3198928B1 (fr) Procédé de traitement d'appel et appareil à utiliser dans un système lte
US8797879B2 (en) Method of transmitting and receiving status report in a mobile communication system
US20070058636A1 (en) System and method for evaluating lower layer reliability using upper layer protocol functionality in a communications network
CN116076151A (zh) 用于级联服务数据单元的通信设备和方法
EP1764957A1 (fr) Système et procédé pour évaluer la fiabilité des couches inférieures utilisant le protocol des couches supérieures dans un réseau de communication
KR100370060B1 (ko) 차세대 이동 통신 시스템의 통신 운용 방법
CN113711558B (zh) 以太帧包头压缩处理方法、装置、用户终端、基站和介质
US20200228235A1 (en) Data recovery in unreliable packet networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19948018

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19948018

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 19948018

Country of ref document: EP

Kind code of ref document: A1