JP4875165B2 - ベアラへのユーザ装置ごとのサービス要求条件を保証する装置および方法 - Google Patents

Description

本発明は一般に、信号層を通じて交渉されるサービス要求条件であって、サービスは実際には接続層またはベアラ層を通じて伝わるサービス要求条件に関する。本発明は特に、任意のユーザ装置に対してサービス要求条件を保証するために、ベアラ層において制御ルールが導入されるシナリオに適用される。

近頃、ユーザ装置（以下、ＵＥ）を有するユーザは、シグナリング層を介して、複数のサービスに対するサービス品質（以下、ＱｏＳ）のようなサービス要求条件を電気通信網と交渉できるシナリオがある。当該複数のサービスは、実際には、アクセスネットワークにより提供される分離したベアラ層または接続層を通じて伝わる。これらのシナリオのうち、ユーザにインターネット・プロトコル（以下、ＩＰ）の接続を提供するものが現在では特に重要である。この状況において、本明細書を通じて説明されるシナリオは、いわゆるＩＰ接続アクセスネットワーク（以下、ＩＰ−ＣＡＮ）を含み、ＩＰ−ＣＡＮを通じてユーザはＩＰパケットを交換できる。より具体的には、ベアラ層または接続層は、複数のＩＰフローを伝えられるメディア・トランスポートであり、トラフィック・プレーンで発生する。ＩＰフローは、同一の送信元ＩＰアドレス及びポート番号、同一の宛先ＩＰアドレス及びポート番号、そして恐らくは同一のトランスポート・プロトコルを有するＩＰパケットの一方向のフローである。従って、ＩＰフローは始点と宛先との間でＩＰパケットを伝送するために用いられる。各ＩＰフローは一つのサービスに関連付けられてもよく、いくつかのＩＰフローが同一のサービスに関連付けられてもよい。

例えば、第１のシナリオは、３ＧＰＰのＴＳ ２３．２２８ Ｖ７．５．０で規定されるように、ユーザがサービス要求条件をＩＰマルチメディア・サブシステム（以下、ＩＭＳ）と交渉するものであってもよい。ここでは、サービスは実際には汎用パケット無線システム（以下、ＧＰＲＳ）接続層のようなＩＰ−ＣＡＮを通じて伝わる。この第１のシナリオでは、プロキシ呼セッション制御機能（以下、Ｐ−ＣＳＣＦ）はＩＭＳへのエントリ・ポイントであり、制御プレーンでシグナリング層内に配置され、従って交渉されたサービス要求条件を知っている。一方、この第１のシナリオのベアラ層は、ＵＥ、サービスＧＰＲＳサポートノード（以下、ＳＧＳＮ）、及びゲートウェイＧＰＲＳサポートノード（以下ＧＧＳＮ）の間で確立された接続パスを通じて構築される。第２のシナリオは、ユーザがビデオ・ダウンロード・サービスのためのストリーミング・サーバのようなアプリケーション・サーバ（以下、ＡＳ）とサービス要求条件を交渉するものであってもよい。ここでは、サービスは実際には無線ローカルエリアネットワーク（以下、ＷＬＡＮ）接続層のようなＩＰ−ＣＡＮを通じて伝わる。この第２のシナリオでは、ストリーミング・サーバはサービス要求条件をＵＥに交渉することを担当するエンティティであり、制御プレーンでシグナリング層内に配置される。ここで、ベアラ層は、ＵＥ、ＷＬＡＮアクセスポイント（以下、ＷＬＡＮ ＡＰ）、ＷＬＡＮアクセス・ゲートウェイ（以下、ＷＡＧ）、およびパケットデータ・ゲートウェイ（以下、ＰＤＧ）の間の接続パスを通じて構築される。制御プレーンにおけるシグナリング層とトラフィック・プレーンにおけるベアラ層との異なる組合せを有することによって、新たなシナリオが明白であるだろう。

一方、ポリシー及び課金制御（以下、ＰＣＣ）と呼ばれる共通のアーキテクチャが現在、３ＧＰＰのＴＳ２３．２０３ Ｖ２．０．０のもとで開発されている。このＰＣＣはすべての異なる種類のアクセスネットワークに対応しているといわれていて、ベアラ層を通じて輸送されるメディアが、シグナリング層を通じて交渉された対応するサ−ビス要求条件の観点でどのように扱われるかを制御することが意図される。言い換えると、基本的なＰＣＣアーキテクチャはユーザ装置と制御プレーン内のサーバとの間でシグナリング層を通じてサービスが交渉されるシナリオに適用されるのに適している。ここで、当該サービスは実際には接続層またはベアラ層を通じて、おそらくは発信ユーザ装置と宛先ユーザ装置との間で伝わる。

３ＧＰＰのＴＳ ２３．２０３に従うと、ＰＣＣアーキテクチャは、所与のサービスに関連付けられた特定のＩＰフローを検出するためのネットワーク制御を定義することを担当するいわゆるポリシー及び課金ルール機能（以下、ＰＣＲＦ）を含み、交渉されたサービス要求条件をベアラ層に施行する制御ルールを生成することによってシグナリング層から受信した情報に基づく決定を行い、さらに当該所与のサービスのためにベアラ層で発生した重大なイベントについてサービス層に通知する。このＰＣＲＦは好適には制御プレーン内の第１のエンティティとトラフィック・プレーン内の第２のエンティティとに通信可能な中間のエンティティ内に配置される。ＰＣＣアーキテクチャはまた、所与のサービスに関連付けられたこの特定のＩＰフローを検出することと、ＰＣＲＦから受信した上記の制御ルールを導入することによりシグナリング層を通じて交渉されたサービス要求条件をベアラ層におけて施行することと、を担当するいわゆるポリシー及び課金施行機能（以下、ＰＣＥＦ）を含む。ＲＣＥＦはトラフィック・プレーンに含まれてもよく、発信ユーザ装置と宛先ユーザ装置との間の接続層またはベアラ層を支援する。ＰＣＥＦおよびＰＣＲＦとは別に、ＰＣＣアーキテクチャはまた、ＩＰベアラのリソースの制御を要求するアプリケーションを提供するアプリケーション機能（以下、ＡＦ）を含む。特に、ＡＦは、交渉されたサービス要求条件を知っている制御プレーン内のサーバ内に存在してもよいし、当該サーバの一部分であってもよい。ＡＦは、ＰＣＲＦの決定のため及び制御ルールの生成のために要求される交渉された動的セッション情報、つまりサービス要求条件を含むサービス情報を転送するためにＰＣＲＦと通信する。

上記の例示的なシナリオに関して、ＩＭＳや適切なアプリケーションサービスのような制御プレーンにおけるアプリケーションすなわちシグナリング層におけるアプリケーションにおいてユーザを登録する前に、ユーザはＩＰ−ＣＡＮを通じてすなわちベアラ層において、ベアラを確立する必要がある。特に、ＩＰ−ＣＡＮがＧＰＲＳアクセス・ネットワークであり且つユーザがＩＭＳネットワークに登録するつもりである場合に、ユーザはまず、ＩＭＳシグナリングを担うＧＰＲＳアクセスネットワークを通じて、プライマリ・パケット・データ・プロトコル（以下、ＰＤＰ）コンテキストを起動する必要がある。ＩＭＳネットワークは一般にセッション確立プロトコル（以下、ＳＩＰ）を利用し、その結果、本議論の目的で、ＩＭＳシグナリングは慣例的にＳＩＰシグナリングとして理解される。このように、ＩＰ−ＣＡＮを通じたベアラの確立は、ＩＰ−ＣＡＮとしてＧＰＲＳアクセスネットワークを有するシナリオにおいて、プライマリＰＤＰコンテキストの起動として理解される。そして、ユーザがＩＰ−ＣＡＮを通じてベアラをひとたび確立すると、ユーザは制御プレーンにおけるアプリケーションに登録でき、例示的なＩＭＳ、例示的なＡＳ、または宛先ユーザに対して、ベアラ層を通じたメディアの伝送に適用されるサービス要求条件を交渉できる。

例えば、図１ａおよび図１ｂで説明されるように、ＧＰＲＳのＩＰ−ＣＡＮを通じてユーザがＩＭＳにアクセスするつもりの上記第１のシナリオにおいて、ユーザはプライマリＰＤＰコンテキストの起動を要求し、この要求はＳＧＳＮを介してＧＧＳＮで受信される。所与のユーザに対するプライマリＰＤＰコンテキストに適用するために事前設定されたルールを要求するために、ＧＧＳＮはいわゆるＣＣＲメッセージをＰＣＲＦに向けて送出する。ＰＣＲＦは加入プロファイル・レジストリ（以下、ＳＰＲ）と連携して、当該所与のユーザに対してサポートされるサービスを示す事前設定されたルールで適用可能なものを取得し、これらをＣＣＡメッセージとともに送り返す。その後に、ＧＧＳＮはユーザに対してプライマリＰＤＰコンテキストの起動の確認を返す。

ＩＭＳシグナリングを担うためのベアラがひとたび確立されると、ユーザはＩＭＳに登録できる。この目的のために、ユーザはＩＭＳのエントリ・ポイントであるＰ−ＣＳＣＦに向けてＳＩＰ登録メッセージを送出し、ひとたびユーザの登録がＩＭＳによって受け付けられサービング呼セッション制御機能（以下、Ｓ−ＣＳＣＦ）がユーザにサービスを提供するために割当てられると、登録が成功したことを示すＳＩＰのＯＫメッセージをユーザは受信する。ユーザは宛先ユーザと通信セッションを確立することを望むかも知れず、この目的のためにＳＩＰ招待メッセージを送出する。この段階において、複数のサービスパラメータすなわちサービス要求条件が、通信に関与するユーザ装置とおそらくはネットワークとの間で交渉される。このサービス要求条件はいわゆるサービス・データ・プロトコル（以下、ＳＤＰ）でＰ−ＣＳＣＦを通じて交渉され、最終的にＰ−ＣＳＣＦはＰＣＲＦに交渉されたサービス要求条件をいわゆるＡＡＲメッセージで送出し返す。ＡＡＲメッセージはとりわけ、交渉された通信セッションのためのメディア・コンポーネント、メディアの種類（例えば、オーディオまたはビデオなど）、および交渉されたＱｏＳパラメータについての情報を含む。

より一般的なシナリオにおいて、基本的に上記に記載されたＰＣＣアーキテクチャに従って、サービス要求条件はいわゆるＡＦを通じて交渉され、ＡＦはサービス要求条件をＰＣＲＦに送る。ＡＦの役割は、この第１のシナリオにおいて、Ｐ−ＣＳＣＦによって実行される。このサービス要求条件が受信されると、ＰＣＲＦは適用する制御ルールを決定でき、制御ルールをＰＣＥＦに導入できる。

この段階において、ＰＣＲＦは、ＩＰ−ＣＡＮを通じて現在確立されているベアラのために制御ルールを導入するか、現在の傾向がユーザ装置による次の生成を示唆するような、交渉されたサービスのための更なる専用のベアラの確立を待つか、のいずれを行うかを決定する必要がある。ここで、ＩＰ−ＣＡＮを通じて現在確立されているベアラは、この第１のシナリオでは、ユーザがＧＰＲＳネットワークを通じてＩＭＳに登録しているプライマリＰＤＰコンテキストである。

ＰＣＲＦが、交渉されたサービスのために更なる専用のベアラが確立されるのを待つことを決定し、且つ上記の第１の例示的なシナリオにおいてユーザにより現在使用されているＵＥが更なるベアラを確立できる場合に、ＧＧＳＮはＳＧＳＮを介してセカンダリＰＤＰコンテキストの起動の要求を受信してもよい。このセカンダリＰＤＰコンテキストの起動の要求は、Ｐ−ＣＳＣＦまたはより一般的にはサービスが交渉されていたＡＦから事前に受信された通信セッションとサービス要求条件とを特定することをＰＣＲＦにさらに可能にさせる情報を含むことが期待される。ＧＧＳＮは適用する制御ルールの特定に関連するこの情報をいわゆるＣＣＲでＰＣＲＦに向けて送出し、ＰＣＲＦはそこで導入される制御ルールをいわゆるＣＣＡでＧＧＳＮに戻す。一般的に言うと、ＰＣＲＦは導入されて適用される制御ルールをＰＣＥＦに戻し、この第１のシナリオでは、ＧＧＳＮはＰＣＣアーキテクチャで説明されるようなＰＣＥＦの機能として振舞うか、またはＧＧＳＮは当該機能を含む。そして、ひとたびＧＧＳＮまたはより正確にはＧＧＳＮ内のＰＣＥＦにおいて制御ルールが導入されると、セカンダリＰＤＰコンテキストの起動はユーザに対して確認を返し、最終的に通信セッションはＰＣＲＦからＡＦに対して、またはこの第１のシナリオでは、ＡＦ機能を含むＰ−ＣＳＣＦに向けて確認される。

しかしながら、ＰＣＲＦが後続するベアラの確立を待つことを決定し、且つＵＥが後続するベアラの確立をサポートできない場合に、待機中の制御ルールは導入されず、サービスは実行され得ないだろう。

一方、ＰＣＲＦがすでに確立されているベアラに対して生成された制御ルールを直ちに導入することを決定し、且つユーザが後続するベアラの確立をさらに要求する場合に、例示的なＩＭＳ、例示的なＡＳ、または宛先ユーザのいずれかである相手側は同一のユーザとの新たな通信セッションの確立を理解しているかもしれないのにもかかわらず、サービス要求条件を交渉する処理が繰り返されるかもしれない。

本発明の目的は、上述の欠点の少なくとも一部を取り除くことであり、シグナリング層を通じてサービスについて交渉されたサービス要求条件をベアラに保証する強化された仕組みであって、ベアラ層はサービス関連の複数のＩＰフローを運ぶことができるメディア・トランスポート層であり、シグナリング層はベアラ層を通じて輸送されるメディアがどのように扱われるべきかを交渉するために用いられる仕組みを提供することである。

すでに確立されているベアラに対する制御ルールの送出および導入と、最終的に生じた後続するベアラに対するこれらの制御ルールの後からの置き換えとは、サービスが実行され得るベアラに対して制御ルールが導入されないという上記の問題を打ち破る理にかなった解法であるかもしれないと考えるかもしれない。しかしながら、この方法はＰＣＥＦとＰＣＲＦとの間のより複雑な手順とシグナリングとを暗示するだろうし、ユーザが最終的にこのような後続するベアラの起動を要求した場合に備えて、後続するベアラに対して再導入される候補として印をつけて以前に導入された制御ルールを常に維持することを暗示する。

従って、本発明の更なる目的は、シグナリング層を通じてサービスについて交渉されたサービス要求条件をベアラに保証する強化された仕組みであって、ＰＣＣアーキテクチャのエンティティ間で交換されるシグナリングの量と実行される動作の量とが、旧式のユーザ装置とより新しいユーザ装置との両方から期待される操作性を許容しつつ、現在開発されるものに匹敵する水準に維持される仕組みを提供することである。

上記目的は一般に、本発明に従って、シグナリング層を通じてサービスについて交渉されたサービス要求条件をベアラに保証する、ＰＣＲＦとして動作可能である制御サーバを提供することによって達成される。この点において、ベアラ層はサービス関連の複数のＩＰフローを運ぶことができるメディア・トランスポート層であり、シグナリング層はベアラ層を通じて輸送されるメディアがどのように扱われるべきかを交渉するために用いられる。

この制御サーバは、ベアラ層内のエンティティとインタフェースで接続可能であり、所与のユーザに対するサービス関連のＩＰフローを運ぶためのベアラの確立に関する情報を受信するように構成された第１の受信器と、シグナリング層内のエンティティとインタフェースで接続可能であり、サービスについて交渉されたサービス要求条件を含むメディアに関するサービス情報を受信するように構成された第２の受信器とを備える。特に、これら第１の受信器と第２の受信器とは別個の要素として実装されてもよいし、他のエンティティとインタフェースで接続する他の受信器とともに受信器モジュール内に統合されてもよい。

制御サーバにベアラの確立について知らせるベアラ層内のエンティティに関して、このようなエンティティは、ＩＰ−ＣＡＮがＧＰＲＳネットワークである場合にＧＧＳＮであってもよいし、ＩＰ−ＣＡＮがＷＬＡＮネットワークである場合にＰＤＧであってもよいし、もっと正確には、ＧＧＳＮまたはＰＤＧに含まれてもよい、ＰＣＣアーキテクチャに従うＰＣＥＦであってもよい。

交渉されたサービス要求条件を含むメディアに関する情報を送出するシグナリング層内のエンティティに関して、このようなエンティティは、ユーザがＩＭＳネットワークにアクセスしていた場合にＰ−ＣＳＣＦであってもよいし、ユーザが例えばビデオをダウンロードするためのビデオ・ストリーミング・サーバにアクセスしていた場合にＡＳであってもよいし、もっと正確には、Ｐ−ＣＳＣＦまたはＡＳに含まれてもよい、ＰＣＣアーキテクチャに従うＡＦであってもよい。

本発明の態様に従って、この制御サーバはまた、所与のユーザにより現在使用されているユーザ装置についてのＵＥ能力（ｃａｐａｂｉｌｉｔｙ）を取得するように構成された能力ハンドラと、サービス要求条件をベアラに保証するために適用される制御ルールを決定するように構成されたプロセッサであって、当該制御ルールは交渉されたサービス要求条件を含み且つシグナリング層内のエンティティから受信されたサービス情報に基づき、且つユーザ装置についてのＵＥ能力に基づくプロセッサと、ユーザ装置のＵＥ能力に応じて、ベアラ層内でポリシー及び課金施行機能として動作可能なエンティティに向けて導入される制御ルールを送出するか、制御ルールをそこに導入するための後続するベアラの確立を待つか、のいずれかを行うように構成されたインストーラとを備える。この点において、ＧＧＳＮとＰＤＧとの両方ともがＰＣＥＦとして動作可能なエンティティであってもいい一方で、Ｐ−ＣＳＣＦとＡＳとの両方ともがＡＦとして動作可能なエンティティであってもよい。

この制御サーバ内の能力ハンドラは、外部のＵＥ能力レポジトリから、またはローカルのＵＥ能力レポジトリから、ＵＥ能力を取得してもよい。このような外部との通信を容易にするために、前者は能力ハンドラ内にプロトコル・ハンドラを含むことを要求するかもしれない。従って、制御サーバ内の能力ハンドラとＵＥ能力レポジトリとの両方が、ＱｏＳ管理、ユーザ装置ごとのサポートされるサービス、後続して確立されるベアラの最大数、およびサポートされるＱｏＳモデルを含むＵＥ能力群から選択された少なくとも一つのＵＥ能力をそれぞれ取得し提供するように構成される。

一般的に言うと、ＵＥ能力である「ユーザ装置ごとのサポートされるサービス」は、ユーザ加入契約に対してサポートされるサービスを示す既存の事前設定されたルールをフィルタするのに用いられてもよい。これは、このような既存の事前設定されたルールは、ＵＥによってサポートされなければ、役に立たないだろうからである。一方、上述されたすべてのＵＥ能力は単独でまたは組み合わされて、本発明の目的のために、適用可能な制御ルールを生成し適用するのに好適である。例えば、上記のインストーラは、後続して確立されるベアラの最大数に到達しているか否かに基づいて、すでに確立されているベアラに対して導入される制御ルールを送出するか、制御ルールを導入するための後続するベアラが確立されるのを待つか、のいずれかを行ってもよい。

「後続して確立されるベアラの最大数」を考慮に入れる上記の利点は、ネットワーク・エンティティがベアラの確立の主導権を握ることができるように、「ＱｏＳモデル」のような他のＵＥ能力と組み合わせて扱われてもよい。例えば、上記のインストーラは、後続して確立されるベアラの最大数にすでに到達している場合に現在確立されているベアラに対して当該制御ルールを導入するか、後続して確立されるベアラの最大数にまだ到達していない場合に新たなベアラの確立し、確立された時点で新たな後続するベアラに対して当該制御ルールを導入することを要求するか、のいずれかを示す指標とともに、インストールされる制御ルールを送出してもよい。

制御サーバおよびＵＥ能力レポジトリから離れて、シグナリング層を通じてサービスについて交渉されたサービス要求条件をベアラ層に保証する対応する方法が提供される。この方法は、制御サーバおよびＵＥ能力レポジトリに含まれる構造要素によって実行される動作として、対応するステップを含む。

本発明の機能、目的、および利点は添付の図面とともに本明細書を読むことで明らかになるだろう。

、 ユーザがＩＭＳネットワークとサービス要求条件を交渉し、サービスは実際には接続層を提供するＧＰＲＳネットワークを通じて伝わる第１のシナリオにおける方法の一例を説明する図である。 シグナリング層を通じてサービスについて交渉されたサービス要求条件をベアラ層に保証する方法であって、ユーザがサービス要求条件をＩＭＳネットワークと交渉する第１のシナリオで適用され、サービスは実際には接続層を提供するＧＰＲＳネットワークを通じて伝わる方法の実施形態の一例を表す図である。 本発明の実施形態に従って、ＰＣＲＦの基本ブロック図および構成要素と、ＰＣＲＦのＰＣＥＦ、ＡＦ、ＳＰＲ、および外部のＵＥ能力レジストリとの接続とを説明する図である。 本発明の実施形態に従って、ローカルのＵＥ能力レポジトリを含むＰＣＲＦの基本ブロック図および構成要素と、ＰＣＲＦのＰＣＥＦ、ＡＦ、およびＳＰＲとの接続とを説明する図である。 ユーザがＩＭＳネットワークとサービス要求条件を交渉し、サービスは実際には接続層を提供するＧＰＲＳネットワークを通じて伝わる第１のシナリオにおけるＰＣＣアーキテクチャの基本ブロック図の一例を示す。 ユーザが制御ブレーンにおけるアプリケーション・サーバとサービス要求条件を交渉し、サービスは実際には接続層を提供するＷＬＡＮネットワークを通じて伝わる第２のシナリオにおけるＰＣＣアーキテクチャの基本ブロック図の一例を示す。

シグナリング層を通じてサービスについて交渉されたサービス要求条件をベアラ層に保証する強化された仕組みのための好適な実施形態を以下に説明する。ベアラ層はサービス関連の複数のＩＰフローを運ぶことができるメディア・トランスポート層であり、シグナリング層はベアラ層を通じて輸送されるメディアがどのように扱われるべきかを交渉するために用いられる。

図２は、上記の第１のシナリオおよび第２のシナリオのような、シグナリング層を通じてサービスについて交渉されたサービス要求条件をベアラ層に保証するためのＰＣＣアーキテクチャを利用するシナリオで適用され得る総括的な方法を説明する。この図２における一連の動作は、第１のシナリオおよび第２のシナリオではそれぞれＧＰＲＳまたはＷＬＡＮであってもよい特定のＩＰ−ＣＡＮにユーザがアクセスすることを示さず、従って、ＩＭＳまたはビデオ・ストリーミングＡＳであってもよい制御プレーン内のアプリケーションにユーザがアクセスするためのＩＰ接続を提供する最初のベアラへの確立の要求を示さない。

図２における一連の動作は、ベアラ層におけるエンティティ３２、すなわち図５および図６に説明されるようなＩＰ−ＣＡＮがＧＰＲＳネットワークであるＧＧＳＮ２１に含まれてもよいし、又はＩＰ−ＣＡＮがＷＬＡＮネットワークであるＰＤＧ５１に含まれてもよいＰＣＥＦは、ステップＳ−１２１で、制御サーバ３１に向けて、所与のユーザに対するサービス関連のＩＰフローを運ぶベアラの確立に関する情報を、このようなベアラのための制御ルールを依頼するために送出することで始まる。特に、ステップＳ−１２１においてベアラの確立に関する情報を受信するこの制御サーバ３１は、ＰＣＣアーキテクチャに従って論理的にシグナリング層とベアラ層との間に置かれた孤立したＰＣＲＦであってもよいし、シグナリング層またはベアラ層に配置された別のエンティティに組み込まれもよいし、当該別のエンティティと一体であってもよい。特に、ＩＰ−ＣＡＮを通じたベアラの確立は、ＩＰ−ＣＡＮとしてＧＰＲＳアクセスネットワークを有するシナリオにおいてＰＤＰコンテキストの確立として理解される。ＩＭＳまたはサービスを実行する特定のＡＳにアクセスするためにＧＰＲＳを通じて確立されたこの最初のベアラは一般にプライマリＰＤＰコンテキストと呼ばれ、ＧＰＲＳアクセスネットワークを通じてさらに確立される後続するベアラは一般にセカンダリＰＤＰコンテキストと呼ばれる。これにもかかわらず、本発明の目的のために、および例示的に引用されるＧＰＲＳおよびＷＬＡＮのような、様々なＩＰ−ＣＡＮに対応することを考えて、議論中の例示的なＩＰ−ＣＡＮに関係なく、本明細書では「ベアラ」、「後続するベアラ」、および「ベアラの確立」と参照される。

この目的のために、図３および図４に説明されるように、制御サーバ３１は、特にＧＧＳＮ２１またはＰＤＧ５１であってもよいベアラ層におけるＰＣＥＦとして動作するエンティティ３２とインタフェースで接続可能な第１の受信器３３１を有し、この第１の受信器３３１は所与のユーザに対するサービス関連のＩＰフローを運ぶベアラの確立についての情報を受信するように構成される。この第１の受信器３３１は分離した要素として実装されてもよいし、他のエンティティとインタフェースで接続可能な他の受信器とともに受信器モジュール３１０に統合されてもよく、この受信器モジュール３１０は図３および図４において制限されないような方法で説明されるような入出力モジュール３１７の一部分であってもよいことを当業者は容易に推察できるだろう。

この段階において、制御サーバ３１は、図３および図４に説明されるユーザ・リポジトリ３４から取得できる所与のユーザに対する加入契約データに従って、ベアラ層内のＰＣＥＦとして動作するエンティティ３２がサポートするサービスを示す事前設定されたデータを提供してもよい。しかしながら、最近の好適な実施形態に従って、図２に示されるようにこの動作は、ステップＳ−１２２およびＳ−１２３で、制御サーバにおいて、所与のユーザにより現在使用されているユーザ装置１１のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザ装置）能力（ｃａｐａｂｉｌｉｔｙ）がＵＥ能力レポジトリ３１６から取得されるまで延期されてもよい。ひとたび制御サーバ３１がＵＥ能力を受信すると、有利には、サポートされると想定されるサービスが、ユーザにより現在使用されているＵＥのＵＥ能力によって効果的にサポートされることを評価するために、事前設定されたルールがフィルタされ得る。そして、その結果生じた事前設定されたルールはステップＳ−１２４において、ベアラ層内のＰＣＥＦとして動作するエンティティ３２に送り返されてもよい。ＵＥ能力によりサポートされるサービスを示すこの事前設定されたルールは現時点で存在する仕組みに対して有益な成果である。なぜなら、ユーザ加入契約によりサポートされるサービスはユーザにより現在使用されているＵＥによってサポートされないかもしれないからである。

この目的のために、制御サーバ３１は、所与のユーザにより現在使用されているユーザの装置１１のＵＥ能力を取得するように構成された能力ハンドラ３１５を含む。直前に言及された最近の好適な実施形態では、制御サーバ３１はまた、インストーラ３１４を含んでもよい。ここで、インストーラ３１４は他のタスクの中でさらに言及され、ステップＳ−１２４においてＰＣＥＦとして動作するエンティティ３２に向けて送出するように構成され、この結果生じる事前設定されたルールは確立されたベアラに対してＵＥ能力によってサポートされるサービスを示す。特にこの目的および他の目的に適用されるように、能力ハンドラ３１５から取得できるユーザ装置のＵＥ能力はユーザ装置ごとのサポートされるサービスに関する情報を含む。インストーラ３１４は図４に例示的に示されるように制御サーバ３１内の分離したモジュールとして提供されてもよいし、図３に例示的に示されるように入出力モジュール３１７に統合されてもよい。

図４に説明される本発明のある実施形態では、制御サーバ３１はユーザ装置１１のＵＥ能力を記憶するためのローカルのＵＥ能力レポジトリ（ＵＥ−ＣＲ）３１６を含み、ローカルのＵＥ能力レポジトリ３１６は能力ハンドラ３１５と内部で通信される。従って、ＵＥ能力を取得するステップＳ−１２２はＵＥ能力をローカルのＵＥ能力レポジトリ３１６で調べるステップを含む。

図３に説明される本発明の別の実施形態では、制御サーバ３１に含まれる能力ハンドラ３１５は外部のＵＥ能力レポジトリ３１６からユーザ装置１１のＵＥ能力を取得するためのクエリ・プロトコル・ハンドラ３１５１を備える。従って、ＵＥ能力を取得するステップＳ−１２２は外部のＵＥ能力レポジトリ３１６にＵＥ能力を問い合わせるステップを含む。どの図にも示されていない更なる実施形態では、このクエリ・プロトコル・ハンドラ３１５１は、図３に説明されるインストーラ３１４のように、入出力モジュール３１７に含まれてもよい。この実装は、唯一の入出力モジュールに外部通信のための接続を集約することを望まれる場合に有効であるかもしれない。

本発明の実施形態によれば、ＵＥ能力レポジトリ３１６は複数のユーザにより使用されるユーザ装置１１、１１２のＵＥ能力を提供するように構成される。この目的のために、ＵＥ能力レポジトリはユーザ単位のＵＥ能力のための記憶装置３１６１とユーザ装置１１、１２のＵＥ能力の供給を受けるための構成ユニット３１６２とを有する。特に、構成ユニット３１６２はシステムを供給するネットワーク事業者からインタフェースＩ−５０を通じてＵＥ能力を供給されてもよいし、装置モデルベースでＵＥ能力が供給されるＵＥサプライヤの前提のもとで専用の構成サーバに接続されてもよい。上記で言及され図４で説明される実施形態に従って、ＵＥ能力レポジトリ３１６が制御サーバ３１に含まれるローカルのエンティティとして提供される場合には、構成ユニット３１６２を入出力モジュール３１７に含めることを可能とするために、上記で説明された他の装置のように、構成ユニット３１６２は記憶装置３１６１から分離されてもよい。

図５および図６で説明されるように、特にＩＰ−ＣＡＮがＧＰＲＳネットワークである場合にＧＧＳＮ２１であってもよく、ＩＰ−ＣＡＮがＷＬＡＮネットワークである場合にＰＤＧ５１であってもよいＰＣＥＦとして動作するエンティティ３２が、図２で説明されるようにステップＳ−１２４において事前設定されたルールをひとたび受信すると、ＧＧＳＮ２１またはＰＤＧ５１はユーザに向けてこのようなベアラの確立を確認応答し、ユーザは、図５および図６に説明されるような制御プレーンにおいて、シグナリング層を通じて、つまりＰＣＣアーキテクチャに従えばＡＦ３３を通じてメディアの交渉を開始できる。

メディアに対するサービス要求条件がシグナリング層のＡＦ３３を通じてひとたび交渉されると、図２の一連の動作は継続し、ステップＳ−１２５でＡＦはサービスについて交渉されるサービス要求条件を含むメディアに関する情報を制御サーバ３１に向けて送出する。特に、このＡＦ３３は、図５および図６がそれぞれ説明するように、サービスを起動するＩＭＳにユーザがアクセスしている場合にＡＦとして動作することが可能なＰ−ＣＳＣＦ４１であってもよいし、例えばビデオをダウンロードするためのビデオ・ストリーミング・サーバにユーザがアクセスしている場合にＡＦとして動作することが可能なＡＳ６１であってもよい。

サービスについて交渉されたサービス要求条件を含むメディアに関するサービス情報がステップＳ−１２５の間に制御サーバ３１においてひとたび受信されると、制御サーバはステップＳ−１２６の間にサービス要求条件をベアラに保証するために適用する制御ルールを決定する。制御ルールはシグナリング層内のエンティティすなわちＡＦ３３から受信したサービス情報に基づいており、交渉されたサービス要求条件を含む。制御ルールはまた、ステップＳ−１２３でＵＥ能力レポジトリ３１６から取得されているであろう、ユーザにより現在使用されているユーザ装置１１のＵＥ能力に基づく。

この目的のために、図３および図４に説明されるように、制御サーバ３１は、シグナリング層のＡＦとして動作するエンティティ３３とインタフェースで接続可能な第２の受信器３１２を含む。ＡＦは特に図５および図６において説明されるようにＰ−ＣＳＣＦ４１またはＡＳ６１であってもよい。この第２の受信器３１２はサービスについて交渉されたサービス要求条件を含むメディアに関するサービス情報を受信するように構成される。制御サーバ３１はまた、ＡＦ３３から受信され、交渉されたサービス要求条件を含むサービス情報に基づき、且つユーザにより現在使用されているユーザ装置のＵＥ能力にも基づく当該制御ルールをステップＳ−１２６において決定するように構成されたプロセッサ３１３を含む。すでに上記で言及したように、この第２の受信器３１２は分離したの要素として実装されてもよいし、上記の第１の受信器３１１や他のエンティティとインタフェースで接続する他の受信器とともに受信器モジュール３１０に統合されてもよい。この受信器モジュール３１０は図３および図４で制限しないように説明されるように、入出力モジュールの一部分であってもよい。

この目的および他の目的のために特に適用できるように、能力ハンドラ３１５によりユーザ装置ごとに取得可能なＵＥ能力は、ＱｏＳクラスを引き出すための情報を提供するＱｏＳ管理に関する情報と、後続に確立されるベアラをＵＥがサポートできる最大数と、ネットワーク主導（以下、ＮＷ主導）であってもよいしＵＥ主導であってもよいサポートされるＱｏＳモデルと、を含む。ＱｏＳ管理に関する情報について、ステップＳ−１２５でＡＦから受信された情報は、例えば、メディアタイプが「ビデオ」であることを示してもよく、これはＱｏＳクラス「会話型」に対応する。一方で、サービス情報はまた、ＱｏＳクラス「会話型」がサポートされないことを示してもよい。この状況では、このようなＱｏＳクラス「ストリーミング型」がＵＥに対するＵＥ能力によりサポートされるという条件で、メディアタイプ「ビデオ」はＱｏＳクラス「ストリーミング型」に対応付けされる。なぜならば、対応付けは好適にはＵＥ能力によってサポートされる最高のＱｏＳクラスに対して行われるからである。適用されるＱｏＳモデルについて、ベアラに関連するＮＷ主導の修正はサポートしないがＵＥ主導の修正のみをサポートするユーザ装置があってもよい。従って、制御サーバ３１は、導入される制御ルールを決定する前に、このＵＥ能力であるＱｏＳモデルを考慮に入れる。この目的のために、プロセッサ３１３は好適には、ＵＥ能力に基づいて、適用するＱｏＳモデルがＮＷ主導であるかＵＥ主導であるかを決定するステップを実行してもよい。しかしながら、能力ハンドラ３１５によりこのようなステップは実行されてもよいので、他の装置も可能である。すでに上記で言及したように、本発明のいくつかの実施形態では、ユーザ装置ごとのＵＥ能力は能力ハンドラ３１５によってＵＥ能力レポジトリ３１６から取得できる。従って、ＵＥ能力レポジトリ３１６は、ＱｏＳ管理と、ユーザ装置ごとのサポートされるサービスと、後続して確立されるベアラの最大数と、サポートされるＱｏＳモデルとを含むＵＥ能力のグループから選択された少なくとも一つのＵＥ能力を提供するように構成される。

適用する制御ルールを制御サーバ３１において決定するステップＳ−１２６は、所与のユーザにより現在使用されているＵＥ１１のＵＥ能力に基づいて二つの異なる結果を提供してもよい。一方の結果においては、取得されたＵＥ能力は、ＵＥがサービス要求条件に従って後続するベアラの確立を要求できることを示してもよい。後続するベアラが確立され得るかどうかを決定するために、制御サーバ３１は、ＵＥ能力に示されるような、後続して確立されるベアラの最大数にすでに到達しているかどうかを調べてもよい。この最大数に到達していることを制御サーバが見つけた場合に、ＵＥは後続するベアラの確立を要求することができず、図２に示されるように、ステップＳ−１２７で、ＰＣＥＦ３２において現在確立されているベアラに対してルールが導入される。そうではなく、最大数にまだ到達しておらず、ＵＥモデルだけがサポートされることをＵＥ能力が示す場合に、制御サーバ３１は後続するベアラの確立を待つステップＳ−１３０を続けることを決定してもよく、従って、導入を待機中という印を現在の制御ルールにつけてもよい。一方、代替の実施形態として、ＮＷ始動のモデルがサポートされることをＵＥ能力が示す場合に、制御サーバ３１はステップＳ−１２７において、最大数にまだ到達していない場合に新たな後続するベアラの確立と当該新たな後続するベアラに対する当該制御ルールの導入とを要求するか、最大数にすでに到達している場合に現在確立されているベアラ内に当該制御ルールを導入することか、のいずれかを行うことの指標とともに、ベアラ層内のＰＣＥＦ３２に向けて制御ルールを送出してもよい。

この目的のために、前述の他の目的のために説明された制御サーバ３１に含まれるインストーラ３１４は、ユーザ装置１１のユーザ能力に基づいて、導入される制御ルールをベアラ層内のＰＣＥＦとして動作可能なエンティティ３２に向けて送出するか、制御ルールを導入するための後続するベアラの確立を待つか、のいずれかを行うように構成される。本発明のある実施形態では、制御サーバ３１のプロセッサ３１３は、ＵＥ能力で示されるように、後続して確立されるベアラの最大数にすでに到達しているかどうかを調べる。この最大数に到達していることをプロセッサか見つけた場合に、インストーラ３１４は、ベアラ層内でＰＣＥＦとして動作可能なエンティティ３２で現在確立されているベアラに対して導入される制御ルールを送出する。そうではなく、後続して確立されるベアラの最大数にまだ到達していない場合に、インストーラは制御ルールが導入されるだろう後続するベアラの確立を待つように構成される。

本発明の別の実施形態では、インストーラ３１４は、ベアラ層においてＰＣＥＦとして動作することができるエンティティ３２に向けて、後続して確立されるベアラの最大数にすでに到達している場合には現在確立されているベアラに対する当該制御ルールを導入することの指標とともに、または、後続して確立されるベアラの最大数にまだ到達していない場合には新たな後続するベアラの確立とひとたび確立されたこの後続するベアラに対する当該制御ルールの導入とを要求することの指標とともに、導入される制御ルールを送出する。

すでに前述したように、インストーラ３１４は図４に示された例のように制御サーバ３１内の分離したモジュールとして提供されてもよいし、図３に示された例のように入出力モジュール３１７に統合されてもよい。

従って、特にＰＣＣアーキテクチャのＰＣＲＦであってもよい制御サーバ３１におけるこの新たな振る舞いは、上述されたような本発明の目的を達成する。制御サーバ３１にＰＣＲＦの機能を実装する場合に、本明細書全体を通じて参照される制御ルールは３ＧＰＰのＴＳ２３．２０３で規定されるようないわゆるＰＣＣルールに含まれるもののような、その他の重要なフィールドとパラメータとを含んでもよい。

実施形態の実装に関して、本発明は、処理ユニットだけでなく入力ユニットおよび出力ユニットを含むコンピュータの内部メモリへ読み出し可能なコンピュータ・プログラムによって実現されてもよい。このコンピュータ・プログラムは、コンピュータで実行される際に、上記の実施形態のもとで説明された一連の動作を実行するように構成された実行可能なソフトウェア部分を備える。特に、コンピュータ・プログラムはＣＤ−ＲＯＭのような搬送用コンピュータ可読媒体に記録されてもよい。

適用性に関して、本発明は、上記の第１のシナリオおよび第２のシナリオのほかに、これらの組合せとして適用されても全くかまわない。ＵＥである「ＵＥ−Ａ」１１を有するユーザがＩＰ−ＣＡＮとしてのＧＰＲＳネットワークを通じてＩＭＳネットワークに登録されることを望む例示的な第１のシナリオでは、ユーザはＧＧＳＮ２１でプライマリＰＤＰコンテキストを起動する必要がある。その後に、ＧＧＳＮは制御サーバ３１にプライマリＰＤＰコンテキストの起動の要求について知らせ、ＰＣＣアーキテクチャに従うＰＣＲＦであってもよい制御サーバ３１は、ＵＥ能力レポジトリ３１６に問い合わせる。ユーザにより現在使用されているＵＥに対するＵＥ能力を取得すると、制御サーバはユーザ加入契約によりサポートされ且つＵＥ能力によってサポートされるサービスを示す事前設定された有効なルールをフィルタしてもよく、これらの事前設定されたルールをＧＧＳＮに向けて返す。ＧＧＳＮは、ＵＥ１１を有するユーザがＩＭＳネットワークにアクセスできるプライマリＰＤＰコンテキストの起動をユーザに向けて確認応答する。ユーザは、恐らくはＵＥである「ＵＥ−Ｂ」１２を有する宛先ユーザとの通信を設定するために、Ｐ−ＣＳＣＦ４１を通じてＩＭＳにアクセスする。その後に、メディアの交渉はシグナリング層のエンティティを通じて実行される。ひとたびＰ−ＣＳＣＦ４１を通じてメディアが交渉されると、Ｐ−ＣＳＣＦ４１またはより正確にはこれに含まれるＡＦ３３は、サービスについて交渉されたサービス要求条件を含むメディアに関するサービス情報を制御サーバ３１に向けて送出する。当該サービス情報を受け取った制御サーバはベアラ層にサービス要求条件を保証するために適用する制御ルールを決定する。これらの制御ルールはＡＦから受け取ったサービス情報に基づいて、および以前に取得されたＵＥ能力に基づいて決定される。これらの制御ルールに基づいて、制御サーバ３１は、恐らくはＧＧＳＮ２１に含まれるベアラ層内のＰＣＥＦ３２に向けて当該制御ルールを導入のために送出するか、または例えばＵＥ−Ａ１１に対するＰＤＰコンテキストの最大数に到達していない場合に、セカンダリＰＤＰコンテキストの起動を待つか、のいずれかを行う決定を行う。特に、ＵＥがプライマリＰＤＰコンテキストのみをサポートし、後続するＰＤＰコンテキストをサポートしない旧式の端末である場合に、制御サーバは現在起動されているプライマリＰＤＰコンテキストに対する制御ルールの導入をＰＣＥＦ３２に示す。

一方、ＵＥがプライマリＰＤＰコンテキストといくつかのセカンダリＰＤＰコンテキストとの動作をサポートするより能力のある端末である場合に、制御サーバ３１は、ＵＥ主導のモデルのみがサポートされる場合に、セカンダリＰＤＰコンテキストの動作を待つか、すべての可能なセカンダリＰＤＰコンテキストがすでに起動されている場合に、現在起動されているＰＤＰコンテキストのために制御ルールを導入する指標とともに当該制御ルールを送出するか、すべての可能なセカンダリＰＤＰコンテキストがまだ起動されているわけではない場合に、新たなセカンダリＰＤＰコンテキストの起動を要求する指標とともに制御ルールを送出するか、のうちのいずれかを行ってもよい。

この例示的な適用性は、以上で説明されたような他のシナリオにも同様に適用できるものの、上述された同じシナリオの例示的な欠点を解決し、従って上述の本発明の目的を達成する。

本発明は例示的で非限定的な方法においていくつかの実施形態の観点で上記に説明される。明らかに、変形および本実施形態の組合せは上記の示唆に照らして可能であり、特許請求の範囲に含まれるいかなる実施形態の修正も含まれることが意図される。

Claims (32)

1. ポリシー及び課金ルール機能として動作可能であり、シグナリング層を通じてサービスについて交渉されたサービス要求条件をベアラ層に保証する制御サーバ（３１）であって、
   前記ベアラ層はサービス関連の複数のＩＰフローを運ぶことができるメディア・トランスポート層であり、前記シグナリング層は前記ベアラ層を通じて輸送されるメディアがどのように扱われるべきかを交渉するために用いられ、
   前記制御サーバ（３１）は、
   ‐前記ベアラ層内のエンティティ（３２，２１，５１）とインタフェースで接続可能であり、所与のユーザに対するサービス関連の前記ＩＰフローを伝えるためのベアラの確立に関する情報を受信するように構成された第１の受信器（３１１，３１０）と、
   −前記シグナリング層内のエンティティ（３３，４１，６１）とインタフェースで接続可能であり、前記サービスについて交渉されたサービス要求条件を含む前記メディアに関するサービス情報を受信するように構成された第２の受信器（３１２，３１０）と、
   −前記所与のユーザにより現在使用されているユーザ装置（１１）についてのユーザ装置“ＵＥ”能力を取得するように構成された能力ハンドラ（３１５）と、
   −前記サービス要求条件を前記ベアラに保証するために適用される制御ルールを決定するように構成されたプロセッサ（３１３）であって、前記制御ルールは前記シグナリング層内の前記エンティティから受信された前記サービス情報と前記ユーザ装置（１１）についての前記ＵＥ能力とに基づく、プロセッサ（３１３）と、
   −前記ユーザ装置の前記ＵＥ能力に応じて、前記ベアラ層内でポリシー及び課金施行機能として動作可能なエンティティ（３２，２１，５１）に向けて導入される前記制御ルールを送出するか、前記制御ルールを導入するための後続するベアラの確立を待つか、のいずれかを行うように構成されたインストーラ（３１４）と
   を備えることを特徴とする制御サーバ（３１）。
2. 前記インストーラ（３１４）は、ポリシー及び課金施行機能として動作可能な前記エンティティ（３２，２１，５１）に向けて、前記確立されたベアラに対して前記ＵＥ能力によりサポートされるサービスを示す事前設定されたルールを送出するようにさらに構成されたことを特徴とする請求項１に記載の制御サーバ（３１）。
3. 前記ベアラ層は汎用パケット無線システム“ＧＰＲＳ”に従って動作するＩＰ接続アクセスネットワーク“ＩＰ−ＣＡＮ”により提供され、前記ベアラはパケット・データ・プロトコル“ＰＤＰ”コンテキストを起動することにより確立され、前記ベアラの確立に関する前記情報を送出する前記ベアラ層内の前記エンティティ（２１）はゲートウェイＧＰＲＳサポート・ノード“ＧＧＳＮ”であることを特徴とする請求項１に記載の制御サーバ（３１）。
4. 前記ベアラ層は無線ローカルエリアネットワーク“ＷＬＡＮ”に従って動作するＩＰ接続アクセスネットワーク“ＩＰ−ＣＡＮ”により提供され、前記ベアラの確立に関する前記情報を送出する前記ベアラ層内の前記エンティティ（５１）はパケットデータ・ゲートウェイ“ＰＤＧ”であることを特徴とする請求項１に記載の制御サーバ（３１）。
5. 前記ベアラ層内のポリシー及び課金施行機能として動作可能な前記エンティティ（３２，２１）は、ゲートウェイＧＰＲＳサポート・ノード“ＧＧＳＮ”であることを特徴とする請求項１に記載の制御サーバ（３１）。
6. 前記ベアラ層内のポリシー及び課金施行機能として動作可能な前記エンティティ（３２，５１）は、パケットデータ・ゲートウェイ“ＰＤＧ”であることを特徴とする請求項１に記載の制御サーバ（３１）。
7. 前記能力ハンドラ（３１５）は、外部のＵＥ能力レポジトリ（３１６）から前記ユーザ装置（１１）の前記ＵＥ能力を取得するためのクエリ・プロトコル・ハンドラ（３１５１）を含むことを特徴とする請求項１に記載の制御サーバ（３１）。
8. 前記ユーザ装置（１１）の前記ＵＥ能力を記憶し、前記能力ハンドラ（３１５）と内部で通信するローカルのＵＥ能力レポジトリ（３１６）をさらに含むことを特徴とする請求項１に記載の制御サーバ（３１）。
9. 前記ＵＥ能力は、適用されるサービス品質“ＱｏＳ”モデルがネットワーク主導とＵＥ主導とのいずれであるかを判定するために、前記プロセッサ（３１３）によって使用されることを特徴とする請求項１に記載の制御サーバ（３１）。
10. 後続して確立されるベアラの最大数にすでに到達している場合に、前記インストーラ（３１４）は、導入される前記制御ルールを、現在確立されているベアラに対して該制御ルールを導入することを示す指標とともに送出することを特徴とする請求項１に記載の制御サーバ（３１）。
11. 後続して確立されるベアラの最大数にまだ到達していない場合に、前記インストーラ（３１４）は、導入される前記制御ルールを、新たな後続するベアラの確立すること及び確立された時点で該新たな後続するベアラに対して該制御ルールを導入することを要求することを示す指標とともに送出することを特徴とする請求項１に記載の制御サーバ（３１）。
12. 前記能力ハンドラ（３１５）から取得可能な前記ユーザ装置（１１）の前記ＵＥ能力は、
    −ＱｏＳ管理、
    −ユーザ装置ごとのサポートされるサービス、
    −後続して確立されるベアラの最大数、及び
    −サポートされるＱｏＳモデル
    を含むＵＥ能力群から選択された少なくとも一つのＵＥ能力を含むことを特徴とする請求項１に記載の制御サーバ（３１）。
13. 前記サービスについて交渉されたサービス要求条件を含む前記メディアに関する前記サービス情報を送出する前記シグナリング層内の前記エンティティ（３３）は、アプリケーション機能“ＡＦ”装置であることを特徴とする請求項１に記載の制御サーバ（３１）。
14. 前記サービスについて交渉されたサービス要求条件を含む前記メディアに関する前記サービス情報を送出する前記シグナリング層内の前記エンティティ（４１，３３）は、ＩＰマルチメディア・サブシステム“ＩＭＳ”のプロキシ呼セッション制御機能“Ｐ−ＣＳＣＦ”であり、アプリケーション機能“ＡＦ”として動作可能であることを特徴とする請求項１に記載の制御サーバ（３１）。
15. 前記サービスについて交渉されたサービス要求条件を含む前記メディアに関する前記サービス情報を送出する前記シグナリング層内の前記エンティティ（６１，３３）は、アプリケーション・サーバ“ＡＳ”であり、アプリケーション機能“ＡＦ”として動作可能であることを特徴とする請求項１に記載の制御サーバ（３１）。
16. シグナリング層を通じてサービスについて交渉されたサービス要求条件をベアラ層に保証する方法であって、
    前記ベアラ層はサービス関連の複数のＩＰフローを運ぶことができるメディア・トランスポート層であり、前記シグナリング層は前記ベアラ層を通じて輸送されるメディアがどのように扱われるべきかを交渉するために用いられ、
    ‐ポリシー及び課金ルール機能として動作可能な制御サーバ（３１）が、前記ベアラ層内のエンティティ（３２，２１，５１）から、所与のユーザに対するサービス関連の前記ＩＰフローを伝えるためのベアラの確立に関する情報を受信する工程（Ｓ−１０２，Ｓ−１１２，Ｓ−１２１）と、
    −前記制御サーバ（３１）が、前記シグナリング層内のエンティティ（３３，４１，６１）から、前記サービスについて交渉されたサービス要求条件を含む前記メディアに関するサービス情報を受信する工程（Ｓ−１２５）と、
    −前記所与のユーザにより現在使用されているユーザ装置（１１）についてのユーザ装置“ＵＥ”能力をＵＥ能力記憶装置（３１６）から取得する工程（Ｓ−１２２，Ｓ−１２３）と、
    −前記制御サーバ（３１）が、前記サービス要求条件を前記ベアラに保証するために適用される制御ルールを決定する工程（Ｓ−１２６）であって、前記制御ルールは前記シグナリング層内の前記エンティティから受信された前記サービス情報と前記ユーザ装置（１１）についての前記ＵＥ能力とに基づく、工程（Ｓ−１２６）と、
    −前記ユーザ装置の前記ＵＥ能力に応じて、前記ベアラ層内でポリシー及び課金施行機能として動作可能なエンティティ（３２，２１，５１）に向けて導入される前記制御ルールを送出する工程（Ｓ−１２７）か、前記制御ルールを導入するための後続するベアラの確立を待つ工程（Ｓ−１３０）か、のいずれかを行う工程と
    を含むことを特徴とする方法。
17. ポリシー及び課金施行機能として動作可能な前記エンティティ（３２，２１，５１）に向けて、前記確立されたベアラに対して前記ＵＥ能力によりサポートされるサービスを示す事前設定されたルールを送出する工程（Ｓ−１２４）をさらに含むことを特徴とする請求項１６に記載の方法。
18. 前記ベアラ層は汎用パケット無線システム“ＧＰＲＳ”に従って動作するＩＰ接続アクセスネットワーク“ＩＰ−ＣＡＮ”により提供され、前記ベアラはパケット・データ・プロトコル“ＰＤＰ”コンテキストを起動することにより確立され、前記ベアラの確立に関する前記情報を送出する前記ベアラ層内の前記エンティティ（２１）はゲートウェイＧＰＲＳサポート・ノード“ＧＧＳＮ”であることを特徴とする請求項１６に記載の方法。
19. 前記ベアラ層は無線ローカルエリアネットワーク“ＷＬＡＮ”に従って動作するＩＰ接続アクセスネットワーク“ＩＰ−ＣＡＮ”により提供され、前記ベアラの確立に関する前記情報を送出する前記ベアラ層内の前記エンティティ（５１）はパケットデータ・ゲートウェイ“ＰＤＧ”であることを特徴とする請求項１６に記載の方法。
20. 前記ベアラ層内のポリシー及び課金施行機能として動作可能な前記エンティティ（３２，２１）は、ゲートウェイＧＰＲＳサポート・ノード“ＧＧＳＮ”であることを特徴とする請求項１６に記載の方法。
21. 前記ベアラ層内のポリシー及び課金施行機能として動作可能な前記エンティティ（３２，５１）は、パケットデータ・ゲートウェイ“ＰＤＧ”であることを特徴とする請求項１６に記載の方法。
22. ユーザ装置（１１）のＵＥ能力を取得する前記工程（Ｓ−１２２，Ｓ−１２３）は、該ＵＥ能力のために外部のＵＥ能力レポジトリ（３１６）に問い合わせる工程を含むことを特徴とする請求項１６に記載の方法。
23. ユーザ装置（１１）のＵＥ能力を取得する前記工程（Ｓ−１２２，Ｓ−１２３）は、該ＵＥ能力のためにローカルのＵＥ能力レポジトリ（３１６）を調べる工程を含むことを特徴とする請求項１６に記載の方法。
24. 前記取得したＵＥ能力に基づいて、適用されるサービス品質“ＱｏＳ”モデルがネットワーク主導とＵＥ主導とのいずれであるかを判定する工程をさらに含むことを特徴とする請求項１６に記載の方法。
25. 導入される前記制御ルールを送出する前記二者択一の一方の工程（Ｓ−１２７）は、後続して確立されるベアラの最大数にすでに到達している場合に、現在確立されているベアラに対して該制御ルールが導入されることを示す工程を含むことを特徴とする請求項１６に記載の方法。
26. 導入される前記制御ルールを送出する前記二者択一の一方の工程（Ｓ−１２７）は、後続して確立されるベアラの最大数にまだ到達していない場合に、新たな後続するベアラの確立すること及び確立された時点で該新たな後続するベアラに対して該制御ルールを導入することを要求する工程を含むことを特徴とする請求項１６に記載の方法。
27. 前記ＵＥ能力レポジトリ（３１６）から取得可能な前記ユーザ装置（１１）の前記ＵＥ能力は、
    −ＱｏＳ管理、
    −ユーザ装置ごとのサポートされるサービス、
    −後続して確立されるベアラの最大数、及び
    −サポートされるＱｏＳモデル
    を含むＵＥ能力群から選択された少なくとも一つのＵＥ能力を含むことを特徴とする請求項１６に記載の方法。
28. 前記サービスについて交渉されたサービス要求条件を含む前記メディアに関する前記サービス情報を送出する前記シグナリング層内の前記エンティティ（３３）は、アプリケーション機能“ＡＦ”装置であることを特徴とする請求項１６に記載の方法。
29. 前記サービスについて交渉されたサービス要求条件を含む前記メディアに関する前記サービス情報を送出する前記シグナリング層内の前記エンティティ（４１，３３）は、ＩＰマルチメディア・サブシステム“ＩＭＳ”のプロキシ呼セッション制御機能“Ｐ−ＣＳＣＦ”であり、アプリケーション機能“ＡＦ”として動作可能であることを特徴とする請求項１６に記載の方法。
30. 前記サービスについて交渉されたサービス要求条件を含む前記メディアに関する前記サービス情報を送出する前記シグナリング層内の前記エンティティ（６１，３３）は、アプリケーション・サーバ“ＡＳ”であり、アプリケーション機能“ＡＦ”として動作可能であることを特徴とする請求項１６に記載の方法。
31. 処理ユニットだけでなく入力ユニットと出力ユニットとを有するコンピュータの内部メモリに読み込み可能なコンピュータプログラムであって、前記コンピュータで実行される場合に請求項１６乃至３０のいずれか１項に記載の方法を実行するように構成された実行形式のソフトウェアを備えるコンピュータプログラム。
32. 前記実行形式のソフトウェアはコンピュータで読み出し可能な媒体に記録されることを特徴とする請求項３１に記載のコンピュータプログラム。

Images