(57)【要約】　　【課題】　　　ネットワークノードでの多層プロトコルスタック全体のスループットを向上させること。　　【解決手段】　符号化部１０６は、多層プロトコルスタック１０１上のプロトコルデータユニットに含まれる多層のヘッダ情報を圧縮する。セッションコンテキストＩＤマネジャー１１２は、符号化部１０６による多層のヘッダ情報の圧縮に関する情報を統合してなり、例えば、多層のヘッダ情報を圧縮する方式を識別するための情報を含むセッションコンテキストＩＤ４０１を生成する。　【選択図】　　　図１
2004096738.tif 000002
【特許請求の範囲】
【請求項１】
　多層プロトコルスタック上のプロトコルデータユニットを送信するノード装置と共に使用されるヘッダ圧縮装置であって、
　前記プロトコルデータユニットに含まれる多層のヘッダ情報を圧縮する圧縮手段と、
　前記圧縮手段による前記多層のヘッダ情報の圧縮に関する統合的な情報を生成する生成手段と、
　を有することを特徴とするヘッダ圧縮装置。
【請求項２】
　生成された統合的な情報は、前記多層のヘッダ情報を圧縮する方式を識別するための識別情報を含むことを特徴とする請求項１記載のヘッダ圧縮装置。
【請求項３】
　一つのストリームに属する前記多層プロトコルスタック上の複数のプロトコルデータユニットにそれぞれ含まれる多層のヘッダ情報の差分を検出する検出手段を有し、
　前記検出手段によって差分がないことが検出された場合、前記複数のプロトコルデータユニットのうち後続のプロトコルデータユニットに対応する識別情報が送信されないような制御が行われることを特徴とする請求項２記載のヘッダ圧縮装置。
【請求項４】
　前記多層プロトコルスタックの各層毎の処理を行う処理エンティティと前記プロトコルデータユニットを授受するための第一のインタフェースと、
　前記多層プロトコルスタックを管理する管理エンティティと制御用の情報を授受するための第二のインタフェースと、
　を有することを特徴とする請求項２記載のヘッダ圧縮装置。
【請求項５】
　多層プロトコルスタック上のプロトコルデータユニットを受信するノード装置と共に使用されるヘッダ復元装置であって、
　前記プロトコルデータユニットに含まれる多層のヘッダ情報の圧縮に関する統合的な情報を取得する取得手段と、
　取得された統合的な情報に基づいて、前記多層のヘッダ情報を復元する復元手段と、
　を有することを特徴とするヘッダ復元装置。
【請求項６】
　多層プロトコルスタック上のプロトコルデータユニットを送信するノード装置と共に使用されるヘッダ圧縮装置におけるヘッダ圧縮方法であって、
　前記プロトコルデータユニットに含まれる多層のヘッダ情報を圧縮する圧縮ステップと、
　前記圧縮ステップでの前記多層のヘッダ情報の圧縮に関する統合的な情報を生成する生成ステップと、
　を有することを特徴とするヘッダ圧縮方法。
【請求項７】
　多層プロトコルスタック上のプロトコルデータユニットを受信するノード装置と共に使用されるヘッダ復元装置におけるヘッダ復元方法であって、
　前記プロトコルデータユニットに含まれる多層のヘッダ情報の圧縮に関する統合的な情報を取得する取得ステップと、
　取得した統合的な情報に基づいて、前記多層のヘッダ情報を復元する復元ステップと、
　を有することを特徴とするヘッダ復元方法。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、ヘッダ圧縮／復元装置及びヘッダ圧縮／復元方法に関する。
【背景技術】
【０００２】
　プロトコルデータユニット（ＰＤＵ）を圧縮する既存の方法では、単一層でのデータフォーマットの圧縮に重点が置かれている。このような技術の１つは、特定のプロトコル層の圧縮に重点を置いたインターネットプロトコル（ＩＰ）ヘッダ圧縮である。
【０００３】
　先行技術でのヘッダ情報の圧縮は、インターネットプロトコルスタックアドレスの圧縮を中心としている。圧縮できるヘッダとしては、ＴＣＰ、ＵＤＰ、ＩＰｖ４、及びＩＰｖ６基本ヘッダと拡張ヘッダが含まれる（例えば、非特許文献１）。ＴＣＰパケットについては、減衰のあるリンクでのＶＪヘッダ圧縮（Van Jacobson compression）の効率性を高めるＶａｎ追加メカニズムも報告されている。非ＴＣＰパケットについては、圧縮のスロースタートとヘッダの周期的リフレッシュによって、コンテキストが変更するようなヘッダの喪失によってパケットを放棄する期間を最短に抑えることができる。ＵＤＰ上でのヘッダ圧縮法、例えばＲＴＰヘッダの圧縮を加えるためのフックがある。
【０００４】
　ヘッダ圧縮は、同じパケットストリームに属する連続パケットで一定であるか、又は希にしか変化しない多くのフィールドに依拠している。パケット間で変化しないフィールドは、伝送する必要は全くない。小さな値及び／又は予測可能な値で変化することが多いフィールド、例えばＴＣＰシーケンス番号は、値を１つずつ増やしながら符号化することができるので、これらのフィールドに必要なビット数は大幅に削減することができる。頻繁にまたランダムに変化するフィールド、例えばチェックサムや認証データは、各ヘッダ内で伝送する必要がある。
【０００５】
　ヘッダ圧縮の一般的原則は、完全ヘッダを含むパケットを時々送信することである。その後送られる圧縮ヘッダは、完全ヘッダによって確定済みのコンテキストを参照する。また圧縮ヘッダは、そのコンテキストに対する増分的変化を含んでもよい。このヘッダ圧縮法では、同じストリームのすべてのパケットが圧縮リンクを通過する必要はない。しかしＴＣＰストリームでは、その後のヘッダ間の差が不規則となり、圧縮率が低下する場合がある。対応するＴＣＰデータと確認パケットが反対方向にリンクを通過する必要もない。
【０００６】
　このヘッダ圧縮スキーマは、第１ホップリンク又は最終ホップリンクで、またネットワークの中間のリンクで役立つ。多くの（数百の）パケットストリームがリンクを通過するとき、ＣＩＤスラッシングと呼ばれる現象が起こることがある。この場合、各ヘッダは既存のコンテキストに対応することは希にしかなく、圧縮せずに、すなわち完全ヘッダとして送る必要がある。最も高い圧縮率のパケットストリームがそのコンテキストを確実に維持するようヒステリシスなどの技術を用いることもできる。このような技術は、ネットワークの中間で必要とされる可能性が高い。
【非特許文献１】"IP Header Compression", Network Working Group Request for Comments No.2507, 1999
【発明の開示】
【発明が解決しようとする課題】
【０００７】
　すべてのネットワークには、各ネットワークノード内で実行されている多くのプロトコルスタック層がある。各プロトコルスタック層は、アドレス、ポート番号、パケット制御データ、及び統合性を保護し伝送中のエラーに対してパケットの回復力を高めるデータなどの特定の層情報を提供する。この情報は、多くの場合、伝送し、受信し、またネットワークノードを接続するためのプロトコルスタックエンティティ間でのパケットデータ交換について一定期間にわたって複製される。本発明では、１つを超えるプロトコルスタックや伝送及び受信ネットワークノード間を通過するデータパケットについて無関係性と冗長性を除去することができる。
【０００８】
　ネットワークノードの従来型の多層プロトコルスタックを支援するために、ヘッダ圧縮を実際に用いる必要性が次第に増しつつある。本発明は、従来のネットワークノード上で圧縮ヘッダ情報を支援できるようにする任意の数の層のプロトコルスタックを復号化及び符号化することができる装置及び方法を提供する。これは、プロトコルスタックを変更せずに行われる。
【０００９】
　ほとんどの無線ネットワークは、コネクションレスセッションのためにパケットを用いるネットワークデータ伝送を支援している。データパケットが送信先にうまく到達する可能性を高めるには、分割が必要である。分割ではヘッダ情報を複製するため、多くのオーバーヘッドが生じる。本発明では、分割データパケット伝送セッションのデータ転送のためにヘッダ情報を圧縮することができる。
【００１０】
　無線ネットワーク、特にＩＥＥＥ８０２．１１に基づくネットワークでは、無線媒体でのデータパケット間でフレーム間期間が用いられる。このフレーム間期間は、一定期間、特に２つのステーションの間で多くのデータ交換がなされる時に、かなりの時間と帯域を要する。本発明は、フレーム間期間を低減する装置と方法を提供する。また本発明によって、長期間にわたる２つのステーション間のデータ交換でのフレーム間期間で浪費される帯域を低減する。
【００１１】
　本発明によって、プロトコルスタックで実施されるヘッダ圧縮技術を持たない２つの従来型ネットワークノードでも適切なインタフェースを提供することによりヘッダ圧縮を行うことができ、従来型の制御ソフトウェアでもヘッダ圧縮を行うことができる。インタフェースは、ネットワークノード間のデータ交換のために従来型のデータパケットを継続して用いることができるように、制御面とデータ面に設けられる。
【００１２】
　すなわち、本発明は、ネットワークノードでの多層プロトコルスタック全体のスループットを向上させることができるヘッダ圧縮／復元装置及びヘッダ圧縮／復元方法を提供することを目的とする。
【課題を解決するための手段】
【００１３】
　本発明は、プロトコルスタックの全体的な変更は行わずに、従来型のネットワークノード間や新しい多層プロトコルスタックを含むネットワークノード間でのデータパケット交換でヘッダ圧縮を使用できるようにすることによって上記の問題を解決する。このために、本発明は、多層プロトコルスタックヘッダ情報トランスコーダを設ける手段と、低ビットレートヘッダ情報交換ができるようにヘッダ情報を符号化及び復号化する手段と、ヘッダ情報圧縮を使用できるように従来型ネットワークプロトコルスタックの制御面にデータ面にインタフェースを設ける手段と、ヘッダ圧縮のためのセッションを開始する手段と、無線媒体でデータ分割が一般的なデータセッション中にヘッダ情報を圧縮する手段と、無線媒体でのデータパケット伝送中にフレーム間時間を低減する手段と、１つを超えるプロトコルスタック層からのデータパケットのヘッダ情報を圧縮する手段と、多層プロトコルスタック層のために圧縮ヘッダ情報を含むデータパケットを検出する手段と、多層プロトコルスタックのために圧縮ヘッド情報を復号化するための手段とを用いる。
【００１４】
　本発明は、２つのネットワークノード間で交換されるデータパケット内にカプセル化されたヘッダ情報の冗長性と無関係性を除去するために、多層プロトコルスタックヘッダ情報トランスコーダによって提供される装置及び機構を利用する。本発明の装置は、層管理エンティティとプロトコルスタック層との間での制御及びデータパケット情報交換のために制御面とデータ面に２つのインタフェースを追加することによって制御することができ、またヘッダ情報の圧縮と復元を行うことができる。この装置は、最初に適当なフレームを交換することによって伝送ノードと複数の受信ネットワークノードとの間でヘッダ圧縮のセッションを行う。圧縮ヘッダ情報の終了と開始を示すための制御フレームが失われた場合に、エラー回復に必要な期間を短くするヘッダ情報更新を示すためにも制御フレームが交換される。トランスコーダの符号化部では、ヘッダ情報圧縮のために行われるセッションとともに、冗長な情報と複製情報の除去が行われる。ヘッダ情報の復元は、トランスコーダの復号化部によって行われる。制御情報は、プロトコル層管理エンティティによってトランスコーダへ送られ、ヘッダ情報圧縮に参与するプロトコル層の数を制御し、指定することができる。ヘッダ情報の変換を必要とするプロトコル層間に流れるデータパケットも解釈され、その後の処理のためにトランスコーダサブユニットへと送られる。トランスコーダ内で起こる処理には、符号化、復号化、登録、及びヘッダ圧縮セッションの削除が含まれる。
【発明の効果】
【００１５】
　本発明を用いることによって、データパケットヘッダ情報の冗長性と無関係性が除去され、プロトコルスタックの異なる層でのペイロードのスループットが向上する。要するに、本発明はスループットを向上させ、また伝送が無線媒体で行われる時には貴重な資源であるオーバーヘッドビットレートの消費を低減する。本発明は、多層プロトコルスタックがヘッダ圧縮を用いることができるような装置と方法を提供する。これは全体的なオーバーヘッドビットレートを削減し、ネットワークノードのための全体的スループットを向上させる。本発明ではさらに、既存のプロトコルスタックの制御メカニズムに改良や変更を加えずに、従来型のプロトコルスタックとネットワークノードがヘッダ圧縮を用いることができる。
【発明を実施するための最良の形態】
【００１６】
　以下の記述では、本発明の説明の目的のために、本発明が完全に理解されるように、特定の番号、時間、構造、及びその他のパラメータを用いて述べる。以下の各段落では、本発明がどのように実施されるかを例を挙げて説明する。しかし、このような詳細がなくても本発明が実施できることは、当業者には明白であろう。
【００１７】
　この節では、無線ネットワークに適用されるＯＳＩ（開放型システム間相互接続）モデルの第２層でネットワークリソースを制御するための装置を開示する。本発明を理解しやすくするために、以下の定義を用いる。
【００１８】
　プロトコルデータユニット（ＰＤＵ）　…　送信元から送信先への送信を成功させるためにヘッダ情報とペイロードで構成された１個のデータパケット
【００１９】
　データストリーム　…　一定の有限期間内の異なる時点で送信されるが、送信先と送信元が類似しているプロトコルデータユニット群
【００２０】
　符号化部　…　プロトコルデータユニットの選択された部分を圧縮する機能的モジュール又は装置
【００２１】
　復号化部　…　プロトコルデータユニットの選択された部分を復元する機能的モジュール又は装置
【００２２】
　セッションコンテキストＩＤマネジャー　…　少なくとも１つのプロトコルスタックを制御する２組のエンティティ間でのデータパケット交換でヘッダ圧縮セッションを行う機能的モジュール又は装置
【００２３】
　パケットストリーム登録部　…　圧縮又は復元を必要とするコネクション型又はコネクションレス型ネットワークについて、１つ又はそれ以上のデータパケットからなるデータパケットストリームを登録し識別するのに用いられる機能的モジュール又は装置
【００２４】
　プロトコル層インタフェース（Ｉ／Ｆ）　…　プロトコルスタックから、圧縮して、また圧縮せずに送られるヘッダ情報を含むデータパケットで構成されるデータパケットストリームを識別するのに用いられる機能的モジュール又は装置
【００２５】
　層管理エンティティインタフェース（Ｉ／Ｆ）　…　通常、プロトコルスタック層の制御活動とメカニズムの調整に用いられる層管理エンティティによって必要とされる圧縮及び復元セッションの制御に用いられる機能的モジュール又は装置
【００２６】
　図１の装置は、本発明の一実施の形態に係る多層プロトコルスタックプロトコルデータユニットヘッダ情報トランスコーダを示している。多層ヘッダトランスコーダ１０２は、ヘッダ情報を符号化及び復号化し、またヘッダ情報の圧縮と復元プロセスを調整及び制御するための方法及びサブモジュールを含む装置である。プロトコル層によって生成され、又は受信されるデータパケットにおいてデータヘッダの圧縮や復元が必要な時には、多層ヘッダトランスコーダ１０２で行われる。多層ヘッダトランスコーダ１０２と各プロトコル層スタックの間でのデータパケットのヘッダ情報のやりとりは参照番号１０３で示されるデータバスを経て行われる。ヘッダ情報の圧縮を支援するために、インタフェース１１６を経てＰＤＵを多層ヘッダトランスコーダ１０２へと送るが、既存のプロトコルスタックに改良を行う必要はない。
【００２７】
　この多層ヘッダトランスコーダ１０２は、２つのネットワークのノード又は構成要素間で交換されるデータパケットユニットのヘッダ情報の圧縮及び復元ができるように、従来型の多層プロトコルスタック１０１や新しいプロトコルスタック層で用いるよう設計されている。新しいプロトコルスタックでは、ヘッダ情報の冗長性と無関係性を除去するよう機能するために、多層ヘッダトランスコーダ１０２によってデータストリームのパケットはオーバーヘッドが少ない状態で送信先へと伝送することができる。したがって、トランスミッタ端部でのスループットが改善される。
【００２８】
　プロトコルスタック層間でのパケットデータユニットの転送の制御は、プロトコル層Ｉ／Ｆ１０４によって調整される。圧縮されるプロトコルスタック層を識別するのに用いられる情報は、層管理エンティティＩ／Ｆ１０９によって提供される情報によって左右される。この情報は、参照番号１１４で示される単一パスを通る。層管理エンティティＩ／Ｆ１０９によって渡される情報は、プロトコル層Ｉ／Ｆ１０４、セッションコンテキストＩＤマネジャー１１２、及びパケットストリーム登録部１０５に提示するのに用いられる。ここで、ヘッダ情報のデータフィールドは圧縮又は復元され、またプロトコルスタック層圧縮ヘッダ情報が適用される。プロトコル層間を上方向及び下方向に通過するデータパケットは、プロトコル層Ｉ／Ｆ１０４によってモニターされ、またデータパケットストリームからヘッダ情報の圧縮又は復元が必要なもののみが抽出され、双方向単一パス１０８を通って符号化部１０６又は復号化部１０７へと送られる。
【００２９】
　送られる前に、データパケット情報は解釈され、ヘッダ情報はパケットストリーム登録部１０５によって分析される。圧縮の必要があるデータパケットは、プロトコル層管理エンティティ１１１によって指定される情報に基づいて圧縮される。プロトコル層間を通り、圧縮されるか圧縮されていないヘッダを含むデータパケットは処理の必要があるため、符号化部１０６又は復号化部１０７へと送られる。トランスコーダ内にあるＰＤＵを圧縮又は復元するためのパスは、パケットストリーム登録部１０５を通過する双方向パス１０８である。
【００３０】
　参照番号１１６で示されるインタフェースは、データ面インタフェースとしても知られており、多層ヘッダトランスコーダ１０２と多層プロトコルスタック１０１との間のヘッダ情報プロトコルデータユニットヘッダ情報として定義される。インタフェース１１６は、ヘッダ情報の圧縮及び復元のためのデータ面として用いられる。参照番号１１５で示されるインタフェースは、ヘッダ情報の圧縮及び復元を可能にする制御情報のためのインタフェースとして機能する。インタフェース１１５は、プロトコル層管理エンティティ１１１がヘッダ情報の圧縮を制御し、調整できるようにする制御面インタフェースとして知られている。
【００３１】
　データ面のインタフェース１１６は、２種類のデータフローで構成されている。すなわち（i）未圧縮ＰＤＵストリームと（ii）圧縮済みＰＤＵストリームである。プロトコル層のための未圧縮及び圧縮済みＰＤＵストリームは、まずプロトコル層Ｉ／Ｆ１０４を通って多層ヘッダトランスコーダ１０２に入り、その後、プロトコル層へと送られる。ヘッダ圧縮を必要とする未圧縮データストリームは、符号化部１０６及び多層ヘッダトランスコーダ１０２によって提供されるその他の制御プロセスに従って圧縮される。プロトコル層Ｉ／Ｆ１０４は、圧縮されたＰＤＵが指定されたプロトコルスタック層に達する前に行われる圧縮済みＰＤＵデータストリームモニタリング及び検出の第１段階である。
【００３２】
　制御面のインタフェース１１５は、２種類のデータフローで構成されている。すなわち（i）プロトコル層管理エンティティ１１１からの制御情報フローと（ii）多層ヘッダトランスコーダ１０２からの結果情報である。プロトコル層管理エンティティ１１１からの制御情報は次のフォーマットに従うことができる。
【００３３】
構造トランスコーダ＿制御
｛
プロトコルスタックの数；
　／*  ヘッダ圧縮のためのプロトコルスタックの数　*／
スタックの説明；
　／*  プロトコルスタックの説明又はその代表例　*／
｝
【００３４】
　圧縮済みのヘッダ情報を含むデータパケットのための新しいストリームセッションを行うために、符号化部１０６によって符号化プロセスが実行される。パケットストリーム登録部１０５は、セッションコンテキストＩＤマネジャー１１２によって、ヘッダ情報の圧縮の一部として用いられるユニークなセッションが参照番号１０８で示される単一パスを通って用いることができるように内部信号を伝送するよう要求される。復号化プロセスでは、パケットストリーム登録部１０５は、プロトコル層Ｉ／Ｆ１０４に入ってきたデータパケットの方向を変え、復元すべきヘッダ情報を復号化部へと送る。多層プロトコルスタック１０１の各々から抽出され符号化部１０６及び復号化部１０７によって処理されたすべての圧縮済み及び未圧縮データ情報は、各プロトコル層による処理のために各プロトコル層へと戻される。プロトコル層から各データパケットのパケットヘッダ情報を得るプロセスとこれらの情報を戻すプロセスは、プロトコル層Ｉ／Ｆ１０４によって行われる。
【００３５】
　図２は、一般的なネットワーク構成で実施することができる、本発明の一実施の形態に係る多層ヘッダトランスコーダ１０２の配置例である（ただし、図２では「多層ヘッダトランスコーダ２０２」と記載）。圧縮済みヘッダ情報を含むプロトコルデータユニットがネットワーク内のいずれか２つのノードの間で、エンド・ツー・エンドで交換できるようにするために、送信元ノード２０３、送信先ノード２０８、及び中間ノード２０７は、参照番号２０１で示される短ヘッダ情報処理ができる必要がある。プロトコルデータユニットが送信元ノード２０３から送信先ノード２０８に達する前に、プロトコルデータユニットは、短ヘッダ情報処理能力を備えた複数の中間ノード２０７を通過する必要がある。プロトコルデータユニットの伝送媒体２０９は、無線媒体でも有線媒体でもよい。短ヘッダ情報処理の可能な短ヘッダ情報処理装置２０１は、汎用プロトコルスタックと多層ヘッダトランスコーダ２０２に接続できるプロトコル層管理エンティティとで構成される。プロトコル層と多層ヘッダトランスコーダ２０２とのインタフェースは、データ面のインタフェース２０４であり、ここでヘッダ情報が検索され、対応するプロトコルスタック層に挿入される。また、プロトコルスタック層ではヘッダ圧縮と復元が求められる。汎用ネットワークノードのプロトコル層管理エンティティのために設けられるインタフェースは、制御面のインタフェース２０５である。
【００３６】
　図３は、２つのネットワークノード間で交換される圧縮済みヘッダについてのセッションを行う際の本発明の実施例を示している。セッションの実行は、セッションコンテキストＩＤマネジャー１１２によって決定される。またこれは、参照番号１１５で示される制御面のインタフェースを通ってプロトコル層管理エンティティ１１１から受け取る制御情報に基づいている。セッション期間３０１は、圧縮されたヘッダを含むプロトコルデータユニットの開始を示すために、セッションフレーム３１１を送信先ノードへと送ることによって生成される。このセッションフレームすなわちインジケータは、既存のプロトコルデータユニットにピギーバックすることができる。セッションフレームは、プロトコルデータユニット内の圧縮ヘッダ情報を用いて、多層プロトコルスタックで最下層のプロトコル層の前のトランスコーダによってのみ生成される。その後の上層からのペイロードは、プロトコルデータユニットに圧縮ヘッダを与える層を通して簡単に送ることができる。
【００３７】
　セッション期間３０１の開始を示した後、ヘッダInfo Sync（情報同期）３０４が、ケイパビリティを示すために送られる。このケイパビリティは、セッション期間内で実行可能な圧縮の種類を含んでいる。また、ＰＤＵのアドレスフィールド、制御フィールド及びその他について行う圧縮の種類を含んでいる。このケイパビリティフィールドは、異なる制御メカニズムを利用するためにＰＤＵプロトコルスタックに埋込まれたヘッダ情報を将来拡張するために用いることができる。またヘッダInfo Sync３０４は、多層プロトコル層ヘッダ情報が開始するプロトコルスタックの既存のプロトコルデータユニットにピギーバックすることができる。すべてのデータＰＤＵ又はＰＤＵの断片は、一定の時間間隔であるフレーム間間隔３０９で分けられる。セッションフレーム（Sess＿Frame）３１１の構造は、次の通りである。
【００３８】
構造Sess＿Frame
｛
Sess＿Frame制御データの種類；
　／*  Sess＿Frameを示すビットフォーマット　*／
フレーム期間；
　／*  秒単位又は他の表示でのセッション期間　*／
ケイパビリティ情報；
　／*  圧縮ケイパビリティの種類　*／
｝
【００３９】
　ヘッダInfo Sync３０４のフォーマットには次のものが含まれる。すなわち、情報、ＴＤＭフレーム３０３の数、分割ＴＤＭフレーム群、ヘッダInfo Re-Sync（情報再同期）３０６間のバイト数すなわち期間、分割できるプロトコルデータユニットの数、Sess＿Frame３１１間のバイト数すなわち時間で表した期間、セッションコンテキストＩＤマネジャーによって生成及び管理されるユニークな番号であるセッションコンテキストＩＤ群、及びコンテキストストリームフィールドである。参照番号３１０で示されるSess＿Frame（セッションフレーム）は、セッション期間の終了時をマークするのに用いられる。また次のセッション期間３０１の開始を示すことにもなる。セッション期間の開始及び終了のためのSess＿Frameフォーマットは、類似のものであっても、また異なるものであってもよい。ヘッダInfo Sync３０４のフォーマットの例を構造形式で示すと次のようになる。
【００４０】
構造ヘッダInfo Sync (情報同期)
｛
ヘッダInfo Sync制御データの種類：
　／*  ヘッダInfo Syncフレームを示すためのビットフォーマット　*／
ＴＤＭフレームの数
　／*  ２つのSess Frame間のＴＤＭフレームの数　*／
分割ＴＤＭ群：
　／*  セッション期間内で許容される分割ＴＤＭフレームの数　*／
ヘッダInfo Re-Sync（情報再同期）間隔；
　／*  ヘッダInfo Re-Sync間で秒又はバイトで測定した最短期間　*／
分割ＰＤＵ群
　／*  セッション期間内で許容される分割ＴＤＭフレームの数　*／
　／*  総セッション期間　*／
セッションコンテキストＩＤフィールド；
　／*  異なる送信先ノードへのデータ送信のための複数のユニークなＩＤ　*／
コンテキストストリーム
　／*  プロトコルスタックの多層のヘッダ情報　*／
｝
【００４１】
　ヘッダInfo Sync３０４が伝送されたあとに、送信元ノードとさまざまな送信先ノードとのデータ交換が起こりうる。データ伝送は、ＴＤＭフレーム３０３及び圧縮されたヘッダ情報を含むＰＤＵのデータ３０５の形式とすることができる。いずれか２つのヘッダInfo Re-Sync３０６のフレーム間又は１つのヘッダInfo Re-Sync３０６のフレームとヘッダInfo Sync３０４との間の期間は、サブセッション期間３０２と名付けられる。ヘッダ情報がデータの損失によって大きく損なわれた場合には、サブセッション期間によってエラーを短い期間内に納めることができる。またこれは、圧縮が確実に実行されるのに役立つ。ヘッダInfo Re-Sync３０６は、ヘッダInfo Re-Sync３０６及びヘッダInfo Sync３０４のその他のフィールドのすべての一部を示すためにユニークな制御データ種類で構成されている。
【００４２】
　ＴＤＭフレーム３０３や圧縮ヘッダを含む通常のＰＤＵは、それぞれ分割ＴＤＭフレーム３１３及び分割ＰＤＵ３１４に分割することができる。ＴＤＭフレーム３０３は、連結された多数のＰＤＵペイロードであり、フレーム間間隔によって分離されず、また圧縮ヘッダを１つ含んでいる。データ３０５とＰＤＵ３１２のヘッダは、サブセッションサブフィールドＩＤとシーケンス制御を含んでいる。次のフォーマットは、ｃｈ３１６として示したヘッダフォーマットの例である。
【００４３】
ｃｈ
｛
ｃｈ制御データの種類；
　／*  ＴＤＭ又はＰＤＵフレームの開始を示すビットフォーマット　*／
サブセッションサブフィールドＩＤ；
　／*  セッション期間内に伝送される最終送信先ノードを示すアドレスフィールド　*／
シーケンス制御フィールド；
　／*  特定の送信先へのデータストリームのためのＴＤＭ及びＰＤＵのシーケンスを制御する制御フィールド　*／
｝
【００４４】
　分割ＴＤＭフレーム３１３では、２種類の分割ＰＤＵヘッダ情報が分割ＴＤＭセッションと後続ＴＤＭセッションの開始を示す。すなわち（i）Ｔｈ３０７と（ii）Ｆｈ３０８である。次に示すのは、Ｆｈ３０８とＴｈ３０７についてのヘッダフォーマットの例である。
【００４５】
Ｔｈ
｛
Ｔｈ制御データの種類；
　／*  Ｔｈ ＰＤＵの開始を示すビットフォーマット　*／
サブセッションサブフィールドＩＤ；
　／*  セッション期間内に伝送される最終送信先ノードを示すアドレスフィールド　*／
シーケンス制御フィールド；
　／*  特定の送信先へのデータストリームのためのＴＤＭ及びＰＤＵのシーケンスを制御する制御フィールド　*／
分割部分の数；
　／*  後続分割ＦｈヘッダＰＤＵの数　*／
｝
【００４６】
Ｆｈ
｛
Ｆｈ制御データの種類；
　／*  Ｆｈ ＰＤＵの開始を示すビットフィールド　*／
サブ分割シーケンス番号；
　／*  分割シーケンス番号　*／
｝
【００４７】
　分割ＰＤＵ３１４の場合、最初の分割ＰＤＵにはヘッダＰｈ３１５があり、次にＦｈヘッダを含む後続分割部分がある。Ｐｈ３１５のヘッダフォーマットは次の通りである。
【００４８】
Ｐｈ
｛
Ｐｈ制御データの種類；
　／*  Ｐｈ ＰＤＵの開始を示すビットフォーマット　*／
サブセッションサブフィールドＩＤ
　／*  セッション期間中に伝送される最終送信先ノードを示すアドレスフィールド　*／
シーケンス制御フィールド
　／*  特定の送信先へのデータストリームのためのＴＤＭ及びＰＤＵのシーケンスを制御する制御フィールド　*／
分割部分の数
　／*  後続分割ＰｈヘッダＰＤＵの数　*／
｝
【００４９】
　マルチレベルプロトコルデータ層に適したヘッダ情報の圧縮を行うために、図４は、図１のセッションコンテキストＩＤマネジャー１１２によるユニークな表示を生成する基本的方法を示している。セッションコンテキストＩＤを生成する例を、図４に示す。ここでは、ヘッダの圧縮が３つのレベルのプロトコルスタック、すなわちＭ番目、（Ｍ＋１）番目及び（Ｍ＋２）番目の層で行われる場合を例にとって説明する。なお、下の説明では、Ｍ番目の層を「層Ｍ」と言い、（Ｍ＋１）番目の層を「層Ｍ＋１」と言い、（Ｍ＋２）番目の層を「層Ｍ＋２」と言う。
【００５０】
　最上層プロトコル層（層Ｍ＋２）は、ペイロード４０４を含んでいる。プロトコルスタック層についてのヘッダ情報、すなわちこの場合の最下層は、層Ｍである。３つの層、すなわちこの例でのＭ番目の層、（Ｍ＋１）番目の層、及び（Ｍ＋２）番目の層のヘッダ情報は、Ｍ番目の層、（Ｍ＋１）番目の層、及び（Ｍ＋２）番目の層のヘッダ情報を連結することによって登録される。したがって、プロトコル層Ｉ／Ｆ１０４を通って多層ヘッダトランスコーダ１０２側に抽出される層Ｍからのプロトコルデータユニットは、層Ｍ＋２のペイロードに層Ｍ＋２のヘッダ情報、層Ｍ＋１のヘッダ情報及び層Ｍのヘッダ情報を連結したフォーマットを有する。
【００５１】
　上記フォーマットを有するプロトコルデータユニットにおける、多層プロトコルスタック１０１のヘッダ情報は、符号化部１０６で圧縮される。より具体的には、層Ｍ＋２のヘッダ情報、層Ｍ＋１のヘッダ情報及び層Ｍのヘッダ情報に対し、各層毎に圧縮処理が施される。圧縮処理が施された各層のヘッダ情報は連結され、これにより圧縮ヘッダ４０５が生成される。
【００５２】
　また、ヘッダ情報を圧縮する方式に関する情報（例えば、用いられた多層プロトコルスタックの最下層のアドレス情報、各層毎のヘッダ情報をどのように圧縮したか、等）は、参照番号４０２で示される連結プロセス部に集められる。そして、連結プロセス部４０２で連結プロセスが実行され、連結プロセス後のヘッダ情報は最終的に、ヘッダ情報圧縮の方式を単一のユニークな表現又は番号を用いて表示するセッションコンテキストＩＤ４０１となる。生成されたセッションコンテキストＩＤ４０１は、圧縮ヘッダ４０５の前方の区間４０３に挿入される。そして、このように生成された圧縮後のプロトコルデータユニット及びセッションコンテキストＩＤ４０１は、プロトコル層Ｉ／Ｆ１０４を通って多層プロトコルスタック１０１側に戻される。そして、圧縮後のプロトコルデータユニットは、セッションコンテキストＩＤ４０１と共に、図３を参照しながら説明した通信セッションに従い、ネットワークノード間で送受信される。
【００５３】
　すなわち、圧縮後のプロトコルデータユニットを受信したネットワークノードでは、当該プロトコルデータユニットを受信したセッション期間に取得したセッションコンテキストＩＤ４０１を用いてインデックスを付けることにより、層Ｍ、層Ｍ＋１及び層Ｍ＋２のヘッダ情報を含むコンテキストストリーム４０６が形成される。これにより圧縮ヘッダ４０５が復元される。なお、コンテキストストリーム４０６は、ヘッダInfo Syncフォーマットのフィールドの１つを形成している。
【００５４】
　ちなみに、多層ヘッダトランスコーダ１０２にて、仮に圧縮ヘッダ４０５及びペイロード４０４を含むプロトコルデータユニットを復元する場合、当該プロトコルデータユニットは、プロトコル層Ｉ／Ｆ１０４を通って多層ヘッダトランスコーダ１０２側に抽出される一方、当該プロトコルデータユニットに対応するセッションコンテキストＩＤ４０１は、プロトコル層Ｉ／Ｆ１０４を通ってセッションコンテキストＩＤマネジャー１１２によって取得される。そして、復号化部１０７で、取得されたセッションコンテキストＩＤ４０１を用いることにより圧縮ヘッダ４０５を復元する。復元後のプロトコルデータユニットは、プロトコル層Ｉ／Ｆ１０４を通って多層プロトコルスタック１０１側に戻される。
【００５５】
　ここで、生成されるセッションコンテキストＩＤ４０１についてより詳細に説明する。ただし、分かりやすく説明するために、３つのレベルのプロトコルスタックの場合を想定し、また、各プロトコル層には５通りのヘッダ圧縮の方式（つまり５種類のセッションコンテキスト）がある場合を想定する。５通りのヘッダ圧縮の方式を表現するには３ビットを要するため、従来のように単一層での圧縮に重点が置かれている場合、３×３＝９ビットを使用しなければならない。これに対して、セッションコンテキストＩＤ４０１を使用すると、セッションコンテキストＩＤ４０１だけで多層のヘッダ情報の圧縮の方式を表示することができるため、５３＝１２５通りの組み合わせの表示が、６ビットを使用するだけで可能になる。
【００５６】
　また、セッションコンテキストＩＤマネジャー１１２では、送信されるあるＰＤＵストリームに属する複数のプロトコルデータユニット（例えば、連続する２つのプロトコルデータユニット）にそれぞれ含まれるヘッダ情報の差分が検出される。この検出の結果、ヘッダ情報の差分がないことが検出された場合、当該複数のプロトコルデータユニットのうち後続のプロトコルデータユニットに対応するセッションコンテキストＩＤ４０１は、先行するプロトコルデータユニットに対応するものと同じになるため、その送信が行われないように制御することも可能である。
【００５７】
　ヘッダ情報における差分の検出が行われるのは、セッションコンテキストＩＤ４０１の生成前及び生成後のどちらでも良い。特にセッションコンテキストＩＤ４０１の生成前の場合は、多層プロトコルスタックの各層毎に差分を検出する必要が生じるが、差分を検出する範囲が小さくなるため、同じヘッダ情報であると判断される確率が高くなる。このように、複数のプロトコルデータユニット間でヘッダ情報の差分がないことが検出された場合に、後続のプロトコルデータユニットに対応するセッションコンテキストＩＤ４０１の送信を省略することができるため、通信セッションにおいて使用する時間や帯域を一層削減することが可能になる。
【００５８】
　図５は、本発明において圧縮（Ｃｏｍｐ）ヘッダ４０５を形成するのに、特定のプロトコル層のヘッダ情報がどのように用いられるかを示している。Ｃｏｍｐヘッダ４０５として示しているヘッダの圧縮のフォーマットは次の通りである。
【００５９】
構造Ｃｏｍｐヘッダ
｛
層の数
　／*  圧縮されるプロトコル層の数　*／
変化を伴う層；
　／*  ヘッダ情報の変更を伴うプロトコル層を示す　*／
圧縮されたヘッドストリーム；
　／*  プロトコル層の圧縮ヘッダにおける変更　*／
｝
【００６０】
　各プロトコル層内で、同じプロトコル層の別の層エンティティとのデータ交換で用いられるＰＤＵのヘッダ情報には、３つの基本フィールドがある。すなわち（i）アドレスフィールドと、（ii）パケット制御フィールドと、（iii）シーケンス制御フィールドである。アドレスフィールドは、アドレスＩＤ５０２に変換され、以下のデータフィールドの種類の１つとすることができる。すなわち、（i）セッションコンテキストＩＤ４０１、（ii）パケットデータ単位の当初ヘッダ５０１におけるアドレスフィールドでの完全アドレスフィールド、（iii）アドレスフィールドがより早いＰＤＵで示されることを示す空白フィールドである。当初ヘッダ５０１におけるパケット制御フィールドは、Change＿フィールド５０３に変換され、変更はフィールド内で示される。前のＰＤＵに基づく変更がない場合には、変更がないことを示すために空白値が用いられる。変更がある場合には、パケット制御フィールドでの変更を示すために異なる値が用いられる。当初ヘッダ５０１におけるシーケンス制御フィールドは、Delta＿フィールド５０４に変換され、変更は最後に伝送されたＰＤＵに基づく値での差に基づいている。参照番号５０６で示されるオペレータは、圧縮ヘッダストリーム５０５を形成するために、アドレスＩＤ５０２と、Change＿フィールド５０３と、Delta＿フィールド５０４とを連結するのに用いられる。
【００６１】
　中間ノードがその間に存在しない２つのネットワークノード間でデータパケットを送信する際には、多層のプロトコルスタックの最下層のプロトコル層で分割を行うことができる。図６は、ビットレートを節約し、スループットを改善するために圧縮がヘッダに対してどのように行われるかについての実施例である。データペイロード６０１は、１つを超える分割ＰＤＵ６０２へと分割される。分割は、無線媒体での伝送の成功率を高めるために適用されることが多い。無線媒体では、伝送媒体が共有され、伝送媒体を共有する伝送ステーション間での調整はほとんどない。これらの分割ＰＤＵ６０２のそれぞれは、通常、複製されたヘッダ情報を有している。単一のプロトコル層のヘッダ情報の圧縮を可能とするために、このプロセスでは、最初の分割ＰＤＵはＰｈヘッダ６０３を含み、後続の分割ＰＤＵはｆｈヘッダ６０４を含む。最終分割部分６０５にはｆｈヘッダと同じフィールドがある。
【００６２】
　このように、本実施の形態によれば、データパケットヘッダ情報の冗長性と無関係性が除去され、プロトコルスタックの異なる層でのペイロードのスループットが向上する。要するに、本発明はスループットを向上させ、また伝送が無線媒体で行われる時には貴重な資源であるオーバーヘッドビットレートの消費を低減する。本発明は、多層プロトコルスタックがヘッダ圧縮を用いることができるような装置と方法を提供する。これは全体的なオーバーヘッドビットレートを削減し、ネットワークノードのための全体的スループットを向上させることができる。
【００６３】
　また、本実施の形態によれば、既存のプロトコルスタックの制御メカニズムに改良や変更を加えずに、従来型のプロトコルスタックとネットワークノードがヘッダ圧縮を用いることができる。ＩＰネットワークの世界では、既存のプロトコルやシステムを排除して新しいシステムを導入することは非常に困難なことであり回避すべきことであるため、プロトコルを再実装する必要なくヘッダ圧縮機能をアドオンすることが可能であることは、本発明の大きなメリットである。
【産業上の利用可能性】
【００６４】
　本発明に係るヘッダ圧縮／復元装置及びヘッダ圧縮／復元方法は、ネットワークノードでの多層プロトコルスタック全体のスループットを向上させる効果を有し、多層プロトコルスタックを支援する通信システムにおいて有用である。
【図面の簡単な説明】
【００６５】
【図１】本発明の一実施の形態において、多層プロトコルスタックヘッダ圧縮のための装置を示す図であり、多層プロトコルスタックのヘッダ情報圧縮のために用いられるトランスコーダの全体的構造を示すブロック図
【図２】本発明の一実施の形態において、ヘッダ情報圧縮のためのネットワークシステム構成を示す図であり、多層プロトコルスタックヘッダ情報圧縮を実行する際のネットワークシステム構成とネットワークノードの全体的構造を示す図
【図３】本発明の一実施の形態において、ヘッダ圧縮セッション期間を示す図であり、セッション期間の構造と要素を示し、また圧縮が異なる種類のデータ交換にどのように適用されるかについて詳細な構造を示す図
【図４】本発明の一実施の形態において、圧縮されたヘッダ情報を含むＰＤＵの図であり、ヘッダ情報の圧縮がどのように実行できるかについての詳細な概観を示す図
【図５】本発明の一実施の形態において、圧縮されたヘッダストリームフォーマットの図であり、単一のプロトコルスタックについての圧縮ヘッダの典型的なフォーマットを示す図
【図６】本発明の一実施の形態において、分割ＰＤＵについての圧縮ヘッダ情報の図であり、分割を適用できる時にヘッダ情報の圧縮がどのように適用できるかについての詳細な概観を示す図
【符号の説明】
【００６６】
　１０１　多層プロトコルスタック
　１０２、２０２　多層ヘッダトランスコーダ
　１０３　データバス
　１０４　プロトコル層インタフェース
　１０５　パケットストリーム登録部
　１０６　符号化部
　１０７　復号化部
　１０８、１１３、１１４　パス
　１０９　層管理エンティティインタフェース
　１１１　プロトコル層管理エンティティ
　１１２　セッションコンテキストＩＤマネジャー
　１１５、１１６、２０４、２０５、２０６　インタフェース
　２０１　短ヘッダ情報処理装置
　２０３、２０７、２０８　ネットワークノード
　２０９　伝送媒体
　３０１　セッション期間
　３０２　サブセッション期間
　３０３　ＴＤＭフレーム
　３０４　ヘッダ情報同期
　３０５　データ
　３０６　ヘッダ情報再同期
　３０７　Ｔｈ
　３０８　Ｆｈ
　３０９　フレーム間間隔
　３１０、３１１　セッションフレーム
　３１２　ＰＤＵ
　３１３　分割ＴＤＭフレーム
　３１４、６０２　分割ＰＤＵ
　４０１、４０３　セッションコンテキストＩＤ
　４０２　連結プロセス部
　４０４　ペイロード
　４０５　圧縮ヘッダ
　４０６　コンテキストストリーム
　５０１　当初ヘッダ
　５０２　アドレスＩＤ
　５０３　Change＿フィールド
　５０４　Delta＿フィールド
　５０５　圧縮ヘッダストリーム
　５０６　オペレータ
　６０１　データペイロード
　６０３　Ｐｈ
　６０４　ｆｈ
　６０５　最終分割部分
　６０６　ＭＡＣヘッダ
【図１】
2004096738.tif 000003
【図２】
2004096738.tif 000004
【図３】
2004096738.tif 000005
【図４】
2004096738.tif 000006
【図５】
2004096738.tif 000007
【図６】
2004096738.tif 000008