(57)【要約】【課題】サービスを受ける終端の端末でＱｏＳを取り扱えるようにする。【解決手段】本発明では、終端の端末２１がＱｏＳに関連する機能を取り扱い、終端点間のＱｏＳを達成する端末ベースのＱｏＳ管理スキームが行われる。端末でＱｏＳの管理を行うため、端末は、ネットワーク条件や他のエンティティの状態などを把握して、どのような操作を行うべきかを知る必要がある。例えば、端末は、パケットの監視や利用情報の収集を行い、収集されたデータをセントラルサーバ（ＳＬＡマネージャ２８）に報告する。セントラルサーバは、その管理ドメイン内のすべての端末からこれらの情報を収集する。また、セントラルサーバは、個々の端末ごとに設定されているサービスレベルなどの情報を参照して、各端末に行わせる操作を決定し、決定した動作を端末に行わせる。【選択図】        図２
2004320159.tif 000002
【特許請求の範囲】
【請求項１】
端末中心の制御を用いて、モバイルネットワークで終端点間のＱｏＳを達成するための通信システムであって、
ＱｏＳの監視し、報告し、実行することが可能なＱｏＳ制御モジュールを有する端末と、
前記端末からＱｏＳの報告を受け、前記端末の前記ＱｏＳ制御モジュールにＱｏＳの実行指示を行うセントラルコントローラと、
前記端末を利用するユーザの加入情報及びサービスレベル協定に関する情報を格納するセントラルデータベースとを、
有する通信システム。
【請求項２】
サービス及びＱｏＳの実行のためにネットワークノードに管理の決定を送信することが可能なポリシーコントロールフレームワークと、
前記ユーザの前記加入情報に基づいて、前記ユーザを認証し、前記サービス及びリソースを許可し、課金情報を収集するセキュリティコントロールフレームワークとを、
有する請求項１に記載の通信システム。
【請求項３】
前記ポリシーコントロールフレームワークを用いて情報交換を行い、ネットワークＱｏＳを実行する手段と、
前記セントラルデータベースから前記ユーザの前記加入情報を検索し、前記ユーザの前記加入情報及び前記端末のステータスに基づいて、前記端末のＱｏＳ実行を管理する手段と、
前記端末のステータスの変更を検出する手段と、
ステータスの変更が検出された場合には、前記セントラルデータベース内の前記ユーザの前記加入情報を更新することによって、前記端末のステータスを統一する手段と、
前記ユーザの前記加入情報から取得したセキュリティの関係を利用して、前記端末とのメッセージの交換を保証する手段とを、
有する請求項１又は２に記載の通信システム。
【請求項４】
各端末のＱｏＳ情報を格納するためのローカルデータベースと、
ＱｏＳ制御及び報告のために、各端末のトンネル情報を格納するためのローカルデータベースと、
前記端末が接続するネットワークのステータスに係る情報を格納するローカルデータベースとを、
有する請求項１又は２に記載の通信システム。
【請求項５】
前記端末がそのホームドメインに直接接続できない場合、前記端末から供給されるドメイン情報に従って、前記端末から前記ホームドメイン内の前記セントラルコントローラに、メッセージを確実に転送するプロキシノードと、
前記セントラルコントローラから前記端末に、メッセージを確実に転送するプロキシノードとを、
有する請求項１又は２に記載の通信システム。
【請求項６】
前記端末が接続しているネットワーク内に存在し、前記セントラルコントローラに対して、前記端末に関するネットワーク情報を報告する監視ノードと、
前記端末が接続しているネットワーク内に存在し、前記端末にサービスを提供する前記セントラルコントローラからの実行指示を実行する実行ノードとを、
有する請求項１又は２に記載の通信システム。
【請求項７】
前記端末の前記ＱｏＳ制御モジュールが、
前記端末及び動作中のすべてのアプリケーションから、ＱｏＳに係る情報を収集する監視モジュールと、
前記セントラルコントローラに前記収集されたＱｏＳに係る情報を報告し、前記セントラルコントローラから実行指示を受信する通信モジュールと、
前記通信モジュールから受信したＱｏＳのメトリックに従って、前記端末の動作を制御する実行モジュールとを、
有する請求項１又は２に記載の通信システム。
【請求項８】
前記端末の前記ＱｏＳ制御モジュールが、前記収集されたＱｏＳに係る情報を格納するためのローカルデータベースをさらに有する請求項７に記載の通信システム。
【請求項９】
前記監視モジュールが、
前記ＱｏＳに係る情報を取得して、前記端末のローカルデータベースに前記ＱｏＳに係る情報を格納するための手段と、
閾値違反を監視する手段と、
前記違反が検出された場合には、前記実行モジュールにトラフィック制御を開始させる手段とを、
有する請求項７に記載の通信システム。
【請求項１０】
前記セントラルコントローラに前記ＱｏＳに係る情報を送信する前に、公知のフォーマットで前記ＱｏＳに係る情報を梱包する手段と、
前記セントラルコントローラから受信したＱｏＳの実行に係る情報を解析する手段と、
前記セントラルコントローラから受信した前記ＱｏＳの実行に係る情報に基づいて、端末の状態を更新する手段と、
必要に応じて、前記セントラルコントローラから受信した前記ＱｏＳの実行に係る情報内の適切な修正を、前記実行モジュールに行わせる手段とを、
有する請求項７に記載の通信システム。
【請求項１１】
前記実行モジュールが、前記端末でトラフィック制御を行う手段をさらに有し、前記端末の動作を制御する請求項７に記載の通信システム。
【請求項１２】
前記実行モジュールが、
前記端末において、パケットを異なる優先順位に分類する手段と、
前記端末に割り当てられるリソース割当が使い切られた場合、前記端末において、パケット廃棄を管理する手段と、
送信レートを下げることによって、前記端末における輻輳を抑える手段と、
十分なリソースが前記端末に割り当てられない場合には、パケットの送信を遅延させることによって、前記端末における輻輳を抑える手段と、
セッションを終了してパケットの送信を中止する手段と、
現在動作しているセッションの総数を制限することによって、出力パケットを減少させる手段と、
出力を行うセッションの総数を制限することによって、入力トラフィックを減少させる手段と、
入力トラフィックを少なくする要求を行うことによって、入力トラフィックを減少させる手段とのうちの少なくとも１つ以上を有する請求項１１に記載の通信システム。
【請求項１３】
前記セントラルデータベースが、
各ユーザの前記加入情報のＱｏＳのプロフィールに関する情報と、
前記各端末のステータスに関する情報と、
ネットワーク間のサービス協定に関する情報と、
前記端末にサービスを提供するネットワークのステータスに関する情報と、
ＱｏＳを管理するためのポリシーを取り扱うメカニズムに関する情報とを、
格納する請求項１に記載の通信システム。
【請求項１４】
端末中心の制御を用いて、モバイルネットワークで終端点間のＱｏＳを達成するための通信システムであり、ＱｏＳの監視し、報告し、実行することが可能なＱｏＳ制御モジュールを有する端末と、前記端末からＱｏＳの報告を受け、前記端末の前記ＱｏＳ制御モジュールにＱｏＳの実行指示を行うセントラルコントローラと、前記端末を利用するユーザの加入情報及びサービスレベル協定に関する情報とを格納するセントラルデータベースとを有する通信システムにおける通信方法であって、
前記ＱｏＳ制御モジュールがサービスとＱｏＳ統計量を収集し、前記セントラルコントローラにフィードバックするステップと、
前記セントラルコントローラが、前記ＱｏＳ制御モジュールからＱｏＳレコードを受信するステップと、
前記セントラルコントローラが、前記端末から受信した前記ＱｏＳレコードと前記加入情報とに基づいて、ＱｏＳ管理を行うステップと、
前記セントラルコントローラが、ＱｏＳの調整のために、前記ＱｏＳ制御モジュールにＱｏＳ実行ルールを送信するステップと、
前記ＱｏＳ制御モジュールが、前記セントラルコントローラから送られてきた前記ＱｏＳ実行ルールを行い、さらに、前記ＱｏＳ制御モジュール自体も、ローカルの実行決定を行うステップとを、
有する通信方法。
【請求項１５】
前記セントラルコントローラが、前記端末のステータスに関して前記セントラルデータベースを更新するステップと、
前記セントラルコントローラが、ＱｏＳ管理のために、前記セントラルデータベースから端末の情報を取得するステップとを、
有する請求項１４に記載の通信方法。
【請求項１６】
前記通信システムが、前記端末が接続しているネットワーク内に存在し、前記セントラルコントローラに対して、前記端末に関するネットワーク情報を報告する監視ノードと、前記端末が接続しているネットワーク内に存在し、前記端末にサービスを提供する前記セントラルコントローラからの実行指示を実行する実行ノードとをさらに有しており、
前記実行ノードが、前記端末に関するネットワークステータス情報を収集するために前記端末にサービスを提供し、前記セントラルコントローラにフィードバックするステップと、
前記実行ノードが、ローカルポリシーに基づくローカルな認証制御を行うために、前記端末にサービスを提供するステップと、
前記セントラルコントローラが、ＱｏＳ管理を行い、フィードバック情報に基づいてＱｏＳ実行ルールを決定するステップと、
前記実行ノードが、前記セントラルコントローラから送られてきたＱｏＳルールを実行するために前記端末にサービスを提供するステップとを、
有する請求項１４に記載の通信方法。
【請求項１７】
前記端末が、セッションコントロールメッセージにＱｏＳ制御能力に関する情報を埋め込み、セッション開始時に、セッションを制御するサーバに対してこの情報を送信するステップと、
前記セッションを制御する前記サーバが前記ＱｏＳ制御能力に関する情報を検出した場合、前記セントラルコントローラが監視セッションを開始するステップと、
前記セントラルコントローラが、返答メッセージ内にＱｏＳ制御能力を埋め込んで、前記端末に返答するステップと、
前記セッション開始時の返答メッセージがＱｏＳ制御能力に関する情報を含む場合、前記端末が前記ＱｏＳ制御モジュールを動作させるステップとを有し、
ＱｏＳ制御を行うための、前記端末の前記ＱｏＳ制御モジュールと前記セントラルコントローラとの間の通信チャンネルを確立する請求項１４に記載の通信方法。
【請求項１８】
セッション制御メッセージ内にＱｏＳの報告情報を埋め込み、前記通信チャンネルを利用して、前記セッションコントロールサーバにその情報を送信するステップと、
前記セッションコントロールサーバが、前記セッション制御メッセージに埋め込まれている前記ＱｏＳの報告情報を分析するステップと、
前記セッションコントロールサーバが、前記ＱｏＳの報告情報を前記セントラルコントローラに送信するステップとを、
有し、前記ＱｏＳ制御モジュールから前記セントラルコントローラに対して、ＱｏＳ情報を報告する請求項１７に記載の通信方法。
【請求項１９】
前記セントラルコントローラが、前記ＱｏＳの報告情報をバックエンドデータベースに格納するステップをさらに有する請求項１８に記載の通信方法。
【請求項２０】
前記セントラルコントローラがセッション制御メッセージにＱｏＳ実行情報を埋め込み、前記通信チャンネルを利用して、前記端末のセッションクライアントにそれを送信するステップと、
前記セッションクライアントが、セッションアプリケーションによって、前記セッション制御メッセージに埋め込まれたＱｏＳ実行情報を分析するステップと、
前記セッションクライアントが、前記ＱｏＳ制御モジュールに前記ＱｏＳ実行情報を送信するステップとを、
有する請求項１７に記載の通信方法。
【請求項２１】
前記端末が、前記ＱｏＳ実行情報を前記端末のローカルデータベースに格納するステップをさらに有する請求項２０に記載の通信方法。
【請求項２２】
前記端末における監視イベントを行うための閾値及び境界値の計算と設定を行うステップと、
前記端末で前記閾値又は前記境界値違反が検出された場合、違反イベントを開始するステップと、
前記端末で前記閾値又は前記境界値違反が検出されない場合、非違反イベントを開始するステップとを、
有し、前記端末の前記ＱｏＳ制御モジュールが有する前記監視モジュールによってトラフィックの監視を行う請求項１６に記載の通信方法。
【請求項２３】
前記端末がネットワークに接続する場合のアクセス制御プロセスの際に、前記端末がＱｏＳ制御サービスを要求するステップと、
アクセス制御サーバが、前記セントラルコントローラに前記ＱｏＳ制御サービス要求の通知を行った場合に、前記セントラルコントローラが監視セッションを開始するステップと、
トンネルチャンネル情報を割り当て、前記セントラルコントローラによる前記アクセス制御サーバへの返答内に前記トンネルチャンネル情報を埋め込むステップと、
前記トンネルチャンネル情報を受信し、これを利用して、前記端末の前記ＱｏＳ制御モジュールと前記セントラルコントローラと間のトンネルチャンネルの設定を行うステップとを有し、
ＱｏＳ制御を行うための、前記端末の前記ＱｏＳ制御モジュールと前記セントラルコントローラとの間の通信チャンネルを確立する請求項１４に記載の通信方法。
【請求項２４】
前記端末のＱｏＳ情報を収集するステップと、
特定のＱｏＳ報告フォーマットに、前記ＱｏＳ情報を梱包するステップと、
前記セントラルコントローラに、前記ＱｏＳ報告を送信するステップとを、
有し、前記ＱｏＳ制御モジュールが、前記通信チャンネルを利用して、前記ＱｏＳ情報を報告する請求項２３に記載の通信方法。
【請求項２５】
前記端末のローカルデータベースに、収集された前記ＱｏＳ情報を格納するステップをさらに有する請求項２４に記載の通信方法。
【請求項２６】
前記セントラルコントローラが、前記端末から前記ＱｏＳの報告を受信するステップと、
前記セントラルコントローラが、前記受信したＱｏＳの報告と、前記バックエンドデータベースから取得したＱｏＳプロフィールとを比較するステップと、
前記セントラルコントローラが、フィードバックする前記ＱｏＳ情報を、特定のＱｏＳフィードバック報告フォーマットに梱包するステップと、
前記セントラルコントローラが、前記端末に対して、前記ＱｏＳのフィードバック情報を送信するステップとを、
有し、前記トンネルチャンネルを利用して、前記セントラルコントローラから前記端末の前記ＱｏＳ制御モジュールにフィードバックを行う請求項２３に記載の通信方法。
【請求項２７】
前記セントラルコントローラが、前記サービスを受けるユーザのＱｏＳプロフィールを前記バックエンドデータベースから読み出すステップと、
前記セントラルコントローラが、前記バックエンドデータベースから、前記中継ネットワークのＱｏＳプロフィールを読み出すステップと、
前記セントラルコントローラが、ネットワークの実行ノードから、前記中継ネットワークのステータスを取得するステップと、
前記セントラルコントローラが、前記通信チャンネルを経由する報告によって、前記端末のステータスを取得するステップと、
前記セントラルコントローラが、前期端末の状態と前記端末のＱｏＳプロフィールとを比較するステップと、
前記セントラルコントローラが、前記ネットワークの状態と前記ネットワークのＱｏＳプロフィールとを比較するステップとを、
有する請求項１９又は２５に記載の通信方法。
【請求項２８】
前記セントラルコントローラが、バックエンドデータベースに格納されているポリシーを取り扱うメカニズムに関する情報に基づいて、行われる操作を決定するステップと、
前記セントラルコントローラが、適切なＱｏＳパラメータを含む操作情報を、ＱｏＳ実行メッセージのフォーマットに梱包するステップと、
動作修正を必要とする端末の前記ＱｏＳ制御モジュールに、前記ＱｏＳ実行メッセージを送信するステップとを、
有する請求項２３に記載の通信方法。
【請求項２９】
端末中心の制御を用いて、モバイルネットワークで終端点間のＱｏＳを達成するための通信システムであり、ＱｏＳの監視し、報告し、実行することが可能なＱｏＳ制御モジュールを有する端末と、前記端末からＱｏＳの報告を受け、前記端末の前記ＱｏＳ制御モジュールにＱｏＳの実行指示を行うセントラルコントローラと、前記端末を利用するユーザの前記加入情報及びサービスレベル協定に関する情報とを格納するセントラルデータベースとを有する通信システムの前記端末における通信方法であって、
監視の必要があるＱｏＳメトリックの閾値を計算するステップと、
前記ＱｏＳメトリックの測定値が、前記計算された閾値に対して妥当な範囲内に存在しない場合、前記端末にローカルなＱｏＳ調整を行うステップと、
ＱｏＳ情報と、利用及び調整のための統計的な情報とを収集するステップと、報告のための所定のフォーマットで、前記ＱｏＳ情報を前記セントラルコントローラに送信するステップと、
ＱｏＳ実行のためのフィードバックを前記セントラルコントローラから受信するステップと、
前記セントラルコントローラからの前記フィードバックに基づいて修正を行うステップとを、
有する通信方法。
【請求項３０】
収集した前記ＱｏＳのデータで、前記端末のローカルデータベースを更新するステップと、
前記セントラルコントローラから受信した前記ＱｏＳ実行のためのフィードバックで、前記端末のローカルデータベースを更新するステップとを、
有する請求項２９に記載の通信方法。
【請求項３１】
前記端末に前記ローカルなＱｏＳ調整を行うために、前記端末でのパケットの送信を遅延する請求項２９に記載の通信方法。
【請求項３２】
前記端末に前記ローカルなＱｏＳ調整を行うために、前記端末でのパケットを廃棄する請求項２９に記載の通信方法。
【請求項３３】
前記端末に前記ローカルなＱｏＳ調整を行うために、前記端末でのパケット送信レートを低減する請求項２９に記載の通信方法。
【請求項３４】
前記端末に前記ローカルなＱｏＳ調整を行うために、前記端末での受信チャンネルの要求を抑制する請求項２９に記載の通信方法。
【請求項３５】
前記端末に前記ローカルなＱｏＳ調整を行うために、前記端末が開始した送信／受信セッションをすぐに終了する請求項２９に記載の通信方法。
【請求項３６】
前記端末から前記セントラルコントローラへの報告情報のデータフォーマットが、
異なった入力メッセージを識別するためのメッセージＩＤと、
ステータスを報告するためのメッセージ全体の長さを示すメッセージ長と、
ＱｏＳのタイプとその値とを有する属性値ペアを含むＱｏＳ報告データとを、
有する請求項１４に記載の通信方法。
【請求項３７】
前記セントラルコントローラから前記端末へのＱｏＳ実行情報のデータフォーマットが、
異なった入力メッセージを識別するためのメッセージＩＤと、
実行すべき操作を指示する操作ＩＤと、
前記操作ＩＤに関連したパラメータを含むＱｏＳ実行データとを、
有する請求項１４に記載の通信方法。
【請求項３８】
所定のテンプレートを参照して、前記操作ＩＤをチェックするステップと、
前記所定のテンプレートに従って、前記ＱｏＳ実行データを梱包又は抽出するステップとを、
有し、前記ＱｏＳ実行データの前記操作ＩＤをエンコード及び／又はデコードする請求項３７に記載の通信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信システムおよび通信方法に関し、特に、無線技術を利用したモバイルネットワークにおける無線通信システム及び無線通信方法に関する。また、本発明は、終端点間のＱｏＳを保証するために、異種のネットワーク環境においても、適用可能である。
【０００２】
【従来の技術】
ＩＰネットワークは、元来、ベストエフォート型トラフィックを運ぶように設計された。ベストエフォート型サービスでは、パケットの伝送は保証されていない。リアルタイムのマルチメディアアプリケーションなどのように遅延に敏感なアプリケーションにとって、データは、利用可能となるように限定された特定の遅延内に到着する必要がある。したがって、これらのアプリケーションは、これらのデータが利用可能となるよう、ネットワークから時間通りに適切に到着するための、あるレベルのサービス保証を必要とする。しかしながら、ベストエフォート型サービスは、これらのアプリケーションの必要条件を満たすには十分でない。
【０００３】
したがって、サービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）のサポートは、サービスを受けるユーザに対してあるレベルのサービス保証を提供するために、システム内で必須の要素となっている。システムにＱｏＳを提供する非常によく使用されている２つの方法として、統合サービス（Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅ：ＩｎｔＳｅｒｖ）（下記の非特許文献１）及び分化サービス（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅ：ＤｉｆｆＳｅｒｖ）（下記の非特許文献２）、又はそれらの変異が使用されている。
【０００４】
ＩｎｔＳｅｒｖフレームワークは、個々のアプリケーションセッション（フロー）に特化したＱｏＳ保証を提供するために、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）で発展した。それは、終端点間のＱｏＳを確実に満足させるのに十分なリソースを予約することができる個々のセッションを必要としている。また、ＩｎｔＳｅｒｖは、個々のフローに基づいて動作する。ＩｎｔＳｅｒｖでの各フローのリソース予約は、ルータがリソース予約を処理してルータを通る各フローのフロー状態を保持する必要性を含んでいる。これによって、大量のオーバヘッドが各フローのそれぞれの状態を保持することになり、ＩｎｔＳｅｒｖの解決策はあまりスケーラブルではない。
【０００５】
スケーラビリティの問題を解決するために、ＤｉｆｆＳｅｒｖの解決策が、後にＩＥＴＦによって推奨されている。ＤｉｆｆＳｅｒｖの解決策では、同様の特徴を有するフローがクラスに集められる。クラスの数は、ＤｉｆｆＳｅｒｖフレームワークをサポートするネットワークによって、あらかじめ定められる。このフレームワークでは、パケットは、ＩＰヘッダ（ＤＳＣＰ：Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｃｏｄｅ  Ｐｏｉｎｔ）の数ビットでパケット自身の状態を運び、各フローの状態を維持するためにルータを必要としない。そのうえ、ＩｎｔＳｅｒｖとは対照的に、同一のフローにおけるパケットは同一のパスに従わないこともある。各パケットは、このＤＳＣＰに基づく特別の転送の取り扱いを受ける。このＤＳＣＰの値は、このパケットがどのように取り扱われるかを決定して、例えば、高い優先度のＤＳＣＰを持つパケットが、まず転送されることになる。
【０００６】
通常、ＩｎｔＳｅｒｖとＤｉｆｆＳｅｒｖのサポートはネットワークで扱われ、終端の端末は、これらの取り扱いが行われていることを知らない。あらゆるマーキング、スケジューリング、ポリシングは、終端の端末の代わりに、ネットワークにおけるネットワーク構成要素によって実行される。これらの方法によって、個々の終端の端末ではなく、ネットワークが、全体として、現在のネットワーク条件に基づくＱｏＳに関連する機能性を取り扱う。したがって、端末自体がどのような状態にあるかをより良く知っているときには、より良い終端点間のＱｏＳを提供するために、終端の端末自体がＱｏＳの機能性の取り扱いを実行する必要がある。
【０００７】
【非特許文献１】
ＩＥＴＦ  Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅ  ｗｏｒｋｉｎｇ  ｇｒｏｕｐ
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｉｎｔｓｅｒｖ−ｃｈａｒｔｅｒ．ｈｔｍｌ
【非特許文献２】
ＩＥＴＦ  Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｄｉｆｆｓｅｒｖ−ｃｈａｒｔｅｒ．ｈｔｍｌ
【非特許文献３】
ＩＥＴＦ  Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  （ＲＦＣ２２０５）
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２２０５．ｔｘｔ；
【非特許文献４】
３ＧＰＰ
ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ
【非特許文献５】
３ＧＰＰ２
ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ２．ｏｒｇ
【非特許文献６】
“  Ｎｅｔｗｏｒｋ  Ａｒｃｈｉｔｅｃｔｕｒｅ”  ３ＧＰＰ  ＴＳ  ２３．００２  Ｖ５．８．０  （２００２−０９）
ｆｔｐ：／／ｆｔｐ．３ｇｐｐ．ｏｒｇ／ｓｐｅｃｓ／ａｒｃｈｉｖｅ／２３＿ｓｅｒｉｅｓ／２３．００２／
【非特許文献７】
ＳＩＰ  ：  Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ    ＲＦＣ２５４３
【非特許文献８】
ＳＤＰ  ：  Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ    ＲＦＣ２３２７
【非特許文献９】
ＥＡＰ  ＡＫＡ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ａｒｋｋｏ−ｐｐｐｅｘｔ−ｅａｐ−ａｋａ−０８．ｔｘｔ
【非特許文献１０】
“Ｐａｒｔ  １１：  Ｗｉｒｅｌｅｓｓ  Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  （ＭＡＣ）  ａｎｄ  ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  （ＰＨＹ）  ｓｐｅｃｉｆｉｃａｔｉｏｎｓ：  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｆｏｒ  Ｅｎｈａｎｃｅｄ  Ｓｅｃｕｒｉｔｙ”
ＩＥＥＥ  Ｓｔｄ  ８０２．１１ｉ／Ｄ３．０，  Ｎｏｖｅｍｂｅｒ  ２００２
【非特許文献１１】
“ＩＥＥＥ  Ｓｔａｎｄａｒｄ  ｆｏｒ  Ｌｏｃａｌ  ａｎｄ  Ｍｅｔｒｏｐｏｌｉｔａｎ  Ａｒｅａ  Ｎｅｔｗｏｒｋｓ  Ｐｏｒｔ−Ｂａｓｅｄ  Ｎｅｔｗｏｒｋ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ”
ＩＥＥＥ  Ｓｔｄ  ８０２．１ｘ−２００１
【非特許文献１２】
“ＤＲＡＦＴ  ＩＥＥＥ  Ｓｔａｎｄａｒｄ  ｆｏｒ  Ｌｏｃａｌ  ａｎｄ  Ｍｅｔｒｏｐｏｌｉｔａｎ  Ａｒｅａ  ＮｅｔｗｏｒｋｓＰｏｒｔ  Ｂａｓｅｄ  Ｎｅｔｗｏｒｋ  Ａｃｃｅｓｓ  ＣｏｎｔｒｏｌＡｍｅｎｄｍｅｎｔ  １：  Ｔｅｃｈｎｉｃａｌ  ａｎｄ  Ｅｄｉｔｏｒｉａｌ  Ｃｏｒｒｅｃｔｉｏｎｓ”
ＩＥＥＥ  ＤＲＡＦＴ        Ｐ８０２．１ａａ／Ｄ４  Ｎｏｖｅｍｂｅｒ  ５，  ２００２
【非特許文献１３】
ＩＴＵ−Ｔ  Ｚ．１２０  Ｍｅｓｓａｇｅ  Ｓｅｑｕｅｎｃｅ  Ｃｈａｒｔ，  １１／１９９９
【非特許文献１４】
Ｆｌｏｙｄ，  Ｓ．，  ａｎｄ  Ｊａｃｏｂｓｏｎ，  Ｖ．，  Ｒａｎｄｏｍ  Ｅａｒｌｙ  Ｄｅｔｅｃｔｉｏｎ  ｇａｔｅｗａｙｓ  ｆｏｒ  Ｃｏｎｇｅｓｔｉｏｎ  Ａｖｏｉｄａｎｃｅ  Ｖ．１  Ｎ．４，  Ａｕｇｕｓｔ  １９９３，  ｐｐ．３９７−４１３
【非特許文献１５】
Ｄ．  Ｃｌａｒｋ  ａｎｄ  Ｗ．  Ｆａｎｇ，  “Ｅｘｐｌｉｃｉｔ  ａｌｌｏｃａｔｉｏｎ  ｏｆ  ｂｅｓｔ  ｅｆｆｏｒｔ  ｐａｃｋｅｔ  ｄｅｌｉｖｅｒｙ  ｓｅｒｖｉｃｅ”，  ＩＥＥＥ  Ｔｒａｎｓ．  Ｎｅｔｗｏｒｋｉｎｇ，  ６（４），  １９９８，  ｐｐ．３６２−３７３．
【０００８】
【発明が解決しようとする課題】
昨今、サービス品質（ＱｏＳ）のサポートは、良いシステムを作る必須要素の１つとなっている。従来、ＱｏＳは、ユーザに対してサービスを提供するネットワークによって扱われる。端末は、アプリケーションレベルでＱｏＳ処理を行うのみであり、例えば、ＲＳＶＰ（非特許文献３）を利用して、アプリケーションの要求に基づいて、ネットワークから所定のリソースを要求する。しかし、無線環境では、ＲＳＶＰはもはやＱｏＳ制御には適していない。移動端末は、その接続点を随時変え、その結果、１回のサービスセッションが終わる前でさえ、異なったデータパスを使用することがある。さらに、ＲＳＶＰは、データパスに沿ったあらゆるノードに対してサポートを要求するので、大きく複雑なシステムでは必ずしも可能なものではない。
【０００９】
終端点間のＱｏＳに着目した場合、コンテンツの受信者でありサービスのユーザである移動端末が、常に一方の終端を構成している。すなわち、端末は、必ずＱｏＳ制御に参加しなければならない。従来のネットワークに基づくＱｏＳ制御はローカライズされており、すなわち、その制御はローカルネットワークの条件にのみ基づいている。例えば、いくつかのネットワークを通じて別の端末に２Ｍｂｐｓのトラフィックを送る端末では、それぞれのネットワークにおいてパケットが失われてしまうかもしれない。また、それぞれのネットワークは、別々にその制御を実行しており、この種の非調整制御は最適化されず効率が悪い。しかしながら、移動端末はトラフィックの最終消費者なので、この移動端末で行われるＱｏＳに関するすべての情報を有しており、この情報を使用してＱｏＳの制御を行うシステムでは、ユーザはより良いサービスを得ることが可能である。
【００１０】
また、ネットワークを中心とするＱｏＳ制御（中継ネットワーク内のネットワークエレメントなどで行われるＱｏＳ制御）では、ネットワークは、トラフィックの輻輳を軽減するために、唯一、キューイング（ｑｕｅｕｉｎｇ：パケットの転送順序制御）又はドロッピング（パケットの廃棄制御）のみを行うことができたが、これによって、問題が完全に解決することができたというわけではない。例えば、端末が速く送信を行うことによって輻輳が生じる場合には、ネットワークのドロッピングやキューイングを実行することによって、当該端末又はその他の端末が悪いサービスを受けることになってしまう。したがって、より良い方法によって、ソースや移動端末がそのトラフィックのスケジューリングを適切な方法で実行することが許容されるべきであり、移動端末用のシグナリングやトラフィック制御を発展させることが必要である。
【００１１】
ネットワークがＱｏＳ管理を実行することができないという極端な場合でも、端末中心のＱｏＳ制御が、依然として、ある程度のＱｏＳ保証を行う可能性がある。端末自体が動作を行い、不必要にネットワークに負荷をかけなければ、完全に輻輳を回避することが可能となる。
【００１２】
【課題を解決するための手段】
上記の問題を解決するため、本発明では、ネットワークから端末に、ＱｏＳ制御モジュールを移す。端末はトラフィックの条件を知り、ネットワークにその制御を任せる代わりに、修正が必要な場合には、端末自体で修正を行うようにしている。これによって、トラフィックを不必要に輻輳させないようにすることが可能となり、ＱｏＳに関連するすべての機能を取り扱うネットワーク管理システムに依存しないようにすることができる。
【００１３】
さらに、ネットワーク管理システムが存在する場合には、付加的なレベルで管理を行うことができるという利点もある。また、ネットワーク管理システムが存在しない場合でも、例えば、より低い送信レートで送信を行ったり、より低い優先度への設定を示すパケットを送信したりするなど、端末自体が、ＱｏＳの実施と動作の修正を適応させる能力を有する。また、ＱｏＳに関する能力がないネットワークでも、このネットワークに接続する端末がすべての動作を行うことが可能ならば、端末は、依然として所定のレベルのＱｏＳを保持することが可能である。
【００１４】
また、終端の端末自体は、ネットワークの状態に合わせて送信の容量を知る必要がある。ネットワークの条件を知るためには、セントラルサーバなどの集中化されたエンティティが、実際のデータ及びネットワークの条件を集めて統合して、各端末にフィードバック修正を行う必要がある。
【００１５】
【発明の実施の形態】
本発明は、より有効な終端点間のＱｏＳ管理を行うため、ＱｏＳの管理機能を端末に移すようにしている。移動端末は、その送信レートを管理したり、さらには取得する要求の数を制御することによって受信レートを管理したりするなどのＱｏＳの管理能力を備えており、本発明は、移動端末のユーザとサービスプロバイダとの間のサービスレベル協定に直接基づいて、すべての端末を監視する中央サーバ（セントラルサーバ）を有している。セントラルサーバは、ユーザのホームネットワークに存在する。このホームネットワークは、ユーザがサービスに加入しているネットワークである。また、端末は、報告及び監視を行うＱｏＳ制御モジュールを有している。このＱｏＳコントローラも、どの値が変更されるべきなのかを端末に告げる実施データを受信した場合でも、動作変更に反応することが可能であり、その後は、ＱｏＳコントローラは新しい値の閾値及びその範囲内で動作を行う。
【００１６】
以下、通信ネットワークに基づいて、端末をパケットのＱｏＳサービスコントロールに順応させるための装置及び方法が開示される。本発明の理解を助けるため、次の定義を使用する。
【００１７】
「ＷＬＡＮ」は、ワイヤレスローカルエリアネットワークを示す。これは、無線技術を通じて、移動端末に対してＬＡＮサービスを提供するために、任意の数のデバイスを含むものである。
【００１８】
「３Ｇネットワーク」は、第３世代の公衆アクセスネットワークを示す。例えば、３ＧＰＰ（非特許文献４）又は３ＧＰＰ２（非特許文献５）によって定義されるシステムである。
【００１９】
「移動端末（Ｍｏｂｉｌｅ  Ｔｅｒｍｉｎａｌ：ＭＴ）」は、無線技術を通じて、ＷＬＡＮやその他のネットワークによって提供されるサービスへのアクセスに使用されるデバイスを示す。
【００２０】
「ホームネットワーク」は、移動端末の相互接続のシナリオにおいて、移動端末が最初に属しているネットワークを示す。
【００２１】
「移動先ネットワーク」は、移動端末が接続するネットワークを示す。このネットワークは、移動端末にアクセスサービスを提供するものである。
【００２２】
「ネットワークエレメント」は、情報処理を行うネットワークで機能するあらゆるデバイスを示す。
【００２３】
「ルールエンジン」は、下記のルールサーバによって設定され、下記のルールインタプリタによってローカルに特有のコマンドに解釈されるルールを実行するネットワークエレメントを示す。
【００２４】
「ルールインタプリタ」は、下記のルールサーバによって与えられるルールを読み込み、適切なパラメータを用いてローカルの技術に特有のコマンドに解釈して、そのコマンドを実行するルールエンジンに対して供給するネットワークエレメントを示す。
【００２５】
「ルールサーバ」は、ルールインタプリタやルールエンジンに対して、要求を受けた場合又は要求を受けずに、適切なルールのセットを送信するネットワークエレメントを示す。
【００２６】
「エアインタフェース」は、移動端末がＷＬＡＮにアクセスするためのあらゆる無線アクセス技術を示す。
【００２７】
「ストリーム」は、所定の属性が共通であり、ネットワークで転送されるパケットの集まりである。
【００２８】
「トラフィック」は、ネットワークで転送されるストリームの集まりである。
【００２９】
「フロー」は、データパスや、ストリームを伝送するときに使用されるデータパスに必要なネットワークリソースを示す。
【００３０】
「ＱｏＳ」は、データストリーム又はトラフィックのサービス品質（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）を示す用語である。
【００３１】
「メッセージ」は、相互接続を制御するために、ネットワークエレメント間で交換される情報を示す。
【００３２】
「動作シーケンス」は、相互接続の制御に関して、任意のネットワークエレメント間で任意の順序で交わされる一連のメッセージ交換を示す。
【００３３】
「上位レイヤ」は、あるエンティティから渡されたパケットを処理する、当該エンティティの上部に位置するあらゆるエンティティを示す。
【００３４】
「ＳＬＡ」は、サービスレベルの協定（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ：サービスレベルアグリメント）を示す。
【００３５】
「ユーザＳＬＡ」は、サービスプロバイダとユーザとの間のサービスレベルアグリメントを示す。
【００３６】
「ネットワークＳＬＡ」は、サービスプロバイダと別のサービスプロバイダとの間のサービスレベルアグリメントを示す。
【００３７】
「ＡＡＡ」は、移動端末へのサービス提供に関する認証（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）、許可（Ａｕｔｈｏｒｉｚａｔｉｏｎ）、課金（Ａｃｃｏｕｎｔｉｎｇ）を示す。
【００３８】
以下の説明では、本発明を完全に理解できるよう、具体的な数、時間、構造、プロトコルの名前、その他のパラメータが使用されるが、このような具体的な詳述がなくても、本発明の実施が可能なことは当業者にとって明白である。また、各事例では、本発明を不明瞭なものとしないよう、よく知られた構成要素やモジュールがブロック図で示される。
【００３９】
図１は、本発明の実施の形態における端末ベースの制御で終端点間のＱｏＳを実現する構成を示す模式図である。ここでは、システムアーキテクチャとして、３Ｇネットワークなどが用いられているが、同様のアーキテクチャや制御方式を有する他のネットワークにも適用可能であることは、当業者にとって明白である。
【００４０】
各移動端末（以下、単に端末とも呼ぶ）１１には、端末のＱｏＳコントローラモジュール１１Ａがインストールされている。この端末ＱｏＳコントローラモジュール１１Ａは、トラフィック調整、動作監視、パケットの再スケジューリングなどのＱｏＳ管理を実行する能力を有している。アクセスポイント１２は、移動先ネットワーク１３への端末の接続点である。移動先ネットワーク１３は、端末へのアクセスサービスを提供するネットワークであり、１つ又は複数の中継ネットワーク１７を介して端末のホームネットワーク１６と接続している。中継ネットワーク１７は、例えば、ＩＰバックボーンやＡＴＭネットワークなどを始めとして、どのようなタイプのものでもよい。
【００４１】
また、ポリシーアテンダント１４は、各移動先ネットワーク１３に存在している。このポリシーアテンダント１４は、移動先ネットワーク１３のルールエンジンとして機能し、移動先ネットワーク１３におけるＱｏＳ制御を実施するために、ポリシーコントロールフレームワークによって取得されるルールを実行する。また、ポリシーアテンダント１４は、移動先ネットワーク１３におけるローカルポリシーに基づいて、接続許可の制御を行う。
【００４２】
ＳＬＡマネージャ１５は、ホームネットワーク１６に存在する特別なサーバであり、このネットワークに加入するあらゆるユーザのＳＬＡに関する情報を有するＳＬＡデータベース１８を含むメインデータベースにアクセスを行う。また、ＳＬＡデータベース１８は、例えば、位置やサービス利用情報などの各ユーザのサービスステータスを含んでいる。３Ｇネットワークでは、このようなデータベースの一例として、ＨＳＳ６サーバ（非特許文献６）が挙げられる。また、ＳＬＡマネージャ１５は、ホームネットワーク１６における処理サーバとして機能し、ユーザの加入プロフィールやネットワークポリシーに基づいて、サービス提供の決定を行う。この決定は、ポリシーコントロールフレームワークによって各ネットワークのポリシーアテンダント１４や、本発明のシグナリング方法によって移動端末１１に伝えられる。
【００４３】
移動端末１１及びポリシーアテンダント１４は、望ましいＱｏＳでユーザにサービスを提供するために、適切に動作を行うことが可能である。また、ここで使用されるポリシーコントロール方法は、ネットワーク配置に依存する。なお、本発明では、既存のポリシーコントロールフレームワークを利用し、ポリシーコントロールフレームワークに付加的な条件を与えるものではない。また、本実施の形態では、シグナリングはＩＰに基づくプロトコルによって行われるが、例えば、ＳＳ７やＡＴＭなどの他の通信プロトコルによる実現が可能であることは、当業者にとって明白である。
【００４４】
端末はモバイルなので、異なる接続点で異なるネットワークに接続することが可能である。端末が接続するネットワークは、そのホームネットワーク１６又は移動先ネットワーク１３（ホームネットワーク１６以外のあらゆるネットワーク）である。端末が直接ホームネットワーク１６に接続する場合には、直接ＳＬＡマネージャ１５に接続する信号経路が保証される。また、端末が移動先ネットワーク１３に接続する場合には、端末によるすべての要求が、移動先ネットワーク１３に送られる必要があり、移動先ネットワーク１３はその要求をホームネットワーク１６に転送する必要がある。すなわち、ホームネットワーク１６と移動先ネットワーク１３とによって双方向の通信が行われる。このような状況における移動端末１１への信号経路を確立する方法はいくつか存在しており、それらは以下のようにして導入される。
【００４５】
図２は、本発明の実施の形態における端末中心のＱｏＳ制御フレームワークの詳細なアーキテクチャを示すブロック図である。なお、この図では、シグナリング及び制御に係るもののみが示され、それらに無関係なエンティティは省略されている。このアーキテクチャでは、セッション管理プロトコルが、端末のＱｏＳ報告及びフィードバック制御に利用される。例えば、セッション管理プロトコルとしては、ＳＩＰが使用可能である。なお、必要最小限の改変によって、他のセッション管理プロトコルでも動作することは、当業者にとって明白である。以下に、このアーキテクチャでの各モジュールの機能を簡潔に説明する。
【００４６】
端末２１は、ユーザ機器であり、例えば、移動端末である。これは、図１の端末１１及びＱｏＳコントローラモジュール１１Ａと同等のものである。
【００４７】
ＳＩＰアプリケーション２２は、セッション管理の基本的なプロトコルであるＳＩＰを使用する端末２１のアプリケーションである。
【００４８】
ＱｏＳコントローラ２３は、端末２１でＱｏＳを管理するエンティティであり、パケットの再スケジューリング、パケットのキューイング、パケットの廃棄、実行されるリクエストの量の調節などの動作監視やトラフィック調整を行う。これは、図１に示されるＱｏＳコントローラモジュール１１Ａの一例である。
【００４９】
移動先ネットワーク２４は、端末２１が現在接続しているネットワークである。
【００５０】
移動先ネットワーク２４におけるＳＩＰプロキシ２５は、実際の目的地に対してＳＩＰメッセージを転送するポイントとして機能する。
【００５１】
ポリシーアテンダント２６は、移動先ネットワーク２４のローカルな処理を管理する機能を有し、ポリシーコントロールフレームワークによって、ホームネットワーク２７のＳＬＡマネージャ２８と接続する。
【００５２】
ホームネットワーク２７は、端末２１がサービスに加入するネットワークである。
【００５３】
ＳＬＡマネージャ２８は、ＳＬＡデータベース２９にアクセスして、ユーザ報告を集め、ＱｏＳの取り扱い及び実施を決定するコントローラモジュールである。
【００５４】
ＳＬＡデータベース２９は、すべてのＳＬＡを格納する集中データ格納手段であり、ユーザとサービスプロバイダとの間のＳＬＡや、サービスプロバイダ間のＳＬＡを含んでいる。さらに、例えば、その位置や要求されたサービスなどの各ユーザに関するサービスステータスをも保持している。ホームＳＩＰプロキシ３０は、ホームネットワーク２７に存在するＳＩＰプロキシである。
【００５５】
図３は、図２のアーキテクチャで使用される、端末が直接ホームネットワークに接続していない場合のＱｏＳの報告及びフィードバックのためのシグナリングを示すシーケンスチャートである。端末２１は、移動先ネットワーク２４に接続し、ホームネットワーク２７へのダイレクトＩＰ接続を利用することはできない。ホームネットワーク２７によって提供されるサービスにアクセスするため、端末２１は、あるセッション管理メカニズムを使用する必要があり、この例では、ＳＩＰが図示されている。なお、他のセッション管理プロトコルでも動作可能なことは、当業者にとっては明白である。
【００５６】
端末２１が要求先パーティ（Ｃａｌｌｅｅ  ｐａｒｔｙ）とのセッションを開始する場合、ＳＩＰアプリケーション２２によって、対応するセッション記述プロトコルで、ＳＤＰメッセージとしても知られている“ＩＮＶＩＴＥ”を発行する（３０１：ＩＮＶＩＴＥ（ＳＤＰ））。ＳＤＰ内には、この端末にＱｏＳ制御能力があることを示すＱｏＳ制御能力タグが埋め込まれる。“ＩＮＶＩＴＥ”メッセージは、まず、移動先ネットワーク２４のＳＩＰプロキシ２５を通る。移動先ネットワーク２４のＳＩＰプロキシ２５はこのパケットを調べて、ホームネットワーク２７のホームＳＩＰプロキシ３０にＳＩＰメッセージを転送する（３０２：ＩＮＶＩＴＥ（ＳＤＰ））。ホームＳＩＰプロキシ３０は、ホームネットワーク２７に存在するＳＩＰプロキシであり、さらなる処理のためにこの要求を他のエンティティに転送する前に、要求されたサービスの許可を行うＳＬＡマネージャ２８に、このサービス要求をチェックさせる（３０３：Ｃｈｅｃｋ  Ｓｒｖ  Ｒｅｑ）。なお、この情報は、ＳＬＡデータベース２９に格納されている要求元のＳＬＡの一部である。
【００５７】
ＳＬＡマネージャ２８は、要求元のＳＬＡを保持していない場合には、ＳＬＡデータベース２９から要求元のＳＬＡを抽出する動作を行い（３０４：ＣｈｅｃｋＳＬＡ）、ＳＬＡデータベース２９は、ＳＬＡマネージャ２８に対してサービスを許可し、要求元のＳＬＡ情報を渡す（３０５：ＳＬＡ  ＯＫ）。このとき、渡されるＳＬＡ情報は、ユーザのＳＬＡの完全なものでなくてもよく、メッセージ（ＣｈｅｃｋＳＬＡ）でＳＬＡマネージャ２８によって示されたサービス要求に関した情報のみを含めればよい。要求元のＳＬＡに基づいてサービスが許可された場合には、ＳＬＡマネージャ２８は、セッション処理を続けるようにホームＳＩＰプロキシ３０に通知を行う（３０６：Ｓｒｖ  Ｒｅｑ  ＯＫ）。一方、サービスが許可されない場合には、ＳＬＡマネージャ２８は、セッション要求を拒絶して、以降の処理を中止する。
【００５８】
次に、サービス要求に応じて、ホームＳＩＰプロキシ３０は、さらなる処理を行うために、例えば、サービスを要求されているホームＳＩＰプロキシなどのサービスプラットフォームに対して、ＳＩＰメッセージを転送する（３０７：サービスプラットフォームへのＲｅｑの転送）。この処理３０７でのサービスプラットフォームの処理が成功の場合には、ホームＳＩＰプロキシ３０は、ＳＩＰ１８３メッセージを受け取る（非特許文献７、８）。端末２１からのＳＤＰメッセージにＱｏＳ制御能力タグが含まれている場合には、ホームＳＩＰプロキシ３０は、ＳＬＡマネージャ２８に“Ｓｔａｒｔ  ＰＭＳｅｓｓｉｏｎ”メッセージを発行する（３０８：Ｓｔａｒｔ  ＰＭＳｅｓｓｉｏｎ）。この“Ｓｔａｒｔ  ＰＭＳｅｓｓｉｏｎ”を受けた場合、ＳＬＡマネージャ２８は、監視セッションを開始することとなる。
【００５９】
また、必要に応じて、ＳＬＡマネージャ２８は、ＳＬＡデータベース２９に格納されたユーザのＳＬＡをアップデートする（３２４：ＳＬＡ更新）。なお、必要に応じてＳＬＡを更新するメカニズムと同一のものを適用することができることは、当業者にとっては明白である。また、同時に、ホームＳＩＰプロキシ３０は、ＱｏＳ制御能力タグが埋め込まれたＳＩＰ１８３メッセージを、移動先ネットワーク２４のＳＩＰプロキシ２５に中継する（３０９：ＳＩＰ  １８３（ＳＤＰ））。この承認メッセージ（ＳＩＰ１８３メッセージ）のＱｏＳ制御能力タグは、端末２１にＱｏＳコントローラモジュールを開始できることを告げるものである。このメッセージを端末２１に転送する前に、移動先ネットワーク２４のＳＩＰプロキシ２５は、ポリシーアテンダント２６と共に端末２１が移動先ネットワーク２４のリソースの使用を許可されるか否かをチェックする（３１０：Ａｕｔｈ  ｒｅｑ（ＳＤＰ））。
【００６０】
要求されたサービスが許可される場合には、リソースが利用可能な場合には、許可を示す情報（Ａｕｔｈｏｒｉｚｅ  Ｔｏｋｅｎ：オーソライズトークン）が、ポリシーアテンダント２６から移動先ネットワーク２４のＳＩＰプロキシ２５に送られる（３１１：Ａｃｋ（Ａｕｔｈ  ｔｏｋｅｎ））。オーソライズトークンを受信した後、移動先ネットワーク２４のＳＩＰプロキシ２５は、端末２１に対して、このトークンと共にＳＩＰ１８３メッセージを転送する（３１２：ＳＩＰ  １８３（ＳＤＰ，  Ａｕｔｈ  Ｔｏｋｅｎ））。端末２１は、このメッセージを受け取った場合には、ＱｏＳコントローラ２３にこのセッションに関する情報を通知して、ＱｏＳコントローラ２３の動作が開始される（３１３：Ｓｔａｒｔ  ＱｏＳ  Ｃｏｎｔｒｏｌｌｅｒ）。
【００６１】
ポリシーアテンダント２６が、ローカルポリシー、又は、リソースが制限されているという理由によって、サービスを許可することができない場合には、メッセージ３１１には無効を示す情報が含まれることになる。この無効を示す情報を受信した場合、移動先ネットワーク２４のＳＩＰプロキシ２５は、ＳＩＰ１８３メッセージをユーザに送らず、代わりに、端末２１に対して、無効を示す情報と共にＳＩＰ４８８エラーメッセージを送る。端末２１が無効を示す情報を受け取ると、端末２１は、ＳＩＰプロキシ２５を介して、セッションを閉じる通るための“ＢＹＥ”メッセージを開始する。なお、許可に失敗した場合のシナリオにおけるこのメッセージ交換処理は、図３では図示省略している。
【００６２】
端末２１がＳＩＰ１８３メッセージを受信した後、端末２１は、ＳＩＰで制御された通常のサービスセッションを開始する（３１４：ユーザセッション）。このサービスセッションの間、ＱｏＳコントローラ２３は、サービスセッションに関するＱｏＳレポートを作り、上記のＳＩＰ信号経路を利用して、ホームネットワーク２７のＳＬＡマネージャ２８にフィードバックを行う。
【００６３】
ＱｏＳコントローラ２３は、定期的に、サービスセッションに関するＱｏＳレポートを、対応するＳＩＰアプリケーション２２に渡す（３１５：ＱｏＳ  Ｒｅｐｏｒｔ）。これを行うため、例えば、“ＲＥＰＯＲＴ”というメッセージのために、新しいＳＩＰの方法を定義することができる。ＳＩＰアプリケーション２２は、“ＲＥＰＯＲＴ”メッセージを生成し、そのＳＤＰ属性フィールド内に、ＱｏＳコントローラ２３から取得したＱｏＳレポート情報を挿入する。また、このメッセージに関する宛先アドレスを、ホームネットワーク２７のＳＩＰプロキシ３０とする。そして、ＳＩＰアプリケーション２２は、このレポートメッセージを移動先ネットワーク２４のＳＩＰプロキシ２５に転送し（３１６：Ｒｅｐｏｒｔ（ＱｏＳ  Ｒｅｐｏｒｔ））、移動先ネットワーク２４のＳＩＰプロキシ２５は、メッセージ内の特定の宛先アドレス（ホームＳＩＰプロキシ３０）に転送する（３１７：Ｒｅｐｏｒｔ（ＱｏＳ  Ｒｅｐｏｒｔ））。なお、移動先ネットワーク２４のＳＩＰプロキシ２５において、このＲＥＰＯＲＴの方法がサポートされていない場合には、ＳＩＰプロキシ２５は、これを“オプション”の方法として取り扱う。
【００６４】
ホームＳＩＰプロキシ３０は、この方法の要求を受け取ると、埋め込まれているＱｏＳレポート情報を抽出して、さらなる処理のために、ＳＬＡマネージャ２８に転送する（３１８：ＱｏＳ  Ｒｅｐｏｒｔ）。ＳＬＡマネージャ２８は、このＱｏＳレポート情報を受け取った後、ネットワークポリシーやその他の関連情報を用いて、ＱｏＳ制御管理（ＱｏＳ  Ｃｏｎｔｒｏｌ  Ｍａｎａｇｅｍｅｎｔ）を行う（３１９：ＱｏＳ制御管理）。この管理では、端末２１に割り当てられるＱｏＳパラメータの調整、及び／又は、ＳＬＡデータベース２９での対応するデータの更新も行われる。
【００６５】
例えば、“ＲＥＰＯＲＴ”メッセージは、以下のようになる。
／＊ＱｏＳの報告を運ぶ新しいＲＥＰＯＲＴの方法＊／
ＲＥＰＯＲＴ  ｓｉｐ：ｆｏｏ．ｂａｒ．ｃｏｍ  ＳＩＰ／２．０
Ｆｒｏｍ  ：  ｓｉｐ：ｔｅｒｍｉｎａｌ１＠ｆｏｏ．ｂａｒ．ｃｏｍ    ／＊端末のＳＩＰアドレス＊／
Ｔｏ  ：  ｓｉｐ：    ｍａｉｎ＠ｈｏｍｅ．ｃｏｍ  ／＊ホームＳＩＰプロキシのアドレス＊／
Ｃｓｅｑ  ：  １  ＲＥＰＯＲＴ
ａ  ＝  ｐａｃｋｅｔ＿ｓｅｎｔ：ｘｘｘｘ    ／＊ＱｏＳパラメータ情報を運ぶ属性フィールド＊／
ａ  ＝  ｐａｃｋｅｔ＿ｒｅｃｖ：ｘｘｘｘ
ａ  ＝  ａｖｇ＿ｂａｎｄｗｉｄｔｈ：ｘｘｘｘ
【００６６】
レポートのために含まれ得るその他のＱｏＳパラメータとしては、ＱｏＳクラス、送信容量（送信バイト）、受信容量（受信バイト）、廃棄容量（廃棄バイト）、廃棄パケット数、平均帯域幅、最大帯域幅、廃棄インターバル、平均遅延時間、ジッタ、利用情報、送信廃棄閾値などが挙げられる。なお、ＱｏＳパラメータはさらに拡張可能であり、上記に限定されるものではない。
【００６７】
ＱｏＳの調整が必要な場合には、ＳＬＡマネージャ２８は、端末２１の識別子と共にＱｏＳ制御メッセージをホームＳＩＰプロキシ３０に送る（３２０：ＱｏＳ  Ｃｏｎｔｒｏｌ）。このとき、ホームＳＩＰプロキシ３０は、ＱｏＳ制御が目的であることを示す特別なコードを有するＳＩＰメッセージを作成し、受け取ったＱｏＳ制御メッセージをその中に入れる。例えば、ＱＯＳ＿ＥＮＦＯＲＣＥメッセージという、別の新しい方法を定義することができる。ホームＳＩＰプロキシ３０は、端末２１の移動先ネットワーク２４のＳＩＰプロキシ２５に、このＱＯＳ＿ＥＮＦＯＲＣＥメッセージを転送する（３２１：ＱＯＳ＿ＥＮＦＯＲＣＥ（ＱｏＳ  Ｃｏｎｔｒｏｌ））。移動先ネットワーク２４のＳＩＰプロキシ２５は、端末２１のＳＩＰアプリケーション２２に、このメッセージを即座に転送する（３２２：ＱＯＳ＿ＥＮＦＯＲＣＥ（ＱｏＳ  Ｃｏｎｔｒｏｌ））。
【００６８】
端末２１のＳＩＰアプリケーション２２は、ＱｏＳ制御を示すコードを読むと、ＳＩＰ  ＴＢＤメッセージから、埋め込まれたＱｏＳ制御情報を抽出して、ＱｏＳコントローラ２３に、サービスセッション情報と共に、抽出されたＱｏＳ制御メッセージを送る（３２３：ＱｏＳ  Ｃｏｎｔｒｏｌ）。そして、ＱｏＳコントローラ２３は、ＱｏＳ制御メッセージによって提供された指示に従って動作し、サービスセッションにとってより良いＱｏＳを達成できるよう、端末２１の動作を調整する。図１２は、本発明の実施の形態における操作＿ＩＤ（Ａｃｔｉｏｎ＿ＩＤ）のテンプレートである。以下のように、例えば、上記の指示は“操作＿ＩＤ”属性フィールドで運ばれる。“操作＿ＩＤ”属性フィールドには、例えば、図１２の表に列挙したものが存在する。
【００６９】
ＱＯＳ＿ＥＮＦＯＲＣＥ  ｓｉｐ：ｈｏｍｅ．ｃｏｍ  ＳＩＰ／２．０
Ｆｒｏｍ  ：  ｓｉｐ：    ｍａｉｎ＠ｈｏｍｅ．ｃｏｍ
Ｔｏ  ：  ｓｉｐ：ｔｅｒｍｉｎａｌ１＠ｆｏｏ．ｂａｒ．ｃｏｍ
Ｃｓｅｑ  ：  １  ＱＯＳ＿ＥＮＦＯＲＣＥ
Ａ  ＝  ａｃｔｉｏｎ＿ｉｄ：ｘｘｘｘ  ／＊ａｃｔｉｏｎ  ａｔｔｒｉｂｕｔｅ＊／
Ａ＝  ＜Ｑｏｓ  Ｐａｒａｍｅｔｅｒ＞：ｙｙｙｙ
【００７０】
なお、ＳＬＡマネージャ２８が同一のメカニズムを使用して、要求されていないＱｏＳ制御メッセージを送ることも可能なことは、当業者にとっては明白である。例えば、ネットワーク状態が変化したり、ネットワーク処理が異なったりする場合には、ＳＬＡマネージャ２８は、端末２１のＱｏＳ制御パラメータを調整する必要であり、これによって、端末２１にＱｏＳ制御メッセージを発信することが可能となる。
【００７１】
また、端末２１のＱｏＳコントローラ２３は、端末２１内のアプリケーションを越えて共有される。したがって、アプリケーションが動作している限り、ＱｏＳコントローラ２３は有効な状態となっている。新しいセッションが、ＱｏＳコントローラ２３が既に実行していることを検出した場合には、ＱｏＳコントローラ２３の新しいプロセスは始まらず、すでに存在しているものを用いて、監視、報告、実施が行われる。
【００７２】
図４は、図１で示される端末中心のＱｏＳ制御フレームワークのための代替アーキテクチャの一例を示すブロック図である。このアーキテクチャでは、ＡＡＡ（認証、許可、課金処理）フレームワークが、ＱｏＳ報告及び制御の実施を確立するために利用される。この図４では、シグナリングと制御に係る要素のみが図示されている。端末４１は、シグナリングのために２つの構成要素、ＱｏＳコントローラ４２及びＡＡＡスタック４３を有している。  ＱｏＳコントローラ４２は、図１で示されるＱｏＳコントローラモジュール１１Ａであり、端末４１でＱｏＳを実施して、端末４１から出力されるトラフィックを制御する。また、ＱｏＳコントローラ４２は、端末４１のＱｏＳ利用情報を監視して集め、端末４１のホームネットワーク４６内のＳＬＡマネージャ４８にフィードバックする。
【００７３】
また、ＡＡＡスタック４３は、端末４１のＡＡＡ（認証、許可、課金処理）手続きを制御するエンティティである。例えば、３Ｇネットワークでは、ＥＡＰ−ＡＫＡ（非特許文献９）を用いることが可能であり、また、ＩＥＥＥ８０２．１１ｉ（非特許文献１０）ＷＬＡＮのシステムでは、ＩＥＥＥ８０２．１ｘ（非特許文献１１、１２）に鍵の管理を行うエンティティを加えたものを用いることが可能である。ＡＡＡスタック４３は、標準のネットワークで必要なものであり、したがって、本発明はネットワークに余分な要求を行うものではない。端末４１は、移動先ネットワーク４４に接続する。移動先ネットワーク４４は、端末４１からホームネットワーク４６内のＡＡＡサーバ４７まで、ＡＡＡメッセージを中継するための標準のＡＡＡ設備、すなわちＡＡＡプロキシ４５を提供する。実際には、ＡＡＡプロキシ４５は、他のネットワークエレメントと共存することが可能であり、例えば、ＩＥＥＥ８０２．１１ｉシステムでは、ＡＡＡプロキシ４５は、アクセスポイント内にある認証装置とすることが可能であり、これによって、端末４１からのＥＡＰパケットは、Ｒａｄｉｕｓ／Ｄｉａｍｅｔｅｒパケットにカプセル化される。ホームネットワーク４６におけるＳＬＡマネージャ４８及びＳＬＡデータベース４９は、図１で定義されている構成要素１５及び１８と同一である。
【００７４】
また、図５は、本発明の実施の形態における端末中心のＱｏＳ制御を達成するために、図４で導入されているフレームワークを使用する信号シーケンスの一例を示すシーケンスチャートである。端末４１が移動先ネットワーク４４に接続して、あるサービスに初めてアクセスする場合、移動先ネットワーク４４では、端末４１のＡＡＡスタック４３が、“ＡＡＡ  ｒｅｑｕｅｓｔ”をＡＡＡプロキシ４５に送る（５０１：ＡＡＡ  ｒｅｑｕｅｓｔ（ＮＡＩ））。この“ＡＡＡ  ｒｅｑｕｅｓｔ”は、端末４１の識別情報及びホームドメイン情報を含んでいる。例えば、３Ｇネットワークでは、この情報は、ネットワークアクセス識別子（ＮＡＩ）の形式で存在している。ＮＡＩの内容は、例えば、“ｔｅｒｍｉｎａｌ１＠ｆｏｏ．ｂａｒ．ｃｏｍ”などが可能である。ここで“ｔｅｒｍｉｎａｌ１”は識別子であり、“ｆｏｏ．ｂａｒ．ｃｏｍ”はホームドメイン情報である。ＡＡＡプロキシ４５は、ＮＡＩ内に記載されているドメイン情報を使用して、要求（ＡＡＡ  Ｒｅｑｕｅｓｔ、以下、ＡＡＡ要求とも呼ぶ）をユーザのホームネットワーク４６のＡＡＡサーバ４７に転送する（５０２：ＡＡＡ  ｒｅｑｕｅｓｔ（ＮＡＩ））。
【００７５】
メッセージを受信した後、ホームネットワーク４６のＡＡＡサーバ４７は、ＡＡＡ要求から、ユーザ識別子とサービス情報とを抽出する。ＡＡＡサーバ４７は、さらにこの要求をＳＬＡマネージャ４８に送り、ＳＬＡ内のユーザの加入情報に対して、サービスが許可されるかどうかをチェックする（５０３：ユーザの加入情報をチェック）。もし利用が不可能ならば、ＳＬＡマネージャ４８は、ＳＬＡデータベース４９からユーザのＳＬＡを抽出する（５０４：ＳＬＡを要求、５０５：ＳＬＡを取得）。一方、ユーザのＳＬＡに基づき、要求されたサービスが許可されるならば、ＳＬＡマネージャ４８は、ＳＬＡに格納されたネットワークポリシーやＳＬＡ内のその他の情報に従って、さらなるサービス構成情報を提供し（５０６：サービス許可段階、初期のＱｏＳを構成）、さらに、ＳＬＡマネージャ４８は、ＡＡＡ要求に埋め込まれたＮＡＩによって、端末４１の能力をチェックする。端末４１がＱｏＳ制御を行うことが可能ならば、疑似サービス“ＱｏＳ制御”が、実際のサービスと共にデフォルトで要求される。
【００７６】
例えば、ＮＡＩがサービスを示すために使用される場合には、ｔｅｒｍｉｎａｌ１＠ＱｏＳＣｏｎｔｒｏｌ．ｆｏｏ．ｂａｒ．ｃｏｍという形式も可能である。ここで、“＠”のすぐ右の“ＱｏＳ  Ｃｏｎｔｒｏｌ”は、端末４１がＱｏＳ制御を行うことが可能であることを示している。なお、サービスを特定するためにＡＡＡ手続きで採用されるスキームに依存して、その他の指示情報を用いることが可能なことは、当業者にとっては明白である。
【００７７】
ＳＬＡマネージャ４８がこの“ＱｏＳ  Ｃｏｎｔｒｏｌ”疑似サービスを発見した場合には、端末４１のサービス監視を開始して、ＱｏＳ制御のための接続を設定するパラメータを構成する。この構成は、ＱｏＳコントローラ４２のためのＱｏＳ初期パラメータの設定、ＱｏＳ制御のためのホームネットワークアドレスの割当て、制御メッセージ用のトンネル構成の管理などを含んでいる。このような特別な設定が、通常のサービス構成に含まれるようにすることも可能であり、この場合には、まとめてＡＡＡサーバ４７に送られる（５０７：Ｓｅｒｖｉｃｅ  Ａｕｔｈ（ＱｏＳ  Ｃｏｎｔｒｏｌ  Ｓｅｔｕｐ））。なお、必要ならば、ＳＬＡマネージャ４８は、同時にＳＬＡデータベース４９に格納されたＳＬＡの更新も行う（５０８：ＳＬＡ更新）。そして、ＡＡＡサーバ４７は、“Ｓｅｒｖｉｃｅ  Ｃｏｎｆｉｇ”メッセージを作成して、その中にすべての設定を埋め込み、移動先ネットワーク４４のＡＡＡプロキシ４５を介して、それを端末４１のＡＡＡスタック４３に送る（５０９：Ｓｅｒｖｉｃｅ  Ｃｏｎｆｉｇ（ＱｏＳ  Ｃｏｎｔｒｏｌ  Ｓｅｔｕｐ）、５１０：Ｓｅｒｖｉｃｅ  Ｃｏｎｆｉｇ（ＱｏＳ  Ｃｏｎｔｒｏｌ  Ｓｅｔｕｐ））。
【００７８】
ＡＡＡスタック４３は、“Ｓｅｒｖｉｃｅ  Ｃｏｎｆｉｇ”メッセージを受け取った場合には、埋め込まれているサービス情報をすべて抽出して、それらを対応するアプリケーションに渡す。また、同様に、“ＱｏＳ  Ｃｏｎｔｒｏｌ”疑似サービスの構成は、端末４１のＱｏＳコントローラ４２に渡されて（５１１：ＱｏＳ  Ｃｏｎｔｒｏｌ  Ｓｅｔｕｐ）、ＱｏＳサービスセッションが開始される。ＱｏＳコントローラ４２は、端末４１でＱｏＳ制御を行うため、ＡＡＡ要求に埋め込まれていた初期のＱｏＳ構成を使用する。また、ＱｏＳコントローラ４２は、ホームネットワーク４６のＳＬＡマネージャ４８に向かうトンネルをセットアップするために、ＡＡＡ要求に埋め込まれていたトンネル構成を使用する（５１２：ＱｏＳ制御トンネル設定）。このトンネルは、ＳＬＡコントローラ４２がＳＬＡマネージャ４８に対してＱｏＳ統計量を報告するために使用され、ＳＬＡマネージャ４８がＱｏＳコントローラ４２に対してＱｏＳ実行指示を送るために使用される。
【００７９】
このスキームでは、ＱｏＳコントローラ４２は、ＡＡＡスタック４３に対して、通常のアプリケーションのように動作を行う。  ＱｏＳ設定やトンネル設定は、ＡＡＡスタック４３にとっては明白である。したがって、たとえ、ＱｏＳコントローラ４２がその設定にＡＡＡフレームワークを使用しても、標準のＡＡＡスタック４３からの変更は全く必要としない。  すなわち、これは、どんな標準ネットワークでも、本発明が、高い適応性を有していることを示すものである。
【００８０】
ユーザセッションが進むと、ＱｏＳコントローラ４２は、端末４１で観測されたサービスを反映するＱｏＳ統計量を生成する。ＱｏＳコントローラ４２は、上記のトンネル設定を使用して、この情報をＳＬＡマネージャ４８に報告する（５１３：ＱｏＳ報告）。図９は、本発明の実施の形態における端末からＳＬＡマネージャに送られるＱｏＳデータを報告するための報告メッセージ（ＱｏＳ報告）のフォーマットを示す図である。報告メッセージは、最初にメッセージ＿ＩＤフィールド９１、続いてメッセージ長フィールド９２、さらにペイロードを有している。ペイロードは、属性値ペア情報９３からなり、属性には、ＱｏＳパラメータ又は情報の属性が含まれている。
【００８１】
ＱｏＳパラメータの例としては、ＱｏＳクラス、送信容量（送信バイト）、受信容量（受信バイト）、廃棄容量（廃棄バイト）、廃棄パケット、平均帯域幅、最大帯域幅、廃棄インターバル、平均遅延時間、ジッタ、利用情報、送信廃棄閾値などが挙げられる。なお、ＱｏＳパラメータはさらに拡張可能であり、上記に限定されるものではない。この例では、固定長の属性値のペアが使用されており、したがって、メッセージ長フィールド９２だけが唯一、メッセージ全体に関して必要な情報となる。なお、可変長の属性値のペアを採用している場合には、各ペアは、属性値のペアの長さを示す付加的な長さフィールドを必要とする。
【００８２】
ＱｏＳコントローラ４２から報告を受け取った後に、ＳＬＡマネージャ４８は、何らかのＱｏＳ管理プロセスを実行して、端末４１で何らかの調整が行われる必要があるか否かを決定する。また、必要ならば、ＳＬＡデータベース４９内のＳＬＡの更新を行う。端末４１で何らかの変更が必要な場合には、ＳＬＡマネージャ４８は、ＱｏＳ制御トンネル設定５１２でＱｏＳ実行メッセージをＱｏＳコントローラ４２に送る（５１４：ＱｏＳ実行制御）。図１０は、本発明の実施の形態におけるＳＬＡマネージャから端末に送られるＱｏＳ実行メッセージのフォーマットを示す図である。ＱｏＳ実行メッセージは、メッセージ＿ＩＤフィールド１０１、メッセージ長フィールド１０２、操作＿ＩＤフィールド１０３、ＱｏＳパラメータフィールド（属性値ペア情報）１０４を有している。ＱｏＳ実行メッセージには、あらかじめ定義されたメッセージテンプレートのセットが存在する。上述の報告メッセージのフォーマットと同様に、ＱｏＳパラメータフィールド１０４は、０個、１個、又は、複数個のＱｏＳデータフィールドであり得る。操作＿ＩＤフィールド１０３及び対応する操作の一例は、図１２に示されているものと同様である。
【００８３】
ＱｏＳ制御トンネル設定５１２でトンネルがいったん設定されれば、ＳＬＡマネージャ４８とＱｏＳコントローラ４２にとって、そのトンネルは利用可能なものとなる。２つのノードが互いに、同一のサブネットに存在するように通信を行う。ＳＬＡマネージャ４８のアドレスと対応するポートナンバーとが、“ＱｏＳ制御”サービスの設定時間中に（ＱｏＳ制御設定５１１のときに）、ＱｏＳコントローラ４２に送信されるようにすることも可能である。端末４１のアドレスは、サービス許可段階５０６の間に、ＳＬＡマネージャ４８によって割り当てられて、常に利用可能である。
【００８４】
ＱｏＳ制御のための終端点間の通信では、ＳＬＡマネージャ４８は、例えば、ポート“ｓｓ”のＩＰアドレス“ｘｘｘｘ”のように、端末４１のアドレス及びあらかじめ定められたポートナンバーのみを記す必要があり、一方、端末４１のＱｏＳコントローラ４２は、例えば、ポート“ｐｐ”のＩＰアドレス“ｙｙｙｙ”のように、ＳＬＡマネージャ４８のアドレス及びサービス許可段階５０６で取得したポートナンバーのみを記す必要がある。中継のルートは、トンネルチャンネル内で扱われる。なお、本発明では、絶対的なアドレスを使用する代わりに、どのようなアドレス方法にも適用可能なことは、当業者にとっては明白である。
【００８５】
トンネルチャンネルは、端末４１ごとに設定される必要があり、通常は、移動先ネットワーク４４におけるサービスで最初に要求される。すなわち、端末４１ごとに、疑似サービス“ＱｏＳ制御”が１つだけ存在する。ＳＬＡマネージャ４８は、チャンネルの中止を決めることができる。例えば、端末がもはや移動先ネットワーク４４に接続していない場合や、サービスセッションがもはや存在しない場合には、ＳＬＡマネージャ４８は、制御ノード（例えば、ＧＧＳＮ）での設定を削除するために、ＡＡＡサーバ４７にシグナリングを行うことができる。
【００８６】
また、ＳＬＡマネージャ４８は、求められていないＱｏＳ実行制御メッセージ５１４をＱｏＳコントローラ４２に送ることも可能である。また、システム全体は、報告及び実行／更新の概念に基づいて動作する。図１に示すポリシーアテンダント１４及びＱｏＳコントローラ１１Ａの両方は、ＳＬＡマネージャ１５に報告を行いながら動作する必要がある。ＱｏＳコントローラ１１Ａは、端末１１で観測される状態に関して報告を行い、一方、ポリシーアテンダント１４は、ネットワークの状態と条件をＳＬＡマネージャ１５に報告する。報告は、定期的又は要請された場合に行われ得る。ＳＬＡマネージャ１５は、ポリシーアテンダント１４又はＱｏＳコントローラ１１Ａの一方からの報告に基づく調整の必要性を判断した場合に、ＱｏＳ実行メッセージを発行する。なお、必要に応じて、ＳＬＡマネージャ１５がポリシーフレームワーク（不図示）をさらに使用して、同時にネットワークを調整できることは、当業者にとっては明白である。
【００８７】
先に説明した２つのシグナリングは、終端点間のＱｏＳ制御を達成するため、端末１１からホームネットワーク１６又はその逆の方向にＱｏＳデータを渡す経路を設定する必要があるシグナリングのメカニズムである。
【００８８】
端末１１はいったんＳＬＡマネージャ１５からＱｏＳ実行指示を受信すると、端末１１のＱｏＳコントローラ１１Ａは、このＱｏＳ実行指示に応じて、現在の状態をＱｏＳ実行指示されたものに置き換える。図６は、本発明の実施の形態におけるＱｏＳコントローラのＱｏＳ監視の一例を示す図である。これは、ハイレベルメッセージシーケンス（非特許文献１３）を使用してモデル化されている。端末１１のＱｏＳコントローラ１１Ａが起動すると、あるプリセットの初期値又は初期構成状態から取得される初期値が構成される（６０１：初期構成の設定）。これらの値は、動作データの監視を行うために使用される異なるＱｏＳメトリックを含んでいる。端末１１のＱｏＳコントローラ１１Ａは起動すると、動作を開始して、利用データの収集及び監視を行う。さらに、収集したデータをフィードバックし、周知のフォーマットに詰めて、統合を行っているセントラルサーバに送る報告を行う（６０２：動作データの監視及び報告）。この場合、セントラルサーバは、例えば、ＳＬＡマネージャ１５である。動作の監視の間、セントラルサーバは動作データとその閾値との比較を行い、違反が起こる（６０３：閾値違反が起こる）と、この違反を処理するために必要な修正を実行する（６０４：違反の処理）。
【００８９】
ここで行われる修正動作は、伝送帯域幅が閾値を超えている場合には、送信パケットの遅延、パケットの完全な廃棄及び／又はパケットの再スケジューリング、あるいは、セッションの完全な終了である。したがって、このようにして、伝送帯域幅を制御することが可能となる。パケットを受ける場合には、入力パケットの要求を最小化して、受信帯域幅を制御し、さらに、すべての入力パケットの帯域幅要求を抑えることができる。また、ネットワークの状態が変化する場合には、ポリシーサーバ（セントラルサーバ）は、ＳＬＡマネージャ１５にこれらの変化を通知する。そして、ＳＬＡマネージャ１５はポリシーの変更に関する決定を行う。これは、更新後の新しい閾値でＱｏＳを管理するため、ポリシーサーバのルールエンジンの更新、及び／又は、影響を受ける端末１１のＱｏＳコントローラの構成の更新を含むものである。影響を受ける端末１１の構成の更新では、上記の影響を受ける端末１１に対して、実行データが渡される。上記の影響を受ける端末１１は、実行データを受信して（６０５：実行データの受信）、このデータの要求に基づいて、必要な更新又は変更を行う（６０６：要求された動作を行う）。そして、監視処理が、更新後の新たな値に基づいて再開される。
【００９０】
図７は、本発明の実施の形態におけるＳＬＡマネージャが監視しているセッションをモデル化した図である。動作監視セッションが開始した場合、ＳＬＡマネージャ１５は監視のために、ＳＬＡデータベース１８から必要なＳＬＡ情報と現在のルールを読み込む（７０１：ルールの読み込み）。ＳＬＡマネージャ１５は、定期的に、端末１１とポリシーサーバのステータスに関する報告を受け取る（７０２：ネットワーク及び端末の監視）。なお、例えば、ＳＬＡマネージャ１５に積極的に送信したり、ＳＬＡマネージャ１５からの要求に応えたりすることによって、ＳＬＡマネージャ１５が非周期的な方法で報告を受け取ることも可能である。ステータスはＳＬＡ情報と比較される。もし、警告又は違反が検出された場合（７０３：違反の検出）には、ＳＬＡマネージャ１５は、違反の性質とネットワーク及び端末１１の両方の状態に依存して、行うべき操作を決定する（７０４：輻輳回避処理、新しいルールの実行）。例えば、ＳＬＡマネージャ１５は、新しいルールを実行したり実行データを決めたりして、周知のフォーマットにその情報を詰めて、新しいルールでポリシーサーバを更新する実行メカニズムを行うか、又は、端末１１に対して、その構成を変更するよう要求する。
【００９１】
また、図１１は本発明の実施の形態における端末のＱｏＳコントローラのためのアーキテクチャを示す図である。このＱｏＳコントローラ  １１０１は、次に示すサブコンポーネントを有している。監視モジュール１１０３は、計測モジュール１１０２を有し、動作監視データを収集して、さらに、閾値違反を確認する。また、実行モジュール１１０７は、トラフィック整理を行う分類装置１１０４、マーカ１１０５、パケット遅延／パケット廃棄装置１１０６を有している。また、通信モジュール１１１０は、計測モジュール１１０２からのすべての動作監視データを集めて格納する利用情報及びトラフィックプロフィール１１０８と、ＳＬＡマネージャと通信を行う報告モジュール１１０９を有している。なお、この通信モジュール１１１０は、実行データを受信しているときには、修正を実行するために実行モジュールとしても機能する。
【００９２】
データパケット１１１２は、端末から出力される前に、その優先順位に従って分類装置１１０４によって分類される必要がある。各アプリケーションには、事前に定義された優先順位があり、分類装置１１０４による分類後、データパケット１１１２は、マーカ１１０５に送られて、“ｉｎ＿ｐｒｏｆｉｌｅ”、“ｏｕｔ＿ｐｒｏｆｉｌｅ”のようにマークされる。計測モジュール１１０２は、利用情報及びトラフィックプロフィール１１０８に対してチェックを行い、端末の現在の状態をマーカ１１０５に通知する。そして、マーカ１１０５は、現在の状態に従って“ｉｎ＿ｐｒｏｆｉｌｅ”、“ｏｕｔ＿ｐｒｏｆｉｌｅ”のようにパケットをマークする。
【００９３】
このマークプロセスの後に、パケット遅延／パケット廃棄装置１１０６は、パケットの発信を遅らせるか、又は、パケット全体を廃棄するかを決定する。さらに、パケット遅延／パケット廃棄装置１１０６は、パケットの遅延又は廃棄に関わらず、計測モジュール１１０２を通じて現在の端末をチェックする。“ｏｕｔ＿ｐｒｏｆｉｌｅ”がマークされているパケットは、“ｉｎ＿ｐｒｏｆｉｌｅ”がマークされているパケットよりも高い確率で廃棄処理される。出力データパケット１１１３は実際に出力されるパケットである。報告モジュール１１０９は、定期的にＳＬＡマネージャ１１１１に報告を行い、ＳＬＡマネージャ１１１１は、報告モジュール１１０９を通じて端末にＱｏＳ実行メッセージを送り返す。何らかの実行動作が要求された場合には、ＱｏＳ実行メッセージが、関連する実行モジュール１１０７で実行される。
【００９４】
また、図８は、本発明の実施の形態におけるＱｏＳコントローラがＱｏＳ監視及びトラフィック制御を行う方法を示す図である。輻輳が起こると、ＳＬＡマネージャ１１１１は、端末のＱｏＳコントローラ１１０１にＱｏＳ実行データを渡して、動作を変更させる。この例では、データパケットは分類装置１１０４によって４つの異なった優先順位Ａ、Ｂ、Ｃ、Ｄに分類される。Ａは最も高い優先度、Ｄは最も低い優先度を示している。また、端末に割り当てられる伝送帯域幅が、修正を実行する決定因子として使用される。さらに、修正を実行するために、その他のパラメータを決定因子に用いることも可能である。
【００９５】
ＱｏＳコントローラ１１０１が、その帯域幅を下げるよう指示するＱｏＳ実行データを受け取る場合には、ＱｏＳコントローラ１１０１は、現在の値から、受信した新しい値に変更して、新しい保証値を設定する（８０１：実行データの受信、新しい保証値の設定）。また、輻輳が起こる場合に関しては、ＳＬＡマネージャ１１１１は、割り当てられた伝送帯域幅を低い優先順位の端末と同一のレベルまで落とし、その影響が出る端末に対して、必要な情報を含む実行データを送る。端末は、この実行データを受信すると、更新を行う前の値と実行データとの比較を行う。また、“ｔｏｔａｌ  ａｌｌｏｃａｔｅｄ  ｂａｎｄｗｉｄｔｈ”（総割当帯域幅）の測定データに関しては、新しい値が既存の値以下の場合には、修正を実行する。
【００９６】
この例では、タイプＡに分類されるパケットに対して、最高の優先度が与えられるが、もし、タイプＡのアプリケーションに関して、総帯域幅の保証値が、要求されている帯域幅を十分サポートできない場合（８０２：クラスＡの帯域幅＞新しい保証値）には、現在行っているクラスＡのセッションを終了する  （８０３：クラスＡのセッションを終了）。一方、総帯域幅の保証値が、要求されている帯域幅をサポートできる場合には、タイプＡのパケットに要求通りの帯域幅がすべて与えられることとなる（８０４：クラスＡのパケットに完全な帯域幅を割り当てる）。タイプＡのパケットに対してすべて割当てを行った後、残りの帯域幅をタイプＢ、Ｃ、Ｄに、例えば、７：２：１の比率で割り当てる（８０５：クラスＢに残りの帯域幅の７０％を割り当てる、８０６：クラスＣに残りの帯域幅の２０％、クラスＤに残りの帯域幅の１０％を割り当てる）。なお、クラスＢ、Ｃ、Ｄでは、送信レート、パケット廃棄、パケット送信の遅延などによって、帯域幅の調節が行われる。このようにして割り当てられた帯域幅やクラスなど数に従って、異なったクラスごとにパケットがキューイングされ、また、各タイプの閾値が計算される（８０７：新しく割り当てられた帯域幅に従って、閾値を再設定）。また、閾値に達するかどうかに従って、パケットには“ｉｎ＿ｐｒｏｆｉｌｅ”、“ｏｕｔ＿ｐｒｏｆｉｌｅ”がマークされる。例えば、ビデオエンコーダアプリケーションの場合に、帯域幅の利用がタイプＢ用の閾値を超えるなら、ＱｏＳコントローラがビデオエンコーダに接続して、もっと低いビットレートでエンコードを行うよう指示することも可能である。
【００９７】
また、上述のアプリケーションへのインタフェースが全く存在せず、接続できない場合には、ＱｏＳコントローラは、閾値に適合するように選択的にパケットを廃棄すると決定することも可能である。入力パケットは“ｏｕｔ＿ｐｒｏｆｉｌｅ”として選択的にマークされて、“ｏｕｔ＿ｐｒｏｆｉｌｅ”でマークされたパケットが、まず最初に廃棄される。タイプＣ及びＤに関しては、タイプＣのパケットが、タイプＤのパケットより頻繁にキューイングされ、タイプＤのパケットは、割り当てられた比率に基づいて最後にキューイングされる。なお、上記の比率は、あくまでも一例であり、異なるクラスに帯域幅を割り当てることによって、あらゆる比率が可能となる。また、分類のタイプは、いかなる分類数でも可能であり、タイプＡ、Ｂ、Ｃ、Ｄに制限されるものではない。さらに、ＱｏＳコントローラは、例えば、ＲＥＤ（非特許文献１４）やＲＩＯ（非特許文献１５）などの、他のスケジューリング手段やキューイングのメカニズムＱｏＳコントローラがスケジューリングの他の手段を使用することができる。
【００９８】
【発明の効果】
本発明によれば、サービスを受ける終端のエンティティである端末でＱｏＳを取り扱うことが可能となる。これによって、ソースがリソースを効率よく管理できるようになり、ネットワークが不必要に輻輳することを避けることが可能となる。ＱｏＳ制御を備えていないネットワークの場合でも、ネットワークに接続する端末が個別にＱｏＳ制御を備えている場合には、端末は、依然としてある程度のＱｏＳ保証を有することになり、端末は、送信するパケット量や要求の量を制御することによって、ネットワークの動きを妨げることはない。また、これによって、ネットワークが、このＱｏＳ制御を行わずにすむようになる。
【図面の簡単な説明】
【図１】本発明の実施の形態における端末ベースの制御で終端点間のＱｏＳを実現する構成を示す模式図
【図２】本発明の実施の形態における端末中心のＱｏＳ制御フレームワークの詳細なアーキテクチャを示すブロック図
【図３】図２のアーキテクチャで使用される、端末が直接ホームネットワークに接続していない場合のＱｏＳの報告及びフィードバックのためのシグナリングを示すシーケンスチャート
【図４】図１で示される端末中心のＱｏＳ制御フレームワークのための代替アーキテクチャの一例を示すブロック図
【図５】本発明の実施の形態における端末中心のＱｏＳ制御を達成するために、図４で導入されているフレームワークを使用する信号シーケンスの一例を示すシーケンスチャート
【図６】本発明の実施の形態におけるＱｏＳコントローラのＱｏＳ監視の一例を示す図
【図７】本発明の実施の形態におけるＳＬＡマネージャが監視しているセッションをモデル化した図
【図８】本発明の実施の形態におけるＱｏＳコントローラがＱｏＳ監視及びトラフィック制御を行う方法を示す図
【図９】本発明の実施の形態における端末からＳＬＡマネージャに送られるＱｏＳデータを報告するための報告メッセージ（ＱｏＳ報告）のフォーマットを示す図
【図１０】本発明の実施の形態におけるＳＬＡマネージャから端末に送られるＱｏＳ実行メッセージのフォーマットを示す図
【図１１】本発明の実施の形態における端末のＱｏＳコントローラのためのアーキテクチャを示す図
【図１２】本発明の実施の形態における操作＿ＩＤ（Ａｃｔｉｏｎ＿ＩＤ）のテンプレートを示す図
【符号の説明】
１１、２１、４１  移動端末（ＭＴ、端末）
１１Ａ、２３、４２、１１０１  ＱｏＳコントローラモジュール（ＱｏＳコントローラ）
１２  アクセスポイント
１３、２４、４４  移動先ネットワーク
１４、２６  ポリシーアテンダント
１５、２８、４８、１１１１  ＳＬＡマネージャ
１６、２７、４６  ホームネットワーク
１７  中継ネットワーク
１８、２９、４９  ＳＬＡデータベース
２２  ＳＩＰアプリケーション
２５  ＳＩＰプロキシ
３０  ホームＳＩＰプロキシ
４３  ＡＡＡスタック
４５  ＡＡＡプロキシ
４７  ＡＡＡサーバ
１１０２  計測モジュール
１１０３  監視モジュール
１１０４  分類装置
１１０５  マーカ
１１０６  パケット遅延／パケット廃棄装置
１１０７  実行モジュール
１１０８  利用情報及びトラフィックプロフィール
１１０９  報告モジュール
１１１０  通信モジュール
１１１２  データパケット
１１１３  出力データパケット
【図１】
2004320159.tif 000003
【図２】
2004320159.tif 000004
【図３】
2004320159.tif 000005
【図４】
2004320159.tif 000006
【図５】
2004320159.tif 000007
【図６】
2004320159.tif 000008
【図７】
2004320159.tif 000009
【図８】
2004320159.tif 000010
【図９】
2004320159.tif 000011
【図１０】
2004320159.tif 000012
【図１１】
2004320159.tif 000013
【図１２】
2004320159.tif 000014