WO2003007572A1 - Procede permettant de compresser des protocoles et systeme associe - Google Patents

Procede permettant de compresser des protocoles et systeme associe Download PDF

Info

Publication number
WO2003007572A1
WO2003007572A1 PCT/EP2002/007876 EP0207876W WO03007572A1 WO 2003007572 A1 WO2003007572 A1 WO 2003007572A1 EP 0207876 W EP0207876 W EP 0207876W WO 03007572 A1 WO03007572 A1 WO 03007572A1
Authority
WO
WIPO (PCT)
Prior art keywords
bnf
protocol
code
rule
receiving terminal
Prior art date
Application number
PCT/EP2002/007876
Other languages
English (en)
Inventor
Richard Price
Original Assignee
Roke Manor Research Limited
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
Priority claimed from GBGB0117132.1A external-priority patent/GB0117132D0/en
Application filed by Roke Manor Research Limited filed Critical Roke Manor Research Limited
Publication of WO2003007572A1 publication Critical patent/WO2003007572A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • G06T9/005—Statistical coding, e.g. Huffman, run length coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC

Definitions

  • the invention relates to a method for compressing protocols and a related system. It is particularly applicable to data compression schemes, which are used in systems to transmit different protocols under which varying protocol information is sent. It has particular, but not exclusive, application to BNF (Backus Naur Form) which is a standard language used to describe new protocols and signalling schemes.
  • BNF Backus Naur Form
  • variable data e.g. strings
  • string, references, as well as the data had to be carefully ordered. This increased processing time.
  • compression algorithms reduced the efficiency of the compression process.
  • European Patent Application Number EP-A2-0 844 768 (Webtv Networks Inc).
  • European Patent Application Number EP-A2-0 844 768 describes a technique in which data that can be compressed, is attached to a compression stream, and compressed. Compressed data is then transmitted continuously as it is generated. Previously data was transmitted in compressed, discrete blocks or packets. Therefore channel carrying capacity was not fully optimised.
  • the technique described overcomes the problem associated with the compression techniques, in which compressed data was transmitted as intermittent packets. However, it did not address the particular problem of improving the compression ratio. Furthermore the aforementioned Patent Application does not provide any hint or suggestion as to how to reduce the required memory capacity of a compressor/decompressor system.
  • a method of transmitting specific protocol field information comprising the following steps: a) pre-storing predictable data portions of protocol fields, at the receiving terminal; b) removing variable data from the protocol field; c) compressing the variable data into a code; d) transmitting the code to said receiving terminal; e) receiving the code at the receiving terminal; f) decompressing the code into said variable data; and g) reconstructing the protocol field using the variable data and the predictable portion of said transmission specific protocol stored at the receiving terminal.
  • the process of transmitting protocols is therefore made more efficient by applying various data compression schemes to the protocols.
  • the amount of transmitted data is reduced, for example by transmitting only the variable data, such as the strings of characters that may vary within a particular protocol.
  • the invention utilises an algorithm to provide efficient compression of arbitrary protocols including SIP [RFC-2543] and RTSP [RFC-2326].
  • the algorithm preferably incorporates in its input a Backus Naur Form (BNF) description of the protocol to be compressed, which is stored at the compressor and decompressor and used as part of the compression process. Since the algorithm is preprogrammed with knowledge of how protocols behave, the compression ratio obtained is very high and the processing and memory requirements are low.
  • BNF Backus Naur Form
  • BNF descriptors are available for a wide range of important protocols including Hyper-text Mark-up Protocol (HTML) and Session Initiation Protocol (SIP).
  • HTTP Hyper-text Mark-up Protocol
  • SIP Session Initiation Protocol
  • the first line of a protocol message references a strict, unaltering set of protocol rules.
  • protocol rules are stored at a receiving terminal of a transmission system, for example a BNF descriptor of a protocol tells the receiving terminal the exact type of messages that are to be transmitted, and references further rules in such a way that every possible message that the protocol can send is defined. In other words it describes the format of the message, effectively stating what a SIP or HTML will comprise.
  • a communication system in which one of a plurality of protocols are transmitted to a receiving terminal, said system comprising: a) means for pre-storing predictable data portions of protocol fields, at the receiving terminal; b) means for removing variable data from the protocol field; c) means for compressing the variable data into a code; d) a transmitter for transmitting the code to said receiving terminal; e) receiving the code at the receiving terminal; f) means for decompressing the code into said variable data; and g) means for reconstructing the protocol field using the variable data and the predictable portion of said transmission specific protocol stored at the receiving terminal.
  • Non predictable data includes information which is not either stored or derivable at the receiving terminal.
  • the type of pre-stored data to be combined may incl ⁇ de a flag or label pointing to which element of pre-stored data needs to be included in the reconstruction of the transmission specific protocol, which data portions need to be taken from a look-up table or index; or which data needs to be derived, for example by way of an iteration to compute a number in a sequence from a previous number according to a stored algorithm.
  • the means for compressing the variable data into a code; means for decompressing the code into said variable data; and means for reconstructing the protocol field may all be performed by dedicated hardware devices or in a Programmable Micro-controller, such as a Digital Signal Processor (DSP) or Application Specific Integrated Circuit (ASIC).
  • DSP Digital Signal Processor
  • ASIC Application Specific Integrated Circuit
  • the number of bits, which may be used to code for each option is generally inversely proportional to the frequency of that option occurring. This improves the compression ratio yet further. It may use for example a Huffman method.
  • the protocol may be in any suitable form, but is preferably in
  • BNF Backus Naur Form
  • All versions of the BNF language are based around the concept of a "BNF rule”.
  • Each BNF rule describes the syntax of a portion of the protocol, and is defined in terms of existing BNF rules.
  • the "top-level" BNF rule describes the entire protocol in question.
  • BNF_rule ... Defines a new BNF rule in terms of existing BNF rules
  • a new BNF rale for an alphanumeric character can be defined in terms of existing BNF rules for letters and digits as follows:
  • alphanum ⁇ letter>
  • An example BNF description taken from SIP [RFC-2543] is described below.
  • the top-level BNF rule in this case describes the format of a website address. Note that website addresses can be expressed either as digits (for example "66.218.71.87”), or in the form of text (for example "www.yahoo.com”).
  • the BNF description allows both the numerical form and the text form of a website address to be used:
  • IPv4address l* ⁇ digit> ".” l* ⁇ digit> ".” l* ⁇ digit> ".' l* ⁇ digit>
  • alphanum ⁇ letter>
  • the BNF-based compression algorithm can compress a protocol described using any variant of BNF, provided that the actions to take for each fundamental BNF rale have been defined. Compression protocols are defined using ABNF [RFC-2234], as this covers a wide range of protocols including SIP [RFC-2543].
  • the basic idea of the BNF-based compression algorithm is to provide a BNF (Backus Naur Form) description of the relevant protocol at the compressor and decompressor.
  • this BNF description is parsed to reconstruct the original uncompressed message.
  • the information required in the compressed message is therefore just a set of instructions telling the decompressor which BNF rale to parse when more than one choice is available.
  • new_rule_3 ⁇ domainlabel> ⁇ new_rule_4>
  • the BNF "and" rule is built up from n consecutive existing BNF rules. For example:
  • ⁇ byte> ⁇ hex_digit> ⁇ hex_digit>
  • the BNF "or" rule specifies that the next part of the protocol can take one of n different forms. For example:
  • alphanum ⁇ letter>
  • an alphanumeric character can be either a letter or a digit.
  • the compressor appends the bits 00 to the end of the compressed message; if it contains the name "Dick” then the compressor appends the bits 01 and so on.
  • the decompressor reads these bits in the compressed message it can work out which of the four names must occur in the uncompressed message.
  • a BNF "text" rale specifies that a certain text string must occur in the uncompressed message. Since the BNF rale does not offer any choice of which text string occurs, it can be compressed down to 0 bits (i.e. the decompressor can successfully reconstruct the text string without needing any information from the compressed message).
  • the decompressor When this BNF rule is encountered, the decompressor simply copies the string "Tom" into the uncompressed message.
  • the BNF "optional" rale specifies that a certain BNF rule may or may not be present in the uncompressed message.
  • list_rule x*y ( ⁇ rule>)
  • a text string can contain 0 or more alphanumeric characters.
  • the protocol is that of a "hello” message.
  • hello-message "hello”
  • name "andrew”
  • first line is the all-defining line of the protocol.
  • BNF the first line also makes reference to the line ⁇ name>.
  • This second line says that the name may be "andrew” or "richard”.
  • the decompressor knows the protocol which is coming next, the only data which needs to be transmitted is the data telling which names are transmitted. In the example, rather than transmitting the strings “andrew” or “richard", because the choices or possibilities are one of two strings, all data can be transmitted as either a "0" or a "1". There is no need to transmit what the protocol (message) is, as a decompressor can derive from the header what message to expect.
  • a binary code may be assigned to each possibility.
  • these 10 possibilities are compressed i.e. coded according to the probability they occur using known compression schemes, such as Huffman.
  • the size of the binary code is made inversely proportional to the probability that that number of characters occurs.
  • hello_message "Hello " ⁇ name>
  • the first step is to split up the two BNF rules into simpler BNF rules taking one of the five "canonical" forms. This is accomplished as follows:
  • hello_message ⁇ rule_l> ⁇ name>
  • the compressor inserts some information into the compressed message that allows the decompressor to work out what to do next.
  • the compressor inserts log 2 (n) bits into the compressed message that can be interpreted as an integer from 0 to (n-1).
  • hello_message "Hello " ⁇ name>
  • the frequency that each choice in a BNF description will be used can be calculated by applying the scheme to a selection of messages. The number of times that each choice is used is recorded, and the results are scaled to give the necessary frequency of occurrence.
  • the resulting set of probability values can then be used to build a "Huffman tree". This tree indicates how to encode each of the choices in an optimally efficient manner, with more common choices communicated to the decompressor using fewer bits than rare choices.
  • the invention has been described with specific reference to examples of compressing and decompressing messages from protocols described using ABNF.
  • Advantages of supporting ABNF is that it is the variant of BNF used to describe many text-based protocols including SIP. It will be appreciated that many other variants exist on the basic BNF language.
  • the "EPIC" variant of BNF provides a number of additional fundamental BNF rales that can be used to describe, in greater detail, protocols to be compressed.
  • EPIC version of BNF provides rules for sequence numbers (which increase by 1 every time the rule is invoked) and length fields (which contain the length of the entire message). Use of these BNF rules improves the compression ratio because the sequence numbers and length fields can be computed or inferred at the decompressor rather than being transmitted as part of the compressed code.
  • any protocol described using the EPIC version of BNF will be compressed to a greater degree than a protocol described using ABNF.
  • dynamic compression may be used to improve the compression ratio.
  • the version of the BNF-based compressor described only compresses messages individually, so the overall compression ratio does not improve. This is also the case even when a large number of consecutive messages are compressed.
  • a more advanced version of the algorithm could modify dynamically the BNF description of the protocol 'on the fly', thereby learning more details of the message flow which it is compressing. For example, any new text strings that occur in the message flow could be added to the BNF description at both the compressor and decompressor.
  • the BNF-based compression algorithm described above can compress any message compatible with the BNF.
  • illegal messages cannot be compressed. In certain cases this may be a drawback, for example if the BNF description becomes outdated. Therefore in the ability to compress messages, which do not follow the BNF description currently available, is ideally also available at the compressor and decompressor.
  • Suitable generic compression algorithms include DEFLATE and
  • a more advanced method for adding generic message compression is to provide a new BNF rule for generic compression and to add this rule to the BNF description of the protocol. This rule can then be invoked as a default, for any part of a message that contains freeform text. Any non-conforming text therefore would still benefit from generic compression techniques. Compliant portions of a message can still be compressed, using the original BNF rales, so the overall compression ratio is higher than that obtained by using the generic algorithm alone.
  • the invention has been described by way of exemplary embodiments only and it will be appreciated that variation to the embodiments may be made without departing from the scope of the invention.
  • the invention may be included in a base system, for use in mobile telephony, a router used in routing signals along optical networks or a mobile telephone handset or pager.

Abstract

Dans un système de communications dans lequel différents protocoles sont émis d'un terminal d'émission vers un terminal de réception, un procédé permettant de transmettre des informations spécifiques de champs protocole consiste à pré-stocker des informations/instructions relatives audits champs protocoles au niveau du terminal de réception. Un compresseur compresse des données variables dans lesdits champs. Le terminal d'émission envoie uniquement des données compressées associées aux données variables d'un champ protocole spécifique; et le terminal de réception interprète le champ protocole spécifique par décompression des données reçues. L'invention trouve une application particulière lorsque les champs protocole sont sous la forme Backus Naur.
PCT/EP2002/007876 2001-07-13 2002-07-15 Procede permettant de compresser des protocoles et systeme associe WO2003007572A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB0117132.1 2001-07-13
GBGB0117132.1A GB0117132D0 (en) 2001-07-13 2001-07-13 Data compression
GB0125866A GB2377597B (en) 2001-07-13 2001-10-29 Method of compressing protocols
GB0125866.4 2001-10-29

Publications (1)

Publication Number Publication Date
WO2003007572A1 true WO2003007572A1 (fr) 2003-01-23

Family

ID=26246310

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2002/007876 WO2003007572A1 (fr) 2001-07-13 2002-07-15 Procede permettant de compresser des protocoles et systeme associe

Country Status (1)

Country Link
WO (1) WO2003007572A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11431990B2 (en) 2015-06-04 2022-08-30 Thales Holdings Uk Plc Video compression with increased fidelity near horizon

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0512174A1 (fr) * 1991-05-08 1992-11-11 Semaphore, Inc. Appareil et méthode de transmission de données en parallèle et basée sur des règles
US5293379A (en) * 1991-04-22 1994-03-08 Gandalf Technologies, Inc. Packet-based data compression method
US6040790A (en) * 1998-05-29 2000-03-21 Xerox Corporation Method of building an adaptive huffman codeword tree
WO2000049748A1 (fr) * 1999-02-17 2000-08-24 Nokia Mobile Phones Ltd. Compression d'en-tete dans des services en temps reel
WO2000079763A1 (fr) * 1999-06-18 2000-12-28 Telefonaktiebolaget L M Ericsson (Publ) Compression d'en-tete robuste dans des communications par paquets

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5293379A (en) * 1991-04-22 1994-03-08 Gandalf Technologies, Inc. Packet-based data compression method
EP0512174A1 (fr) * 1991-05-08 1992-11-11 Semaphore, Inc. Appareil et méthode de transmission de données en parallèle et basée sur des règles
US6040790A (en) * 1998-05-29 2000-03-21 Xerox Corporation Method of building an adaptive huffman codeword tree
WO2000049748A1 (fr) * 1999-02-17 2000-08-24 Nokia Mobile Phones Ltd. Compression d'en-tete dans des services en temps reel
WO2000079763A1 (fr) * 1999-06-18 2000-12-28 Telefonaktiebolaget L M Ericsson (Publ) Compression d'en-tete robuste dans des communications par paquets

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JACOBSON V: "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, INTERNET ENGINEERING TASK FORCE, February 1990 (1990-02-01), XP002139708 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11431990B2 (en) 2015-06-04 2022-08-30 Thales Holdings Uk Plc Video compression with increased fidelity near horizon

Similar Documents

Publication Publication Date Title
US6883035B2 (en) System and method for communicating with temporary compression tables
EP1334560B1 (fr) Procede de communication pour une compression de contexte partage
US6985965B2 (en) Static information knowledge used with binary compression methods
CA2065578C (fr) Methode de compression de donnees utilisant des paquets
EP1320832B1 (fr) Procede de compression de paquets de donnees
US7295575B2 (en) Packet transmitting/receiving apparatus and packet transmission method
US6963587B2 (en) Communication system and method utilizing request-reply communication patterns for data compression
US20040075596A1 (en) Huffman data compression method
AU2001277483B2 (en) Header compression method for network protocols
EP1397866A2 (fr) Procede et dispositif de compression de donnees adaptative
AU2001293963A1 (en) A method of processing data packets
CA2428788C (fr) Connaissance d'informations statiques utilisee avec des procedes de compression binaire
JPH11196000A (ja) 符号化方法及びデータ圧縮器
EP1590889A2 (fr) Procede et dispositif de compression de donnees de texte
WO2002041498A2 (fr) Systeme et procede de communication utilisant des modeles de communication question-reponse pour la compression de donnees
WO2003007572A1 (fr) Procede permettant de compresser des protocoles et systeme associe
JPH09149080A (ja) データ伝送装置
GB2377597A (en) Method of compressing protocols where information/instructions about the protocols are pre-stored at the receiving terminal
WO2003015284A1 (fr) Procede de compression de donnees a l'aide d'un code de longueur variable
Bakota et al. Optimal format indication in distributed profiles ROHC compression

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): GB US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR

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)
122 Ep: pct application non-entry in european phase