JP4443594B2 - セッション・アダプテーションのための方法及び装置 - Google Patents

Description

本発明は、異種環境におけるセッション・アダプテーション及びサービス品質（ＱｏＳ）の分野に関する。

次世代ネットワークは、異種環境であり、広範囲のサービスをサポートすることが想定される。異種環境は、アクセス及びトランスポート技術から始まって、異なった装置と処理能力とを有するモバイルユーザの環境へと移行していくことになる。上記の異種性に加えて、マルチメディア及びファイル配信（file-distribution）セッションのような通信サービスは、少なくとも最低限の品率レベルでリクエスタ（要求側）へ配信されなければならない。しかしながら、セッションパス上の異種ユーザ又はユーザグループへセッション内容を配信及び適合させることは、異なる配信技術を伴うドメイン、異なる容量を有するリンク、及び、独特の要求事項を有するユーザが関与しているため難しい課題である。

異種環境からなるネットワークを間に介するような異なるレシーバ（receiver）に対するセッション・アダプテーションの問題は、環境がマルチキャストアウェア（multicast-aware）であり、ＱｏＳアウェア（QoS-unaware）ではない状況に取り組んできた。既存の解決策は、必要とされる適合制御機能をサポートするためにエンドホスト上で独自モジュールの実施を必要とするか、又は、レシーバからの多様化した要求を満たすためにコンテントコーディング（content coding）を変更するための特定のメカニズムに依拠するかの何れかである。しかしながら、各エンドホストでの余計な機能の実施、及び、コンテントコーディングを変更する必要性は、環境の複雑さを増し、かつ、環境の柔軟性を低下させるため、適切ではない。

このギャップを埋めるため、異種環境からなるネットワークを間に介するような異なるレシーバにセッションの品質レベルを適合させることができ、かつ、優先度の低いセッションのフローがドメイン又はドメイン間のリンクによってサポートされていない際に上流及び／又は下流のネットワークリソースの浪費を回避することができるようなＱｏＳアウェアなセッションメカニズムが必要となる。このメカニズムは、アンダーレイネットワーク配信技術（underlying network distribution technique）とは独立に動作し、エンドホスト上での独自モジュールの実施を回避できなければならない。更に、このメカニズムは、様々なプロトコル及びメカニズムとの容易な相互作用と、簡単な配備とを同時に可能にするオープンインタフェースをサポートしなければならない。

アダプテーション制御問題を扱っている提案は、これまでになされている。しかしながら、既存の解決策は、エンドホスト上での独自モジュールの実施を必要とするか、又は、ネットワーク内の特定の場所にコンテントコーディングをネットワーク帯域幅に適合させる役目を担う装置を必要とする（例えば、非特許文献１）。更に、殆どの解決策は、マルチキャストアウェアな環境に焦点が合わされ、マルチメディアセッションに範囲が限定され、一般に、ＱｏＳアウェアではない（例えば、非特許文献２）。したがって、従来のアプローチは、システムの柔軟性を低下させ、スケーラビリティの問題を提示し、環境の複雑さを増大させるため、異種環境からなるネットワークにおいて進行中のネットワーク条件にセッションを適合させる場合には適していない。

以下では、適用範囲を強調し、異種環境からなるネットワークに適していない理由を説明し、ある種の従来技術を簡単に説明する。

文献に提示されている適合制御スキームは、セッション（特に、マルチメディアセッション）を様々なレシーバに適合させるため、又は、ネットワーク条件の変化に反応するために使用されている。一般に、これらのアプローチは、センダーベース（sender-based）、レシーバベース（receiver-based）、及び、トランスコーダベース（transcoder-based）に分類される。

センダーベースの制御スキームの一例は、非特許文献３において提案されており、センダー側で動的チャンネルレート割り当てを用いることによりレシーバの安定性及びフェアネスを改善する「Ｏｎ ｔｈｅ Ｕｓｅ ｏｆ Ｓｅｎｄｅｒ Ａｄａｐｔａｔｉｏｎ ｔｏ Ｉｍｐｒｏｖｅ Ｓｔａｂｉｌｉｔｙ ａｎｄ Ｆａｉｒｎｅｓｓ ｆｏｒ Ｌａｙｅｒｅｄ Ｖｉｄｅｏ Ｍｕｌｔｉｃａｓｔ」というアプローチである。しかしながら、このアプローチは、セッション品質レベルを保証することなく、ベストエフォートサービス（Best-Effort service）しかサポートしない。その上、センダーベースのレートアダプテーション（rate adaptation）は、異種環境からなるマルチキャスティング環境では巧く機能しないが、その理由は、単一のターゲットレートが存在せず、様々なレシーバの品質要求が、１個の伝送レートで同時に満たされないからである。

非特許文献４では、インターネットを介したマルチキャストマルチメディア伝送のための「Ｒｅｃｅｉｖｅｒ−ｄｒｉｖｅｎ Ｌａｙｅｒｅｄ Ｍｕｌｔｉｃａｓｔ」（ＲＬＭ）スキームを提案している。次いで、ＳＡＭと呼ばれる簡単なレシーバベースの適合メカニズムを含む、様々なレシーバへのマルチメディアコンテンツのストリーム化を可能にするようなその他の提案が記載されている（例えば、非特許文献５）。レシーバは、ＳＡＰＲＡによって提供される情報である、表示されたビデオストリームの特有の品質を、ネットワークの現在条件に適合させるためにＳＡＭを使用するようになっている。レシーバは、最初に、最も重要なフローのためのマルチキャストグループを結合して、次に、ＳＡＭは、付加的なフローを結合し又は削除することにより知覚品質（perceptual quality）を制御するようになっている。しかしながら、これらのアプローチは、センダー、レシーバ、又は、両方に、システムの複雑さを増大させ、柔軟性を低下させる余計な作業負荷／モジュールを必要とする。更に、用途をマルチキャスト環境に限定する、ネットワークにおけるＩＰマルチキャストテクノロジーのサポートが必要とされ、セッションのフローを別のネットワークサービスクラスへ再調整することを要求するためにＱｏＳマッピングのようなスキームとの相互作用がサポートされない。

異種環境に適していると考えられる適合アプローチは、トランスコーダベースのスキームからなり（例えば、非特許文献６）、様々なタイプの接続性又は様々なレベルの輻輳を伴うネットワーク領域へ様々なレベルの品質を提供するためにネットワークエレメントを適切なロケーションに配置している。ビデオトランスコーダベースの技術は、シングルユーザユニキャストセッション、及び／又は、マルチユーザマルチキャストセッションに適用される。例えば、Ｈａｙｄｅｒ等による「Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ ＴｒａｎＳｃａｌｉｎｇ ｆｏｒ ｔｈｅ Ｗｉｒｅｌｅｓｓ Ｉｎｔｅｒｎｅｔ」（非特許文献６）というアプローチは、ＴｒａｎＳｃａｌｉｎｇと呼ばれるトランスコーダベースのメカニズムを提案している。このＴｒａｎＳｃａｌｉｎｇを用いることにより、所与の帯域幅レンジをカバーするマルチメディアセッションは、様々な帯域幅レンジをカバーする１個以上の配信チャンネルにマッピングされる。様々なアクセスネットワークの様々なゲートウェイは、固有のローカルドメインと、帰属させられている装置とに適した所望のトランスケーリングオペレーション（TransScaling operation）を実行することが可能である。しかしながら、トランスコーダベースのスキームは、高いメモリとＣＰＵ消費量とを要求するネットワーク装置の複雑さを増大させ、トランスコーダエレメントは、セッションパスに沿って様々なコーデックを用いてセッションのためのビデオ符号化、復号化及び再符号化を実行する必要があるので、スケーラビリティ問題が生じることになる。更に、このアプローチは、上流又は下流のネットワークリソースの浪費を回避できないだけでなく、セッションのフローを別のサービスのクラスに再割り当てできるようにするために外部メカニズムとの相互作用も同様に回避しない。

一般に、殆どのアプローチは、固有のＩＰ配信技術（例えば、ＩＰマルチキャスト）に限定され、それらの用途を将来の次世代ネットワークのような異種環境に限定している。更に、各エンドホスト上での独自モジュールの実施すること、及びコンテントコーディングの変更を必要とすることは、適当な解決策ではない。なぜなら、柔軟性を低下させ、システムの複雑さを増大させるからである。更に、一部の提案は、アダプテーション・プロセスを実行するために、要求されるセッションの品質レベルを考慮しないだけでなく、柔軟性のあるアダプテーション決定（例えば、レシーバが支払ってもよいと考えるサービスのコスト）も考慮していない。また、データ内容又はファイル配信サービスのようなその他のタイプのセッション／サービスの配信は、現行の適合メカニズムによってサポートされていない。
Ｔ．Ｓｈａｎａｂｌｅｈ ａｎｄ Ｍ．Ｇｈａｎａｂａｒｉ，「Ｍｕｌｔｉｌａｙｅｒ Ｔｒａｎｓｃｏｄｉｎｇ ｗｉｔｈ Ｆｏｒｍａｔ Ｐｏｒｔａｂｉｌｉｔｙ ｆｏｒ Ｍｕｔｉｃａｓｔｉｎｇ ｏｆ Ｓｉｎｇｌｅ−Ｌａｙｅｒｅｄ Ｖｉｄｅｏ」，ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎ ｏｎ Ｍｕｔｉｍｅｄｉａ，ｖｏｌ．７，ｎｕｍｂｅｒ １，Ｆｅｂｒｕａｒｙ ２００５ Ｈ．Ｃｈｉｕ ａｎｄ Ｋ．Ｙｅｕｎｇ，「Ｆａｓｔ−ｒｅｓｐｏｎｓｅ Ｒｅｃｅｉｖｅｒ−ｄｒｉｖｅｎ Ｌａｙｅｒｅｄ Ｍｕｌｔｉｃａｓｔ ｗｉｔｈ Ｍｕｌｔｉｐｌｅ Ｓｅｒｖｅｒｓ」，Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，２００５ Ａｓｉａ−Ｐａｃｉｆｉｃ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ，ｐｐ．２５９−２６３，Ｏｃｔｏｂｅｒ ２００５ Ｗｕ ｅｔ ａｌ．，「Ｏｎ ｔｈｅ Ｕｓｅ ｏｆ Ｓｅｎｄｅｒ Ａｄａｐｔａｔｉｏｎ ｔｏ Ｉｍｐｒｏｖｅ Ｓｔａｂｉｌｉｔｙ ａｎｄ Ｆａｉｒｎｅｓｓ ｆｏｒ Ｌａｙｅｒｅｄ Ｖｉｄｅｏ Ｍｕｌｔｉｃａｓｔ」，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｓｅｃｏｎｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ ｉｎ Ｍｕｌｔｉｓｅｒｖｉｃｅ ＩＰ Ｎｅｔｗｏｒｋｓ，ｐｐ．３４７−３５７，Ｆｅｂｒｕａｒｙ ２００３ Ｓ．ＭｃＣａｎｎｅ，Ｖ．Ｊａｃｏｂｓｏｎ ａｎｄ Ｍ Ｖｅｔｔｅｒｌｉ，「Ｒｅｃｅｉｖｅｒ−ｄｒｉｖｅｎ Ｌａｙｅｒｅｄ Ｍｕｌｔｉｃａｓｔ」、Ｉｎ ｐｒｏｃ．ｏｆ ＳＩＧＣＯＭＭ Ｓｙｍｐｏｓｉｕｍｓ ｏｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ ａｎｄ Ｐｈｏｔｏｃｏｌｓ，ｐｐ．１１７−１３０，Ａｕｇｕｓｔ １９９６ Ｐ．Ｍｅｎｄｅｓ，Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ ａｎｄ Ｅ．Ｍｏｎｔｅｉｒｏ，「Ａ Ｒｅｃｅｉｖｅｒ−ｄｒｉｖｅｎ Ａｄａｐｔｉｖｅ Ｍｅｃｈａｎｉｓｍ Ｂａｓｅｄ ｏｎ ｔｈｅ Ｐｏｐｕｌａｒｉｔｙ ｏｆ Ｓｃａｌａｂｌｅ Ｓｅｓｓｉｏｎｓ」，Ｔｈｉｒｄ ＣＯＳＴ ２６３ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｑｕａｌｉｔｙ ｏｆ ｆｕｔｕｒｅ Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅｓ （ＱｏｆＩＳ），Ｏｃｔｏｂｏｒ ２００２ Ｒ．Ｈａｙｄｅｒ，Ｓ．Ｍｉｈａｅｌａ ａｎｄ Ｋ．Ｓｈｉｒｉｓｈ，「Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ ＴｒａｎＳｃａｌｉｎｇ ｆｏｒ ｔｈｅ Ｗｉｒｅｌｅｓｓ Ｉｎｔｅｒｎｅｔ」，ＥＵＲＡＳＩＰ Ｊｏｕｒｎａｌ ｏｎ Ａｐｐｌｉｅｄ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ （ＪＡＳＰ），ｎｕｍｂｅｒ ２，ｐｐ．２６５−２７９，Ｆｅｂｒｕａｒｙ ２００４

一実施形態によれば、ネットワークを介してソースとレシーバとの間でセッションを適合させるための方法であって、あるソースから発信されている前記セッションが、前記セッションを一体的に形成するような複数のフローから構成されており、前記レシーバが、前記セッションのフローの全部又は一部を受信し、前記セッションが、前記ソースから前記レシーバまで複数のネットワークノードを通過し、複数のアダプテーションエージェントが、前記ネットワークに設けられており、各アダプテーションエージェントが、前記セッションにフローを追加するか又は前記セッションからフローを削除することによりアダプテーションメカニズムを実行する能力を備えており、各アダプテーションエージェントが、前記ソースから前記レシーバまでの前記経路に沿って１個以上のネットワークノードを担当するものであり、当該方法は、
前記アダプテーションエージェントの１つによってネットワーク使用量を表すネットワークパラメータを受信するステップと、
前記セッションを前記ネットワーク使用量に適合させるやり方を前記アダプテーションエージェントによって決定する決定メカニズムを実行するステップと、
前記セッションに１個以上のフローを追加するか又は前記セッションから１個以上のフローを削除するステップと、
前記追加された又は削除されたフローに応じて、ネットワークリソースを割り当てるか又は解放することを、前記ネットワークに設けられたリソース割り当てメカニズムに通知するステップと、
上流及び／又は下流のアダプテーションエージェントに新しいセッションの構成について通知するステップと
を含む方法が提供される。

本方法は、異種環境であっても、エンドホスト上で独自モジュールを実施する必要がないような、セッション・アダプテーションを通じてリソースの効率的な利用するやり方を提供する。

一実施形態によれば、前記フローを追加もしくは削除するステップに代わって、又は、前記フローを追加もしくは削除するステップに付加して、前記決定メカニズムが、現在のサービスクラス以外の異なるサービスクラスに前記セッション中の１個以上のフローを再割り当てすることを決定するものあり、
前記リソース割り当てメカニズムに代わって、サービス品質マッピングメカニズムに前記決定メカニズムの決定に関して通知される。

これは、ＱｏＳメカニズム及びＱｏＳアウェアなセッションマッピングとの相互作用を可能にする。

一実施形態によれば、前記フローを追加もしくは削除するステップに代わって、又は、前記フローを追加もしくは削除するステップに付加して、前記決定メカニズムが、サービスのクラスに関してリソースを再調整することを前記リソース割り当てメカニズムに要求することを決定するようになっている。

これは、ネットワークリソースの再調整により、例えば、セッション中の各フローに割り当てられた全帯域幅を保証できるようにする。

一実施形態によれば、各フローには優先度が割り当てられ、前記決定メカニズムが、前記フローの前記優先度に基づいて前記フローの追加又は削除を決定するようになっている。

これは、個別のフローの優先度を考慮する効率的なサービスアダプテーションを可能にする。

一実施形態によれば、前記ネットワーク使用量の情報が、十分なネットワークリソースが利用可能であるかどうかに関する情報を含んでおり、
前記ネットワークリソースが十分になければ、前記決定メカニズムが１個以上のフローを削除することを決定し、
前記ネットワークリソースが十分にあれば、１個以上のフローを追加することを決定するようになっている。

これは、セッションを実際のネットワーク条件に適合させ、一方、例えば、ネットワーク輻輳は、それが出現したときに考慮され、それが消失したときに再び考慮される。

一実施形態によれば、本方法は、
前記セッション中の前記フローが活動中であるか又は休止中であるかを表すために前記セッションの前記フローの状態を保持するステップを含んでおり、
フローをセッションに追加することは、そのフローを活動状態に置くことに対応しており、
フローをセッションから削除することは、そのフローを休止状態に置くことに対応しており、
前記状態の各々が可逆的である。

このことは、削除されたセッションは失われず、条件が許すならば再び活動させられ得ることを意味する。

一実施形態によれば、複数のセッションが存在しており、前記決定メカニズムが、前記複数のセッションの中で適合させられるべき１個以上のセッションを選択することを備えており、
該選択は、
アダプテーションのために最低オーディエンスサイズを有するセッションを選択するという規準と、
アダプテーションのために最低コストを有するセッションを選択するという規準と、
アダプテーションのためにオーディオセッションよりビデオセッションを優先して選択するという規準と
のうちの１つ以上の規準に基づいている。

これにより、様々なセッションの様々な優先度に適合することが可能となる。

一実施形態によれば、別のアダプテーションエージェントから新しいセッションの構成に関する情報を受信するアダプテーションエージェントは、前記レシーバから前記ソースまでの前記セッションの前記経路における前記アダプテーションエージェントのロケーションと、前記アダプテーションエージェントが前記セッションのための分岐点を有するかどうかとに基づいて、前記フローを追加又は削除するかどうか、及び、前記新しいセッションの構成に関する情報が更に上流又は下流へ転送されるべきであるかどうかを決定するようになっている。

これは、フローが依然として必要とされている場合において、例えば、ネットワークノードがセッションのための分岐点を有するとともに異なる分岐でフローが依然として必要とされているという理由から、ノードはそのフローを削除するのではなく、そのフローを維持し続けるという効果がある。更に、これによって、ネットワークに異種性があり得ることも考慮し、一方のドメインではフローは削除され、別のフローではフローは維持され続けることになる。

一実施形態によれば、ネットワークを介してソースとレシーバとの間でセッションを適合させるためのエージェントであって、あるソースから発信されている前記セッションが、前記セッションを一体的に形成するような複数のフローから構成されており、前記セッションが、前記ソースから前記レシーバまで複数のネットワークノードを通過し、当該エージェントが、前記ネットワークに設けられた複数のアダプテーションエージェントのうちの１つのエージェントであり、各アダプテーションエージェントが、前記セッションにフローを追加するか又は前記セッションからフローを削除することによりアダプテーションメカニズムを実行する能力を備えており、各アダプテーションエージェントが、前記ソースから前記レシーバまでの前記経路に沿って１個以上のネットワークノードを担当するものであり、
前記アダプテーションエージェントが、
ネットワーク使用量を表すネットワークパラメータを受信するインタフェースと、
前記セッションを前記ネットワーク使用量に適合させるやり方を決定する決定モジュールと、
前記セッションに１個以上のフローを追加するか又は前記セッションから１個以上のフローを削除する追加／削除モジュールと、
前記追加された又は削除されたフローに応じて、ネットワークリソースを割り当てるか又は解放することを、前記ネットワークに設けられたリソース割り当てメカニズムに通知するリソース情報モジュールと、
上流及び／又は下流のアダプテーションエージェントに新しいセッションの構成を通知する上流／下流情報モジュールと
を備えている、エージェントが提供される。

一実施形態によれば、前記フローの追加もしくは削除に代わって、又は、前記フローの追加もしくは削除に付加して、前記決定モジュールが、前記セッション中の１個以上のフローを現在のサービスクラス以外の異なるサービスクラスへ再割り当てすることを決定するものであり、
前記リソース割り当てメカニズムの代わりに、サービス品質マッピングメカニズムに前記決定モジュールの決定に関して通知されるようになっている。

一実施形態によれば、前記フローの追加もしくは削除に代わって、又は、前記フローの追加もしくは削除に付加して、前記決定モジュールが、サービスのクラスに関してリソースを再調整することを前記リソース割り当てメカニズムに要求することを決定するようになっている。

一実施形態によれば、各フローには優先度が割り当てられ、前記決定メカニズムが、前記フローの前記優先度に基づいて前記フローの追加又は削除を決定するようになっている。

一実施形態によれば、エージェントは、
前記セッション中のフローが活動中であるか又は休止中であるかを表すために前記セッション中のフローの状態を保持する保持モジュールを備えており、
フローをセッションに追加することは、そのフローを活動状態に置くことに対応しており、
フローをセッションから削除することは、そのフローを休止状態に置くことに対応しており、
前記状態の各々は、可逆的である。

一実施形態によれば、前記決定モジュールは、前記レシーバから前記ソースまでの前記セッションの前記経路における前記アダプテーションエージェントのロケーションと、前記アダプテーションエージェントが前記セッションのための分岐点を有するかどうかとに基づいて、前記フローを追加又は削除するかどうか、及び、前記アダプテーションエージェントが別のアダプテーションエージェントから新しいセッションの構成に関する情報を受信した場合にこの情報が更に上流又は下流へ転送されるべきであるかどうかを決定するようになっている。

以下、発明の実施形態を詳細に説明する。最初に、以下の説明で使用される用語を簡単に説明する。

・自律システム（Autonomous System）（ＡＳ）：単一の管理エンティティの代わりに共通ネットワークアドミニストレータによって制御される単一ネットワーク又はネットワークのグループの何れかである。
・ドメイン：共通のサービスポリシーの集合で動作するようなノードの集合である。本提案では、ドメインはＡＳとして見なされている。
・下流：データフローと同一方向。
・上流：データフローと反対方向。
・セッション：セッションは、ユーザ（又はユーザエージェント）とピアとの間の通信を定義する。セッションは、セッションフローの集合を構成するようにある程度の個数（１からＮ個）のフローから構成されている。セッションは１個以上（Ｍが自然数であるとして、１からＭ個）のレシーバによって受信される。
・休止中フロー（Asleep flow）：ＳＡＱＵＥエージェントによってデータプレーンから削除されたセッションのフローである。
・活動中フロー（Awaked flow）：ＳＡＱＵＥエージェントによってデータプレーンに追加されたセッションのフローである。
・ＳＡＱＵＥエージェント：発明の実施形態に従ってセッションを適合させるＳＡＱＵＥメカニズムを実施するネットワーク内のエンティティである。
・データプレーン（data plane）：データパケットを処理するために使用されるネットワーク機能性（network functionality）の集合である。これは、ネットワークプロトコルによって使用されるものとして制御パケットを処理するために使用され得るネットワーク機能性の集合である制御プレーンの反対の意味である。
・配信チャンネル（distribution channel）：セッションのフローがドメイン内又はドメイン間で関連付けられたユニキャストフロー又はマルチキャストツリーである。マルチキャストツリーは、ソース・スペシフィック・マルチキャスト（ＳＳＭ）チャンネルである（ＲＦＣ３５６９を参照）。

図１は、発明の実施形態が使用される環境を示している。パブリッシュ−サブスクライブサービス（publish-subscribe）は、ＩＰＴＶサービスのような様々なマルチユーザセッションを有しており、このＩＰＴＶサービスは、各番組がセッションに対応する様々な番組を有している。各セッションは、（オプションとして）、オーディオ、ビデオ、及び、ＴＶレーティングのような複数のメディアタイプを備え得る。１つのメディアタイプ（例えば、ビデオ）は、そのとき、例えば、ＭＰＥＧ４コーデックを使用することにより、数個のフローで構成し得る。ユーザは、図１に概略的に示されているように、個別にセッションに加わることを希望している。

一実施形態によれば、セッション中の優先度の低いフローを削除又は追加することによりマルチユーザセッションの品質レベルを現在のネットワーク条件に適合させるＱｏＳ（サービス品質）アウェア・セッション・アダプテーションメカニズム（Qos -aware session adaptation mechanism：以下、ＳＡＱＵＥメカニズム又は簡単にＳＡＱＵＥと呼ぶ）が提供される。よって、レシーバは、利用可能なセッション（例えば、最大品質−セッションの全フロー）に参加し、ＳＡＱＵＥメカニズムは、例えば、現在のリンク容量とフロー優先度とに基づくネットワークの実際の条件に応じて、セッション中のフローの個数を調整する。セッション・アダプテーションのプロセスは、例えば、別のネットワークサービスクラスへフロー又はセッションを再割り当てすることを要求することにより、ＱｏＳマッピングスキームとの相互作用によって実行することも可能である。更に、ＳＡＱＵＥは、セッション中の優先度の低いフローがドメイン又はドメイン間によってサポートされていないときに、上流及び／又は下流のネットワークリソースの浪費を回避することを目的としている。

一実施形態によれば、セッション・アダプテーションを実行する役割を担うセッション・アダプテーションのためのセッション・アダプテーションエージェント（以下では、ＳＡＱＵＥエージェントと呼ばれる）が提供される。ＳＡＱＵＥエージェントは、ネットワーク内の別個のエンティティでもよく、又は、ネットワークのエッジに位置するとともに、他のネットワークからの他のネットワークエージェントのようなレシーバもしくは他の装置へアクセスできるネットワークエージェントのような別のネットワークエンティティに統合されてもよい。

一実施形態によるＳＡＱＵＥメカニズムのＱｏＳアウェア特性は、（例えば、ＱｏＳマッピングスキームと相互作用することにより）ネットワークサービスクラスにマッピングされたマルチユーザセッションの調整を制御する能力、又は、リソース割り当てコントローラスキームと相互作用することによりネットワークサービスクラスの調整を要求する能力によって実現される。更に、一実施形態によるＳＡＱＵＥメカニズムは、オープンインタフェースの使用により異種環境にわたってセッション・アダプテーションをサポートするようになっている。このインタフェースは、様々なプロトコル及びメカニズムとの相互作用と、容易な配備と、異種環境への適用とを可能にする。このインタフェースは、ＳＡＱＵＥが以下のコンポーネントと通信することを可能にする。
・マルチユーザセッションの制御、サポート及び品質レベルを改善するようなセッション又はアプリケーションプロトコル又はメカニズム。
・アンダーレイ・トランスポート接続とは独立にセッションの調整を可能にする接続性制御プロトコル又はメカニズム。
・ネットワークリソースの動的管理をサポートするリソース割り当てコントローラプロトコル又はメカニズム。
・モビリティオペレーションを支援するモビリティプロトコル（mobility protocol）又はメカニズム。

これらのコンポーネントは後で詳しく説明される。

上記に加えて、ＳＡＱＵＥメカニズムは、以下の内容を提供する環境で動作するようになっている。
・マルチユーザセッションのセンダーが、例えば、セッション記述プロトコル（ＳＤＰ）を使用することにより各フローの必要条件及び優先度を定める（非特許文献７）。
・各レシーバがオフライン又はオンライン手段を用いてセンダーから利用可能なセッションのセッション記述を取得する。
・各レシーバが参加を希望するところにあたるセッションの記述を、セッションセットアップの際にレシーバが接続されているアクセスネットワーク内のエージェントに送信する。
・ネットワークエージェントは、ユーザによって要求されたサービスの（セッション及びその関連したパラメータの定義である）セッションオブジェクトを定め、このセッションオブジェクトは、セッション・アダプテーションを実行するために使用されるものである。また、このセッションオブジェクトは、各フローの優先度及び／又は現在の帯域幅容量に関する情報を格納している。
Ｍ．Ｈａｎｄｌｅｙ，Ｖ．Ｊａｃｏｂｓｏｎ ａｎｄ Ｃ．Ｐｅｒｋｉｎｓ，「ＳＤＰ：Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ」，ＩＥＴＦ，Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ，Ｊａｎｕａｒｙ ２００６

ＳＡＱＵＥエージェントは、ドメイン間、ドメイン内でセッション・アダプテーションを実行するように構成され、かつ、ドメイン内又はドメイン間のネットワークエージェントの集合に関連付けられ得る。図２は、ドメインＤ１にドメイン内のセッション・アダプテーションを制御する役割を担う１個のＳＡＱＵＥエージェントが存在する、一般的なシナリオにおけるＳＡＱＵＥのロケーション（location）の実施例を表している。ドメインＤ２内で、各ＳＡＱＵＥエージェントは、ネットワークエージェントの集合のためのセッション・アダプテーションを実行するように構成されている。最後に、ドメインＤ３内で、ＳＡＱＵＥエージェントは、ネットワークエージェントとともにエッジに配置されている。ＳＡＱＵＥインタフェースの使用は、後述されているように異種環境内での簡単な配備をサポートする外部プロトコル又はメカニズムとの容易な相互作用を可能にする。

セッション・アダプテーションを実行するため、ＳＡＱＵＥエージェント（或いは、外部セッション又はアプリケーションプロトコル若しくはメカニズム）は、（上流及び／又は下流エージェントのＩＰアドレスと、セッションの各フローの重要性と、ビットレートと、動作状態とを含んでいる）セグメント内の現在のセッションに関連する各セッション及び各フローの状態を保持するようになっている。削除されたフローの動作状態に関する情報は、セッションパスに沿った全エージェントによって保持され、又は、データプレーンからフローを削除した最初のエージェントだけによって保持される（この場合、除去されたフローに関する制御情報は、その他のエージェントの制御プレーンから解放される）。ステートレスＳＡＱＵＥ（stateless SAQUE）が作動させられたとき、ステートレスＳＡＱＵＥは、現在のセッション及びセッションのフローに関する制御情報（例えば、各セッション又はフローの動作状態、ネットワークサービスクラス、重要性、オーディエンスサイズ及びコスト）を交換するためにセッション／アプリケーションのプロトコル／メカニズムと相互作用する。フローの動作状態は、休止状態にされ（データプレーンから削除され）、又は、活動状態にされる（データプレーンに追加される）。ここで、休止状態とは、フローがネットワークリソースの利用不能によって休止していることを意味し、活動状態とは、フローのため利用可能なネットワークリソースが存在することを意味する。

更に、ＳＡＱＵＥエージェント間の同時使用は、（ＳＡＱＵＥエージェントが発生、送信、受信、及び、解釈可能である専用ＳＡＱＵＥメッセージを用いて、又は、外部のセッション／アプリケーションのプロトコル／メカニズムによってサポートされているシグナリングメッセージの使用によって）メッセージをシグナリングすることにより行われる。メッセージによって伝達される情報、例えば、セッションオブジェクトは、ネットワークリソースの上流及び／又は下流の浪費を回避して、上流又は下流のエージェントに休止状態又は活動状態に置かれるべきフローを知らせるために使用される。

図３には、後述されるコンポーネントを備えるＳＡＱＵＥエージェント３５０が概略的に示されている。主要なコンポーネントは、以下で説明されるアダプテーションメカニズム３００及び数個のインタフェースである。
・インタフェース：
セッション／アプリケーションインタフェース３０５：作動すること、及び、休止状態又は活動状態に置かれるべきセッションのフローに関する制御情報（例えば、セッションオブジェクト）を送信することをＳＡＱＵＥアダプテーション・プロセスに要求するために、外部のプロトコル／メカニズム３２５によって使用されるインタフェース（例えば、セッションアウェアＱｏＳアダプテーションメカニズムは、セッションを現在のネットワーク条件に再調整するようにＳＡＱＵＥをトリガーする）。このインタフェースは、フロー又はセッションをサービスの別のネットワーククラス（network class）へ再割り当てすることを要求するためにＱｏＳマッピングスキームを作動させるように更に構成されることが可能である。ＳＡＱＵＥエージェントが自分のジョブを終了したとき、ＳＡＱＵＥエージェントは、リクエスタへの応答を送信するために同じインタフェースを使用するようになっている。
接続性インタフェース３１５：このインタフェースは、活動中のフローがドメイン内又はドメイン間で関連付けられた配信チャンネルをプロトコル／接続性制御メカニズム３３０に要求するために使用される。更に、ＳＡＱＵＥエージェントは、フローが休止状態に置かれたために、どの配信チャンネルが削除されるべきであるかに関する情報を送信するためにこのインタフェースを使用するようになっている。
リソースインタフェース３１０：ネットワークリソースの浪費を避けるため、ＳＡＱＵＥは、セッション中のどのフローが休止状態であるかをリソース割り当てコントローラプロトコル又はリソースコントローラメカニズム３３５へ通信するために、このインタフェースを使用する。更に、ＳＡＱＵＥエージェントは、セッション中の活動状態のフローによって使用されるべきサービスのクラスと関連付けられているネットワークリソースを要求するために、このインタフェースを使用する。このインタフェースは、要求の状態に関する応答（例えば、受け入れられた、又は、拒絶された）を受信するため、ネットワークの現在の状態に関する情報（例えば、輻輳状況において影響されたサービスのクラス）を受信するため、及び、ネットワークサービスクラスの調整を要求するためにも使用される。
アクセスインタフェース３２０：このインタフェースは、モビリティオペレーションを支援するために、セッション中の休止もしくは活動中のフローに関してモビリティ管理プロトコル／メカニズム又はアクセスコントローラメカニズム３４０に通知するためにＳＡＱＵＥエージェントによって使用される。このインタフェースは、（例えば、セッション開始プロトコル（ＳＩＰ、ＲＦＣ３１６１を参照）のような標準的なプロトコルを使用することにより）、自分のセッションの品質レベルをエンドホストに通知するため、又は、加入されるか又はそのまま放置されるべきセッションのフローをユーザアプリケーションに通知するため、また、プロトコル／メカニズム３４０をトリガーするためにも使用される。
・アダプテーションメカニズム３００：セッション・アダプテーションメカニズムは、入力としてセッションオブジェクト及び現在のネットワーク条件（例えば、ネットワークサービスクラス毎に利用可能な帯域幅）を有する。その後、入力情報は、セッションのフローを削除又は追加するため、並びに、ネットワークサービスクラスの調整するため、フローもしくはセッションの別のサービスクラスへの再マッピングを要求するために使用される。

上記インタフェースに基づいて、ＳＡＱＵＥエージェントは、セッションセットアップ中のリソースの不足に起因して、又は、輻輳（congestion）中のリソースの減少に起因して、例えば、リソースコントローラのような様々なメカニズムから数種類のトリガーを受信することができる。ＳＡＱＵＥメカニズムは、別のＳＡＱＵＥエージェント又はＱｏＳマッピングメカニズムからもトリガーを受信することができる。トリガーされた後、ＳＡＱＵＥメカニズムは、再調整されるべきセッションを特定することにより開始する。これは、例えば、
・常に、最低オーディエンスサイズを伴うセッションを調整する。
・常に、最低コストを伴うセッションを調整する。
・常に、最初にビデオセッションを調整し、その後にオーディオセッションを調整する。
といったポリシーに基づいて行われ得る。

ポリシーの構成は、サービスプロバイダによって、そのビジネスモデルに応じてもしくはその隣接サービスプロバイダとの合意に応じて静的に行われ、又は、隣接のＳＡＱＵＥエージェントのような外部トリガーによって動的に行われ得る。

セッション及び対応するネットワーククラスの集合の選択後、ＳＡＱＵＥメカニズムは、このようなセッションの品質を、
・（マッピングメカニズムが利用可能であるならば）セッション中の全フローの一部をサービスクラスへ再マッピングすることを要求すること
・（アロケーションメカニズムが利用可能であるならば）ネットワーククラスのリソースの再調整を要求すること
・フローを削除／追加することによって現在のネットワーククラス内のセッション品質を低下又は向上させること
などによって調整するようになっている。

再マッピングの目的のため、ＳＡＱＵＥエージェントは、マッピングメカニズム、例えば、「サービスマッピングの品質のための方法及び装置（the method and apparatus for quality of service mapping）」という名称で、本出願と同一出願人の名義かつ同日に出願された欧州特許出願に記載されているようなメカニズムと通信し得る。このようなマッピングメカニズムの詳細は、参照によって本明細書に組み込まれているこの並行してなされた出願に記載されている。

複数のアダプテーションエージェント（又はＳＡＱＵＥエージェント）を使用するアダプテーションメカニズムのオペレーションは、図４に示されているフローチャートと共に説明される。オペレーション４００において、ＳＡＱＵＥエージェント（アダプテーションエージェント）は、ネットワーク使用量を知らせるネットワークパラメータと一緒にトリガーメッセージを受信する。これらのパラメータは、例えば、ネットワーク使用量を監視するリソース割り当てコントローラから生成され、それらは、空いているリソース及び利用可能なリソースを表すか、又は、例えば、ネットワーク内の輻輳を表し得る。

応答として、ＳＡＱＵＥエージェントは、オペレーション４１０において、ネットワークパラメータに適合するやり方を決定するために決定メカニズムを実行するようになっている。この決定メカニズムは、例えば、図３に示されているメカニズム３００であり得る。

決定メカニズムの結果は、例えば、フローをセッションに追加すること、又は、フローをセッションから削除することである（オペレーション４２０）。オペレーション４３０において、ＳＡＱＵＥエージェントは、その後に、ネットワークに設けられたリソース割り当てメカニズムに、このメカニズムがそれに応じてリソースを割り当てるか、又は、解放するように、フローの新しい構成を通知するようになっている。

オペレーション４４０において、ＳＡＱＵＥエージェントは、次に、セッションのパスに沿った上流及び／又は下流エージェントに新しいセッション構成を通知するようになっている。このようにして通知されたＳＡＱＵＥエージェントは、これをトリガーメッセージとして使用して、自分自身がセッションのフローの追加又は削除を実行し、その後に、再び、自分のドメイン内の何れかの（可能であればその他の）リソース割り当てメカニズムに新しいセッションの構成を通知する。再び、ＳＡＱＵＥエージェントは、その後に、新しいセッションの構成に関する情報を、セッションパス内での自分のロケーションに依存して、上流及び／又は下流方向へ渡してもよい。このように、追加又は削除されたフローに関する情報は、レシーバからソースまでのセッションパスに沿って全ＳＡＱＵＥエージェントへ転送され、このようにして、セッションがネットワーク全体を通じて適合させられるようになっている。

一実施形態によれば、新しいセッションの構成に関して上流又は下流エージェントから情報メッセージを受信するＳＡＱＵＥエージェントは、この情報メッセージが、受信されたメッセージの提供元のエージェントにおいて行われたようにフローを追加又は削除することにより自分自身でセッション・アダプテーション・メカニズムを実行するようなトリガーメッセージであると見なす。しかしながら、決定メカニズムは、このエージェントが担当しているネットワークノード内において実際にフローが追加されるべきであるか、又は、削除されるべきであるかという問題に関して、ある種の情報（インテリジェンス）を利用し得る。例えば、ＳＡＱＵＥエージェントが担当しているノードは、セッションが下流方向へ分岐する分岐ノードであり、分岐のうちの１つは、依然としてこのフローを使用するかもしれない。この場合、ＳＡＱＵＥエージェントは、フローを保持すること、及び、更なるトリガーメッセージを上流方向へ転送しないことを決定し得る。

一実施形態によれば、決定メカニズムは、フローを追加又は削除することを決定せずに、１個以上のフローを異なるサービスクラスへ再マッピングすることを決定する。この場合、サービス品質マッピングメカニズムは、リソース割り当てメカニズムの代わりにこの決定を通知され得る。

更なる実施形態によれば、決定メカニズムは、フローを追加／削除すること、又は、フローを再マッピングすることを決定しないが、ネットワーククラスリソースの再調整を実行することを決定する。一実施形態では、決定メカニズムは、セッションを適合させる３つの選択肢、すなわち、サイズ変更（フローの追加／削除）と、異なるサービスクラスへのフローの再マッピングと、ネットワーククラスリソースの調整とを有している。決定メカニズムは、したがって、状況に応じて３つのうちの１つ以上を選択し、それらが、次に、できる限り所与の優先度又は順序で実行される。これにより、図５のフローチャートと共にこれから説明される実施形態が導かれる。

手順は、できる限り複数のセッションの間のセッションの選択（５１０）と、一体的にセッション・アダプテーションをトリガーするオペレーション５００とによって開始する。オペレーション５２０において、手順はネットワークリソースに関する情報を取得し、その後に、オペレーション５２５において、決定メカニズムは使用すべきアダプテーション方法５３０を決定する。この決定は、ネットワークリソースのようなパラメータ、様々なクラス内で利用可能なリソースに関する情報のようなパラメータに基づいており、更に、これらの種類のパラメータを使用するとともに予め構成され得る、ある種の決定スキームに基づいている。付加的に又は代替的に、セッションを適合させるために選択されたやり方は、要求又はトリガーに基づいており、例えば、トリガーがマッピングメカニズムよってもたらされたものならば、オペレーションは、そのとき、再マッピングであり得る。

選ばれた選択肢がフローの追加／削除である場合、オペレーション５３５において、追加又は削除されるべきフローが選択される。この決定は、例えば、フローに割り当てられた優先度に基づいている。

オペレーション５４０において、リソース割り当てメカニズムは、次に、対応するリソースの割り当て又は解放をトリガーするように通知される。オペレーション５４５において、上流及び／又は下流のエージェントは、新しいセッションの構成が通知される。

決定メカニズムがオペレーション５２５においてネットワークリソースの調整を始めるならば、これは、実行されるアダプテーション方法５３０が、ネットワーククラスリソースの調整を要求するオペレーション５５０（例えば、対応する制御メカニズム）を含む、という効果がある。これが可能でないならば（チェックボックス５５５）、メカニズムは、フローを追加／削除することによりセッションをサイズ変更する他のアダプテーションメカニズムに進み得る（オペレーション５３５）。

オペレーション５２５おいて選択されたアダプテーションメカニズムが再マッピングであるならば、このメカニズムは、再マッピングされるフローを選択するためにオペレーション５６０に進み、その後、マッピングメカニズムは、オペレーション５６５において、再マッピングを実行するように要求される。これが成功しないならば、このメカニズムはセッションをサイズ変更することによりアダプテーションを進める（オペレーション５３５）。

図５に示されているように、１個（以上）のアダプテーションメカニズムが、できる限り優先度又は順序に従って選択され、初期的に選択されたアダプテーションメカニズムが失敗した場合のバックアップメカニズムが準備されている。

一実施形態によれば、ＳＡＱＵＥメカニズムは、例えば、セッションを確立するときに、フローに割り当てられた優先度に基づいて追加又は削除すべきフローに関する決定を行うようになっている。

一実施形態において、ＳＡＱＵＥエージェントによって実行されるオペレーションに関する決定は、このＳＡＱＵＥエージェントのロケーション及び／又は外部トリガーに依存する。更に、セッション中のフローの個数の調整とは無関係に、ＳＡＱＵＥエージェントのアダプテーションメカニズムは、２つの基本的な作業方法、すなわち、マルチユーザセッションのフローを削除／休止、又は、追加／休止解除を有しており、後述されるように、休止状態又は活動状態に置かれるフローを選択するために決定プロセスを実行する能力を更に備えている。

最初に、セッションを現在のネットワーク状態に適合させるオペレーション方法、すなわち、セッション中のフローの個数の削減又は増加について説明する。

・セッション中のフローの個数の削減
このオペレーションは、セッション中の優先度の低いフローを削除することによりセッション品質レベルを低下させる。この場合、ＳＡＱＵＥエージェントは、セッションを現在のネットワーク条件に適合させ、かつ、（例えば、ＳＡＱＵＥエージェントにフローの個数が削減されるべきであることを知らせるリソース割り当てメカニズムと相互作用する）エージェントによって削除される／削除され得るセッション中のフロー又は優先度の低いフローによる上流及び／又は下流のネットワークリソースの浪費を回避する目的で、セッション中の（休止状態に置かれた）フローの個数を削減するために、例えば、外部アプリケーションプロトコルによって（それらのインタフェースを介して）トリガーがされる。一実施形態では、ＳＡＱＵＥは、例えば、外部セッション／アプリケーションのプロトコル／メカニズムによって、又は、リソース割り当てコントローラプロトコル／メカニズムによって、セッション中のフローの個数を削減するためにトリガーされる。例えば、ＱｏＳマッピングメカニズムは、ネットワークサービスクラスの利用可能な容量がセッション中のフローの低いパケット損失を保証するために十分ではないとき、ＳＡＱＵＥエージェントをトリガーしてもよい。更に、一実施形態では、ＳＡＱＵＥエージェントは、そのインタフェースを介して、自分のセッションの品質レベルをレシーバに通知するように、又は、着目中のレシーバがそのセッション若しくはそのセッション中のフローに存在しないことをソースに通知するように、又は、セッション中のフローが削除されたときに、その状態を更新するために、モビリティ管理スキーム若しくはメカニズムにシグナリングするように構成されている。

・セッション中のフローの個数の再確立（増加）
このオペレーションは、優先度の低いフローをセッションに追加することにより、セッションの完全な品質を保証することを目的とする。ＳＡＱＵＥエージェントは、最大のセッション品質レベルをサポートするため、セッション中のフローの個数を再確立するようにトリガーされる。休止中フローは、ネットワーク能力（network capability）が（例えば、他のセッションの終了、ルーティング変更、又は、輻輳のないネットワークへのレシーバの移動性に起因して）再び利用可能になるとき、ＳＡＱＵＥエージェントによって休止状態が解除される。ＳＡＱＵＥエージェントは、外部セッション／アプリケーションのプロトコル／メカニズムによって（例えば、外部アプリケーションプロトコルにより送信されたシグナリングメッセージを受信することによって）、又は、リソース割り当てコントローラプロトコル／メカニズムによって（例えば、リソースコントローラからリソースインタフェース３１０を介してＳＡＱＵＥエージェントへ渡されたある特定のネットワークサービスクラスの利用可能な帯域幅を知らせることによって）、セッション中のフローを休止解除するためにトリガーされてもよい。ＳＡＱＵＥエージェントは、フローがドメイン内又はドメイン間で関連付けられ、様々なアドレス範囲の間の不連続点を回避する配信チャンネルを休止状態が解除されたフロー毎に要求するために接続性制御メカニズムと相互作用するように更に構成されてもよい。その上、セッションパスに沿ったフローの再確立中に、セッション中の何れかのフローが（例えば、ネットワークリソースの利用不可能性に起因して）エージェントによってサポートされないならば、前述のオペレーション方法又はフローの除去／削減が要求される。

決定プロセス：
一実施形態では、ネットワークサービスクラスのリソースを再調整する要求に関する決定、並びに、（もし利用可能であるならば）別のサービスのクラスに再割り付けされるべきフロー又は休止状態又は活動状態に置かれるべきフローに関する決定は、静的及び／又は動的な構成によって選択されたフレキシブルパラメータの集合に基づいている。前者は、サービスプロバイダによってそのビジネスモデルに応じて、又は、隣接するサービスプロバイダとのある同意に応じて構成される（例えば、ネットワーク輻輳の状況では、ＳＡＱＵＥエージェントは、小規模のオーディエンスを有するセッション中のフローを削除するように静的に構成されている）。動的な構成は、ＱｏＳマッピングメカニズム（既に記載されたアプリケーション、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ Ｍａｐｐｉｎｇ」）のような外部プロトコル／メカニズムによって、若しくは、（それらのインタフェースを経由する）アプリケーションプロトコルよって、又は、その他のＳＡＱＵＥエージェント（例えば、専用のＳＡＱＵＥメッセージを用いて）を介して要求時（on-demand）に行われる。これらの場合に、指示が、インタフェースによって、又は、例えば、どのフローが休止状態若しくは活動状態に置かれるべきかもしくは別のサービスクラスへ再割り当てされるべきフローはどれであるかという情報を送信するメッセージによって、伝達される。動的な構成は、シグナリングメッセージ又はインタフェースの要求によって、記述されたセッションのセッションメディアタイプ又はコストに応じて実行される。更に、ネットワーク輻輳の期間中、ＳＡＱＵＥエージェントは、例えば、セッション中の各フローに割り当てられた全帯域幅を保証する目的で、サービスのクラスに関してネットワークリソースを再調整するためにリソース割り当てコントローラメカニズムをトリガーすることができる。

（ＳＡＱＵＥエージェントによって実施される）ＳＡＱＵＥメカニズムは、異種環境を間に介するような様々なレシーバへのマルチユーザセッション内容の配信を可能にする。その上、ＳＡＱＵＥメカニズムは、エージェントによって拒絶された（又は拒絶されることになる）フローのセッションによる上流又は下流のネットワークリソースの浪費を回避するようになっている。

ＳＡＱＵＥメカニズムの更なる実施形態が次に説明される。

ＳＡＱＵＥメカニズムは、マルチユーザセッションの品質レベルを異種環境で様々なレシーバに適合させることを目的としている。更に、ＳＡＱＵＥは、上流又は下流のネットワークリソースの浪費と、エージェントにおいてサポートされていないフローによって記憶された状態とを回避することにより、ネットワークリソースの使用量を改善することを目的とする。一実施形態では、ドメイン内又はドメイン間のサービスクラスに関する現在のネットワークリソース容量に関する情報は、リソース割り当てコントローラプロトコル又はメカニズムによってサポートされている。例えば、輻輳状況において、ＳＡＱＵＥエージェントは、例えば、ネットワーククラスにマッピングされたセッション中のフローを休止状態に置くことにより、又は、別のサービスクラスへのフローの再割り付けを要求することにより、セッションを現在のネットワーク条件に適合させるようにトリガーされる。ネットワークリソースが再び利用可能であるとき、ＳＡＱＵＥエージェントは、例えば、予め休止状態に置かれていたフローを休止解除することにより、セッションの品質レベルを再調整するため作動されるようになっている。一実施形態では、ＳＡＱＵＥは、フローが遮断されることを回避するために、セッションのフローを別のネットワークサービスクラスへ再割り当てするやり方として、外部ＱｏＳマッピングメカニズムを作動するように構成され得る。更に、フローが休止状態又は活動状態に置かれるとき、ＳＡＱＵＥエージェントは、セッション中のフローの個数を除去又は再確立するためのやり方として、上流及び／又は下流のエージェントへシグナリングすることにより、セッションの品質レベルを調整するように、セッション、又はアプリケーションのシグナリングプロトコル、又はメカニズムをトリガーするようになっている。この機能性は、例えば、専用のＳＡＱＵＥメッセージを使用するＳＡＱＵＥエージェントによってサポートされ、又は、シグナリングは、アプリケーションプロトコルを使用して行われてもよい。例えば、ＳＡＱＵＥメッセージは、エッジにあるルータ間で動作する任意のセッション制御プロトコルのメッセージ集合に含まれていてもよい。どのフローが休止状態又は活動状態に置かれるべきであるかに関する決定は、クラス毎にネットワークリソースを再調整するために、別のサービスクラス又はリソース割り当てコントローラメカニズムへフローを再割り当てするＱｏＳマッピングスキームとの相互作用と同様に、静的又は動的に構成されたフレキシブルパラメータの集合に基づくことが可能である。例えば、この決定は、シグナリングメッセージによって運ばれたセッションオブジェクト、各セッション又はフローのコスト、及び／又は、各フロー若しくはセッションのタイプの集団のサイズに基づき得る。

ＳＡＱＵＥエージェントは、ステートフル（stateful）でもステートレス（stateless）でもよく、後者では、外部セッション又はアプリケーションプロトコル若しくはメカニズムは、ＳＡＱＵＥエージェントが関連付けられているドメイン内又はドメイン間の現在のセッションに関する各セッション及び各フローの状態を保持しなくてはならない。一実施形態では、セッション・アダプテーションを実行するために必要とされる状態は、上流及び／又は下流のＳＡＱＵＥエージェントのＩＰアドレスと、セッションのための分岐点の個数と、各フローの重要性（又は優先度）と、ビットレートと、ネットワークサービスクラスと、動作状態に関する情報とを含んでいる（動作状態を含む削除されたフローに関する情報は、全エージェント、又は、エージェントがセッションパスに沿って関連付けられている外部メカニズム、又は、データプレーンからフローを削除した第１のエージェント（若しくはメカニズム）だけによって保持される）。更に、ＳＡＱＵＥエージェントによって実行されるセッション・アダプテーションを改良するため、一実施形態によれば、記憶されている状態は、例えば、オーディエンスサイズと各セッション又はフローのコストとに関するような余分な情報を収容することにより強化される。したがって、ＳＡＱＵＥエージェントが作動されているとき、ＳＡＱＵＥエージェントは、外部セッション／アプリケーションのプロトコル／メカニズムもしくはＳＡＱＵＥエージェントによって保持されている状態、又は、シグナリングメッセージに記述されている情報に応じて、自分のオペレーションを実行するようになっている。その上、ＳＡＱＵＥエージェント間の通信は、ＳＡＱＵＥメッセージ、又は、外部セッション／アプリケーションのプロトコル／メカニズムのシグナリングメッセージに基づき得る。シグナリングメッセージは、上流及び／又は下流のＳＡＱＵＥエージェントに、休止状態又は活動状態に置かれるべきフロー、並びに、別のサービスクラスに再割り当てされたフロー（セッションオブジェクトに記述されている情報）を通知し得る。

以下の説明中、一実施形態によるＳＡＱＵＥメカニズムは、より詳細に記述される。本実施形態は、セッション中のフローの追加／削除の説明に焦点を置いている。しかしながら、一実施形態によれば、ＳＡＱＵＥエージェントの機能性は、別のサービスクラスへのフローの再割り当て、又は、クラスに関するネットワークリソースの調整の要求を更に備えている。これは、ＳＡＱＵＥエージェントとリソース割り当てメカニズムとサービス品質マッピングメカニズムとの間のそれぞれのインタフェースを経由する付加的な適切なシグナリングによって実行され得る。

以下の実施形態では、外部のセッション／アプリケーションのプロトコル／メカニズムは、ＳＡＱＵＥメカニズム（ＳＡＱＵＥエージェント）によって使用される（セッションパスに沿ったフローの動作状態を含む）各セッション及び各フローの状態を保持する役割を担うことが想定されている。例えば、図２に示されているように、ソースからレシーバＲ２までの間のＳＡＱＵＥエージェントを含むネットワークエージェントのような、ソースからレシーバまでのパスに沿った複数のＳＡＱＵＥエージェントが存在する場合を想定する。本実施形態では、ＳＡＱＵＥエージェント間の同時使用は、この外部のセッション／アプリケーションのプロトコル又はメカニズムのシグナリングメッセージの使用によって実行されている。セッションパスに沿ったＳＡＱＵＥエージェントのロケーション（location）に依存して、かつ、ＳＡＱＵＥエージェントがトリガーされる時に依存して、ＳＡＱＵＥエージェントの挙動は以下のようになる。

最初に、セッション中のフローの個数の削減のオペレーションが、ＳＡＱＵＥエージェントの様々なロケーションｉ）からｉｉｉ）と、このオペレーションが要求される様々な時点とに関して説明される。

ｉ）ＳＡＱＵＥエージェントのロケーション：セッションのアクセスポイントでセッション・アダプテーションを制御する役割を担うエージェントである。
・セッションセットアップ中：ＳＡＱＵＥエージェントが外部のセッション／アプリケーションのプロトコル／メカニズムによってトリガーされたとき（すなわち、ネットワークリソースがフローに関して現在のエージェントによって予約されていなかった場合）、ＳＡＱＵＥエージェントは、（例えば、セッションオブジェクトによって与えられる現在の帯域幅容量及びフロー優先度に基づいて）削除されるべきセッション中のフローを選択し、ＳＡＱＵＥエージェントは、例えば、シグナリングメッセージを送信することにより、セッション中の（休止状態に置かれている）休止中のフローに関する状態を更新するため、かつ、参照されているフローに関する状態を除去する（参照されているフローを休止モードに置く）ため、上流エージェントにシグナリングするように外部のセッション／アプリケーションのプロトコル／メカニズムをトリガーする。
・セッションセットアップ後：ＳＡＱＵＥエージェントは、例えば、休止状態に置かれるべきフローを通知するシグナリングメッセージを受信することにより、外部のセッション／アプリケーションのプロトコル／メカニズムによってトリガーされ得る（例えば、この状況は上流エージェントからフロー休止に関する情報を受信した後に起こる）。更に、ＳＡＱＵＥエージェントは、（例えば、輻輳状態に起因して）サービスクラスに関してネットワークリソースの利用不可能性を報告するリソース割り当てコントローラプロトコル／メカニズムによって作動され得る。後者の状況では、ＳＡＱＵＥエージェントは、（例えば、小規模の視聴者（オーディエンス）を有するフローを削除するといったローカルなアダプテーション決定に基づいて）どのフローが休止状態に置かれるべきであるかを検証する。両方の場合に、ＳＡＱＵＥエージェントは、休止中のフローに関する状態を除去するため、リソース割り当てコントローラプロトコル／メカニズムをトリガーし、フローに関する状態を削除するため、様々なトランスポートテクノロジーを伴うドメイン間で接続性を保持する役割を担う接続性制御プロトコル／メカニズムにシグナリングする。ＳＡＱＵＥエージェントは、セッション中のフローの個数に関する状態を更新するため、モビリティ管理プロトコル／メカニズムを更にトリガーする。その上、セッション／アプリケーションとの相互作用は、上述されているやり方と同様に行われる。

ｉｉ）ＳＡＱＵＥエージェントのロケーション：セッションのためのマルチキャスト又はユニキャスト分岐点を有するエージェントである。
・セッションセットアップ中：ＳＡＱＵＥエージェントが、休止状態に置かれるべきフローを通知する外部のセッション／アプリケーションのプロトコル／メカニズムによってトリガーされるとき（例えば、セッションオブジェクトを受信する）、ＳＡＱＵＥエージェントは、削除されるべきセッション中のフローを検証し、下流のＳＡＱＵＥエージェントへ向かう休止中のフローに関する情報を用いて状態を更新するようにリクエスタに通知するようになっている。
・セッションセットアップ後：ＳＡＱＵＥエージェントがセッション／アプリケーション又はリソース割り当てコントローラプロトコル／メカニズムによってトリガーされるとき、ＳＡＱＵＥエージェントは、下流のエージェントへ向かうどのフローが休止状態に置かれるべきであるかをチェックする。その後、ＳＡＱＵＥエージェントは、ドメイン内又はドメイン間のセッション中の休止中のフローに関する下流の状態を除去するため、リソース割り当てコントローラプロトコル／メカニズムをトリガーし、下流のエージェントへ向かうフローを解放するため、接続性制御プロトコル／メカニズムにシグナリングし、状態を更新するため、セッション／アプリケーションのプロトコル／メカニズムをトリガーし、フローが他のレシーバによって使用されているので、（もしそうであるならば、換言すると、もしフローが下流方向の別の分岐で依然として使用されているならば）上流のシグナリングメッセージを送信する必要がないことを通知する。ＳＡＱＵＥがリソース割り当てコントローラプロトコル／メカニズムによってトリガーされるならば、ＳＡＱＵＥは、休止中のフローに関する状態を更新するため、下流のエージェントにシグナリングするようなセッション／アプリケーションのプロトコル／メカニズムを更にトリガーする。

ｉｉｉ）ＳＡＱＵＥエージェントのロケーション：セッションの分岐点がなく、アクセスエージェントと、セッションの分岐点を有するエージェントとの間のパスにあるエージェントである。
・セッションセットアップ中：ＳＡＱＵＥエージェントが外部のセッション／アプリケーションのプロトコル／メカニズムによってトリガーされ、現在のエージェントによって拒絶されているフローに関する情報を受信したとき、ＳＡＱＵＥエージェントは、外部のセッション／アプリケーションのプロトコル／メカニズムにセッション中の休止中のフローに関する情報を用いてその状態を更新するようにシグナリングし、現在のエージェントによって休止状態に置かれたようなその休止中のフローに関する状態を除去するために、前の上流のエージェントにシグナリングする。
・セッションセットアップ後：ＳＡＱＵＥエージェントが（例えば、上流又は下流のシグナリングメッセージを受信することにより）セッション／アプリケーションによって、又は、リソース割り当てコントローラプロトコル／メカニズムによってトリガーされるとき、ＳＡＱＵＥエージェントは、どのフローが休止状態に置かれるべきであるかをチェックする。その後、ＳＡＱＵＥエージェントは、休止中フローの状態を除去するようにリソース割り当てコントローラプロトコル／メカニズムをトリガーし、接続性制御プロトコル／メカニズムにフローに関するその状態を削除するようにシグナリングする。最後に、ＳＡＱＵＥエージェントは、セッション／アプリケーションのプロトコル／メカニズムをトリガーし、削除されたフローに関するその状態を更新させ、セッション中の休止中フローに関する状態を更新するため下流及び／又は上流のエージェントへシグナリングメッセージを送信させる。

今度は、セッション中のフローの個数の再確立のオペレーションが、ＳＡＱＵＥエージェントの様々なロケーションｉ）からｉｉｉ）に関して説明される。

ｉ）ＳＡＱＵＥエージェントのロケーション：セッションのアクセスポイントでセッション・アダプテーションを制御する役割を担うエージェントである。
・ＳＡＱＵＥエージェントは、（例えば、上流のＳＡＱＵＥエージェントによって休止解除されたフローに関する情報を有するシグナリングメッセージの受信時に）外部のセッション／アプリケーションのプロトコル／メカニズムによって、又は、（例えば、ネットワークサービスクラスが再び利用可能になる旨に関する指示の受信時に）リソース割り当てコントローラプロトコル／メカニズムによってトリガーされ、１つ以上のセッション中のフローを追加することによりセッションを調整する。その後、ＳＡＱＵＥエージェントは、接続性制御プロトコル／メカニズムにフロー毎に配信チャンネルを制御するようにシグナリングし、セッション中の休止解除されたフローのためのネットワークリソースを要求するリソース割り当てコントローラプロトコル／メカニズムをトリガーする（例えば、ワイヤレスリンク上のネットワークリソースを予約する）。更に、ＳＡＱＵＥエージェントは、セッション／アプリケーションのプロトコル／メカニズムをトリガーし、セッション中のフローの個数に関するその状態を更新させるために、セッション並びにモビリティ管理プロトコル／メカニズムに関する情報を更新する。ＳＡＱＵＥエージェントは、プロトコル／メカニズムをトリガーし、レシーバのアプリケーションに、例えば、加入されるべき休止解除されたフローに関して又はセッションの実際の品質レベルを通知するように構成され得る。その上、ＳＡＱＵＥエージェントは、（上流のエージェントがセッションセットアップ中にフローを休止状態に置いているならば）休止解除されたフローのためのリソースをこの上流のエージェントに要求するため、セッション／アプリケーションのプロトコル／メカニズムと相互作用する。

ｉｉ）ＳＡＱＵＥエージェントのロケーション：セッションのマルチキャスト又はユニキャスト分岐点を有するエージェントである。
・ＳＡＱＵＥエージェントは、外部のセッション／アプリケーションのプロトコル／メカニズム、又は、リソース割り当てコントローラプロトコル／メカニズムによってトリガーされ、例えば、ネットワーククラスのため利用可能なリソースが存在する旨の指示を受信し次第、セッション中のフローの個数を再調整する。この情報に基づいて、ＳＡＱＵＥエージェントは、どのフローが活動状態に置かれるべきであるかを検証し、フロー毎に配信チャンネルを要求する。その後、ＳＡＱＵＥエージェントは、フローのためのネットワークリソースをリソース割り当てコントローラプロトコル／メカニズムに要求する。最後に、ＳＡＱＵＥエージェントは、（例えば、セッションの新しい分岐点を追加することにより）活動しているフローに状態を追加し、下流のエージェントにセッション中のフローのためのネットワークリソースを割り当てるようにシグナリングするために、セッション／アプリケーションをトリガーする。

ｉｉｉ）ＳＡＱＵＥエージェントのロケーション：セッションの分岐点がなく、アクセスエージェントと、セッションの分岐点を有するエージェントとの間のパスにあるエージェントである。
・ＳＡＱＵＥエージェントは、（例えば、下流又は上流のシグナリングメッセージの受信時に）セッション／アプリケーションによって、又は、リソース割り当てコントローラプロトコル／メカニズムによってトリガーされ得る。次に、ＳＡＱＵＥエージェントは、どのフローが活動状態に置かれるべきであるかをチェックする。その後、ＳＡＱＵＥエージェントは、セッション中のフローのための配信チャンネルを要求する接続性制御プロトコル／メカニズムと相互作用し、フロー毎にネットワークリソースを要求するためにリソース割り当てコントローラプロトコル／メカニズムをトリガーする。更に、ＳＡＱＵＥエージェントは、セッション／アプリケーションのプロトコル／メカニズムをトリガーし、その状態を更新させ、セッションパスに沿ってリソースを要求するやり方として上流及び／又は下流のエージェントにシグナリングする。

図６は、３個のドメインにより構成された一般的なシナリオにおいて、セッション中のフローを削除することによりセッション・アダプテーションを実行するＳＡＱＵＥメカニズムの実施例を概略的に示しており、このシナリオでは、２個のレシーバ（Ｒ１及びＲ２）が３個のフローにより構成されたセッション（Ｓ１）の全フローに関与している。Ｓ１の各フローは、ソースによって、例えば、ＭＰＥＧ−４マルチフローセッションの場合のように、その重要性に応じて定義されている。本実施形態では、以下のメカニズムが提供される。

・（セッションパスに沿ったフローの動作状態を含む）各セッション及び各フローの状態を保持するセッション制御メカニズム。更に、ＳＡＱＵＥエージェント間の同時使用は、本メカニズムによってサポートされているシグナリングメッセージを使用することにより行われる。
・セッションセットアップ中にＳＡＱＵＥエージェントに要求し、セッションオブジェクトを供給する役割を担うメカニズム。
・様々なアドレス範囲を有するドメイン間で接続性を制御する役割を担う接続性制御メカニズム。
・ドメイン内及びドメイン間における現在の帯域幅容量を含むネットワークサービスクラスに関する情報を保持するリソース割り当てコントローラメカニズム。更に、本メカニズムは、サービスクラスの帯域幅容量が再び利用可能になったときにＳＡＱＵＥエージェントに要求する役割を担う。
・モビリティ管理メカニズムの存在。

上記のメカニズムは、ネットワーク内の適切なネットワーク実施又はエンティティによって提供され、ＳＡＱＵＥエージェントによって実施されるＳＡＱＵＥメカニズムは、図３に関連して既に記載されたインタフェースを通じてこれらのメカニズムと通信し相互作用することができる。

図６に示されている実施例において、ＳＡＱＵＥエージェントは、例えば、選択されたサービスのクラスにＳ１の全フローを収容するために利用可能なネットワークリソースが存在しないという理由で、例えば、セッションセットアップ中にネットワークノードＥ内のＱｏＳマッピングメカニズムによってトリガーされる。ローカルな構成、及び、ドメインＤ３内の利用可能なネットワークリソースを含むような、リクエスタによって提供されたセッションオブジェクトに関する情報に基づいて、（本実施形態ではネットワークノードＥのモジュールである）ＳＡＱＵＥエージェントは、そのアダプテーションメカニズムを実行し、優先度の低いフロー、すなわち、Ｓ１のフロー３（Ｆ３）を削除することを決定し、削除されたフローに関する状態をデータプレーンから除去するために、Ｆ３の動作状態を更新し（休止状態に置き）、（図３に矢印によって示されているように）上流のＳＡＱＵＥエージェントにシグナリングメッセージを送信するようにセッション制御メカニズムをトリガーし、それによって、上流のネットワークリソースの浪費を回避する。

シグナリングメッセージを受信し次第、ＳＡＱＵＥエージェントは、モジュールとしてＳＡＱＵＥエージェントを含むネットワークノードＣ内でトリガーされる。ノードＣのＳＡＱＵＥエージェントは、Ｆ３のためのネットワークリソースを解放するためにリソース割り当てコントローラメカニズムと相互作用し、下流の削除されたフローに関するその状態を更新させるために、接続性制御スキームにシグナリングする。最後に、ＳＡＱＵＥエージェントは、Ｆ３の動作状態を変更するためにセッション制御メカニズムと相互作用し、また、このエージェントはセッションＳ１のための別の分岐点を有するので、（別の下流の分岐パスにおいてＦ３は依然として必要とされているため）ＳＡＱＵＥエージェントは、上流シグナリングメッセージを送信することが必要とされない旨の情報を提供する。

図７は、３個のドメインにより構成されている一般的なシナリオにおいて、セッション中のフローを追加することによりセッション・アダプテーションを実行するＳＡＱＵＥメカニズムの実施例を概略的に示しており、このシナリオでは、２個のレシーバがセッション（Ｓ１）中の全フローに関与している。図７に示されている実施形態は、ネットワークリソースが再び利用可能になったときにフローＦ３を休止解除することにより、Ｓ１の品質レベルを改善するＳＡＱＵＥメカニズムオペレーションを示している。本実施形態では、ノードＥ内で実施されているＳＡＱＵＥメカニズムは、（明示的には示されていない）リソース割り当てコントローラメカニズムによってトリガーされる。ＳＡＱＵＥエージェントとしての機能を果たすモジュールを備えるネットワークノードＥは、リソース割り当てコントローラメカニズムによって、クラスＸ（Ｓ１がマッピングされた一般的なサービスクラス）のための帯域幅容量がエージェントＥとＦとの間で再び利用可能である旨が通知される。その後、ノードＥ内に実施されているＳＡＱＵＥエージェントは、ネットワークノードＥと関連付けられているセッション制御メカニズムによって記憶されている状態をチェックし、Ｓ１のＦ３が休止中であることを検証する。次に、ＳＡＱＵＥエージェントは、（できる限りそのアダプテーションメカニズムを参照することにより）そのローカルな構成に基づいて、Ｆ３を休止解除することに決定し、配信チャンネル及びネットワークリソースをクラスＸ内のＦ３にそれぞれ割り当てるために、接続性制御メカニズム及びリソース割り当てコントローラメカニズムをトリガーする。これらのタスクが終了されたとき、リソース割り当てコントローラメカニズムは、ノードＥのＳＡＱＵＥエージェントをトリガーし、（受け入れられた、又は、拒絶された）オペレーションの状態をＳＡＱＵＥエージェントに通知し、接続性制御メカニズムは、ドメインＤ２とＤ３との間のフローのために割り当てられた配信チャンネル識別子を、ＳＡＱＵＥエージェントに通知する。この情報に基づいて、ＳＡＱＵＥエージェントは、Ｆ３に関する状態を更新するためのやり方としてセッション制御スキーマと相互作用する。その後、ＳＡＱＵＥエージェントは、ネットワークノードＣ及びＦ内のＦ３を休止解除するために、セッション制御メカニズムのシグナリングメッセージを使用する。

ノードＣ及びＦにおいて、これらのノード内で実施されているＳＡＱＵＥエージェント間の相互作用、セッション制御、接続性制御及びリソース割り当てコントローラメカニズムは、上述されているやり方と同じように行われる。しかしながら、ノードＣがそのセッションのための分岐点でありＦ３が上流のパス内で既に活動状態にあるため、ノードＣは、上流のシグナリングメッセージを送信するためにセッション制御メカニズムをトリガーしない。ノードＦに関して、ノードＦはアクセスノードであるため、ＳＡＱＵＥエージェントは、モビリティ管理をトリガーし、Ｆ３に関するその状態をアクティブ化し、ＳＩＰは、（必要に応じて）マルチキャストドメインＤ３内でＦ３のため使用される配信チャンネルをレシーバのアプリケーションに通知するためにトリガーされ得る。このように、アプリケーションは、インターネット・グループ・マネージメント・プロトコル（ＩＧＭＰｖ３、ＲＦＣ３３７６を参照）又はマルチキャスト・リスナ・ディスカバリ・プロトコル（ＭＬＤｖ２、ＲＦＣ３８１０を参照）を使用することにより正しいマルチキャストチャンネルに加入することができる。

上記の実施形態では、ＳＡＱＵＥエージェントは、それぞれのネットワークノードのモジュールとして実施されている。しかしながら、ＳＡＱＵＥメカニズムは、ＳＡＱＵＥエージェントが、例えば、図６及び７のドメインＤ１に示されているように、セッションが通過するネットワークノードとは独立した別個のエンティティであっても同様に動作し得る。このような場合、ＳＡＱＵＥエージェントは複数のネットワークノードを担当し、それゆえに、担当しているセッションにフローを追加し、又は、担当しているセッションからフローを削除し得る。ＳＡＱＵＥエージェント間のシグナリングは、セッション／アプリケーションプロトコル又はメカニズムを使用することにより、又は、ＳＡＱＵＥエージェント間の専用メッセージを使用することにより、上述されているやり方と同様に実行され得る。

上述されている実施形態は、ハードウェアによって、ソフトウェアによって、又は、ソフトウェアとハードウェアとの組み合わせによって実施されることが当業者によって理解されるであろう。本発明の実施形態と共に記載されているモジュール及び機能は、全体として又は部分的に、本発明の実施形態と共に説明される方法に従って動作するように適切にプログラムされているマイクロプロセッサ又はコンピュータによって実施される。本発明の実施形態を実施する装置は、本発明の実施形態に記載されているようなセッション・アダプテーションを実行する能力を備えるように適切にプログラムされている、例えば、ネットワーク内のノード又はエレメントを備え得る。

本発明の実施形態によれば、データキャリアに記憶されているか、又は、記録媒体若しくは伝送リンクのような物理的な手段によって具現化された何か他の方法で記憶され、コンピュータ上で実行されたときに、コンピュータを上述されている本発明の実施形態に従って動作させることができるコンピュータプログラムが提供される。

本発明の実施形態は、上述されているようなセッション・アダプテーション・マッピング・メカニズムに従って動作するようにプログラムされている、例えば、ネットワーク内のノード又はネットワーク内のエンティティによって実施され得る。

本発明の実施形態が使用される通信環境を概略的に示している。 本発明の実施形態を実施するネットワーク環境を概略的に示している。 本発明の実施形態によるアダプテーションエージェントの構成を概略的に示している。 本発明の実施形態の動作を概略的に示すフローチャートを示している。 本発明の更なる実施形態のオペレーションを概略的に示すフローチャートを示している。 本発明の更なる実施形態を実施するネットワーク環境を概略的に示している。 本発明の更なる実施形態を実施するネットワーク環境を概略的に示している。

Claims (17)

1. ネットワークを介して或るソースと或るレシーバとの間でセッションを適合させるための方法であって、ここで、前記ソースから発信されている前記セッションが、前記セッションを一体的に形成するような複数のフローから構成されており、前記レシーバが、前記セッションのフローの全部又は一部を受信するものであり、前記セッションが、前記ソースから前記レシーバまで複数のネットワークノードを通過しており、複数のアダプテーションエージェントが、前記ネットワークに設けられており、各アダプテーションエージェントが、前記セッションにフローを追加するか又は前記セッションからフローを削除することによりアダプテーションメカニズムを実行する能力を備えるものであり、各アダプテーションエージェントが、前記ソースから前記レシーバまでの前記経路に沿って１個以上のネットワークノードを担当するものであり、
   前記アダプテーションエージェントの１つによってネットワーク使用量を表すネットワークパラメータを受信するステップと、
   前記セッションを前記ネットワーク使用量に適合させるやり方を前記アダプテーションエージェントによって決定する決定メカニズムを実行するステップと、
   前記セッションに１個以上のフローを追加するか又は前記セッションから１個以上のフローを削除するステップと、
   前記追加された又は削除されたフローに応じて、ネットワークリソースを割り当てるか又は解放することを、前記ネットワークに設けられたリソース割り当てメカニズムに通知するステップと、
   上流及び／又は下流のアダプテーションエージェントに新しいセッションの構成について通知するステップと
   を含む方法。
2. 前記フローを追加もしくは削除するステップに代わって、又は、前記フローを追加もしくは削除するステップに付加して、前記決定メカニズムが、現在のサービスクラス以外の異なるサービスクラスに前記セッション中の１個以上のフローを再割り当てすることを決定し、
   前記リソース割り当てメカニズムに代わって、サービス品質マッピングメカニズムが前記決定メカニズムの決定に関して通知される、請求項１に記載の方法。
3. 前記フローを追加もしくは削除するステップに代わって、又は、前記フローを追加もしくは削除するステップに付加して、前記決定メカニズムが、サービスのクラスに関してリソースを再調整することを前記リソース割り当てメカニズムに要求することを決定するようになっている、請求項１又は２に記載の方法。
4. 前記フローのそれぞれには優先度が割り当てられ、前記決定メカニズムが、前記フローの前記優先度に基づいて前記フローの追加又は削除を決定するようになっている、請求項１ないし３のいずれか一項に記載の方法。
5. 前記ネットワーク使用量の情報が、十分なネットワークリソースが利用可能であるかどうかに関する情報を含んでおり、
   前記ネットワークリソースが十分になければ、前記決定メカニズムが１個以上のフローを削除することを決定し、
   前記ネットワークリソースが十分にあれば、前記決定メカニズムが１個以上のフローを追加することを決定するようになっている、請求項１ないし４のいずれか一項に記載の方法。
6. 前記セッション中の前記フローが活動中であるか又は休止中であるかを表すために前記セッションの前記フローの状態を保持するステップを含んでおり、
   フローをセッションに追加することは、そのフローを活動状態に置くことに対応しており、
   フローをセッションから削除することは、そのフローを休止状態に置くことに対応しており、
   前記状態の各々が、可逆的である、請求項１から５の一項に記載の方法。
7. 複数のセッションが存在しており、前記決定メカニズムが、前記複数のセッションの中で適合させられるべき１個以上のセッションを選択することを備えており、
   該選択は、
   アダプテーションのために最低オーディエンスサイズを有するセッションを選択することと、
   アダプテーションのために最低コストを有するセッションを選択することと、
   アダプテーションのためにオーディオセッションよりビデオセッションを優先して選択することと
   のうちの１つ以上の規準に基づいている、請求項１ないし６のいずれか一項に記載の方法。
8. 別のアダプテーションエージェントから新しいセッションの構成に関する情報を受信するアダプテーションエージェントは、前記レシーバから前記ソースまでの前記セッションの前記経路における前記アダプテーションエージェントのロケーションと、前記アダプテーションエージェントが前記セッションのための分岐点を有するかどうかとに基づいて、前記フローを追加又は削除するかどうか、及び、前記新しいセッションの構成に関する情報が更に上流又は下流へ転送されるべきであるかどうかを決定するようになっている、請求項１ないし７のいずれか一項に記載の方法。
9. ネットワークを介して或るソースと或るレシーバとの間でセッションを適合させるためのエージェントであって、前記ソースから発信されている前記セッションが、前記セッションを一体的に形成するような複数のフローから構成されており、前記セッションが、前記ソースから前記レシーバまで複数のネットワークノードを通過しており、当該エージェントが、前記ネットワークに設けられた複数のアダプテーションエージェントのうちの１つのエージェントであり、各アダプテーションエージェントが、前記セッションにフローを追加するか又は前記セッションからフローを削除することによりアダプテーションメカニズムを実行する能力を備えるものであり、各アダプテーションエージェントが、前記ソースから前記レシーバまでの前記経路に沿って１個以上のネットワークノードを担当するものであり、
   前記アダプテーションエージェントが、
   ネットワーク使用量を表すネットワークパラメータを受信するインタフェースと、
   前記セッションを前記ネットワーク使用量に適合させるやり方を決定する決定モジュールと、
   前記セッションに１個以上のフローを追加するか又は前記セッションから１個以上のフローを削除する追加／削除モジュールと、
   前記追加された又は削除されたフローに応じて、ネットワークリソースを割り当てるか又は解放することを、前記ネットワークに設けられたリソース割り当てメカニズムに通知するリソース情報モジュールと、
   上流及び／又は下流のアダプテーションエージェントに新しいセッションの構成を通知する上流／下流情報モジュールと
   を備えるものである、エージェント。
10. 前記フローの追加もしくは削除に代わって、又は、前記フローの追加もしくは削除に付加して、前記決定モジュールが、前記セッション中の１個以上のフローを現在のサービスクラス以外の異なるサービスクラスへ再割り当てすることを決定するものであり、
    前記リソース割り当てメカニズムの代わりに、サービス品質マッピングメカニズムに前記決定モジュールの決定に関して通知されるようになっている、請求項９に記載のエージェント。
11. 前記フローの追加もしくは削除に代わって、又は、前記フローの追加もしくは削除に付加して、前記決定モジュールが、サービスのクラスに関してリソースを再調整することを前記リソース割り当てメカニズムに要求することを決定するようになっている、請求項９又は１０に記載のエージェント。
12. 各フローには優先度が割り当てられ、前記決定メカニズムが、前記フローの前記優先度に基づいて前記フローの追加又は削除を決定するようになっている、請求項９ないし１１のいずれか一項に記載のエージェント。
13. 前記ネットワーク使用量の情報が、十分なネットワークリソースが利用可能であるかどうかに関する情報を含んでおり、
    前記ネットワークリソースが十分になければ、前記決定モジュールが、１個以上のフローを削除することを決定するようになっており、
    前記ネットワークリソースが十分にあれば、前記決定モジュールが、１個以上のフローを追加することを決定するようになっている、請求項９ないし１２のいずれか一項に記載のエージェント。
14. 前記セッション中のフローが活動中であるか又は休止中であるかを表すために前記セッション中のフローの状態を保持する保持モジュールを備えており、
    フローをセッションに追加することは、そのフローを活動状態に置くことに対応しており、
    フローをセッションから削除することは、そのフローを休止状態に置くことに対応しており、
    前記状態の各々が、可逆的である、請求項９ないし１３のいずれか一項に記載のエージェント。
15. 複数のセッションが存在しており、前記決定モジュールが、前記複数のセッションの中で適合させられるべき１個以上のセッションを選択するようになっており、
    前記選択が、
    アダプテーションのために最低オーディエンスサイズを有するセッションを選択することと、
    アダプテーションのために最低コストを有するセッションを選択することと、
    アダプテーションのためにオーディオセッションよりビデオセッションを優先して選択することと
    のうちの１つ以上の規準に基づいている、請求項９ないし１４のいずれか一項に記載のエージェント。
16. 前記決定モジュールは、前記レシーバから前記ソースまでの前記セッションの前記経路における前記アダプテーションエージェントのロケーションと、前記アダプテーションエージェントが前記セッションのための分岐点を有するかどうかとに基づいて、前記フローを追加又は削除するかどうか、及び、前記アダプテーションエージェントが別のアダプテーションエージェントから新しいセッションの構成に関する情報を受信した場合にこの情報が更に上流又は下流へ転送されるべきであるかどうかを決定するようになっている、請求項９ないし１５のいずれか一項に記載のエージェント。
17. 請求項１から８のうちの一項に記載の方法をコンピュータに実行させるようなコンピュータ実行可能なコードを備えているコンピュータプログラム。

Images