WO2020119718A1 - Procédé et dispositif de décompression de paquets de données - Google Patents

Procédé et dispositif de décompression de paquets de données Download PDF

Info

Publication number
WO2020119718A1
WO2020119718A1 PCT/CN2019/124546 CN2019124546W WO2020119718A1 WO 2020119718 A1 WO2020119718 A1 WO 2020119718A1 CN 2019124546 W CN2019124546 W CN 2019124546W WO 2020119718 A1 WO2020119718 A1 WO 2020119718A1
Authority
WO
WIPO (PCT)
Prior art keywords
data packet
packet
timestamp
period
decompression
Prior art date
Application number
PCT/CN2019/124546
Other languages
English (en)
Chinese (zh)
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 WO2020119718A1 publication Critical patent/WO2020119718A1/fr

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0205Traffic management, e.g. flow control or congestion control at the air interface
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0006Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056Systems characterized by the type of code used
    • H04L1/0061Error detection codes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0078Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0079Formats for control data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W56/00Synchronisation arrangements

Definitions

  • the embodiments of the present application relate to the technical field of communications, and in particular to a method and a device for decompressing a data packet.
  • Robust packet header compression is an efficient packet header compression technology that is applied to the packet data aggregation protocol (Packet Data Convergence Protocol, PDCP) layer in the link layer in wireless communication, which can greatly improve air interface transmission Efficiency, save air interface resources, improve cell edge coverage and system capacity.
  • PDCP Packet Data Convergence Protocol
  • the compression end compresses the header of the original message at the PDCP layer.
  • the compressed message passes through the radio link control (Radio Link Control, RLC) layer, media access control (MAC) layer, and physical layer (PHY) After the relevant processing, it is transmitted to the receiving end through the air interface.
  • RLC Radio Link Control
  • MAC media access control
  • PHY physical layer
  • the compressed packet is submitted to the PDCP layer through the PHY layer, MAC layer and RLC layer.
  • the decompression end decompresses the compressed message to restore the original Message to complete the compression and decompression process.
  • the compression end when a new data stream arrives, the compression end first enters the compression initialization state, saves the packet header information of the data stream in the corresponding context of the compression end, and sends the complete header information to the decompression end, the decompression end Save the header information in the corresponding context of the decompression end.
  • the compression end After the decompression end receives all the contexts, the compression end enters the compressed state and starts to send compressed messages.
  • Each compression message sent by the compression end can have a selective update context to ensure that the compression end context holds the header information of the compression end that was successfully sent by the compression end.
  • the decompression end can update the compressed message after receiving it The context of the corresponding decompression end to ensure that the context of the compression end and the decompression end are synchronized.
  • the coefficient (TS_scaled) changes the important compressed message loss information (for example: air interface fluctuation, weak coverage packet loss), or there are consecutive multiple compressed messages (including important compressed messages) loss, the time in the context of the compression end and decompression end Timestamp related information will be inconsistent, such as timestamp step size (Ts_stride), timestamp step size coefficient (TS_scaled), etc. Subsequent compression messages (such as type 0 packets) that enter a new talk period or silence period will fail to decompress continuously, resulting in deterioration of voice quality.
  • Ts_stride timestamp step size coefficient
  • Embodiments of the present application provide a method and a device for decompressing a data packet, so as to reduce the decompression failure caused by the loss of key data packets or the compatibility problem of the compression encoding method, and improve the voice quality.
  • an embodiment of the present application provides a method for decompressing a data packet, which includes: when the decompression of the header of the current data packet fails, determining whether the failure to decompress the header occurs during the conversion between the talk period and the silent period; The failure to decompress the packet header occurs during the conversion between the talk period and the quiet period. According to the difference between the sequence number of the message, the time stamp step of the data packet, and the time stamp of the last correctly decompressed data packet, multiple time stamps to be verified are obtained.
  • the difference between the packet sequence numbers is the difference between the packet sequence number of the current data packet after decoding and the packet sequence number of the last correctly decompressed data packet; using the multiple time stamps to be checked, Make the current data packet header cyclic redundancy check CRC correct timestamp update context, the context is used to decompress the subsequently received data packet.
  • the execution body of the method steps in the embodiments of the present application is a decompression terminal.
  • the decompression terminal may be a terminal device or a chip in the terminal device, or may be an access network device or a chip in the access network device.
  • the execution subject is a terminal device or a chip in the terminal device
  • the execution subject is an access network device or a chip in the access network device.
  • the use of the plurality of time stamps to be checked so that the header time of the current data packet cyclic redundancy check CRC correct time stamp update context includes: using the plurality of The timestamp to be verified is CRC-checked with other field information of the header of the current data packet to determine whether there is a timestamp with correct verification; when there is a timestamp with correct verification, according to the timestamp with correct verification A timestamp step size coefficient is determined, and the context is updated using the verified timestamp and the timestamp step size coefficient.
  • the timestamp step size coefficient is further determined by verifying the correct timestamp, and the context is updated with the correct timestamp and timestamp stepping coefficient, thereby improving the accuracy of decompressing subsequent received data packets.
  • the method further includes: separately decompressing the subsequent received data packets using multiple updated contexts, and decompressing them consecutively k times An updated context after successful compression is used as a context for decompressing subsequently received data packets; wherein, the multiple updated contexts are respectively determined according to multiple verified timestamps, and k is taken Integer greater than 1.
  • the updated context can be used to decompress multiple times to achieve the correct update of the context. Ensure correct decompression of subsequently received data packets to improve the quality of voice calls.
  • the multiple time stamps to be checked include: ⁇ Pre-Timestamp+Ts_stride*delta_sn, Pre-Timestamp+Ts_stride*(delta_sn+1), ..., Pre-Timestamp+Ts_stride*delta_sn*8 ⁇
  • the former Timestamp represents the timestamp of the last correctly decompressed data packet
  • Ts_stride represents the timestamp step size of the data packet
  • delta_sn represents the difference between the sequence numbers of the packets.
  • the method further includes: selecting a time stamp step size of the data packet from a step size set, the step size set includes a call period step size, a silent period step size, and zero One or more items; perform the step of obtaining multiple timestamps to be verified based on the packet sequence number difference, the timestamp step of the data packet, and the timestamp of the last correctly decompressed data packet; When there is no correct timestamp among the multiple timestamps to be verified, a different step size value is selected from the step size set as the timestamp step size of the data packet Among the timestamps to be verified, there is a timestamp with correct verification.
  • the method further includes: in the process of decompressing the received data packet, determining the set of step sizes according to the time stamp difference of adjacent data packets that are decompressed correctly.
  • the determining of the step size set according to the time stamp difference of the adjacent data packets that are decompressed correctly includes: the data packets that have been decompressed correctly before the current data packet , The difference between the timestamps of the data packets in the adjacent call period is taken as the step of the call period, and the step of the quiet period is equal to the step of the call period*8; the decompressed correct silence occurs before the current data packet During the period data packet, the difference between the time stamps of the data packets in the adjacent quiet period is used as the quiet period step, and the talk period step is equal to the quiet period step/8.
  • the determining whether the packet header decompression failure occurs during a conversation period and a silent period conversion process includes: according to the packet type of the current data packet and the packet of the last correctly decompressed data packet Type to determine whether the failure to decompress the packet header occurs during the conversion between the talk period and the silent period.
  • the packet type of the current data packet and the packet type of the last correctly decompressed data packet it is determined whether the failure to decompress the packet header occurs during the conversion between the talk period and the silent period, It includes: when the packet type of the current data packet is different from the packet type of the last correctly decompressed data packet, it is determined that the decompression failure of the packet header occurs during the conversion period of the talk period and the silent period; the packet type and the current data packet When the packet type of the last correctly decompressed data packet is the same, according to the number of lost packets of the voice data packet and the silent data packet, it is determined whether the failure to decompress the packet header occurs during the conversion between the conversation period and the silent period.
  • the determining whether the packet header decompression failure occurs during a conversation period and a silent period conversion process according to the number of lost voice data packets and silent data packets includes: according to the packet sequence number The difference and the reception time interval determine the number of packet loss of the voice data packet and the number of packet loss of the silent data packet, and the reception time interval is the current data packet and the last correctly decompressed data Time interval between packets; when any one of the following conditions is met, it is determined that the failure to decompress the packet header occurs during the conversion between the talk period and the silent period: the number of lost voice packets and the loss of silent packets The number of packets is not equal to 0; or, the number of lost packets of the voice data packet is equal to 0, the number of lost packets of the silent data packet is not equal to 0, and the current data packet is a voice data packet; or, The number of lost packets of the voice data packet is not equal to 0, the number of lost packets of the silent data packet is equal to 0, and the current data packet is a voice data packet; or
  • the method further includes: determining a packet type of the current data packet according to a payload length of the current data packet; and determining a payload length according to the last correctly decompressed data packet The packet type of the last correctly decompressed data packet.
  • an embodiment of the present application provides a device for decompressing a data packet.
  • the device for decompressing a data packet has a function of implementing the above method.
  • the function can be realized by hardware, or can also be realized by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • the structure of the above-mentioned data packet decompression device includes a processor and a transceiver, and the processor is configured to process the data packet decompression device to perform the corresponding function in the above method.
  • the transceiver is used to realize the communication between the above-mentioned decompressing device of the data packet and the compression end.
  • the device for decompressing the data packet may further include a memory for coupling with the processor, which stores program instructions and data necessary for the device for decompressing the data packet.
  • an embodiment of the present application provides a communication apparatus, including: a receiving module and a processing module; the processing module is configured to determine when the header of the current data packet received through the receiving module fails to decompress Whether the packet header decompression failure occurs during the conversation period and the silent period conversion process; the processing module is also used for the packet header decompression failure occurring during the conversation period and the silent period conversion process, according to the packet sequence number difference, data
  • the timestamp step of the packet and the timestamp of the last correctly decompressed data packet obtain multiple timestamps to be checked, and the difference between the packet sequence number is the packet sequence number after decoding the current data packet and the latest The difference of the packet sequence numbers of a correctly decompressed data packet; the processing module is also used to use the multiple time stamps to be checked to make the CRC of the current packet header correct
  • the timestamp updates the context, which is used to decompress subsequent received data packets.
  • the processing module is configured to perform CRC using the multiple time stamps to be checked and other field information of the header of the current data packet to determine whether there is a correct time stamp ;
  • the timestamp step coefficient is determined according to the correct timestamp, and the context is updated using the correct timestamp and the timestamp step coefficient.
  • the processing module is also used to decompress subsequent received data packets using multiple updated contexts when there are multiple valid timestamps, which will be continuously k times
  • the updated context after successful decompression is used as a context for decompressing subsequently received data packets; wherein, the multiple updated contexts are respectively determined according to multiple check-correct time stamps, k Take an integer greater than 1.
  • the multiple time stamps to be checked include: ⁇ Pre-Timestamp+Ts_stride*delta_sn, Pre-Timestamp+Ts_stride*(delta_sn+1), ..., Pre-Timestamp+Ts_stride*delta_sn*8 ⁇
  • the former Timestamp represents the timestamp of the last correctly decompressed data packet
  • Ts_stride represents the timestamp step size of the data packet
  • delta_sn represents the difference between the sequence numbers of the packets.
  • the processing module is further configured to: select a timestamp step from the step set as the data packet, the step set includes a call period step, a silent period step and One or more of zero; perform the step of obtaining multiple timestamps to be verified based on the packet sequence number difference, the timestamp step of the data packet, and the timestamp of the last correctly decompressed data packet; When it is determined that there is no correct timestamp among the plurality of timestamps to be verified, a different step size value is selected from the step size set as the timestamp step size of the data packet until acquisition Among the multiple timestamps to be verified, there is a timestamp with correct verification.
  • the processing module is further configured to: during the decompressing of the received data packet, determine the step size set according to the time stamp difference value of the adjacent data packets that are decompressed correctly.
  • the processing module is used to: when the decompressed correct session data packet has appeared before the current data packet, use the difference of the timestamps of adjacent session data packets as the call Period step, the silent period step is equal to the conversation period step *8; when there is a decompressed correct silent period packet before the current data packet, the difference between the time stamps of the adjacent silent period packets is taken as In the silent period step, the conversation period step is equal to the silent period step/8.
  • the processing module is used to determine whether the failure to decompress the header of the packet occurs during the call period according to the packet type of the current data packet and the packet type of the last correctly decompressed data packet Silent period conversion process.
  • the processing module is configured to: when the packet type of the current data packet is different from the packet type of the last correctly decompressed data packet, determine that the decompression failure of the packet header occurs during the call period and Silent period conversion process; when the packet type of the current data packet is the same as the packet type of the last correctly decompressed data packet, determine whether the packet header decompression fails according to the number of lost voice packets and silent packets Occurs during the conversion between talk and silent periods.
  • the processing module is configured to determine the number of packet loss of the voice data packet and the number of packet loss of the silent data packet according to the difference between the packet sequence number and the receiving time interval,
  • the receiving time interval is a time interval between the current data packet and the last correctly decompressed data packet; when any one of the following conditions is met, it is determined that the decompression failure of the packet header occurs during a talk period and a silent period Conversion process: the number of packet loss of the voice data packet and the number of packet loss of the silent data packet are not equal to 0; or, the number of packet loss of the voice data packet is equal to 0, the number of packet loss of the silent data packet The number of lost packets is not equal to 0, and the current data packet is a voice data packet; or, the number of lost packets of the voice data packet is not equal to 0, and the number of lost packets of the silent data packet is equal to 0, and the The current data packet is a silent data packet.
  • the processing module is further configured to: determine the packet type of the current data packet according to the payload length of the current data packet; and according to the payload of the last correctly decompressed data packet The length determines the packet type of the last correctly decompressed data packet.
  • an embodiment of the present application provides a communication device, including: a processor, configured to execute the method described in the first aspect or any possible design of the first aspect.
  • the communication device may further include a memory for storing instructions or data, and the processor may call the instructions or data to perform the method described in the first aspect or any possible design of the first aspect.
  • the communication device may be a terminal device, an access network device, a chip in the terminal device, or a chip in the access network device.
  • an embodiment of the present application provides a computer-readable storage medium on which instructions are stored, and when the instructions are executed, the method of the above aspect is executed.
  • an embodiment of the present application provides a computer program product containing instructions, which when run on a computer, causes the computer to execute the method described in the above aspect.
  • the present application provides a chip system including a processor for supporting the above-mentioned data packet decompression device or terminal device to implement the functions involved in the above aspects, for example, generating or processing the above method The information involved.
  • the chip system further includes a memory, and the memory is used to store necessary program instructions and data of the decompression device of the data packet or the terminal device.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • the decompression of the header of the current data packet fails, it is determined whether the failure of decompressing the header occurs during the conversion between the conversation period and the silent period.
  • the failure to decompress the header occurs during the conversation
  • multiple timestamps to be checked are obtained based on the difference between the sequence number of the message, the timestamp step of the data packet, and the timestamp of the most recently decompressed data packet, and multiple timestamps to be checked are used.
  • the correct timestamp of the CRC in the context updates the context, thereby reducing the failure of decompression caused by the loss of critical data packets or the compatibility of compression encoding methods, thereby avoiding continuous or repeated packet loss caused by the failure of decompression, and ensuring voice quality .
  • FIG. 1 is a schematic diagram of a system architecture according to an embodiment of the present application
  • FIG. 2A is a schematic diagram of the basic principle of RoHC compression according to an embodiment of the present application.
  • 2B is a schematic diagram of the fields included in the header of the data packet according to an embodiment of the present application.
  • 2C is a schematic diagram of the state change of the compression end according to an embodiment of the present application.
  • 2D is a schematic diagram of the state change of the compression end according to an embodiment of the present application.
  • FIG. 2E is a schematic diagram of the change of the packet header during the conversion of different compression and decompression states according to an embodiment of the present application
  • FIG. 3 is a schematic diagram of an application scenario according to an embodiment of the present application.
  • FIG. 4 is a flowchart of a method for decompressing a data packet according to an embodiment of the present application
  • FIG. 5 is a flowchart of another method for decompressing a data packet according to an embodiment of the present application.
  • FIG. 6 is a flowchart of another method for decompressing a data packet according to an embodiment of the present application.
  • FIG. 7A is a schematic structural diagram of an apparatus for decompressing a data packet according to an embodiment of the present application.
  • FIG. 7B is a schematic structural diagram of another apparatus for decompressing a data packet according to an embodiment of the present application.
  • references to “plurality” herein refers to two or more.
  • “And/or” describes the relationship of the related objects, indicating that there can be three relationships, for example, A and/or B, which can indicate: there are three conditions: A exists alone, A and B exist at the same time, and B exists alone.
  • the character “/” generally indicates that the related object is a "or" relationship.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal frequency division multiple access
  • SC-FDMA single carrier frequency division multiple access
  • CDMA systems can implement wireless technologies such as universal wireless terrestrial access (UTRA), CDMA2000, and so on.
  • UTRA may include wideband CDMA (Wideband CDMA, WCDMA) technology and other CDMA variant technologies.
  • CDMA2000 can cover the interim standard (IS) 2000 (IS-2000), IS-95 and IS-856 standards.
  • the TDMA system can implement wireless technologies such as the global system for mobile (GSM).
  • OFDMA system can realize such as evolved universal wireless terrestrial access (evolved UTRA, E-UTRA), ultra mobile broadband (ultra mobile broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash OFDMA And other wireless technologies.
  • UTRA and E-UTRA are UMTS and UMTS evolved versions.
  • 3GPP's long-term evolution (LTE) and various versions based on LTE evolution are new versions of UMTS that use E-UTRA.
  • the fifth generation (5Generation, 5G) communication system and New Radio (NR) are the next generation communication systems under study.
  • the communication system may also be applicable to future-oriented communication technologies, and all the technical solutions provided by the embodiments of the present application are applicable.
  • Terminal equipment also known as user equipment (User Equipment (UE), mobile terminal (Mobile Terminal, MT), mobile user equipment, etc.
  • UE User Equipment
  • MT Mobile Terminal
  • RAN Radio Access Network
  • the user equipment may be a mobile terminal, such as a mobile phone (or referred to as a "cellular" phone) and a mobile-capable computer, for example, it may be a portable, pocket-sized, handheld, built-in computer, or vehicle-mounted mobile device. It can also be a communication device in machine type communication MTC.
  • the access network device may be a device deployed in a wireless access network to provide wireless communication functions for terminal devices.
  • the access network device may include various forms of macro base stations, micro base stations (also called small stations), relay stations, access points, etc., and may also include various forms of control nodes, such as network controllers.
  • the control node may connect multiple base stations and configure resources for multiple terminal devices covered by the multiple base stations.
  • the names of devices with base station functions may be different, such as eNB or e-NodeB in LTE, or it may be a base station or a transmitting and receiving endpoint in 5G or NR, such as gNB, this embodiment of the present application is not limited thereto.
  • FIG. 1 is a schematic diagram of a system architecture according to an embodiment of the present application. As shown in FIG. 1, the system architecture of this embodiment may include a compression terminal 1 and a decompression terminal 2.
  • the compression terminal 1 may be any terminal device described above, and the decompression terminal 2 may be any access network device described above.
  • the compression terminal 1 may be any of the foregoing access network devices, and the decompression terminal 2 may be any of the foregoing terminal devices.
  • the compression terminal 1 and the decompression terminal 2 of the embodiment of the present application adopt the RoHC technology to improve the air interface transmission efficiency, save the air interface resources, and improve the cell edge coverage and capacity.
  • the RoHC compressor (RoHC Compressor) at the compression end compresses the packet header, which can be an IP field + TCP field, an IP field + UDP field, an IP field + UDP field + RTP field, where the IP field can be an IPv4 field Or IPv6 field.
  • 2A is a schematic diagram of the basic principle of RoHC compression according to an embodiment of the present application. As shown in FIG. 2A, the header of the compression end is an IPv4 field or an IPv6 field (that is, IPv4/6 as shown in FIG. 2A) + UDP field + RTP field. Compressor, the header can be compressed into a header with a smaller number of bytes.
  • the header of the 40-byte IPv4 field + UDP field + RTP field can be compressed to 1 byte, compression efficiency Up to more than 90%.
  • the compression efficiency of different fields can be seen in Table 1.
  • the decompression end decompresses it through the RoHC decompressor (RoHC Compressor) to recover the original header of the data packet, that is, the IPv4 field or the IPv6 field as shown in FIG. 2A (that is, as shown in FIG. 2A IPv4/6)+UDP field+RTP field.
  • RoHC Compressor RoHC Compressor
  • the IPv4 field may include a version number field, a source address field, a destination address field, etc., to carry corresponding information.
  • the reason why the RoHC compressor can achieve header compression is because there is meaningful redundancy in consecutive packet headers of the same data stream.
  • the unchanged fields (such as the diagonal field) in consecutive headers in the same voice data stream account for 62%
  • the fields deducible from other fields account for 13%
  • the changing fields accounts for 25%.
  • the information carried in the IP-ID field, SN field, and timestamp field in the change field also changes regularly. For example, the RTP SN of adjacent voice data packets increases by 1 in sequence, and the IP-ID increases by 1 in sequence.
  • the information carried in the above unchanged field may be called static domain information, and the information carried in the above-mentioned derivable field and the changed field is called dynamic domain information.
  • IR Initialization and Refresh
  • First-order compression (First Order, FO) state
  • the dynamic domain of the compression end is unstable, and the compression end sends data packets (such as UO-1* (6 bytes), R-1* (6 bytes), UOR-2 * (13 bytes), IR-Dyn packet (20 bytes)), carrying the changed dynamic domain information to the decompression end to update the context.
  • data packets such as UO-1* (6 bytes), R-1* (6 bytes), UOR-2 * (13 bytes), IR-Dyn packet (20 bytes)
  • Second-level compression (SecondOrder, SO) state
  • the dynamic domain of the compression end changes steadily, the compression end sends data packets (such as UO-0 (1 byte), R-0 (1 byte)), and carries the least SN compression
  • the information is given to the decompressor to recover the entire data packet.
  • FIG. 2C is a schematic diagram of the state change of the compression end according to an embodiment of the present application. As shown in FIG. 2C, the compression end is initially in the IR state, and gradually moves to the FO state and the SO state. Will move back to the low-level compression state. The efficient and reliable compression is realized through the conversion of the compression state.
  • NC No Context
  • the static context on the decompression side has been established, but the dynamic context is not established or not synchronized with the compression side.
  • the decompression side needs to receive UOR-2*, IR dynamic (IR-Dyn) packets.
  • FC Full Context
  • FIG. 2D is a schematic diagram of the state change of the compression end according to an embodiment of the present application.
  • the decompression end is initially in the NC state, and after the decompression static context and the dynamic context are established; Go to the FC state; in the FC state, if n packets solve the error k1 packets, then fall back to the SC state; in the SC state, once a pair of packets is solved, it can immediately transition to the FC state; in the SC state, if n packets are unpacked If the wrong k2 packets are returned to the NC state.
  • the correct decompression is achieved through the conversion of the decompression state, k1 and k2 are integers.
  • FIG. 2E is a schematic diagram of the change of the packet header during the conversion of different compression and decompression states according to an embodiment of the present application.
  • the left side is the compression end, and the right side is the decompression end.
  • the compression end initially sends a complete static domain Packets of information and dynamic domain information (may be called compressed packets), that is, the first packet from top to bottom in the figure, the first packet carries static domain information and dynamic domain information, and is received by the decompression end
  • the decompressing terminal confirms that the decompressing terminal decompresses correctly, and establishes the context, then feeds back the decompressing success to the compression terminal (as shown in Figure 2E ACK), the compression terminal sends The second data packet and the third data packet can no longer carry static domain information.
  • the compressed dynamic domain information can be carried, which is the second data packet in the figure; if the dynamic domain If the field changes irregularly, then carry the complete dynamic domain information, that is, the third data packet in the figure.
  • the compressed message carries a CRC check bit. If the CRC check is correct at the decompression end, it indicates that the decompression is successful (ACK shown in FIG. 2E), otherwise the decompression fails (NACK shown in FIG. 2E).
  • the compressed data packet types can include: type 0 packets (1 byte), type 1 packets (2 to 11 bytes), type 2 packets (3 to 13 bytes), IR-dyn packets (21 bytes), IR packet (42 bytes).
  • the Type 0 packet carries the W-LSB encoded message sequence number (sn), for example, the above UO-0 (1 byte), R-0 (1 byte).
  • Type 1 packets carry the W-LSB encoded message sequence number (sn), the time stamp based on the step size encoding (TS_scaled) and the W-LSB encoded time stamp (Timestamp), for example, UO-1 above *(6 bytes), R-1*(6 bytes).
  • the Type 2 packet carries the W-LSB encoded message sequence number (sn), the timestamp based on the step size encoding (TS_scaled) and the W-LSB encoded timestamp (Timestamp), for example, UOR-2 above * (13 bytes), IR-Dyn packet (20 bytes). Among them, the compression efficiency of type 2 packets is lower than that of type 1 packets.
  • FIG. 3 is a schematic diagram of an application scenario according to an embodiment of the present application.
  • the compression end can be in the SO state during the call period, send a type 0 packet to the decompression end, only carry the message
  • the compression code and CRC check bit of the serial number (sn) do not carry the encoded value of the time stamp step size (Ts_stride).
  • the decompression end can restore the time stamp of the data packet ( Timestamp). During the conversion between the talk period and the silent period, the increase in the timestamp (Timestamp) of adjacent data packets will jump.
  • the interval between adjacent data packets can be 20ms ⁇ 160ms, with 8k sampling frequency as For example, the increment of the timestamp may be 160, 320, ..., 1120, or 1280.
  • the compression end retreats from the SO state to the FO state.
  • the compression end sends a type 1 packet, a type 2 packet, or an IR-dyn packet to the decompression end, to carry the compression encoding of the time stamp step size (Ts_stride) of the data packet.
  • Ts_stride time stamp step size
  • the timestamp information may include a timestamp (Timestamp) and a timestamp step size (Ts_stride), which in turn causes the subsequent decompression of Type 0 packets that enter the talk or silence period, resulting in packet loss and deterioration of voice quality.
  • the reasons for the loss of the data packet carrying the time stamp step size (Ts_stride) at the decompression end may include: 1) The data packet carrying the time stamp step size (Ts_stride) is lost due to air interface fluctuation and weak coverage. 2) When the silent period and the conversation period are converted, the compression end and the decompression end do not match the compression encoding processing method of the timestamp information of the data packet, for example, the compression end uses the step-based encoding method to perform the timestamp step (Ts_stride) After encoding, W-LSB encoding is performed, and the decompression end directly decompresses the timestamp information using adaptive variable-length encoding. Decompression failure due to compatibility issues results in the data packet carrying the timestamp step size (Ts_stride) Lost.
  • the decompressing terminal can use the message sequence number (SN) information, the interval characteristics of the data packet, and the cyclic redundancy check (Cyclic Redundancy Check, CRC) mechanism to perform the timestamp field. Repair, and then restore the correct context to correctly decompress the subsequent received data packets to avoid packet loss.
  • SN message sequence number
  • CRC Cyclic Redundancy Check
  • the execution subject of the method for decompressing a data packet may be a communication device or an internal chip of the communication device, and the communication device may be the compression terminal as described above.
  • the communication device may be For any of the foregoing terminal devices, for downlink transmission, the communication device may be any of the foregoing access network devices.
  • FIG. 4 is a flowchart of a data packet decompression method according to an embodiment of the present application. As shown in FIG. 4, the method in this embodiment may include:
  • Step 101 When the decompression of the header of the current data packet fails, determine whether the failure to decompress the header occurs during the conversion between the talk period and the silent period.
  • the compression end sends a data packet to the decompression end, the decompression end decompresses the data packet, and the decompression end determines whether the failure of the header decompression occurs during the call period and the silence period when the current packet header decompression fails The conversion process.
  • the data packets received by the compression end all refer to compressed packets, and the decompression end needs to decompress the received data packets.
  • Decompression includes decoding the field information included in the header of the data packet, splicing the decoded field information, and then performing a CRC check.
  • the cause of the decompression failure may be a decoding error of some field information in the packet header, for example, a timestamp (Timestamp) decoding error, and the timestamp (Timestamp) may be recovered through the following steps of the embodiment of the present invention.
  • the conversation period and silent period conversion processes involved in this article include the conversation period to silent period process (see FIG. 3), and/or the silent period to conversation period (see FIG. 3). Specifically, it may be during the conversion of the conversation period to the silent period, or during the conversion of the silent period to the conversation period.
  • the process of converting a conversation period into a silent period may include the previous packet being a conversation period data packet and the latter packet being a silence period data packet; the conversion of a silence period into a conversation period may include the previous packet being a silence period data packet and the latter packet It is a data packet during a call, which can be understood as the decompression of the header of the data packet at any circle shown in FIG. 3.
  • the process of converting the conversation period to the silent period may include after the conversation period is converted to the silent period, but continuous packet loss during the silent period.
  • the process of converting the silent period to the conversation period may include the conversion of the silent period to the conversation period, but continuous packet loss during the conversation period. It can be understood that the decompression of the header of the data packet after any circle shown in FIG. 3 fails. At this time, multiple data packets before the current data packet are lost, including data packets during the conversion between the talk period and the silent period.
  • the current data packet is the fourth data packet in the silent period, and the first data packet, the second data packet, and the third data packet in the silent period are lost; or, for example, the current data packet is the second The third data packet of a conversation period, at this time, the first data packet and the second data of the second conversation period are lost.
  • the data packet involved in this article may be a talk period data packet or a silent period data packet.
  • the current data includes a data packet during a conversation period or a data packet during a silence period.
  • Step 102 When the decompression of the packet header occurs during the conversion between the call period and the silent period, multiple multiples to be verified are obtained according to the difference between the sequence number of the packet, the time stamp step of the data packet, and the time stamp of the last correctly decompressed data packet Timestamp.
  • the difference between the message sequence numbers is the difference between the decoded message sequence number (SN) of the current data packet and the message sequence number (SN) of the most recently decompressed data packet.
  • the timestamp step of the data packet can be the timestamp step of the last correctly decompressed data packet, or it can be the timestamp step corresponding to the packet type of the current data packet, which can be the silent period step or the talk period
  • the specific explanation can refer to the description of the following embodiments.
  • the most recently decompressed data packet is the last data packet of the first talk period, as an example.
  • the decompression of the header of the current data packet fails, and the failure to decompress the header occurs during the conversion between the talk period and the silence period.
  • the difference between the sequence numbers of the two data packets (delta_sn) is equal to 1, that is, there is no packet loss in the middle, the talk period
  • the current data packet carries the compressed field of the timestamp.
  • the decompression of the header of the current data packet described above fails.
  • delta_sn the packet sequence number difference
  • (Ts_stride) 160)
  • the time stamp of the last correctly decompressed data packet to determine the timestamp carried by the current data packet that failed to decompress, for example, if the timestamp of the most recently decompressed data packet is expressed as the previous Timestamp, then the value range of the timestamp of the current data packet is: ⁇ Timestamp +160, before Timestamp+160*2, before Timestamp+160*3, before Timestamp+160*4, before Timestamp+160*5, before Timestamp+160*6, before Timestamp+160*7, before Timestamp+160* 8 ⁇ , the multiple numbers
  • delta_sn represents the packet sequence number difference
  • the delta_sn may be any integer greater than or equal to 1
  • Ts_stride represents the timestamp step size
  • the value range of the current data packet timestamp in this embodiment is: ⁇ pre-Timestamp+Ts_stride*delta_sn , Before Timestamp+Ts_stride*(delta_sn+1), ..., before Timestamp+Ts_stride*delta_sn*8 ⁇ .
  • the timestamp of the current data packet can be within the range of the timestamp used for the decompression failure.
  • CRC check is performed on timestamps other than the stamp.
  • Step 103 Use the multiple timestamps to be checked to update the context with the timestamp that makes the header CRC of the current data packet correct, and the context is used to decompress the subsequently received data packet.
  • the CRC check of the timestamp to be checked described in this article refers to: performing CRC together with the timestamp to be checked and other field information of the packet header. If the CRC is correct, the timestamp and the header of the check are correct.
  • the original header of the current data packet can be obtained by splicing other field information.
  • the other field information of the packet header may include information such as version number, source address, and target address.
  • the CRC check bit carried in the current data packet is 3bit, and the probability of 3bit false check is 1/8.
  • the correct timestamps are calculated to obtain the updated context, and each updated context is used to decompress the subsequently received data packet to select the updated context that can be successfully decompressed multiple times in succession as the The context for decompressing the subsequently received data packets.
  • the decompression of the header of the current data packet fails, it is determined whether the failure of the decompression of the header occurs during the conversion process of the conversation period and the silent period.
  • the failure of the decompression of the header occurs during the conversion process of the conversation period and the silent period, according to the message
  • the sequence number difference, the timestamp step of the data packet, and the timestamp of the most recently decompressed data packet acquire multiple timestamps to be verified, and update the context using the timestamps with the correct CRC among the multiple timestamps to be verified, thereby Reduce the failure of decompression caused by the loss of key data packets or the compatibility of compression encoding methods, and then avoid continuous or repeated packet loss caused by the failure of decompression to ensure voice quality.
  • the loss of key data packets causes the terminal equipment to exit RoHC, causing voice interruption and packet loss, and after exiting RoHC, each voice packet for upstream scheduling suddenly abruptly from the original 45 bytes
  • the expansion is 100 bytes, and the occurrence of voice fragmentation and jitter packet loss makes full use of RoHC to improve remote coverage.
  • the decompression end can also determine the timestamp step size coefficient (Ts_scaled) according to the correct timestamp of the CRC, and use the correct timestamp and timestamp step size coefficient (Ts_scaled) of the CRC to update the corresponding element in the context .
  • the calculation method of the time stamp step size coefficient (Ts_scaled) may be a quotient obtained by dividing the correct time stamp of the CRC by the time stamp step size.
  • the timestamp offset (Ts_offset) can also be determined according to the correct timestamp of the CRC. The calculation method may be that the correct timestamp of the CRC is the remainder of the timestamp step.
  • the multiple timestamps to be checked include: ⁇ Pre-Timestamp+Ts_stride*delta_sn, Pre-Timestamp+Ts_stride*(delta_sn+1),..., Pre-Timestamp+Ts_stride*delta_sn*8 ⁇ .
  • the former Timestamp represents the timestamp of the last correctly decompressed data packet
  • Ts_stride represents the timestamp step size of the data packet
  • delta_sn represents the difference between the sequence numbers of the packets.
  • the context may include static domain information and/or dynamic domain information as described above, that is, it may include a timestamp step size coefficient (Ts_scaled), a timestamp step size (Ts_stride), etc. as described above.
  • Ts_scaled a timestamp step size coefficient
  • Ts_stride a timestamp step size
  • FIG. 5 is a flowchart of another data packet decompression method according to an embodiment of the present application. As shown in FIG. 5, the method in this embodiment may include:
  • Step 201 The compression end sends a data packet to the decompression end.
  • the decompression end receives the data packet sent by the compression end.
  • the decompression end decompresses the header of the received data packet to obtain complete header information.
  • Step 202 The decompression end decompresses the current data packet.
  • the decompression end determines whether the failure to decompress the header occurs during the conversion between the talk period and the silent period. If yes, go to step 203.
  • the decompression end determines whether the packet header decompression failure occurs during the conversation period and the silence period. For a specific implementation manner, reference may be made to the explanation of the embodiment shown in FIG. 6 below, and details are not described here.
  • Step 203 When the failure to decompress the packet header occurs during the conversion between the talk period and the silent period, select a time stamp step size from the step size set as the data packet.
  • the step size set may include one or more of the talk period step size, the silent period step size, and zero.
  • the talk period step size can be 20ms* sampling rate
  • the quiet period step size can be 160ms* sampling rate, taking 8k sampling rate as an example
  • the talk period step size can be 20ms*8000/s
  • the quiet period step size can be It is 160ms*8000/s.
  • the step size set is a preset set of values, including the call period step size, the silent period step size and zero.
  • the initial state of the step set includes only 0.
  • the decompressed correct call period data has appeared before the current data packet
  • the difference between the timestamps of the data packets in the adjacent call period is taken as the step of the call period, and the step of the silent period is equal to the step of the call period *8;
  • the decompressed correct data appears before the current data packet
  • the difference between the time stamps of adjacent data packets in the quiet period is taken as the step in the quiet period, and the step in the talking period is equal to the step in the quiet period/8.
  • the decompression end may randomly select a step size from the set of step sizes as the time stamp step size of the data packet to perform the following steps 204 to 205 to determine the time stamp step size of the data packet. Whether there is a timestamp with correct CRC among the multiple timestamps to be checked, if not, the timestamp step of the data packet is updated through step 206, and the timestamp step of the updated data packet is used to execute The following steps 204 to 205 until a time stamp with correct verification is obtained.
  • the decompression end may first select the current timestamp step as the timestamp step of the data packet.
  • the current timestamp step is the silent period step to perform the following steps 204 to Step 205, determine whether the CRC correct timestamp exists among the multiple timestamps to be checked corresponding to the timestamp step of the data packet, if not, update the timestamp step of the data packet through step 206, and The updated timestamp step is used to perform the following steps 204 to 205 until a timestamp with correct verification is obtained.
  • Step 204 Acquire multiple time stamps to be checked according to the packet sequence number difference, the time stamp step of the data packet, and the time stamp of the last correctly decompressed data packet.
  • step 102 For a specific implementation manner of acquiring multiple time stamps to be verified, reference may be made to the explanation of step 102 in the embodiment shown in FIG. 4, and details are not described herein again.
  • Step 205 Determine whether a verified timestamp exists among the multiple timestamps to be verified, and if not, perform step 206. If yes, go to step 207.
  • Step 206 Select a different step value from the step set as the time stamp step of the data packet.
  • step 204 to step 205 are executed until there is a timestamp with correct verification among the acquired multiple timestamps to be verified.
  • Step 207 Use the multiple timestamps to be checked to update the context with the timestamp that makes the CRC of the header of the current data packet correct, and the context is used to decompress the subsequently received data packet.
  • step 207 For the explanation of step 207, reference may be made to the explanation of step 103 in the embodiment shown in FIG. 4, which will not be repeated here.
  • the decompression of the header of the current data packet fails, it is determined whether the failure of the decompression of the header occurs during the conversion process of the conversation period and the silent period.
  • the failure of the decompression of the header occurs during the conversion process of the conversation period and the silent period, according to the message Sequence number difference, multiple different timestamp steps and the timestamp of the most recently decompressed data packet Obtain multiple timestamps to be checked, and use multiple timestamps to be checked to make the current packet header CRC
  • the correct timestamp updates the context, thereby reducing the failure of decompression caused by the loss of critical data packets or the compatibility of compression encoding methods, thereby avoiding continuous or repeated packet loss caused by the failure of decompression and ensuring voice quality.
  • the loss of key data packets causes the terminal equipment to exit RoHC, causing voice interruption and packet loss, and after exiting RoHC, each voice packet for upstream scheduling suddenly abruptly from the original 45 bytes
  • the expansion is 100 bytes, and the occurrence of voice fragmentation and jitter packet loss makes full use of RoHC to improve remote coverage.
  • one possible way to determine whether the packet header decompression failure occurs during the conversation period and the silent period conversion process is: according to the packet type of the current data packet and the most recent decompressed The packet type of the data packet determines whether the failure to decompress the packet header occurs during the conversion between the talk period and the silent period.
  • FIG. 6 is a flowchart of another method for decompressing a data packet according to an embodiment of the present application.
  • a process of determining whether a packet header decompression failure occurs during a conversation period and a silence period is performed.
  • the method in this embodiment may include:
  • Step 301 Obtain the packet types of the current data packet and the last correctly decompressed data packet.
  • the packet type of the current data packet is determined according to the payload length of the current data packet, and the last correctly decompressed data packet is determined according to the payload length of the last correctly decompressed data packet
  • the packet type of the packet is determined according to the payload length of the last correctly decompressed data packet
  • the payload length of the data packet in the silent period is less than 8 bytes, and the payload length of the data packet in the conversation period is 14 to 180 bytes.
  • Step 302 Determine whether the current data packet and the last correctly decompressed data packet have the same packet type. If not, perform step 303, and if yes, perform step 304.
  • Step 303 When the packet type of the current data packet is different from the packet type of the last correctly decompressed data packet, it is determined that the decompression failure of the packet header occurs during the conversion between the talk period and the silent period.
  • the packet type of the current data packet is different from the packet type of the last correctly decompressed data packet, it can be determined that the decompression of the packet header occurs during the conversion between the talk period and the quiet period, for example, as shown in the first After a circle, or after the first circle and before the second circle.
  • Step 304 When the packet type of the current data packet is the same as the packet type of the last correctly decompressed data packet, determine whether the packet header decompression failure occurs according to the number of lost voice data packets and silent data packets The conversion process between the talk period and the silent period.
  • the packet type of the current data packet is the same as the packet type of the last correctly decompressed data packet, it can be determined that the number of lost packets is large. For example, the most recently decompressed data packet is the first The talk period data packet in one circle, the current data packet is the talk period data packet in the second circle. Specifically, it can be determined in the following manner whether the packet header decompression failure occurs during the conversation period and the silent period conversion process.
  • the number of lost packets of the voice data packet and the number of lost packets of the silent data packet can be determined according to the difference between the packet sequence number and the receiving time interval, the receiving time interval is the current data packet and the Describe the time interval between the most recently decompressed data packets.
  • the number of packet loss of the voice data packet and the number of packet loss of the silent data packet are not equal to 0
  • the number of lost packets of the voice data packet is equal to 0, the number of lost packets of the silent data packet is not equal to 0, and the current data packet is a voice data packet; or, the loss of the voice data packet
  • the number of packets is not equal to 0, the number of dropped packets of the silent data packet is equal to 0, and the current data packet is a silent data packet.
  • the packet type of the current data packet and the packet type of the last correctly decompressed data packet it is determined whether the failure to decompress the packet header occurs during the conversion period between the talk period and the silent period, and then when the packet header is decompressed The failure occurs during the conversion between the call period and the silent period. According to the difference between the sequence number of the message, multiple different timestamp steps and the timestamp of the last correctly decompressed data packet, multiple timestamps to be verified are obtained.
  • the loss of key data packets causes the terminal equipment to exit RoHC, causing voice interruption and packet loss, and after exiting RoHC, each voice packet for upstream scheduling suddenly abruptly from the original 45 bytes
  • the expansion is 100 bytes, and the occurrence of voice fragmentation and jitter packet loss makes full use of RoHC to improve remote coverage.
  • the decompression end can fall back from the FC state to the SC state, and send the non-compression end to the compression end. Confirm (Nack), so that the compression end sends UOR-2* packets or IR-Dyn packets to the decompression end. If the decompression end still cannot decompress the data packet correctly, the decompression end can return from the SC state to the NC state, and Send a static Nack to the compression end, so that the compression end sends IR packets to the decompression end.
  • the solutions of the method for decompressing the data packet provided by the embodiments of the present application are introduced from the perspective of the decompression terminal itself and the interaction between the decompression terminal and the compression terminal.
  • the decompression end and the compression end include hardware structures and/or software modules corresponding to performing each function.
  • the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed by hardware or computer software driven hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
  • the decompression device as the decompressed data packet may include a receiving module 701 and a processing module 702, as shown in FIG. 7A.
  • the device for decompressing the data packet may be used to perform the operation of the decompressing end in FIG. 3 described above.
  • the processing module 702 is configured to determine whether the failure to decompress the header of the current data packet occurs during the conversion between the talk period and the silent period when the decompression of the header of the current data packet received through the receiving module 701 fails;
  • the processing module 702 is also used for when the packet header decompression failure occurs during the conversion between the talk period and the quiet period, according to the difference between the sequence number of the message, the timestamp step of the data packet, and the latest correctly decompressed data packet.
  • the difference between the packet sequence numbers is the difference between the packet sequence number of the current data packet after decoding and the packet sequence number of the last correctly decompressed data packet;
  • the processing module 702 is further used to update the context by using the multiple timestamps to be checked so that the header cyclic redundancy check of the current data packet has a correct CRC timestamp, and the context is used for subsequent reception
  • the received data packets are decompressed.
  • the device for decompressing a data packet in the embodiment of the present application can reduce the decompression failure caused by the loss of key data packets or the compatibility problem of the compression encoding method, and thus avoid continuous packet loss or repeated loss caused by the failure of decompression. Package to ensure voice quality.
  • the processing module 702 is configured to perform CRC using the multiple time stamps to be verified and other field information of the header of the current data packet to determine whether there is a time stamp with correct verification;
  • the timestamp step size coefficient is determined according to the correct timestamp, and the context is updated using the correct timestamp and the timestamp step size coefficient.
  • the processing module 702 is also used to decompress subsequent received data packets using multiple updated contexts when there are multiple timestamps with correct verification, and will decompress continuously for k consecutive times
  • the updated context is used as the context for decompressing subsequently received data packets; where the multiple updated contexts are respectively determined according to multiple verified timestamps, and k is greater than 1. Integer.
  • the multiple timestamps to be checked include: ⁇ Pre-Timestamp+Ts_stride*delta_sn, Pre-Timestamp+Ts_stride*(delta_sn+1), ..., Pre-Timestamp+Ts_stride*delta_sn*8 ⁇ ; where, before Timestamp represents the timestamp of the last correctly decompressed data packet, Ts_stride represents the timestamp step size of the data packet, and delta_sn represents the difference between the sequence numbers of the packets.
  • the processing module 702 is further configured to: select a time stamp step size of the data packet from a step size set, where the step size set includes a call period step size, a silent period step size, and zero-one Item or multiple items; perform the step of obtaining multiple timestamps to be checked based on the packet sequence number difference, the timestamp step of the data packet, and the timestamp of the last correctly decompressed data packet; When there is no correct timestamp among the multiple timestamps to be verified, a different step size value is selected from the step size set as the timestamp step size of the data packet, until the obtained multiple Among the timestamps to be verified, there is a timestamp with correct verification.
  • the processing module 702 is further configured to: during decompressing the received data packet, determine the step size set according to the time stamp difference of adjacent data packets that are decompressed correctly.
  • the processing module 702 is configured to: when the decompressed correct session data packet has appeared before the current data packet, use the time stamp difference of adjacent data packets as the session duration step ,
  • the quiet period step is equal to the talk period step *8; when a decompressed correct quiet period data packet has appeared before the current data packet, the difference between the time stamps of adjacent quiet period data packets is used as the quiet period Period step, the talk period step is equal to the silent period step/8.
  • the processing module 702 is configured to determine, according to the packet type of the current data packet and the packet type of the last correctly decompressed data packet, whether the failure to decompress the packet header occurs during the conversation period and the silent period conversion process.
  • the processing module 702 is configured to: when the packet type of the current data packet is different from the packet type of the last correctly decompressed data packet, determine that the failure to decompress the packet header occurs during the conversation period and the silent period conversion Process; when the packet type of the current data packet is the same as the packet type of the last correctly decompressed data packet, determine whether the packet header decompression failure occurred during a call based on the number of lost voice data packets and silent data packets The conversion process between the period and the silent period.
  • the processing module 702 is configured to determine the number of lost packets of the voice data packet and the number of lost packets of the silent data packet according to the difference between the packet sequence number and the receiving time interval, the receiving The time interval is the time interval between the current data packet and the last correctly decompressed data packet; when any one of the following conditions is met, it is determined that the failure to decompress the packet header occurs during the conversion between the talk period and the silent period:
  • the number of packet loss of the voice data packet and the number of packet loss of the silent data packet are not equal to 0; or, the number of packet loss of the voice data packet is equal to 0, the number of packet loss of the silent data packet
  • the number is not equal to 0, and the current data packet is a voice data packet; or, the number of dropped packets of the voice data packet is not equal to 0, the number of dropped packets of the silent data packet is equal to 0, and the current data
  • the packet is a silent data packet.
  • the processing module 702 is further configured to: determine the packet type of the current data packet according to the payload length of the current data packet; determine the payload length according to the payload length of the last correctly decompressed data packet Describe the packet type of the most recently decompressed data packet.
  • the device for decompressing the data packet may further include a sending module 703, configured to feed back to the compression end the non-acknowledgement (Nack) or acknowledgement (Ack) as described in the above embodiment.
  • a sending module 703 configured to feed back to the compression end the non-acknowledgement (Nack) or acknowledgement (Ack) as described in the above embodiment.
  • the receiving module 701, the processing module 702, and the sending module 703 in the decompressing device based on the data packet can also implement other operations or functions of the decompressing end in the above method, which will not be repeated here.
  • FIG. 7B shows another possible structural diagram of the apparatus for decompressing a data packet involved in the foregoing embodiment.
  • the device for decompressing the data packet may also be referred to as a communication device.
  • the communication device may include a processing unit 705, and the processor may execute the technical solution of any of the foregoing embodiments.
  • the communication device may further include a storage unit 706, which is coupled to the processing unit 705.
  • the storage unit 706 is used to store instructions, which are used by the processing unit 705 to read and execute any of the above-mentioned implementations Example of the decompression method of data packets.
  • the processing unit 705 is configured to decompress other operations or functions of the end.
  • the communication device may further include a transceiver unit 704 for implementing communication between the decompression device of the data packet and the compression terminal.
  • the processing unit 705 may include one or more processors; optionally, the storage unit 706 may include one or more memories.
  • the communication device may be a terminal, an access network device, a chip in the terminal, or a chip in the access network device.
  • the transceiver unit 704 may include Input or output interface, pin or circuit, etc.; when the communication device is a terminal or an access network device, the transceiver unit 704 may include an antenna and a transceiver.
  • the controller/processor used to perform the above-mentioned data packet decompression method of the present application may be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), and a field programmable gate Array (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It can implement or execute various exemplary logical blocks, modules, and circuits described in conjunction with the disclosure of the present application.
  • the processor may also be a combination of computing functions, for example, including one or more microprocessor combinations, a combination of DSP and microprocessor, and so on.
  • the steps of the method or algorithm described in conjunction with the disclosure of the present application may be implemented by hardware, or by a processor executing software instructions.
  • the software instructions can be composed of corresponding software modules, which can be stored in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, mobile hard disk, CD-ROM or any other form of storage known in the art Medium.
  • An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and can write information to the storage medium.
  • the storage medium may also be a component of the processor.
  • the processor and the storage medium may be located in the ASIC.
  • the ASIC can be located in any node of the video surveillance network.
  • the processor and the storage medium can also exist as discrete components in any node of the video surveillance network.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general-purpose computer, a dedicated computer, a computer network, or other programmable devices.
  • the computer instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be from a website site, computer, server or data center Transmit to another website, computer, server or data center via wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.).
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device including a server, a data center, and the like integrated with one or more available media.
  • the usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, Solid State Disk (SSD)) or the like.
  • a magnetic medium for example, a floppy disk, a hard disk, a magnetic tape
  • an optical medium for example, a DVD
  • a semiconductor medium for example, Solid State Disk (SSD)

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Des modes de réalisation de la présente invention concernent un procédé et un dispositif de décompression de paquets de données. Le procédé consiste : lorsqu'une décompression d'en-tête d'un paquet de données actuelles échoue, à déterminer si la décompression d'en-tête échoue lors d'une période d'appel et d'un processus de commutation de période silencieuse ; si la décompression d'en-tête échoue lors de la période d'appel et du processus de commutation de période silencieuse, à acquérir, selon une différence de nombres de séquences de paquets, une taille d'étape d'horodatage d'un contexte de décompression de paquets de données et un horodatage du dernier paquet de données correctement décompressé, de multiples horodatages à vérifier ; et à mettre à jour le contexte à l'aide d'un horodatage ayant passé un CRC parmi les multiples horodatages. Le mode de réalisation de la présente invention réduit les échecs de décompression résultant de la perte d'un paquet de données critiques ou d'un procédé de compression et de codage incompatibles, ce qui permet d'éviter une perte continue de paquets ou une perte répétée de paquets provoquée par des défaillances de décompression et d'assurer une bonne qualité vocale.
PCT/CN2019/124546 2018-12-14 2019-12-11 Procédé et dispositif de décompression de paquets de données WO2020119718A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811535588.5 2018-12-14
CN201811535588.5A CN111328104B (zh) 2018-12-14 2018-12-14 数据包的解压缩方法和装置

Publications (1)

Publication Number Publication Date
WO2020119718A1 true WO2020119718A1 (fr) 2020-06-18

Family

ID=71075851

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/124546 WO2020119718A1 (fr) 2018-12-14 2019-12-11 Procédé et dispositif de décompression de paquets de données

Country Status (2)

Country Link
CN (1) CN111328104B (fr)
WO (1) WO2020119718A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111954248B (zh) * 2020-07-03 2021-10-01 京信网络系统股份有限公司 一种音频数据报文处理方法、装置、设备及存储介质
CN112333047B (zh) * 2020-11-16 2022-04-26 展讯通信(上海)有限公司 数据传输方法、装置及设备
CN114499750A (zh) * 2021-11-30 2022-05-13 华为技术有限公司 一种数据包的处理方法、通信装置及通信系统
CN114679300B (zh) * 2022-02-28 2023-10-13 福思(杭州)智能科技有限公司 一种数据校验方法、装置、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102571540A (zh) * 2010-12-20 2012-07-11 华为技术有限公司 一种解压的方法及装置
WO2016101453A1 (fr) * 2014-12-22 2016-06-30 中兴通讯股份有限公司 Procédé et dispositif de compression d'horodateur
US10037240B2 (en) * 2015-09-24 2018-07-31 Qualcomm Incorporated Timestamp repair mechanism in case of decompression failure
CN108574684A (zh) * 2017-03-14 2018-09-25 大唐移动通信设备有限公司 一种解压缩的方法和装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108737349B (zh) * 2017-04-24 2020-08-28 大唐移动通信设备有限公司 一种语音数据包的处理方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102571540A (zh) * 2010-12-20 2012-07-11 华为技术有限公司 一种解压的方法及装置
WO2016101453A1 (fr) * 2014-12-22 2016-06-30 中兴通讯股份有限公司 Procédé et dispositif de compression d'horodateur
US10037240B2 (en) * 2015-09-24 2018-07-31 Qualcomm Incorporated Timestamp repair mechanism in case of decompression failure
CN108574684A (zh) * 2017-03-14 2018-09-25 大唐移动通信设备有限公司 一种解压缩的方法和装置

Also Published As

Publication number Publication date
CN111328104B (zh) 2022-03-04
CN111328104A (zh) 2020-06-23

Similar Documents

Publication Publication Date Title
WO2020119718A1 (fr) Procédé et dispositif de décompression de paquets de données
TWI693843B (zh) 上行資料壓縮方法及其發送設備
US10194349B2 (en) Header compression optimization method during and after handovers in cellular communication network
US20210176662A1 (en) Data transmission method and related apparatus
US11956667B2 (en) Communication method and device
WO2022111317A1 (fr) Procédé et appareil de transmission de données, dispositif et support de stockage
WO2022143684A1 (fr) Procédé et appareil de traitement de données
WO2022111365A1 (fr) Procédé et appareil de transmission de données, dispositif, support de stockage et produit-programme
CN111355564B (zh) 处理压缩错误的方法和装置
US20230216611A1 (en) Packet loss indication method and related device
WO2022237279A1 (fr) Procédé et appareil de transmission de données
CN109756306B (zh) 信息传输方法和通信设备
US20240080729A1 (en) Communication Method and Apparatus
WO2023102938A1 (fr) Procédé de communication sans fil et dispositif de communication
JP5075100B2 (ja) 最大受信状態変数を設定する方法及び通信装置
US11483737B2 (en) RRC message transmission method and device
WO2021097686A1 (fr) Procédé de transmission de paquet ethernet compressé, et appareil
US9794930B1 (en) Method and apparatus for packet data unit processing for retransmission
US9843655B1 (en) Method and apparatus for packet data unit processing
CN110602745A (zh) 一种数据包解压方法及装置
CN112787980B (zh) 反馈的方法和设备
CN112333773B (zh) 通信处理方法、设备、装置及存储介质
WO2023016506A1 (fr) Procédé de transmission de données et appareil de communication
CN110875916A (zh) 一种语音数据的传输方法和网络设备

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

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

Country of ref document: EP

Kind code of ref document: A1