(57)【要約】  通信パスに沿って、アップストリーム方向及びダウンストリーム方向の両方について、ＱｏＳリソース又はサービスパラメータを相互に予約、監視及び／又は適応化し、ノード接続性の品質が時間的に予測不能に変化することがある動的な、移動体の無線ＩＰネットワークにおいて異なるアクセス技術をサポートするモバイル機器上で実行される対称型リアルタイムサービスを実現する帯域内シグナリングメカニズム内における双方向ＱｏＳ予約手続きのためのメカニズムを提供する。すなわち、本発明が提案する解決方法は、動的な双方向の拘束されたネットワークリソース予約に基づく動的な双方向ＱｏＳ予約帯域内シグナリング法を用いて、従来のＱｏＳ予約メカニズム、特に、無線ネットワーク及び無線アドホックネットワークにおける適応型のリアルタイムサービスを最適化する。ここで、用語「帯域内（in-band）」とは、制御データ及びユーザプレーンデータを分離しない状況を示す。
2007507931.tif 000002
【特許請求の範囲】
【請求項１】
ノード（１０６ａ、１０６ｃ）間の特定のルーティングパスに沿ってリソース制御情報をシグナリングすることにより、移動ノード（１０６ａ）及び通信相手ノード（１０６ｃ）上で実行される対称型リアルタイムマルチメディアアプリケーション及び／又はデータサービスに必要なネットワークリソース及び／又はサービスパラメータを管理するサービス品質（ＱｏＳ）予約方法において、
上記移動ノード（１０６ａ）及び通信相手ノード（１０６ｃ）のために予約された接続のルーティングパスを介して伝送されるメッセージ（４００）内に、該移動ノード（１０６ａ）と通信相手ノード（１０６ｃ）の間で伝送されるリソース制御情報を埋め込むステップ（Ｓ１）と、
ネットワーク（１０４）を介して、両方の方向に同じルーティングパス（代替＃１）を用いて、上記移動ノード（１０６ａ）と通信相手ノード（１０６ｃ）の間でリソース制御情報を伝達するステップ（Ｓ２）とを有するサービス品質予約方法。
【請求項２】
上記移動ノード（１０６ａ）は、両方の方向に同時に、所定の量のネットワークリソースの要求を示すリソース予約要求メッセージを開始するイニシエータとなる（Ｓ３ａ）ことを特徴とする請求項１記載のサービス品質予約方法。
【請求項３】
上記通信相手ノード（１０６ｃ）は、両方の方向に同時に、所定の量のネットワークリソースの要求を示すリソース予約要求メッセージを開始するイニシエータとなる（Ｓ３ａ）ことを特徴とする請求項１記載のサービス品質予約方法。
【請求項４】
上記リソース予約要求メッセージのイニシエータ（１０６ａ、１０６ｃ）は、双方向接続を関連付け、関連するフローの継続期間の間変化しない特定の転送処理を実現する固有の予約識別子（ＩＤ）を生成する（Ｓ４）ことを特徴とする請求項２又は３記載のサービス品質予約方法。
【請求項５】
上記リソース予約要求メッセージの両方の方向について、同時に
ＩＰデータグラム（４００）にピギーバックされたリソース制御情報を用いて、ネットワークリソースを割り当てるステップ（Ｓ５）と、
上記ネットワークリソースを監視するステップ（Ｓ６）とを実行し、
上記予約されたルーティングパスの両方の方向のためのリソース制御情報は、同じＩＰデータグラム（４００）に埋め込まれることを特徴とする請求項２乃至４いずれか１項記載のサービス品質予約方法。
【請求項６】
上記予約の各方向のためのリソース制御情報は、ＩＰデータグラム（４００）のヘッダ拡張（４０１ｃ、４０１ｄ、４０１ｃ’、４０１ｄ’）の一部であるリソース情報要素（４００ａ、４００ｂ）を介してピギーバックされ（Ｓ７）、該各リソース情報要素（４００ａ、４００ｂ）は、一方又は両方のフローの定量化可能なリソースメトリック又は一方又は両方のフローの定量化可能な及び定量化不能なフローコンテキスト情報に関連する個々のフロー又はフロー集合体のフロー属性に関連する予約されたルーティングパスに亘るリソース属性を表すことを特徴とする請求項１乃至５いずれか１項記載のサービス品質予約方法。
【請求項７】
上記リソース情報要素（４００ａ、４００ｂ）は、リソース予約要求メッセージのイニシエータから受け手へのアップストリーム方向、又はリソース予約要求メッセージの受け手からイニシエータへのダウンストリーム方向、又は両方の方向に、リソース制御情報を記述し、上記アップストリーム方向及びダウンストリーム方向は、予約手続きにおける、上記リソース予約要求メッセージのイニシエータ又は受け手としての役割のために、上記移動ノード（１０６ａ）及び通信相手ノード（１０６ｃ）によって一意的に特定されることを特徴とする請求項６記載のサービス品質予約方法。
【請求項８】
上記リソース情報要素（４００ａ、４００ｂ）は、各フローについて、モジュール式に組織化され、上記リソース制御情報を提供したノード（１０６ａ、１０６ｃ）は、ＩＰデータグラムヘッダ（４０１ｃ、４０１ｄ、４０１ｃ’、４０１ｄ’）に格納されるリソース情報要素（４００ａ、４００ｂ）の数を判定する（Ｓ８）ことを特徴とする請求項６記載のサービス品質予約方法。
【請求項９】
上記各リソース情報要素（４００ａ、４００ｂ）は、上記監視された属性値のためのフィールド（５０３）及び各リソース属性の最大値を定義する上側の閾値及び／又は最小値を定義する下側の閾値により記述されるリソース属性固有のフロー要求を指定する属性要求仕様フィールド（５０４、５０５）を有することを特徴とする請求項１乃至８いずれか１項記載のサービス品質予約方法。
【請求項１０】
上記移動ノード（１０６ａ）と通信相手ノード（１０６ｃ）の間の予約されたルーティングパス（代替＃１）に沿って、上記予約の両方の方向について、使用可能なリソースに関する情報を同時に監視するステップ（Ｓ９ａ）と、
上記予約されたルーティングパス（代替＃１）に沿う全てのノード（１０５ｂ、１０５ｃ）について、アップストリーム方向及びダウンストリーム方向の実際のリソース属性値を判定するステップ（Ｓ９ｂ）と、
上記予約されたルーティングパス（代替＃１）に沿ういずれかのノード（１０５ｂ、１０５ｃ）において、アップストリーム方向、ダウンストリーム方向又は両方の方向について監視されたリソース属性が、上記ＩＰデータグラムヘッダで搬送される通信相手が監視した属性値より小さい値を有する場合、該ＩＰデータグラムヘッダのリソース情報要素（４００ａ、４００ｂ）に新たな値を割り当て（Ｓ９ｃ）、リソース制御情報の受け手が両方の方向について現在のリソース値を判定（Ｓ９ｄ）できるようにするステップとを更に有する請求項１乃至９いずれか１項記載のサービス品質予約方法。
【請求項１１】
一組の属性要求仕様を記述するリソース予約要求メッセージを送信し（Ｓ１０ａ）、上記移動ノード（１０６ａ）又は通信相手ノード（１０６ｃ）により、リソース予約の一方又は両方の方向のリソース割当手続きを制御するステップ（Ｓ１０ｂ）と、
上記リソース予約要求メッセージに基づき、予約されたルーティングパス（代替＃１）に沿う全ての転送ノード（１０５ｂ、１０５ｃ）により、アップストリーム方向、ダウンストリーム方向又は両方の方向に同時に割り当てるべきリソース属性値を決定するステップ（Ｓ１０ｃ）とを更に有する請求項１乃至１０いずれか１項記載のサービス品質予約方法。
【請求項１２】
異なる双方向フローのためのリソース制御情報を同じＩＰデータグラム（４００）にピギーバックし（Ｓ１１ａ）、該それぞれのフローについて、異なるフローに関する予約識別子情報要素及びＩＰデータグラム（４００）のヘッダ内のリソース情報要素（４００ａ、４００ｂ）を上記ＩＰデータグラムヘッダに付加し（Ｓ１１ｂ）、上記予約識別子及び他のリソース情報要素（４００ａ、４００ｂ）のグループ化は、該情報の特定のフローへのメンバシップを決定する（Ｓ１１ｃ）ことを特徴とする請求項１乃至１１いずれか１項記載のサービス品質予約方法。
【請求項１３】
上記移動ノード（１０６ａ）又は通信相手ノード（１０６ｃ）は、ＩＰ層において、両方向又は単方向リソース制御情報を、ネットワーキングインタフェースに送信する準備ができているＩＰデータグラム（４００）に挿入できるか、又はこの目的のために独立したＩＰデータグラム（４００）を生成する必要があるかを判定する（Ｓ１２）ことを特徴とする請求項１乃至１２いずれか１項記載のサービス品質予約方法。
【請求項１４】
上記リソース制御情報は、上記リソース予約要求メッセージのイニシエータと受け手の間の予約されたルーティングパス（代替＃１）に沿ういずれかのノード（１０５ｂ、１０５ｃ）に格納されることを特徴とする請求項１３記載のサービス品質予約方法。
【請求項１５】
上記通信相手ノード（１０６ｃ）において、監視した属性値と、供給されてくるＩＰデータグラム（４００）の上記リソース情報要素（４００ａ、４００ｂ）内の属性要求仕様とを比較する（Ｓ１３ｂ）ことによって、アップストリーム及びダウンストリーム方向のルーティングパスに沿って、リソースが不十分である状況を検出する（Ｓ１３ａ）ステップを更に有する請求項１乃至１４いずれか１項記載のサービス品質予約方法。
【請求項１６】
１つ以上の転送ノード（１０５ｂ、１０５ｃ）が所定のリソース属性をサポートしない場合、上記ＩＰデータグラムヘッダ（４００）により示される特定のリソース情報要素の監視された該リソース属性値を０に設定する（Ｓ１４）ステップを更に有する請求項１乃至１５いずれか１項記載のサービス品質予約方法。
【請求項１７】
予約されたルーティングパス（代替＃１）に沿う特定のノード（１０５ｂ、１０５ｃ）において、双方向予約のアップストリームパス及びダウンストリームパスが同じルートを経由しない場合、予約エンドポイントがルーティングの非対称性の状況を容易に解釈できるように、ＩＰデータグラムヘッダ内の属性値を０に設定するステップ（Ｓ１５）を更に有する請求項１乃至１６いずれか１項記載のサービス品質予約方法。
【請求項１８】
上記予約されたルーティングパス（代替＃１）に沿う転送ノード（１０５ｂ、１０５ｃ）及び上記リソース予約要求メッセージのイニシエータ又は受け手によって、１つ以上の属性要求仕様の値が０のリソース予約要求メッセージを、明示的な解放メッセージとして解釈する（Ｓ１６ａ）ステップと、
上記予約されたルーティングパス（代替＃１）に沿う転送ノード（１０５ｂ、１０５ｃ）において、上記属性要求仕様の値を、フロー固有の予約状態情報の削除に関連付けるステップ（Ｓ１６ｂ）とを更に有する請求項１乃至１７いずれか１項記載のサービス品質予約方法。
【請求項１９】
上記予約されたルーティングパス（代替＃１）に沿う転送ノード（１０５ｂ、１０５ｃ）及び上記リソース予約要求メッセージの受け手によって、１つ以上の属性要求仕様の値が０ではないリソース予約要求メッセージを明示的なセットアップメッセージとして解釈するステップ（Ｓ１７ａ）と、
上記予約されたルーティングパス（代替＃１）に沿う転送ノード（１０５ｂ、１０５ｃ）において、上記属性要求仕様の値をフロー固有の予約状態情報のインストールに関連付けるステップ（Ｓ１７ｂ）とを更に有する請求項１乃至１８いずれか１項記載のサービス品質予約方法。
【請求項２０】
双方向又は単方向として予約のタイプを指定するフロー情報要素を、予約セットアップメッセージのＩＰデータグラムヘッダ（４０１ｃ、４０１ｄ、４０１ｃ’、４０１ｄ’）にピギーバックするステップ（Ｓ１８ａ）と、
上記予約されたルーティングパス（代替＃１）に沿う転送ノード（１０５ｂ、１０５ｃ）において、上記フロー情報要素を解釈し、予約状態情報の正しいインストールを確実にするステップ（Ｓ１８ｂ）とを更に有する請求項１乃至１９いずれか１項記載のサービス品質予約方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、モバイル機器上で実行され、ノード接続の品質が時間的に予測不能に変化する、動的なモバイル無線ＩＰネットワークにおいて、異なるアクセス技術をサポートするために使用される適応型のリアルタイムサービス等のアプリケーションのためのサービス品質（quality-of-service：ＱｏＳ）サポートの分野に関する。
【背景技術】
【０００２】
帯域幅が制約された無線リンクレベルの性能のために、ネットワークリソースが一時的に劣化することがある。無線リンクの特性及び障害のため、移動ノード間の接続が時間的に変化することがある。リンク品質が予測不能に時間的に変化することは、隣接するノード間の接続性及びネットワークへの端末アクセスに悪影響を及ぼす。
【０００３】
また、信頼性が低下する更なる要因として、例えば、サードパーティネットワーク等の中間転送ネットワークに属する無線ノードの使用可能性又は動きが予測不能である点が挙げられる。第３世代以降の移動ネットワークは、無線アドホックネットワークにより固定無線ネットワークアクセスインフラストラクチャを拡張し、無線通信範囲及び移動ユーザのためのネットワーク容量を拡張することができる。欧州のプロジェクトＭＩＮＤは、無線アクセスルータ又は移動端末を含むアーキテクチャを開発している（IST-2000-28584 MIND, Mobile IP-based Network Developments, http://www.ist-mind.org/参照）例えば、無線ルータ又は移動端末等の無線ネットワークノードの切断又は切換により、ネットワークのブランチが分離され、公衆アクセスから切断されることがある。この結果、ネットワークを介する専用パスに沿うトランスポート品質は、時間的にかなり頻繁且つ重大に変化することがある。
【０００４】
したがって、既存のＱｏＳ感知フローは、無線障害及びトポロジー変化に応じて、速やかに確立、復元、適応化及び解放する必要がある。エス・エム・シェリエ（S. M. Shahrier）及びケー・エム・シャヒーン（K. M. Shaheen）による論文「双方向のＱｏＳシグナリングのためのフレームワーク（A Framework for Bidirectional QoS Signaling）」（インターネットドラフト（Internet Draft）、２００２）に開示されているように、この問題は、既存の回線交換又は音声ベースの有線及び無線システムと同様の性能を要求する、例えば、ボイスオーバＩＰ（voice-over-IP：ＶｏＩＰ）又はテレビ会議等のリアルタイムの会話アプリケーションのサポートを妨害する。これは、これらの全ての対称型ストリーミングサービスが、例えば、帯域幅及びレーテンシー特性等、安定した対称双方向のリソース要求を課すためである。
【０００５】
既存のプロトコルの複雑さは、これらの要求を満たさないことも多い。個々のデータフローのためのリソース予約（例えば、ＦＴＰサーバとのファイル交換）を可能にするサービスアーキテクチャ、すなわち、統合サービス（Integrated Services：ＩｎｔＳｅｒｖ）モデルも提案されている。これに代えて、ルーティングパスに沿ってネットワークノードが必要とするより少ない状態情報でフローの集合体に関してパケット転送処理を判定することにより、拡張性を向上させるクラス別サービス（ＤｉｆｆＳｅｒｖ）モデルも提案されている。ＩｎｔＳｅｒｖモデルの１つの候補として、ピアホストにリソース要求を自動的にシグナリングするアプリケーションを可能にするリソース予約プロトコル（ＲＳＶＰ）が提案されている。プロトコルは、ルーティングパスに沿って、ホップバイホップで解釈してもよく、非適合領域の領域のネットワーク境界における適切なマッピングメカニズムによって、非ＲＳＶＰネットワーク領域にトランスペアレントにトンネルしてもよい。ＲＳＶＰプロトコルは、ＩＰ関連の開発及び標準化組織により何らかの承諾を得ているが、モバイル環境において、適応型の実時間アプリケーションとの相互運用性を実現する場合、このプロトコルの欠陥は明白である。ＲＳＶＰを拡張するための（ＩＥＴＦ  ＷＧ  ＮＳＩＳが研究する）開発中の標準化案でさえ、上述したネットワーキング問題を十分補償することができない。これは、制御とユーザデータとが明確に分離されているために、変化するネットワーキング条件への速やかな適応化が行えないためである。
【０００６】
ローカルレベルでは、ノートコンピュータ又はパームトップコンピュータをリンクするアドホックネットワークを用いて、会議の参加者間で情報を公開し、共有することができる。また、これらは、機器が、例えば、オーディオ及び／又はビデオ信号、アラーム、コンフィグレーションアップデート等の情報を直接交換するホームネットワークのアプリケーションにも好適に用いられる。このコンテキストにおいて、将来実現されるであろうアプリケーションとしては、掃除を行い、皿を洗い、芝生を刈り、安全を監視する等の目的で相互接続された家庭用ロボットの自律型ネットワークがある。近年、水質汚染を予測し、又は津波の早期警戒情報を提供する、環境監視のためのアドホックマルチホップネットワークが提案されている。短距離アドホックネットワークは、所謂「パーソナルエリアネットワーク（Personal Area Network：ＰＡＮ）」を形成し、ケーブルの必要性を排除することにより、様々なモバイル機器（例えば、携帯電話機及びＰＤＡ）の間の相互通信を簡素化できる。また、アドホックネットワーク領域のノードに対し、固定ネットワークが提供する移動性を拡張することもできる。
【０００７】
モバイルアドホックネットワーク（mobile ad-hoc network：ＭＡＮＥＴ）は、通常、分散環境で動作し、送信元と宛先の間で、トラヒックは、複数の無線ホップを通り過ぎることができる。経路決定アルゴリズム及び無線層のインプリケーションは、これらのネットワークに関する困難な研究課題である。ノードが移動するネットワークの生来的な予測不可能性により、基底に存在するネットワークのノード間でデータを矛盾無く転送するためのルーティング及び移動機能の実現が困難になる。なお、マルチホップ無線方式では、性能を維持しながら、電池容量を節約することができる。いずれの場合も、アドホックネットワーキングモデルの最も魅力的な特徴は、恐らく、集中制御からの独立性であり、これにより、ユーザに与えられる自由度及び柔軟性が向上する。
【０００８】
現在の技術水準の簡単な説明
発明の中心的概念を明らかにするために、従来の技術における最も重要なＱｏＳ予約概念及びプロトコルの一部を簡潔に説明する必要がある。
【０００９】
エス・シェンカー（S. Shenker）及びジェイ・ロクラウスキ（J. Wroclawski）による論文「ネットワーク要素サービス仕様テンプレート（Network Element Service Specification Template）（ＩＥＴＦ  ＲＦＣ２２１６、１９９７年９月）」には、今日の移動ユーザに対する様々なＱｏＳ予約概念が開示されている。「サービス品質（quality of service：ＱｏＳ）」という用語は、例えば、現在実現されている帯域幅、パケット遅延、パケット損失レート等のパラメータにより記述される、提供されるパケット配信サービスの性質を指す。インターネットは、伝統的に、単一のＱｏＳ及び使用可能な帯域幅及び遅延特性が瞬間的な負荷に依存するベストエフォート型配信を提供する。アプリケーションから見たＱｏＳの制御は、基底に存在するネットワークインフラストラクチャを適切に提供することにより機能する。
【００１０】
エス・ブレーク（S. Blake）、ディー・ブラック（D. Black）、エム・カールソン（M. Carlson）、イー・デイビース（E. Davies）、ゼット・ワング（Z. Wang）、ダブル・ウィス（W. Weiss）らによる論文「クラス別サービスのためのアーキテクチャ（An Architecture for Differentiated Services）（ＩＥＴＦ  ＲＦＣ２４７５、１９９８年１２月）」に開示されているように、ＱｏＳ対応のＩＰベースのネットワークでは、２つのメインサービスストリーム、すなわち、シグナリング（リソース）予約セットアッププロトコル（Reservation Setup Protocol：ＲＳＶＰ）を伴う統合サービス（ＩｎｔＳｅｒｖ）及びクラス別サービス（ＤｉｆｆＳｅｒｖ）がある。上述したＩｎｔＳｅｒｖアーキテクチャは、エンドツーエンドＱｏＳをアプリケーションに提供する目的で、インターネットの伝統的なベストエフォート型（ＢＥ）モデルに対する一組の拡張を定義する。クラス別サービスは、シグナリングなしで、同様のＱｏＳデータフローに対する予約の集合を提供する。すなわち、ＤｉｆｆＳｅｒｖネットワークは、所謂ＤｉｆｆＳｅｒｖコードポイント（DiffServ Code Point：ＤＳＣＰ）に基づいて、パケットを、少数の集合的なＱｏＳデータフローの１つ又は「クラス」に分類する。
【００１１】
ＱｏＳアーキテクチャでは、例えば、アール・ブレーデン（R. Braden）他による論文「インターネットアーキテクチャにおける統合サービス：概観（Integrated Services in the Internet Architecture: An Overview）（ＩＥＴＦ  ＲＦＣ１６３３、１９９４年６月）」に開示されているＩｎｔＳｅｒｖアーキテクチャによって提案されるように、パケット分類子（packet classifier）を用いて、パケットを、特定の手法で扱うべきパケットのフロー又はシーケンスに分類する。この目的で、アプリケーションフローを一意的に特定するために、予約識別子が必要である。予約識別子は、例えば、ＩＰソース、宛先ＩＰアドレス、ポート番号等の幾つかのパケットフィールドを含むことができる。ＩＰｖ６の場合、エス・デアリング（S. Deering）及びアール・ヒンデン（R. Hinden）による論文「インターネットプロトコル、バージョン６（ＩＰｖ６）仕様書（ＩＥＴＦ  ＲＦＣ２４６０、１９９８年１２月）」に開示されているように、個々のフローの分類を簡素化するために、フローラベルフィールドが定義されている。フローを一意的に識別するために、このフィールドをＩＰｖ６送信元アドレスと共に評価する提案もある。
【００１２】
アール・ブラドン（R. Bradon）他による論文「リソース予約プロトコル（ＲＳＶＰ）−バージョン１：機能仕様（Resource ReSerVation Protocol (RSVP) - Version 1: Functional Specification）（ＩＥＴＦ  ＲＦＣ２２０５、１９９７年９月）」に開示されているように、リソース予約プロトコル（ＲＳＶＰ）では、データパスを介して、定期的に更新メッセージを送り、接続の有効性を維持する「ソフトステート（soft state）」の概念を用いる。このため、ＲＳＶＰは、統合サービスアーキテクチャのシグナリング部分を構成するエンドツーエンド制御プロトコルである。予約は、受け手指向（receiver-oriented）であり、予約の集合処理は、各アプリケーションの必要性に応じてサポートされる。ＱｏＳデータフローは、複数の送り手を有することができ、プロトコルは、異なる送り手のための予約をどのように集めるかを指示するために、異なる予約スタイルをサポートする。ＲＳＶＰによって用いられる２つの重要なメッセージタイプは、「ＰＡＴＨ」及び「ＲＥＳＶ」である。各データソースは、「ＰＡＴＨ」メッセージを定期的に送信し、送り手から受け手までのパスに沿って、ルータにおいてパス状態をセットアップする。各ＱｏＳデータフローの受け手は、「ＲＥＳＶ」メッセージを定期的に送信し、受け手から送り手までのリバースパスに沿って、中間ルータにおいて予約状態をセットアップする。これにより、ＲＳＶＰは、ネットワークに亘ってかなり安定したパスを実現する。
【００１３】
エー・ケー・タルクダー（A. K. Talukdar）、ビー・アール・バドリーナート（B. R. Badrinath）、エー・アチャーヤ（A. Acharya）らによる論文「ＭＲＳＶＰ：モバイルホストを含む統合サービスネットワークのためのリソース予約プロトコル（MRSVP: A Resource Reservation Protocol for an Integrated Services Network with Mobile Hosts）（米国ラトガース大学、コンピュータサイエンス学部、技術報告書、ＤＣＳ−ＴＲ−３３７、１９９７年７月）」に開示されているモバイルリソース予約プロトコル（ＭＲＳＶＰ）は、能動的予約及び受動的予約といった２つのタイプの予約をサポートする。能動的予約（active reservation）は、データが実際に交換されるＱｏＳデータフローに対応しており、受動的予約は、未だ他のデータフローによって用いられているリソースを事前に予約するものであり、より弱いＱｏＳ保証又はベストエフォート型サービスを要求する場合もある。
【００１４】
従来の解決方法の短所及び問題
アドホックネットワークにおける最も重要な問題の１つは、データフローのルーティングパス及び通信接続のＱｏＳ条件が頻繁且つ重大に、時間的に変化することである。したがって、データフローは、無線環境障害及びトポロジー変化に応じて、速やかにリダイレクト、確立、復元、適応化及び解放する必要がある。現在普及している従来の技術水準に基づくＱｏＳプロトコルは、このような動的な移動無線環境に好適ではない。これらのプロトコルは、潜在的な将来のルーティングパスのＱｏＳ状況を事前に検査するのではなく、ハンドオーバ処理により生じるＱｏＳ条件変化に対し、受動的且つ応答的な手法で反応するに過ぎない。
【００１５】
ＲＳＶＰ等の従来のリソース予約プロトコルは、通常、単方向予約要求をサポートするだけである。対称型アプリケーションについてこれまでに議論した解決方法は、拘束されていない双方向予約（unbundled bidirectional reservation）である。この結果、互いに反対に位置する通信エンドポイント（「アプリケーションピア」）から２つの単方向の接続が確立される。パスに沿ったノードを介するルーティングについて、ルーティング制約の意味において、アップストリームのフローは、関連するダウンストリームのトラヒックに関係しないので、両方の予約は、相互依存性を全く有さない。これらの予測不能な非対称性は、例えば、一方向の接続が、まだ十分な能力を有しているにもかかわらず、会話を実現する接続のための総合的なＱｏＳ要求が満たされなくなるといった状況を引き起こす。時間が経過するにつれてリンク品質が頻繁に変化する移動無線ネットワークにおいては、特定のタイプの双方向アプリケーションについて、各方向においてルートを「拘束（bundle）」する必要がある。したがって、両方向が同じ経路を用いる必要があり、又はネットワークにより単一のインスタンスとして扱われるべきである。
【００１６】
長年に亘り、インターネットに関して、トランスポート及びネットワーク層ＱｏＳが研究されてきたが、これらの研究は、主に、有線ネットワークの仮定に基づいて行われている。しかしながら、移動ノードを無線リンク接続により処理する、複数の家庭を接続する異種のアクセスネットワーク内の無線通信では、帯域幅が制限され、エラーレートが高く、リソースの変動が大きい。更に、移動ノードがネットワークへのアクセス点を変更する場合、ハンドオーバー中及びハンドオーバー後にシステムの振る舞いを制御するメカニズムが必要である。したがって、これらの信頼性の低いネットワークのこのような生来的な振る舞いに対処するために、無線通信におけるＱｏＳの提供は重要な課題である。エス・エム・シェリエ（S. M. Shahrier）及びケー・エム・シャヒーン（K. M. Shaheen）による論文「双方向のＱｏＳシグナリングのためのフレームワーク（A Framework for Bidirectional QoS Signaling）」（インターネットドラフト（Internet Draft）、２００２）に開示されているように、例えば、ボイスオーバＩＰ（voice-over-IP：ＶｏＩＰ）又はテレビ会議等、移動ノード上で実行される会話のような実時間アプリケーションを考慮に入れると、要求されるＱｏＳ能力は、既存の回線交換又は音声ベースの無線システムと同様の性能を要求する。
【００１７】
これらの対称型ストリーミングサービスは、対称型の双方向の帯域幅及びレーテンシー条件の安定を要求する。また、逆方向のパス上で肯定応答メッセージが遅延又は欠落する虞がある場合、スループットが減少するＴＣＰ接続内における双方向予約の必要性も明白である。
【００１８】
アクセスネットワークに接続するために、移動ノードで生成されるアプリケーションフローを２つの経路間でルーティングすることができる構成の具体例を図１に示す。現在のＩＰトランスポートネットワークでは、ダウンストリーム及びアップストリームのフローが物理ネットワーク上の異なるパスを経由することに関する制約はない。したがって、両方向について非対称のＩＰルーティングのため、ＱｏＳ予約は、双方向でない。この状況では、アプリケーションが通信パスに沿って対称型の能力を必要とする移動無線ストリーミングのリアルタイムのシナリオでは、問題が生じる虞がある。
【００１９】
有線接続とは異なり、移動無線接続では、これらの能力の時間的な変化は予測できない。このため、ダウンリンク側は、如何なる無線リンク品質の変化による影響も受けていないにもかかわらず、アップリンク側が、要求されたＱｏＳパラメータをサポートできなくなるといった状況が発生する可能性がある。すなわち、このような非対称性により、一方向のパスが十分なリソースを有していても、双方向接続のための総合的なＱｏＳ要求が満たされなくなってしまう状況が生じる。
【発明の開示】
【発明が解決しようとする課題】
【００２０】
上述の課題に鑑み、本発明の目的は、アドホックネットワーク環境において、有効なＱｏＳメカニズムを提供することである。
【００２１】
この目的は、独立請求項の特徴により達成される。有利な特徴は、従属請求項において定義されている。発明の更なる目的及び利点は、以下の詳述により明らかとなる。
【課題を解決するための手段】
【００２２】
本発明が提案する解決方法は、通信パスに沿って、アップストリーム方向及びダウンストリーム方向の両方について、ＱｏＳリソース又はサービスパラメータを相互に予約、監視及び／又は適応化し、ノード接続性の品質が時間的に予測不能に変化することがある動的な、移動体の無線ＩＰネットワークにおいて異なるアクセス技術をサポートするモバイル機器上で実行される対称型リアルタイムサービスを実現する帯域内シグナリングメカニズム内における双方向ＱｏＳ予約手続きのためのメカニズムを提供する。すなわち、本発明が提案する解決方法は、動的な双方向の拘束されたネットワークリソース予約に基づく動的な双方向ＱｏＳ予約帯域内シグナリング法を用いて、従来のＱｏＳ予約メカニズム、特に、無線ネットワーク及び無線アドホックネットワークにおける適応型のリアルタイムサービスを最適化する。ここで、用語「帯域内（in-band）」とは、制御データ及びユーザプレーンデータを分離しない状況を示す。したがって、ネットワークの観点から、両方の通信方向は、独立していない。図２は、アップリンク及びダウンリンクが同じ通信パスを用いるように強制する通信シナリオの具体例を示している。
【００２３】
以下の章では、発明が提案する解決方法のための、ＱｏＳ監視、予約管理及び適用されたソフトステートモデルに関する幾つかの前提条件を簡潔に説明する。
【００２４】
＊ＱｏＳ監視：ＱｏＳフレームワークは、データリンク層（層２）に関して、実際のＱｏＳ能力を監視する能力を有する必要がある。ＱｏＳ対応のパスに沿ったネットワークリソース使用可能性に関して、適応型のアプリケーションに最新の情報が定期的に供給されることが仮定される。したがって、適応型のアプリケーションを最適にサポートする帯域内シグナリングメカニズムが提供される。
【００２５】
＊予約管理：データリンク層は、ＱｏＳモデルが生成するＱｏＳ要求、例えば、受動的又は能動的なリソース予約要求を処理する能力を有する必要がある。
【００２６】
＊ソフト状態モデル：無線ネットワークにおいて、予約された接続を有効に保つために用いられる予約イニシエータは、ソフトステート予約モデルが記述するネットワーク状態情報を定期的に更新する必要がある。
【００２７】
包括的には、予約は、単方向であっても双方向であってもよい。したがって、予約要求のイニシエータは、「ＱｏＳコンテナ」に組み込まれた「ＱｏＳ情報要素」によって、リソース予約情報を提供する。
【００２８】
本発明が提供する帯域内シグナリング法は、広範囲に亘るアプリケーションに予約機能を提供する柔軟なリソース予約メカニズムに関連する。この概念により、クライアント又はサーバアプリケーションは、所定のサービス又はビジネスモデルに適合するように、予約スタイル要求を指定することができる。リソースパラメータは、「ＱｏＳコンテナ」に含まれた「ＱｏＳ情報要素」によって指定される。
【００２９】
可能なインプリメンテーションとして、エス・デアリング（S. Deering）及びアール・ヒンデン（R. Hinden）による論文「インターネットプロトコル、バージョン６（ＩＰｖ６）仕様書（ＩＥＴＦ  ＲＦＣ２４６０、１９９８年１２月）」に開示されているＩＰｖ６ホップバイホップ拡張ヘッダに「ＱｏＳコンテナ」を統合する。予約「ＱｏＳコンテナ」は、モジュール形式で構成される。例えば、一組の予め定義された値から、アプリケーションに必要なパラメータを含ませることができる。
【００３０】
アプリケーションに提供される「ＱｏＳ情報要素」の仕様は、ネットワークのリソースの使用に強く影響する。より正確には、これらの情報要素は、予約のタイミング、予約の制御及びこの他の要素に影響を及ぼす。
【００３１】
複数のフロー間でリソースを効率的に使用するために、特定の「ＱｏＳ情報要素」を適用するために許容できる状況を定義するネットワークポリシを確立することが好ましい。予約適応性、すなわち、ネットワーク内の変化した条件に適応する能力は、ＩＰ層に示される予約スタイルパラメータではない。適応性は、フローの終端のノード間で、ＩＰ及び下位の層が提供する現在利用可能なリソースを考慮に入れて、同意されることが仮定される。
【００３２】
１個のパスにおいて、確認なしで高速な予約を実現する概念を導入する。これに代えて、要求のイニシエータに向けて送信される肯定応答により予約をトリガしてもよい。これにより、能動的予約及び受動的予約の概念を導入する。これは、これらの２つの予約のタイプをサポートするＭＲＳＶＰから導出される。
【００３３】
受動的予約では、フローは、潜在的な将来の使用のために、ネットワークリソース、例えば、所定の帯域幅の必要性を宣言できる。予約の状態が能動的予約に変わるまでは、他の如何なるフローも、これらの「受動的に予約された」リソースを使用することができる。すなわち、他のフローは、受動的に予約されたリソースを借りることができる。この手法により、条件が変化するネットワークにおけるネットワーク使用効率が向上する。受動的な状態予約は、計画されたハンドオーバーに先立って行ってもよい。
【００３４】
能動的予約は、特定のフロー又はデータパケット交換のために明確に定義されたＱｏＳ能力を有するフロー集合体に排他的に割り当てられる。能動的予約を作成したフロー以外の他の如何なるフローも、割り当てられたリソースを共有できない。また、能動的予約は、ソフトステートとして定義され、したがって、更新する必要がある。
【００３５】
単方向予約は、双方向予約が確立できない場合、又は双方向予約を解放する必要がある場合の代替的な解決策（フォールバックソリューション）であるとみなすことができる。この場合、２つの通信ピアの間のデータグラムは、非対称のリンク又は負荷分散のため、必ずしも同じパスを経由しない。
【００３６】
単方向予約要求だけをサポートするＲＳＶＰとは異なり、この手法では、双方向予約を要求することができる。双方向予約の場合、２つのピアホスト間のアップストリーム及びダウンストリーム予約は、ネットワークを介して、同じパスを反対の方向に用いることが想定される。双方向データフローは、同じパスに沿って、それぞれ反対の方向にリソース予約を組み合わせる素インスタンス（atomic instance）を表す。双方向のパスは、ホップバイホップで、又は明示的な経路リストを決定することにより確立することができる。対称及び非対称の予約をサポートするためには、プロトコルインプリメントにおいて、順方向及び逆方向用の予約メトリック及び監視フィールドの個別の組を考慮する必要がある。
【００３７】
予約を確立するには、独立した検査メカニズムにより、アップリンクのネットワークパス及びダウンリンクのネットワークパスの両方を検査しなければならない。各ホップは、送信インタフェース及び受信インタフェースの両方について、使用可能なリソースを確認する必要があり、また、場合によっては、イニシエータから見て次のホップルータに要求を送る前に、両方のインタフェースのために、（受動的又は能動的に）リソースを予約する必要がある。
【００３８】
双方向予約確立処理の結果に関するフィードバックは、「実際値（actual value）」フィールド内に保存できる。アプリケーションは、予約セットアップの監視情報を受け取ると共に、予約結果にどのように反応するかを決定する。
【００３９】
現在の技術水準におけるルーティングノードは、単一のステップによる両方向の予約をサポートしていない。ルーティングノードが双方向予約セットアップをサポートしない場合、部分的に失敗したことを示す予約結果が対応する監視フィールド（例えば、ＱｏＳメトリックの場合「実際値」フィールド）に保存される。この処理では、イニシエータには、予約要求の一方向しか確立できなかったこと、したがって、双方向予約要求は満たされなかったことが通知される。
【００４０】
また、非対称のネットワーク負荷も、双方向予約セットアップの失敗の原因となり得る。セットアップに問題が生じた場合、イニシエータは、リソースが不十分である状況にどのように対処するかを決める。１つの反応スキームとして、イニシエータは、単方向予約だけを要求してもよい。単方向予約だけを受け取ることによって、ピアは、自らダウンストリーム予約を確立する。
【００４１】
予約パスに沿う特定のルーティングノードにおいて、双方向予約のためのアップストリームパス及びダウンストリームパスが同じ経路を通らないことをリソース検査メカニズムが検出した場合、各ノードにおいて、ＩＰデータグラムヘッダにより搬送される監視された属性値の幾つか又は全てを０に設定する。予約のエンドポイントがルーティングの非対称性の状況を容易に解釈できるようにするために、これらの属性値は、予約プロトコルの統語構造仕様に基づき、０に設定する必要がある。図３は、双方向予約セットアップのためのフローチャートを示している。
【００４２】
双方向予約が時間切れになり、又は明示的に取り消された場合は、アップストリーム及びダウンストリームの予約エントリの両方を取り消す。
【００４３】
本発明の利点は、単一のステップで実行できる動的な双方向のリソース予約、組み合わされた双方向の予約監視及び適応化、並びにモバイル環境に適切に適用できる帯域内シグナリング概念である。
【００４４】
＊動的な双方向のリソース予約：双方向通信システムパスを推定する特定のアプリケーションは、双方向予約の利益を享受する。アプリケーションの観点から、両方の通信方向は、独立していない。時間が経過するにつれてリンク品質が頻繁に変化する無線ネットワークにおいては、特定のタイプの双方向アプリケーションについて、各方向においてルートを「拘束（bundle）」する必要があり、これは、両方向が同じ経路を用いる必要があり、又はネットワークにより単一のインスタンスとして扱われるべきであることを意味する。
【００４５】
＊単一のステップで実行できる双方向のリソース予約：要求のイニシエータと、対応するノードとの間でホップバイホップで送信される単一のメッセージにより、又は２つのメッセージ（要求及び確認）により、リソースを割り当てることができる。拘束された双方向予約について、２つのピアホスト間のアップストリーム及びダウンストリーム予約は、ネットワークを介して、同じパスを反対の方向に用いることが想定される。この結果、本発明は、同じパスに沿って、それぞれ反対の方向にリソース予約を組み合わせる素インスタンスとして、双方向フローの概念を導入する。双方向予約の拘束により、ネットワークシグナリングオーバヘッドを減少させることができる。
【００４６】
＊組み合わされた双方向の予約監視及び適応化：アップリンクのネットワークパス及びダウンリンクのネットワークパスの両方を検査するために、独立した検査メカニズムが必要である。各ホップは、送信インタフェース及び受信インタフェースの両方について、使用可能なリソースを確認する必要があり、また、場合によっては、イニシエータから見て次のホップルータに要求を送る前に、両方のインタフェースのために、リソースを予約する必要がある。リソースの双方向の監視又は適応化は、単一のメッセージ内で行われる。ハンドオーバー状況及びＱｏＳ適応化の場合、フローバンドの拘束により、再交渉処理の速度を高めることができる。
【００４７】
＊モバイル環境に適切に適用できる帯域内シグナリング概念：帯域内シグナリングは、予測できない特性を有するネットワークリンクを介する拘束された双方向予約のために最も有益である。通常の双方向フローのためのシグナリングオーバヘッドは、非常に小さい。例えば、所定のソフトステート時間間隔で、アプリケーションデータグラムを定期的に送信する場合、シグナリング情報は、このアプリケーションデータグラムによってピギーバックすることができる。予約エンドポイントを表すホストは、予約に関するフィードバック情報を生成する。予約イニシエータに送信されるアプリケーションデータがないため、このフィードバック情報の提供により、単方向のアプリケーションフローに幾つかの問題が生じる。信頼できるトランスポート接続（例えば、ＴＣＰ）では、予約イニシエータにフィードバック情報を搬送するために用いることができる双方向のメッセージフローがある。双方向フローがない場合、フィードバックのみを目的として、フィードバック情報をＩＰｖ６データグラムに含ませることもできる。しかしながら、この手続きは更なるシグナリング負荷をネットワークに課すこととなる点を考慮する必要がある。
【００４８】
発明の一実施形態は、複数の相互接続された転送ノードを含む、接続性が予測不能に変化するＩＰベースの動的なモバイルアドホックネットワークを介して、ノード間で、特定のルーティングパスに沿って両方の方向でリソース制御情報をシグナリングすることにより、移動ノード及び通信相手ノード上で実行される対称型リアルタイムマルチメディアアプリケーション及び／又はデータサービスに必要なネットワークリソース及び／又はサービスパラメータを予約し、割り当て、監視し及び／又は適応化する双方向のサービス品質（ＱｏＳ）予約方法を提供する。移動ノードと通信相手ノードの間で伝送されるリソース制御情報は、これらのノードのために予約された接続のルーティングパスを介して、ホップバイホップで伝送されるＩＰデータグラムに埋め込まれ、リソース制御情報は、ネットワークを介して、両方の方向に同じルーティングパスを用いて、移動ノードと通信相手ノードの間でホップバイホップで伝達される。
【００４９】
ここで、移動ノード又は通信相手ノードは、両方の方向に同時に、所定の量のネットワークリソースの要求を示すリソース予約要求メッセージを開始するイニシエータとなる。予約要求のイニシエータ及び予約されるネットワークリソースの所定の量は、通信ピア間で確立される合意又は契約によって定義される。これに代えて双方は、セッション層折衝又はアプリケーション層折衝によって合意を行ってもよい。
【００５０】
上記リソース予約要求メッセージのイニシエータは、単一のアプリケーションフロー又はＩＰデータグラム分類のために集められた両方向のフローにより、双方向接続を関連付け、関連するフローの継続期間の間変化しない特定の転送処理を実現する固有の予約識別子（ＩＤ）を生成してもよい。これにより、ネットワークリソースは、ＩＰデータグラムにピギーバックされたリソース制御情報を用いることによって、ホップバイホップで割り当てられ又は監視され、また、この割当及び監視の両方は、リソース予約要求メッセージの両方の方向について同時に実行され、予約されたルーティングパスの両方の方向のためのリソース制御情報は、同じＩＰデータグラムに埋め込まれる。
【００５１】
予約の両方向のためのリソース制御情報は、ＩＰデータグラムのヘッダ拡張の一部であるリソース情報要素を介して、ピギーバックされ、各リソース情報要素は、一方又は両方のフローの定量化可能なリソースメトリック又は一方又は両方のフローの定量化可能な及び定量化不能なフローコンテキスト情報に関連する個々のフロー又はフロー集合体のフロー属性に関連する予約されたルーティングパスに亘るリソース属性を表す。
【００５２】
リソース情報要素は、リソース予約要求メッセージのイニシエータから受け手へのアップストリーム方向、又はリソース予約要求メッセージの受け手からイニシエータへのダウンストリーム方向、又はこれらの両方の方向に、リソース制御情報を記述し、アップストリーム方向及びダウンストリーム方向は、予約手続きにおける、リソース予約要求メッセージのイニシエータ又は受け手としての役割のために、移動ノード及び通信相手ノードによって一意的に特定される。
【００５３】
リソース情報要素は、各フローについて、モジュール式に組織化され、リソース制御情報を提供したノードは、ＩＰデータグラムヘッダに格納されるリソース情報要素の数を決定する。
【００５４】
各リソース情報要素は、監視された属性値のためのフィールド及び各リソース属性の最大値を定義する上側の閾値及び／又は最小値を定義する下側の閾値により記述されるリソース属性固有のフロー要求を指定する属性要求仕様フィールドを有する。これに代えて又はこれに加えて、各リソース属性について離散値を指定してもよい。予約のイニシエータ又は受け手は、属性要求仕様を生成及び変更でき、予約パスに沿うルーティングノードは、この属性要求仕様を解釈して、要求された量のリソースを予約に割り当てることができる。
【００５５】
本発明の更なる実施形態においては、移動ノードと通信相手ノードの間の予約されたルーティングパスに沿って、予約の両方の方向について、使用可能なリソースに関する情報を同時に監視する。そして、予約されたルーティングパスに沿う全てのノードについて、アップストリーム方向及びダウンストリーム方向の実際のリソース属性値を判定する。予約されたルーティングパスに沿ういずれかのノードにおいて、アップストリーム方向、ダウンストリーム方向又は両方の方向について監視されたリソース属性が、ＩＰデータグラムヘッダで搬送される通信相手が監視した属性値より小さい値を有する場合、ＩＰデータグラムヘッダのリソース情報要素に新たな値を割り当て、リソース制御情報の受け手が両方の方向について現在のリソース値を決定できるようにする。
【００５６】
本発明の更なる実施形態においては、一組の属性要求仕様を記述するリソース予約要求メッセージを送信し、移動ノード又は通信相手ノードにより、リソース予約の一方又は両方の方向のリソース割当手続きを制御する。リソース予約要求メッセージに基づき、予約されたルーティングパスに沿う全ての転送ノードにより、アップストリーム方向、ダウンストリーム方向又は両方の両方に同時に割り当てるべきリソース属性値を決定する。双方向予約のためのリソースの制御は、通信ピアにより、より上位の層折衝を介して行われる。より上位の層折衝メカニズムがない場合、通信ピアは、特定のＩＰ拡張ヘッダを用いて、ホップバイホップではなく、エンドツーエンドで解釈される情報要素を交換してもよい。
【００５７】
異なる双方向フローのためのリソース制御情報を同じＩＰデータグラムにピギーバックし、それぞれのフローについて、異なるフローに関する予約識別子情報要素及びＩＰデータグラムのヘッダ内のリソース情報要素をＩＰデータグラムヘッダに付加し、予約識別子及び他のリソース情報要素のグループ化は、情報の特定のフローへのメンバシップを決定する。これにより、移動ノード又は通信相手ノードは、ＩＰ層において、両方向又は単方向リソース制御情報を、ネットワーキングインタフェースに送信する準備ができているＩＰデータグラムに挿入できるか、又はこの目的のために独立したＩＰデータグラムを生成する必要があるかを判定する。リソース制御情報は、リソース予約要求メッセージのイニシエータと受け手の間の予約されたルーティングパスに沿ういずれかのノードに格納される。
【００５８】
本発明の更なる実施形態においては、通信相手ノードにおいて、監視した属性値と供給されてくるＩＰデータグラムのリソース情報要素内の属性要求仕様とを比較することによって、アップストリーム及びダウンストリーム方向のルーティングパスに沿って、リソースが不十分である状況を検出する。これにより、特定の例外又は警告メッセージを定義しなくてもよくなる。指定されたエンドシステムは、特定のリソースの不足に対応する必要がある。
【００５９】
１つ以上の転送ノードが所定のリソース属性をサポートしない場合、ＩＰデータグラムヘッダにより示される特定のリソース情報要素の監視されたリソース属性値を０に設定する。
【００６０】
また、発明の一実施形態は、予約されたルーティングパスに沿う特定のノードにおいて、双方向予約のアップストリームパス及びダウンストリームパスが同じルートを経由しない場合、予約エンドポイントがルーティングの非対称性の状況を容易に解釈できるように、ＩＰデータグラムヘッダ内の属性値を０に設定するステップを有する双方向のサービス品質（ＱｏＳ）予約方法を提供する。
【００６１】
本発明の更なる実施形態においては、予約されたルーティングパスに沿う転送ノード及びリソース予約要求メッセージのイニシエータ又は受け手によって、１つ以上の属性要求仕様の値が０のリソース予約要求メッセージを、明示的な解放メッセージとして解釈する。そして、予約されたルーティングパスに沿う転送ノードにおいて、この属性要求仕様の値を、フロー固有の予約状態情報の削除に関連付ける。
【００６２】
また、予約されたルーティングパスに沿う転送ノード及びリソース予約要求メッセージの受け手によって、１つ以上の属性要求仕様の値が０ではないリソース予約要求メッセージを明示的なセットアップメッセージとして解釈する。予約されたルーティングパスに沿う転送ノードにおいて、この属性要求仕様の値を、属性要求仕様の値をフロー固有の予約状態情報のインストールに関連付ける。
【００６３】
本発明の更に他の実施形態においては、双方向又は単方向として予約のタイプを指定するフロー情報要素を、予約セットアップメッセージのＩＰデータグラムヘッダにピギーバックする。そして、予約されたルーティングパスに沿う転送ノードにおいて、フロー情報要素を解釈し、予約状態情報の正しいインストールを確実にする。
【００６４】
本発明の更なる利点及び実施形態は、従属請求項及び図面を参照する以下の発明の詳細な説明から明らかとなる。
【発明を実施するための最良の形態】
【００６５】
以下、図１〜図９を参照して、本発明の実施形態を詳細に説明する。更に、本発明に基づく双方向シグナリングのための帯域内シグナリングプロトコルの例示的なメッセージ統語構造についても簡潔に説明する。表２には、これらの図面において参照番号とともに示されるシンボルの意味を示している。
【００６６】
ＩＰｖ６では、任意のインターネット層情報は、パケット内のＩＰｖ６ヘッダと上位層ヘッダの間に設けることができる独立したヘッダに符号化される。シグナリング情報は、ルーティングパスに沿った全てのルーティングノードで解釈する必要がある場合、ホップバイホップオプションヘッダにより搬送される。ピアノード間でのみ必要な情報は、宛先オプションヘッダに格納される。
【００６７】
本発明の具体例では、エス・デアリング（S. Deering）及びアール・ヒンデン（R. Hinden）による論文「インターネットプロトコル、バージョン６（ＩＰｖ６）仕様書（ＩＥＴＦ  ＲＦＣ２４６０、１９９８年１２月）」に開示されているＩＰｖ６ホップバイホップ拡張ヘッダを用いて、パスに沿ったルーティングノードが解釈するリソース制御情報を運ぶ。シグナリング情報は、ホップバイホップで予約された接続のデータパスを経由するＩＰデータグラムにピギーバックする。これにより、両方の通信ピアの間でシグナリング情報を伝達するために、ネットワークを介して、両方の方向で同じ通信パスがホップバイホップで用いられる。
【００６８】
モジュールの概念を提供する「ＱｏＳコンテナ」の用語を導入する。包括的に言えば、ＱｏＳコンテナは、ＱｏＳ情報要素の形式でシグナリング情報を含み、これは、通常、単一のフローに関連付けられるが、フローのグループに関連付けてもよい。この手法に関する主要な概念は、パケット内に設けられるＱｏＳ情報要素の数及びサイズが可変であるという点である。例えば、現在解釈する必要がある情報だけがコンテナにより搬送される。ＱｏＳコンテナ内には、不可欠なＱｏＳ情報要素と、任意のＱｏＳ情報要素とがあり、任意のＱｏＳ情報要素は、補足的情報を含む。
【００６９】
１つのＱｏＳ情報要素表現は、ＱｏＳメトリック情報を伝えるＱｏＳメトリック情報要素である。ＱｏＳメトリック情報要素は、監視された属性値のフィールド及びリソース属性特定のフロー要求、すなわち、属性要求仕様を指定する更なるフィールドから構成される。各リソース属性の最大値を定義する上側の閾値又は最小値を定義する下側の閾値は、属性要求仕様を記述する。これに代えて、予約のために各リソース属性の値が許容される範囲を記述する上下の閾値を一緒に指定してもよい。これに代えて又はこれに加えて、各リソース属性について離散値を指定してもよい。予約のイニシエータ又は受け手は、属性要求仕様を生成及び変更でき、予約パスに沿うルーティングノードは、この属性要求仕様を解釈して、要求された量のリソースを割り当てることができる。
【００７０】
各予約開始ノード（イニシエータ）は、固有の予約識別子を生成する必要がある。双方向接続は、単一のアプリケーションフロー又はフローの集合体に関連付けられる。予約識別子は、関連するフローの継続期間の間変化せず、両方の方向において、ＩＰデータグラムの分類のために用いられ、これにより特定の転送処理が実現される。
【００７１】
他の具体例は、フロー識別子の独立性の必要性を示している。フローの受け手が役割を変更し、特定の予約識別子で定義されたセッションへの応答を開始する場合、この受け手は、ＩＰｖ６パケットヘッダ送信元アドレスフィールドにＩＰｖ６アドレスを付加することができる。この場合、送信元アドレス及びフローラベルの組合せは、元の予約識別子を表現していない。このため、中継ノードは、フローに属するパケットを正しく分類できない。したがって、フローのトランスペアレント性が必要とされる場合、元の予約識別子情報を搬送するために、予約識別子情報要素が必要である。例えば、アール・バネルジー（R. Banerjee）他による論文「ハイブリッド法を用いた、効率的なサービス品質を提供するＩＰｖ６フローラベルの使用のための修正された仕様（A Modified Specification for Use of the IPv6 Flow Label for Providing Efficient Quality of Service Using Hybrid Approach）（インターネットドラフト、２００２年２月）」等、２０ビットのフローラベルフィールドを定義するための仕様の修正に関する提案は、本発明の範囲に含まれない。これらの幾つかの提案とは異なり、本発明では、セッション継続期間の間、固定されたフローラベルを仮定する。
【００７２】
例えば、アール・ブレーデン（R. Braden）他による論文「インターネットアーキテクチャにおける統合サービス：概観（Integrated Services in the Internet Architecture: An Overview）（ＩＥＴＦ  ＲＦＣ１６３３、１９９４年６月）」に開示されているパケット分類識別子を用いて、パケットを、特定の手法で処理されるパケットのフロー又はシーケンスに分類する。したがって、フローを一意的に特定するために、「予約識別子」という用語を用いる。ここでは、予約識別子は、エス・デアリング（S. Deering）及びアール・ヒンデン（R. Hinden）による論文「インターネットプロトコル、バージョン６（ＩＰｖ６）仕様書（ＩＥＴＦ  ＲＦＣ２４６０、１９９８年１２月）」において定義されているＩＰｖ６送信元アドレス（フローを生成するホストのアドレス）及びＩＰｖ６フローラベルから構築することを提案する。予約識別子は、フロー識別子、ＱｏＳイニシエータのＩＰアドレス及びフローエンドポイントから独立している必要があるため、これは必要条件ではない。エム・ブルンナー（M. Brunner）他による論文「ＱｏＳシグナリングプロトコルのための要求（Requirements for QoS Signaling Protocols）」（インターネットドラフト、２００２年１１月、draft-brunner-nsis-req-02.txt）に開示されているように、移動体通信の分野における様々なシナリオでは、ハンドオフから生じるフローは、エンドポイント等を変更する可能性があるため、上述のような独立性が要求されるが、要求されるＱｏＳは同じである。
【００７３】
フローのトランスペアレント性が要求される場合、元の予約識別子情報を搬送するために、予約識別子情報要素を用いる必要がある。効率的なＩＰｖ６フロー分類を実現するために、「予約識別子情報要素」は、ＩＰｖ６メインヘッダフィールドの固定された位置のみに格納されるＩＰｖ６フローラベルフィールド及びＩＰｖ６送信元アドレスから構築してもよい。ＱｏＳコンテナ内で「予約識別子情報要素」が特定された場合、ＩＰｖ６ヘッダのフロー情報は、無視する必要がある。ＱｏＳコンテナ内では、予約識別子情報要素は、最初のＱｏＳ情報要素である必要がある。
【００７４】
ＲＳＶＰは、受け手指向の予約を用いるが、提案する解決方法では、送り手及び受け手による予約要求をトリガすることができる。送り手による予約（アップストリーム予約とも呼ぶ。）の場合、各中継ルーティングノードにおいて、送出インタフェースにリソースを割り当てる。一方、受け手による予約の場合、中継ルーティングノードの受入インタフェースにネットワークリソースを割り当てる。予約セットアップをどの方向にイネーブルにするかを区別できるようにするために、両方の通信ピアは、アップストリーム及びダウンストリーム方向について、リソース制御要素の順序に同意する必要がある。中継ルーティングノードに対して、この割当を隠すために、通信ピアは、受信したＩＰデータグラム内のリソース制御情報の順序に関して、アップストリーム及びダウンストリームに関連するリソース制御情報のシーケンスを変更してもよい。
【００７５】
双方向のセッションにおいて、双方向のメディア適応化を実行する能力をサポートするために、固有の予約識別子に属する双方向ＱｏＳ属性を導入する。この双方向ＱｏＳ属性は、通信パスに沿った予約が、両方の方向についてセットアップする必要があることをルータに知らせる。双方向予約の成功に関するフィードバックは、「実際値」フィールドに示される監視結果から得ることができる。対称双方向要求が行われたとの仮定は、双方向予約のために１つのＱｏＳメトリック情報要素だけが生成されたという事実から推定される。非対称双方向要求の場合は、対称双方向要求とは異なり、１つのＱｏＳコンテナ内にグループ化された同じタイプ識別子を有する２つのＱｏＳ情報要素が提供される。第１のＱｏＳ情報要素は、順方向フローを記述する要素として解釈され、第１のＱｏＳ情報要素は、逆方向フローを記述する要素として解釈される。アップストリーム方向及びダウンストリーム方向は、ＱｏＳ開始ノードの観点から定義される。
【００７６】
各ＱｏＳコンテナは、複数のＱｏＳ情報要素を搬送することができる。ピギーバックされたＱｏＳコンテナは、ＩＰデータグラム内にリソース制御情報を保持する。リソース制御情報は、予約の両方の方向について、リソースをホップバイホップで割り当て、リソースをホップバイホップで監視し、またこの両方を同時に行うために用いられる。モジュール式のＱｏＳ情報要素の概念は、特定用途のＱｏＳニーズに対して柔軟に対応できるという利点を有する。各ＱｏＳ情報要素は、ＴＬＶ（タイプ−データ長−値：Type-Length-Value）フォーマットに従う。ここで、「タイプ」は、オブジェクトデータを指定し、「データ長」は、オクテットの数を示し、「値」は、データフィールドを記述する。ＱｏＳ情報要素は、出現順に処理される。図４に示す具体例では、ＱｏＳ情報要素４００ａは、ＱｏＳ情報要素４００ｂの前に処理される。
【００７７】
ＱｏＳメトリック情報要素の具体例を図５に示す。通常のタイプフィールド及びデータ長フィールドに加えて、３つの更なるフィールドに分割されるオブジェクトのデータフィールドがある。これらのフィールドは、特定のＱｏＳメトリックについての実際値、最小値、及び最大値を格納する。この具体例では、最後の２つのフィールドは、特定用途のためのＱｏＳニーズを記述する値を格納する。第３のフィールドは、ネットワークから供給される情報をカバーし、エンドツーエンドリンク条件の実際の状況に関する必要なフィードバックを提供する。したがって、このフィールドは、各ホップ毎に、ＱｏＳ固有のネットワークメトリックの実際値によって更新される。値が０に設定された場合、検討中のメトリックについて、リソースは予約されない。
【００７８】
図６は、アップストリーム及びダウンストリームが異なるＱｏＳメトリックを要求することを意味する非対称双方向シナリオにおけるＱｏＳメトリック情報要素の１つの具体例を示している。両方の通信ピアは、リソース状況を明確に特定するために、アップストリーム方向及びダウンストリーム方向について、リソース制御要素の順序に同意する必要がある。中継ルーティングノードに対して、通信ピア間のこの合意を隠すために、通信ピアは、受信したＩＰデータグラム内のリソース制御情報の順序に関して、アップストリーム及びダウンストリームに関連するリソース制御情報のシーケンスを変更してもよい。
【００７９】
図７は、対称双方向シナリオにおけるＱｏＳメトリック情報要素の１つの具体例を示している。対称双方向予約要求内では、アップストリーム及びダウンストリームのＱｏＳメトリックは、同一である。この場合、同じタイプ識別子を有する１つのＱｏＳ情報要素だけがＱｏＳコンテナに保存される。
【００８０】
図８は、十分なリソースがある場合の対称双方向シナリオの通信の具体例を示している。移動ノード１０６ａ（ＭＮ）は、中継ノード１０６ｂ（ＩＮ）（２）を介して、通信相手ノード１０６ｃ（ＣＮ）に対称双方向予約要求（１）を送信する。ここで、ＩＮは、ＭＮが開始した双方向リソース要求を実現させるために十分なリソースを有するとする。したがって、ＩＮは、各方向について２００キロビット／秒を予約し、ＣＮに双方向予約要求を送る（２）。これにより、ＣＮは、予約要求が成功したことを示す情報を入手する。ＣＮは、明示的な又はピギーバックされた結果をＭＮに応答する（３）。ダウンストリーム方向では、中継ノード１０６ｂは、再び予約要求を解釈してもよい（４）。
【００８１】
図９は、リソースが不十分な場合の対称双方向シナリオの通信の具体例を示している。移動ノード１０６ａ（ＭＮ）は、中継ノード１０６ｂ（ＩＮ）（２）を介して、通信相手ノード１０６ｃ（ＣＮ）に対称双方向予約要求（１）を送信する。ここでは、ＩＮは、ＭＮが開始した双方向リソース要求を実現させるために十分なリソースを有していないとする。ＩＮは、アップストリーム方向について、１５０キロビット／秒のビットレートしか予約できないとする。したがって、実際値フィールドは、２００キロビット／秒から１５０キロビット／秒に変更される。ノードＩＮは、更新後の双方向予約要求をＣＮに送信する（２）。これにより、ＣＮは、予約要求が実現されなかったことを示す情報を入手する。ＣＮは、明示的な又はピギーバックされた結果をＭＮに応答する（３、４）。これにより、ＭＮ上で動作する関連するアプリケーションは、パスに沿って使用できるリソースが不十分であることに対応して反応することができる。
【００８２】
【表１】
2007507931.tif 000003
【００８３】
【表２Ａ】
2007507931.tif 000004
【００８４】
【表２Ｂ】
2007507931.tif 000005
【００８５】
【表２Ｃ】
2007507931.tif 000006
【００８６】
【表２Ｄ】
2007507931.tif 000007
【００８７】
【表２Ｅ】
2007507931.tif 000008
【図面の簡単な説明】
【００８８】
【図１】移動ノードが生成したアプリケーションフローが、ＩＰトランスポートネットワークに接続された２つの異なる経路でルーティングされる、アップリンク接続及びダウンリンク接続のために異なるパスが予約される無線双方向通信システムシナリオの概要を示す図である。
【図２】アップリンク接続とダウンリンク接続について同じパスが予約される無線双方向通信システムシナリオの概要を示す図である。
【図３】本発明の一実施形態に基づく双方向予約セットアップ手続きを示すフローチャートである。
【図４】ＩＰデータグラムのＱｏＳコンテナの構造の具体例を示す図である。
【図５】モジュラＱｏＳメトリック情報要素の具体例を示す図である。
【図６】非対称双方向通信システムシナリオにおけるモジュラＱｏＳメトリック情報要素の具体例を示す図である。
【図７】対称双方向通信システムシナリオにおけるモジュラＱｏＳメトリック情報要素の具体例を示す図である。
【図８】十分なリソースがある場合の対称双方向シナリオの通信の具体例を示す図である。
【図９】リソースが不十分な場合の対称双方向シナリオの通信の具体例を示す図である。
【図１】
2007507931.tif 000009
【図２】
2007507931.tif 000010
【図３】
2007507931.tif 000011
【図４】
2007507931.tif 000012
【図５】
2007507931.tif 000013
【図６】
2007507931.tif 000014
【図７】
2007507931.tif 000015
【図８】
2007507931.tif 000016
【図９】
2007507931.tif 000017
【手続補正書】
【提出日】平成17年11月22日(2005.11.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
帯域内シグナリングメカニズムに基づいて、ノード（１０６ａ、１０６ｃ）間の特定のルーティングパスに沿ってリソース制御情報をシグナリングすることにより、移動ノード（１０６ａ）及び通信相手ノード（１０６ｃ）上で実行される対称型リアルタイムマルチメディアアプリケーション及び／又はデータサービスに必要なネットワークリソース及び／又はサービスパラメータを管理するサービス品質（ＱｏＳ）予約方法において、
上記移動ノード（１０６ａ）及び通信相手ノード（１０６ｃ）のために予約された接続のルーティングパスを介して伝送されるメッセージ（４００）内に、該移動ノード（１０６ａ）と通信相手ノード（１０６ｃ）の間で伝送されるリソース制御情報を埋め込むステップ（Ｓ１）と、
ネットワーク（１０４）を介して、両方の方向に同じルーティングパス（代替＃１）を用いて、上記移動ノード（１０６ａ）と通信相手ノード（１０６ｃ）の間でリソース制御情報を伝達するステップ（Ｓ２）とを有するサービス品質予約方法。
【国際調査報告】
2007507931.tif 000018
2007507931.tif 000019
2007507931.tif 000020