(57)【要約】  本発明は、分散局のネットワークでデータ圧縮を利用する問題に関する。しばしば、ヘッダ圧縮は、ネットワーク（特に無線ネットワーク）の帯域利用を改善するために使用される。ヘッダ圧縮は、アクセスポイント又はルータに実装され得るが、例えば、限られたCPUパワーのため、スケーラビリティの欠如のため、又はハンドオーバ待ち時間のため、双方の実装が重要な問題を有する。問題を解決するために、本発明は、ネットワークにおける専用データ圧縮サーバと、ネットワークでトランスペアレントにデータ圧縮を展開する新しいプロトコルとを使用することを提案する。
2009520420.tif 000002
【特許請求の範囲】
【請求項１】
分散局のネットワークでデータパケットを交換する方法であって、
前記局の一部は、データパケットを交換するためにデータ圧縮を使用可能であり、他の部分は使用不可能であり、
１つ以上のデータ圧縮サーバが前記ネットワークに追加され、
前記１つ以上のデータ圧縮サーバは、転送パスの一部でデータ圧縮可能な局から不可能な局に／不可能な局からデータ圧縮可能な局に送信するためにデータ圧縮を利用することをサポートすることを特徴とする方法。
【請求項２】
前記圧縮サーバは、非圧縮形式で前記圧縮不可能な局からデータパケットを受信し、前記データパケットを圧縮し、圧縮形式で前記圧縮可能な局に前記データパケットを送信する、請求項１に記載の方法。
【請求項３】
前記圧縮サーバは、圧縮形式で前記圧縮可能な局からデータパケットを受信し、前記データパケットを伸張し、非圧縮形式で前記圧縮不可能な局に前記データパケットを送信する、請求項１又は２に記載の方法。
【請求項４】
圧縮可能な局は、登録処理で前記圧縮サーバに登録する、請求項１ないし３のうちいずれか１項に記載の方法。
【請求項５】
前記圧縮可能な局は、前記登録処理の登録メッセージに圧縮機能を記載する、請求項４に記載の方法。
【請求項６】
前記圧縮サーバは、前記圧縮可能な局から前記登録メッセージを受信した後に、肯定応答メッセージに圧縮機能を記載する、請求項５に記載の方法。
【請求項７】
前記圧縮可能な局は、圧縮アルゴリズムを選択し、どの圧縮アルゴリズムがデータ圧縮に選択されたかについての情報を有する肯定応答メッセージを前記圧縮サーバに返信する、請求項６に記載の方法。
【請求項８】
前記圧縮可能な局は、前記登録処理の後に、プロトコルスタックのフィルタモジュールを起動し、
前記フィルタモジュールは、前記フィルタモジュールの上のプロトコルレイヤから生じた他のネットワーク局からの前記圧縮可能な局の宛先アドレスについての要求に対する応答パケットをブロックする、請求項４ないし７のうちいずれか１項に記載の方法。
【請求項９】
前記ネットワーク局の前記宛先アドレスについての要求とその応答とについて、アドレス解決プロトコル（ARP）が使用される、請求項８に記載の方法。
【請求項１０】
前記圧縮サーバは、前記要求が圧縮不可能な局から生じた場合に、前記圧縮サーバのアドレスで、前記圧縮可能な局の前記宛先アドレスについての前記要求に対して応答パケットを送信する、請求項８又は９に記載の方法。
【請求項１１】
前記圧縮可能な局自体が、他の局の宛先アドレスについての要求を生成する場合、前記フィルタモジュールは、前記要求を前記圧縮サーバへのクエリに変換し、
前記要求が圧縮不可能な局に向けられた場合、前記圧縮サーバは、前記圧縮サーバ自体の宛先アドレスを返信し、
前記要求が圧縮可能な局に向けられた場合、前記圧縮サーバは、他の局の宛先アドレスを返信し、
前記フィルタモジュールは、前記圧縮サーバの宛先アドレス又は前記他のサーバの宛先アドレスで、前記フィルタモジュールの上のプロトコルレイヤへの応答を生成する、請求項８ないし１０のうちいずれか１項に記載の方法。
【請求項１２】
他のネットワーク局の宛先アドレスへの要求及び応答は、アドレス解決プロトコル（ARP）によるメッセージに対応する、請求項８ないし１１のうちいずれか１項に記載の方法。
【請求項１３】
局は、前記圧縮サーバに活動メッセージを定期的に送信し、
局からの活動メッセージが特定の期間だけ遅れた場合に、前記圧縮サーバは、前記移動局に割り当てられたリソースを開放する、請求項１ないし１２のうちいずれか１項に記載の方法。
【請求項１４】
前記ネットワークは、インターネットプロトコル（IP）ネットワークであり、
局が前記ネットワークに入り、動的ホスト構成プロトコル（DHCP）を使用してIPアドレスを取得する場合、DHCPサーバは、DHCPOFFERメッセージの任意選択フィールドに前記圧縮サーバのIPアドレスを含めて、IPアドレスの提供を前記局に送信する、請求項１ないし１３のうちいずれか１項に記載の方法。
【請求項１５】
前記データ圧縮は、前記データパケットのヘッダ圧縮に関する、請求項１ないし１４のうちいずれか１項に記載の方法。
【請求項１６】
前記ヘッダ圧縮アルゴリズムは、“Van  Jacobsonヘッダ圧縮（VJHC）”又は“ロバストヘッダ圧縮（ROHC）”に対応する、請求項１５に記載の方法。
【請求項１７】
請求項１ないし１６のうちいずれか１項に記載の方法で使用される圧縮サーバであって、
アドレス情報に関する要求メッセージ及び応答メッセージを生成することを含み、他のネットワーク局から及び他のネットワークへの制御通信を処理することを担う別のコントローラユニットを有することを特徴とする圧縮サーバ。
【請求項１８】
圧縮アルゴリズム毎に実装された別の圧縮ユニットを有する、請求項１７に記載の圧縮サーバ。
【請求項１９】
各ユニットは、別のサーバ装置に配置される、請求項１７又は１８に記載の圧縮サーバ。
【請求項２０】
全てのユニットは、単一のサーバ装置に配置される、請求項１７ないし１９のうちいずれか１項に記載の圧縮サーバ。
【請求項２１】
請求項１ないし１６のうちいずれか１項に記載の方法で使用されるネットワーク局であって、
前記局は、データパケットを交換するためにヘッダ圧縮を使用可能であり、
前記局は、プロトコルスタックの一部としてフィルタモジュールを有し、
前記フィルタモジュールは、前記フィルタモジュールの上のプロトコルレイヤから生じた他のネットワーク局からの圧縮可能な局の宛先アドレスについての要求に対する応答パケットをブロックするネットワーク局。
【請求項２２】
前記フィルタモジュールは、前記圧縮可能な局自体が前記要求を生成した場合、他の局の宛先アドレスについての前記要求を、前記圧縮サーバへのクエリに変換する手段を有し、
前記フィルタモジュールは、前記フィルタモジュールがどの宛先アドレスを前記圧縮サーバから受信したかに応じて、前記圧縮サーバの宛先アドレス又は他の局の宛先アドレスで前記フィルタモジュールの上のプロトコルレイヤへの応答を生成する手段を有する、請求項２１に記載のネットワーク局。
【請求項２３】
前記フィルタモジュールは、圧縮サーバへの前記ネットワーク局の登録の後にプロトコルスタックで起動され、前記局が前記圧縮サーバから登録解除した後に停止される、請求項２１又は２２に記載のネットワーク局。
【請求項２４】
請求項１ないし１６のうちいずれか１項に記載の方法で使用されるDHCPサーバであって、
前記ネットワークに入る局からDHCPDISCOVERメッセージを受信したときに、DHCPOFFERメッセージの任意選択フィールドに圧縮サーバのIPアドレスを含めて、IPアドレスの提供を局に送信するように適合されるDHCPサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク通信（特に、コンピュータネットワーク及びホームネットワーク）の分野に関する。特に、本発明は、ネットワーク通信にデータ圧縮を利用することに関する。
【背景技術】
【０００２】
VJHCアルゴリズムとも呼ばれ、RFC1144に記載されているVan  Jacobsonにより生成されたヘッダ圧縮技術が確立されており、無線ローカルエリアネットワーク（WLAN）で帯域利用を改善するために使用される。これは、低速シリアルリンクでTCP/IP（Transmission  Control  Protocol/Internet  Protocol）性能を改善するために特に設計されたデータ圧縮プロトコルである。ヘッダ圧縮技術は、平均的な場合に、通常の40バイトのTCP/IPパケットヘッダを3〜4バイトに低減する。これは、リンクの双方の端点でTCP接続の状態を保存し、変化するヘッダフィールドの差のみを送信することにより、上記のことを行う。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
WLANでは、ヘッダ圧縮は、アクセスポイント（AP）又はルータに実装され得る。これらの実装の双方が異なる問題に直面する。
【０００４】
1.既存のネットワークのAP及びルータは、異なる製造者から生じることがある。これらは、異なるオペレーティングシステムプラットフォーム（OS）に基づき、通常では非常に限られたCPU性能を有するため、ヘッダ圧縮を実装することが困難になることがある。
【０００５】
2.スケーラビリティの欠如。限られたCPUパワーのため、WLANでサポートされるヘッダ圧縮可能な移動局の数が非常に限られ、複数のヘッダ圧縮プロトコルが同じネットワークで同時に展開できない。
【０００６】
3.ヘッダ圧縮がAPに実装される場合、移動局がAPのグループの間を移動しているときに、コンテキスト転送（context  transfer）が必要になる。これは長いハンドオーバ待ち時間を生じ得る。
【課題を解決するための手段】
【０００７】
これらの全ての問題を解決するため、本発明は、ネットワークにデータ圧縮サーバを追加することを提案する。局の一部は、データパケットを交換するためにデータ圧縮を使用可能であり、他の部分は使用不可能である。データ圧縮サーバは、転送パスの一部でデータ圧縮可能な局から不可能な局に／不可能な局からデータ圧縮可能な局に送信するためにデータ圧縮を利用することをサポートする。このことは、ネットワークの全体のデータ伝送容量が主観的に増加するという利点を有する。
【０００８】
更に、本発明は、ネットワーク（例えばWLAN）でトランスペアレントにヘッダ圧縮を展開するために、THCDP（Transparent  Header Compression Deployment Protocol)と呼ばれる新しい種類のプロトコルとヘッダ圧縮装置とを開示する。この機構は、既存のネットワーク装置に小規模の変更のみを必要とし、既存のサービスに影響を及ぼさない。また、移動中の移動局のハンドオーバ待ち時間を延ばさず、良好なスケーラビリティを有する。
【０００９】
ヘッダ圧縮のトランスペアレントな展開を実現するために、２つの種類の装置がネットワークに追加される。一方はHCC（Header  Compression  Controller）であり、他方は、HCS（Header  Compression  Server）である。HCCは、トラヒックがHCSにより傍受され得るように、ヘッダ圧縮可能な移動局のARPクエリ（Address  Resolution  Protocol）への応答を担う。HCSは、パケットのヘッダ圧縮／伸張を行い、これらを実際の宛先に転送する。また、送信パケットがヘッダ圧縮を実行するためにHCSに転送され得るように、出力ARPフィルタモジュールが、ヘッダ圧縮可能な移動局のプロトコルスタックに挿入される。効率を改善するために、同じヘッダ圧縮プロトコルをサポートする２つのノードの間の通信は、HCSにより仲裁されず、相互に直接通信する。
【００１０】
このアーキテクチャはまた、良好なスケーラビリティを有する。HCCの調整を通じて、異なるヘッダ圧縮プロトコルが、複数のHCSを使用することにより同じネットワークで同時に適用可能になる。また、負荷の平衡を保つため、１つのヘッダ圧縮プロトコルに複数のHCSが存在してもよい。HCC及びHCSは、異なるサーバに存在してもよく、ちょうど１つの物理サーバに存在してもよい。
【発明の効果】
【００１１】
1.既存のネットワーク装置を変更せず、LANでヘッダ圧縮のトランスペアレントな展開ができる。
【００１２】
2.移動局のハンドオーバ待ち時間を延ばさない。
【００１３】
3.ヘッダ圧縮可能な移動局は、同じネットワークでヘッダ圧縮のない移動局と共存することができる。
【００１４】
4.良好なスケーラビリティが可能になる。より多くのヘッダ圧縮プロトコル及びより多くのヘッダ圧縮可能な移動局が、単にネットワークに更なるHCSを追加することによりサポート可能になる。
【００１５】
本発明はまた、独立請求項17に記載の圧縮サーバと、独立請求項20に記載のネットワーク局と、請求項23に記載のDHCPサーバとに関する。本発明の更なる有利な実施例は、それぞれの従属項から明らかになる。
【発明を実施するための最良の形態】
【００１６】
本発明の実施例が図面に示されており、以下で説明する。
【００１７】
THCDPプロトコルの動作について、２つの例で説明する。図１及び２は、THCDPヘッダ圧縮をサポートする簡単であるが典型的なLAN環境を示している。図１は、HC可能な携帯情報端末STA1（以下ではPDA  STA1と呼ばれる）と通常のHC不可能な遠隔パーソナルコンピュータPC1との間の通信シナリオを示している。図２は、２つのHC可能な装置（PDA  STA1及びラップトップSTA2）の間の通信シナリオを示している。
【００１８】
PDA  STA1及びラップトップSTA2は、２つのアクセスポイントAP1及びAP2を通じてローカルエリアネットワークLANに接続された２つの移動局であり、異なる製造者から生じてもよい。PDA  STA1は、HC可能なPDA電話であり、STA2は、HC可能なラップトップである。これらの双方は、ロバストヘッダ圧縮プロトコル（ROHC：robust  header  compression  protocol）をサポートする。ROHCプロトコルはRFC3095に記載されている。PC1は、インターネットを介してLANに接続された遠隔PCであり、PC2は、LAN内のローカルPCである。双方のコンピュータPC1及びPC2は、PDA  STA1と通信してもよい。R1は、全体LANのデフォルトルータである。S0はDHCPサーバであり、S1、S2及びS3は、ヘッダ圧縮及び伸張に使用されるサーバである。簡潔にするため、これらは別々のサーバとして図示されているが、物理ネットワークではこれらは単なる論理エンティティでもよく、同じ物理サーバに存在してもよい。サーバS1は、ヘッダ圧縮コントローラHCCと呼ばれ、HCCは、サーバS2及びS3の動作を調整する。S2及びS3は、ヘッダ圧縮サーバHCSである。サーバS1は、ROHC圧縮アルゴリズムを実装するが、サーバS2は、VJHCアルゴリズムを実装する。サーバS2及びS3は、HCC  S1に登録し、自分のヘッダ圧縮機能について通知する。
【００１９】
HC可能な移動局PDA  STA1がWLAN内に移動し、アクセスポイントAP1に関連付けた（アソシエーションした）後に、DHCPサーバS0からネットワーク構成を取得する。次に、登録メッセージを通じて、HCC  S1とヘッダ圧縮機能をネゴシエーションする。登録が成功した後に、HCC  S1は、PDA  STA1のARP応答を引き継ぎ、これにより、PDA  STA1の何らかのARPクエリは、選択されたHCS（例えばS2）のMACアドレス又は元のPDA  STA1のMACアドレスで、HCC  S1により応答される。これは、ARPクエリがPDA  STA1と同じヘッダ圧縮プロトコルをサポートするノードからのものであるか否かに依存する。そうである場合（例えば、ARPクエリがラップトップSTA2からのものであり、ラップトップSTA2もPDA  STA1と同様にROHCヘッダ圧縮をサポートする場合）、HCC  S1は、PDA  STA1の元のMACアドレスでARPクエリに応答する。これにより、ラップトップSTA2とPDA  STA1とが直接の通信を行うことが可能になる。そうでない場合（例えば、ARPクエリが遠隔PC1からルーティングされたパケットについてルータR1からのものである場合）、HCC  S1は、選択されたHCSサーバのMACアドレス（例えばS2サーバのMAC）でクエリに応答する。これにより、サーバS2は、パケットを傍受し、パケットでヘッダ圧縮を実行することができる。
【００２０】
他方、HCCサーバS1に登録が成功した後に、出力ARPパケットのフィルタは、PDA  STA1のオペレーティングシステムのプロトコルスタックに接続される。これにより、全てのARPクエリ及びARP応答が傍受される。全てのARP応答は破棄され、何らかのARPクエリがPDA  STA1からHCC  S1に送信されるTHCDPピア・ツー・ピアARPクエリを起動する。
【００２１】
図１の点線は、PDA  STA1とPC1との間の通信のトラヒックパスを示している。このシナリオでは、S2は全てのパケットを傍受し、PDA  STA1へ／からのパケットのヘッダ圧縮／伸張を実行する。
【００２２】
図２の点線は、PDA  STA1とラップトップSTA2との間の通信のトラヒックパスを示している。このシナリオでは、２つの局の双方がROHCヘッダ圧縮プロトコルをサポートするため、相互に直接通信する。
【００２３】
前述のように、ネットワークに２つの種類のヘッダ圧縮装置（HCS（Header  Compression  Server）及びHCC（Header  Compression  Controller））が存在する。HCSは、ヘッダ圧縮プロトコルを実装するサーバである。HCCは、HCSの動作を調整し、移動局からの登録／登録解除メッセージを処理し、また、これらの登録された移動局のARP要求に応答する。
【００２４】
ヘッダ圧縮のトランスペアレントな実装を実現するために、HCCサーバS1は、HC不可能な局からHC可能な移動局へのARPクエリへの応答を担う。これらの局は自分でARPクエリに応答しない。これにより、これらの移動局宛のパケットは、ヘッダを圧縮するためにHCSサーバS1、S2に転送され得る。
【００２５】
効率を改善するために、同じヘッダ圧縮プロトコルをサポートする２つのノードの間の通信は、HCSにより傍受されず、相互に直接通信することを可能にする。
【００２６】
次のセクションは、THCDPのメッセージ相互作用を説明する。各種類のTHCDPメッセージに使用される固有の識別番号が存在する。同じID番号を有するメッセージは、同じメッセージフォーマットを共有するが、その使用は、特定のシナリオに従って変わる。
【００２７】
＜移動局とHCCサーバとの間の相互作用＞
移動局の観点から、THCDPプロトコルの主なステップは、
HCCのアドレスの取得
HCCへの登録
他のノードとの通信
HCCからの登録解除
を有する。
【００２８】
i)HCCのアドレスの取得
移動局がWLANに入ると、DHCPプロトコルを通じてそのIP構成を取得する。DHCPプロトコルは、構成情報をTCP/IPネットワークのホストに渡すフレームワークを提供する。構成パラメータ及び他の制御情報は、DCHPメッセージの“任意選択”フィールドに格納されるタグ付データ項目で伝達される。THCDPプロトコルでHCCのIPアドレスを自動的に構成するために、新しい任意選択フィールド“HCCAddr”がDHCPOFFERメッセージに追加され、HCCのIPアドレスを移動局に転送する。これが図３に示されている。
【００２９】
ii)HCCへの登録
登録処理が図４に示されている。移動局がHCCサーバS1のIPアドレスを取得し、移動局がヘッダ圧縮をサポートすると、サポートされるHCアルゴリズムのリストを含む登録メッセージをHCC  S1に送信する。この処理中にユーザ認証は存在しない。この理由は、ユーザ認証は（例えば、IEEE802.1x又は他の機構を通じて）WLANアクセス制御で行われていることが当然であると考えるためである。これは必須ではなく、セキュリティの理由で、更なる認証が必要に応じて追加されてもよい。
【００３０】
THCDPは、テキスト型メッセージフォーマット及びUTF-8（8-bit  Unicode  Transformation  Format）エンコードを使用し、メッセージは、TCP接続を通じて伝送される。UTF-8はRFC3629に示されている。
【００３１】
全てのメッセージは、RFC2822の基本フォーマットを使用する。メッセージは、スタートラインと、１つ以上のヘッダフィールドと、ヘッダフィールドの終わりを示すエンプティラインと、任意選択のメッセージ本文とを有する。
【００３２】
THCDPメッセージ=メッセージ形式ライン
*メッセージヘッダ
CRLF
{メッセージ本文}
メッセージ形式ライン= THCDP/V1.0  メッセージ形式
メッセージ形式ライン、各メッセージヘッダライン及びエンプティラインは、CRLF（carriage-return  line-feed  sequence）により終端されなければならない。メッセージ本文が存在しなくても、エンプティラインは存在しなければならない。
【００３３】
登録メッセージの詳細情報
登録メッセージ
メッセージID：1
説明：登録メッセージは、将来の通信で使用されるヘッダ圧縮プロトコルとHCプロトコルのパラメータとをネゴシエーションするために移動局により使用される。また、HCCにヘッダ圧縮機能を登録するためにHCSサーバにより使用されてもよい。
【００３４】
このメッセージは本文を有し、本文は、利用可能なヘッダ圧縮プロトコルの１つ以上の説明を含む。
【００３５】
フォーマット：
【表１】
2009520420.tif 000003
ここで、“From”フィールドの値は、このメッセージのIPアドレスの発信元IPを示し、メッセージヘッダの“MessageType”フィールドの値は、HCS_REG又はSTA_REGになり得る。これは、登録メッセージがHCSサーバ又は移動局からのものであることを意味する。
【００３６】
メッセージの本文は、１つ以上のヘッダ圧縮プロトコルの説明を有し、ヘッダ圧縮プロトコルの説明のフォーマットは以下のようになる。
名前：プロトコル名
パラメータ：*<para_name=value;>
移動局から登録メッセージを受信した後に、HCCサーバS1は、サポートされるヘッダ圧縮プロトコルのリストと共に、ACK（肯定応答）パケットを移動局に送信する。他方、全ての利用可能なHCSサーバS1、S2が、これらの最大許容可能クライアント数に到達すると、HCCは、移動局にNACK（否定応答）パケットを送信し、ヘッダ圧縮要求を拒否してもよい。要求されたヘッダ圧縮プロトコルの全てがいずれのHCSサーバS1、S2によりサポートされていないことをHCCが見つけたときに、同じことが行われてもよい。
【００３７】
移動局は、HCCからNACKを受信したときに、ヘッダ圧縮パケットを送信しない。他方、HCCからACKを受信したときに、移動局は、１つのヘッダ圧縮プロトコルを選択し、ACKをHCCに送信する（他の希な状況でNACKを送信してもよい）。
【００３８】
ACKメッセージの詳細情報
ACKメッセージ
メッセージID：2
説明：ACKメッセージは、使用されるヘッダ圧縮プロトコルとヘッダ圧縮パラメータとのネゴシエーションの間に移動局又はHCCにより使用される。この種類のメッセージはまた、メッセージ本文を有し、メッセージ本文は、ヘッダ圧縮プロトコルへの説明を有する。
【００３９】
フォーマット：
【表２】
2009520420.tif 000004
NACKメッセージの詳細情報
NACKメッセージ
メッセージID：3
説明：NACKメッセージは、登録ネゴシエーションの間に移動局及びHCCにより使用される。
【００４０】
フォーマット：
【表３】
2009520420.tif 000005
ここで、“Reason”フィールドの値は、なぜ要求が拒否されたかの理由を提供する。これは通常の文字列である。
【００４１】
登録処理の成功の後に、移動局及びHCCは、どのヘッダ圧縮プロトコルを使用するかと、このプロトコルのグローバルなパラメータとについて合意に達する。HCCに登録が成功した後に、移動局は、以下の動作を実行する。
・出力ARPパケットフィルタモジュール30をオペレーティングシステムのプロトコルスタックに接続する。これが図５に示されている。このモジュールは、移動局のOS  ARPモジュール20からの全ての出力ARP応答パケットを破棄する。OS  ARPモジュール20から出力ARPクエリパケットが受信され、クエリがHCCのMACアドレスについてである場合、このモジュールは、単にARP応答を構成し、HCCの実際のMACアドレスについてOS  ARPモジュール20に通知する。そうでない場合、カスタマイズされたピア・ツー・ピアARPクエリ（THCDP  ARPクエリと呼ばれる）をHCCに送信し、HCCは、THCDP  ARP応答を送信する。HCCから応答を受信した後に、移動局は、通常のARP応答パケットを構成し、これをOS  ARPモジュール20に配信する。
・ヘッダ圧縮を有効にする。
【００４２】
THCDP  ARPクエリメッセージの詳細情報
THCDP  ARPクエリメッセージ
メッセージID：4
説明：THCDP  ARPクエリメッセージは、HC可能な移動局からHCCに送信され、他のノードのMACアドレスを問い合わせるためにHC可能な移動局により使用される。
【００４３】
フォーマット：
【表４】
2009520420.tif 000006
ここで、“QueryIP”フィールドは、このARPクエリが起動されるIPアドレスを示す。
【００４４】
移動局が登録した後に、HCCは以下の動作を実行する。
・登録された移動局をプロキシARPリストに追加する。これにより、この移動局のプロキシARP応答を生成することが可能になる。
・THCDP  ARPクエリメッセージがこの登録された移動局から受信されると、以下の状況に従ってTHCDP  ARP応答を生成する。
【００４５】
・THCDP  ARPクエリメッセージが、この問い合わせ中の局と同じヘッダ圧縮プロトコルをサポートする他の移動局のMACアドレスを問い合わせている場合、HCCは、問い合わされた局の実際のMACアドレスを返信する。
【００４６】
・THCDP  ARPクエリメッセージが、問い合わされたヘッダ圧縮を実行することができない他の局についてのものである場合、HCCは、その機能を有する適切なHCSサーバのMACアドレスを問い合わせ中の局に返信する。
【００４７】
THCDP  ARP応答メッセージの詳細情報
THCDP  ARP応答メッセージ
メッセージID：5
説明：THCDP  ARP応答メッセージは、HCCからHC可能な移動局に送信され、他のノードのMACアドレスについてHC可能な移動局に通知するために使用される。
【００４８】
フォーマット：
【表５】
2009520420.tif 000007
ここで、“MAC”フィールドの値は、“QueryIP”フィールドで示されたIPアドレスのMACアドレスである。
【００４９】
＜他のノードとの通信＞
登録の後に、HC可能な局は、ヘッダ圧縮されたIPパケットを通じて他のノードと通信することができる。
【００５０】
図６及び７は、HC可能な移動局STA1と他の通常のノードPC2との間の通信の状況を示している。このシナリオでは、２つのノードは、HCSサーバS2を通じて相互に通信する。図６は、PC  PC2が通信を初期化するときのメッセージ相互作用を示している。この場合、PCは、非圧縮のIPパケットをHCS  S2に送信する。HCS  S2は、これらのパケットを圧縮形式でPDA  STA1に転送する。逆方向では、PDA  STA1は、そのパケットを圧縮形式でHCS  S2に送信する。HCS  S2は、伸張を実行し、これらを非圧縮形式でPCに転送する。図７は、PC2からのブロードキャストARPクエリへの応答メッセージ（図６参照）がPDA  STA1の出力ARPフィルタモジュール30でブロックされることを示している。更に、PDA  STA1のOS  ARPモジュール20で生成されたPC2へのARPクエリは、出力ARPフィルタモジュール30で傍受され、PC2へのTHCDP  ARPクエリに変換される。THCDP  ARP応答メッセージは、出力ARPフィルタモジュール30で受信され、HCSサーバS2の発信元アドレスを有するARP応答メッセージに変換される。この応答メッセージはOS  ARPモジュール20に転送される。IPパケットを通じた通信は、図６のようになる。
【００５１】
図８は、２つのHC可能な移動局STA1及びSTA2の間の通信を示している。これらのノードの双方がROHCをサポートすることを仮定すると、圧縮形式で相互に通信することができる。この状況で、どのノードが通信を開始するかに拘らず、メッセージ相互作用はほぼ同じになる。図８は、PDA  STA1が通信を初期化するときのシナリオを示している。
【００５２】
＜HCCからの登録解除＞
移動局がもはやヘッダ圧縮を必要としない場合（例えば、ヘッダ圧縮モジュールが無効になった場合）、ヘッダ圧縮コントローラS1に登録解除メッセージを送信し、リソースを開放するように通知するべきである（図９参照）。この後に、HCCは、この移動局のARPクエリに応答することを中止し、移動局は、そのARPテーブルの全てのエントリを無効にする。これにより、この後に、通常のARPプロトコルに従って宛先ノードの実際のMACアドレスを取得することができ、その後に、宛先にパケットを直接送信することができる。
【００５３】
登録解除メッセージの詳細情報
登録解除メッセージ
メッセージID：6
説明：登録解除メッセージは、登録解除のために、HC可能な移動局又はHCSからHCCに送信される。
【００５４】
フォーマット：
【表６】
2009520420.tif 000008
＜ハートビート（heartbeat）メッセージ＞
移動局が突然にクラッシュしたときにできるだけ早くリソースを開放するために、THCDPプロトコルは、ハートビートメッセージをHCCに定期的に送信することにより、移動局から活動を報告することを求める。所定の時間にハートビートメッセージが存在しない場合、HCCは、移動局がクラッシュしたこと又は現在のネットワークから離れたことと考え、登録解除メッセージを受信したときのように、この移動局に関する全てのリソースを開放する。
【００５５】
ACKメッセージの詳細情報
ハートビートメッセージ
メッセージID：7
説明：ハートビートメッセージは、活動を通知するために、HC可能な移動局又はHCSからHCCに送信される。
【００５６】
フォーマット：
【表７】
2009520420.tif 000009
＜HCCとHCSとの間の相互作用＞
移動局とHCSとの間の相互作用の他に、HCSはまた、その存在とヘッダ圧縮機能とについてHCCに報告する必要がある。これにより、HCCは、登録要求を移動局から適切なHCSに転送することができる。これは、図１１に示すように、登録、登録解除及び定期的なハートビートメッセージを通じて行われる。
【００５７】
本発明は、ネットワークでのヘッダ圧縮の使用に限定されない。本発明は、一般的に帯域最適化のためにネットワークでデータ圧縮を利用することに関する。
【００５８】
【表８】
2009520420.tif 000010
【図面の簡単な説明】
【００５９】
【図１】HC可能な局とHC未対応のPCとの間の通信
【図２】２つのHC可能な局の間の通信
【図３】HCサーバアドレスの取得のためのメッセージ交換
【図４】登録処理
【図５】プロトコルスタックにおける出力ARPフィルタモジュールの位置
【図６】HC不可能なノードがHC可能なノードとの通信を初期化する場合のメッセージ交換
【図７】HC可能な局が他の通常なノードとの通信を初期化する場合のメッセージ交換
【図８】２つのHC可能なノードの間のメッセージ交換
【図９】登録解除処理
【図１０】ハートビートメッセージ
【図１１】HCCとHCSとの間のメッセージ相互作用
【図１】
2009520420.tif 000011
【図２】
2009520420.tif 000012
【図３】
2009520420.tif 000013
【図４】
2009520420.tif 000014
【図５】
2009520420.tif 000015
【図６】
2009520420.tif 000016
【図７】
2009520420.tif 000017
【図８】
2009520420.tif 000018
【図９】
2009520420.tif 000019
【図１０】
2009520420.tif 000020
【図１１】
2009520420.tif 000021
【国際調査報告】
2009520420.tif 000022
2009520420.tif 000023
2009520420.tif 000024