(57)【要約】【課題】モバイルハンドオフのための動的パケットバッファリングシステム【解決手段】本発明は、モバイルがそこから遠ざかりつつあり、又はそこに向かいつつあるネットワークのエッジの近くにあるアクセスルータ又はネットワークノードにおける、移動ノードのためのパケットのバッファリング使用に関するものである。この際、一時記憶パケットは、ハンドオフプロセスが完了した後で、移動ノードに転送される。また、本発明は、ハンドオフプロセス時に移動ノードから発信されるパケットのバッファリング使用にも関するものである。この際、一時記憶パケットは、ハンドオフプロセスが完了した後で、これらの目的の宛先に転送される。バッファリングシステムは、既存のモビリティプロトコル、アクセスプロトコルと連携させて、又は独立のネットワーク又はリンク層機構として使用される。【選択図】      なし
2008514034.tif 000002
【特許請求の範囲】
【請求項１】
一連の隣接するネットワークに沿って移動するモバイル機器を、パケット損失なしでハンドオフする方法であって、アクセスルータ、前記モバイルが遠ざかりつつあるネットワークのエッジの近くにあるネットワークノード、前記モバイルが向かいつつあるネットワークのエッジの近くにあるネットワークノード、あるネットワークから別のネットワークに移動するときにネットワーク接続のない期間に遭遇する移動ノード、及び通信相手ノードの少なくとも１つに、モバイルごとのパケットバッファを設けることと、及びハンドオフプロセスが完了したときに、バッファに一時記憶されたパケットを、前記移動ノードに、及び／又は前記移動ノードから転送することと、を含む、ハンドオフ方法。
【請求項２】
バッファリングが、既存のモビリティプロトコル、アクセスプロトコルと関連して、又は独立のネットワーク又はリンク層機構として使用される、請求項１に記載の方法。
【請求項３】
バッファリング制御に使用されるプロトコルが、バッファリングシステムがモビリティ管理プロトコルと広く互換性を有するように、別個のプロトコルとして定義される、請求項２に記載の方法。
【請求項４】
モビリティ管理プロトコルの独立性を得るために、バッファに一時記憶されたパケットを前記移動ノードに転送するのに使用されるトンネル確立機構を規定することを備える、請求項３に記載の方法。
【請求項５】
トンネル管理の複雑度を低減する機構として、前記転送の一部で、前記一時記憶されたパケットの宛先ＩＰアドレスをｎＣｏＡに変更することを備える、請求項３に記載の方法。
【請求項６】
前記バッファに一時記憶されたパケットの宛先ＩＰアドレスをｎＣｏＡに変更することを備える、請求項３に記載の方法。
【請求項７】
リンク層に規定プロトコルを設けることによって、ハンドオーバ時にアクセスポイントにおいてパケットバッファリングを制御することをさらに備える、請求項１に記載の方法。
【請求項８】
前記ハンドオフ期間中に、転送中の前記バッファリングノードパケットをバッファに一時記憶することと、ハンドオフが完了次第、バッファに一時記憶されたパケットをフラッシュし、フラッシュされた一時記憶パケットを、新しい場所にある前記モバイル機器に転送することと、をさらに備える、請求項１に記載の方法。
【請求項９】
前記ハンドオフ期間中に前記モバイル機器からの出て行くパケットを一時記憶し、前記ネットワークエッジのところのバッファノードにパケットを一時記憶することを更に含み、それにより、ハンドオフ時の双方向バッファリングを実現し、双方向でのパケット損失を補償する、請求項１に記載の方法。
【請求項１０】
前記移動ノードがアクティブなスキャンを実行するときに、前記アクセスポイント内に位置するバッファノードにパケットを一時記憶することをさらに含む、請求項１に記載の方法。
【請求項１１】
ハンドオフの前に、ハンドオフ前トラフィックが前のネットワークを介して前記モバイル機器に到達し、前記モバイル機器が新しいネットワークに移動する用意ができたときに、前記モバイル機器は、前記バッファノードにその意図を知らせ、前記バッファノードは、まだ前のネットワークを介して転送されており、前記モバイル機器に向けられたトラフィックを一時記憶し始め、ハンドオフが完了すると、前記モバイル機器は、前記バッファノードに一時記憶されたパケットをフラッシュすることを合図し、前記一時記憶パケットを、新しいネットワークにある前記モバイル機器に送ると、前記バッファノードは前のアクセスルータ、次のアクセスルータ、及び／又は前記モバイル機器に留まる、請求項１に記載の方法。
【請求項１２】
１つ以上のモバイル機器に宛てられたパケットをインターセプトし、各モバイル機器がハンドオフ処理にある間パケット損失を避けるために前記パケットを一時的に記憶するネットワークエンティティーであるノードにパケットを一時記憶すること、前記ネットワークエンティティバッファノードに移動ノードごとにパケットを分類することと、ハンドオフが完了した後で一時記憶パケットを適切に転送することと、をさらに含み、これらのステップの各々が、バッファリングサービスを要求するモバイル機器によって合図される、請求項１に記載の方法。
【請求項１３】
一時記憶されるべきパケットの分類は、前記移動ノードが、前記移動ノードにとって対象となるパケットだけを一時記憶するよう前記バッファリングノードに知らせるＢＲｅｑ［ｉｎｉｔｉａｌ］を使って指図することをさらに備える、請求項１２に記載の方法。
【請求項１４】
前記モバイル機器は、バッファリング制御プロトコルを使って前記バッファノードにバッファリングサービスを要求し、前記プロトコルは、バッファリング要求結果及びエラー条件を伝え、前記バッファノードは、要求に応答するが、要求を生成せず、前記バッファリングサービスは一時的なサービスであり、バッファリングノードがモバイル機器からＢＲｅｑ［ｉｎｉｔｉａｌ］を受け取り、折衝された値が確立されたときにバッファリングを開始する、請求項１に記載の方法。
【請求項１５】
前記モバイル機器によって送られるＢＲｅｑ［ｉｎｉｔｉａｌ］及び後続のＢＲｅｑが、任意の一時記憶パケットに対して前記バッファノードが強制するポリシを指示し、前記一時記憶パケットを転送している、又はドロップしているバッファノードによってフラッシュポリシが強制され、前記バッファリング制御プロトコル又はアウトバンド機構を使って、前記モバイル機器に明示的エラー通知を送る、請求項１に記載の方法。
【請求項１６】
既存のフラッシュプロトコルが、肯定的サービス終了後に、一時記憶パケットを転送し、前記バッファノードには、前記一時記憶パケットをフラッシュし始めるときに、前記モバイル機器の現在の気付アドレスが供給されており、前記バッファリング制御プロトコルは、前記バッファノードに、前記移動ノードの現在の気付アドレスを指示する、請求項７に記載の方法。
【請求項１７】
前記モバイル機器と前記バッファノードが同じＩＰサブネット上にあるとき、前記一時記憶パケットは、アドレス解決プロトコルを使って前記モバイル機器にローカルで送られ、前記モバイル機器と前記バッファノードが異なるＩＰリンク上にあるとき、一時記憶パケットは、前記モバイル機器に向かってこれの次のホップルータ送られ、ＩＰ経路指定を使って前記モバイル機器に経路指定される、請求項１６に記載の方法。
【請求項１８】
前記バッファリング制御プロトコルは、前記モバイル機器によって、前記バッファリングノードにおけるバッファリングサービスを要求するのに使用され、前記バッファリング制御プロトコルは、新しいプロトコル、既存のプロトコルの拡張、又はリンク層プロトコルの拡張である、請求項２に記載の方法。
【請求項１９】
バッファリングフェーズの範囲が、前記バッファノードが、要求フェーズの間にバッファリングサービスが提供されることを指示するＢＡｎｓ［ｉｎｉｔｉａｌ］で応答した直後に開始し、サービス終了条件が満たされたときに終了する、トラフィック分類及びバッファリングが行われている期間にわたり、前記バッファリングフェーズの間に、前記バッファノードと前記モバイル機器は、１つ又は複数の延長要求を交換することができ、各交換が延長要求折衝を完了する、請求項１に記載の方法。
【請求項２０】
前記バッファノードと前記モバイル機器が同じ場所に位置する場合、前記延長要求取り決めは、前記モバイル機器内においてローカルで行われる、請求項１９に記載の方法。
【請求項２１】
一連の隣接するネットワーク移動ノードに沿って移動し、ネットワーク接続のない期間に遭遇するモバイル機器を、パケット損失なしでハンドオフするシステムであって、アクセスルータ、前記モバイルが遠ざかりつつあるネットワークのエッジの近くにあるネットワークノード、前記モバイルが向かいつつあるネットワークのエッジの近くにあるネットワークノード、移動ノード、及び／又は通信相手ノードにおいてモバイルごとのパケットバッファを備え、前記バッファノードが、ハンドオフプロセスが完了したときに、一時記憶パケットを、前記移動ノードに、及び／又は前記移動ノードから転送する、システム。
【請求項２２】
アクセスルータ、前記モバイルが遠ざかりつつあるネットワークのエッジの近くにあるネットワークノード及び／又は前記モバイルが向かいつつあるネットワークのエッジの近くにあるネットワークノード、移動ノード、通信相手ノードにおけるモバイルごとのパケットバッファと、モビリティ管理プロトコルと広く互換性を有するように別個のプロトコルとして規定されているバッファリング制御プロトコルであり、前記モバイル機器と前記移動ノードの間でイベント及びパラメータを知らせる前記バッファリング制御プロトコルと、パケットを一時記憶するための待ち行列及び転送機構と、前記モバイル機器バッファノードにおいてハンドオフ期間中に出て行くパケットを一時記憶する前記モバイル機器のバッファノード及び前記ネットワークエッジのところでパケットを一時記憶するバッファノードであり、ハンドオフ時に双方向バッファリングを実現し、双方向でのパケット損失を補償し、１つ又は複数のモバイル機器に向けられたパケットをインターセプトし、前記モバイル機器が前記ハンドオフプロセスにある間のパケット損失を回避するために前記パケットを一時的に記憶するネットワークエンティティであり、移動ノードごとにパケットを分類し、分類されたパケットを一時記憶し、ハンドオフが完了した後で一時記憶パケットを適切に転送する前記バッファノードと、前記モバイル機器と前記バッファノードが同じＩＰサブネット上にあるときには、前記モバイル機器に前記一時記憶パケットをローカルで送り、前記モバイル機器と前記バッファノードが異なるＩＰリンク上にあるときには、一時記憶パケットを、前記モバイル機器に向かって次のホップルータに送り、ＩＰ経路指定を使って一時記憶パケットを前記モバイル機器に経路指定するアドレス解決プロトコルとをさらに備える、請求項２１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、無線ネットワーキングに関し、いくつかの好ましい実施形態では、隣接するネットワークなどの間でのモバイル機器のハンドオフを改善する方法に関する。
【背景技術】
【０００２】
１．ネットワーク及びインターネット（登録商標）プロトコル
多様なコンピュータネットワークがあり、中でも代表的なのがインターネットである。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公共の自己持続的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる通信プロトコルのセットを使って各ホストを接続する。インターネットは、インターネットバックボーンと呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスの大部分は、企業及び個人にアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。
【０００３】
ＩＰ（インターネットプロトコル）は、ネットワーク上である機器（例えば、電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の機器にデータを送るためのプロトコルである。ＩＰは、コネクションレス型プロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なバージョンのＩＰがある。ネットワーク上の各ホスト機器は、ホスト機器のＩＰネットワークへの接続点を識別する少なくとも１つのＩＰアドレスを有する。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれる構成要素に分割される。あらゆるパケットは、独立のデータ単位として扱われる。
【０００４】
インターネットなどのネットワークを介した各点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク内の２点間の通信プロセスを７つの階層に分け、各層は独自の機能セットを付加する。各機器は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れが生じるようにメッセージを処理する。７つの機能層を提供するプログラミング及び／又はハードウェアは、通常、デバイスオペレーティングシステムと、アプリケーションソフトウェアと、ＴＣＰ／ＩＰ及び／又は他のトランスポート及びネットワークプロトコルと、この他のソフトウェア及びハードウェアとの組み合わせである。
【０００５】
通常、上位４層は、メッセージがユーザから、又はユーザに渡されるときに使用され、下位３層は、メッセージが機器（ＩＰホスト機器など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の機器である。他の何らかのホストに向けられているメッセージは、上位層には渡されず、他のホストに転送される。ＯＳＩ及び他の類似のモデルにおいて、ＩＰは第３層、すなわちネットワーク層にある。以下に、ＯＳＩモデルの各層を列記する。第７層（すなわち、アプリケーション層）は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証及びプライバシが考慮され、データ構文に対する制約条件が識別されるなどの層である。第６層（すなわち、プレゼンテーション層）は、例えば、着信及び発信データをあるプレゼンテーション形式から別の形式に変換するなどの層である。第５層（すなわち、セッション層）は、例えば、アプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了させる層である。第４層（すなわち、トランスポート層）は、例えば、エンドツーエンド制御及びエラーチェックなどを管理する層である。第３層（すなわち、ネットワーク層）は、例えば、経路指定や転送などを処理する層である。第２層（すなわち、データリンク層）は、例えば、物理レベルでの同期を取り、ビットスタッフィングを行い、伝送プロトコルの知識及び管理を提供するなどの層である。米国電気電子技術者協会（ＩＥＥＥ）では、データリンク層を、物理層との間のデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、エラー回復を行うＬＬＣ（論理リンク制御）層という、２つのさらなる副層に細分している。第１層（すなわち、物理層）は、例えば、物理レベルでネットワークを介してビットストリームを伝達する層である。ＩＥＥＥでは、物理層を、ＰＬＣＰ（物理層収束手順）副層とＰＭＤ（物理媒体依存）副層とに細分している。
【０００６】
通常、第２層より上位の各層（例えば、ＯＳＩモデルにおけるネットワーク層又は第３層を含む各層など）を上位層と呼ぶ。
【０００７】
２．無線ネットワーク
無線ネットワークは、例えば、セルラ及び無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ページャ、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器には、音声及び／又はデータの高速無線伝送を確保するデジタルシステムが含まれ得る。典型的なモバイル機器は、送受信機（すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機）、アンテナ、プロセッサ、１つ又は複数の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（例えば、データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、デジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース（例えば、ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）といった構成要素の一部又は全部を含む。
【０００８】
モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いられてもよい。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含まれ得る。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ規格が存在する。
【０００９】
例えば、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、及び他のモバイル機器の間のリンク、ならびにインターネットへの接続を提供するのに使用され得る。ブルートゥースは、モバイル機器が、短距離無線接続を使って、モバイル機器同士で、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを明示するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする様々なモバイル機器の普及から生じるエンドユーザ問題に対処するデジタル無線プロトコルを作成して、異なるベンダから提供される装置が相互にシームレスに動作するようにする。ブルートゥース機器は、共通の命名概念に従って命名され得る。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）又は一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名前を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器には、ＩＰアドレス及びＩＰ（ネットワーク）名が与えられ得る。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、例えば、ＢＤＮ、ＢＤＡ、ＩＰアドレス及びＩＰ名などを含み得る。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名前を指すものである。
【００１０】
ＩＥＥＥ規格であるＩＥＥＥ８０２．１１は、無線ＬＡＮ及び機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現され得る。場合によって、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含んでいることもある、カードなどの別個のハードウェアをインストールしてもよい。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であれ、移動局（ＳＴＡ）であれ、ブリッジであれ、ＰＣＭＣＩＡカードであれ、又は別の機器であれ、無線送受信機、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべき要素を含む。
【００１１】
加えて、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）も利用され得る。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つ以上の独立のネットワークインターフェースを含んでいてもよく、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレス、及びＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を有し得る。
【００１２】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Wireless Fidelity）機器、ＧＰＲＳ（汎用パケット無線システム）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（移動通信用グローバルシステム）機器、ＥＤＧＥ（Enhanced Data for GSM Evolution）機器、ＴＤＭＡ型（時分割多重接続）機器、又はＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含まれ得る。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、ＩＥＥＥ  ＭＡＣアドレスを含む、様々な種類のアドレスを含んでいてもよい。
【００１３】
また、無線ネットワークには、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、及び他のモバイルネットワークシステムにおいて見られる方法及びプロトコルも関与し得る。モバイルＩＰに関して、これには、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、各ユーザに最初に割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器がホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワーク及びネットワークのサブネット内における機器の現在位置を識別する気付アドレス（ＣｏＡ）とを割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントが、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、モバイルノードが気付アドレスを変更する都度、ホームエージェントにバインディング更新を送ることができる。
【００１４】
基本的なＩＰ経路指定では（すなわち、モバイルＩＰ外部では）、通常、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、各ノードが接続されているネットワークリンクを識別するという前提に依拠している。本明細書で使用する場合、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、及び／又は転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスプレフィックスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットなどを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットなどを調べることができる。典型的なモバイルＩＰ通信の場合、ユーザが、例えばインターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスク及びデフォルトのルータを用いて再構成される必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。
【００１５】
３．モバイル機器のハンドオフ
例えば、ＩＰベースの無線ネットワークインターフェース（ＩＥＥＥ８０２．１１や８０２．１６インターフェースなど）を備えるモバイル機器などの状況において、モバイル機器は、あるネットワークから別のネットワークに移動するときに、ローミング又はハンドオフを実行する必要がある。既存のハンドオフ方法では、ハンドオフは、通常、以下のプロトコル層特有のハンドオフ手順を実行することによって達成される。
【００１６】
第１に、ハンドオフが物理層で行われる。この際、モバイル機器は、これの無線チャネルを、例えば、移動先ネットワーク内の無線基地局又は無線アクセスポイントに切り換える。
【００１７】
第２に、ハンドオフが第２層で行われる。この際、モバイル機器は、これの第２層（すなわちリンク層）接続を移動先ネットワークに切り換える。前述のように、リンク層又は第２層は、ユーザトラフィックを搬送するＩＰ層直下のプロトコルを指す。モバイル機器は、移動先ネットワークが第２層認証を必要とする場合には、移動先ネットワークとの第２層認証を実行する。
【００１８】
第３に、ハンドオフがＩＰ層で行われる。この際、モバイル機器は、移動先ネットワークからローカルＩＰアドレスを獲得し、移動先ネットワークが必要とする場合にはＩＰ層認証を実行し、次いで、モバイル機器に向けられたＩＰパケットが、ＩＰネットワークによって、移動先ネットワークを介してこのモバイル機器に経路指定され得るように、ＩＰ層場所更新を実行する。場合によっては、ＩＰ層場所更新をサポートする１つの方法は、インターネット技術標準化委員会（ＩＥＴＦ）によって定義されているモバイルＩＰを使用するものである。
【００１９】
第４に、ハンドオフがアプリケーション層で行われる。モバイル機器は、これのアプリケーショントラフィックが、移動先ネットワークを介してモバイル機器上のアプリケーションに正しく流れるようにするために、アプリケーション層で必要なステップを実行する。例えば、モバイル機器が、ＩＥＴＦによって定義されているセッション開始プロトコル（ＳＩＰ）を使って、これのアプリケーション層シグナリングを管理するときには、アプリケーション層ハンドオフは、モバイル機器がこれの現在の場所をこれのホームＳＩＰサーバで更新することによって達成され得る。また、モバイル機器は、移動先ネットワークが必要とする場合には、移動先ネットワークとのアプリケーション層認証の実行を必要とすることもある。これが該当するのは、例えば、モバイル機器が、在圏３ＧＰＰ（第３世代パートナーシッププロジェクト）無線ネットワークにおいてＩＰマルチメディアサブシステム（ＩＭＳ）を使用している場合であり、ＩＭＳは、３ＧＰＰネットワークを介したマルチメディアアプリケーションのためのアプリケーション層シグナリング及び管理をサポートするＳＩＰベースのシステムである。
【００２０】
ＩＰ層ハンドオフとアプリケーション層ハンドオフのどちらかで十分な場合もある。すなわち、ＩＰ層とアプリケーション層両方のハンドオフを実行する必要がないこともある。これら既存の方法は、ＩＰベースの無線ネットワークで使用されるときに、著しいハンドオフ遅延をもたらすことがある。例えば、都市や、集合ビル又は居住施設の内部や、複数の無線ＬＡＮが存在する他の公共の場所など、多くの無線ローカルエリアネットワーク（ＷＬＡＮ）がある地理的区域では、モバイル機器が、複数の無線ネットワークから同時に強力な無線信号を受け取ることがある。しかしながら、このモバイル機器には、これらの無線ネットワークのいくつかの使用が許可されていないこともある。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
前述の既存のハンドオフ方法の下では、モバイル機器は、移動先ネットワークを、例えば、無線信号強度に基づいて選択し、前述のステップを経て移動先ネットワークに接続してから、例えば、モバイル機器が、ネットワークを使用することを許されているかどうか、又はネットワークが、モバイル機器が必要とする機能（例えば、十分な利用可能帯域幅など）若しくはサービスを提供しないかどうかを知ることになる。したがって、モバイル機器は、モバイル機器が必要とする機能及びサービスを提供し、モバイル機器がこれらを使用することを許可するネットワークに最終的に接続するまで（又は可能なネットワークが完全に尽きるまで）、別のネットワークに接続しようとする必要があり、このプロセスを繰り返すことになる。したがって、既存のシステムでは、ハンドオフに、許容できないほど長時間を要することがあり、例えば、ライブ音声、及び／又はビデオアプリケーションなど、影響を受けやすいアプリケーションを遅延させることになり得る。様々なシステム及び方法が知られているが、無線ネットワークでハンドオフを実行する改善されたシステム及び方法が依然として求められている。
【課題を解決するための手段】
【００２２】
本発明の好ましい実施形態の１つの広い態様は、一連の隣接するネットワークに沿って移動するモバイル機器と通信相手ノードの間の、パケット損失損失なしのハンドオフである。移動ノードは、あるネットワークから別のネットワークに移動するときに、ネットワーク接続のない期間に遭遇し得る。パケット損失を無くすことは、アクセスルータ、モバイルがそこから遠ざかりつつあるネットワークのエッジの近くにあるネットワークノード、モバイルがそこに向かいつつあるネットワークのエッジの近くにあるネットワークノード、及び／又は移動ノード上に位置する、モバイルごとのパケットバッファを使用することによって実現され得る。バッファに入れられたパケットは、ハンドオフプロセスが完了したときに、移動ノードに転送される。
【００２３】
好ましい実施形態の別の態様は、既存のモビリティプロトコル、アクセスプロトコルと連携させたバッファリング、又は独立のネットワーク若しくはリンク層機構としてのバッファリングの使用であり、バッファリング制御に使用されるプロトコルは、システムが、モビリティ管理プロトコルと広く互換性を有するように、別個のプロトコルとして定義される。バッファリング制御プロトコルは、モバイル機器と移動ノードの間でイベント及びパラメータを知らせる。
【００２４】
好ましい実施形態の別の態様は、モビリティ管理プロトコルの独立性を提供するために、一時記憶パケットを移動ノードに転送するのに使用されるトンネル確立機構を規定する。
【００２５】
好ましい実施形態の別の態様は、バッファノードにおける、ハンドオフ時に転送中であるパケットのバッファリングである。ハンドオフが完了次第、一時記憶パケットは、フラッシュされ、新しい場所にあるモバイル機器に転送される。モバイル機器には、モバイル機器バッファノードでハンドオフ時に出て行くパケットを一時記憶するバッファリングノードを設けることができ、ネットワークエッジには、ネットワークエッジバッファからモバイル機器に送られないパケットを一時記憶するバッファノードを設けることができる。モバイル機器とモバイル機器とにバッファリングノードを設けることによって、ハンドオフ時の双方向バッファリングが実現され、双方向でのパケット損失が補償される。
【００２６】
好ましい実施形態の別の態様では、ハンドオフ前トラフィックが、ハンドオフ前に前のネットワークを介してモバイル機器に到達する。モバイル機器は、新しいネットワークに移動する用意ができたときに、バッファノードにこれの意図を知らせ、バッファノードは、モバイル機器に向けられたトラフィックをバッファに記憶し始める。ハンドオフが完了次第、モバイル機器は、バッファノードに一時記憶されたパケットをフラッシュし、これらの一時記憶パケットを新しいネットワーク内にあるモバイル機器に転送するように合図し、バッファノードは、一時バッファリングサポートを必要とするノード上にあってもよく、前のアクセスルータ、次のアクセスルータ、又はモバイル機器のいずれかにあることも可能である。
【００２７】
好ましい実施形態に別の態様では、バッファノードは、１つ又は複数のモバイル機器に向けられたパケットをインターセプトし、モバイル機器がハンドオフプロセスにある間のパケット損失を回避するためにこれらのパケットを一時的にバッファに記憶するネットワークエンティティであり、バッファノードは、移動ノードごとにパケットを分類し、分類されたパケットをバッファに記憶し、ハンドオフが完了した後で、一時記憶パケットを適切に転送し、これらのステップのそれぞれが、バッファリングサービスを要求するモバイル機器によって合図される。
【００２８】
好ましい実施形態の別の態様では、既存のバッファリング制御プロトコルが、肯定的サービス終了後に一時記憶パケットの転送を合図し、バッファノードには、一時記憶パケットをフラッシュし始めるときに、モバイル機器の現在の気付アドレスが提供されている。また、バッファリング制御プロトコルは、バッファノードに一時記憶パケットのフラッシュ及び転送の前に、移動ノードの現在の気付アドレスも知らせる。
【００２９】
好ましい実施形態の別の態様では、モバイル機器とバッファノードが同じＩＰサブネット上にあるとき、一時記憶パケットは、モバイル機器にローカルで送られ、モバイル機器とバッファノードが異なるＩＰリンク上にあるとき、一時記憶パケットは、モバイル機器に向かってこれの次のホップルータに送られ、ＩＰ経路指定を使ってモバイル機器に経路指定される。
【００３０】
好ましい実施形態の別の態様では、バッファリングフェーズが、バッファノードが、最初のバッファリング要求に対して、バッファリングサービスが提供されることを指示する応答を行った直後に開始し、サービス終了条件が満たされたときに終了する、トラフィック分類及びバッファリングが行われている期間にわたる。バッファリングフェーズの間、バッファノードとモバイル機器は、１つ又は複数の延長要求を交換することができ、各交換が、延長要求取り決めを完了させる。
【００３１】
好ましい実施形態の別の態様では、バッファリング制御プロトコルは、移動ノードがバッファに入れられるべきトラフィックの種類（トラフィック分類）を指定することを可能にするものと定義する。これは、移動ノードが、対象となるトラフィックだけを一時記憶するバッファノードに柔軟な合図を送ることができるようにする。また、これは、バッファノードが、バッファリング要求に必要なリソース割り振りを低減するのにも役立つ。
【００３２】
好ましい実施形態の別の態様では、バッファリングノードが、バッファリングサービスの実行に際して割り振られるべきリソースを調整し、取り決めすると規定する。割り振られるべきリソースの量は、要求ごとに、移動ノードのハンドオフ要件、及びバッファリングノード内のリソースの利用可能性を考慮に入れて算出される。このような折衝は、バッファリング制御プロトコルの一部である。
【００３３】
好ましい実施形態の別の態様は、移動ノード内にあるべきバッファリングノードを定義する。これは、移動ノード内にある、パケットを送っているソフトウェアアプリケーションに役立つ。送られたパケットは、ハンドオフが行われているときに一時記憶される。このようなシナリオでは、移動ノードのバッファノードへのシグナリングが、ローカルで行われる。一時記憶パケットがフラッシュされ、転送されるとき、一時記憶パケットの宛先ＩＰアドレスは、不変のままとされ、通常のＩＰ経路指定を介して経路指定される。
【００３４】
様々な実施形態の上記その他の態様、特徴、及び／又は利点は、以下の説明を、添付の図と併せて考察すればさらに理解されるであろう。様々な実施形態は、該当する場合には、異なる態様、特徴及び／又は利点を含むことも、除外することもできる。加えて、様々な実施形態は、該当する場合には、他の実施形態の１つ又は複数の態様又は特徴を組み合わせることもできる。個々の実施形態の態様、特徴及び／又は利点の説明は、他の実施形態又は特許請求の範囲を限定するものと解釈されるべきではない。
【発明を実施するための最良の形態】
【００３５】
添付の図に、本発明の好ましい実施形態を、限定のためではなく例として示す。
【００３６】
本発明は、多くの異なる形として実施され得るが、本明細書では、本開示が、本発明の原理の例を提供するものとみなされるべきであり、このような例は、本発明を、本明細書で開示し、及び／又は図示する好ましい実施形態だけに限定するためのものではないという了解の下で、いくつかの例示的実施形態を説明する。
【００３７】
本明細書では、以下の省略形を用いる。移動ノード（ＭＮ）、通信相手ノード（ＣＮ）、バッファリングノード（ＢＮ）、フラッシュポリシ（ＦＰ）、バッファリング制御プロトコル（ＢＣＰ）、サービス終了（ＥＯＳ）、バッファサイズ（ｂｓｚ）、時間制限タイムアウト（ｈｐ）、分類されたトラフィック（ｔｃ）、ＣｏＡ（気付アドレス）、結果コード（ｒｃｏｄｅ）。
【００３８】
モバイル環境では、あるネットワークから別のネットワークに移動している移動ノード（ＭＮ）に、ネットワーク接続のない期間があることが予期される。したがって、ＭＮに向けられた転送中のパケットが、ハンドオフ期間（ＨＰ）中に失われる可能性が極めて高い。ハンドオフ期間は、ＭＮのパケットのトラフィックパスは、ＭＮが適正なエンティティにこれの新しい場所を通知する（モバイルＩＰｖ４／６のバインディング更新）まで、引き続き前のネットワークを介して送られることによってさらに長引く。このような場合、ＭＮが前のネットワークを離れたときから、適切なエンティティが、ＭＮの新しい場所（モバイルＩＰｖ６経路最適化のＨＡ又はＣＮ）を知り、これらのパケットをしかるべく転送するときまで、パケット損失が発生する。このような長期にわたる損失期間は、この損失を完全に補償することのできないストリーミングアプリケーションの品質を著しく害する。
【００３９】
既存の技法は、このような喪失を、ネットワーク端点（すなわち、メディアアプリケーション）のところで軽減しようとする。大部分のマルチメディアアプリケーションは、プレイアウトバッファ、ＦＥＣ［１０］、ＲＴＣＰベースのフィードバック［８］、及び他の技法［９］に頼って、パケット損失の影響を最小限に抑え、又はトラフィック中の小さいギャップを修正する。しかしながら、既存の解決法は、過度のパケット損失や過度の遅延を考慮に入れておらず、損失及び遅延の影響を受け易いＶｏＩＰなどのリアルタイムアプリケーションもサポートしていない。加えて、これらの機構は、エンドシステムの協働に大きく依存するものでもある。ＣＮがＭＮから離れている場合には、再送信ベースの機構も遅延の一因となる。本発明は、モバイルがそこから遠ざかりつつあり、又はそこに向かいつつあるネットワークのエッジの近くにあるアクセスルータ又はネットワークエンティティ（バッファリングノード）のところにモバイルごとのパケットバッファを設けることによって、アプリケーション端点の向こう側で解決策を提供する。ハンドオフ期間の間に転送中のパケットが、バッファリングノード（ＢＮ）に一時記憶される。ハンドオフが完了すると、一時記憶パケットは、フラッシュされ、新しい場所にあるＭＮに転送される。この手法は、ＢＮに到達しているＭＮに向けられたすべてのパケットのゼロパケット損失を実現する。また、この解決法は、ＭＮが、ＢＮの挙動をより大ざっぱに制御することができるようにして、全般的なハンドオフ遅延を低減するのに役立つバッファ方式を示すものでもある。
【００４０】
また、ハンドオフ期間中にＭＮによって送られた発信パケットも、ハンドオフプロセスの間に失われ得る。このような場合、ハンドオフ期間中に出て行くパケットのためのバッファリング対策を提供するためのＢＮも、ＭＮにおいてローカルで実施され得る。ＭＮとネットワークエッジの両方にＢＮを有することによって、ハンドオフ時の双方向バッファリングが実現され、双方向でのパケット損失が補償される。
【００４１】
また、ＢＮは、特に、アクティブスキャンを実行するＭＮを支援するために、アクセスポイント内に位置していてもよい。ＭＮは、現在関連付けられているアクセスポイントと異なるチャネル上でアクティブスキャンを実行するとき、もはや、このアクセスポイントからパケットを受け取ることができなくなる。本発明の一実施形態では、ＭＮ省電力モードを使ってアクセスポイントにシナリオを知らせ、アクセスポイントがＭＮに代わってバッファリングを開始することができるようにする。アクセスポイント自体でＢＮを実施すれば、２．１．６で説明するように、バッファリング期間及びバッファサイズをより適切に制御する同じ機能が提供される。
【００４２】
１．１．背景
好ましい実施形態は、以下の、及び／又はこの他の背景情報を改善するものである。以下の各文献は、参照により、これの全体が本明細書に組み込まれる。
【００４３】
[1]Moore,N.、Choi J.、Pentland Bret、「Tunnel Buffering for Mobile IPv6」、draft-moore-mobopts-tunnel-buffering-00.txt、2004年7月。
[2]Khalil,M.、Akhtar H.、Qaddoura E.、Perkins C.、Cerpa A.、「Buffer Management for Mobile IP」、draft-mkhalil-mobileip-buffer-00.txt、1999年10月。
[3]R. Koodli、「Fast Handovers for Mobile IPv6」、draft-ietf-mipshop-fast-mipv6-03.txt、2004年10月。
[4]Krishnamurthi G.、Chalmers R.、Perkins C.、「Buffer Management for Smooth Handovers in Mobile IPv6」、draft-krishnamurthi-mobileip-buffer6-00.txt、2000年7月。
[5]Chul-Ho Lee、Dongwook Lee、JongWon Kim、「Seamless MPEG-4 Video Streaming over Mobile IP-enabled Wireless LAN」、Network Research Workshop 2004/18th APAN meeting。
[6]Perkins C.、Wang K-Y.、「Optimized smooth handoffs in Mobile IP」、Proceedings of IEEE Symposium on Computers and Communications、1999年7月。
[7]Pejman Roshan、Jonathan Leary、「802.11 Wireless LAN Fundamentals」、Cisco Press、ISBN1587050773、2003年12月。
[8]Rosenberg J.、Schulzrinne H.、「An RTP Payload Format for Generic Forward Error Correction」、RFC2733、1999年12月。
[9]Perkins C.、Hodson O.、「Options for Repair of Streaming Media」、RFC2354、1998年6月。
[10]Bremen J.、Wenger S.、Sato N.ら、「Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)」draft-ietf-avt-rtcp-feedback-11.txt、2004年8月。
[11]Reza Rejaie他「RAP: An End-to-end Rate-based Congestion Control Mechanism for Real-time Streams in the Internet」、1999年3月。
概ね類似したバッファリング機能を提供する２つの提案がある［１、２］。両提案とも、ハンドオーバ期間中のネットワークにおけるバッファリングをサポートするためのモバイルＩＰ（ｖ４／ｖ６）プロトコルの拡張を定義している。好ましい実施形態は、例えば、既存の提案でサポートされていない、以下の新しい特性の１つ又は複数、好ましくは全部を含む。
【００４４】
既存の提案は、特定のモビリティ管理プロトコルと緊密に結合されている。これに対して、本方法は、バッファリング制御プロトコルを別個のプロトコルとして定義することによって、どんなモビリティ管理プロトコルとも協働することができる。
【００４５】
既存の提案では、バッファリングノードの場所が、ホームエージェントやモビリティアンカーポイントなどのモビリティエージェントだけに限られる。これに対して、本方法は、バッファリングノードの場所に関してより多くの柔軟性を提供する。
【００４６】
既存の提案では、ハンドオーバ期間終了後の、バッファに入れられたパケットの移動ノードへの転送が、結合されたモビリティ管理プロトコルのモビリティエージェントの転送挙動に大きく依存する。これに対して、本方法は、モビリティ管理プロトコルの完全な独立性を提供するために、一時記憶パケットを移動ノードに転送するのに使用される、独自のトンネル確立機構を定義する。
【００４７】
本方法の好ましい実施形態では、バッファリングパケットの詳細な待ち行列及び転送機構、及び誤り状況での詳細な挙動が定義されており、既存の提案ではこのような詳細が欠落している。
【００４８】
既存のプロトコルには、ハンドオーバ時のアクセスポイントにおけるパケットバッファリング制御専用の、リンク層で定義されたプロトコルがない。本明細書で説明する好ましい方法は、ハンドオーバ時のアクセスポイントにおけるパケットバッファリングを制御するためにリンク層で定義され得る。
【００４９】
以下に、本方法と既存の方法のいくつかの実施形態の間の比較を示す。
【００５０】
参照文献［１］では、ＢＵ（バインディング更新）及びＬＢＵ（ローカルバインディング更新）メッセージのモビリティヘッダにおけるＰビットの追加の使用が説明されている。Ｐビットの値は、ＨＡ（ホームエージェント）に、パケットをいつ一時記憶するべきか（Ｐビットが「１」）、及びパケットをいつ転送すべきか（Ｐビットが「０」）を指示する。この手法は、例えば、動的折衝が行われ、バッファリングの終わりに複数の挙動が選択され得る本方法のいくつかの実施形態に比べて、限界がある。
【００５１】
参照文献［２］では、本発明で提示する方法に似た、モバイルＩＰｖ４バッファリングプロトコルが説明されている。最も類似している点は、バッファリング期間を管理し、バッファサイズ、及びトラフィックフロー識別情報（ＩＰトラフィックフィルタ）を折衝する制御プロトコルの明示的定義である。モバイルＩＰｖ４環境の制限内で、参照文献［２］では、バッファリング期間の長さを決定するための明示的シグナリングを推奨しているが、同時に、バッファへのリース期間も示唆している。本方法は、機能的に多少の類似性を有するともいえるが、本方法は、モバイルＩＰｖ４トポロジを越えて動作し、ＢＮの場所は、ＦＡ（移動先エージェント）又はＨＡ（ホームエージェント）だけに限定されない。
【００５２】
参照文献［４］は、［２］のモバイルＩＰｖ６バージョンであり、類似の機構が説明されている。既存の方法によってサポートされていない本発明にある１つの特徴が、バッファ管理発見である。これは、ＩＰｖ６ルータ広告を利用してネットワークのバッファリング機能をチェックする。総じて、［４］及び［２］で説明されている方法は、実質的に、同一である。
【００５３】
参照文献「８、９及び１０］では、バッファ管理プロトコルを使用せずにパケット損失を低減し、エンドクライアントの協働に大きく依存する代替の機構が示されている。
【００５４】
ＭＮ（移動ノード）がアクティブにスキャンしている間のパケット損失を回避するためにＩＥＥＥ８０２．１１の電力管理機能を使用する既存の方法がある［７］。この方法では、ＭＮは、現在のアクセスポイントに、ＭＮが休眠モードに入ろうとしていることを知らせ、アクセスポイントは、ＭＮが起動するまでＭＮのパケットをバッファに一時記憶しようとする。しかしながら、特に、この方法は、ハンドオーバ時にパケットを一時記憶するためには使用され得ない。この欠点は、この方法が、ＭＮが起動してバッファリングを停止した後、ＭＮが引き続きこのアクセスポイントと関連付けられているものと想定することに起因するものであり、この方法は、特定のＱｏＳ要件を満たすのに必要とされ得る、トラフィックフロー識別情報、バッファサイズ、バッファリング期間などの追加情報を搬送しないために、適用範囲が限られている。
【００５５】
２．アーキテクチャ
好ましい実施形態には、バッファ方式に必要とされる、ＢＮとバッファリング制御プロトコル（ＢＣＰ）という２つの主要な構成要素がある。ＢＣＰは、ＭＮとＢＮの間でイベント及びパラメータを知らせる。ＢＣＰは、再送信機能を有する要求（ＢＲｅｑ）と応答（ＢＡｎｓ）の対で構成される信頼性の高いプロトコルである。ＢＣＰについては、セクション３で詳細に論じる。
【００５６】
このアーキテクチャでは、バッファリングと、セクション２．１．５で論じるように、バッファがフラッシュされるときに、一時記憶パケットが任意のノードに転送されることを可能にする転送の間に明確な区別がある。モビリティプロトコルの場合、転送は、トンネリングが関与するかどうかに関わりなく実行される。また、ＢＣＰの使用は、あらゆるモビリティ管理プロトコルとの明確な区別も定義する。ＢＣＰ用法の一部は以下の通りである。
【００５７】
１．図１に示すようなエンドホストとこれのアクセスルータの間。
【００５８】
２．エンドホストとこれのアクセスポイントの間。この場合、バッファリング制御プロトコルは、Ｌ２又はＬ３において定義され得る。
【００５９】
図１に、ＢＮとして働くアクセスルータを備えるパケットバッファリングモデルを示す。このバッファリングモデルは、ＭＮ１０２に向かうトラフィックフロー１１６、１２２、及び１０４を使うとうまく説明できる。ハンドオフに先立ち、ハンドオフ前トラフィック１１８が前のネットワーク１１０を介してＭＮ１０２に到達する。ＭＮは、新しいネットワーク１１２に移動しようとすると、ＢＮ１０６に、これの意図を明示的に知らせる。次いで、ＢＮ１０６は、まだ、前のネットワーク１１０を介して転送されている、ＭＮ１０２に向けられたトラフィック１１６を一時記憶し始める。ハンドオフが完了すると、ＭＮ１０２は、線１２０で示すように、ＢＮ１０６に（明示的又は暗黙的に）、一時記憶パケット１０４をフラッシュし、これを新しいネットワーク１１２にあるＭＮ１０２に転送するよう合図する。しかしながら、ＢＮの場所がこのトポロジだけに限定されないことに留意することは重要である。ＢＮは、セクション２．１．６で論じるように、一時バッファリングサポートを必要とする任意のノード上に存在し得る。例えば、前のアクセスルータ１０８、次のアクセスルータ１０９、及びモバイル機器１０２は、すべて、バッファリング機能を備えることができる。通信相手ノード１００とＭＮ１０２の間の経路最適化を伴うハンドオフ後トラフィックを、流れ線１１４で表す。
【００６０】
流れ線１２２は、ＣＮとＭＮ１０２の間の気付アドレスを用いたハンドオフ後トラフィックを示す。このバッファ方式必要な、ＢＮとバッファリング制御プロトコル（ＢＣＰ）という２つの主要構成要素がある。ＢＣＰは、ＭＮとＢＮの間でイベント及びパラメータを知らせる。ＢＣＰは、再送信機能を有する要求（ＢＲｅｑ）と応答（ＢＡｎｓ）の対で構成される信頼性の高いプロトコルである。ＢＣＰについてはセクション３で詳細に論じる。
【００６１】
２．１．バッファリングノード
好ましい実施形態では、バッファリングノード（ＢＮ）が、１つ又は複数のＭＮに向けられたパケットをインターセプトし、ＭＮがハンドオフプロセスにある間のパケット損失を回避するために、これらを一時的にバッファに記憶するネットワークエンティティである。これを行うために、ＢＮは、ＭＮごとにパケットを分類し、パケットをバッファに記憶し、ハンドオフが完了した後で、一時記憶パケットをしかるべく転送することができなければならない。加えて、これらのステップのそれぞれが、バッファリングサービスを要求するＭＮによって合図される。
【００６２】
２．１．１  バッファリングノード及びバッファリング制御プロトコル
ＭＮとの関連において、ＢＮは、受動エンティティである。ＭＮは、ＢＣＰを使ってＢＮにバッファリングサービスを要求する。また、このプロトコルは、バッファリング要求結果、及びシグナリングエラーを含むエラー条件も伝える。ＢＮは、要求に応答する（受け取ったＢＲｅｑごとにＢＡｎｓを送る）だけであり、これらを生成することは決してない。ＢＣＰについては、セクション３で詳細に論じる。
【００６３】
２．１．２  トラフィック分類
ＢＮは、サービスを求めるＭＮごとに、トラフィックを分類し、バッファを動的に割り振ることができなければならない。バッファに一時記憶しなければならないトラフィックの分類は、ＭＮがＢＲｅｑ［ｉｎｉｔｉａｌ］を送るときにＭＮによって指図される。［ｉｎｉｔｉａｌ］は、トラフィック分類情報を含む、ＭＮによって送られた信号の種類（初期）及び信号パラメータを指定する。ＭＮは、ＭＮに向けられたすべてのトラフィックではなく、ある特定の種類のトラフィックだけを一時記憶してもよい。ＭＮによって分類情報が提供されない場合、ＢＮは、ＭＮ向けのすべてのトラフィックを一時記憶する必要がある。
【００６４】
２．１．３  バッファサイズ（ｂｓｚ）割り振り
また、ＢＲｅｑ［ｉｎｉｔｉａｌ］では、ＭＮが、ＢＮによって割り振られるバッファのサイズを折衝することもできる。ＭＮは、ハンドオフ期間の長さとトラフィックレートの事前知識を有し、これによって、バッファサイズ（ｂｓｚ）の妥当な値を算出できることもある。しかしながら、ＢＮは、メモリリソースを温存するために、この値に制限を設けることができる。したがって、ＢＮがｂｓｚの最終値を決定する。この最終値は、ＢＮによって、ＢＡｎｓ［ｉｎｉｔｉａｌ］の一部としてＭＮに返される。ＢＮによって課される値がＭＮにとって許容できない場合、ＭＮは、ＢＮに、バッファリングサービスを終了するという意図を指示するＢＲｅｑ［ｓｔｏｐ］を送ることによって、これのバッファリングサービスを求める要求を撤回してもよい。
【００６５】
また、ＭＮは、ＢＲｅｑ［ｉｎｉｔｉａｌ］において、ＭＮが申し出るｂｓｚが、ＭＮが必要とする量であり、これより少ない量は許容できないかどうかを指示してもよい。ＭＮは、ＢＲｅｑ［ｉｎｉｔｉａｌ］パラメータの必須フラグ（ｆｌａｇ．ｍ）を設定することによってこれを指示することができる。ＢＮがこの要件に対応することができない場合、ＢＮは、サービスを直ちに終了し、ＢＡｎｓ［ｉｎｉｔｉａｌ］によってＭＮにエラーを返す。このような場合、ＢＮは、このサービスに関する状態情報を保持することさえもしないはずである。
【００６６】
ｂｓｚの値は初期折衝時に設定されるが、バッファリングサービスの間に動的に調整されてもよい。詳細はセクション３．３．２に示す。
【００６７】
２．１．３  バッファリングサービス期間
バッファリングサービスは、一時的なサービスであるため、バッファリングは、ＢＮがＭＮからＢＲｅｑ［ｉｎｉｔｉａｌ］を受け取り、取り決められた値が確立された後で開始する。次いで、サービスに関する状態情報がＢＮによって維持される。何らかの理由でＢＮが初期要求に対応できない場合、ＢＮは、セクション２．１．７で説明するように、ＢＡｎｓ［ｉｎｉｔｉａｌ］の一部としてＭＮにこの障害を伝えてもよい。バッファリングサービスは、少なくとも、ＭＮがＩＰパケットを送受信することができないハンドオフ期間を包含すべきである。バッファリング期間の終了は、肯定的又は否定的結果を有し得るサービス終了（ＥＯＳ）期間である。肯定的結果を有するバッファリング期間（ｂｐ）は、それぞれ、セクション２．１．３．１とセクション２．１．３．２で説明する、時間制限方法と明示的シグナリング方法の両方を使って求めることができる。２つの方法は、相互に排他的であるが、相補的である。というのは、一方を使って他方に取って代わることができるからである。否定的結果を有するバッファリング期間は、セクション２．１．７で説明するように、エラー条件が満たされるときに発生する。
【００６８】
２．１．３．１  時間制限バッファリング
ＢＮとＭＮは、ＥＯＳを決定するための時間制限タイムアウト値（ｂｐ）を取り決めることができる。ＢＲｅｑ［ｓｔｏｐ］の明示的受け取りの前のタイムアウト満了は、セクション２．１．４で説明するように、肯定的ＥＯＳ及び既存のフラッシュポリシ（ＦＰ）の強制を構成する。大きなｂｐ値は、バッファをオーバフローさせることになる。このような場合、セクション２．１．７．２で説明するように、バッファオーバフロー緊急事態処置が実行される。タイムアウトの長さは、ＭＮがＩＰパケットを送受信することのできないハンドオフ期間を包含する。
【００６９】
２．１．３．２  明示的シグナリング
前に確立されたｂｐ値の満了前のＢＲｅｑ［ｓｔｏｐ］の明示的受け取りは、肯定的ＥＯＳ及び既存のＦＰの強制を構成する。セクション２．１．４の説明を参照されたい。また、ＢＲｅｑ［ｅｘｔ］前に、信号が、任意の既存のポリシを指定変更する新しいＦＰ値を搬送していることもある。このような場合には、新しいＦＰが強制されるべきである。明示的信号の期間は、ＭＮがＩＰパケットを送受信することのできないハンドオフ期間を包含するはずである。明示的シグナリングは、時間制限バッファリングと共に使用されてもよい。また、明示的シグナリングは、バッファサイズ要件の変更など、ネットワークの動的挙動に対応するのに使用することもできる。
【００７０】
２．１．３．３  エラー条件
バッファリングサービスを強制終了させるバッファリングサービスの間に発生するエラー条件は、否定的ＥＯＳを構成するはずである。ＢＮが限られた回復を実行しようとする場合には、任意の既存のＦＰが強制され得る。しかしながら、一般に、エラー条件は、致命的とみなされるべきであり、サービスに割り振られたすべてのリソース及び状態情報は、システムに解放されるべきである。２．１．７を参照されたい。
【００７１】
２．１．４  フラッシュポリシ
ＢＲｅｑ［ｉｎｉｔｉａｌ］は、ＭＮによって送られる後続のＢＲｅｑと共に、ＥＯＳが満たされた後でＢＮが任意の一時記憶パケットに対して強制するポリシを指図する。ＢＮによって強制されるフラッシュポリシ（ＦＰ）は、一時記憶パケットを転送し、又は一時記憶パケットをドロップし、ＢＣＰ又はＩＣＭＰなどのアウトバンド機構を使ってＭＮに明示的エラー通知を送る。ＭＮからのＢＲｅｑ［ｉｎｉｔｉａｌ］は、バッファリングサービスが、デフォルトのＦＰを指定変更する後続のＢＲｅｑ［ｅｘｔ］を受け取らずに終了した後でＢＮによって強制されるデフォルトのＦＰを含む。後続の新しいＦＰを含むＢＲｅｑ［ｅｘｔ］は、前に確立されたあらゆるＦＰを指定変更する。
【００７２】
２．１．５  パケット転送
既存のＦＰが、肯定的ＥＯＳ後に一時記憶パケットを転送するとき、ＢＮは、一時記憶パケットをフラッシュし始めるときに、ＭＮの現在のＣｏＡを知っていることができなければならない。ＭＮの現在のＣｏＡは、ＢＮに登録されているものと同じであることもあり、ＭＮが、ＢＮに登録した後でこれのＣｏＡを変更している場合には、異なることもある。ＢＣＰを任意のモビリティ管理プロトコルと協働させるために、ＢＣＰ自体が、ＢＮが一時記憶パケットをフラッシュし始めるときに、ＢＮにＭＮの現在のＣｏＡを指示する機構を有する。これは、ＢＲｅｑ［ｓｔｏｐ］メッセージにＭＮの現在のＣｏＡを含めることによって実現される。ＢＲｅｑ［ｓｔｏｐ］が送られない、セクション２．１．３．１で説明している時間制限バッファリングの場合、ＢＣＰは、ｂｐが満了する前に、ＢＲｅｑ［ｅｘｔ］信号にＣｏＡを含めてもよい。ＢＮは、異なるＣｏＡを有するＭＮによって複数のＢＲｅｑ［ｅｘｔ］が送られた場合、最後に送られたＣｏＡを使用してもよい。
【００７３】
好ましくは、一時記憶パケットのフラッシュ及び一意記憶パケットの転送は、以下のように実行される。
【００７４】
ＭＮとＢＮが同じＩＰサブネット上にある場合、一時記憶パケットは、アドレス解決プロトコル（ＡＲＰ）を使って、ローカルでＭＮに送られる。そうでなく、ＭＮとＢＮが異なるＩＰリンク上にある場合、一時記憶パケットは、ＭＮに向かってこれの次のホップルータに送られ、ＩＰ経路指定を使ってＭＮに経路指定される。後者の場合、一時記憶パケットは、ＢＮとＭＮの現在のＣｏＡの間のＩＰトンネルで搬送され得る。このＩＰトンネルは、バッファリングを停止させるための明示的シグナリングを実行する前に存在しない場合には、ＢＲｅｑ［ｓｔｏｐ］とＢＡｎｓの交換又はｂｐ満了を介した明示的シグナリングによって確立される。ＢＮは、ＩＰトンネル確立の一部として、現在のＣｏＡと、前のネットワークにおけるＭＮのＣｏＡの間のマッピングを維持なければならない。この場合、一時記憶パケットのＩＰ経路指定が、結果としてＩＰトンネルを介したパケットの転送をもたらし得る。このＩＰトンネルが、ＦＭＩＰ６［３］などのモビリティ管理／最適化プロトコルを介して確立される場合、トンネルは、別のトンネルを作成するのでなく、一時記憶パケットを転送するのに使用される。
【００７５】
ＭＮとＢＮが異なるＩＰリンク上にある場合に、ＩＰトンネルを作成することの代替として、ＢＮは、一時記憶ＩＰパケットの宛先アドレスを変更することができる。転送時、ＢＮは、一時記憶パケットの宛先ＩＰアドレスを現在のＣｏＡに設定することができる。この場合、パケットは、現在のＣｏＡに向けて通常のＩＰ経路指定を介して転送されることになる。これは、ＭＮへのＩＰトンネルを確立し、維持することに伴う余計な管理を低減する。また、これは、ＩＰモビリティ管理プロトコルがトンネリング機能を利用できない場合、又はモビリティ管理プロトコルが使用されない場合にも役立つ。
【００７６】
２．１．６  ネットワークにおけるＢＮの場所
ＢＮは、ＭＮとＣＮの間の通信パス上にある任意のノード上に配置され得るが、ＢＮは、図１に示すように、ＭＮがハンドオフ前に接続される前のアクセスルータの所、又は図２に示すように、ＭＮがハンドオフ後に接続される新しいアクセスルータの所に配置するのが好ましい。図２には、事前認証／プロビジョニングを伴うパケットバッファリングが示されており、ＢＮ２１４が新しいネットワーク上に位置する場合には、ＭＮが移動する前に、何らかの事前認証及び事前プロビジョニングが行われるものと仮定され得る。事前プロビジョニング手順は、ＢＮが、ＭＮのアドレスを、モビリティプロトコルの助けを借りずに、移動前でさえも決定することができるようにする。しかしながら、いかなる場合でも、ＢＮが前のネットワークに位置していようとも、新しいネットワークに位置していようとも、同じアーキテクチャを適合させることができ、ＢＮとＭＮの間の対話は変わらない。
【００７７】
アクセスルータ２０４は前のネットワーク２１６にあり、アクセスルータ（ＢＮ）２０５は、新しいネットワーク２１８にある。流れ線２０６はＣＮ２０２とＭＮ２００の間のハンドオフ前トラフィックを表す。流れ線２１０は、通信相手ノード２０２とＭＢ２００の間のハンドオフ後トラフィックを表す。流れ線２１２は、ＣＮ２０２とＢＮ２１４の間の一時記憶トラフィックを表す。流れ線２０８は、ＭＮ２００とＢＮ２１４の間のシグナリングを表す。
【００７８】
ＢＮの別の場所を、図３に示すように、ＭＮ自体の内部とすることができる。アクセスルータ３１４は、新しいネットワーク３０２にあり、アクセスルータ３１８は前のネットワーク３００にある。流れ線３１２は、ＣＮ３０４とＭＮ３２４の間のバッファに記憶されたトラフィックを表す。
【００７９】
流れ線３０６は、ＭＮからＣＮへのハンドオフ前トラフィックを表す。流れ線３０８は、ＭＮとバッファノード３１０の間のシグナリングを表す。流れ線３１６は、ＢＮ３１０からＣＮ３０４へのハンドオフ後トラフィックを表す。
【００８０】
これに関して、図３に、ＭＮ３２４内に位置する、発信パケットのためのバッファリングノード（ＢＮ）を示す。この場合、ＢＮは、ハンドオフ期間中にＭＮの発信パケットへのバッファリングサービスとして働く。これの使用は、前に開示したＢＮの場所と相互に排他的であり、これらを補完するものである。ＢＮがＭＮ内に存在すれば、双方向バッファリングが実現され得る。前の場所と同様に、ＢＮのアーキテクチャ及びＢＮのＭＮとの対話は変わらない。
【００８１】
また、ＢＮがＭＮ内に存在すると、ハンドオフ時のピンポン現象の場合に役立つ。ピンポン現象は、ＭＮが新しいネットワークでハンドオフを完了するのに失敗し、前のネットワークへの関連付けし直すときなどに発生する。このような場合、ＢＮは、失敗したハンドオフ試行時に失われている可能性のあるパケットの回復機構として働く。ＭＮにおいて発信トラフィックのためにバッファリングが行われるとき、一時記憶パケットの転送挙動は、もっぱら、各パケットの宛先アドレスによって決定される。加えて、ＭＮで発信パケットをバッファに入れる際には外部シグナリングは不要である。参照文献［１１］では、輻輳制御を提供するための発信トラフィックのバッファリングが論じられているが、モビリティシナリオについては明確に論じられていない。
【００８２】
また、ＢＮは、ＭＮが、新しいアクセスポイントを探し、又は新しいアクセスポイントへの接続性を試すためにアクティブにスキャンしているときに、パケットをバッファに一時記憶するのを助けるために前のアクセスポイント内に位置していてもよい。
【００８３】
２．１．７  エラー条件
エラー条件又は否定的ＥＯＳは、以下の理由で発生し得る。
【００８４】
２．１．７．１  サービスを提供することのできないＢＮ
ＢＮは、リソース限界のために応じることのできない、ＭＮのＢＲｅｑ［ｉｎｉｔｉａｌ］を受け取ることがある。これは、ＢＮのリソースが、他のＭＮに提供されている既存のバッファリングサービスのためにすでに限られているときに起こり得る。また、これは、ＢＮが、ＢＲｅｑ［ｉｎｉｔｉａｌ］でＭＮによって課されているパラメータが、システムによって提供され得る合計リソース量より大きい場合にも起こり得る。このような場合、ＢＮは、ＭＮにこの障害を、ＭＮにＢＮが要求されたサービスを提供できないことを通知するＢＡｎｓ［ｉｎｉｔｉａｌ］として伝えることができる。ＢＮは、要求されたサービスのどんな状態情報も保持する必要はない。ＭＮは、調整された値を有する新しいＢＲｅｑ［ｉｎｉｔｉａｌ］を再提出しようとしてもよい。このような場合、ＢＮは、これを新しいサービスの要求として扱う。
【００８５】
２．１．７．２  バッファオーバフロー
バッファオーバフローは、セクション２．１．３で説明しているように、ＢＮによって待ち行列に入れられているパケットの数が、バッファＥＯＳが満たされる前に、割り振られたバッファの容量を超えたときに発生する。このような場合、ＢＮがＭＮにこの状況を伝え、ＢＲｅｑ［ｅｘｔ］を介してバッファリング期間の延長などの後続処置を取り決めることができないこともある。ＭＮは、ハンドオフプロセスの最中である可能性もあり、このため、ＢＮは、以前に構成された管理ポリシに基づいて以下の処置を講じる必要がある。
【００８６】
２．１．７．２．１  バッファ期間終了が満たされるまでのテールドロップ
回復可能な環境を提供するために、ＢＮは、現在バッファに記憶されているパケットだけを維持し、この後の新着パケットをドロップ（テールドロップ）しようとすることができる。バッファ期間終了が満たされると、ＢＮは、２．１．４で説明しているように、既存のＦＰを強制することができる。これは、ＢＮが、ＭＮが失うことになるパケットの数を制限することを可能にする。
【００８７】
２．１．７．２．２  バッファリングサービスの終了
回復可能性が求められておらず、又はリソース限界のために不可能な状態では、ＢＮは、バッファリングサービスを完全に終了し、これに関連付けられたすべてのリソースを解放しようとしてもよい。このような場合、ＭＮは、後続のＢＲｅｑ／ＢＡｎｓシグナリングが交換された後で、ＢＮの処置を知ることができる。ＢＮは、バッファ期間終了が満たされたときにこのようなシグナリングが行われない場合には、関連付けられたバッファリングサービスのために保持しているすべての関連状態を黙って廃棄することができる。
【００８８】
２．１．７．３  シグナリング障害（バッファ制御プロトコル障害）
シグナリング障害は、バッファ制御プロトコルエラーが発生したときに発生する。バッファ制御プロトコル（ＢＣＰ）は、再送信、及びこのイベントを指示することのできるエラー処理機能を提供する。ＢＮは、セクション３．５で論じるように、エラーの重大度に応じてしかるべく対処することができる。
【００８９】
２．１．７．４  システム／ホスト障害
システム障害は、メモリ枯渇、全ネットワーク接続障害、又はＢＮがあるホスト又はシステムが、不安定で使用不能な状態になる他の障害を含み得る。このような状態をもたらす任意のイベント又は条件が、致命的であるとみなされ、ＢＮを動作不能にし得る。このようなイベントの発生時にＢＮによって講じられる処置は、条件の重大度及びシステムで実施されている回復可能性の方式よって決まる。このような場合、ＢＮの可用性は、ＢＮの実現形態によって決まる。
【００９０】
２．２．要件
パケットが転送中にバッファに入れられるときに、シームレスなトラフィックフローを実現するために課されるべき制限がある。
【００９１】
２．２．１  一時記憶パケットの優先度
パケットが誤った順序での配信されるのを回避するために、一時記憶パケットの優先度が、あらゆる新着のハンドオフ後のパケットに対して維持される必要がある。肯定的ＥＯＳが満たされ、ＢＮが一時記憶パケットを転送することが必要になると、ＢＮは、一時記憶パケットが、確実に、ＭＮに向けられたどんな新着のパケットよりも前にＭＮに転送されるようにしなければならない。これが必要なのは、ＭＮに送られるパケットの順序を維持するためである。これを達成する方法は、大部分は実現形態に特有のものであり、システムで利用可能な機構に依存する。一般的な方法は以下の通りである。
【００９２】
２．２．１．１  ＢＮにおける追加の転送待ち行列
ＢＮのメインバッファ以外に、追加の転送待ち行列が実施されてもよい。この転送待ち行列は、ＢＮのバッファがフラッシュされている間に、ＭＮに向けられた新着のハンドオフ後のパケットを格納するのに使用されてもよい。これは、順次使用される２つのバッファを備えるという効果を有する。バッファのフラッシュは排他的であり、メインバッファが、転送待ち行列により優る高い優先度を有する。例えば、システムは、トラフィック制御待ち行列（すなわち、Ｌｉｎｕｘ（登録商標）トラフィック制御モジュール）を利用して待ち行列優先度を実施することができる。
【００９３】
２．２．１．２  システム受信側待ち行列
システムの中には、着信パケットを、システムによって転送される前にバッファに一時記憶するためのインターフェース受信側待ち行列（ネットワークドライバｒｘ待ち行列）を実施するものがある。ＢＮは、この機能を利用して、この待ち行列に格納されているパケットの処理に取って代わることができる。ＢＮは、システムに取って代わって、システムが、受信側待ち行列に格納されているパケットを経路指定し始める前に、これのバッファをフラッシュする。注意すべきなのは、受信側待ち行列が、このインターフェースでのすべての着信パケットを保持することである。したがって、受信側待ち行列の処理に取って代わることは、一般に、単にＭＮのパケットだけに限らず、すべてのパケットの配信を遅延させることになる。
【００９４】
２．２．２  ＥＯＳ時のフラッシュ及び転送レート
肯定的ＥＯＳ後のＢＮにおけるフラッシュ及び転送レートは、新着のハンドオフ後パケットの受信レートより大きくなければならない。これが該当しない場合、ハンドオフ後パケットを保持する待ち行列（２．２．１．１及び２．２．１．２）が、ＢＮのバッファが空になる前に一杯になる可能性がより大きくなる。これは、ハンドオフ後待ち行列のオーバフローを招き、最終的にはパケット損失をもたらす。フラッシュ及び転送は、ＢＮがシステム内の他のすべての処置に取って代わる場合（すなわち、スピンロッキング）、もっぱらＢＮのみによって行われ得る。これで、フラッシュ及び転送が、他のどんな転送より前に行われるよう保証することができる。しかしながら、ＢＮは、この手法を用いる場合、長期にわたる優先使用がシステム状態に悪影響を及ぼすこともあるため、大いに注意を払うべきである。いかなる場合にも、解決法は、実現形態に特有のものである。
【００９５】
２．２．３  最大バッファリングサービス期間
サービス期間の限度が、ＢＮで、バッファの最大サイズ、ならびに、セクション２．１．３．１で説明しているｂｐ値の最大期間を定義することによって管理上構成される必要がある。これらの限度は、ＢＮが利用可能なローカルリソースを考慮する必要がある。これらの限度は、折衝不可能な値とみなされるべきである。
【００９６】
２．２．４  ＭＮへの通信リンク
ハンドオフの前と後に、ＭＮとＢＮの間のシグナリング（ＢＣＰ）が存在するものと想定される。
【００９７】
３．バッファリング制御プロトコル（ＢＣＰ）
ＢＣＰは、ＭＮがＢＮにおけるバッファリングサービスを要求するのに使用される制御プロトコルである。ＢＣＰは、要求と応答の信号対からなる、単純で信頼性の高いメッセージングシステムである。ＢＣＰは、新しいプロトコルとして、又はＰＡＮＡや、ＳＩＰや、モバイルＩＰ（ｖ４／ｖ６）などの既存のプロトコルの拡張として定義されてもよく、リンク層プロトコルの拡張として定義されてもよい。例えば、モバイルＩＰｖ６では、ＢＣＰをＴＬＶ形式で搬送するバインディング更新／確認メッセージ交換における新しいモビリティオプションを定義することが可能である。ＰＡＮＡでは、ＰＵＲ／ＰＵＡメッセージ交換に付加され得るＢＣＰ  ＡＶＰを定義することが可能である。ＢＣＰシグナリングの要件が受け入れられる限り、他の方法が用いられてもよい。いかなる場合にも、ＢＣＰ信号の配信及び符号化は、ＢＣＰを搬送するプロトコルごとに特有のものとなり得る。
【００９８】
３．１  プロトコル信号
原則として、要求信号は、ＭＮからＢＮに送られ、応答信号は、要求信号に応答して、ＢＮによってＭＮに送られる。ＢＮが要求信号を生成することは絶対にない。要求信号は、要求に関するパラメータを搬送し、応答信号は結果コードを含む。送信タイムアウト、再送信及びエラー処理挙動を使用することによって信頼性がサポートされる。ＢＣＰは、以下の信号対を使用する。
【００９９】
３．１．１  ＢＲｅｑ［ｉｎｉｔｉａｌ］及びＢＡｎｓ［ｉｎｉｔｉａｌ］
これらの信号は、常に、ＭＮとＢＮの間で最初に交換されるべきものである。これらの信号は、セクション３．３．１で説明するように、バッファリングサービスを確立するのに使用される。これらの信号は以下の形式を有する。
【０１００】
ＢＲｅｑ［ｉｎｉｔｉａｌ］＝｛ｉｄ，ｂｐ，ｔｃ，ｂｓｚ，ｐ｝
ｉｄ−ＢＮに対してＭＮを一意に識別するのに使用されるＭＮのＩＤ。これは、ＭＮのＭＡＣアドレス又はソースアドレスとすることができる。
【０１０１】
ｂｐ−バッファリング期間
ｔｃ−分類され、バッファに一時記憶されるべきアプリケーション特有のトラフィック
ｂｓｚ−割り振られるべき推奨バッファサイズ
ｐ−ＥＯＳのＦＰ、有効な値は、ドロップ、転送又は信号を伴うドロップ
ｆｌａｇ｛ｍ｝−要求フラグ
ｍ−設定される場合、ｂｓｚは必須であり、折衝され得ない
ＢＡｎｓ［ｉｎｉｔｉａｌ］＝｛ｉｄ，ｂｐ，ｂｓｚ，ｒｃｏｄｅ｝
ｉｄ−ＢＮに対してＭＮを一意に識別するのに使用されるＭＮのＩＤ。これは、ＭＮのＭＡＣアドレス又はソースアドレスとすることができる。
【０１０２】
ｂｐ−このサービスのバッファリング期間
ｂｓｚ−このサービスに割り振られるバッファサイズ
ｒｃｏｄｅ−ＢＮによって提供される結果コード
３．１．２  ＢＲｅｑ［ｅｘｔ］及びＢＡｎｓ［ｅｘｔ］
これらの信号は、バッファリングサービスを確立した後、ＭＮのハンドオフ期間の前又は後に交換される。これらは、セクション３．３．２で説明するように、バッファリングサービスのパラメータを延長するのに使用される。
【０１０３】
ＢＲｅｑ［ｅｘｔ］＝｛ｉｄ，ｓｅｑ，ｂｐ，ｂｓｚ，ｐ，ｃｏａ｝
ｉｄ−ＢＲｅｑ［ｉｎｉｔｉａｌ］で送られるＭＮのＩＤ
ｓｅｑ−信号の連番
ｂｐ−追加のバッファリング期間、ゼロ（０）でもよい
ｂｓｚ−追加のバッファサイズ、ゼロ（０）でもよい
ｐ−ＥＯＳの新しいＦＰ、有効な値は、ドロップ、転送又は信号を伴うドロップ
ｃｏａ−ＭＮの現在のＣｏＡ
ＢＡｎｓ［ｅｘｔ］＝｛ｉｄ，ｓｅｑ，ｂｐ，ｂｓｚ，ｒｃｏｄｅ｝
ｉｄ−ＢＲｅｑ［ｉｎｉｔｉａｌ］で送られるＭＮのＩＤ
ｓｅｑ−信号の連番、ＢＲｅｑ［ｅｘｔ］と合致しなければならない
ｈｐ−このサービスの新しいバッファリング期間
ｂｓｚ−このサービスに割り振られる新しいバッファサイズ
ｒｃｏｄｅ−ＢＮによって提供される結果コード
３．１．３  ＢＲｅｑ［ｓｔｏｐ］及びＢＡｎｓ［ｓｔｏｐ］
これらの信号は、セクション３．３．３で説明するように、バッファリングサービスを停止させるために交換される。
【０１０４】
ＢＲｅｑ［ｓｔｏｐ］＝｛ｉｄ，ｐ，ｃｏａ｝
ｉｄ−ＢＲｅｑ［ｉｎｉｔｉａｌ］で送られるＭＮのＩＤ
ｐ−ＥＯＳの終了ＦＰ、有効な値は、ドロップ、転送又は信号を伴うドロップ
ｃｏａ−ＭＮの現在のＣｏＡ
ＢＡｎｓ［ｓｔｏｐ］＝｛ｉｄ，ｒｃｏｄｅ｝
ｉｄ−ＢＲｅｑ［ｉｎｉｔｉａｌ］で送られるＭＮのＩＤ
ｒｃｏｄｅ−ＢＮによって提供される結果コード
３．２  サービス属性
ＢＣＰは、ＢＮ内のサービス属性（状態情報）も作成する。これらの属性は、以下のものを含むことができる。
【０１０５】
ＭＮのＩＤ（ｉｄ）、
バッファリング期間（ｂｐ）、
折衝されたバッファサイズ（ｂｓｚ）、
トラフィック分類（ｔｃ）パラメータ、
ＦＰ、現在のＥＯＳフラッシュポリシ、
最新の延長要求の連番、
現在のＭＮのＣｏＡ、
前のＭＮのＣｏＡ。
【０１０６】
これらの属性は、セクション３．３．１で説明するように、要求フェーズの間に割り振られ得る。属性の値は、有効な要求信号又は他のローカルイベントを受け取ったときに、ＢＮによって更新される。属性存続期間は、サービスの期間に制限される。肯定的又は否定的ＥＯＳが満たされた場合、ＢＮは、これらの属性によって占められているリソースを解放する。
【０１０７】
３．３  サービスフェーズ
一般に、ＢＣＰは、ＢＮサービスを３つのフェーズに分けることができる。バッファリングサービスは、これらのフェーズを順次完了しなければならない。
【０１０８】
３．３．１  サービス要求フェーズ
サービス要求フェーズは、ＭＮのバッファリングサービスを確立するのに使用される初期フェーズである。このフェーズは、バッファリング要件を折衝し、ＢＮがこれらの要件を満たすことができるかどうか決定するための、ＭＮとＢＮの間の単一のＢＲｅｑ［ｉｎｉｔｉａｌ］／ＢＡｎｓ［ｉｎｉｔｉａｌ］信号交換の期間にわたる。ＢＮがＭＮに対応することができる場合、状態情報が割り振られ、ＭＮトラフィックのバッファリングが直ちに開始する。次いで、ＢＮは、成功を示す結果コード（ｒｃｏｄｅ）と共に、ＭＮにＢＡｎｓ［ｉｎｉｔｉａｌ］を送る。ＢＮが、ＭＮによって提供されたヒント値への調整を行っており、サービスを提供することができる場合、バッファリングサービスは、この場合もやはり、エラーを示すｒｃｏｄｅを含むＢＡｎｓ［ｉｎｉｔｉａｌ］で開始される。ＢＮがサービスを提供することができない場合には、状態情報が割り振られず、ＢＮは、適切なエラーコードと共にＢＡｎｓ［ｉｎｉｔｉａｌ］を送る。ＭＮは、初期ＢＲｅｑ［ｉｎｉｔｉａｌ］で以下のパラメータを送る。
【０１０９】
３．３．１．１  バッファリング期間
ＭＮは、ハンドオーバ期間の推定値とすることもできる、バッファリング期間の長さについての事前知識を有し得るため、ＭＮは、この値をＢＮに送ることができる。ＢＮは、セクション２．２．３で説明しているように、この値がローカルで構成された最大限度を超えない場合には、この値をｂｐに使用することができる。この値が最大限度を下回る場合、ＢＮは、ＢＡｎｓ［ｉｎｉｔｉａｌ］で成功を指示するｒｃｏｄｅを設定すべきである。この値が最大限度を超える場合、ＢＮは、バッファリング要求を拒否し、又は最大限度をｂｐ値として使用することができる。どちらの場合にも、ＢＮは、ＢＡｎｓ［ｉｎｉｔｉａｌ］でエラーを指示するｒｃｏｄｅを設定することによって、ＭＮに、これの決定を通知する必要がある。ＭＮには、ＢＮが、ＭＮが不適切であると認める最大値を使用する場合、サービスを終了させるという選択肢もある。このような場合、ＭＮは、セクション３．３．３で説明するように、直ちに終了フェーズに進むことができる。
【０１１０】
３．３．１．２  バッファサイズ（ｂｓｚ）
ＭＮは、サービスの間ＢＮによって使用されるべきｂｓｚを推奨することができる。これが可能なのは、ＭＮが、使用されるアプリケーション、したがって、予期されるトラフィックレート及びチャネル条件についての事前知識を有し得るからである。ハンドオフ期間と組み合わせて、ＭＮは、分類されたトラフィックに対応するのに必要とされる妥当なｂｓｚを計算することができる。しかしながら、ＭＮによって提供されるｂｓｚは、ＢＮに対するヒントにすぎない。ＢＮは、ローカルで利用可能なリソースに基づく、使用されるべき実際のｂｓｚに関する最終権限を有する。ＢＮは、ＭＮによって示唆されたｂｓｚに対応できる場合、ＢＡｎｓ［ｉｎｉｔｉａｌ］で成功を指示するｒｃｏｄｅを設定してもよい。ＢＮは、ヒント値に対応することができない場合、ローカルで構成された最大限度を使用し、ＢＡｎｓ［ｉｎｉｔｉａｌ］でエラーを指示するｒｃｏｄｅを設定することによって、ＭＮに、これの決定を通知してもよい。ＭＮには、ＢＮによって発行されたｂｓｚが不適切である場合には、サービスを終了させるという選択肢もある。このような場合、ＭＮは、セクション３．３．３で説明するように、終了フェーズに直ちに進むことができる。
【０１１１】
３．３．１．３  トラフィック分類（ｔｃ）
デフォルトでは、ＭＮに向けられたすべてのトラフィックが、バッファリング期間中、ＢＮによってバッファに一時記憶される。しかしながら、ＭＮは、バッファに記憶する必要のあるトラフィックの種類に関するパラメータを提供してもよい。これは、ＭＮが、ある特定の種類のトラフィック（ｔｃ）だけをバッファに記憶しようとする場合である。ｔｃパラメータの形式は実現形態に特有のものであり、ＭＮは、この実現形態についての事前知識を有することを必要とすることがある。
【０１１２】
３．３．１．４  フラッシュポリシ
ＭＮによって送られたＦＰは、セクション２．１．３で説明しているようにＥＯＳが満たされた後で、ＢＮが一時記憶パケットで強制すべきポリシを決定する。現在サポートされているポリシは、セキュリティ２．１．４で説明しているように、パケットを転送又はドロップすることである。ＢＮが、どんなＥＯＳ時にも一時記憶パケットをドロップするよう指定するＢＲｅｑ［ｉｎｉｔｉａｌ］のＦＰ値は、サービスが無意味になるため、不適切であるように思われる。しかしながら、セクション２．１．３で説明しているように、満たされるＥＯＳ条件に応じて、ＭＮが２つの異なるポリシを強制しようとする場合があり得る。例えば、ＭＮは、時間制限バッファリングＥＯＳが満たされたときに、すべてのパケットをドロップしようとし、明示的シグナリングＥＯＳが満たされたときに、すべてのパケット転送しようとすることがある。このような場合、デフォルトのＦＰは、すべてのパケットをドロップするように設定され、肯定的ＥＯＳを合図する後続のＢＲｅｑ［ｓｔｏｐ］は、すべてのパケットを転送するＦＰを搬送することができる。
【０１１３】
また、ＢＲｅｑ［ｉｎｉｔｉａｌ］で供給されるＦＰは、ヌルに設定されてもよい。このような場合、使用されるＦＰは、ローカルで構成された値とすることができる。
【０１１４】
３．２  バッファリングフェーズ
バッファリングフェーズは、トラフィック分類及びバッファリングが行われている期間にわたる。これは、ＢＮが、要求フェーズで、バッファリングサービスが提供されることを指示するＢＡｎｓ［ｉｎｉｔｉａｌ］で応答した直後に開始し、ＥＯＳ条件が満たされたときに終了する。このフェーズの間、ＢＮとＭＮは、１つ又は複数の延長要求（ＢＲｅｑ［ｅｘｔ］／ＢＡｎｓ［ｅｘｔ］）を交換することができる。各交換は、延長要求折衝を完了する。延長要求は、ＭＮが、要求フェーズ又は前の延長要求交換の間に確立されている属性値を再折衝することを可能にする。延長要求は、バッファリングサービスが延長され得るようにする。また、この期間には、バッファリングサービスを打ち切るためのＢＲｅｑ［ｓｔｏｐ］／ＢＡｎｓ［ｓｔｏｐ］交換も行われ得る。このような場合、ＢＲｅｑ［ｓｔｏｐ］で供給されるＦＰは、すべての一時記憶パケットをドロップするポリシを強制してもよい。
【０１１５】
延長要求を行うときには、信号交換がハンドオフ期間の前又は後に行われるため、注意を払う必要がある。よって、ＭＮは、信号交換時にネットワーク接続を利用できるようにするために、信号交換をハンドオフ期間と同期させる。
【０１１６】
ＢＲｅｑ［ｉｎｉｔｉａｌ］と対称的に、ＢＲｅｑ［ｅｘｔ］によって提供されるパラメータは、既存の属性値に追加される。ＦＰを除いて、結果として生じる新しい値は、セクション３．３．１の初期値に課されるのと同じ制限及び条件に制約され得る。ＭＮは、あらゆるＢＲｅｑ［ｅｘｔ］で以下のパラメータを送る。
【０１１７】
３．３．２．１  バッファリング期間
ＭＮは、ＢＮに、ＢＲｅｑ［ｅｘｔ］信号で追加のハンドオフ遅延を通知してもよい。ＢＲｅｑ［ｅｘｔ］で提供されるハンドオフ値は、既存のハンドオフ属性値に追加され、セクション３．３．１．１．で指定されている制限及び条件に従う。このプロセスは、ＢＮによって受け取られる新しいＢＲｅｑ［ｅｘｔ］ごとに繰り返される。ＭＮがこの特定の値を調整しようとしない場合には、このパラメータはゼロ（０）に設定されてもよい。
【０１１８】
３．３．２．２  バッファサイズ（ｂｓｚ）
ＭＮは、ＢＮに、延長要求にどれ程多くのｂｓｚが必要とされるかについてのヒントを提供してもよい。ＢＲｅｑ［ｅｘｔ］で提供されるｂｓｚ値は、既存のｂｓｚ属性値に追加され、セクション３．３．１．１で指定されている制限及び条件に従う。このプロセスは、ＢＮによって受け取られる新しいＢＲｅｑ［ｅｘｔ］ごとに繰り返される。ＭＮは、この特定の値を調整しようとしない場合、このパラメータをゼロ（０）に設定してもよい。
【０１１９】
３．３．２．３  フラッシュポリシ
ＭＮは、ＢＲｅｑ［ｅｘｔ］を使って、現在のバッファリングサービスの新しいデフォルトＦＰを設定してもよい。ＢＮは、ＥＯＳが満たされたときに、新しいＦＰを強制する。ＢＲｅｑ［ｅｘｔ］で供給されるＦＰがヌルである場合、これは、ＢＮに、既存のＦＰ属性値を維持するよう指示するものである。既存の属性値がヌルである場合、ＢＮは、ＦＰ属性値を、ローカル構成値に設定すべきである。
【０１２０】
３．３．２．４  ＣｏＡ情報
また、ＢＲｅｑ［ｅｘｔ］は、セクション２．１．５で説明している転送を円滑化するために、ＭＮのＣｏＡを更新するのに使用することもできる。ＢＲｅｑ［ｅｘｔ］でＣｏＡを搬送することは、時間制限タイムアウトが、肯定的ＥＯＳを満たすために明示的シグナリングに取って代わる場合には必要である。また、ＢＲｅｑ［ｅｘｔ］にＣｏＡパラメータを含むことによって、ＢＣＰ及びＢＮは、アーキテクチャ的に、使用されている状況に依存しなくなる。例えば、ＭＮ上にあるＢＮは、図３に示すように、セクション２．１．６で論じられているピンポン現象の場合、ＢＮに、これの前のＣｏＡを通知することができる。
【０１２１】
３．３．３  終了フェーズ
終了フェーズは、セクション２．１．３で説明しているように、ＥＯＳが満たされたときに開始し、バッファリングサービスに割り振られたすべてのリソースがシステムに解放されたときに終了する。肯定的ＥＯＳが満たされ、転送ポリシが強制されるとき、ＢＮは、セクション２．１．５及びセクション２．２で説明している転送要件に従う必要がある。明示的シグナリングの場合、バッファリングサービスを終了させるために、ＭＮとＢＮの間でＢＲｅｑ［ｓｔｏｐ］／ＢＡｎｓ［ｓｔｏｐ］が交換される。ＭＮは、信号交換の間にネットワーク接続が行われるようにするために、ハンドオフ期間と同期を取る必要がある。また、明示的ＢＲｅｑ［ｓｔｏｐ］は、ＭＮがバッファリングサービスを打ち切るのにも使用され得る。サービスは、ＭＮが、パケットのドロップを強制するＦＰを伴うＢＲｅｑ［ｓｔｏｐ］を送信するときに打ち切られる。ＢＲｅｑ［ｓｔｏｐ］は、以下のパラメータを有する。加えて、ＢＮが、一時記憶パケットのＭＮへの転送を実行しようとしており、ＭＮとＢＮが異なるＩＰリンク上にあり、ＢＮとＭＮの間にトンネルがない場合、ＢＮは、ＭＮへの新しいトンネルも作成する。
【０１２２】
３．３．３．１  フラッシュポリシ
終了フェーズの間、ＢＮは、ＢＲｅｑ［ｓｔｏｐ］で供給されたＦＰを強制する。ＢＲｅｑ［ｓｔｏｐ］で供給されたＦＰがヌルである場合、ＢＮは、既存のＦＰ属性値を強制する。転送を指定するＦＰは、セクション２．２の転送要件に従う。
【０１２３】
３．３．３．２  ＣｏＡ情報
ＢＲｅｑ［ｓｔｏｐ］信号がＣｏＡ情報を搬送する場合、これは、ＢＲｅｑ［ｅｘｔ］で搬送された前のＣｏＡ情報の指定変更を行い、一時記憶パケットを転送するときに使用されるはずである。また、ＢＲｅｑ［ｓｔｏｐ］は、ＩＰネットワークにある新しいＣｏＡがこれのホームと異なる場合に、ＩＰ−ＩＰトンネルを確立する信号としても使用され得る。詳細はセクション２．１．５に示されている。
【０１２４】
３．４  プロトコル信号の流れ
図４に示すプロトコルの流れは、ＭＮハンドオフ、トラフィック分類及びバッファリングに関連する際の、信号交換の一般的な順序を示すものである。変数ｏ１及びｏ２は、バッファリングフェーズの間にネットワーク接続が存在し得るときに、有効なＭＮ及びＢＮが生じ得る期間を定義するものである。
【０１２５】
３．５  プロトコル信頼性
ＢＣＰは、別の信号交換を開始する前に既存の信号交換を完了することを必要とするロックステッププロトコルである。これは、ＢＮにおける状態遷移及び再送信時の硬直性を簡略化する。
【０１２６】
ＢＣＰは、送信タイムアウト及び再送信を使ってシグナリングの障害を検出する。要求信号だけが再送信される。ＭＮは、要求を送り、指定されたタイムアウト期間内に応答を受け取らなかった場合、要求を再送信する必要がある。最大回数の再送信が行われた後で応答が受け取られなかった場合、ＭＮでエラー条件が発生する。送信タイムアウトも、最大再送信回数も、全体的遅延を最小限に抑えるために、妥当な値とすべきである。ＢＮによって送られる応答信号は再送信されない。ＢＮは、どんな再送信要求に対しても同じ応答信号で応答すべきである。ＭＮとの接続が完全に失われた場合、ＢＮは、ｈｐ値を利用してバッファリングサービスを終了させることができる。
【０１２７】
ＢＲｅｑ［ｅｘｔ］では、ＢＮは、この信号に関連付けられた連番を利用して、受け取ったＢＲｅｑ［ｅｘｔ］が再送信であるかどうか判定する必要もある。ＢＮによって送られるＢＡｎｓ［ｅｘｔ］信号は、応答に関連付けられたＢＲｅｑ［ｅｘｔ］の連番と等しい整合する連番を供給しなければならない。これが必要なのは、複数のＢＲｅｑ［ｅｘｔ］／ＢＡｎｓ［ｅｘｔ］交換が行われ得るからである。ＢＲｅｑ［ｉｎｉｔｉａｌ］／ＢＡｎｓ［ｉｎｉｔｉａｌ］信号及びＢＲｅｑ［ｓｔｏｐ］／ＢＡｎｓ［ｓｔｏｐ］信号は、これらの交換が、それぞれ、バッファリングサービスの開始時と終了時に１度だけしか行われないはずであるため、連番チェックを必要としない。また、信号の妥当性は、連番の値をチェックすることによっても補足され得る。
【０１２８】
３．６  ネットワークにおけるＢＮ利用可能性の発見
ＭＮは、バッファリングサービスの利用可能性を発見するために、既存のネットワークと、ＭＮがそこに向かいつつある新しいネットワークの両方のネットワークエンティティに、ＢＲｅｑ［ｉｎｉｔｉａｌ］を送ろうとすることができる。ＭＮは、ネットワークエンティティからの応答がないことを使って、どちらのネットワークがバッファリングサービスを提供しないか指示することができる。応答の欠如は、ＭＮが、応答を受け取らずに最大回数の再送信試行に達したときとして定義されるべきである。ＭＮがどちらのネットワークからも応答を受け取らなかった場合、サービスは存在しない。ＭＮが両方のネットワークから応答を受け取った場合、ＭＮは、どちらのネットワークがサービスを提供することになるか選択し、選択しなかったネットワークにおける要求を打ち切る必要がある。代替として、バッファリングサービスの利用可能性は、ＤＮＳやＤＨＣＰなど既存の機構によっても提供され得る。
【０１２９】
３．７  セキュリティでの考慮事項
ＢＣＰは、固有のセキュリティを提供しない。ＢＣＰは、セクション３．８で説明するように、下位層、ＩＰ層（すなわちＩＰｓｅｃ）又はＢＣＰを搬送する親プロトコルによって提供されるセキュリティを利用する。
【０１３０】
３．８  実現形態での考慮事項
ＢＮ実現形態は、システム上にある方法及び機能を利用してもよい。例えば、Ｌｉｎｕｘシステムでは、トラフィック分類を、ネットフィルタ（ｉｐｔａｂｌｅ）又はトラフィック制御モジュールを使って行うことができる。これらのツールを使ってフローごとに、複雑な分類規則がインストールされ得る。加えて、バッファリングは、トラフィック制御モジュールをＢＮ特有の制御と共に使っても実現することもできる。
【０１３１】
発明の広い適用範囲
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明する様々な好ましい実施形態だけに限定されるものではなく、本開示に基づき、当分野の技術者によって理解されるはずの、同等の要素、改変、省略、（様々な実施形態にまたがる態様などの）組み合わせ、適合及び／又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられている言語に基づいて広く解釈されるべきであり、本明細書において、又は本願の出願手続中に示される例だけに限定されるものではなく、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「好ましくは、しかしそれだけに限らないが」を意味する。
【０１３２】
本開示及び本願の出願手続中において、手段プラス機能限定又はステッププラス機能限定は、特定の請求項限定について、この限定に、ａ）「〜の手段」又は「〜のステップ」が明示的に記載されている、ｂ）対応する機能が明示的に記載されている、及びｃ）構造、材料又はこの構造を支持する動作が記載されていないという条件すべてが存在する場合に限って用いられる。本開示及び本願の出願手続中において、「本発明」又は「発明」という用語は、本開示内の１つ又は複数の態様に言及するものとして使用され得る。本発明又は発明という言葉は、重要度を識別するものであると不適切に解釈されるべきではなく、すべての態様又は実施形態にまたがって適用されるものであると不適切に解釈されるべきでなく（すなわち、本発明はいくつかの態様と実施形態を有すると理解されるべきであり）、本願又は特許請求の範囲を限定するものであると不適切に解釈されるべきではない。本開示及び本願の出願手続中において、「実施形態」という用語は、任意の態様、機能、プロセス又はステップ、これらの任意の組み合わせ、及び／又はこれらの任意の部分などを示すのに使用され得る。いくつかの例では、様々な実施形態が、重なり合う機能を含んでいることがある。本開示では、「例えば」を意味する「ｅ．ｇ．」という省略用語が用いられることがある。
【図面の簡単な説明】
【０１３３】
【図１】ＢＮとして働くアクセスルータを備えるパケットバッファリングモデルを表す図である。
【図２】事前認証／プロビジョニングを伴うパケットバッファリングを表す図である。
【図３】発信パケットのためのＭＮ内に位置するバッファリングノード（ＢＮ）を表す図である。
【図４】ＢＣＰプロトコルの流れを示す図である。
【図１】
2008514034.tif 000003
【図２】
2008514034.tif 000004
【図３】
2008514034.tif 000005
【図４】
2008514034.tif 000006
【国際調査報告】
2008514034.tif 000007
2008514034.tif 000008
2008514034.tif 000009