CN100433841C - Robustness header compression/decompression method for MIPv6 - Google Patents

Abstract

The present invention relates to a robustness header compression/decompression method for MIPv6, which relates to the internet mobile communication field and belongs to a header compression/decompression according to data flows sent by MIPv6 in wireless mobile environment. The method utilizes an ROHC regulation at both ends of a wireless communication link to compress transmission layer headers and network layer headers adopted in real-time audio and video services transmitted in a network; the method sends complete MIPv6 groups in the initial transmission stage of data flows and selects associated identifiers to correspond to the complete MIPv6 groups according to the characteristic that multiple domains in UDP/IPv6/MIPv6 headers in the same data flow are constant; then, a compression regulation is started; subsequent groups only need to transfer variational header domains and associated identifiers. The present invention defines compression/decompression processes and compressed group formats; simulation indicates that the header compression rate achieves 96%. The present invention effectively compresses header information, has preferable fault-tolerance function, and greatly enhances the channel utilization rate of wireless links.

Description

Robust Header Compression/Decompression Method for Internet Protocol Version 6 Mobility Sub-Protocol MIPv6

Technical field:

The invention relates to the field of Internet mobile communication, and belongs to a header compression/decompression method when sending data streams in a wireless mobile environment according to MIPv6.

Background technique:

Robust Header Compression (Robust Header Compression, referred to as ROHC) is a header compression protocol proposed by the Internet Engineering Task Force (IETF). Header compression mechanism for residual bit errors (RFC3095). ROHC proposes different header compression sub-protocols (profiles) for different protocols. The currently standardized sub-protocols include RTP/UDP/IP, UNCOMPRESSED, UDP/IP, and ESP/IP header models. But there is no header model for MIPv6 yet.

Since the IP packets on the Internet need to find their way according to the IP header information during the forwarding process, if real-time audio and other small packet services are transmitted, the header itself will take up a lot of overhead, thus occupying too much network bandwidth, which will increase the network bandwidth. burden of transmission. For the wired network, this burden will not affect the performance of the network for the time being. However, the transmission bandwidth of the wireless network is relatively narrow, and this burden will have a great impact. In particular, the Mobility Support for Internet Protocol version 6 (MIPv6) which is currently under development requires a larger overhead for the header itself, so header compression is more urgently needed.

Invention content:

The purpose of the present invention is to provide a method for MIPv6 robust header compression/decompression to improve wireless bandwidth utilization when transmitting MIPv6 packets in a wireless environment.

Technical solution of the present invention is as follows:

The method is to carry out the following processing at both ends of the wireless communication link: ① screening MIPv6 packets; and ② performing header compression/decompression on data flow packets encapsulated with UDP protocol; It is the decompressor; the compressor classifies the selected packets according to the state of the information in the packet header field, and then selects the corresponding compression method to compress the header, and then transmits it to the decompressor; the decompressor obtains the enough information, and then revert to the original uncompressed header;

The range of header compression/decompression is the static domain and dynamic domain of the UDP/MIPv6/IPv6 header in the data flow packet; the compressed packet includes the following categories: ①Initialization packet that contains complete MIPv6 packet information; ②Includes Dynamic grouping of dynamically changing header field information; ③Completely compressed grouping containing the association identifier CID;

The working process of the described compression side comprises the following steps: 1. screening: the compression side identifies a flow according to the flow mark and the source address field in the MIPv6 packet; ;②Initialization: For packets belonging to new data streams, set the compressor to work in the initial state, and send initialization packets to the decompressor from the compressor; Dynamic header compression ROHC protocol to send dynamic packets and fully compressed packets;

The working process of the decompression party includes the following steps: 1. For the new data stream, accept the initialization grouping, and establish the decompression association table item; 2. For the grouping that has already established the decompression association table item, use the robust header to compress the ROHC protocol. Decompress, find the decompression association according to the association identifier CID information, and restore the original uncompressed header; ③ According to the selected operation mode in the robust header compression ROHC protocol, decide whether to send a feedback packet to the compressor.

That is to say, the present invention applies robust header compression to the wireless environment of MIPv6, and compresses/decompresses the UDP/MIPv6/IPv6 header of the real-time data flow at both ends of the wireless link, so that the The required header overhead is reduced.

(1) Principle

According to the MIPv6 draft, when a mobile node (Mobile Node, hereinafter referred to as MN) sends a packet to a correspondent node (Correspondent Node, hereinafter referred to as CN), the source address in the IPv6 packet header is the care-of address (Care-of Address) of the MN. ). In order to include the home address (HomeAddress) that uniquely identifies the MN in the packet, the packet sent by the MN must have a destination option header (Destination OptionHeader) that includes the home address. The packet sent from the CN to the MN is in the form of a routing header, that is, the destination address of the packet is the care-of address of the MN, and the routing header contains the home address of the MN. As shown in Figure 1. For convenience, we refer to these two headers stipulated in the MIPv6 protocol as MIPv6 extension headers.

Due to the low transmission rate and high bit error rate of the wireless link, the overhead of transmitting the IPv6 packet header on the wireless network is too large. For example, the payload of a frame of audio data is usually only 15-32 bytes, and the transmission of this data in the MIPv6 environment requires a 40-byte IPv6 header, a 20/24-byte MIPv6 header, and 8 bytes of transport layer user data UDP protocol (UDP) header, the header overhead of UDP/MIPv6/IPv6 is 68/72 bytes in total, if the communication peer is also MN, then the combined header overhead of IP/UDP/RTP of the packet is 92 bytes Festival. This not only occupies bandwidth, but also increases the probability that packets will be discarded due to errors.

In fact, during the transmission process, many fields of the IPv6 header of the packets of the same data flow are the same, and only a few fields are dynamically changed. In addition, each field in the MIPv6 header is statically unchanged. Therefore, if only a complete MIPv6 packet and the corresponding option header are sent at the beginning of a data flow on the wireless link, the header field of the subsequent packet only transmits the changed part and the associated identifier relative to the same flow, so that Bandwidth can be used more effectively.

Since header compression needs to preserve the state of the compressor and the decompressor, header compression is only applicable to data streams with a long duration and multiple packets, and it is meaningless for header compression of a single packet. Generally speaking, real-time audio and video streams are long data streams sent in the form of UDP packets, so the present invention only compresses the UDP/MIPv6/IPv6 headers in the MIPv6 packets.

(2) MIPv6 header compression/decompression method

The application of ROHC under MIPv6 conditions in the wireless link is shown in Figure 2:

The mobile node MN at one end of the wireless link and the radio network controller RNC (Radio Network controller) at the other end are used as nodes performing ROHC compression/decompression. On the wireless link between MN and RNC, MIPv6 packets compressed by the ROHC protocol are transmitted, and on the wired link between RNC and CN, ordinary MIPv6 packets are transmitted. Both MN and RNC can perform both compression and decompression. For a stream, its compressor and decompressor are located at both ends of the wireless link (that is, MN and RNC), the compressor is at the sender, and the decompressor is at the receiver.

The specific compression/decompression method is as follows:

The working process of the compressor includes the following steps:

① Screening. The compressor identifies a flow according to the flow mark and the source address field in the MIPv6 packet; then, filters out the packets containing the data flow of the UDP/MIPv6/IPv6 header;

②Initialization. For the packets belonging to the new data stream, the compressor work is set to the initial state (IR: Initialization and Refresh), and the compressor sends the initialization packet to the decompressor. In addition to the information of the MIPv6 packet itself, the initialization packet also includes additional information such as a subprotocol field (profile ID) and a context ID (CID for short). Profile ID is a specification for pointing out how to carry out header compression to specific packet flow (in the present invention, for UDP/MIPv6/IPv6 packet flow) on a specific link. The CID is used to make the decompressor index the associated content of the stream in the storage association table (the association table contains the information of each field in the packet), and it is unique in the channel through which the compressed packet is transmitted. The compressor/decompressor maintains an association table entry for each data stream.

③ Start the compression procedure. For the packet of the data flow that has already established the initialization information, the dynamic packet and the fully compressed packet are sent according to the ROHC regulation. At this time, according to the specific situation of the group, it should be processed according to the ROHC regulations. Different processing methods are used for different types of fields in the group. The following analyzes the header format of the packet communicated between the MN and the CN.

As shown in the table below, many fields in the packet header in the IPv6 data stream are constant (such as source/sink address, source/sink port, etc.), which are called static fields; some fields may change occasionally ( Such as traffic level, relay point limit); some fields are changed irregularly (such as UDP checksum). When compressing, each field in the header should be classified first, and then different processing methods should be adopted for different types of fields.

Table 1: Basic headers for IPv6

area static Version, stream mark, next header, source address, sink address dynamic Traffic level, relay point limit

Table 2: Extension headers of MIPv6

area static Sink options header and wayfinding header related to home address dynamic none

Table 3: UDP headers

area static Source port, sink port, dynamic checksum

Static fields are generally not sent in compressed packets. The dynamic domain can be sent only when it is changed. At this time, a dynamic packet is used, which contains CID information, dynamically changing header domain information and data domain information; fully compressed packets generally do not change in the dynamic domain Send it down, mainly including CID information. For details, see the sub-protocol format description section.

Therefore, compressed packets include the following categories:

① An initialization packet containing complete MIPv6 packet information;

②Dynamic grouping containing dynamically changing header field information;

③Completely compressed packet including CID.

The working process of the decompressor includes the following steps:

①For the new data stream, accept the initialization packet, and establish the decompression association table item; ②For the group that has already established the decompression association table item, use the ROHC procedure to decompress, find the decompression association according to the CID information, and restore the original uncompressed header ③ According to the operation mode in the selected ROHC regulations, decide whether to send feedback packets to the compressor.

The feedback packet is used to tell the compressor whether the packet is successfully decompressed, and mainly includes CID information, feedback flag information and information on whether the decompression is successful.

(3) MIPv6 header compression sub-protocol

According to the above-mentioned method of using ROHC framework for MIPv6 packet header compression, and the formats of initialization packet, dynamic packet, fully compressed packet, and feedback packet defined by RFC3095, the present invention proposes the MIPv6 header compression sub-protocol.

① Define the format of the profile ID compressed by the MIPv6 header as 0x000a. The format of the CID is defined in accordance with RFC3095.

②Since there is no sequence number in the UDP/MIPv6/IPv6 header or the packet number field (IP-ID) in the IPv4 packet, the compressor should randomly generate a 2-byte (16-bit) sequence number SN as a sign of feedback. When sending, it is compressed into a value calculated using the W-LSB (Window-based LSB encoding) algorithm.

③ The format of the initialization packet is also defined in accordance with RFC3095, which includes the content of the extended header of MIPv6. Its specific format is shown in Figure 3.

④According to the definition of RFC3095, there are three main types of dynamic grouping and fully compressed grouping, which are respectively defined as type 0, type 1, and type 2. Type 0 is a fully compressed packet, sending only the serial number SN (or plus cyclic redundancy check and CRC); type 1 contains parameters used to update the SN function; type 2 is a dynamic packet, including information used to update the dynamic domain . Since the function of SN in the present invention is constant, there is no type 1 compressed packet.

Moreover, ROHC has three operating modes: Uni-directional (U-mode for short), Bi-directional Optimistic (O-mode for short), and Bi-directional Reliable (R-mode for short). ). U-mode is used when no feedback channel exists or cannot be used, in which case packets are sent in only one direction, from the compressor to the decompressor. The purpose of O-mode is to provide a high degree of compression efficiency with reasonable robustness. R-mode provides full robustness, but with slightly higher overhead and more feedback messages. The two modes of O-mode and R-mode have more frequent feedback, and both the compression side and the decompression side have strict logic to detect whether the association is synchronized.

For different working modes, the compressed packet formats are generally different. Therefore, the naming of grouping types here follows the format: mode-type-property. For example: R-0 refers to R-mode, type 0 compression packet; UOR-2-Prio refers to the type 2 compression packet, applicable to all working modes, and the compression header contains Prio (priority ) change information.

Therefore, the dynamic grouping of the MIPv6 sub-protocol proposed by the present invention and the fully compressed grouping format are as follows:

Type 1: Type 0 (There are two formats)

The R-0 format is shown in Figure 3, and SN is a compressed value of 6 bits.

The UO-0 format is shown in Figure 4, SN is a 4-bit compressed value, and a 3-bit CRC is added.

Type 2: Type 2 (There are two formats)

There are 6-bit SN and 7-bit CRC. When F=0, it means that the packet is UOR-2-Prio (as shown in FIG. 5 ), and when F=1, it means that the packet is in UOR-2-Hop format (as shown in FIG. 6 ).

When the priority in the packet header changes, a UOR-2-Prio packet should be sent, and the changed priority should be written into the Priority field.

A UOR-2-Hop packet shall be sent when the hop limit in the packet header changes. Write the changed relay point limit into the Hoplimit domain.

(4) Effect

In order to test the compression effect of the present invention on the MIPv6 packet, we have adopted the NS-2 simulation tool to simulate the header compression of the MIPv6 packet of voice and video services.

The voice service is a classic service on the wireless link, and in 3G, the multimedia service will also be a major part. The speech service simulated by the present invention is adaptive multi-rate (AMR: Adaptive Multi Rate) coded standard speech, and the generation rate of speech data is 12.2 kb/s, one frame every 20 milliseconds. The video service adopts the MPEG-4 standard, the sending rate of the video data is 48kb/s, and 10 frames are sent per second. The wireless link delay is 100 milliseconds, and the bit error rate is 10 ^-4 ~ 10 ^-2 b/s.

Let avg_header_len represent the average header length of the packet, total_bytes represent the total number of bytes sent (including various types of compressed packets and their feedback), decomped represents the number of successfully decompressed packets, and payload_len represents the payload size in the packet (the same The payload length of the flow is the same), the calculation formula of the average header length is:

avg_header_len=(total_bytes-decomped×payload_len)÷decomped

Table 4 and Table 5 show the compressed average header lengths (unit is byte) of voice service and video service streams of different lengths under the condition that there is no error in the wireless link. It can be known from the table that when the total business volume is greater than 1000 packets, the average header length of the ROHC protocol tends to be stable. Comparing Table 4 and Table 5, since the grouping interval of the voice service is short (20ms), the grouping interval of the video service is long (100ms), and the header compression protocol is related to time (slow start mechanism, timeout mechanism), so the average overhead Not the same.

Table 4: Average header length for audio services (in bytes)

Table 5: Average header length of video services (in bytes)

The simulation results show that the compression ratios in different modes are all greater than 96%. Using ROHC to compress the header of MIPv6 packets can greatly improve the efficiency of packet transmission. The MIPv6 sub-protocol applying ROHC header compression can better adapt to the characteristics of low transmission rate and high bit error rate of wireless links. The application of the invention is beneficial to improving the bandwidth utilization rate in the wireless environment.

Description of drawings:

Fig. 1 is the packet header format when MN communicates with CN;

Fig. 2 is the schematic diagram that MIPv6 grouping is transmitted in the network;_

Fig. 3～7 is the schematic diagram of MIPv6 header compression sub-protocol; The specific format of all dynamic domains, static links and dynamic links is formulated according to RFC3095 (due to its variable length, it is represented by a dotted line box); Figure 4 is the R-0 packet format; Figure 5 is the UO-0 packet format; Figure 6 is the UOR -2-Prio packet format; Figure 7 is the UOR-2-Hop packet format; among them, the packet format adopted is the case of small CID, if there is a large business data flow that needs to be compressed, the large CID method will be adopted, The method of adopting a large CID is to insert an enhanced CID domain of 1 to 2 bytes behind the current small CID.

Figure 8 is the workflow of the compressor;

Figure 9 is the workflow of the decompressor.

Detailed ways:

Embodiment of the present invention is realized under Linux operating system, and main implementation process is as follows:

Add the software written according to the above method and sub-protocol at the sending and receiving interface of the Linux network link layer as the processing module of the compressor and the decompressor to form the corresponding compressor and decompressor, and group the specific data stream sent out performing compression and simultaneously decompressing the received compressed data flow packet.

Fig. 8 is an example of the basic flow of the MIPv6 compressor implemented according to the method proposed by the present invention. The compressor first extracts the header of the packet, and then judges whether it is a UDP/MIPv6 packet, and compresses the header of the MIPv6 packet using the UDP transmission protocol. If the packet is the first packet of the data flow, then create a compression association for the flow, send an initialization packet, and start the compression initialization procedure; if the packet belongs to a data flow that has already created a compression association, then according to its state Perform compression, the format of the compressed packet is shown in Figure 3-7, and then send the compressed packet through the network interface.

Fig. 9 is an example of the basic flow of the MIPv6 decompressor implemented according to the method proposed by the present invention. For the data stream packet received from the network interface, the decompressor will judge whether the data packet is a MIPv6 header compressed packet, and if so, read the CID, and search for the corresponding associated table item to decompress according to the CID. Then, the feedback information is processed according to whether the decompression result is correct or not, and the corresponding compressor performs necessary operations according to the relevant feedback information.

Claims (1)

1, a kind of robust header compression/decompression method that is used for the 6th edition mover agreement MIPv6 of Internet Protocol is characterized in that:

This method is to carry out following processing at the two ends of wireless communication link:

1. grouping is screened to MIPv6; And

2. to carrying out header compression/decompress(ion) with the data stream packet of udp protocol encapsulation;

Wherein, transmit leg is compression side, and reciever is a decompressor;

Classify according to the state of information in the packet header territory to selected grouping in compression side, select corresponding compression method to carry out header compression then after, send decompressor to; Decompressor obtains enough information according to the leader after compressing, and reverts to the leader of original uncompressed then;

The scope of header compression/decompress(ion) is the static fields and the dynamic domain of the UDP/MIPv6/IPv6 leader in this data stream packet;

Grouping after the compression comprises following classification:

1. the initialisation packet that has comprised complete MIPv6 grouping information;

2. the Dynamic Packet that has comprised the leader domain information of dynamic change;

3. the complete compressed packet that has comprised related identifier CID;

The course of work of compression side comprises the steps:

1. screening: the compression root is discerned a stream according to flow label, source address territory in the MIPv6 grouping; Then, filter out the grouping of the data flow that contains the UDP/MIPv6/IPv6 leader;

2. initialization: for the grouping that belongs to new data flow, the work of the side of compression is arranged on initial condition, the compression direction decompressor sends initialisation packet;

3. rules are compressed in startup: for the grouping that the data flow of setting up initialization information is arranged, send Dynamic Packet and complete compressed packet according to robust header compression ROHC rules;

The course of work of decompressor comprises the steps:

1. for new data flow, accept initialisation packet, set up the related list item of decompress(ion);

2. for the grouping of setting up the related list item of decompress(ion), utilize robust header compression ROHC rules to carry out decompress(ion), search the decompress(ion) association, revert to the leader of original uncompressed according to related identifier cid information;

3. according to the operator scheme in the selected robust header compression ROHC rules, whether decision sends feedback packet to compression side.

Images