JP4526038B2 - 通信システムにおけるセッション - Google Patents

Description

本発明は、通信システムに関し、特に、通信システムによって提供されるセッションに関連するポリシー制御に関する。

通信システムは、通信システムに関連するユーザ機器および／または他のノードなどの２つ以上のエンティティ間で通信セッションを可能にする機構とみなすことができる。通信は、例えば、音声、データ、マルチメディアなどの通信を含むことができる。ユーザ機器は、例えば、双方向の電話コールまたは多元電話会議を備えることができる。ユーザ機器は、例えば、サービス・プロバイダ・サーバなどのアプリケーション・サーバ（ＡＳ）への接続を備えるため、アプリケーション・サーバによって提供されるサービスを利用することもできる。

通信システムは、通常、通信システムに関連する種々のエンティティが実行可能な内容、およびそれをどのように達成するべきであるかを定めた所与の標準または規格に従って動作する。例えば、この標準または規格は、ユーザ、あるいはより精密にはユーザ機器に、回線交換サービスおよび／またはパケット交換サービスが提供されるかどうかを定義することができる。接続に使用されるものとする通信プロトコルおよび／またはパラメータも定義することができる。すなわち、通信が基礎とすることのできる特定セットの「規則」を、システムによる通信を可能にするために定義する必要がある。

ユーザ機器用の無線通信を実証する通信システムが知られている。この無線システムの一例が、公衆陸上移動体通信網（ＰＬＭＮ／Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）である。ＰＬＭＮは、通常、セルラ技術に基づくものである。セルラ・システムでは、トランシーバ基地局（ＢＴＳ）または同様のアクセス・エンティティが、移動局（ＭＳ）とも呼ばれる無線ユーザ機器（ＵＥ）に、これらエンティティの間の無線インタフェースを介してサービスを提供する。ユーザ機器と通信ネットワークの要素との間の無線インタフェース上での通信は、適切な通信プロトコルに基づくものとすることができる。通信に必要な基地局装置および他の装置の動作は、１つまたはいくつかの制御エンティティによって制御することができる。種々の制御エンティティは、相互接続可能である。

移動体ネットワークを、他のネットワーク、例えば、公衆交換電話網（ＰＳＴＮ）、および／またはＩＰ（インターネット・プロトコル）などの他の通信ネットワーク、および／または他のパケット交換データ・ネットワークに接続するために、１つまたは複数のゲートウェイ・ノードを提供することもできる。例えば、要求されたサービスが他のネットワークに配置されたサービス・プロバイダによって提供される場合、サービス要求は、移動体ネットワークを介して他のネットワークへ、さらにその後、サービス・プロバイダへとルーティングされる。

通信システムの加入者などのユーザに提供可能なサービスの一例が、いわゆるマルチメディア・サービスである。マルチメディア・サービスを提供可能な通信システムの一例が、インターネット・プロトコル（ＩＰ）マルチメディア・ネットワークである。ＩＰマルチメディア（ＩＭ）機能は、ＩＰマルチメディア・コア・ネットワーク（ＣＮ）サブシステム、または簡潔にＩＰマルチメディア・サブシステム（ＩＭＳ）によって提供することができる。ＩＭＳは、マルチメディア・サービスを提供するための種々のネットワーク・エンティティを含む。

第３世代パートナーシップ・プロジェクト（３ＧＰＰ／Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）は、ＩＭＳサービスを提供するためのバックボーン通信システムとして、汎用パケット無線サービス（ＧＰＲＳ／Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）の使用を定義している。従ってこの規格では、マルチメディア・サービスが実行できる可能なバックボーン通信システムの一例として、ＧＰＲＳが使用される。第３世代パートナーシップ・プロジェクト（３ＧＰＰ）は、ユーザ機器のユーザにマルチメディア・サービスへのアクセスを提供する第３世代（３Ｇ）コア・ネットワーク用の基準アーキテクチャも定義している。このコア・ネットワークは、３つの基本ドメインに分割される。これが回線交換（ＣＳ）ドメイン、パケット交換（ＰＳ）ドメイン、およびインターネット・プロトコル・マルチメディア（ＩＭ）ドメインである。

後者のＩＭドメインは、マルチメディア・サービスが適切に管理されることを確実にするためのものである。３Ｇ ＩＭドメインは、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）によって開発されたセッション開始プロトコル（ＳＩＰ）をサポートする。セッション開始プロトコル（ＳＩＰ）は、１人または複数の参加者（エンドポイント）を伴うセッションを作成、修正、および終了するためのアプリケーション層制御プロトコルである。

ＳＩＰは、例えば、会議などのマルチメディア・セッションを確立、修正、および終了することができる。しかしながら、メディアのタイプ、コーデック、またはサンプリング・レートなどのセッションの詳細を記述することはできない。その代わりに、ＳＩＰメッセージの本文は、セッション記述プロトコル（ＳＤＰ）形式で符号化されたセッションの記述を含む。提案／応答モデルと呼ばれるメカニズムが定義され、これによって２つのエンティティは、ＳＤＰを使用して両者の間のマルチメディア・セッションの共通認識に達することができる。このモデルでは、一方の参加者が他方の当事者に対して自分の観点から所望のセッションの記述を提案し、他方の参加者は自分の観点から所望のセッションに応答する。他方の参加者は、例えば、提案を減らすことができる。３ＧＰＰは、ＩＰマルチメディア・サブシステムのオペレータが、自分たちのネットワーク内でセッションが許可されたメディア・パラメータを定義できるようにするものであり、これらは、汎用ローカル・ポリシーまたはメディア・ポリシーであるか、あるいはサブスクリプション・ベースの制約である。これらのネットワークでは、許可されたメディアのみを確立することができる。ポリシーに違反するＳＤＰは、ネットワークによって拒否される。

３ＧＰＰに関するＳＤＰを含むＳＩＰ要求の処理について説明してきたが、ペイロードを伴う応答などのＳＩＰ応答の処理についてはまだ論じていない。ＳＩＰは、ＳＩＰ応答でＳＤＰを送信することができる。しかしながら、ＳＤＰが、オペレータによって設定されたがユーザには知らされていないポリシーなどの、メディア・ポリシーに違反する場合、こうした応答を拒否することはできない。

本発明の実施形態は、前述の１つまたはいくつかの問題に対処することを目標とする。

本発明の一実施形態によれば、通信システムにおけるメッセージへの応答を処理するための方法が提供されている。この方法は、第１の当事者から第２の当事者へメッセージを送信するステップと、メッセージに対する応答を送信するステップであって、この応答が当事者間の通信に関するポリシーに違反している少なくとも１つのパラメータを含むステップと、ポリシーに違反している少なくとも１つのパラメータを応答が含むことをネットワーク・コントローラにおいて検出するステップと、少なくとも１つのパラメータをポリシーに合致するように修正するステップとを含む。

他の実施形態によれば、通信セッションの当事者間の応答および要求を処理し、第１の当事者から第２の当事者へメッセージを転送し、メッセージに対する応答が当事者間の通信に関するポリシーに違反している少なくとも１つのパラメータを含むかどうかをチェックし、少なくとも１つのパラメータをポリシーに合致するように修正するように構成される通信システム用のコントローラが提供される。

さらに他の実施形態によれば、接続された当事者間に通信セッションを提供するための通信システムが提供され、この通信システムは、通信セッションの当事者間の応答および要求を処理し、第１の当事者から第２の当事者へメッセージを転送し、メッセージに対する応答が当事者間の通信に関するポリシーに違反している少なくとも１つのパラメータを含むかどうかをチェックし、少なくとも１つのパラメータをポリシーに合致するように修正するように構成されるコントローラを備える。

より特有の実施形態では、少なくとも１つのパラメータはコントローラによって修正される。他の実施形態では、少なくとも１つのパラメータは第１の当事者によって修正される。応答は、第２の当事者から第１の当事者へ修正されずに渡される場合がある。応答に答える第１の当事者からの他のメッセージが、ポリシーに違反している少なくとも１つのパラメータを含む場合、チェックはコントローラによって実行される場合がある。

実施形態は、非許容パラメータを伴うセッションの処理における利点を提供することができる。処理は整合性を有するものとすることができる。システムは、矛盾するポリシーによって生じる種々の起こり得る状況をより良く予見することができる。
本発明をより良く理解するために、一例として添付の図面を参照する。

本発明のある実施形態について、第３世代（３Ｇ）移動体通信システムの例示としてのアーキテクチャを参照しながら、以下で一例として説明する。しかしながら、この実施形態は任意の適当な通信システムに適用可能であることを理解されたい。
本発明を実施することができるネットワーク・アーキテクチャの一例を示す図１を参照する。図１では、ＩＰマルチメディア・ネットワーク加入者にＩＰマルチメディア・サービスを提案するための、ＩＰマルチメディア・ネットワーク４５が提供される。

前述のように、ＩＰマルチメディア（ＩＭ）機能は、移動体通信システムによって提供することができる。通常、移動体通信システムは、通常はユーザ機器と通信システムの少なくとも１つの基地局との間の無線インタフェースを介して、複数の移動体ユーザ機器にサービスを提供するように配置構成される。移動体通信システムは、論理的には、無線アクセス・ネットワーク（ＲＡＮ）とコア・ネットワーク（ＣＮ）とに分けることができる。

システムでは、基地局３１および４０が、ユーザ機器と無線アクセス・ネットワークとの間の無線インタフェースを介して、移動体ユーザ、すなわち加入者の、移動体ユーザ機器３０、４１に信号を送信し、これらから信号を受信するように配置構成される。従って、移動体ユーザ機器は、無線インタフェースを介して無線アクセス・ネットワークに信号を送信すること、およびここから信号を受信することができる。

図示された配置構成では、ユーザ機器３０、４１は、それぞれ基地局３１、４０に関連するアクセス・ネットワークを介して、ＩＭＳネットワーク４５にアクセスすることができる。見やすくするために、図１には２つの基地局しか示されていないが、典型的な通信ネットワーク・システムには、通常いくつかの基地局が含まれることを理解されたい。

移動体ユーザ機器は、ネットワークに接続するためのインターネット・プロトコル（ＩＰ）通信に適合した任意の適切な移動体ユーザ機器を備えることができる。例えば、移動体ユーザは、パーソナル・コンピュータ（ＰＣ）、携帯情報端末（ＰＤＡ）、移動局（ＭＳ）などによって、セルラ・ネットワークにアクセスすることができる。以下の例は、移動局との関連において説明する。

当業者であれば、典型的な移動局の機能および動作は周知である。それ故、ユーザは、電話コールを発信および受信するネットワークとの間でデータを受信および送信する、ならびに、マルチメディア・サービスを使用してマルチメディア・コンテンツまたはそうでないものを体験するなどのタスクに、移動局が使用できることに留意されたい。移動局は、移動体通信ネットワークの基地局との間で信号を無線で受信および送信するためのアンテナを含むことができる。移動局には、移動体ユーザ機器のユーザにイメージおよび他のグラフィカル情報を表示するためのディスプレイも提供することができる。静止イメージまたはビデオ・イメージを取り込むために、カメラ手段を提供することができる。通常は、スピーカ手段も提供される。移動局の動作は、コントロール・ボタン、音声コマンドなどの適切なユーザ・インタフェースによって制御することができる。さらに移動局には、プロセッサ・エンティティおよびメモリ手段も提供される。
見やすくするために、図１には２つの移動局しか示されていないが、いくつかの移動局が移動体通信システムの基地局と同時に通信可能であることを理解されたい。

コア・ネットワーク（ＣＮ）エンティティは、通常、いくつかの無線アクセス・ネットワークを介した通信を可能にするため、さらに、単一の通信システムを、他のセルラ・システムおよび／または固定回線通信システムなどの１つまたは複数の通信システムとインタフェースさせるための種々の交換および他の制御エンティティならびにゲートウェイを含む。３ＧＰＰシステムでは、無線アクセス・ネットワーク・コントローラは、通常、適切なコア・ネットワーク・エンティティ、またはサービス提供汎用パケット無線サービス・サポート・ノード（ＳＧＳＮ）（図１のコントローラ３３および３９参照）などであるがこれに限定されることのないエンティティに接続される。無線アクセス・ネットワークは、例えば、Ｉｕインタフェースなどの適切なインタフェースを介してサービス提供ＧＰＲＳサポート・ノードと通信している。図には示されていないが、ＳＧＳＮは、通常、それぞれのユーザ機器のサブスクリプションに関連する情報を格納するために構成された指定加入者データベースにアクセスすることができる。次にサービス提供ＧＰＲＳサポート・ノードは、通常、ＧＰＲＳバックボーン・ネットワーク３２を介してゲートウェイＧＰＲＳサポート・ノードと通信する。このインタフェースは、一般に、交換パケット・データ・インタフェースである。

３ＧＰＰネットワークでは、ネットワークを介してトラフィック・フローを搬送するためにパケット・データ・セッションが確立される。こうしたパケット・データ・セッションは、多くの場合、パケット・データ・プロトコル（ＰＤＰ）コンテキストと呼ばれる。ＰＤＰコンテキストには、ユーザ機器と無線ネットワーク・コントローラとの間に提供される無線ベアラ、ユーザ機器、無線ネットワーク・コントローラ、およびＳＧＳＮの間に提供される無線アクセス・ベアラ、ならびに、サービス提供ＧＰＲＳサービス・ノードとゲートウェイＧＰＲＳサービス・ノードとの間に提供される交換パケット・データ・チャネルが含まれる場合がある。各ＰＤＰコンテキストは、通常、特定のユーザ機器とゲートウェイＧＰＲＳサポート・ノードとの間に通信パスウェイを提供し、通常は、いったん確立されると、複数のフローを搬送することができる。通常、各フローは、例えば、特定のサービスおよび／または特定のサービスのメディア構成要素を表す。従って、ＰＤＰコンテキストは、多くの場合、ネットワークを横切る１つまたは複数のフローの論理通信パスウェイを表す。ユーザ機器とサービス提供ＧＰＲＳサポート・ノードとの間にＰＤＰコンテキストを実施するために、一般にユーザ機器へのデータ転送を可能にする無線アクセス・ベアラ（ＲＡＢ）を確立する必要がある。これらの論理および物理チャネルの実施は、当業者には周知であるため、本明細書ではこれ以上詳細には説明しない。

これまでの通信システムは、サーバなどのコントローラ・エンティティによって処理されるデータ・ネットワークの種々の機能によってユーザ機器にサービスが提供されるという方向で開発されてきた。例えば、現在の第３世代（３Ｇ）無線マルチメディア・ネットワーク・アーキテクチャでは、種々の制御機能を提供するいくつかの異なるサーバが、サービス提供の制御に使用されるものと想定される。これらには、コール状態制御機能（ＣＳＣＦ）などの機能が含まれる。コール状態制御機能は、プロキシ・コール状態制御機能（Ｐ−ＣＳＣＦ）、問い合わせコール状態制御機能（Ｉ−ＣＳＣＦ）、およびサービス提供コール状態制御機能（Ｓ−ＣＳＣＦ）などの種々のカテゴリに分割することができる。同様の機能が、様々なシステムにおいて様々な名前で呼ばれる場合があることを理解されたい。例えば、ある適用例では、ＣＳＣＦはコール・セッション制御機能と呼ばれることがある。

ＩＭＳシステムによって提供されるサービスを使用したいユーザは、第１に、サービス提供コール・セッション制御機能（Ｓ−ＣＳＣＦ）３６などのサービス提供コントローラに登録する必要がある場合がある。図１に示されるように、Ｓ−ＣＳＣＦ３６とユーザ機器との間の通信は、少なくとも１つのプロキシ・コール・セッション制御機能（Ｐ−ＣＳＣＦ）３５を介してルーティングされる場合がある。それ故、プロキシＣＳＣＦ３５は、ＧＧＳＮ３４からサービス提供コール・セッション制御機能３６へメッセージをプロキシするためのものである。次に、サービス提供コントローラ、すなわち図１のＣＳＣＦ３６は、ユーザ機器３０が登録されている必要のある制御エンティティを提供する。登録は、ユーザ機器が通信システムにサービスを要求できるようにするために必要である。

ポリシー制御エンティティ３７も提供される場合がある。ポリシー制御エンティティ３７は、必要なポリシー情報をそのデータベース３８内に格納するように構成することができる。ネットワーク・エンティティは、特定ユーザのメディア・ポリシーに関する情報を取得するためなど、種々の目的でポリシー制御エンティティに照会することができる。ポリシー制御エンティティは、Ｐ−ＣＳＣＦおよびＧＧＳＮに接続されたポリシー決定機能（ＰＤＦ）によって提供することができる。

図１には、アプリケーション・サーバ５０も示されている。ユーザ機器は、ＧＰＲＳネットワークを介して、例示としてのインターネット・プロトコル（ＩＰ）ネットワークなどであるが、これらに限定されることのない１つまたは複数のデータ・ネットワークに接続されるアプリケーション・サーバに接続することができる。各データ・ネットワークに多数のアプリケーション・サーバが接続できることを理解されたい。

必ずしも必要ではないが、さらに図１のシステムは、必要な通信リソースがバックボーン・ネットワークによって提供されており、サービス提供コントローラ３６に登録されているユーザが、通信システムを介して所望のサービスに関する要求をサービス提供コントローラに送信することにより、アプリケーション・サーバ５０によって提案されたサービスの使用を開始しなければならないように、配置構成することができる。

実施形態は、事前に定義されたアクションがメディア・ポリシー違反の検出後に実行可能な場合に有利な可能性があるという認識に基づくものである。このアクションは、好ましくは、Ｐ−ＣＳＣＦ３５などのプロキシ・ネットワーク要素で実行される。
以下で説明するより詳細な例示としての実施形態は、ＰＤＦ３７に格納されたオペレータのメディア・ポリシーに従わない提案などのセッション・パラメータを含むＳＩＰ応答などのメッセージを取り扱うものであり、従って、少なくとも１つの違反パラメータをポリシーに合致させるためにアクションを実行する必要がある場合がある。

図２に示されるように、適切なＣＳＣＦはパラメータを転送する前に修正することができる。第１のユーザ機器３０からの「ＩＮＶＩＴＥ」に応答して第２のユーザ機器４１から送信される２００ ＯＫは、メディア・ポリシーに違反するＳＤＰ提案を含む。ＣＳＣＦは、ＳＤＰ提案としてさらに第１のユーザ機器３０に送信される前に、ＳＤＰ提案がメディア・ポリシーに合致するように提案を修正する。ＡＣＫでの応答は、メディア・ポリシーによって受け入れ可能となる。
削減されたメディアに当事者が満足しない場合（最悪の場合は、交差部分においてすべてのメディアが無効となる可能性がある）、新しいｒｅＩＮＶＩＴＥを開始することができる。これが可能なのは、マルチメディア・セッションがネットワークによって解除されないためである。

図３に示された代替実施形態によれば、適切なＣＳＣＦはこの問題を無視して、ＳＤＰ提案を含む未修正のＳＩＰメッセージを転送することができる。第１のユーザ機器からのＩＮＶＩＴＥに対する第２のユーザ機器からの暫定応答には、メディア・ポリシーに違反するＳＤＰ提案が含まれる可能性がある。すなわち、ＳＤＰ提案は受け入れられたままの状態で転送することができる。次に、ＣＳＣＦは、他方の当事者からの修正済みおよび許容可能なセッション・パラメータ応答を待つ。ＳＤＰ応答は、次に、メディア・ポリシーに照らしてチェックされるＰＲＡＣＫ要求で受信することができる。これが受け入れ可能でない場合、ＰＲＡＣＫ要求は拒否される。それ故、ＣＳＣＦは、最終パラメータが依然としてメディア・ポリシーに違反している場合、提案／応答を拒否することができる。
拒否は、許可されたメディア・ポリシーを含むことができる。これは、図２に従って提供することができる。

次に、一実施形態に従ったＰ−ＣＳＣＦ３５の動作に関するより詳細な例について説明する。Ｐ−ＣＳＣＦ３５がＳＤＰ提案を含むＳＩＰ要求を受信した場合、Ｐ−ＣＳＣＦは受信したＳＤＰ内のメディア・パラメータを検査することができる。Ｐ−ＣＳＣＦ３５が、ネットワーク上で、例えばローカル・ポリシーが原因で許可されない何らかのメディア・パラメータを発見すると、Ｐ−ＣＳＣＦはＳＤＰペイロードを含む「Ｎｏｔ Ａｃｃｅｐｔａｂｌｅ Ｈｅｒｅ」応答を戻すことができる。ＳＤＰペイロードは、すべてのメディア・タイプ、コーデック、および、ローカル・ポリシーに従って許可されるかまたはこれら許可パラメータのサブセットであるＰ−ＣＳＣＦのオペレータによる構成に基づく他のＳＤＰパラメータの、いずれかを含むことができる。このサブセットは、受信したＳＩＰ要求のコンテンツに依存することができる。

Ｐ−ＣＳＣＦが、図３のＳＩＰ １８３メッセージなどのＳＤＰ提案を含む信頼できる暫定ＳＩＰ応答を受信した場合、Ｐ−ＣＳＣＦは、受信したＳＤＰ提案内のメディア・パラメータを検査しないように構成することができる。それ故、たとえ提案がネットワーク上でローカル・ポリシーによって許可されないメディア・パラメータを含む場合であっても、ＳＤＰがトランスペアレントにＰ−ＣＳＣＦ３５を渡すことを許可することができる。Ｐ−ＣＳＣＦはＳＩＰ応答を拒否できない場合があるため、これは有利である。その代わりに、Ｐ−ＣＳＣＦは、この提案に関するＳＤＰ応答を含む後続のＰＲＡＣＫ要求に基づいてアクションを実行することが可能であり、その結果、これがチェックされる。必要であれば、すなわち、ユーザ機器（ＵＥ）によって削減されたＳＤＰ応答が依然としてローカル・ポリシーに違反している場合、Ｐ−ＣＳＣＦは、許可されたＳＤＰペイロードであるローカル・ポリシーを含む「Ｎｏｔ Ａｃｃｅｐｔａｂｌｅ Ｈｅｒｅ」応答を戻すことができる。

Ｐ−ＣＳＣＦが、ＳＤＰ提案を含む確認ダイアログでＩＮＶＩＴＥ要求に対する、すなわちｒｅＩＮＶＩＴＥに対する２ｘｘ最終ＳＩＰ応答を受信した場合、Ｐ−ＣＳＣＦは受信したＳＤＰ提案内のメディア・パラメータを検査することができる。Ｐ−ＣＳＣＦがネットワーク上で、例えばローカル・ポリシーによって許可されないメディア・パラメータを発見すると、図２に示されるように、Ｐ−ＣＳＣＦはＳＤＰ提案をローカル・ポリシーと交差させることができる。これにより、「ＡＣＫ」要求で送信されたＳＤＰ応答がローカル・ポリシーによって許可されたこと、ならびに最初にＰ−ＣＳＣＦで受信されたＳＤＰ提案に対する有効な応答であることを確保することができる。

次に、ある実施形態に従った動作がＳ−ＣＳＣＦ３６で実行される、より詳細な例について説明する。Ｓ−ＣＳＣＦ３６がＳＤＰを含むＳＩＰ要求を受信した場合、Ｓ−ＣＳＣＦは受信したＳＤＰ内のメディア・パラメータを検査することができる。Ｓ−ＣＳＣＦが、ローカル・ポリシーまたはサブスクリプションのいずれかに基づいて許可されない何らかのメディア・パラメータを発見した場合、Ｓ−ＣＳＣＦはＳＤＰペイロードを含む「Ｎｏｔ Ａｃｃｅｐｔａｂｌｅ Ｈｅｒｅ」応答を戻すことができる。前述のように、ＳＤＰペイロードは、すべてのメディア・タイプ、コーデック、および、ローカル・ポリシーおよびユーザ・サブスクリプションに従って許可されるかまたはこれら許可パラメータのサブセットであるＳ−ＣＳＣＦのオペレータによる構成に基づく他のＳＤＰパラメータの、いずれかを含むことができる。このサブセットは、受信したＳＩＰ要求のコンテンツに依存することができる。

Ｓ−ＣＳＣＦがＳＤＰ提案を含む信頼できる暫定ＳＩＰ応答を受信した場合、Ｓ−ＣＳＣＦは、受信したＳＤＰ提案内のメディア・パラメータを検査しないように構成することができる。それ故、ＳＩＰ応答を拒否できない場合があるため、ローカルまたは他のポリシーによってネットワーク上で許可されないメディア・パラメータであっても許可することができる。その後Ｐ−ＣＳＣＦは、この提案に対するＳＤＰ応答を含む後続のＰＲＡＣＫ要求を検査することが可能であり、必要であれば、すなわちＵＥによって削減されたＳＤＰ応答が依然としてローカル・ポリシーに違反している場合、ＳＩＰ要求に関して上記で説明したように続行される。

Ｓ−ＣＳＣＦがＳＤＰ提案を含む確認ダイアログで、ＩＮＶＩＴＥ要求に対する２ｘｘ最終ＳＩＰ応答を受信した場合、Ｓ−ＣＳＣＦは受信したＳＤＰ提案内のメディア・パラメータを検査することができる。Ｓ−ＣＳＣＦがネットワーク上でローカル・ポリシーによって許可されないメディア・パラメータを発見すると、Ｓ−ＣＳＣＦはＳＤＰ提案をローカル・ポリシーと交差させることができる。これにより、ＡＣＫメッセージで送信されたＳＤＰ応答がローカル・ポリシーによって許可されたこと、ならびに、最初にＳ−ＣＳＣＦで受信されたＳＤＰ提案に対する有効な応答であることを保証することができる。ＳＩＰプロトコル内のＡＣＫは拒否できないことに留意されたい。

可能性に従って、通信システムは、初期のＩＮＶＩＴＥに対するＳＩＰ ２００ ＯＫがＳＤＰ提案を含むことができないように構成される。この場合、初期のＩＮＶＩＴＥ要求が提案を含むことができるか、またはＳＤＰ提案を伴う暫定の信頼できる応答が存在可能かのいずれかである。

次に、ネットワークが処理可能であることが必要な場合のある、不適切なＳＤＰモデルについて簡単に説明する。あるシナリオによれば、ＳＤＰ提案／応答モデルに従ってＳＤＰ提案には応答されない。この場合、ＳＤＰ提案は撤回される可能性がある。他のシナリオでは、ＳＤＰ提案／応答モデルはＳＤＰペイロードを要求するが、ＳＩＰメッセージ内にはこれがない。その後、中間サーバはトランスペアレントに動作することができる。ＳＩＰメッセージは無効なＳＤＰ提案、例えば、構文上の意味論的エラーも含むことが可能であるか、またはＳＤＰ提案／応答モデルが破壊される。これは、無効な提案とみなすことができる。ＳＩＰメッセージは、無効なＳＤＰ応答も含むことができる。対応する提案は撤回され、Ｐ−ＣＳＣＦはポリシー決定機能にポリシー・セットアップ情報を送信しない。

以上、本発明の実施形態について移動局などのユーザ機器に関して説明してきたが、本発明の実施形態は任意の他のタイプの機器に適用可能であることを理解されたい。
本発明の例について、ＩＭＳシステムおよびＧＰＲＳネットワークとの関連において説明してきた。本発明は、符号分割多元接続、周波数分割多元接続、または時分割多元接続、ならびにそれらの任意の混成を含む、任意の他のアクセス技法にも適用可能である。さらに、いわゆるすべてのＩＰエンティティを備えたすべてのＩＰネットワークとの関連において、所与の例について説明する。本発明は、任意の他の適切な通信システム、無線または固定のいずれかの回線システム、ならびに標準およびプロトコルにも適用可能である。無線データ通信サービスが実行可能な他の可能な通信システムの例には、Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ（ＵＭＴＳ）などの第３世代汎用移動体通信システム、ｉ−ｐｈｏｎｅまたはＣＤＭＡ２０００およびＴｅｒｒｅｓｔｒｉａｌ Ｔｒｕｎｋｅｄ Ｒａｄｉｏ（ＴＥＴＲＡ）システム、Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）移動体データ・ネットワークが含まれるが、これらに限定されるものではない。固定回線システムの例には、家庭やオフィスなど様々な場所に居るユーザに、インターネット・アクセスを提供する多様なブロードバンド技法が含まれる。通信ネットワークに使用される標準およびプロトコルにかかわらず、本発明はセッションに関連するポリシー制御が必要なすべての通信ネットワークで適用可能である。

本発明の実施形態について、プロキシおよびサービス提供コール状態制御機能との関連において説明した。本発明の実施形態は、適用可能な他のネットワーク要素にも適用可能である。
本明細書では、本発明の例示としての実施形態について上記で説明しているが、添付の特許請求の範囲に定義された本発明の範囲を逸脱することなく、開示された解決策に対して実行可能ないくつかの変形および修正があることにも留意されたい。

本発明の一実施形態を示す図である。 本発明の一態様の動作を示す信号流れ図である。 本発明の他の態様の動作を示す信号流れ図である。

Claims (5)

1. 第１のユーザ装置から第２のユーザ装置へセッション開始プロトコル・メッセージを送信するステップと、
   前記第２のユーザ装置から前記第１のユーザ装置へセッション記述プロトコルオファを含むセッション開始プロトコル応答を送信するステップと、
   引き続く要求を受信し、前記要求がローカルポリシーに違反する前記オファに対するセッション記述プロトコル回答を含んでいるかをチェックするステップと、
   前記セッション記述プロトコル回答が前記ローカルポリシーに違反していた場合には、前記回答は受領することができない旨の応答を返信するステップとを含み、
   前記応答には、前記ローカルポリシーで許可されるセッション記述プロトコルペイロードを含むことを特徴とする方法。
2. 前記セッション記述プロトコル回答は前記第１のユーザ装置において解析されることを特徴とする請求項１に記載の方法。
3. セッション開始プロトコル要求を第１のユーザ装置から第２のユーザ装置へ送信する手段と、
   セッション記述プロトコルオファを含むセッション開始プロトコル応答を前記第２のユーザ装置から前記第１のユーザ装置へ送信する手段と、
   引き続く要求を受信し、前記要求がローカルポリシーに違反する前記オファに対するセッション記述プロトコル回答を含んでいるかをチェックする手段と、
   前記セッション記述プロトコル回答が前記ローカルポリシーに違反していた場合には、前記回答は受領することができない旨の応答を返信する手段とを含み、前記応答には、前記ローカルポリシーで許可されるセッション記述プロトコルペイロードを含むことを特徴とするネットワーク・コントローラ。
4. 前記ネットワーク・コントローラがプロキシ・コール・セッション制御機能を有することを特徴とする請求項３に記載のネットワーク・コントローラ。
5. 前記ネットワーク・コントローラがサービス提供コール・セッション制御機能を有することを特徴とする請求項３に記載のネットワーク・コントローラ。

Images