JP5139595B2

JP5139595B2 - 関連するサービスレベルを提供するための方法及び装置

Info

Publication number: JP5139595B2
Application number: JP2012501957A
Authority: JP
Inventors: マティアスリドストレム，; イヴァルス，イグナチオマス
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2009-03-27
Filing date: 2009-03-27
Publication date: 2013-02-06
Anticipated expiration: 2029-03-27
Also published as: WO2010110710A1; EP2412139B1; KR101528389B1; KR20120028857A; BRPI0924637A2; JP2012522419A; CN102365850B; US20120030365A1; EP2412139A1; CN102365850A; US9277029B2; US20160173581A1

Description

本発明は一般に、ルータ内の通信リソースの制御によって、ピアツーピアセッション中に、関連するサービスレベルを加入者のために提供して、加入者の品質に対する期待度を満すことができるようにする方法及び装置に関する。

ＩＰ（インターネットプロトコル）を用いるパケットベースの通信を行うために種々のマルチメディアサービスが開発されたが、このマルチメディアサービスは、一般に、固定又は携帯用コンピュータと、電話のようなユーザ端末との間での異なるフォーマット及び組み合わされた形のメディアの送信を含むものとなる。また、異なるアクセスネットワークと接続されたユーザ端末用のこのようなマルチメディアサービス及びセッションを可能にするために、「ＩＰマルチメディアサブシステム」（ＩＭＳ）と呼ばれるアーキテクチャも開発されてきた。

マルチメディアセッションは、一般に、セッションのセットアップのためのシグナリングプロトコル「ＳＩＰ」（セッション開始プロトコル）を用いて、ＩＭＳネットワーク内の特定のセッション制御ノードにより処理される。例えば、端末は、マルチメディアアプリケーションが端末において呼び出されたときなどに、別の端末又はサーバとのセッションを開始するために「ＳＩＰＩＮＶＩＴＥ」と呼ばれるメッセージを送信することができる。ＳＩＰＩＮＶＩＴＥメッセージは、セッションを確立するために、ＩＭＳネットワーク及びアクセスネットワークにおいて異なるアクションをトリガし、使用されるアクセスネットワーク内に適切なリソースの予約を含むものである。

ＳＩＰにおいて、「ＳＤＰ」（セッション記述プロトコル）と呼ばれる追加プロトコルがマルチメディアセッションの種々のパラメータを指定するために使用されると共に、ＳＤＰメッセージが一般に、自己完結したボディとしてＳＩＰメッセージの内部に組み込まれている。複数のＳＤＰメッセージを用いて、端末能力及びメディアの属性に関する情報が提供されるが、この情報提供は、当業において周知のマルチメディアセッションのためのセッションパラメータの指定と、該セッションパラメータの交渉とを行うために実行される。これらのセッションパラメータは端末能力、メディアの属性及びセッションの確立に必要なアドレス情報を含んでもよい。上述のＳＩＰＩＮＶＩＴＥメッセージ及び通常の応答メッセージ「ＳＩＰ２００ＯＫ」には、一般に、セッションを求めて送信者により提案されるセッションパラメータと共に、組込み型ＳＤＰメッセージが含まれる。

また、使用されるアクセスネットワークに関連付けられたポリシーノードも一般にＩＭＳネットワークと接続される。とりわけ、このポリシーノードは、種々の所定のポリシ及び会員登録プロファイルに基づいて、セッション用ネットワークリソースの予約を制御する。特に、アクセスネットワークにおける上記のリソース予約のための、様々のサービスと加入者の少なくともいずれかに対する種々のＱｏＳ（サービス品質）要件を、例えば、上記のＳＤＰ交渉に基づいてポリシーノードにより実施することができる。ＩＭＳネットワークにより制御されるマルチメディアセッションにおいて、上記ポリシーノードが上述したようなネットワークリソースの予約を制御する場合、参加しているパーティのために所望の又は予期されるＱｏＳを取得することが可能となる。

従って、加入者のために通信セッションを確立する際、種々のネットワークリソースが予約され、それによって、容認可能で、かつ、予期されるサービスレベルが、データビットレート及び待ち時間等に関して加入者のために維持されるようになることが望ましい。従って、ＩＭＳにより制御されるセッションのセットアップ中にネットワークリソースを予約するとき、任意のＱＯＳ要件を考慮に入れることが可能となる。

しかし、中間セッション制御ノード又はポリシーノードを何ら含まない、単に参加パーティにより開始され、かつ、制御されるセッション（一般にピアツーピアセッションと呼ばれる）は、上記の方法で特定のＱｏＳを取得することはできない。ルータ固有のメカニズム及びポリシを個々に有する種々のルータを介してインターネット等のＩＰネットワークを経由して、異なるデータフローを制御するために、パーティ間で送信される任意のデータがデータパケットとしてルート指定される。通信を行うパーティのＱＯＳ要件がルータにおいて考慮されることを保証するための標準化された又は一貫性のあるメカニズムは今日存在しない。図１に、ＩＰネットワーク１００内のルータＲを介する２つのユーザ端末ＡとＢ間のピアツーピアセッション用の典型的シナリオが示されている。端末ＡがアクセスルータＲＡと接続され、端末Ｂが別のアクセスルータＲＢと接続される。ネットワーク１００における複数の中間ルータＲを介する送信パスは、セッション中に、異なるデータパケットに対応して変動することができる。このことは当業において公知である。

今日、差別化されたサービス及び会員登録がＩＭＳネットワークの加入に対して普通に提供され、これによって、加入者は、当該サービスに対するＱＯＳ要件を一般に指示する様々なタイプの申し込みを含むサービスを消費することができるようになっている。従って、例えば異なる申し込みタイプに関連し、かつ、個々のサービスにも関連するＱｏＳに関する特定のサービスレベルが加入者に提供され得ることになる。例えば、「プラチナ」会員登録という普通の用語を用いることによって、相対的に高い保証が与えられるＱｏＳ又はサービスレベルの提供が可能となるのに対して、「ゴールド」、「シルバー」及び「ブロンズ」会員登録ではこの順に低いサービスレベルが提供されることになる。

さらに、例えば異なる価格で様々のサービスレベルの特定のサービスの提供を行うことも可能である。会員登録、サービス及び品質／サービスレベルのこの差別化はますます顕著になり、従って顧客の満足度及び期待度に大いに影響を与えることになる。例えば、ブロンズレベルの加入者が或るサービスレベルを得ることで満足すると考えられるのに対して、プラチナレベルの加入者の場合さらに高いサービスレベルを予期して、満足しないこともあり得る。

しかし、上述したようなピアツーピアセッションに対して上記のようなサービスレベルが保証されることはあり得ない。さらに、ピアツーピアセッションの開始のためにＳＩＰを使用するとき、異なる通信事業者のネットワーク間においてサービスレベルの固有の定義を有する可能性があるサービスレベル要件をマップする方法は存在しない。例えば、様々のサービスレベルを表すブロンズ、シルバー、ゴールド及びプラチナという普通に使用される用語は、品質関連セッションパラメータに関しては、異なる通信事業者のネットワークでは、異なる言外の意味を持つ可能性がある。さらに、これらのセッションは、適切に機能するＳＤＰ交渉を達成するために、同じ品質関連セッションパラメータの両方向の使用に関して左右対称となる必要がある。従って、インターネットのような中央管理されていないＩＰネットワークでは、ピアツーピアセッションに対する所望の、かつ、関連するサービスレベルを、ルータを介して正常に達成できないという問題がある。

以上略述した問題を解決することが本発明の目的である。特に、ピアツーピアセッションに関与する場合にも、関連する又は正当化されたサービスレベル又はＱｏＳを含む通信サービスを加入者が消費できるようにすることが本発明の目的である。下記に添付された独立請求項に従う方法及び装置の提供によってこれらの目的及び他の目的の達成が可能となる。

１つの側面によれば、本発明は、第２の加入者とのピアツーピアセッション状態にある第１の加入者に対して、関連するサービスレベルを提供するためのＩＰネットワークのルータにおける方法に関わる。本方法では、第１の加入者から送信されたセッションセットアップメッセージが受信されると、第１の加入者の所要のサービスレベルが、セッションセットアップメッセージ内に含まれているサービスレベル指標から検出される。次いで、第１の加入者の通信事業者のサービスレベルの定義が取得されると共に、第１の加入者の検出済みサービスレベルに従って、第２の加入者から第１の加入者へのデータ送信用ルータにおいて要求される通信リソースがサービスレベル定義による解釈として決定される。次いで、この決定済み通信リソースはルータ内に予約され、かつ、セッションセットアップメッセージが次のホップノードへ転送される。

別の側面によれば、本発明は、上記の方法に従って関連するサービスレベルを提供するための、ＩＰネットワークのルータ内の機器に関わる。このルータ機器は第１の加入者から送信されるセッションセットアップメッセージを受信し、次いで、セッションセットアップメッセージ内に含まれているサービスレベル指標から第１の加入者の所要のサービスレベルを検出するように適合された受信ユニットを備える。また、上記機器は、第１の加入者の通信事業者のサービスレベル定義を取得するように適合された取得ユニットと、第２の加入者から第１の加入者へのデータ送信用ルータにおいて、所要の通信リソースをサービスレベル定義によって解釈されるような検出済みサービスレベルに従って決定するように適合されたリソースマネージャとを備える。このリソースマネージャは通信リソースをルータ内に予約するようにさらに適合される。また、上記機器はセッションセットアップメッセージを次のホップノードへ転送するように適合された転送ユニットを備える。

ルータ内における本発明の方法及び機器は、以下のオプションの実施形態のうちの任意の実施形態に従って実装することも可能である。

１つの実施形態では、上記リソースマネージャは、セッションセットアップメッセージをルータへ転送した最後のホップノードをルータ内に記録するようにさらに適合される。このリソースマネージャは、反対方向に送信される任意のセッション関連メッセージ及びデータパケットが、セッションセットアップメッセージと同じパスを介してルート指定されることを保証するためにさらに利用される。上記セッションセットアップメッセージは前回のＳＤＰ交渉からマップされた複数のパラメータを含んでもよい。

更なる実施形態では、第１の加入者からのセッションセットアップメッセージはリソース予約メッセージであってもよく、かつ、リソースマネージャは、第２の加入者から送信された予約確認メッセージの受信時に予約済み通信リソースをルータ内に予約するようにさらに適合されてもよい。上記リソース予約メッセージはＰＡＴＨメッセージであってもよく、かつ、予約確認メッセージはＲＥＳＶメッセージであってもよい。

上記取得ユニットは、受信したセッションセットアップメッセージ内のＵＲＩに基づいて、第１の加入者の通信事業者のＱｏＳ制御サーバからサービスレベル定義をフェッチするようにさらに適合されてもよい。このサービスレベル定義は、ＱｏＳ制御サーバに保持されているＸＭＬドキュメント内に指定されてもよい。上記取得ユニットは、ルータ内のローカルストレージからサービスレベル定義を取り出すようにさらに適合されてもよい。

また、別の側面によれば、本発明は、第２の加入者とのピアツーピアセッション時に、関連するサービスレベルを取得するためのユーザ端末内の機器に関わる。この端末装置は、第１の加入者の通信事業者のＱｏＳ制御サーバが保持しているサービスレベル定義を参照するＵＲＩを取得するように適合された取得ユニットを備える。上記端末装置は、１以上のルータを備えた送信パスを介してセッションセットアップメッセージを第２の加入者へ送信するように適合された送信ユニットであって、上記セッションセットアップメッセージには、ＵＲＩと、第１の加入者の所要のサービスレベルを参照するサービスレベル指標とを含む。

以下の詳細な説明において、本発明の更なる特徴および利点について説明する。

好ましい実施形態によって、及び、添付図面を参照して、以下さらに詳細に本発明について説明する。

ＩＰネットワーク内のルータＲを介してユーザ端末ＡとＢとの間におけるピアツーピアセッションに関連する典型的シナリオを示す。別の実施形態に係る、加入者Ｂとのピアツーピアセッション状態にある加入者Ａのために、関連するサービスレベルを提供する手順を示す概略ブロック図である。ＰＡＴＨメッセージが転送されるとき、加入者ＡとＢとの間の送信パスの個々のルータ内において最後のホップノードを記録する方法を示す、別の実施形態に係る概略ブロック図である。加入者ＡとＢとの間の送信パス内のルータにおいて、関連するサービスレベルを提供するための手順を示す、さらに別の実施形態に係るフローチャートである。別の実施形態に係るユーザ端末５００及びルータ５０２内の装置をさらに詳細に示す概略ブロック図である。

本発明は、ＩＰネットワークの送信パス内のルータを介する加入者間におけるピアツーピアセッションを可能にするものであり、このピアツーピアセッションにおいて、加入者により予期されるか、要求される様々なサービスレベルに従って、通信リソースを非対称にルータ内に予約することが可能となる。このピアツーピアセッションによって、個々の参加する加入者は、受信側加入者に関連するような予想されるサービスレベルに従って、相手側加入者からデータ又はメディアをセッション中に受け取ることが可能となる。

簡潔にいえば、上記所要のサービスレベルは、セッションセットアップ手順中に加入者間で交換されるＳＤＰメッセージを含むようなセッションセットアップメッセージの形で示される。これによって、セッションの送信パス内の個々のルータは、加入者が送信したセッションセットアップメッセージの中にサービスレベルの指示を検出し、かつ、当該加入者のために受信方向に通信リソースを適宜ルータ内に予約することができる。従って、以下に説明する方法で、サービスレベル指示を提供するための正規のＳＤＰメッセージや別のセッションセットアップメッセージの利用が可能となる。

セッションセットアップメッセージの形で表されるサービスレベル指示は、異なる通信事業者が作成した定義による解釈が可能となる。１つの実施形態では、通信事業者のサービスレベル定義が事前にルータ内に記憶又はキャッシュされる。別の実施形態では、送信側加入者がセッションセットアップメッセージの中に含めているＵＲＩ（ユニバーサルリソース識別子）を用いて、上記通信事業者のサービスレベル定義は当該通信事業者のＱｏＳ制御サーバからフェッチされる。実際には、加入者は、相手側加入者へ向けて送信されるセッションセットアップメッセージの形のサービスレベル指示と共に常時ＵＲＩを含むことが望ましい。これによって、ルータが必要に応じてＱｏＳ制御サーバからサービスレベル定義をフェッチすることが可能となる。次いで、上記セッションセットアップメッセージは送信パス内のルータを介して送信されて、個々のルータがサービスレベル指示、及び、必要に応じてＵＲＩも読み出すと共に、かつ、通信リソースを適宜予約できるようになる。

以下の実施形態例において、並びに、この説明を通じてずっと、「加入者」という用語は、一般に、エンドユーザ、及び、本願に記載の方法で（例えばユーザ端末内に実装されているＵＡ（ユーザエージェント）等によって）サービスの確立と実行とを行う際に使用される、エンドユーザの通信機器を表す。加入者の通信機器は、無線電話機又は固定電話機、コンピュータ、サーバ、ゲームユニット又はＩＰＴＶクライアント、セットトップボックス等のようなテレビ機器であってもよい。本発明は加入者の任意の特定の通信機器に限定されるわけではない。さらに、「関連する」サービスレベルという用語は、サービスレベルの指示、並びに、当該サービスレベルの通信事業者の定義によって効率よく決定されるサービスレベルが加入者に対して正当化される／保証されることを意味する。

図２に示される通信シナリオをまず参照しながら、加入者Ｂとのピアツーピアセッションの形で、関連するサービスレベルを加入者Ａのために提供する手順について次に説明する。説明を簡略にするために、本図は、ＡとＢとの間の送信パス内のどこかに位置する単に１つの例示のルータ２００内において実行されるものとしての手順を示すものである。但し、図示の手順は、基本的に、送信パス内の他の任意のルータにおいても同様に実行される。本図ではＱｏＳはサービスレベルを表す同意語として使用される。加入者ＡとＢとが様々のサービスレベルを有し、従ってサービスレベルに関して非対称セッションを必要とすることがさらに仮定されている。加入者Ａが相対的に高いサービスレベルを予期するプラチナ加入者である可能性もあるのに対して、加入者Ｂが相対的に低いサービスレベルを予期するブロンズレベルの加入者である可能性もある。

第１のステップ２：１は、ある時点における加入者Ａによって、適用可能なサービスレベルの定義が記憶されているＱｏＳ制御サーバ２０２につながるＵＲＩが取得されることを概略的に示すステップであり、この定義は、加入者Ａにサービスを提供しているネットワーク通信事業者により決定され、確立される。例えば、加入者Ａの端末の電源がオンにされ、次いでアクセスネットワークに登録されると、通信事業者のネットワークからＵＲＩを取得することが可能となる。また、実装構成に応じて事前に端末内にＵＲＩを構成することも可能である。

以下の更なるステップを実行する前に、メディア用コーデックのような、両方のパーティが使用する種々のセッションパラメータの確立のための、ＡとＢ間におけるＳＤＰメッセージの交換を含む、ピアツーピア通信のための加入者ＡとＢ間の定期的なＳＤＰ交渉を事前に行うことが想定されている。次のステップ２：２において、加入者Ａは、加入者Ａのための、関連する、かつ、所要のサービスレベルを示すサービスレベル指標を含むセッションセットアップメッセージを送信する。このセッションセットアップメッセージは、該メッセージがパス内の１以上の前回のルータの中を通過した後等にサービスレベルルータ２００により受信される。図示のルータ２００は実際にはＡとＢとの間の送信パス内の任意のルータであってもよい。

従って、加入者Ａは、前回のＳＤＰ交渉において同意されているように、ステップ２：２において送信されたセッションセットアップメッセージの中へＡの所要のサービスレベルをマップした。本例では、このセッションセットアップメッセージは、上記サービスレベル指標を運ぶために利用できる「ＰＡＴＨ」と呼ばれるリソース予約メッセージである。但し、本発明は、一般にこの特定のセッションセットアップメッセージに限定されるわけではない。また、ＰＡＴＨメッセージは、通信事業者のサービスレベル定義を指示する上述のＵＲＩもＱｏＳ制御サーバ２０２の中に含む。例示の修正済みＰＡＴＨメッセージについては後程さらに詳細に説明する。

次のステップ２：３において、ルータ２００は、受信済みＵＲＩを利用して、ＱｏＳ制御サーバ２０２から上記サービスレベル定義をフェッチする。これは上記受信済みサービスレベル指標の重要性を判定するためである。上記とは別に、上記サービスレベル定義がルータ内のローカルストレージに以前に記憶又はキャッシュされた場合、ルータ２００は、該ルータ内のローカルストレージから上記サービスレベル定義を取り出すことも可能である。従って、ルータ２００は、Ｂからメディアを受信するとき、どのようなサービス品質が予期され、加入者Ａのために保証されているかの判定が可能となると共に、この判定によって、関連するサービスレベルを満たすためにどのような通信リソースをルータにおいて使用する必要があるかの判定を行うことも可能となる。したがって、次のステップ２：４において、受信した指標と、フェッチした定義とに基づいて、Ａのための受信方向（すなわちＢからＡへ向う方向）のデータ又はメディアの通信に必要な通信リソースが決定され、次いで、ルータ２００において適宜予約又は準備が行われる。

さらに、ルータ２００は、次のステップ２：５において、最後のホップノード（すなわち、反対方向の任意のメッセージ又はデータが、ルータ２００と同様の予約又は準備されたリソースを有するルータを備えた同じパスを辿ることができるように、メッセージをルータ２００へ転送した前回のルータ（図示せず）のＩＰアドレスのような適切な識別子）も記録する。ルータ２００がパス内の第１のノードであれば、記録すべき最後のホップノードは加入者Ａとなる。次いで、ＰＡＴＨメッセージは、ステップ２：６において概略的に示されているように、加入者Ｂへ向けてパス内の次のホップノード（図示せず）へ転送される。

加入者Ｂが最終的にＰＡＴＨメッセージを受信したとき、Ｂの送信方向のサービスレベルと、ＢからＡへのパスに沿ったルータ内の予約済みリソースとを確認するために、ステップ２：７において応答セッションセットアップメッセージが送信パスを介して加入者Ｂから送信される。ここで注目すべき点として、ステップ２：２より前に行われた前回のＳＤＰ交渉によって、加入者ＢがＢの送信指示のサービスレベルに事前に同意しているという点が挙げられる。このサービスレベルもＡからＰＡＴＨメッセージの中へマップされたものであった。また、オプションとして、加入者Ｂの端末は、ＰＡＴＨメッセージ内の指標及びＵＲＩに基づいて（すなわち基本的にステップ２：４において上記ルータが行った方法と同じ方法で）、Ａの実際のサービスレベルを決定することも可能である。応答セッションセットアップメッセージは、個々のルータ内における最後のホップノードの記録のお蔭で、Ａからの最初のセッションセットアップメッセージと同じルータを介して、逆方向に加入者Ｂから送信されることになる。

本例では、応答セッションセットアップメッセージは「ＲＥＳＶ」と呼ばれるリソース確認メッセージである。但し、本発明は一般に上記特定の応答セッションセットアップメッセージに限定されるわけではない。上記で使用した例示のリソース予約メッセージＰＡＴＨ及びＲＥＳＶは、セッション用としてＱｏＳを確立するために広く使用されているプロトコルＲＶＳＰ（リソース予約プロトコル）に基づいて構成される。

次のステップ２：８において、Ｂから送信されるＲＥＳＶメッセージの受信時に、ルータ２００は、ＢからＡへの方向に通信を行うために予約されかつ準備されたリソースを予約し、次いで、図示の最後のステップ２：９において、ＲＥＳＶメッセージを逆方向にＡへ向けて次のホップノード（すなわちルータ２００に事前に記録された最後のホップノード）へ転送する。このようにして、ＲＥＳＶメッセージがルータパスを経由して送信されると、パスに沿って個々のルータ内に予約され、かつ、準備されたリソースが、セッション用として確認され、かつ、予約される。この確認と予約とによって、関連するサービスレベルを用いてメディアの通信をすべてのルータ内で行うことが保証される。最終的に、ＲＥＳＶメッセージは加入者Ａに着信し、パス内において行われたリソース予約が確認されることになる。

加入者Ａは関連するサービスレベルと共にＢからメディアを受信することができる。また、ルータ内にリソース予約を行う上述の手順を実行することも可能であり、この手順の実行によって、ＡからＢへの反対方向に送信パスのセットアップと、加入者Ｂのための関連するサービスレベルの提供が可能となる。従って、加入者Ｂは、Ｂのための有効なサービスレベル指標と、サービスレベル定義を指示するＵＲＩとを含むＰＡＴＨメッセージを、基本的に加入者Ａが行ったのと同じ方法で、加入者Ｂにサービスを提供している通信事業者のＱｏＳ制御サーバ２０４において送信することによって、別のリソース予約手順を開始することになる。

次いで、破線の両方向の矢印により示されるように、ルータ２００と、上記パスに沿う別のルータとは、加入者Ｂのための有効な通信事業者のサービスレベル定義であって、Ａのために上述したような方法でＵＲＩを利用するサービスレベル定義をＱｏＳ制御サーバ２０４からフェッチすることが可能となる。次いで、Ｂの受信方向（すなわちＡからＢへ向う方向）に対応して個々のルータにおいて必要なこれらの通信リソースを適宜決定し、かつ、予約することが可能である。本例では、加入者Ａ及びＢは異なる通信事業者によりサービスを受ける。但し、加入者Ａ及びＢは同じ通信事業者及び同じＱｏＳ制御サーバによってサービスを受けることも可能である。

必要な通信リソースが両方向用の送信パスに沿って（すなわち基本的にステップ２：２−２：９に従って）すべてのルータ内に予約された後、加入者ＡとＢとの間で非対称セッションを実行することができる。プラチナレベルの加入者であるＡとブロンズレベルの加入者であるＢのケースでは、プラチナレベルの関連するサービスレベルはＡの受信方向用として提供され、かつ、ブロンズレベルの関連するサービスレベルはＢの受信方向用として提供される。

上記の例では、ＳＤＰ交渉に基づく、所要ルータリソースの予約、準備及び予約のために使用される上記セッションセットアップメッセージは、例えばＲＳＶＰプロトコル又はＭＰＬＳプロトコルに従うＰＡＴＨ及びＲＥＳＶメッセージであった。しかし、本発明はこれら特定のメッセージに限定されるわけではなく、別の同様のセッションセットアップメッセージを用いて、例えばプロトコルＧ−ＭＰＬＳＤｉｆｆｓｅｒｖ、Ｉｎｔｓｅｒｖ等に従う同意されたＳＤＰ交渉パラメータをマップすることも可能である。

図３は、Ａからのセッションセットアップメッセージ（このケースではＰＡＴＨメッセージ）がルータを介して送信されるとき、加入者ＡとＢとの間の送信パスの個々のルータ３００が最後のホップノードを記録する（３０２）方法の一例を示す図である。従って、ＰＡＴＨメッセージをＡから直接受信する第１のルータＲ_１が最後のホップノードとして加入者Ａを記録する。同様に、ルータＲ_２はＲ_１を記録し、ルータＲ_３はＲ_２を記録し、ルータＲ_４はＲ_３を記録し、そして、ルータＲ_５はＲ_４をそれぞれの最後のホップノードとして記録する。ルータＲ_２がＡを記録する必要はない場合もある。というのは、Ａへ向けられたデータパケットが個々のパケット内のＡの宛先アドレスに基づいて最終ホップ時にＡへ転送されることになるからである。

これによって、Ｂからの応答セッションセットアップメッセージ（本ケースではＲＥＳＶメッセージ）を、同じルータを介して逆方向にＡへ送信することが可能となる。また、セッション中のＢからＡへの任意の更なるデータパケットが、記録済みの最後のホップノードに基づいて同じパスを進むことになる。上記手順は、対応する方法でＡからＢへ向う反対方向に、来るべきデータパケットに対して実行することも可能である。

上述のセッションセットアップメッセージと、ＰＡＴＨ及びＲＥＳＶメッセージ等の応答セッションセットアップメッセージとの中へマップするパラメータによってＳＤＰ交渉メッセージを構成することが可能な方法を示す更なる詳細例について次に説明する。この場合もまた、プラチナユーザである加入者Ａがブロンズユーザである加入者Ｂとのセッションを開始することが想定されている。Ａからの例示のセッションセットアップメッセージは以下のような特別のＳＩＰヘッダを有するＳＩＰＩＮＶＩＴＥメッセージである。

m=audio 20002 RTP/AVP 0
C=IN IP4 192.0.2.1
a=curr:qos e2e none a=des:qos mandatory e2e
scheme " http : //www.QoSOperatorX. com/attributes . xml " sendrecv platinum
サービスレベル指標である最後のパラメータはＡすなわちプラチナによって提供される。「スキーム（scheme）」と呼ばれるパラメータは、ＵＲＩhttp://www.QoSOperatorX.com/attributes.xml（このようにして通信事業者Ｘのサービスレベル定義を含むＱｏＳ制御サーバ内のＸＭＬドキュメントを指示する）によって、ＱｏＳ制御サーバからフェッチすべきＡの通信事業者Ｘのサービスレベル定義を表す。

受信側加入者Ｂのみにブロンズのサービスレベルを利用する権利が与えられている。そのため、Ｂからの応答セッションセットアップメッセージには、ブロンズに対応するサービスレベル指標が含まれている。Ｂからの例示の応答セッションセットアップメッセージは、以下のような特別のＳＩＰヘッダを有する２００ＯＫメッセージである。

m=audio 30000 RTP/AVP 0
C=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e
scheme " http : //www.QoSOperatorY.com/attributes.xml" sendrecv bronze
a=conf:qos e2e recv
ＵＲＩhttp://www.QoSOperatorY.com/attributes.xmlは、Ｂの通信事業者Ｙのサービスレベル定義を含む、ＱｏＳ制御サーバ内のＸＭＬドキュメントを指示する。従って、これら双方のメッセージにおいて、第２のa-lineは、サービスレベル指標及びＵＲＩを含む所望のサービスレベルを双方向に解決するための必要なパラメータを含むことになる。いずれのメッセージ内のこのa-lineは、いずれの方向にも対応する正確なサービスレベルを決定するために、双方の加入者による解釈が可能である。このケースでは、加入者Ａは以下のように解釈することになる。

scheme = QoSOpeatorX
level = sendrecv platinum
そして、加入者Ｂは以下のように解釈することになる：
scheme = QoSOpeatorY
level = sendrecv bronze
従って、これらのサービスレベル指標を解釈して、加入者側でキャッシュされるか、提供済みのＵＲＩからフェッチされるかのいずれかにより得ることができる、ＸＭＬドキュメント内のそれぞれのサービスレベル定義に基づいて、必要な又は所要のセッションパラメータに変換することが可能である。

例えば、アップロード／ダウンロード送信に必要な通信パラメータを個々のＸＭＬドキュメントの形で提供することが可能となる。さらに、基本的に当該ＸＭＬドキュメントに対するルールを含む同じＵＲＩ内に発見されるＸＭＬスキーマに対してこのＸＭＬドキュメントの検証を行い、クライアントの不正な振舞いの阻止を図るようにすることができる。これは、リソース予約パス内のどこにおいても行うことが可能である。

必要な通信パラメータが解決されるとすぐに、加入者が無線端末を使用していれば、ＳＤＰはアップリンク／ダウンリンクパラメータを含むことが可能であり、かつ、場合によっては、両方の端部によって肯定応答を受けることができる待ち時間等のような追加パラメータを含むことができる。この起動側加入者Ａは、上記の例の場合のようにＲＶＳＰ等の現在使用されているリソース予約プロトコルにこれらのパラメータをマップする。

個々の中間ノード又はルータにおいて、必要な通信リソースは、上述したように加入者Ａ及びＢからのＰＡＴＨメッセージに応じて、来るべきセッション用として予約され、この結果、個々のトランスポート方向（すなわちＡ及びＢのそれぞれの受信方向）にデータパケット用として個々のルータ内に作成される「パス状態」が得られることになる。これらの通信リソースは以下を備えることができる：
１．送信者データのフォーマットを説明するための送信者テンプレート
２．トラフィック特性又はデータフローの帯域幅について説明するための送信者ｔｓｐｅｃ
３．広告データ［ＸＸ］を運ぶａｄｓｐｅｃ
逆方向データパスに沿ってＲＥＳＶメッセージが送信されるとき、ＲＥＳＶメッセージのＩＰ宛先アドレスは、逆方向パス上に在る個々のノード（すなわち転送パス内に記録されている最後のホップノード）において次のノードのアドレスに変更され、かつ、ＩＰソースアドレスも逆方向のパス上に在る前回のノードのＩＰアドレスに変更される。上記ＲＥＳＶメッセージは、セッション用として必要とされるリソースを特定する、いわゆる「フロースペックデータオブジェクト（flowspec data object）」をさらに含んでもよい。

したがって、加入者Ａは、同意済みのパラメータを配置したＰＡＴＨメッセージを前回のＳＤＰ交渉から第１に送信する。次いで、加入者Ｂは、同じパラメータを使用しているＲＥＳＶメッセージによってＰＡＴＨメッセージの肯定応答を行い、該ＰＡＴＨメッセージはＳＤＰに対して肯定応答を受けることができる。パスに沿う任意のノードにおいて、ＱｏＳパラメータは、それぞれのセッションセットアップメッセージ内のＵＲＩの中に発見されるＸＭＬドキュメントに対して肯定応答を受けることができる。ＲＥＳＶメッセージが肯定応答を受けるとすぐに、実際のセッション開始が可能となる。

第２の加入者Ｂとのピアツーピアセッション状態にある第１の加入者Ａのために関連するサービスレベルを提供するためのＩＰネットワークのルータ内の例示の手順について、図４のフローチャートを参照して説明する。第１ステップ４００において、加入者Ｂとのセッションを求めて加入者Ａから送信されたセッションセットアップメッセージがルータにおいて受信される。このケースでのセッションセットアップメッセージはＰＡＴＨメッセージのようなリソース予約メッセージである。この受信されたリソース予約メッセージにはサービスレベル指標が含まれ、さらに、オプションとして、上述したような、ＱｏＳ制御サーバからフェッチすることができる加入者Ａの通信事業者のサービスレベル定義を参照するＵＲＩも含まれる。

次のステップ４０２において、ルータ内に事前にサービスレベル定義がローカルに格納されていたかどうかのチェックが行われる。上記サービスレベル定義が格納されていた場合、この格納済みのサービスレベル定義はステップ４０４においてローカルストレージ等から取り出される。このような定義がローカルに格納されていなかった場合、通信事業者のサービスレベル定義は、受信済みリソース予約メッセージ内のＵＲＩに基づいて、更なるステップ４０６においてＱｏＳ制御サーバ等からフェッチされる。

次のステップ４０８において、適当なサービスレベル定義が取得された後、ルータは、受信側加入者Ａのために関連するサービスレベルを保証するＢからＡへのデータ送信のために、上記受信済みサービスレベル指標と、取得済みのサービスレベル定義とに基づいて、どのような通信リソースがルータ内において要求されているかを次に決定することが可能となる。これらの決定済み通信リソースもまた予約され、かつ、次のステップ４１０において準備される。

さらにステップ４１２において、ルータは最後のホップノード（すなわち現在のルータへメッセージを転送した前回のノード）を記録する。この記録によって、反対方向に在るいずれのメッセージ又はデータも、同じ方法で予約され、かつ、準備されたリソースを有するルータを介して同じパスを辿ることが可能となる。このステップは、ＩＰアドレスや、最後のホップノードの別の適切な識別子を記録するステップを有してもよい。次いで、加入者Ｂの方へ向うパス内の次のホップノードが決定され、そしてリソース予約メッセージは次のステップ４１４において加入者Ｂへ転送される。このステップで定期的な転送メカニズムを利用することができる。

やがて加入者Ａから送信されるリソース予約メッセージは加入者Ｂに着信し、次いで、加入者Ｂは、ＲＥＳＶメッセージ等の予約確認メッセージを応答セッションセットアップメッセージとして送信することによって加入者Ａに応答する。次いで、上述したように、送信パスの個々のルータ内に記録された最後のホップノードに従って上記応答メッセージをルート指定することができる。従って、ステップ４１６において予約応答メッセージは現在のルータで受信されることになる。提案されたセッションを相手側加入者が受け入れた旨がこのメッセージにより効率よく確認されることに起因して、最終的に、来るべきセッションのために事前に予約され、かつ、準備された通信リソースを最終ステップ４１８において予約することが可能となる。

上述したように、上記手順は、送信パスに沿って個々のルータにおいて基本的に双方向に実行されることが望ましい。セッションが上記のように事前に準備されていた場合、適当なセッションの開始が可能となり、次いで個々のルータは、予約済み通信リソースにより、関連するサービスレベルでの加入者によるデータ受信を保証することになる。

図５は、少なくとも第２の加入者（図示せず）とのピアツーピアセッション状態にある第１の加入者のために関連するサービスレベルを提供することができる、第１の加入者のユーザ端末５００内の装置と、ＩＰネットワークのルータ５０２内の装置とをさらに詳細に示すブロック図である。ユーザ端末５００は、制限なく、無線又は固定電話機、コンピュータ、サーバ、ゲームユニット又はＩＰＴＶクライアント、あるいは、セットトップボックス等のようなテレビ機器であってもよい。

ユーザ端末５００は、例えばそのホームネットワーク５０４からＵＲＩを取得するように適合された取得ユニット５００ａを備え、該ＵＲＩは、第１の加入者の通信事業者のＱｏＳ制御サーバ５０６により保持されているサービスレベル定義Ｄを参照する。また、ユーザ端末５００は、ルータ５０２を備えた送信パスを介して第２の加入者へ向けてセッションセットアップメッセージ（本例ではＰＡＴＨメッセージ）を送信するように適合された送信ユニット５００ｂを備える。この送信済みのＰＡＴＨメッセージは、上記取得済みＵＲＩと、第１の加入者の所要のサービスレベルとを参照するサービスレベル指標を含む。

図示のように、ルータ５０２内の受信ユニット５０２ａは端末５００から送信されるＰＡＴＨメッセージを受信するように適合される。また、受信ユニット５０２ａは、受信済みセッションセットアップメッセージ内に含まれているサービスレベル指標から、第１の加入者の所要のサービスレベルを検出するように適合される。ＵＲＩがルータ５０２内に事前に記憶あるいはキャッシュされている場合、ルータ５０２は、ＱｏＳ制御サーバ５０６か、あるいは、ルータ内のローカルストレージ５０２ｃのいずれかから、第１の加入者の通信事業者のサービスレベル定義Ｄを取得するように適合された取得ユニット５０２ｂをさらに備える。

ルータ５０２は、取得済みサービスレベル定義により解釈されるような、第１の加入者の検出済みサービスレベルに従って、第２の加入者から第１の加入者へのデータ送信のためにルータにおいて要求される通信リソースを決定するように適合されたリソースマネージャ５０２ｄをさらに備える。リソースマネージャ５０２ｄは上記の決定済み通信リソースをルータ内に予約するようにさらに適合される。また、ルータ５０２は次のホップノード５０８、（一般に同様の手順が行われる送信パス内の次のルータ）へセッションセットアップメッセージを転送するように適合された転送ユニット５０２ｅも備える。

リソースマネージャ５０２ｄは、ルータ５０２内の別のローカルストレージ５０２ｆ内のルータへＰＡＴＨメッセージを転送した最後のホップノード（図示せず）を記録するようにさらに適合されてもよい。記録された最後のホップノードは、反対方向に送信される任意のセッション関連メッセージと、データパケットとがＰＡＴＨメッセージと同じパスを介して（すなわち同じ方法で予約済み通信リソースを含むルータを介して）ルート指定されることを保証するためにその後使用することができる。

図５は単に、ユーザ端末５００及びルータ５０２における論理的意味での種々の機能単位を例示する図であるという点に留意されたい。しかし、当業者が実際には、任意の適切なソフトウェア及びハードウェア手段を用いて、これらの機能を自由に実現可能である。従って、本発明は一般に端末５００及びルータ５０２の図示の構造のみに限定されるわけではない。

上述の実施形態のうちのいずれかを用いることによって、参加する加入者のために関連するサービスレベルを提供するように、ＩＰネットワークの送信パス内のルータを介してピアツーピアセッションを加入者の間で確立することが可能となる。セッションの両方向に対して上述のメカニズムが適用されれば、加入者により予期されるか、要求される様々のサービスレベルに従って非対称に通信リソースをルータ内に予約することが可能となる。これによって、双方の加入者は、自分のそれぞれの関連するサービスレベルに従ってセッション中にデータの受信を行うことが可能となる。

本発明について、具体的な実施形態例を参照しながら説明したが、この説明は、一般に本発明のコンセプトを説明することを意図しているだけであって、本発明の範囲を限定していると考えるべきではない。例えば、上記の実施形態を説明するとき、プロトコルＳＩＰと、メッセージＰＡＴＨ及びＲＳＶＰプロトコルのＲＥＳＶとが本明細書で用いられているが、上記の機能を有する他の任意の規格及びプロトコルも基本的に使用可能である。本発明は添付の請求項によって定義される。

Claims

第２の加入者（Ｂ）とピアツーピアセッション状態にある第１の加入者（Ａ）に対して関連するサービスレベルを提供するＩＰネットワークのルータ（２００，５０２）における方法であって、
前記第１の加入者から送信されたセッションセットアップメッセージを受信するステップ（２：２，４００）と、
前記セッションセットアップメッセージに含まれるサービスレベル指標から前記第１の加入者の必要とされるサービスレベルを検出するステップと、
前記第１の加入者のオペレータのサービスレベル定義（Ｄ）を取得するステップ（２：３，４０４，４０６）と、
前記サービスレベル定義を用いた解釈として、前記第１の加入者の検出したサービスレベルに従って前記第２の加入者から前記第１の加入者へのデータ送信用に前記ルータ内で必要とされる通信リソースを決定するステップ（２：４，４０８）と、
前記ルータにおける前記通信リソースを予約するステップ（２：４，４１０）と、
前記セッションセットアップメッセージを次のホップノードへ転送するステップ（２：７，４１２）と
を含むことを特徴とする方法。
前記セッションセットアップメッセージを前記ルータへ転送させる最後のホップノードは、反対方向に送信される任意のセッション関連メッセージ及びデータパケットが前記セッションセットアップメッセージとして同じパス上にルート指定されることを保証するためにさらに使用されるように、前記ルータ内で記憶される（２：５，４１２）ことを特徴とする請求項１に記載の方法。
前記セッションセットアップメッセージは前回のＳＤＰ交渉からマップされた複数のパラメータを含むことを特徴とする請求項１又は２に記載の方法。
前記第１の加入者からの前記セッションセットアップメッセージはリソース予約メッセージであり、
前記予約される通信リソースは、前記第２の加入者から送信された予約確認メッセージを受信する際のルータにおいて予約されることを特徴とする請求項１乃至３の何れか１項に記載の方法。
前記リソース予約メッセージはＰＡＴＨメッセージであり、
前記予約確認メッセージはＲＥＳＶメッセージであることを特徴とする請求項４に記載の方法。
前記サービスレベル定義（Ｄ）は、前記受信したセッションセットアップメッセージのＵＲＩに基づき、前記第１の加入者の前記オペレータにおけるＱｏＳ制御サーバ（２０２）からフェッチされることを特徴とする請求項１乃至５の何れか１項に記載の方法。
前記サービスレベル定義は、前記ＱｏＳ制御サーバで維持されるＸＭＬドキュメントで特定されることを特徴とする請求項６に記載の方法。
前記サービスレベル定義（Ｄ）は、前記ルータのローカルストレージ（５０２ｃ）から取り出されることを特徴とする請求項１乃至５の何れか１項に記載の方法。
第２の加入者とピアツーピアセッション状態にある第１の加入者（５００）に対して関連するサービスレベルを提供するＩＰネットワークのルータ（５０２）における装置であって、
第１の加入者から送信されたセッションセットアップメッセージを受信し、前記セッションセットアップメッセージに含まれるサービスレベル指標から前記第１の加入者の必要とされるサービスレベルを検出する受信ユニット（５０２ｂ）と、
前記第１の加入者のオペレータのサービスレベル定義（Ｄ）を取得する取得ユニット（５０２ａ）と、
前記サービスレベル定義を用いた解釈として、前記第１の加入者の検出したサービスレベルに従って前記第２の加入者から前記第１の加入者へのデータ送信用に前記ルータ内で必要とされる通信リソースを決定し、前記ルータにおける前記通信リソースを予約するリソースマネージャ（５０２ｃ）と、
前記セッションセットアップメッセージを次のホップノードへ転送する転送ユニット（５０２ｄ）と
を備えることを特徴とする装置。
前記リソースマネージャは、反対方向に送信される任意のセッション関連メッセージ及びデータパケットが前記セッションセットアップメッセージとして同じパス上にルート指定されることを保証するためにさらに使用されるように、前記セッションセットアップメッセージを前記ルータへ転送させる最後のホップノードを前記ルータ内に記憶することを特徴とする請求項９に記載の装置。
前記セッションセットアップメッセージは前回のＳＤＰ交渉からマップされた複数のパラメータを含むことを特徴とする請求項９又は１０に記載の装置。
前記第１の加入者からの前記セッションセットアップメッセージはリソース予約メッセージであり、
前記リソースマネージャは、前記第２の加入者から送信された予約確認メッセージを受信する際のルータにおいて予約されることを特徴とする請求項９乃至１１の何れか１項に記載の装置。
前記リソース予約メッセージはＰＡＴＨメッセージであり、
前記予約確認メッセージはＲＥＳＶメッセージであることを特徴とする請求項１２に記載の装置。
前記サービスレベル定義（Ｄ）は、前記受信したセッションセットアップメッセージのＵＲＩに基づき、前記第１の加入者の前記オペレータにおけるＱｏＳ制御サーバ（２０２）からフェッチされることを特徴とする請求項９乃至１３の何れか１項に記載の装置。
前記サービスレベル定義は、前記ＱｏＳ制御サーバで維持されるＸＭＬドキュメントで特定されることを特徴とする請求項１４に記載の装置。
前記取得ユニットは、前記ルータのローカルストレージ（５０２ｃ）からサービスレベル定義（Ｄ）を取り出すことを特徴とする請求項９乃至１５の何れか１項に記載の装置。
第２の加入者とピアツーピアセッション状態にある第１の加入者に対して関連するサービスレベルを取得するユーザ端末の装置（５００）であって、
前記第１の加入者のオペレータのＱｏＳ制御サーバ（５０６）によって維持されるサービスレベル定義（Ｄ）を参照するＵＲＩを取得する取得ユニット（５０２ａ）と、
少なくとも１つのルータを含む送信パスを介してセッションセットアップメッセージを前記第２の加入者へ送信する送信ユニット（５０５ｂ）と
を備え、
前記セッションセットアップメッセージは、前記第１の加入者の必要とされるサービスレベルを参照するＵＲＩ及びサービスレベル指標を含むことを特徴とする装置。