HK1113965B - Method and apparatus for handling out-of-sequence packets in header decompression - Google Patents

Description

Method and apparatus for processing out-of-order packets in header decompression

Technical Field

The present invention relates generally to telecommunications, and more particularly to compression of headers of packets, such as media packets.

Background

With the great success of the internet, it has become a daunting task to utilize Internet Protocol (IP) over all kinds of links. However, due to the fact that the header of the IP protocol is rather large, making it a fact for narrowband links, such as cellular links, is not necessarily a simple task. As an example, consider ordinary voice data conveyed over protocols (IP, UDP, RTP) for voice over JP (VoIP), where the header may represent approximately 70% of the packets, resulting in a very inefficient use of the link.

The term "header compression" (HC) encompasses the passing of point-to-point links on a per-hop basisThe necessary bandwidth for the information carried in the header is minimal. Header compression techniques typically have a history of over ten years within the internet community. There are several commonly used header compression protocols, such as the following: (1) van Jacobson, "compress TCP/IP header for low speed serial link", IETF RFC 1144, IETF Network work Group, 1990 month 2; (2) mikael Degermark, Bjrn Nordgren, Stephen Pink, "IP header compression", IETF RFC 2507, IETF Network Working Group, month 2 1999; and (3) Steven Casner, Van Jacobson, "compression of JP/UDP/RTP headers for Low speed Serial links", IETF RFC 2508, IETF Network work Group, month 2 1999, all of which are incorporated herein by reference in their entirety.

Header compression takes advantage of the fact that: some fields in the header do not change in the stream or change with small and/or predictable values. The header compression scheme utilizes these characteristics and transmits static information only initially, while the change field is transmitted packet by packet with its absolute value or as a difference value. Completely random information must be sent without any compression.

Header compression is therefore an important component to make IP services over the air, such as voice and video services, economically viable. Header compression solutions have been proposed by the robust header compression (ROHC) working group of the Internet Engineering Task Force (IETF) to improve the efficiency of such services.

Robust header compression (ROHC), as defined in RFC3095(Bormann, c., "robust header compression (ROHC): framework and four subsets of protocols RTP, UDP, ESP and uncompressed", RFC3095, Internet engineering task Force, month 7 2001), is an extensible framework for the compressed subsets of protocols for which various protocols can be defined. For real-time multimedia services (e.g. voice, video), application data is transported end-to-end in IP/UDP/RTP streams. Header compression for IP/UDP/RTP is defined by ROHC protocol subset 0x0001(ROHC RTP) and is applicable, among other things, to voice over IP (VoIP) services. The ROHC RTP header compression scheme is designed to efficiently compress IP/UDP/RTP headers passing through an arbitrary link layer.

A number of other ROHC protocol subsets are also defined for compression. Wherein still include: (1) IP/UDP/RTP headers (described in Jonsson, L. and G.Pelletier, "robust header compression (ROHC): Link layer assisted ROHC protocol subset for IP/UDP/RTP" (IETF RFC3242, 4. 2002) and "zero byte support for Bi-directional reliable mode (R mode) in extended Link layer assisted robust header compression (ROHC) protocol subset for Liu, Z and K.le" (IETF RFC 3408, 12. 2002)); (2) IP-only headers (described in Jonsson, l. and g. pelletier, "robust header compression (ROHC): compression protocol subset of IP" (ietf rfc 3843, month 6 2004)); (3) IP/TCP headers (described in Pelletier, g., Jonsson, l., West, m., and r. price, "robust header compression (ROHC): TCP/IP protocol subset (ROHC-TCP)" (Internet Draft (in order), < Draft-ietf-ROHC-TCP-08.txt >, 10 months 2004)); and (4) JP/UDP-Lite/RTP headers (described in Pelletier, g, "robust header compression (ROHC): UDP-Lite's protocol subset" (internet draft (in its formulation), < draft-ietf-ROHC-UDP-Lite-04.txt >, month 6 2004)). All RFCs cited herein are incorporated by reference in their entirety.

In addition to negotiation (see also "PPP-based robust header compression (ROHC)" by Bormann, c, IETF RFC 3241, 4 months 2002), the ROHC protocol suite only requires framing and error detection to be provided by the link layer, while all other functionality is handled by the ROHC scheme itself.

The ROHC protocol subsets "IP only" (robust header compression (ROHC): compression protocol subset of IP ", IETF RFC 3843, month 6 2004) and ROHC-UDPLite" (robust header compression (ROHC): protocol subset of UDP-Lite, in Pelletier, g.), Internet Draft (in the formulation), < Draft-IETF-ROHC-UDP-Lite-04. xt >, < month 6 2004) defined in RFC3095, RFC3242, RFC 3408 all support three different modes of operation. Briefly, for a particular context, the mode of operation controls the actions and logic to be performed and the packet types to be used in different states of the header compression operation. The allowed packet types and formats may vary from mode to mode. The unidirectional mode (U-mode) is used at the beginning of any ROHC compression before any transition to other modes may occur. The two-way optimization mode (O-mode) seeks to maximize compression efficiency and the sparse use of the feedback channel. The bi-directional reliable mode (R-mode) seeks to maximize robustness to loss propagation and contextual damage propagation.

In U-mode, packets are only sent from the compressor to the decompressor. Thus, U-mode is available on links where the return path from decompressor to compressor is not needed or available. Periodic refreshes are used for U-mode. U-mode is particularly suitable for broadcast or multicast channels.

The O-mode is similar to the U-mode with the difference that a feedback channel is used to send error recovery requests and (optionally) acknowledgements of important context updates from decompressor to compressor. For most ROHC protocol subsets, U-mode and O-mode are often ambiguously denoted by the term U/O mode due to their rather similar characteristics, e.g. the same set of packet formats for both modes.

The R-mode differs significantly from the other two modes, mainly by the more extensive utilization of the feedback channel and the more strict logic for performing context updates. The R-mode also employs several different packet types that are understood and useful only in this mode.

The modes of operation have different properties in terms of compression efficiency, robustness and processing complexity. The mode transition may only be initiated by the decompressor. ROHC does not specify the manner and time that each mode should be used (except that ROHC compression must always be started in U-mode). Thus, the logic for mode transition is an implementation decision and may be based on measurements of link characteristics, link conditions, implementation optimization of a particular mode, or may be based on other algorithms. In particular, for broadcast/multicast type services, header compression operates only in a unidirectional mode (U-mode), since typically for such services a feedback channel from decompressor to compressor is not available or required.

A header compression scheme (e.g., ROHC profile) may be conceptualized and/or implemented as a state machine. A difficult task is to keep the compressor and decompressor states, called contexts, consistent with each other while keeping the header overhead as low as possible. The compressor has a state machine and the decompressor has a state machine. The compressor state machine directly affects the compression efficiency level because it is an important part of the logic that controls the selection of the type of compressed packet to be sent. The purpose of the decompressor state machine is primarily to provide logic for feedback (if applicable) and to identify the packet type for which decompression may be attempted.

The compression context contains and holds relevant information about the past packet and this information is used to compress and decompress subsequent packets. The context of the compressor is the state it uses to compress the header, as described in the ROHC document. The context of the decompressor is the state it uses to decompress the header. Where it is clear which one is referred to, either one or a combination of the two is often referred to as a "context". The context contains relevant information from previous headers in the packet stream, such as compressed and decompressed static fields and possible reference values. In addition, additional information describing the packet stream is also part of the context, such as information on how the JP identifier field changes and typical inter-packet additions in sequence numbers or timestamps.

Fig. 1 illustrates a compressor state machine for the ROHC protocol subsets defined in RFC3095, RFC3242, RFC 3408 "JP only" (robust header compression (ROHC) by Jonsson, l, and g. Pelletier, compression protocol subset of IP, IETF RFC 3843, month 6 2004) and "ROHC-UDPLite" (robust header compression (ROHC) by Pelletier, g., UDP-Lite, protocol subset of internet draft (in the formulation), < draft-IETF-ROHC-UDP-Lite-04.txt >, month 6 2004). For ROHC compression, the three compressor states are Initialization and Refresh (IR), First Order (FO), and Second Order (SO) states. The compressor starts with the lowest compression state (IR) and gradually transitions to a higher compression state. The compressor will always operate in the highest possible compression mode, subject to the constraint that the compressor is sufficiently confident that the decompressor has the information needed to decompress a header compressed according to that state. See, for example, RFC 30954.3.1 section ("robust header compression (ROHC): framework and four subsets of protocols: RTP, UDP, ESP, and uncompressed", IETF RFC3095, month 4 2001). In particular, when operating in U-mode, decisions regarding transitions between various compression states are typically made by the compressor based on changes in packet headers and periodic timeouts.

The Initialization and Refresh (IR) state is defined in section 4.3.1 according to RFC3095, the purpose of the IR state being to initialize the static part of the context on the decompressor or to recover after a failure. In this state, the compressor sends the complete header information. This includes all static and non-static fields in uncompressed form plus some additional information. The compressor stays in the IR state until it is clearly assured that the decompressor correctly received the static information.

Therefore, the IR state is the state in which the compression level is the lowest. Figure 2, section 5.3.1 taken from RFC3095, describes a U-mode state machine. In the U-mode state machine of fig. 2, Timeout _1 generally corresponds to the periodic transmission of static (and possibly dynamic) parameters for the decompressor context, while Timeout _2 generally corresponds to the periodic transmission of only dynamic parameters for the decompressor context.

In addition, the context Copy (CR) mechanism of the ROHC profile introduces an additional state, the CR state. See "robust header compression (ROHC) by Pelletier, g.: the context of the ROHC protocol subset replicates "Internet Draft (in its formulation), < Draft-ietf-ROHC-context-reproduction-01. txt >, month 10 2003. To date, only the [ ROHC-TCP ] protocol subset is specified to support context replication, but other protocol subsets may also support context replication as long as their corresponding standards are updated. The CR state may also be used by a subset of protocols operating in U mode. Fig. 3 illustrates the logic of the previous state machine added to the CR state. In U-mode, the downward transition is performed according to the same logic as described above.

Fig. 4, taken from RFC3095, section 5.3.2, illustrates an example U-mode decompressor state machine. The state of the decompressor dictates what type of compressed packet can be decompressed. In the No Context (NC) state, only packets that initialize the static portion may be decompressed (e.g., ROHC IR packets). In the Static Context (SC) state, only packets containing sufficient information about dynamic parameters (e.g., ROHC IR-DYN or UOR-2 packets) may be decompressed. In the Full Context (FC) state, any packet may be decompressed. Thus, depending on the condition of the channel and depending on the success rate of decompression, the decompressor state machine will transition between different states and must wait to receive the appropriate packet for attempting decompression.

In one-way operation, there is no feedback back to the compressor. Thus, in one-way operation, the decompressor may (in the worst case) have a latency of up to Timeout _1 without being able to start decompression of the received packet, and a latency of up to Timeout _2 before it can restart compression after severe context damage to the dynamic information.

To date, header compression algorithms have been designed under the following assumptions: the packets (whose headers are compressed) are delivered substantially in order, so that the packets do not need to be substantially reordered upon receipt. Based on this assumption, most conventional header compression algorithms operate on the premise that reordering of header-compressed packets between a compressor and a decompressor is not possible. See, for example: VanJacobson, "compress TCP/IP header for Low speed Serial Link", IETF RFC 1144, IETFNetwork Working Group, 1990, 2 months; mikael Degermark, BjrnNordgren, Stephen Pink, "IP header compression", IETF RFC 2507, IETF NetwodkWorking Group, month 2 1999; steven Casner, Van Jacobson, "for Low speed Serial Link compressionIP/UDP/RTP header ", IETF RFC 2508, IETF network working Group, month 2 1999; and Carsten Bormann et al, "robust header compression (ROHC): framework and four protocol subsets: RTP, UDP, ESP and uncompressed ", IETF RFC3095, month 4 2001, all of which are incorporated herein by reference.

Several header compression algorithms allow or accommodate only slight out-of-sequence delivery of packets and thus only slight reordering of packets (with a depth of a few packets) upon reception. See, for example: koren, t., casser, s., geovrhese, j., Thompson b., and p.ruddy, "enhanced compression rtp with links of high latency, packet loss, and reordering (crtp)", IETF RFC 3545, IETF Network Working Group, month 7 2003; and "robust header compression (ROHC) over channels that can reorder packets," by Pelletier, g., Jonsson, l., and Sandlund, k., Internet Draft (in the formulation), < Draft-pelleter-ROHC-over-reordering-00. txt >, month 6 2004, incorporated herein by reference.

The design of compression algorithms has mainly focused on improving the tolerance for packet loss driven by the properties of the wireless cellular link. The encoding of the order information has been improved from accumulated delta encoding to more robust windowed least significant bit (W-LSB) encoding. Cumulative delta encoding is described, for example, in the following documents: van Jacobson, "compress TCP/IP header for low speed serial link", IETF RFC 1144, IETF Network work Group, 1990 month 2; mikael Degermark, Bjrn Nordgren, Stephen Pink, "IP header compression", IETFRFC 2507, IETF Network Working Group, month 2 1999; and StevenCasner, Van Jacobson, "compress IP/UDP/RTP headers for Low speed Serial Link", IETF RFC 2508, IETF Network work Group, month 2 1999. The window least significant bit (W-LSB) encoding is described in the following documents: "robust header compression (ROHC) by Carsten Bormann et al: framework and four protocol subsets: RTP,UDP, ESP and uncompressed ", IETF RFC3095, month 4 2001. Other methods are also used, such as reducing the compression ratio of the sequence information (Koren, t., casser, s., geovrhese, j., Thompson b., and p.ruddy, "enhanced compression rtp with links having high delay, packet loss, and reordering (crtp)", IETF RFC 3545, IETF Network work great group, 7 months 2003), or adjusting some of the parameters of the existing coding method (Pelletier, g., Jonsson, l., and Sandlund, k. "robust header compression (ROHC) over channels that can reorder packets, Internet Draft (in formulation),<draft-pelletier-rohc-over-reordering-00.txt>6 months 2004).

Consistent with the above observations, the IETF ROHC Working Group (WG) designs a header compression algorithm (protocol subset) with the following assumptions: the channel between the compressor and decompressor does not reorder the header compressed packets. Thus, the channel is required to maintain packet ordering for each compressed stream. This assumption has been adopted to define an encoding method in order to aggressively compress a header and obtain a high compression ratio. For certain subsets of protocols, modifications may be made to the logic and/or to certain encoding methods (e.g., LSBs) in order to handle very small (less than 5 packets) amounts of reordering (Pelletier, g., Jonsson, l., and Sandlund, k. "robust header compression (ROHC) over channels that can reorder packets", Internet Draft (in the formulation), < Draft-pellet-ROHC-over-reordering-00. txt >, 2004). However, changes to fields that are not encoded with order information (e.g., semi-static fields) limit the ability to decompress reassembled sequenced packets and/or prevent severe context damage in the presence of medium (tens of packets) or high (hundreds of packets) reordering.

With the upcoming development of wireless links with higher bit rates and lower latency (still higher latency for bit rates), the in-order delivery assumption may no longer be valid. There is a need for header compression/decompression algorithms that are robust not only to packet loss, but also to out-of-order delivery and thus reordering of packets.

What is needed, therefore, and an object of the present invention, is a method and apparatus for header decompression even for out-of-order packets.

Disclosure of Invention

In various aspects, modes, embodiments and implementations, a header compression repair technique is implemented by a remote terminal, by a header decompressor for use on a remote terminal and by a method of operating a remote terminal and/or decompressor, and (optionally) in certain aspects, modes, embodiments and implementations, also by taking into account structural and operational aspects of the header compressor.

The header decompressor is adapted for use with a remote unit, such as a mobile station or user equipment unit. The remote unit also typically includes a transceiver or the like that receives packets over a link such as an air interface, including packets having compressed headers and possibly out-of-order packets. According to an independent and distinct aspect of its configuration and operation, the header decompressor, upon detecting a non-receipt of an expected packet in a packet flow over the link, stores, for each non-receipt, a snapshot of the header decompression context information existing at the time of the non-receipt. Then, when the header decompressor detects a header decompression failure of a subsequently received packet, the header decompressor determines (e.g., by performing a repair procedure) whether the header decompression of the subsequently received packet can be obtained using one of the plurality of stored snapshots. In an effort to make such an acquisition, the decompressor preferably retries decompression of a subsequently received packet (e.g., using a repair procedure) and employs each of the plurality of stored snapshots in such a retry. If header decompression of a subsequently received packet is obtained using only one of the plurality of stored snapshots, the header decompressor (e.g., using a repair procedure) more definitively determines that a retry of header decompression of the subsequently received packet was successful. The selection of which of the multiple snapshots is actually used for the packet may be based on other techniques, such as, for example, transport protocol checking, or the like, such as transport protocol checksum or CRC, if more than one of the multiple snapshots obtains successful header decompression of the packet.

As one example implementation of the first aspect of configuration and operation, for each packet lost in a sequence of streams or a group of consecutive packets, the header decompressor stores a corresponding snapshot of the set of snapshots in a sliding window memory. In a different mode, the header decompressor may retry decompression of a later received packet using all snapshots in the set or a subset of the snapshots in the set. In a mode in which a subset of snapshots is employed, the composition of the subset may be based on the most likely snapshot that facilitates successful decompression, e.g., a snapshot determined by the packet sequence number (e.g., the least significant bits of the sequence number) carried in the packet header.

According to a second independent and distinct aspect of its configuration and operation, the header decompressor further determines whether header decompression fails for a predetermined number of packets received after non-receipt of an expected packet in the flow. Such header decompression failure may result from the fact that: one or more of the non-received packets may have carried meaningful context update information, without which header decompression results in "context damage". If so, the header decompressor stores (e.g., using an assisted repair procedure) packets (e.g., "buffered packets") that were received after non-receipt and that have failed header decompression, and it is desirable to use such lost context update information to perform subsequent repairs of buffered packets when it is able to somehow recover the lost context update information. Thus, according to the second aspect, if the header decompressor takes one of a plurality of stored snapshots to obtain decompression of a subsequently received packet (e.g. by performing a repair procedure), the snapshot of the header decompression context information that implements header decompression is updated and used (e.g. by a secondary repair procedure) to retry header decompression of the stored (buffered) packet.

In a second aspect, employing one of a plurality of stored snapshots to effect recovery of decompression of a subsequently received packet is feasible in two example scenarios. In the first such case, the context update information required for decompression of buffered packets is out-of-order packets that are delayed and received by the header decompressor only after a context corruption is detected (handled as later received packets). In a second such case, the context update information needed for decompressing a buffered packet is obtained by retransmission in another packet (handled as a later received packet), as described below in connection with the third aspect.

According to a third, independent and distinct aspect of its configuration and operation, the header decompressor generates an unreceived notification of an expected packet in the flow when the packet header cannot be decompressed (e.g., using a repair procedure). Preferably, the non-received notification includes packet retransmission information to enable retransmission of packets with appropriately updated header decompression context information (e.g., from a header compressor over a link) to recover the effort of a header decompressor performing successful header decompression (e.g., using a repair procedure). For example, the notification of non-receipt includes the sequence number of the last successfully decompressed packet as packet retransmission information.

As an example implementation, the header decompressor stores the snapshot in a sliding window memory. The size of the sliding window memory is preferably determined by the product of the bandwidth and the delay of the link. The header decompressor updates the contents of the sliding window memory by ensuring that the oldest snapshot in the sliding window memory corresponds to the maximum reordering depth that the sliding window memory can handle.

According to a fourth separate and distinct aspect of its configuration and operation, the header decompressor (e.g., by performing a window allocation procedure) temporarily allocates reusable memory for the plurality of stored snapshots according to one or more window parameters received over the link. The parameters may represent one or more (preferably all) of the following: a size of a reusable memory in which a plurality of stored snapshots are stored; allocating time for a reusable memory for storing a plurality of stored snapshots; time to deallocate reusable memory used to store the plurality of stored snapshots.

According to this fourth aspect, the header decompressor applies additional memory and processing requirements to the sliding window memory only selectively, e.g. at times indicated by the window parameter. Advantageously, with this fourth aspect, memory locations allocated for sliding window memory may be temporarily allocated or used when no repair procedure is invoked or expected. The time for invoking or anticipating the repair process of the header decompressor, and thus the allocation of the sliding window memory, may include various types of handoffs and handovers or any other time or period when packets may be prone to out-of-order or to being lost. Such times may be determined by measurement or predicted by historical (likelihood) information.

Drawings

The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred embodiments, as illustrated in the accompanying drawings in which reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.

FIG. 1 is a diagram of an example compressor state machine.

FIG. 2 is a diagram of an example U-mode state machine.

Fig. 3 is a diagram illustrating the logic of the state machine added to the CR state.

Fig. 4 is a diagram illustrating an example U-mode decompressor state machine.

Fig. 5 is a diagram illustrating a general telecommunications system used as an example context for illustrating a technique for header decompression repair.

Fig. 6A is a schematic diagram illustrating basic example functional entities of a header decompressor according to the first example aspect.

Fig. 6B is a diagram illustrating a basic example functional process performed by the header decompressor of fig. 6A.

Fig. 6C is a diagram illustrating basic example operations performed by the header decompressor of fig. 6A.

Fig. 6D is a diagram illustrating basic example operations and events performed by the repair process of the header decompressor of fig. 6A.

FIG. 7 is a diagram illustrating an example sliding window maintained by the window manager.

Fig. 8A is a schematic diagram illustrating basic example functional entities of a header decompressor according to the second exemplary aspect.

Fig. 8B is a diagram illustrating a basic example functional process performed by the header decompressor of fig. 8A.

Fig. 8C is a diagram illustrating basic example operations performed by the header decompressor of fig. 8A.

Fig. 8D is a diagram illustrating basic example operations and events performed by the repair process of the header decompressor of fig. 8A.

Fig. 8E is a diagram illustrating basic example operations and events performed by the assisted repair process of the header decompressor of fig. 8A.

FIG. 9 is a diagram illustrating an example sliding window maintained in the case where an assisted repair process is utilized.

Fig. 11 is a diagram representing a general telecommunication system illustrating a third aspect in which a notification is provided to a compressor about the fact that a packet expected by a decompressor has not been received.

Fig. 11A is a diagram representing a general telecommunication system illustrating a third aspect in which notification is provided via an in-band feedback signal from a decompressor.

Fig. 11B is a diagram representing a general telecommunications system illustrating a third aspect in which notification is provided via link layer messaging.

Fig. 12A is a schematic diagram illustrating basic example functional entities of a header decompressor in accordance with the third exemplary aspect, wherein the header decompressor comprises a retransmission requester.

Fig. 12B is a schematic diagram illustrating basic example functional entities of a header decompressor in accordance with the third exemplary aspect, wherein the header decompressor comprises a link layer loss notifier.

Fig. 12C is a diagram illustrating selected basic example operations performed by the header decompressor of either of fig. 12A or 12B.

Fig. 12D is a diagram illustrating selected basic example operations performed by the header compressor of fig. 11 upon receipt of a feedback notification.

Fig. 13 is a diagram representing a generic telecommunication system illustrating a fourth aspect in which a header decompressor temporarily allocates reusable memory for a plurality of stored snapshots in accordance with one or more window parameters.

Fig. 14 is a schematic diagram illustrating basic example functional entities of a header decompressor according to the fourth example aspect of fig. 13.

Fig. 15A is a schematic diagram of a particular telecommunications system used as an example context in which the present invention may be employed, in which a header compressor is included in a General Packet Radio Service (GPRS) service (SGSN) node.

Fig. 15B is a schematic diagram of a particular telecommunications system useful as an example context in which the present invention may be employed, in which a header compressor is included in a gateway General Packet Radio Service (GPRS) support node (GGSN).

Fig. 15C is a schematic diagram of a particular telecommunications system used as an example context in which the present invention may be employed, in which the compressor is included in a Radio Network Controller (RNC).

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth such as the particular architecture, interfaces, techniques, etc., in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail.

Fig. 5 illustrates an example telecommunications network 20 in which a packet stream is provided by a packet source 21. For example, fig. 5 illustrates a media packet 22 having a Media Payload (MPAY) and a header (MH) applied to a protocol stack 23. The specific protocols that make up the protocol stack may vary and typically include application protocols below the internet protocol and below the transport protocol. In the particular illustrated example, the protocol stack 23 is used to attach protocol headers 24 (e.g., IP, UDP, and RTP) to the media packets 22. The media packet 22 with its appended protocol header 24 is applied to a packet header compressor 25. The packet compressor 25 compresses the protocol header 24, generating a compressed header 26 of the packet. The header compressor 25 performs header compression in accordance with any one of a number of suitable header compression algorithms, conventional (e.g., ROHC or SigComp) or otherwise. After the packet header is compressed by the header compressor 25, the packet formatter 26 adds a compressed header to the packet applied to the transceiver 29. The transceiver 29 is operative to transmit packets, such as the packet 30 with its compressed header 26, in a packet stream 34 over an interface 38 to a remote unit 40 via a link 36. It is possible that most of the flow 34 of packets with compressed headers need not be contiguous, but may be sporadic, depending on the type of packet service involved and the nature of the material (e.g., media type) contained in the packet service.

The packet flow emanating from the packet source 21 of fig. 5 may be implemented in various ways. For example, a packet flow may: (1) pre-recorded and sent by the server (in this case, the media in the media packets 22 is already encoded); (2) from a transcoder that adapts the original media from the source to another media encoding that may be more suitable and/or supported by the terminal; or (3) from a source that performs real-time encoding of real-time media. Thus, the header compressor may receive incoming media packets from any of several types of media sources at a location in the IP network. The packet source 21 may be any suitable source, such as a media server, and may be located in a node or network that is common to or remote from the header compressor 25.

The telecommunications elements shown above to the left of the interface 38 in fig. 5 are merely representative of some of the elements germane to the present discussion and are understandably not integral to the telecommunications network 20, as there are many other elements not shown. Furthermore, the set of elements may be distributed over one or more nodes or networks (e.g. a core network or a radio access network), and in some cases the individual elements may themselves be distributed over multiple platforms and/or nodes. Thus, for the sake of brevity, the elements are shown as being continuously connected directly together in the manner of FIG. 5.

Although remote unit 40 has a number of elements, some basic representative elements that are suitable for understanding the header decompression performed by remote unit 40 are shown in fig. 5. Among these elements is a transceiver 42 that applies packets received over link 36 to a packet deformatter 44. The packet deformatter 44 is primarily used to extract the compressed header from the received packet. After extracting the compressed header, the compressed header is sent to a header decompressor 46 for decompression. After the packet headers are decompressed by header decompressor 46, the packets containing their decompressed headers are stored by buffer manager 48 in decompressed packet buffer 49. Buffer manager 48 also retrieves from decompressed packet buffer 49 decompressed packets needed by packet utilization application 50, e.g., a particular application involved in receiving a media stream, etc. In addition, remote unit 40 includes a packet formatter 52 for preparing packets to be looped back over link 36 (and the various illustrated elements upstream from packet formatter 52).

The header compressor 25 is used to compress packet headers (e.g., media packets) that have been provided by the packet source 21 and that may also have been encoded. In combination with its header compression, the header compressor 25 sends context information to the decompressor for use by the decompressor in decompressing the compressed headers of the media packets. As used herein, "context information" includes one or both of context initialization information and context refresh information. The context information may be included in the packet stream to remote unit 40 at regular intervals, as is typically the case (e.g., in RFC3095 ("robust header compression (ROHC) of Bormann, c.): framework and four subsets of protocols: RTP, UDP, ESP, and uncompressed", RFC3095, internet engineering task force, month 7 2001), or may be included in accordance with the media characteristics of the media packets disclosed in U.S. patent application serial No. (attorney docket No.: 2380 and 839), entitled "method and apparatus for header compression with transfer of context information depending on media characteristics", filed concurrently and incorporated by reference herein.

Header decompressor 46 is therefore adapted for use with a remote unit 40 (which may take the form of or be considered any of a number of devices/applications such as a mobile station, mobile terminal, wireless terminal, or user equipment unit). In the illustrated embodiment of fig. 5, header decompressor 46 is present in wireless remote unit 40. Thus, the remote unit 40 receives radio frequency transmissions over the air or radio interface, represented in fig. 5 by dashed line 38. The use of wireless remote unit 40 is, for example, in accordance with the RFC cited herein and incorporated by reference. It will be appreciated, however, that the header decompression techniques described herein are not limited to use with any particular type of remote terminal or terminal interface, and that these techniques may alternatively or additionally be used for transmission of radiation or waves other than wireless or via other than radio waves. Out-of-order packet reception may occur in a wired link network or system, for example, when there are different physical paths and thus different delays for the same virtual link.

Remote unit 40 receives packets including packets having compressed headers over link 36, such as an air interface. These packets are typically transmitted sequentially over the link. However, by virtue of processor 54 included in header decompressor 46, remote unit 40 is able to process out-of-order packets containing packets that are subject to a medium or high re-order. As used herein, a "medium reordered" packet means that the packet out-of-order corresponds to a number of tens of packets, while a "high reordered" packet means that the packet out-of-order corresponds to a number of hundreds of packets. This out-of-order processing is illustrated below by several representative, non-limiting and potentially independent aspects.

Retry decompression with stored ephemeral content state

Fig. 6A illustrates an example structure and/or functional units of a header decompressor 46(1) according to the first aspect. Header decompressor 46(1) includes decompression state machine 60 which receives packets from packet deformatter 44 having headers that require decompression. Decompression state machine 60 (in the manner described above and as understood by those skilled in the art) provides, for example, logic for feedback (if applicable) and identifies the type of packet for which decompression may be attempted. Decompression state machine 60 includes a packet header decompressor 62 that actually performs, or at least attempts to perform, decompression of packets requiring decompression.

Out-of-order packet processor 54 of header decompressor 46(1) also includes various other elements or functionality as shown in fig. 6A. Such elements or functionalities include a last context snapshot store 63, a sequence analyzer 64, a window manager 66, and a repair unit 68. Decompression failure unit/routine 70 is included in header decompressor 46(1), either separately or as part of out-of-order packet processor 54. As with other aspects of the header decompressor described below, these elements or functionality may be implemented individually or collectively using individual hardware circuits, using software running in conjunction with one or more suitably programmed digital microprocessors or general purpose computers, using Application Specific Integrated Circuits (ASICs), and/or using one or more Digital Signal Processors (DSPs).

Based on the basic events or steps of operation (as shown in fig. 6C), header decompressor 46(1) first detects the non-receipt of an expected packet in stream 34 of packets over link 36 (event 6C-1). In the example implementation of fig. 6A, the sequence analyzer 64 performs detection of non-receipt of a packet. Upon detecting a non-receipt of the expected packets in stream 34, as event 6C-2, header decompressor 46(1) stores, for each non-receipt, a snapshot of the header decompression context information that existed at the time of the non-receipt. As used herein, a "snapshot" or context item is state information that is needed and saved for decompression of a particular packet, i.e., a packet with sequence number SN ═ x. The identity and nature of this information is understood with reference to RFC3095(Bormann, c., "robust header compression (ROHC): framework and four subsets of protocols RTP, UDP, ESP and uncompressed", RFC3095, internet engineering task force, month 7 2001), each subsection including, for example, subsection 6.5, subsection 6.5.1 and subsection 6.5.2.

Depending on the packet, the snapshot may include all the context information that is present at the time, or (in a more economical case) only the dynamic and/or semi-static context information required for decompression of the packet header. For each context entry (snapshot) saved in the window memory 72, the value of the Sequence Number (SN) associated with the packet is saved as an index to that entry. In one mode of operation, the context information stored in the snapshot in the window memory 72 may be the entire context information that appears or exists when a packet is lost. In another more economical mode of operation, the context information stored in the snapshot in window memory 72 may simply be the dynamic and/or semi-static context information that currently exists when a packet is lost. It is feasible to save only semi-static and dynamic information as snapshots, since for example static information already exists in the context and static information does not change for a single stream.

Header decompression context information required for decompression when not received is obtained by decompression state machine 60 from context update packets received by remote unit 40 and stored in last context snapshot memory 63. In the described implementation, such a snapshot of header decompression context information is obtained from last context snapshot storage 63 and stored by window manager 66 in window storage 72 of the context snapshot. Then, when header decompressor 46(1) detects a header decompression failure of a subsequently received packet, header decompressor 46(1) determines (e.g., by performing a repair process performed by repair unit 68) whether header decompression of the subsequently received packet is available using one of the plurality of stored snapshots as event 6C-3.

FIG. 7 illustrates an example sliding window 74 that is maintained by window manager 66 in window memory 72. The circle indicator a in fig. 7 indicates that the most recent Sequence Number (SN) received has the value SN_currentThe sequence analyzer 64 detects five gaps or holes in the packet reception. Thus, a "snapshot" of the existing context information at each time of hole detection is inserted into five locations in the window memory 72. First window item x in window memory 72₀Corresponding to the oldest hole; second window item x in window memory 72₁Corresponding to the next oldest hole; and so on, wherein the window item x_iIs said to have a window order or window entry number i. As shown in FIG. 7, the window items have a base based on the oldest item (x)₀) Indexed index, where the index indicates the oldest item x₀And how many packets are received between the occurrence of the hole. For example, item x of FIG. 7₃Indicates that in item x₀(item x)₀Is x_ref) Forty-two groupings of holes after (a) appear to be holes. Items x in window memory 72_iGenerated from the detected hole, and for each entry, appropriate context update information (current context information when packet loss occurs) is stored in the corresponding entry.

The CnWnd interval size may be based on the bandwidth-delay product of the link to which header compression is applied. This can be used to derive the reordering depth. When the oldest snapshot slides out of window memory 72, the next oldest snapshot becomes the reference. For example, if in FIG. 7, window store 72 is full over time and the oldest snapshot is slipped out, then it was formerly taken as snapshot x₁Will become x₀And other snapshots are indexed against it. Window depth notification is in our needThe extent of tracing back in the history of the grouping of context snapshots is maintained in the window memory 72. This window starts at the point where a hole appears in the sequence and the upper limit is the last decompressed packet (decompressed current context state). The reordering depth may be the maximum possible reordering that a packet may experience on the link between the compressor and the decompressor, or may simply be the maximum amount of reordering that one wishes to be able to handle (which may be controlled by memory limitations).

The circle indicators B, C, D, and E of fig. 7 reflect the basic sub-events of the event 6C-3 and the respective basic operations of the repair unit 68. The circled indicator B represents a later received packet that failed decompression, where the sequence number of the failed packet is not known (and thus the failed packet is considered out of order). The circle indicator C of fig. 7 indicates that the repair unit 68 retries decompression of a packet received later. Upon retrying decompression, header decompressor 46(1) takes each of a plurality of stored snapshots, e.g., each of the five snapshots shown in fig. 7. The circle indicator C of fig. 7 reflects the fact that: if a subsequently received packet is not presented with either one of the snapshots being decompressible or the presentation is with more than one of the snapshots, the subsequently received packet may not be decompressible or another logic may be needed to decide which of a plurality of candidate snapshots to use with the subsequently received packet. On the other hand, as shown by the circled indicator E of fig. 7, if a later received packet is decompressed using only one of the snapshots in the example sliding window 74, the repair process may be successful and have enhancements to the assurance of resolution. In the particular case shown in fig. 7, the header presentation of a subsequently received packet that fails decompression at the circle indicator B is decompressible with the only one of the context snapshots in 74, namely snapshot context Delta _ C _ ref 2. Accordingly, the headers of later received packets have been decompressed and the packets may be applied to the buffer manager 48 for storage in the decompressed packet buffer 49.

Fig. 6B illustrates in more detail the functional aspects of out-of-order packet processor 54 of header decompressor 46(1) and the various communications or signals communicated therebetween. In fig. 6B, the entities are represented in functional terms, for example as procedures or routines. Thus, for example, repair process 68 corresponds to repair unit 68 of FIG. 6A.

In accordance with operation, fig. 6B indicates via signal S-1 that the packet header decompressor 62 notifies the sequence analyzer 64 upon successful decompression of the packet header. The sequence analyzer 64 receives the decompressed packet and verifies its sequence number. If the sequence number of a decompressed packet has a value in an expected order, e.g., in a sequence with the sequence numbers of other decompressed packets, the decompressed packet may be passed (via signal S-2) to buffer manager 48 for storage in decompressed packet buffer 49 (see fig. 5). Alternatively, if the sequence number of a packet whose header is decompressed by the last context snapshot store 63 is determined by the sequence analyzer process 64 to be out of order, a signal S-3 is sent to the window manager process 66. The window manager process 66 obtains (via signal S-4) the context information then present from the last context snapshot memory 63 and stores the context snapshot in the window memory 72 at the location corresponding to the hole caused by the lost packet. If the packet header decompressor 62 cannot decompress the packet, a failure notification signal S-5 is sent to the repair unit 68.

Those skilled in the art will appreciate that the entire packet with its header decompressed does not necessarily need to be sent to the sequence analyzer process 64 as long as the decompressed packet or at least its sequence number is sent. This also assumes that the sequence analyzer process 64 has the ability to forward successfully decompressed, ordered packets to the buffer manager 48 based on the results of its sequence analysis.

Fig. 6D illustrates the basic functional aspects of the repair unit 68 and the repair process performed thereby upon receipt of the failure notification signal S-5 (see fig. 6B). The functional aspects of the repair unit 68 correspond substantially to the primary event 6C-3 shown in fig. 6C. Thus, the enumerated Repair Events (REs) shown in FIG. 6D are substantially contained in one non-limiting example implementation of repair unit 68.

Repair event R-1 of FIG. 6D illustrates the receipt of a notification by repair unit 68. In the case of a decompression failure notification of signal S-5, such notification triggers event R-2. As event R-2, repair unit 68 determines the set of most suitable snapshots in window memory 72 to be used for retrying decompression of the packet header that failed decompression. As previously described, for each packet lost in the sequence of streams or groups of consecutive packets, header decompressor 46(1) stores the corresponding snapshot of the set of snapshots in sliding window memory 72. In a different mode, the header decompressor may retry decompression of a later received packet that failed decompression using all snapshots in the set or a subset of the snapshots in the set. Thus, repair event R-2 includes repair unit 68 determining whether to include all or a subset of the snapshots in window memory 72. In the case of a subset of snapshots, the repair unit 68 determines the composition of the subset based on which snapshots are the most likely snapshots to facilitate successful decompression, such as the snapshot determined by the packet sequence number (e.g., the least significant bits of the sequence number). Thus, as event R-2, the repair unit 68 first requests or fetches a set (or subset) of items (snapshots) by sending a signal S-6 to the window manager 66. The window manager 66 obtains the set (or subset) of items (snapshots) from the window memory 72 when sending the set (or subset) of items (snapshots) to the repair unit 68 as shown by signal S-7. The set (or subset) of items (snapshots) taken from the window store 72 is hereinafter referred to as the item of the set (or subset)₁To item_last。

As event R-3, the repair unit 68 retries decompression of the header of the failed packet. Retry decompression comprises a series of decompression retries, each retry involving an item₁To item_lastA different one of them. Signal S-6 of FIGS. 6D and 6B represents a representative one of the items, e.g., items, looped back to packet header decompressor 62 for retry decompression_i. As event R-4, item is taken_iWhether or not the retry decompression has a meaningful result is via a packet header decompressor 62 and processed by a repair unit 68Signal S-9 reports.

If it is determined that only one entry (e.g., only one context snapshot) results in correct decompression of the previously failed packet after all decompression retries of the failed packet are completed, then, as event R-5, repair unit 68 sends the repaired packet (as signal S-10) to buffer manager 48 for storage in decompressed packet buffer 49 (see fig. 5). In addition, as part of event R-5, repair unit 68 sends the sequence number of the repaired packet to sequence analyzer 64. The fact that only one context snapshot makes the packet header uncompressible adds confidence to the decompression.

If it is determined that more than one item (e.g., context snapshots) results in correct decompression of a previously failed packet after all decompression retries of the failed packet are completed, then as event R-6, repair unit 68 employs an additional verification mechanism, wishing to select one of the context snapshot candidates to be used deterministically for later received packets. Employing additional verification mechanisms may include, for example, transmission protocol (e.g., UPD or TCP) verification. Such checks may include, for example, a checksum or a cyclic redundancy Check (CRS). If the use of the additional checking mechanism results in a determination that only one of the candidate snapshots resolves the packet, then as event R-5, the repair unit 68 sends the repaired packet (as signal S-10) to the buffer manager 48 for storage in the decompressed packet buffer 49 (see fig. 5), and the sequence number of the repaired packet is sent to the sequence analyzer 64.

On the other hand, if decompression of the packet header did not occur using the snapshot entry, a failure notification is sent to the decompression failure unit/routine 70 as signal S-12. Similarly, if at event R-6, the repair unit 68(2) cannot decide which of the plurality of snapshot candidates is optimal for decompression, a failure notification is sent as signal S-12.

For convenience, the events performed by repair unit 68 as shown in FIG. 6D are collectively referred to as a routine for retrying packet header decompression with a window of context snapshots, such as routine 76. This naming is described from a further possible routine executable by the repair unit 68, such as routine 76 of routine 78 retrying decompression of the header of the buffered packet, as will be described later.

Thus, header decompressor 46(1) performs events such as the first aspect of the foregoing processing of out-of-order packets as decompression in conjunction with packet headers. Thus, header decompressor 46(1) maintains a sliding window of context snapshots, with the entries in the window containing only one transient context snapshot. The stored snapshot reflects the state of the context as it has been made at the time (hole in the sequence) of the lost packet (should have been received, and may also be considered reordered). For each packet (or a group of consecutive packets) lost in the sequence of packets in the stream, an entry is inserted in the sliding window. The robust nature of the header compression algorithm will treat this lost packet as a packet loss until it is eventually received. When such a sliding window is not maintained, packets reordered at a depth of more than about one in the case of ROHC are not decompressed.

The size of the sliding window is preferably equal to the reordering depth that the decompressor can handle. In one example implementation, the size of the window may be based on a bandwidth-delay product of the link. The oldest entry in the sliding window is the maximum reordering depth that can be handled. The successor entries may be stored as delta codes in the sliding window according to the oldest reference.

Repair unit 68 operates in an exemplary mode by assuming that packets that failed decompression are reordered (i.e., out of order). Repair unit 68 looks up the most likely appropriate window entry (context snapshot) in the sliding window that can be used to retry decompression of the failed packet. Finding the most likely appropriate window entry may be dependent on or based on the packet sequence number or may include all context snapshots in the sliding window 74. Repair unit 68 retries decompression of failed packets using a set of context snapshots from sliding window 74 one by one. The repair unit 68 considers decompression successful if exactly one decompression for the context window is successful. Otherwise, the attempt to repair is a failure. In performing the repair, the sliding window is updated to keep its size corresponding to the reordering depth.

Estimation of decompression success rate of out-of-sequence packets using sliding window

As a mode of operation, the header decompressor 46(1) of out-of-order packets can be employed to estimate the decompression success rate. The following is a derivation of this estimate, where table 1 represents the symbols used in the derivation.

Table 1: symbol for success rate estimation derivation

Symbol	Definition of
		Pr(item)	Probability of success of CRC check for decompression attempts employing window entry item (including header with residual error)
Prrepair(item)	Probability that decompression of reordered packets corresponding to window entry item will succeed (without including a header with residual error)

bits(field)	Compressing the number of bits of the field in the header
		x	Window entry corresponding to out-of-order received packet
xi	Sequence number of window item
		c_ref	Oldest context reference in window (x)i＝x0)
delta(c_ref)i	For a value corresponding to xiThe window item holds the difference between the oldest context references
		wnd_depth	Reordering depth that windows can handle
cnt_wnd	Window of transient context state where entries contain sequence numbers corresponding to packets not received

In connection with this derivation, the following considerations apply:

-Pr(x_i) 1/2 y, where y is the number of bits of the CRC (CRC-y), i! 0 ═ 0

-Pr(x_i) Given for no correlation between items (fully random data) -but this is not the case, so in reality Pr (x)_i) And even smaller.

-x_iIs a term in a window of size x +1 terms, iE [0, x]。

Now the probability that there will be more than one value in the window, Prepair (xo), is queried knowing that the window size is at least as large as the reordering depth of the links. Each item xi in the window has a probability of p (xi) being incorrectly interpreted as a correct value, where there is always a unique value (xo) known as the correct value (i.e., p (xo) ═ 1). Thus, let prepair (xo) be the probability of correctly decompressing the reordered packet xo from the multiple j-value entries held in the window (where wnd _ size is the link loss/reordering rate per reordering depth):

equation 1a

Equation 1b

Equation 1 yields table 2:

TABLE 2

For each case, the above values assume that 100% of the traffic employs one of CRC-3 or CRC-7 rather than some combination. Assuming that in a certain case 90% of the packets are PT-0 or PT-1(CRC-3) and 10% are PT-2(CRC-7), Prepair (xo) is given by equation 2.

Equation 2

Equation 2 yields table 3:

TABLE 3

In the derivation there is also an effect of the number of SN bits, i.e. this is valid when the number of SN bits yields such a small p that the actual value exceeds LsB interpretation intervals.

Determination of memory requirements for a sliding window of a context snapshot

Now consider the total decompressor memory requirement of the context window. To maintain a sliding window of contexts, the cost is one extra context size of the context identifiers (CDs) for which the decompressor wants to process the reordering plus a small amount of each increment of this context from packets lost from the sequence, as shown in equation 4.

Equation 4

A Context Identifier (CID) identifies a compressor flow and associates it to a context. This is required because many different streams may be compressed between the same compressor and decompressor pair. CID cannot match x shown in FIG. 7_iThe positions are correlated. It is the ordering information, typically the SN field, and x shown in FIG. 7_iThe positions are correlated. In equation 4, the acid is the active cidAnd wnd depth is the insertion rate (average number of entries per window size). For ROHC, the parameter Max _ CID is the upper limit of the acid. The worst case is when sizeof (delta (context)) is the size of the dynamic field.

Header decompression uses the LSB encoded SN bits (using rohc symbols) assuming a reordered packet (once the first decompression fails) to find (estimate) the correct context reference in the window. As previously mentioned, in some modes, it is not always necessary to try all references. The LSB encoding keeps the window of possible values for the LSB bits consistent. Only one value is possible in the window. However, by reordering packets (e.g., out-of-order packets), the LSB bits may correspond to the values that are considered old by the compressor and discarded (i.e., the window moves forward). Therefore, decompression is first attempted using the values in the LSB window. If failure occurs and the decompressor knows that reordering may have occurred, an "older" value may be tried for decompression.

Retry decompression for repair of buffered packets

According to a second independent and distinct aspect of its configuration and operation, the header decompressor also performs a secondary repair procedure on out-of-sequence packets. Fig. 9 illustrates a situation in which the second aspect and the auxiliary repair process may be advantageously employed.

In fig. 9, a circle indicator a represents the following fact: as successive packets x₁-x₆Is lost, no important context update is received. Since no important context update is received, in the lost packet x₁-x₆The received packet then encounters a decompression failure, as indicated by the circled indicator B in fig. 9.

For such a case, and in accordance with the second aspect described herein as shown in fig. 8A and 8B, out-of-order packet processor 54(2) of header decompressor 46(2) includes a secondary repair process 80, and repair unit 68(2) includes, in addition to routine 76, a routine 78 for retrying decompression of the header of buffered packets.

Fig. 8C illustrates the basic steps performed by the out-of-order packet processor 54(2) according to the second aspect in addition to the steps performed by the first aspect (described with reference to fig. 6C). As event 8C-1, the header decompressor 46(2) determines whether header decompression has failed for a predetermined number of packets received after non-receipt of a packet expected in the stream (e.g., whether an event shown by a circle indicator B in fig. 9 actually occurs). Such header decompression failure may result from the fact that: one or more of the non-received packets may already carry meaningful context update information, without which the header decompressor causes "context damage". If so, as event 8C-2, header decompressor 46(2) employs a secondary repair process 80 to store packets (e.g., "buffered packets") that were received after non-receipt and that failed in header decompression. Performing such storage or buffering of failed packets, it is desirable that the repair unit 68(2) can employ such lost context update information to perform subsequent repair of buffered packets when it is able to recover the lost context update information. Such storage or buffering of packets that fail decompression is shown by the circled indicator C in fig. 9.

Then, as shown at event 8C-3 and the circled indicators D, E and F in fig. 9, if header decompressor 46(2) attempts to obtain decompression of a subsequently received packet using one of the plurality of stored snapshots (using routine 76 for retrying packet header decompression using the window of context snapshots as previously described in connection with the first aspect). If a retry decompression of a subsequently received packet is successful with one of the context snapshots, as event 8C-4 and as indicated by the circled indicator G in fig. 9, the snapshot of the header decompression context information that implements header decompression is updated and used (e.g., by an auxiliary repair process) to retry header decompression of the stored (buffered) packet.

In a second aspect, employing one of a plurality of stored snapshots to effect recovery of decompression of a subsequently received packet is feasible in two example scenarios. In the first such case, the context update information required for decompression of buffered packets is out-of-order packets that are delayed and received by the header decompressor only after a context corruption is detected (handled as later received packets). In a second such case, the context update information needed for decompressing a buffered packet is obtained by retransmission in another packet (handled as a later received packet), as described below in connection with the third aspect.

Fig. 8A illustrates an example structure and/or functional units of a header decompressor 46(2) according to the second aspect. Header decompressor 46(2) and its associated out-of-order packet processor 54(2) comprise the same entities as previously described with respect to header decompressor 46(1) of fig. 6A and additionally comprise other such entities such as an auxiliary repair process 80 and a buffer manager 82 that manages the storage, retrieval and deletion of initially non-decompressible packets with respect to packet buffer 84. Packet buffer 84 is also referred to as a "problem" packet buffer due to the fact that packets stored in packet buffer 84 initially appear to be non-decompressible. As described above, repair unit 68(2) of header decompressor 46(2) includes not only routine 76 for retrying packet header decompression with a window of context snapshots, but also routine 78 for retrying decompression of the header of buffered packets.

Fig. 8B illustrates in more detail the functional aspects of and various communications or signals communicated between out-of-order packet processors 54(2) of header decompressor 46(2) other than those shown and previously described with reference to fig. 6B. The aspects, events and signals of fig. 8B, which are common to fig. 6B, may be understood from the discussion of fig. 6B and thus will not be described in detail. Also in fig. 8B, as in fig. 6B, the entities are represented in functional items, for example, as procedures or routines. Elements among the newly included functionality shown in fig. 8B are those of the auxiliary repair process 80 and the buffer manager 82.

The basic actions and events performed by the secondary repair process 80 are illustrated in FIG. 8E. For example, FIG. 8E shows that, as event 8E-1, the assisted repair process 80 monitors the history of the ordering of the decompressed packets. To do so, the secondary repair process 80 periodically communicates (via signal S-13) with the sequence analyzer 64 to determine what sequence numbers have been received and what expected sequence numbers are missing.

The auxiliary repair process 80 also monitors for notification of a header decompression failure sent by the packet header decompressor 62 as signal S-5 as event 8E-2. When multiple such header decompression failures are recorded, such as the repeated header decompression failure shown by the circled indicator B in fig. 9, as event 8E-3, the secondary repair process 80 determines whether the context may have been corrupted. If there is a probability of context corruption, then as event 8E-4, the auxiliary repair process 80 requests the buffer manager 82 to buffer packets whose headers have just failed decompression. Signal S-14 represents an instruction to the auxiliary repair process 80 to send a buffer failed packet to the buffer manager 82. Then, as event 8E-5, the auxiliary repair process 80 sends a set context damage indicator to the repair unit 68 (2). When "set," the context damage indicator informs the repair unit 68(2) about a suspected context damage and that the auxiliary repair process 80 is buffering packets for which header decompression failed. The sending of the set context damage indicator is represented by signal S-15. Then, as event 8E-6, the auxiliary repair process 80 passes the failure event notification of signal S-5 to the repair unit 68 (2).

If it is determined as event 8E-3 that a context corruption is not possible, then as event 8E-7, the auxiliary repair process 80 will clear or "reset" the context corruption indicator and will send the same signal as signal S-16. In addition, in conjunction with event 8E-6, the secondary repair process 80 passes a decompression failure event notification of signal S-5 to the repair unit 68 (2). Similarly, if it is determined that there is no repeated failure as event 8E-2, a clear or "reset" context damage indicator and a decompression failure event notification of signal S-5 are sent to the repair unit 68 (2).

Repair unit 68(2) of header decompressor 46(2) executes routine 76 (for retrying packet header decompression with a window of context snapshots) in substantially the same manner as previously described, and also executes routine 78 for retrying decompression of the header of the buffered packet in conjunction with the second aspect of header decompression. In addition to the previously described events of routine 76, FIG. 8D also represents additional events of routine 78, discussed below.

The discussion of the routine 78 for retrying decompression of the header of a buffered packet continues with event R-5 of fig. 8D, for example after the routine 76 has successfully decompressed the packet header using one of the context snapshots stored in the window memory 72. After doing so, routine 78 checks whether the context damage indicator is "set" (and thus indicates that the auxiliary repair process 80 has buffered one or more failed packets) or "reset" as event R-6. The context corruption indicator of routine 78 is maintained as event R-7 and updated in accordance with the receipt and processing at event R-1 of either a "set" context corruption indicator sent from the auxiliary repair process 80 as signal S-15 or a "reset" context corruption indicator sent from the auxiliary repair process 80 as signal S-16. If the context damage indicator has been reset, then as event R-8, repair unit 68(2) completes this particular example of its execution.

On the other hand, if at event R-6 it is determined that the auxiliary repair process 80 has determined and communicated a condition regarding the occurrence of a context corruption, then as event R-9, routine 78 directs window manager 66 (via signal S-18) to update the successfully used context snapshot in window memory 72. Then. As event R-10, routine 78 can fetch the buffered packet from packet buffer 84. Accordingly, routine 78 sends a buffer fetch signal S-19 to buffer manager 82. The buffer manager 82 responds by taking all packets in the packet buffer 84 (all of which failed the previous header decompression) and returning those packets as signals S-20 to the routine 78 of the repair unit 68 (2).

Having retrieved the decompression-failed packet from packet buffer 84, routine 78 retries all buffered packets, e.g., packets, as event R-11 using the most recently successful context snapshot at packet decompression₁To packet_lastHeader decompression.Figure 8D shows that the routine 78 sends each such packet, e.g., packet, one at a time, with signal S-21 to the packet header decompressor 62_j. For each packet sent to packet header decompressor 62 for retry header decompression, packet header decompressor 62 returns a result signal S-22. As event R-12, routine 78 analyzes each packet_iTo determine whether retry header decompression was successful. If the packet header is successfully decompressed by the routine 78, then as event R-13, the routine 78 of the repair unit 68(2) sends the successfully header-decompressed packet to the buffer manager 48 (via signal S-23) for storage in the decompressed packet buffer 49 (see fig. 5). In addition, as part of event R-5, repair unit 68 sends the sequence number of the repaired packet to sequence analyzer 64 as signal S-24. In addition, the repair unit 68(2) sends a signal S-25 to the buffer manager 82 to delete the successfully header decompressed packets from the packet buffer 84.

If the packet header is unsuccessfully decompressed by the routine 78, then as event R-14, the repair unit 68(2) must decide whether to drop (delete) the packet in question from the packet buffer 84 or to retain the packet in the packet buffer 84 before a more explicit determination can be made as to the actual loss of the packet. Fig. 8D shows via signal S-26 that the repair unit 68(2) instructs the buffer manager 82 to drop or delete still problematic packets from the packet buffer 84.

As event R-15, the routine 78 determines whether all packets in the packet buffer 84 have been retried for header decompression with a successful context snapshot. If header decompression has been retried for all packets in the packet buffer 84, the routine 78 completes its execution example, as shown by event R-16. Otherwise, retry header decompression of the remaining buffered packets continues.

Thus, in a second aspect of processing out-of-order packets in conjunction with header decompression, header decompressor 46(2) maintains a sliding window of references, such as context snapshots, as in the first aspect. Header decompressor 46(2) buffers (e.g., in packet buffer 84) the packets that failed decompression. Buffering is performed under the following assumptions: when decompression fails repeatedly for multiple packets after one or more consecutive packets encounter a loss, context damage may occur if no valid update is received. Valid updates are the encoded robust property of the SN bits and updates that are not covered with respect to a function established for that field, such as a semi-static field or a field that does not change often. It may also be an update representing the SN field and/or the substantial jump in the field for which the SN-based function is established, i.e. the Time Stamp (TS), JP identifier (IP-ID). In this case, header decompressor 46(2) assumes that the lost packets are delayed by reordering, and this results in a repeat failure. It is also assumed that a packet that failed to decompress may also fail because it was reordered itself, in which case the window-based repair described above with reference to routine 76 is invoked. If window-based repair is successful for a packet, header decompressor 46(2) updates (in a sliding window) the context entry used to decompress the packet, and then retries decompression of the buffer entry to which the updated window entry may be applicable. Reordered packets decompressed using window-based repair are likely to be correctly decompressed if repair of one or more buffers is successful. On the other hand, if the repair fails, the buffer entry may be discarded.

Referring to fig. 9, the packets successfully decompressed in the circle indicators D, E and F are packets that have failed decompression repetition, i.e., packets that arrive out of order after the context is corrupted, for decompression. This packet contains the necessary information to update the context to a state suitable for correct decompression of a packet that failed a previous decompression. Note that if decompression of buffered packets proceeds successfully, this provides greater assurance that the reordered packets are also correctly decompressed with the correct reference.

Fig. 10 illustrates basic example operations performed by window manager 66 in conjunction with header decompressor 46 (2). Many of these example operations also apply to the operation of window manager 66 in conjunction with header decompressor 46 (1). As event 10-1, the window manager 66 handles any notifications or interface communications. For example, if the window manager 66 obtains an indication from the sequence analyzer 64 that the sequence number of the decompressed header of the most recently received packet is out of order, the window manager 66 obtains the last context snapshot from the last context snapshot store 63 as event 10-2 and then stores the last context snapshot in the correct location in the window store 72 as event 10-3. On the other hand, when the window manager 66 receives a set fetch request (e.g., signal S-6) from the routine 76 of the repair unit 68, as event 10-4, the window manager 66 fetches and returns the appropriate snapshot set from the window memory 72 (the set fetch response is, for example, signal S-7).

As event 10-5, window manager 66 updates window store 72, for example, by appropriately clearing a particular snapshot. As described above, the sliding context window 74 has a specified size (e.g., the product of bandwidth and delay) such that when newer entries enter the input end of the sliding context window 74, the oldest entry therein is shifted out to the output end of the sliding context window 74. Thus, event 10-5 manages the removal from the oldest snapshot in the sliding context window 74, with the result that any snapshot that loops to the exit end of the sliding context window 74 is considered to be associated with a hole that is irretrievable packet loss. Similarly, a successfully used snapshot may also be purged from the window memory 72 if the snapshot in the sliding context window 74 is successfully used to decompress packets and it is thereafter determined that the successfully used snapshots are not consecutive (e.g., in terms of sequence number) in turn with another hole at the time of packet reception (e.g., not adjacent to another snapshot in the sliding context window 74). The removal of a snapshot that is successfully used may occur because there are no neighboring snapshots that may have context information that depends on the context information of the snapshot being removed. In addition, the window manager 66 executes events 10-6 for controlling the determined size of the sliding window 74 and events 10-7 for controlling the sliding or movement of content through the sliding window, as needed.

Selective repair of context damage using decompressor triggered compressor retransmission

Fig. 11 generally illustrates a third separate and distinct aspect of its configuration and operation, in which, when out-of-order packet processor 54(3) is unable to decompress one or more packet headers, remote unit 40(3) generates and sends a notification 85 to header compressor 24(3) indicating the fact that header decompressor 46(3) encountered or may encounter decompression difficulties (e.g., decompression failure).

As a first example implementation of the third aspect, fig. 11A and 12A illustrate an example embodiment in which, upon failure of header decompressor 46(3A) to decompress a packet header, header decompressor 46(3) generates notification 85A to header compressor 25(3A) of the fact that no packet is expected in the flow. In this regard, fig. 11A shows that header decompressor 46(3) is equipped with decompression failure unit/routine 70(3) which generates notification 85A. Thus, the notification shown in FIG. 11A takes the example form of an in-band feedback notification 85A.

11B and 12B illustrate an example embodiment in which a link layer process 86 identifies an event such as a packet reception failure and sends a link layer notification 85B to the corresponding link layer process 28. The corresponding link layer process 28 then informs the header compressor 25(3B) of the actual, anticipated, or expected packet decompression difficulties, as indicated by arrow 87.

Fig. 12A and 12B illustrate two example implementations of header decompressor 46(3A) and header decompressor 46(3B) shown in fig. 11A and 11B, respectively. In header decompressor 46(3) of fig. 12A, decompression failure unit/routine 70(3A) includes retransmission requester 87. Alternatively, in header decompressor 46(3B) of fig. 12B, decompression failure unit/routine 70(3B) may optionally include retransmission requester 87 (as shown by the dashed line), but the embodiment of fig. 12B contains the link layer notification of fig. 11B.

The feedback notification 85A of the embodiment of fig. 11A and 12A and the link layer notification 85B of the embodiment of fig. 11B and 12B are both used to trigger selective retransmission of packets from the header compressor 25 (3). Thus, as reflected by these two alternative implementations, the compressor selective retransmission may be the result of either a notification from the link layer to the compressor 25(3), e.g., that a number of losses occurred (using the link layer loss notification 85B), or a decompressor retransmission request, e.g., feedback (using the retransmission requester 87).

The repair process employed by header decompressor 46(3A) of the embodiment of fig. 11A or the repair process employed by header decompressor 46(3B) of the embodiment of fig. 11B may be the repair process of fig. 6D employing only routine 76 or the repair process of fig. 8D employing routine 78 (for retrying decompression of a header of a buffered packet) in addition to routine 76. This is the case whether header decompressor 46(3) takes the form of fig. 12A with its retransmission requester 87, the form of fig. 12B with its link layer loss notification 85B, or any other form.

The basic example events or actions performed by the decompression failure unit/routine 70(3A) are shown in fig. 12C. The action of decompression failure unit/routine 70(3A) is initiated as event 12C-1, which is the receipt and processing of a non-repairable notification (e.g., signal S-21) from the repair unit 68 retrying decompression. Upon receiving such a non-repairable notification, as event 12C-2, decompression failure unit/routine 70(3A) takes (from sequence analyzer 64) the sequence number of the last packet whose header was successfully decompressed. The removal of the sequence number of the last packet whose header was successfully decompressed is represented in fig. 12C by signal S-27, while the feedback or other consultation about the sequence number from the sequence analyzer 64 is shown as signal S-28. Event 12C-3 indicates that decompression failure unit/routine 70(3A) includes the sequence number of the last packet whose header was successfully decompressed in the failure notification provided to header compressor 25(3A) via feedback notification 85A (see fig. 11A).

According to this third aspect, in the implementation mode of fig. 11A or 11B, the header decompressor 46(3) triggers the compressor to selectively retransmit the context update packet. The retransmission of the context update packet is triggered by a failure notification from the link layer, e.g. with link layer notification 85B, or in response to a negative acknowledgement 85A from the decompressor, e.g. with retransmission requester 87. As described with reference to fig. 12C, this feedback typically contains the sequence number of the last successfully decompressed packet.

To retransmit the correct compressed packet, compressor 25(3) maintains a compressor sliding context window 90 substantially equivalent to decompressor sliding window 74. The similarity and related nature of the sliding contextual window 74 and the compressor sliding contextual window 90 is illustrated by the dashed arrow 92 in fig. 11.

Fig. 11 and 11A and 11B show header compressor 25(3) maintaining compressor sliding context window 90. Each entry in compressor sliding context window 90 includes or contains a compressed header that has been sent to remote unit 40. Not all of the compressed headers generated by header compressor 25(3) need be included in compressor sliding context window 90. The compressed headers that must be included in the compressor sliding context window 90 are those used to update one or more fields of the context (other than the fields related to the established function for the Sequence Number (SN)). In particular, the compressed headers inserted in the compressor sliding context window 90 are those that update fields other than the SN, IP-ID or RTP Timestamp (TS) fields. A compression header for updating a function established for the Sequence Number (SN) may also be inserted into the compressor sliding context window 90.

As with the sliding context window 74 maintained by header decompressor 46(3), the window size of the compressor sliding context window 90 is equal to the reordering depth that can be handled by compressor 25 (3). Similarly, the oldest entry residing in the compressor sliding context window 90 is the maximum reordering depth that can be handled. Similar to the size of the sliding context window 74, the size of the compressor sliding context window 90 may be based on the link bandwidth-delay product.

Fig. 12D illustrates the basic actions or events performed by header compressor 25(3) upon receiving a feedback notification 85 from header decompressor 46(3), e.g., from retransmission requester 87 or link layer 86 or any other such repair failure notifier. When header compressor 25(3) determines that feedback notification 85 is received as event 12D-1, header compressor 25(3) obtains the sequence number included in feedback notification 85 as event 12D-2. The sequence number contained in the feedback notification 85 should be the sequence number of the last packet whose header was successfully decompressed by the header decompressor 46 (3). Then, as event 12D-3, header compressor 25(3) obtains information from its compressor sliding context window 90 that allows header decompressor 46(3) to repair the context. This information typically relates to one or more items of compressed headers from the compressor sliding context window 90 that have a higher sequence number in the sequence than the sequence number received in the feedback notification 85. As event 12D-4, header compressor 25(3) transmits context repair information (e.g., one or two snapshots with higher sequence numbers in compressor sliding context window 90) in the packet to remote unit 40.

Retransmission of higher sequence number packets by header compressor 25(6) may be useful to the decompressor in cases of high loss and/or reordering rates (e.g., out-of-sequence rates). In the case of loss, fewer packets will be lost. In the case of reordering, packets that cannot be decompressed until the delayed packet is received can be decompressed faster, assuming retransmission is better than the delayed packet over the link (which has a low probability of occurrence when possible). In addition, header compressor 25(3) should perform the same repair action (reduce compression of certain packets) upon receiving feedback from the decompressor, i.e. this logic is an addition rather than a replacement.

Notification of decompressor about reordering

In accordance with a fourth separate and distinct aspect of its configuration and operation, fig. 13 and 14 illustrate a header decompressor 46(4) that temporarily allocates reusable memory for a plurality of stored snapshots in accordance with one or more window parameters communicated to a remote unit 40 (4). In the example shown in fig. 13 and 14, the remote unit 40 receives a notification via the link layer that a sliding contextual window 74 will be needed or useful, possibly for a time, and notifies the window allocation process 92 of the window manager 66 to allocate the necessary storage locations in the window memory 72. Fig. 13 specifically shows (via link layer message 94) that the link layer 28 on the network side notifies the link layer process 86 in the remote unit 40 of the need to allocate window memory 72, and that the link layer process 86 forwards the window allocation indication and information (via signal 96) to the window allocation process 92.

To reflect the fact that the window memory 72 may be temporarily allocated according to this fourth aspect, a sliding context window 74 is shown in dashed lines in fig. 13 and 14.

The parameters transmitted in the sliding window assignment message (e.g., link layer message 94) may represent one or more of the following (preferably all of the following): a size of a reusable memory in which a plurality of stored snapshots are stored; allocating time for a reusable memory for storing a plurality of stored snapshots; time to deallocate reusable memory used to store the plurality of stored snapshots.

According to this fourth aspect, the header decompressor applies additional memory and processing requirements to the sliding window memory only selectively, e.g. at times indicated by the window parameter. Advantageously, with this fourth aspect, memory locations allocated for sliding window memory may be temporarily allocated or used when no repair procedure is invoked or anticipated. The time to invoke or anticipate the repair process of the header decompressor, and thus the allocation of the sliding window memory, may include various types of switches and handovers, or any other time or period of time when packets may be prone to out-of-order or to being lost. Such times may be determined by measurement or predicted by historical (likelihood) information.

Thus, the link layer or other network function may inform the decompressor about the time period when reordering is occurring or is likely to occur (or the loss rate may increase). The notification should include: information on a start _ event of a period; information on the end of the period (start _ stop); the degree of depth (depth) is reordered. Upon receipt of the start _ event notification, the decompressor can then start filling the window of size depth with a full reference and gradually fill it with new entries as packets are lost in the sequence to perform window-based repair when packet decompression fails. The decompressor may also buffer packets that still failed to decompress after performing the window-based repair, in order to attempt the buffer-based repair later when the reordered packets are successfully decompressed.

This fourth aspect makes additional memory and processing requirements necessary only when reordering (or increased loss) is likely to occur. This signal may be relevant, for example, when a handover occurs or when link quality degrades-thereby resulting in a higher FER and/or more link layer retransmissions. This may provide memory savings because the decompressor may not want to keep a history of the context all the time — only when it is useful.

It will be appreciated that while the window memory 72 and packet buffer 84 are illustrated in the example implementation as being in separate memories, this need not be the case. In practice, the window memory 72 and the packet buffer 84 may have corresponding locations in the same storage device when used. Such storage devices may take any of several forms, including Random Access Memory (RAM) or semiconductor memory, to name just two non-exhaustive examples.

In an example implementation, the remote terminal is a user equipment unit that receives packets (with compressed headers) over an air interface. As mentioned above, other forms or remote units are possible. When the remote terminal takes the form of a user equipment unit, the headers are preferably compressed using robust header compression (ROHC) in U/O mode, but may be compressed using other techniques such as SigComp. SigComp is described, for example, in the following documents (all of which are incorporated herein in their entirety by reference): price, r. et al, "signaling compression (SigComp)", RFC3320, internet engineering task force, 12 months 2002; hannu, h. et al, "signaling compression (SigComp) -extended operations", RFC3321, internet engineering task force, 12 months 2002; U.S. patent publication US 2004/0047301. The header decompressor typically determines that header decompression fails (e.g., for a subsequently received packet) by failing to verify header decompression for the subsequently received packet using a Cyclic Redundancy Check (CRC) or transport layer checksum.

The more detailed illustrative embodiments presented above that represent specific units, functionalities and signals are not restrictive, mandatory or limiting, but are used only as example implementations.

A non-limiting example environment for implementation of the above described network is a telecommunications network 100 such as that shown in fig. 15A. The example telecommunications network 100 includes a radio access network 110 and a core network 112. The core network 112 is shown as including a circuit switched domain 113 and a packet switched domain 114. In the specifically illustrated example, the circuit switched domain 113 (e.g., a PSTN/ISDN-connected oriented network) is shown as including a Mobile Switching Center (MSC)/visitor location register node 115 and a gateway MSC node 116. The packet-switched domain 114 is illustratively shown as including a General Packet Radio Service (GPRS) service (SGSN) node 117 coupled to a gateway General Packet Radio Service (GPRS) support node (GGSN) 118.

The Gateway GPRS Support Node (GGSN)118 provides an interface to packet-switched networks (e.g., the internet, x.25 external networks) and thus serves to convert data formats, signaling protocols, and address information to allow communication between different networks. Serving GPRS Support Node (SGSN)117 provides packet routing to the SGSN service area and serves GPRS subscribers physically located within the SGSN service area. The Serving GPRS Support Node (SGSN)117 provides functions such as authentication, ciphering, mobility management, charging data and logical link management for the user equipment unit. A GPRS subscriber may be served by any SGSN in the network depending on location. The functionality of the Serving GPRS Support Node (SGSN)117 and the Gateway GRPS Support Node (GGSN)118 may be combined into the same node or may exist in separate nodes as shown in fig. 15A.

In the embodiment of fig. 15A, a General Packet Radio Service (GPRS) service (SGSN) node 117 of the core network node 112 is also shown as including a header compressor 25-15A. The structure and operation of the header compressor 25-15A is substantially similar to the general typical header compressor 25 described previously.

The core network 112 is connected to the radio access network 110 by a radio access network interface indicated by dashed line 122. The radio access network 110 includes one or more control nodes 126 and one or more radio Base Stations (BSs) 128. In an exemplary, non-limiting implementation in which the radio access network 110 is a UMTS Terrestrial Radio Access Network (UTRAN), the radio access network interface shown by dashed line 122 is referred to as the Iu interface, and the control node 126 takes the form of a Radio Network Controller (RNC). The function and composition of the radio network control node 126 is known to those skilled in the art, such as diversity switching units, controllers and various interfaces. In other implementations of the radio access network 110, the control node 126 may have other names, such as Base Station Controller (BSC), radio network control node, and so on. In any case, it should be understood that the radio access network 110 of fig. 15A is represented with only one control node 126 for the sake of brevity, wherein the control node 126 is connected to two Base Stations (BSs) 128. As understood by those skilled in the art, the radio access network 110 typically has a number of control nodes 126 which may be connected by interfaces not shown, such as the Iur interface.

Also for simplicity, only two base station nodes 128 are shown connected to the representative control node 126. It will be appreciated that different numbers of base stations 128 may be served by each control node 126, and that the control nodes 126 need not serve the same number of base stations. Further, those skilled in the art will also appreciate that a base station is sometimes also referred to in the art as a radio base station, a node B, or a node B.

In short, it is assumed in the discussion that follows that each base station 128 serves one cell. However, those skilled in the art will appreciate that a base station may be used to communicate over the air interface for more than one cell. For example, two cells may utilize resources located on the same base station site. Further, each cell may be divided into one or more sectors, with each sector having one or more cells/carriers.

Remote unit 140 communicates over a radio or air interface 138 with one or more cells or one or more Base Stations (BSs) 128. In different implementations, remote unit 140 may be referred to by different names, such as remote terminal, wireless terminal or wireless unit, mobile station or MS, mobile terminal or MT, or user equipment Unit (UE). Of course, each base station typically serves many remote units, although only one remote unit 140 is shown in fig. 15A for ease of illustration.

In the above example UMTS implementation, the radio access is preferably based on Wideband Code Division Multiple Access (WCDMA), where each radio channel is allocated using a CDMA spreading code. Of course other access methods may be used.

Remote unit 140 has a header decompressor 25-15A that contains an out-of-order packet processor 54. The structure and operation of the remote unit 140 and header decompressor may be, for example, any of the header decompressors with their associated out-of-order packet processors 54 as described above in connection with any of the aspects. The structure and operation of other unillustrated components of the remote unit 140, including component transceivers, protocol stacks, decoders, buffers, etc., are known to those skilled in the art.

In the embodiment of FIG. 15B, a gateway General Packet Radio Service (GPRS) support node (GGSN)118 is shown to include a header compressor 25-15B in place of that included on SGSN 117. The structure and operation of the header compressor 25-15B is substantially similar to that previously described.

In the embodiment of fig. 15C, the radio network controller node 126 is shown to include a header compressor 25-15C in place of one of the core network nodes. The structure and operation of the header compressor 25-15C is substantially similar to the general representative header compressor 25 described previously.

Although nodes such as those shown in fig. 15A, 15B, and 14C have myriad other elements and functionalities, as will be appreciated by those skilled in the art, only those elements and functionalities described herein are necessary or helpful in explaining the contextual information transfer techniques described herein.

It should be noted that even the generic terms "header compression", "header compressor" and "(header) decompressor" are used to indicate that the applicability of this concept is not limited to any particular header compression scheme. This is particularly applicable to most ROHC protocol subsets, including but not limited to ROHC-TCP (0x0006), ROHC RTP (0x0001), UDP (0x0002), IP (0x0004), ESP (0x0003), UDP-Lite (0x0008), RTP/UDP-Lite (0x0007) header compression protocol subsets. Part of the proposed solution also has the advantage that it does not require any changes to any of the ROHC standards.

It should also be appreciated that the header decompression techniques and other activities described herein need not be performed on a similarly structured node or terminal as illustrated and/or described herein. Rather, various functions may be distributed or dispersed to other nodes or devices or even networks (e.g., core and radio access networks). Furthermore, even the header compression function may be distributed to a plurality of nodes and/or devices, if necessary.

The term "network node" as used herein denotes any node or unit or a part of a node or unit as described herein, which performs in whole or in part the control of the transfer of context information, e.g. in accordance with the above.

Furthermore, the node or apparatus comprising the header compressor 25 may or may not be more than one node or network interface located remotely from the receiving entity. For example, a reference herein to the context information being sent over the air or radio interface to a receiving entity (e.g., remote unit 40) does not require that header compressor 25 be located in a node or location adjacent to the radio interface.

While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements.

Claims (17)

1. A remote terminal (40), comprising:

a transceiver (42) for receiving packets over a wireless interface (38), including packets (30) having compressed headers (26) and possibly out-of-sequence packets (30);

a header decompressor (46);

characterized in that said decompressor (46), upon detection of non-receipt of a packet (30) expected in a stream of packets (30) over a wireless interface (38), stores, for each non-receipt, a snapshot of header decompression context information existing at the time of said non-receipt, and wherein when said header decompressor (46) detects failure of header decompression of a subsequently received packet, said header decompressor (46) performs a repair procedure that determines whether header decompression of said subsequently received packet is available using one of a plurality of stored snapshots, and

wherein in performing the repair process, the header decompressor (46) retries decompression of the subsequently received packet using each of the plurality of stored snapshots, and if header decompression of the subsequently received packet is obtained using only one of the plurality of stored snapshots, the repair process determines that header decompression of the subsequently received packet was successful or that the repair process was successful

The repair process uses more than one of the plurality of stored snapshots to obtain decompression of the subsequently received packet, but the repair process uses an additional verification process to select between more than one of the plurality of stored snapshots.

2. The remote terminal of claim 1, wherein for each packet or group of consecutive packets (30) lost in the sequence of streams, the header decompressor (46) stores a corresponding snapshot of a set of snapshots in a sliding window memory (74).

3. The remote terminal of claim 1, wherein when said header decompressor (46) further determines that header decompression fails for a predetermined number of packets (30) received after non-receipt of expected packets (30) in said stream, said header decompressor (46) performs a secondary repair procedure that stores packets (30) received after said non-receipt and that header decompression failed.

4. The remote terminal of claim 1, wherein if execution of said repair procedure takes one of said plurality of stored snapshots to obtain decompression of said subsequently received packet, a snapshot of header decompression context information that implements header decompression is updated and used by a secondary repair procedure to retry header decompression of a stored packet (30).

5. The remote terminal of claim 1, wherein upon failure of said repair procedure, said header decompressor (46) generates an unreceived notification of an expected packet (30) in said flow, said unreceived notification including packet retransmission information to enable retransmission of packets having appropriately updated header decompression context information.

6. The remote terminal of claim 1, wherein the header decompressor (46) performs a window allocation procedure that temporarily allocates reusable memory for the plurality of stored snapshots based on parameters received over the link.

7. A method of operating a remote terminal (40), the remote terminal (40) receiving packets (30) over a link, including packets (30) having a compressed header (26) and possibly out-of-sequence packets (30), the method characterized by the steps of:

(1) detecting an expected non-receipt of a packet (30) in a flow of packets through the link;

(2) for each non-receipt, storing a snapshot of header decompression context information existing at the time of said non-receipt; then the

(3) Upon a failure of header decompression for a subsequently received packet, determining whether header decompression of the subsequently received packet is available using one of a plurality of stored snapshots;

(4) retry header decompression of the subsequently received packet using each of the plurality of stored snapshots;

(5) determining that header decompression of the subsequently received packet was successful if header decompression of the subsequently received packet was obtained using only one of the plurality of stored snapshots; or

Upon taking decompression of the subsequently received packet using more than one of the plurality of stored snapshots, an additional verification process is used to select between more than one of the plurality of stored snapshots.

8. The method of claim 7, further comprising:

determining whether header decompression fails for a predetermined number of packets (30) received after non-receipt at step (1), and if so: then

Storing the received packet (30) having failed header decompression after said non-receipt before performing step (3);

updating the snapshot of header decompression context information obtained in step (3) for header decompression of said subsequently received packet; and

retry header decompression of the stored packet (30) using the updated snapshot of header decompression context information.

9. The method of claim 7, further comprising:

determining whether header decompression fails for a predetermined number of packets received after non-receipt at step (1), and if so:

before performing step (3):

storing the received packet (30) having failed header decompression after said non-receipt; and

providing a notification enabling the compressor to send packets with appropriately updated header decompression context information as said subsequently received packets in step (3); and

retry header decompression of the stored packet (30) using the updated snapshot of header decompression context information.

10. The method of claim 7, further comprising temporarily allocating reusable memory for the plurality of snapshots stored in step (2) based on parameters received on the link prior to performing step (1).

11. The method of claim 7, wherein said header (26) has been compressed using one of "robust header compression (ROHC)" and "signaling compression SigComp" for U/O mode.

12. An apparatus for operating a remote terminal (40), the remote terminal (40) receiving packets (30) over a link, including packets having a compressed header (26) and possibly out-of-order packets, wherein the apparatus comprises:

means for detecting an unreceived of an expected packet (30) in a flow of packets through the link;

means for storing, for each non-receipt, a snapshot of header decompression context information existing at the time of said non-receipt;

means for determining, when header decompression fails for a subsequently received packet, whether header decompression of the subsequently received packet is available using one of a plurality of stored snapshots;

means for retrying decompression of the subsequently received packet using each of the plurality of stored snapshots; and

means for employing an additional verification process to select between more than one of the plurality of stored snapshots when decompression of the subsequently received packet is obtained employing more than one of the plurality of stored snapshots.

13. The apparatus of claim 12, wherein the apparatus further comprises:

means for retrying header decompression of the subsequently received packet using each of the plurality of stored snapshots;

means for determining that header decompression of the subsequently received packet was successful when header decompression of the subsequently received packet was obtained using only one of the plurality of stored snapshots.

14. The apparatus of claim 12, wherein the apparatus further comprises means for retrying decompression of the subsequently received packet using each of the plurality of stored snapshots using a repair process, wherein the repair process uses more than one of the plurality of stored snapshots to obtain decompression of the subsequently received packet, but wherein the repair process selects between more than one of the plurality of stored snapshots using an additional verification process.

15. The apparatus of claim 12, wherein the apparatus further comprises:

means for determining whether header decompression failed for a predetermined number of packets (30) received after not receiving an expected packet (30) in a flow of packets over the link, and if so, the apparatus further comprises:

means for storing packets (30) received after said non-receipt and determined to have failed header decompression, before header decompression fails for later received packets;

means for retrying header decompression of the stored packet (30) using the updated snapshot of header decompression context information.

16. The apparatus according to claim 12, wherein said apparatus further comprises means for performing generating an unreceived notification of an expected packet (30) in said flow, said unreceived notification comprising packet retransmission information enabling retransmission of packets having appropriately updated header decompression context information.

17. The apparatus of claim 12, wherein the apparatus further comprises:

means for determining, for packets (30) expected in a flow of packets not received over said link, whether header decompression failed for a predetermined number of packets (30) received, and if so said apparatus further comprises:

for, before header decompression fails for a subsequently received packet:

means for storing a packet (30) received after said non-receipt and determined to have failed header decompression; and

means for providing a notification to a compressor to enable said compressor to transmit a subsequently received packet having appropriately updated header decompression context information as a failure in header decompression for said subsequently received packet; and

means for retrying header decompression of the stored packet (30) using the updated snapshot of header decompression context information.