ＱｏＳ制御システム、ＱｏＳ制御装置及びセッション制御装置

トップ :: H 電気 :: H04 電気通信技術

【発明の名称】	ＱｏＳ制御システム、ＱｏＳ制御装置及びセッション制御装置
【発明者】	【氏名】湯本一磨【氏名】高瀬晶彦
【要約】	【課題】要求されたリソース及び品質を提供することができないときに、提供可能な代替候補を提示する。【構成】端末装置と、端末装置が送受信するパケットを転送するノード装置と、ノード装置のリソースの確保を要求するリソース要求装置と、ノード装置のリソースの割当を制御するＱｏＳ制御装置とを備え、ネットワークにおけるリソースの割当を制御するＱｏＳ制御システムにおいて、ＱｏＳ制御装置は、ノード装置が受信したパケットを転送する経路情報、及びノード装置のリソース情報を管理し、端末装置が通信する経路に含まれるノード装置が、リソース要求装置によって要求されたリソースを提供可能であるか否かを判定し、ノード装置が要求されたリソースを提供できないとき、要求されたリソースの代替候補を決定し、代替候補をリソース要求装置に通知する。

【特許請求の範囲】
【請求項１】
ネットワークにおけるリソースの割当を制御するＱｏＳ制御システムであって、
端末装置と、前記端末装置が送受信するパケットを転送するノード装置と、前記ノード装置のリソースの確保を要求するリソース要求装置と、前記ノード装置のリソースの割当を制御するＱｏＳ制御装置と、を備え、
前記ＱｏＳ制御装置は、
前記ノード装置が受信したパケットを転送する経路情報、及び前記ノード装置のリソース情報を管理し、
前記端末装置が通信する経路に含まれるノード装置が、前記リソース要求装置によって要求されたリソースを提供可能であるか否かを判定し、
前記ノード装置が要求されたリソースを提供できないとき、要求されたリソースの代替候補を決定し、前記代替候補を前記リソース要求装置に通知することを特徴とするＱｏＳ制御システム。
【請求項２】
前記ＱｏＳ制御装置は、前記リソース要求装置が要求したリソースを提供できないとき、提供可能な帯域を代替候補として通知することを特徴とする請求項１に記載のＱｏＳ制御システム。
【請求項３】
前記ＱｏＳ制御装置は、前記リソース要求装置が要求したリソースを提供できないとき、前記ノード装置に備えられた出力キューのうち、要求された優先度と異なる優先度の出力キューを代替候補として通知することを特徴とする請求項１に記載のＱｏＳ制御システム。
【請求項４】
前記ＱｏＳ制御装置は、前記リソース要求装置が要求したリソースを即時提供できないとき、提供可能となる時間を代替候補として通知することを特徴とする請求項１に記載のＱｏＳ制御システム。
【請求項５】
前記リソース要求装置は、前記端末装置が送受信する呼制御メッセージを中継するセッション制御装置であって、
前記セッション制御装置は、
前記端末装置が送信した呼制御メッセージに含まれるメディア情報に基づいて、前記ノード装置に要求するリソースを決定し、
前記ＱｏＳ制御装置から代替候補を含む応答を受信したとき、前記代替候補のリソース情報を呼制御メッセージに包含可能なメディア情報に変換し、前記変換されたメディア情報を含む呼制御メッセージを前記端末装置に中継することを特徴とする請求項１に記載のＱｏＳ制御システム。
【請求項６】
前記セッション制御装置は、呼制御メッセージによる前記端末装置のネゴシエーション手順における、オファー要求に対するアンサー応答を受信したとき、前記ＱｏＳ制御装置に対し、前記ノード装置のリソースの確保を要求することを特徴とする請求項５に記載のＱｏＳ制御システム。
【請求項７】
ネットワークにおけるリソースの割当を制御するＱｏＳ制御システムで、端末装置が送受信するパケットを転送するノード装置のリソースの割当を制御し、前記ノード装置のリソースの確保を要求するリソース要求装置と前記ネットワークを介して接続するＱｏＳ制御装置であって、
前記ノード装置の経路情報、及びリソース情報を管理し、
前記端末装置が通信する経路に含まれるノード装置が、前記リソース要求装置に要求されたリソースを提供可能であるか否かを判定し、
前記ノード装置が要求されたリソースを提供できないとき、要求されたリソースの代替候補を決定し、前記リソース要求装置に前記代替候補を通知することを特徴とするＱｏＳ制御装置。
【請求項８】
前記ノード装置が要求されたリソースを提供できないとき、提供可能な帯域を代替候補として提示することを特徴とする請求項７に記載のＱｏＳ制御装置。
【請求項９】
前記ノード装置が要求されたリソースを提供できないとき、前記ノード装置に備えられた出力キューで、要求された優先度と異なる優先度の出力キューを代替候補として通知することを特徴とする請求項７に記載のＱｏＳ制御装置。
【請求項１０】
前記ノード装置が要求されたリソースを即時提供できないとき、前記要求されたリソースが提供可能となる時間を代替候補として通知することを特徴とする請求項７に記載のＱｏＳ制御装置。
【請求項１１】
ネットワークにおけるリソースの割当を制御するＱｏＳ制御システムで、端末装置が送受信するパケットを転送するノード装置のリソースの割当を制御するＱｏＳ制御装置と接続するセッション制御装置であって、
前記端末装置が送受信する呼制御メッセージを中継し、
前記呼制御メッセージに含まれるメディア情報に基づいて、前記ノード装置に要求するリソースを決定し、
前記ＱｏＳ制御装置から代替候補を含む応答を受信したとき、前記代替候補のリソース情報を呼制御メッセージに包含可能な形式のメディア情報に変換し、前記変換されたメディア情報を含む呼制御メッセージを前記端末装置に中継することを特徴とするセッション制御装置。
【請求項１２】
前記セッション制御装置は、前記呼制御メッセージによる前記端末装置のネゴシエーション手順における、オファー要求に対するアンサー応答を受信したとき、前記ＱｏＳ制御装置に対し、前記ノード装置のリソースの確保を要求することを特徴とする請求項１１に記載のセッション制御装置。

【発明の詳細な説明】【技術分野】
【０００１】
本発明は、ＱｏＳ制御システムに関し、特に、要求されたリソース又は品質を提供できないときに代替候補を提示する技術に関する。
【背景技術】
【０００２】
近年、インターネットの利用範囲が拡大し、音声及び動画の配信などのマルチメディアサービスが提供されている。しかし、ＶｏＩＰなどによる会話音声データの伝送は、ネットワークの遅延を低く抑えないと、音声品質が著しく劣化してしまうため、厳しいリアルタイム性が要求される。
【０００３】
そこで、特許文献１には、帯域管理装置（ＱｏＳ制御装置）が、提供されるサービスに応じて通信帯域を制御することによって帯域を確保し、ネットワークの伝送品質を維持する技術が提案されている。また、特許文献２には、セッション確立時に端末間通信に要求されるリソースをコールエージェント（呼制御装置）がポリシーサーバに要求し、要求リソース量を満足する通信パス（経路）が存在する場合には、当該経路にデータを伝送するネットワークポリシー制御システムが提案されている。
【０００４】
さらに、非特許文献１には、セッション制御プロトコルとしてＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）を使用し、ＱｏＳの前提条件を含めたネゴシエーションを行うプロトコル仕様の拡張が示されている。また、非特許文献２には、セッション制御装置（呼制御装置）からＱｏＳ制御装置のようなポリシーを適用する機能を有する装置に対するリソース要求インタフェースの仕様が示されている。
【特許文献１】特開２０００－２２４２３９号公報
【特許文献２】特開２００３－２５８８５７号公報
【非特許文献１】RFC3312 "Integration of Resource Management and SIP",IETF,2002年10月
【非特許文献２】3GPP Specification "TS29.209 Version 6.5.0",3GPP,2006年6月21日
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来のＱｏＳ制御システムにおけるＱｏＳ（リソース、品質）要求の応答は、成功（可）又は失敗（不可）といった結果を返すことはできたが、提供可能なリソース及び品質を代替候補として提示することはできなかった。
【０００６】
本発明が解決しようとする課題は、要求されたリソース及び品質を提供することができないときに、提供可能な代替候補を提示することである。
【課題を解決するための手段】
【０００７】
本発明の代表的な一形態では、ネットワークにおけるリソースの割当を制御するＱｏＳ制御システムであって、端末装置と、前記端末装置が送受信するパケットを転送するノード装置と、前記ノード装置のリソースの確保を要求するリソース要求装置と、前記ノード装置のリソースの割当を制御するＱｏＳ制御装置と、を備え、前記ＱｏＳ制御装置は、前記ノード装置が受信したパケットを転送する経路情報、及び前記ノード装置のリソース情報を管理し、前記端末装置が通信する経路に含まれるノード装置が、前記リソース要求装置によって要求されたリソースを提供可能であるか否かを判定し、前記ノード装置が要求されたリソースを提供できないとき、要求されたリソースの代替候補を決定し、前記代替候補を前記リソース要求装置に通知する。
【発明の効果】
【０００８】
本発明の一形態によると、要求されたリソース及び品質が提供できない場合には、提供可能な代替候補を提示することができる。
【発明を実施するための最良の形態】
【０００９】
図１は、本発明の実施の形態のＱｏＳ制御システムの構成を示す図である。ＱｏＳ制御システムは、セッション制御装置１、ＱｏＳ制御装置２、ユーザ端末（ＵＥ：ＵｓｅｒＥｑｕｉｐｍｅｎｔ）３Ａ、３Ｂ、コアノード４及びエッジノード５を備える。セッション制御装置１、ＱｏＳ制御装置２、ユーザ端末３Ａ及び３Ｂは、エッジノード５及びコアノード４によって構成されるネットワークに接続する。
【００１０】
なお、図１では、ネットワークのレイヤ構造、及びシグナリングパケットとデータパケットの流れを明示するために、セッション制御装置１、ＱｏＳ制御装置２、ユーザ端末３Ａ及び３Ｂを分離して表記している。したがって、シグナリングパケットは、ユーザ端末３Ａ及び３Ｂとセッション制御装置１とが直接接続されて送受信されているのではなく、ネットワークを介して送受信される。同様に、セッション制御装置１とＱｏＳ制御装置２との間、ＱｏＳ制御装置２とコアノード４及びエッジノード５との間もネットワークを介して接続される。
【００１１】
セッション制御装置１は、ネットワークを介してユーザ端末３Ａ及び３Ｂが送受信するセッション制御メッセージ（呼制御メッセージ）を中継制御する。セッション制御装置１は、ユーザ端末３Ａ又は３Ｂが送信したセッション接続要求にＱｏＳの前提条件が含まれる場合に、ＱｏＳ制御装置２にＱｏＳ要求を発行する。
【００１２】
ＱｏＳ要求のパラメータとしては、例えば、セッション識別子、フローの方向（双方向／送信方向／受信方向）、宛先／送信元ＩＰアドレス、プロトコル番号、ＴＣＰ／ＵＤＰの宛先／送信元ポート番号、メディア種別、コーデック種別、最大要求帯域、優先度、要求転送品質（例えば、ＩＴＵ－Ｔ勧告Ｙ．１５４１で規定されているクラス）などの情報を送る。
【００１３】
ＱｏＳ制御装置２は、ＱｏＳ要求を受信すると、要求の受入可否を判定する。受入可能な場合には、対象フローの経路となるノードに対してＱｏＳ制御を実行する。ＱｏＳ制御とは、要求されたリソース又は品質を予約（確保）することである。一方、要求された品質を提供できないとき、代替候補が存在する場合には代替候補を提示し、代替候補が存在しない場合にはその旨をセッション制御装置１に応答する。
【００１４】
セッション制御装置１は、ＱｏＳ制御装置２からの応答を受信すると、代替候補のリソース情報から該当するメディア情報を決定し、ユーザ端末３に対する応答を中継する。
【００１５】
なお、ユーザ端末に相当する装置は、アプリケーションサーバであってもよい。また、ＱｏＳ制御装置２にＱｏＳ要求を発行する主体は、セッション制御装置１ではなくアプリケーションサーバであってもよい。
【００１６】
図２は、本発明の実施の形態のアクセス網とコア網、及びトランスポート層３０２とサービス層３０１の境界を明示したコア網に対してＱｏＳ制御システムを適用する一例を示す図である。
【００１７】
ユーザ端末３Ａは、アクセス網を介してコア網に接続し、更に相手側のアクセス網を経由して相手側のユーザ端末と接続する。また、アクセス網及びコア網の構成要素は、サービス層３０１とトランスポート層３０２に分類される。
【００１８】
図１のセッション制御装置１は、アクセス網のＰ－ＣＳＣＦ（Ｐｒｏｘｙ－ＣａｌｌＳｅｓｓｉｏｎＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ）３１０Ａ、３１０Ｂ、及びコア網のＳ－ＣＳＣＦ（Ｓｅｒｖｉｎｇ－ＣＳＣＦ）３１２に該当する。また、図２では、Ｓ－ＣＳＣＦはコア網に含まれているが、（Ｂ）のＳＣＦｓ（ＳｅｒｖｉｃｅＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎｓ）を提供する事業者と、（Ｄ）のコア網を提供する事業者は異なる場合がある。
【００１９】
コア網に含まれるコアルータ３２０及びエッジルータ３２２は、それぞれ図１のコアノード４及びエッジノード５に相当する。また、アクセス網のリソースを制御するリソースアクセスコントロール装置３１４Ａ、３１４Ｂ及びＱｏＳ制御装置３１６は、図１のＱｏＳ制御装置２に相当する。
【００２０】
図３は、本発明の実施の形態のＱｏＳ制御装置２の構成を示す図である。ＱｏＳ制御装置２は、ＣＰＵ１０、メモリ１３、記憶装置１２及び通信インタフェース（通信ＩＦ）１１を備える。
【００２１】
ＣＰＵ１０は、メモリ１３に記憶されたプログラムを実行する。メモリ１３は、ＣＰＵ１０によって実行されるプログラム及び処理に必要なデータを格納する。通信ＩＦ１１は、ネットワークを介して他の計算機と通信する。
【００２２】
記憶装置１２は、ＱｏＳ制御用プログラム及びＱｏＳ制御に必要なデータを格納する。ＱｏＳ制御用プログラムは、実行時にメモリ１３に展開される。記憶装置１２は、ＱｏＳ制御装置２の筐体内部に実装されても、外部記憶装置として設置されても、ネットワークを介して接続されてもよい。
【００２３】
さらに、ＱｏＳ制御装置２には、管理者が操作するためのユーザインタフェースを備えてもよい。ユーザインタフェースとしては、例えば、コマンド入力のためのキーボード、ＧＵＩ入力のためのマウス、及びディスプレイなどの表示装置などがある。
【００２４】
ＱｏＳ制御用プログラムは、通信制御プログラム２０、要求条件受信処理プログラム２１、ＱｏＳ設定要求処理プログラム２２、結果応答処理プログラム２３、ノード設定情報収集処理プログラム２４、要求受付判定処理プログラム２５、対象ノード特定処理プログラム２６及びノード管理情報更新処理プログラム２７などによって構成される。各プログラムは、それぞれ異なるプロセスで実行される独立したプログラムであってもよいし、同一のプロセスで実行される単一のプログラムとして構成してもよい。
【００２５】
通信制御プログラム２０は、通信ＩＦ１１を介して受信したパケットを解析する。さらに、通信制御プログラム２０は、パケットのヘッダ情報を整形して送信する。
【００２６】
要求条件受信処理プログラム２１は、受信したＱｏＳ要求の内容を解析する。ＱｏＳ設定要求処理プログラム２２は、対象のノードに対してＱｏＳ設定を実行する。結果応答処理プログラム２３は、受信したＱｏＳ要求に対する判定結果を要求元に応答する。
【００２７】
ノード設定情報収集処理プログラム２４は、対象ネットワークに含まれるノードの設定情報を収集する。要求受付判定処理プログラム２５は、受信したＱｏＳ要求の受入可否を判定する。対象ノード特定処理プログラム２６は、要求されたＱｏＳを適用する対象のノードを特定する。ノード管理情報更新処理プログラム２７は、各ノードの利用状況などを更新する。
【００２８】
また、記憶装置１２は、ＱｏＳ制御を実行するために必要な情報として、ノード情報管理テーブル２８、ノード利用情報管理テーブル２９、要求受付判定テーブル１８及びリソース割当管理テーブル１９を格納する。各テーブルは、記憶装置１２に格納された状態で随時アクセスされるデータベースとして構成してもよいし、ＱｏＳ制御用プログラムの実行時にメモリ１３に展開して利用してもよい。
【００２９】
ノード情報管理テーブル２８は、ネットワークを構成するノードの構成情報を格納する。ノード利用情報管理テーブル２９は、ネットワークを構成するノードの利用状態を格納する。要求受付判定テーブル１８は、出側エッジノード及び入側エッジノードにおけるＱｏＳ要求の受入可否の判定結果に基づいて、ＱｏＳ要求全体の受入可否を判定するための情報を格納する。リソース割当管理テーブル１９は、セッション単位に割り当てられたリソースを管理する。
【００３０】
図５は、本発明の実施の形態のノード設定情報管理テーブル２８の構成を示す図である。ノード設定情報管理テーブル２８に格納された情報は、ＱｏＳ制御装置２がノード設定情報収集プログラム２４を実行し、各ノードのルーティング情報を収集して記録される。
【００３１】
ノード設定情報管理テーブル２８は、ノード４０、インターフェース４２、宛先ネットワーク４４及びネクストホップ４６を含む。ノード４０は、ネットワークを構成する各ノードの識別子を格納する。具体的には、図１のコアノード４又はエッジノード５の識別子が格納される。インターフェース４２は、各ノードの通信ＩＦの識別子を格納する。ネクストホップ４６は、宛先ネットワーク４４にパケットを転送するための送り先であり、ルータのＩＰアドレスを格納する。
【００３２】
図６Ａは、本発明の実施の形態のリンクごとに利用情報を管理するノード利用情報管理テーブル２９の構成を示す図である。ノード利用情報管理テーブル２９は、ノード５０、リンク／キュー５２、帯域容量５４及び積算使用量５６を含む。ノード利用情報管理テーブル２９は、ノード管理情報更新処理プログラム２７が実行されることによって、更新される。
【００３３】
ノード５０は、ネットワークを構成する各ノードの識別子を格納する。具体的には、図１のコアノード４又はエッジノード５の識別子が格納される。リンク／キュー５２は、各ノードのリンク又はキューの識別子を格納する。図６Ａでは、リンクの識別子が格納されている。帯域容量５４は、各リンク／キューに割り当てられた帯域の容量を格納する。積算使用量５６は、使用中の帯域の容量を格納する。
【００３４】
図６Ｂは、本発明の実施の形態のノード装置のシェーパ機能による優先キュー／非優先キューの利用を説明する図である。シェーパ機能とは、パケットの出力順序及び出力帯域を制御する機能である。
【００３５】
図６Ｂに示すシェーパは、１つの優先キュー（ＬＬＱ：Low latency Queueing）と３つの重み付き非優先キュー（ＷＦＱ：Weighted Fair Queueing）を備える。ノード装置は、宛先が同一のフローであっても、優先的に転送する必要があれば、優先キューに振り分け、インターネット通信のようにベストエフォートで転送すればよい場合には、非優先キューに振り分けることによって品質を制御する。
【００３６】
図６Ｂでは、Ｑ＃４は優先キューであって、Ｑ＃１～Ｑ＃３よりも優先してパケットを出力する。一方、Ｑ＃１～Ｑ＃３は、優先キューが使用していない帯域を指定された重み（Ｘ：Ｙ：Ｚ）に応じて出力される。図６Ｂに示す回線では、合計１Ｇｂｐｓの帯域が割り当てられており、優先キューＱ＃４には３００Ｍｂｐｓの帯域が割り当てられ、非優先キューには残りの帯域が５：３：２で分割されて割り当てられている。
【００３７】
図６Ｃは、本発明の実施の形態のキューごとに利用情報を管理するノード利用情報管理テーブル２９を示す図である。テーブルの構成は、図６Ａと同じである。また、図６Ｃに示すノード利用情報管理テーブル２９は、図６Ｂに示したシェーパ機能に対応する。なお、図６Ｃのリンク／キュー５２には、キューの識別子が格納される。
【００３８】
図７は、本発明の実施の形態の要求受付判定テーブル１８の構成を示す図である。ＱｏＳ制御装置２は、要求受付判定テーブル１８を参照してＱｏＳ要求の結果を判定する。なお、ＱｏＳ要求の判定は、ネットワークの帯域容量が十分に確保されている場合には、通信経路に含まれる全てのノードについて判定せずに入側及び出側のエッジノードのみを判定すればよい。本発明の実施の形態では、入側及び出側のエッジノードのみを判定する。
【００３９】
要求受付判定テーブル１８は、出側エッジノードの出力余剰１３０、入側エッジノードの出力余剰１３１及び結果判定１３２を含む。出側エッジノードの出力余剰１３０は、要求されたＱｏＳ要求を満たす場合には、“○”が格納され、代替候補が存在する場合には、“△”が格納され、代替候補が存在しない場合には、“×”が格納される。入側エッジノードの出力余剰１３１についても同じである。
【００４０】
結果判定１３２は、出側エッジノードの出力余剰１３０及び入側エッジノードの出力余剰１３１との関係から、ＱｏＳ要求の結果が格納される。具体的には、入側及び出側のエッジノードの値がともに“○”であれば、結果判定１３２を「可」とし（１３３）、いずれか一方でも“×”であれば、「不可」とする（１３７、１３８）。代替候補を提示可能な場合には、結果判定１３２を「代替提示」とする（１３４～１３６）。
【００４１】
図８は、本発明の実施の形態のリソース割当管理テーブル１９の構成を示す図である。リソース割当管理テーブル１９は、セッション単位にレコードが記録される。リソース割当管理テーブル１９は、セッション識別子１５０、利用ノード１５２、リンク／キュー１５４、利用帯域１５６、利用時間１５８及び代替通知１６０を含む。
【００４２】
セッション識別子１５０は、端末が使用しているセッションの識別子が格納される。ノード１５２は、ＱｏＳ制御（リソース割当）が実行されたノードの識別子を格納する。リンク／キュー１５４は、ＱｏＳ制御されたリンク又はキューの識別子を格納する。利用帯域１５６は、ＱｏＳ制御によって確保された帯域が格納される。利用時間１５８は、利用終了時刻を格納してもよいし、利用開始時刻及び利用時間を格納してもよい。代替通知１６０は、該当セッションが既に代替通知されているとき、重複して代替候補となることを防ぐためにフラグを設定する。
【００４３】
続いて、以上の構成によって実行されるＱｏＳ制御装置２の処理について説明する。
【００４４】
図１０は、本発明の実施の形態のＱｏＳ制御装置２によって実行される処理のフローチャートである。
【００４５】
ＱｏＳ制御装置２は、起動すると、ノード設定情報収集処理プログラム２４によって、制御対象ノードのノード設定情報を収集する（ステップ１１０）。収集されたノード設定情報は、図５に示したノード設定情報管理テーブル２８に格納される。具体的には、ＱｏＳ制御装置２は、各対象ノードに設定されたルーティング情報を収集し、ノード４０のインタフェース４２ごとに、宛先ネットワーク４４及びネクストホップ４６を記録する。
【００４６】
なお、図１０に示すフローチャートでは、ＱｏＳ制御装置２を起動した直後にノード設定情報収集プログラム２４を実行する手順を示しているが、定期的なバッチ処理で稼動させてもよい。また、ネットワークトポロジの更新などを契機として、管理者又は外部装置からのトリガによって実行してもよいし、ＱｏＳ要求が発生したタイミングで実行してもよい。
【００４７】
ノード設定情報の収集が完了すると、ＱｏＳ制御装置２は、アプリケーションサーバ３００又はセッション制御装置１などからのＱｏＳ要求を受け付ける（ステップ１１１）。ＱｏＳ制御装置２は、ＱｏＳ要求を受信すると（ステップ１１１の結果が「Ｙ」）、まず、要求条件受信処理プログラム２１によって要求内容を解析する。なお、ＱｏＳ要求でなかった場合には（ステップ１１１の結果が「Ｎ」）、ＱｏＳ要求の受信を継続する。
【００４８】
次に、ＱｏＳ制御装置２は、要求内容に基づいて、対象ノード特定処理プログラム２６を実行することによって、ＱｏＳ制御を実行する対象のノードを特定する（ステップ１１２）。具体的には、ＱｏＳ要求に含まれる宛先アドレス及び送信元アドレスに基づいて、ノード設定情報管理テーブル２８を検索し、パケットを送信する経路を選択し、経路に含まれるノード及び通信ＩＦを抽出する。
【００４９】
また、ＱｏＳ制御装置２は、検索結果からネクストホップ４６に格納された値が管理ドメインに含まれないレコードを抽出することによって、エッジノードを特定することができる。最初に送信元アドレスに接続されるエッジノードを特定することによって、対象ネットワークにおける起点を特定することができる。さらに、トポロジ情報を併用することによって、経路上のノードを特定する効率を向上させることも可能である。なお、前述のように、本発明の実施の形態では、対象ネットワークの入側と出側のエッジノードのみを対象ノードとしている。
【００５０】
ＱｏＳ制御の対象ノードが特定されると、ＱｏＳ制御装置２は、要求受付判定処理プログラム２５を実行し、ＱｏＳ要求を受入可能であるか否かを判定する（ステップ１１５）。
【００５１】
ＱｏＳ制御装置２は、ノード利用情報管理テーブル２９から対象となるノード５０及びリンク／キュー５２に対応するレコードを抽出し、対象ノードの使用状況を取得する。ＱｏＳ制御装置２は、取得した対象ノードの使用状況に基づいて、受入可否を判定する。具体的には、ＱｏＳ制御装置２は、積算使用量５６に要求された容量を加えた値と、帯域容量５４に格納された値とを比較することによって、対象ノードごとの受入可否を判定する。そして、ＱｏＳ制御装置２は、要求受付判定テーブル１８を参照し、入側のエッジノード及び出側のエッジノードの判定結果に基づいて、ＱｏＳ要求の受入可否を判定する。
【００５２】
ＱｏＳ制御装置２は、ＱｏＳ要求の受入判定結果が「可」の場合には、ＱｏＳ設定要求処理プログラム２２によって、対象ノードに対してＱｏＳ設定を実行する（ステップ１２０）。
【００５３】
ＱｏＳ制御装置２は、ＱｏＳ設定が完了すると、ノード管理情報更新処理プログラム２７を実行し、ノード利用情報管理テーブル２９の積算使用量５６を更新する（ステップ１２１）。ＱｏＳ制御装置２は、このようにＱｏＳ設定を実行した後でノード利用情報管理テーブル２９を更新してもよいし、各ノードのトラフィック状況を実際に監視して更新してもよい。また、ＱｏＳ制御装置２がトラフィック状況を監視してもよいし、外部の専用装置がトラフィック状況を監視してもよい。
【００５４】
一方、ＱｏＳ制御装置２は、ＱｏＳ要求の受入可否の判定結果が「代替提示」の場合には、割り当て可能な帯域を決定する（ステップ１１８）。割り当て可能な帯域は、ノード利用情報管理テーブル２９から対象ノード５０及び対象リンク／キュー５２に対応するレコードを抽出し、帯域容量５４と積算使用量５６との差分を算出することによって求めることができる。
【００５５】
ＱｏＳ要求のパラメータに優先度又は要求転送品質の条件が指定されている場合には、ＱｏＳ制御装置２は、まず最初に対応するリンク／キューを抽出する。このとき、要求された条件を満足することができない場合には、他の優先度又は要求転送品質に対応するリンク／キューの状況を抽出し、代替候補として通知するようにしてもよい。優先度、要求転送品質及び割当可能な帯域の双方を代替候補として通知してもよい。代替候補の選定については、詳細を後述する。
【００５６】
ＱｏＳ制御装置２は、受信したＱｏＳ要求に対する判定結果を結果応答処理プログラム２３を実行し、ＱｏＳ要求の要求元に応答する（ステップ１２３）。そして、ＱｏＳ制御装置２は、ＱｏＳ要求の受信を終了するか否かを判定する（ステップ１２４）。ＱｏＳ要求の受信の終了条件を満たしている場合には（ステップ１２４の結果が「Ｙ」）、処理を終了する。終了条件を満たしていない場合には（ステップ１２４の結果が「Ｎ」）、再びＱｏＳ要求の受信を待機する。
【００５７】
図４は、本発明の実施の形態のセッション制御装置１の構成を示す図である。セッション制御装置１は、ＣＰＵ３０、メモリ３３、記憶装置３２、及び通信ＩＦ３１を備える。
【００５８】
ＣＰＵ３０は、メモリ３３に記憶されたプログラムを実行する。メモリ３３は、ＣＰＵ３０によって実行されるプログラム及び処理に必要なデータを格納する。通信ＩＦ３１は、ネットワークを介して他の計算機と通信する。
【００５９】
記憶装置３２は、セッション制御用プログラム及びセッションの管理に必要なデータを格納する。セッション制御用プログラムは、実行時にメモリ３３に展開される。記憶装置３２は、セッション制御装置１の筐体内部に実装されても、外部記憶装置として設置されても、ネットワークを介して接続されてもよい。
【００６０】
さらに、セッション制御装置１には、管理者が操作するためのユーザインタフェースを備えてもよい。ユーザインタフェースとしては、例えば、コマンド入力のためのキーボード、ＧＵＩ入力のためのマウス、及びディスプレイなどの表示装置などがある。
【００６１】
セッション制御用プログラムは、通信制御プログラム３４、アドレス解決処理プログラム３５、中継制御処理プログラム３６及びＱｏＳ制御要求処理プログラム３７などによって構成される。各プログラムは、それぞれ異なるプロセスで実行される独立したプログラムであってもよいし、同一のプロセスで実行される単一のプログラムとして構成してもよい。
【００６２】
通信制御プログラム３４は、通信ＩＦ３１を介して受信したパケットを解析する。さらに、通信制御プログラム３４は、パケットのヘッダ情報を整形して送信する。
【００６３】
アドレス解決処理プログラム３５は、アドレス情報がＦＱＤＮ（ＦｕｌｌｙＱｕａｌｉｆｉｅｄＤｏｍａｉｎＮａｍｅ）などのドメイン形式又はＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）形式で記述されているとき、ＤＮＳ検索などを実行することによって、ＩＰアドレスを解決する。
【００６４】
中継制御処理プログラム３６は、通信ＩＦ３１を介して通信制御プログラム３４が受信したメッセージ（パケット）を処理する。ＱｏＳ制御要求処理プログラム３７は、ＱｏＳ制御装置２にＱｏＳ要求を送信する。また、ＱｏＳ制御要求処理プログラム３７は、ＱｏＳ要求に対するＱｏＳ制御装置２からの応答を受信する。
【００６５】
セッション管理テーブル３８及びメディアマッピングテーブル３９は、図４では、メモリ３３に格納されているが、記憶装置３２に格納し、実行時にメモリ３３に展開してもよい。また、記憶装置１２に格納した状態で随時アクセスされるデータベースとして構成してもよい。
【００６６】
セッション管理テーブル３８は、セッションごとの状態遷移情報が記録される。メディアマッピングテーブル３９は、メディア情報と帯域との対応が格納される。
【００６７】
図９は、本発明の実施の形態のメディアマッピングテーブル３９の構成を示す図である。セッション制御装置１は、ＱｏＳ制御装置２が提示した代替候補をメディアマッピングテーブル３９に基づいて変換し、結果をユーザ端末３Ａ又は３Ｂに送信する。
【００６８】
メディアマッピングテーブル３９は、メディア種別６０、帯域６２及びコーデック種別６４を含む。メディア種別６０は、メディアの種類が格納され、例えば、「Ａｕｄｉｏ」又は「Ｖｉｄｅｏ」などの値が格納される。帯域６２は、必要な帯域容量が格納され、コーデック種別６４は、対応するコーデックの名称が格納される。
【００６９】
図１１は、本発明の実施の形態のセッション制御装置１がアンサーを受信したときの処理フローを示すフローチャートである。アンサーとは、発側ユーザ端末が送信した要求オファーに対して、着側（相手側）ユーザ端末が送信する応答メッセージのことである。セッション制御プロトコルにＳＩＰを使用する場合には、要求オファーはＩＮＶＩＴＥメッセージに相当する。
【００７０】
セッション制御装置１は、メッセージを受信すると、中継制御プログラム３６によって受信メッセージを解析する。セッション制御装置１は、受信したメッセージがＱｏＳ要求を含むアンサーであるか否かを判定する（ステップ１４０）。受信したメッセージがＱｏＳ要求を含むアンサーでない場合には（ステップ１４０の結果が「Ｎ」）、通常のセッション制御装置として中継制御などの処理を実行する（ステップ１４５）。
【００７１】
一方、受信したメッセージがＱｏＳ要求を含むアンサーであった場合には（ステップ１４０の結果が「Ｙ」）、セッション制御装置１は、ＱｏＳ制御装置２にＱｏＳ要求を発行する（ステップ１４１）。
【００７２】
ＱｏＳ制御装置２は、ＱｏＳ要求を受信すると、パラメータとして最大要求帯域が指定された場合には、指定された最大要求帯域に基づいて、要求受付判定処理１１５を実行する（図１０のステップ１１５）。一方、ＱｏＳ要求のパラメータに最大要求帯域が指定されていない場合には、要求帯域を取得する必要がある。例えば、パラメータにメディア種別及びコーデック種別が指定されているときには、ＱｏＳ制御装置２にメディアマッピングテーブル３９と同等のメディア情報を備え、メディア種別及びコーデック種別に基づいて、要求帯域を取得すればよい。
【００７３】
なお、メディア情報は、最大要求帯域を指定する場合であっても、メディア種別及びコーデック種別を指定する場合であっても、新規メディア又は新規コーデックに柔軟に対応するために、ＱｏＳ制御装置２の外部に配置するとよい。例えば、セッション制御装置１又はアプリケーションサーバに備えられてもよい。
【００７４】
セッション制御装置１は、ＱｏＳ制御装置２からの応答メッセージを受信し、結果が「可（成功）」であった場合には（ステップ１４２の結果が「Ｙ」）、受信したメッセージをそのまま中継する（ステップ１４６）。
【００７５】
一方、ＱｏＳ制御装置２からの応答メッセージの結果が「否（失敗）」であるが（ステップ１４２の結果が「Ｎ」）、代替候補が提示されている場合には（ステップ１４３の結果が「Ｙ」）、メディアマッピングテーブル３９を参照し、対応メディアを選定する（ステップ１４４）。本発明の実施の形態では、代替候補は、帯域で通知されるため、代替候補として通知された帯域に収まるコーデックを選定する。
【００７６】
発側ユーザ端末３Ａに対する応答メッセージは、代替候補を提示する場合であっても、応答種別をエラー応答（例えば、５８０応答）として送信される（ステップ１４６）。このとき、応答メッセージの書式を拡張することによって、代替候補となるメディア情報を通知する。
【００７７】
なお、ＱｏＳ制御装置２からの応答メッセージの結果が「否（失敗）」であって（ステップ１４２の結果が「Ｎ」）、代替候補が提示されていない場合には（ステップ１４３の結果が「Ｎ」）、受信したメッセージをそのまま中継する（ステップ１４６）。
【００７８】
図１２は、本発明の実施の形態のコア網のＱｏＳ制御装置が要求されたＱｏＳ要求に対し、代替候補を提示する処理のシーケンスを示す図である。なお、図１２では、発側及び着側のアクセス網のＱｏＳ制御を省略して説明する。
【００７９】
また、本発明の実施の形態では、セッション制御プロトコルにＳＩＰを使用する。また、メディア情報は、ＳＤＰ（ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ）によって記述される。
【００８０】
ユーザ端末３Ａは、まず、相手側のユーザ端末３Ｂと通信するために、メディア情報を含むＩＮＶＩＴＥメッセージを送信する（Ｓ７０）。送信されたメッセージは、発側アクセス網のＰ－ＣＳＣＦ３１０Ａ、Ｓ－ＣＳＣＦ３１２及び着側アクセス網のＰ－ＣＳＣＦ３１０Ｂに中継されて相手側のユーザ端末３Ｂに到達する。
【００８１】
相手側ユーザ端末３Ｂは、ＩＮＶＩＴＥメッセージ（Ｓ７０）の応答として、アンサーを送信する（Ｓ７２）。アンサーは、着側アクセス網のＰ－ＣＳＣＦ３１０Ｂを経由して、Ｓ－ＣＳＣＦ３１２に送信される。また、相手側ユーザ端末３Ｂは、ＩＮＶＩＴＥメッセージ（Ｓ７０）に含まれたメディア情報のうち、通信可能なメディアをアンサーに記述する。Ｓ７２のアンサーは、ＱｏＳ要求を含むものとして以下の処理を説明する。
【００８２】
Ｓ－ＣＳＣＦ３１２は、ＱｏＳ要求を含むアンサーを受信すると（図１１のステップ１４０の結果が「Ｙ」）、ＱｏＳ制御装置３１６にＱｏＳ要求を発行する（Ｓ７４、図１１のステップ１４１）。
【００８３】
ＱｏＳ制御装置３１６は、ＱｏＳ要求を受信すると（図１０のステップ１１１の結果が「Ｙ」）、まず、ＱｏＳを適用する対象ノードを特定する（図１０のステップ１１２）。続いて、ＱｏＳ制御装置３１６は、対象ノードに要求されたリソース及び帯域を受入可能であるか否かを判定する（図１０のステップ１１５）。本発明の実施の形態では、受信したＱｏＳ要求をそのまま受け入れることはできないが、代替手段を提示することはできるものとする（図１０のステップ１１６の結果が「Ｎ」、ステップ１１７の結果が「Ｙ」）。代替候補は、前述のように、ノード利用情報管理テーブル２９を参照し、対象ノードの帯域容量５４から積算使用量５６の差を算出した容量とすることができる。
【００８４】
ここで、図６Ａのリンクごとに利用情報を管理するノード利用情報管理テーブル２９に基づいて、代替候補を選定する例を具体的に説明する。対象ノードとして、Ｎｏｄｅ１及び＃３のリンクが特定されたとき、帯域容量５４は１００ＭＢであり、積算使用量５６は９０ＭＢとなっている。要求された帯域が１５ＭＢであるとき、帯域容量５４と積算使用量５６との差は１０ＭＢであるため、受信したＱｏＳ要求を受け入れることはできない。そこで、利用可能な帯域を１０ＭＢとする代替候補を提示することができる。
【００８５】
また、ＱｏＳ制御装置３１６は、図９に示したリソース割当管理テーブル１９を参照し、指定時間後にリソースを確保するようにしてもよい。このとき、ＱｏＳ制御装置２は、対象のノード及びリンク／キューに基づいて、リソース割当管理テーブル１９から要求帯域を満たす利用帯域１５６を有するレコードを抽出する。そして、終了予定時間が最も早いセッションについて、利用時間１５８に基づいて「リソース確保可能時間」を算出して通知する。抽出されたレコードには、代替通知１６０にフラグを立てることによって、重複通知を防止する。なお、利用終了時刻を過ぎたレコードは、定期的なガベージコレクト処理によって削除される。
【００８６】
続いて、図６Ｃのキューごとに利用情報を管理するノード利用情報管理テーブル２９に基づいて、代替候補を選定する例を具体的に説明する。対象ノードとして、Ｎｏｄｅ１が特定され、品質保証（ＱｏＳ、優先制御／優先転送）による１００ＭＢの通信帯域が要求されたとき、Ｑ＃４の帯域容量が３００ＭＢであるのに対し、積算使用量が既に２５０ＭＢに達している。したがって、優先キューＱ＃４は、１００ＭＢの帯域を必要とする新たなフローを受け入れることができない。
【００８７】
そこで、ＱｏＳ制御装置３１６は、代替候補として、５０ＭＢ以下の帯域であれば受入可能と提示することができる。また、リソース割当管理テーブル１９を参照し、要求帯域（１００ＭＢ）を提供可能となる時刻を提示してもよい。さらに、非優先キュー（Ｑ＃３／Ｑ＃２／Ｑ＃１）の利用状況に基づいて、新たに１００ＭＢの帯域を提供可能であるか否かを判定し、提供可能である場合には、ベストエフォート型の通信であれば許容可能であることを提示することができる。
【００８８】
また、Ｑ＃１からＱ＃３は異なる帯域幅を有するが、すべて非優先キューである。そこで、ＱｏＳ制御装置３１６は、Ｑ＃１からＱ＃３のキューに優先度を設定し、相対的に優先度の高いキューを割り当てることも可能である。
【００８９】
さらに、ＱｏＳ制御装置３１６は、Ｑ＃１からＱ＃３を対象とするメディア種類に応じて使い分けることができる。例えば、Ｑ＃３をベストエフォート型の映像／音声通信用、Ｑ＃２をベストエフォート型のＨＴＴＰ通信用、Ｑ＃１をそれ以外のベストエフォート型通信用として運用する場合、ＱｏＳ要求の対象フローが映像音声通信であったとき、Ｑ＃３の利用状況に基づいて代替候補を提示する。
【００９０】
ＱｏＳ制御装置３１６は、代替候補が決定されると（図１０のステップ１１８）、Ｓ-ＣＳＣＦ３１２に決定した代替候補を通知する（Ｓ７６、図１０のステップ１２３）。
【００９１】
Ｓ-ＣＳＣＦ３１２は、ＱｏＳ制御装置３１６からＱｏＳ要求を受入可能であるか否かの判定結果を受信する（図１１のステップ１４２）。そして、Ｓ-ＣＳＣＦ３１２は、判定結果が受入不可であって（図１１のステップ１４２の結果が「Ｎ」）、代替候補が提示されると（図１１のステップ１４３の結果が「Ｙ」）、代替候補に対応するメディアを選定する（図１１のステップ１４４）。代替候補は、帯域で提示されるため、Ｓ-ＣＳＣＦ３１２は、メディアマップテーブル３９を参照し、提示された帯域を満たす対応メディア（コーデック種別６４）を取得する。
【００９２】
Ｓ-ＣＳＣＦ３１２は、対応メディアを取得すると、代替候補をユーザ端末３Ａに通知する（Ｓ７８、図１１のステップ１４６）。本発明の実施の形態では、通知するメッセージはＳＤＰの書式に従い、「ｍ＝」行に代替候補となるメディア情報を指定する。具体的には、「ｍ＝」行に“m=audio 20000 RTP/AVP 18 (G729）”などと記述する。さらに、「ａ＝」行で代替候補の推奨であることを示す識別子（ｒｅｃ：ｒｅｃｃｏｍｅｎｄａｔｉｏｎ）を新たに定義し、代替候補の提示であることを通知する。具体的には、「ａ＝」行に“a=rec:qos optional e2e sendrecv”などと記述すればよい。
【００９３】
一方、Ｓ-ＣＳＣＦ３１２は、判定結果が受入不可であって（図１１のステップ１４２の結果が「Ｎ」）、代替候補が提示されない場合には（図１１のステップ１４３の結果が「Ｎ」）、その旨をユーザ端末３Ａに通知する（Ｓ７８、図１１のステップ１４６）。具体的に通知するメッセージは、応答種別をエラー応答（例えば、５８０応答）とし、従来のメッセージ書式を活用し、「ａ＝」行に「ｆａｉｌｕｒｅ」識別子を指定すればよい。
【００９４】
図１３は、本発明の実施の形態の着側アクセス網のＱｏＳ制御装置が代替候補を提示する処理のシーケンスを示す図である。着側アクセス網には、ＱｏＳ制御装置であるＰＤＦ（ＰｏｌｉｃｙＤｅｃｉｓｉｏｎＦｕｎｃｔｉｏｎ）３１４Ｂが配置される。
【００９５】
ユーザ端末３Ａが相手側のユーザ端末３Ｂと通信するためにＩＮＶＩＴＥメッセージを送信し（Ｓ８０）、相手側のユーザ端末３Ｂがアンサーを送信する（Ｓ８２）手順は、図１２に示したＳ７０及びＳ７２と同じである。
【００９６】
相手側のユーザ端末３Ｂが送信したアンサーは、まず、着側アクセス網のＰ－ＣＳＣＦ３１０Ｂに送信される。Ｐ－ＣＳＣＦ３１０Ｂは、アンサーを受信すると（図１１のステップ１４０の結果が「Ｙ」）、ＰＤＦ３１４ＢにＱｏＳ要求を発行する（Ｓ８４、図１１のステップ１４１）。ＱｏＳ要求の発行（Ｓ８４）から結果応答の受信（Ｓ８６）までの手順は、図１２のＳ７４からＳ７６までの手順と同じである。
【００９７】
そして、Ｓ－ＣＳＣＦ３１２は、Ｐ－ＣＳＣＦ３１０Ｂから送信された応答メッセージ（Ｓ８８）の内容がエラー応答であった場合には、代替候補が提示されている場合も含め、ＱｏＳ制御装置３１６に対するＱｏＳ要求を発行せずにメッセージを中継する。また、発側アクセス網のＰ－ＣＳＣＦ３１０Ａも同様である。すなわち、図１１のステップ１４０において、受信したアンサーがエラー応答であった場合は、一般的なセッション制御装置として、メッセージを中継する（図１１のステップ１４５）。
【００９８】
なお、ＰＤＦ３１４ＢをＱｏＳ制御装置３１６と同等の機能を有するものとしたが、代替候補を提示する機能を有さない、ＱｏＳ要求の受入可否を判定する機能のみを有する装置とした場合も、シーケンスは同じである。受信メッセージの内容がエラー応答であった場合には、セッション制御装置は、ＱｏＳ要求を発行せずに受信メッセージを中継する。
【００９９】
図１４は、本発明の実施の形態の発側アクセス網のＱｏＳ制御装置が代替候補を提示する処理のシーケンスを示す図である。発側アクセス網には、ＱｏＳ制御装置であるＰＤＦ３１４Ａが配置される。図１４では、着側アクセス網、コア網及び発側アクセス網でそれぞれＱｏＳ要求の受入可否が判定される。
【０１００】
ユーザ端末３Ａが相手側のユーザ端末３Ｂと通信するためにＩＮＶＩＴＥメッセージを送信し（Ｓ９０）、相手側のユーザ端末３Ｂがアンサーを送信する（Ｓ９１）手順は、図１２に示したＳ７０及びＳ７２と同じである。
【０１０１】
Ｐ－ＣＳＣＦ３１０Ｂは、ユーザ端末３Ｂから送信されたアンサー（Ｓ９１）を受信すると、ＰＤＦ３１４ＢにＱｏＳ要求を送信する（Ｓ９２）。Ｐ－ＣＳＣＦ３１０Ｂは、ＰＤＦ３１４Ｂから「受入可」のメッセージ（Ｓ９３）を受信し、受信したメッセージをＳ－ＣＳＣＦ３１２に中継する（Ｓ９４）。
【０１０２】
Ｓ－ＣＳＣＦ３１２は、Ｐ－ＣＳＣＦ３１０Ｂから送信されたメッセージ（Ｓ９４）を受信すると、ＱｏＳ制御装置３１６にＱｏＳ要求を送信する（Ｓ９５）。Ｓ－ＣＳＣＦ３１２は、ＱｏＳ制御装置３１６から「受入可」のメッセージ（Ｓ９６）を受信し、受信したメッセージをＰ-ＣＳＣＦ３１４Ａに中継する（Ｓ９７）。
【０１０３】
Ｐ－ＣＳＣＦ３１０Ａは、Ｓ－ＣＳＣＦ３１２から送信されたメッセージ（Ｓ９７）を受信すると、ＱｏＳ制御装置３１６にＱｏＳ要求を送信する（Ｓ９８）。Ｐ－ＣＳＣＦ３１０Ａは、ＱｏＳ制御装置３１６から「受入不可」のメッセージ（Ｓ９９）を受信し、受信したメッセージをユーザ端末３Ａに中継する（Ｓ１００）。
【０１０４】
このように、発側のユーザ端末３Ａから相手側のユーザ端末３ＢまでのＱｏＳを確保する場合には、アンサー応答を中継するときに管理対象のネットワークに対してＱｏＳ制御をそれぞれ実行する。なお、ＱｏＳ制御は、受信メッセージの内容がエラー応答以外の場合に実行される。エラー応答の場合はＱｏＳ制御を実行せず、通常のセッション制御装置として、メッセージを中継する。
【０１０５】
図１５は、本発明の実施の形態のユーザ端末が代替候補を含むアンサー応答を受信したときに表示される端末通知ダイアログの一例を示す図である。
【０１０６】
ユーザ端末３Ａは、相手側のユーザ端末３Ｂに接続しようとし、代替候補が提示されたとき、利用者に通知するためにダイアログ２００を表示する。
【０１０７】
ダイアログ２００は、通知欄２０４、「Ｒｅｔｒｙ」ボタン２０１、「ＢｅｓｔＥｆｆｏｒｔ」ボタン２０２、及び「Ｃａｎｃｅｌ」ボタン２０３を含む。
【０１０８】
通知欄２０４には、利用者が要求したメディアを利用することができないこと、及び通信可能なメディアの代替候補を表示する。図１５で示したダイアログでは、利用者が要求したメディアが「ＰＣＭＵ」であり、提示された代替候補が「Ｇ．７２９」となっている。通知欄２０４には、メディア情報を表示する部分を除いて定型文とし、応答メッセージに含まれたメディア情報を埋め込んで表示内容としてもよい。
【０１０９】
利用者は、通知された代替候補によって通信する場合には、「Ｒｅｔｒｙ」ボタン２０１を選択し、代替候補によって再接続する。また、ＱｏＳ制御を実行せずに再接続する場合には、「ＢｅｓｔＥｆｆｏｒｔ」ボタン２０２を選択する。接続を中止する場合には、「Ｃａｎｃｅｌ」ボタン２０３を選択する。
【０１１０】
図１６は、本発明の実施の形態の発側のユーザ端末で許容する代替候補を事前設定する画面２１０の一例を示す図である。
【０１１１】
代替候補の事前設定は、「Ａｕｄｉｏ」又は「Ｖｉｄｅｏ」などメディア種別ごとに、許容レベル又は品質レベルを指定する。設定画面２１０では、チェックボックスにより許容可能なメディア情報を選択する。また、図示した項目以外にも、フローの方向（双方向／送信方向／受信方向）などを設定項目として追加してもよい。
【０１１２】
設定画面２１０は、利用帯域を示す数値を選択する形式となっているが、「ＰＣＭＵ」又は「Ｇ．７２９」などのコーデック種別を指定する形式であってもよい。コーデック種別を指定する形式では、代替候補としてコーデック種別が通知されるため、容易に比較することができる。また、利用帯域を数値で選択する形式とすると、ユーザ端末にメディアマッピングテーブルのような変換テーブルを備える必要がある。なお、ＳＩＰのようなセッション制御プロトコルのようにコーデック種別を含んだメッセージを送受信する場合には、コーデック種別そのものを設定項目とすることによって、変換テーブルが不要になり、変換処理による処理負荷を除くことができる。
【０１１３】
本発明の実施の形態では、ＱｏＳ制御装置２にＱｏＳ要求を発行する主体がセッション制御装置１である場合について説明したが、ＱｏＳ要求を発行する主体は別の装置でもよい。例えば、ＱｏＳ要求を発行する装置は、アプリケーションサーバ、ネットワークのトラフィック状況を監視するネットワーク監視装置、ネットワークの構成又は経路を制御するネットワーク管理装置でもあってもよい。なお、ＱｏＳ要求を発行するタイミングは、各装置の仕様に依存する。
【０１１４】
また、ＱｏＳ制御装置２の構成及びＱｏＳ要求のパラメータは、セッション制御装置１からＱｏＳ要求を発行する場合と同じである。さらに、ＱｏＳ制御装置２の処理手順についても、図１０のフローチャートに従って処理される。ＱｏＳ要求を発行する装置とＱｏＳ制御装置２との間で送受信されるメッセージのシーケンスについても、図１２のＳ７４のＱｏＳ要求及びＳ７６の結果応答と同じになる。
【０１１５】
本発明の実施の形態によれば、ＱｏＳ制御装置が要求されたリソース及び品質を提供可能か否かを判定し、要求された品質を提供できない場合には代替候補を選定する。そして、提示された代替候補をセッション制御装置が変換し、メディア情報として要求元に提示する。したがって、セッションの接続を要求する利用者及びアプリケーションは、要求が受け入れられなかった場合に受入可能な代替案が提示されるため、提示された代替案で再接続するか否かを判断することができる。さらに、利用者が許容可能な代替案を試行錯誤しながら再接続を繰り返す必要が無くなるため、利便性が向上し、トラフィックを削減することができる。
【図面の簡単な説明】
【０１１６】
【図１】本発明の実施の形態のＱｏＳ制御システムの構成を示す図である。
【図２】本発明の実施の形態のＱｏＳ制御システムのコア網に対する適用を示す図である。
【図３】本発明の実施の形態のＱｏＳ制御装置の構成を示す図である。
【図４】本発明の実施の形態のセッション制御装置の構成を示す図である。
【図５】本発明の実施の形態のノード設定情報管理テーブルの構成を示す図である。
【図６Ａ】本発明の実施の形態のリンク単位のノード利用情報管理テーブルの構成を示す図である。
【図６Ｂ】本発明の実施の形態のノード利用情報管理テーブルの構成を示す図である。
【図６Ｃ】本発明の実施の形態のキュー単位のノード利用情報管理テーブルの構成を示す図である。
【図７】本発明の実施の形態の要求受付判定テーブルの構成を示す図である。
【図８】本発明の実施の形態のリソース割当管理テーブルの構成を示す図である。
【図９】本発明の実施の形態のメディアマッピングテーブルの構成を示す図である。
【図１０】本発明の実施の形態のＱｏＳ制御装置の処理手順を示すフローチャートである。
【図１１】本発明の実施の形態のセッション制御装置のＱｏＳ要求手順を示すフローチャートである。
【図１２】本発明の実施の形態のコア網のＱｏＳ制御装置が代替候補を提示する処理のシーケンスを示す図である。
【図１３】本発明の実施の形態の着側アクセス網で代替候補を提示する処理のシーケンスを示す図である。
【図１４】本発明の実施の形態の発側アクセス網で代替候補を提示する処理のシーケンスを示す図である。
【図１５】本発明の実施の形態の代替候補を端末に通知するダイアログの一例を示す図である。
【図１６】本発明の実施の形態の許容可能な代替候補を端末から事前に設定する画面の一例を示す図である。
【符号の説明】
【０１１７】
１セッション制御装置
２ＱｏＳ制御装置
３Ａ、３Ｂユーザ端末
４コアノード
５エッジノード
１８要求受付判定テーブル
１９リソース割当管理テーブル
２１要求条件受信処理プログラム
２２ＱｏＳ設定要求処理プログラム
２３結果応答処理プログラム
２４ノード設定情報収集処理プログラム
２５要求受付判定処理プログラム
２６対象ノード特定処理プログラム
２７ノード管理情報更新処理プログラム
２８ノード情報管理テーブル
２９ノード利用情報管理テーブル
３７ＱｏＳ制御要求処理プログラム
３９メディアマッピングテーブル

【出願人】	【識別番号】０００００５１０８【氏名又は名称】株式会社日立製作所
【出願日】	平成１８年７月１０日（２００６．７．１０）
【代理人】	【識別番号】１０００７５５１３【弁理士】【氏名又は名称】後藤政喜【識別番号】１００１１４２３６【弁理士】【氏名又は名称】藤井正弘【識別番号】１００１２０２６０【弁理士】【氏名又は名称】飯田雅昭
【公開番号】	特開２００８－１７４０９（Ｐ２００８－１７４０９Ａ）
【公開日】	平成２０年１月２４日（２００８．１．２４）
【出願番号】	特願２００６－１８９１８２（Ｐ２００６－１８９１８２）