(57)【要約】  論理的なコネクションを介して他のパケット通信装置とパケットヘッダを圧縮又は伸長するヘッダ処理を行なってパケット通信するパケット通信装置において、前記コネクションにおける第１のパケットフローに関する第１のヘッダ処理状態の状態マシンと、前記コネクションにおける第２のパケットフローに関する第２のヘッダ処理状態の状態マシンとを管理し、前記の各状態マシンのいずれか一方における状態遷移に応じて、他方における状態遷移を制御する。
2009072175.tif 000002
【特許請求の範囲】
【請求項１】
論理的なコネクションを介して他のパケット通信装置とパケットヘッダを圧縮又は伸長するヘッダ処理を行なってパケット通信するパケット通信装置であって、
前記コネクションにおける第１のパケットフローに関する第１のヘッダ処理状態の状態マシンと、前記コネクションにおける第２のパケットフローに関する第２のヘッダ処理状態の状態マシンとを管理する状態マシン管理手段と、
前記の各状態マシンのいずれか一方における状態遷移に応じて、他方における状態遷移を制御する制御手段と、
をそなえたことを特徴とする、パケット通信装置。
【請求項２】
前記第１のパケットフローは送信パケットフローであり、前記第１のヘッダ処理状態はヘッダ圧縮処理状態であるとともに、
前記第２のパケットフローは受信パケットフローであり、前記第２のヘッダ処理状態はヘッダ伸長処理状態である、
ことを特徴とする、請求項１記載のパケット通信装置。
【請求項３】
前記の各パケットフローはそれぞれ受信パケットフローであり、前記の各ヘッダ処理状態はそれぞれヘッダ伸長処理状態である、
ことを特徴とする、請求項１記載のパケット通信装置。
【請求項４】
前記の各パケットフローはそれぞれ送信パケットフローであり、前記の各ヘッダ処理状態はそれぞれヘッダ圧縮処理状態である、
ことを特徴とする、請求項１記載のパケット通信装置。
【請求項５】
前記制御手段は、
前記一方の状態マシンが２以上存在する場合に、特定の状態遷移の生じた前記一方の状態マシンの数が所定数を超えると、前記制御の可否を判定し、可能であれば、前記他方の状態マシンにおける状態遷移を実施する、ことを特徴とする、請求項１記載のパケット通信装置。
【請求項６】
前記制御手段は、
前記他方の状態マシンが２以上存在する場合に、前記他方の状態マシンのいずれかを選択的に前記判定の対象とする、ことを特徴とする、請求項５記載のパケット通信装置。
【請求項７】
前記他方の状態マシンにおけるヘッダ処理状態の状態遷移条件に、前記一方の状態マシンにおけるヘッダ処理状態の状態遷移種別と、前記他方の状態マシンにおけるヘッダ処理状態の状態種別とを含む、ことを特徴とする請求項１〜６のいずれか１項に記載のパケット通信装置。
【請求項８】
前記他方の状態マシンにおけるヘッダ処理状態の状態遷移条件に、前記ヘッダ処理のプロトコルで規定された遷移判定パラメータ値を含む、ことを特徴とする、請求項１〜７のいずれか１項に記載のパケット通信装置。
【請求項９】
前記ヘッダ処理は、ＲｏＨＣ（Robust Header Compression）処理である、ことを特徴とする、請求項１〜８のいずれか１項に記載のパケット通信装置。
【請求項１０】
論理的なコネクションを介して他のパケット通信装置とパケットヘッダを圧縮又は伸長するヘッダ処理を行なってパケット通信するパケット通信方法であって、
前記コネクションにおける第１のパケットフローに関する第１のヘッダ処理状態の状態マシンと、前記コネクションにおける第２のパケットフローに関する第２のヘッダ処理状態の状態マシンとを管理し、
前記の各状態マシンのいずれか一方における状態遷移に応じて、他方における状態遷移を制御する、
ことを特徴とする、パケット通信方法。
【請求項１１】
前記第１のパケットフローは送信パケットフローであり、前記第１のヘッダ処理状態はヘッダ圧縮処理状態であるとともに、
前記第２のパケットフローは受信パケットフローであり、前記第２のヘッダ処理状態はヘッダ伸長処理状態である、
ことを特徴とする、請求項１０記載のパケット通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット通信装置及びパケット通信方法に関する。本発明は、例えば、３ＧＰＰ（3rd Generation Partnership Project）の通信システム等において、パケットヘッダを圧縮、復元する技術に用いると好適である。
【背景技術】
【０００２】
３ＧＰＰの移動体通信システムでのパケット通信に適用可能な技術の１つとして、例えば、ロバストヘッダ圧縮（ＲｏＨＣ：Robust Header Compression）技術がある（下記非特許文献１参照）。ＲｏＨＣでは、パケット受信側でのヘッダ伸張（復元）処理の結果に応じて、パケット送信側でのヘッダ圧縮効率を適応的に変更（制御）する。
このＲｏＨＣに関する既存の技術として、例えば、下記特許文献１には、パケット受信側において、受信パケットのヘッダに誤りがあることを検出した場合に、参照情報の更新要求をパケット送信側に対して送信し、パケット送信側において、所定の時間内に複数の更新要求が受信された場合に、パケット受信側で参照情報が参照されずに復元された後、前記参照情報の更新に使用されるヘッダを有するパケットをパケット受信側に対して送信する方法が記載されている。【０００３】
また、下記特許文献２及び特許文献３には、例えば、復元されたヘッダを含むパケットのエラーを検出し、エラーが有るパケットの数とエラーが無いパケットの数との関係に基づいて、格納されている参照情報を更新する必要があると判定したときには、参照情報を更新するための更新情報を要求する方法が記載されている。
さらに、下記特許文献４には、例えば、単位時間Ｘあたりに受信したＡＣＫパケットまたはＮＡＣＫパケットの個数を求め、パケットのヘッダ圧縮に関する動作モードが圧縮効率優先モードであるときに、求めたＮＡＣＫパケットの個数が所定の値Ｙを超えた場合には、前記動作モードを信頼性優先モードに切り替え、前記動作モードが信頼性優先モードであるときに、単位時間Ｘあたりに受信したＡＣＫパケットの個数が所定の値Ｚを超えた場合には、前記動作モードを圧縮効率優先モードに切り替える方法が記載されている。【０００４】
また、下記特許文献５には、例えば、周期的な間隔で圧縮器の動作を変更する方法や、解凍器からのフィードバックに応じて、圧縮器の動作を変更する方法が記載されている。
【非特許文献１】3GPP TS36.300 V8.1.0 (2007-06)、4.3.1, Figure 6-1, Figure6-2, 6.3.1、[online]、3rd Generation Partnership Project、［平成１９年１２月３日検索］、インターネット〈http://www.3gpp.org/ftp/Specs/html-info/36300.htm〉
【特許文献１】特開２００２−９４５５４号公報
【特許文献２】特開２００４−２２９３１８号公報
【特許文献３】特開２００４−２１５３０７号公報
【特許文献４】特開２００２−１３５３６２号公報
【特許文献５】特表２００７−５０２０７３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上述した従来の技術では、同じベアラ（論理的なコネクション）に属する複数のパケットフローに関して、ＲｏＨＣの状態遷移はフロー間で独立して制御されるに過ぎない。
本発明の目的の一つは、ヘッダ伸張処理の失敗によるパケットデータの損失を低減することにある。【０００６】
また、通信システムのスループットを向上させることも本発明の他の目的の一つである。
なお、前記目的に限らず、後述する発明を実施するための最良の形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の一つとして位置付けることができる。
【課題を解決するための手段】
【０００７】
上記の目的を達成するために、本発明では、以下のパケット通信装置及びパケット通信方法を用いる。
（１）即ち、本発明のパケット通信装置は、論理的なコネクションを介して他のパケット通信装置とパケットヘッダを圧縮又は伸長するヘッダ処理を行なってパケット通信するパケット通信装置であって、前記コネクションにおける第１のパケットフローに関する第１のヘッダ処理状態の状態マシンと、前記コネクションにおける第２のパケットフローに関する第２のヘッダ処理状態の状態マシンとを管理する状態マシン管理手段と、前記の各状態マシンのいずれか一方における状態遷移に応じて、他方における状態遷移を制御する制御手段と、をそなえる。【０００８】
（２）ここで、前記第１のパケットフローは送信パケットフローであり、前記第１のヘッダ処理状態はヘッダ圧縮処理状態であるとともに、前記第２のパケットフローは受信パケットフローであり、前記第２のヘッダ処理状態はヘッダ伸長処理状態であってもよい。
（３）また、前記の各パケットフローはそれぞれ受信パケットフローであり、前記の各ヘッダ処理状態はそれぞれヘッダ伸長処理状態であってもよい。【０００９】
（４）さらに、前記の各パケットフローはそれぞれ送信パケットフローであり、前記の各ヘッダ処理状態はそれぞれヘッダ圧縮処理状態であってもよい。
（５）そして、前記制御手段は、前記一方の状態マシンが２以上存在する場合に、特定の状態遷移の生じた前記一方の状態マシンの数が所定数を超えると、前記制御の可否を判定し、可能であれば、前記他方の状態マシンにおける状態遷移を実施するようにしてもよい。【００１０】
（６）また、前記制御手段は、前記他方の状態マシンが２以上存在する場合に、前記他方の状態マシンのいずれかを選択的に前記判定の対象とすることとしてもよい。
（７）さらに、前記他方の状態マシンにおけるヘッダ処理状態の状態遷移条件に、前記一方の状態マシンにおけるヘッダ処理状態の状態遷移種別と、前記他方の状態マシンにおけるヘッダ処理状態の状態種別とを含むようにしてもよい。【００１１】
（８）また、前記他方の状態マシンにおけるヘッダ処理状態の状態遷移条件に、前記ヘッダ処理のプロトコルで規定された遷移判定パラメータ値を含むようにしてもよい。
（９）さらに、前記ヘッダ処理は、ＲｏＨＣ（Robust Header Compression）処理であることとしてもよい。
（１０）また、本発明のパケット通信方法は、論理的なコネクションを介して他のパケット通信装置とパケットヘッダを圧縮又は伸長するヘッダ処理を行なってパケット通信するパケット通信方法であって、前記コネクションにおける第１のパケットフローに関する第１のヘッダ処理状態の状態マシンと、前記コネクションにおける第２のパケットフローに関する第２のヘッダ処理状態の状態マシンとを管理し、前記の各状態マシンのいずれか一方における状態遷移に応じて、他方における状態遷移を制御する。【００１２】
（１１）ここで、前記第１のパケットフローは送信パケットフローであり、前記第１のヘッダ処理状態はヘッダ圧縮処理状態であるとともに、前記第２のパケットフローは受信パケットフローであり、前記第２のヘッダ処理状態はヘッダ伸長処理状態であってもよい。
【発明の効果】
【００１３】
上記本発明によれば、ヘッダ圧縮処理されたパケットデータを正常に復元できない期間を削減して、パケットデータの損失を抑制することができる。そして、通信システムのスループットを向上させることが可能となる。
【図面の簡単な説明】
【００１４】
【図１】本発明の概要を説明する図である。
【図２】一実施形態に係る通信システムの構成を示すブロック図である。
【図３】一実施形態に係るＵＥ及びｅＮＢの構成を示すブロック図である。
【図４】状態マシン対応データ・連動遷移条件データの一例を示す図である。
【図５】（Ａ）は一実施形態に係る圧縮器の状態マシン図であり、（Ｂ）は一実施形態に係る伸張器の状態マシン図である。
【図６】図２に示す通信システムの動作例を説明するフロー図である。
【図７】（Ａ）は本発明の第１変形例に係る圧縮器の状態マシン図であり、（Ｂ）は本発明の第１変形例に係る伸張器の状態マシン図である。
【図８】第１変形例に係る通信システムの動作例を説明するフロー図である。
【図９】第３変形例における状態マシン対応データ・連動遷移条件データの一例を示す図である。
【図１０】（Ａ）は第３変形例に係る圧縮器の状態マシン図であり、（Ｂ）は第３変形例に係る伸張器の状態マシン図である。
【図１１】第３変形例に係る通信システムの動作例を説明するフロー図である。
【図１２】第４変形例における状態遷移制御方法を説明するフロー図である。
【図１３】３ＧＰＰの移動体通信システムの構成例を示すブロック図である。
【図１４】ＲＯＨＣ  Ｏ−ｍｏｄｅにおける圧縮器の状態遷移を説明する図である。
【図１５】ＲＯＨＣ  Ｒ−ｍｏｄｅにおける圧縮器の状態遷移を説明する図である。
【図１６】伸張器の状態遷移を説明する図である。
【図１７】既存の通信システムの動作例を説明する図である。
【符号の説明】
【００１５】
１  ＵＥ
２  ｅＮＢ
１−Ａ，２−Ａ  圧縮器
１−Ｂ，２−Ｂ  伸張器
３  メモリ
４  バス
５  プロセッサ
６  パケット処理エンジン
７  ネットワークインタフェース
【発明を実施するための最良の形態】
【００１６】
以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に示す実施形態は、あくまでも例示に過ぎず、以下に示す実施形態で明示しない種々の変形や技術の適用を排除する意図はない。即ち、本発明は、その趣旨を逸脱しない範囲で種々変形（各実施形態を組み合わせる等）して実施することができる。
〔１〕適用システム例
以下に説明する実施形態では、通信システムの一例として、３ＧＰＰ（3rd Generation Partnership Project）の移動体通信システムを想定する。【００１７】
図１３に、３ＧＰＰの移動体通信システムの構成例を示す。
この図１３において、ＵＥ（User Equipment）１は、無線網管理ノード（evolved Node-B、略してｅＮＢ）２と無線通信を行なう機能を具備しており、ｅＮＢ２を介して他のＵＥ１や外部パケット網（インターネット、企業網など）４などと通信するものである。
ｅＮＢ２は、ＬＴＥ／ＳＡＥ（Long Term Evolution/System Architecture Evolution）よりも前の世代の無線基地局（Node-B）の機能と無線基地局制御装置（ＲＮＣ：Radio Network Controller）の機能とを兼ね備えている。【００１８】
また、ａＧＷ（E-UTRAN Access Gateway）などの無線アクセス網管理ノード３は、複数のｅＮＢ２を管理、制御し、ＵＥ１と外部パケット網４との間のメッセージの送受信を行なう。
上記システムでのパケット通信に用いられるパケットヘッダは、特に音声データを転送する場合、パケットデータに対してオーバヘッドが大きいため、そのままヘッダを付与して通信した場合には効率が悪い場合がある。また、無線区間の通信は有線区間の通信に比べて品質が劣りやすい傾向にあり、かつ、帯域幅等の通信リソースに限りがあるため、有線区間以上に通信効率の向上が求められる。【００１９】
このため、ｅＮＢ２とＵＥ１との間のパケット通信に関して、ヘッダ圧縮（ＲｏＨＣ：Robust Header Compression）が行なわれる場合がある（例えば、前記非特許文献１参照）。
ここで、前記非特許文献１によれば、パケット送信側の圧縮器におけるＲｏＨＣのヘッダ圧縮処理状態には、圧縮せずに全てのヘッダ情報を送信するＩＲ（Initialization and Refresh）状態，ヘッダ情報のうち動的に変化する部分（シーケンス番号など）を送信するＦＯ（First Order）状態，ヘッダ情報のうち動的に変化する部分をエンコードし最小フィールドのみを送信するＳＯ（Second Order）状態がある。さらに、ＲｏＨＣには３つの転送モードとして、Ｕ（Unidirectional）モード，Ｏ（Optimistic）モード，Ｒ（Reliable）モードが定義されており、通信中にそれぞれのモードへの遷移が可能である。【００２０】
一方、対向するパケット受信側の伸張器におけるＲｏＨＣのヘッダ伸張処理状態には、デコードするためのヘッダ情報が全く無いＮＣ（No Context）状態，静的なヘッダ情報（アドレスやポート番号など）を有する（つまり、動的なフィールドの受信、更新が必要である）ＳＣ（Static Context）状態，動的に変化するヘッダ値の差分情報をデコード可能（つまり、フィールド情報を正しく復号可能）なＦＣ（Full Context）状態がある。【００２１】
ＲｏＨＣでは、前記Ｏモード、あるいは、Ｒモードのパケット送信側の圧縮器において、対向局（受信側）からのフィードバック情報に応じて、ヘッダ圧縮処理状態が制御されるとともに、パケット受信側の受信器において、対向局（送信側）からのパケットデータのヘッダ伸張処理結果（エラーチェック結果）に基づき、ヘッダ伸張処理状態が制御される（例えば、前記特許文献１〜５参照）。【００２２】
ここで、図１４〜図１６に、上述のヘッダ圧縮処理状態及びヘッダ伸張処理状態に係る状態マシン（状態遷移図）を示す。図１４は圧縮器におけるＯモードの状態マシンを示し、図１５は圧縮器におけるＲモードの状態マシンを示す。また、図１６は伸張器における状態マシンを示す。
図１４に示すように、Ｏモードにおいては、圧縮器は、ＩＲ状態から動作を開始し、対向局宛に、パケットヘッダ伸張処理のための完全な参照情報（コンテクスト情報）を含むパケットヘッダを送出する。【００２３】
そして、対向局側の伸張器がより上位のヘッダ圧縮処理状態（ＦＯ状態あるいはＳＯ状態）に従って正常にパケットデータを伸張（復元）できると推測した場合（Optimistic）や、対向局側の伸張器からフィードバック情報として正常応答（ＡＣＫ）を受信した場合、ヘッダ圧縮処理状態は、より上位のＦＯ状態あるいはＳＯ状態に遷移する。
ヘッダ圧縮処理状態がＦＯ状態へ遷移すると、対向局側の伸張器がより上位のヘッダ圧縮処理状態（ＳＯ状態）に従って正常にパケットデータを伸張できると推測した場合（Optimistic）や、対向局側の伸張器からフィードバック情報として正常応答（ＡＣＫ）を受信した場合に、ヘッダ圧縮処理状態は、より上位のＳＯ状態へ遷移する。【００２４】
一方、ＳＯ状態で対向局側の伸張器からフィードバック情報として静的否定応答（ＳＴＡＴＩＣ＿ＮＡＣＫ）を受信した場合、ヘッダ圧縮処理状態は下位のＩＲ状態へ遷移する。
そして、ヘッダ圧縮処理状態がＳＯ状態へ遷移した場合は、対向局側の伸張器からフィードバック情報として正常応答（ＡＣＫ）を受信すると、ヘッダ圧縮処理状態は、現状のＳＯ状態に留まる。【００２５】
一方、対向局側の伸張器からフィードバック情報として否定応答（ＮＡＣＫ）を受信した場合や、コンテクスト情報の更新要求（update）を受信した場合、ヘッダ圧縮処理状態は、より下位のＦＯ状態へ遷移する。また、対向局側の伸張器からフィードバック情報として静的否定応答（ＳＴＡＴＩＣ＿ＮＡＣＫ）を受信した場合、ヘッダ圧縮処理状態は、より下位のＩＲ状態へ遷移する。【００２６】
また、図１５に示すように、Ｒモードでは、上記のＯモードとは異なり、推測による状態遷移（制御）は行なわれない。例えば、対向局側の伸張器からのＡＣＫ応答により、ヘッダ圧縮処理状態が、より上位（ＩＲ状態からＦＯ状態あるいはＳＯ状態、またはＦＯ状態からＳＯ状態）へ遷移する。
一方、図１６に示すように、対向局側の伸張器は、ＮＣ状態から動作を開始し、対向局側の圧縮器から受信したパケット（ＩＲパケット）データに対して、上記完全なコンテクスト情報を基にヘッダ伸張処理を行なう。このヘッダ伸張処理が成功すると、伸張器のヘッダ伸張処理状態は、ＦＣ状態へ遷移する。【００２７】
ＦＣ状態において、対向局側の圧縮器から受信したパケットデータについてのヘッダ伸張処理が成功した場合、ヘッダ伸張処理状態は、現状のＳＯ状態に留まる。しかし、ヘッダ伸張処理が失敗した場合は、ヘッダ伸張処理状態は、より下位のＳＣ状態へ遷移する。図１６に示す例では、ＦＣ状態において、所定のエラーレートを超える場合、例えば、対向局から受信したｎ1個のパケットデータのうちｋ1個のパケットデータがヘッダ伸張処理に失敗した場合に、ヘッダ伸張処理状態は、より下位のＳＣ状態へ遷移する。【００２８】
また、ＳＣ状態においては、対向局側の圧縮器から受信したパケットデータについてのヘッダ伸張処理が成功した場合、ヘッダ伸張処理状態は、ＦＣ状態へ遷移する。一方、ヘッダ伸張処理が失敗した場合は、ヘッダ伸張処理状態は、より下位のＮＣ状態へ遷移する。
図１６に示す例では、ＳＣ状態において、所定のエラーレートを超える場合、例えば、対向局から受信したｎ2個のパケットデータのうちｋ2個のパケットデータがヘッダ伸張処理に失敗した場合、ヘッダ伸張処理状態は、より下位のＮＣ状態へ遷移する。また、ＳＣ状態において、動的なコンテクスト情報が必要である場合（No#Dynamic）は、ＳＣ状態に留まる。【００２９】
さらに、ＮＣ状態においては、対向局側の圧縮器から受信したパケットデータについてのヘッダ伸張処理が成功した場合、ヘッダ伸張処理状態は、ＦＣ状態へ遷移する。一方、ＮＣ状態において、静的なコンテクスト情報が必要である場合（No#Static）、ＮＣ状態に留まる。
上述の状態遷移（制御）を行なうシステムの動作について図１７を用いて説明する。【００３０】
例えば、圧縮器１−Ａ及び伸張器１−ＢをそなえたＵＥ１と、伸張器２−Ｂ及び圧縮器２−ＡをそなえたｅＮＢ２とが、ＲｏＨＣによるパケット通信を行なう場合、ＵＥ１からｅＮＢ２への上り通信方向（以下、ＵＬという）では、圧縮器１−Ａにおいて現状のヘッダ圧縮処理状態に応じたヘッダ圧縮が施されたパケットデータが、伸張器２−Ｂへ送信される。【００３１】
圧縮器１−Ａからのヘッダ圧縮処理済みパケットデータを受信した伸張器２−Ｂは、以前に受信したヘッダ情報（コンテクスト情報）を用いて当該パケットデータを伸張（デコード）する。このとき、伸張器では、パケットデータに関するエラーチェックが行なわれ、そのエラーチェック結果が、圧縮器１−Ａへとフィードバック情報として返信される。
つまり、前記デコード処理が成功した場合は、フィードバック情報としてＡＣＫが圧縮器１−Ａに返されるが、失敗した場合は、コンテクスト情報の欠落などにより伸張されなかったパケットデータに関する情報が圧縮器１−Ａにフィードバック情報（例えば、ＮＡＣＫなど、ＳＯ状態からＦＯ状態への状態遷移を誘起する情報）として送信される。【００３２】
伸張器２−Ｂでは、前記エラーチェック結果に応じて、上述のようにＮＣ，ＳＣ，ＦＣのいずれかへの状態遷移が行なわれる一方、圧縮器１−Ａでは、前記フィードバック情報に応じて、上述のようにＩＲ，ＦＯ，ＳＯのいずれかへの状態遷移が行なわれる。
一方、ｅＮＢ２からＵＥ１への下り通信方向（以下、ＤＬという）でも、ＵＬと同様の状態遷移制御が行なわれる。【００３３】
このようにして、伸長器２−Ｂ（１−Ｂ）は、デコードを行なうためのコンテクスト情報が古くなった場合や、コンテクスト情報を適切に更新できなくなった場合などに、圧縮器１−Ａ（２−Ａ）側へフィードバック情報を通知して、ヘッダ圧縮処理状態をＩＲ状態やＦＯ状態などのより上位の状態へ遷移させることで前記コンテクスト情報を更新する。
〔２〕概要
図１に示す例を用いて本例の概要を説明する。【００３４】
この図１に示すように、例えば、ＵＥ１（ｅＮＢ２）側の圧縮器から対向局｛ｅＮＢ２（ＵＥ１）｝側の伸張器宛にヘッダ圧縮処理済みのパケットデータが送信される場合、ヘッダ圧縮処理状態がＳＯ状態であり、かつ、ヘッダ伸張処理状態がＦＣ状態であれば、パケットデータは正常にデコードされる（（１）伸張ＯＫ）。
ところが、ＵＥ１とｅＮＢ２との間の通信環境の変化などにより、対向局側の伸張器２−Ｂ（１−Ｂ）において、複数回のパケットエラーが検出されると（（２）複数回のパケットエラー）、上述のように、ヘッダ伸張処理状態はＦＣ状態から下位のＳＣ状態へ遷移する。なお、以下、上述した既存の状態遷移を本例での状態遷移と区別する意味で通常遷移ということがある。【００３５】
このとき、圧縮器１−Ａ（２−Ａ）は、フィードバック情報を受信するまでは対向局側の伸張器２−Ｂ（１−Ｂ）のヘッダ伸張処理状態が遷移したことを知らないので、それまでどおり、ＳＯ状態でのヘッダ圧縮処理を施されたパケットデータ（エンコードした動的ヘッダ情報を含むパケットデータ）を上記対向局側の伸張器宛に送信する。
しかしながら、対向局側の伸張器２−Ｂ（１−Ｂ）は静的なヘッダ情報しかもたないＳＣ状態にあり、前記パケットデータを正常にデコードすることができないので、当該パケットデータは破棄される（（３）伸張ＮＧ）。【００３６】
対向局側の伸張器２−Ｂ（１−Ｂ）は、自身のヘッダ伸張処理状態の通常遷移に応じて、上記圧縮器１−Ａ（２−Ａ）宛に、ＳＯ状態からＦＯ状態への遷移を誘起するフィードバック情報を送出する（（４）フィードバック情報）。
その結果、上記圧縮器１−Ａ（２−Ａ）のヘッダ圧縮処理状態はＳＯ状態からＦＯ状態へ通常遷移し、コンテクスト情報が更新されて、対向局側の伸張器２−Ｂ（１−Ｂ）は正常なデコード処理を行なうことが可能となる（（５）伸張ＯＫ／参照情報の更新）。【００３７】
ところで、ＵＥ１とｅＮＢ２との間でＶｏＩＰ（Voice over IP）通信を行なうことがある。ＶｏＩＰ通信では、ペイロードデータ（パケットデータ）に対し、ヘッダ（パケットヘッダ）のオーバヘッドが大きいため、ＲｏＨＣを適用するのが好ましい。また、ＶｏＩＰ通信は、通信遅延に敏感であるため、優先度の高い（ＱｏＳの高い）通信路サービス（ベアラ）で取り扱うことが好ましい。【００３８】
ここで、ＵＥ１とｅＮＢ２との間で優先度の高いベアラによるサービスを提供することとしても、上述のような、複数回のパケットエラーによるヘッダ伸張処理状態の遷移（例えば、ＦＣ状態からＳＣ状態への遷移）が発生する場合がある。これは、ＵＥ１が無線通信の好ましくない位置（トンネルの中、屋内、ビルの陰など）に存在しているような場合である。【００３９】
このような場合、上述のように対向局側の伸張器２−Ｂ（１−Ｂ）のヘッダ伸張処理状態が複数回のパケットエラーによる遷移が生じたとしても、そのことを上記圧縮器１−Ａ（２−Ａ）に通知するためのフィードバック情報が到達しないことがある。
その結果、対向局側の伸張器２−Ｂ（１−Ｂ）のヘッダ伸張処理状態が遷移しても、圧縮器のヘッダ圧縮処理状態は遷移されず、状態遷移後の対向局側の伸張器２−Ｂ（１−Ｂ）では正常なデコード処理を行なうことができないようなヘッダ圧縮処理済みのパケットデータが送信されることになる。この場合、そのようなパケットデータは、対向局側の伸張器２−Ｂ（１−Ｂ）で破棄されることになる。【００４０】
また、ＵＥ１とｅＮＢ２との間の通信環境の変化によりフィードバック情報の到達が遅延することもある。そのような場合、フィードバック情報の遅延期間に比例して状態遷移後の対向局側の伸張器２−Ｂ（１−Ｂ）では正常なデコード処理を行なうことができないようなヘッダ圧縮処理済みのパケットデータが送信されることになるので、やはり多くのパケットデータが破棄される。【００４１】
そこで、以下に説明する限定的でない例では、圧縮器１−Ａ（２−Ａ）及び伸張器２−Ｂ（１−Ｂ）をそなえたパケット通信装置において、第１のヘッダ処理状態の状態マシンと、第２のヘッダ処理状態の状態マシンとのいずれか一方における状態遷移に応じて、他方における状態遷移を制御する（以下、かかる状態遷移を前記通常遷移と区別する意味で連動遷移ということがある）。【００４２】
例えば、自局の伸張器１−Ｂ（２−Ｂ）のヘッダ伸張処理状態が、現状よりも下位（例えば、ＦＣ状態からＳＣ状態）へ通常遷移したことを検出すると、これに連動して、自局の圧縮器１−Ａ（２−Ａ）のヘッダ圧縮処理状態を現状よりも下位（例えば、ＳＯ状態からＦＯ状態）へ連動遷移させる。
これにより、対向局側の伸張器２−Ｂ（１−Ｂ）からのフィードバック情報によらず、自局の圧縮器１−Ａ（２−Ａ）のヘッダ圧縮処理状態を遷移させることができる。つまり、上述のように、フィードバック情報の未達や遅延が発生した場合においても、自局の伸張器１−Ｂ（２−Ｂ）のヘッダ伸張処理状態の遷移に応じて、自局の圧縮器１−Ａ（２−Ａ）のヘッダ圧縮処理状態を連動遷移させることが可能となる。その結果、自局の圧縮器１−Ａ（２−Ａ）のヘッダ圧縮処理状態を、対向局側でデコードが成功する可能性の高いヘッダ圧縮処理状態へ確実且つ迅速に遷移させることができる。【００４３】
即ち、自局の圧縮器１−Ａ（２−Ａ）のヘッダ圧縮処理状態を、対向局側の伸張器２−Ｂ（１−Ｂ）のヘッダ伸張処理状態と迅速に整合（適合）させることができ、パケットデータの損失発生期間を削減して、通信システムのスループットを向上させることが可能となる。
〔３〕一実施形態
（３．１）システム構成
図２は一実施形態に係る通信システムの構成を示すブロック図である。この図２に示すシステムは、例えば、ａＧＷや外部パケット網などに相当する上位ネットワーク（図示省略）と、ＵＥ１と、ｅＮＢ２とをそなえる。【００４４】
即ち、図２に示す通信システムは、論理的なコネクション（例えば、ベアラ）を介してｅＮＢ２（またはＵＥ１）とパケットヘッダを圧縮又は伸張するヘッダ処理を行なってパケット通信するパケット送信装置としてのＵＥ１（またはｅＮＢ２）と、前記パケット送信装置からのヘッダ圧縮処理済みのパケットデータを、受信済みの参照情報（コンテクスト情報）を基に伸張（復元）するパケット受信装置としてのｅＮＢ２（またはＵＥ１）とをそなえる。【００４５】
また、ＵＥ１及びｅＮＢ２の要部に着目すると、ＵＥ１は、圧縮器１−Ａと、伸張器１−Ｂとをそなえ、ｅＮＢ２は、伸張器２−Ｂと、圧縮器２−Ａとをそなえる。
ここで、圧縮器１−Ａ（２−Ａ）は、対向局宛に送信すべきパケットデータ（のパケットヘッダ）について、現状のヘッダ圧縮処理状態（ＩＲ，ＦＯ，ＳＯのいずれかの状態）に従って、ＲｏＨＣ処理（圧縮処理）を施し、ヘッダ圧縮処理済みのパケットデータを送信する機能を具備する。【００４６】
対向局側の伸張器２−Ｂ（１−Ｂ）は、現状のヘッダ伸張処理状態（ＮＣ，ＳＣ，ＦＣのいずれかの状態）に従って、上記圧縮器１−Ａ（２−Ａ）からのパケットデータのヘッダ情報（コンテクスト情報）を抽出するとともに、前記コンテクスト情報を用いてヘッダ圧縮処理済みのパケットデータの伸張（復元）を行なうものである。また、前記伸張処理の際にエラーチェックを行ない、そのエラーチェック結果をフィードバック情報（例えば、ＳＯ状態からＦＯ状態への遷移を誘起する情報）として圧縮器１−Ａ（２−Ａ）宛に返信する機能を具備する。【００４７】
なお、コンテクスト情報の欠落などにより正常に伸張できないパケットデータは伸張器２−Ｂ（１−Ｂ）で破棄され、正常に伸張されたパケットデータは、上位ネットワーク側のａＧＷ（図示省略）へ送信される。
本実施形態における伸張器１−Ｂ（２−Ｂ）は、上述した機能に加えて、自身のヘッダ伸張処理状態の遷移に関する情報を同一局内の圧縮器１−Ａ（２−Ａ）へ通知する機能を具備する。そして、伸張器１−Ｂ（２−Ｂ）からのヘッダ伸張処理状態の遷移に関する情報を受けた圧縮器１−Ａ（２−Ａ）では、当該情報に応じてヘッダ圧縮処理状態が連動遷移される。【００４８】
一方、本実施形態における圧縮器１−Ａ（２−Ａ）も上述の機能に加えて、ヘッダ圧縮処理状態の遷移に関する情報を同一局内の伸張器１−Ｂ（２−Ｂ）へ通知する機能を具備する。そして、圧縮器１−Ａ（２−Ａ）からのヘッダ圧縮処理状態の遷移に関する情報を受けた伸張器１−Ｂ（２−Ｂ）でも同様に、当該情報に応じてヘッダ伸張処理状態が連動遷移される。【００４９】
これにより、ＵＥ１とｅＮＢ２との間の通信環境の変化などにより、対向局側の伸張器２−Ｂ（１−Ｂ）からのフィードバック情報が到達しなかったり遅延したりしても、ヘッダ圧縮処理状態を当該通信環境に適した状態に迅速に連動遷移させることができる。
その結果、ヘッダ圧縮処理済みのパケットデータを正常に復元できない期間を削減できるので、パケットデータの損失を抑制して、通信システムのスループットを向上させることが可能となる。【００５０】
また、上述の状態遷移制御方法を従来の状態遷移制御方法と併用すれば、状態遷移のフィードバック経路が単純に二倍となり、エラー耐性を強化することが可能となる。
（３．２）ＵＥ１（ｅＮＢ２）について
図３は一実施形態に係るＵＥ１及びｅＮＢ２の構成を示すブロック図である。
この図３に示すように、ＵＥ１（ｅＮＢ２）は、例えば、メモリ３と、バス４と、プロセッサ５と、パケット処理エンジン６と、ネットワークインタフェース７とをそなえ、パケット処理エンジン６は、圧縮器１−Ａ（２−Ａ）と、伸張器１−Ｂ（２−Ｂ）とをそなえる。【００５１】
メモリ３は、プロセッサ５及びパケット処理エンジン６による各種制御用データを格納する機能を具備するものである。本メモリ３には、例えば、通信ベアラ管理データ，伸張器制御データ，圧縮器制御データ及び状態マシン対応データ・連動遷移条件データなどが格納される。
通信ベアラ管理データは、ＵＥ１とｅＮＢとの間の通信路（ベアラ）を管理するための情報である。また、伸張器制御データは、伸張器１−Ｂ（２−Ｂ）のヘッダ伸張処理状態を管理（制御）するための情報で、例えば、伸張器１−Ｂ（２−Ｂ）の状態マシンや、ヘッダ伸張処理状態及びその遷移状況に関する情報を含む。【００５２】
さらに、圧縮器制御データは、圧縮器１−Ａ（２−Ａ）のヘッダ圧縮処理状態を管理（制御）するための情報で、例えば、圧縮器１−Ａ（２−Ａ）の状態マシンや、ヘッダ圧縮処理状態及びその遷移状況に関する情報を含むものである。
また、状態マシン対応データ・連動遷移条件データは、同一ベアラに属する状態マシン（ヘッダ圧縮処理状態及びヘッダ伸張処理状態）の対応関係に関する情報で、例えば、後述するように、図４に示すようなデータ構成をとる。この状態マシン対応データ・連動遷移条件データは、プロセッサ５によりベアラが確立され、また、パケット処理エンジン６によりＲｏＨＣによる送受信パケットフローが開始され、さらに、前記圧縮器制御データ及び伸張器制御データ上に各状態マシンが生成された場合に、プロセッサ５及びパケット処理エンジン６が、通信ベアラ管理データを用いて、各状態マシンの対応付けを行なうことにより作成される。【００５３】
バス４は、各種データを送受するための通信路であり、プロセッサ５は、ＵＥ１（ｅＮＢ２）における各種制御を行なうもので、例えば、メモリ３に格納される上記通信ベアラ管理データを用いて、ベアラの確立などの通信制御を行なう機能を具備する。
また、パケット処理エンジン６は、圧縮器１−Ａ（２−Ａ）及び伸張器１−Ｂ（２−Ｂ）の各種制御を行なうもので、例えば、メモリ３に格納される伸張器制御データ，圧縮器制御データ及び状態マシン対応データ・連動遷移条件データを用いて、圧縮器１−Ａ（２−Ａ）のヘッダ圧縮処理状態の遷移制御、及び、伸張器１−Ｂ（２−Ｂ）のヘッダ伸張処理状態の遷移制御などを行なう機能を具備する。なお、圧縮器１−Ａ（２−Ａ）及び伸張器１−Ｂ（２−Ｂ）は、（３．１）にて上述したものと同様の機能を具備する。【００５４】
即ち、メモリ３及びパケット処理エンジン６は、前記ベアラにおける送信パケットフローあるいは受信パケットフロー（第１のパケットフロー）に関するヘッダ圧縮処理状態あるいはヘッダ伸張処理状態（第１のヘッダ処理状態の状態マシン）と、前記ベアラにおける送信パケットフローあるいは受信パケットフロー（第２のパケットフロー）に関するヘッダ圧縮処理状態あるいはヘッダ伸張処理状態（第２のヘッダ処理状態の状態マシン）とを管理する状態マシン管理手段として機能する。【００５５】
また、パケット処理エンジン６は、前記の各状態マシンのいずれか一方における状態遷移に応じて、他方における状態遷移を制御する制御手段として機能する。
ネットワークインタフェース７は、ＵＥ１（ｅＮＢ２）と外部ネットワーク（ｅＮＢ２の場合は、無線ネットワーク）とのインタフェース機能を具備するもので、例えば、圧縮器１−Ａ（２−Ａ）からのヘッダ圧縮処理済みのパケットデータについて所定の送信処理を施し、外部ネットワークへ送出する一方、外部ネットワークからのパケットデータについて所定の受信処理を施し、バス４を介して伸張器１−Ｂ（２−Ｂ）へ送出する機能を具備する。なお、ＵＥ１側のネットワークインタフェース７は、上位プロトコル層（アプリケーション）とのデータ送受を行なう機能も具備する。また、ｅＮＢ２におけるネットワークインターフェース７は、ＵＥ１とのデータ送受の他、外部ネットワークとのデータ送受を行なう機能も具備する。【００５６】
ここで、図４を用いて状態マシン対応データ・連動遷移条件データについて説明する。図４は状態マシン対応データ・連動遷移条件データの一例を示す図である。
図４に示すように、状態マシン対応データ・連動遷移条件データは、例えば、ＵＥ１とｅＮＢ２との間に設定される複数のベアラにおいて、複数のＲｏＨＣフロー（送受信パケットフロー）毎に、発生した状態遷移イベントを表す状態遷移内容と、その状態遷移内容に連動して実施される状態遷移対象を示す連動遷移対象とが対応付けられて設定される。【００５７】
具体的には、例えば、あるベアラａにおいて、上記状態遷移内容として受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態のＦＣ状態からＳＣ状態への遷移が設定されており、また、当該状態遷移内容に対応付けられた上記連動遷移対象として、送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態のＳＯ状態からＦＯ状態への遷移が設定されている場合、パケット処理エンジン６により、受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態のＦＣ状態からＳＣ状態への遷移が検出されると（状態遷移イベントの発生）、上記状態マシン対応データ・連動遷移条件データが参照される。【００５８】
このとき、上記状態マシン対応データ・連動遷移条件データには、受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態のＦＣ状態からＳＣ状態への遷移に対して、送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態のＳＯ状態からＦＯ状態への遷移が連動遷移対象として設定されているので、当該状態遷移イベントに連動して、送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態のＳＯ状態からＦＯ状態への遷移制御が実施されるのである。なお、もちろん、同様にして、送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態の遷移イベント発生に応じて、受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態の遷移を行なうこともできる。【００５９】
図５（Ａ）及び図５（Ｂ）を用いて上記の状態遷移制御方法の一例を説明する。図５（Ａ）は本圧縮器１−Ａ（２−Ａ）の状態マシン図であり、図５（Ｂ）は本伸張器１−Ｂ（２−Ｂ）の状態マシン図である。
図５（Ａ）に示すように、送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態がＳＯ状態（ＳＯ＿ｉ）である場合においては、対向局側の伸張器２−Ｂ（１−Ｂ）からフィードバック情報として否定応答（ＮＡＣＫ）を受信した場合やコンテクスト情報の更新要求（update）を受信した場合に通常遷移されるのに加えて、受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態がＦＣ状態（ＦＣ＿ｋ）からＳＣ状態（ＳＣ＿ｋ）へ通常遷移した場合や受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態がＳＣ状態（ＳＣ＿ｋ）からＮＣ状態（ＮＣ＿ｋ）へ通常遷移した場合に、ヘッダ圧縮処理状態は、より下位のＦＯ状態（ＦＯ＿ｉ）へ連動遷移される。【００６０】
また、送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態がＦＯ状態（ＦＯ＿ｉ）である場合においては、対向局側の伸張器２−Ｂ（１−Ｂ）からフィードバック情報として静的否定応答（ＳＴＡＴＩＣ＿ＮＡＣＫ）を受信した場合に通常遷移されるのに加えて、受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態がＦＣ状態（ＦＣ＿ｋ）からＳＣ状態（ＳＣ＿ｋ）へ通常遷移した場合や受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態がＳＣ状態（ＳＣ＿ｋ）からＮＣ状態（ＮＣ＿ｋ）へ通常遷移した場合に、ヘッダ圧縮処理状態は、より下位のＩＲ状態（ＩＲ＿ｉ）へ連動遷移される。【００６１】
一方、図５（Ｂ）に示すように、受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態がＦＣ状態（ＦＣ＿ｋ）である場合においては、例えば、対向局から受信したｎ1個のパケットデータのうちｋ1個のパケットデータがヘッダ伸張処理に失敗した（所定のエラーレートを超えた）場合に通常遷移されるのに加えて、送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態が、フィードバック情報（ＮＡＣＫまたはupdate）に起因してＳＯ状態（ＳＯ＿ｉ）からＦＯ状態（ＦＯ＿ｉ）へ通常遷移した場合や送信パケットフロー「＃ｉ」に関するヘッダ伸張処理状態がＳＯ状態（ＳＯ＿ｉ）からＩＲ状態（ＩＲ＿ｉ）へ遷移した場合、あるいは、フィードバック情報（ＳＴＡＴＩＣ＿ＮＡＣＫ）に起因してＦＯ状態（ＦＯ＿ｉ）からＩＲ状態（ＩＲ＿ｉ）へ通常遷移した場合に、ヘッダ伸張処理状態は、より下位のＳＣ状態（ＳＣ＿ｋ）へ連動遷移される。【００６２】
また、受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態がＳＣ状態（ＳＣ＿ｋ）である場合においては、例えば、対向局から受信したｎ2個のパケットデータのうちｋ2個のパケットデータがヘッダ伸張処理に失敗した（所定のエラーレートを超えた）場合に通常遷移されるのに加えて、送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態が、フィードバック情報（ＮＡＣＫまたはupdate）に起因してＳＯ状態（ＳＯ＿ｉ）からＦＯ状態（ＦＯ＿ｉ）へ通常遷移した場合や送信パケットフロー「＃ｉ」に関するヘッダ伸張処理状態がＳＯ状態（ＳＯ＿ｉ）からＩＲ状態（ＩＲ＿ｉ）へ遷移した場合、あるいは、フィードバック情報（ＳＴＡＴＩＣ＿ＮＡＣＫ）に起因してＦＯ状態（ＦＯ＿ｉ）からＩＲ状態（ＩＲ＿ｉ）へ通常遷移した場合に、ヘッダ伸張処理状態は、より下位のＮＣ状態（ＮＣ＿ｋ）へ連動遷移される。【００６３】
このように、本実施形態では、自局（ＵＥ１あるいはｅＮＢ２）のヘッダ圧縮処理状態（あるいはヘッダ伸張処理状態）の下位状態への遷移が発生すると、それに連動して、ヘッダ伸張処理状態（あるいはヘッダ圧縮処理状態）の下位状態への遷移を行なうのである。
なお、上記状態マシン対応データ・連動遷移条件データの設定は、あくまでもその一例に過ぎず、適宜変更することもできる。【００６４】
例えば、ヘッダ圧縮処理状態がＳＯ状態（ＳＯ＿ｉ）からＩＲ状態（ＩＲ＿ｉ）へ連動遷移する条件として、受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態がＦＣ状態（ＦＣ＿ｋ）からＳＣ状態（ＳＣ＿ｋ）へ通常遷移した場合や受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態がＳＣ状態（ＳＣ＿ｋ）からＮＣ状態（ＮＣ＿ｋ）へ通常遷移した場合を追加しても、本実施形態を同様に実施することができる。【００６５】
（３．３）本例の通信システムの動作について
次に、本例の通信システムの動作例について図６を用いて説明する。
この図６に示すように、まず、パケット処理エンジン６が、圧縮器１−Ａ（２−Ａ）あるいは伸張器１−Ｂ（２−Ｂ）における或る状態Ａの下位状態遷移イベントの発生を検知する（ステップＳ１参照）。ここで、或る状態Ａの下位状態遷移イベントとは、例えば、図５（Ｂ）に示すような、ヘッダ伸張処理状態のＦＣ状態からＳＣ状態への通常遷移などを指す。【００６６】
すると、パケット処理エンジン６によりメモリ３に格納される各種データが参照され、ステップＳ１の状態遷移イベントを遷移条件にもつ状態マシンがあるかどうかが判定される（ステップＳ２）。つまり、状態マシン対応データ・連動遷移条件データに、状態Ａの下位状態遷移イベントの発生を示す状態遷移内容が設定されているかどうかを判定し、設定されていると判定した場合は（ステップＳ２のＹＥＳルート参照）、連動遷移対象に設定されている遷移対象を抽出する一方、設定されていないと判定した場合は（ステップＳ２のＮＯルート参照）、状態Ａの下位状態遷移イベントを実行する（ステップＳ４参照）。【００６７】
例えば、状態Ａの下位状態遷移イベントが図５（Ｂ）に示すような、ヘッダ伸張処理状態のＦＣ状態からＳＣ状態への通常遷移であるとすれば、図５（Ａ）に示すような、ヘッダ圧縮処理状態のＳＯ状態からＦＯ状態への連動遷移や、ＦＯ状態からＩＲ状態への連動遷移がパケット処理エンジン６により連動遷移対象として抽出される。
パケット処理エンジン６は、上記連動遷移対象に該当する状態マシンにおいて、現状態が最下位状態（ＩＲ状態あるいはＮＣ状態）でないかどうかを判定し、最下位状態でないと判定した場合に、当該連動遷移対象に設定されている遷移対象について下位状態への遷移を実施する（ステップＳ３参照）。最下位状態である場合は、遷移の必要がないので連動遷移は実施しない。【００６８】
例えば、ヘッダ圧縮処理状態の現状態がＳＯ状態であるとすれば、ＳＯ状態からＦＯ状態への連動遷移が実施される。
次いで、パケット処理エンジン６は、状態Ａの下位状態遷移イベントを実行する（ステップＳ４参照）。ここで、例えば、上記状態Ａの下位状態遷移イベントが、伸張器１−Ｂ（１−Ａ）のヘッダ伸張処理状態の下位状態遷移である場合は、当該下位状態遷移イベントの実行とともに、対向局側の圧縮器２−Ａ（１−Ａ）宛に上述のフィードバック情報が送信され、圧縮器２−Ａ（１−Ａ）においても下位状態への遷移イベントが誘発される。【００６９】
本通信システムが上述のように動作することにより、ＵＥ１及びｅＮＢ２は、圧縮器１−Ａ（２−Ａ）のヘッダ圧縮処理状態が下位の状態へ遷移（例えば、ＳＯ状態からＦＯ状態へ遷移）するためのフィードバック情報が対向局側の伸張器２−Ｂ（１−Ｂ）から到達しない場合においても、自局の伸張器１−Ｂ（２−Ｂ）のヘッダ伸張処理状態の状態遷移に連動して、前記ヘッダ圧縮処理状態を対向局側でデコード処理が成功する可能性の高いヘッダ圧縮処理状態へ遷移させることができる。【００７０】
同様に、ＵＥ１及びｅＮＢ２は、圧縮器１−Ａ（２−Ａ）ヘッダ圧縮処理状態の状態遷移に連動して、自局の伸張器１−Ｂ（２−Ｂ）のヘッダ伸張処理状態を遷移させることができる。なお、このヘッダ伸張処理状態の連動遷移に応じて、伸張器１−Ｂ（２−Ｂ）が、対向局側の圧縮器２−Ａ（１−Ａ）宛に状態遷移を誘起するフィードバック情報を送信すれば、上記所定のエラーレートを超えるのを待たずに、対向局側の圧縮器２−Ａ（１−Ａ）のヘッダ圧縮処理状態を適切な状態に遷移させることができる。【００７１】
つまり、本通信システムは、ＵＥ１及びｅＮＢ２にそなえられた圧縮器１−Ａ，２−Ａ及び伸張器１−Ｂ，２−Ｂの各状態マシンのいずれかにおいて下位状態への遷移が発生すると、これに連動して、自局及び対向局の他の状態マシンの遷移を迅速に実施することができるのである。その結果、エラー耐性、対応の迅速さを向上させることができる。
このように、本通信システムによれば、ヘッダ圧縮処理済みのパケットデータを正常に復元できない期間を削減して、パケットデータの損失を抑制することができ、通信システムのスループットを向上させることが可能となる。【００７２】
〔４〕第１変形例
上述した例では、圧縮器１−Ａ（２−Ａ）及び伸張器１−Ｂ（２−Ｂ）のいずれか一方の状態マシンにおいて下位状態への遷移が発生すると、それに連動して、自局（ＵＥ１あるいはｅＮＢ２）の他方の状態マシンにおいて下位状態への遷移を実施したが、前記他方の状態マシンにおけるヘッダ処理状態の連動遷移の条件として、前記一方の状態マシンにおける前記遷移内容と、前記他方の状態マシンにおける前記遷移前の状態とに基づき、連動遷移を実施するようにしてもよい。つまり、上記状態遷移内容及び連動遷移対象がある特定の条件を満たす場合に、連動遷移を実施するようにしてもよい。【００７３】
図７（Ａ）及び図７（Ｂ）を用いて本変形例における状態遷移制御方法の一例を説明する。図７（Ａ）は本変形例に係る圧縮器の状態マシン図であり、図７（Ｂ）は本変形例に係る伸張器の状態マシン図である。
図７（Ａ）に示すように、本変形例の通信システムでは、例えば、圧縮器１−Ａ（２−Ａ）の送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態がＳＯ状態（ＳＯ＿ｉ）であって、対向局側の伸張器からフィードバック情報として静的否定応答（ＳＴＡＴＩＣ＿ＮＡＣＫ）を受信した場合に通常遷移するのに加えて、伸張器１−Ｂ（２−Ｂ）の受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態がＦＣ状態（ＦＣ＿ｋ）からＳＣ状態（ＳＣ＿ｋ）へ通常遷移した場合に、ヘッダ圧縮処理状態をより下位のＦＯ状態（ＦＯ＿ｉ）へ連動遷移する。それ以外の場合は、上記連動遷移は実施されない。【００７４】
即ち、上述した実施形態では、圧縮器１−Ａ（２−Ａ）の送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態の遷移前の状態及び伸張器１−Ｂ（２−Ｂ）の受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態の状態遷移内容に関らず連動遷移を実施したが、本変形例では、圧縮器１−Ａ（２−Ａ）の送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態の遷移前の状態及び伸張器１−Ｂ（２−Ｂ）の受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態の状態遷移内容が所定の条件を満たす場合にのみ、連動遷移を実施する。【００７５】
同様にして、図７（Ｂ）に示すように、例えば、受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態がＳＣ状態（ＳＣ＿ｋ）であって、対向局から受信したｎ2個のパケットデータのうちｋ2個のパケットデータがヘッダ伸張処理に失敗した（所定のエラーレートを超えた）場合に通常遷移するのに加えて、送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態が、フィードバック情報（ＮＡＣＫまたはupdate）に起因してＳＯ状態（ＳＯ＿ｉ）からＦＯ状態（ＦＯ＿ｉ）へ通常遷移した場合に、ヘッダ伸張処理状態をより下位のＳＣ状態（ＳＣ＿ｋ）へ連動遷移する。それ以外の場合は、上記連動遷移は実施されない。【００７６】
本変形例における通信システムの動作例について図８を用いて説明する。
この図８に示すように、まず、パケット処理エンジン６が、圧縮器１−Ａ（２−Ａ）あるいは伸張器１−Ｂ（２−Ｂ）における或る状態Ａの下位状態遷移イベントの発生を検知する（ステップＳ１０参照）。ここで、或る状態Ａの下位状態遷移イベントとは、例えば、図７（Ｂ）に示すような、ヘッダ伸張処理状態のＦＣ状態からＳＣ状態への通常遷移などを指す。【００７７】
すると、パケット処理エンジン６によりメモリ３に格納される各種データが参照され、ステップＳ１０の状態遷移イベントを遷移条件にもつ状態マシンがあるかどうかが判定される（ステップＳ２０）。つまり、状態マシン対応データ・連動遷移条件データに、状態Ａの下位状態遷移イベントの発生を示す状態遷移内容が設定されているかどうかを判定し、設定されている場合は（ステップＳ２０のＹＥＳルート参照）、連動遷移対象に設定されている遷移対象を抽出する一方、設定されていない場合は（ステップＳ２０のＮＯルート参照）、連動遷移は行なわずに、状態Ａの下位状態遷移イベントを実行する（ステップＳ４０参照）。【００７８】
例えば、状態Ａの下位状態遷移イベントが図７（Ｂ）に示すような、ヘッダ伸張処理状態のＦＣ状態からＳＣ状態への通常遷移であるとすれば、図７（Ａ）に示すような、ヘッダ圧縮処理状態のＳＯ状態からＩＲ状態への連動遷移がパケット処理エンジン６により連動遷移対象として抽出される。
パケット処理エンジン６は、上記連動遷移対象に該当する状態マシンにおいて、現状態に関係のある連動遷移対象があるかどうかを判定し（ステップＳ２５参照）、ないと判定した場合（ステップＳ２５のＮＯルート参照）、状態Ａの下位状態遷移イベントを実行する（ステップＳ４０参照）一方、あると判定した場合（ステップＳ２５のＹＥＳルート参照）、当該連動遷移対象に設定されている遷移対象について下位状態への遷移を実施する（ステップＳ３０参照）。【００７９】
例えば、ヘッダ圧縮処理状態の現状態がＳＯ状態であるとすれば、図７（Ａ）に示すように、ＳＯ状態からＩＲ状態への連動遷移が実施される。
そして、パケット処理エンジン６は、状態Ａの下位状態遷移イベントを実行する（ステップＳ４０参照）。ここで、例えば、上記状態Ａの下位状態遷移イベントが、伸張器１−Ｂ（１−Ａ）のヘッダ伸張処理状態の下位状態遷移である場合は、当該下位状態遷移イベントの実行とともに、対向局側の圧縮器２−Ａ（１−Ａ）宛に上述のフィードバック情報が送信され、圧縮器２−Ａ（１−Ａ）においても下位状態への遷移イベントが誘発される。【００８０】
本変形例における通信システムは上述のように動作することにより、ベアラが提供する品質や圧縮方式の特性に応じて、上記状態遷移内容及び連動遷移対象を適宜変更することで、より詳細に連動遷移を実施できる。
その結果、本変形例では、上述した実施形態と同様の効果が得られるほか、上記連動遷移の実施割合を調整して、圧縮器１−Ａ（２−Ａ）でのヘッダ圧縮効率の必要以上の低下を回避することが可能となる。【００８１】
〔５〕第２変形例
上述した例では、圧縮器１−Ａ（２−Ａ）あるいは伸張器１−Ｂ（２−Ｂ）の状態マシンにおける状態遷移（通常遷移）に応じて、伸張器１−Ｂ（２−Ｂ）あるいは圧縮器１−Ａ（２−Ａ）の状態マシンにおいて連動遷移を実施したが、ＵＥ１とｅＮＢ２との間のベアラにおいて複数のパケットフロー（送信パケットフローまたは受信パケットフロー）が多重されている場合、圧縮器１−Ａ（２−Ａ）の一方の送信パケットフローに関するヘッダ圧縮処理状態の通常遷移に応じて、圧縮器１−Ａ（２−Ａ）の他方の送信パケットフローに関するヘッダ圧縮処理状態の連動遷移を行なうようにしてもよい。【００８２】
また、同様に、伸張器１−Ｂ（２−Ｂ）の一方の受信パケットフローに関するヘッダ伸張処理状態の通常遷移に応じて、伸張器１−Ｂ（２−Ｂ）の他方の受信パケットフローに関するヘッダ伸張処理状態の連動遷移を行なうようにしてもよい。
具体的には、例えば、上記状態マシン対応データ・連動遷移条件データにおいて、パケットフロー「＃ｉ」及びパケットフロー「＃ｋ」をそれぞれ送信パケットフローとしたり、または、受信パケットフローとしたりすることで実現される。【００８３】
第２変形例における通信システムはこのように動作することにより、ベアラに多重された複数のパケットフローに関する２つのヘッダ圧縮処理状態間及び２つのヘッダ伸張処理状態間においても、上述した実施形態と同様の効果を得ることができる。
〔６〕第３変形例
上述した例では、ある１つの状態マシンでの通常遷移に応じて、別の状態マシンにおいて連動遷移を実施したが、圧縮器１−Ａ（２−Ａ）あるいは伸張器１−Ｂ（２−Ｂ）の状態マシンが２以上存在する場合、これらの複数の状態マシンにおいて発生した状態遷移の数に応じて、連動遷移を実施するようにしてもよい。【００８４】
例えば、ＵＥ１とｅＮＢ２との間のベアラにおいて複数のパケットフロー（送信パケットフローまたは受信パケットフロー）が多重されている場合は、圧縮器１−Ａ（２−Ａ）あるいは伸張器１−Ｂ（２−Ｂ）の状態マシンが２以上存在することとなる。
このとき、上記複数の状態マシンにおいて所定の時間あたりに発生する下位状態への遷移イベント数[Ｎｔ（Ｎｔは自然数）]が所定の閾値｛Ｎｃ（Ｎｃは自然数）｝を超えた場合に、ＵＥ１とｅＮＢ２との間の通信環境が悪化したと判断し、他の状態マシンにおいて連動遷移を実行する。【００８５】
図９，図１０（Ａ）及び図１０（Ｂ）を用いて第３変形例における状態遷移制御方法の一例を説明する。図９は第３変形例における状態マシン対応データ・連動遷移条件データの一例を示す図である。また、図１０（Ａ）は本変形例に係る圧縮器の状態マシン図であり、図１０（Ｂ）は本変形例に係る伸張器の状態マシン図である。
この図９に示すように、第３変形例における状態マシン対応データ・連動遷移条件データには、例えば、図４に示す各種データに加えて、Ｎｔ値、閾値Ｎｃ、単位時間設定、エラーパケット数閾値ｍ、遷移発生フロー記録データ及び遷移対象（Ｆａ条件設定状態遷移リスト）が設けられる。【００８６】
そして、本変形例では、図１０（Ａ）に示すように、例えば、送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態がＳＯ状態（ＳＯ＿ｉ）である場合において、対向局側の伸張器からフィードバック情報として否定応答（ＮＡＣＫ）を受信した場合やコンテクスト情報の更新要求（update）を受信した場合に通常遷移されるのに加えて、フラグ｛Ｆａ（ｉ，Ｎｔ）｝＝１を満たす場合に、ヘッダ圧縮処理状態は、より下位のＦＯ状態（ＦＯ＿ｉ）へ連動遷移される。【００８７】
このＦａ（ｉ，Ｎｔ）は、ベアラａにおける送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態の遷移条件（フラグ）である。Ｆａ（ｉ，Ｎｔ）は、例えば、状態マシン対応データ・連動遷移条件データに格納されているＮｔ値（ここでＮｔ値は、自然数）が閾値Ｎｃ（ここでＮｃは、自然数）を超えた場合に「１」となる一方、それ以外の場合は「０」となるようにパケット処理エンジン６により管理・更新される。【００８８】
ここで、Ｎｔ値は、あるベアラａにおける複数の状態マシンで、単位時間設定データにより設定される所定の時間あたりに発生する下位状態への遷移イベント数を示すものであり、例えば、パケット処理エンジン６により管理・更新される。
つまり、本変形例では、例えば、同一ベアラ内の複数の状態マシンにおいて上記所定の時間内に発生する通常遷移イベントの発生数Ｎｔが閾値Ｎｃを超えた場合に、フラグを「１」とし、このフラグが遷移の条件に設定されている状態マシンの状態に対して連動遷移を実施するのである。【００８９】
同様に、送信パケットフロー「＃ｉ」に関するヘッダ圧縮処理状態がＦＯ状態（ＦＯ＿ｉ）である場合においては、対向局側の伸張器からフィードバック情報として静的否定応答（ＳＴＡＴＩＣ＿ＮＡＣＫ）を受信した場合に通常遷移されるのに加えて、Ｆａ（ｉ，Ｎｔ）＝１を満たす場合に、ヘッダ圧縮処理状態は、より下位のＩＲ状態（ＩＲ＿ｉ）へ連動遷移される。【００９０】
一方、図１０（Ｂ）に示すように、受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態がＦＣ状態（ＦＣ＿ｋ）である場合においては、例えば、対向局から受信したｎ1個のパケットデータのうちｋ1個のパケットデータがヘッダ伸張処理に失敗した（所定のエラーレートを超えた）場合に通常遷移されるのに加えて、Ｆａ（ｋ，Ｎｔ）＝１を満たす場合に、ヘッダ伸張処理状態は、より下位のＳＣ状態（ＳＣ＿ｋ）へ連動遷移される。【００９１】
また、同様に、受信パケットフロー「＃ｋ」に関するヘッダ伸張処理状態がＳＣ状態（ＳＣ＿ｋ）である場合においては、例えば、対向局から受信したｎ2個のパケットデータのうちｋ2個のパケットデータがヘッダ伸張処理に失敗した（所定のエラーレートを超えた）場合に通常遷移されるのに加えて、Ｆａ（ｋ，Ｎｔ）＝１を満たす場合に、ヘッダ伸張処理状態は、より下位のＮＣ状態（ＮＣ＿ｋ）へ連動遷移される。【００９２】
具体的には、例えば、閾値Ｎｃが「３」であり、既に、送信パケットフロー「＃１」，「＃３」，「＃０」の３フローにおいて、下位状態への遷移が発生しているとき、送信パケットフロー「＃２」においてＳＯ状態からＦＯ状態への通常遷移が発生したとする。
このとき、Ｎｔ＞Ｎｃとなり、フラグに「１」が設定される。そして、同一ベアラ内の上記送信パケットフロー「＃１」，「＃３」，「＃０」，「＃２」以外のパケットフローであり、且つ、上記フラグが連動遷移条件に設定されているパケットフローを検索する。本例では、受信パケットフロー「＃ｋ」が選択され、例えば、ＦＣ状態からＳＣ状態へ連動遷移される。なお、この具体例では、複数の送信パケットフローにおいて発生した状態遷移数に応じて、受信パケットフローを連動遷移させる例について説明したが、もちろん、複数の送信パケットフローにおいて発生した状態遷移数に応じて、別の送信パケットフローを連動遷移させてもよいし、また、複数の受信パケットフローにおいて発生した状態遷移数に応じて、送信パケットフローあるいは別の受信パケットフローを連動遷移させるようにしてもよい。【００９３】
本変形例におけるシステムの動作例について図１１を用いて説明する。
この図１１に示すように、まず、例えば、パケット処理エンジン６が、圧縮器１−Ａ（２−Ａ）あるいは伸張器１−Ｂ（２−Ｂ）における或る状態Ａの下位状態遷移イベントの発生を検知する（ステップＳ１００参照）。ここでは、例えば、或る状態Ａの下位状態遷移イベントが、図１０（Ａ）に示す別フローの状態マシンにおける下位状態への通常遷移であるとする。【００９４】
パケット処理エンジン６は、後述する状態遷移イベント発生数Ｎｔの観測時間として用いる、状態マシン対応データ・連動遷移条件データの単位時間設定を参照することで、所定の時間が経過したかどうかを判定する（ステップＳ１０２参照）。ここで、所定の観測時間が経過したと判定した場合は（ステップＳ１０２のＹＥＳルート参照）、パケット処理エンジン６は、後述する遷移発生フロー記録データの記録を消去するとともに、Ｎｔ値に「０」を代入する（ステップＳ１０４参照）。これにより、所定の時間毎に上記連動遷移条件（Ｎｔ値と閾値Ｎｃとの関係）を初期化して、上記連動遷移の実施割合を調整することができる。その結果、圧縮器１−Ａ（２−Ａ）でのヘッダ圧縮の圧縮効率が必要以上に低下することを回避できる。【００９５】
一方、所定の時間が経過していないと判定した場合は（ステップＳ１０２のＮＯルート参照）、パケット処理エンジン６により、ステップＳ１１０以降の処理を行なう。
パケット処理エンジン６は、メモリ３に格納される各種データを参照して、単位時間設定に基づく単位時間あたりの下位状態への通常遷移イベント発生数Ｎｔが閾値Ｎｃを超えるかどうかを判定する（ステップＳ１１０参照）。ここで、Ｎｔ＞Ｎｃでないと判定した場合は（ステップＳ１１０のＮＯルート参照）、フラグＦａ（ｉ，Ｎｔ）に「０」を設定するとともに、状態Ａの下位状態遷移イベントを実行する（ステップＳ１５０参照）。【００９６】
Ｎｔ＞Ｎｃであると判定した場合は（ステップＳ１１０のＹＥＳルート参照）、パケット処理エンジン６により、フラグＦａ（ｉ，Ｎｔ）に「１」が設定される。そして、Ｆａ条件設定状態遷移リストに予め設定されている、フラグＦａ（ｉ，Ｎｔ）を連動遷移条件にもち、且つ、当該単位時間において状態遷移が行われていない状態マシンが選択される。さらに、フラグＦａ（ｉ，Ｎｔ）を連動遷移条件にもつ状態マシンから、例えば、ラウンドロビンなどの方式により、連動遷移対象が選択される（ステップＳ１２０参照）。【００９７】
例えば、図１０（Ａ）に示すように、送信パケットフロー「＃ｉ」の状態マシンが選択される。
そして、パケット処理エンジン６は、ステップＳ１２０にて選択した状態マシンにおいて、現在の状態を下位状態へ連動遷移させる（ステップＳ１３０参照）。
例えば、図１０（Ａ）に示すように、連動遷移条件｛Ｆａ（ｉ，Ｎｔ）｝に基づき、ＳＯ状態からＦＯ状態への連動遷移、あるいは、ＦＯ状態からＩＲ状態への連動遷移が実施される。【００９８】
パケット処理エンジン６は、上記ステップＳ１３０にて連動遷移させた後の状態及び状態Ａがより下位状態へ遷移することを遷移発生フロー記録データに記録し、ステップＳ１００のイベント発生をカウントするため、Ｎｔ値を１インクリメントする（ステップＳ１４０参照）。
そして、パケット処理エンジン６は、状態Ａの下位状態遷移イベントを実行する（ステップＳ１５０参照）。【００９９】
本変形例における通信システムは上述のように動作することにより、圧縮器１−Ａ（２−Ａ）あるいは伸張器１−Ｂ（２−Ｂ）の状態マシンが２以上存在する場合においても、上記実施形態及び各変形例と同様の効果を得ることができる。
〔７〕第４変形例
また、上述した例の連動遷移条件に加えて、ＲｏＨＣプロトコルで規定された遷移判定パラメータ値（エラーパケット数）を併用するようにしてもよい。【０１００】
例えば、上記第３変形例で説明した方法で選択された連動遷移対象について、伸張器１−Ｂ（２−Ｂ）で検出されるエラーパケット数ｋ1（ｋ2）が、エラーパケット数閾値ｍ（ｍは自然数）以上である場合に当該連動遷移を実施する一方、そうでない場合は当該連動遷移を実施しないようにすることもできる。
本変形例におけるシステムの動作例について図１２を用いて説明する。【０１０１】
この図１２に示すように、ステップＳ２００，Ｓ２０２，Ｓ２０４，Ｓ２１０，Ｓ２２０及びステップＳ２４０〜ステップＳ２６０については、前述したステップＳ１００，Ｓ１０２，Ｓ１０４，Ｓ１１０，Ｓ１２０及びステップＳ１３０〜ステップＳ１５０と同様である。
本変形例では、ステップＳ２２０において選択された状態マシンについて、パケット処理エンジン６により、エラーパケット数ｋ1（ｋ2）が、状態マシン対応データ・連動遷移条件データに設定されているエラーパケット数閾値ｍ以上であるかどうかが判定される（ステップＳ２３０参照）。【０１０２】
そして、エラーパケット数ｋ1（ｋ2）が閾値ｍ以上であると判定された場合（ステップＳ２３０のＹＥＳルート参照）、ステップＳ２４０にて当該状態マシンにおいて連動遷移を実施する一方、エラーパケット数ｋ1（ｋ2）が閾値ｍ以上でないと判定された場合は（ステップＳ２３０のＮＯルート参照）、ステップＳ２２０で選択された状態マシンにおいて連動遷移を実施せずに、再び、ステップＳ２２０を実施し、当該単位時間に未遷移で、「Ｎｔ＞Ｎｃ」を遷移条件にもち、エラーパケット数がステップＳ２３０の条件を満たす状態マシンを検索する。【０１０３】
なお、ここでは、具体例として、上記第３変形例で説明した方法に対して、本変形例に係るエラーパケット数に応じた連動遷移制御を適用した場合を説明したが、もちろん、上述した実施形態及び各変形例についても同様に本変形例に係る連動遷移制御を適用して実施するようにしてもよい。
例えば、いずれの実施形態及び変形例においても、連動遷移対象として選択されたパケットフローについて、上記エラーパケット数に応じた連動制御可否の判断を行なうことができる。【０１０４】
本変形例における通信システムは上述のように動作することにより、上述した実施形態及び各変形例と同様の効果が得られるほか、連動遷移の実施割合についてさらに詳細に調整することができる。その結果、圧縮器１−Ａ（２−Ａ）でのヘッダ圧縮効率の必要以上の低下を回避することが可能となる。
〔８〕その他
上述した例では、主に、下位状態への遷移について説明したが、もちろん上位状態への遷移についても同様に連動遷移制御を実施することができる。【０１０５】
また、上述した例では、ヘッダ圧縮処理及びヘッダ伸張処理の一例としてＲｏＨＣを適用した場合を説明したが、本発明は、これに限らず一般的なヘッダ圧縮伸張技術についても適用することができる。
さらに、上述した例では、対向局側からのフィードバック情報に応じた遷移制御を本発明と併用する場合を説明したが、本発明は、前記フィードバック情報に応じた遷移制御を行なわずに実施することもできる。【０１０６】
また、上述した例では、例えば３ＧＰＰの移動通信システムの構成要素（エンティティ）であるＵＥ１及びｅＮＢ２にて連動遷移制御を実施する場合について説明したが、パケットヘッダ圧縮復元を行なう、その他のエンティティにて連動遷移制御を実施することも可能である。
【図１】
2009072175.tif 000003
【図２】
2009072175.tif 000004
【図３】
2009072175.tif 000005
【図４】
2009072175.tif 000006
【図５】
2009072175.tif 000007
【図６】
2009072175.tif 000008
【図７】
2009072175.tif 000009
【図８】
2009072175.tif 000010
【図９】
2009072175.tif 000011
【図１０】
2009072175.tif 000012
【図１１】
2009072175.tif 000013
【図１２】
2009072175.tif 000014
【図１３】
2009072175.tif 000015
【図１４】
2009072175.tif 000016
【図１５】
2009072175.tif 000017
【図１６】
2009072175.tif 000018
【図１７】
2009072175.tif 000019
【国際調査報告】
2009072175.tif 000020
2009072175.tif 000021
2009072175.tif 000022
2009072175.tif 000023