[go: up one dir, main page]

WO2001067715A1 - Pre-verification de sommes de controle utilisee par la compression d'en-tete basee sur une somme de controle - Google Patents

Pre-verification de sommes de controle utilisee par la compression d'en-tete basee sur une somme de controle Download PDF

Info

Publication number
WO2001067715A1
WO2001067715A1 PCT/SE2001/000468 SE0100468W WO0167715A1 WO 2001067715 A1 WO2001067715 A1 WO 2001067715A1 SE 0100468 W SE0100468 W SE 0100468W WO 0167715 A1 WO0167715 A1 WO 0167715A1
Authority
WO
WIPO (PCT)
Prior art keywords
checksum
header
packet
crc
reliability
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/SE2001/000468
Other languages
English (en)
Inventor
Krister Svanbro
Lars-Erik Jonsson
Hans Hannu
Nicklas Sandgren
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Priority to AU2001237877A priority Critical patent/AU2001237877A1/en
Publication of WO2001067715A1 publication Critical patent/WO2001067715A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/09—Error detection only, e.g. using cyclic redundancy check [CRC] codes or single parity bit
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/63—Joint error correction and other techniques
    • H03M13/6312—Error control coding in combination with data compression
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/65—Purpose and implementation aspects
    • H03M13/6522—Intended application, e.g. transmission or communication standard
    • H03M13/6547—TCP, UDP, IP and associated protocols, e.g. RTP
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • the invention relates generally to packet communications and, more particularly, to header compression in packet communications.
  • IP Internet Protocol
  • the objective is, of course, to use the Internet as a link for transporting voice and speech data.
  • Speech data has been transported across the Internet using IP-based protocols such as the User Datagram Protocol (UDP) and the Real-time Transport Protocol (RTP) .
  • UDP User Datagram Protocol
  • RTP Real-time Transport Protocol
  • a computer running telephony software converts speech into digital data which is then assembled into IP- based data packets that are suitable for transfer across the Internet.
  • a typical IP-based speech data packet 10 is shown in FIG. 1.
  • the packet 10 is one of a plurality of related packets that form a stream of packets 10 representing speech data being transferred over a packet-switched communication network such as the Internet.
  • the packet 10 is made of a header portion 12 and a payload portion 14.
  • the header 12 may include static information 16 such as the source and destination addresses of the packet 10, and dynamic information 18 such as the IP identification, RTP sequence number, and RTP time stamp.
  • FIG. 2 illustrates a pertinent portion of an exemplary packet-switched communication network 20.
  • a packet source 22 such as the Internet provides a stream of IP -based data packets 10 across a link 24 to an access technology 26 such as, for example, a base station.
  • the access technology 26 compresses the data packets 10 received from the packet source 20 and transmits the compressed packets across a link 28 to a receiver 30 such as, for example, a mobile cellular station.
  • the link 28 may be any radio interface between the access technology 26 and the receiver 30 such as, for example, a cellular link.
  • the receiver 30 receives the compressed packets from the access technology 26 and decompresses the packets, including reconstruction of the packet headers.
  • the header 12 may represent up to 70% of the data packet 10, leaving little capacity for the payload 14.
  • this inefficient use of bandwidth is much too expensive for IP -based transportation to become a viable alternative to circuit switched speech services. Therefore, some compression or reduction of the header 12 is generally required.
  • header compression refers to the art of minimizing the necessary bandwidth for information carried in packet headers on a per hop basis over point-to- point links.
  • the headers are compressed or otherwise reduced at the transmitting side and then reconstructed at the receiving side.
  • headers generally comprise both static information and dynamic information, that is, information that may change from one packet to the next. Header compression is usually realized by sending only the static information initially. Dynamic information is then transferred by sending only the change, or delta, from the previous packet. Completely random information is usually sent without compression.
  • compression efficiency relates to how much the headers are compressed and can generally be expressed by the average compressed header size.
  • Robustness relates to how well a compression scheme handles loss over a predefined link. For example, will a loss make the contexts inconsistent, possibly resulting in a large number of erroneously decompressed packet headers?
  • Reliability relates to how trustworthy a scheme is in terms of catching incorrectly decompressed packets. Any header compression scheme, in order to be feasible, must take at least these factors into account.
  • ROCCO Real-Time Checksum-based header Compression
  • CRC cyclical redundancy checking
  • a CRC is calculated over the full original IP/UDP/RTP header by the compressor and then included in the compressed header.
  • the compressed header (with the included CRC) is then sent to the decompressor where it is reconstructed.
  • a new CRC is calculated over the full reconstructed header. This new CRC is then compared with the included CRC to see if there is a match, which means the header reconstruction was performed correctly.
  • CRC calculation is well-known to those of ordinary skill in the art and will not be discussed here. Suffice it to say, however, the size of the CRC impacts the compression efficiency and reliability of the header compression scheme.
  • a CRC length of 10 bits is commonly used.
  • a short CRC provides higher compression efficiency, but lower reliability.
  • longer CRCs are generally favored in order to ensure strong reliability, often at the expense of compression efficiency. It is desirable, therefore, to be able to generate a CRC that provides high reliability without compromising compression efficiency.
  • the present invention advantageously provides a CRC that has high reliability, yet does not unnecessarily compromise compression efficiency.
  • a CRC is pre-verified at the compressor before it is sent to the decompressor. The pre-verification ensures that the CRC is of sufficient length to provide robustness and reliability, but is not unnecessarily lengthy.
  • the present invention is directed to a method or apparatus for pre-verifying checksums to ensure the checksums are reliable for header decompression purposes.
  • the checksums are preverified at the compressor side before being transmitted to the decompressor. Verification of the checksums includes testing against a number of packet loss scenarios to ensure reliable detection of errors.
  • pre-verification helps increase and/or maintain compression efficiency by keeping the length of the checksums from becoming unnecessarily long.
  • the invention is related to a method of verifying a checksum in a header compression protocol.
  • the method comprises the steps of calculating a checksum, based on a packet header, compressing the packet header in accordance with the header compression protocol, and testing the checksum, for reliability prior to including the checksum in the compressed packet header.
  • the invention is related to a system for verifying a checksum in a header compression protocol.
  • the system comprises a checksum calculator for calculating a checksum based on a packet header, a compressor for compressing the packet header in accordance with the header compression protocol, and a reliability processor for testing a reliability of the checksum prior to including the checksum in the compressed packet header.
  • FIGURE 1 illustrates a typical speech data packet.
  • FIGURE 2 illustrates a packet-switched communication environment
  • FIGURE 3 illustrates a general packet flow according to an embodiment of the present invention
  • FIGURE 4 illustrates a general flow of the checksum preverification process according to the embodiment of FIGURE 3;
  • FIGURE 5 illustrates a compressor apparatus according to the embodiment of FIGURE 3.
  • FIGURE 6 illustrates a decompressor apparatus according to the embodiment of FIGURE 3.
  • ROCCO calculates a CRC over the full original IP/UDP/RTP header at the compressor and then includes that CRC in the transmitted compressed header. Once the compressed header is reconstructed at the decompressor, a new CRC is calculated over the full reconstructed header. This new CRC is then compared to the included CRC to see if there is a match, which means the reconstructed header is correct. If the verification fails (i.e., the CRCs do not match), ROCCO provides for local repair of the reconstructed header by additional reconstruction attempts based on one or more assumptions about what may have happened during transmission of the packet.
  • Examples of events that may have occurred during the transmission include reordering of the packets, damaged packets, and lost packets, all of which may result in a packet loss from the decompressor's perspective.
  • the first additional reconstruction attempt assumes there was no packet loss.
  • Subsequent reconstruction attempts assume a single preceding packet was lost, then two preceding packets lost, and so on.
  • the decompressor alternately assumes a zero, one, or two packet loss, and so on, and calculates a new CRC based on the most probable context assuming the packet (s) were lost.
  • FIG. 3 illustrates the general packet flow according to one embodiment of the present invention.
  • header compression is performed in accordance with the ROCCO protocol.
  • a CRC is calculated over the full, original header at step 302.
  • the CRC is verified for reliability, a process which will be explained in more detail herein. If the CRC is reliable, step 306, the CRC is included with the packet and sent to the next destination, step 308. If the CRC is not reliable, than a different, reliable CRC is sent instead, or additional information such as extra header fields is sent with the packet at step 310.
  • the compressed header including the CRC is sent to the receiver via the link 28, it is reconstructed at step 320.
  • the type of CRC is determined, e.g., the standard CRC, or a modified version for CRCs that were not considered to be reliable.
  • the reconstructed header is verified by calculating a new CRC for the reconstructed header and comparing it against the included CRC. If verification is confirmed, step 326, the decompressed packet including the reconstructed header is forwarded to the intended application. If verification is not confirmed, i.e., the newly calculated CRC does not match the included CRC, the packet is discarded at step 328.
  • reliability relates to the trustworthiness of a compression scheme. To this end, the CRC should be of a sufficient length to be able to catch most or all erroneous header reconstructions.
  • the present invention considers two factors in calculating such a CRC: the order and assumptions made by the decompressor in its repair attempts, and the number of actual lost packets that can be tolerated, as specified at the receiver side.
  • the compressor of the present invention would calculate a CRC that meets the following
  • the calculated CRC is checked to see whether it can catch a 1 packet error if it is assumed that no packet loss occurred. In other words, if a true 1 packet error occurred during transmission and the decompressor began repair under the (wrong) assumption that there was no packet loss, generating a new CRC accordingly, would the calculated CRC catch (i.e., not match) the newly generated
  • step 412 If no, the compressor must recalculate the CRC at step 412, possibly resulting in a longer CRC with each recalculation. The check is repeated for up to a 3 packet error with an assumption of 2 packets loss, steps 402-410. If the CRC passes the last check, step 410, the process stops at step 414 and no more checks are performed according to this exemplary embodiment.
  • the present invention ensures the length of CRC will not be any longer than it needs to be for reliability purposes, thereby helping to at least maintain a high level of compression efficiency.
  • the CRC is then considered to be unreliable. In that case, the CRC may still be included in the packet (step 310 in FIG. 3) if additional information about the CRC is included.
  • FIG. 5 illustrates an embodiment of the present invention as implemented in the access technology 26.
  • the access technology 26 includes a packet compressor 50 for compressing a data packet such as the data packet 10 (shown in FIG. 1 ) , including the header therein.
  • a CRC calculator 52 calculates a CRC based on the original, uncompressed header of the received packet.
  • a reliability processor 54 then checks the calculated CRC for reliability in accordance with the flow diagram illustrated in FIG. 4. If the CRC is sufficiently reliable, it is included with the compressed header, and the compressed packet is then sent to the receiver 30 via the transmitter 56. If not, additional information may be sent as explained previously.
  • the receiver 30 includes a packet decompressor 60 for decompressing the compressed packet and reconstructing the header therein.
  • a CRC extractor 62 extracts the included CRC and determines whether it is a standard CRC or a modified one (such as in the case of an unreliable CRC).
  • a verification processor
  • the verification processor 64 calculates a new CRC based on the reconstructed header and then compares it to the included CRC. If there is a match, the header reconstruction process is considered to be correct, and the packet is sent to a codec 66 for further processing. If no match, then an error has occurred, and the verification processor 64 attempts to repair the error in accordance with the ROCCO protocol.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé et un appareil de pré-vérification de sommes de contrôle permettant et de garantir la fiabilité des sommes de contrôle aux fins de la décompression d'en-tête (300). Les sommes de contrôle sont pré-vérifiées (304) par le compresseur (50) avant d'être transmises (308) au décompresseur (60). La vérification (304) des sommes de contrôle comporte le test de scénarios empêchant la perte d'un certain nombre de paquets en vue de garantir une détection fiable d'erreurs. De plus, la pré-vérification (304) contribue à augmenter et/ou à conserver l'efficacité de compression en empêchant que les sommes de contrôle ne deviennent trop longues.
PCT/SE2001/000468 2000-03-07 2001-03-06 Pre-verification de sommes de controle utilisee par la compression d'en-tete basee sur une somme de controle Ceased WO2001067715A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001237877A AU2001237877A1 (en) 2000-03-07 2001-03-06 Pre-verification of checksums used with checksum-based header compression

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US18828500P 2000-03-07 2000-03-07
US60/188,285 2000-03-07
US67214900A 2000-09-26 2000-09-26
US09/672,149 2000-09-26

Publications (1)

Publication Number Publication Date
WO2001067715A1 true WO2001067715A1 (fr) 2001-09-13

Family

ID=26883910

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2001/000468 Ceased WO2001067715A1 (fr) 2000-03-07 2001-03-06 Pre-verification de sommes de controle utilisee par la compression d'en-tete basee sur une somme de controle

Country Status (2)

Country Link
AU (1) AU2001237877A1 (fr)
WO (1) WO2001067715A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006008341A1 (fr) * 2004-07-20 2006-01-26 Nokia Corporation Compression d'en-tete entre un compresseur et un decompresseur
US7301947B2 (en) 2001-06-27 2007-11-27 Nokia Corporation Transmission of compression identifier of headers on data packet connection
EP1894382A4 (fr) * 2005-06-21 2013-11-27 Ericsson Telefon Ab L M Compression d'en-tetes robuste, dynamique
WO2023098430A1 (fr) * 2021-11-30 2023-06-08 华为技术有限公司 Procédé de traitement de paquets de données, appareil de communication et système de communication

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5566170A (en) * 1994-12-29 1996-10-15 Storage Technology Corporation Method and apparatus for accelerated packet forwarding

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5566170A (en) * 1994-12-29 1996-10-15 Storage Technology Corporation Method and apparatus for accelerated packet forwarding

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
LARS-ERIK JONSSON ET AL: "Robust checksum-based header compression (ROCCO)", NETWORK WORKING GROUP, INTERNET DRAFT, 10 March 2000 (2000-03-10), pages 1 - 67, XP002901828 *
LARS-ERIK JONSSON ET AL: "Robust checksum-based header compression (ROCCO)", NETWORK WORKING GROUP, INTERNET-DRAFT, 22 June 1999 (1999-06-22), XP002901829 *
V JACOBSON/1/ RFC1144: "Compressing TCP/IP headers for low speed serial links", NETWORK WORKING GROUP, February 1990 (1990-02-01), XP002901830 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7301947B2 (en) 2001-06-27 2007-11-27 Nokia Corporation Transmission of compression identifier of headers on data packet connection
WO2006008341A1 (fr) * 2004-07-20 2006-01-26 Nokia Corporation Compression d'en-tete entre un compresseur et un decompresseur
EP1894382A4 (fr) * 2005-06-21 2013-11-27 Ericsson Telefon Ab L M Compression d'en-tetes robuste, dynamique
US8804765B2 (en) 2005-06-21 2014-08-12 Optis Wireless Technology, Llc Dynamic robust header compression
WO2023098430A1 (fr) * 2021-11-30 2023-06-08 华为技术有限公司 Procédé de traitement de paquets de données, appareil de communication et système de communication

Also Published As

Publication number Publication date
AU2001237877A1 (en) 2001-09-17

Similar Documents

Publication Publication Date Title
US6609224B1 (en) Replacement of transport-layer checksum in checksum-based header compression
US6385199B2 (en) Method and apparatus for packet transmission with header compression
Bormann et al. RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed
CN101411157B (zh) 用于在稳健标头压缩中加强局部修复的方法和系统
JP4582565B2 (ja) パケット通信におけるロバストヘッダ圧縮
US7647421B2 (en) Extension header compression
CN1528052B (zh) 用于提供消息压缩的上下文的方法和系统
US8327233B2 (en) Method and device for transmitting and receiving data packets
CN101057479B (zh) 用于在首标解压缩中处理失序分组的方法及设备
EP1415474B1 (fr) Procédé et compresseur pour la compression d'information d'horodatage dans des paquets
US20040199660A1 (en) Method of multiplexing compressed and uncompressed internet protocol packets
CN100423481C (zh) 报头压缩分组接收装置和方法
JP4598082B2 (ja) エラーに強いヘッダ圧縮においてローカル修正を強化させるための方法及びシステム
CN100446514C (zh) 以分组流传输数据分组的方法及其装置
EP1786170B1 (fr) Compression des en-têtes en paquets vocaux
EP1169801A1 (fr) Procede et dispositifs de transfert de donnees numeriques
US20040165585A1 (en) Packet transmission apparatus and packet transmission method
WO2000079764A1 (fr) Codage delta robuste dote d'informations historiques
US20040034826A1 (en) Transport protocol checksum recalculation
WO2001067715A1 (fr) Pre-verification de sommes de controle utilisee par la compression d'en-tete basee sur une somme de controle
TW540213B (en) Pre-verification of checksums used with checksum-based header compression
Yiannakoulias et al. Evaluation of header compression schemes for IP-based wireless access systems
Bormann et al. RFC3095: RObust Header Compression (ROHC): Framework and four profiles
Maravi Manish Raj Shivare
Yoshimura et al. Network Working Group C. Bormann, Editor, TZI/Uni Bremen Request for Comments: 3095 C. Burmeister, Matsushita Category: Standards Track M. Degermark, Univ. of Arizona H. Fukushima, Matsushita H. Hannu, Ericsson

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP