SE522063C2 - Bit error reduction in IP protocol stacks, introduces protection for packet head at link layer's head compression level - Google Patents

Abstract

Each packet in the link layer in the stack is analyzed in order to determine whether it has a complete head or not. If the head is complete, the link layer's control sum evaluation is used as normal to reject the defective packet. If the packet has a compressed head, the link layer's control sum evaluation is ignored and the packet is propagated upwards in the stack. In order to compensate for the control sum evaluation being ignored, one or more local sums are used to introduce a head protection at the link layer's head compression level. The IP-protocol stack is based on a secure link layer in which the packet flow is head-compressed according to a suitable head compression standard.

Description

'1 522 oss u 0 I. ; o a - a | o now the 2 Line Procedure Protocol (HDLC) and often for lethal links over dial-up telephone lines where PPP links are established between users and service providers.

IP-based network applications generally retrieve network resources through two interfaces, the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). Both of these protocols are located in the transport layer between the applications on the application layer and the internet protocol on the network layer. While TCP is a connection-oriented protocol with features for providing reliable data delivery, UDP is a connection-free protocol without the reliability present in TCP. UDP provides applications with a direct interface to the Internet Protocol and the ability to turn to a dedicated application process running on a host without establishing a connection session, as required by TCP. In many cases, when an entire transmission can be performed through only a few UDP packets, UDP provides much more efficient communication compared to TCP. Creating a TCP session would take far too long in relation to the data to be transmitted. In addition, applications and protocols designed for the delivery of delay-sensitive real-time data such as speech or image typically use UDP as their transport layer protocol. If a packet of speech or picture is lost, retransmission is usually not practically possible because the retransmitted information would be out of sync with current data.

Consequently, the acknowledgment and retransmission services offered by TCP have low practical value for delay-sensitive real-time data, and UDP is used instead.

To improve the transmission efficiency in general and for PPP links with low speed and medium speed in particular, various methods for compressing heads in IP / UDP packets and IP / TCP packets have been developed. For example, the RFC 2507 and RFC 2508 of the Internet Engineering Task Force (IETF) specify Internet standards for compression of IP heads that can be applied to IPv4 heads and IPv6 base heads and IPv6 extension heads, TCP and UDP. - heads as well as encapsulated IPv4 and lpv6 heads. In particular, RFC 2507 and RFC 2508 IET F RFC 2507 and RFC 2508 are hereby incorporated by reference.

Header compression significantly reduces the negative effects with large IP heads and allows efficient bandwidth utilization. Among other things, head compression of heads reduces overhead caused, and thus less bandwidth is required for the heads. It also reduces the packet loss rate for each given bit error rate because fewer bits are sent per packet compared to full header packets.

The key feature that allows effective header compression is that in a packet fl destiny, the huvud most main fields are identical in consecutive packets. For simplicity, one can imagine a packet som destiny as all the packets sent from a particular source address and port to a particular destination address and port using the same transport protocol. A basic principle for compressing heads in a packet fl destiny is to send a packet with a complete header and establish a link between the invariant field of the full header and a context identifier (CID), which is a small unique number also carried by compressed heads. The connection between the immutable fields and the context identifier is typically implemented in a main compression table in which the immutable fields in the complete header are stored as a compression state. The CID identifier in the compressed header of the subsequent packet is used to find the corresponding compression state in the main compression table to be used for decompression. Each change in a main field that is not expected to change causes the compressor to send a new complete header to update the compression state for the packet fate. In addition to the CID identifiers, the compressed heads can also include incremental changes for different parameters in the heads. 20 25 522 063 4 To alleviate the problem of incorrect decryption, complete headers are typically sent from time to time to update the compression state, and according to IEIF RFC 2507, each new version of the compression state for a given CID is identified by a generation nunner. In RF C 2507, each complete header that updates a compression state carries a generation number, and the compressed headers carry the compression state generation number used to compress the headers. When the decompressor detects that a compressed header carries a different generation number than the generation number of the packet compression state, the compression state is obsolete and the main compressed packet must be discarded or stored until a new complete header establishes a correct compression state.

In RFC 2508 the problem of incorrect decompression is solved by a sequence recorder and peer signaling.

Fig. 1 illustrates a complete UDP header with CID and generation coupling as well as a corresponding compressed header, which is based on the CID and generation fields according to RFC 2507. The gray fields in the complete header are stored as compression states. The UDP checksum is normally included in the compressed header as a security measure.

Without main compression, a bit error only affects the packet that actually contains the bit error. However, when main compression is applied and the bit error occurs in a complete header, a single bit error can cause the loss of a large number of subsequent main compressed packets. This is because the bifurcation will propagate in all subsequent compressed heads that are expanded using the compression condition established by the faulty complete head. If the link layer protocol uses a strong checksum, such propagation is prevented 20 25 522 063 a | | o. . n 5 of bit errors because frames with bit errors will be thrown before they reach the decompressor.

As noted in the article Low-loss TCP / IP header compression for wireless networks by Degermark et al., Wireless Networks 3 (1997), pages 375-387, this generally means that the compression of IP heads requires the use of a secure link layer protocol with a strong checksum.

The bit error resistance, also referred to as the bit error tolerance, for a standard IP protocol stack (IPv4 or IPv6) is normally based on a secure link layer protocol such as the line procedure protocol (HDLC). Fig. 2 is a schematic overview of a UDP / IP protocol stack based on an HDLC link layer. In this example, compression of IP heads at the sub-level HC (Header Compression) of the link layer is used to improve the transmission efficiency of the link. Fig. 2 also illustrates the checksums that occur in a UDP / IP stack.

Today's standardized secure link layer protocols generally have a simple error detection mechanism with a checksum covering the entire frame. This can be seen in Fig. 3 which illustrates the different heads of the UDP / IP protocol stack according to Fig. 2 and the coverage of the existing checksums in more detail. The HDLC protocol normally has a 16-bit or 32-bit checksum that covers the entire 1-IDLC frame except the start and stop edges. If a bit error occurs somewhere in the part of the frame covered by the HDLC control surround, the corresponding packet is simply thrown at the reception side when the error in the checksum is detected. The other available checksums, at the UDP level and for the IPv4 header, would be superfluous in this case. They are used only for extra protection to ensure that the application package reaches its correct destination.

However, for many IP-based applications, especially for those that include delay-sensitive real-time data, such as speech or picture, it is secure. n o - | u u | u o u- link layer detection mechanism for errors in checksums is not very suitable and generally leads to serious deteriorations in the quality of application. Especially for loss-prone links with high bit error rates (BER), such as radio or microwave links or even low quality copper cables, far too many packets will be discarded due to the link layer protocol error detection with strong checksums. On the other hand, main compression methods used to improve the transmission efficiency, especially for low speed or medium speed links, really require a secure link layer.

Due to the above conflicting requirements for the link layer, there seems to be a general need to develop a new strategy for improved bit error resistance, especially for low or medium speed links with relatively high bit error rates.

RELATED ART The American patent with no. 5,535,199 as of July 9, 1996 relates to TCP / IP master compression in X.25 networks. The patent discloses both a method and an apparatus for negotiating the use of the so-called van Jacobsen system for main compression / decompression between remote nodes in a TCP / IP / X.25 network as well as a method for implementing the use of the van Jacobsen the system for main compression / decompression in such a network. A specific protocol identifier (PID) in a user data field of a call request packet is used to indicate that the terminal that issued the call request will use TCP / IP master compression. The terminal that receives the call request then returns either a message that the call is accepted or a message that if the terminal can use the TCPIIP call is rejected, depending on the main compression. 20 25 522 063 v - ~ v n n | n c | | n n | v ~ o; International application WO 99/04522, published January 28, 1999, relates to a system for adaptive lossless compression of cell / packet heads in an ATM network. On the transmission side, the system distinguishes between cells / packets, detects heads, compresses heads and combines compressed heads and payload. On the receiving side, the system distinguishes between main compressed cells / packets, separates compressed heads from payloads, decompresses heads and combines the decompressed heads with payloads to form cells / packets.

International application WO 00/42743, published on July 20, 2000, relates to a method for transferring information in data transfer modes between communication devices and presents a mechanism for improving packet transfer in such a way as to avoid unnecessary fragmentation while achieving such a small amount. delay as possible in the transmission of packets that require real-time data transmission. The proposed mechanism is based on real-time packaging principles of shut-off / resumption type where some of the main information fl is transmitted to be sent at the end of a packet after the information part of the packet.

International application WO 95/30282, published on November 9, 1995, relates to a digital radio communication system which includes the detection of bad frames. To get an early warning of an impending bad frame, error detection time slot for time slot is suggested. The error detection mechanism uses a signal that is present in each time slot in both the forward and return links, namely the Coded Digital Verification Color Code (CDVCC). The CDVCC signal is a 12-bit coded version of the 8-bit DVCC signal, and the redundancy of the 12-bit coded version is used by an error correction algorithm to detect the presence of a bit error in the decoded DVCC signal. An error detected in the DVCC signal 20 522 063 o a n n o o u u »8 means that even the corresponding frame is corrupted and thus a bad frame can be detected on a time-by-time basis before the complete frame has been received.

BRIEF SUMMARY OF THE INVENTION It is a general object of the present invention to improve the bit error resistance of an IP protocol stack based on a secure link layer.

It is particularly desirable to find a new bit error resistance strategy which can solve the conflicting requirements of the link layer protocol of on the one hand delay sensitive real time data in high bit error rate environments and on the other hand the use of main compression.

Another object of the invention is to improve the application quality, such as speech quality, for IP-based real-time applications.

Yet another object of the invention is to provide a mechanism for protecting master information in master compressed packets.

These and other objects are solved by the invention as defined in the appended claims.

The invention is based on the insight that for IP-based applications, such as compressed speech or image, in which the payload is built up of parameters that have different levels of significance for the final application quality, it is interesting to propagate packets with bit errors in less important parameters up in the IP stack for use in the application as long as the more important parameters are correct.

The basic problem with secure link layers such as the HDLC link layer is that each frame with an error indicated by the check sum of the link layer is normally discarded. This makes it impossible to distinguish between errors in heads in higher protocols, errors in important application parameters or errors in less important application parameters. Packages with errors in less important application parameters should be allowed to propagate upwards in the IP stack at least up to the UDP level, perhaps all the way up to the application level. Packages with errors in heads in higher protocols or in critical application parameters should be discarded unless the errors can be corrected by an error correction method.

In short, the basic idea of the invention is to make the secure link layer insecure for main compressed packets and forward main compressed packets upwards in the IP stack for higher level error evaluation, also referred to as higher level error protection in a more general sense. This opens up for smarter handling of incorrect packages compared to just throwing them away at the link layer. For example, if it can be determined at the UDP level or by an application-specific protocol that a bit error in a packet only affects a less important application parameter, that packet can probably be used by the application without seriously degrading the application quality.

If the application-specific protocol has error correction options, a bit error in a critical parameter can also be corrected so that the corresponding package can be used.

This leads to significant improvements in the application quality and interesting applications in this respect are compressed speech, compressed image or other applications with similar requirements for bit error.

All packets are preferably analyzed at the link layer to determine if the packets are mastered and the secure link layer is made insecure by ignoring or overriding the link layer check sum evaluation and forwarding the main compressed packets up in the protocol stack. Of course, it is not necessary to forward master-compressed packets with correct checksums on the link layer to a higher protocol level for further error evaluation. In a 20 25 522 063 n u ø a | o | | | | n u: 10 optimized implementation is therefore only propagated main compressed packages with incorrect checksums on the link layer upwards in the IP stack for error evaluation at a higher level.

By overriding the link layer's checksum evaluation for main compressed packets and propagating them to higher protocol levels while maintaining the checksum evaluation for full header packets, the complete heads can still be properly protected at the link layer to ensure a correct complete header is entered into header compression. This is extremely important as the full head compression state will be used to replace compressed heads for all packets until a new full head is received.

Although application-specific parameters are handled more intelligently at a higher protocol level, it is clearly advantageous to compensate for the disregard of the link layer checksum for main compressed packets by also protecting the main information at the link layer HC level. According to the invention, this is mainly solved by elegantly introducing one or more local checksums for protection of specific parts of the compressed head. The basic idea according to this aspect of the invention is to select a first subset of the compressed header as a local checksum and protect a second subset of the compressed header by the selected local checksum. For example, the local checksum can be selected as a predetermined part of the context identifier (CID) field to protect the PPP protocol identifier field (PID) and possibly also the CID field, or as a predetermined part of the generation field to protect the rest of the generation field.

By denying a number of such local checksums and using the fact that higher level checksums, such as the UDP checksum, protect themselves, virtually all fields in the compressed header can be protected at the master compression level. 522 065 n ø n n c o .o 11 The invention offers the following advantages: - Improved bit error resistance; - More intelligent handling of faulty head compressed packages while providing complete protection against faulty packages with full heads; and 5 - Improved application quality, especially for compressed speech and image.

Other advantages offered by the present invention will be apparent upon reading the following description of the embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS The invention, together with further objects and advantages thereof, may best be understood by reference to the following description when read in conjunction with the accompanying drawings, in which: Fig. 1 illustrates a complete UDP head with CID and generation linkage as well as a corresponding compressed header based on the CID and generation fields; Fig. 2 is a schematic overview of a UDP / IP protocol stack based on an HDLC link layer; Fig. 3 illustrates the different heads of the UDP / IP protocol stack according to Fig. 2 and the coverage of the existing checksums in more detail; Fig. 4 is a schematic drawing of a simple network from the point of view of the protocol stack; 522 063 u a | «U 1 | Fig. 5 is a schematic overview of a UDP / IP control stack based on an HDLC link layer according to a preferred embodiment of the invention; Fig. 6A illustrates the main format according to UDP Lite; Fig. 6B illustrates a UDP Lite package with a selective checksum; Fig. 7 is a schematic fate diagram summarizing the basic mechanism according to a preferred embodiment of the invention; Figs. 8A-B are schematic diagrams illustrating head compression protection for 8-bit and 16-bit CID formats for non-TCP heads compressed according to RFC 2507, respectively; Figs. 9A-B are schematic diagrams illustrating head compression protection for 8-bit and 16-bit CID formats for non-TCP heads compressed according to RFC 2508, respectively; and Figs. 10A-B are schematic diagrams illustrating head compression protection for 8-bit and 16-bit CID formats for ROCCO heads, respectively.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION Throughout the drawings, the same reference numerals will be used for corresponding or identical elements. 20 25 522 oss q; f, v n a | Q | n en 13 For a better understanding, the invention will now be described with reference to a particular example in which an IP protocol stack runs applications over a PPP / HDLC-based link layer. More specifically, it is assumed in the following example that the application is a delay-sensitive real-time application such as speech or image, and that the fate of packets is transported using the transport layer protocol UDP. For enhancement links or especially for low speed transmission efficiency, medium speed such as radio or microwave links, packets are main compressed using a suitable main compression method (for example RFC 2507, RFC 2508, ROCCO or ROCH).

Reference overview Fig. 4 is a schematic drawing of a simple net from the point of view of the protocol stack.

The network 10 comprises a first end system (IP host) 11 which is connected by conventional communication links with varying bit error rates and a suitable number of intermediate routers 12 to a second end system (IP host) 13.

The payload of the application is encapsulated in UDP / IP packets and sent over the PPP / HDLC-based links. The protocol stacks are processed by conventional process systems in the processed UDP protocol and the hosts and routers. In this example, the application protocol is only in end systems 11 and 13.

Bit error resistance for improved application quality and secure main compression The HDLC checksum is calculated for all packets and sent over the respective PPP / HDLC based link, but the control field evaluation on the receiving side is ignored for main compressed packets. This means that main compressed packets are forwarded upwards in the IP stack for higher level error protection. The packets are preferably finally propagated at least up to the UDP level where they can be handled by a fail-safe method that is more intelligent than the secure link layer control number evaluation. On the other hand, defects in complete head packages are detected already at 522 065 n | | o e u o n f | ø vn 14 the link layer level to ensure that a correct complete head is entered in the main compression table.

All packets are therefore analyzed at the secure link layer to determine whether the packets are master-compressed. This is preferably determined at the PPP layer by analyzing the PPP protocol identification byte (PID) to determine the type of payload in the PPP packet. Table I below illustrates the PID values for different types of packets and also whether an incorrect HDLC checksum should be used to throw a packet based on the corresponding PID value.

Table I Type of protocol header PID value (hex) Discard packets in case of CRC error RFC 2507/2508 Complete 0061 Yes header RFC 2507 compressed non-0065 No TCP header RFC 2508 compressed UDP-0067 No header with 8-bit CID RFC 2508 compressed UDP-2067 No header with 16-bit CID ROCCO - all headers 1 value, TBD No All other protocol heads - Yes a By analyzing the PPP-PID it can thus be determined whether the packet is a full header packet in which case the evaluation of HDLC the checksum is used as normal to discard incorrect packages with full headers, or a main compressed packet in which case the HDLC checksum evaluation is ignored and the packet is propagated upwards in the protocol stack. It should be understood, however, that Table I is not exhaustive and that other types of protocol headers such as ROHC- 20 n ß: nu u I a; ,,, 5 '0 U U I s i oo I I v o n n c v t o | . .uu en an. o v u. 0 v o la u o a ° 9 5 Û II lan 15 head (RObust Header Compression) and other future types of heads can be included in the table.

This solution not only opens up for more intelligent handling of incorrect head-compressed packages at a higher level, but also solves the problem of proper protection of packages with full heads at the link layer. This latter aspect of the invention is very important because the full header compression state will be used to replace compressed heads for all packets until a new full header is received. In the case of IPv6 which has no checksum for the IPv6 header, the verified full header becomes even more important.

As will be appreciated by those skilled in the art, master compressed packets with correct HDLC checksums do not necessarily need to be subjected to further higher level error evaluation as it has already been established at the link layer that the entire packet is free of bit errors.

It is thus possible to minimize the load placed on the higher level error evaluation and only forward main compressed packets with incorrect HDLC checksums upwards in the IP stack for higher level error evaluation. For the sake of robustness and simplicity, however, it is normally assumed that all main compressed packets will be forwarded upwards in the stack for higher level evaluation.

For more information on the PPP / HDLC link layer protocol, see IEIF RFC 1662, which is hereby incorporated by reference.

Fig. 5 is a schematic overview of a UDP / IP protocol stack based on an HDLC link layer according to a preferred embodiment of the invention. As indicated in the HDLC control clock at the PPP / HDLC layer for Fig. 5, main compressed packets are ignored. To compensate for the disregard of the HDLC checksum, head protection is introduced at the HC level and an error protection method for the UDP layer and / or the application layer that is more intelligent than the error evaluation of the HDLC checksum is introduced to optimize the use of the overlink the application information. The main protection method for the HC level will be clarified in detail later.

As mentioned above, full header packets are completely protected by the HDLC control socket to ensure proper extension of compressed heads to UDP / IP heads by using the appropriate compression state stored in the HC table.

Main compressed packets for which the evaluation of the HDLC checksum at the link layer has been ignored are propagated upwards in the IP stack and the compressed heads are extended to the corresponding IP heads by using the HC table.

According to a preferred embodiment of the invention, the UDP protocol and / or the application protocol are preferably configured with a selective error detection mechanism so that it can be determined whether a bit error affects the main information, important application parameters or less important application parameters. If it can be determined that the main information and the more important application parameters in a package are not affected by bit errors, then that package can probably be used by the application without a serious deterioration in the application quality.

Compressed speech, for example, includes speech packets that are made up of speech coding and decoding parameters of different levels of significance for the final speech quality. In Fig. 5, such parameters are designated as A, B, C and D. For convenience, the parameters are typically sorted in descending priority with the most important parameter first for protection. error evaluation method, with a checksum covering main information and facilitating the selective By using a selective 522 063 now; oo 17 suitable parts of the payload A, B, an error in minor coding and decoding parameters C, D was allowed to propagate to the application while an error in more important coding and decoding parameters A, B leads to the corresponding packet being discarded unless the error can be corrected of an error correction method. Significant improvements in speech quality can be obtained by not throwing main compressed packets with incorrect checksums at the link layer and instead propagating the packets upwards in the IP stack where important speech coding and decoding parameters for at least some of the packets can be used. In the case of error correction, which requires fl your error protection bits, an even higher proportion of the packages can be used in the application.

For example, the so-called UDP-Lite protocol can be used for selective error detection at the UDP layer. Fig. 6A illustrates the main format according to UDP Lite, and Fig. 6B illustrates a UDP Lite package with a selective checksum.

The protocol size is the same as for the regular UDP header, but the length field has been replaced with a checksum coverage field that indicates how many bytes should be covered by the 16-bit checksum starting from the first byte in the UDP-Lite header. In the same way as for the standard UDP checksum, the IP address of the source and destination is included in the calculation of the checksum. This format allows the protection of a selected part (the first part) of the payload, which is useful if the packages are sorted with the most important parameters in the first part of the package.

A solution where the UDP header is omitted and the application is sent directly over IP (often referred to as "raw" IP) is also possible. In that case, a corresponding selective checksum must be included in the application header.

In general, possible protection methods for higher level error protection can range from bit error detection algorithms, such as parity bits, checksums or more specifically CRC sums, to error correction methods for single bit errors or multiple bit errors, such as the Hamrning algorithm.

Referring again to Fig. 5, the checksum of the IPv4 header for complete header packets is evaluated before a new context is established in the HC table to ensure that previous bit errors have not propagated to the present link at the IP level. In this way, the risk of high error magnification is reduced or eliminated.

Otherwise, a single bit error that has been propagated to a complete header at the IP level can result in a fl your hundred times magnification of the error. This mechanism can also be introduced for the transport layer by using UDP Lite or other selective checksum procedures to ensure that the packet reaches the correct destination. Checking the selective checksum before the UDP header is entered into the HC table also eliminates the error magnification.

The gain is of course not limited to the examples above. Although the main target application is compressed speech or image, other applications with similar bit error requirements may also benefit from the invention. In addition, link layer protocols other than the PPP / HDLC protocol can also be used for the secure link layer.

The basic mechanism according to a preferred embodiment of the invention will now be summarized with reference to the fate diagram in Fig. 7. In step S1 it is determined whether the package is main compressed. Main compressed packets override the link layer CRC (step S2) and are forwarded to the HC level (step S3) for evaluation of head defects. In step S4, it is determined whether the compressed head is free from bit errors using one or more of your local checksums. If a bit error is detected in the compressed header, the packet is discarded in step S5. Otherwise, if the compressed head is OK, the application layer in step S6. In step S7, an appropriate error correction or forward packet is applied to the transport layer and / or selective error detection method on the packet to determine whether the packet can be used by the application. For packages with full headers, it is determined in step S8 whether the CRC of the link layer is correct. If the complete head packet is incorrect, the packet is discarded in step S9. Otherwise, a compression state and context is established in step S10.

Protection of master information in master-compressed packets As mentioned above, master information is protected at the HC level of the link layer to compensate for the override of the link layer check sum evaluation for master-compressed packets. In standard methods of head compression, such as RFC 2507 and RFC 2508, there is no head protection at this level.

According to the invention, the protection of information in a compressed head is achieved mainly by elegantly introducing one or more local checksums for the protection of specific parts of the compressed head. By defining a number of local checksums and using the fact that higher level checksums, such as the UDP checksum, protect themselves, all fields in the compressed header can be protected at the HC level.

Specific solution for RFC 2507 For main compression according to RFC 2507 we introduce a solution where x bits in the CID field at HC level are used to protect the static part of the main compressed fields, and y bits of the generation field are used to protect the rest of the generation field.

The information to be protected by the x CID bits without violating the HC standard must be static. Otherwise, the CID bits used for protection will vary from packet to packet, making it impossible to use the method against a peer node that does not use the proposed protection method. According to a preferred embodiment 522 us n | ø «. . -,,, ._ 20 of the invention, the x CID bits protect both the CID value itself and the bits that indicate additional main data (“D”) and whether the CID is 8 bits or 16 bits (“0” and “1”) as the PPP Protocol Identifier (PID).

The generation value changes with each new version of the compression state, so it cannot be protected with the x bits, not without changing the HC table with each new complete header. Therefore, y bits in the generation field are used as parity bits for the rest of the generation bits. This of course reduces the number of possible generation values, but as long as the generation value is not repeated more often than every three seconds, the solution is still in accordance with the HC standard.

The UDP checksum protects itself because an incorrect checksum normally results in a dropped packet at the UDP layer. lPv4 ID is assumed to be protected by using a selected sequence in lPv4 ID so that any incorrect values can be detected as bit errors. If the end user is aware of the possibility of errors in the main compressed links along the IP line, the ID field is alternatively protected by always selecting z bits in the ID field to protect the rest of the 16 bits in the same way as for the proposed CID protection. .

Specific solution for RFC 2508 For main compression according to RFC 2508, x bits are used in the CID field at the HC level to protect the static part of the main compressed fields in the same way as for the solution for RFC 2507 above.

The sequence counter protects itself as any incorrect sequence numbers result in discarded packets and a request for a new complete header. The UDP checksum also protects itself because an incorrect checksum normally results in a dropped packet at the UDP layer. 20 522 063 a. | »N 1 | . . . a - n. 21 The delta value for IPv4 ID is a little more complicated to protect. According to a preferred embodiment of the invention, it is therefore assumed that the CID protection is only used when I = 0. If the IP end system always uses an increment of +1 for IPv4 ID, this will be assumed to be the default when the context is set up by a full header, and no Delta IPv4 ID field will be required. However, if the increment differs from the normal one, it is necessary to have a delta value for IPv4 ID to provide information about the new incremental change of IPv4 ID. In this case, indicator I is set for a dynamic delta value, i.e. I = 1, and now the HDLC checksum is used to detect any errors and to discard the packet if this is the case.

The above principles for the protection of principal information by one or more local checksums are generally applicable to any compressed header or combination of heads that includes static or quasi-static master information. Consequently, the principles of the invention can be used not only in connection with RFC 2507 and RFC 2508 IETF standards, but also in conjunction with other methods of main compression such as ROCCO (RObust Checksurn-based header COmpression) and ROHC (RObust Header Compression) which are currently proposed by working groups under the IETF.

Specific solution for the ROCCO proposal Main compression according to ROCCO is a fairly sophisticated algorithm that was originally developed for handling main compression over air interfaces with high bit error rates. With ROCCO, the head-compressed head as well as any complete heads are already protected by a CRC inside the ROCCO head.

The ROCCO header also protects the CID value if a packet flow mode is selected. Today, only the 8-bit CID format is specified in the proposal and only for some of the possible main formats. To be consistent with the other formats for main compression, this invention also predicts the development of a 16-bit CID format in ROCCO. Referring to Figs. 10A-B, the proposed addition to the existing ROCCO solution is to use x bits in the CID field to protect only the PPP PID value because the CID values and the rest of the The ROCCO head is already protected. A common PID value is used for all heads in the ROCCO algorithms.

As already mentioned, common general protection methods range from bit error detection algorithms to bit error correction methods, such as the Harmníng algorithm. For example, to achieve a 21-bit error correction by using a Hamming algorithm, 5 parity bits would be needed. (For a bit error, up to ll bits could be corrected with only 4 parity bits.) This should cover PPP PID and CID as well as “l” and “D” in the other HC byte. If an error cannot be corrected, the package should be discarded.

The embodiments described above are given by way of example only, and it should be understood that the present invention is not limited thereto. Further modifications, alterations and improvements, which maintain the basic underlying principles shown and claimed herein, are within the scope and spirit of the invention.

Claims (39)

20 522 063 23 PATENT REQUIREMENTS A bit error resistance method for an Internet Protocol (IP) stack based on a secure link layer having packet error detection functionality, characterized by: - analyzing packets at the link layer to determine whether the packets are main compressed packets or packets provided with complete headers , complete headers packets that are incorrect are discarded and at least some of the main compressed packets are forwarded upward in the higher level error protection protocol stack. The bit error resistance method according to claim 1, characterized in that the error protection at a higher level comprises detection of errors in part of the packet. The bit error resistance method according to claim 1, characterized in that the error protection at a higher level comprises error correction. The bit error resistance method according to any one of the preceding claims, characterized by overriding the link layer detecting errors in packets for all main compressed packets and forwarding all main compressed packets upwards in the higher level error protection protocol stack. The bit error method according to claim 1, characterized in that the error protection at a higher level comprises the step of protecting main information in the main compressed packets at a higher sub-level of the link layer. 20 522 063 24 The bit error resistance method according to claim 5, characterized in that the higher sub-level is the HC level (Header Compression). The bit error resistance method according to any of the preceding claims, characterized in that the higher level error protection comprises the step of protecting main information and at least part of the payload in the packets at the UDP (User Datagram Protocol) level. The bit fault resistance method according to any one of the preceding claims, characterized in that the higher level fault protection comprises the step of protecting at least part of the payload in the packages at the application level. The bit error resistance method according to claim 7 or 8, characterized in that the packets comprise compressed real-time data such as compressed speech or image, and the higher level error protection of at least part of the payload comprises the step of protecting critical real-time parameters in the payload. The bit error resistance method according to claim 5 or 6, characterized in that the step of protecting head information in the main compressed packets comprises the step of protecting at least part of the compressed head by a local checksum selected as a local stretch of the compressed head. The bit error resistance method according to claim 10, characterized in that the local checksum is a predetermined part of a context identifier field (CID) in the compressed header. 20 522 063 jš_ 1 u »; | u n ou 25 The bit error resistance method according to claim 10, characterized in that the local checksum is a predetermined part of a generation error in the compressed header. The bit error resistance method according to claim 10, characterized in that the local checksum is a predetermined part of an IPv4 identifier field in the compressed header. The bit error resistance method according to any one of claims 10-13, characterized in that the protected compressed master information comprises the local checksum. The bit error resistance method according to any one of claims 1-11, characterized in that the main compressed packets are main compressed according to one of the following standards: - RFC 2507 according to the Internet Engineering Task Force (IETF); - RFC 2508 according to the IETF; and - ROCCO (RObust Checksum-based header COmpression) according to IETF. The bit error resistance method according to any one of the preceding claims, characterized by discarding a master compressed packet with an incorrect checksum in the link layer if the dynamic delta value indicator for a version 4 identifier of the Internet Protocol (IPv4) is set. The bit failure method according to any one of the preceding claims, characterized by discarding complete headed packages having incorrect checksums in the link layer. 20 522 063 26 The bit error resistance method according to any one of the preceding claims, characterized by discarding complete header packets having incorrect IPv4 checksums, thus protecting against bit error propagation at the Internet Protocol (IP) level. The bit error resistance method according to any one of the preceding claims, characterized in that the frame protocol of the secure link layer is the PPP (Point-to-Point Protocol). The bit error resistance method according to any one of the preceding claims, characterized in that the secure link layer is the line procedure protocol layer (HDLC). 21. A bit error resistance system for an Internet Protocol Stack (IP) based on a secure link layer having means for evaluating checksum errors, characterized by: - means for analyzing packets at the link layer to determine whether the packets are main compressed packets or packets with complete headings ; means for disposing of packages with complete heads which have incorrect control urns at the link layer; and - means for forwarding at least some of the main compressed packets upwards in the higher level error protection protocol stack. The bit error resistance system according to claim 21, characterized in that the error protection at a higher level comprises detecting errors in part of the package. The bit error resistance system according to claim 21, characterized in that the error protection at a higher level comprises error correction. 20 522 063 i n n - n n | u 27 The bit error resistance system according to any one of claims 21-23, characterized by means for overriding the evaluation of checksum errors for all main compressed packets, the forwarding means being operative to forward all main compressed packets upwards in the higher level protocol protection stack. The bit error resistance system according to any one of claims 21-24, characterized in that the error protection at a higher level is performed at least in part by means for protecting main information in the main compressed packets at a higher sub-level of the link layer. The bit error resistance system according to claim 25, characterized in that the higher sub-level is the HC level (Header Compression). The bit error resistance system according to any one of claims 21-26, characterized in that the error protection at a higher level is performed at least in part by means for protection of main information and at least part of the payload in the packages at the UDP level (User Datagram Protocol). The bit fault resistance system according to any one of claims 21-27, characterized in that the fault protection at a higher level is carried out at least in part by means for protecting at least part of the payload in the packages at the application level. The bit fault resistance system according to claim 27 or 28, characterized in that the packets comprise compressed real-time data such as compressed speech or image, and that the higher level fault protection of at least part of the payload is performed by means for protecting critical real-time parameters in the payload. 20 522 063 Q o: u | ø Q o | | u o: 28 The bit error system according to claim 25 or 26, characterized in that the means for protecting main information in the main compressed packets comprises means for protecting at least part of the compressed head by a local checksum selected as a local subset of the compressed head. The bit error rate system according to claim 30, characterized in that the local checksum is a predetermined part of a context identifier (CID) in the compressed header. The bit error resistance system according to claim 30, characterized in that the local checksum is a dry-determined part of a generational error in the compressed header. The bit error resistance system according to claim 30, characterized in that the local control surm is a predetermined part of an IPv4 identifier field in the compressed header. The bit error resistance system according to any one of claims 30-33, characterized in that the protected compressed master information comprises the local checksum. The bit error resistance system according to any one of claims 21-31, characterized in that the main compressed packets are main compressed according to one of the following standards: - RFC 2507 according to the Internet Engineering Task Force (IETF); - RFC 2508 according to the IETF; and - ROCCO (RObust Checksum-based header COmpression) according to IETF. 522 oss Q | n 1 a | n. | u nu 29 The bit error resistance system according to any one of claims 21-35, characterized by means for discarding a main compressed packet with an incorrect checksum in the link layer if the dynamic delta value indicator for an identifier of version 4 of the Internet Protocol (IPv4) is set. The bit error resistance system according to any one of claims 21-36, characterized by means for discarding complete header packets having incorrect IPv4 checksums, thus protecting against propagation of bit errors at the Internet Protocol (IP) level. The bit error resistance system according to any one of claims 21-37, characterized in that the frame protocol of the secure link layer is the PPP (Point-to-Point Protocol). The bit error resistance system according to any one of claims 21-38, characterized in that the secure link layer is the line procedure protocol layer (HDLC).