WO2011047621A1 - 基于重传机制的对头压缩数据包进行传输的方法和装置 - Google Patents

基于重传机制的对头压缩数据包进行传输的方法和装置 Download PDF

Info

Publication number
WO2011047621A1
WO2011047621A1 PCT/CN2010/077911 CN2010077911W WO2011047621A1 WO 2011047621 A1 WO2011047621 A1 WO 2011047621A1 CN 2010077911 W CN2010077911 W CN 2010077911W WO 2011047621 A1 WO2011047621 A1 WO 2011047621A1
Authority
WO
WIPO (PCT)
Prior art keywords
header
data packet
information
header compression
compressed
Prior art date
Application number
PCT/CN2010/077911
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 华为技术有限公司
Priority to EP10824462.5A priority Critical patent/EP2493104B1/en
Publication of WO2011047621A1 publication Critical patent/WO2011047621A1/zh
Priority to US13/436,280 priority patent/US8392616B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0006—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format

Definitions

  • the present invention claims to be submitted to the Chinese Patent Office on October 23, 2009, and the application number is 200910236485. 3.
  • the invention name is "transfer based on the retransmission mechanism.”
  • the priority of the Chinese Patent Application the entire disclosure of which is incorporated herein by reference.
  • the present invention relates to the field of communications technologies, and in particular, to a method and apparatus for transmitting a header compressed data packet based on a retransmission mechanism.
  • the header compression mechanism can solve the above problems while ensuring the inherent flexibility of the IP protocol.
  • the header compression mechanism may include: ROHC (Robust Header Compression), CRTP (Real-time Transport Protocol Header Compression) mechanism, and ERTPT (Extended RTP Header Compression). Head compression) mechanism, etc.
  • R0HC is a stream-based header compression scheme.
  • the R0HC mechanism takes a reference packet in a certain stream, and only transmits information about the change of the reference packet in the header field for other packets to achieve the purpose of compression, thereby saving the packet header overhead and utilizing the bandwidth more effectively.
  • a R0HC channel needs to be established, and the R0HC channel is a logical channel.
  • the entry is a compressor
  • the exit is a decompressor
  • the compressor and the decompressor are in one-to-one correspondence.
  • the compressor performs header compression on the original data and sends it to the decompressor through the logical channel.
  • the R0HC channel is a unidirectional logical channel.
  • the decompressor must be able to provide feedback information to the compressor, so the ROHC feedback channel is the logical channel carrying the feedback information, the entry is the decompressor, and the exit is the compressor.
  • the ROHC header compression mechanism can be simply described as the interaction between two state machines (a compression state machine and a decompression state machine). Each of the two state machines has three different states. Both state machines are gradually transitioned from a lowest compression state to a higher state.
  • the state transition mode of the compressor is shown in Figure 1
  • the state transition mode of the decompressor is shown in Figure 2.
  • the R0HC compressor contains three states: IR (Initial and Refresh).
  • the initial state is the IR state.
  • the R0HC compression end sends IR or IR-DYM data packets, which contain static information in the packet header (source IP address). , destination IP address, etc.) and some dynamic information (SN serial number, Timestamp timestamp, etc.).
  • the IR package contains both static and dynamic information, while the IR-DYM package can contain only dynamic information.
  • the R0HC decompressor contains three states: NC (No Context, SC C Satic Context, Static Context), FC (Ful l Context, All Context).
  • NC No Context, SC C Satic Context, Static Context
  • FC Full l Context, All Context
  • the NC is the initial state of the decompressing end. At this time, the decompressing end does not receive the data packet, and does not have any information needed for decompression
  • SC is that the decompressing end obtains all the static decompressed information and partial dynamic decompressed information; That is, the decompressor has obtained all the static and dynamic decompression information.
  • R0HC's Context information is divided into two different types: static Context information and dynamic Context information, where static Context information is rarely changed, so generally the compressed end does not need to be transmitted as long as the receiving end receives it correctly;
  • the dynamic Context information is changed.
  • the dynamic Context information in the existing IP packet header is mainly SN, Timestamp, and IP_id.
  • ARQ automatic repeat request
  • ARQ is a technique for recovering an erroneous message by the receiver requesting the sender to retransmit the erroneous packet message, and is a method for processing the error caused by the channel in the communication.
  • ARQ includes three methods: stop-and-wait, go-back-n ARQ, selective repeat ARQ, and hybrid ARQ (HARQ). They differ in the way they handle different error packets.
  • the HARQ system introduces FEC (Forward Error Correction) in the ARQ system.
  • FEC Forward Error Correction
  • the FEC can be used to correct data errors during transmission. That is, if the error is within the error correction range of the FEC, the FEC corrects Wrong, if the error correction range is exceeded, the receiver instructs the sender to retransmit some or all of the information of the error message, and then the receiver combines the message information received again with the message information received last time. To recover message information.
  • the R0HC mechanism can save wireless network resources and improve service quality.
  • the existing R0HC mechanism treats the error headers directly for discarding without further processing.
  • the status is rolled back and updated.
  • the context information is resynchronized and decompressed.
  • the automatic retransmission mechanism can improve the accuracy and reliability of message transmission.
  • Embodiments of the present invention provide a method and apparatus for transmitting a header compressed data packet based on a retransmission mechanism, so that a header compression end uses a feedback information of a retransmission mechanism to determine a state of the header compression end, according to the The state of the header compression side performs header compression on the data packet.
  • a method for transmitting a compressed packet based on a retransmission mechanism including:
  • the header compression end of the sending device obtains feedback information of the header compressed data packet during transmission
  • the header compression end determines the state of the header compression end according to the feedback information, and performs header compression on the data packet according to the state of the header compression end and sends the data packet to the decompression end of the receiving device.
  • a device for transmitting a compressed data packet based on a retransmission mechanism includes:
  • a feedback information obtaining module configured to obtain feedback information of the header compressed data packet during the transmission process
  • the header compression state processing module is configured to determine a state of the header compression end according to the feedback information, perform header compression on the data packet according to the state of the header compression end, and send the data packet to a decompression end of the receiving device.
  • the embodiment of the present invention combines the header compression mechanism and the retransmission mechanism, so that the header compression end obtains the feedback information of the retransmission mechanism, so that the header compression end can use the header compression end.
  • the feedback information determines the state of the compressed end of the head, and performs a corresponding state transition if necessary, according to the header compression end
  • the state of the packet is header compressed to improve the transmission efficiency of the packet.
  • FIG. 1 Schematic diagram of the state transition mode of the compressor in the R0HC head compression mechanism
  • FIG. 1 Schematic diagram of the state transition mode of the decompressor in the R0HC head compression mechanism
  • FIG. 3 is a flowchart of processing a R0HC compression method for a data packet based on HARQ according to Embodiment 1 of the present invention
  • FIG. 4 is a schematic diagram of a transmission process of a data packet transmitted from a high layer to an air interface in an IEEE 16m system according to Embodiment 1 of the present invention
  • FIG. 5 is a structural diagram of a specific implementation of an apparatus for performing header compression on a data packet based on an automatic retransmission technology according to Embodiment 2 of the present invention.
  • the header compression end of the sending device obtains feedback information of the header compressed data packet in the transmission process, and the header compression end determines the state of the header compression end according to the feedback information, according to the header compression end
  • the state header compresses the packet and sends it to the decompressing end of the receiving device.
  • Embodiment 1 utilizes the feedback information in the HARQ mechanism, and the HARQ transmitting end acquires the transmission state information of the data packet at the HARQ receiving end, and the HARQ transmitting end feeds back the transmission state information to the R0HC header compression end, and the R0HC header compression end. Based on these transmission status information, the decompression state of the ROHC header decompressor can be predicted, thereby determining the state of the R0HC head compression end, and changing the state machine of the ROH head compression end as necessary.
  • a processing flow of a method for transmitting a header compressed data packet based on HARQ provided by this embodiment is shown in the figure As shown in FIG.
  • Step 31 A transmission status information table is saved and managed for each data packet at the R0HC header compression end.
  • the R0HC header compression end in order to enable the R0HC header compression end to know the actual transmission status of the data packet in the network, the R0HC header compression end needs to save a transmission status information table for each data packet subjected to header compression, and the transmission status is
  • the transmission status information saved in the information table includes: at least one of a header compression sequence number, a packet header information, a transmission success or failure information of the data packet, packet encapsulation information, and HARQ process information.
  • the foregoing packet header information may include: a header compression context information of the R0HC, including static Context information and/or dynamic Context information. This embodiment will be described below with an IEEE 16m system. In the IEEE 16m system, the transmission process of data packets from the upper layer to the air interface is shown in Figure 4, CS
  • the sublayer receives packets from the upper layer network, distributes the packets to different ROHC Contexts according to the characteristics of the packets, and performs header compression on the packets. If the packet includes an RTP (Transport Protocol Header Compression) header, the RTP header includes SN information, and the SN information is used as a sequence number compressed by the packet header; if the packet is The RTP header is not included, and the system increments from 0 to generate a virtual SN number for the packet as the serial number of the packet header compression.
  • RTP Transport Protocol Header Compression
  • the data packet After the data packet is compressed by the header, it is mapped to a different MAC (Medium Access Control) connection, and the data packet is packetized into different MAC data packets according to actual system resource conditions.
  • MAC Medium Access Control
  • a header-compressed packet can be split into multiple different MAC packets for transmission.
  • Each MAC packet contains a part of the information of the header compressed data packet, for example, some data packets only contain data packet header information, and some only contain data packet payload information. There is no serial number information in the MAC packet, but the system can generate a virtual MAC sequence number as the identifier of the MAC packet on each MAC connection.
  • the system can use the SN of the first ARQ block (block) in the MAC packet as the identifier of the MAC packet.
  • the ARQ block is also a virtual data block that generates an ARQ sequence number by sorting and sorting all MAC packets on the MAC connection according to a fixed size.
  • the MAC packet is mapped to a different HARQ process for transmission.
  • the MAC packets transmitted on the same HARQ process form a HARQ packet. It is identified by the lbit AISN whether the HARQ packet is a retransmitted data packet.
  • the foregoing packet encapsulation information includes: CID information of the MAC, ARQ block The information, the virtual MAC SN information, whether the data packet is packaged and the like, and the HARQ process information includes: HARQ process information, HARQ data packet retransmission identifier and the like.
  • the R0HC header compression end determines the state of the R0HC header compression end according to the stored transmission status information table and feedback information of the data packet, and determines whether state transition or other operations are required. In this embodiment, any processing of the data packet by the lower layer is reported to the R0HC header compression end.
  • the packet encapsulation information of the data packet needs to be reported to R0HC head compression end.
  • the HARQ receiving end needs to feed back the transmission status of the data packet to the HARQ transmitting end, and the HARQ transmitting end reports the transmission status of the received data packet as feedback information to the R0HC.
  • Head compression end finds the corresponding data packet according to the transmission status information table of the data packet stored by itself.
  • the HARQ receiver feeds back the NACK (Unacknowledged) to the HARQ sender; if the packet is lost during transmission, the HARQ receiver does not receive the packet.
  • the HARQ sender does not receive any response message. If the HARQ receiving end receives the same HARQ packet as the AISN of the previous packet, it knows that the HARQ packet is a retransmission packet. For a retransmission packet, the HARQ receiving end also feeds back the ACK and NACK or no response to the HARQ transmitting end. information.
  • a HARQ data packet may contain a plurality of different header compressed data packets
  • the ACK and NACK or no response information fed back by the HARQ receiving end indicates whether the HARQ data packet is correctly received, and the R0HC header compression end is according to the ACK.
  • HARQ in NACK or no response information and transmission status information table The header encapsulated by the data packet compresses the packet information, obtains the header compressed packet with the correct and/or failed transmission, and obtains the header compressed packet correctly received by the HARQ receiver according to the correctly compressed and/or failed header compressed packet.
  • the order and decompression headers decompress the number of failed packets.
  • the header compression end Determining, by the header compression end, whether the decompression end can be based on the order in which the header compression packet of the transmission failure and/or the header compression packet correctly received by the decompression terminal, and the transmission status information of the saved header compression packet Decompressing the subsequent header compressed data packet, if yes, the header compression end remains unchanged from the existing compressed state or transitions from the non-fully compressed state to the fully compressed state; otherwise, the header compressed end migrates the state from the fully compressed state It is not fully compressed.
  • the incompletely compressed state includes: an initial state or a first level state
  • the fully compressed state includes: a second level state.
  • the HARQ sender does not necessarily need to transmit ACK and NAK or no-acknowledgement information to the R0HC compression end, and may be determined by the HARQ transmitting end to transmit the correct and/or failed data packet according to the foregoing ACK and NACK or no-answer information. And obtaining, according to the correctly transmitted and/or failed data packet, the order of the data packets correctly received by the HARQ receiving end and the number of the data packets failed by the decompressing end decompression end. The HARQ sender then reports the obtained correctly and/or failed data packet and/or the sequence of the data packet correctly received by the HARQ receiving end, and the number of data packets failed to be decompressed by the decompression header to the ROH compression end.
  • HARQ is a stop-and-wait protocol
  • a packet is not transmitted until it is correctly transmitted or discarded. Therefore, unless the following packet is transmitted to the maximum number of times, it is impossible to out of order.
  • the HARQ packet transmission exceeds the maximum number of times, the HARQ sender fails to feed back the packet transmission failure to the ROH head.
  • the R0HC header compression end fails to obtain the data packet transmission, according to the data packet that fails to be transmitted, the data packet and the transmission status information table corresponding to a certain number of subsequent data packets of the data packet are queried.
  • the ratio of the number of packets that fail to be compressed to the total number of header compressed packets received by the decompressor is obtained by a preset threshold, that is, the requirement of state transition of k of n is reached, and then the subsequent packets are determined. Whether the IR or IR-Dyn data packet is included, if yes, it is judged that the R0HC decompressing end can recover the subsequent data packet, and the R0HC header compression end does not perform any processing; otherwise, it is judged that the R0HC decompressing end cannot recover the subsequent data packet.
  • the state of the R0HC header compression end is transferred to the IR or F0 state, and the IR or IR-Dyn data packet is sent to update the header compression information of the R0HC decompression end. If the R0HC header compression end determines that the packet is lost due to packet loss, the number of MACs that have not yet been sent in the MAC cache is not yet sent. According to the packet even if it is sent to the decompressing end, the decompressing end cannot correctly decompress the MAC data packet. There are two ways to deal with the packet: First, the R0HC header compression end notifies the MAC and the HARQ sender sends the direct discard to the above cache. The data packet has not been sent, and the air interface resource is reduced.
  • the R0HC header compression end notifies the MAC sublayer by means of inter-layer transmission.
  • the header compressed packet that has not been sent in the MAC buffer and has been MAC-encapsulated, it is in the form of a MAC sub-header.
  • adding necessary information and rules that can assist in decompression headers information includes: header compression information such as SN and/or TS and/or IP-ID, the above rules include: How to add related information to the corresponding MAC header
  • These information rules and the inter-layer primitives are sent from the R0HC to the MAC.
  • the MAC layer processes the MAC packets that have not been sent in the MAC buffer according to the received information and rules.
  • the header and payload of the R0HC packet may be transmitted in different MAC/RLC packets. If the R0HC header compression end cannot know which MAC/RLC packet the packet header and the payload are respectively in, if one MAC/RLC packet in the MAC/RLC packet fails to be transmitted, other MAC/RLC packets may directly throw away. If the R0HC header compression end can know which MAC/RLC packet the packet header and the payload are respectively in, if the MAC/RLC packet transmission of the packet header fails, the R0HC header compression end requests the lower layer to discard the MAC/RLC packets in the MAC address.
  • MAC/RLC data packets if only the MAC data packet transmission of the payload fails, the MAC/RLC data packet where the packet header is located continues to be transmitted, and the receiving end is notified to transmit the header information to the R0HC decompression end, and the header compression end is received.
  • the header information is used for decompressing and updating the header information, and then the MAC/RLC packet of the packet header is discarded.
  • the processing manner is similar to that described above, and the R0HC header compression end is for each affected one according to the received packet loss information and the transmission status information table of the data packet saved by itself.
  • Context determine whether it needs state transfer or update the header compression information in the cached MAC packet.
  • Case 2 If the ROHC data packet of a context ID is carried in a different HARQ process, the data packets transmitted on different HARQ processes will have different data error probability.
  • HARQ process 1 carries the data packet of sequence number 1-3
  • HARQ process 2 carries the data packet of sequence number 4_6, and HARQ process 1 and HARQ process 2 start transmission simultaneously; however, during transmission, the serial number After the 4-6 data packet is retransmitted once, it is correctly received by the receiving end; and the data packet of sequence number 1-3 is retransmitted three times, and then received by the receiving end correctly, then the data packet of sequence number 4-6 will be prior to The packets of sequence numbers 1-3 are transmitted to the R0HC decompressor. The out-of-order arrival of such packets may cause an error in packet decompression if the size of the buffer window is exceeded.
  • the first data packet on each automatic retransmission process is An initial header compressed packet containing header compression context information.
  • the HARQ sender class performs HARQ process partitioning according to the location of the IR or IR-DYN packet, and generates an IR or IR-DY packet or specifically generates an IR or IR-DYN packet, which is placed at the first position of the HARQ packet on each HARQ process.
  • a HARQ packet on one HARQ process is lost, it does not affect the decompression of the HARQ packet on other HARQ processes.
  • the HARQ receiving end also feeds back the ACK and NACK information to the HARQ transmitting end, and the HARQ transmitting end judges and maintains the SDU (Service Data Unit) of the data packet received by the receiving end according to the received ACK/NACK. Unit) Status and sequence, send the SDU reception status and sequence of the packet to the R0HC header compression end.
  • the R0HC header compression end obtains the disorder of the transmission of the data packet according to the SDU reception status and sequence of the above data packet and the normal transmission order of the data packet.
  • the decompressing end can decompress the out-of-order data packet, and if not, the state of the R0HC header compression end is shifted to In the IR or F0 state, the IR or IR_Dyn packet is sent to update the header compression information of the R0HC decompression end; otherwise, the R0HC header compression end does not perform state transition.
  • the data packet RTP SN number is 1, 2, 3 is transmitted in process 1, the RTP SN number is 4, 5, 6 is transmitted in process 2, and the RTP SN number is 7, 8, 9 is transmitted in process 3.
  • the compression end knows the order in which the data packet arrives at the decompression end according to the feedback in the retransmission technique, knowing that the decompression end cannot correctly decompress the data packet with the sequence number 7, 8, 9 and the wrong data packet reaches k of The state transition request of n, and the packet that has been transmitted after header compression has no IR/IR-Dyn packet, then the header compression side performs state transition, and transitions from the SO state to the F0 or IR state.
  • Step 33 The HARQ receiving end correctly sorts the data packets according to the received scheduling indication and the sequence information of the ACID. When packet scheduling is performed on the HARQ sender, packets can be placed sequentially in the order of the packets.
  • the ACID is incremented on the HARQ process for transmission.
  • the HARQ receiving end can know the order of the data packets from different HARQ processes according to the scheduling indication and the sequence information of the ACID, thereby correctly sorting the data packets.
  • the HARQ receiver should try to ensure that the packets belonging to a header compression context are sent to the R0HC header compression terminal in sequence, reducing the decompression failure caused by out-of-order. If the R0HC header compression end determines that the packet is not yet transmitted according to the feedback information of the HARQ, the data packet that has not yet been sent in the buffer is sent to the decompressing end, and the decompressing end cannot correctly decompress the MAC data packet.
  • the two processing modes are as follows: First, the MAC and HARQ senders are directly notified to discard the above-mentioned data packets that have not been sent in the cache, and the air interface resources are reduced. Second, the MAC sublayer is notified by means of inter-layer transmission, and the MAC sublayer is not transmitted for the MAC cache.
  • the MAC encapsulated header compresses the data packet, adds the necessary information and rules to assist the decompression of the header through the form of the MAC subheader, and processes the MAC packet that has not been sent in the MAC buffer according to the received information and rules.
  • the CRC cycl ic redundancy check code
  • the CRC in the data packet after the header compression may be optionally selected. ) omitted to reduce air interface resource consumption. Or change the bit occupied by the original CRC check bit to add some information to assist the decompression, such as increasing the header compression information such as SN, IP-ID, TS, etc., which is helpful for the success rate of header decoding.
  • This method of omitting the CRC check is optional. If the header compression is performed in this way, it is necessary to perform correlation capability negotiation when the header compression context is initially established, and determine the header of the data packet by omitting the CRC check. compression.
  • the processing flow of the method for transmitting the HARQ-based header compressed data packet provided in the foregoing Embodiment 1 can also be applied to the LTE system.
  • the transmission status information saved in the transmission status information table includes: at least one of a header compression sequence number, a data packet header information, a transmission success or failure information of the data packet, and a HARQ process information.
  • the foregoing data packet header information may include: R0HC Context information, including static Context information and dynamic Context information. Since the LTE system is different from the 16m system, the transmission information also changes. The main difference is that the HARQ process information includes: RLC (Radio Link Control), serial number, logical process id, and HARQ. Process number, etc.
  • the RMC's UM (Unacknowledged Mode) and AM (Acknowledged Mode) modes have the data packets sorted according to the sequence number in the RLC packet header.
  • the system has an automatic sorting function, and does not need to use scheduling information and retransmission information to sort.
  • the TM mode which has no sorting function, needs to sort the packets by scheduling information and retransmitting information as in the IEEE 16m system.
  • the HARQ in the foregoing Embodiment 1 can also be replaced by ARQ.
  • the specific processing procedure is that the ARQ receiving end feeds back the transmission status of the data packet to the R0HC header compression end.
  • the R0HC header compression end determines whether a state transition or other operation is required according to the transmission state information table of the stored data packet and the transmission condition of the data packet.
  • the packet transmission state information stored by the R0HC header compression terminal is the same as the HARQ-related operation in the first embodiment.
  • the transmission condition of the data packet that is, the feedback information that the ARQ transmitting end receives the data sent by the ARQ receiving end correctly, which specifically includes the response information correctly received by the data packet, the response information received by the data packet error, and the data packet loss. No response message caused.
  • the specific decision process of the state transition or other operations is the same as the HARQ related operation.
  • Embodiment 2 The embodiment of the present invention further provides a device for transmitting a header compressed data packet based on a retransmission technology, where the device is disposed at a header compression end of the sending device, and the specific implementation structure is as shown in FIG. 5, which may specifically include :
  • the feedback information obtaining module 51 is configured to obtain feedback information of the header compressed data packet in the transmission process
  • the header compression state processing module 52 is configured to determine a state of the header compression end according to the feedback information, according to the state of the header compression end
  • the packet is header compressed and sent to the decompressing end of the receiving device.
  • the device may further include:
  • the transmission status information management module 53 is configured to save and manage transmission status information of the data packet, where the transmission status information of the data packet includes: a header compression sequence number, a data packet header information, a transmission success or failure information, a package information, and a retransmission At least one of the process information.
  • the feedback information obtaining module 51 includes:
  • the information receiving module 511 is configured to receive the feedback information reported by the sending end of the sending device based on the retransmission mechanism, where the feedback information is sent by the receiving end of the receiving device based on the retransmission mechanism according to the transmission condition of the data packet.
  • the transmitting end of the transmitting device is configured to receive the feedback information reported by the sending end of the sending device based on the retransmission mechanism, where the feedback information is sent by the receiving end of the receiving device based on the retransmission mechanism according to the transmission condition of the data packet.
  • the information processing module 512 is configured to obtain, according to the feedback information, a header compressed data packet that is transmitted correctly and/or failed, and determine, according to the correctly compressed and/or failed header compressed data packet, a header compression correctly received by the decompressing terminal.
  • the header compression packet with correct and/or failed transmission and/or header compression correctly received by the decompression terminal may be determined according to the response of the data packet included in the feedback information, the reception error response, and the no response information. The order of the packets.
  • the transmitting end of the transmitting device determines to transmit the correct and/or failed header compressed data packet and/or decompress according to the response of the data packet included in the feedback information, the receiving error response, and the no response information.
  • the order in which the header is correctly received by the terminal is compressed and reported to the information processing module.
  • the header compression state processing module 52 includes:
  • the first processing module 521 is configured to determine, according to the order of the header compressed data packets correctly received by the decompressing end obtained by the information processing module, and the transmission state information of the header compressed data packet saved by the header compression end, whether the decompressing end is The header compression packet can be decompressed, and if so, the header compression end maintains the existing compression state or migrates the compression state from the non-fully compressed state to the fully compressed state; otherwise, the header compression end compresses the state. Migrating from a fully compressed state to a non-fully compressed state.
  • the incompletely compressed state includes: an initial state or a first level state
  • the fully compressed state includes: a second level state.
  • the header compression end determines, according to the response of the header compressed data packet included in the feedback information, the receiving error response, and the no-acknowledgement information, the header compressed data packet that fails to be transmitted and the data packet that is decompressed by the decompression end decompression end. Quantity.
  • the header compression end determines, according to the response of the header compressed data packet included in the feedback information, the received error response information, and the no response information, the order of the header compressed data packets correctly received by the decompressing terminal;
  • the header compression end sequentially compresses the data packets according to the order of the headers received by the decompression terminal, and the header. Compressing the normal transmission order of the data packets, and obtaining the disordered transmission of the header compressed data packets;
  • the header compression end is in accordance with the disordered transmission of the header compressed data packet, and the data saved by the header compression end.
  • the transmission status information of the packet determines whether the decompressing end can decompress the subsequent header compressed data packet.
  • the header compression end migrates the compressed state from the fully compressed state to the incompletely compressed state, the header compression end further notifies the transmitting end of the transmitting device based on the retransmission mechanism to discard the header compressed data packet in the retransmission buffer; Alternatively, the sender of the retransmission-based transmitting device is notified to add the header compression context information to the header compressed data packet in the retransmission buffer, and then sent to the receiving end of the receiving device based on the retransmission mechanism.
  • the second processing module 522 is configured to: when a header compressed data packet is split into multiple MAC or radio link control RLC data packets, the header compression end cannot determine which MAC address or header information the header compression load information is placed on or And determining, by the header compression end, that at least one of the plurality of MAC or RLC data packets is lost according to the response of the header compressed data packet included in the feedback information, the receiving error response, and the no response information.
  • the header compression end notifies the receiving end of the receiving device based on the retransmission mechanism to discard the plurality of MAC or RLC data packets; when a header compressed data packet is split into multiple MAC or RLC data packets, the header compression end When it can be determined which header or load information of the header compression is placed in which MAC or RLC data packet, the header compression end determines the header compression according to the response of the header compressed data packet included in the feedback information, the reception error response, and the no response information.
  • the header compression end After the MAC or RLC data packet of the packet header is lost, the header compression end notifies the receiving end of the receiving device based on the retransmission mechanism to discard the plurality of MAC or RLC data packets;
  • the header compressed data packet is split into a plurality of MAC or RLC data packets, and the header compression end is capable of determining which MAC or RLC data packet the header compressed header and load information are placed respectively, according to the feedback.
  • the receiving end of the retransmission mechanism-based receiving device continues to transmit header compression.
  • the MAC or RLC data packet of the packet header is sent to the decompressing end, and after receiving the MAC or RLC data packet where the header of the header is compressed, the decompressing end compressing and decoding the header is performed by using the packet header information.
  • the context information is compressed, and then the MAC or RLC packet in which the header of the header is compressed is discarded.
  • the third processing module 523 is configured to: in the process of performing header compression on the data packet according to the state of the header compression end, omitting the cyclic redundancy check code in the header compressed data packet; or, after header compression
  • the information occupied by the cyclic redundancy check code in the data packet is set to assist the decompression of the header.
  • the embodiment of the present invention combines a header compression mechanism and an automatic retransmission mechanism, so that the R0HC header compression end obtains feedback information of an automatic retransmission technology such as HARQ, and other useful information of the data packet in wireless transmission. And use the transmission status information of the saved data packet to correctly estimate the decompression information of the R0HC decompression end, thereby adapting Time-changing the state machine of the ROHC head compression end or performing other data processing operations, thereby improving the transmission efficiency of the data packet and improving system performance.
  • the header compression end utilizes the feedback information of the automatic retransmission technology, so that the header compression feedback information sent from the decompression end to the header compression end can be reduced, thereby saving system resources.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

基于重传机制的对头压缩麵 行传输的雄和装置 本申请要求于 2009年 10月 23日提交中国专利局、 申请号为 200910236485. 3、 发 明名称为 "基于重传机制的对头压缩数据包进行传输的方法和装置"的中国专利申请的 优先权， 其全部内容通过引用结合在本申请中。 技术领域 本发明涉及通信技术领域，尤其涉及一种基于重传机制的对头压缩数据包进行传输 的方法和装置。
背景技术 由于物理条件的限制， 无线链路与有线链路相比， 传输速率较低， 而误码率偏高。 当将 IP协议技术应用在无线网络小区环境中时， 存在分组头标开销过大的问题。 例如， 一个 IPv6语音通信分组， 用户真正需要的分组净荷往往只占整个分组的 22%。 这样不仅 浪费带宽， 还增大了由于分组出错而导致的该分组被丢弃的概率。 若不采取有效措施， 在浪费宝贵无线网络资源的同时， 还会降低用户的服务质量。
采用头压缩机制可以解决上述问题， 同时可保证 IP协议固有的灵活性。头压缩机制 可包括： ROHC ( Robust Header Compression, 鲁棒性头标压缩） 、 CRTP ( Real-time Transport Protocol Header Compression, 实时传输协议头压缩） 机制， 以及 ECRTP (Extended RTP Header Compression, 扩展实时传输协议头压缩） 机制等。
以 R0HC为例， R0HC是一种基于流的头标压缩方案。在网络数据传输过程中， 同一个 流的分组中大部分头标域具有相同的域值。 R0HC机制在某个流中取一个参考分组， 对于 其他分组仅仅发送头标域中相对参考分组变化的信息， 以达到压缩目的， 从而节省分组 头标开销， 更加有效地利用带宽。
通过 R0HC机制在无线网络中进行通信， 需要建立 R0HC信道， R0HC信道为一个逻辑信 道， 在这个逻辑信道中， 入口是压缩器， 出口是解压缩器， 压缩器和解压缩器一一对应。 压缩器把原始数据进行头压缩以后通过该逻辑信道发送给解压缩器。该 R0HC信道为单向 逻辑信道。 同时， 为了支持双向压缩， 解压缩器必须能够给压缩器提供反馈信息， 因此 R0HC反馈信道为承载所述反馈信息的逻辑信道， 入口是解压缩器， 出口是压缩器。 ROHC头压缩机制可以被简单描述为两个状态机 （一个压缩状态机和一个解压状态 机）之间的互作用。 两个状态机各自都有三种不同的状态。 两个状态机都是由最低的压 缩状态开始逐步转变到更高的状态。 其中压缩机的状态转移方式如图 1所示， 解压缩机 的状态转移方式如图 2所示。
如上图 1所示， R0HC压缩机包含三种状态： IR ( Initial and Refresh, 初始状态） ，
F0 (First Order, 第一等级） ， SO ( Second Order, 第二等级） 。 初始的状态为 IR状 态， 这时解压缩端几乎没有解压缩所需的静态和动态信息， R0HC压缩端发送 IR或是 IR-DYM数据包， 其中包含了数据包头中的静态信息 （源 IP地址， 目的 IP地址等）和一些 动态信息 （SN序列号， Timestamp时间戳等） 。 IR包既包含静态信息又包含动态信息， 而 IR-DYM包可以只包含动态信息。 当解压缩端得到静态信息和部分动态信息时， 压缩端 处于 F0状态。 当解压缩端得到所有的静态和动态信息， 压缩端进入 SO状态， 报头的数据 压缩到最小。
如图 2所示， R0HC解压缩机包含三种状态： NC (No Context ,没有上下文）， SC C Satic Context , 静态上下文） ， FC (Ful l Context , 全部上下文） 。 NC就是解压缩端的初始 状态， 这时解压缩端没有收到数据包， 没有解压缩需要的任何信息； SC就是解压缩端得 到了全部的静态解压缩的信息以及部分动态解压缩的信息； FC就是解压缩端已经获得了 全部的静态和动态解压缩信息。
R0HC的 Context (上下文） 信息分成两种不同类型： 静态 Context信息和动态的 Context信息， 其中静态 Context信息是很少变化的， 所以一般只要接收端正确接收到， 压缩端就可以不需要再传输； 而动态的 Context信息是变化的， 现有的 IP数据包头中的 动态 Context信息主要为 SN， Timestamp, IP_id。
如果包含了静态 Context信息更新的数据包发生了错误或是丢失， 会导致之后所有 的数据包都无法获取静态 Context信息， 以致于后继大量的解头压缩失败； 如果连续丢 失了一定数量的数据包， 也会导致后继数据包不能解析动态 Context信息， 以致于解头 压缩失败。
ARQ ( auto repeat request , 自动重传请求） 是通过接收方请求发送方重传出错的 数据包文来恢复出错的报文的一种技术， 是通信中用于处理信道所带来差错的方法之
ARQ包括三种方式: 即停等式（stop-and-wait ) ， 回退 n帧 ( go-back-n) ARQ, 选择 性重传 （selective repeat ) ARQ, 以及混合 ARQ (HARQ) 。 它们的区别在于对于出错的 数据包文的处理机制不同。 HARQ系统就是在 ARQ系统中引入了 FEC (Forward Error Correction, 前向纠错） ， 该 FEC可以用来纠正传输过程中的数据差错， 即如果错误在 FEC的纠错范围内， 那么 FEC 就进行纠错， 如果超出了其纠错范围， 那么接收方指示发送方重传出错报文的部分或者 全部信息， 然后， 接收方将再次收到的报文信息与上次收到的报文信息进行合并， 以恢 复报文信息。
采用 R0HC机制可以节约无线网络资源， 提高服务质量， 但由于现有的 R0HC机制对于 错误报头的处理为直接丢弃而不作进一步处理， 在错包率达到一定程度的情况下， 导致 状态回退并更新 context信息， 重新同步解压状态， 在无线链路状况较差时， 会导致频 繁的状态回退， 极大降低压缩效率。 而自动重传机制可以提高报文发送的正确率和可靠 性，
在现有技术的一些无线传输系统中， 比如在 IEEE ( Institute of Electrical and Electronics Engineers , 电子电气工禾呈师协会) 16m, LTE ( Long Term Evolution, 长期演进） 系统中， 虽然同时应用了 R0HC机制和自动重传机制， 但是将 R0HC机制和自 动重传机制作为两个相对独立的技术进行应用， 没有利用 R0HC机制和自动重传机制之间 的关联性特点来提升系统性能。 发明内容 本发明的实施例提供了一种基于重传机制的对头压缩数据包进行传输的方法和装 置， 以实现头压缩端利用重传机制的反馈信息确定所述头压缩端的状态， 根据所述头压 缩端的状态对数据包进行头压缩。
—种基于重传机制的对头压缩数据包进行传输的方法， 包括：
发送设备的头压缩端获取头压缩数据包在传输过程中的反馈信息；
所述头压缩端根据所述反馈信息确定所述头压缩端的状态， 根据所述头压缩端的 状态对数据包进行头压缩并发送给接收设备的解压缩端。
一种基于重传机制的对头压缩数据包进行传输的装置， 包括：
反馈信息获取模块， 用于获取头压缩数据包在传输过程中的反馈信息；
头压缩状态处理模块， 用于根据所述反馈信息确定所述头压缩端的状态， 根据所 述头压缩端的状态对数据包进行头压缩并发送给接收设备的解压缩端。
由上述本发明的实施例提供的技术方案可以看出， 本发明实施例通过将头压缩机 制和重传机制进行结合， 使头压缩端获取重传机制的反馈信息， 可以使头压缩端利用该 反馈信息确定所述头压缩端的状态， 在必要时进行相应的状态转移， 根据所述头压缩端 的状态对数据包进行头压缩， 提高数据包的传输效率。 附图说明 为了更清楚地说明本发明实施例的技术方案， 下面将对实施例描述中所需要使用 的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本发明的一些实施例， 对 于本领域普通技术人员来讲， 在不付出创造性劳动性的前提下， 还可以根据这些附图获 得其他的附图。
图 1 R0HC头压缩机制中的压缩机的状态转移方式示意图；
图 2 R0HC头压缩机制中的解压缩机的状态转移方式示意图；
图 3本发明实施例一提供的一种基于 HARQ的对数据包进行 R0HC压缩方法的处理 流程图；
图 4为本发明实施例一提供的在 IEEE 16m系统中的数据包从高层传输到空口的传 输过程示意图；
图 5 为本发明实施例二提供的一种基于自动重传技术的对数据包进行头压缩的装 置的具体实现结构图。
具体实肺式
在本发明实施例中，发送设备的头压缩端获取头压缩数据包在传输过程中的反馈信 息， 所述头压缩端根据所述反馈信息确定所述头压缩端的状态， 根据所述头压缩端的状 态对数据包进行头压缩并发送给接收设备的解压缩端。
为便于对本发明实施例的理解， 下面将结合附图以几个具体实施例为例做进一步的 解释说明， 且各个实施例并不构成对本发明实施例的限定。
实施例一 该实施例利用 HARQ机制中的反馈信息， HARQ发送端获取数据包在 HARQ接收端上的 传输状态信息， HARQ发送端再将该传输状态信息反馈到 R0HC头压缩端， R0HC头压缩端 根据这些传输状态信息， 可以预测出 R0HC解头压缩器的解头压缩状态， 从而确定所述 R0HC头压缩端的状态， 在必要时相应地改变 R0HC头压缩端的状态机。 该实施例提供的一种基于 HARQ的对头压缩数据包进行传输的方法的处理流程如图 3所示， 包括如下处理步骤： 步骤 31， 在 R0HC头压缩端对每个数据包都保存和管理一个传输状态信息表。 在该实施例中， 为了能够使 R0HC头压缩端得知数据包在网络中实际的传输状况， R0HC头压缩端对每个进行头压缩的数据包都需要保存一个传输状态信息表，该传输状态 信息表中保存的传输状态信息包括： 头压缩序列号， 数据包头信息， 数据包的传输成功 或失败信息， 数据包封装信息和 HARQ进程信息等信息中的至少一项。 上述数据包头信 息中可以包括： R0HC的头压缩 Context信息， 其中包括静态 Context信息和 /或动态的 Context信息。 下面以 IEEE 16m系统来说明该实施例。 在 IEEE 16m 系统中， 数据包从高层传输到空口的传输过程如图 4 所示， CS
( Convergence Sublayer ， 汇聚子层） 子层从高层网络接收数据包， 根据数据包的特 性将数据包分配到不同的 ROHC Context上， 对数据包进行头压缩。 如果该数据包中包 含有 RTP ( Transport Protocol Header Compression, 实时传输协议头压缩） 包头， 则 该 RTP包头中会包含有 SN信息， 将该 SN信息作为该数据包头压缩的序列号； 如果该数 据包中没有包含 RTP包头， 系统会从 0开始逐一递增为该数据包产生虚拟的 SN号作为 该数据包头压缩的序列号。 上述数据包被头压缩后， 被映射到不同的 MAC (Medium Access Control , 媒质接入 控制层） 连接上， 根据实际的系统资源状况， 将该数据包打包分片为不同 MAC数据包。 如果是分片的情况， 一个头压缩后的数据包可以被分成多个不同的 MAC数据包传输。 每 个 MAC数据包中包含头压缩数据包的一部分信息，比如有的数据包只包含数据包头信息， 有的只包含数据包载荷信息。 MAC数据包中没有序列号信息， 但是系统可以在每个 MAC 连接上， 生成一个虚拟的 MAC序列号作为 MAC数据包的标识。 如果 MAC层支持 ARQ， 系 统可以使用 MAC数据包中第一个 ARQ block (块） 的 SN作为 MAC包的标识。 ARQ block 也是一个虚拟数据块， 它对 MAC连接上所有 MAC数据包根据一个固定大小分块、 排序， 产生一个 ARQ序列号。 在 MAC层封装为大小合适的 MAC数据包后， 将 MAC数据包映射到 不同的 HARQ进程上传输。当前帧上，相同 HARQ进程上传输的 MAC数据包组成一个 HARQ 包。 由 lbit的 AISN标识该 HARQ包是否为重传数据包。 在上述 IEEE 16m系统中， 上述数据包封装信息包括： MAC的 CID信息， ARQ block 信息，虚拟 MAC SN信息，数据包是否被打包分片等信息，上述 HARQ进程信息包括： HARQ 进程信息， HARQ数据包重传标识等信息。 步骤 32、HARQ发送端将数据包的传输情况作为反馈信息上报给 R0HC头压缩端。 R0HC 头压缩端根据存储的数据包的传输状态信息表和反馈信息，确定 R0HC头压缩端的状态， 判断是否需要进行状态转移或是进行其他操作。 在该实施例中， 下层对数据包的任何处理都要上报给 R0HC头压缩端， 比如， 数据 封装实体根据网络资源状况对头压缩后的数据包进行封装后， 需要将数据包的封装信息 上报给 R0HC头压缩端。 上述经过封装后的数据包通过 HARQ进程传输到 HARQ接收端后， HARQ接收端需要向 HARQ发送端反馈数据包的传输情况， HARQ发送端将接收到的数据包的传输情况作为反 馈信息上报给 R0HC头压缩端。 R0HC头压缩端根据自身存储的数据包的传输状态信息表 找出对应的数据包。 再根据数据包的传输状态信息表和接收到的数据包的传输情况， 判 断是否需要进行状态转移或是进行其他操作， 比如， 更新缓存中的 MAC数据包里的头压 缩信息。 若是数据包被正确接收， 根据 R0HC现有技术更新压缩状态， 将 IR状态迁移为 F0或 SO状态或是将 F0状态迁移为 SO状态。 若是数据包传输错误， 具体状态迁移方式 见下面介绍。 下面分两种情况来讨论上述 HARQ接收端向 HARQ发送端反馈数据包的传输情况。 情况 1 : 一个 context ID的相关 R0HC数据包都对应到一个 MAC连接上传输， 对应 到一个物理层 HARQ进程上传输。 这种情况下， 如果 HARQ包被正确接收， 则 HARQ接收端向 HARQ发送端反馈 ACK
(ACKnowledge , 应答）； 若是 HARQ包被错误接收， 则 HARQ接收端向 HARQ发送端反馈 NACK ( Unacknowledged, 接收出错应答）； 若是数据包在传输过程中丢失， HARQ接收端 没有收到数据包不会发送任何反馈信息或是反馈数据包在传输中丢失， 则 HARQ发送端 没有收到任何应答信息。 HARQ接收端若是收到和前一个包的 AISN相同的 HARQ包，就知 道这个 HARQ包为重传包， 针对一个重传包， HARQ接收端也要向 HARQ发送端反馈上述 ACK和 NACK或无应答信息。由于一个 HARQ数据包中可能包含多个不同的头压缩数据包， 所以 HARQ接收端反馈的 ACK和 NACK或无应答信息， 指示的是该 HARQ数据包的是否正 确接收， R0HC头压缩端根据述 ACK和 NACK或无应答信息和传输状态信息表中的 HARQ 数据包所封装的头压缩数据包信息， 获取传输正确和 /或失败的头压缩数据包， 再根据 传输正确和 /或失败的头压缩数据包获取 HARQ接收端正确接收到的头压缩数据包的次序 和解头压缩端解压缩失败的数据包的数量。
所述头压缩端根据所述传输失败的头压缩数据包和 /或解压缩端正确接收到的头压 缩数据包的次序， 以及保存的头压缩数据包的传输状态信息， 判断解压缩端是否能够解 压缩后续头压缩数据包， 如果是， 则所述头压缩端保持现有压缩状态不变或者从非完全 压缩状态迁移为完全压缩状态； 否则， 所述头压缩端将状态从完全压缩状态迁移为非完 全压缩状态。 在 R0HC机制中， 所述的非完全压缩状态包括： 初始状态或第一等级状态， 所述的完全压缩状态包括： 第二等级状态。 在实际应用中， HARQ发送端不一定需要把 ACK和 NAK或无应答信息传到 R0HC压缩 端， 可以是由 HARQ发送端根据上述 ACK和 NACK或无应答信息确定传输正确和 /或失败 的数据包， 再根据传输正确和 /或失败的数据包获取 HARQ接收端正确接收到的数据包的 次序和解头压缩端解压缩失败的数据包的数量。 HARQ发送端再将获取的传输正确和 /或 失败的数据包和 /或 HARQ接收端正确接收到的数据包的次序， 以及和解头压缩端解压缩 失败的数据包的数量上报到 R0HC压缩端。 由于 HARQ是停等协议， 一个数据包正确传输或是被丢弃之前是不会传输下一个数 据包的， 所以除非下面的数据包传输到最大次数被丢弃， 是不可能出现乱序的情况。 当 HARQ数据包传输超过最大次数被丢弃时， HARQ发送端向 R0HC头压缩端反馈数据包传输 失败。 R0HC头压缩端获取数据包传输失败后，根据所述传输失败的数据包，查询该数据包 以及该数据包的一定数量的后续数据包对应的传输状态信息表， 当当所述解头压缩端解 压缩失败的数据包的数量与解头压缩端接收到的头压缩数据包的总数量的比例得到了 预先设置的阈值， 即达到了 k of n的状态转移的要求， 则判断上述后续数据包中是否 包含有 IR或 IR-Dyn数据包， 如果是， 则判断 R0HC解压缩端可以恢复上述后续数据包， R0HC头压缩端不做任何处理； 否则， 则判断 R0HC解压缩端不能恢复上述后续数据包， R0HC头压缩端的状态转移为 IR或 F0状态， 发送 IR或 IR-Dyn数据包来更新 R0HC解压 缩端的头压缩信息。 若是 R0HC头压缩端判决出由于丢包， 导致后续还处于 MAC缓存尚未发送的 MAC数 据包即使发送到解压缩端， 解压缩端不能够对该 MAC数据包进行正确解压缩， 则有两种 处理方式： 一是 R0HC头压缩端通知 MAC以及 HARQ发送端发送端直接丢弃上述处于缓存 尚未发送的数据包， 减少空口资源； 二是 R0HC头压缩端通过层间传输的方式通知 MAC 子层， 对于位于 MAC缓存没有发送的已经进行 MAC封装的头压缩数据包， 通过 MAC子头 的形式， 在其中添加必要的可以协助解头压缩的信息和规则 （信息包括： SN和 /或 TS 和 /或 IP-ID等头压缩 context信息， 上述规则包括： 相关信息如何增加到对应的 MAC 头）， 这些信息规则和通过协议层间原语由 R0HC发到 MAC， MAC层收到该原语后， 按照 接收到的信息和规则对处于 MAC缓存尚未发送的 MAC数据包进行处理。 如果一个 R0HC之后的头压缩数据包被拆分成多个不同的 MAC/RLC数据包数据包， 其 R0HC数据包的包头和 payload (负荷）可能被分在不同的 MAC/RLC数据包中传输， 如 果 R0HC头压缩端不能获知包头和 payload分别在哪个 MAC/RLC数据包中， 则如果这几 个 MAC/RLC数据包中的一个 MAC/RLC数据包传输失败，其他的 MAC/RLC数据包可以直接 丢弃。 如果 R0HC头压缩端可以获知包头和 payload分别在哪个 MAC/RLC数据包中， 则 如果包头所在的 MAC/RLC数据包传输失败， R0HC头压缩端要求下层丢弃这几个 MAC/RLC 数据包中的其他 MAC/RLC数据包； 如果只是 payload所在的 MAC数据包传输失败， 则包 头所在的 MAC/RLC数据包继续传输， 并通知接收端将此包头信息传输给 R0HC解压缩端， 解头压缩端收到该包头所在的 MAC/RLC数据包后，利用其中的数据包头信息进行解头压 缩和更新解头压缩 context信息， 之后丢弃该包头所在的 MAC/RLC数据包。 对于一条 MAC连接对应到多个头压缩 Context的情况， 处理方式与上面描述相似， R0HC头压缩端根据收到的数据包丢失信息和自身保存的数据包的传输状态信息表，针对 每个受影响的 Context , 判断其是否需要状态转移或是更新缓存中的 MAC数据包里的头 压缩信息。 情况 2: 如果一个 context ID的相关 ROHC数据包承载在不同的 HARQ进程， 那么在 不同的 HARQ进程上的传输的数据包会有不同的数据出错概率。 例如， HARQ进程 1上承 载了序列号 1-3的数据包， HARQ进程 2上承载了序列号 4_6的数据包， HARQ进程 1和 HARQ进程 2同时开始传输； 但是， 在传输过程中， 序列号 4-6的数据包重传一次后， 被 接收端正确接收； 而序列号 1-3的数据包重传三次后， 才被接收端正确接收， 那么序列 号 4-6的数据包将先于序列号 1-3的数据包被传送到 R0HC解压器， 这种数据包到达的 乱序， 如果超出了解压窗口的大小， 就可能造成数据包解压的出错。 在这种情况下， HARQ发送端接收到头压缩后的 R0HC数据包后， 并需要对 R0HC数据 包承载在不同的 HARQ进程上发送时， 则在每个自动重传进程上的首个数据包为包含头 压缩上下文信息的初始头压缩数据包。 HARQ发送端尽量根据 IR或 IR-DYN包的位置进行 HARQ进程划分， 将 IR或 IR-DY 包或者特定地生成 IR或 IR-DYN包， 放在每个 HARQ进 程上的 HARQ包的首位置， 这样， 即使一个 HARQ进程上的 HARQ包发生了丢失， 不会影 响到其他 HARQ进程上的 HARQ包的解压缩。 在该情况下， HARQ接收端也要向 HARQ发送端反馈上述 ACK和 NACK信息， HARQ发 送端根据接收到的 ACK/NACK, 判断并维护接收端接收的数据包的 SDU ( Service Data Unit , 业务数据单元） 状态和顺序， 将该数据包的 SDU接收状态和顺序发送到 R0HC头 压缩端。 R0HC头压缩端根据上述数据包的 SDU接收状态和顺序和数据包的正常发送次 序， 得出数据包的传输乱序的情况。 然后， 根据所述数据包的传输乱序的情况， 以及保 存的数据包的传输状态信息，判断解压缩端是否能够解压缩所述乱序数据包，如果不能， 则 R0HC头压缩端的状态转移为 IR或 F0状态， 发送 IR或 IR_Dyn数据包来更新 R0HC解 压缩端的头压缩信息； 否则， R0HC头压缩端不进行状态转移。 比如数据包 RTP SN号为 1， 2， 3在进程一中传输， RTP SN号为 4， 5， 6在进程二 中传输， RTP SN号为 7， 8， 9在进程三传输。 由于进程二发生重传， 进程三中的 7， 8， 9先到达解压缩端， 造成乱序。 如果解压缩窗口小于 3， 则当前解压缩器中保持的解头 压缩上下文不能解 RTP SN序列号超过 3的数据包。 这个时候压缩端根据重传技术中的 反馈得知数据包到达解压缩端的次序， 知道解头压缩端不能正确解压序列号为 7， 8， 9 的数据包， 并且错误的数据包达到了 k of n的状态转移的要求， 而其后正在传输的已 经进行头压缩的数据包没有 IR/IR-Dyn数据包， 则头压缩端进行状态转移， 从 SO状态 转移到 F0或 IR状态。 步骤 33、 HARQ接收端根据收到的调度指示和 ACID的序列信息， 对数据包进行正确 排序。 在 HARQ 发送端进行数据包调度时， 可以按照数据包的顺序将数据包顺序地置于
ACID递增的 HARQ进程上传输。
HARQ接收端根据调度指示和 ACID的序列信息，就可以知道来自不同 HARQ进程的数 据包的次序， 从而对数据包进行正确排序。 HARQ接收端要尽量保证属于一个头压缩 Context的数据包顺序发送给 R0HC解头压 缩端， 减少因为乱序造成的解压缩失败。 若是 R0HC头压缩端根据 HARQ的反馈信息判决出由于丢包， 导致后续还处于缓存尚 未发送的数据包即使发送到解压缩端，解压缩端不能够对该 MAC数据包进行正确解压缩， 则有两种处理方式： 一是通知 MAC和 HARQ发送端直接丢弃上述处于缓存尚未发送的数 据包， 减少空口资源； 二是通过层间传输的方式通知 MAC子层， 对于位于 MAC缓存没有 发送的已经进行 MAC封装的头压缩数据包， 通过 MAC子头的形式， 在其中添加必要的可 以协助解头压缩的信息和规则， 按照接收到的信息和规则对处于 MAC 缓存尚未发送的 MAC数据包进行处理。 在采用上述实施例一提供的基于 HARQ 的对数据包进行 R0HC压缩方法的处理流程 后， 可选的可以将头压缩后的数据包中的 CRC ( cycl ic redundancy check code , 循环 冗余校验码）省略， 以减少空口资源消耗。 或是将原有的 CRC校验位所占的比特位改为 增加一些协助解头压缩的信息， 如增加 SN， IP-ID, TS等头压缩信息， 有助于解头压缩 的成功率。 这种省略 CRC校验的方式是可选实现的， 若是使用这种方式进行头压缩， 需要在头 压缩 Context初始建立时， 进行相关能力协商， 确定使用省略 CRC校验的方式进行数据 包的头压缩。 上述实施例一提供的基于 HARQ的对头压缩数据包进行传输的方法的处理流程还可 以应用于 LTE系统。 该传输状态信息表中保存的传输状态信息包括： 头压缩序列号， 数据包头信息， 数 据包的传输成功或失败信息和 HARQ进程信息等信息中的至少一项， 上述数据包头信息 中可以包括： R0HC的 Context信息，其中包括静态 Context信息和动态的 Context信息。 由于 LTE系统与 16m系统有所不同， 其传输信息也有所变化， 主要不同之处有， 上 述 HARQ进程信息中包括有： RLC ( Radio Link Control , 无线链路控制） 序列号、 逻辑 进程 id和 HARQ进程号等。 在 LTE接收端，其 RLC的 UM( Unacknowledged Mode，无应答模式）和 AM( Acknowledged Mode , 应答模式） 模式有对收到的数据包根据 RLC数据包头中的序列号对数据包排序。 这种情况下， 系统有自动排序的功能， 不需要利用调度信息和重传信息排序。 对于 RLC 的 TM模式， 没有排序的功能， 需要和 IEEE 16m系统一样通过调度信息和重传信息对数 据包进行排序。 在实际应用中，上述实施例一中的 HARQ还可以用 ARQ来代替，具体处理过程为 ARQ 接收端将数据包的传输情况反馈给 R0HC头压缩端。 R0HC头压缩端根据存储的数据包的 传输状态信息表和数据包的传输情况， 判断是否需要进行状态转移或是进行其他操作。 所述 R0HC头压缩端存储的数据包传输状态信息与实施例一中的与 HARQ相关的操作相 同。 所述数据包的传输情况， 即 ARQ发送端接收到 ARQ接收端发送来的数据是否正确接 收的反馈信息， 其具体包含数据包正确接收的应答信息， 数据包错误接收的应答信息与 数据包丢失造成的无应答信息。所述状态转移或是进行其他操作的具体判决过程与 HARQ 相关操作相同。 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程， 是可以通 过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质 中， 该程序在执行时， 可包括如上述各方法的实施例的流程。 其中， 所述的存储介质可 为磁碟、 光盘、 只读存储记忆体（Read-Only Memory, ROM)或随机存储记忆体（Random Access Memory, RAM) 等。 实施例二 本发明实施例还提供了一种基于重传技术的对头压缩数据包进行传输的装置， 该装 置设置在发送设备的头压缩端， 其具体实现结构如图 5所示， 具体可以包括：
反馈信息获取模块 51， 用于获取头压缩数据包在传输过程中的反馈信息； 头压缩状态处理模块 52， 用于根据所述反馈信息确定所述头压缩端的状态， 根据所 述头压缩端的状态对数据包进行头压缩并发送给接收设备的解压缩端。
所述的装置还可以包括：
传输状态信息管理模块 53， 用于保存和管理数据包的传输状态信息， 所述的数据包 的传输状态信息包括： 头压缩序列号， 数据包头信息， 传输成功或失败信息、 封装信息 和重传进程信息中的至少一项。
所述的反馈信息获取模块 51包括：
信息接收模块 511， 用于接收基于重传机制的发送设备的发送端上报的所述反馈信 息， 所述反馈信息为基于重传机制的接收设备的接收端根据数据包的传输情况， 反馈给 所述发送设备的发送端的；
信息处理模块 512， 用于根据所述反馈信息获取传输正确和 /或失败的头压缩数据 包， 并根据所述传输正确和 /或失败的头压缩数据包确定解压缩端正确接收到的头压缩 数据包的次序。 在实际应用中， 可以根据所述反馈信息中包括的数据包的应答、 接收出 错应答和无应答信息确定传输正确和 /或失败的头压缩数据包和 /或解压缩端正确接收 到的头压缩数据包的次序。 或者， 由基于重传机制的发送设备的发送端根据所述反馈信 息中包括的数据包的应答、 接收出错应答和无应答信息确定传输正确和 /或失败的头压 缩数据包和 /或解压缩端正确接收到的头压缩数据包的次序， 再上报给信息处理模块。
所述的头压缩状态处理模块 52包括：
第一处理模块 521， 用于根据所述信息处理模块获取的解压缩端正确接收到的头压 缩数据包的次序， 以及头压缩端保存的头压缩数据包的传输状态信息， 判断解压缩端是 否能够解压缩后续头压缩数据包， 如果是， 则所述头压缩端保持现有压缩状态不变或者 将压缩状态从非完全压缩状态迁移为完全压缩状态； 否则， 所述头压缩端将压缩状态从 完全压缩状态迁移为非完全压缩状态。
在 R0HC中， 所述的非完全压缩状态包括： 初始状态或第一等级状态， 所述的完全压 缩状态包括： 第二等级状态。
比如， 所述头压缩端根据所述反馈信息中包括的头压缩数据包的应答、 接收出错应 答和无应答信息，确定传输失败的头压缩数据包以及解头压缩端解压缩失败的数据包的 数量。
当所述解头压缩端解压缩失败的数据包的数量与解头压缩端接收到的头压缩数据 包的总数量的比例达到了预先设置的阈值时，判断所述后续数据包中包含的头压缩上下 文信息是否足够， 如果是， 则判断解压缩端能够解压缩所述后续头压缩数据包； 否则， 判断解压缩端不能解压缩所述后续头压缩数据包。
再比如， 所述头压缩端根据所述反馈信息中包括的头压缩数据包的应答、 接收出错 应答信息和无应答信息， 确定解压缩端正确接收到的头压缩数据包的次序；
当属于一个头压缩上下文连接上的多个头压缩数据包被承载在不同的重传进程上 传输时， 所述头压缩端根据所述解压缩端正确接收到的头压缩数据包的次序， 以及头压 缩数据包的正常发送次序， 得出头压缩数据包的传输乱序的情况；
所述头压缩端根据所述头压缩数据包的传输乱序的情况， 以及头压缩端保存的数据 包的传输状态信息， 判断解压缩端是否能够解压缩后续头压缩数据包。
所述的头压缩端将压缩状态从完全压缩状态迁移为非完全压缩状态之后，所述头压 缩端还通知基于重传机制的发送设备的发送端丢弃处于重传缓存中的头压缩数据包； 或 者，通知所述基于重传机制的发送设备的发送端在所述处于重传缓存中的头压缩数据包 中添加头压缩上下文信息后， 再发送给基于重传机制的接收设备的接收端。
第二处理模块 522， 用于当一个头压缩数据包被拆分成多个 MAC或无线链路控制 RLC 数据包，所述头压缩端不能确定头压缩的包头和负荷信息分别放在哪个 MAC或 RLC数据包 时， 所述头压缩端根据所述反馈信息中包括的头压缩数据包的应答、 接收出错应答和无 应答信息确定所述多个 MAC或 RLC数据包中的至少一个丢失后， 则所述头压缩端通知基于 重传机制的接收设备的接收端丢弃所述多个 MAC或 RLC数据包； 当一个头压缩数据包被拆分成多个 MAC或 RLC数据包，所述头压缩端能够确定头压缩 的包头和负荷信息分别放在哪个 MAC或 RLC数据包时，所述头压缩端根据所述反馈信息中 包括的头压缩数据包的应答、 接收出错应答和无应答信息确定头压缩的包头所在的 MAC 或 RLC数据包丢失后， 则所述头压缩端通知基于重传机制的接收设备的接收端丢弃所述 多个 MAC或 RLC数据包； 当一个头压缩数据包被拆分成多个 MAC或 RLC数据包，所述头压缩端能够确定头压缩 的包头和负荷信息分别放在哪个 MAC或 RLC数据包时，所述头压缩端根据所述反馈信息中 包括的头压缩数据包的应答、 接收出错应答和无应答信息确定头压缩的负荷所在的 MAC 或 RLC数据包丢失后， 则所述基于重传机制的接收设备的接收端继续传输头压缩的包头 所在的 MAC或 RLC数据包给解压缩端， 所述解头压缩端收到该头压缩的包头所在的 MAC或 RLC数据包后， 利用其中的数据包头信息进行解头压缩和更新解头压缩上下文信息， 之 后丢弃该头压缩的包头所在的 MAC或 RLC数据包。 第三处理模块 523，用于在根据所述头压缩端的状态对数据包进行头压缩的过程中， 将头压缩后的数据包中的循环冗余校验码省略； 或者， 在头压缩后的数据包中的循环冗 余校验码所占的比特位中设置协助解头压缩的信息。 综上所述， 本发明实施例通过将头压缩机制和自动重传机制进行结合， 使 R0HC头压 缩端获取 HARQ等自动重传技术的反馈信息， 以及数据包在无线传输中的其他有用信息， 并利用保存的数据包的传输状态信息， 正确估计 R0HC解压缩端的解头压缩信息， 从而适 时地改变 ROHC头压缩端的状态机或者进行其他数据处理操作， 从而提高数据包的传输效 率， 提高系统性能。 本发明实施例由于使头压缩端利用了自动重传技术的反馈信息，可以减少来自解压 缩端向头压缩端发送的头压缩反馈信息， 从而节省系统资源。 以上所述， 仅为本发明较佳的具体实施方式， 但本发明的保护范围并不局限于此， 任何熟悉本技术领域的技术人员在本发明揭露的技术范围内， 可轻易想到的变化或替 换， 都应涵盖在本发明的保护范围之内。 因此， 本发明的保护范围应该以权利要求的保 护范围为准。

Claims

权利要求
1、 一种基于重传机制的对头压缩数据包进行传输的方法， 其特征在于， 包括： 发送设备的头压缩端获取头压缩数据包在传输过程中的反馈信息；
所述头压缩端根据所述反馈信息确定所述头压缩端的状态，根据所述头压缩端的状 态对数据包进行头压缩并发送给接收设备的解压缩端。
2、 根据权利要求 1所述的基于重传机制的对头压缩数据包进行传输的方法， 其特征 在于， 所述的发送设备的头压缩端获取头压缩数据包在重传过程中的反馈信息， 包括： 所述头压缩端接收基于重传机制的发送设备的发送端上报的所述反馈信息，所述反 馈信息为基于重传机制的接收设备的接收端根据数据包的传输情况， 反馈给所述自动重 传的发送端的。
3、 根据权利要求 1或 2所述的基于重传机制的对头压缩数据包进行传输的方法， 其 特征在于， 所述头压缩端根据所述反馈信息确定所述头压缩端的状态， 包括：
所述头压缩端根据所述反馈信息获取传输正确和 /或失败的头压缩数据包， 并根据 所述传输正确和 /或失败的头压缩数据包确定解压缩端正确接收到的头压缩数据包的次 序；
所述头压缩端根据所述解压缩端正确接收到的头压缩数据包的次序， 以及头压缩端 保存的头压缩数据包的传输状态信息， 判断解压缩端是否能够解压缩后续头压缩数据 包， 如果是， 则所述头压缩端保持现有压缩状态不变或者将压缩状态从非完全压缩状态 迁移为完全压缩状态； 否则， 所述头压缩端将压缩状态从完全压缩状态迁移为非完全压 缩状态。
4、 根据权利要求 3所述的基于重传机制的对头压缩数据包进行传输的方法， 其特征 在于， 在鲁棒性头标压缩 R0HC中， 所述的非完全压缩状态包括： 初始状态或第一等级状 态， 所述的完全压缩状态包括： 第二等级状态。
5、 根据权利要求 3所述的基于重传机制的对头压缩数据包进行传输的方法， 其特征 在于， 所述的判断解压缩端是否能够解压缩后续头压缩数据包， 包括：
所述头压缩端根据所述反馈信息中包括的头压缩数据包的应答、接收出错应答和无 应答信息，确定传输失败的头压缩数据包，以及解头压缩端解压缩失败的数据包的数量; 当所述解头压缩端解压缩失败的数据包的数量与解头压缩端接收到的头压缩数据 包的总数量的比例达到了预先设置的阈值时，判断所述后续数据包中包含的头压缩上下 文信息是否足够， 如果是， 则判断解压缩端能够解压缩所述后续头压缩数据包； 否则， 判断解压缩端不能解压缩所述后续头压缩数据包。
6、 根据权利要求 3所述的基于重传机制的对头压缩数据包进行传输的方法， 其特征 在于， 所述的判断解压缩端是否能够解压缩后续头压缩数据包， 包括：
所述头压缩端根据所述反馈信息中包括的头压缩数据包的应答、接收出错应答信息 和无应答信息， 确定解压缩端正确接收到的头压缩数据包的次序；
当属于一个头压缩上下文连接上的多个头压缩数据包被承载在不同的重传进程上 传输时， 所述头压缩端根据所述解压缩端正确接收到的头压缩数据包的次序， 以及头压 缩数据包的正常发送次序， 得出头压缩数据包的传输乱序的情况；
所述头压缩端根据所述头压缩数据包的传输乱序的情况， 以及头压缩端保存的数据 包的传输状态信息， 判断解压缩端是否能够解压缩后续头压缩数据包。
7、 根据权利要求 3所述的基于重传机制的对头压缩数据包进行传输的方法， 其特 征在于， 所述的头压缩数据包的传输状态信息包括： 头压缩序列号， 数据包头信息， 传 输成功或失败信息、 封装信息和重传进程信息中的至少一项。
8、 根据权利要求 3所述的基于重传机制的对头压缩数据包进行传输的方法， 其特征 在于，所述的头压缩端将压缩状态从完全压缩状态迁移为非完全压缩状态之后，还包括: 所述头压缩端通知基于重传机制的发送设备的发送端丢弃处于重传缓存中的头压 缩数据包； 或者， 通知所述基于重传机制的发送设备的发送端在所述处于重传缓存中的 头压缩数据包中添加头压缩上下文信息后， 再发送给基于重传机制的接收设备的接收 W o
9、 根据权利要求 1或 2所述的基于重传机制的对头压缩数据包进行传输的方法， 其 特征在于， 所述的方法还包括：
当一个头压缩数据包被拆分成多个 MAC或无线链路控制 RLC数据包，所述头压缩端不 能确定头压缩的包头和负荷信息分别放在哪个 MAC或 RLC数据包时，所述头压缩端根据所 述反馈信息中包括的头压缩数据包的应答、 接收出错应答和无应答信息确定所述多个 MAC或 RLC数据包中的至少一个丢失后， 则所述头压缩端通知基于重传机制的接收设备的 接收端丢弃所述多个 MAC或 RLC数据包； 当一个头压缩数据包被拆分成多个 MAC或 RLC数据包，所述头压缩端能够确定头压 缩的包头和负荷信息分别放在哪个 MAC或 RLC数据包时，所述头压缩端根据所述反馈信 息中包括的头压缩数据包的应答、接收出错应答和无应答信息确定头压缩的包头所在的 MAC或 RLC数据包丢失后， 则所述头压缩端通知基于重传机制的接收设备的接收端丢弃 所述多个 MAC或 RLC数据包； 当一个头压缩数据包被拆分成多个 MAC或 RLC数据包，所述头压缩端能够确定头压 缩的包头和负荷信息分别放在哪个 MAC或 RLC数据包时，所述头压缩端根据所述反馈信 息中包括的头压缩数据包的应答、接收出错应答和无应答信息确定头压缩的负荷所在的 MAC或 RLC数据包丢失后， 则所述基于重传机制的接收设备的接收端继续传输头压缩的 包头所在的 MAC或 RLC数据包给解压缩端，所述解头压缩端收到该头压缩的包头所在的 MAC或 RLC数据包后， 利用其中的数据包头信息进行解头压缩和更新解头压缩上下文信 息， 之后丢弃该头压缩的包头所在的 MAC或 RLC数据包。
10、 根据权利要求 1或 2所述的基于重传机制的对头压缩数据包进行传输的方法， 其 特征在于， 所述的方法还包括：
当属于一个头压缩上下文连接上的多个头压缩数据包被承载在不同的重传进程上 传输时， 如果所述多个头压缩数据包中有包含头压缩信息的初始头压缩数据包， 则每个 重传进程中的首个头压缩数据包为包含头压缩信息的初始头压缩数据包。
11、 根据权利要求 1或 2所述的基于自动重传技术的对数据包进行头压缩的方法， 其 特征在于， 所述的方法还包括：
当一个头压缩数据包需要承载在多个重传进程上传输时，基于重传机制的发送设备 的发送端将所述头压缩数据包顺序地置于标识递增的重传进程上传输；
基于重传机制的接收设备的接收端根据接收到的数据包的调度信息和所述多个重 传进程的标识的序列信息， 对接收到的所述多个重传进程上传输的数据包进行排序。
12、 根据权利要求 1或 2所述的基于重传机制的对头压缩数据包进行传输的方法， 其 特征在于， 在根据所述头压缩端的状态对数据包进行头压缩的过程中， 将头压缩后的数 据包中的循环冗余校验码省略； 或者， 在头压缩后的数据包中的循环冗余校验码所占的 比特位中设置协助解头压缩的信息。
13、 一种基于重传机制的对头压缩数据包进行传输的装置， 其特征在于， 包括： 反馈信息获取模块， 用于获取头压缩数据包在传输过程中的反馈信息；
头压缩状态处理模块， 用于根据所述反馈信息确定所述头压缩端的状态， 根据所述 头压缩端的状态对数据包进行头压缩并发送给接收设备的解压缩端。
14、 根据权利要求 13所述的基于重传机制的对头压缩数据包进行传输的装置， 其特 征在于， 所述的装置还包括：
传输状态信息管理模块， 用于保存和管理数据包的传输状态信息， 所述的数据包的 传输状态信息包括： 头压缩序列号， 数据包头信息， 传输成功或失败信息、 封装信息和 重传进程信息中的至少一项。
15、 根据权利要求 13所述的基于重传机制的对头压缩数据包进行传输的装置， 其特 征在于， 所述的反馈信息获取模块包括：
信息接收模块， 用于接收基于重传机制的发送设备的发送端上报的所述反馈信息， 所述反馈信息为基于重传机制的接收设备的接收端根据数据包的传输情况， 反馈给所述 发送设备的发送端的；
信息处理模块， 用于根据所述反馈信息获取传输正确和 /或失败的头压缩数据包， 并根据所述传输正确和 /或失败的头压缩数据包确定解压缩端正确接收到的头压缩数据 包的次序。
16、 根据权利要求 15所述的基于重传机制的对头压缩数据包进行传输的装置， 其特 征在于， 所述的头压缩状态处理模块包括：
第一处理模块，用于根据所述信息处理模块获取的所述解压缩端正确接收到的头压 缩数据包的次序， 以及头压缩端保存的头压缩数据包的传输状态信息， 判断解压缩端是 否能够解压缩后续头压缩数据包， 如果是， 则所述头压缩端保持现有压缩状态不变或者 将压缩状态从非完全压缩状态迁移为完全压缩状态； 否则， 所述头压缩端将压缩状态从 完全压缩状态迁移为非完全压缩状态。
17、 根据权利要求 13所述的基于重传机制的对头压缩数据包进行传输的装置， 其特 征在于， 所述的头压缩状态处理模块包括：
第二处理模块，用于当一个头压缩数据包被拆分成多个 MAC或无线链路控制 RLC数据 包， 所述头压缩端不能确定头压缩的包头和负荷信息分别放在哪个 MAC或 RLC数据包时， 所述头压缩端根据所述反馈信息中包括的头压缩数据包的应答、接收出错应答和无应答 信息确定所述多个 MAC或 RLC数据包中的至少一个丢失后， 则所述头压缩端通知基于重传 机制的接收设备的接收端丢弃所述多个 MAC或 RLC数据包； 当一个头压缩数据包被拆分成多个 MAC或 RLC数据包，所述头压缩端能够确定头压缩 的包头和负荷信息分别放在哪个 MAC或 RLC数据包时，所述头压缩端根据所述反馈信息中 包括的头压缩数据包的应答、 接收出错应答和无应答信息确定头压缩的包头所在的 MAC 或 RLC数据包丢失后， 则所述头压缩端通知基于重传机制的接收设备的接收端丢弃所述 多个 MAC或 RLC数据包； 当一个头压缩数据包被拆分成多个 MAC或 RLC数据包，所述头压缩端能够确定头压缩 的包头和负荷信息分别放在哪个 MAC或 RLC数据包时，所述头压缩端根据所述反馈信息中 包括的头压缩数据包的应答、 接收出错应答和无应答信息确定头压缩的负荷所在的 MAC 或 RLC数据包丢失后， 则所述基于重传机制的接收设备的接收端继续传输头压缩的包头 所在的 MAC或 RLC数据包给解压缩端， 所述解头压缩端收到该头压缩的包头所在的 MAC或 RLC数据包后， 利用其中的数据包头信息进行解头压缩和更新解头压缩上下文信息， 之 后丢弃该头压缩的包头所在的 MAC或 RLC数据包。
18、 根据权利要求 13所述的基于重传机制的对头压缩数据包进行传输的装置， 其 特征在于， 所述的头压缩状态处理模块包括： 第三处理模块， 用于在根据所述头压缩端的状态对数据包进行头压缩的过程中， 将 头压缩后的数据包中的循环冗余校验码省略； 或者， 在头压缩后的数据包中的循环冗余 校验码所占的比特位中设置协助解头压缩的信息。
PCT/CN2010/077911 2009-10-23 2010-10-20 基于重传机制的对头压缩数据包进行传输的方法和装置 WO2011047621A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP10824462.5A EP2493104B1 (en) 2009-10-23 2010-10-20 Header compression data packet transmission method and device based on retransmission mechanism
US13/436,280 US8392616B2 (en) 2009-10-23 2012-03-30 Method and apparatus for transmitting header-compressed packet based on retransmission mechanism

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200910236485.3A CN102045132B (zh) 2009-10-23 2009-10-23 基于重传机制的对头压缩数据包进行传输的方法和装置
CN200910236485.3 2009-10-23

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/436,280 Continuation US8392616B2 (en) 2009-10-23 2012-03-30 Method and apparatus for transmitting header-compressed packet based on retransmission mechanism

Publications (1)

Publication Number Publication Date
WO2011047621A1 true WO2011047621A1 (zh) 2011-04-28

Family

ID=43899835

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/077911 WO2011047621A1 (zh) 2009-10-23 2010-10-20 基于重传机制的对头压缩数据包进行传输的方法和装置

Country Status (4)

Country Link
US (1) US8392616B2 (zh)
EP (1) EP2493104B1 (zh)
CN (1) CN102045132B (zh)
WO (1) WO2011047621A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113115361A (zh) * 2019-01-16 2021-07-13 Oppo广东移动通信有限公司 以太网帧头压缩处理方法、装置、芯片及计算机程序

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102148676B (zh) * 2011-05-09 2013-06-05 北京星河亮点技术股份有限公司 下行harq的实现系统及方法
CN102984753A (zh) * 2011-09-05 2013-03-20 普天信息技术研究院有限公司 一种提高无线通信数据传输效率的方法
US9356645B2 (en) * 2012-11-16 2016-05-31 International Business Machines Corporation Saving bandwidth in transmission of compressed data
US9307419B1 (en) * 2013-03-07 2016-04-05 Sprint Communications Company L.P. Data transmission throughput for a wireless access node
IN2014CH00621A (zh) * 2014-02-07 2015-08-14 Samsung R & D Inst India Bangalore Private Ltd
US9923695B2 (en) * 2014-09-24 2018-03-20 Samsung Electronics Co., Ltd. Call processing method and apparatus for use in LTE system
CN105591711B (zh) * 2014-10-22 2019-12-03 中兴通讯股份有限公司 鲁棒性头压缩状态回迁的方法及压缩器
CN105764092A (zh) * 2014-12-17 2016-07-13 中兴通讯股份有限公司 初始状态报文发送控制方法、压缩端、解压端设备及系统
WO2016183820A1 (zh) * 2015-05-20 2016-11-24 华为技术有限公司 上行数据包处理方法、装置和基站
KR102300300B1 (ko) * 2015-07-03 2021-09-09 삼성전자주식회사 헤더 압축을 이용한 패킷 통신 방법 및 장치
US10110360B2 (en) * 2015-07-27 2018-10-23 Qualcomm Incorporated Recovery mechanism for ROHC with lost initialization and refresh messages
US10194348B2 (en) * 2016-05-27 2019-01-29 Qualcomm Incorporated Techniques and apparatuses for improved robust header compression (ROHC) decompression
US10623230B2 (en) * 2016-07-18 2020-04-14 The Regents Of The University Of California Trans-layer robust header-compression technique
CN107645746B (zh) * 2016-07-20 2021-03-16 深圳市中兴微电子技术有限公司 一种上下文更新方法、系统及设备
CN108093298A (zh) * 2016-11-21 2018-05-29 松下知识产权经营株式会社 影像传输系统
US10706779B2 (en) * 2017-02-23 2020-07-07 Synaptics Incorporated Device and method for image data processing
WO2018203982A1 (en) * 2017-05-05 2018-11-08 The Regents Of The University Of California Trans-layer bidirectional robust header compression system
CN109219078B (zh) * 2017-07-04 2020-07-28 大唐移动通信设备有限公司 语音丢包处理方法及装置
CN110290480B (zh) * 2018-03-19 2021-12-28 成都鼎桥通信技术有限公司 群组呼叫方法、通信装置及存储介质
CN110636035B (zh) * 2018-06-25 2020-11-20 大唐移动通信设备有限公司 一种通信方法、装置及可读存储介质
CN111385263B (zh) * 2018-12-29 2022-05-24 大唐移动通信设备有限公司 一种数据包头压缩信息的维护方法及通信设备
CN110062419A (zh) * 2019-04-18 2019-07-26 苏州博联科技有限公司 基于马尔可夫决策过程的数据报文头压缩优化方法
CN111866969B (zh) * 2019-04-30 2021-10-26 华为技术有限公司 一种数据处理方法、通信装置和系统
CN112218390A (zh) * 2019-07-10 2021-01-12 大唐移动通信设备有限公司 数据处理的方法和设备
US10817460B2 (en) * 2019-08-28 2020-10-27 Advanced New Technologies Co., Ltd. RDMA data sending and receiving methods, electronic device, and readable storage medium
CN112769743B (zh) * 2019-11-06 2022-05-24 大唐移动通信设备有限公司 一种报头压缩方法、装置及设备
US11330665B2 (en) * 2020-01-09 2022-05-10 Qualcomm Incorporated Increasing throughput efficiency in a PDCP channel with ROHC TCP profile
CN115039438A (zh) * 2020-05-15 2022-09-09 Oppo广东移动通信有限公司 一种发送数据包的方法及压缩设备
WO2021262248A1 (en) * 2020-06-22 2021-12-30 Qualcomm Incorporated Techniques for selective re-compression of robust header compression packets
CN117715109A (zh) * 2020-11-24 2024-03-15 展讯半导体(成都)有限公司 通信处理方法、设备、装置及存储介质
US20230009824A1 (en) * 2021-07-09 2023-01-12 Qualcomm Incorporated Transmission of previously compressed packets to avoid throughput drop
CN115834002B (zh) * 2022-11-16 2023-10-31 江苏为是科技有限公司 高速传输系统及方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1835588A (zh) * 2005-03-17 2006-09-20 华为技术有限公司 一种数据流头压缩中的全头包发送方法
WO2007120335A2 (en) * 2005-12-23 2007-10-25 Qualcomm Incorporated System and method for optimizing robust header compression (rohc) in high delay variance environment
CN101365158A (zh) * 2007-08-10 2009-02-11 华为技术有限公司 头压缩反馈的参数协商、实现方法和系统
CN101453298A (zh) * 2007-12-07 2009-06-10 华为技术有限公司 一种无线网络中头压缩的处理方法及系统、装置

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6542931B1 (en) * 1999-11-05 2003-04-01 Nokia Corporation Using sparse feedback to increase bandwidth efficiency in high delay, low bandwidth environment
US7817628B2 (en) * 2004-11-15 2010-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for header compression with transmission of context information dependent upon media characteristic
US8804765B2 (en) * 2005-06-21 2014-08-12 Optis Wireless Technology, Llc Dynamic robust header compression
US20070025345A1 (en) * 2005-07-27 2007-02-01 Bachl Rainer W Method of increasing the capacity of enhanced data channel on uplink in a wireless communications systems
US7876695B2 (en) * 2006-03-07 2011-01-25 Telefonaktiebolaget Lm Ericsson (Publ) Communication station and method providing flexible compression of data packets
US8175075B2 (en) * 2006-12-26 2012-05-08 Alcatel Lucent Adaptive header compression in a wireless communication network
US7920535B2 (en) * 2007-01-16 2011-04-05 Texas Instruments Incorporated Idle connection state power consumption reduction in a wireless local area network using beacon delay advertisement
US20080285566A1 (en) * 2007-04-27 2008-11-20 Interdigital Technology Corporation Method and apparatus for providing and utilizing radio link control and medium access control packet delivery notification
KR101495913B1 (ko) * 2007-08-10 2015-02-25 엘지전자 주식회사 이동통신 시스템에서 ｐｄｃｐ 계층의 제어 데이터 전송방법, 수신 방법, 그 송신장치 및 수신장치
KR101163275B1 (ko) * 2008-03-17 2012-07-05 엘지전자 주식회사 Ｐｄｃｐ 상태 보고 전송 방법

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1835588A (zh) * 2005-03-17 2006-09-20 华为技术有限公司 一种数据流头压缩中的全头包发送方法
WO2007120335A2 (en) * 2005-12-23 2007-10-25 Qualcomm Incorporated System and method for optimizing robust header compression (rohc) in high delay variance environment
CN101365158A (zh) * 2007-08-10 2009-02-11 华为技术有限公司 头压缩反馈的参数协商、实现方法和系统
CN101453298A (zh) * 2007-12-07 2009-06-10 华为技术有限公司 一种无线网络中头压缩的处理方法及系统、装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2493104A4 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113115361A (zh) * 2019-01-16 2021-07-13 Oppo广东移动通信有限公司 以太网帧头压缩处理方法、装置、芯片及计算机程序
CN113115361B (zh) * 2019-01-16 2023-03-10 Oppo广东移动通信有限公司 以太网帧头压缩处理方法、装置、芯片及计算机程序
US11736977B2 (en) 2019-01-16 2023-08-22 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method for header compression of ethernet frame, terminal device

Also Published As

Publication number Publication date
CN102045132B (zh) 2014-04-30
CN102045132A (zh) 2011-05-04
EP2493104B1 (en) 2014-12-17
EP2493104A1 (en) 2012-08-29
EP2493104A4 (en) 2012-08-29
US8392616B2 (en) 2013-03-05
US20120189023A1 (en) 2012-07-26

Similar Documents

Publication Publication Date Title
WO2011047621A1 (zh) 基于重传机制的对头压缩数据包进行传输的方法和装置
US9736723B2 (en) Link layer assisted robust header compression context update management
US7636312B2 (en) Apparatus and method for moving a receive window in a radio access network
US7904777B2 (en) Method and system for generating block acknowledgements in wireless communications
US20090319850A1 (en) Local drop control for a transmit buffer in a repeat transmission protocol device
WO2010121410A1 (zh) 一种采用arq机制的头压缩通信方法和装置
WO2007098676A1 (fr) Procédé de réassemblage de données dans un système de communication sans fil et appareil associé
JP5120456B2 (ja) 通信システム、通信装置、通信方法、及び通信プログラム
KR20100053625A (ko) 무선 통신 시스템에서의 핸드오버 동안 데이터의 계층 2 터널링
TW200935812A (en) Status reporting for retransmission protocol
WO2011079777A1 (zh) 数据传输的方法和网络侧设备
JP2004507167A (ja) データ送信プロトコル
WO2010121409A1 (zh) 一种压缩数据包的传输方法及装置
KR100668680B1 (ko) 휴대 인터넷 시스템의 자동 재전송 요구 연결에서 효율적인데이터 폐기 처리 방법
WO2011061855A1 (ja) 無線通信装置、システム及び再送制御方法
KR101374261B1 (ko) 이동통신 시스템에서 컨트롤 프로토콜 데이터 유니트전달을 위한 장치 및 방법

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010824462

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE