CN1889575B - A Method of Realizing Header Compression and Multiplexing in IP Layer - Google Patents

Abstract

The invention discloses a method for realizing header compression and multiplexing at the IP layer. The business message of the UDP port number is used as a multiplexing subframe, and the UDP multiplexing header is added to the front of the multiplexing subframe, and more than one multiplexing subframe carrying the UDP multiplexing header is encapsulated in the same IP packet, and add an IP header to the header of the IP packet. The invention improves the transmission efficiency, reduces the requirement on the transmission bandwidth, reduces the operating cost of the operator, reduces the number of packets forwarded on the transmission network, and reduces the requirement on the processing capacity of the router.

Description

A Method of Realizing Header Compression and Multiplexing in IP Layer

technical field

The invention relates to compression and multiplexing technology, in particular to a method for realizing header compression and multiplexing at the IP layer.

Background technique

In wireless communication systems, all-IP is a development trend. IP can use resources more efficiently, and the use of packet switching technology can achieve more sharing than the use of time slot switching technology, thereby reducing the cost of unit transmission.

For example, in the CDMA2000 system, the IP/UDP protocol stack is used to carry services between the centralized base station controller (CBSC) and the centralized base transceiver station (CBTS), wherein each service channel uses a source user datagram The protocol (UDP) port number and the destination UDP port number are represented by a pair, plus the difference in IP address, different channels correspond to different {source IP address, source UDP port number, destination IP address, destination UDP port number} groups.

Fig. 1 is the format of each field of the existing IP data packet header, wherein, the protocol version is the version number of the IP protocol, which can be IPv4 or IPv6; the header length is the length value of the IP data packet header; the service type is used to indicate the IP data The service priority of the packet; the lifetime sets the maximum number of routers that the IP packet can pass through, that is, the lifetime of the IP packet; the total length field refers to the length of the entire IP packet, in bytes, using the header length field and the total length field, you can know the starting position and length of the data content in the IP data packet; the identification field uniquely identifies each data packet sent by the host, and usually the value of this field will increase by 1 each time a message is sent ; The flag field and slice offset field are used for fragmentation and reassembly; the protocol domain field indicates the upper layer protocol type of the IP packet; the header checksum field is the checksum code calculated according to the IP header.

Figure 2 is the format of each field of the existing UDP data packet header, wherein the content of the UDP length field is the length value of the entire UDP data packet, and the content of the checksum field is the checksum specified in the protocol according to the entire UDP data packet The checksum code computed by the algorithm.

At present, the IP-based wireless communication system has the problem of low efficiency when transmitting service packets. For example, in the CDMA2000 system, voice service packets are transmitted in 20ms frames. In this way, every 20ms voice service packets The length is smaller, and Table 1 shows the packet lengths of various speech coding types in CDMA2000:

Table 1

It can be seen from Table 1 that the average voice packet length is 8.28 bytes when using the QCELP 8K coding method; the average voice packet length is 8.68 bytes when using the enhanced variable frequency coding (EVRC) method; The length is 15.7 bytes. Since the IP header has 20 bytes and the UDP header also has 8 bytes, it is obvious that the voice transmission efficiency on the Abis interface between the BSC and the BTS in the CDMA2000 system is relatively low. Using the QCELP 8K coding method, the average transmission efficiency is about 22.8%; using the EVRC coding method, the average transmission efficiency is about 23.7%; using the Q13K coding method, the average transmission efficiency is about 35.9%.

Similarly, in other wireless communication systems, such as the WCDMA system, there are also problems similar to those of the CDMA2000 system. It can be seen that the transmission efficiency of service packets in the current wireless communication system is low, and the bandwidth is relatively large, which greatly reduces the benefits brought by the transformation of IP into the wireless communication system.

Contents of the invention

The purpose of the present invention is to propose a method for realizing header compression and multiplexing at the IP layer, so as to improve the efficiency of transmission and bearing.

To achieve the above object, the invention provides a method for realizing header compression and multiplexing at the IP layer, comprising the following steps:

Compress the UDP header of the IP data packet transmitted at the IP layer into a UDP multiplexing header, use the service message with the same source UDP port number and destination UDP port number as a multiplexing subframe, and Adding the UDP multiplexing header at the end, encapsulating more than one multiplexing subframe carrying the UDP multiplexing header in the same IP packet, and adding an IP header to the IP packet header.

Said steps are also preceded by:

a. The receiver sends a negotiation request message requesting header compression and multiplexing to the sender;

b. The sender returns a negotiation response message to the receiver, and the message carries a connection identifier of the connection between the sender and the receiver;

c. The receiver sends a negotiation confirmation message to the sender to confirm the header compression and multiplexing;

d. The sender configures multiplexing parameters to the user plane, and the user plane completes header compression and multiplexing of service packets.

Also include the following steps before the step a:

The sender and the receiver respectively establish a mapping table of the corresponding relationship between the connection identifier, the source port number of the sender, and the destination port number of the receiver.

In step d, the sender configures the multiplexing parameters to the user interface and performs the following steps:

Set the maximum subframe length for multiplexing, and the multiplexing subframe of the service message will not be multiplexed after exceeding this length;

Set the maximum multiplexing time. From the moment of multiplexing, the service packets must be sent out before the maximum multiplexing time is exceeded.

The header compression described in step d specifically performs the following steps:

The source UDP port number and the destination UDP port number are replaced by the connection identifier; the length field and the checksum field of the UDP header are deleted.

After said step d, also include the process of stopping header compression and multiplexing, specifically perform the following steps:

e1. The receiver sends a negotiation request message requesting to stop header compression and multiplexing to the sender;

e2. The sender returns a negotiation response message to the receiver, and the message carries the connection identifier of the connection between the sender and the receiver;

e3. The receiver sends a negotiation confirmation message to the sender, confirming to stop the header compression and multiplexing.

After the compression and multiplexing of the IP data packet is completed, the checksum code of the IP data packet is added at the end of the IP data packet.

The negotiation request message and the negotiation confirmation message include a flag field, a compression multiplexing start field, a message length field and a reserved field.

The negotiation response message includes a flag field, a compressed multiplexing confirmation field, a connection identification field and a reserved field.

In the present invention, by compressing the UDP header into a UDP multiplexing header, the business message with the same source UDP port number and destination UDP port number is used as a multiplexing subframe, and a UDP multiplexing header is added to the front of the multiplexing subframe, and Encapsulate multiple multiplexing subframes with UDP multiplexing headers in the same IP packet, so that multiple service messages share the UDP header and IP header, increasing the proportion of service messages in the transmission packet, thereby The transmission efficiency is improved, the requirement for transmission bandwidth is reduced, the operator's operating cost is reduced, the number of packets forwarded on the transmission network is reduced, and the requirement for router processing capability is reduced.

Description of drawings

Fig. 1 is the structural diagram of each field of IP packet header in the prior art;

Fig. 2 is the packet header structural diagram of UDP packet in the prior art;

FIG. 3 is a flowchart of a method for implementing header compression and multiplexing at the IP layer in an embodiment of the present invention.

Detailed ways

The basic thought of the present invention is: when IP layer transmits business message, compresses UDP header into UDP multiplex header, uses the business message with same source UDP port number and purpose UDP port number as multiplexing subframe, in this The front part of the multiplexing subframe is added with the UDP multiplexing header, and multiple multiplexing subframes carrying the UDP multiplexing header are encapsulated in the same IP packet, so that multiple service messages share the UDP header and the IP header , thereby improving transmission efficiency, reducing requirements on transmission bandwidth and operating costs.

In the present invention, the IP data packet header does not support optional items, and uses fixed options, that is, the optional item field shown in FIG. 1 is not used.

The realization of the header compression and multiplexing method in the present invention includes two parts: a control plane and a user plane, wherein the control plane is used to complete compression multiplexing startup and negotiation of compression multiplexing parameters, and the user plane is used to complete header compression and multiplexing. The protocol type value filled in the protocol field field of the IP packet header for the control plane protocol is 23, and the protocol type value filled in the protocol field field of the IP packet header for the user plane protocol is 24.

Since each session adopts {source IP address, destination IP address, source UDP port number, destination UDP port number} group identification, and this identification has been determined when each session is established, when the subsequent session is transmitted, These addresses are all repeated, so it should be possible to compress the logo. However, according to the IP protocol, IP addresses must be used when transmitting data packets at the IP layer, otherwise the transmitted data packets will be discarded, so, The realization principle of the header compression in the present invention is: the source IP address and the destination IP address are not compressed, only the source UDP port number and the destination UDP port number are compressed.

The specific compression method is: at the sender, compress the 16-bit source UDP port number and the 16-bit destination UDP port number shown in Figure 2 into a connection identifier (SID), that is, replace the source UDP port number and the destination UDP port number with the SID , the receiver recovers the source UDP port and destination UDP port number according to the SID. In addition, the 16-bit UDP length field is deleted, because the receiver can calculate the length of the UDP data packet according to the length of the UDP header and the length of the message. In addition, the 16-bit checksum field is set as an optional item. In the case that the link layer has provided checksum, the checksum field can be omitted. For example: if the IP protocol is carried on the PPP link, because the PPP link The checksum itself already exists, and the checksum already includes the IP/UDP header. At this time, the checksum of the UDP header can be ignored.

Compressed UDP header is called UDP multiplexing header in the present invention, and its structure is as shown in table 2:

LXT SXT 6-bit or 14-bit LEN 8-bit or 16-bit SID

Table 2

Among them, the LXT flag field is 1 bit, which is used to indicate whether the LEN field is 6 bits or 14 bits;

The SXT flag field is 1 bit, which is used to indicate whether the length of the SID field is 8 bits or 16 bits;

SID is the connection identifier, which must be consistent between the receiving and sending parties. The connection identifier is obtained during the negotiation phase and used in the multiplexed message;

LEN is the subframe length, that is, the length of the multiplexed subframe, and the length does not include the SID and LEN itself. In the present invention, the implementation principle of header multiplexing is: under the condition of not exceeding the maximum length of the IP data packet stipulated in the protocol, the data packets with the same source IP address and destination IP address are encapsulated in the same IP data packet, and the multiplexed An IP header; the IP data packet with the same source UDP port number and destination UDP port number is used as a multiplexing subframe and added to the UDP multiplexing header.

In addition, due to the problem of bit errors in the link transmission, it is necessary to check the errors in the transmission, and the checksum of the IP header only covers the part of the IP header. Therefore, in order to correctly protect the multiplexed packets and reduce the verification overhead, it is A checksum bit is added at the end of the multiplexed packet. The checksum is similar to the checksum in the header of the UDP packet and covers the header of the multiplexed packet and all subframes. The checksum is a 16-bit value, similar to the UDP checksum. If the sender sends 0 in the checksum field, it means that there is no checksum. Under this condition, the receiver does not need to calculate the checksum.

The IP packet format after multiplexing is shown in Table 3:

IP header UDP multiplexing header multiplexing subframe UDP multiplexing header multiplexing subframe ... checksum

table 3

After the header compression and multiplexing are realized, the header part of the IP data packet needs to be modified. The specific modification is: because the original multiple service packets are encapsulated in one IP data packet, the total length has changed. Re-fill the total length field in the IP packet header with the new total length; in addition, because the number of IP data packets has also changed, it is necessary to re-fill the identification field according to the provisions of the IP protocol; since the header compression and multiplexing are implemented on the user plane Therefore, the type value filled in the protocol field is 24; finally, the header checksum must be recalculated according to the modification of the above fields, and the calculation method is the same as the checksum algorithm specified in the existing IP protocol.

Fig. 3 is the flow chart of the method for realizing header compression and multiplexing at the IP layer in an embodiment of the present invention, specifically perform the following steps:

Step 301 , the receiver sends a negotiation request message requesting compression and multiplexing of the IP header and the UDP header to the sender. The negotiation request message is initiated by the receiver. If the receiver supports compression and multiplexing, it will initiate the negotiation request during the call establishment process. The format of the negotiation request message is shown in Table 4:

Table 4

Wherein, the length of the FLAG domain is 6 bits, and when the value of the FLAG domain is 1, it means that the message is a negotiation request message (MUX REQUEST);

The length of the MON/MOFF field is 1 bit. When MON/MOFF=0, it means that the negotiation request disables the compression multiplexing function; MON/MOFF=1 indicates that the negotiation request enables the compression multiplexing function;

The 16-bit reserved field (reserved) is not used for the time being, and will be expanded in subsequent versions of the protocol.

Step 302: The sender returns a negotiation response message to the receiver, and the negotiation response message carries the connection identifier of the connection established between the sender and the receiver. The negotiation response message is sent by the sender. It is a message used to confirm the negotiation request. It is divided into an agreement (ACK) message and a disagreement (NAK) message. The format of the negotiation response message is shown in Table 5:

table 5

Wherein, the length of the FLAG field is 6 bits, when the value is 2, the message is identified as an ACK message, and when the value is 3, the message is identified as a NAK message;

The length of the MON/MOFF field is 1 bit. If the message is negotiated off, the value of MON/MOFF is set to 1. If the message is negotiated, the value of MON/MOFF is set to 0;

The length of the SXT field is 1 bit. When the value is 0, it means that the SID is 8 bits, and when it is 1, it means that the SID is 16 bits;

The SID is the connection identifier determined by the sender. When the SID is 8 bits, 8-bit padding is required to ensure 4-byte alignment. In the present invention, a connection identifier (SID) is used to identify different connections, and the SID is unique on a point-to-point connection link, numbered from 0 by the sender. This embodiment sets up the mapping table of SID and source UDP port number and purpose UDP port number at link two ends, replaces source UDP port number and purpose UDP port number with SID, thereby completes the source UDP port number and purpose UDP port number of compression.

The subsequent 16-bit source port number and destination port number are the source port number and destination port number corresponding to the SID.

If the negotiation response message is a NAK message, it means that the negotiation is not agreed, and the unapproved parameters are returned to the receiver, and the receiver adjusts these parameters and then sends the negotiation request again.

Step 303 , the receiver sends a negotiation confirmation message to the sender to confirm the compression and multiplexing of the IP header and the UDP header. The format of the negotiation confirmation message is the same as that in Table 4, wherein the length of the FLAG field is also 6 bits, but the value is 4; the length of the MON/MOFF field is also 1 bit, and the value of this field is 1, otherwise 0.

The protocol in the above steps is the control plane protocol, and the protocol number filled in the protocol field of the IP packet header is 23.

Step 304, the sender configures multiplexing parameters to the user plane, that is, enables compression multiplexing. The following multiplexing parameters need to be set:

F_MAX_SUB_LEN: The maximum subframe length for multiplexing. When this length is exceeded, multiplexing will not be performed;

F_MAX_MUX_TIME: The maximum multiplexing time, starting from the start of multiplexing, before this time, the packet must be sent out, this parameter avoids excessive delay and jitter caused by multiplexing;

A mapping table of the corresponding relationship between SID, source UDP port number and destination UDP port number.

Step 305, performing header compression and multiplexing of service packets on the user plane.

When the user plane of the sender confirms that the message has no options, it compresses and multiplexes the IP header and UDP header. The specific compression and multiplexing methods are as described above.

The receiver decodes according to the protocol field of IP, if the data packet is a multiplexed packet, unpacks it according to LXT and SXT, and restores the packet according to the relationship between the saved SID and UDP port number.

If the receiving party wants to stop packet compression and multiplexing, it uses a process similar to steps 301 to 303 for negotiation. At this time, the control plane message sent by the receiving party is a negotiation request message requesting to stop the multiplexing of the IP header and the UDP header. , the MON/MOFF field is set to 0.

Finally, it is noted that the above embodiments are only used to illustrate the technical solutions of the present invention without limitation. Although the present invention has been described in detail with reference to the embodiments, those of ordinary skill in the art should understand that the technical solutions of the present invention can be modified or equivalent replacement without departing from the spirit and scope of the technical solutions of the present invention.

Claims (8)

1. realize a head compression and a multiplexing method at the IP layer for one kind, it is characterized in that, may further comprise the steps:

Will be at UDP the multiplexing head of boil down to UDP of the IP packet of IP layer transmission, the service message that will have identical sources udp port number and purpose udp port number is as multiplexed sub frame, and add the multiplexing head of described UDP in the front portion of this multiplexed sub frame, the multiplexed sub frame that carries the multiplexing head of UDP more than one is encapsulated in the same IP bag, and adds the IP head at described IP packet header;

Also comprise before the described step:

A, receive direction transmit leg send request and carry out head compression and multiplexing message of negotiation request;

B, the described recipient of sending direction return the negotiation response message, carry the connection identifier that is connected between described transmit leg and the described recipient in this message; Identify different connections with this connection identifier, it is unique that this connection identifier connects on the link at a point-to-point, set up the mapping table of connection identifier and source udp port number and purpose udp port number at both link ends, replaced source udp port number and purpose udp port number with connection identifier;

C, the described transmit leg of described receive direction send consults confirmation message, confirms to carry out described head compression and multiplexing;

D, described transmit leg are configured to user's face with multiplexing parameters, are finished a compression and multiplexing of service message by described user's face.

2. according to claim 1 in an IP layer realization head compression and a multiplexing method, it is characterized in that described step a is before further comprising the steps of:

Connect the respectively mapping table of corresponding relation between sign and the source port number of transmit leg and recipient's the destination slogan of transmit leg and recipient.

3. according to claim 2ly realize a head compression and a multiplexing method, it is characterized in that transmit leg described in the steps d is configured to the mask user body with multiplexing parameters and carries out following steps at the IP layer:

Multiplexing maximum subframe lengths is set, and the multiplexed sub frame of described service message is multiplexing above no longer carrying out after this length;

The maximum multiplexing time is set, counts,, service message must be sent surpassing described maximum before the multiplexing time from beginning the multiplexing moment.

4. describedly realize a head compression and a multiplexing method according to claim 1,2 or 3, it is characterized in that the concrete following steps of carrying out of the compression of head described in the steps d at the IP layer:

Replace source udp port number and purpose udp port number with described connection identifier; Length field and the verification and the territory of deletion UDP head.

5. describedly realize a head compression and a multiplexing method according to claim 1,2 or 3, it is characterized in that, also comprise after the described steps d stopping a head compression and a multiplexing process, specifically carry out following steps at the IP layer:

E1, receive direction transmit leg send request and stop head compression and multiplexing message of negotiation request;

E2, the described recipient of sending direction return the negotiation response message, carry the connection identifier that is connected between described transmit leg and the described recipient in this message;

E3, the described transmit leg of described receive direction send consults confirmation message, confirms to stop described head compression and multiplexing.

6. according to each describedly realizes a head compression and a multiplexing method at the IP layer in the claim 1 to 3, it is characterized in that, finish to the compression of described IP packet multiplexing after, add the verification and the sign indicating number of this IP packet at the afterbody of described IP packet.

7. describedly realize a head compression and a multiplexing method according to claim 1,2 or 3, it is characterized in that, described message of negotiation request and consult confirmation message and comprise mark domain, the multiplexing startup of compression territory, message length territory and keep the territory at the IP layer.

8. describedly realize a head compression and a multiplexing method according to claim 1,2 or 3, it is characterized in that described negotiation response message comprises mark domain, the multiplexing affirmation of compression territory, connection identifier territory and keeps the territory at the IP layer.

Images