(57)【特許請求の範囲】
【請求項１】
アプリケーション・クライアント（Ｃ）とアプリケーション・サーバ（Ｓ）が、それらを接続する通信ネットワーク（ＮＡＣ、ＮＭＣ、ＮＢ、ＮＭＳ、ＮＡＳ）内の経路（Ｐ）の品質パラメータをネゴシエートする方法であって、
前記アプリケーション・クライアントが、資源の識別子を含む要求を前記アプリケーション・サーバに送ることと、
前記アプリケーション・サーバが、前記資源に関連付けられたデータを含む少なくとも１つの回答を前記アプリケーション・クライアントに送ることと、
前記要求と前記回答が前記経路を介して送信されることと、
を含み、
前記少なくとも１つの回答が、品質アウェア・プロトコルに準拠し、前記経路に沿ってネットワーク・ノードにより実施される品質パラメータを含むことを、前記識別子が指定し、
前記通信ネットワークが、前記品質パラメータに基づいて調整されることを特徴とする方法。
【請求項２】
前記識別子が、前記品質アウェア・プロトコルを示す特定のスキームで始まる一意の資源識別子である請求項１に記載の方法。
【請求項３】
前記ネットワーク・ノードは、前記品質パラメータを読み取り、前記品質パラメータに従って前記回答が送信されることを保証するように前記ネットワーク・ノード自体のパラメータを調整する請求項１乃至２のいずれか１項に記載の方法。
【請求項４】
前記品質パラメータは、待ち時間制約、ジッタ制約、帯域幅制約の群の中の１つまたは複数のパラメータを含む請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記アプリケーション・サーバと前記アプリケーション・クライアントが、前記回答の受信後にネゴシエーション段階を開始し、前記ネゴシエーション段階は、品質測定を可能にする反復的に連続するメッセージからなり、かつ、少なくとも前記品質測定が前記品質パラメータに準拠した時点で終了する請求項１乃至４のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーション・サーバとアプリケーション・クライアントの間の通信ネットワークを介した情報伝達の分野に関する。
【背景技術】
【０００２】
通信ネットワークは、ブラウザなどのアプリケーション・クライアントに、資源の識別子、またはＵＲＩを指定することによってアプリケーション・サーバ（または、ウェブ・サーバ）でナビゲートすることを可能にする。
【０００３】
ＵＲＩ（ユニファイド・リソース識別子（Ｕｎｉｆｉｅｄ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ））は、ＲＦＣ１７３８に従ってＵＲＬ（ユニファイド・リソース・ロケータ）を含み、インターネット内の一意の資源を定義する。資源は、使用可能な最小の情報とみなすことができる。これは、ＨＴＭＬ（ハイパーテキスト・マークアップ言語）に従って書かれたウェブページ、オーディオ・ストリームまたはオーディオ・ビデオ・ストリーム、マルチメディア・ファイルまたはテキスト・ファイルなどであってよい。
【０００４】
ある種の情報に関しては、一定のサービス品質が必須であり、または少なくとも望ましいものとすることができる。例えば、オーディオ・ストリームまたはオーディオ・ビデオ・ストリームは、エンド・ユーザに滑らかな表現を提供するために、リアルタイムで、かつ、ストリームのパケット間の待ち時間を最小限にしてアプリケーション・クライアントに配信される必要がありうる。
【０００５】
アプリケーション・クライアントとアプリケーション・サーバの間で、適切な品質パラメータをネゴシエートすることができるが、そのようなネゴシエーションは通信ネットワークにはほとんど影響を与えず、一方、品質低下の原因は、ほとんどの場合、通信ネットワークのノードにある。
【０００６】
ＤｉｆｆＳｅｒｖやＲＳＶＰといった、通信経路に沿って一定のサービス品質を保証するメカニズムも存在するが、これらの解決策は、プロトコル・スタックのより低いレイヤで使用可能であり、アプリケーション・レベルでは使用可能ではない。エンド・ユーザがそれらのプロトコルを使用してサービス品質を要求することは不可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、アプリケーションに既存の規格および慣習に適合するようにサービス品質パラメータをネゴシエートすることを可能にする解決策が求められている。
【課題を解決するための手段】
【０００８】
本発明の目的は、アプリケーション・クライアントとアプリケーション・サーバが、それらを接続する通信ネットワーク内の経路の品質パラメータをネゴシエートするための方法を提案することによってこの必要性を満たすことである。この方法は、アプリケーション・クライアントが、資源の識別子を含む要求をアプリケーション・サーバに送ること、および前記アプリケーション・サーバが、前記資源に関連付けられたデータを含む少なくとも１つの回答をアプリケーション・クライアントに送ることを含む。この要求とこの回答は経路を介して送信される。
【０００９】
この方法は、少なくとも１つの回答が、品質アウェア・プロトコルに準拠し、経路に沿ってネットワーク・ノードにより実施されるべき品質パラメータを含むべきであることを、識別子が指定することを特徴とする。
【００１０】
本発明の一実施形態によれば、識別子は、この品質アウェア・プロトコルを示す特定のスキームで始まる統一資源識別子（ＵＲＩ）である。
【００１１】
ネットワーク・ノードは、品質パラメータを読み取ることができ、品質パラメータに従って回答が送信されることを保証するようにそのネットワーク・ノード自体のパラメータを調整する。
【００１２】
品質パラメータは、待ち時間制約、ジッタ制約、帯域幅制約の群の中の１つまたは複数のパラメータを含む。
【００１３】
アプリケーション・サーバとアプリケーション・クライアントは、回答の受信後にネゴシエーション段階を開始することができ、このネゴシエーション段階は、品質測定を可能にする反復的に連続するメッセージからなり、かつ、少なくともそれら品質測定が品質パラメータに準拠した時点で終了する。
【００１４】
本発明およびその利点を、以下の詳記で添付の図面と共にさらに明確に記述する。
【図面の簡単な説明】
【００１５】
【図１】アプリケーション・サーバとアプリケーション・クライアントを接続することができ、本発明を実施することができる通信ネットワークの一例を示す図である。
【図２】本発明に関連してアプリケーション・クライアント端部で使用できる典型的なマン・マシン・インターフェイスを示す図である。
【発明を実施するための形態】
【００１６】
この方法は、３つの段階を有するものと考えることができる。
【００１７】
第１の段階はハンドシェイク段階と定義され、この段階では、アプリケーション・サーバがアプリケーション・クライアントによって交信され、品質制約を伝達する。
【００１８】
これを行うために、アプリケーション・クライアントは、ユーザにアプリケーション・サーバの資源の識別子を要求することができる。図２は、このための典型的な一実施形態を示しており、図中、マン・マシン・インターフェイスＭＭＩは、ユーザにインターネットのブラウジングを可能にする１つのソフトウェアに関連付けられたウィンドウＳＢを表示している。このようなソフトウェアがあれば、ユーザは、この資源のアドレスを専用フィールドＡＦに入力することができる。
【００１９】
このようなアドレスは、通常はＵＲＬ（「ユニフォーム・リソース・ロケータ」）またはＵＲＩ（「統一資源識別子」）である。これは、使用されるべきプロトコルを示すスキームで始まる。ＩＥＴＦのＲＦＣ  １７３８で規定されているように、このスキームは「ｆｔｐ」、「ｈｔｔｐ」、「ｍａｉｌｔｏ」などの値をとることができる。本発明によれば、品質アウェア・プロトコルを示すために新しいスキームが使用される。このスキームは例えば「ｈｔｔｐｑ」であってよく、これは、このスキームがＲＦＣ２６１６で規定されたＨＴＴＰプロトコルに基づいており、かつ、文字「ｑ」で表されるように品質アウェアであることを示している。
【００２０】
ユーザが入力したＵＲＬは次の形式をとることができる。
”ｈｔｔｐｑ：”  ”／／”  ｈｏｓｔ  ［”：”  ｐｏｒｔ］  ［ｐａｔｈ［”？”  ｑｕｅｒｙ］］
【００２１】
視覚的なＭＭＩによってユーザにプロンプト表示する以外の方法でアプリケーション・クライアントに資源の識別子を特定させることは本発明の範囲内であることをさらに理解されたい。当然ながら、まず、ＭＭＩは他の入力手段（例えば、音声コマンド）を使用しうるが、一部のアプリケーションもまたｈｔｔｐｑ要求をユーザに透過的な方法で自動的に送りうる。
【００２２】
さらに任意で、アプリケーション・クライアントは品質ヘッダ（ｑｕａｌｉｔｙ  ｈｅａｄｅｒｓ）を送ることができ、アプリケーション・サーバは、確定値（ｄｅｆｉｎｉｔｉｖｅ  ｖａｌｕｅ）でアプリケーション・サーバの回答を構築する際にそれらを考慮することができる。
【００２３】
アプリケーション・サーバは、ＨＴＴＰ  ３０３エラー・メッセージによって回答することができ、このメッセージは、次のＱＨＴＴＰヘッダの一部またはすべてを含むことができる。
・Ｑ−Ｌａｔｅｎｃｙ−ｃｏｎｓｔｒａｉｎｔ（Ｑ−待ち時間−制約）：このヘッダは、アプリケーションに必要とされる最大待ち時間を示す。
・Ｑ−Ｊｉｔｔｅｒ−ｃｏｎｓｔｒａｉｎｔ（Ｑ−ジッタ−制約）：このヘッダは、アプリケーションに許される最大ジッタを示す。
・Ｑ−Ｂａｎｄｗｉｄｔｈ−ｃｏｎｓｔｒａｉｎｔ（Ｑ−帯域幅−制約）：このヘッダは、アプリケーションに必要とされる最小帯域幅をビット毎秒（ｂｐｓ）で示す。
・Ｑ−ＰｏｒｔＲａｎｇｅ−ｃｏｎｓｔｒａｉｎｔ（Ｑ−ポート範囲−制約）：このヘッダは、アプリケーションに対するＵＤＰまたはＴＣＰのポート範囲を示す。  このヘッダには、「，」で区切られたいくつかの値を次の構文で含めることができる。
＜プロトコル＞  ＜初期ポート範囲＞  ［−  ＜最終ポート範囲＞］  ［，  ＜プロトコル＞＜初期ポート範囲＞［−＜最終ポート範囲＞］］
・Ｌｏｃａｔｉｏｎ（ロケーション）：このヘッダは、ウェブブラウザに新しいＱ−ＨＴＴＰ要求を新しいＨＴＴＰＱ  ＵＲＬに向けて送ることを促す、ネゴシエーション段階で使用されるべき次のＵＲＬを示す。
・Ｑ−ｔｒｉｅｓ（Ｑ−試行）：このヘッダは、ネゴシエーション段階中の試行回数と最大試行回数とを含む。最初、試行回数は０に設定されている。試行限度数に達した場合、それ以上品質を向上させることはできないとみなされる。２つの値は「，」で区切られる。
・Ｑ−Ｉｎｔｅｒｖａｌ（Ｑ−間隔）：このヘッダは、サーバがクライアントにネゴシエーション段階の再開を許可する間隔（例えば、秒による表示）を示す。
・Ｑ−Ｒｅｓｕｌｔ（Ｑ−結果）：このヘッダは、品質ネゴシエーション処理の結果を含む。これは、最初は「Ｏｋ」または同じことを意味する他の値に設定されている。
・Ｑ−Ｕｐｇｒａｄｅ（Ｑ−アップグレード）：このヘッダは、ネットワーク品質のアップグレードが必要であることを示す。このヘッダは、ある意味では、本実施形態で使用される類のメッセージ（ｅｒｒｏｒ  ３０３）（エラー３０３）と一部重複するが、サーバがネットワーク品質のアップグレードを求める前に何らかの測定の実行を希望する場合には有益でありうる。例えばこの値が「Ｎｏ」の場合はネットワークにアップグレードは求められておらず、この値が「Ｎｅｅｄｅｄ（必要）」の場合は、ネットワークに品質のアップグレードが要求されていることを示す。
・Ｑ−Ｄｉｇｅｓｔ（Ｑ−ダイジェスト）：ネゴシエーション段階の後続メッセージのヘッダに変更が加えられることを避ける目的で、このヘッダは、すべての品質ヘッダの値と秘密のサーバキーワードとを使用して生成されたハッシュ値を含む。
・Ｑ−Ａｕｔｏｎｏｍｏｕｓ−ｓｙｓｔｅｍｓ（Ｑ−自律−システム）：値は「；」で区切られる。自律システムの完全なリストを得るために、各中間自律システムはそれぞれの識別子をこのヘッダに記入する必要がある。
【００２４】
これら２つのメッセージの後、第１段階が完了する。経路が確立し、アプリケーション・クライアントへの品質パラメータの送信が完了する。したがって、すべての中間ネットワーク・エレメントがＱ−ヘッダを読み取る機会を得たことになる。
【００２５】
図１は、アプリケーション・サーバとアプリケーション・クライアントを接続することができ、本発明を実施することができる通信ネットワークの一例を示す図である。
【００２６】
実際には、この通信ネットワークはいくつかのサブネットワークから構成されうる。この例では、アプリケーション・クライアントＣは、ネットワーク・エレメント（またはノード）Ｎ１で構成されるアクセス・ネットワークＮＡＣに接続され、アプリケーション・サーバＳは、ネットワーク・ノードＮ７で構成されるアクセス・ネットワークＮＡＳに接続される。
【００２７】
両方のアクセス・ネットワークＮＡＣとＮＡＳはそれぞれＮＭＣとＮＭＳというメトロポリタン・エリア・ネットワークに接続され、これらメトロポリタン・エリア・ネットワークは、バックボーン・ネットワークＮＢを介して相互に接続される。メトロポリタン・ネットワークＮＭＣは２つのノードＮ２とＮ３で構成され、メトロポリタン・ネットワークＮＭＳは単一のノードＮ６で構成される。バックボーン・ネットワークは２つのノードＮ４とＮ５を含む。
【００２８】
当然ながら、当技術分野には当業者が本発明を容易に配置しうる多くの他のトポロジーが存在する。
【００２９】
アプリケーション・クライアントＣをアプリケーション・サーバＳにリンクする通信経路Ｐは、ネットワーク・エレメントＮ１、Ｎ２、Ｎ３、Ｎ４、Ｎ５、Ｎ６、Ｎ７を通る。
【００３０】
前述のとおり、すべてのそれらのネットワーク・エレメントは通信経路内に位置するので、アプリケーション・クライアントＣとサーバＳが交換した２つのメッセージを既に伝送しており、また、サーバの回答と共に送信されたヘッダに関して認識している。それらヘッダとそれらが含む品質パラメータとを認識しているので、ネットワーク・エレメントはそれらを実施することができる。
【００３１】
品質パラメータがネットワーク・ノードによって実施される方法はいくつかありうる。
【００３２】
例えば、担当するネットワーク・ノード内で要求されるサービス品質を提供する責任を持つ品質管理サーバＭＳに送られたメッセージｍを、アクセス・ノードはトリガすることができる。このトリガは、クライアント側（すなわち、ノードＮ１によって）またはサーバ側（すなわち、ノードＮ７によって）で行われうる。
【００３３】
別の一実施形態によれば、経路Ｐ内に位置する一部またはすべてのネットワーク・ノードは、要求される品質パラメータを保証するために必要な資源をそれら自体に準備しておくことができる。
【００３４】
アルゴリズムの第２段階は、品質ネゴシエーション段階である。この段階は、ハンドシェイク段階中に既に達した事柄に関して品質保証を付け加えるものなので、任意とみなすことができる。
【００３５】
このネゴシエーション段階は、経路Ｐが最低限の品質制約に準拠するまで反復的に連続するメッセージを伴う。この連続するメッセージはさらに、ネットワークがいくつかの品質測定を行うことを可能にする。
【００３６】
アプリケーション・クライアントＣは、すべてのＱ−ＨＴＴＰ品質ヘッダを含むＱ−ＨＴＴＰ  ＧＥＴメッセージをアプリケーション・サーバＳに向けて送る。これらのヘッダは、すべての中間ネットワーク・エレメントにこの情報を提供するためにすべてのメッセージに含まれる。この点が、正規のＨＴＴＰプロトコルと異なる（正規のＨＴＴＰプロトコルでは、クライアントはＬｏｃａｔｉｏｎ（ロケーション）ヘッダの受信後はすべてのヘッダを送らないことになっている）ことに留意されたい。
【００３７】
本発明の本実施形態によれば、アプリケーション・サーバＳは次の項目を含むＨＴＴＰエラー３０３メッセージによって回答しなければならない。
・受信した要求のすべての品質ヘッダ、
・Ｑ−Ｔｉｍｅｓｔａｍｐ（Ｑ−タイムスタンプ）：初期値を０とする新しい追加ヘッダ。
・Ｑ−Ｒｅｓｕｌｔ（Ｑ−結果）：「Ｏｋ」に設定されている。
・Ｌｏｃａｔｉｏｎ（ロケーション）：リダイレクトされるべき次の「ｈｔｔｐｑ」ＵＲＬ。  使用されるべき一般的なスキーマは、毎回異なるクエリ値による”ｈｔｔｐｑ”  ”／／”  ｈｏｓｔ  ［”：”  ｐｏｒｔ］  ［ｐａｔｈ［”？”  ｑｕｅｒｙ］］である。このクエリ値は、Ｑ−Ｔｒｉｅｓ（Ｑ−試行）ヘッダの値であってよい。
・Ｑ−Ｔｒｉｅｓ（Ｑ−試行）ヘッダは、前回の値に１を加えて更新される。
・Ｑ−Ｄｉｇｅｓｔ（Ｑ−ダイジェスト）ヘッダは、すべての他のヘッダの新しい値によって再計算される。
【００３８】
アプリケーション・クライアントＣはこのメッセージを受信すると、Ｑ−ＨＴＴＰ  ＧＥＴ要求を再度送る。アプリケーション・クライアントＣは、サーバが構築したＴｉｍｅｓｔａｍｐ（タイムスタンプ）ヘッダを含むいかなるヘッダをも変更すべきでない。
【００３９】
このように行われるので、アプリケーション・サーバＳは、第１のタイムスタンプと、この新たに受信したメッセージ内のタイムスタンプの間の経過時間を測定することができる。この時点で、次の３つの可能性がある。
１）  最大試行回数に達している。この場合、本発明者らは、これ以上品質を向上させることはできないとみなすことができる。Ｑ−Ｒｅｓｕｌｔ（Ｑ−結果）ヘッダの値が「ＮＯＫ」の場合、アプリケーション・サーバはＨＴＴＰ  ４１２メッセージによって回答する。ＩＥＴＦのＲＦＣ  ２６１６、パラグラフ１０．４．１３で規定されるＨＴＴＰプロトコルによれば、「４１２」メッセージは、クライアントまたはサーバの必要とする前提条件となる設定が満たされていないことを意味する。
２）  Ｔｉｍｅｓｔａｍｐ（タイムスタンプ）ヘッダと現在時刻の差が、待ち時間制約に準拠するだけ十分に小さい。この場合、アプリケーション・サーバＳは、「Ｏｋ」に設定されたＱ−Ｒｅｓｕｌｔ（Ｑ−結果）ヘッダを含むＨＴＴＰ  ２００メッセージによって回答する。
３）  最後のケースでは、上記の差は十分に小さくはないが、試行回数が最大値に達していない。この場合、次の項目を含むＨＴＴＰ  ３０３メッセージが送り返される。
・要求内で受信されたすべての品質ヘッダ、
・Ｑ−Ｔｉｍｅｓｔａｍｐ（Ｑ−タイムスタンプ）ヘッダの新しい値、
・「ＮＯＫ」（または、結果がｏｋでないことを意味するいかなる他の値）に設定されたＱ−Ｒｅｓｕｌｔ（Ｑ−結果）ヘッダ値
・新しい値に設定されたＬｏｃａｔｉｏｎ（ロケーション）ヘッダ。
【００４０】
終了条件の１つが満たされるまで、アプリケーション・クライアントは、ＨＴＴＰ  Ｌｏｃａｔｉｏｎ（ロケーション）ヘッダ・メカニズムを使用して、通信ネットワークＮＡＣ、ＮＭＣ、ＮＢ、ＮＭＳ、ＮＡＳにそれら自体を調整することを許可するためにＱ−ＨＴＴＰ要求を送ることになる。
【００４１】
２００  Ｏｋメッセージが受信された場合、それは、最適条件に到達し、かつ、クライアントが、十分な品質接続かまたは少なくともネットワークが提供する最高の品質接続でサービスにアクセスできることを意味する。
【００４２】
この場合、Ｓサーバは、それ自体が上記のアプリケーション・クライアントに要求した資源に関連するデータを含むメッセージを送り始めることができる。それは、例えば、マルチメディア資源（例えば、動画ストリーミングおよび／またはオーディオ／ストリーミング）のデータを含むパケットであってよい。資源は、アプリケーション・サーバとリンクを確立できる別のクライアントのアドレスであってもよく、その場合、データは音声通話および／またはビデオ通話の内容である。
【００４３】
本発明の一実施形態によれば、第３段階は、ネットワーク条件が何時変更されて全体的な品質が低下するかをチェックしてそれに反応することを目的として、アプリケーションの実行中に配置することもできる。アプリケーション・クライアントは、前述のようにネゴシエーション段階を定期的に再実行することができ、その結果、ネットワーク・ノードは再調整されうる。このような再ネゴシエーションを実行することができる間隔は、Ｑ−Ｉｎｔｅｒｖａｌ（Ｑ−間隔）ヘッダ内に示される。
【００４４】
クライアントからの要求が多すぎることを原因とする何らかのパフォーマンス上の問題が発生することを避けるために、サーバは、Ｑ−Ｉｎｔｅｒｖａｌ（Ｑ−間隔）要件が満たされない場合は、２００  Ｏｋ応答によって自動的に回答することができる。
【００４５】
本発明の一実施形態によれば、ネットワーク・ノード内のプロビジョニングまたは資源は、ＩＰ／ＭＰＬＳレベルのＤｉｆｆＳｅｒｖメカニズムに従い実行することができる。次いで、ネゴシエーション段階中のアプリケーションの目的で転送クラスを適切な値に変更することができる。Ｑ−ＨＴＴＰヘッダ内に含まれる実際の値を読み取るのではなく、ネゴシエーションの各ステップでＨＴＴＰトラフィックをより高位の転送クラスに移動することにより動的適応を達成しうる。既に説明したように、設定した最大反復が満たされた時点か、または品質パラメータが（アプリケーションから見て）十分に良好になった時点で、処理は終了する。
【００４６】
ネットワークの観点からすると、セッション終了後にＱｏＳプロファイルをデフォルト設定に戻すために、無活動タイマ（ｉｎａｃｔｉｖｉｔｙ  ｔｉｍｅｒｓ）も定義することができる。
【００４７】
他のネットワーク・エレメントはＱｕａｌｉｔｙ（品質）ヘッダを使用して品質制約を達成することができ、また、各エレメントが、Ｑ−ＨＴＴＰヘッダのＢａｎｄｗｉｄｔｈ（帯域幅）制約およびＬａｔｅｎｃｙ（待ち時間）（これは、通常、いくつかの優先権方針を含意する）を使用して、帯域幅に関して各エレメント自体の調整を完了したものと考えられる。
【００４８】
クライアントのブラウザ上では、デフォルト設定を提供するために、設定可能なＱｕａｌｉｔｙ（品質）ヘッダの集合をブラウザの設定メニューに表示させ、第１のメッセージ内にそれら品質ヘッダを簡単に表示できるようにすることが好ましい。
【００４９】
この技術的発明に加えて、他のビジネス・モデルを設計することができる。例えば、品質の代金支払者が誰なのかによって、アプリケーション・サーバは、第１のメッセージ内に含めて送られた所望のアプリケーション・クライアントのパラメータを受理するか、またはサーバが代金を支払うパラメータを強制することができる。
【図１】
0005511988.tif 000002
【図２】
0005511988.tif 000003