JP5043975B2

JP5043975B2 - パケット通信での性能を改善するためのヘッダフィールドの操作

Info

Publication number: JP5043975B2
Application number: JP2010071377A
Authority: JP
Inventors: ジムサンドクビスト，; ソルトハラスチ，; クリステルスヴァンブロ，; ラーズ−エリクヨンソン，; ヴィクネサンアヤドゥライ，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 1999-09-28
Filing date: 2010-03-26
Publication date: 2012-10-10
Anticipated expiration: 2020-08-11
Also published as: EP1216539A1; CA2385616A1; JP2003510964A; ES2340835T3; AU778401B2; WO2001024443A2; DE60043989D1; KR100673186B1; CN1146206C; JP4590144B2; AU6744100A; US6700888B1; CN1391757A; ATE460790T1; JP2010178363A; CA2385616C; WO2001024443A3; KR20020037361A; EP1216539B1

Description

本発明は、概してパケット通信に、より特定すると、パケット通信の性能を改善するためのヘッダフィールドの操作に関する。

インターネットの極めて大きな成功により、インターネットプロトコル、つまりＩＰ（ここに参照として取り込むJon Postel, Internet Protocol, DARPA RFC 791, 1981年9月を参照；ここに参照として取り込むSteven Deering とRobert Hinden, Internet Protocol, Version 6 (Ipv6) Specificaion, IETF RFC 2460, IETF IP Next Generation Working Group, 1998年12月を参照）を多くの様々なタイプのパケット通信リンク上で利用することは、理想的ではあるが、困難な課題となっている。インターネットプロトコルは、通常、伝送制御プロトコル、つまりＴＣＰ（ここに参照として取り込むJon Postel, Transmission Control Protocol, DARPA RFC 761, 1980年1月を参照）等の伝送プロトコル、ユーザーデータグラムプロトコル、つまりＵＤＰ（ここに参照として取り込むJon Postel, User Datagram Protocol, DARPA RFC 768, 1980年8月を参照）、又は、実時間転送プロトコル、つまりＲＴＰ（ここに参照として取り込むHenning Schulzrinne, Stephen L. Casner, Ron Frederick and Van Jacobson, RTP: A Transport Protocol for Real-Time Applications, IETF RFC 1889, IETF Audio/Video Transport Working Group, 1996年1月を参照）等のアプリケーションレベルプロトコルと共に使用される。

上記の全てのプロトコルでは、各データグラム（パケット）に挿入されるプロトコルヘッダが利用されている。あるプロトコルヘッダには、どれもが何らかの重要な目的のために利用される様々なフィールドが含まれており、従って、それらの情報は、最終目的地に適切に運ばれなくてはならない。

狭帯域のポイント・トゥー・ポイントリンク、例えば無線リンク上でのヘッダのオーバーヘッドを減少させるため、従来のヘッダ圧縮技術がしばしば使用されている。ヘッダ圧縮スキームでは、プロトコルヘッダで転送される情報量が圧縮され、狭帯域幅のリンクを使用する際に必要な帯域幅の量を減少させる。圧縮されたヘッダはリンクの受信側でヘッダ伸張器によって完全に再構成され、従って、ヘッダ圧縮／伸張プロセスがヘッダフィールドのインテグリティに影響することはない。

ルータごとにヘッダフィールドのいくつかを再計算及び／又は修正することも従来からなされている。そのような再計算／修正は、それらヘッダフィールドの機能の一部として意図的に設計されている。

特開平１１−２２０４６９号公報特開平４−１９６７３３号公報

本発明では、幾つかのヘッダフィールドがヘッダ圧縮／伸張にとって必ずしも不可避ではないにもかかわらず問題であることが確認された。そのようなフィールドの幾つかの例と、なぜそれらが必ずしも不可避でないにもかかわらず問題であるのかを以下に説明する。

インターネットプロトコルヴァージョン４（ＩＰｖ４）の確認（ＩＤ）フィールドは、従来から、様々なフラグメントに分割されたパケットの様々な部分を確認するために使用されている。しかし、ＩＰｖ４スペシフィケーションでは、送信ホストはＩＤフィールドに対して「その送信元−宛先のペアと、データがインターネットシステムでアクティブになるときのためのプロトコルにとってユニークな」値を与えることが要求されているだけである。この要求は、周知の様々な方法で順守することができるが、本発明では、ヘッダを圧縮する目的では、あるパケットストリームのヘッダの値を連続的に増加する態様でＩＤフィールドに割当てる（以下、「連続−ストリーム」割当てと称する）ことが好ましいことが確認された。他の周知の割当てスキームには、ＩＤフィールド値のランダム割当て、又は、いかなるホストから出力するパケットストリームの全てに共通のカウンタを使用して連続的に増加する値をＩＤフィールドへ割当てる方法（以下、「連続−ホスト」割当て）がある。本発明は、ランダム割り当て及び連続−ホスト割り当ての双方が、ヘッダ圧縮に使用するには問題があると認識する。

ヘッダ圧縮／伸張に問題のある他のＩＰヘッダフィールドは、有効期間／ホップリミット（ＴＴＬ／ＨＬ）フィールドである。このフィールドの値は、特定のパケットが取るパスで１ホップごとに１つ減少する。同様のパケットストリームに対応するパケットが、送信元と宛先の間の様々なパスを通って交互に行き来する場合、ＴＴＬ／ＨＬフィールド値は、相互に大きな違いの無い、典型的には小さな値である２つの値を交互にとることになる。従来、ＴＴＬ／ＨＬフィールド値は、変化する度にヘッダ圧縮器からヘッダ伸張器へリンク上を転送されなければならなかった。これにより、ヘッダ圧縮スキームの性能が不都合に制限され、それに応じて、必要帯域幅も増加することとなった。

上記の事項に鑑みて、例えば、ヘッダ圧縮スキームの性能にとって問題となる上記に記載のヘッダフィールドに対するヘッダ圧縮性能を改善することが望ましい。

本発明は、問題のあるヘッダフィールドに関して、ヘッダ圧縮スキームに対して透明で、且つヘッダフィールドの機能性を妨害することのない態様で、当該ヘッダフィールドのインテグリティを意図的に破壊することによってへッダ圧縮性能を改善する。このようなヘッダフィールドインテグリティの意図的な破壊は、ヘッダ圧縮を使用しないパケット通信パスにも有利に適用することができる。

上述したように、従来のヘッダ圧縮／伸張技術は、あるヘッダフィールドのインテグリティや機能性を破壊しない。とういのも、ヘッダフィールドは、（少なくとも理想的には）伸張器で完全に復元されるからである。同様に、上述したように、各ルータでのヘッダフィールドの再計算／修正は、あるフィールドのインテグリティや機能性を破壊しない。というのも、そのような再計算／修正は、実際、当該フィールドの一機能であるからである。

他の全てのヘッダフィールドの操作は、以下の２つの一般的な理由から、伝統的に禁止されてきた。つまり、（１）当該フィールドのインテグリティの破壊を回避するため、そして、（２）当該フィールドの機能性を妨害しないためである。更に、理由（１）がヘッダフィールドの操作を禁止することを正当化するために必要な唯一の理由と考えられてきたため、上記理由（２）については、実際全く考慮されてこなかった。しかし、本願発明は、上記理由（２）がヘッダフィールドを操作しない唯一の実質的な理由であると認識し、従って、本発明は、ヘッダフィールドのインテグリティの破壊によってヘッダフィールドの機能性が妨害されない限り、ある特定の状態では、ヘッダフィールドを操作し、その結果としてヘッダフィールドのインテグリティを破壊することは許容され得ると結論付けた。このようなヘッダフィールドの操作を、ここでは、機能性透明ヘッダフィールド操作と称する。

図１は、本発明に係るパケット交換通信ネットワークの実態態様の関連部分を図示する。図１において、ＨＣＮは、ヘッダ圧縮技術を使用したパケット通信ノードを示し、ＨＤＮは、ノードＨＣＮのヘッダ圧縮技術に対応したヘッダ伸張技術を使用したパケット通信ノードを示す。パケット通信ノードＨＣＮとＨＤＮは、データパス１５、例えば、セルラ無線リンク等の狭帯域ポイント・トゥー・ポイントリンクを介して連結される。セルラ無線リンクの例では、ノードＨＣＮはセルラ無線リンクを介して通信動作可能な従来の無線転送ステーションに設けられてもよく、ノードＨＤＮは、セルラ無線リンクを介して通信動作可能な従来の無線受信ステーションに設けられてもよい。当業者にとって明白なように、ノードＨＣＮ及びＨＤＮと両者の間を連結するデータパス１５によって表示されているパケット通信パス１８は、ヘッダ圧縮／伸張技術を利用する、いかなるタイプのポイント・トゥー・ポイントのパケット通信パスとしても具体化することができる。

図１ではまた、破壊ノード１３が図示されており、該破壊ノード１３は、１１で入力パケットストリームを受信し、１又は複数のパケットの１又は複数のヘッダフィールドを操作（変更）することによってヘッダフィールドのインテグリティを破壊し、更に、インテグリティが破壊された変更後のヘッダフィールドを含む対応する変更されたパケットストリームを１４で出力する。１４で、変更されたパケットストリームはノードＨＣＮへ入力される。パケットストリーム１４でヘッダフィールドを変更することによって、パケット通信パス１８、特にヘッダ圧縮／伸張動作において性能が向上する。ヘッダフィールドインテグリティの破壊は、パケット通信パス１８のヘッダ圧縮スキームに透明であり、変更されたヘッダフィールドの機能性は、ヘッダフィールドインテグリティの対応する破壊によって妨害されない。

以下の詳細な説明から明らかなように、破壊ノード１３は、独立のパケット通信ノードとして実行されてもよく、又は、図１の破線で示されたように、ノードＨＣＮに含まれていてもよい。

図２は、図１の破壊ノードの例示的な実施態様を図示する。図２の例示的な実施態様でパケットストリーム１１は、パケットストリーム１１のパケットからヘッダを抽出するヘッダエクストラクタ２２へ入力される。ヘッダエクストラクタは、ヘッダストリームを出力し、ヘッダ抽出の結果得られたペイロードストリームも出力する。ペイロードストリームは、ペイロードバッファ２８へ入力され、ヘッダストリームは、フィールドエクストラクタ２４へ入力される。フィールドエクストラクタ２４は、ヘッダストリームの各ヘッダをその構成フィールドまで分離する。これらの構成ヘッダフィールドストリームは、プロセシングポーション２６のそれぞれのフィールドプロセッサへ、２１で出力される。１または複数のフィールドプロセッサは２６で、対応するヘッダフィールドストリームの１又は複数のヘッダフィールドを変更する。

２３では、プロセシングポーション２６は、関連フィールドプロセッサによって変更されたものも含むヘッダフィールド群をヘッダアセンブラＨＡへ出力し、ここでは、２３で受信された構成ヘッダフィールドストリームから（インテグリティが破壊された１又は複数のフィールドを含む）変更されたヘッダストリームを組立てる。変更されたヘッダストリームは、ペイロードバッファ２８から受信したバッファされたペイロードストリームの対応ペイロードと変更されたヘッダストリームのヘッダを結合するコンバイナ２７へ、２５で出力される。コンバイナ２７は、図１に図示したように、変更されたパケットストリーム１４を出力する。

ヘッダアセンブラＨＡは組立てられたヘッダのフィールドをカバーする全てのチェックサム値（例えば、ＩＰＶ４チェックサム、又は、ＵＤＰ／ＴＣＰチェックサム）を再計算し、２６に表示のフィールドプロセッサによってなされたいかなるフィールド変更にも適応することができる。あるいは、フィールドプロセッサは、（例えば、図２の２９に表示された）ヘッダアセンブラＨＡに、いつヘッダフィールドが変更されたかを通知することができるので、ヘッダアセンブラは必要な場合だけチェックサム値を再計算することができる。

図３は、図２のフィールドプロセッサの例示的な実施態様を図示する。図３の実施態様では、図２のフィールドエクストラクタ２４によって２１で出力されたＴＴＬ／ＨＬフィールドストリームは、フィルタ３１へ３０で入力され、ここで、ＴＴＬ／ＨＬフィールドストリームの値に対して平滑化演算を適用する。そして、フィルタ３１の出力は、図３のヘッダアセンブラＨＡに適用される。

図４は、図３のフィルタ３１の実施態様を図示する。３０で受信されたＴＴＬ／ＨＬフィールドストリームの新値の各々がバッファ４１、セレクタ４２、及びコンパレータ４３に入力される。３０で受信された新値は、４１でバッファされた前の値と４３で比較される。コンパレータ４３の出力、ＤＩＦＦは、ＴＴＬ／ＨＬフィールドの新値とＴＴＬ／ＨＬフィールドの前の値の差異を示す。この差異ＤＩＦＦは、もうひとつのコンパレータ４５に入力され、図４においてＴＨ_ＤＩＦＦとして表示された閾値と比較される。コンパレータ４３から出力された差異が閾値を越える場合には、コンパレータ４５の出力４６は、図２のヘッダアセンブラＨＡに出力されるべき新値を選択する。コンパレータから出力された差異が閾値より小さい場合には、コンパレータ４５の出力４６は図２のヘッダアセンブラＨＡに出力されるべき（バッファ４１からの）前の値を選択する。

図５は、図４の実施フィルタによって実行される例示的演算を図示する。５１で新値を受信した後、５２で前の値と比較され、ＤＩＦＦの値を得る。当該実施態様では、ＤＩＦＦは、新値と前の値の間の差異の絶対値である。そして、５３では、ＤＩＦＦの値が閾値ＴＨ_ＤＩＦＦより小さいか否かが判断され、小さい場合には最後の値が５４で新値に代わり、小さくない場合には、新値がヘッダアセンブラＨＡへ提供される（図４のセレクタ４２を参照）。図４及び図５の例示的閾値ＴＨ_ＤＩＦＦは、ＴＨ_ＤＩＦＦ＝２である。このように、ＴＴＬ／ＨＬフィールドの値が（しばしばそうであるように）２以上に変化しない限りは、フィルタリング演算は新値が前の値と等しくなるように設定し、好適には、図２のノードＨＣＮを、ノードＨＤＮへ新値を送信する要求から開放し、以って、ヘッダオーバーヘッド要求を減少させる。

図６は、図２のフィールドプロセッサの更なる例示的実施態様を図示している。他の入力６３がゼロ値と連結しているセレクタ６２へは、フィールドエクストラクタ２４から受信されたチェックサムフィールド値（例えば、ＵＤＰチェックサム値）のストリームが６１で入力される。セレクタ６２の出力６４は、図２のヘッダアセンブラＨＡと連結している。セレクタ６２は、決定論理６６の入力６７及び６８でそれぞれ受信されたビットエラー率（ＢＥＲ）情報とペイロード情報に対して、決定論理６６によって動かされる制御入力６５を有する。

図７（ａ）は、図６の決定論理６６の例示的実施例を図示する。図７（ａ）の実施例では、コンパレータ７１は、データパス１５のビットエラー率（ＢＥＲ）と閾値ＴＨ_ＢＥＲを比較する。同様に、図７（ａ）では、コンパレータ７２は、パケットストリーム１１のペイロードのビットエラー感度を閾値ＴＨ_ＳＥＮＳと比較する。コンパレータ７１の出力７３とコンパレータ７２の出力７４は、ＡＮＤゲート７５に入力され、ここで、その出力は図６のセレクタ６２を制御する。コンパレータ７１に入力されたＢＥＲは、従来から、図１のＨＤＮ等のノードから図１のＨＣＮ等のノードへ提供されている。このように、ＢＥＲは、図７（ａ）の実施態様で使用されるために、ノードＨＣＮから破壊ノード１３へ容易に提供されうる。閾値ＴＨ_ＢＥＲの一例が１０^−４である。コンパレータ７２が受信したペイロード感度情報、つまり、どの情報がビットエラーに対するペイロードの感度を示すかは、関係するペイロードのタイプに拠る。閾値ＴＨ_ＳＥＮＳは、所望の性能に基づいて試験的に決定することができる。

図８（ａ）は、図６及び図７（ａ）のフィールドプロセッサの実施態様によって実行することができる例示的演算を図示する。ＢＥＲ及びペイロード感度情報を８１で取得した後、８２でＢＥＲが閾値ＴＨ_ＢＥＲを超過するか否かを判断する。超過する場合には、８３でペイロード感度が閾値ＴＨ_ＳＥＮＳより小さいか否かを判断する。小さい場合には、決定論理６６は、ゼロ値が６３でヘッダアセンブラＨＡにチェックサムフィールド値として出力されるようにセレクタ６２を制御する。このように、例えば、図１の１５のデータパスが比較的高いビットエラー率を有する場合、及び、パケットストリームのペイロードが比較的ビットエラーに対して鈍感な場合には、チェックサムフィールドは、その値をゼロに設定することによって、不活化する。これにより、パケット通信パス１８におけるヘッダオーバーヘッドが減少し、且つ、ペイロードエラーを有するパケットが目的アプリ−ケーションに確実に送信される。ＢＥＲが８２の閾値を超過しない場合、又はペイロード感度が８３の閾値より低くない場合、図６のセレクタ６２はフィールドエクストラクタ２４から受信したチェックサムフィールド値を通過させ、ヘッダアセンブラＨＡ（図２参照）へ出力する。

他の実施態様では、図７（ｂ）に図示されたように、図７（ａ）のコンパレータ７２は、ペイロードのタイプを示す情報を受信するコンパレータ７２Ａと置換されてもよく、この情報とビットエラー感度が低いペイロードタイプ（例えば、いくつかの実時間データアプリケーション）のリストを比較する。コンパレータ７２Ａが低感度のペイロードタイプのリストから当該ペイロードタイプを見つけた場合には、出力７４（図７（ａ）も参照）は活性化される。これはまた図８（ｂ）のステップ８３Ａに図示されており、当該ステップは図８（ａ）のステップ８３に置換することができる。

図６から図８（ｂ）の実施態様は、ヘッダ圧縮を使用しないパケット通信パスにも有利に適用することができる。パケットをペイロードエラーと共に伝送することに係る上記に記載の利益は、ヘッダ圧縮がパケット通信パスで使用されるか否かとは関係ない。

図９（ａ）は、図２のフィールドプロセッサの更なる例示的実施態様を図示する。図９の９１では、ＩＰヴァージョン４ＩＤフィールド値等のフィールドエクストラクタ２４からのＩＤフィールド値のストリームがセレクタ９２によって受信される。セレクタ９２は、セレクタ９８と協力し、現在の割当てスキームシグナル９９に応じて、図２のヘッダアセンブラＨＡに対して不変のＩＤフィールド値をルートするか、あるいは、ヘッダアセンブラＨＡまでのマッパー９６を通じてＩＤフィールド値をルートするか、あるいは、マッパー９７を通じてＩＤフィールド値をヘッダアセンブラＨＡまでルートする。

９９の現在の割当てスキームシグナルが、現在のＩＤフィールド割当てスキームは連続−ストリーム割当て（図９（ａ）のＳＥＱ）であると指示した場合、ヘッダアセンブラＨＡへの出力のために、フィールド値がセレクタ９２からセレクタ９８まで９３でルートされる。９９の現在の割当てスキーム信号が現在のＩＤフィールド割当てスキームがランダム割当てであると示した場合、ＩＤフィールド値は９４でセレクタ９２からランダムマッパー９６までルートされ、ここで、セレクタ９８を通じた図２のヘッダアセンブラＨＡへの出力のためにランダムに割当てられた値を連続−ストリーム値にマップする。９９の現在の割当てスキーム制御シグナルが、現在のＩＤフィールド割当てスキームを連続−ホスト割当て（図９（ａ）のＨＯＳＴ−ＳＥＱ）であると示した場合、ＩＤフィールド値は、９５で、セレクタ９２から連続−ホストマッパー９７までルートされ、ここで、元の連続−ホスト割当値から、ヘッダアセンブラＨＡにセレクタ９８を介して出力するため、ＩＤフィールド値を連続−ストリーム値にマップする。

図１０は、図９（ａ）のフィールドプロセッサの実施態様によって実行されうる例示的演算を図示する。１００では、現在のＩＤフィールド割当てスキームが連続−ストリーム、ランダム又は連続−ホストか否かを判断する。現在のスキームが連続−ストリーム（ＳＥＱ）である場合には、（図９（ａ）の９３に対応し）ＩＤフィールド値のマッピングは必要ではない。現在のスキームが連続−ホスト（ＨＯＳＴ−ＳＥＱ）である場合には、連続−ホスト割当てから連続−ストリーム割当てへのマッピングが１０１で行われる。現在のスキームがランダム割当ての場合には、ランダム割当てから連続−ストリーム割当てへのマッピングが１０２で行われる。

現在のＩＤフィールド割当てスキームが連続的か、ランダムか、又は連続−ホストか否かを示した、図９（ａ）（９９参照）及び図１０（１００参照）に図示された現在のスキーム情報は、例えば、９１でストリームのＩＤフィールド値を検討するだけで得ることができる。このように、図９（ｂ）に図示したように、適当な量のＩＤフィールド値をバッファすることができ、スキーム判定器９０がバッファされたフィールド値を検討し、それから現在のスキームを判断することができる。

９６（図９（ａ））及び１０２（図１０）に図示された、ランダムＩＤフィールド割当てから連続−ストリームＩＤフィールド割当てへの上記に記載のマッピングは、例えば、ＲＴＰがアプリケーションレベルプロトコルとして使用されている場合に、各ＩＤフィールド値を対応するＲＴＰ列番号に適合するように変更することによって、行うことができる。

図９（ａ）及び図１０に関して以上で見たように、現在のＩＤフィールド割当てスキームが、双方ともが図１のノードＨＣＮ及びＨＤＮにとって問題である、ランダム又は連続−ホストである場合はいつでも、そのようなＩＤフィールド割当てを連続−ストリームＩＤフィールド割当てにマッピングすることができる。該連続−ストリームＩＤフィールド割当ては、図１のパケット通信パス１８で使用されるヘッダ圧縮スキームの性能の向上に好ましい（例えば、要求されるヘッダのオーバーヘッドが減少する）。

本発明の例示的実施例を上記で詳細に説明したが、本発明の範囲は、これによって限定されることはなく、様々な実施態様において実施することができる。

本発明に係るパケット交換通信システムの例示的実施例の一部を図示する。図１の破壊ノードの実施態様を図示する。図２のフィールドプロセッサの実施態様を図示する。図３のＴＴＬ／ＨＬフィールドフィルタの実施態様を図示する。図４の実施態様によるフィールドプロセッサによって実行することができる動作の実施例を図示する。図２のフィールドプロセッサの更なる実施例を図示する。図７（ａ）は、図６の決定論理の実施態様を図示し、図７（ｂ）は図７（ａ）の代替実施態様を図示する。図８（ａ）は図６及び図７（ａ）の実施態様のフィールドプロセッサによって実行することができる演算の実施例を図示し、図８（ｂ）は図６及び図７（ｂ）の実施態様のフィールドプロセッサによって実行することができる演算の実施例を図示する。図９（ａ）は図２のフィールドプロセッサの更なる実施態様を図示し、図９（ｂ）は図９（ａ）の実施態様を更に詳細に図示する。図９（ａ）の実施態様のフィールドプロセッサによって実行することができる動作の実施例を図示する。

Claims

ヘッダ圧縮器（ＨＣＮ）を含むパケット通信パス（１８）上のパケット通信の性能向上のための装置であって、
パケット通信パス上で通信されるべきパケットを受信するための入力部（１１）と、
当該入力部と連結され、受信したパケットのヘッダを構成フィールドに分解するフィールドエクストラクタ（２４）と、
当該フィールドエクストラクタから対応する１つのヘッダフィールドを受信し、当該１つのヘッダフィールドと変更されたヘッダフィールドのうちの１つを選択的にヘッダアセンブラ（ＨＡ）へ提供する、１又は複数のフィールドプロセッサ（２６）と、
当該１又は複数のフィールドプロセッサからヘッダフィールドを受信し変更されたヘッダを組み立てるヘッダアセンブラ（ＨＡ）と、
当該変更されたヘッダの圧縮のために当該変更されたヘッダをヘッダ圧縮器へ出力するために当該ヘッダアセンブラと連結された出力部（１４）とを有し、
当該フィールドプロセッサは、異なるパケットにおける同一のヘッダフィールドの値に応じて、当該１つのヘッダフィールドから、当該変更されたヘッダフィールドを作成する装置。
上記フィールドプロセッサは、上記１つのヘッダフィールドと、上記異なるパケットにおける同一のヘッダフィールドのそれぞれの値の差異に応じて上記１つのヘッダフィールドを変更する、請求項１に記載の装置。
上記入力部は、上記ヘッダフィールドを連続して受信し、上記フィールドプロセッサは、連続したヘッダフィールド値に平滑化演算を行うための平滑化フィルタを含み、当該ヘッダフィールド値は、上記連続したヘッダフィールド内のそれぞれのヘッダフィールドに関連する、請求項２に記載の装置。
上記ヘッダフィールドは有効期間フィールドである、請求項１に記載の装置。
上記パケット通信パスには、無線リンクが含まれる、請求項１に記載の装置。
ヘッダ圧縮器を含むパケット通信パス（１８）上のパケット通信の性能向上のための方法であって、
パケット通信パス上で通信されるべきパケットを受信するステップと、
受信したパケットのヘッダを構成フィールドに分解するステップと、
分解された１又は複数のヘッダフィールドのそれぞれについて、１つのヘッダフィールドを受信し、当該１つのヘッダフィールドと変更されたヘッダフィールドのうちの１つを選択的に提供するステップと、
変更されたヘッダを組み立てるステップと、
ヘッダ圧縮を適用するステップとを有し、
当該提供ステップは、異なるパケットにおける同一のヘッダフィールドの値に応じて、当該１つのヘッダフィールドから、当該変更されたヘッダフィールドを作成することを含む方法。
上記提供ステップは、上記１つのヘッダフィールドと上記異なるパケットにおける同一のヘッダフィールドのそれぞれの値の差異に応じて上記１つのヘッダフィールドを変更することを含む、請求項６に記載の方法。
上記受信ステップは、上記ヘッダフィールドを連続して受信することを含み、上記提供ステップは、当該受信した一連のヘッダフィールドにそれぞれ関連した、連続したヘッダフィールドの値に平滑化フィルタリング演算を行うことを含む、請求項７に記載の方法。