A method for compressing information in a communication system is provided. The method includes compressing first address data in a first packet stream by using second address data included in a second packet stream.
|
1. A method for compressing information in a communication system, the method comprising:
comparing first address data in a first message to second address data included in a second message to identify differences between the first and second address data;
compressing, by a compressor, the first address data using the second address data based upon the comparison of the first address data and the second address data; and
transmitting, sequentially, at least one packet of a first packet stream comprising the compressed first address data and at least one packet of a second packet stream comprising the second address data.
18. A node for communication system, the node comprising:
a compressor configured to
compare first address data in a first message to second address data in a second message to identify differences between the first and second address data, and
compress the first address data using the second address data based upon the comparison of the first address data and the second address data; and
a transmitter configured to first transmit at least one packet of a first packet stream comprising the compressed first address data and to then transmit at least one packet of a second packet stream comprising the second address data.
24. A method for decompressing information in a communication system, the method comprising:
receiving, sequentially, at least one packet of a first packet stream and at least one packet of a second packet stream, wherein the first packet stream comprises compressed first address data and the second packet stream comprises second address data, wherein the compressed first address data is based on a comparison of the first address data and the second address data to identify differences between the first and second address data; and
decompressing, by a decompressor, the compressed first address data using the second address data.
20. A node for communication system, said node comprising:
a receiver configured to receive a first packet stream and a second packet stream, wherein the first packet stream comprises compressed first address data and the second packet stream comprises second address data, wherein the compressed first address data is based on a comparison of the first address data and the second address data to identify differences between the first and second address data; and
a decompressor configured to decompress the compressed first address data using the second address data and the identified differences between the first and second address data.
26. A computer program embodied on a non-transitory computer readable medium, the non-transitory computer readable medium storing code comprising computer executable instructions configured to control a processor for performing:
receiving, sequentially, at least one packet of a first packet stream and at least one packet of a second packet stream, wherein the first packet stream comprises compressed first address data and the second packet stream comprises second address data, wherein the compressing comprises a comparison of the first address data and the second address data to identify differences between the first and second address data; and
decompressing the compressed first address data using the second address data.
22. A computer program embodied on a non-transitory computer readable medium, the non-transitory computer readable medium storing code comprising computer executable instructions configured to control a processor for performing:
comparing first address data in a first message to second address data included in a second message to identify differences between the first and second address data;
compressing the first address data using the second address data based upon the comparison of the first address data and the second address data; and
transmitting, sequentially, at least one packet of a first packet stream comprising the compressed first address data and at least one packet of a second packet stream comprising the second address data.
16. A communication system, comprising:
a first node comprising a compressor configured to compress address data, wherein the compressor is further configured to:
compare first address data in a first message to second address data included in a second message to identify differences between the first and second address data, and
compress the first address data using the second address data based upon the comparison of the first and the second address data, wherein at least one packet of a first packet stream comprising the compressed first address data and at least one packet of a second packet stream comprising the second address data are transmitted, sequentially, to a second node; and
the second node comprising a decompressor configured to receive the first packet stream and a second packet stream and decompress the first address data using the second address data.
2. A method as claimed in
providing the first address data and the second address data comprising an Internet Protocol address included in a header of a packet.
3. A method as claimed in
4. A method as claimed in
determining if a difference between the first address data and the second address data satisfies a predefined condition.
5. A method as claimed in
providing the predefined condition comprising a predefined level of similarity between the first address data and the second address data.
6. A method as claimed in
satisfying the predefined condition with the first address data and the second address data having similar prefixes.
7. A method as claimed in
8. A method as claimed in
using the second address data as a reference for the first address data.
9. A method as claimed in
communicating from the compressor to a decompressor an indication that the second address data has been used as the reference for the first address data.
10. A method as claimed in
compressing the first address data to provide a compressed address data,
comparing a size of the first address data with a size of the compressed address data, and
using for transmission of an address data either the first address data or the compressed address data having a smaller size.
11. A method as claimed in
sending information between two nodes regarding similarities of the first address data and second address data.
12. A method as claimed in
providing the information regarding similarity in prefixes of the IP addresses.
13. A method as claimed in
providing the information regarding similarity in trailing bits or bytes of the first address data and the second address data.
14. A method as claimed in
15. A method as claimed in
17. A communication system of
19. A node for communication system of
21. A node for communication system of
23. A computer program of
25. A method of
27. A computer program of
|
|||||||||||||||||||||||||||
This application claims priority of U.S. Provisional Application Ser. No. 60/511,662, entitled, “Compressing Header Data,” filed Oct. 17, 2003, the entire contents of which are incorporated herein by reference.
1. Field of the Invention
The present specification relates to compression of data in communication systems, and in particular to compression of address data of a data stream communicated via a data communication system.
2. Description of the Related Art
A communication system can be seen as a facility that enables communications between two or more entities such as user equipment and/or other nodes associated with the communication system. The communication may comprise, for example, communication of voice, data, multimedia and so on.
A communication system typically operates in accordance with a given standard or specification which sets out what the various entities associated with the communication system are permitted to do and how that should be achieved. For example, the standard or specification may define if a circuit switched service and/or a packet switched service is provided. Communication protocols and/or parameters which shall be used for various functions on the system, such as routing, addressing and message formats, may also be defined. In other words, a specific set of “rules” on which the communication can be based on needs to be defined to enable communication by means of the system.
Routing of data packets between entities of a communication system is an important function of packet switched communication systems. In packet switched systems such as the Internet Protocol (IP) based networks a packet stream is routed via the various entities to the destination address based on address information contained in the headers of the packets of the stream.
The header information may be compressed. Header compression is considered as being one of the key techniques to improve spectrum efficiency and performance over wireless links or other links with limited bandwidth. These improvements are believed to be especially important for enabling wireless use of Internet.
In the existing header compression schemes the configuration involves a compressor and decompressor. The compressor receives uncompressed IP packets, divides them into separate streams based on IP address (source address, destination address, or both of these addresses) and possibly other header information (e.g. protocol type of upper layer, source and/or port number of upper layer). For each packet stream, the compressor maintains a compressor context and uses it to compress headers of this packet stream. The header-compressed packets are then communicated from the compressor to the decompressor. Usually, each compressed packet carries an indicator (e.g. context identification) to indicate to the decompressor which context has been used to generate this compressed packet. The decompressor also maintains a decompressor context for each packet stream. Various context synchronization mechanisms are usually used to ensure that a compressed packet can be successfully decompressed. When receiving a header compressed packet sent by the compressor, the decompressor decompresses the header using the correct decompressor context, reassembles the entire packet with the decompressed header, and then forwards the uncompressed packet to next entity, for example to a upper layer, commonly to a local upper layer, or to the next node on the packet path to its destination.
Conventional header compression schemes thus divide packets into packet streams and then compress each packet stream using a compression context established for that stream between a compressor and its peer decompressor. IP addresses are then used to classify a packet stream. Because of this IP packets carrying different IP addresses will be compressed using separate contexts.
A technique called “context replication” has been proposed in the Internet Engineering Task Force (IETF) to allow a new packet stream to be compressed using context of another existing packet stream. This may reduce the synchronization overhead for the new stream when header fields of packets belonging to the two (i.e. the existing and new) streams have the same or similar values. Otherwise, the uncompressed values of those header fields would need to be sent from the compressor to the decompressor to establish context for the new packet stream.
However, replication of contexts cannot be used for handling of IP addresses in all occasions. In particular, the proposal may only allow the context replication of IP addresses only in circumstances where the address data is exactly same between the new and existing packet streams. If there is even a small difference between the addresses, the compressor has to send the address uncompressed. The proposal does not even recognise a case where two packet streams carry substantially similar, but not exactly the same, IP addresses. Therefore the proposal does not enable optimisation that is based on exploitation of the similarity of IP addresses. In other words, the current context replication methods of robust header compression are not able to compress together IP addresses carried in packet streams with almost similar but not identical IP addresses.
Embodiments of the present invention aim to address one or several of the above problems.
According to one aspect of the present invention, there is provided a method for compressing information in a communication system, the method comprising the step of compressing first address data in a first packet stream by using second address data included in a second packet stream.
According to another aspect of the present invention there is provided a communication system comprising a first node provided with a compressor for compressing address data and a second node provided with a decompressor for decompressing address data. The first node is configured to compress first address data in a first packet stream communicated via the first node by using second address data included in a second packet stream.
According to yet another aspect of the present invention there is provided node for communication system. The node comprises a compressor for compressing first address data in a first packet stream communicated via the node by using second address data included in a second packet stream.
According to a yet another aspect of the present invention there is provided a node for communication system. The node comprises a decompressor for decompressing first address data in a first packet stream communicated via the node by using second address data included in a second packet stream.
In more detailed form, the address data may comprise an Internet Protocol address included in a header of a packet.
The compression may be applied to address data comprising at least one of destination address and source address.
The communication system may be configured to determine if a difference between the first address data and the second address data meets a predefined condition.
The second address data may be used as a reference for the first address data.
The embodiments of the invention may advantageously reduce overhead associated with IP addresses during context initialization for header compression. The reduction may be significant for headers whose main content are the source and destination addresses. Foe example, in Ipv6 headers these take 32 bytes out of 40 bytes. The embodiments may also be beneficial for short-lived sessions. The proposed mechanism may be easily applied to various header compression schemes as a feature component. The compressor and decompressor may not require any additional memory, since a reference address required in certain embodiments is already stored in compression context of the existing compression schemes.
For better understanding of the present invention, reference will now be made by way of example to the accompanying drawings in which:
The following describes in a way of examples how first addresses data carried in a packet stream may be compressed using the second addresses data carried in another packet stream. The described embodiment can be used to improve header compression efficiency for example when the two packet streams carry substantially similar but not exactly the same IP addresses. The substantially similar portion may comprise, for example, similar prefix.
In a possible scenario illustrated in
In the following the address of the existing context i.e. the reference address is referred to as ‘ref_addr’. The address of the packet stream wherein the compression is applied to, i.e. the address to be compressed is referred to as ‘cur_addr’. The compressed address of the other packet stream, i.e. cur_addr, will be referred to as ‘comp_addr’.
Examples of
In the following example it is assumed that the compressor node 10 knows that a) the reference context including the ref_adr is established on the decompressor side. Furthermore, it is assumed that b) a compressed packet has means to indicate to the decompressor whether cur_addr in this packet was compressed, and if yes, c) which ref_addr was used as the reference.
Assumption a) is a basic requirement in the current proposal for context replication in IETF. Implementation of assumption b) may require only two bits in the compressed header, one for source address and one for destination address, to indicate if the cur_addr in the packet is compressed. Implementation of assumption c) may also be based on the current proposal on context replication which already provides means to indicate the “base context” that is used to generate current packet. Therefore, no extra information is necessarily needed when compressing current source and destination addresses using the source and destination addresses, respectively, in the base context.
It shall be appreciated that the embodiments are not limited to this. In accordance with a possible alternative, an implementation may choose to have more flexibility, for example, to allow compression of a cur_addr (i.e. either source or destination address in the current packet) by using either the source or destination address in the base context. In that case, one more bit is needed for each cur_addr to indicate the ref_addr in the base context. There are many possibilities as where the aforementioned extra bits, if needed, can be located.
The compressor node 10 may provide two conceptual steps. In step 1 the compressor node 10 decides whether the cur_addr should be compressed using a given ref_addr. In step 2 the compressor node may then perform the actual compression of cur_addr using ref_addr as reference. These steps will now be explained in more detail.
It shall be appreciated that the two steps may not be separated in some practical applications. The step may be run in parallel processes or in a single process. Some parts of Step 2 may also be executed before Step 1.
Compressor Step 1—Decision
The decision may depend on the size of the address. For example, if the size of comp_addr is smaller than that of cur_addr or some threshold value set by implementation, then the compressor may decide that the cur_addr should be compressed using a given ref_addr. The threshold value may be even smaller than the size of the cur_addr.
Typically two factors affect the size of the comp_addr. One factor is the similarity in terms of bit pattern between the cur_addr and ref_addr. The other factor is the encoding overhead for the similarity.
The decision can be made in many ways. Some of the possibilities are discussed below. Note that the given examples are not mutually exclusive and can be combined in implementation.
There are many possibilities to implement the required encoding format. Just a few of them are given below, these being for typical scenarios. In practice, an implementation may support multiple encoding formats and select one of them that yields the smallest comp_addr. In that case, an indicator may be needed either in the comp_addr or using spare bits in the compressed header to inform decompressor which format is used.
In accordance with a first possibility prefix match is used. A compressed IP address could look as shown in
The prefix-len field of the
The trailing-bits field contains the (N—prefix-len) least significant bits in cur_addr, where N is the total length of IP address in units of bits. N=32 for Ipv4 and N=128 for Ipv6. Obviously, prefix-len<N.
The padding field of
The prefix-len field can be encoded in many ways. The simplest method is linear encoding with fixed length. For example, 7 bits prefix-len field (which can cover value range of 128) should be enough for Ipv6 address compression. Other possible, but not limiting examples of suitable methods are variable length encoding or Huffman encoding. These encode the frequently occurring values with fewer bits, while use more bits to present other possible values.
A common configuration for Ipv6 addresses is 64 bits subnet prefix followed by 64 bits interface identifier. For example, the above referenced RFC 3513 specifies: “For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format”. Therefore, this property may be employed in the embodiments by reserving the shortest code point (e.g. 1 bit) for this configuration. The 1-bit prefix-len indication can even be carried using a spare bit that may be available in the compressed header. In that case, the entire cur_addr will comprise only the 64 bits (or 8 bytes) interface ID, which has the good property of byte alignment.
Above format assumes compression is done at bit level. Alternatively, compression can be done at the byte level that may simplify encoding/decoding implementation and reduce processing time. A possible address header wherein the byte level compression may be applied is illustrated in
The prefix-len field gives the length of the prefix in units of bytes that is the same between cur_addr and ref_addr. Note that the common case of 8 bytes (i.e. 64 bits) interface ID (identity) may be encoded more efficiently with the manner described above. For other general cases, fixed length linear encoding would probably be good enough for the prefix-len field, since it only takes 4 bits (or 2 bits) to encode Ipv6 (or Ipv4) address length.
The padding field is an optional field that may be present for byte alignment purpose, i.e., to make trailing-bytes field start at byte boundary. The padding field may also be used as a means to carry signals from the compressor to the decompressor.
The trailing-bytes filed gives the (N—prefix-len) least significant bytes in cur_addr, where N is the total length of IP address in units of bytes. N=4 for Ipv4 and N=16 for Ipv6.
Another possibility is to employ trailing bits/bytes match. For example, an Ipv6 node may use the same interface identifier to generate multiple Ipv6 addresses for that interface, such as link-local unicast address, site-local unicast address and global unicast address. All of these addresses may have the same trailing bits (i.e. the interface identifier) but different prefix. In this case, the compressor can use the same encoding methods as above, except that:
A yet further possibility is to arbitrarily match pattern other than in the above two scenarios. Following is one possible encoding format for compression of Ipv6 addresses as shown in
The bitmask field is used to indicate which byte in cur_addr matches that of ref_addr. If bit at position n is 0 (zero), cur_addr and ref_addr have same value at byte n. Otherwise, they differ at byte n. This field can be generated by applying XOR operation on cur_addr and ref_addr as described in Compressor Step 1 above, except that the XOR is now at byte level.
The byte sequence field is for carrying the original value of each unmatched byte, in the order as they appear in cur_addr. Obviously, each byte in the byte sequence field corresponds to a bit in the bitmask that has value of 1. Therefore, the decompressor can determine the total number of unmatched bytes (i.e. length of this field) and the position of each unmatched byte in the original cur_addr.
This encoding format may also be used for the above described prefix match or trailing bits/bytes match. This may, however, cause higher overhead than the encoding format described with these matches.
The operation of the decompressor will be described next by means of examples.
When receiving a packet with compressed header the decompressor may first check if the source and/or destination IP addresses in the packet have been compressed in accordance with the embodiments of the present invention. If yes, the decompressor may fetch the ref_addr referred to by the packet. If the source and destination addresses are both compressed, they may have used two different ref_addr, one for the source address and another one for the destination address. The decompressor may then regenerate the original IP address (cur_addr) using the corresponding ref_addr and the comp_addr carried in the packet. Specifically, the matched parts (as indicated in comp_addr) will be copied from ref_addr, and unmatched parts from comp_addr. The detailed decoding process depends on the encoding format as described above with reference to the exemplifying compression procedures.
Above described compressor/decompressor procedures are based on various kinds of “direct” differential encoding methods that encode the difference between cur_addr and ref_addr. Another approach could be based on “indirect” encoding. In this scenario the compressor may calculate X=cur_addr XOR ref_addr, and then compress X. As mentioned earlier in compressor step 1, X will reflect the similarity between cur_addr and ref_addr. Therefore, X will contain a sequence of zeros for each matched part between cur_addr and ref_addr. X can be compressed using various methods, e.g. run length encoding. The compressed X may be sent in the header compressed packet. Decompressor then decompresses X, and calculates (X XOR ref_addr). The result will be cur_addr.
Above method uses properties of the XOR function. That is, (a XOR b) XOR b=a, which holds for any value of a and b. In terms of compression efficiency, the approach probably will have similar or slightly less compression ratio than the direct encoding approach. However, it may be preferred in certain implementation where the compression of X can be done fast, for example by means of hardware based solutions. Since XOR operation is fast, that means the total compression/decompression time can be shorter than that of direct encoding approach.
In a typical mobile network a mobile station is allowed to dynamically change its source address. One of the reasons for allowing is privacy, for example, to make it more difficult for eavesdroppers and other information collectors to identify the MS based on IP address. The procedure is sometimes called as stateless address autoconfiguration. However, all of the source addresses used by the MS will have the same prefix as assigned by the gateway node, GGSN. That means for uplink (i.e. from the MS to the remote endpoint), multiple packet streams will have similar source address. For downlink (i.e. toward the MS), destination address will be similar.
A mobile router is another good example of the possible application. The mobile router is a mobile node that is responsible for one or more entire networks moving together, e.g., on an airplane, a ship, a train, an automobile, a bicycle, or a kayak. All of the nodes within the mobile network(s) have IP addresses with same prefix. When the mobile router is connected to other networks via a bandwidth-limited link, header compression is probably needed. A possible application in this context is the Personal Area Network (PAN). PAN may be connected to external networks through a mobile router and via low-bandwidth link. For example, a person can carry a group of BLUETOOTH™ devices which are connected to outside world through a mobile station, for example a mobile phone. Those devices may use IP addresses with same prefix. Header compression and thus this invention can be applied here.
A further exemplifying use is MS accessing multiple servers (e.g. a web servers) that have similar IPv6 address. In this case, the embodiments can be applied to destination address for uplink traffic and source address for downlink traffic. The gain is believed to be particularly significant for IPv6 header compression due to the large size, 16 bytes, of IPv6 addresses.
It shall be appreciated that the above list is not exhaustive. Various combinations of the above examples are also possible. For example, when a node belonging to a network served by a mobile router talks to multiple servers having similar Ipv6 addresses, this invention can be applied to destination and source IP addresses.
It should be appreciated that whilst embodiments of the present invention have been described in relation to mobile stations, embodiments of the present invention are applicable to any other suitable type of communication nodes.
It is also noted herein that while the above describes exemplifying embodiments of the invention, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the present invention as defined in the appended claims.
Liu, Zhigang, Saifullah, Yousuf, Le, Khiem
| Patent | Priority | Assignee | Title |
| Patent | Priority | Assignee | Title |
| 5850526, | Feb 07 1996 | Kingston Technology Company | LAN station for determining the destination LAN station is capable of decompressing by comparing destination address to block of addresses assigned by a LAN manufacturer |
| 6608841, | Dec 30 1999 | Nokia Technologies Oy | System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks |
| 6618397, | Oct 05 2000 | PROVISIONPOINT COMMUNICATIONS, LLC | Group packet encapsulation and compression system and method |
| 6704795, | Oct 12 1999 | Cisco Technology, Inc. | Technique for reducing consumption of router resources after BGP restart |
| 6708166, | May 11 1999 | NORBERT TECHNOLOGIES, L L C | Method and apparatus for storing data as objects, constructing customized data retrieval and data processing requests, and performing householding queries |
| 6711164, | Nov 05 1999 | Nokia Corporation | Method and apparatus for performing IP-ID regeneration to improve header compression efficiency |
| 6754231, | Jun 18 1999 | TELEFONAKTIEBOLAGET L M ERICSSON PUBL | Robust header compression in packet communications |
| 6856599, | Sep 13 2000 | HARRIS GLOBAL COMMUNICATIONS, INC | System and method of reducing retransmission of messages in a TCP/IP environment |
| 7058728, | Oct 29 1999 | Nokia Technologies Oy | Method and apparatus for initiating compression of headers of packets and refreshing the context related to the packets |
| 7193996, | Feb 28 2002 | SILICON VALLEY BANK DBA SILICON VALLEY EAST | System and method for determining a source of an internet protocol packet |
| 7554981, | Nov 26 2003 | Wind River Systems, Inc. | System and method for efficient storage and processing of IPv6 addresses |
| 7792092, | Dec 29 1998 | Nokia Technologies Oy | Data transmission method and a network element |
| 20020118671, | |||
| 20040139070, | |||
| 20040230583, | |||
| 20070110046, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Dec 11 2003 | LIU, ZHIGANG | Nokia Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 014810 | /0420 | |
| Dec 11 2003 | LE, KHIEM | Nokia Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 014810 | /0420 | |
| Dec 11 2003 | SAIFULLAH, YOUSUF | Nokia Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 014810 | /0420 | |
| Dec 18 2003 | NOKIA SOLUTIONS AND NETWORKS OY | (assignment on the face of the patent) | / | |||
| Sep 13 2007 | Nokia Corporation | Nokia Siemens Networks Oy | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 020550 | /0001 |
| Date | Maintenance Fee Events |
| Aug 05 2014 | ASPN: Payor Number Assigned. |
| Dec 22 2017 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Dec 15 2021 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Date | Maintenance Schedule |
| Jul 01 2017 | 4 years fee payment window open |
| Jan 01 2018 | 6 months grace period start (w surcharge) |
| Jul 01 2018 | patent expiry (for year 4) |
| Jul 01 2020 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Jul 01 2021 | 8 years fee payment window open |
| Jan 01 2022 | 6 months grace period start (w surcharge) |
| Jul 01 2022 | patent expiry (for year 8) |
| Jul 01 2024 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Jul 01 2025 | 12 years fee payment window open |
| Jan 01 2026 | 6 months grace period start (w surcharge) |
| Jul 01 2026 | patent expiry (for year 12) |
| Jul 01 2028 | 2 years to revive unintentionally abandoned end. (for year 12) |