(57)【要約】  本発明は、通信システム（１００）内のセッションのベアラに関するトランスポート・ポリシーを要求する方法及び装置に関する。本発明に係るトランスポート・ポリシー要求ノード（５００）は、サービスの前記ベアラに関するトランスポート・ポリシーの選択をトリガするトリガ・イベントを検出するように適合されたイベント・ハンドリング機構（５０５）と、トランスポート・ポリシーを選択し、前記トランスポート・ポリシーを示すポリシー要求を前記ポリシー決定機能に送信するように適合されたトランスポート・ポリシー選択機構（５２５）と、前記サービスに関連するコンテキストに関する情報を受信するように適合されたコンテキスト情報ハンドリング機構（５１５、５２０）と、を備える。前記コンテキスト情報は、トランスポート・ポリシーの選択のトリガ、及び／又はトランスポート・ポリシーの選択の基礎として使用することができる。【選択図】  図７
2011502383.tif 000002
【特許請求の範囲】
【請求項１】
ポリシー決定機能（２２０；３２０）を備える通信システム（１００）内のセッションのベアラに関するトランスポート・ポリシーを要求するトランスポート・ポリシー要求ノード（５００）であって、
セッションの前記ベアラに関するトランスポート・ポリシーの選択をトリガするトリガ・イベントを検出するように適合されたイベント・ハンドリング機構（５０５）と、
トランスポート・ポリシーを選択し、前記トランスポート・ポリシーを示すポリシー要求を前記ポリシー決定機能に送信するように適合されたトランスポート・ポリシー選択機構（５２５、５３０）と、
を備え、
前記セッションに関連するコンテキストに関する情報を受信するように適合されたコンテキスト情報ハンドリング機構（５１５、５２０）
を備えることを特徴とする、トランスポート・ポリシー要求ノード。
【請求項２】
前記トランスポート・ポリシー選択機構は、前記受信された前記コンテキストに関する情報に基づいてトランスポート・ポリシーを選択するように適合される、
請求項１に記載のトランスポート・ポリシー要求ノード。
【請求項３】
前記イベント・ハンドリング機構は、前記コンテキスト情報ハンドリング機構による情報の受信をトリガ・イベントとして検出するように適合される、
請求項１又は２に記載のトランスポート・ポリシー要求ノード。
【請求項４】
特定の前記トランスポート・ポリシーを選択する際に前記トランスポート・ポリシー選択機構によって使用される命令を受信するように適合されたトランスポート・ポリシー選択命令インターフェース（５３５）を更に備える、
上記請求項のいずれか一項に記載のトランスポート・ポリシー要求ノード。
【請求項５】
前記トランスポート・ポリシー選択機構は、例えばスクリプト等の動的ワークフロー（６００）を利用して所望の前記トランスポート・ポリシーを選択するように適合される、上記請求項のいずれか一項に記載のトランスポート・ポリシー要求ノード。
【請求項６】
前記コンテキスト情報ハンドリング機構は、前記セッションに関するシグナリング・トラフィックを傍受し、それによってコンテキスト情報を受信するように適合されたパケット・スニファを備える、
上記請求項のいずれか一項に記載のトランスポート・ポリシー要求ノード。
【請求項７】
前記イベント・ハンドリング機構は、アプリケーション・サーバ（２２５）又はアプリケーション・クライアント（２３５）からトリガ信号を受信するように適合される、
上記請求項のいずれか一項に記載のトランスポート・ポリシー要求ノード。
【請求項８】
前記コンテキスト情報ハンドリング機構は、前記コンテキストを定義するのに使用されるパラメータの値に関するクエリ（９Ｄａ）を別の装置に送信するように適合される、
上記請求項のいずれか一項に記載のトランスポート・ポリシー要求ノード。
【請求項９】
前記トランスポート・ポリシー選択機構は、ポリシー決定機能によって直接解釈可能な伝送プロトコルに従って、所望の前記トランスポート・ポリシーを示す前記ポリシー要求を送信するように適合される、
上記請求項のいずれか一項に記載のトランスポート・ポリシー要求ノード。
【請求項１０】
前記トランスポート・ポリシー選択機構は、前記ポリシー要求が所望の前記トランスポート・ポリシーを所望の前記トランスポート・ポリシーとして維持する上で満足すべき条件を更に示すような形で、所望の前記トランスポート・ポリシーを示す前記ポリシー要求を送信するように更に適合される、
請求項１乃至９のいずれか一項に記載のトランスポート・ポリシー要求ノード。
【請求項１１】
請求項１乃至１０のいずれか一項に記載のトランスポート・ポリシー要求ノードを備えるシステム（１００）内で通信するユーザ機器（１０５）であって、
セッション開始メッセージ（１０００）を前記ネットワークに送信するように適合されたセッション開始機構
を備え、
前記セッション開始機構は、前記セッション開始メッセージに関係するセッションに関するポリシー要求が前記トランスポート・ポリシー要求ノードによって生成されるか否かを示すインジケーション（１０１０）をセッション開始メッセージに含めるように適合される、
ことを特徴とするユーザ機器。
【請求項１２】
請求項１乃至１０のいずれか一項に記載のトランスポート・ポリシー要求ノードを備える通信システム（１００）においてセッション開始メッセージ（４Ｂ；９Ｂ、１０００）を中継するアプリケーション機能（２１５）であって、前記アプリケーション機能が開始されるセッションに関するポリシー要求を生成すべきか否かを判定するために、受信されるセッション開始メッセージを分析するように適合された機構を備える、アプリケーション機能。
【請求項１３】
セッションのベアラに関するトランスポート・ポリシーを判定するシステムであって、
所望のトランスポート・ポリシーを示すポリシー要求（９Ｅ）を受信し、前記ポリシー要求に従って前記ベアラにトランスポート・ポリシーを割り当てるように適合されたポリシー決定機能（２２０）と、
請求項１乃至１０のいずれか一項に記載のトランスポート・ポリシー要求ノードと、
を備えるシステム。
【請求項１４】
前記トランスポート・ポリシー選択機構によって使用される命令がその機構を利用して作成され、前記トランスポート・ポリシー要求ノードに送信され得る命令作成機構
を更に備える、請求項１３に記載のシステム。
【請求項１５】
前記ユーザ機器からの要求を受信し中継するように適合されたアプリケーション機能（２１５）
を更に備える、請求項１３又は１４に記載のシステム。
【請求項１６】
前記アプリケーション機能は、前記アプリケーション機能が前記ポリシー決定機能にポリシー要求を送信すべきかどうかを判定するために、ユーザ機器から受信される要求（１０００；９Ｂ）を分析するように適合される、
請求項１５に記載のシステム。
【請求項１７】
通信システム（１００）内のセッションのベアラに関するトランスポート・ポリシーを割り当てる方法であって、
トランスポート・ポリシーの選択をトリガするトリガ・イベントを検出すること（７００；７２０）と、
前記ベアラに関するトランスポート・ポリシーを選択すること（７１０）と、
選択された前記トランスポート・ポリシーを示すポリシー要求（９Ｅ）をポリシー決定機能（２２０）に送信すること（７１５）と、
を含み、
前記セッションに関するコンテキスト情報を受信し、受信された前記コンテキスト情報をトランスポート・ポリシーの割り当て時に使用すること
を含むことを特徴とする方法。
【請求項１８】
前記選択することは、受信された前記コンテキスト情報に基づく、
請求項１７に記載の方法。
【請求項１９】
前記トリガ・イベントは、特定のコンテキスト情報の受信である、
請求項１７又は１８に記載の方法。
【請求項２０】
前記トランスポート・ポリシーが選択されるセッションを開始することと、
前記セッションが開始されたときに、トリガ・イベントを検出するように適合された関連する１つ（又は複数）のイベント・ハンドリング機構（５０５）を開始することと、
を更に含む、請求項１７乃至１９のいずれか一項に記載の方法。
【請求項２１】
前記検出すること及び／又は前記受信することは、前記セッションに関するシグナリング・トラフィックを傍受することによって達成される、
請求項１７乃至２０のいずれか一項に記載の方法。
【請求項２２】
前記セッションに関するコンテキスト・パラメータの値を要求するクエリを前記通信システム内のノードに送信すること
を更に含む、請求項１７乃至２１のいずれか一項に記載の方法。
【請求項２３】
前記ポリシー要求を送信することは、前記ポリシー決定機能によって直接解釈可能な伝送プロトコルに従って実行される、
請求項１７乃至２２のいずれか一項に記載の方法。
【請求項２４】
前記ポリシー要求を送信することは、前記ポリシー要求が所望の前記トランスポート・ポリシーを所望の前記トランスポート・ポリシーとして維持する上で満足すべき条件を更に示すような形で実行される、
請求項１７乃至２３のいずれか一項に記載の方法。
【請求項２５】
コンピュータ・プログラムであって、
それらがコンピュータ上で実行されたときに請求項１７乃至２４のいずれか一項に記載の各ステップを実行するように動作可能なコンピュータ・プログラム・コード部分
を備えるコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムに関し、より詳細には、通信システムにおける通信セッションに対するトランスポート・ポリシーの割り当てに関する。
【背景技術】
【０００２】
近年、モバイルと固定の両方の電気通信システムにおいてインターネットと電気通信サービスの統合が進展している。第３世代移動無線通信網では、いずれも大きな成果をあげているセルラー・ネットワークとインターネットという２つの概念が密接に結び付いている。同様に、最近では固定電気通信ネットワークとインターネットの融合に関する標準化がTISPAN（Telecoms & Internet converged Services and Protocols for Advanced Networks）で進められている。
【０００３】
インターネットと電気通信サービスの融合は、帯域幅やサービス品質等の伝送条件についてそれぞれ独自の要件を有する多種多様な新しい応用分野への道を開く。通信ネットワークのユーザに提供されるサービスを改善するとともに通信リソースの使用を最適化するために、通信リソースが使用される応用例の要件に伝送条件を適合させることができることが望ましい。
【０００４】
３ＧＰＰ規格、ならびにＩＰベース通信を可能にするＩＰ-ＴＶ規格のような他の規格によれば、制御シグナリング・プレーンとトラフィック・メディア・プレーンとの間の接続は、アプリケーション機能（ＡＦ）によって提供される。一般に、ＡＦは、ポリシー決定機能（Policy Decision Function : PDF）に接続され、このポリシー決定機能にいわゆるトランスポート・ポリシー要求を送信することにより、セッションの特定の伝送要件を要求することができる（例えば、３ＧＰＰ技術仕様書（ＴＳ）23.203 version 7.2.0参照）。しかしながら、ＡＦによって生成され得るポリシー要求の柔軟性は限られているため、また、リソース使用効率を改善するために、リソースの割り付け及び他のポリシー関連イベントの柔軟性を高めることが望まれている。
【発明の概要】
【０００５】
本発明に関する課題は、通信セッションに対するトランスポート・ポリシーの割り当ての柔軟性を高めることにより通信システム内の通信リソースの使用率をどのように改善するかである。
【０００６】
この課題は、ポリシー決定機能を備える通信システム内のユーザ機器とのセッションのベアラに関するトランスポート・ポリシーを要求するトランスポート・ポリシー要求ノード（transport policy requesting node : TPRN）によって解決される。前記ＴＰＲＮは、サービスの前記ベアラに関するトランスポート・ポリシーの選択をトリガするトリガ・イベントを検出するように適合されたイベント・ハンドリング機構と、トランスポート・ポリシーを選択し、前記トランスポート・ポリシーを示すポリシー要求をポリシー決定機能に送信するように適合されたトランスポート・ポリシー選択機構と、を備える。前記ＴＰＲＮは、前記セッションに関連するコンテキストに関する情報を受信するように適合されたコンテキスト情報ハンドリング機構によって特徴付けられる。
【０００７】
上記の課題は更に、通信システム内のセッションのベアラに関するトランスポート・ポリシーを割り当てる方法によって解決される。前記方法は、トランスポート・ポリシーの選択をトリガするトリガ・イベントを検出することと、前記ベアラに関するトランスポート・ポリシーを選択することと、選択された前記トランスポート・ポリシーを示すポリシー要求をポリシー決定機能に送信することと、を含む。前記方法は更に、前記セッションに関するコンテキスト情報を受信し、受信された前記コンテキスト情報をトランスポート・ポリシーの割り当て時に使用することを含む。
【０００８】
本発明に係る方法及び装置によれば、セッションに対するトランスポート・ポリシーの割り当てを、当該セッションに関連するコンテキスト・パラメータに合わせて動的に調整することが可能となり、それ故通信リソースの使用効率が改善されることになる。
【０００９】
以下の説明を添付図面と併せて読めば、本発明及びその利点のより完全な理解が得られるはずである。
【図面の簡単な説明】
【００１０】
【図１】通信システムの概略図である。
【図２】従来技術によるセッション・ベースＩＰ通信を提供する通信システムにおけるトラフィック・メディア・プレーン・シグナリング及び制御プレーン・シグナリングを示す概略図である。
【図３】従来技術によるＩＰマルチメディア・サブシステム（ＩＭＳ）を使用する通信システムにおけるトラフィック・メディア・プレーン・シグナリング及び制御プレーン・シグナリングを示す概略図である。
【図４】従来技術によるＩＰマルチメディア・サブシステムを使用する通信システムにおけるトランスポート・ポリシー・ハンドリングを示すシグナリング図である。
【図５】本発明に係るトランスポート・ポリシー要求ノードの機能を示す図である。
【図６】セッションのトランスポート・ポリシー選択に関して実行されるワークフローの一例を示す図である。
【図７】本発明に係るトランスポート・ポリシー選択方法を示すフローチャートである。
【図８】本発明に係るトランスポート・ポリシー要求ノードを含む通信システムを示す図である。
【図９】本発明に係るトランスポート・ポリシー要求ノードを備えるシステムにおけるセッション開始時のトランスポート・ポリシー・ハンドリングを示すシグナリング図である。
【図１０ａ】アプリケーション機能ノードによるポリシー決定が開始されるか否かを示すフラグを含むセッション開始メッセージの一例を示す図である。
【図１０ｂ】アプリケーション機能によるポリシー決定が開始されるか否かを判定する方法を示すフローチャートである。
【発明を実施するための形態】
【００１１】
図１は、ユーザ機器１０５と、セッション・ベース・インターネット・プロトコル（ＩＰ）通信を提供するネットワーク１１０と、を含む通信システム１００の一例を概略的に示す。ネットワーク１１０によってサポートされるセッション・ベースＩＰ通信は、例えばインターネット・プロトコル・マルチメディア・サブシステム（ＩＭＳ）規格、実時間ストリーミング・プロトコル（ＲＴＳＰ）、セッション開始プロトコル、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）、又はセッション・ベースＩＰ通信を提供する他の規格に基づくものとすることができる。セッションという用語は、ポート番号等の共通点を共有するＩＰパケット・シーケンスとして解釈されるべきである。ＩＭＳ規格の説明については、例えば３ＧＰＰ技術仕様書23.228 version 8.0.0を参照していただきたい。
【００１２】
図１のユーザ機器（ＵＥ）１０５は、無線接続であっても固定接続であってもよい物理インターフェース１１５を介してネットワーク１１０内で通信することができる。ネットワーク１１０は、汎用パケット無線サービス（ＧＰＲＳ）、無線ローカルエリアネットワーク（ＷＬＡＮ）サービス、他の任意のベアラ・サービス等、１つ又は複数のインターネット・プロトコル接続アクセス・ネットワーク（ＩＰ‐ＣＡＮ）ベアラを提供することができる。
【００１３】
セッション・ベースＩＰ通信は一般に、セッション・シグナリングがトラフィック・フローから分離される点で階層化アーキテクチャに従う動作となる。それ故、物理インターフェース１１５は、制御シグナリング・プレーンではセッション・シグナリング・メッセージの伝送に使用され、トラフィック・メディア・プレーンではメディア・トラフィックの伝送に使用される。
【００１４】
図２には、従来技術に関する制御シグナリング・プレーン２００ならびにトラフィック・メディア・プレーン２０５内の各経路が概略的に示される。ネットワーク１１０は、例えばＩＭＳ機能を利用してＩＰセッション・ベースの通信を提供するように構成される。ユーザ機器１０５とネットワーク１１０との間の接続を提供する物理インターフェース１１５は、制御シグナリング・インターフェース部分１１５ａと、メディア・トラフィック・インターフェース部分１１５ｂと、を含むように図示されている。
【００１５】
ネットワーク１１０は、１つ又は複数のポリシー実施機能（Policy Enforcement Functions : PEF）２１０を含む。ここで、セッションに適用されるトランスポート・ポリシー又は単にポリシーは、セッションのトランスポート・メディアに関するサービス品質（ＱｏＳ）パラメータ及び／又はリソース予約ルールの設定を表すものと解釈していただきたい。セッションのトランスポート・ポリシーは通常、セッションが関与するサービスのタイプ、ならびに１つ（又は複数）のユーザ機器１０５の１つ（又は複数）のユーザによって保持されるサブスクリプションのタイプに依存する。従来技術のポリシー割り当ては、エンド・ポイント間のネゴシエーションを含み、そこで、各エンド・ポイントは、エンド・ユーザ要求及びユーザ機器１０５の能力に応じてそれぞれの要件を表現することができる。従来技術によれば、セッションのトランスポート・ポリシーは、帯域幅要件、優先度、及び／又はゲーティング制限に関して表現されることが多い。
【００１６】
ＰＥＦ２１０は、トラフィック・メディア・プレーン２０５内の様々なＩＰセッションに応じて様々なポリシーを実施するように構成される。トラフィック・メディア・プレーン２０５内のメディア・コンポーネントは、例えばパケット・フィルタによって識別される。ＰＥＦ  ２１０は、様々なメディア・フローに応じてルーティング・ロジックの様々な処理を提供することができる。ネットワーク１００がＧＰＲＳをインターネット・プロトコル接続アクセス・ネットワーク（ＩＰ‐ＣＡＮ）ベアラとして提供する場合は、ＰＥＦは一般に、ゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）内に配置され、ＩＰ‐ＣＡＮベアラがＷ‐ＬＡＮ、ＤＳＬ、Ｇ‐ＰＯＮ等に基づく場合は、ＰＥＦ２１０は、トラフィック・メディア・プレーン２０５の対応するノード内に配置される。
【００１７】
図２のネットワーク１１０は更に、ネットワーク１１０内で制御メッセージをシグナリングするためのアプリケーション機能（ＡＦ）２１５及びポリシー決定機能（ＰＤＦ）２２０、ならびにアプリケーション・サーバ・システム２２５も備えるように図示されている。アプリケーション・サーバ・システム２２５は、アプリケーション・レイヤ機能を提供し、ユーザ機器１０５にサービスを提供するように適合される。多くの場合、アプリケーション・サーバ・システム２２５は、制御シグナリング・プレーン２００とトラフィック・メディア・プレーン２０５の両方の一部となるが、図示を簡略化するために、図２ならびに図３及び図８では制御シグナリング・プレーン２００のみの一部として図示される。アプリケーション・サーバ・システム２２５は、例えばプッシュ・ツー・トーク機能、ボイス・オーバＩＰ機能、ゲーミング・アプリケーション、コンテンツ作成機能等、メディア・レイヤで動作するアプリケーション機能を含む。アプリケーション・サーバ・システム２２５は、課金システムや測位システム等のサービス・イネーブラも含むことができる。更に、アプリケーション・サーバ・システム２２５は多くの場合、セッション・ハンドリング機能も含む。図１のアプリケーション・サーバ・システム２２５は、ＡＦ２１５を介してセッション情報をトラフィック・メディア・プレーンに通信する。
【００１８】
図２のＰＤＦ２２０は、ＡＦ２２０を介しインターフェース２４５を経て受信される情報に基づいて特定のセッションに適用すべきポリシーを決定する。即ち、ＰＤＦ２２０によってセッションのポリシー・ルールが生成される。その後、ポリシー・ルールは、ＰＥＦ２１０に転送され、ＰＥＦ２１０によって実施される。ＰＤＦ２２０は、ＰＥＦ２１０を介したシグナリング・プレーン２００とトラフィック・メディア・プレーン２０５との間のインターフェースを提供する。
【００１９】
図２は更に、ＩＰセッション通信がそれらを利用して実現され得るユーザ機器１０５内の様々な機能の一例も示す。図２のユーザ機器１０５は、ＩＰセッション・クライアント２３５に接続されるアプリケーション２４０を備える。ＩＰセッション・クライアント２３５は、アプリケーション・サーバ・システム２２５から提供されるサービスの実行に関する制御信号をユーザ機器１０５のアプリケーション２４０との間で通信するように適合される。ＩＰセッション・クライアント２３５は更に、トラフィック・メディア・プレーン２０５のネットワーク１１０との間でトラフィックを通信するように適合される。
【００２０】
従来技術によれば（例えば３ＧＰＰ  ＴＳ 23.203 version 7.2.0参照）、ＡＦ２１５は、ＰＤＦ２２０を介して制御シグナリング・プレーン２００とトラフィック・メディア・プレーン２０５との間の接続を提供する。ＡＦ２１５は、セッション・エンド・ポイント間のセッション・シグナリングを中継するとともに、ＰＥＦ２１０のリソース変更要求を生成するように適合される。ＡＦ２１５は、プロキシとして働く、即ち、要求の中継、要求の内部的なサービス、及び／又は他のノードへの要求の転送を行うが、要求が伝送されるコンテキストについてはごく限られた知識しか有さない。例えば、サービスの呼び出し又は実行の一環としてセッション要求が送信される場合に、ＡＦ２１５は、そのセッション要求に含まれる知識以外のサービスの特性及び要件に関する知識を何ら有さない。ＡＦ２１５からサービスされる要求に含まれる情報は、一般にごく限られている。このため、リソースの割り付け及び他のポリシー関連イベントの柔軟性及び正確性が制限される。
【００２１】
図３には、ＩＭＳベース・システムに関する従来技術のシステム１００の一例が示される。この場合、ユーザ機器１０５のＩＰセッション・クライアント２３５は、ＩＭＳクライアント３３５であり、ＡＦ２１５は、プロキシ・コール／セッション制御機能（Proxy Call／Session Control Function : Ｐ-CSCF）３１５であり、ＰＤＦ２２０は、ポリシー及び課金ルール機能（Policy and Charging Rule Function : PCRF）３２０である。図３のＩＭＳベース・システム１００は更に、Ｐ‐ＣＳＣＦ３１５とアプリケーション・サーバ・システム２２５との間の通信用のＳ‐ＣＳＣＦ３２５を備える。Ｓ‐ＣＳＣＦ３２５は、セッション開始プロトコル（ＳＩＰ）サーバである。Ｐ‐ＣＳＣＦ１２５は、シグナリング・プレーン２００のＳ‐ＣＳＣＦ３２５と通信することができる。図３の実施形態では、Ｓ‐ＣＳＣＦ３２５は、例えばボイス・オーバＩＰ、プッシュ・ツー・トーク、ビリング・サービス、ゲーミング等のサービスを実行するためのハードウェア及び／又はソフトウェアを備えるアプリケーション・サーバ・システム２２５に接続される。
【００２２】
図３のＰＣＲＦ３２０は、ベアラ・ポリシーへのサービスのマッピングが定義されるテーブルを含むポリシー・データベース３５５を備える。ＰＣＲＦ３２０は、現行の３ＧＰＰ  ＩＭＳ規格（とりわけ、３ＧＰＰ ＴＳ23.203 v.7.2.0及び23.228 v.8.0.0参照）によると、Ｐ‐ＣＳＣＦ３１５の一部として実装されることも別個のエンティティとして実装されることもある。ＰＣＲＦ３２０が別個のエンティティとして実装される場合は、Ｐ‐ＣＳＣＦ３１５は、Ｒｘインターフェース３４５と呼ばれるインターフェースを介してＰＣＲＦ３２０と通信することができる。ＰＣＲＦ２２０は更に、Ｇｘインターフェース３５０と呼ばれるインターフェースを介してＰＥＦ３１０と通信することもできる。
【００２３】
図３のＩＭＳベース・システム１００は、本発明が適用可能なシステム１００の一例にすぎない。以下では例示のために、本発明のいくつかの特徴を図３のＩＭＳベース・システムに関して説明する。しかしながら、本発明は、例えばＲＴＳＰやプレーンＳＩＰ（非ＩＭＳベース）のような他の規格のＩＰセッション通信システムにも等しく適用可能であることに留意していただきたい。
【００２４】
システム１００のトラフィック・メディア・プレーン２０５でメディア・セッションが開始されるときは、バインディング手続きを使用して、セッションのサービス・データ・フローが当該サービス・データ・フローをトランスポートすると見なされるＩＰ‐ＣＡＮベアラと関連付けられる。ＩＭＳ規格を使用するシステム１００では、サービス・データ・フローは、セッション記述プロトコル（Session Description Protocol : SDP）を利用してセット・アップされる。詳細については、メディア・セッションの開始が概略的なシグナリング図で示される図４に関して説明する。ＩＭＳシステム１００におけるメディア・セッションの開始は、制御シグナリング・プレーン２００においてセッション記述プロトコル（ＳＤＰ）のオファー／アンサー・モデルに従いセッション開始プロトコル（ＳＩＰ）を利用してシグナリングされる。
【００２５】
ＩＭＳセッション、又はＳＤＰを利用してセッションを記述する他のセッションをセット・アップするときに、各セッション・エンド・ポイント（例えば２つの異なるユーザ機器１０５の各アプリケーション２４０、又はアプリケーション・サーバ・システム２２５内のユーザ機器及びアプリケーション・サーバの各アプリケーション２４０）は、制御シグナリング・プレーン２００においてＳＩＰメッセージを送信し合うことにより、トラフィック・メディア・プレーン２０５上で使用すべきリソースを調整する。
【００２６】
図４のシグナリング図には、従来技術によるセッション開始成功シナリオの一例が概略的に示される。ここで、ユーザ機器１０５内のアプリケーション２４０は、セッション開始ノードとして働く。図４のシナリオでは、４Ａでアプリケーション２４０からのサービス要求が行われる時点で、ユーザ機器１０５は、既にネットワーク１１０に接続されており、例えばデフォルトのベアラを使用してＩＰ‐ＣＡＮセッションの確立も済ませている。図４のシグナリング図には以下のイベントが含まれる。
【００２７】
４Ａ：ユーザ機器１０５内のアプリケーション２４０が、開始されるサービスの実行に必要となるパラメータの該当する値をSIP INVITEシグナリング・メッセージに入力する。このようなパラメータとしてはとりわけ、開始されるセッションでどのようなタイプのサービスが使用されることが企図されるかを示すＩＭＳクラス・オブ・サービス・インジケータ（IMS Class of Service Indicator : ICSI）が挙げられる。その後、開始ノードは、SIP INVITEシグナリング・メッセージを他のセッション・エンド・ポイントに送信する。
【００２８】
４Ｂ：まず、Ｐ‐ＣＳＣＦ３１５を介してSIP INVITEメッセージが送信される。次に、Ｐ‐ＣＳＣＦ３１５は、SIP INVITEメッセージをＳ‐ＣＳＣＦ３２５に転送する。
【００２９】
４Ｃ：Ｓ‐ＣＳＣＦ３２５が、サービス制御を実行する。このサービス制御は、例えば適用され得るサービス制限を発見するためのサブスクライバ・データの検査を含むこともある。更に、Ｓ‐ＣＳＣＦ３２５は、要求されたサービスを提供することが可能な関連するアプリケーション・サーバにSIP INVITEを経路指定する。
【００３０】
４Ｄ：図４は成功シナリオを示すため、要求されたサービスが許可され、SIP INVITEメッセージは、Ｓ‐ＣＳＣＦ３２５からセッション終端エンド・ポイントに送信される。
【００３１】
４Ｅ：他のエンド・ポイントからのオファー応答メッセージ（典型的には「SIP 200 OK」）が、Ｓ‐ＣＳＣＦ３２５において受信される。このオファー応答メッセージは、SIP INVITEに含まれるパラメータの少なくとも一部を含むが、これらのパラメータは、終端エンド・ポイントで値が変更されている可能性もある。その後、オファー応答はＰ‐ＣＳＣＦ３１５に転送される。
【００３２】
４Ｆ：Ｐ‐ＣＳＣＦ３１５は、プロキシとして動作し、ＰＣＲＦ３２０に対するポリシー要求をパラメータ値に従って生成する。現行のＩＭＳ規格では、このポリシー要求は、Ｒｘインターフェース３４５を介してトランスポートされるアクセス認証要求（Access Authentication Request : AAR）メッセージとされる。
【００３３】
４Ｇ：ＰＣＲＦ３２０が、要求されるポリシーの観点から受信されたポリシー要求メッセージの分析を行い、要求されるポリシーと、関与するエンド・ポイントについて許可されるポリシーとを比較する。要求されるポリシーでベアラをセット・アップするようＰＥＦ２１０に要求するリソース予約要求メッセージが、ＰＣＲＦ３２０からＰＥＦ２１０に送信される。
【００３４】
４Ｈ：ＩＰ‐ＣＡＮベアラの変更開始メッセージが、ＰＥＦ１２０からユーザ機器１０５に送信される。
【００３５】
４Ｉ：ユーザ機器１０５、ＰＥＦ３１０、及びＰＣＲＦ３２０から肯定応答メッセージが送信される。
【００３６】
４Ｊ：Ｐ‐ＣＳＣＦ３１５が、オファー応答メッセージをユーザ機器１０５に転送する。
【００３７】
上述のＩＭＳに基づくシステム１００のセッションを対象とする従来技術のポリシー割り付けは、セッション記述プロトコル（ＳＤＰ）に基づくものである。他の規格に従って動作するシステム内のセッション開始を表す対応する従来技術のシグナリング図もほぼ同様である。セッションで使用すべきリソースの割り付け又は変更は、いずれもＡＦ２１５（図４では、Ｐ‐ＣＳＣＦ３１５）を介してポリシー決定機能（図４では、ＰＣＲＦ３２０）に送信されるセッション開始ネゴシエーションを利用して実行される。セッション開始メッセージ（図４では、ＳＤＰによるSIP INVITEメッセージ）に含めることが可能な情報は限られており、セッション開始メッセージに含まれるパラメータではセッションのＱｏＳを所望の粒度で決定するには十分でない可能性がある。
【００３８】
本発明によれば、セッション又はセッションの一部を利用してサービスが実行されるコンテキストに関する情報を受信するように適合されたコンテキスト情報ハンドラ（context information handler）を備えるトランスポート・ポリシー要求ノードを導入することにより、特定のセッション又はセッションの特定の部分に関するトランスポート・ポリシーの柔軟性が大幅に改善される可能性がある。かかるコンテキスト情報ハンドラを用いると、ポリシー要求ノードは、セッションが実行されるコンテキストに関する情報を受信することが可能となり、また、サービスがそのポリシーを利用して実行されるセッションのトランスポート・ポリシーを、そのようなコンテキストに合わせて調整することが可能となる。以下、セッションという用語は、トランスポート・ポリシーの割り当てが行われ得るセッションの全体と一部の両方を含むものと解釈されるべきである。
【００３９】
以下で説明するように、新しいコンテキスト情報の受信は、セッションの新しいトランスポート・ポリシーの選択をトリガするトリガ・イベントとなり得る。コンテキスト情報は、トランスポート・ポリシーの選択がセッション開始メッセージやセッション変更メッセージの受信等の他のイベントによってトリガされている状況において、セッションに関してどのトランスポート・ポリシーを選択すべきかを判定する際にも使用され得る。
【００４０】
トランスポート・ポリシー要求をトリガする際に使用され得るコンテキスト情報の例としては、例えば、セッション・エンド・ポイントの一方又は両方の位置；特定のアプリケーション、例えばゲームの瞬間的な解像度又は帯域幅要件；時刻；セッションに関与するユーザ機器１０５によって他のどのようなサービスが現在使用されているか；関与するユーザ機器１０５に関する請求先口座のステータス；ネットワーク又はネットワークの一部の現在のトラフィック負荷（例えば移動無線システム内の特定のセルの現在の負荷）に関する情報；過負荷状態の可能性がある特定のタイプのアクセス技術（例えば特定のタイプの無線技術）の負荷；ユーザ機器１０５のユーザがどのアプリケーションを定期的に使用するかに関する情報；関連するアプリケーションとの接続等を挙げることができる。例えば、ゲームのユーザがより高い（又はより低い）解像度を必要とするゲーム・モードに移行するためのユーザ機器１０５上のボタンを押下した場合、トランスポート・ポリシー要求ノードは、そのイベントに関する情報をコンテキスト情報インターフェースを介して受信することができ、また、より高い（又はより低い）帯域幅のトランスポート・ポリシー要求を関連するポリシー決定ポイントに送信することができる。このようにして、セッションで使用される帯域幅は、任意の時点でセッションによって搬送されるアプリケーションに合わせて最適化することができ、また、帯域幅使用率及び／又はアプリケーションについてユーザが知覚できる品質が改善され、特定の状況に応じてカスタマイズされる。セッションに関するトランスポート・ポリシーの割り当てはトリガ・イベントの受信時に更新されるので、セッションのトランスポート・ポリシーは、セッションの寿命期間中の様々な時点で、セッションの様々なトランスポート要件に応じて変化する可能性がある。
【００４１】
トランスポート・ポリシーの動的なコンテキスト依存割り付けが望ましい他の多くの状況が考えられ得る。例えば、モバイル・ユーザ機器１０５が特定のエリアに進入したときに、その進入したエリアのトランスポート・ポリシー選択ルールに従ってトランスポート・ポリシーを修正することができる。そのようなエリアは、例えばトラフィック負荷が通常高い（又は低い）エリアとすることができ、このエリアへの進入時に、より低い（又はより高い）帯域幅消費量の新しいトランスポート・ポリシーを選択することができる。
【００４２】
上記から分かるように、セッションのトランスポート・ポリシー選択に関して使用されるコンテキスト情報は、そのセッションが使用されることになるアプリケーション、例えばゲームに由来することも、測位サーバやトラフィック負荷監視ノード等の外部ソースに由来することもある。
【００４３】
図５には、本発明に係るトランスポート・ポリシー要求ノード（ＴＰＲＮ）５００が概略的に示される。このシステムは、ＴＰＲＮが制御シグナリング・プレーン２００に参加し、必要に応じてトラフィック・メディア・プレーン２０５に参加するのを容易にするように構成される。図５のＴＰＲＮ５００は、インターフェース５１０を介して、セッションに関連するトラフィックの１つ又は複数のベアラのトランスポート・ポリシー要求をトリガするトリガ信号を受信するように適合されたイベント・ハンドラ５０５を備える。ＴＰＲＮ５００は更に、インターフェース５２０を介して、トランスポート・ポリシーが要求されるセッション又はセッションの一部に関連するコンテキストに関する情報を受信するように適合されたコンテキスト情報ハンドラ５１５を備える。このようなコンテキスト情報は、アプリケーション・サーバ・システム２２５から受信されることもシステム１００内の他のノードから受信されることもある。更に、ＴＰＲＮ５００は、所望のトランスポート・ポリシーとして特定のトランスポート・ポリシーを選択し、そのトランスポート・ポリシーを示すポリシー要求をインターフェース５３０を介してポリシー決定機能２２０に送信するように適合されたポリシー選択機構５２５を備える。ＴＰＲＮ５００のこれらの様々な機能は、適切なハードウェア及び／又はソフトウェアによって実施することができる。
【００４４】
ＴＰＲＮ５００のコンテキスト情報ハンドラ５１５は、セッションに関連するコンテキストに関する情報を受信するように適合される。本発明の一実施形態では、コンテキスト情報ハンドラ５１５は、そのようなコンテキスト情報をＴＰＲＮ５００の外部のノード、例えば測位ノード、コンテキスト作成ノード、トラフィック負荷監視ノード、課金ノード等に要求するように適合され得る。その代わりに、又はコンテキスト情報要求機能と組み合わせて、コンテキスト情報ハンドラ５１５は、進行中のセッションに関して発生するイベント、例えばユーザ機器１０５のユーザからのゲーミング命令の送信や、セッションがＩＰ-ＴＶの伝送に使用されるシナリオでユーザ機器１０５から送信されるチャネルに対する課金命令の送信等、各種イベントに関するコンテキスト情報を検出するために進行中のシグナリングを構文解析（parse）する機能を含むことができる。有利なことに、このような構文解析機能は、セッションに関連するシステム１００内のノード間で発生するシグナリングを傍受／構文解析するように適合されたスニファ（a sniffer）に基づくものとすることができる。このようなスニファは、関連するプロトコル、例えばＨＴＴＰや、ＩＰ-ＴＶ、ＶｏＩＰ、ＭＳＮ、Ｓｋｙｐｅ（登録商標）、チャット・プロトコル等に関するプロトコルを傍受するように適合される。更に、コンテキスト情報ハンドラ５１５は、コンテキスト情報の送信が他のノードによって開始されたときに他のノードからＴＰＲＮ５００に送信されるコンテキスト情報も受信するように適合され得る。コンテキスト情報ハンドラ５１５は、コンテキスト関連データを記憶する記憶手段を含んでも含まなくてもよい。
【００４５】
ＴＰＲＮ５００のイベント・ハンドラ５０５は、セッションのトランスポート・ポリシーの選択をトリガするイベントを検出し、トリガ・イベントの検出時に当該セッションのトランスポート・ポリシーの選択をトリガするように適合される。イベント・ハンドラ５１５は更に、トランスポート・ポリシー選択機構５２５をトリガして特定のセッションのトランスポート・ポリシーを選択するように適合される。
【００４６】
有利なことに、トリガ・イベントは、新しいセッションの開始を含むことができる。この目的のために、イベント・ハンドラ５００は、例えばセッション・セット・アップ・シグナリングを傍受／構文解析するように適合されたセッション開始スニファ（session initiation sniffer）（例えば、関連するセッションの開始がＳＩＰを利用して実行される場合はＳＩＰスニファ）を含むことができ、また、セッション開始シグナリング（例えば、ＩＭＳ規格を使用したシステム１００内のＳ‐ＣＳＣＦ３２５からの信号）を受信及び中継するように適合することもできる。
【００４７】
有利なことに、セッションのトランスポート・ポリシーの選択をトリガするトリガ・イベントは、例えばユーザ機器１０５のユーザからのゲーミング命令の送信、セッションがＩＰ-ＴＶの伝送に使用されるシナリオでユーザ機器１０５から送信されるチャネルに対する課金命令の送信、ユーザ機器１０５が特定のエリアに進入したことを示す情報等、特定のコンテキスト情報の受信を含むことができる。それ故、有利なことに、イベント・ハンドラ５０５は、そのような特定のコンテキスト情報がコンテキスト情報ハンドラ５１５によって受信されたときを検出するように適合される。トリガ・イベントがコンテキスト情報ハンドラ５１５におけるコンテキスト情報の受信である場合、イベント・ハンドラ５０５によって受信されるトリガ信号は、内部インターフェース５２０を介して受信される。この場合、イベント・ハンドラ５０５は、そのような特定のコンテキスト情報の受信が検出されたときにトランスポート・ポリシー選択機構５２５にトリガを送信するように適合されたコンテキスト情報ハンドラ５１５の一部として（少なくとも部分的に）実装することも、別個の機構として実装することもできる。
【００４８】
ＴＰＲＮ５００のポリシー選択機構５２５は、イベント・ハンドラ５０５からトリガが受信されたときに特定のセッションのトランスポート・ポリシーを選択するように適合される。有利なことに、ポリシー選択機構５２５は、トランスポート・ポリシーの選択時に、コンテキスト情報ハンドラによって受信されるコンテキスト情報を使用するように適合され得る。トランスポート・ポリシーの選択は、例えば１つ又は複数のコンテキスト・パラメータの値を検査し、それらのコンテキスト・パラメータ値に従ってトランスポート・ポリシーを選択することによって実行することができる。コンテキスト情報ハンドラ５１５がコンテキスト情報要求を外部ノードに送信し得るＴＰＲＮ５００の一実施形態では、ポリシー選択機構は、関連するコンテキスト・パラメータの値がＴＰＲＮ５００によってまだ知られていない場合はその値を要求するようコンテキスト情報ハンドラ５１５に命令するように適合され得る。
【００４９】
ポリシー選択機構５２５は、それらを利用して選択が行われる命令を実行するハードウェア及び／又はソフトウェアを備える。ＴＰＲＮ５００の一実施形態では、ＴＰＲＮ５００は、それらを利用してトランスポート・ポリシーが選択される新しい命令セットを受信するインターフェース５３５を備える。このような命令は、例えばポリシー選択機構５２５によって実行されるスクリプト等の動的ワークフローを利用して表現され得る。大部分の実装環境において、ポリシー選択機構５２５は、ある命令セットが１つ又は複数のトリガ・イベントに適用され、他の命令セットが他のトリガ・イベントに適用される、トランスポート・ポリシーを選択する複数の異なる命令セットへのアクセスを有する。また、特定の状況でどの命令セットが適用されるかは、他のパラメータ、例えばトランスポート・ポリシーがどのようなタイプのセッション（テキスト／ビデオ／音声等）について選択されるかに依存する可能性がある。
【００５０】
ＴＰＲＮ５００によって直ちに実行可能な新しい命令セットがインターフェース５３５を介して受信されるようにすることにより、ポリシー選択機構５２５は、異なるポリシー選択手続きが必要とされ得る新しいシナリオに容易に適合させることができる。このことは、例えば既存の様々なアプリケーション・コンポーネントを組み合わせることによって新しいアプリケーションが容易に設計され得るアプリケーション設計環境で有益である。アプリケーション・サーバのオペレータは、例えばアプリケーション・サーバから提供されるサービスを搬送するセッションのトランスポート・ポリシーをどのように選択すべきかに関する新しい命令の適用が開始されるほんの数分又は数秒前に、スクリプトがインターフェース５３５を利用してポリシー選択機構５２５にダウンロードされるように設計することもできる。
【００５１】
トランスポート・ポリシー選択機構５２５は、特定のサービス・クラスのセッションについて選択される対応するトランスポート・ポリシーと共に、セッションが属する可能性がある様々な品質クラスのリストを含むテーブル又はデータベースを利用することができる。本実施形態では、セッションに関連するコンテキスト・パラメータを検査することにより、そのセッションが現在属する品質クラスを表す値が得られる。このような値は、品質クラス・インジケータ（Quality Class Indicator : QCI）を利用して示すことができる。本発明の他の実装環境では、ポリシー選択機構５２５は、セッションを特定のクラスに割り当てることなく、セッションのポリシーをコンテキスト・パラメータの値に基づいて直接選択することができる。
【００５２】
多くの実装環境では、トランスポート・ポリシー選択機構５２５は、セッションのトランスポート・ポリシーを選択する際に、動的なコンテキスト・パラメータ以外のパラメータ、例えばユーザ・サブスクリプションに関するパラメータ等も考慮に入れる。ＴＰＲＮ５００は、システム１００から提供されるサービスのサブスクリプションに関係するサブスクリプション・ポリシーに関する情報を含むサブスクリプション・データベースに接続され得る。このようなサブスクリプション・ポリシーは、例えばサブスクリプションがアクセス可能なポリシー又はポリシーのタイプや、サブスクリプションが呼び出し可能な関数又は関数のタイプ等に関する情報を含むことができる。後述の図６に一例が示されるワークフロー６００は、例えばサブスクライバ・データベースの検査を実行するステップを含むことができる。
【００５３】
図６は、トランスポート・ポリシーを選択する際にポリシー選択機構５２５によって使用され得るワークフロー６００の一例を示す。ワークフロー６００は、「ユーザ・ポリシー」、「必要解像度」、及び「ユーザ機器位置」というパラメータがポリシー決定に関連するシナリオを示す。ステップ６０５で、関連するセッションに関するユーザ・ポリシー、必要解像度、及びユーザ機器位置が検査される。本発明の一実施形態では、これらのパラメータのいずれかが未知である場合、ポリシー選択機構５２５は、上述のとおり欠落情報の要求をコンテキスト情報ハンドラ５１５に送信する。関連するパラメータの値が判定されたときはステップ６１０に進み、各パラメータ値がある基準を満足するかどうか、本例ではユーザ・ポリシーが「プレミアム音声」、位置が「市街地」、帯域幅要件が「極めて高い」に該当するかどうかが検査される。該当する場合には、品質クラス・インジケータ（ＱＣＩ）が、特定のトランスポート・ポリシーが要求される特定のサービス・クラスを示す所定の値（本例では「１０」）に設定される。その後、ステップ６１５でワークフロー６００は終了する。関連するパラメータ値がステップ６１０の基準を満足しない場合には、他の品質クラスの基準を同様に検査することができ、即ち、ＱＣＩを異なる値に設定するいくつかのパラメータ値セットをワークフロー６００で使用することができる。
【００５４】
図６に示される例示的なワークフローは、様々な例のうちの１つにすぎず、様々な手法で修正することが可能である。ポリシー決定には任意の数のパラメータを関連付けることができ、また、関連するパラメータの任意の値を特定のポリシーを設定するトリガとして使用することが可能である。
【００５５】
トランスポート・ポリシー選択機構５２５によって実行されるトランスポート・ポリシー選択でワークフロー６６０を使用する代わりに、例えばそれを利用してポリシー決定が実行され得るポリシー・データベースを使用することもできる。このポリシー・データベースは有利なことに、例えばサービス及び／又はサブスクリプション・カテゴリの様々な値を様々なＱＣＩにマッピングすることが可能となるテーブルを収容することができる。
【００５６】
ＴＰＲＮ５００は更に、セッションのベアラに関する通知をＰＥＦ２１０又はＰＤＦ２２０から受信するように適合された通知ハンドラ（notification handler）５４０を任意選択で含むことができる。有利なことに、このような通知は、インターフェース５３０を介して受信することができる。ＰＤＦ２２０は多くの場合、トラフィック・メディア・プレーン２０５からの情報を制御シグナリング・プレーン２００に通信することができる。例えば、３ＧＰＰ  ＴＳ23.203規格によれば、ＡＦ２１５は、ベアラ喪失等のイベントをＡＦ２１５に知らせるベアラからの情報をサブスクライブすることができる。しかしながら、ＡＦ２１５はプロキシであるので、そのような通知に応答する能力は限られている。ＡＦ２１５にベアラ・レイヤの何らかの変更が知らされた場合、ＡＦ２１５が有する選択肢は、セッションを切断するか、その通知を無視してセッションを継続するかのいずれかである。
【００５７】
セッションの開始時又はセッションの進行中に、通知ハンドラ５４０は、通知ハンドラ５３０がベアラに関する通知をサブスクライブしたいと望んでいることをＰＤＦ２２０に知らせる通知開始メッセージを、ＰＤＦ２２０に送信することができる。別法として、ＰＤＦ２２０は、ＴＰＲＮ５００に何らかの通知を常に送信するように構成することもできる。
【００５８】
ＴＰＲＮ５００の通知ハンドラ５４０は、セッションのベアラに関する通知にどのように応答するかを決定するように構成され得ることが好ましい。例えば、通知ハンドラ５４０は、帯域幅要件が満足できない場合にそのセッションを閉じるべきかどうか、又はそのセッションの新しいトランスポート・ポリシーの選択をトリガするためのトリガ信号をイベント・ハンドラ５０５に送信すべきかどうかを判定する判定機構を含むことができる。通知ハンドラ５４０は、セッション・シグナリング・エンド・ポイントとして（例えば、ＳＩＰバック・ツー・バック・ユーザ・エージェント（Back-to-Back User Agent : B2BUA）として）働くように構成され得る。ＰＤＦ２２０によって受信される通知にどのように応答するかを判定する際に、通知ハンドラ５４０は、関連するセッションが使用されるアプリケーションに依存するパラメータを考慮に入れるが、例えば実時間サービスを使用するアプリケーションでは、ベアラ喪失が発生したかどうかを監視することが極めて重要となる可能性がある一方、ベスト・エフォート・サービスでは、そのような監視が不要となる可能性もある。
【００５９】
通知ハンドラ５４０は、必要に応じてＰＤＦ２２０からアプリケーション・サーバ・システム２２５に通知を転送するように構成することもできる。アプリケーション・サーバ・システム２２５は、例えば要求されるＱｏＳレベルが満足できないことを示す情報が通知に含まれる場合に、セッションのポリシーをより低いＱｏＳレベルのポリシーに変更するよう要求する機能を含むことができる。更に、アプリケーション・サーバ・システム２２５がセッションのＳＩＰエンド・ポイント又はＳＩＰバック・ツー・バック・ユーザ・エージェント（Ｂ２ＢＵＡ）として働く場合、アプリケーション・サーバ・システム２２５は、ＳＩＰセッションの再ネゴシエーションを開始することができる。この処理は、例えばセッションに関与するアプリケーション・サーバ・システム２２５のアプリケーションがビデオ・オン・デマンド・セッション又は会議サービス・セッションあるいは他の実時間セッションである場合に適切である可能性がある。
【００６０】
上記の説明では、通知ハンドラ５４０は、ＰＤＦ２２０から各種通知を受信するように構成されるものとして説明されている。同様に、通知ハンドラ５４０は、通知の送信が可能なシステム１００内の他の任意のトラフィック・メディア・ノードから各種通知を受信するように構成することもできる。
【００６１】
図７のフローチャートには、本発明のＴＰＲＮ５００によってセッションに関して実行されるポリシー要求方法が概略的に示される。図７のステップ７００で、システム１００内の２つのエンド・ポイント間のセッションが開始される。ステップ７０３で、関連するプロセスがＴＰＲＮ５００のイベント・ハンドラ５０５において開始される。図７に記載の手順は、同じＴＰＲＮ５００内の複数の異なる進行中のセッションを対象に同時に実行される。各セッションについて、トランスポート・ポリシー選択をトリガすることが可能なイベントは、例えばそのセッションに関して実行されるアプリケーションや関与するユーザ機器１０５のサブスクリプション等に応じて、セッション毎に異なる可能性がある。それ故、ステップ７０３では、ステップ７００で開始されたセッションに関連するトリガ・イベントのタイプを検出するように適合された１つ（又は複数）のイベント・ハンドラが開始される。上述のとおり、トリガ・イベントは、例えばＳＩＰ要求が検出されたこと、特定の時間になったこと、ユーザ機器が特定の地理的領域に進入したこと、アプリケーション・サーバ・システム２２５によって実行されるプログラム（例えばゲーム）が特定のプロセスに入ったこと等とすることができる。例えば、ＨＴＴＰシグナリングに関するセッションでは、関連するＨＴＴＰ信号を検出することが可能なイベント・ハンドラをステップ７０３で開始することができ、ＭＳＮメッセージングに関するセッションでは、ＭＳＮシグナリングを検出することが可能なイベント・ハンドラをステップ７０３で開始することができる。
【００６２】
ステップ７０５に進むと、関連するコンテキスト・パラメータが検査される。このステップは、例えばステップ７００で検出されたトリガ・イベントに適用されるワークフローを選択するステップと、選択されたワークフローに関連するコンテキスト・パラメータの値を検査するステップと、を含むことができる。コンテキスト・パラメータの値が既知でない場合は、かかる情報を外部ノードに要求するようコンテキスト情報ハンドラ５１５に命令することができる。
【００６３】
ステップ７１０で、セッションのトランスポート・ポリシーがトランスポート・ポリシー選択機構５２５によって選択される。この選択は、例えば図６に示したタイプのワークフローを利用して実行することができる。関連するパラメータ、例えばコンテキスト・パラメータ、及びサブスクリプションに関するパラメータのような他のパラメータの値に基づいて、セッションのトランスポート・ポリシーが選択される。トランスポート・ポリシーの選択は、例えばセッションに品質クラスを割り当てるステップと、関連する品質クラスに適用される割り当て済みのトランスポート・ポリシーを識別するステップと、を含むことができる。このようなセッションの品質クラスは、セッションの寿命期間中に他のトリガ・イベントが発生したときにセッションの品質クラスが変化する可能性がある点で動的である。
【００６４】
トランスポート・ポリシーが選択されたときは、ステップ７１５でＰＤＦ２２０にポリシー要求を送信することにより、選択されたトランスポート・ポリシーが要求される。
【００６５】
次に、ステップ７２０に進むと、新しいトリガ・イベント又はセッション閉鎖まで待機し、その後ステップ７２５に進む。ステップ７２５で、セッションがまだ進行中であるかどうかが検査される。進行中でない場合には、ステップ７３０に進んでプロセスは終了する。一方、セッションがまだ進行中である場合には、ステップ７０５に戻る。
【００６６】
上述の方法では、ステップ７００のセッション開始がトランスポート・ポリシー選択のトリガ・イベントとして働くものと仮定されている。しかしながら、例えばセッション開始時にセッションについてデフォルト・トランスポート・ポリシーが選択されるシナリオでは、必ずしもそうであるとは限らない可能性もある。そのような場合は、ステップ７０３の直後にステップ７２０に進んでもよい。
【００６７】
ＴＰＲＮ５００は、ＡＦ２１５とは異なるノードの形で実装することができ、それによってシステム１００が本発明に係るポリシー要求ノードとＡＦ２１５の両方を備えるようにすることができる。ＡＦ２１５は、好ましくは非常に効率的なプロキシ関連特性を有するべきであり、したがってセッションのエンド・ノード間の要求の中継に関与しない最低限の機能を備えるべきである。このような制限は、ＡＦ２１５と別々に実装される新しいポリシー要求ノードには適用されない。
【００６８】
更に、動的なコンテキスト依存型トランスポート・ポリシー要求機構（context dependent transport policy requesting mechanism）をＡＦ２１５と（少なくとも論理的に）分離されたノードに実装することにより、新しいトランスポート・ポリシー・パラメータと共に様々なポリシー・パラメータのより高い粒度の値を容易に導入することが可能となる。ＡＦ２１５は、セッション要求の通信に制限され（例えばＩＭＳシステム１００ではＳＩＰメッセージの通信に制限され）、新しいパラメータ又はパラメータ値を導入する場合はセッション・シグナリング・プログラムの実質的な再設計が必要となるが、このことは一般に望ましくない。ＳＩＰプロトコルは、ＳＩＰエンド・ポイント間の通信用プロトコルであり、アプリケーション・サーバ・システム２２５とＰＥＦ２１０との間の通信専用の新しいパラメータの導入は、ＳＩＰプロトコル違反と見なされる。
【００６９】
より広範なポリシー・パラメータ及びパラメータ値を利用してより多くの種類のポリシーが要求される可能性がある場合は、適用されるポリシー・パラメータの粒度が小さくなるとともにパラメータの種類が増加する可能性があるため、ポリシーの実施の厳格さも高まる可能性がある。
【００７０】
図８は、ＡＦ２１５とＴＰＲＮ５００の両方を含むシステム１００の例示的な（論理）構成を示す。ＴＰＲＮ５００は、インターフェース５３０を介してＰＤＦ２２０と論理的に直接通信することができる。インターフェース５３０は、アプリケーション・サーバ・システム２２５とＰＤＦ２２０との間の代替的な接続、換言すれば、システム１００のメディア・レイヤとポリシー決定機能との間の代替的な接続を提供する。ＡＦ２１５とＰＤＦ２２０との間のインターフェースとは対照的に、インターフェース５３０は、ポリシー関連情報を通信する上でＳＩＰ／ＳＤＰ等のセッション・プロトコルを利用した通信に限らず、より柔軟なフォーマットを使用することができる。ＴＰＲＮ５００は、プロキシならびにＳＩＰ／ＳＤＰプロトコル及び他のセッション・プロトコルに適用される要件及び制約によって制限されないので、ＴＰＲＮ５００のポリシー選択機能の詳細レベル及び正しいトランスポートをアクティブ化する能力がＡＦ２２０のポリシー選択機能の場合と比較して高くなる可能性がある。それ故、ポリシー選択プロセスで考慮に入れられるパラメータ（コンテキスト・パラメータならびに他のパラメータ）の数が増加し、ポリシー要求に含まれ得るパラメータの数も増加する可能性があり、ポリシー要求に含まれるパラメータの可能な値の粒度も増加する可能性がある。
【００７１】
上述のとおり、ＴＰＲＮ５００は、コンテキスト情報を受信することが可能なインターフェース５２０を有する。図８では、インターフェース５２０は、ＴＰＲＮ５００と、アプリケーション・サーバ・システム２２５がその一部を構成することも構成しないこともあるコンテキスト情報ドメイン８００との間の接続として示されている。
【００７２】
アプリケーション・サーバ・システム２２５は、１つ又は複数のアプリケーション・サーバを備えることができる。アプリケーション・サーバ・システム２２５に含まれ得る様々なサーバ・タイプの例として、サービス・サーバ・ドメインではプッシュ・ツー・トーク・サーバ、ＩＰＴＶサーバ、チャット・サーバ等が挙げられ、コンテンツ・サーバ・ドメインではコンテンツ・サーバ及びコンテンツ作成サーバが、業務支援サーバ・ドメインではビリング・サーバ、顧客関係管理サーバ、及びデジタル著作権管理サーバが挙げられる。
【００７３】
ＴＰＲＮ５００は、アプリケーション・サーバ・システム２２５との（論理的に）直接的なインターフェースを有することができ、このインターフェースを利用して、インターフェース５３０を介したＰＤＦ２２０へのポリシー関連情報の通信がアプリケーション・サーバ・システム２２５によって開始され得る。インターフェース５３０を用いると、アプリケーション・サーバ・システム２２５がＰＤＦ２２０へのポリシー関連情報の通信を開始することが可能となるので、本構成では、アプリケーション・サーバ・システム２２５がサービスのポリシー要件に影響を及ぼすパラメータの変化に合わせてポリシーを調整することが可能となる。ゲーミングに関するセッションの場合では、ゲーム内のイベント、例えば他のゲーミング・シナリオよりも高い帯域幅が必要とされるゲーミング・シナリオが発生した場合にポリシーの変更をトリガすることができ、現在アクティブ状態にあるゲーミング・シナリオに合わせてポリシーを調整することができる。アプリケーション・サーバ・システム２２５は、ＴＰＲＮ５００にトリガを送信することによってトランスポート・ポリシー選択を開始することができる。インターフェース５３０を介してアプリケーション・サーバ・システム２２５からＰＤＦ２２０にポリシー関連情報を直接通信可能とすることにより、アプリケーション・サーバ・システム２２５として実装されるメディア・レイヤがポリシー決定に関連する追加的な入力パラメータをポリシー決定プロセスに追加することが可能となるため、セッション／セッションの一部への正しいメディア・リソースの割り付けが容易となる。
【００７４】
システム１００の他の構成では、ＴＰＲＮ５００は、アプリケーション・サーバ・システム２２５と独立して動作するように構成される。システム１００では、ＴＰＲＮ５００は、アプリケーション・サーバ・システム２２５及び他のノードからのトリガを受動的に待つように構成すること、及び／又は例えば上述のスニファを利用してトリガを能動的に探索するように構成することも可能である。
【００７５】
本発明は、アプリケーション・サーバ・システム２２５が設計プロセス終盤に様々なアプリケーション・コンポーネントを組み合わせることによって新しいアプリケーションが構築され得るサービス指向アーキテクチャ（ＳＯＡ）に基づく場合は特に有益である。アプリケーション・コンポーネントは、例えば測位サーバ、ボイス・オーバＩＰサーバ、メッセージング・サーバ、プッシュ・ツー・トーク・サーバ等とすることができるが、トラフィック・メディア・プレーン２０５内のマルチメディア・パケット・フローをセット・アップするのに必要な制御シグナリング・プレーン２００内の制御シグナリングに関与することが好ましい。アプリケーション・コンポーネントをセッションに追加するとき又はセッションから削除するときは、ユーザ体験又は帯域幅使用率を最適化するために、そのセッションで使用されるリソースを変更することが望まれる可能性がある。このようなリソースの変更は、インターフェース５３０を利用して効率的に実現することができる。現行のＩＭＳ規格によれば、セッションのリソース変更にはＰ‐ＣＳＣＦ３１５を介したＳＩＰシグナリングが必要とされる。新しいインターフェース５３０を利用すれば、インターフェース５３０を介してリソース変更が実現でき、ＳＩＰシグナリングは必要なくなる。
【００７６】
図９は、ＡＦ２１５、ならびにＰＤＦ２２０とのインターフェース５３０を有するＴＰＲＮ５００を含むシステム１００に関する図４と同様のセッション開始シナリオを概略的に示す。図４に示されるシナリオと同様に、ユーザ機器１０５は、例えばデフォルト・ベアラを使用してネットワーク１１０に既に接続されている。図９のシグナリング図には以下のイベントが含まれる。
【００７７】
９Ａ：ユーザ機器１０５のアプリケーション２４０が、例えばＳＤＰ又は他のセッション記述プロトコルで開始されるサービスの実行に必要となるパラメータの該当する値をセッション開始メッセージに入力する。関連するパラメータは、例えばサポートされるコーデック・タイプ、帯域幅、及びサービス・タイプである可能性がある。
【００７８】
９Ｂ：該当する値を含むセッション開始メッセージが、ＡＦ２１５を介してセッション・エンド・ポイントに向けて送信される。
【００７９】
９Ｃ：エンド・ポイントからのセッション応答メッセージが、ＴＰＲＮ５００において受信される。このセッション応答メッセージは、セッション開始メッセージのパラメータの一部を含むことも全部を含むこともあるが、これらのパラメータは、終端エンド・ポイントで値が変更されている可能性もある。
【００８０】
９Ｄ：ＴＰＲＮ５００が、トランスポート・ポリシー選択（図７参照）を実行する。
【００８１】
９Ｅ：ＴＰＲＮ５００からのポリシー要求が、インターフェース５３０を介してＰＤＦ２２０に送信される。
【００８２】
９Ｆ：ＰＤＦ２２０が、ＰＥＦ２１０にリソース予約要求を送信する。
【００８３】
９Ｇ：ＩＰ‐ＣＡＮベアラ変更をユーザ機器１０５に知らせるメッセージが、ＰＥＦ１２０からユーザ機器１０５に送信される。
【００８４】
９Ｈ：ユーザ機器１０５、ＰＥＦ２１０、及びＰＤＦ２２０から肯定応答メッセージが送信される。
【００８５】
９Ｉ：ＴＰＲＮ５００が、セッション応答メッセージをユーザ機器１０５に転送する。
【００８６】
９Ｊ：ＴＰＲＮ５００が、開始されたセッションに関連する１つ（又は複数）のイベント・ハンドラを開始する（図７のステップ７０３参照）。
【００８７】
図９のシグナリング図では、ＴＰＲＮ５００がポリシー要求を生成するためのトリガ・イベントは、セッション開始シグナリングである。イベント９Ｄのトランスポート・ポリシー選択がセッション開始メッセージの受信によってトリガされるのか、それともセッション応答メッセージの受信によってトリガされるのかは重要ではなく、どちらの選択肢が実施されてもよい。また、上述のとおり、ポリシー要求は、セッション開始シグナリング以外の様々なイベントによってトリガされ得るため、ポリシー要求をトリガすることが可能なイベントは、セッション毎に異なる可能性がある。ＴＰＲＮ５００のイベント・ハンドラ５０５によってポリシー要求トリガ・イベントが検出されたことに応答して、図９のイベント９Ｄ〜９Ｈで示される各イベントが実行される。
【００８８】
ＴＰＲＮ５００によってトランスポート・ポリシー選択が実行されるイベント９Ｄは、典型的にはセッションに関連するコンテキスト・パラメータの値を判定するための、ＴＰＲＮ５００とアプリケーション・サーバ・システム２２５内のノードとの間のシグナリングを含む。かかるシグナリングは、イベント９Ｄａのコンテキスト要求、及びイベント９Ｄｂのコンテキスト応答で示される。
【００８９】
図４及び図９のシグナリング図を比較すると、２つのシナリオで必要とされるシグナリングの量が同様であること、それ故、図９のシナリオの利点は図４のシナリオと比較してセット・アップ時間の遅延なしに達成され得ることが分かる。
【００９０】
イベント９Ｅのポリシー要求は、インターフェース５３０を介して伝送される（この点、ポリシー要求がＲｘインターフェース２４５、ＩＭＳベース・システム１００ではＲｘインターフェース３４５を介して伝送される図４に示される従来技術のシナリオとは異なる）。一般に、ＡＦ２１５とＰＤＦ２２０との間のインターフェース２４５は、限られた数のパラメータの伝送をサポートするように標準化されている。しかしながら、このような制約は、インターフェース５３０には適用されない。
【００９１】
必要となるＰＤＦ２２０の再設計を最小限に抑えるために、インターフェース５３０を介したシグナリングで使用されるプロトコルは、有利なことに、インターフェース２４５を介したシグナリングで使用される従来技術のプロトコルに基づくものとすることもできる。ＩＭＳ規格を使用するシステムでは、インターフェース５３０を介したシグナリングで使用されるプロトコルは、有利なことにＲｘプロトコルに基づくものとすることができる。しかしながら、上述のとおり、ポリシー要求内のポリシー関連パラメータの数を増加させること、及び／又は既存のパラメータの値の粒度を高めることが有利であることが多い。したがって、インターフェース５３０を介したシグナリングでは、インターフェース２４５を介したシグナリングで使用されるプロトコルの拡張版を使用することが有利である可能性もある。
【００９２】
そのような拡張版プロトコルによるポリシー要求メッセージの可能な属性のリストを以下に示す。
●メディア・プレーンにおける転送遅延（例えば、あるパーセンタイルのパケットで許可される最大転送遅延を示すことが可能）
●信頼性（例えば、パケットが損失しない確率を示すことが可能）
●最大リソース・コスト（例えば、選択されたリソース上の一定のトラフィック・ボリュームに関する転送コストの相対値（Low（低）／Medium（中）／High（高）等）を与えることが可能）
●モビリティ要件（例えば、「シームレス」／「セッション継続、但し割込み可能」／「モビリティ不要」として表現されるハンドオーバ効率）
●アプリケーション識別子（例えば、クラス・オブ・サービス・インジケータ（Class of Service Indicator : CSI）
●コーデック・タイプ
●メディア・タイプ（例えば、音声／ビデオ／テキスト）
●コーデック・データ（例えば、ＡＭＲ／Ｇ．７１１等）
●フロー使用率
●要求されるアクセス・タイプ（例えば、ロバスト・オーディオ・ツール（ＲＡＴ）、インテリジェント無線ＬＡＮ（Ｉ‐ＷＬＡＮ）、ロング・ターム・エボリューション（ＬＴＥ）、デジタル加入者線（ｘ‐ＤＳＬ）等）
●要求される帯域幅（「最大帯域幅のビット誤り」／「最大及び最小保証帯域幅」）
●課金識別子
●予約優先度
●フロー・ステータス（ゲーティング）
●ＵＥの宛先ＩＰアドレス＋ポート
●要求されるポリシーの有効期限
●その他
【００９３】
上記で列挙した属性の１つ又は複数をポリシー要求に導入することにより、ポリシー要求が機能拡張され、その結果ポリシー割り当ての柔軟性が高まることになる。
【００９４】
上記の属性リストのうち、ポリシー要求９Ｅに含めることが可能な属性の一例は、「要求されるポリシーの有効期限」である。要求されるポリシーの有効期限に関する情報をポリシー要求に含めることにより、ネットワーク１１０内のシグナリング量を減少させることが可能となる。この有効期限は、例えばある期間として表現することも、要求されるポリシーがそのイベントの発生によって無効となるイベントとして表現することもできる。ポリシー要求９Ｅは、要求されるポリシーの有効期限に関する情報を含む場合は、その要求されるポリシーの有効期限が切れたときにどのポリシーを適用すべきかに関する情報も含むことができる。別法として、ＰＤＦ２２０は、要求されるポリシーの有効期限が切れたときにデフォルト・トランスポート・ポリシーを適用するように構成され得る。
【００９５】
更に、従来技術に従ってＰＤＦ２２０内に配置される機能の一部、例えば該当するＱＣＩ値の識別等は、ＴＰＲＮ５００に移動させることができる。その場合は、インターフェース５３０を介して使用される拡張版プロトコルにＱＣＩを表す属性が含められる。
【００９６】
インターフェース５３０上のポリシー要求で使用される属性の数及び複雑さは、実装上の必要性に応じて適合され得る。例えば、ポリシー要求を簡略化するために、必要とされる属性が少なくなるようにポリシー・データベース（図３のデータベース３５５参照）又は変換テーブルを使用することもでき、実際には、ポリシー・クラスを定義する１つの属性だけを使用することもできる。
【００９７】
ＴＰＲＮ５００の機能は、システム１００内の他の任意のノードと同じ場所に配置することができ、ＩＭＳベース・システム１００では、そのようなノードは、例えばＳ‐ＣＳＣＦ３２５であることも、アプリケーション・サーバ・システム２２５内の任意のアプリケーション・サーバであることもある。しかしながら、ＴＰＲＮ機能を別個の論理ノードの形で実装しても、標準化されたノードであるＳ‐ＣＳＣＦ３２５を変更する必要は生じない。更に、アプリケーション・サーバ・システム２２５は、２つ以上のアプリケーション・サーバと単一のＴＰＲＮ５００とを必要とする可能性があるので、ＴＰＲＮ５００を別個のノードとして有することは、ＴＰＲＮ５００をアプリケーション・サーバと同じ場所に配置する場合よりも単純な解決策を提供する。
【００９８】
本発明を実施するシステム１００では、サービスのポリシー決定が従来技術（図４参照）に従ってＡＦ２１５によって開始されることが最良である場合と、アプリケーション・サーバ・システム２２５（図９参照）によって開始されることが最良である場合とが存在する可能性が高い。有利なことに、ユーザ機器１０５又は他のエンド・ノードによるセッションの開始時にＡＦ２２０がこれらの２つの場合を区別するために、ポリシー決定がＡＦ  ２２０によって開始されるべきか否かをＡＦ２２０に通知するフラグ又は他の手段を開始エンド・ポイントからＡＦ２２０に送信されるセッション招待メッセージに含めることができる。
【００９９】
図１０ａには、ＡＦポリシー決定フラグ１０１０をポリシー決定インジケータとして含むセッション開始メッセージ１０００の一例が示される。メッセージ１０００は更に、ヘッダ１００５と、セッション開始に関する他の情報１０１５とを含む。ユーザ機器１０５のアプリケーション２４０がセッション開始メッセージを生成するときに、そのセッション開始メッセージのポリシーＡＦポリシー決定フラグは、セット・アップされるセッションに適した値に設定される。
【０１００】
別法として、メッセージ１０００の他の情報１０１５内のパラメータ又はパラメータの組合せを、例えばクラス・サービス・インジケータ（ＣＳＩ）やセッション開始メッセージ内の同様のサービス識別子等のＡＦポリシー決定インジケータとして使用することもできる。ＡＦ２２０は、ＡＦ２２０がどのサービスについてポリシー決定を開始すべきかに関する情報、及び／又はどのサービスに関するポリシー決定がアプリケーション・サーバ・システム２２５によって開始されるべきかに関する情報を記憶することができる。このような情報は、例えばＡＦ２２０がポリシー決定を開始すべき又は開始すべきでないサービスのサービス識別子のリストである可能性がある。
【０１０１】
図１０ｂは、ポリシー決定がＡＦ２２０によって開始されるべきか否かを判定するのに使用されるＡＦ２２０内のプロセスを概略的に示すフローチャートである。ステップ１０５０で、（ポリシー決定がセッション開始メッセージによってトリガされるのかそれともセッション開始応答メッセージによってトリガされるのかに応じて）セッション開始メッセージ又はセッション開始応答メッセージが受信される。次に、ステップ１０５５に進むと、ＡＦ２２０がポリシー決定を開始すべきことがＡＦポリシー決定インジケータによって示されるかどうかが検査される。そうである場合には、ステップ１０６０に進んでＡＦ２２０がポリシー決定を開始する。次に、ステップ１０６５に進むと、ポリシー要求が該当ノードに転送される。ＡＦ２２０がポリシー決定を実行すべきでないことがＡＦポリシー決定インジケータによって示される場合には、ステップ１０５０の後、ステップ１０６０には進まずに直接ステップ１０６５に進む。
【０１０２】
ＴＰＲＮ５００の機能は、システム１００内の他の任意のノードと同じ場所に配置することができ、ＩＭＳベース・システム１００では、そのようなノードは、例えばＳ‐ＣＳＣＦ３２５であることも、アプリケーション・サーバ・システム２２５内の任意のアプリケーション・サーバであることもある。しかしながら、ＴＰＲＮ機能を別個の論理ノードの形で実装しても、標準化されたノードであるＳ‐ＣＳＣＦ３２５を変更する必要は生じない。更に、アプリケーション・サーバ・システム２２５は、２つ以上のアプリケーション・サーバと単一のＴＰＲＮ５００とを必要とする可能性があるので、ＴＰＲＮ５００を別個のノードとして有することは、ＴＰＲＮ５００をアプリケーション・サーバと同じ場所に配置する場合よりも単純な解決策を提供する。
【０１０３】
本発明は、単なる例示として提示される添付図面及び上記の詳細な説明に開示される実施形態に限定されるものではなく、様々な手法で実施され得ることが当業者には理解されるだろう。
【図１】
2011502383.tif 000003
【図２】
2011502383.tif 000004
【図３】
2011502383.tif 000005
【図４】
2011502383.tif 000006
【図５】
2011502383.tif 000007
【図６】
2011502383.tif 000008
【図７】
2011502383.tif 000009
【図８】
2011502383.tif 000010
【図９】
2011502383.tif 000011
【図１０ａ】
2011502383.tif 000012
【図１０ｂ】
2011502383.tif 000013
【国際調査報告】
2011502383.tif 000014
2011502383.tif 000015
2011502383.tif 000016