WO2011137789A1 - 一种压缩方法与装置 - Google Patents

一种压缩方法与装置 Download PDF

Info

Publication number
WO2011137789A1
WO2011137789A1 PCT/CN2011/074286 CN2011074286W WO2011137789A1 WO 2011137789 A1 WO2011137789 A1 WO 2011137789A1 CN 2011074286 W CN2011074286 W CN 2011074286W WO 2011137789 A1 WO2011137789 A1 WO 2011137789A1
Authority
WO
WIPO (PCT)
Prior art keywords
header
compressed
header compression
packet
identifier
Prior art date
Application number
PCT/CN2011/074286
Other languages
English (en)
French (fr)
Inventor
朱雷
权威
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2011137789A1 publication Critical patent/WO2011137789A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • the present application claims priority to Chinese Patent Application No. 201010287387.5, filed on Sep. 20, 2010, the disclosure of which is incorporated herein in The present invention relates to the field of wireless communication technologies, and in particular, to a compression method and apparatus.
  • the Packet Data Convergence Protocol (PDCP) layer and its compression function in the Long Term Evolution (LTE) specification are implemented in an evolved base station (eNB) and a user equipment (UE). The air gap between them is used for control plane signaling compression and user plane data compression, respectively.
  • PDCP Packet Data Convergence Protocol
  • LTE Long Term Evolution
  • eNB evolved base station
  • UE user equipment
  • the air gap between them is used for control plane signaling compression and user plane data compression, respectively.
  • ROHC Robust Header Compression
  • the functional entities include a compressor and a decompressor. This compression method can not only save the capacity of the air interface, but also Save transmission capacity on the LTE-Uu interface.
  • ROHC includes Internet Protocol (IP) / User Datagram Protocol (UDP) / Real-time Transport Protocol (RTP) classes and UDP/IP classes and ESP (Encapsulating Security Payload) / IP compression class.
  • IP Internet Protocol
  • UDP User Datagram Protocol
  • RTP Real-time Transport Protocol
  • ESP Encapsulating Security Payload
  • the nested IP header is divided into two layers.
  • the inner IP header can be IP/UDP/RTP, IP/UDP, IP/Transport Control Protocol (TCP), and the outer IP header can be Internet Protocol (Internet).
  • Protocol, IP)/UDP/GPRS Tunneling Protocol-User plane (GTP-U) header compresses and transmits each protocol header through the inner IP header compression framework and the outer IP header compression framework.
  • the IP packet compressed by the header reduces the efficiency of the header compression context.
  • a data transmission method including:
  • the first device sends a message to the second device, where the message carries an Internet Protocol IP header and a header compression context identifier to be compressed, and the IP header to be compressed is determined according to a first IP header compression method, and the header compression context identifier is used. Identifying the IP header to be compressed;
  • the first device compresses the IP packet header by using the first IP packet header compression method, and sends the IP packet header compressed IP data packet to the second device, and the IP packet header compressed IP data packet carrying station
  • the header compresses the context identifier, so that after the second device receives the IP packet compressed by the IP header, it determines, according to the header compression context identifier carried in the IP packet compressed by the IP header.
  • the IP header to be compressed recovers the compressed IP data packet into an IP data packet before compression according to the determined IP packet header to be compressed.
  • another method of data transmission including:
  • the second device receives the message sent by the first device, where the message carries the Internet Protocol IP header and the header compression context identifier to be compressed, and the IP header to be compressed is determined according to the first IP header compression method, and the header compression context identifier is Used to identify the IP header to be compressed;
  • the second device Determining, by the second device, the IP header to be compressed corresponding to the header compression context identifier carried in the IP packet compressed by the IP header, and using the compressed IP header according to the determined IP header to be compressed The packet is restored to the IP packet before compression.
  • a data transmission apparatus including:
  • a determining module configured to determine a packet to be compressed according to the first Internet Protocol IP header compression method a header, the IP header to be compressed is represented by a header compression context identifier;
  • a transmitting module configured to send a message to the second device, where the message carries the IP header and header compression context identifier to be compressed determined by the determining module;
  • a processing module configured to compress, by using the first IP header compression method, the IP header determined by the determining module
  • the transmitting module is configured to send, to the second device, the IP data packet that is processed by the processing module to perform the IP header compression, where the IP packet compressed by the IP header carries the header compression context identifier, so that After receiving the IP packet compressed by the IP header, the second device determines an IP header to be compressed corresponding to the header compression context identifier carried in the IP packet compressed by the IP header, according to the The determined IP header to be compressed restores the compressed IP packet to an IP packet before compression.
  • Another data transmission apparatus which is characterized by comprising:
  • a transmission module configured to receive a message sent by the first device, where the message carries an Internet Protocol IP header and a header compression context identifier to be compressed, and the IP header to be compressed is determined according to a first IP header compression method, where the header is compressed.
  • the context identifier is used to identify the IP header to be compressed; and is configured to receive the IP packet compressed by the IP header, where the data packet is compressed by the first device by using the first IP header compression method,
  • the IP packet compressed by the IP header carries the header compression context identifier;
  • a determining module configured to determine an IP header to be compressed corresponding to the header compression context identifier carried in the IP packet compressed by the IP header received by the transmission module;
  • a processing module configured to restore the compressed IP data packet to an IP data packet before compression according to the IP packet header to be compressed determined by the determining module.
  • the first device sends a message to the second device, where the message carries an Internet Protocol IP header and a header compression context identifier to be compressed, and the IP header to be compressed is determined according to a first IP header compression method, and the header compression context identifier is used. Identifying the IP header to be compressed;
  • the IP header is compressed by using the first IP header compression method. Transmitting the IP packet compressed IP packet to the second device, where the IP packet compressed IP packet carries the header compression context identifier, so that the second device receives the IP header compression After the IP data packet, the IP header to be compressed corresponding to the header compression context identifier carried in the IP packet compressed by the IP header is determined, and the compressed IP header is determined according to the determined IP header. The IP data packet is restored to the IP data packet before compression, thereby preventing the second device from processing the received header compression context IP data packet, and the IP data packet compressing the write context of the bearer header and the IP data packet of other services. Therefore, the efficiency of the header compression context transfer is improved, and the integrity of the compressed information of the RN and the DeNB is ensured.
  • FIG. 1 is a schematic flowchart of a data transmission method according to an embodiment of the present invention.
  • FIG. 2 is a schematic flowchart of another data transmission method according to an embodiment of the present invention.
  • FIG. 3 is a schematic flowchart of another data transmission method according to an embodiment of the present invention.
  • FIG. 4 is a schematic flowchart of another data transmission method according to an embodiment of the present invention.
  • FIG. 5 is a schematic flowchart of another data transmission method according to an embodiment of the present invention.
  • FIG. 6 is a schematic flow chart of another air interface compression method according to an embodiment of the present invention.
  • FIG. 7 is a schematic flowchart of another air interface compression method according to an embodiment of the present invention.
  • FIG. 8 is a schematic structural diagram of a data transmission apparatus according to an embodiment of the present invention.
  • FIG. 9 is a schematic structural diagram of another data transmission apparatus according to an embodiment of the present invention.
  • the nested IP header is divided into two layers, the outer packet header is IP/UDP/GTP-U, and the inner packet header is IP/UDP/RTP.
  • the IP packet header is IP/UDP/GTP-U.
  • the packet header is used as an example.
  • the IP header is the inner packet header IP/UDP/RTP, the implemented process is the same as the process described in this embodiment, but can be used between the UE and the DeNB entity (that is, on the Uu interface). , will not repeat them here.
  • the IP packet compressed by the IP header is simply referred to as the second IP packet.
  • FIG. 1 is a schematic flowchart of a data transmission method according to an embodiment of the present invention, where the embodiment includes:
  • the first device sends a message to the second device, where the message carries an Internet Protocol IP header and a header compression context identifier to be compressed, and the IP header to be compressed is determined according to a first IP header compression method, and the header compression context is determined.
  • the identifier is used to identify the IP header to be compressed.
  • the first device uses the first IP header compression method to compress the IP packet header, and sends the IP packet header compressed IP data packet to the second device, and the IP packet header compressed IP data packet. Carrying the header compression context identifier.
  • the second device After the second device receives the IP packet compressed by the IP header, determining an IP header to be compressed corresponding to the header compression context identifier carried in the IP packet compressed by the IP header, The compressed IP data packet is restored to the pre-compressed IP data packet according to the determined IP header to be compressed.
  • the method provided by the embodiment of the present invention can prevent the second device from compressing the received bearer header context IP data packet and the IP data packet of the bearer header compression write context and the IP data packet of other services, thereby improving the processing.
  • the efficiency of header compression context delivery guarantees RN and The DeNB compresses the integrity of the information.
  • FIG. 2 is a schematic flowchart of another data transmission method according to an embodiment of the present invention, where the embodiment includes:
  • the second device receives the message sent by the first device, where the message carries an Internet Protocol IP header and a header compression context identifier to be compressed, and the IP header to be compressed is determined according to the first IP header compression method, and the header is compressed.
  • the context identifier is used to identify the IP header to be compressed.
  • the second device receives the IP packet compressed by the IP header, where the data packet is compressed by the first device by using the first IP header compression method, and the IP packet compressed by the IP header is compressed. Carrying the header compression context identifier.
  • the second device determines an IP header to be compressed corresponding to the header compression context identifier carried in the IP packet compressed by the IP header, and compresses the compressed IP header according to the determined IP header.
  • the IP packet is restored to the IP packet before compression.
  • the method provided by the embodiment of the present invention can prevent the second device from compressing the received bearer header context IP data packet and the IP data packet of the bearer header compression write context and the IP data packet of other services, thereby improving the processing.
  • the efficiency of header compression context delivery ensures the integrity of the compressed information of the RN and DeNB.
  • the first device uses a relay node (Relay Node, RN), and the second device uses an evolved base station (Donor eNB, DeNB) as an example, or the first device uses the DeNB and the second device uses the RN as an example.
  • the first device and the second device include, but are not limited to, the devices listed above.
  • the embodiments in the present invention are all examples of the outer layer header.
  • FIG. 3 is a schematic flowchart of another data transmission method according to an embodiment of the present invention.
  • a header compression method supported by a DeNB and an RN is negotiated on a Un interface by using an RRC message, when the RN or the DeNB decides to start. Compressing the outer packet header, and using the link network layer layer signaling to notify the decompressed entity of the content of the outer packet header to be compressed and the header compression context identifier. After the decompression entity confirms, the outer IP header is compressed.
  • This embodiment includes: 301.
  • the DeNB sends a Radio Resource Control (RRC) reconfiguration message to the RN, where the message carries the target corresponding to the outer IP/UDP/GTP-U header compression method.
  • RRC Radio Resource Control
  • the identifier may be used to indicate that the DeNB has the capability of compressing the outer IP/UDP/GTP-U header and the specific header compression mode supported by the DeNB.
  • the specific header compression mode may be the outer IP/UDP/ The header compression method of the GTP-U header.
  • 302. Determine, according to the identifier corresponding to the received outer IP/UDP/GTP-U header compression method, an IP header compression method supported by the RN, and send an RRC reconfiguration complete message to the DeNB, where the message carries the outer IP/supported by the RN.
  • the identifier of the UDP/GTP-U header compression method is the identifier of the UDP/GTP-U header compression method.
  • step 302 if the RN does not support the outer IP/UDP/GTP-U header compression method, the RRC reconfiguration complete message does not carry the identifier of the outer header compression method of the RN.
  • the air interface bearer may be used to send an IP data packet, where the IP data packet includes an inner layer IP/UDP/GTP-U packet header and an outer layer IP/UDP/GTP- U header, that is, no compression state.
  • the RN sends an RRC Header Compression Initialization (RRC Comps sion) message to the DeNB, where the message is used to initialize a header compression context, where the message includes an outer IP/UDP/GTP-U header and a header compression context identifier to be compressed.
  • RRC Comps sion RRC Header Compression Initialization
  • the content of the compressed outer IP/UDP/GTP-U header and the header compression context identifier are determined according to the IP header compression method supported by the RN, and the header compression context identifier is used to identify the outer IP/ to be compressed.
  • UDP/GTP-U header UDP/GTP-U header.
  • the header compression context identifier may be an identifier of the RN node, may be an identifier of the UE that sends and receives the IP data packet, may be an identifier carried between the RN and the DeNB, may be a tunnel ID of the GTP-U tunnel, and may be an IP data stream. logo.
  • the identifier of the IP data stream includes a source address, a destination address, a source port, a destination port, and an IP flow quintuple composed of a transport protocol.
  • the DeNB returns an RRC Header Acknowledgement (RRC Compresynthesis Ack) message to the RN node, and responds to the initialization header compression context.
  • RRC Compresynthesis Ack RRC Header Acknowledgement
  • the RN compresses an outer IP/UDP/GTP-U packet header by using an IP header compression method supported by the RN, where the compressed IP/UDP/GTP-U data packet carries the header compression context identifier, that is, the data.
  • the header compression context identifier of the packet is preserved and the outer IP/UDP/GTP-U header is compressed.
  • the RN sends the compressed IP data packet to the DeNB.
  • the DeNB After determining, by the DeNB, the compressed IP data packet of the outer IP/UDP/GTP-U header, determining, by the outer IP/UDP/GTP-U packet header, the outer layer IP/UDP/GTP.
  • the IP/UDP/GTP-U packet is restored to the outer IP/UDP/GTP-U packet before compression.
  • the header compression context of the R0HC protocol is carried by the IP data packet and transmitted, so that the radio access network (Radio Acces s Ne twork, RAN) link layer network entity will carry the IP packet of the header compression context of the ROHC protocol and other services.
  • the IP packet is equivalently processed, resulting in low efficiency of header compression context transfer using the IP packet to carry the R0HC protocol.
  • the outer layer IP/UDP/GTP-U packet header is taken as an example, and the outer layer IP/UDP/GTP-U packet header to be compressed is carried by the access network link layer signaling message between the RN and the DeNB.
  • the header compression context identifier the RN compresses the outer IP/UDP/GTP-U header using the IP header compression method supported by the RN, and the compressed
  • the IP/UDP/GTP-U data packet carries the header compression context identifier, thereby preventing the RN or DeNB from bearing the header compression context of the outer IP/UDP/GTP-U data packet and the outer layer of other services.
  • IP/UDP/GTP-U data packet is equivalently processed, which ensures the integrity of the compressed information of the RN and the DeNB, and improves the efficiency of the header compression context transfer.
  • FIG. 4 is a schematic flowchart of another data transmission method according to an embodiment of the present invention.
  • a header compression method supported by a DeNB and an RN is negotiated on a Un interface by using an RRC message, and the RN or the DeNB decides to start compression.
  • the outer packet header, the outer IP/UDP/GTP-U header information and the header compression context identifier are notified to the decompressed entity through the PDCP layer control protocol data unit (Protoco l Da ta Uni t, PDU) message, after the decompression entity confirms Starting to compress the outer IP header, this embodiment includes: 401.
  • the DeNB sends an RRC reconfiguration message to the RN, where the message carries an identifier corresponding to the outer IP/UDP/GTP-U packet header compression method.
  • the identifier may be used to indicate that the DeNB has the capability of compressing the outer IP/UDP/GTP-U header and the specific compression mode supported by the DeNB.
  • the specific header compression mode may be the outer IP/UDP/GTP. -U header compression method.
  • step 402 if the RN does not support the outer IP/UDP/GTP-U header compression method, the RRC reconfiguration complete message does not carry the identifier of the outer header compression method of the RN.
  • the air interface bearer may be used to send an IP data packet, where the IP data packet includes an inner layer IP/UDP/GTP-U and an outer layer IP/UDP/GTP-U.
  • the header is the state of no compression.
  • the RN sends a packet data convergence protocol control packet data unit (PDCP Cont rol PDU) message to the DeNB, where the message includes a content of the compressed outer IP/UDP/GTP-U packet header and a header compression context identifier, where the compressed to be compressed
  • PDCP Cont rol PDU packet data convergence protocol control packet data unit
  • the content of the outer IP/UDP/GTP-U header and the header compression context identifier are determined according to the outer IP/UDP/GTP-U header compression method supported by the RN, and the header compression context identifier is used to identify the to-be-identified Compressed outer IP/UDP/GTP-U header.
  • the header compression context identifier may be an identifier of the RN node, may be an identifier of the UE that sends and receives the IP data packet, may be an identifier carried between the RN and the DeNB, may be a tunnel ID of the GTP-U tunnel, and may be an IP data stream. logo.
  • the identifier of the IP data stream includes a source address, a destination address, a source port, a destination port, and an IP flow quintuple composed of a transport protocol.
  • the DeNB returns an Automa t i C Repea t reques t Acknowledgement (ARQ Ack) message to the RN node.
  • ARQ Ack Automa t i C Repea t reques t Acknowledgement
  • the RN compresses the outer layer by using an IP header compression method supported by the RN.
  • IP/UDP/GTP-U packet header the compressed IP/UDP/GTP-U data packet carries the header compression context identifier, that is, the header compression context identifier of the data packet is reserved, and the outer layer IP/UDP/GTP -U header is compressed.
  • the RN sends the compressed IP data packet to the DeNB.
  • the DeNB After receiving the IP data packet compressed by the outer IP/UDP/GTP-U packet header, the DeNB determines the outer IP/UDP/GTP compressed by the outer IP/UDP/GTP-U packet header.
  • the IP/UDP/GTP-U packet is restored to the outer IP/UDP/GTP-U packet before compression.
  • the header compression context of the R0HC protocol is carried by the IP data packet and is transmitted, so that the RAN layer network entity equalizes the IP data packet carrying the header compression context of the R0HC protocol and the IP data packet of other services, thereby causing the IP data packet to be carried.
  • the header compression context of the R0HC protocol has a low transfer rate.
  • the outer layer IP/UDP/GTP-U packet header is taken as an example, and the packet data convergence unit (PDCP Cont rol PDU) message is controlled by sending a packet data convergence protocol to the DeNB, where the message includes the compressed outer layer IP/ The content of the UDP/GTP-U header and the header compression context identifier, the RN compresses the outer IP/UDP/GTP-U header using the IP header compression method supported by the RN, and the compressed IP/UDP/GTP-U data.
  • PDCP Cont rol PDU packet data convergence unit
  • the packet carries the header compression context identifier, so as to prevent the RN or the DeNB from processing the IP data packet of the bearer header compression context and the IP data packet of other services, ensuring the integrity of the compressed information of the RN and the DeNB, and improving the header compression context transmission. s efficiency.
  • FIG. 5 is a schematic flowchart of another data transmission method according to an embodiment of the present invention.
  • a header compression method supported by a DeNB and an RN is negotiated on a Un interface by using an RRC message, and the RN or the DeNB decides to start compression.
  • the outer packet header is used to notify the decompressed entity of the outer IP/UDP/GTP-U header information and the header compression context identifier by using the PDCP user plane PDU message. After the decompression entity confirms, the outer IP header is compressed.
  • the embodiment includes:
  • the DeNB sends an RRC reconfiguration message to the RN, where the message carries an identifier corresponding to the outer IP/UDP/GTP-U header compression method.
  • the identifier can be used to embody the ability of the DeNB to compress the outer IP/UDP/GTP-U header and the specific compression mode supported by the DeNB.
  • the specific header compression mode may be a header compression mode of the outer IP/UDP/GTP-U packet header.
  • step 502 if the RN does not support the outer IP/UDP/GTP-U header compression method, the RRC reconfiguration complete message does not carry the identifier of the outer packet header compression method of the DeNB.
  • the air interface bearer may be used to send an IP data packet, where the IP data packet includes an inner layer IP/UDP/GTP-U packet header and an outer layer IP/UDP/GTP- U header, that is, no compression state.
  • the RN sends a PDCP user plane PDU message to the DeNB, where the message includes the content of the compressed outer IP/UDP/GTP-U header and a header compression context identifier, and the outer layer to be compressed
  • the content of the I P / UDP / GTP-U header and the header compression context identifier are determined according to the I P header compression method supported by the RN.
  • the header compression context identifier may be an identifier of the RN node, may be an identifier of the UE that sends and receives the IP data packet, may be an identifier carried between the RN and the DeNB, may be a tunnel ID of the GTP-U tunnel, and may be an IP data stream. logo.
  • the identifier of the IP data stream includes a source address, a destination address, a source port, a destination port, and an IP flow quintuple composed of a transport protocol.
  • the DeNB returns an ARQ Ack message to the RN node.
  • the RN compresses an outer IP/UDP/GTP-U packet header by using an IP header compression method supported by the RN, where the compressed IP/UDP/GTP-U data packet carries the header compression context identifier, that is, the data.
  • the header compression context identifier of the packet is preserved and the outer IP/UDP/GTP-U header is compressed.
  • the RN sends the compressed IP data packet to the DeNB.
  • the DeNB compresses the IP packet according to the received outer IP/UDP/GTP-U header. After that, the outer IP/UDP/ to be compressed corresponding to the header compression context identifier carried in the outer IP/UDP/GTP-U packet compressed by the outer IP/UDP/GTP-U packet header is determined. GTP-U header, according to the determined outer IP/UDP/GTP-U header to be compressed, the compressed outer layer
  • the IP/UDP/GTP-U packet is restored to the outer IP/UDP/GTP-U packet before compression.
  • the outer layer IP/UDP/GTP-U packet header is used as an example, and the outer IP/UDP/GTP-U header and header compression context to be compressed are carried by the PDCP user plane PDU message between the RN and the DeNB.
  • the RN uses the IP header compression method supported by the RN to compress the outer IP/UDP/GTP-U header, and the compressed IP/UDP/GTP-U packet carries the header compression context identifier, thereby avoiding the RN.
  • the DeNB equalizes the outer IP/UDP/GTP-U data packet of the bearer header compression context and the outer IP/UDP/GTP-U data packet of other services, thereby ensuring the integrity of the compressed information of the RN and the DeNB, and improving The efficiency of header compression context delivery.
  • the PDCP layer and the RLC layer between the RN and the DeNB are in an acknowledge mode.
  • the transmitting side adds a necessary acknowledgement and retransmission mechanism to the upper layer data, and then transmits the signal. And guaranteed to pass to the peer entity.
  • the transmitting side has the ARQ capability, if the radio link control (RLC) of the receiving side receives the wrong RLC PDU, the RLC of the transmitting side is notified to retransmit the PDU that received the error. Since the RLC PDU contains the sequence number information, Supports the delivery of data to higher layers in an order or out of order.
  • the acknowledgement mode is the standard mode for packet data transmission.
  • FIG. 6 is a schematic flowchart of another air interface compression method according to an embodiment of the present invention.
  • a header compression method supported by a DeNB and an RN is negotiated on a Un interface by using an RRC message, and the RN or the DeNB decides to start compression.
  • the outer packet header, the outer IP/UDP/GTP-U header information and the header compression context identifier are used to notify the decompression entity in the PDCP layer user plane PDU to start compressing the outer IP data packet.
  • the embodiment includes:
  • the authorized evolved base station (Donor eNB, DeNB) sends an RRC reconfiguration message to the relay node (RN), where the message carries the outer layer.
  • RN relay node
  • the identifier corresponding to the IP/UDP/GTP-U header compression method is used to reflect the ability of the DeNB to compress the outer IP/UDP/GTP-U header and the specific compression mode supported by the DeNB.
  • the specific header compression mode may be an outer layer.
  • the identifier of the outer IP/UDP/GTP-U header compression method supported by the RN is the identifier of the outer IP/UDP/GTP-U header compression method supported by the RN.
  • step 602 if the RN does not support the outer IP/UDP/GTP-U header compression method, the RRC reconfiguration complete message does not carry the identifier of the outer header compression method of the RN.
  • the air interface bearer may be used to send an IP data packet, where the IP data packet includes an inner layer IP/UDP/GTP-U and an outer layer IP/UDP/GTP-U.
  • the header is the state of no compression.
  • the RN sends a PDCP user plane PDU message to the DeNB, where the message includes the content of the outer IP/UDP/GTP-U header to be compressed and the header compression context identifier, and the outer layer to be compressed
  • the content of the IP/UDP/GTP-U header and the header compression context identifier are determined according to the IP header compression method supported by the RN, and the contents of the same outer IP/UDP/GTP-U header and the header compression context identifier to be compressed are compressed. Sent by at least two PDCP PDU messages.
  • the specific number of times that the outer IP/UDP/GTP-U header information is sent to the decompressed entity can be counted according to the probability that the PDCP PDU of the Un interface is successfully sent.
  • the IP address is sent.
  • the number of UDP/GTP-U header information can be reduced accordingly.
  • the number of times IP/UDP/GTP-U header information is sent can be increased accordingly.
  • the header compression context identifier may be an identifier of the RN node, may be an identifier of the UE that sends and receives the IP data packet, may be an identifier carried between the RN and the DeNB, may be a tunnel ID of the GTP-U tunnel, and may be an IP data stream. logo.
  • the identifier of the IP data stream includes a source address, a destination address, a source port, a destination port, and an IP flow quintuple composed of a transport protocol.
  • the RN compresses the outer IP/UDP/GTP-U packet header by using the IP header compression method supported by the RN.
  • the compressed IP/UDP/GTP-U data packet carries the header compression context identifier, that is, the header compression context identifier of the data packet is reserved, and the outer IP/UDP/GTP-U header is compressed.
  • the RN sends the compressed IP data packet to the DeNB.
  • the DeNB After determining, by the DeNB, the compressed IP data packet of the outer IP/UDP/GTP-U header, the DeNB determines the outer IP/UDP/GTP compressed by the outer IP/UDP/GTP-U packet header.
  • the IP/UDP/GTP-U packet is restored to the outer IP/UDP/GTP-U packet before compression.
  • the header compression context of the R0HC protocol is carried by the IP data packet and is transmitted, so that the RAN layer network entity equalizes the IP data packet carrying the header compression context of the R0HC protocol and the IP data packet of other services, thereby causing the IP data packet to be carried.
  • the header compression context of the R0HC protocol has a low transfer rate.
  • the outer IP/UDP/GTP-U identifier carried by the access network link layer signaling message between the RN and the DeNB is used to establish a header compression context, and the header compression context of the IP data packet is reserved.
  • the identifier is used to compress the outer IP/UDP/GTP-U packet header, so as to prevent the RN or the DeNB from processing the IP data packet of the bearer header compression context and the IP data packet of other services, thereby ensuring the integrity of the compressed information of the RN and the DeNB. Improves the efficiency of header compression context delivery.
  • the PDCP layer and the RLC layer carried between the RN and the DeNB are in an unacknowledged mode.
  • the sending entity adds the necessary control protocol overhead to the upper layer PDU for transmission, but It is not guaranteed to be delivered to the peer entity, and the acknowledgment and retransmission mechanism is not used.
  • the receiving entity submits the error data received as an error, or directly discards and reports to the upper layer. Since the RLC PDU contains the sequence number, it can The integrity of the high-level PDU is detected, and the medical mode service may include cell broadcast and IP telephony.
  • the acknowledgment mode can be used in the initial stage of the header compression establishment, and the IP/UDP/GTP-U header information and the header compressed IP Flow identifier are successfully transmitted, and then the non-acknowledgment mode is passed to pass the other remaining. IP packet.
  • the RN determines and initiates an outer IP header compression process
  • this embodiment The outer IP/UDP/GTP-U header compression process initiated by the DeNB in the reverse direction is described.
  • the RRC reconfiguration message process during the establishment of the air interface bearer is consistent with the direction in which the RN initiates the header compression, but the outer layer
  • Another flow chart compression method includes:
  • the RN sends an RRC reconfiguration message to the DeNB, where the message carries an identifier corresponding to the outer IP/UDP/GTP-U packet header compression method.
  • the identifier is used to reflect the ability of the DeNB to compress the outer IP/UDP/GTP-U header and the specific compression mode supported by the DeNB.
  • step 702 if the DeNB does not support the outer IP/UDP/GTP-U header compression method, the RRC reconfiguration complete message does not carry the identifier of the outer packet header compression method of the DeNB.
  • the air interface bearer may be used to send an IP data packet, where the IP data packet includes an inner layer IP/UDP/GTP-U and an outer layer IP/UDP/GTP-U.
  • the header is the state of no compression.
  • the DeNB sends a PDCP Cont ro PDU message to the RN, where the message includes the content of the outer IP/UDP/GTP-U header to be compressed and the header compression context identifier, and the outer layer to be compressed
  • the content of the IP/UDP/GTP-U packet header and the header compression context identifier are determined according to the IP header compression method supported by the DeNB, and the header compression context identifier is used to identify the outer layer to be compressed.
  • IP/UDP/GTP-U header
  • the header compression context identifier may be an identifier of the RN node, may be an identifier of the UE that sends and receives the IP data packet, may be an identifier carried between the RN and the DeNB, may be a tunnel ID of the GTP-U tunnel, and may be an IP data stream. logo.
  • the identifier of the IP data stream includes a source address, a destination address, a source port, a destination port, and an IP flow quintuple composed of a transport protocol.
  • the quintuple of the header compression context identifier of the compressed IP stream is composed of a source address, a destination address, a source port, a destination port, and a transport protocol.
  • the RN returns an ARQ Ack message to the DeNB.
  • the DeNB compresses an outer IP/UDP/GTP-U packet header by using an IP header compression method supported by the DeNB, where the compressed IP/UDP/GTP-U data packet carries the header compression context identifier, that is, the data.
  • the header compression context identifier of the packet is preserved and the outer IP/UDP/GTP-U header is compressed.
  • the DeNB sends the compressed IP data packet to the RN.
  • the RN determines the outer IP/UDP/ compressed outer IP/UDP/GTP-U header.
  • the IP/UDP/GTP-U packet is restored to the outer IP/UDP/GTP-U packet before compression.
  • the header compression context of the R0HC protocol is carried by the IP data packet and is transmitted, so that the RAN layer network entity equalizes the IP data packet carrying the header compression context of the R0HC protocol and the IP data packet of other services, thereby causing the IP data packet to be carried.
  • the header compression context of the R0HC protocol has a low transfer rate.
  • the outer layer IP/UDP/GTP-U packet header is taken as an example, and the outer layer IP/UDP/GTP-U packet header to be compressed is carried by the access network link layer signaling message between the RN and the DeNB.
  • the header compresses the context identifier, and the DeNB uses the IP header compression method supported by the DeNB to compress the outer layer.
  • the IP/UDP/GTP-U packet header, the compressed IP/UDP/GTP-U data packet carries the header compression context identifier, thereby preventing the RN or the DeNB from compressing the outer layer IP/UDP/GTP of the bearer header.
  • U packets are equivalent to the outer IP/UDP/GTP-U packets of other services, ensuring the integrity of the compressed information of the RN and the DeNB, and improving the efficiency of the header compression context transfer.
  • FIG. 7 is similar to the process of header compression in the embodiment 3 shown in FIG. 3, except that the header compression process initiated by the DeNB is performed, and the entity performing header compression is DeNB, similarly, FIG.
  • FIG. 4 The embodiment shown in FIG. 4, FIG. 5, and FIG. 6 may be subjected to a header compression process initiated by the DeNB, and the DeNB enters Line header compression, not repeated here.
  • FIG. 8 is a schematic structural diagram of a data transmission apparatus according to an embodiment of the present invention, including: a determining module 801, configured to determine, according to a first Internet Protocol IP header compression method, a header to be compressed, where the IP header to be compressed is compressed by a header Context identifier representation;
  • the transmitting module 802 is configured to send signaling to the second device, where the signaling carries the IP header and header compression context identifier to be compressed determined by the determining module;
  • the processing module 803 is configured to compress, by using the first IP header compression method, the IP header determined by the determining module;
  • the transmission module 804 is configured to send, to the second device, the IP data packet that is processed by the processing module to perform the IP header compression, where the IP packet compressed by the IP header carries the header compression context identifier, After the second device receives the IP packet compressed by the IP header, determining the IP header to be compressed corresponding to the header compression context identifier carried in the IP packet compressed by the IP header, according to the The determined IP header to be compressed restores the compressed IP packet to an IP packet before compression.
  • the IP header is compressed by using the first IP header compression method, and the IP packet compressed by the IP header is sent to the second device, and the IP packet compressed by the IP header is compressed.
  • Carrying the header compression context identifier so that after the second device receives the IP packet compressed by the IP header, determining the header compression context identifier carried in the IP packet compressed by the IP header
  • the compressed IP data packet is restored to the IP data packet before compression according to the determined IP packet header to be compressed, thereby preventing the second device from compressing the received bearer context IP data.
  • the packet, and the IP data packet that compresses the write context of the bearer header and the IP data packet of other services are equivalently processed, thereby improving the efficiency of the header compression context transfer and ensuring the integrity of the compressed information of the RN and the DeNB.
  • the transmission module is further configured to receive an identifier corresponding to the IP header compression method sent by the second device, where the determining module is further configured to use the IP header compression method corresponding to the identifier received by the transmission module as a The first IP header compression method is described. Further, the transmission module is further configured to receive a target corresponding to the IP header compression method supported by the second device;
  • the determining module is further configured to determine a first IP packet header compression method adopted by the first device in the IP header compression method corresponding to the identifier received by the transmission module;
  • the transmitting module is further configured to send, to the second device, an identifier corresponding to the first IP header compression method determined by the determining module, so that the second device is configured according to the first IP header compression method. Identifying a location of the IP header to be compressed in the IP packet before compression, and restoring the compressed IP packet to a pre-compression IP according to the determined IP header to be compressed and the determined location data pack.
  • the transmission module is further configured to receive, receive, and send the second device
  • An acknowledgement message is described for compressing the IP header and the header compression context identifier, and the acknowledgement message is an automatic repeat request acknowledgement ARQ ACK message.
  • FIG. 9 is a schematic structural diagram of another data transmission apparatus according to an embodiment of the present invention, including: a transmission module 901, configured to receive signaling sent by a first device, where the signaling carries an Internet Protocol IP header and header compression to be compressed. a context identifier, the IP header to be compressed is determined according to a first IP header compression method, the header compression context identifier is used to identify the IP header to be compressed, and the IP packet compressed by the IP header is received. The data packet is compressed by the first device by using the first IP packet header compression method, and the IP packet compressed by the IP packet header carries the header compression context label;
  • a determining module 902 configured to determine an IP packet header to be compressed corresponding to the header compression context identifier carried in the IP packet compressed by the IP packet header received by the transmission module;
  • the processing module 903 is configured to restore the compressed IP packet to the IP packet before compression according to the IP header to be compressed determined by the determining module.
  • the second device can prevent the received bearer from compressing the context IP data packet, and compressing the bearer to write the context of the IP data packet and other services.
  • the IP data packets are equivalently processed, thereby improving the efficiency of header compression context delivery and ensuring the integrity of the compressed information of the RN and the DeNB.
  • the transmitting module is configured to send, to the first device, an identifier corresponding to the IP header compression method, so that the first device uses the IP header compression method corresponding to the identifier as the first IP header compression method.
  • the transmitting module is further configured to send, to the first device, an identifier corresponding to an IP header compression method that the second device can support, so that the first device determines an IP header compression method corresponding to the identifier.
  • the transmitting module is further configured to receive a target corresponding to the first IP header compression method sent by the first device;
  • the determining module is further configured to determine, according to the identifier corresponding to the first IP header compression method received by the transmission module, the location of the IP header to be compressed in the IP data packet before compression; And compressing the compressed IP data packet into an IP data packet before compression according to the IP header to be compressed determined by the determining module and the determined location.
  • the transmission module is further configured to send the second device to the first device And receiving an acknowledgement message of the IP header to be compressed and the header compression context identifier, where the acknowledgement message is an automatic retransmission request acknowledgement ARQ ACK message.
  • the IP packet compressed by the IP header is simply referred to as the second IP packet.
  • each unit included is only divided according to functional logic, but is not limited to the foregoing division, as long as the corresponding function can be implemented;
  • the specific names are also for convenience of distinguishing from each other and are not intended to limit the scope of the present invention.
  • the above mentioned storage medium may be a read only memory, a magnetic disk or an optical disk or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

一种压缩方法与装置
本申请要求于 2010 年 09 月 20 日提交中国专利局、 申请号为 201010287387.5 ,发明名称为"一种压缩方法与装置 "的中国专利申请的优先 权， 其全部内容通过引用结合在本申请中。 技术领域 本发明涉及无线通讯技术领域， 具体涉及一种压缩方法与装置。 背景技术 长期演进（Long Term Evolution, LTE )规范中的分组数据汇聚协议 ( Packet Data Convergence Protocol， PDCP )层及其压缩功能， 在演进基站 ( Evolution NodeB， eNB )和用户设备 ( User Equipment, UE )之间的空口 分别被用于控制面信令压缩和用户面数据压缩。
在 UE和 eNB的 PDCP层中对分组流进行鲁棒性 IP头压缩 （Robust Header Compression, ROHC ), 其功能实体包括压缩器和解压缩器， 这种压 缩方式不仅能节省空中接口的容量， 还能节省 LTE-Uu接口上的传输容量。 ROHC 包括因特网协议 ( Internet Protocol , IP ) /用户数据才艮协议 ( User Datagram Protocol, UDP )/实时传输协议（ Real-time Transport Protocol, RTP ) 类和 UDP/IP类和 ESP ( Encapsulating Security Payload ) /IP压缩类。
嵌套的 IP包头分为两层， 内层 IP包头可以为 IP/UDP/RTP、 IP/UDP、 IP/传输控制协议包头（ Transport Control Protocol， TCP )， 外层 IP包头可以 为因特网协议（ Internet Protocol， IP )/UDP/GPRS隧道协议用户面协议（ GPRS Tunneling Protocol-User plane, GTP-U )包头， 通过内层 IP包头压缩框架和 外层 IP包头压缩框架分别对各个协议包头进行压缩， 发送包头压缩后的 IP 数据包， 从而降低了头压缩上下文的传递效率。 发明内容 本发明实施例提供了一种数据传输方法， 以提高头压缩上下文的传递 效率。
本发明实施例具体可以通过如下技术方案实现：
一方面， 提供了一种数据传输方法， 包括：
第一设备向第二设备发送消息， 所述消息携带待压缩的因特网协议 IP 包头和头压缩上下文标识，所述待压缩的 IP包头根据第一 IP包头压缩方法 确定， 所述头压缩上下文标识用于标识所述待压缩的 IP包头；
所述第一设备使用所述第一 IP包头压缩方法压缩所述 IP包头，向所述 第二设备发送所述 IP包头压缩后的 IP数据包， 所述 IP包头压缩后的 IP数 据包携带所述头压缩上下文标识， 以使得所述第二设备收到所述 IP包头压 缩后的 IP数据包后， 确定所述 IP包头压缩后的 IP数据包中携带的所述头 压缩上下文标识所对应的待压缩的 IP包头，根据所确定的待压缩的 IP包头 将所述压缩后的 IP数据包恢复为压缩前的 IP数据包。
一方面， 提供了另一种数据传输方法， 包括：
第二设备接收第一设备发送的消息， 所述消息携带待压缩的因特网协 议 IP包头和头压缩上下文标识， 所述待压缩的 IP包头根据第一 IP包头压 缩方法确定， 所述头压缩上下文标识用于标识所述待压缩的 IP包头；
所述第二设备接收所述 IP包头压缩后的 IP数据包，所述数据包为所述 第一设备使用所述第一 IP包头压缩方法压缩， 所述 IP包头压缩后的 IP数 据包携带所述头压缩上下文标识；
所述第二设备确定所述 IP包头压缩后的 IP数据包中携带的所述头压缩 上下文标识所对应的待压缩的 IP包头，根据所确定的待压缩的 IP包头将所 述压缩后的 IP数据包恢复为压缩前的 IP数据包。
一方面， 提供了一种数据传输装置， 其特征在于， 包括：
确定模块， 用于根据第一因特网协议 IP包头压缩方法确定待压缩的包 头， 所述待压缩的 IP包头用头压缩上下文标识表示；
传输模块， 用于向第二设备发送消息， 所述消息携带所述确定模块确 定的所述待压缩的 IP包头和头压缩上下文标识；
处理模块， 用于使用所述第一 IP包头压缩方法压缩所述确定模块确定 的所述 IP包头；
所述传输模块， 用于向所述第二设备发送所述处理模块进行所述 IP包 头压缩后的 IP数据包， 所述 IP包头压缩后的 IP数据包携带所述头压缩上 下文标识， 以使得所述第二设备收到所述 IP包头压缩后的 IP数据包后，确 定所述 IP包头压缩后的 IP数据包中携带的所述头压缩上下文标识所对应的 待压缩的 IP包头， 根据所确定的待压缩的 IP包头将所述压缩后的 IP数据 包恢复为压缩前的 IP数据包。
一方面， 提供了另一种数据传输装置， 其特征在于， 包括：
传输模块， 用于接收第一设备发送的消息， 所述消息携带待压缩的因 特网协议 IP包头和头压缩上下文标识， 所述待压缩的 IP包头根据第一 IP 包头压缩方法确定，所述头压缩上下文标识用于标识所述待压缩的 IP包头； 用于接收所述 IP包头压缩后的 IP数据包，所述数据包为所述第一设备使用 所述第一 IP包头压缩方法压缩， 所述 IP包头压缩后的 IP数据包携带所述 头压缩上下文标识；
确定模块，用于确定所述传输模块接收的所述 IP包头压缩后的 IP数据 包中携带的所述头压缩上下文标识所对应的待压缩的 IP包头；
处理模块， 用于根据所述确定模块所确定的待压缩的 IP包头， 将所述 压缩后的 IP数据包恢复为压缩前的 IP数据包。
第一设备向第二设备发送消息， 所述消息携带待压缩的因特网协议 IP 包头和头压缩上下文标识，所述待压缩的 IP包头根据第一 IP包头压缩方法 确定， 所述头压缩上下文标识用于标识所述待压缩的 IP包头；
本发明各实施例，通过使用所述第一 IP包头压缩方法压缩所述 IP包头， 向所述第二设备发送所述 IP包头压缩后的 IP数据包， 所述 IP包头压缩后 的 IP数据包携带所述头压缩上下文标识， 以使得所述第二设备收到所述 IP 包头压缩后的 IP数据包后， 确定所述 IP包头压缩后的 IP数据包中携带的 所述头压缩上下文标识所对应的待压缩的 IP包头， 根据所确定的待压缩的 IP包头将所述压缩后的 IP数据包恢复为压缩前的 IP数据包， 从而避免第 二设备将接收到的承载头压缩上下文 IP数据包、 以及将承载头压缩写上下 文的 IP数据包和其他业务的 IP数据包等同处理，从而提高了头压缩上下文 传递的效率， 保证了 RN和 DeNB压缩信息的完整性。
附图说明 为了更清楚地说明本发明实施例中的技术方案， 下面将对实施例描述 中所需要使用的附图作简要介绍， 显而易见地， 下面描述中的附图仅仅是 本发明的一些实施例， 对于本领域的普通技术人员来讲， 在不付出创造性 劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1为本发明实施例的一种数据传输方法流程示意图；
图 2为本发明实施例的另一种数据传输方法流程示意图；
图 3为本发明实施例的另一种数据传输方法流程示意图；
图 4为本发明实施例的另一种数据传输方法流程示意图；
图 5为本发明实施例的另一种数据传输方法流程示意图；
图 6为本发明实施例的另一种空口压缩方法流程示意图；
图 7为本发明实施例的另一种空口压缩方法流程示意图；
图 8为本发明实施例的一种数据传输装置的结构示意图；
图 9为本发明实施例的另一种数据传输装置的结构示意图。
具体实施方式 为了使本发明的目的、 技术方案和优点更加清楚， 下面将结合附图对 本发明作进一步地详细描述， 显然， 所描述的实施例仅仅是本发明一部份 实施例， 而不是全部的实施例。 基于本发明中的实施例， 本领域普通技术 人员在没有做出创造性劳动前提下所获得的所有其它实施例， 都属于本发 明保护的范围。
嵌套的 IP 包头分为两层， 外层包头为 IP/UDP/GTP-U， 内层包头为 IP/UDP/RTP, 本申请的实施例中， IP包头以外层 IP/UDP/GTP-U包头为例 进行说明， 当 IP包头为内层包头 IP/UDP/RTP时， 所实现的流程和本实施 例中说明的过程一致，只是可以用于 UE和 DeNB实体之间（即 Uu接口上）， 在此不再赘述。
为了使描述清楚， 本发明实施例中将 IP包头压缩后的 IP数据包简称 为第二 IP数据包。
图 1为本发明实施例的一种数据传输方法流程示意图， 该实施例包括：
101、 第一设备向第二设备发送消息， 所述消息携带待压缩的因特网协 议 I P包头和头压缩上下文标识， 所述待压缩的 IP包头根据第一 I P包头压缩 方法确定， 所述头压缩上下文标识用于标识所述待压缩的 IP包头。
102、 所述第一设备使用所述第一 IP包头压缩方法压缩所述 IP包头， 向 所述第二设备发送所述 IP包头压缩后的 IP数据包， 所述 IP包头压缩后的 IP 数据包携带所述头压缩上下文标识。
以使得所述第二设备收到所述 IP包头压缩后的 IP数据包后， 确定所述 IP包头压缩后的 IP数据包中携带的所述头压缩上下文标识所对应的待压缩 的 IP包头， 根据所确定的待压缩的 IP包头将所述压缩后的 IP数据包恢复为 压缩前的 IP数据包。
采用本发明实施例提供的方法， 能够避免第二设备将接收到的承载头 压缩上下文 IP数据包、 以及将承载头压缩写上下文的 IP数据包和其他业务 的 IP数据包等同处理， 从而提高了头压缩上下文传递的效率， 保证了 RN和 DeNB压缩信息的完整性。
图 2为本发明实施例的另一种数据传输方法流程示意图， 该实施例包 括：
201、 第二设备接收第一设备发送的消息， 所述消息携带待压缩的因特 网协议 IP包头和头压缩上下文标识， 所述待压缩的 IP包头根据第一 IP包头 压缩方法确定， 所述头压缩上下文标识用于标识所述待压缩的 IP包头。
202、 所述第二设备接收所述 IP包头压缩后的 IP数据包， 所述数据包为 所述第一设备使用所述第一 IP包头压缩方法压缩， 所述 IP包头压缩后的 IP 数据包携带所述头压缩上下文标识。
203、 所述第二设备确定所述 IP包头压缩后的 IP数据包中携带的所述头 压缩上下文标识所对应的待压缩的 IP包头， 根据所确定的待压缩的 IP包头 将所述压缩后的 IP数据包恢复为压缩前的 IP数据包。
采用本发明实施例提供的方法， 能够避免第二设备将接收到的承载头 压缩上下文 IP数据包、 以及将承载头压缩写上下文的 IP数据包和其他业务 的 IP数据包等同处理， 从而提高了头压缩上下文传递的效率， 保证了 RN和 DeNB压缩信息的完整性。
本发明实施例中第一设备以中继节点 （Relay Node , RN ) 、 第二设备 以演进的基站（Donor eNB, DeNB )为例， 或者第一设备以 DeNB、 第二设备 以 RN为例进行说明， 所述第一设备与第二设备包括但不限于上述列举的设 备。
本发明中的实施例都是以外层包头为例进行说明。
图 3为本发明实施例另一种数据传输方法流程示意图， RN和 DeNB之间的 承载建立阶段， 使用 RRC消息将 DeNB和 RN支持的头压缩方法在 Un接口上协 商， 当 RN或者 DeNB决定开始压缩外层包头， 使用接入网链路层信令将所要 压缩外层包头的内容和头压缩上下文标识通知给解压实体， 在解压实体确 认后， 开始压缩外层 IP包头， 本实施例包括： 301、 在空口承载建立阶段， DeNB向 RN发送无线资源控制 （Radio Resource Cont rol , RRC )重配置消息， 该消息携带了外层 IP/UDP/GTP-U包 头压缩方法对应的标只。
该标识可以用于体现该 DeNB具有压缩外层 IP/UDP/GTP-U包头的能力和 DeNB所支持的具体的头压缩方式， 步骤 301中， 具体的头压缩方式可以为外 层 IP/UDP/GTP-U包头的头压缩方式。
302、 根据接收的外层 IP/UDP/GTP-U包头压缩方法对应的标识， 确定 RN 支持的 IP包头压缩方法， 向 DeNB发送 RRC重配置完成消息， 该消息携带该 RN 支持的外层 IP/UDP/GTP-U包头压缩方法的标识。
步骤 302中， 若 RN不支持该外层 IP/UDP/GTP-U包头压缩方法， 则 RRC重 配置完成消息不携带 RN的外层包头压缩方法的标识。
303、可选的，在空口承载建立后，该空口承载可以用于发送 IP数据包， 此时的 IP数据包中包括内层 IP/UDP/GTP-U包头和外层 IP/UDP/GTP-U包头， 即没有压缩的状态。
304、 RN向 DeNB发送 RRC头压缩初始化（ RRC Compres s ionlni t ) 消息， 用于初始化头压缩上下文， 该消息包括待压缩的外层 IP/UDP/GTP-U包头和 头压缩上下文标识， 该待压缩的外层 IP/UDP/GTP-U包头的内容和头压缩上 下文标识是根据 RN所支持的 IP包头压缩方法确定的， 所述头压缩上下文标 识用于标识所述待压缩的外层 I P/UDP/GTP-U包头。
头压缩上下文标识可以是 RN节点的标识， 可以是发送和接收 IP数据包 的 UE的标识，可以是 RN和 DeNB之间承载的标识，可以是 GTP-U隧道的隧道 ID， 可以是 I P数据流的标识。
其中， IP数据流的标识包括源地址、 目的地址、 源端口、 目的端口、 传输协议组成的 IP流五元组。
305、 DeNB向 RN节点返回 RRC头压缩确认（RRC Compres s ionAck )消息， 对初始化头压缩上下文的应答。 306、 RN使用该 RN支持的 IP包头压缩方法，压缩外层 IP/UDP/GTP-U包头， 所述压缩后的 IP/UDP/GTP-U数据包携带所述头压缩上下文标识， 即该数据 包的头压缩上下文标识被保留， 外层 IP/UDP/GTP-U包头被压缩。
307、 RN向 DeNB发送压缩后的 IP数据包。
308、 DeNB根据收到的所述外层 IP/UDP/GTP-U包头压缩后的 IP数据包 后， 确定所述外层 IP/UDP/GTP-U包头压缩后的外层 IP/UDP/GTP-U数据包中 携带的所述头压缩上下文标识所对应的待压缩的外层 IP/UDP/GTP-U包头， 根据所确定的待压缩的外层 IP/UDP/GTP-U包头将所述压缩后的外层
IP/UDP/GTP-U数据包恢复为压缩前的外层 IP/UDP/GTP-U数据包。
R0HC协议的头压缩上下文通过 IP数据包承载， 并进行传递， 使无线接 入网 （Radio Acces s Ne twork, RAN )链路层网络实体将承载 ROHC协议的头 压缩上下文的 IP数据包和其他业务的 IP数据包等同处理， 从而导致用 IP数 据包承载 R0HC协议的头压缩上下文传递效率低。 而本发明实施例中， 以外 层 IP/UDP/GTP-U包头为例， 通过 RN和 DeNB之间的接入网链路层信令消息携 带待压缩的外层 IP/UDP/GTP-U包头和头压缩上下文标识， RN使用该 RN支持 的 IP包头压缩方法， 压缩外层 IP/UDP/GTP-U包头， 所述压缩后的
IP/UDP/GTP-U数据包携带所述头压缩上下文标识， 从而避免 RN或 DeNB将承 载头压缩上下文的外层 IP/UDP/GTP-U数据包和其他业务的外层
IP/UDP/GTP-U数据包等同处理， 保证了 RN和 DeNB压缩信息的完整性， 提高 了头压缩上下文传递的效率。
图 4为本发明实施例另一种数据传输方法流程示意图， RN和 DeNB之间的 承载建立阶段， 使用 RRC消息将 DeNB和 RN支持的头压缩方法在 Un接口上协 商， RN或者 DeNB决定开始压缩外层包头， 通过 PDCP层控制协议数据单元 ( Protoco l Da ta Uni t , PDU ) 消息将外层 IP/UDP/GTP-U包头信息和头压缩 上下文标识通知给解压实体， 在解压实体确认后， 开始压缩外层 IP包头， 该实施例包括： 401、 在空口承载建立阶段， DeNB向 RN发送 RRC重配置消息， 该消息携 带了外层 IP/UDP/GTP-U包头压缩方法对应的标识。
该标识可以用于体现该 DeNB具有压缩外层 IP/UDP/GTP-U包头的能力和 DeNB所支持的具体的压缩方式， 步骤 401中， 具体的头压缩方式可以为外层 IP/UDP/GTP-U包头的头压缩方式。
402、 根据接收到的外层 I P/UDP/GTP-U包头压缩方法对应的标识确定 RN 支持的 IP包头压缩方法， 向 DeNB发送 RRC重配置完成消息， 该消息携带该 RN 支持的外层 IP/UDP/GTP-U包头压缩方法的标识。
步骤 402中， 若 RN不支持该外层 IP/UDP/GTP-U包头压缩方法， 则 RRC重 配置完成消息不携带 RN的外层包头压缩方法的标识。
403、可选的，在空口承载建立后，该空口承载可以用于发送 IP数据包， 此时的 IP数据包中包括内层 IP/UDP/GTP-U和外层 IP/UDP/GTP-U包头， 即没 有压缩的状态。
404、 RN向 DeNB发送分组数据汇聚协议控制分组数据单元（ PDCP Cont rol PDU )消息， 该消息包括该压缩的外层 IP/UDP/GTP-U包头的内容和头压缩上 下文标识， 该待压缩的外层 IP/UDP/GTP-U包头的内容和头压缩上下文标识 是根据 RN所支持的外层 IP/UDP/GTP-U包头压缩方法确定的， 所述头压缩上 下文标识用于标识所述待压缩的外层 IP/UDP/GTP-U包头。
头压缩上下文标识可以是 RN节点的标识， 可以是发送和接收 I P数据包 的 UE的标识， 可以是 RN和 DeNB之间 载的标识， 可以是 GTP-U隧道的隧道 ID, 可以是 IP数据流的标识。
其中， IP数据流的标识包括源地址、 目的地址、 源端口、 目的端口、 传输协议组成的 IP流五元组。
405、 DeNB向 RN节点返回自动重传清求确认通知 ( Automa t i c Repea t reques t Acknowledgement, ARQ Ack)消息。
406、 RN使用所述 RN支持的 IP包头压缩方法， 压缩所述外层 IP/UDP/GTP-U包头， 所述压缩后的 IP/UDP/GTP-U数据包携带所述头压缩上 下文标识， 即该数据包的头压缩上下文标识被保留， 外层 IP/UDP/GTP-U包 头被压缩。
407、 RN向 DeNB发送压缩后的 IP数据包。
408、 DeNB据收到的所述外层 IP/UDP/GTP-U包头压缩后的 IP数据包后， 确定所述外层 IP/UDP/GTP-U包头压缩后的外层 IP/UDP/GTP-U数据包中携带 的所述头压缩上下文标识所对应的待压缩的外层 IP/UDP/GTP-U包头， 根据 所确定的待压缩的外层 IP/UDP/GTP-U包头将所述压缩后的外层
IP/UDP/GTP-U数据包恢复为压缩前的外层 IP/UDP/GTP-U数据包。
R0HC协议的头压缩上下文通过 IP数据包承载， 并进行传递， 使 RAN层网 络实体将承载 R0HC协议的头压缩上下文的 IP数据包和其他业务的 IP数据包 等同处理， 从而导致用 IP数据包承载 R0HC协议的头压缩上下文传递率低的 问题。 而本发明实施例中， 以外层 IP/UDP/GTP-U包头为例， 通过向 DeNB发 送分组数据汇聚协议控制分组数据单元（PDCP Cont rol PDU ) 消息， 该消 息包括该压缩的外层 IP/UDP/GTP-U包头的内容和头压缩上下文标识， RN使 用该 RN支持的 IP包头压缩方法， 压缩外层 IP/UDP/GTP-U包头， 所述压缩后 的 IP/UDP/GTP-U数据包携带所述头压缩上下文标识， 从而避免 RN或 DeNB将 承载头压缩上下文的 IP数据包和其他业务的 IP数据包等同处理， 保证了 RN 和 DeNB压缩信息的完整性， 提高了头压缩上下文传递的效率。
图 5为本发明实施例另一种数据传输方法流程示意图， RN和 DeNB之间的 承载建立阶段， 使用 RRC消息将 DeNB和 RN支持的头压缩方法在 Un接口上协 商， RN或者 DeNB决定开始压缩外层包头， 通过 PDCP用户面 PDU消息将外层 IP/UDP/GTP-U包头信息和头压缩上下文标识通知给解压实体， 在解压实体 确认后， 开始压缩外层 IP包头， 该实施例包括：
501、 在空口承载建立阶段， DeNB向 RN发送 RRC重配置消息， 该消息携 带了外层 IP/UDP/GTP-U包头压缩方法对应的标识。 该标识可以用于体现 DeNB具有压缩外层 IP/UDP/GTP-U包头的能力和 DeNB所支持的具体的压缩方式。 步骤 501中， 具体的头压缩方式可以为外层 IP/UDP/GTP-U包头的头压缩方式。
502、 根据接收到的外层 IP/UDP/GTP-U包头压缩方法对应的标识， 确定 RN支持的 IP包头压缩方法， 向 RN发送 RRC重配置完成消息， 该消息携带该 RN 支持的外层 IP/UDP/GTP-U包头压缩方法的标识。
步骤 502中， 若 RN不支持该外层 IP/UDP/GTP-U包头压缩方法， 则 RRC重 配置完成消息不携带 DeNB的外层包头压缩方法的标识。
503、可选的，在空口承载建立后，该空口承载可以用于发送 IP数据包， 此时的 IP数据包中包括内层 IP/UDP/GTP-U包头和外层 IP/UDP/GTP-U包头， 即没有压缩的状态。
504、 RN向 DeNB发送 PDCP用户面 PDU消息， 该消息包括该压缩的外层 IP/UDP/GTP-U包头的内容和头压缩上下文标识， 该待压缩的外层
I P / UDP / GTP-U包头的内容和头压缩上下文标识艮据 RN所支持的 I P包头压缩 方法确定的。
头压缩上下文标识可以是 RN节点的标识， 可以是发送和接收 I P数据包 的 UE的标识， 可以是 RN和 DeNB之间承载的标识， 可以是 GTP-U隧道的隧道 ID, 可以是 IP数据流的标识。
其中， IP数据流的标识包括源地址、 目的地址、 源端口、 目的端口、 传输协议组成的 IP流五元组。
505、 DeNB向 RN节点返回 ARQ Ack消息。
506、 RN使用该 RN支持的 IP包头压缩方法，压缩外层 IP/UDP/GTP-U包头， 所述压缩后的 IP/UDP/GTP-U数据包携带所述头压缩上下文标识， 即该数据 包的头压缩上下文标识被保留， 外层 IP/UDP/GTP-U包头被压缩。
507、 RN向 DeNB发送压缩后的 IP数据包。
508、 DeNB根据收到的所述外层 IP/UDP/GTP-U包头压缩后的 IP数据包 后， 确定所述外层 IP/UDP/GTP-U包头压缩后的外层 IP/UDP/GTP-U数据包中 携带的所述头压缩上下文标识所对应的待压缩的外层 IP/UDP/GTP-U包头， 根据所确定的待压缩的外层 IP/UDP/GTP-U包头将所述压缩后的外层
IP/UDP/GTP-U数据包恢复为压缩前的外层 IP/UDP/GTP-U数据包。 。 而本发明实施例中， 以外层 IP/UDP/GTP-U包头为例， 通过 RN和 DeNB之 间的 PDCP用户面 PDU消息携带待压缩的外层 IP/UDP/GTP-U包头和头压缩上 下文标识， RN使用该 RN支持的 IP包头压缩方法， 压缩外层 IP/UDP/GTP-U包 头， 所述压缩后的 IP/UDP/GTP-U数据包携带所述头压缩上下文标识， 从而 避免 RN或 DeNB将承载头压缩上下文的外层 IP/UDP/GTP-U数据包和其他业务 的外层 IP/UDP/GTP-U数据包等同处理， 保证了 RN和 DeNB压缩信息的完整性， 提高了头压缩上下文传递的效率。
图 4与图 5所示的实施例， RN与 DeNB之间 载 PDCP层和 RLC层为确认模 式， 在确认模式中， 发送侧在高层数据上添加必要的确认和重传机制后， 进行传送， 并保证传递到对等实体。 因为发送侧具有 ARQ能力， 如果接收侧 的无线链路控制 （Radio Link Control, RLC )收到错误的 RLC PDU，通知发送 侧的 RLC重传接收错误的 PDU， 由于 RLC PDU中包含顺序号信息， 支持数据向 高层的顺序或乱序递交， 确认模式是分组数据传输的标准模式。
图 6为本发明实施例另一种空口压缩方法流程示意图， RN和 DeNB之间的 承载建立阶段， 使用 RRC消息将 DeNB和 RN支持的头压缩方法在 Un接口上协 商， RN或者 DeNB决定开始压缩外层包头， 使用在 PDCP层用户面 PDU将外层 IP/UDP/GTP-U包头信息和头压缩上下文标识通知解压实体， 开始压缩外层 IP数据包， 该实施例包括：
601、 在空口承载建立阶段， 授权演进基站（Donor eNB, DeNB ) 向中 继节点 ( Re l ay Node , RN )发送 RRC重配置消息， 该消息携带了外层
IP/UDP/GTP-U包头压缩方法对应的标识。 该标识用于体现 DeNB具有压缩外层 IP/UDP/GTP-U包头的能力和 DeNB所 支持的具体的压缩方式。 步骤 601中， 具体的头压缩方式可以为外层
IP/UDP/GTP-U包头的头压缩方式。
602、 根据接收到的外层 IP/UDP/GTP-U包头压缩方法对应的标识， 确定 RN支持的 IP包头压缩方法， 向 DeNB发送 RRC重配置完成消息， 该消息携带该
RN支持的外层 I P/UDP/GTP-U包头压缩方法的标识。
步骤 602中， 若 RN不支持该外层 IP/UDP/GTP-U包头压缩方法， 则 RRC重 配置完成消息不携带 RN的外层包头压缩方法的标识。
603、可选的，在空口承载建立后，该空口承载可以用于发送 IP数据包， 此时的 IP数据包中包括内层 IP/UDP/GTP-U和外层 IP/UDP/GTP-U包头， 即没 有压缩的状态。
604、 RN向 DeNB发送 PDCP用户面 PDU消息， 该消息包括待压缩的外层 IP/UDP/GTP-U包头的内容和头压缩上下文标识， 该待压缩的外层
I P / UDP / GTP-U包头的内容和头压缩上下文标识艮据 RN所支持的 I P包头压缩 方法确定的， 并且将压缩的相同外层 IP/UDP/GTP-U包头的内容和头压缩上 下文标识通过至少两个 PDCP PDU消息发送。
其中， 发送外层 IP/UDP/GTP-U包头信息传递给解压实体的具体次数可 以根据 Un接口的 PDCP PDU成功发送的概率进行统计， 在 Un接口上的成功发 送概率较高时， 发送 IP/UDP/GTP-U包头信息的次数可以相应减少， 反之， 发送 IP/UDP/GTP-U包头信息的次数可以相应增加。
头压缩上下文标识可以是 RN节点的标识， 可以是发送和接收 I P数据包 的 UE的标识， 可以是 RN和 DeNB之间承载的标识， 可以是 GTP-U隧道的隧道 ID, 可以是 IP数据流的标识。
其中， IP数据流的标识包括源地址、 目的地址、 源端口、 目的端口、 传输协议组成的 IP流五元组。
605、 RN使用该 RN支持的 IP包头压缩方法，压缩外层 IP/UDP/GTP-U包头， 所述压缩后的 IP/UDP/GTP-U数据包携带所述头压缩上下文标识， 即该数据 包的头压缩上下文标识被保留， 外层 IP/UDP/GTP-U包头被压缩。
606、 RN向 DeNB发送压缩后的 IP数据包。
607、 DeNB根据收到的所述外层 IP/UDP/GTP-U包头压缩后的 IP数据包 后， 确定所述外层 IP/UDP/GTP-U包头压缩后的外层 IP/UDP/GTP-U数据包中 携带的所述头压缩上下文标识所对应的待压缩的外层 IP/UDP/GTP-U包头， 根据所确定的待压缩的外层 IP/UDP/GTP-U包头将所述压缩后的外层
IP/UDP/GTP-U数据包恢复为压缩前的外层 IP/UDP/GTP-U数据包。
R0HC协议的头压缩上下文通过 IP数据包承载， 并进行传递， 使 RAN层网 络实体将承载 R0HC协议的头压缩上下文的 IP数据包和其他业务的 IP数据包 等同处理， 从而导致用 IP数据包承载 R0HC协议的头压缩上下文传递率低的 问题。 而本发明实施例中， 通过 RN和 DeNB之间的接入网链路层信令消息携 带的外层 IP/UDP/GTP-U标识， 建立头压缩上下文， 保留该 IP数据包的头压 缩上下文标识， 对外层 IP/UDP/GTP-U包头进行压缩， 从而避免 RN或 DeNB将 承载头压缩上下文的 IP数据包和其他业务的 IP数据包等同处理， 保证了 RN 和 DeNB压缩信息的完整性， 提高了头压缩上下文传递的效率。
在图 6所示的实施例中， RN和 DeNB之间承载的 PDCP层和 RLC层为非确认 模式， 在非确认模式中， 发送实体在高层 PDU上添加必要的控制协议开销， 进行传送， 但不保证传递到对等实体， 且没有使用确认和重传机制， 接收 实体对所接收到的错误数据标记为错误后递交， 或者直接丟弃并向高层报 告， 由于 RLC PDU包含顺序号， 因此能够检测高层 PDU的完整性， 醫模式的 业务可以包括小区广播和 I P电话。
另外， 根据 Un接口上承载的业务不同， 可以在头压缩建立初期使用确 认模式， 将 IP/UDP/GTP-U包头信息和头压缩的 IP Flow标识成功传递后， 再 进入非确认模式传递其它剩余的 I P数据包。
以上几个实施例中， 由 RN判断并发起外层 I P包头压缩过程， 本实施例 中说明了反方向的 DeNB发起的外层 IP/UDP/GTP-U包头压缩过程， 空口承载 建立期间的 RRC重配置消息过程和 RN发起头压缩的方向一致， 但是外层
IP/UDP/GTP-U包头信息和压缩信息传递的方向是相反的， 如图 7所示， 为本 发明实施例另一种空口压缩方法流程示意图， 包括：
701、 在空口承载建立阶段， RN向 DeNB发送 RRC重配置消息， 该消息携 带了外层 IP/UDP/GTP-U包头压缩方法对应的标识。
该标识用于体现 DeNB具有压缩外层 IP/UDP/GTP-U包头的能力和 DeNB所 支持的具体的压缩方式。
702、 根据接收到的外层 IP/UDP/GTP-U包头压缩方法对应的标识， 确定 DeNB支持的 IP包头压缩方法， 向 RN发送 RRC重配置完成消息， 该消息携带该
DeNB支持的外层 IP/UDP/GTP-U包头压缩方法的标识。
步骤 702中， 若 DeNB不支持该外层 IP/UDP/GTP-U包头压缩方法， 则 RRC 重配置完成消息不携带 DeNB的外层包头压缩方法的标识。
703、可选的，在空口承载建立后，该空口承载可以用于发送 IP数据包， 此时的 IP数据包中包括内层 IP/UDP/GTP-U和外层 IP/UDP/GTP-U包头， 即没 有压缩的状态。
704、 DeNB向 RN发送 PDCP Cont ro l PDU消息， 该消息包括待压缩的外层 IP/UDP/GTP-U包头的内容和头压缩上下文标识， 该待压缩的外层
IP/UDP/GTP-U包头的内容和头压缩上下文标识根据 DeNB所支持的 I P包头压 缩方法确定的， 所述头压缩上下文标识用于标识所述待压缩的外层
IP/UDP/GTP-U包头。
头压缩上下文标识可以是 RN节点的标识， 可以是发送和接收 I P数据包 的 UE的标识，可以是 RN和 DeNB之间承载的标识，可以是 GTP-U隧道的隧道 ID， 可以是 I P数据流的标识。
其中， IP数据流的标识包括源地址、 目的地址、 源端口、 目的端口、 传输协议组成的 IP流五元组。 其中， 压缩 IP流的头压缩上下文标识的五元组由源地址、 目的地址、 源端口、 目的端口、 传输协议组成。
705、 RN向 DeNB返回 ARQ Ack消息。
706、 DeNB使用该 DeNB支持的 IP包头压缩方法， 压缩外层 IP/UDP/GTP-U 包头， 所述压缩后的 IP/UDP/GTP-U数据包携带所述头压缩上下文标识， 即 该数据包的头压缩上下文标识被保留， 外层 IP/UDP/GTP-U包头被压缩。
707、 DeNB向 RN发送压缩后的 IP数据包。
708、 RN根据据收到的所述外层 IP/UDP/GTP-U包头压缩后的 IP数据包 后， 确定所述外层 IP/UDP/GTP-U包头压缩后的外层 IP/UDP/GTP-U数据包中 携带的所述头压缩上下文标识所对应的待压缩的外层 IP/UDP/GTP-U包头， 根据所确定的待压缩的外层 IP/UDP/GTP-U包头将所述压缩后的外层
IP/UDP/GTP-U数据包恢复为压缩前的外层 IP/UDP/GTP-U数据包。
R0HC协议的头压缩上下文通过 IP数据包承载， 并进行传递， 使 RAN层网 络实体将承载 R0HC协议的头压缩上下文的 IP数据包和其他业务的 IP数据包 等同处理， 从而导致用 IP数据包承载 R0HC协议的头压缩上下文传递率低的 问题。 而本发明实施例中， 以外层 IP/UDP/GTP-U包头为例， 通过 RN和 DeNB 之间的接入网链路层信令消息携带待压缩的外层 IP/UDP/GTP-U包头和头压 缩上下文标识， DeNB使用该 DeNB支持的 IP包头压缩方法， 压缩外层
IP/UDP/GTP-U包头， 所述压缩后的 IP/UDP/GTP-U数据包携带所述头压缩上 下文标识， 从而避免 RN或 DeNB将承载头压缩上下文的外层 IP/UDP/GTP-U数 据包和其他业务的外层 IP/UDP/GTP-U数据包等同处理， 保证了 RN和 DeNB压 缩信息的完整性， 提高了头压缩上下文传递的效率。
图 7所示的实施例与图 3所示的实施例 3的头压缩的过程类似， 不同之处 在于是由 DeNB发起的头压缩过程， 而进行头压缩的实体为 DeNB， 类似的， 图 2、 图 4、 图 5、 图 6所示的实施例可以由 DeNB发起的头压缩过程， DeNB进 行头压缩， 在此不在赘述。
图 8为本发明实施例的一种数据传输装置的结构示意图， 包括： 确定模块 801， 用于根据第一因特网协议 IP包头压缩方法确定待压缩的 包头， 所述待压缩的 IP包头用头压缩上下文标识表示；
传输模块 802， 用于向第二设备发送信令， 所述信令携带所述确定模块 确定的所述待压缩的 IP包头和头压缩上下文标识；
处理模块 803， 用于使用所述第一 IP包头压缩方法压缩所述确定模块确 定的所述 IP包头；
所述传输模块 804， 用于向所述第二设备发送所述处理模块进行所述 IP 包头压缩后的 IP数据包， 所述 IP包头压缩后的 IP数据包携带所述头压缩上 下文标识， 以使得所述第二设备收到所述 IP包头压缩后的 IP数据包后， 确 定所述 IP包头压缩后的 IP数据包中携带的所述头压缩上下文标识所对应的 待压缩的 IP包头， 根据所确定的待压缩的 IP包头将所述压缩后的 IP数据包 恢复为压缩前的 IP数据包。
本发明各实施例， 通过使用所述第一 IP包头压缩方法压缩所述 IP包头， 向所述第二设备发送所述 IP包头压缩后的 IP数据包， 所述 IP包头压缩后的 I P数据包携带所述头压缩上下文标识， 以使得所述第二设备收到所述 I P包 头压缩后的 IP数据包后， 确定所述 IP包头压缩后的 IP数据包中携带的所述 头压缩上下文标识所对应的待压缩的 IP包头， 根据所确定的待压缩的 IP包 头将所述压缩后的 IP数据包恢复为压缩前的 IP数据包， 从而避免第二设备 将接收到的承载头压缩上下文 IP数据包、 以及将承载头压缩写上下文的 IP 数据包和其他业务的 IP数据包等同处理， 从而提高了头压缩上下文传递的 效率， 保证了 RN和 DeNB压缩信息的完整性。
进一步， 所述传输模块还用于接收所述第二设备发送的 IP包头压缩方 法对应的标识； 所述确定模块还用于将所述传输模块接收的所述标识对应 的 IP包头压缩方法作为所述第一 IP包头压缩方法。 进一步， 所述传输模块还用于接收所述第二设备所能支持的 IP包头压 缩方法对应的标只；
所述确定模块还用于确定所述传输模块接收的所述标识对应的 IP包头 压缩方法中， 所述第一设备采用的第一 IP包头压缩方法；
进一步， 所述传输模块还用于向所述第二设备发送所述确定模块确定 的第一 IP包头压缩方法对应的标识， 以使得所述第二设备根据所述第一 IP 包头压缩方法对应的标识确定所述待压缩的 IP包头在压缩前的 IP数据包中 的位置， 以及根据所确定的待压缩的 IP包头及所确定的位置将所述压缩后 的 IP数据包恢复为压缩前的 IP数据包。
进一步， 若所述第一设备和所述第二设备之间承载的 PDCP层和无线链 路控制 RLC层处于确认模式， 所述传输模块还用于接收所述第二设备发送 的、 收到所述待压缩 IP包头与头压缩上下文标识的确认消息， 所述确认消 息为自动重传请求确认 ARQ ACK消息。
图 9为本发明实施例的另一种数据传输装置的结构示意图， 包括： 传输模块 901， 用于接收第一设备发送的信令， 所述信令携带待压缩的 因特网协议 IP包头和头压缩上下文标识， 所述待压缩的 IP包头根据第一 IP 包头压缩方法确定， 所述头压缩上下文标识用于标识所述待压缩的 IP包头； 用于接收所述 IP包头压缩后的 IP数据包， 所述数据包为所述第一设备使用 所述第一 IP包头压缩方法压缩， 所述 IP包头压缩后的 IP数据包携带所述头 压缩上下文标只；
确定模块 902， 用于确定所述传输模块接收的所述 IP包头压缩后的 IP数 据包中携带的所述头压缩上下文标识所对应的待压缩的 I P包头；
处理模块 903， 用于根据所述确定模块所确定的待压缩的 IP包头， 将所 述压缩后的 I P数据包恢复为压缩前的 I P数据包。
采用本发明实施例提供的方法， 能够避免第二设备将接收到的承载头 压缩上下文 IP数据包、 以及将承载头压缩写上下文的 IP数据包和其他业务 的 IP数据包等同处理， 从而提高了头压缩上下文传递的效率， 保证了 RN和 DeNB压缩信息的完整性。
进一步， 所述传输模块用于向所述第一设备发送 IP包头压缩方法对应 的标识， 以使得所述第一设备将所述标识对应的 I P包头压缩方法作为所述 第一 IP包头压缩方法。
进一步， 所述传输模块还用于向所述第一设备发送所述第二设备所能 支持的 IP包头压缩方法对应的标识， 以使得所述第一设备确定所述标识对 应的 IP包头压缩方法中所述第一设备采用的第一 IP包头压缩方法；
进一步， 所述传输模块还用于接收所述第一设备发送的所述第一 IP包 头压缩方法对应的标只；
所述确定模块还用于根据所述传输模块接收的所述第一 IP包头压缩方 法对应的标识确定所述待压缩的 IP包头在压缩前的 IP数据包中的位置； 所述处理模块还用于根据所述确定模块确定的待压缩的 IP包头及所确 定的位置将所述压缩后的 IP数据包恢复为压缩前的 IP数据包。
进一步， 若所述第一设备和所述第二设备之间承载的 PDCP层和无线链 路控制 RLC层处于确认模式， 所述传输模块还用于向所述第一设备发送所述 第二设备收到所述待压缩 IP包头与头压缩上下文标识的确认消息， 所述确 认消息为自动重传请求确认 ARQ ACK消息。
为了使描述清楚， 本发明实施例中将 IP包头压缩后的 IP数据包简称 为第二 IP数据包。
值得注意的是， 上述用户设备和基站实施例中， 所包括的各个单元只 是按照功能逻辑进行划分的， 但并不局限于上述的划分， 只要能够实现相 应的功能即可； 另外， 各功能单元的具体名称也只是为了便于相互区分， 并不用于限制本发明的保护范围。
另外， 本领域普通技术人员可以理解实现上述各方法实施例中的全部 或部分步骤是可以通过程序来指令相关的硬件完成， 相应的程序可以存储 于一种计算机可读存储介质中， 上述提到的存储介质可以是只读存储器， 磁盘或光盘等。
以上所述， 仅为本发明较佳的具体实施方式， 但本发明的保护范围并 不局限于此， 任何熟悉本技术领域的技术人员在本发明实施例揭露的技术 范围内， 可轻易想到的变化或替换， 都应涵盖在本发明的保护范围之内。 因此， 本发明的保护范围应该以权利要求的保护范围为准。

Claims

权利要求
1、 一种数据传输方法， 其特征在于， 包括：
第一设备向第二设备发送消息， 所述消息携带待压缩的因特网协议 IP 包头和头压缩上下文标识， 所述待压缩的 IP包头 4艮据第一 IP包头压缩方法 确定， 所述头压缩上下文标识用于标识所述待压缩的 IP包头；
所述第一设备使用所述第一 IP包头压缩方法压缩所述待压缩的 IP包 头， 向所述第二设备发送所述 IP包头压缩后的第二 IP数据包， 所述第二 IP 数据包携带所述头压缩上下文标识， 以使得所述第二设备收到所述第二 IP 数据包后， 根据所述消息中携带的待压缩 IP包头和头压缩上下文标识确定 所述第二 IP数据包中携带的所述头压缩上下文标识所对应的待压缩的 IP包 头， 根据所确定的待压缩的 IP包头将所述第二 IP数据包恢复为压缩前的 IP 数据包。
2、 根据权利要求 1所述的方法， 其特征在于， 所述第一设备向所述第 二设备发送消息之前， 还包括：
所述第一设备接收所述第二设备发送的、 IP包头压缩方法对应的标识; 所述第一设备将所述标识对应的 IP包头压缩方法作为所述第一 IP包头 压缩方法。
3、 根据权利要求 1所述的方法， 其特征在于， 所述第一设备向所述第 二设备发送消息之前， 还包括：
所述第一设备接收所述第二设备所能支持的 I P包头压缩方法对应的标 识；
所述第一设备确定所述标识对应的 I P包头压缩方法中所述第一设备采 用的第一 IP包头压缩方法， 所述第一设备向所述第二设备发送所述第一 IP 包头压缩方法对应的标识， 以使得所述第二设备收到所述第二 I P数据包后， 根据所述第一 IP包头压缩方法对应的标识确定所述待压缩的 IP包头在压缩 前的 IP数据包中的位置， 以及根据所确定的待压缩的 IP包头及所确定的位 置将所述第二 I P数据包恢复为压缩前的 I P数据包。
4、 根据权利要求 1所述的方法， 其特征在于，
所述消息包括接入网链路层信令；
所述接入网链路层信令包括 RRC头压缩初始化信令或者分组数据汇聚 协议 PDCP层的分组数据单元 PDU信令。
5、 根据权利求 1所述的方法， 其特征在于， 所述第一设备使用所述第 一 IP包头压缩方法压缩所述 IP包头之前， 所述方法还包括：
所述第一设备收到所述第二设备发送的确认消息， 所述确认消息为所 述第二设备收到所述消息中携带的所述待压缩 IP包头与头压缩上下文标识 后发送。
6、 根据权利要求 5所述的方法， 其特征在于， 若所述第一设备和所述 第二设备之间承载的 PDCP层和无线链路控制 RLC层处于确认模式， 所述确认 消息包括自动重传请求确认 ARQ ACK消息。
7、 根据权利要求 6所述的方法， 其特征在于， 所述方法还包括： 将相同的待压缩的 IP包头和头压缩上下文标识通过至少两个分组数据 汇聚协议数据单元 PDCP PDU信令发送。
8、 根据权利要求 1至 7任一权利要求所述的方法， 其特征在于， 包括： 所述第一设备为中继节点 RN， 所述第二设备为演进的基站 DeNB; 或者 所述第一设备为 DeNB， 所述第二设备为 RN。
9、 一种数据传输方法， 其特征在于， 包括：
第二设备接收第一设备发送的消息， 所述消息携带待压缩的因特网协 议 I P包头和头压缩上下文标识， 所述待压缩的 I P包头根据第一 I P包头压缩 方法确定， 所述头压缩上下文标识用于标识所述待压缩的 IP包头；
所述第二设备接收所述 IP包头压缩后的第二 IP数据包， 所述第二 IP数 据包为所述第一设备使用所述第一 IP包头压缩方法压缩， 所述第二 IP数据 包携带所述头压缩上下文标识；
所述第二设备根据所述消息中携带的待压缩 IP包头和头压缩上下文标 识确定所述第二 IP数据包中携带的所述头压缩上下文标识所对应的待压缩 的 IP包头， 根据所确定的待压缩的 IP包头将所述第二 IP数据包恢复为压缩 前的 IP数据包。
10、 根据权利要求 9所述的方法， 其特征在于， 所述第二设备接收所述 第一设备发送的消息之前， 还包括：
所述第二设备向所述第一设备发送 I P包头压缩方法对应的标识， 以使 得所述第一设备将所述标识对应的 IP包头压缩方法作为所述第一 IP包头压 缩方法。
11、 根据权利要求 10所述的方法， 其特征在于， 所述第二设备接收所 述第一设备发送的消息之前， 还包括：
所述第二设备向所述第一设备发送所述第二设备所能支持的 I P包头压 缩方法对应的标识， 以使得所述第一设备确定所述标识对应的 I P包头压缩 方法中所述第一设备采用的第一 IP包头压缩方法；
所述第二设备接收所述第一设备发送的所述第一 I P包头压缩方法对应 的标识；
所述第二设备根据所述第一 I P包头压缩方法对应的标识确定所述待压 缩的 IP包头在压缩前的 IP数据包中的位置， 以及根据所确定的待压缩的 IP 包头及所确定的位置将所述压缩后的 IP数据包恢复为压缩前的 IP数据包。
12、 根据权利要求 9至 11任一权利要求所述的方法， 其特征在于， 所述消息包括接入网链路层信令；
所述接入网链路层信令包括 RRC头压缩初始化信令或者分组数据汇聚 协议 PDCP层的分组数据单元 PDU信令。
13、 根据权利要求 9至 11任一权利要求所述的方法， 其特征在于， 所述 第二设备接收所述第二 IP数据包之前， 还包括： 所述第二设备向所述第一设备发送所述第二设备收到所述待压缩 IP包 头与头压缩上下文标识的确认消息。
14、 根据权利要求 13所述的方法， 其特征在于， 若所述第一设备和所 述第二设备之间承载的 PDCP层和无线链路控制 RLC层处于确认模式， 所述确 认消息包括自动重传请求确认 ARQ ACK消息。
15、 一种数据传输装置， 其特征在于， 包括：
确定模块， 用于根据第一因特网协议 IP包头压缩方法确定待压缩的包 头， 所述待压缩的 IP包头用头压缩上下文标识表示；
传输模块， 用于向第二设备发送消息， 所述消息携带所述确定模块确 定的所述待压缩的 IP包头和头压缩上下文标识；
处理模块， 用于使用所述第一 IP包头压缩方法压缩所述确定模块确定 的待压缩的所述 IP包头；
所述传输模块， 用于向所述第二设备发送所述处理模块进行所述 IP包 头压缩后的第二 IP数据包， 所述第二 IP数据包携带所述头压缩上下文标识， 以使得所述第二设备收到所述第二 I P数据包后， 根据所述消息中携带的待 压缩 IP包头和头压缩上下文标识确定所述第二 IP数据包中携带的所述头压 缩上下文标识所对应的待压缩的 IP包头， 根据所确定的待压缩的 IP包头将 所述第二 I P数据包恢复为压缩前的 I p数据包。
16、 根据权利要求 15所述的装置， 其特征在于，
所述传输模块还用于接收所述第二设备发送的、 IP包头压缩方法对应 的标识；
所述确定模块还用于将所述传输模块接收的所述标识对应的 IP包头压 缩方法作为所述第一 IP包头压缩方法。
17、 根据权利要求 15所述的装置， 其特征在于，
所述传输模块还用于接收所述第二设备所能支持的 I P包头压缩方法对 应的标识； 所述确定模块还用于确定所述传输模块接收的所述标识对应的 IP包头 压缩方法中， 所述第一设备采用的第一 IP包头压缩方法；
所述传输模块还用于向所述第二设备发送所述确定模块确定的第一 IP 包头压缩方法对应的标识， 以使得所述第二设备收到所述第二 I P数据包后， 根据所述第一 IP包头压缩方法对应的标识确定所述待压缩的 IP包头在压缩 前的 IP数据包中的位置， 以及根据所确定的待压缩的 IP包头及所确定的位 置将所述第二 I P数据包恢复为压缩前的 I P数据包。
18、 根据权利要求 15所述的方法， 其特征在于，
若所述第一设备和所述第二设备之间承载的 PDCP层和无线链路控制 RLC层处于确认模式， 所述传输模块还用于接收所述第二设备发送的、 收到 所述待压缩 IP包头与头压缩上下文标识的确认消息， 所述确认消息为自动 重传请求确认 ARQ ACK消息。
19、 一种数据传输装置， 其特征在于， 包括：
传输模块， 用于接收第一设备发送的消息， 所述消息携带待压缩的因 特网协议 IP包头和头压缩上下文标识， 所述待压缩的 IP包头根据第一 IP包 头压缩方法确定， 所述头压缩上下文标识用于标识所述待压缩的 IP包头； 用于接收所述 IP包头压缩后的第二 IP数据包， 所述第二 IP数据包为所述第 一设备使用所述第一 IP包头压缩方法压缩， 所述第二 IP数据包携带所述头 压缩上下文标只；
确定模块， 用于根据所述消息中携带的待压缩 IP包头和头压缩上下文 标识确定所述传输模块接收的所述第二 I P数据包中携带的所述头压缩上下 文标识所对应的待压缩的 IP包头；
处理模块， 用于根据所述确定模块所确定的待压缩的 IP包头， 将所述 压缩后的 IP数据包恢复为压缩前的 IP数据包。
20、 根据权利要求 19所述的装置， 其特征在于，
所述传输模块用于向所述第一设备发送 I P包头压缩方法对应的标识， 以使得所述第一设备将所述标识对应的 I P包头压缩方法作为所述第一 IP包 头压缩方法。
21、 根据权利要求 20所述的方法， 其特征在于，
所述传输模块还用于向所述第一设备发送所述第二设备所能支持的 IP 包头压缩方法对应的标识， 以使得所述第一设备确定所述标识对应的 I P包 头压缩方法中所述第一设备采用的第一 IP包头压缩方法；
所述传输模块还用于接收所述第一设备发送的所述第一 IP包头压缩方 法对应的标识；
所述确定模块还用于根据所述传输模块接收的所述第一 IP包头压缩方 法对应的标识确定所述待压缩的 IP包头在压缩前的 IP数据包中的位置； 所述处理模块还用于根据所述确定模块确定的待压缩的 IP包头及所确 定的位置将所述压缩后的 IP数据包恢复为压缩前的 IP数据包。
22、 根据权利要求 19所述的装置， 其特征在于，
若所述第一设备和所述第二设备之间承载的 PDCP 层和无线链路控制 RLC层处于确认模式，所述传输模块还用于向所述第一设备发送所述第二设 备收到所述待压缩 IP包头与头压缩上下文标识的确认消息， 所述确认消息 为自动重传请求确认 ARQ ACK消息。
PCT/CN2011/074286 2010-09-20 2011-05-19 一种压缩方法与装置 WO2011137789A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010287387.5 2010-09-20
CN201010287387.5A CN102413506B (zh) 2010-09-20 2010-09-20 一种压缩方法与装置

Publications (1)

Publication Number Publication Date
WO2011137789A1 true WO2011137789A1 (zh) 2011-11-10

Family

ID=44903600

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/074286 WO2011137789A1 (zh) 2010-09-20 2011-05-19 一种压缩方法与装置

Country Status (2)

Country Link
CN (1) CN102413506B (zh)
WO (1) WO2011137789A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117062257A (zh) * 2023-10-11 2023-11-14 腾讯科技（深圳）有限公司 基于多通道的数据传输方法、终端设备以及目标网关

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103812846A (zh) * 2012-11-14 2014-05-21 重庆重邮信科通信技术有限公司 一种头压缩方法及系统
WO2017041223A1 (zh) * 2015-09-08 2017-03-16 华为技术有限公司 一种报文的处理方法和基站
WO2017147754A1 (zh) * 2016-02-29 2017-09-08 华为技术有限公司 数据包的压缩方法和装置
CN108632901B (zh) * 2017-03-24 2019-12-24 维沃移动通信有限公司 一种数据传输方法及终端
WO2019214625A1 (zh) * 2018-05-11 2019-11-14 电信科学技术研究院有限公司 Ue能力信息的上报、获取和处理方法及对应装置
CN110475243B (zh) * 2018-05-11 2020-10-30 电信科学技术研究院有限公司 Ue能力信息的上报、获取和处理方法及对应装置
CN115696312A (zh) * 2019-08-14 2023-02-03 华为技术有限公司 一种ue上报udc信息方法及设备
CN114303355B (zh) * 2019-11-05 2024-03-29 Oppo广东移动通信有限公司 一种指示解压缩对象的方法及装置、通信设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1866908A (zh) * 2005-05-18 2006-11-22 中兴通讯股份有限公司 一种在无分片特定环境中压缩ip－udp报文头的方法
CN101212404A (zh) * 2006-12-27 2008-07-02 大唐移动通信设备有限公司 鲁棒头压缩分组数据传输的方法及系统
CN101350812A (zh) * 2008-08-22 2009-01-21 上海华为技术有限公司 一种数据的传输方法、通信设备及通信系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100396643B1 (ko) * 1998-09-07 2003-10-17 엘지전자 주식회사 무선패킷데이터단말
CN100589441C (zh) * 2006-10-13 2010-02-10 中兴通讯股份有限公司 一种应用于端到端链路传输中ip报头压缩的方法
CN101197824A (zh) * 2006-12-08 2008-06-11 华为技术有限公司 一种确定压缩算法的方法及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1866908A (zh) * 2005-05-18 2006-11-22 中兴通讯股份有限公司 一种在无分片特定环境中压缩ip－udp报文头的方法
CN101212404A (zh) * 2006-12-27 2008-07-02 大唐移动通信设备有限公司 鲁棒头压缩分组数据传输的方法及系统
CN101350812A (zh) * 2008-08-22 2009-01-21 上海华为技术有限公司 一种数据的传输方法、通信设备及通信系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117062257A (zh) * 2023-10-11 2023-11-14 腾讯科技（深圳）有限公司 基于多通道的数据传输方法、终端设备以及目标网关
CN117062257B (zh) * 2023-10-11 2024-02-09 腾讯科技（深圳）有限公司 基于多通道的数据传输方法、终端设备以及目标网关

Also Published As

Publication number Publication date
CN102413506B (zh) 2015-04-15
CN102413506A (zh) 2012-04-11

Similar Documents

Publication Publication Date Title
US11490446B2 (en) Method and apparatus for reconfiguring a bearer
WO2011137789A1 (zh) 一种压缩方法与装置
US11805443B2 (en) Method and apparatus for data processing in wireless communication system
US9736723B2 (en) Link layer assisted robust header compression context update management
JP3776406B2 (ja) ワイヤレスコミュニケーションシステムのデータ伝送確認方法
KR101387537B1 (ko) 성공적으로 수신했으나 헤더 압축 복원에 실패한 패킷의 처리 방법
US8553566B2 (en) Method of delivering a PDCP data unit to an upper layer
US6301479B1 (en) Technique for providing a secure link in a mobile communication system
EP2168270B1 (en) A method for handling correctly received but header compression failed packets
TW200917870A (en) Layer 2 tunneling of data during handover in a wireless communication system
US20090103445A1 (en) Method and apparatus for enhancing various pdcp and layer 2 operations
KR102300300B1 (ko) 헤더 압축을 이용한 패킷 통신 방법 및 장치
US9923695B2 (en) Call processing method and apparatus for use in LTE system
CN102318282B (zh) 一种压缩数据包的传输方法及装置
WO2013001838A1 (ja) 受信装置、送信装置及びフィードバック方法
CN115022922A (zh) 用于lte系统中的呼叫处理方法和装置
US20080130684A1 (en) Method and apparatus for performing reordering in a wireless communications system
GB2462699A (en) Delivering PDCP SDUs to an upper layer within a receiving side entity of an E-UMTS
GB2628863A (en) Methods for controlling a PDCP transmitter and receiver
GB2628894A (en) Methods for controlling a PDCP transmitter and receiver
WO2024209014A1 (en) Methods for controlling a pdcp transmitter and receiver
KR20200076574A (ko) 차세대 이동 통신 시스템에서 pdcp 계층 장치 기반 보안키 확인 방법 및 장치

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: 11777208

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: 11777208

Country of ref document: EP

Kind code of ref document: A1