(57)【要約】分散型マルチメディアアプリケーションにおいて、動的なエンドツーエンドＱｏＳ交渉及び制御調整を実現するフレームワークを提供する。このフレームワークは、ユーザの嗜好に基づき、動的な能力交渉と、適応経路及び（代替的な）ＱｏＳ契約の仕様とを実現する。詳しくは、ＳＩＰ／ＲＴＳＰ／ＳＤＰ等のＩＰに基づくプロトコルの拡張に基づいて、ネットワークリソース予約（例えばＲＳＶＰ）、ローカル端末リソース（例えばＣＰＵ、メモリ、電源、補助装置）確保及び適応化メカニズムを調整する、代替的なＱｏＳ、能力、嗜好／コンフィグレーションのエンドツーエンド交渉のためのプロトコルを提供する。２以上のピア（１０１、１０３）がマルチパーティ、マルチストリーム、マルチメディア通信を実現するための６個のフェーズを開示する。これらのフェーズとは、プロトコル検出（１０４）フェーズ、前交渉（１０６）フェーズ、マルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズ、高速交渉（経済原理による）（１０８）フェーズ、再交渉（経済原理による）（１０９）フェーズ、確保リソース解放（１１０）フェーズである。これらのフェーズは連続させてもよく、異なる時刻に実行してもよい。本発明は、時間及びリソースが消費される前交渉（１０６）フェーズと、任意であるマルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズの負担からピア（１０１、１０３）を解放する任意のサードパーティエンティティであるＥ２ＥＮＰブローカ（１０５）このエンティティは、オーディオ／ビデオ会議のブリッジとして実現してもよい。
2004537187.tif 000002
【特許請求の範囲】
【請求項１】
ローカル、ピア及びネットワークのリソース管理の統合及び調整に基づいて、マルチメディアアプリケーション及びサービスの保証されたエンドツーエンド品質を提供する品質提供方法であって、
実際の通信が行われる前に、ピア（２１６）によって、能力、品質及び適応化メカニズムの共通の組に関する前交渉（１０６）を行うステップを有するサービス品質提供方法。
【請求項２】
ピア間でサービス品質契約及び能力の組に関する前交渉（１０６）を行うステップを有する請求項１記載のサービス品質提供方法。
【請求項３】
複数のピア間で複数のストリームのサービス品質相関及び同期アスペクトに関する交渉（１０７）を行うステップを有する請求項１又は２記載のサービス品質提供方法。
【請求項４】
ストリーミング中に再交渉（１０９）が行われる場合、上記ピア（２０６）が再交渉状態を参照し、該再交渉状態は、所定の（前交渉された）サービス品質契約及び所定の（前交渉された）能力の組を示すことを特徴とする請求項１乃至３いずれか１項記載のサービス品質提供方法。
【請求項５】
上記ピア（２１６）は、上記前交渉（１０６）の間に、最も分解能が細かいレベルにおいて、ストリーム毎の及び／又はストリームの群毎のサービス品質契約について交渉し、該ストリームの群は、１つのセンダであるピアからレシーバであるピアへのストリームの集合であることを特徴とする請求項１乃至４記載のサービス品質提供方法。
【請求項６】
上記ピア（２１６）は、能力コンフィグレーションの変更について通知されることを特徴とする請求項１乃至５いずれか１項記載のサービス品質提供方法。
【請求項７】
選択するクライアントが、所定の種類のストリームについて前交渉された代替的な品質及びコンフィグレーションの情報がサーバにおいて既に使用可能であることを特徴とする請求項１乃至６いずれか１項記載のサービス品質提供方法。
【請求項８】
プロトコル検出（１０４）フェーズ、前交渉（１０６）フェーズ、マルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズ、高速交渉（経済原理による）（１０８）フェーズ、再交渉（経済原理による）（１０９）フェーズ、確保リソース解放（１１０）フェーズを有する請求項１乃至７いずれか１項記載のサービス品質提供方法。
【請求項９】
上記６個のフェーズは、連結され、連続的に実行され、又は異なる時刻に（但し、請求項８に示す順序で）実行されることを特徴とする請求項８記載のサービス品質提供方法。
【請求項１０】
上記マルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズは、任意に実行され、イニシエータ（１０１）が複数のピア（２１６）との間で、イニシエータ（１０１）の側のみで強制されるユーザポリシに基づいて相関及び同期が必要な複数のストリームを用いて通信する場合にのみ要求されることを特徴とする請求項９記載のサービス品質提供方法。
【請求項１１】
上記プロトコル検出（１０４）フェーズ及び前交渉（１０６）フェーズは、前もって実行され、この結果は、複数の後続する通信セッションに適用され、該各通信セッションは、任意に実行される特定のマルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズにより開始されることを特徴とする請求項１０記載のサービス品質提供方法。
【請求項１２】
上記マルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズが後続する複数の通信セッションに適用可能な場合、該通信セッションは、特定の高速交渉（１０８）フェーズにより開始されることを特徴とする請求項１１記載のサービス品質提供方法。
【請求項１３】
上記プロトコル検出（１０４）フェーズ、前交渉（１０６）フェーズ、マルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズ、高速交渉（１０８）フェーズ、再交渉（１０９）フェーズ、確保リソース解放（１１０）フェーズの間、プロトコルがローカルリソース管理ユニット（２０６）とインタラクトすることを特徴とする請求項８乃至１２いずれか１項記載のサービス品質提供方法。
【請求項１４】
リソース承認制御及びリソース予約が、ネットワークリソース予約ユニット（２０７）を用いて、まずイニシエータ（１０１）、次にレスポンダ（１０３）、最後にネットワークの順で実行されることを特徴とする請求項８乃至１３いずれか１項記載のサービス品質提供方法。
【請求項１５】
上記イニシエータ及びレスポンダにおける処理では、リアルタイムＣＰＵスケジューリング、メモリ管理、電源管理等の問題が処理されることを特徴とする請求項１４記載のサービス品質提供方法。
【請求項１６】
上記確保リソース解放フェーズ（１１０）では、まずネットワークリソース、次にピア（２１６）のリソース、最後にローカルリソースを解放することを特徴とする請求項８乃至１５いずれか１項記載のサービス品質提供方法。
【請求項１７】
確立されたマルチメディアセッションの実行時の間の任意の時刻において、任意のピアが適応化を要求し、再交渉（１０９）フェーズを起動することを特徴とする請求項８乃至１６いずれか１項記載のサービス品質提供方法。
【請求項１８】
プロトコル検出（１０４）フェーズにおいて、ピア（１０１、１０３）に対し、ディレクトリサーバ（１０２）に問い合わせを行うよう強制することにより、又はディレクトリサーバ（１０２）にこのような情報を告知させることによりＥ２ＥＮＰ型の前交渉を行うステップを有する請求項８乃至１７記載のサービス品質提供方法。
【請求項１９】
前交渉フェーズ（１０６）において、能力に関する前交渉を行うステップを有する請求項１８記載のサービス品質提供方法。
【請求項２０】
前交渉フェーズ（１０６）において、完全なコーデックリストに関する前交渉を行うステップを有する請求項８乃至１９いずれか１項記載のサービス品質提供方法。
【請求項２１】
前交渉フェーズ（１０６）において、ストリームレベルにおける適応経路に関する前交渉を行うステップを有する請求項８乃至２０いずれか１項記載のサービス品質提供方法。
【請求項２２】
マルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズにおいて、ストリーム群レベルにおける適応経路に関する前交渉を行うステップを有する請求項８乃至２１いずれか１項記載のサービス品質提供方法。
【請求項２３】
高速交渉フェーズ（１０８）の速度を高めるために前交渉されたＱｏＳ契約及び能力に対するインデクスを付与するステップを有する請求項８乃至２２いずれか１項記載のサービス品質提供方法。
【請求項２４】
再交渉フェーズ（１０９）の速度を高めるために前交渉されたＱｏＳ契約及び能力に対するインデクスを付与するステップを有する請求項８乃至２３いずれか１項記載のサービス品質提供方法。
【請求項２５】
ピア間で非同期メッセージを交換しイベントをイベントを通知することによって、実行時において能力のインストール／削除を取り扱うステップを有する請求項８乃至２４いずれか１項記載のサービス品質提供方法。
【請求項２６】
代替的なＱｏＳ条件及び能力をエンドツーエンド毎に前交渉し、遠隔通信セッションを行う全てのピアが同意できる共通レベルの代替的なＱｏＳ及び能力を前もって確立する遠隔通信用のエンドツーエンド交渉プロトコル。
【請求項２７】
サービス品質のエンドツーエンド交渉を仲介して、前交渉（１０６）フェーズと、任意であるマルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズの負担からピアを解放するブローカ。
【請求項２８】
コンピュータにより実行されて、請求項１乃至２５いずれか１項記載のサービス品質提供方法を実現するコンピュータプログラム。
【請求項２９】
請求項１乃至２５いずれか１項記載のサービス品質提供方法を実現するピアであって、分散型リソース管理処理の交渉処理における異なるフェーズを調整する調整ユニット（２０４）を備えるピア。
【請求項３０】
上記調整ユニットは、プロトコル検出（１０４）フェーズを実行し、続いて、前交渉（１０６）フェーズ、任意であるマルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズ、経済原理に基づく高速交渉（１０８）フェーズ、経済原理に基づく再交渉（１０９）フェーズ、確保リソース解放（１１０）フェーズを起動することを特徴とする請求項２９記載のピア。
【請求項３１】
使用されるエンドツーエンド交渉プロトコルに関する情報を告知し及び問い合わせるためのプロトコル検出ユニット（２１３）を備える請求項２９又は３０記載のピア。
【請求項３２】
他のピア（２１６）に対する調整処理の異なるフェーズを上記調整ユニット（２０４）に実行させるセッションプロトコルユニット（２０５）を備える請求項２９乃至３１いずれか１項記載のピア。
【請求項３３】
上記調整ユニット（２０４）をローカルリソース管理ユニット（２０６）に接続するインタフェース（２１１）を備える請求項２９乃至３２いずれか１項記載のピア。
【請求項３４】
上記調整ユニット（２０４）をプロトコル検出ユニット（２１３）に接続するインタフェース（２１４）を備える請求項２９乃至３２いずれか１項記載のピア。
【請求項３５】
上記調整ユニット（２０４）をセッションプロトコルユニット（２０５）に接続するインタフェース（２１０）を備える請求項２９乃至３２いずれか１項記載のピア。
【請求項３６】
上記調整ユニット（２０４）をＦＳＭエンジンユニット（２０３）に接続するインタフェース（２０９）を備える請求項２９乃至３２いずれか１項記載のピア。
【請求項３７】
上記調整ユニット（２０４）をネットワークリソース予約ユニット（２０７）に接続するインタフェース（２０９）を備える請求項２９乃至３２いずれか１項記載のピア。
【請求項３８】
上記能力の交渉及び再交渉は、選択されたコーデック及びこのコーデックのコンフィグレーションのシグナリングを含むことを特徴とする請求項２５又は２６記載のエンドツーエンド交渉プロトコル。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散型マルチメディアアプリケーション及び分散型マルチメディア技術の分野に関する。また、本発明は、特にマルチメディアミドルウェア、サービス品質（Quality of Service：ＱｏＳ）管理、リソース予約（Resource Reservation）メカニズム、移動端末、無線通信に関連した研究開発を含む。
【背景技術】
【０００２】
まず、この明細書及び特許請求の範囲において用いる技術用語について簡単に説明する。
【０００３】
【表１】
2004537187.tif 000003
【０００４】
次に、この明細書において使用する略語を説明する。
【０００５】
【表２】
2004537187.tif 000004
【０００６】
以下は、当分野における周知の文献である。
【０００７】
【特許文献１】
［Manda00a］  ディー・マンデート（D. Mandato）、移動マルチメディアアプリケーションのための汎用ＱｏＳ適応化フレームワーク（A universal QoS adaptation framework for mobile multimedia applications）、欧州特許出願第００１１１１９１．３号、２０００年、５月２４日
【特許文献２】
［Manda00b］  ディー・マンデート（D. Mandato）他、ＱｏＳに基づく移動マルチメディアアプリケーションのための高レベルインタフェース（High-Level interface for QoS-based mobile multimedia applications）、欧州特許出願第００１２６９７５．２号、２０００年１２月８日
【非特許文献１】
［Beser00］  ビー・ベザー（B. Beser）、ＳＤＰのコーデック能力属性（Codec Capabilities Attribute for SDP）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-beser-mmusic-capabilities-00.txt＞
【非特許文献２】
［Bhatt99］  エス・バッティ（S. Bhatti）、ジー・ナイト（G. Knight）、インターネットアプリケーションのためのＱｏＳ適応化判断の実現（Enabling QoS adaptation decisions for Internet applications）、１９９９年、英国、ロンドン
【非特許文献３】
［Blake98］  エス・ブレーク（S. Blake）、ディー・ブラック（D. Black）、エム・カールソン（M. Carlson）、イー・デービィズ（E. Davies）、ゼット・ワング（Z. Wang）、ダブル・ワイス（W. Weiss）、サービスを差別化するためのアーキテクチャ（An Architecture for Differentiated Services）、ＩＥＴＦ標準勧告文書（IETF Request for Comments）、２４７５、１９９８年１２月
【非特許文献４】
［Booch99］  ジー・ブーチ（G. Booch）、ジェイ・ランボウ（J. Rumbaugh）、アイ・ヤコブソン（I. Jacobson）、統一モデリング言語ユーザガイド（The Unified Modeling Language User Guide）、アディソン・ウェズリー・ロングマン（Addison Wesley Longman）、１９９９年
【非特許文献５】
［Bor00］  シー・ボルマン（C. Bormann）他、単純な会議制御プロトコル（Simple Conference Control Protocol）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-ietf-mmusic-sccp-01.txt＞
【非特許文献６】
［Bum00］  エル・バーネス（L. Burness）他、移動性をサポートする適応化サービスのための知的サービス品質アーキテクチャ（The BRAIN Quality of Service Architecture for Adaptable Services with Mobility Support）、ＰＩＭＲＣ２０００会報（in Proceedings of the PIMRC 2000）、２０００年、ロンドン
【非特許文献７】
［Cama00］   ジー・カマリロ（G. Camarillo）、ＳＤＰ必須条件の確認（Confirmation of SDP preconditions）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-camarillo-manyfolks-confirm-02.txt＞
【非特許文献８】
［Cama00a］ ジー・カマリロ（G. Camarillo）、ＳＤＰ必須条件を用いた第３者呼制御（Third party call control with SDP preconditions）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-camarillo-3pcc-pos-00.txt＞
【非特許文献９】
［Conneg00］  ジー・クライン（G. Klyne）編、改訂メディア特徴セット一致アルゴリズム（A revided media feature set matching algorithm）、ＩＥＴＦメディア特徴登録分科会、未完成（IETF media feature registration WG, Work-in-progress）、＜draft-klyne-conneg-feature-match-02.txt＞
【非特許文献１０】
［Conneg00a］  ジー・クライン（G. Klyne）編、複合メディアの特徴の識別（Identifying composite media features）、ＩＥＴＦｃｏｎｎｅｇ分科会、未完成（IETF conneg working group, Work-in-progress）、＜draft-ietf-conneg-feature-hash-05.txt＞
【非特許文献１１】
［Frolu98］  エス・フロルド（S. Frolund）、ジェイ・コイスチニエン（J. Koistinien）、ＱＭＬ：サービス品質仕様のための言語（QML: A Language for Quality of Service Specification）、ＨＰ−Ｌａｂ技術レポート（HP-Lab Technical Reports）、ＨＰＬ−９８−１０，９８０２１０
【非特許文献１２】
［Handl98］  エム・ハンドレイ（M. Handley）、ブイ・ヤコブソン（V. Jacobson）、ＳＤＰ：セッション記述プロトコル（SDP : Session Description Protocol）、ＩＥＴＦ標準勧告文書（IETF Request for Comments）：２３２７、１９９８年４月
【非特許文献１３】
［Handl99］  エム・ハンドレイ（M. Handley）、エイチ・シュルツリン（H. Schulzrinne）、イー・スコラー（E. Schooler）、ジェイ・ローゼンバーグ（J. Rosenberg）、ＳＩＰ：セッション開始プロトコル（SIP : Session Initiation Protocol）、ＩＥＴＦ標準勧告文書（IETF Request for Comments）：２５４３、１９９９年３月
【非特許文献１４】
［Handl00］  エム・ハンドレイ（M. Handley）、シー・パーキンス（C. Perkins）、イー・ウェラン（E. Whelan）、セッション告知プロトコル（Session Announcement Protocol）、ＩＥＴＦ標準勧告文書（IETF Request for Comments）：２９７４、２０００年１０月
【非特許文献１５】
［ISOX641］  ＩＴＵ勧告Ｘ．６４１（１２／９７）｜ＩＳＯ／ＩＥＣ１３２３６：１９９８、情報技術−サービス品質：フレームワーク（Information technology-Quality of Service : Framework）
【非特許文献１６】
［Kassl99a］  エー・カスラー（A. Kassler）、ピー・シュルテス（P. Schulthess）、無線ＡＴＭネットワークのためのエンドツーエンドサービス品質管理アーキテクチャ（An End-to-End Quality of Service Management Architecture for Wireless ATM networks）、ＨＩＣＳＳ３２会議（Proceedings of the HICSS 32）、米国、ハワイ、マウイ、１９９９年１月
【非特許文献１７】
［Kassl99b］  エー・カスラー（A. Kassler）、ピー・シュルテス（P. Schulthess）、無線ＡＴＭのＱＯＳパラダイムの移動ブロードバンドアプリケーション及びユーザへの拡張（Extending the QoS paradigm of Wireless ATM to Mobile Broadband Applications and to the User）、ＷＣＮＣ’９９会議（Proceedings of the WCNC'99）、米国、ニューオリンズ、１９９９年９月
【非特許文献１８】
［Kassl00］  エー・カスラー（A. Kassler）他、ＢＲＥＮＴＡ−適応化マルチメディア通信のための移動性及びサービス品質のサポート（BRENTA-Supporting Mobility and Quality of Service for Adaptable Multimedia Communication）、ＩＳＴ移動通信サミット２０００会議（Proceedings of the IST Mobile Communications Summit 2000）、アイルランド、ゲールウェイ（Galway）、２０００年１０月、４０３〜４０８頁
【非特許文献１９】
［Kassl00a］  エー・カスラー（A. Kassler）他、ＱｏＳサポートを有する適応化マルチメディアサービスのためのオープンエンドシステムアーキテクチャ（An Open Endsystem Architecture for Adaptable Multimedia Services with QoS Support）、ＢＲＡＩＮワークシップ会議（Proceedings of the BRAIN workshop）、ロンドン、２０００年
【非特許文献２０】
［Levin01］  オー・レビン（O. Levin）、マルチメディア及びビデオのサポートのためのＳＩＰ要件（SIP Requirements for support of Multimedia and Video）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-levin-sip-for-video-00.txt＞
【非特許文献２１】
［Marsh00］  ダブル・マーシャル（W. Marshall）他、リソース管理のためのＳＩＰ拡張（SIP Extensions for Resource Management）、ＩＥＴＦドラフト（IETF draft）、＜draft-ietf-sip-manyfolks-resorce-00＞、２０００年１１月
【非特許文献２２】
［Nahr95］  ケー・ナーステッド（K. Nahrstedt）、ジェイ・スミス（J. M. Smith）、ＱｏＳブローカ（The QoS Broker）、ＩＥＥＥマルチメディアマガジン（IEEE Multimedia Magazine）、１９９５年春（２）１、５３〜６７頁
【非特許文献２３】
［OTT99］  ジェイ・オット（J. Ott）他、グループ協働のための能力記述（Capability description for group cooperation）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-ott-mmusic-cap-00.txt＞
【非特許文献２４】
［Pan99］  ピー・パン（P. Pan）、エイチ・シュルツリン（H. Schulzrinne）、ＹＥＳＳＩＲ：インターネットのための単純な予約メカニズム（YESSIR : A Simple Reservation Mechanism for the Internet）、コンピュータ通信レビュー（Computer Communication Review(CCR)）、ＶＯＬ．２９，Ｎｏ．２、８９〜１０１頁、１９９９年４月
【非特許文献２５】
［Pasqu92］  ジェイ・パスクアーレ（J. Pasquale）、ジー・ポリゾス（G. polyzos）、イー・アンダーソン（E. Anderson）、ブイ・コンペラ（V. Kompella）、マルチメディアマルチキャストチャンネル（The Multimedia Multicast Channel）、デジタルオーディオ及びビデオのためのネットワーク及びオペレーティングシステムに関する第３回国際会議会報（Proc. of 3rd International Workshop on Network and Operating System Support for Digital Audio and Video）（ＮＯＳＳＤＡＶ  ９２）、カリフォルニア州、サンディエゴ、１９９２年１１月、１８５〜１９２頁
【非特許文献２６】
［Pasqu93］  ジェイ・パスクアーレ（J. Pasqual）他、ディメンションツリーにおけるフィルタ伝播：連続メディアネットワークにおける帯域幅と処理のトレードオフ（Filter Propagation in Dissemination Trees : Trading off Bndwidth and Processing in Continuous Media Networks）、ＮＯＳＳＤＡＶ９３会報（Proc. of NOSSDAV 93）、英国、ランカスター、ランカスター大学、１９９３年、２６９〜２７８頁
【非特許文献２７】
［RFC2533］  ＲＦＣ２５３３、メディア特徴セットを記述する構文（A Syntax for Describing Media Feature Sets）、グラハム・クライン（Graham Klyne）、５ＧＭ／コンテンツ技術（5GM/Content Technologies）、１９９９年３月
【非特許文献２８】
［RFC2703］  ＲＦＣ２７０３、プロトコル独立コンテンツ交渉フレームワーク（Protocol-independent Content Negotiation Framework）、グラハム・クライン（Graham Klyne）、５ＧＭ／コンテンツ技術（5GM/Content Technologies）、１９９９年９月
【非特許文献２９】
［SIPRES01］  ダブル・マーシャル（W. Marshall）他、リソース管理とＳＩＰの統合−リソース管理のためのＳＩＰ拡張（Integration of Resource Management and SIP-SIP Extensions for Resource Management）、ＩＥＴＦのＳＩＰ分科会、未完成（IETF SIP working group, Work- in-progress）、＜draft-ietf-sip-manyfolks-resource-01.txt＞
【非特許文献３０】
［SDPCN00］  エフ・アンドリーセン（F. Andreasen）、ＳＤＰ単純能力交渉（SDP Simple Capability Negotiation）、ＩＥＴＦのＭＭＵＳＩＣ分科会、未完成（IETF MMUSIC working group, Work-in-progress）、＜draft-andreasen-mmusic-sdp-simcap-00.txt＞
【非特許文献３１】
［SDPCN01］  エフ・アンドリーセン（F. Andreasen）ＳＤＰ単純能力交渉要件（SDP Simple Capability Negotiation Requirements）、ＩＥＴＦのＭＭＵＳＩＣ分科会、未完成（IETF MMUSIC working group, Work-in-progress）、＜draft-andreasen-mmusic-sdp-simcap-reqts-00.txt＞
【非特許文献３２】
［SDPNG01］  ディー・クッチャー（D. Kutscher）他、セッション記述及び能力交渉のための要件（Requirements for Session Description and Capability Negotiation）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-kutscher--mmusic-sdpng-req-01.txt＞
【非特許文献３３】
［SHULZ98］  エイチ・シュルツリン（H. Schulzrinne）、エー・ラオ（A. Rao）、アール・ランフィエ（R. Lanphier）、リアルタイムストリーミングプロトコル（ＲＴＳＰ）（Real Time Streaming Protocol (RTSP)）、ＩＥＴＦ標準勧告文書（IETF Request for Comments）、２３２６、１９９８年４月
【非特許文献３４】
［SIPRES01］  ダブル・マーシャル（W. Marshall）他、リソース管理とＳＩＰの統合−リソース管理のためのＳＩＰ拡張（Integration of Resource Management and SIP-SIP Extensions for Resource Management）、ＩＥＴＦのＳＩＰ分科会、未完成（IETF SIP working group, Work- in-progress）、＜draft-ietf-sip-manyfolks-resource-01.txt＞
【非特許文献３５】
［SMIL98］  同期マルチメディア統合言語（ＳＭＩＬ）（Synchronized Multimedia Integration Language (SMIL)）１．０仕様書、Ｗ３Ｃ勧告、１９９８年６月１５日
【非特許文献３６】
［Yeado93］  エヌ・イェードン（N. Yeadon）、エフ・ガルシア（F. Garcia）、ディー・ハッチンソン（D. Hutchinson）、ディー・シェパード（D. Shepherd）、フィルタ：マルチピア通信のためのＱｏＳサポートメカニズム（Filters: QoS Support Mechanisms for Mulipeer Communications）、通信における選択された領域に関するＩＥＥＥジャーナル（IEEE Jounal on Selected Areas in Communications）、Ｖｏｌ．１４，Ｎｏ．７、１９９３年９月  次に、関連する先行文献について、簡単に説明する。
【０００８】
「ダブル・マーシャル（W. Marshall）他、リソース管理のためのＳＩＰ拡張（SIP Extensions for Resource Management）、ＩＥＴＦドラフト（IETF draft）、＜draft-ietf-sip-manyfolks-resorce-00＞」において、その著者らは、マルチフェーズの呼設定メカニズム（multi-phase call-setup mechanism）を提案し、このメカニズムにより、ネットワークＱｏＳ及び安全確立（security establishment）は、セッション開始プロトコル（ＳＩＰ）によって開始され、セッション記述プロトコル（ＳＤＰ）によって記述されるセッションの必須条件となる。ネットワークリソースは、既存のネットワークリソース予約メカニズム（例えば、ＲＳＶＰ）を用いて、セッションが開始される以前に確保される。リソース管理プロトコルは、呼シグナリングの２つのフェーズ間でインタリーブされ、参加者は、ネットワークにおいてリソースが使用可能になった後に招待される。必須条件の確認は、明示的に知らされる。リソース管理は、ネットワークリソースに対してのみ行われる。必須条件が満たされているか否かを判定するためのＳＤＰへの拡張が紹介されている。
【０００９】
「ジー・カマリロ（G. Camarillo）、ＳＤＰ必須条件の確認（Confirmation of SDP preconditions）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-camarillo-manyfolks-confirm-02.txt＞」においては、どのパーティが必須条件の確認を送るかを示す追加的な方向属性が紹介されている。更に、「ジー・カマリロ（G. Camarillo）、ＳＤＰ必須条件の確認（Confirmation of SDP preconditions）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-camarillo-manyfolks-confirm-02.txt＞」は、ＳＤＰ必須条件が用いられている場合にＳＩＰにおける第３者呼制御を実行するためのメカニズムを提案している。
【００１０】
「ＲＦＣ２５３３、メディア特徴セットを記述する構文（A Syntax for Describing Media Feature Sets）、グラハム・クライン（Graham Klyne）、５ＧＭ／コンテンツ技術（5GM/Content Technologies）、１９９９年３月」において、その著者らは、メディア処理能力を表すメディア特徴セットを表現するフォーマットを提案している。更に、特徴セットに適合するアルゴリズムも提案されている。このアルゴリズムは、センダとレシーバの能力が互換性を有するか否かを判定するために使用することもできる。
【００１１】
この適合アルゴリズムは、「ジー・クライン（G. Klyne）編、改訂メディア特徴セット一致アルゴリズム（A revided media feature set matching algorithm）、ＩＥＴＦメディア特徴登録分科会、未完成（IETF media feature registration WG, Work-in-progress）、＜draft-klyne-conneg-feature-match-02.txt＞」において更に改善されている。
【００１２】
更に、「ジー・クライン（G. Klyne）編、複合メディアの特徴の識別（Identifying composite media features）、ＩＥＴＦｃｏｎｎｅｇ分科会、未完成（IETF conneg working group, Work-in-progress）、＜draft-ietf-conneg-feature-hash-05.txt＞」では、特徴表現のハッシュを用いて複合メディア特徴セットを記述する複合メディア特徴セットのための省略フォーマットが提案されている。このフォーマットは、逆参照を行う（dereferencing）如何なる特定のメカニズムからも独立して、任意の特徴セット表現を参照するための省略形式を提供する。「エフ・アンドリーセン（F. Andreasen）ＳＤＰ単純能力交渉（SDP Simple Capability Negotiation）、ＩＥＴＦのＭＭＵＳＩＣ分科会、未完成（IETF MMUSIC working group, Work-in-progress）、＜draft-andreasen-mmusic-sdp-simcap-00.txt＞」において、その著者らは、能力の組（capability set）を容易に参照できるようにするために、能力の組がハンドル（上述したハッシュに類似する）を含む必要があるとの要件について記述している。
【００１３】
「ＲＦＣ２７０３、プロトコル独立コンテンツ交渉フレームワーク（Protocol-independent Content Negotiation Framework）、グラハム・クライン（Graham Klyne）、５ＧＭ／コンテンツ技術（5GM/Content Technologies）、１９９９年９月」において、その著者らは、インタラクトするリソースに対する、プロトコルから独立したコンテンツ交渉のための抽象化されたフレームワークを提案している。しかしながら、このフレームワークは、コンテンツ交渉処理を提供するものではない。このフレームワークは、センダの能力と、伝送すべきデータリソースと、レシーバの能力と、これらの能力を交換するプロトコルとに対する要求を識別する。交渉は、一連の交渉メタデータの交換によって実行される。伝送される特定のデータファイルが見つかった場合には、交渉は中止される。センダがそのファイルを決定した場合、センダはデータを転送し、それ以外の場合は、レシーバはセンダに知らせる。この提案しているフレームワークは、コンテンツ交渉に関する。
【００１４】
「ディー・クッチャー（D. Kutscher）他、セッション記述及び能力交渉のための要件（Requirements for Session Description and Capability Negotiation）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-kutscher--mmusic-sdpng-req-01.txt＞」は、マルチパーティによるマルチメディア会議シナリオにおけるセッション記述及びエンドポイント能力を取り扱うフレームワークの要件を特定している。ユーザの嗜好、システムの能力又は他の制約に基づいて、会議について異なるコンフィグレーションを選択することができる。潜在的なコンフィグレーションの共通の組を決定し、情報交換のためにこれらの共通のコンフィグレーションの１つを選択するために、ピア間の交渉処理に関する要件が識別されるが、この要件は記述されない。この能力交渉を用いて、潜在的な参加者のエンドシステムの能力に互換性を有する有効なセッション記述及びユーザの嗜好が得られる。異なる種類の会議に対応して、異なる交渉ポリシを用いてもよい。また、セッション設定に関連するネットワークリソース予約に関する要件も識別されている。更に、能力を記述し、交渉言語を提供する手法が提案されているが、プロトコルについては説明されていない。
【００１５】
「エフ・アンドリーセン（F. Andreasen）ＳＤＰ単純能力交渉（SDP Simple Capability Negotiation）、ＩＥＴＦのＭＭＵＳＩＣ分科会、未完成（IETF MMUSIC working group, Work-in-progress）、＜draft-andreasen-mmusic-sdp-simcap-00.txt＞」の著者らは、最小限の、下位互換性を有する（backward compatible）能力交渉メカニズムを提供するＳＤＰ拡張の組を提案している。「ビー・ベザー（B. Beser）、ＳＤＰのコーデック能力属性（Codec Capabilities Attribute for SDP）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-beser-mmusic-capabilities-00.txt＞」の著者は、エンドポイントがコーデックの選択肢を知り、共通の組に同意できるようにＳＤＰを拡張している。これにより、通信パートナは、発信者（originator）の能力及び嗜好に関する情報を得ることができる。「ジェイ・オット（J. Ott）他、グループ協働のための能力記述（Capability description for group cooperation）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-ott-mmusic-cap-00.txt＞」においては、マルチパーティによる共同研究のシナリオにおけるエンドシステムの潜在的且つ特定のコンフィグレーションを記述する表記法が提案されている。これにより、システム能力を定義し、共通の能力の組を算出し、セッション記述において用いられる選択されたメディア記述を表現するメカニズムが実現される。しかしながら、この文献には、能力交換のためのプロトコルは示されていない。「シー・ボーマン（C. Bormann）他、単純な会議制御プロトコル（Simple Conference Control Protocol）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-ietf-mmusic-sccp-01.txt＞」の著者らは、密結合会議（tightly coupled conferences）のための単純な会議制御プロトコル（simple conference control protocol：ＳＣＣＰ）のサービスを定義している。ここでは、分散アプリケーションリソースに関する、メンバー管理、アプリケーション／セッション管理、及びアクセス制御規則が定義されている。例えばＳＩＰを用いて確立することもできる会議の状態は、ＳＣＣＰを用いて、その継続期間の間管理される。この処理は、適切なコンフィグレーション、コンフィグレーションに関する交渉、及びコンフィグレーションの変更の発見を含む。しかしながら、ここでは、ローカルリソース管理を伴うインタラクションは行われない。
【００１６】
「ケー・ナーステッド（K. Nahrstedt）、ジェイ・スミス（J. M. Smith）、ＱｏＳブローカ（The QoS Broker）、ＩＥＥＥマルチメディアマガジン（IEEE Multimedia Magazine）、１９９５年春（２）１、５３〜６７頁」において、その著者らは、エンドポイントにおけるリソースを組織化し、複数の層に亘るリソース管理を調整する機能的エンティティであるＱｏＳブローカに基づくエンドポイントアーキテクチャのためのモデルを提案している。システムを適切に構成するために、ＱｏＳブローカは、承認制御（admission control）及び交渉を用いる。ピアエンティティ間の交渉により、通信システムの全ての必要なコンポーネントを含む有効なコンフィグレーションが構築される。
【００１７】
本明細書において、経済原理（economy principle）という用語は、「ケー・ナーステッド（K. Nahrstedt）、ジェイ・スミス（J. M. Smith）、ＱｏＳブローカ（The QoS Broker）、ＩＥＥＥマルチメディアマガジン（IEEE Multimedia Magazine）、１９９５年春（２）１、５３〜６７頁」に記述されている、以下のような確保の順序を示す。
・最初にローカルリソースが確保される。
・次に、ピアエンティティとの交渉により、そのピアエンティティにおけるリソース要求にマッピングすることができるコンフィグレーションが導き出され、このリソース要求が予約される。
・ネットワークリソースは、高価であり、複数のユーザによって共有されているため、ネットワークリソースの確保は、最後に行われる。
【００１８】
「オー・レビン（O. Levin）、マルチメディア及びビデオのサポートのためのＳＩＰ要件（SIP Requirements for support of Multimedia and Video）、ＩＥＴＦインターネットドラフト、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-levin-sip-for-video-00.txt＞」の著者らは、ＩＰに亘るリアルタイムマルチメディアサポートのための呼制御プロトコルのための要件の組を提案している。ここで、能力を表現する必要があり、必要なリソースの量を特定するために能力を知らせる必要があり、及び能力及び確保されたリソースに基づく範囲内で、メディアストリームを開き／閉じ／変更するために、呼制御メカニズムが必要である。また、この著者らは、セッション中に、（使用可能であれば）新たな能力を告知することを提案している。更に、ピア（peer）は、使用されるコーデックの共通の組に同意する必要がある。ストリームを開始／終了するセッション制御メカニズムは、必須条件として位置づけられる。
【００１９】
「エル・バーネス（L. Burness）他、移動性をサポートする適応化サービスのための知的サービス品質アーキテクチャ（The BRAIN Quality of Service Architecture for Adaptable Services with Mobility Support）、ＰＩＭＲＣ２０００会報（in Proceedings of the PIMRC 2000）、２０００年、ロンドン」、「エー・カスラー（A. Kassler）他、ＢＲＥＮＴＡ−適応化マルチメディア通信のための移動性及びサービス品質のサポート（BRENTA-Supporting Mobility and Quality of Service for Adaptable Multimedia Communication）、ＩＳＴ移動通信サミット２０００会議（Proceedings of the IST Mobile Communications Summit 2000）、アイルランド、ゲールウェイ（Galway）、２０００年１０月、４０３〜４０８頁」、及び「エー・カスラー（A. Kassler）他、ＱｏＳサポートを有する適応化マルチメディアサービスのためのオープンエンドシステムアーキテクチャ（An Open Endsystem Architecture for Adaptable Multimedia Services with QoS Support）、ＢＲＡＩＮワークシップ会議（Proceedings of the BRAIN workshop）、ロンドン、２０００年」においては、ローカル、ピア（peer）及びネットワークリソース予約をエンドツーエンドＱｏＳ管理のためのフレームワークに統合するエンドシステムアーキテクチャが提案されている。ユーザ嗜好と適応経路とがＱｏＳ状態とともに用いられて、アプリケーションレベルにおけるＱｏＳ交渉が行われる。更に、ローカルリソースとのインタラクションが紹介されている。階層化されたアーキテクチャは、異なる種類のアプリケーションへのサポートを実現する。
【００２０】
２０００年１２月８日に出願された欧州特許出願第００１２６９７５．２号には、例えばＳＩＰ等の既存のセッションプロトコル層をストリーム集合体のマルチプルレベルにおける前交渉適応経路（pre-negotiating Adaptation Path）に拡張する基礎的な発想が開示されている。しかしながら、この欧州特許出願は、十分に完成された（full-fledged）エンドツーエンドＱｏＳ交渉プロトコルを詳細には開示しておらず、また、承認制御（admission control）及びリソース予約処理を統合していない。
【００２１】
２０００年、５月２４日に出願された欧州特許出願第００１１１１９１．３号においては、複数のマルチメディアストリーム間におけるＱｏＳ同期及びＱｏＳ相関を実現するためのデータモデルが詳細に開示されている。このようなデータモデルは、上述した欧州特許出願第００１２６９７５．２号に開示されている概念を発展させたものである。しかしながら、このデータモデルは、コーデック等の能力の記述をカバーしていない。
【発明の開示】
【発明が解決しようとする課題】
【００２２】
［Levin01］の第２頁には、次のような記述がある。「（・・・）セッション確立処理の間の能力合意に基づいて、ある品質のセッションが確立され、この品質がセッションの継続期間に亘って維持される。ここで、問題は、能力仕様、リソース予約、メディアストリーム制御の３つの領域における表現能力の欠如として記述することができる。
【００２３】
望まれる最終的な目的は、次の通りである。
・コンフィグレーションにおける要求を行うことなく、能力（すなわち、サポートされるメディア、ＣＯＤＥＣアルゴリズム、帯域幅等）を表現する。
・特定のセッションに要求される全てのリソースを（例えば、能力に関連して）知らせる。
・セッション内において、メディアストリームを明示的に開き及び閉じ、及び事前に告知された能力及び確保されたリソースの範囲内であるストリームのパラメータを変更する。」
更に、この論文の著者は、第４頁において、次のように記述している。「能力告知（capabilities announcement）」フェーズを実際のメディアストリームから分離するために、ＳＩＰ拡張が必要となる場合もある。
【００２４】
従来の課題に鑑み、本発明は、効果的にＱｏＳ保証を実現する概念を提供することである。
【課題を解決するための手段】
【００２５】
本発明の目的は、独立請求項に示す特徴によって達成される。従属請求項は、本発明の中心的概念を更に発展させたものである。
【００２６】
本発明の更なる目的及び利点は、添付の図面を参照して後に説明する。
【発明を実施するための最良の形態】
【００２７】
効果的にＱｏＳ保証を実現するために重要となる要件は以下の通りである。
【００２８】
次のような、複数の側面（aspects）を互いにリンクするメカニズム及びプロトコルの包括的な組の提供。
１．前交渉（Pre-Negotiation）。これは、オフラインで行ってもよく、及び例えばＬＤＡＰ等を用いて公表してもよい。
２．アドホック予約によって統合された交渉
２．１経済原理
２．２以下にリストとして示す特徴によって強調された、リソース予約の調整
・ローカル及びピア（peer）のリソース管理とのインタクラクションに関する特定の記述（この点において、何らかのプロトコル手続きが必要である）
・適応経路を構築し、参照する状態ＩＤの使用
・異なるレベルにおける適応経路のための階層的状態マシーンへの明示的言及
本発明の目的の１つは、次のような様々なサービスをサポートすることである。
・会話サービス
・配信サービス
・情報検索サービス
本発明によって提案される概念によって、これらの異なる種類のサービスに適応化することができる。サービスの種類に応じて、及び各通信相手（センダ／レシーバ）の通信モードに応じて、予約を行うネットワークとエンドシステムリソースとの間のインタラクションに必要とされる動作のシーケンスが異なる場合があるため、このような適応化が必要となる。
【００２９】
例えば、レシーバがセンダからの通信を待つ必要があるか否か、又はネットワークにおけるリソースの予約をどの端末（センダ又はレシーバ）が開始するかといった質問を特定する必要がある。これらの質問に対する回答は、サービスの種類に応じて異なる。
【００３０】
エンドツーエンド交渉プロトコル（End-to-End Negotiation Protocol：Ｅ２ＥＮＰ）の概念
ＱｏＳが使用可能な通信セッション（QoS-enabled communication session）の確立は、エンドツーエンドのＱｏＳアスペクトの交渉によって開始される多段階処理によって実現される。ここで提案する手法では、各ピアが、共通レベルのＱｏＳに関する交渉を予め（すなわち、実際の通信が開始される前に）行い、各ピアがこのＱｏＳの使用に同意する。これは、偶発的な（contingent）交渉（例えば、オーディオ／ビデオストリームの確立）又は再交渉（進行中のセッション期間中のＱｏＳ契約の変更）を効率的に取り扱うために、各ピアが後に使用することができる語彙に関する前交渉の形式で行われる。この手法の利点は、各ピアがストリーミングの間に完全な交渉サイクルを実行することに代えて、交渉状態を参照するのみでよいため、再交渉に必要な時間が短縮されるという利点がある。更に、交渉の種類は、全てのピアにおいて、現在使用可能な能力に基づいてカスタマイズすることができる。
【００３１】
特定されるステップは、以下の通りである。
１．ピア間におけるＱｏＳ契約の組の前交渉。このようなＱｏＳ組は、所定の種類（例えば、オーディオストリーム、ビデオストリーム又はデータストリーム）の汎用ストリームのための適応経路を記述する。
２．中間のステップとして、各ピアは、複数のストリーム間のＱｏＳ相関及び同期アスペクトの交渉を行う。このステップは、セッションに含まれるストリームが１つのみである場合は不要であり、この場合、ＱｏＳ相関は、単純に無視される。このステップにより、セッション概念が構築される。なお、ピアが複数のストリームを調整する必要がある場合、交渉されたＱｏＳ状態から導出されるＱｏＳ相関及び同期の問題は、（例えば、ＲＴＰに基づいて）特定の調整機能を起動することによって、実行時に取り扱ってもよい。
３．最後のステップとして、各ピアは、ストリーム確立時に、ステップ（１）において確立された前交渉された語彙に基づいて、ストリーム毎にＱｏＳ契約を取り決める。このステップにおいては、実際の承認制御（admission control）が実行される。ここで、この本発明の一側面として、ネットワークリソースは共有すべきであり、ローカルリソースより高価であるという事実に鑑みた経済原理に従うことを提案する。
【００３２】
ここで提案される処理は、次のような順序のステップに基づいて行われる。
３．１例えばＣＰＵ、メモリ、電源等のローカルリソース（すなわち、ローカルシステムによって管理されるリソース）は、通信を開始するパーティ（すなわち、イニシエータ（initiator））の端末装置において確保される。これらは、イニシエータによって排他的に用いられるものであるため、最も安価なリソースである。イニシエータとなるパーティによって確保されるリソースの量は、イニシエータが最も興味を有し、処理することができる品質に対応する。
３．２例えばＣＰＵ、メモリ、電源等のリモートリソースは、通信を確立するための要求を受け取るパーティ（すなわち、レスポンダ）の端末装置において確保される。これらのリソースは、例えば、ビデオオンデマンドのシナリオ（この場合、レスポンダは、ビデオサーバであり、ビデオサーバは、複数のユーザからの複数の要求に応じる必要がある。）等の複数の遠隔通信セッションに関して、複数のイニシエータによって共有される場合がある。イニシエータ側においてリソースの利用可能性を確認する以前にこれらの共有リソースを予約しようとする（したがって、レスポンダにおける他の通信セッションに影響を与える）ことは無意味である。
３．３ローカルリソース及びリモートリソースの両方が無事に予約された場合にのみ、複数のパーティによって（定義によって）共有されるネットワークリソースが確保される。この意味において、ネットワークリソースは、全てのリソースのうちで最も高価なリソースであるとみなすことができる。
４．本発明は、所定の通信セッションの所定の参加者の能力のコンフィグレーションの変化（例えば、所定のマルチメディアコーデックのインストール又は削除）に関する情報をピアに通知するプロトコル手続きを提供する。各ピアに前もってこの情報を通知することにより、現在アクティブなあらゆる通信セッションに関して、及び通信セッションを確立するための将来の試みに関する全ての交渉処理に関して、適切な動作を行うことができる。
【００３３】
ステップ（２）、（３）（又はステップ（１）（注２）、（２）、（３））は、まとめて一回の処理（注３）として取り扱ってもよく、個々の動作のシーケンス（注４）とみなしてもよい。
【００３４】
なお、ある状況では、ステップ（３．１）、（３．２）、（３．３）のみが必要である場合もある。このような状況とは、例えば、デフォルトとして（固定の設定を用いて）全てが予め取り決められている場合、及びサーバにおいて、ビデオストリームに関する唯一の品質及びコンフィグレーションが存在している場合等である。
【００３５】
Ｅ２ＥＮＰの主な特徴（key aspect）は、Ｅ２ＥＮＰがネットワーク予約シグナリングプロトコルに関連して用いることができるだけではなく、他の種類のＱｏＳアーキテクチャに関連しても用いることができるという点である。後者の場合、前交渉では、各ピアが、各ピアの能力に関して、用いるべきＱｏＳクラスの種類に同意することに重点が置かれる。
【００３６】
交渉の内容
この章では、（ｉ）情報の種類と、（ｉｉ）どのような状況でこの情報の種類を交渉する必要があるかについて重点を置く。
【００３７】
詳しくは、各ピアは、以下の事項に合意する必要がある。
・どのＥ２ＥＮＰ（又は他のプロトコル）を用いるか
・どの能力及びコンフィグレーションが利用可能であり、適用可能であるか
・どのＱｏＳ契約が適用可能であり、適応経路を形成するか
・適応経路自体
サポートされるＥ２ＥＮＰの種類
現在の当分野のアプリケーションの多くは、特定の改良を施さなければ、ここで説明するＥ２ＥＮＰを採用することができない。これらのアプリケーションは、当分野で現在用いられている交渉メカニズムの他の何らかの形式に適用される。また、将来のアプリケーションがＥ２ＥＮＰ又はそのちょっとだけ異なるバージョンを部分的にのみサポートしてもよいと仮定することは合理的である。
【００３８】
これらの理由から、交渉を行うべき第１の情報の種類は、サポートされるＥ２ＥＮＰの種類とバージョンである。
【００３９】
この情報は、ディレクトリサーバを用いて得ることができる。例えば、所定のピアに関連付けられたディレクトリエントリと、名前が付けられたＥ２ＥＮＰは、所定のピアがＥ２ＥＮＰをサポートしていることを示すトークンとしての役割を果たす。ディレクトリエントリは、以下のようなものであってもよい。
【００４０】
【表３】
2004537187.tif 000005
【００４１】
ここで、「type of service」は、例えば情報検索サービスや会話サービスを示し、「protocl」は、例えば、ＳＩＰ（ＳＤＰとともに）、Ｈ．３２３、ＲＴＳＰ等（すなわち、このＥ２ＥＮＰがどのプロトコルに準拠しているか）を示し、「version」は、機能の増加的な組を区別する数値を示す。上述したプロトコルに加えて、交渉を行い、適応経路を記述するために特別な拡張が必要である。
【００４２】
一具体例においては、Ｅ２ＥＮＰは、サービスの種類に基づいて、以下のようなプロトコルにマッピングすることができる。
【００４３】
【表４】
2004537187.tif 000006
【００４４】
この情報は、ピアによって意図的に、直接問い合わされるだけではなく、ディレクトリサーバ自体が前もってこの情報を告知してもよい。
【００４５】
能力
ピア間で、以下のような様々な種類の能力について交渉を行う必要がある。
・メディアタイプ及びＱｏＳ契約の範囲（Dimension）
・ビットレート
・コーデック
・端末能力
・ネットワークリソース予約サポート
以下の章では、各種類の能力について詳細に分析する。
【００４６】
メディアタイプ及びＱｏＳ契約の範囲
メディアタイプ（オーディオ／ビデオ／データ）は、Ｅ２ＥＮＰメッセージ内の情報をふるい分ける（screening）ために用いることができる。ピアは、共通のメディアタイプの組について同意する。具体例として、レシーバが生のオーディオストリームを確立することを要求したが、対応するオーディオストリームのセンダがマイクロフォンを備えていない場合、オーディオコーデックに関するこれ以上の交渉は無意味であり、したがってスキップされる。したがって、メディアタイプの使用は、交渉の間にピアにとって利用しやすいフォーマットにＥ２ＥＮＰメッセージを変換する。メディアタイプに加えて、本発明は、ＱｏＳ契約が作成されているＱｏＳ契約の範囲（QoS Contract Dimension）のリストを含む要求を識別する。一具体例として、１つのピアがフレームレートとフレームサイズに関する交渉を希望し、他方のピアがフレームレートのみに関する交渉を希望する場合がある。
【００４７】
一具体例として、ＶｏＤサーバが利用できる映画の表現（バージョン）を１つのみしか有しておらず、利用可能なネットワークメディア適応化ユニット（network media adaptation unit）が存在しない場合、フレームサイズに関する交渉を行っても無意味である。
【００４８】
本発明は、メディアタイプ情報を記述する以下のフォーマットを提案する。
【００４９】
【表５】
2004537187.tif 000007
【００５０】
ここで、「param_audio」及び「param_video」の細分（refinement）は、ＱｏＳ契約の範囲を、例えば、ビデオのフレームサイズ及びフレームレート、オーディオのサンプリング周波数及びチャンネル数等によって詳細にするものであり、これについては次の章で詳細に説明する。このフォーマットは、所定のＥ２ＥＮＰメッセージにおけるメディアタイプの各記述に適用される。
【００５１】
コーデック
ピアがＱｏＳ契約又は適応経路（後述する説明参照）を交渉する前に、各ピアは、どのコーデックが包括的に適用可能かについて同意する必要がある。実現可能なＱｏＳも利用可能なコーデックの種類に依存する。更に、所定のピアは、所定のコーデックの組を備えるが、このコーデックの使用は、他の全てのピアによる等しいコーデックの使用可能性によって実際に拘束される。
【００５２】
今日のＳＩＰインプリメンテーションにより、提案時（invitation time）において、ピアツーピア毎に、よく定義されたストリーム（well-defined stream）の仕様に関して、コーデックの交渉を行うことができる。
【００５３】
本発明のフレームワークにおいては、このようなＳＩＰ能力は、上述したステップ（１）〜（４）におけるステップ（１）において、後のストリーム確立時にどのストリームを用いるかに関わらず、利用可能なコーデックの完全なリストを交渉することによって提供される。換言すれば、各ピアは、これにより、実際のメディア仕様が定まる前に、共通のコーデックの組について合意する。
【００５４】
更に、現在の及び将来の端末装置は、「オンザフライ（on the fly）」動作でコーデックをインストール又は削除できるものであるため、コーデックの共通のセットについて、後の接続中に（例えば、ビデオ会議中に）再交渉を行う必要がある可能性がある。この再交渉は、新たなＳＩＰメッセージを用いて実現することができる。
【００５５】
ビットレート
マルチメディアアプリケーションに用いる帯域幅を最小化するために、クライアントは、以下のような２つの主なメカニズムを用いる。
・低い（固定）ビットレートコーデックを用いて、ネットワークリソースの消費量を低減する
・可変ビットレートコーデックを用いる
クライアントは、互換性があるコーデックの任意の組について合意する必要がある。なお、コーデックのビットレートは、クライアント（送信側／受信側）及びネットワーク（アクセスネットワーク及びコアの両方）にサポートされている必要がある。更に、１つのコーデックが、コーデックのコンフィグレーションに応じて、異なるビットレートレベルを生成してもよい。一具体例として、Ｇ．７２６コーデックは、１６、２４、２３又は４０ｋｂ／ｓのビットレートを生成する。レシーバが所定のコーデックのある種のコンフィグレーションのみしか取り扱えないような場合もある。一具体例として、レシーバが１９．６ｋｂ／ｓのモデムを使用している場合、このレシーバは、Ｇ．７２６コーデックの１６ｋｂ／ｓのコンフィグレーションのみしか取り扱うことができない。更に、ある種のオーディオコーデック及び幾つかのビデオコーデックは、可変ビットレートを生成でき、この可変ビットレートは、通常、漏れバケツモデル（leaky bucket model）を用いて特定される。この場合、ビットレート要求は、持続可能なビットレート、ピークビットレート及びバースト時間（ソースがピークビットレートでデータを送信することが許可されている期間）によって特定される。
【００５６】
本発明が提案する手法では、互換可能なコーデックの組の交渉に加えて、各ピアは、各コーデックについて、各ピアが取り扱うことができる帯域幅に関して有効なコーデックコンフィグレーションに合意する必要がある。イニシエータは、固定ビットレート及び可変ビットレートの両方をサポートする漏れバケツモデル（持続可能なビットレート、ピークビットレート及びバースト時間）を用いて、ピアに対して帯域幅仕様の組を提供及び交渉する。上述の例では、両方のパーティは、次に示すビットレート仕様を有するＧ．７２６コーデックに合意する。（持続可能なビットレート、ピークビットレート及びバースト時間）＝（１６，１６，Ｎ／Ａ）
ビットレートに関して、互換性を有するコーデックコンフィグレーションに合意した後に、ステップ（３）において、ネットワークに対して、実際のコンフィグレーションにおいて使用される実際の目標ビットレートが交渉される。
【００５７】
端末能力
端末装置の物理的特徴（例えば、モニタサイズ）に関する情報をモデル間で交換してもよく、この情報が遠隔通信ネットワークを介したサービスの配信に影響を与えてもよい。例えば、非常に小さな表示装置しか備えていない携帯電話に高解像度の画質のビデオストリームを送信しても無駄であるため、このような処理が重要となる。したがって、各ピアは、ＱｏＳを交渉する際に、端末能力について合意する必要がある。端末能力には、例えば、表示装置のサイズ、表示可能な色数、所定のメディアタイプを処理する包括的な能力（例えば、オーディオミキサが使用可能であるか）及び所定のメディアタイプを処理するために必要なサービスに関する全ての情報等が含まれる。
【００５８】
この点において、合成能力／嗜好プロファイル（Composite Capabilities/Preference Profiles：以下、ＣＣ／ＰＰという）フレームワーク言語（ＸＭＬとＲＤＦの組合せ）及び要求／応答ＨＴＴＰプロトコルによって、ＲＤＦフォーマットでターミナル能力を特定することができる。
【００５９】
ネットワークリソース予約サポート
１又は複数のリモートピアがＲＳＶＰに対応していないことを前もって判断できる場合は、ＲＳＶＰのようなシグナリングプロトコルを用いて、エンドツーエンドでネットワークリソースを要求しようとすることは、無意味である。そこで、可能なソリューションとして、ピアのアクセスネットワークにおいて、所定の信号プロトコルが利用可能であるか否かをピアに問い合わせるとよい。
【００６０】
より単純なソリューションとして、前交渉の間に、ピアがお互いに、どの方向に沿ってネットワークリソースを確保しようとしているかを指示してもよい。このとき用いられる値は、Ｎ／Ａ、レシーバ、センダ／レシーバ等があり、ここでレシーバ及びセンダの概念は、用いられているリソース予約プロトコル（用いられていれば）に関連する。リソース予約プロトコルが用いられている場合、この情報により、リソース予約プロトコルのタイプをモデル化することができる。
【００６１】
例えば、ＲＳＶＰがエンドツーエンドで使用可能な単純なビデオオンデマンドサービスのシナリオにおいては、ＲＳＶＰはレシーバから開始されるため、クライアントはレシーバとして働き、サーバはセンダとして働く。センダによって開始されるＹＩＳＳＩＲ（［Pan99］参照）の場合、コンフィグレーションは、リソース予約プロトコルの観点からは、逆になる。
【００６２】
同様に、エンドツーエンドＲＳＶＰがサポートされているビデオ会議シナリオでは、各ピアは、多くの場合、センダ／レシーバとして構成される。
【００６３】
所定のピアについて方向が特定されていない場合、対応するピアは、所定のピアに対してネットワークリソース予約メカニズムが使用できないと直ちに推定することができる。ここで重要な点は、このモデルにより、ＱｏＳシグナリングプロトコル（例えば、ＲＳＶＰ）がエンドツーエンドで使用不可能な場合にも共同作業が行えるという点である。このような場合は、各ピアは、センダ（又は全く存在しないもの）として単純にモデル化される。本発明は、後者のソリューションを統合する。
【００６４】
ＱｏＳ契約
ＱｏＳ契約は、以下のように表現される高レベルＱｏＳ特性（high-level QoS characteristics）の組として定義される。
・動作ターゲット：所望の値
・動作領域：所望の値の範囲
・閾値／制限：ＱｏＳ適応化ビジネスロジックに関する異なる状況をマーキングする値の組
上述のＱｏＳ仕様のいずれも、最終的には、例えば百分位数、平均値、偏差等を宣言することによって、統計的フォーマットで更に表現してもよい。
【００６５】
適応経路
各ピアは、所定のＱｏＳ契約のみではなく、代替的なＱｏＳ契約にも合意する。代替的なＱｏＳ契約は、時間の経過とともに、ネットワーク及び／又は端末のリソースの利用可能性が変化したときに、いつでも効果的に用いることができる。これにより、各ピアは、どの代替的なＱｏＳ契約を（及びどの状況下で）用いることによって、ＱｏＳの重大な変化又は現在用いられているＱｏＳ契約に関するＱｏＳ違反に対処できるかを知ることができる。
【００６６】
上述したステップ（１）〜（４）のステップ（１）においては、ストリームに関連する適応経路のみが前交渉される。より高レベルなパス（ＱｏＳ相関問題に関連する）は、上述したステップ（１）〜（４）のステップ（２）において、より高いレベルで交渉される。
【００６７】
最良状況ＱｏＳ契約（best-case QoS Contract）とともに、適応経路は、拡張ＱｏＳ契約を構成する。この拡張ＱｏＳ契約は、交渉され、インデクスが付される。ピアが後により低いレベルのＱｏＳに切り換えることを決めた場合、ＱｏＳを階層的な有限状態マシーンの状態として特定するインデクスを他のペアに伝えるだけで、そのＱｏＳ状態への適応化が行われる。
【００６８】
Ｅ２ＥＮＰの種類
通信セッションに参加する動作者（actor）は、以下のような役割を果たす。
・レシーバ／センダ：センダは、単にレシーバにデータを送信し、一方、レシーバは、センダからデータを受信する。双方向会議は、センダ／レシーバとセンダ／レシーバの対としてモデル化される。
・イニシエータ／レスポンダ：イニシエータは、レスポンダに対し、通信セッションに参加するよう促す（invite）。レスポンダは、イニシエータからの要求を待機する。
【００６９】
可能な組合せは以下の通りである。
【００７０】
イニシエータ及びセンダ→レスポンダ及びレシーバ
イニシエータ及びレシーバ→レスポンダ及びセンダ
イニシエータがセンダである場合、メディアストリームのセンダがセッションを開始する（センダが招き、レシーバがコンタクトされることを待つ）。イニシエータがレシーバである場合、メディアストリームのレシーバがセッションを開始する（レシーバが招き、センダがコンタクトされることを待つ）。イニシエータ／センダは、レスポンダ／レシーバと通信を行うことができる。イニシエータ／レシーバは、レスポンダ／センダと通信を行うことができる。
【００７１】
以下、本発明において検討されるＥ２ＥＮＰの種類に影響と与える主なシナリオを一覧として示す。
・ピアツーピア交渉：例えばビデオ会議等に参加する複数のピアに実際に拡張できるが、各ピアの設定（peering）は、直接ピアツーピアＱｏＳ交渉メカニズムによって調整される。
・１×Ｎマルチキャスト交渉：この場合、センダ及び複数のレシーバは、同時に１又は複数のＱｏＳ特性を交渉する必要がある。この処理は、接続全体に亘って（connection-wide basis）行ってもよく（すなわち、全てのピアの最小共通分母を判定する）、選択されたレシーバ毎に行ってもよい（任意のピア間の何らかのＱｏＳ特性に関するピアツーピア交渉。上述の説明参照）。ベストエフォートレベル（best effort level）が合意されている場合、レシーバは、最小の共通ＱｏＳレベルに合意できなくても、通信を行うことができ、この他の場合（例えば、保証されたＱｏＳポリシの場合）、これらのレシーバは、除外され（dropped）、又は他のメカニズムを用いる必要がある。具体例として、センダとレシーバとの間でメディアフィルタ又はメディアトランスコーダ（transcoder）を用いてメディアストリームを調整し、レシーバの能力及びＱｏＳ状態がセンダのＱｏＳ状態に合致するようにしてもよい。メディアトランスコーダは、ある表現を他の表現に変換する（例えば、メディアストリームのコーデックをＰＣＭからＧＳＭオーディオに変換する）ために使用できる。メディアフィルタは、メディアの品質（例えば、センダに適応化を強制することなく、フレームサイズ、フレームレート又は所望の品質）をより精密に適応化するために使用できる。
【００７２】
接続全体のＥ２ＥＮＰ（connection-wide E2ENP）は、様々なソースからの複数のフローにＱｏＳ相関を強制するために効果的に用いることができる。１×Ｎマルチキャスト交渉を用いることにより、複数のレシーバにデータを送信する単独のセンダの場合だけではなく、複数のセンダから供給されるフローのＱｏＳを相関させる単独のレシーバの場合についても、共通のＱｏＳを判定することができる。
【００７３】
ＩＴＵ勧告Ｘ．６４１（１２／９７）｜ＩＳＯ／ＩＥＣ１３２３６：１９９８、情報技術−サービス品質：フレームワーク（Information technology-Quality of Service : Framework）は、上述したような種類の交渉を記述し、イニシエータ、プロバイダ、及び１以上のレスポンダを含む３パーティ交渉を取り扱っている。一方、本発明では、適用範囲をアプリケーションレベルにおけるイニシエータ及び１以上のレスポンダとの間の関係に限定している。プロバイダを明示的に直接的に含めない理由は、プロバイダがトラヒック及び承認制御（admission control）のみにしか関わらないためでる。したがって、ピアとネットワークプロバイダとの間では、トラヒック契約のみを交渉すればよい。リソース（特にネットワークリソース）を事前に所定の期間確保する、すなわちリソースを使用せずに確保することは無意味であるため、この交渉は、セッション確立中にのみ行われる。
【００７４】
ピアは、名目上のＱｏＳレベルに合意することによって、ここに説明するＥ２ＥＮＰ前交渉を実行する。実際の接続確立の間は、ピアは、前交渉された契約を用いる。これらの契約は、ローカルで検査され、リソースが確保される。次に、この処理段階の結果がピアに提示され、ここで初めて余分なリソースが解放される。最後に、このレベルにおいて、ネットワークリソースが確保され、これに応じて、更に余分なリソースを解放してもよい。実際の接続品質を監視することにより、ピアは、前交渉された所定のＱｏＳ契約が満足されているか否かをいつでも判定することができる。ここで、所定のＱｏＳ契約が満足されていない場合、前交渉された適応経路に基づいて、代替的なＱｏＳレベルを選択できるか、及びどのようにして選択するかが判定される。欧州特許出願第００１２６９７５．２号（［Manda00b］）に開示されているように、ネットワークリソースの確保の変更が頻繁に要求されることを回避するために、ＱｏＳ契約及び適応経路に適切な許容範囲及びヒステリシスを設定してもよい。
【００７５】
いずれの場合も、前交渉フェーズの間に、各ピアは、事前に算出された適応経路を含む、事前に構成されたユーザプロファイルに対するビッド（bid）を他のピアから受け取り、このビッドを査定する。この査定は、ビッドにおける各ＱｏＳ契約の各パラメータと、ユーザプロファイルに含まれる対応する情報とを比較することによって行われる。このビッドを受け入れるか、又はカウンタオファー（counteroffer）を提示するかは、提示されたＱｏＳ契約のＱｏＳ範囲全体に基づいて判断される。ビッドが異なるＱｏＳ範囲を有するＱｏＳ契約を提案している場合、相互に理解できるＱｏＳ範囲のサブセットのみが考慮される。
【００７６】
イニシエータは、ビッドとして提示する各ＱｏＳ契約に識別子を付す。レスポンダは、対応する識別子を特定することによって、所定のＱｏＳ契約の受け入れを通知する（又は、カウンタオファーとしてこのＱｏＳ契約を更新する提案を提示する）。レスポンダがより精密なＱｏＳ契約解像度に対応できる場合（例えば、提示された所定のＱｏＳに対応して、レスポンダの１つにおいて、より「緻密な」精度の複数のＱｏＳ契約が使用可能である場合）、このレスポンダは、新たなＱｏＳ契約を含むカウンタオファーを返してもよい。イニシエータはこれらのカウンタオファーを収集し、これらのうちで最も有意義な（meaningful）カウンタオファーを選択し、これらに新たな識別子を付し、新たな交渉ラウンドにおいて、全てのピアに対しこのカウンタオファーを提示する。
【００７７】
サービスの種類とＥ２ＥＮＰの種類との間のマッピング
以下では、上述した様々な種類のサービスに関連して、Ｅ２ＥＮＰがどのように活用されるかを説明する。
【００７８】
会話サービス
これは、リアルタイムビデオ会議又はＣＳＣＷ等の場合である。これらのサービスの主な特徴は、ピア間で交換されるコンテンツの種類が、ユーザによるシステム及び他のピアとのインタラクションに基づいているという点である。例えば、ビデオフローの大半は、生の画像（例えば、ウェブカメラで撮像される）を搬送する。
【００７９】
この他の重要な側面としては、各ピアが、開示時刻及びサービス期間を含む所定の日程について事前に合意する必要があるという点である。この合意は、インターネットの場合、通常ＳＡＰ及びＳＩＰを用いて実現される。
【００８０】
この種類のサービスを実際にどのように活用するかは、現実の具体例に応じて異なる。例えばビデオ会議の場合、テレコミュニケーションの分野では、特別なブリッジが用いられ、スタートポロジソリューション（star topology solution）が提供される。会議に参加しようとするパーティは、単にブリッジにアクセスすることにより、ビデオ会議に参加できる。一方、インターネットの分野では、マルチキャスト技術を用いることが一般的である。すなわち、会議に参加しようとするパーティは、適切なマルチキャストグループを選局すればよい。なお、ここでは、Ｅ２ＥＮＰの観点から、共通レベルのＱｏＳを交渉するために、ピアがユニキャストシグナリングを用いると仮定する。
【００８１】
会話サービスは、全てのピアがセンダ及び／又はレシーバとして動作できる、１つのイニシエータと複数のレスポンダを備える場合としてモデル化することができる。更に、リソース予約プロトコルから、各パーティは、センダ又はレシーバが提供するネットワークリソース予約プロトコル（存在する場合）のいずれも用いることができる。したがって、イニシエータはネットワークから及びレスポンダから（レスポンダは、デコード及び表示のためのリソースを提供する必要があるため）リソースを要求する。更に、イニシエータは、自らのリソースをローカルで管理する。
【００８２】
配信サービス
配信サービスは、コンテンツプロバイダと、（ｉ）既知のコンテンツ消費者又は（ｉｉ）未知のコンテンツ消費者を含むことができる。前者の場合、情報検索サービス（後述）の場合と同様にＳＩＰ又はＲＴＳＰ拡張を用いることができ、後者の場合、ＳＡＰ拡張が考慮される。センダは、マルチキャストグループのリストを単純に告知し、このリストからレシーバは、所望のマルチキャストを選択して、コンテンツを配信させる。コンテンツ消費者が既知である場合を除いて、ＳＡＰには、Ｅ２ＥＮＰの削減されたバージョンのみしかマッピングできない。適応経路は、コンテンツプロバイダが同じコンテンツを異なるレベルのＱｏＳで異なるマルチキャストグループ（ＱｏＳレベル毎に１つのマルチキャストグループ）にストリーミングするように単純にモデル化することができる。したがって、コンテンツ消費者は、単に端末／アクセスネットワークにおいて使用可能なＱｏＳのレベルを監視し、その間に何らかのＱｏＳの変更又はＱｏＳ違反が生じた場合、他のマルチキャストグループを選択し直せばよい。これに代えて、ネットワーク内において、メディアフィルタ／トランスコーダと連携して、必要な条件を備えたＥ２ＥＮＰ（full-blown E2ENP）を用いて、メディアストリームを異なるＱｏＳレベルに対応させるようにしてもよい。ここでは、コンテンツ消費者は、メディアフィルタ／トランスコーダに対し、新たなＱｏＳレベルに切り換えるように単に指示するのみでよい。異なるマルチキャストグループに配信されるストリームを相互に同期させる役割は、コンテンツプロバイダとレシーバとが担っている。
【００８３】
なお、最適化を目的として、センダは、マルチキャストグループ毎のレシーバの数に関する統計的情報を収集し、ネットワークが未使用のチャンネルのパケットで溢れてしまうことを回避してもよい。このためには、コンテンツプロバイダと各レシーバとの間のシグナリングが必要である。なお、本発明は、このような場合を取り扱わない。
【００８４】
情報検索サービス
この種類のサービスは、通常、ＲＴＳＰプロトコルを用いて管理される。本発明は、会話サービスに関して説明した手法と同様に、Ｅ２ＥＮＰの目的を達成するためのプロトコルの拡張を提案する。詳しくは、ＲＴＳＰプロセスは、レシーバにより、ＲＴＳＰ記述法（RTSP DESCRIBE method）を用いて、センダに所定のメディア（例えば、ビデオストリーム）を記述するよう要求することによって開始される。この方法により、レシーバは、センダが所定のメディアを使い切るように強要することができる様々なレベルのＱｏＳに関する情報を知らされる。したがって、レシーバは、任意の時刻にどのレベルを強制するかを選択できる可能性を有している。これは、本発明によって提案される概念と類似し、高速交渉サイクル（fast negotiation cycle）に組み合わされる前交渉処理の形式である。ＴＲＳＰ記述法の拡張では、上述した能力に関する全ての情報が含まれ、ここで説明する分散型のリソース管理メカニズムがＲＴＳＰに組み込まれる。
【００８５】
ＱｏＳ相関特性は、ＳＭＩＬ（［SMIL98］）を用いることによっても実現される。なお、本発明は、このような技術の組込みについては取り扱わない。
【００８６】
エンドツーエンド再交渉プロトコル（End-to-End Re-Negotiation Protocol：Ｅ２ＥＲＰ）
Ｅ２ＥＲＰは、再交渉問題に重点を置いた、Ｅ２ＥＮＰのサブセットである。このプロトコルは、以下のような状況下において、いつでもアクティブ化される。
１．伝送処理に含まれる機能的エンティティにおいてＱｏＳ違反が検出された場合
２．現在監視されているＱｏＳレベルが現在強制されているＱｏＳ契約に適合できなくなった場合
３．何らかの特定の機能によって、新たに検出された追加的リソースが受け取られたことが通知された場合
４．ピアの１つが異なるＱｏＳ契約を強制することを決定した場合（例えば、ユーザがより高いフレームレートを要求した場合）
第２及び第３の状況は、主に最適化処理に関連しており、この最適化処理により、アプリケーションは、ＱｏＳ要求を向上／低下（upgrade/degrade）することができる。一方、第１の状況は、劇的なリソースの不足を取り扱うものであり、これは適正且つ速やかに対処しなければアプリケーションに好ましくない影響を与える。
【００８７】
したがって、第１の状況では、それまで確保されているリソースを維持しようとする必要はなく、ローカルリソースと最終的にはネットワークリソースとに関する再交渉が行われる。このような処理は、第２及び第３の状況では不可能である。したがって、最適化問題を取り扱う場合は、常に以下の点に留意する必要がある。
・先に割り当てたリソースと、新たな量との間の差異にあたる超過するリソースを割り当てるか（ＱｏＳ向上の場合）、
・又は、再交渉が成功して終了するまで元のリソースを確保したまま、ゼロから新たなリソースを割り当てる（悲観的手法）。この手法は、元のリソースを確保したまま、更なるリソースを割り当てる手法としてモデル化することもできる。この割当に失敗した場合、元から確保されているリソースを維持し、割当に成功した場合は、新たに割り当てられたリソースを使用する。
・幾つかのリソースを解放し、ＱｏＳ状態を切り換える（ＱｏＳ低下の場合）。
【００８８】
第１のオプションが極めて効果的であるが、異なるＱｏＳ状態間では、幾つかのリソースを共有することが容易ではないという問題がある。例えば、コーデックが回避され、全く異なるスレッド上で実行されている別のコーデックに置換されようとしている場合、所定のコーデックのスレッドに関するスケジューリング情報は、全く使用価値がなくなる。
【００８９】
したがって、第２の手法は、悲観的ではあるが、最も現実的な手法である。以下では、新たなリソースの割当と、これに続く元のリソースの解放について説明する。なお、リソースの解放は、システムの負荷が低減されるため、常に可能である。
【００９０】
再交渉が起動されると、各ピアは、再交渉適応経路から、検出されたＱｏＳの変化／違反に対処するために強制すべき最良の代替的なＱｏＳ契約を判定する。実際にどのＱｏＳ契約を強制するかに関する合意を行うために、新たなＱｏＳ契約を識別する情報がピア間で交換される。適応経路を事前に交渉することにより、ピアは、単に識別子を交換するだけで、この前交渉を効率的に実行することができる。全てのピアが同時に違反を検出した場合、何らかの形式の競合分解能アルゴリズム（contention resolution algorithm）を強制する必要がある。この点においては、周知の異なる手法を用いることができる。これらの手法とは、例えば、マスタ／スレーブの役割の割当（通常、イニシエータにマスタの役割を割り当てる）、又は任意の期間経過後の再試行等である。本発明では、マスタ／スレーブメカニズムを利用する。
【００９１】
要約すれば、以下のような種類の再交渉が特定される。
ａ）ＱｏＳ違反の検出によって起動される再交渉。ここでは、新たなリソースはゼロから割り当てられ、元のリソースは自動的に解放される（ＱｏＳ低下の場合、これは問題とはならない）
ｂ）システムを最適化するための再交渉。ここでは、新たなリソースはゼロから割り当てられ、元のリソースは、Ｅ２ＥＲＰが成功して完了した後に解放される。
ｃ）システムを最適化するための再交渉。ここでは、新たなリソースはゼロから割り当てられ、元のリソースは自動的に解放される。
【００９２】
動的エンドツーエンドＱｏＳ交渉及び制御のフレームワーク
本発明は、分散型マルチメディアアプリケーションにおける動的エンドツーエンドＱｏＳ交渉及び制御の連携を実現するフレームワークを提供する。このフレームワークは、ユーザの嗜好に基づき、動的能力交渉と、適応経路及びＱｏＳ契約の仕様を構築する。これらの原理について、図面を参照して説明する。
【００９３】
イニシエータ１０１は、インタフェース２１４を介して、ディレクトリサーバ１０２、２１５に問い合わせを行うプロトコル検出ユニット１０４、２１３を用いて、プロトコルのバージョンを検出する。この処理は、ローカル調整ユニット（local Coordination Unit）２０４により調整される。セッションプロトコルユニット２０５は、全ての種類の交渉及び通信に使用される。詳しくは、セッションプロトコルユニット２０５は、ピア２１６（レスポンダ１０３）に対して、能力及びコンフィグレーションの共通の組を交渉し、前交渉フェーズ１０６を構築する。更に、セッションプロトコルユニット２０５は、マルチストリームＱｏＳ同期及びＱｏＳ相関フェーズ１０７に用いられるＱｏＳ契約及び適応経路を交渉する。ローカルリソース管理は、インタフェース２１１を介して、ローカルリソース管理ユニット（ＣＰＵ、バッファ及び他のローカルリソースを管理する）２０６によって実行される。ローカルリソース管理は、調整ユニット２０４によって、ネットワークリソースの確保に対して調整される。このネットワークリソースの確保は、インタフェース２１２を介して、ネットワークリソース予約ユニット２０７によって行われる。
【００９４】
通信セッション確立の間、すなわち高速交渉フェーズ１０８が実行されている間は、あらゆるエンドツーエンドインタラクションが経済原理に従って実行される。この原理では、最初にローカルリソース、次にピアのリソース、最後にネットワークリソースが確保される。通信セッションの間に、リソースの使用可能性の変化又はリソースの使用可能性に影響を与える他の何らかの理由によって再交渉が必要となった場合、同様に経済原理に則って、再交渉フェーズ１０９が実行される。
【００９５】
最後に、確保リソース解放フェーズ１１０において、確保されているリソースが解放される。ローカルプロトコルスタック２０８は、インタフェース２１７を介して、セッションプロトコルユニット２０５とのインタフェースを司り、セッションプロトコルを実現する。更に、プロトコルスタック２０８は、インタフェース２１０を介して制御されるネットワークリソース予約プロトコルを実現する。
【００９６】
ＱｏＳ感知アプリケーションユニット（QoS-Aware Application Unit）２０２は、ＦＳＭエンジンユニット２０３を用いて、ＱｏＳ感知アプリケーションユニット２０２が取り扱う全てのストリームの状態を制御する。調整ユニット（Coordination Unit）２０４は、ＦＳＭユニット２０３とともに、インタフェース２０９を介して、ＱｏＳ感知アプリケーションユニット２０２に対し、ＱｏＳ保証を用いて、他のアプリケーションへのネットワーク接続を確立し、使用し、制御し、解放する可能性を提供する。このような接続の確立は、能力、コンフィグレーション、ＱｏＳ契約及び適応経路の交渉（ＦＳＭエンジンユニット２０３によって管理される）と、経済原理に基づくローカル、ピア及びネットワークのリソースの統合を含む。制御処理は、ローカル、ピア及びネットワークのリソースの再交渉及び統合を含み、更にＦＳＭエンジンユニット２０３が調整ユニット２０４と協働して管理する状態遷移を含んでもよい。解放処理は、調整ユニット２０４と協働して行われるネットワーク、ローカル及びピアのリソースの削除（tear-down）及び状態管理（ＦＳＭエンジンユニット２０３による）を含む。
【００９７】
更に、本発明は、Ｅ２ＥＮＰブローカ（E2ENP Broker）１０５と、時間及びリソースを消費する前交渉フェーズ１０６（そして最終的に、マルチストリームのＱｏＳ同期及びＱｏＳ相関１０７）からピア１０１、１０３を解放することができ、任意に設けられるサードパーティエンティティとの概念を提供する。各ピア１０１、１０３は、接続すべきＥ２ＥＮＰブローカ１０５をディレクトリサーバ１０２から検出した後に、適応経路、能力、及びこのＥ２ＥＮＰブローカ１０５に接続されるピアのリストをアップロードすることができる。Ｅ２ＥＮＰブローカ１０５は、例えばオーディオ／ビデオ会議ブリッジの拡張されたバージョンとして実現してもよく、又は交渉プロセスを取り扱う拡張されたＳＩＰプロキシサーバ又はＳＩＰリダイレクトサーバ（SIP redirect server）と、適応経路、能力、及びこれらの中間的な交渉された全てのバージョン（all the intermediate negotiated version）を格納するＳＩＰレジスタの拡張されたバージョンとを組み合わせることにより実現してもよい。
【００９８】
Ｅ２ＥＮＰブローカ１０５は、各ピア１０１、１０３からこのような情報を収集し、自らのメモリ空間において、ローカルで交渉処理を実行する。この処理の間、Ｅ２ＥＮＰブローカ１０５は、レスポンダ１０３がＥ２ＥＮＰブローカ１０５にその情報を未だ格納していない場合、イニシエータ１０１に代わって、指示されたレスポンダ１０３にコンタクトしてもよい。交渉が成功すると、Ｅ２ＥＮＰブローカ１０５は、ピア１０１、１０３に対し、処理の結果得られたリソースの使用可能性を通知し、各ピア１０１、１０３は、その結果をダウンロードする。また、Ｅ２ＥＮＰブローカ１０５は、複数回の交渉を繰り返すことができる（これができなければ、ピア間自体で実行するには、余りにも高価すぎる）。レスポンダ１０３は、イニシエータ１０１からのビッドに合意せず、カウンタオファーを提示してもよい。カウンタオファーの分析は、ピア間における複数回の往復のメッセージ交換を含み、したがって時間がかかる処理である。Ｅ２ＥＮＰブローカ１０５は、この全ての処理を調停することができる。
【００９９】
具体例
この章では、本発明の概念を具体化した具体例について説明する。この具体例は、ＩＰに準拠するネットワークを用いたリアルタイムマルチメディア会議のシナリオに基づいている。メディア伝送（media transport）は、ＲＴＰ／ＲＴＣＰを用いて実行される。
【０１００】
ここでは、説明を簡潔に行うために、既存のＳＩＰ／ＳＤＰと標準化すべき拡張規格とにマッピングすることができる疑似プロトコル（ＱＵＥＲＹ，ＲＥＳＰＯＮＳＥ，ＣＯＭＭＩＴ，ＳＴＡＲＴ，ＳＴＡＲＴ ＡＣＫ，ＲＥＳＥＲＶＥ，ＣＯＮＦＩＲＭ）を用いて本発明の原理を説明する。更に、この具体例では、２つのピアＡ、Ｂ間の処理に限定して説明を行う。ここで、イニシエータ１０１がレスポンダ１０３からメディアストリーム（ここではビデオストリームとする）を受け取ることを望んだとする。
【０１０１】
プロトコル検出ユニット１０４がプロトコルの検出に成功すると、Ｅ２ＥＮＰ処理は、前交渉フェーズ１０６から開始され、両方のパーティが理解できる共通のＥ２ＥＮＰバージョンが形成される。
【０１０２】
前交渉フェーズ１０６においては、ＱｏＳ感知アプリケーションユニット２０２がローカルＦＳＭエンジンユニット２０３を用いて交渉を要求し、ビッドを提供する。このビッドは、能力及びコンフィグレーションのリストと、ＱｏＳ契約及び適応経路のリストとを含み、これらには全てインデクスが付されている。ビッドは、ＳＤＰ拡張（例えば、現在開発されているＳＤＰｎｇ（［DPNG00］））を用いて記述することができる。調整ユニット２０４は、ＱＵＥＲＹメッセージを用いて、セッションプロトコルユニット２０５を介して、ピアにビッドを送信する。ＱＵＥＲＹメッセージは、ＳＩＰ拡張に基づくものであってもよい。ピアのセッションプロトコルユニット２０５は、ＱＵＥＲＹメッセージを受け取り、そのピアの調整ユニット２０４に対し、そのピアのＦＳＭエンジンユニット２０３を用いてビッドを評価するよう指示する。ピアのＦＳＭエンジンユニット２０３は、自らの適応経路及び能力にビッドを適応させ、共通のサブセットを作成し、ピアの調整ユニット２０４を介して、このサブセットを応答メッセージとしてピアのセッションプロトコルユニット２０５に供給し、セッションプロトコルユニット２０５は、ＳＩＰ拡張に基づくＲＥＳＰＯＮＳＥメッセージを生成する。イニシエータ１０１のセッションプロトコルユニット２０５は、新たなビッドを受け取って、調整ユニット２０４を介して、ローカルのＦＳＭエンジンユニット２０３に評価要求を供給する。そして、新たなビッドは、互換性について再び検査され（ここで、ビッドは、ピアが互換性を有さないことを示すエンプティの状態である場合もある）、イニシエータ１０１のＦＳＭエンジンユニット２０３は、全てのレスポンダからの全ての新たなビッドを収集し、共通のサブセットを作成し、全てのピアに送信する。この処理は、まず、強制メッセージ（enforce message）を調整ユニット２０４に送ることによって開始され、調整ユニット２０４は、この強制メッセージを更にセッションプロトコルユニット２０５に供給する。イニシエータ１０１のセッションプロトコルユニット２０５は、例えばＳＩＰ拡張に基づくコミットメッセージ（commit message）を生成する。コミットメッセージは、ビッドに適合する結果（例えば、ＳＤＰ拡張を用いて記述することができる）を伝えるメッセージである。コミットメッセージは、レスポンダ１０３のセッションプロトコルユニット２０５に配信され、このセッションプロトコルユニット２０５は、調整ユニット２０４を介して、ＦＳＭエンジンユニット２０３にこの結果を強制する。この時点で、全ての通信パートナは、コーデック、能力、適応経路及びＱｏＳ状態の共通の組に同意しており、後に、参照（状態ＩＤ：ＳｔａｔｅＩＤと示される）に基づいてデコードを行うことができる。
【０１０３】
ここで、イニシエータ１０１がビデオストリームを含む実際のセッションを開始することを望んだとする。状態及び適応経路は、上述した前交渉フェーズ１０６において予め取り決められている。イニシエータ１０１のＱｏＳ感知アプリケーションユニット２０２は、ローカルの調整ユニット２０４からストリームＩＤと所望の状態ＩＤとを受け取ってストリームの開始を要求し、ローカルの調整ユニット２０４は、まず、ローカルの承認検査（admission test）を実行し、ローカルリソース管理ユニット２０６にリソースを要求することによってリソースをローカルで確保する。ローカルリソースの問題のために、所望の条件が満足されない場合には、調整ユニット２０４は、ＦＳＭエンジンユニット２０３に対し、交渉された適応経路に基づくより軽いリソース要求を有する次のＱｏＳ状態を試行するよう要求する。ローカルにおけるリソース予約が成功した後、開始要求は、ローカルのセッションプロトコルユニット２０５に伝播（propagate）し、このセッションプロトコルユニット２０５は、例えばＳＩＰ拡張に基づくＳＴＡＲＴメッセージをピアのセッションプロトコルユニット２０５に送信する。このＳＴＡＲＴメッセージは、強制された状態ＩＤとストリームＩＤ（これらは、ＳＤＰ拡張を用いてモデル化することができる）を含む。ＳＴＡＲＴメッセージは、ピアの調整ユニット２０４を介してピアのＦＳＭエンジンユニット２０３に供給され、このＦＳＭエンジンユニット２０３は、状態ＩＤが有効であることを確認する。状態ＩＤが有効であることが確認された場合、ＦＳＭエンジンユニット２０３は、調整ユニット２０４と、ローカルリソース管理ユニット２０６によって提供されるサービスとを用いてメディアストリームを処理するためのリソースを要求する。このローカルリソース管理ユニット２０６は、承認検査を行い、ピアにおいてリソースを確保する。
【０１０４】
ここで、ピアにおいてリソースが確保されなかった場合、ピアの調整ユニット２０４は、ＦＳＭエンジンユニット２０３に対し、前交渉された適応経路に基づいて新たな状態ＩＤを選択するよう要求する。ここで、全てが承認された場合、ピアの調整ユニット２０４は、ピアのセッションプロトコルユニット２０５に対し、イニシエータ１０１のセッションプロトコルユニット２０５に新たな状態ＩＤとともにＳＴＡＲＴ ＡＣＫを送信するよう要求する。ＳＴＡＲＴ ＡＣＫは、ローカルの調整ユニット２０４を介して、ローカルのＦＳＭエンジンユニット２０３に供給される。ローカルのＦＳＭエンジンユニット２０３は、状態の互換性を確認し、状態が互換性を有する場合、ローカルの調整ユニット２０４に対し、（例えば、ＲＳＶＰを用いて）ローカルのネットワークリソース予約ユニット２０７を介してネットワークリソースを確保するよう要求する。状態ＩＤが先に選択した状態ＩＤと異なる場合、ローカルリソース管理ユニット２０６に指示を出し、新たな状態ＩＤに基づいてローカルリソースの確保を更新させる（図２は、互換性を有している場合の具体例を示しているので、この処理は示されていない）。更に、ピア１０３が所属しているアクセスネットワーク内のネットワークリソース予約を管理する場合（［Marsh00］）、調整ユニット２０４は、セッションプロトコルユニット２０５に対し、そのピア１０３にＲＥＳＥＲＶＥメッセージを送信するよう要求する。このような場合、ピア１０３は、セッションプロトコルユニット２０５を介してＲＥＳＥＲＶＥメッセージを受け取って、調整ユニット２０４を起動し、ピア１０３のネットワークリソース予約ユニット２０７を介して、（例えば、ＲＳＶＰを用いて）ネットワークリソースを要求させる。ネットワークレベルにおいてリソースが確保されると、ピア２１６における調整ユニット２０４は、ＣＯＮＦＩＲＭメッセージを用いてセンダに確認メッセージを送信する。ＣＯＮＦＩＲＭメッセージは、ローカルのセッションプロトコルユニット２０５が受信する。このユニットは、ローカルの調整ユニット２０４に確認情報を供給する。イニシエータ１０１が全てのレスポンダ１０３からの確認情報を収集すると、イニシエータ１０１は、イニシエータ１０１としての役割を終え、全てが正しく設定される。
【０１０５】
同時制御（concurrency control）を実行するために、前交渉フェーズ１０６、マルチストリーム同期及びＱｏＳ相関フェーズ１０７、高速交渉フェーズ１０８又は再交渉フェーズ１０９を開始する端末は、いずれもイニシエータ１０１としての役割を担うことができる。すなわち、その端末は、イニシエータ１０１として、既知のピアにメッセージを送信し、所定のフェーズに参加するように促す。イニシエータ１０１として動作する他のピアがない場合、ピア２１６は、自らがイニシエータ１０１として機能していることを認識し、レスポンダ１０３として機能しているピアからリソース予約（ローカル及びネットワークリソースの集合）の確認を待機する。この他の場合、すなわち、ピア２１６の１つが既にイニシエータ１０１として機能している場合、このイニシエータ１０１が予期されるピア２１６をレスポンダ１０３のリストに追加し、予期されるピア２１６は、このイニシエータ１０１によって所定のフェーズに招待されるのを待つ。
【０１０６】
所定のフェーズが終了すると、すなわち所定のイニシエータ１０１が全てのレスポンダ１０３からの確認情報を収集し終えると、イニシエータ１０１として機能している所定のピアが自らのイニシエータ１０１としての役割を終える。このモードでは、トークンパッシングメカニズム（token passing mechanism）が用いられ、ここでは、トークンの取得によりイニシエータ１０１として動作することが認められ、フェーズが完了するとトークンが無効となる。これにより、マスタがイニシエータ１０１であり、スレーブがレスポンダ１０３であるマスタ−スレーブ法を用いて、衝突が生じている状況にも対応することができる。イニシエータ１０１は、レスポンダ１０３に対し、ネットワークリソースの確保をいつ開始するかを指示する。いずれの場合も、ネットワークリソースの確保は、ピア間で同時に行われる（但し、例えばＲＳＶＰ等のＱｏＳ確保シグナリングプロトコルがエンドツーエンドで使用可能な場合を除く）。
【０１０７】
本発明の側面
以下、本発明によって提案される様々な概念について説明する。
・Ｅ２ＥＮＰを定義するための既存の異なるプロトコル及び技術の統合及び拡張（Ｅ２ＥＲＰを含む）：詳しくは、この側面は、次のようなフェーズを包含する。プロトコル検出フェーズ１０４、前交渉フェーズ１０６、マルチストリームＱｏＳ同期及びＱｏＳ相関フェーズ１０７、高速交渉フェーズ（経済原理による）１０８、再交渉フェーズ（経済原理による）１０９、確保リソース解放フェーズ１１０。これら６個フェーズは、連続して行ってもよく、異なる時刻に実行してもよい。マルチストリームＱｏＳ同期及びＱｏＳ相関フェーズ１０７は、ピア２１６が相関及び同期が必要な複数のストリームを送信／受信することによってインタラクトを行う場合にのみ必要であり、これ以外の場合は行わなくてもよい。プロトコル検出フェーズ１０４及び前交渉フェーズ１０６は、前もって実行してもよく、その結果を後続する複数の通信セッションに適用してもよい。これにより各通信セッションは、特定のマルチストリームＱｏＳ同期及びＱｏＳ相関フェーズ１０７によって開始される。後のフェーズの結果が複数の連続する通信セッションに適用可能な場合、各通信セッションは、特定の高速交渉フェーズ１０８によって開始されてもよい。前交渉フェーズ１０６、マルチストリームＱｏＳ同期及びＱｏＳ相関フェーズ１０７、高速交渉フェーズ１０８、再交渉フェーズ１０９、確保リソース解放フェーズ１１０の間、プロトコルは、ローカルリソース管理ユニット２０６とインタラクトする。
・経済原理：この側面に基づき、リソース承認制御及びリソース予約は、次のような順序に従って適用される。すなわち、まずＥ２ＥＮＰのイニシエータ１０１、次にＥ２ＥＮＰのレスポンダ１０３、最後にネットワークリソース予約ユニット２０７を用いてネットワークに対してリソース承認制御及びリソース予約が行われる。先に行われる２つのステップにおいては、リアルタイムＣＰＵスケジューリング、メモリ管理、電源管理等の問題が処理される。再交渉においても同様の処理順序が適用されるが、この場合、先に割り当てられたローカルリソースを、直ちに又は後の確保リソース解放フェーズ１１０において、更新する（解放する又は再割当する）必要がある。確保リソース解放フェーズ１１０では、まずネットワークリソース、次にピアのリソース、最後にローカルリソースが解放される。
・Ｅ２ＥＮＰの概念：この側面に基づき、上述のようにして確立されたマルチメディアセッション実行時の間のいかなる時点においてもコンポーネントは適応化を要求することができる。これにより、経済原理に基づく、ローカル、ピア及びネットワークのリソース管理が再び要求される。この適応化を実行する際は、ユーザが定義した又はユーザにより提供された試行を潜在的に用いて、適応経路を構築することができる。
・Ｅ２ＥＮＰ型の前交渉：これは、プロトコル検出フェーズ１０４において、ピア１０１、１０３に対し、ディレクトリサーバ１０２に問い合わせを行うよう強制することにより、又はディレクトリサーバ１０２にこのような情報を告知させることにより実行される。また、ディレクトリサーバ１０２に代えて、ＳＩＰレジストリサーバを用いてもよい。
・能力の前交渉：これは、前交渉フェーズ１０６において、例えば拡張されたＳＩＰ／ＳＤＰ等の特定のプロトコルを用いることによって実行できる。
・完全なコードリストの前交渉：これは、前交渉フェーズ１０６において、例えば拡張されたＳＩＰ／ＳＤＰ等の特定のプロトコルを用いることによって実行できる。
・ストリームレベルにおける適応経路の前交渉：これは、前交渉フェーズ１０６において、例えば拡張されたＳＩＰ／ＳＤＰ等の特定のプロトコルを用いることによって実行できる。
・ストリーム群レベルにおける適応経路の前交渉：これは、マルチストリームＱｏＳ同期及びＱｏＳ相関フェーズ１０７において、例えば拡張されたＳＩＰ／ＳＤＰ等の特定のプロトコルを用いることによって実行できる。
・高速交渉フェーズ１０８の速度を高めるための、前交渉されたＱｏＳ契約及び能力に対するインデクスの付与。
・再交渉フェーズ１０９の速度を高めるための、前交渉されたＱｏＳ契約及び能力に対するインデクスの付与。
・データモデルのモデリング：欧州特許出願第００１２６９７５．２号に開示されているＳＤＰ又はＳＤＰｎＧの拡張されたバージョン。ピア間で非同期メッセージを交換しイベントをイベントを通知することによって、実行時においても能力のインストール／削除を取り扱うことができる。これは、例えば拡張されたＳＩＰ／ＳＤＰに基づいて行うことができる。
・Ｅ２ＥＮＰブローカ１０５のサポート：これは、任意に設けられるサードパーティのエンティティであり、これにより、時間及びリソースを消費する前交渉フェーズ１０６（そして最終的に、マルチストリームのＱｏＳ同期及びＱｏＳ相関フェーズ１０７）からピア１０１、１０３を解放することができる。各ピア１０１、１０３は、接続すべきＥ２ＥＮＰブローカ１０５をディレクトリサーバ１０２から検出した後に、適応経路、能力、及びこのＥ２ＥＮＰブローカ１０５に接続されるピアのリストをアップロードすることができる。Ｅ２ＥＮＰブローカ１０５は、例えばオーディオ／ビデオ会議ブリッジの拡張されたバージョンとして実現してもよく、又は交渉プロセスを取り扱う拡張されたＳＩＰプロキシサーバ又はＳＩＰリダイレクトサーバ（SIP redirect server）と、適応経路、能力、及びこれらの中間的な交渉された全てのバージョン（all the intermediate negotiated version）を格納するＳＩＰレジスタの拡張されたバージョンとを組み合わせることにより実現してもよい。Ｅ２ＥＮＰブローカ１０５は、各ピア１０１、１０３からこのような情報を収集し、自らのメモリ空間において、ローカルで交渉処理を実行する。この処理の間、Ｅ２ＥＮＰブローカ１０５は、レスポンダ１０３がＥ２ＥＮＰブローカ１０５にその情報を未だ格納していない場合、イニシエータ１０１に代わって、指示されたレスポンダ１０３にコンタクトしてもよい。交渉が成功すると、Ｅ２ＥＮＰブローカ１０５は、ピア１０１、１０３に対し、処理の結果得られたリソースの使用可能性を通知し、各ピア１０１、１０３は、その結果をダウンロードする。
・Ｅ２ＥＮＰブローカ１０５により、複数回の交渉の繰り返し（negotiation iteration）を実行することができる。この処理は、Ｅ２ＥＮＰブローカ１０５を用いなければ、コストが高すぎる。レスポンダ１０３は、イニシエータ１０１からのビッドに合意せず、カウンタオファーを提示してもよい。カウンタオファーの分析は、ピア間における複数回の往復のメッセージ交換を含み、したがって時間がかかる処理である。Ｅ２ＥＮＰブローカ１０５は、この全ての処理を調停することができる。
・適応経路及び能力に関する情報を既存のＳＩＰ又はＲＴＳＰのメッセージに加える（piggybacking）ことによる、適応経路（ストリームレベルにおける）及び能力の前交渉フェーズ１０６のためのＳＩＰ及びＲＴＳＰの拡張。
・適応経路に関する情報を既存のＳＩＰ又はＲＴＳＰのメッセージに加える（piggybacking）ことによる、ストリーム収集レベル１０７における適応経路の前交渉のためのＳＩＰ及びＲＴＳＰの拡張（欧州特許出願第００１１１１９１．３号に基づく）。
・高速交渉フェーズ１０８及び再交渉フェーズ１０９のためのプロトコル手続き及びメッセージ（前交渉された適応経路のＱｏＳ契約に関連付けられた識別情報を用いることによって実現される）。
・以下の目的でメッセージを定義することによるＳＩＰ／ＳＤＰ及びＲＴＳＰの拡張。
ａ．ＱｏＳ契約交渉
ｂ．ピア間におけるネットワークリソースの確保の調整（必要であれば）
・インデクスが付されたＱｏＳ契約及び能力を用いた、高速交渉フェーズ１０８のためのＳＩＰ及びＲＴＳＰの拡張。
・インデクスが付されたＱｏＳ契約及び能力を用いた、再交渉フェーズ１０９のためのＳＩＰ及びＲＴＳＰの拡張。
・高速交渉フェーズ１０８及び再交渉フェーズ１０９の間に、ＳＩＰ及びＲＴＳＰに認証された同期手続きを導入することにより実現される、経済原理に基づく、ピア間のネットワークリソース予約メカニズムの調整。
・使用されるエンドツーエンドＱｏＳ交渉プロトコルをディレクトリサーバ１０５に告知させるためのＳＡＰの拡張。
・プロトコル検出フェーズ１０４を実現するために使用されるエンドツーエンドＱｏＳ交渉プロトコルの種類を格納及び／又は検索するための、ＳＩＰレジスタの使用に関する既存のディレクトリプロトコル又はＳＩＰの拡張。
・配信サービスに関する適応経路を告知するためのＳＡＰ拡張。ここで、ＡＰは、それぞれが特定のＱｏＳ契約を対象とする様々なマルチキャストグループのリストを単に作成する。
・ＳＩＰに関するＥ２ＥＮＰ関連の全ての変更は、理論的に、Ｈ．３２３にも同様にマッピングされる。
・確保リソース解放フェーズ１１０の管理
・高速交渉フェーズ（経済原理による）１０８及び再交渉フェーズ（経済原理による）１０９における能力の交渉及び再交渉は、ピア２１６がオーディオ及び／又はビデオコーデック及びこれらのコンフィグレーション（ビットレート等）に合意するために情報を交換する必要があることを知らせる処理を含む。
【０１０８】
本発明の実施の形態
以下、図２を用いて、本発明の実施の形態について説明する。
【０１０９】
各ピア２１６は、プロトコルスタック２０８（例えば、ＩＰ及びＴＣＰ／ＵＤＰ）及び調整ユニット２０４を含む演算ユニット２０１を備える。調整ユニット２０４は、以下のフェーズを調整する。
１．インタフェース２１４を介したプロトコル検出ユニット２１３によるプロトコル検出フェーズ１０４
２．インタフェース２０９を介したＦＳＭエンジンユニット２０３による、及びインタフェース２１０を介したセッションプロトコルユニット２０５による前交渉フェーズ１０６及びマルチストリーム同期及び相関フェーズ１０７
３．インタフェース２１１を介したローカルリソース管理ユニット２０６による、インタフェース２１０を介したセッションプロトコルユニット２０５による、及びインタフェース２１２を介したネットワークリソース予約ユニット２０７による高速交渉フェーズ１０８
４．インタフェース２０９を介したＦＳＭエンジンユニット２０３による（適応経路を用いて代替的なＱｏＳ契約を評価するための）、インタフェース２１１を介したローカルリソース管理ユニット２０６による、インタフェース２１０を介したセッションプロトコルユニット２０５による、及びインタフェース２１２を介したネットワークリソース予約ユニット２０７による再交渉フェーズ１０９
５．インタフェース２１１を介したローカルリソース管理ユニット２０６による、インタフェース２１０を介したセッションプロトコルユニット２０５による、及びインタフェース２１２を介したネットワークリソース予約ユニット２０７による解放フェーズ１１０
ＦＳＭエンジンユニット２０３は、所定のＱｏＳ感知アプリケーションユニット２０２の一部であってもよく、又は複数の所定のＱｏＳ感知アプリケーションユニット２０２が使用できる独立したエンティティ（ミドルウェア）であってもよい。ＦＳＭエンジンユニット２０３は、調整ユニット２０４と協働して、ＱｏＳ感知アプリケーションユニット２０２に代わって、所定の適応経路とともに構成された後に、所定の適応経路に関連するＦＳＭを実現することができるソフトウェア処理であってもよい。
【０１１０】
プロトコル検出ユニット２１３により、調整ユニット２０４は、ディレクトリサーバ２１５（ＳＩＰレジスタの拡張として実現することもできる）に連結し、プロトコル検出フェーズ１０４を実行することができる。プロトコル検出ユニット２１３は、調整ユニット２０４に代わって、Ｅ２ＥＮＰに関する情報を告知及び問い合わせることによって、既存の特定のプロトコル（例えば、ＬＤＡＰ、ＳＡＰ、ＳＩＰ）の用途を拡張する。
【０１１１】
セッションプロトコルユニット２０５により、調整ユニット２０４は、ピア２１６に対し、上述したフェーズ１０６〜１１０を実行することができる。セッションプロトコルユニット２０５は、適応経路及び能力のビッド／カウンタオファーを記述するためのＳＤＰ又はＳＤＰｎＧ拡張を用いて、及びＳＩＰ又はＲＴＳＰ（又はＨ．３２３／Ｈ．２４５）にフェーズ１０６〜１１０、特に前交渉フェーズ１０６及びマルチストリーム同期及び相関フェーズ１０７（経済原理に基づくリソース調整を含む）に必要なシグナリングを実現するための特定のメッセージを導入することにより、ＳＩＰ／ＳＤＰ又はＲＴＳＰ（又はＨ．３２３／Ｈ．２４５）等の既存のプロトコルを拡張する。
【０１１２】
ローカルリソース管理ユニット２０６へのインタフェース２１１は、以下のようなリソースのクラスに関して識別される。
・ＣＰＵリソース
・メモリ（主メモリ及び副メモリ）リソース
・バッテリ電源
・外部補助リソース
各クラスのリソースについて、特定のローカルリソース管理ユニット２０６は、例えば、演算ユニット２０１にロードされるオペレーティングシステムの拡張として実現される。
【０１１３】
インタフェース２１１により、調整ユニット２０４は、以下のようなタスクを実行することができる。
・様々な基準（例えば、ストリーム毎又は処理毎の順位）に基づくリソース使用の監視
・所定の条件が満たされた場合に一度及び／又は随時、調整ユニット２０４に供給すべき通知の登録（及び登録抹消）
・所定量のリソースの確保（及び解放）（例えば、ＣＰＵデッドラインの設定又は所定のプロセスのためのメモリ領域の確保）
・所定の確保の更新（再交渉のため）
・例えば処理等の所定のエンティティのローカルリソース用途への割当（及び割当解除）（これは、通常、ＯＳからの指示がなくては直接操作できないリソースに対して行われる）。クラスは、ある種の優先順位を有し、これを用いてＯＳは、ユーザのポリシに基づいてリソースの用途を最適化することができる。
【０１１４】
各ピア２１６は、処理の間、他のすべてのピアがイニシエータ１０１として機能しない場合、イニシエータ１０１としての役割を担うことができる。この役割は、以下のようなフェーズの期間全体に亘って維持される。
・前交渉フェーズ１０６
・マルチストリーム同期及びＱｏＳ相関フェーズ１０７
・高速交渉フェーズ１０８（経済原理による）
・再交渉フェーズ１０９（経済原理による）
リソース解放フェーズ１１０において、ピアの一部は、セッション終了プロセス（session tear down process）に含まれず、したがって、残りのピアとセッションを継続することを望み、同時に実行されるフェーズ１９７、１０８、１０９において、イニシエータ１０１の役割を引き受けてもよい。
【０１１５】
ここで、上述のいずれかのフェーズにおいて、ピア２１６（以下、ピアＡという）がイニシエータ１０１として機能しようとし、他のピア２１６をレスポンダ１０３として招いたとする。このとき既にこのフェーズが進行している（すなわち、他のピア２１６の１つが既にイニシエータ１０１として機能してたとする）場合、ピアＡは、現在アクティブなイニシエータ１０１からの招待を待機する必要があると通知され、イニシエータ１０１は、自らのレスポンダ１０３のリストにピアＡを追加する必要がある。
【０１１６】
上述のいずれのフェーズの結果も、イニシエータ１０１側における全てのレスポンダ１０３からの、ネットワークリソースの確保に成功したことを示す全ての確認情報の集合に合致する。イニシエータ１０１は、他のすべてのピアに対して、既に受け取った確認情報を検証し、矯正処理（corrective action）を行うことにより、ピア間のリソースの使用のバランスを調整する。結論が得られると、イニシエータ１０１として機能するピア２１６は、ニュートラル状態に入り、すなわち予期されるピア２１６に対して、イニシエータ１０１しての機能を解放する。イニシエータ１０１としての機能は、論理的トークン（イニシエータ機能トークン（Initiator Role Token）：ＩＲＴ）としてモデリングすることができ、ＩＲＴは、上述のフェーズのいずれかが終了すると、ピア間で交換することができる。
【０１１７】
他のピア２１６は、複数のピア２１６間で既にアクティブな通信セッションに参加することができる。これらの場合、全てについて再交渉を行う必要があり、又は再交渉を行うことが望ましい。本発明の主な特徴は、前交渉フェーズ１０６を実際のマルチストリーム同期及びＱｏＳ相関フェーズ１０７、高速交渉フェーズ１０８（経済原理による）及び再交渉フェーズ１０９（経済原理による）から分離した点である。セッション告知時において、ピア２１６がどのレベルのＱｏＳを用いるかを事前に合意している限り、これらのピア２１６は、ここで説明した、処理速度を速めるためにインデクスが付された交渉処理を用いて、アクティブなセッションにいつでも参加できる（又は離脱できる）。ここで、主な問題は、前交渉を全く行うことなく、後に会議に参加するピア２１６をどのように扱うかという点である。このような場合、以下に示す幾つかのソリューションを任意に選択することができる。
１．全てのピア２１６間で全てに関する再交渉を行う。これは、サービスが長く中断されるだけではなく、このソリューションにより、例えばビデオ会議セッションに所属する接続間に従属関係を強制し、多くの場合非現実的であるため、余り望ましくないソリューションである。
２．新たなピア２１６に対し、既に前交渉されている情報を受け入れるよう強制する。ここで、新たなピア２１６がこの情報を受け入れない場合、このピア２１６は、所定のセッションに参加することができない。
３．ネットワークに組み込まれたフィルタによってメディアを適応化し、新たなピア２１６の他の嗜好に適応させる。この概念に関する更なる詳細は、［Pasqu92］、［Pasqu93］、［Yeado93］、［Kassl99a］、［Kassl991］に開示されている。
【０１１８】
結論として、本発明は、これらの問題を取り扱う何らかのアプリケーション（例えば、会議制御ツール）によって第２又は第３のソリューションが強制され、本発明基づくサービスを使用すると仮定する。これは、第２及び第３のソリューションが本発明の範囲内にないことを意味している。
【０１１９】
Ｅ２ＥＮＰブローカ１０５が使用され及び／又は交渉により取り決められた語彙がディレクトリサーバ１０２又はＳＩＰレジスタに格納される場合、新たな参加者は、このようなエンティティから、前交渉された情報をより効率的に直接得ることができ、したがって、高速交渉フェーズ１０８（経済原理による）及び再交渉フェーズ１０９（経済原理による）のみを起動する。
【０１２０】
時間的に非対称のイニシエータ１０１／レスポンダ１０３スキームは、マスタ／スレーブコンフィグレーションと同等であり、この場合、イニシエータ１０１はマスタとして機能し、各レスポンダ１０３はスレーブとして機能する。したがって、前交渉フェーズ１０６、マルチストリームＱｏＳ同期及びＱｏＳ相関フェーズ１０７、高速交渉フェーズ（経済原理による）１０８、再交渉フェーズ（経済原理による）１０９、確保リソース解放フェーズ１１０の間、独立してフェーズを開始するピア２１６から生じる可能性がある矛盾を解決することができる。
【０１２１】
通常の会話フェーズの間（すなわち、高速交渉フェーズ１０８の後）、複数のピア２１６があらゆるＱｏＳの変化／ＱｏＳ違反を同時に検出でき、これにより、衝突が生じた場合、対応する再交渉フェーズ１０９が要求される。ここで、最後にイニシエータ１０１の役割を担ったピア２１６が再びイニシエータ１０１の役割を担い、ピア間の要求を仲裁する。これは、直前に機能したイニシエータ１０１が各ピア２１６の識別情報を保持していることを意味する。
【０１２２】
なお、最悪の状況として、このようなピア２１６が通信セッションの間に通信セッションから離脱してしまった場合、矛盾が不可避となる場合がある。このような場合、他のピアからの同様の要求を受けてＩＲＴを捕捉しようとする各ピア２１６は、任意の期間ブロックされ、この期間経過後に同様の試みを行う。この期間において、他のピア２１６がＩＲＴを捕捉する要求を送信すると、この期間において保留されているピア２１６に対してこれに応じた通知がなされ、これによりタイマ及びＩＲＴを捕捉しようとする要求が中断され、このピア２１６がレスポンダ１０３としての役割を引き受ける。
【０１２３】
図５は、Ｅ２ＥＮＰブローカの具体例を示しており、このＥ２ＥＮＰブローカには、上述したセッション開始プロトコル（ＳＩＰ）が適用されている。ＳＩＰプロキシサーバ及び／又はＳＩＰリダイレクトサーバ５０１は、ＳＩＰレジスタ５０３に接続されている。本発明は、ＳＩＰレジスタ５０３によって使用されるデータベース５０４に格納されている位置情報５０５に、本発明に基づいて記述されたＱｏＳ仕様及び能力情報５０６と、交渉されたＱｏＳ情報５０７（交渉／再交渉フェーズの間に導き出された一時的な結果及び最終的に合意された結果の両方）を含めることを提案する。ＳＩＰレジスタ５０３に情報を登録する際は、ユーザは、これらの情報５０６、５０７をアップロードすることができる。Ｅ２ＥＮＰブローカ５０２は、周知のメカニズム（例えば、ＪＡＩＮ ＳＩＰサーブレットＡＰＩ（JAIN SIP Servlet API））によって、特定のインタフェース５０８を介してＳＩＰプロキシサーバ及び／又はＳＩＰリダイレクトサーバ５０１と通信を行うユニットである。ＳＩＰ拡張として実現されたＥ２ＥＮＰプロトコルが使用される場合はいかなるときも、Ｅ２ＥＮＰブローカ５０２は、レジスタのデータベースに格納された上述の情報を用いて、全てのピアに代わって、自らのメモリスペースにおいて、上述した交渉及び再交渉フェーズを実行する。Ｅ２ＥＮＰブローカ５０２は、インタフェース５０９を介してＳＩＰレジスタ５０３と通信を行う。
【０１２４】
従来の技術と比較した本発明の主な利点
【０１２５】
【表６】
2004537187.tif 000008
【０１２６】
【表７】
2004537187.tif 000009
【０１２７】
【表８】
2004537187.tif 000010
【０１２８】
注１：ＩＴＵ−Ｔ（先のＣＣＩＴＴ）勧告Ｅ．８００の定義より
注２：既に合意されている適応経路に対する異なる解釈を有するパーティがセッションに参加した場合、前交渉は有効ではなくなる場合がある。
注３：例えば、２個のオーディオ及び３個のビデオストリームが同時に存在するセッションの交渉及び設定
注４：まず前交渉を行い、第１のストリームから開始し、次に第２のストリームを加える等。
【図面の簡単な説明】
【０１２９】
【図１】高レベルＭＳＣ識別フェーズを説明する図である。
【図２】本発明に基づくシステムを機能的に示すブロック図である。
【図３】前交渉フェーズ１０６（ＭＳＣ）の具体例を示す図である。
【図４Ａ】高速交渉フェーズ１０８（ＭＳＣ）の具体例を示す図である。
【図４Ｂ】図４Ａの続きである。
【図５】ＳＩＰに基づくＥ２ＥＮＰブローカの具体的構成を示す図である。
【図１】
2004537187.tif 000011
【図２】
2004537187.tif 000012
【図３】
2004537187.tif 000013
【図４Ａ】
2004537187.tif 000014
【図４Ｂ】
2004537187.tif 000015
【図５】
2004537187.tif 000016
【国際公開パンフレット】
2004537187.tif 000017
2004537187.tif 000018
2004537187.tif 000019
2004537187.tif 000020
2004537187.tif 000021
2004537187.tif 000022
2004537187.tif 000023
2004537187.tif 000024
2004537187.tif 000025
2004537187.tif 000026
2004537187.tif 000027
2004537187.tif 000028
2004537187.tif 000029
2004537187.tif 000030
2004537187.tif 000031
2004537187.tif 000032
2004537187.tif 000033
2004537187.tif 000034
2004537187.tif 000035
2004537187.tif 000036
2004537187.tif 000037
2004537187.tif 000038
2004537187.tif 000039
2004537187.tif 000040
2004537187.tif 000041
2004537187.tif 000042
2004537187.tif 000043
2004537187.tif 000044
2004537187.tif 000045
2004537187.tif 000046
2004537187.tif 000047
2004537187.tif 000048
2004537187.tif 000049
2004537187.tif 000050
2004537187.tif 000051
2004537187.tif 000052
2004537187.tif 000053
2004537187.tif 000054
2004537187.tif 000055
2004537187.tif 000056
2004537187.tif 000057
2004537187.tif 000058
2004537187.tif 000059
2004537187.tif 000060
2004537187.tif 000061
2004537187.tif 000062
2004537187.tif 000063
2004537187.tif 000064
2004537187.tif 000065
2004537187.tif 000066
2004537187.tif 000067
2004537187.tif 000068
2004537187.tif 000069
2004537187.tif 000070
2004537187.tif 000071
2004537187.tif 000072
2004537187.tif 000073
2004537187.tif 000074
2004537187.tif 000075
2004537187.tif 000076
2004537187.tif 000077
2004537187.tif 000078
2004537187.tif 000079
2004537187.tif 000080
2004537187.tif 000081
2004537187.tif 000082
【手続補正書】
【提出日】平成15年4月14日(2003.4.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークのピア間で媒体ストリームを交換する媒体ストリーム交換方法において、
ストリームを交換する以前に、２つのピア間で、複数のサービス品質契約及び端末能力に関する前交渉（１０６）を行うステップと、
ストリーム確立時において、上記前交渉されたサービス品質契約及び端末能力を用いて、ストリーム毎にＱｏＳ契約を交渉する（１０７）ステップとを有する媒体ストリーム交換方法。
【請求項２】
複数のピア間で複数のストリームのサービス品質相関及び同期アスペクトに関する交渉（１０７）を行うステップを有する請求項１記載の媒体ストリーム交換方法。
【請求項３】
ストリーミング中に再交渉（１０９）が行われる場合、上記ピア（２０６）が再交渉状態を参照し、該再交渉状態は、前交渉された所定のサービス品質契約及び前交渉された所定の能力の組を示すことを特徴とする請求項１乃至２いずれか１項記載の媒体ストリーム交換方法。
【請求項４】
上記ピア（２１６）は、上記前交渉（１０６）の間に、最も分解能が細かいレベルにおいて、ストリーム毎の及び／又はストリームの群毎のサービス品質契約について交渉し、該ストリームの群は、１つのセンダであるピアからレシーバであるピアへのストリームの集合であることを特徴とする請求項１乃至３記載の媒体ストリーム交換方法。
【請求項５】
上記ピア（２１６）は、能力コンフィグレーションの変更について通知されることを特徴とする請求項１乃至４いずれか１項記載の媒体ストリーム交換方法。
【請求項６】
選択するクライアントが、所定の種類のストリームについて前交渉された代替的な品質及びコンフィグレーションの情報がサーバにおいて既に使用可能であることを特徴とする請求項１乃至５いずれか１項記載の媒体ストリーム交換方法。
【請求項７】
プロトコル検出（１０４）フェーズ、前交渉（１０６）フェーズ、マルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズ、高速交渉（１０８）フェーズ、再交渉（１０９）フェーズ、確保リソース解放（１１０）フェーズを有する請求項１乃至６いずれか１項記載の媒体ストリーム交換方法。
【請求項８】
上記全てのフェーズは、連結され、連続的に実行され、又は異なる時刻に実行されることを特徴とする請求項７記載の媒体ストリーム交換方法。
【請求項９】
上記マルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズは、任意に実行され、イニシエータ（１０１）が複数のピア（２１６）との間で、イニシエータ（１０１）の側のみで強制されるユーザポリシに基づいて相関及び同期が必要な複数のストリームを用いて通信する場合にのみ要求されることを特徴とする請求項８記載の媒体ストリーム交換方法。
【請求項１０】
上記プロトコル検出（１０４）フェーズ及び前交渉（１０６）フェーズは、前もって実行され、この結果は、複数の後続する通信セッションに適用され、該各通信セッションは、任意に実行される特定のマルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズにより開始されることを特徴とする請求項９記載の媒体ストリーム交換方法。
【請求項１１】
上記マルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズが後続する複数の通信セッションに適用可能な場合、該通信セッションは、特定の高速交渉（１０８）フェーズにより開始されることを特徴とする請求項１０記載の媒体ストリーム交換方法。
【請求項１２】
上記プロトコル検出（１０４）フェーズ、前交渉（１０６）フェーズ、マルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズ、高速交渉（１０８）フェーズ、再交渉（１０９）フェーズ、確保リソース解放（１１０）フェーズの間、プロトコルがローカルリソース管理ユニット（２０６）とインタラクトすることを特徴とする請求項７乃至１１いずれか１項記載の媒体ストリーム交換方法。
【請求項１３】
リソース承認制御及びリソース確保が、ネットワークリソース確保ユニット（２０７）を用いて、まずイニシエータ（１０１）、次にレスポンダ（１０３）、最後にネットワークの順で実行されることを特徴とする請求項７乃至１２いずれか１項記載の媒体ストリーム交換方法。
【請求項１４】
上記イニシエータ及びレスポンダにおける処理では、実時間ＣＰＵスケジューリング、メモリ管理、電源管理等の問題が処理されることを特徴とする請求項１３記載の媒体ストリーム交換方法。
【請求項１５】
上記確保リソース解放フェーズ（１１０）では、まずネットワークリソース、次にピア（２１６）のリソース、最後にローカルリソースを解放することを特徴とする請求項７乃至１４いずれか１項記載の媒体ストリーム交換方法。
【請求項１６】
確立されたマルチメディアセッションの実行時の間の任意の時刻において、任意のピアが適応化を要求し、再交渉（１０９）フェーズを起動することを特徴とする請求項７乃至１５いずれか１項記載の媒体ストリーム交換方法。
【請求項１７】
プロトコル検出（１０４）フェーズにおいて、ピア（１０１、１０３）に対し、ディレクトリサーバ（１０２）に問い合わせを行うよう強制することにより、又はディレクトリサーバ（１０２）にこのような情報を告知させることによりＥ２ＥＮＰ型の前交渉を行うステップを有する請求項７乃至１６記載の媒体ストリーム交換方法。
【請求項１８】
前交渉フェーズ（１０６）において、完全なコーデックリストに関する前交渉を行うステップを有する請求項７乃至１７いずれか１項記載の媒体ストリーム交換方法。
【請求項１９】
前交渉フェーズ（１０６）において、ストリームレベルにおける適応経路に関する前交渉を行うステップを有する請求項７乃至１８いずれか１項記載の媒体ストリーム交換方法。
【請求項２０】
マルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズにおいて、ストリーム群レベルにおける適応経路に関する前交渉を行うステップを有する請求項７乃至１９いずれか１項記載の媒体ストリーム交換方法。
【請求項２１】
高速交渉フェーズ（１０８）の速度を高めるために前交渉されたＱｏＳ契約及び能力に対するインデクスを付与するステップを有する請求項７乃至２０いずれか１項記載の媒体ストリーム交換方法。
【請求項２２】
再交渉フェーズ（１０９）の速度を高めるために前交渉されたＱｏＳ契約及び能力に対するインデクスを付与するステップを有する請求項７乃至２１いずれか１項記載の媒体ストリーム交換方法。
【請求項２３】
ピア間で非同期メッセージを交換しイベントをイベントを通知することによって、実行時において能力のインストール／削除を取り扱うステップを有する請求項７乃至２２いずれか１項記載の媒体ストリーム交換方法。
【請求項２４】
代替的なＱｏＳ条件及び能力をエンドツーエンド毎に前交渉し、遠隔通信セッションを行う全てのピアが同意できる共通レベルの代替的なＱｏＳ及び能力を前もって確立する遠隔通信用のエンドツーエンド交渉プロトコル。
【請求項２５】
サービス品質のエンドツーエンド交渉を仲介して、前交渉（１０６）フェーズと、任意であるマルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズの負担からピアを解放するブローカ。
【請求項２６】
コンピュータにより実行されて、請求項１乃至２３いずれか１項記載のサービス品質提供方法を実現するコンピュータプログラム。
【請求項２７】
請求項１乃至２３いずれか１項記載のサービス品質提供方法を実現するピアであって、分散型リソース管理処理の交渉処理における異なるフェーズを調整する調整ユニット（２０４）を備えるピア。
【請求項２８】
上記調整ユニットは、プロトコル検出（１０４）フェーズを実行し、続いて、前交渉（１０６）フェーズ、任意であるマルチストリームＱｏＳ同期及びＱｏＳ相関（１０７）フェーズ、経済原理に基づく高速交渉（１０８）フェーズ、経済原理に基づく再交渉（１０９）フェーズ、確保リソース解放（１１０）フェーズを起動することを特徴とする請求項２７記載のピア。
【請求項２９】
使用されるエンドツーエンド交渉プロトコルに関する情報を告知し及び問い合わせるためのプロトコル検出ユニット（２１３）を備える請求項２７又は２８記載のピア。
【請求項３０】
他のピア（２１６）に対する調整処理の異なるフェーズを上記調整ユニット（２０４）に実行させるセッションプロトコルユニット（２０５）を備える請求項２７乃至２９いずれか１項記載のピア。
【請求項３１】
上記調整ユニット（２０４）をローカルリソース管理ユニット（２０６）に接続するインタフェース（２１１）を備える請求項２７乃至３０いずれか１項記載のピア。
【請求項３２】
上記調整ユニット（２０４）をプロトコル検出ユニット（２１３）に接続するインタフェース（２１４）を備える請求項２７乃至３０いずれか１項記載のピア。
【請求項３３】
上記調整ユニット（２０４）をセッションプロトコルユニット（２０５）に接続するインタフェース（２１０）を備える請求項２７乃至３０いずれか１項記載のピア。
【請求項３４】
上記調整ユニット（２０４）をＦＳＭエンジンユニット（２０３）に接続するインタフェース（２０９）を備える請求項２７乃至３０いずれか１項記載のピア。
【請求項３５】
上記調整ユニット（２０４）をネットワークリソース確保ユニット（２０７）に接続するインタフェース（２０９）を備える請求項２７乃至３０いずれか１項記載のピア。
【国際調査報告】
2004537187.tif 000083
2004537187.tif 000084
2004537187.tif 000085
2004537187.tif 000086
2004537187.tif 000087