WO2007031090A1

WO2007031090A1 - A method of compressing the header of a data packet

Info

Publication number: WO2007031090A1
Application number: PCT/DK2006/000510
Authority: WO
Inventors: Tatiana Kozlova Madsen; Frank H.P. Fitzek
Original assignee: Aalborg Universitet
Priority date: 2005-09-15
Filing date: 2006-09-15
Publication date: 2007-03-22

Abstract

The invention relates to a method of compressing the header of a data packet for transmission in a communication system, in which the data packet comprises a data part having a payload size and a header part. The header part of the data packets is adaptively compressed using a header compression mechanism based on the payload size of the data part.

Description

Title: A method of compressing the header of a data packet

Technical Field

The present invention relates to a method of compressing the header of a data packet for transmission in a communication system, said data packet comprising a data part having a payload size and a header part. The invention further relates to a communication system using the header compression method.

Background Art

The wireless delivery of multimedia services is one of the goals of the next generation of mobile communication systems. Users are expecting that the same services will be available in wireless networks as in wired ones. However, for instance Internet Protocol (IP) based multimedia applications, including audio- and video-streaming and gaming, require more bandwidth than traditional voice services in circuit-switched networks. In order to use the limited resource, i.e. bandwidth, in the most efficient way, both IP packet header and packet payload should be compressed. A number of IP header compression schemes have been proposed over the past 15 years, e.g. Van Jacobsen HC (RFC 1114) [1], Compressed RTP (RFC 2508) [2], Enhanced Compressed RTP (RFC 3545) [3], and Robust Header Compression (RFC 3095) [4]. These techniques allow compression of a 40-byte IPv4 header down to 2-4 bytes.

All these techniques apply compression of an IP packet header based on CONTEXT state, but without taking into account the requirements of the link layer. A number of wireless technologies available today use fixed packet sizes at the link level: e.g.

GPRS, UMTS, and Bluetooth. Due to the specifics of packetizing of data implemented in the technologies mentioned above, IP header compression schemes do not perform efficiently compared with technologies where payload of the link layer packet can freely vary, such as in the WLAN IEEE 802.11 standard.

When dealing with header compression for packets with variable length, a useful parameter to consider is bandwidth savings. The bandwidth savings are calculated as the amount of data transmitted using a header compression scheme over the data required to send the same amount of information without applying header compression. In this case, even a small compression of a header will lead to some savings. This is not the case, when packets of fixed sizes are used on the link layer. In this situation, the communication is often based on some kind of time division access method: the channel is slotted and a packet transmission can start only at the beginning of the slot. Even if the packet length is smaller than maximally allowed by this packet type, no other packets can be sent in this slot and the bandwidth is wasted. Therefore, if applying header compression, the size of the packet can not be reduced significantly (such that it will fit in another packet type) and no bandwidth savings can be achieved.

This problem of header compression inefficiency for fixed packet types has not been addressed in the literature. The only attempt in this direction was made in Zero-byte

ROHC [5] that is an additional profile for Robust Header Compression (ROHC) [4].

Zero-byte header compression is designed to prevent the single-octet ROHC-header from pushing a packet voice stream into the next higher fixed packet size for the radio.

It is designed especially for usage in a GPRS air interface.

Disclosure of Invention

The object of the invention is to obtain a new and improved method for header compression of data packets.

This is according to the invention achieved by the header part of the data packets being adaptively compressed using a header compression mechanism based on the pay- load size of the data part.

Thereby it is achieved that the header compression mechanism based on the payload size can change between different compression schemes and thereby achieve an optimum compression.

In a preferred embodiment according to the invention, the header compression mecha- nism is switched on or off based on the payload size of the data part. This method eliminates the need for using context repair mechanisms in order to prevent context re- synchronization or loss propagation, since this method will send the entire header, when the header compression mechanism is switched off. This helps to maintain the synchronization between for instance the compressor and a decompressor of a com- munication system. According to a preferred embodiment, the communication system uses fixed link layer packet types. The method is especially applicable for situations, where the link layer payload size can take values only from a predefined set, i.e. when several link layer packet types are supported.

According to an alternative embodiment, the data packets are sent in blocks of a fixed size, the number of blocks used depending on the size of the IP data packets. The header compression method is suitable for communication systems using fixed data block sizes, since the adaptive header compression mechanism can reduce the num- ber of blocks used for sending the data packets on the link layer. Otherwise, the compression mechanism is switched of, thereby minimizing propagation losses.

In a preferred embodiment according to the invention, the header compression is switched off if the packet type of a data packet with header compression is the same as the packet type of a data packet without header compression, and is switched on if the packet type of a data packet with header compression is different from the packet type of a data packet without header compression. That is, the header compression mechanism is only used if the packet type changes due to the header compression.

According to another preferred embodiment according to the invention, the header compression is switched off if the number of blocks used for sending a data packet with header compression is the same as the number of blocks used for a data packet without header compression, and is switched on if the number of blocks used for sending a data packet with header compression is different from the number of blocks used for a data packet without header compression. The header compression is thereby only switched on, if compression of the header will reduce the number of necessary blocks for sending the data packets. If the header compression does not reduce the number of necessary blocks, the header compression mechanism will be switched off, and the entire header will be sent together with the data packet. As previously mentioned, this eliminates the need for repair mechanisms, when loss propagation has occurred in systems using for instance differential compression schemes, since the entire header will be frequently sent to the receiver.

According to preferred embodiments, the header compression mechanism, when switched on, uses header compression schemes known per se in the art. This can for example be achieved by the header compression mechanism compressing the header by removing redundancy from the header of the data packet using information from previously sent data packets. This can be achieved by the header compression mechanism compressing the header, so that the header of a data packet only carries differential information compared to a preceding header.

According to a preferred embodiment, the header compression is tuned in such a way that only a subset of available packet types is used. For example, during poor channel conditions, it is favourable to use packet types that involve Forward Error Correction (FEC) coding. The proposed header compression method can be tuned so that such packet types automatically are chosen.

The object of the invention is also achieved by a communication system using the aforementioned method for header compression.

According to a preferred embodiment of the system according to the invention, the system comprises a transmitter side and a receiver side, a communication channel being generated between the transmitter side and the receiver side, wherein the transmitter side comprises a header compression mechanism, and the receiver side comprises a header decompression mechanism.

The object of the invention is also achieved by a header mechanism, which is switched on or off based on the payload size of the data part of the data packet.

Brief Description of the Drawings

The invention is explained in detail below with reference to the drawings, in which

Fig. 1 is a schematic view illustrating the general concept of header compression,

Fig. 2 is a schematic view of delta coding in which loss propagation occurs,

Fig. 3 is an illustration of header compression as a two-state Markov chain,

Fig. 4 is a schematic view of a simulation model used for demonstrating the header compression method according to the invention, Fig. 5 is a graph showing the fraction of packets received and decompressed correctly for different packet types in Bluetooth communication,

Figs. 6-11 show performance graphs for a first simulation scenario, in which there are two packets in a frame,

Figs. 12-17 show performance graphs for a first simulation scenario, in which there are twenty packets in a frame,

Figs. 18-23 show performance graphs for a first simulation scenario, in which there are one hundred packets in a frame,

Figs. 24-29 show performance graphs for a second simulation scenario, in which there are two packets in a frame,

Figs. 30-35 show performance graphs for a second simulation scenario, in which there are twenty packets in a frame, and

Figs. 36-41 show performance graphs for a second simulation scenario, in which there are one hundred packets in a frame.

Best Modes for Carrying out the Invention

Before introducing the novel Internet Protocol (IP) header compression concept, in- sights to the main concept and terminology of header compression research will be provided.

Header compression is possible due to some redundancy among the different header fields of different protocol layers and the interdependencies of IP packets. It is typically performed on the headers of the network layer and above. For example, for multimedia services header compression is done on the RTP/UDP/IP headers (Real-time Transport Procol/User Datagram Protocol/Internet Protocol). The compressor/ decompressor is located between the link and the network layers in the protocol stack. Analysis of the variations on the field information of the packet flow is used to decide the smallest amount of information needed to reconstruct the header fields on the receiver side. Depending on the rate of change, the headerfields of an uncompressed header can be classified as constant, delta, inferable or random [6]. Constant fields do not change during a particular IP stream. These fields can be completely omitted after the first successful transmission. Inferred fields can be determined from other header fields and are relatively easy to compress. Delta fields change by a small amount and can be compressed by using delta coding approach. Random fields do not have a regular pattern and it is advisable always to send them uncompressed.

The general concept of header compression is given in Fig. 1. On a sender side 10, a compressor 11 removes redundancy from the incoming packet using information from the past packets, called the CONTEXT (or base). A decompressor 21 maintains the context and uses it to reconstruct a header 12, 22 of the incoming packet sent via a communication channel. The inconsistencies in the contexts of the compressor 11 and the decompressor 21 lead to the loss in synchronization and failure of the decompression procedure.

The delta coding approach is commonly used for header compression and will briefly be described in the following. First, an uncompressed header UCH is sent to establish the context. It is followed by a row of compressed headers CH that carry only the differential information referring to the preceding header. The differences between two packet headers are referred to as the delta. For error-free channels this is a very efficient way of header compression. However, it is very sensitive to packet losses; if one packet is lost, the context at the decompressor is not updated and all the subsequent packets, even if received correctly, can not be decompressed. This situation is refered to as loss propagation (see also Fig. 2).

To prevent the context re-synchronization (loss propagation), a context repair mechanism should be applied. A sender will rely on the feedback from a receiver in order to know when to transmit a packet with an uncompressed header. When the feedback is unavailable, the synchronization of the context is achieved by periodically refreshing of the states. The repetition rate of the updates depends a lot on the channel error rate and the propagation environment.

The problem of loss propagation is crucial for the efficient design of header compression schemes. This was recognized already in the earliest work on header compres- sion. The proposed existing solutions include either excessive signalling from the receiver to the sender or periodic full context updates. Both methods decrease bandwidth savings. Thus, there is a clear trade-off between the compression gain and robustness of the scheme. We propose a novel scheme that allows keeping the context synchronization, thus ensuring robustness. At the same time, the compression gain of the proposed scheme is the same as for conventional header compression schemes.

General description of the proposed header compression scheme The main idea of the proposed novel header compression scheme is to switch the compression mechanism on/ off adaptively depending on the size of IP packet payload. The compression mechanism will be enabled, if a smaller packet size can be used by employing header compression (HC). This leads to the bandwidth savings. If the same link layer packet type is used for sending a packet with compressed and uncompressed header, then the header compression mechanism is disabled, and the packet with a full header is transmitted instead. This helps to keep the synchronization between the compressor and decompressor.

The following pseudo-code summarizes how the novel header compression algorithm works, where U and C are the sizes of uncompressed and compressed headers in bytes, respectively:

1 ) Stream L of packets

2) Take next packet p_/from L. Payload of p, is x bytes.

3) If packet type [U+x] = packet type [C+x], then

HC = OFF else

HC = ON

4) If L ≠ 0 then Goto 2.

The presented novel scheme can also be explained with the help of a two-state Markov model (Fig. 3). In conventional header compression schemes, transitions between the states are done either periodically or based on the feedback from the receiver. In the proposed novel scheme, an additional parameter, namely the payload size, is taken into account in order to make a decision about the transition to another state. A deci- sion is made individually for each packet. The proposed scheme has the following properties:

Statement 1: The proposed novel header compression method reduces probability of error propagation compared with the conventional compression schemes. It maintains synchronization between the compressor and decompressor without the need of excessive signalling.

Statement 2: The proposed header compression scheme is designed for fixed packet sizes. Existing header compression schemes do not take this property into account. Header compression is based on differential methods, which are efficient approaches to compress the information. Unfortunately, these methods introduce error propagation because of de-synchronization of the compressor and decompressor. De- synchronization occurs due to the packet losses. Resynchronization is achieved either by periodic updates (in case of no feedback from the receiver) or by excessive signal- ling (in case feedback is provided by the receiver). The proposed scheme frequently sends a packet with an uncompressed header, thereby maintaining synchronization.

Statement 3: The proposed novel header compression scheme achieves the same bandwidth occupancy as conventional schemes. Indeed, the header compression mechanism is switched off only if the same type of packet is used as when header compression is applied. Technologies using fixed packet sizes on the link layer are based on the time division concept; a communication slot is reserved for a particular pair of communicating devices. Even if a short packet is transmitted within a slot, another packet cannot be transmitted within this slot, and bandwidth is wasted.

Statement 4: The header compression can be tuned in the way that only a subset of available packet types is used. Indeed, there can be situations, where only a subset of available packet types is suitable for data transmission. For example, under poor channel conditions packets with error protection should be preferred. If this is the case, then by switching header compression on or off for a particular IP packet payload size, this can be achieved using only a pre-defined subset of link layer packets.

Adaptive Header Compression for Bluetooth

The novel header compression approach is in the following described by considering the Bluetooth technology as an example. The proposed scheme is called Adaptive Header Compression (AHC) for Bluetooth. Bluetooth is a low-cost low-power wireless technology that provides connectivity among devices placed within a short range. Bluetooth uses controlled scheduled transmissions. The Bluetooth system provides duplex transmission based on slotted time- division duplex (TDD), where the duration of each slot is 625 μs. Asynchronous links support payloads with or without a 2/3-rate Forward Error Correction (FEC) coding scheme. In addition, single-slot, three-slot and five-slot packets are available. The Bluetooth packet types are summarized in Table 1. The big difference between user payload of 1~, 3- and 5-slot packets appears from the below table. The payload length is variable and depends on the available user data. However, the maximum length is specified for each packet type. The whole slot (or 3 or 5 slots) is reserved for a transmission, even if the packet length is smaller than maximally available.

Table 1: Bluetooth Packet Types

Following the proposed approach, the IP header is compressed or not depending on the payload size. Table 2 shows when to apply header compression (assuming that uncompressed header is 40 bytes, compressed header is 4 bytes). If the payload is more than 339 bytes, segmentation is required.

Table 2: Proposed adaptive scheme: switching header compression mechanism ON/OFF depending on the payload size

Situations can occur, in which the link layer specifies that only a subset of available packet types should be used for data transmission. For example, in bad channel conditions, DM packets (Data Medium rate packets) should be preferred since they have 2/3 FEC protection (as opposed to DH packets (Data High rate packets)). In this case, the operation of the proposed header compression can be tuned in such a way that automatically only DM packets are used. The operation of the adaptive scheme is presented in Table 3.

Table 3: Proposed adaptive scheme: switching header compression mechanism ON/OFF depending on the payload size

Performance Evaluation of Adaptive Header Compression Simulator

To evaluate the performance of the Adaptive Header Compression (AHC) scheme, a simulator in MATLAB has been developed. The simulation model consists of three main parts: i) data and header generator and header compressor/ decompressor; ii) Bluetooth baseband and iii) channel (see Fig. 4). The channel is modelled as an Addi- tive White Gaussian Noise (AWGN) channel. The Bluetooth block includes Automatic Repeat request (ARQ), Cyclic Redundancy Check (CRC) and a FEC generator, and a Gaussian Frequency Shift Keying (GFSK) modulator/demodulator. The implemented header compressor works on the RTP/UDP/IP headers. The task of the decompressor is to rebuild or recreate the uncompressed form of the packet and to update the con- text. If a packet with an uncompressed header is received, then the context of the decompressor is updated. In case a compressed packet is received, it is uncompressed in the following way: the fixed fields are taken from the context of the decompressor; the delta fields are calculated from the data from the compressed packet and the context stored in the decompressor. After a packet is decompressed, the context is updated.

The payload size of a packet stream is not fixed, but is assumed to vary randomly. It is assumed to be independent and identically distributed (i.i.d.) over the interval [1 ; 299] bytes. The performance of the Adaptive Header Compression is compared to one of the conventional schemes, RFC 2508 [2]. The results for when no header compression is applied for data transmission are also presented.

Performance metrics

A number of performance metrics has been evaluated. Mainly, focus has been on the metrics that reflect bandwidth savings and robustness. Additionally, parameters that characterize energy-efficiency of the scheme are studied since the minimization of en- ergy consumption is a desired property for small battery-driven devices (that is often the case for Bluetooth networks).

Packet Delivery and Decompression Ratio (PDDF): This metric is defined as the ratio of the number of successfully decompressed packets to the total number of packets sent. This metric shows how reliable a network is and how robust the communication system according to the invention is against channel errors.

PDDF = ^-XlOO ,

where N_s is the total number of packets sent and N_R is the number of packets received and correctly decompressed.

Packet Error Probability (PEP): This metric shows the rate at which the packets are lost and it is defined as:

PEP = I --

N,

Bandwidth savings: This metric defines savings of the bandwidth, measured in slots, normalized to the number of slots needed for data transmission if no header compression is applied:

where S_AHc is the total number of slots required for data transmission using AHC (or RFC-2508) and SNHC is the total number of slots in case of no header compression.

Average packet delay: This parameter considers only the transmission delay, ignoring processing and queuing delays, and it is defined as time that has elapsed from the moment the transmission of the packet has started until the moment it is finished. This metric is slightly different from the average IP packet length, since the metric here is calculated using the size of a link layer packet that can be different from the length of an IP packet when extra protection bits are added (e.g. DM packets).

Energy Efficiency (Bytes/mJ): This is the ratio between the correctly received data in bytes and the total amount of energy spent during the transmission in mJ [8].

„ ~_rf. . Good Throughput Energy Efficiency = ₇ ^-^- ^

ΨTX ^X^ΓX ⁺ ^RX ^χPjoc ⁺T_lpm X-P_lpm ) where T_1x, T_RX and T_/pm are periods of time that a node spends for transmitting, receiv- ing and in low power mode (Ipm), respectively. P_7x, P_RX and P_/pm are the amounts of power a node uses for transmitting, receiving and in Ipm, respectively. Typical values considered in the simulation are as follows [9]:

Table 4: Typical power values for different states

In the slots where there is no transmission (e.g. odd slots in a broadcasting scenario), a node is assumed to be in a low power mode.

Average Power Dissipation (APD) (mW): It is defined as a ratio of the total energy spent for data transmission over the time needed for transmission [9]. A device that constantly transmits with APD will consume the same amount of energy as the considered Bluetooth device.

{T_τx XP_TX)+ [T_11x XP^)₊ (T_lpm XP₁ )

APD = -

¹ TTX + ^{τ 1}TRX A ^- ¹TIpIIi Scenarios

Two conceptually different scenarios are considered.

1) One-to-many communication/ No feedback The first scenario presents broadcasting/ multicasting by a Bluetooth access point (that assumes to have a role of a piconet master) to a number of devices (that have a role of piconet slaves). In this case, the AM_ADDR field in the Bluetooth header is set to 000 indicating that this information is intended for every active member of the piconet. The master transmits data only in even slots using 1-, 3- or 5-slot packets. The slots follow- ing after a master transmission (odd slots) are empty: none of the slaves is allowed to transmit in these slots. Thus, the master transmission is left unacknowledged. This case is referred to as 'no feedback is available from the receiver'. It means that the context update can be done only periodically.

This scenario corresponds to the situation when, for example, the same information is downloaded to the multiple devices through a Bluetooth access point.

The key feature of this scenario is the absence of the feedback information. Thus, the performance of the header compression schemes is expected to be the same in case of one-to-one communication, but when no feedback from the receiver is present, as for example is the case if a Synchronous Connection Oriented (SCO) link is set up between a master and a slave.

2) One-to-one communication/ Link layer assisted feedback The second scenario focuses on one-to-one communication between two Bluetooth devices. Bluetooth uses stop-and-wait ARQ scheme: DM or DH packets are retransmitted until acknowledgement of a successful reception is returned or timeout is exceeded. The acknowledgement information is included in the header of a return packet (ARQN=I for acknowledge (ACK) and ARQN=O for no acknowledge (NACK)). The slave will respond in the next slot followed after master-to-slave transmission. In the simulation model the number of retransmissions is limited to 5.

Thanks to the ARQ scheme, the feedback regarding the successful transmission of a packet is available at the next slot at the link-layer. Exploiting cross-layer approach, this information can be passed on to the network layer and to the header compressor.

Thus, the feedback from the receiver is available in this case. The advantage of the described cross-layer approach is that the feedback can be delivered to the compressor without the need of additional signalling but purely relaying on the cross-layer information exchange. We refer to this situation as 'link-layer assisted feedback'. For the simulation purposes, we assume that there is no processing delay, and if a packet cannot be delivered correctly, already the next IP packet of the stream is sent with an uncompressed packet (this allows immediate CONTEXT synchronization). However, if a processing delay is large, the decompressor will drop a number of packets before the update will be received.

The presence of the immediate feedback illuminates the loss propagation problem. In this case the proposed Adaptive Header Compression and RFC 2508 schemes will show approximately the same performance. Instead, for the present simulation evaluation, the focus has been directed at the case, where only a subset of available packet types is used for data transmission.

This approach can be also motivated by the following observation: the error-proneness of a header compression scheme depends on the type of the link layer packet used for a transmission. This is due to the different packet length and different error protection schemes used. Fig. 5 shows the "robustness" when different Bluetooth packet types are used (for abbreviation see Table 2). From Fig. 5 it can be seen that in cases when DM packets are used for data transmission (packet types 1 ,3,4 and 7), a significant ratio of packets is received and decompressed correctly compared with DH packets. This motivates the proposed header compression approach that works exclusively with DM packets, as it is explained in Section Ml-B (see also Table 3). It can be anticipated that this scheme gives a performance improvement compared with RFC 2508 when channel conditions are not good. If such channel conditional are detected by a link layer (e.g. bit errors exceed a certain threshold), a request can be sent to the compressor to switch to the new scheme.

The following sections present simulation results.

Results for Scenario 1

In the following a frame is defined as a series of packets, where the first packet is transmitted with an uncompressed header and the following packets carry compressed headers. N denotes the number of packets in a frame. The choice of N has a big impact on the performance of the RFC 2508 compression scheme and will strongly de- pend on channel conditions. Therefore, results for three different values are presented: /V=2, 20 and 100.

All considered parameters are plotted vs. signal-to-noise ratio (SNR).

The situation where N=2 corresponds to very small frame size. In this situation the considered header compression schemes perform very similar to the case of no compression. Anyway, bandwidth savings of about 8% can be achieved for RFC 2508 and AHC (Fig. 8).

For larger values of N, the compression gain of the schemes increases and bandwidth savings of 16% are observed (Figs. 14 and 20). AHC and RFC 2508 achieve the same bandwidth savings. As a consequence of savings in bandwidth occupancy, the average packet delay (ADP) is reduced (Figs. 15 and 21). The difference in ADP for RFC 2508 and AHC is negligibly small compared to no compression case.

From Figs. 12 and 18 a rapid drop can be observed in Packet Delivery Ratio (PDR) for RFC 2508, when channel conditions become worse. AHC is much more robust against channel errors (the line corresponding to AHC lies above the blue for RFC-2508 and close to the line for the no header compression case). Packets without header compression are only lost if channel errors occur. However, in this case, loss propagation problems do not occur. Therefore, this case provides the upper bound for PDR and the closer a PDR of a compression scheme is to the PDR of the no header compression case, the more robust is the scheme.

With regard to energy efficiency of the proposed scheme, it can be observed that Average Power Dissipation (APD) is slightly higher for AHC compared with RFC 2508, but still the power used on average by AHC is smaller than the no compression case (Fig. 17). In good channel conditions {SNR>22), RFC 2508 is the most energy efficient scheme, only as little as possible is transmitted and there are no packet losses. The packet headers can thus be decompressed. But as channel conditions become worse (SNR<20), the efficiency of RFC 2508 deteriorates quickly and already when SA/R=18, it falls down to zero. This is due to a severe loss propagation problem from which RFC 2508 suffers when SΛ//R<18. On the contrary, AHC still shows high energy efficiency even when the channel is not good. Comparing the cases of Λ/=20 and Λ/=100, the PDR for RFC 2508 degrades rapidly when N is large. With a large N, the context update is performed less frequently and more packets will be dropped at the decompressor. However, the value of N does not have any significant impact on the performance of AHC. The PDR stays as high for W=100 as it is for Λ/=20. This phenomenon can be explained by an efficient context update method of AHC.

Overall, it can be concluded for this scenario that for any N AHC is a robust scheme. Thus, the present invention is able to maintain a high PDR without losing in bandwidth savings. On average it consumes slightly more energy compared with the conventional compression schemes, but the overall energy efficiency of AHC is higher when SNR<20.

Results for Scenario 2 First of all, it can be noticed that the results for different values of N are very similar. It is clear that the performance of the no header compression scheme does not depend on N at all. From 1 it appears that N does not have any big influence on AHC. If feedback is available, the value of N does not influence the performance of RFC 2508 either. Even though the periodic context updates are kept activated, the majority of up- dates are triggered by the receiver feedback (negative ACK).

To underline that only DM packets are used in combination with AHC scheme, this scheme is referred to as AHC-DM.

As expected, AHC-DM achieves the highest PDR, even higher than no header compression case (Fig. 30). This is due to the extra error protection used in DM packets. Using DM packets also helps to reduce loss propagation problems since more packets are received correctly.

Compared with Scenario 1 , where bandwidth savings are constant regardless of the SNR value, the bandwidth savings in Scenario 2 are not a constant function of the SNR (Fig. 32), due to possible packet retransmissions. Under good channel conditions (SNR>20), bandwidth savings of RFC 2508 are the same as in Scenario 1 , i.e. 16%, since there are almost no retransmissions in this case. However, bandwidth savings for AHC-DM are lower, about 6%, due to the excessive error protection of DM packets. But when SNR<20, almost 30% of bandwidth can be saved using AHC-DM compared with no header compression case. When the SNR decreases further no bandwidth savings can be achieved.

The same type of behaviour can be observed in the ADP graphs (Fig. 33). When SNR=12, all schemes show the same delay. However, when 16<SΛ/ft<20, AHC-DM minimizes the transmission delay.

This is also reflected in the energy-consumption and efficiency graphs (Figs. 34 and 35). AHC-DM is the least energy efficient during good channel conditions. But as the channel becomes worse, AHC-DM shows the best efficiency and on average it uses less power for packet transmission, since the number of retransmissions is smaller than for other schemes.

Overall, AHC-DM should be preferred when SNR<20.

Conclusions

A novel header compression scheme has been introduced that is suitable for usage with wireless technologies operating with fixed link layer packet types. The usage of the general approach is illustrated with the example of Bluetooth technology. The state- ments on the properties of the proposed scheme are verified by the extensive simulations. Two different scenarios are considered: i) broadcasting of data by a Bluetooth access point and ii) data exchange between two Bluetooth devices. The robustness of the scheme is shown for both scenarios.

To summarize, the advantages of the proposed novel approach are the following:

• Increased capacity

• Introduces robustness without losing bandwidth efficiency

• Proposal is compliant with the specifications in the standard

• Can work with the whole set of packet types, or just a subset • Depending on the packet length, the method according to the invention will lead to power savings

• Simple and therefore can be used in low complexity nodes

The invention has been described with reference to a preferred embodiment. However, the scope of the invention is not limited to the illustrated embodiment, and alterations and modifications can be carried out without deviating from said scope of the invention.

Bibliography

[1] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial Links", Request for Comments 1144, February 1990.

[2] S. Casner and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", Request for Comments 2508, February 1999.

[3] T. Koren and et al, "Enhanced Compressed RTP (ECRTP) for links with high delay, packet loss and reordering", Request for Comments 3545, July 2003.

[4] C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, and H. Zheng, "Robust Header Compression: Framework and four profiles", Request for Comments 3095, July 2001.

[5] Z. Liu, K. Le, "Zero-byte support for Bidirectional Reliable mode in Extended Link- layer Assisted Robust Header Compression Profile", Request for Comments 3408, December 2002.

[6] F.H.P. Fitzek, S. Hendrata, P. Seeling, M. Reisslein, Chapter in "Wireless Internet - Header Compression Schemes for Wireless Internet Access", CRC Press. 2004.

[7] Bluetooth specification. Version 2.0. www.bluetooth.org

[8] G. Kuijpers, P. Popovski, H. Yomo, T.K. Madsen, and R. Prasad, "Flexible and Energy-Efficient Networking Structure using Bluetooth Park Mode", in Wireless Personal Multimedia Communications WPMC 2004, Padova, Italy, September 2004.

[9] M. Perillo and W. Heinzelman, "ASP: An adaptive energy-efficient polling algorithm for Bluetooth piconets", in Proc. 36^th Intl. Conf. on System Sciences (HICSS O3), Hawaii, Jan. 2003.

Claims

1. A method of compressing the header of a data packet for transmission in a communication system, said data packet comprising a data part having a payload size and a header part, characterised in that the header part of the data packets is adaptively compressed using a header compression mechanism based on the payload size of the data part.

2. A method according to claim 1 , wherein a header compression mechanism is switched on or off based on the payload size of the data part.

3. A method according to claim 1 or 2, wherein the communication system uses fixed link layer packet types.

4. A method according to any of the preceding claims, wherein the data packets are sent in blocks of a fixed size, the number of blocks used depending on the size of the data packets.

5. A method according to any of the preceding claims, wherein the header compres- sion is switched off if the packet type of a data packet with header compression is the same as the packet type of a data packet without header compression, and is switched on if the packet type of a data packet with header compression is different from the packet type of a data packet without header compression.

6. A method according to claim 3 or claim 3 and any of claims 4-5, wherein the header compression is switched off if the number of blocks used for sending a data packet with header compression is the same as the number of blocks used for a data packet without header compression, and is switched on if the number of blocks used for sending a data packet with header compression is different from the number of blocks used for a data packet without header compression.

7. A method according to any of the preceding claims, wherein the header compression mechanism compresses the header by removing redundancy from the header of the data packet using information from priorly sent data packets.

8. A method according to claim 7, wherein the header compression mechanism compresses the header, so that the header of a data packet only carries differential information compared to a preceding header.

9. A method according to any of the preceding claims, wherein the header compression is tuned in such a way that only a subset of available packet types are used.

10. A communication system using a header compression method according to any of claims 1-9.

11. A communication system according to claim 10, wherein the system comprises a transmitter side and a receiver side, a communication channel being generated between the transmitter side and the receiver side, and wherein the transmitter side comprises a header compression mechanism, and the receiver side comprises a header decompression mechanism.

12. A header compression mechanism for compressing the header of a data packet comprising a header part and a data part, said data part having a payload size, characterised in that the header mechanism is switched on or off based on the payload size of the data part of the data packet.