JP2006521717A5 - - Google Patents

Description

通信システムにおけるサービスの提供

本発明は、通信システムに関し、特に通信システムと関連するエンティティ間で通信を必要とするサービスの提供の開始に関する。

通信システムは、通信システムと関連するユーザ機器、通信ネットワーク要素および他のエンティティなどの２つ以上のエンティティ間の通信を可能にする装置とみなすことができる。概して通信システムは、所与の規格または通信システムと関連する様々なエンティティの何が実行を許可され、それがどのように達成されるべきかを定義する仕様に基づいて動作する。例えば、その規格または仕様は、ユーザ、より正確にはユーザ機器または端末がユーザ回路交換サービスおよび／またはパケット交換サービスによって提供されたかどうかを定義することが可能である。接続に用いられる通信プロトコルおよび／またはパラメータも、定義することが可能である。すなわち、その通信が基づくことのできる特定の一連の「規定」は、そのシステムによって通信が可能になるように定義される必要がある。

無線通信をユーザ機器に提供する通信システムは、公知である。無線システムの一例には、セルラーネットワークがある。セルラーシステムにおいて、基地局（ＢＴＳ）または類似的なアクセスエンティティは、これらのエンティティの間の無線インターフェースを介して移動局（ＭＳ）または他の無線ユーザ機器（ＵＥ）のような役割を果たす。ユーザ機器と通信ネットワークとの間の通信は、適切な通信プロトコルに基づくことができる。基地局の装置および他の通信に必要な装置の動作は、１つまたは複数の制御エンティティによって制御することができる。様々な制御エンティティを相互接続してもよい。１つ以上のゲートウェイノードをセルラーネットワークを他のネットワーク、例えば、公衆交換電話網（ＰＳＴＮ）および／またはＩＰ（インターネットプロトコル)のような他の通信ネットワーク、および／または他のパケット交換ネットワークなどへの接続のために提供してもよい。

通信システムへの加入者に対して提供することが可能なサービスの例には、いわゆるマルチメディアサービスがある。マルチメディアサービスの提供が可能となった通信システムは、ＩＰマルチメディアネットワークと呼ばれることもある。ＩＰマルチメディアネットワークの機能は、ＩＰマルチメディアコアネットワーク（ＣＮ）サブシステム、または短くＩＰマルチメディアサブシステム（ＩＭＳ）によって提供することができる。ＩＭＳは、マルチメディアサービスの提供のために様々なエンティティを備える。

通信システムは、ネットワークの様々なサービスの提供機能がサーバとして公知のネットワークエンティティによって取り扱う方向で開発されている。例えば、現在の第三世代（３Ｇ）の無線マルチメディアネットワークのアーキテクチャにおいて、いくつかの異なるサーバを異なる機能を取り扱うために用いることも考えられる。これらには、コールセッション制御機能（ＣＳＣＦ）などの機能が挙げられる。このコールセッション機能は、プロキシコールセッション制御機能（Ｐ−ＣＳＣＦ）、問合せコールセッション制御機能（Ｉ−ＣＳＣＦ）、およびサービング・コールセッション制御機能（Ｓ−ＣＳＣＦ）などの様々なカテゴリに分類することが可能である。時折ＣＳＣＦをコール状態制御機能またはコールサーバ制御機能と呼ぶことが好まれると理解されたい。

サービング・コールセッション制御機能は、通信システムからサービスを要求できるようにするために加入者が登録する必要のあるエンティティを形成する。サービング・コールセッション制御機能は、セッションの開始および終了において、開始に関するコールセッション制御機能（Ｏ−ＣＳＣＦ）および終了に関するコールセッション制御機能（Ｔ−ＣＳＣＦ）にさらに分類することができる。

サービング制御エンティティに加えて、ユーザは、Ｐ−ＣＳＣＦのようなプロキシ制御エンティティを伴うことを必要とすることがある。プロキシエンティティは、ユーザがサービスを提供されるエリアに割り当てることが可能である。

加入者管理サーバ（Home Subscriber Server, ＨＳＳ）および様々なアプリケーションサーバのようなエンティティも、通信ネットワーク内に提供することが可能である。加入者管理サーバ（ＨＳＳ）は、上述のサーバから加入者に関連した情報を格納するためのものである。加入者情報には、認証データ（例えば、加入者または端末の登録識別）などの情報を含むことが可能である。ＨＳＳは、概して恒久的に加入者のプロフィール情報を格納するために用いられる。加入者管理サーバ（HSS）は、例えばセッションのセットアップ手順の間に他の機能エンティティによって問合せを受けることが可能である。

アプリケーションサーバ（ＡＳ）は、付加価値ＩＭサービスをユーザに提供するように構成されたエンティティである。アプリケーションサーバは、ユーザの家庭用ネットワーク内に存在することが可能である。アプリケーションサーバはまた、代わりとして、ユーザの家庭用ネットワークの外部となること、またサードパーティのサービスによって提供されることも可能である。このサードパーティは、別のネットワークまたは単にスタンドアロンのアプリケーションサーバであってもよい。アプリケーションサーバは、オペレータのネットワークによってサポートされるサービスに代わってのデータ通信セッションを左右したり影響を与えたりすることがある。アプリケーションサーバは、サービスのホストし、実行することが可能である。アプリケーションサーバの例には、セッション開始プロトコル（ＳＩＰ）アプリケーションサーバ、オープンサービスアクセス（ＯＳＡ）アプリケーションサーバ、およびモバイルネットワーク用拡張ロジックＩＰマルチメディアサービスの交換機能のためのカスタマイズアプリケーション（ＣＡＭＥＬ ＩＭ−ＳＳＦ）が挙げられる。

伝統的に、通信システムは、ユーザ、概して加入者が通信システム上で通信を始めなければならないように構成される。例えば、ユーザは、通信のセッション、処理または他のタイプに適切な通信ネットワークエンティティから要求することが可能である。このような通信は、ユーザから発信するとみなすことができる。

従って、発信に関するセッション／トランザクションは、通常ユーザのユーザ機器か、またはユーザの代わってのネットワークエンティティによって送られるセッション／トランザクションであると理解される。終了に関するセッション／トランザクションは、通常ユーザのユーザ機器かまたはユーザの代わってのネットワークエンティティによって終了されるセッション／トランザクションである。

例えば、３ＧＰＰ（第三世代標準化団体）規格のリリース５（Ｒｅｌ−５）のＩＭＳネットワークは、ユーザ機器（ＵＥ）がどのようにセッションおよび単一のトランザクションを開始できるのかという規定を定義する。しかしながら、Ｒｅｌ−５に表される唯一の規定では、いわゆる開始に関するフィルタ基準がどのように適用されるのかということに焦点を当てている。リリース５は、他のパーティがユーザに代わってセッションやトランザクションを開始することを許可していない。３ＧＰＰ規格のリリース６では、アプリケーションサーバ（ＡＰ）が、Ｓ−ＣＳＣＦへのＩＳＣ（ＩＰマルチメディアサービス制御）を介してユーザ機器に代わってセッション開始プロトコル（ＳＩＰ）の要求を送信できなければならないことを求めている。しかしながら、現在の３ＧＰＰリリース６規格であっても、アプリケーションサーバの開始要求がユーザ機器からの発信の要求によって直接引き起こされるという例外的な場合を除いて、アプリケーションサーバがそうすることを可能にするアプリケーションサーバ（ＡＳ）に対する機構を提供していない。従って、アプリケーションサーバは、依然としてＳＩＰの要求またはユーザに代わっての他の要求を発信するサービスを実行することができない。

本発明者らは、アプリケーションサーバのようなネットワークエンティティが、ユーザを開始に関するパーティであるとみなすことができるようなユーザに代わっての通信を必要とするプロセスを開始することができれば、利点になりうるということを見出した。有用となりうるサービスの一例には、ユーザに代わってリストのメンバーにメッセージを送信することが可能なアプリケーションサーバであるメッセージングリストが挙げられる。別の例には、ユーザの存在状態を通信するユーザメッセージに代わって送信することができるアプリケーションサーバがある。さらに別の例には、例えば会議やグループコール、またはチャットアプリケーションなどのためにユーザに代わってセッションまたはトランザクションを開始することが可能なアプリケーションがある。上述はほんの数例を示すにすぎないこと、また通信に対して要求を発信することを可能にするネットワークエンティティの可能性によって利益を得ることができる様々な他のサービスがあると理解されたい。

しかしながら、このような動作の要求を発信するネットワークエンティティの取り扱いに対する機構の不足のため、現在の通信システムに問題が生じる可能性がある。例えば、二次的な通信のルーティングや課金機能などに関する問題が生じる可能性がある。これは、通信システムの他のエンティティが、例えば、更なるメッセージをどこで通信すべきか、またはどのように通信を制御すべきかなどを認識できていないために生じる。

例えば、Ｓ−ＣＳＣＦがメッセージを受信する場合、そのメッセージをどのように取り扱うのかを決定できることが必要になる。現在のシステムにおいて、Ｓ−ＣＳＣＦは、メッセージに対して、「開始のためのフィルタ」（Originating Filter）および「終了のためのフィルタ」（Terminating Filter）として知られているフィルタ基準を適用することができる。「フィルタ基準」（Filter Criteria；ＦＣ）という用語は、特定のサービスアプリケーションのための関連するサービスポイントトリガ（ＳＰＴｓ）を定義する用語を示す。ＳＩＰの通信環境では、このフィルタ基準は特定のサービスアプリケーションに送信される、または代理となるべきＳ−ＣＳＣＦによって受信されるＳＩＰの要求のサブセットを定義する。Ｓ−ＣＳＣＦは、このフィルタ基準を加入者管理サーバ（ＨＳＳ）またはアプリケーションサーバ（ＡＳ）から受信することが可能である。

従来技術では、終了に関するフィルタ基準は、アプリケーションサーバからの全てのメッセージに適用される。しかしながら、メッセージは、アプリケーションサーバから発信されたサービス要求や、ネットワーク内のユーザに代わって発信された他の同様なメッセージである可能性がある。従って、本発明者らは、メッセージに対して、終了に関するフィルタ基準ではなく、開始に関するフィルタ基準が適用されるべきであるかどうかを決定するための機構が要求されていることを見出した。これは、開始に関するフィルタ基準がそのようなメッセージに対してより正確な評価結果を与えることが可能だからである。

誤った「役割」すなわちフィルタ基準がメッセージに用いられた場合、このことが、例えば、ルーティングおよび他の制御動作の観点から問題を起こす可能性がある。この点に関して一旦決定が行われると、その決定された役割は、メッセージが送信されたユーザに代わってのユーザ以外であるエンティティから発信されたメッセージの評価に対する適切なフィルタ基準を適用できるように、通信システムの他のエンティティに通信される必要も生じうる。

本発明の実施形態は、上述の問題点のうちの１つまたは複数に対処することを目的としている。

本発明の一側面によれば、通信システムにおけるサービスの提供方法であって、前記通信システムに関連する第１のエンティティにおいて、前記通信システムのユーザにサービスを提供することが可能な通信制御エンティティに関する情報をストレージエンティティから受信するステップと、前記情報に基づいて、前記第１のエンティティから前記通信制御エンティティに開始要求を送るステップと、を備える方法が提供される。

本発明の一側面によれば、通信システムのユーザにサービスを提供するために構成された前記通信システムであって、
・ 前記通信システムのユーザにサービスを提供することができる通信制御エンティティと、
・ ユーザに関するストレージエンティティからの情報を受信するための第１のインターフェース及び前記ストレージエンティティからの前記情報に基づいて前記通信制御エンティティへ開始要求を送るための第２のインターフェースを備える第１のエンティティと、
を備える通信システムが提供される。

本発明の別の側面によれば、通信システムのためのアプリケーションサーバであって、前記通信システムのユーザに関するストレージエンティティからの情報を受信するための第１のインターフェースと、前記ストレージエンティティからの前記情報に基づいてユーザにサービスを提供することが可能な通信制御エンティティに開始要求を送るための第２のインターフェースとを備えるアプリケーションサーバが提供される。

本発明のさらに別の側面によれば、通信システムの第１のエンティティと前記通信システムのユーザにサービスの提供が可能な通信制御エンティティとの間のインターフェースに伝送される開始要求であって、ユーザ情報のストレージエンティティからの情報に基づいて発生される、開始要求が提供される。

より具体的な実施態様では、前記開始要求が、前記要求に関連する通信の取り扱いに関する情報を含む。前記開始要求は、前記開始要求に関連する更なる通信は、その要求がユーザから発信した場合と同様の方法で取り扱われるべきであるとする指示を含むことが可能である。終了サービスあるいは開始サービスのどちらかを、前記要求に基づいて提供することが可能である。

第１のエンティティで、前記通信制御エンティティが前記要求に関連する更なる要求をどのように取り扱うべきであるかを決定することが可能である。

第１のエンティティは、ユーザに代わって前記開始要求を発生させることが可能である。

前記開始要求を、前記通信制御エンティティのアドレスに関する情報に基づいて発生することが可能である。第１のエンティティは、前記開始要求を送信する前に前記通信制御エンティティのアドレスに関する前記情報を修正することが可能である。第１のエンティティは、前記開始要求にサービスタイプの表示子を付け加えることが可能である。前記サービスタイプの表示子を、前記通信制御エンティティの前記アドレス内に含むことが可能である。

第１のエンティティは、要求を送信すべきポートを選択することが可能である。

開始要求を送信する前に第１のエンティティからデータベースに問合せを送信することが可能である。このような問合せは、前記通信制御エンティティに基づく。

ユーザにサービスを提供することを可能にする前記通信制御エンティティに関する前記情報に対する問合せを、第１のエンティティから送信することが可能である。

前記通信制御エンティティの情報に対する少なくとも２つの異なるアドレスに関する情報を、前記ストレージエンティティに格納することが可能である。

前記開始要求は、前記要求に適用されるフィルタ基準を示すことが可能である。

本発明のこれらの実施態様は、ユーザに代わって機能するサービスを実行する可能性を有する通信ネットワークのエンティティを可能にできる。本解決策は、現存する通信システムにおける実施が実質的に容易である。ユーザ情報が加入者管理サーバ（ＨＳＳ）のような集中化された方法で格納された事例では、この集中化されたストレージを修正する必要がない。特定の実施態様において、ユーザ情報ストレージに、サービスへの適切なエントリ点を見つけ出すためのクエリーのような通常の通信プロトコルや手順を用いて問い合わせることができる。

本発明の好適な実施形態の説明

本発明の更なる理解のために、添付図面を例として参照する。

本発明を具体化することが可能であるＩＰマルチメディアネットワークを示す図１を参照する。ＩＰマルチメディアサービスは、ＩＰマルチメディアネットワークの加入者に提供されることが可能である。ＩＰマルチメディア（ＩＭ）機能は、サービスを提供するための様々なエンティティを備えるコアネットワークシステム（ＣＮ）によって提供されることができる。

本発明において、通信システムのエンティティは、通信制御エンティティによってユーザに提供されるサービスと関連する開始要求を送信する。下記の詳細な例において、アプリケーションサーバおよび通信制御エンティティを備えるエンティティは、サービング・コールセッション制御機能によって提供される。実施態様を更に詳細に説明する前に、これらの実施態様および実施態様と関連する他の可能な要素を、図１を参照して以下に簡単に説明する。図１は、モバイル通信システムの一部にすぎないということを理解されたい。

描かれる構成において、基地局１１は、セルラー通信ネットワークのアクセスエンティティを提供する。無線アクセスネットワーク１１は、適切な制御装置（明確にするため図示せず）によって制御される。制御装置を各基地局に備えることが可能であるか、または制御装置が複数の基地局を制御することが可能である。複数の基地局を制御するために、制御装置を個々の基地局および無線アクセスネットワーク階層内に備えるという解決策も公知である。従って、システムに基づいたアクセスネットワーク制御装置の名前、位置および数は、システムに依存すると理解されたい。例えば、ＵＭＴＳ地上波無線アクセスネットワーク（ＵＴＲＡＮ）は、無線ネットワーク制御装置（ＲＮＣ）と呼ばれるコントローラノードを使用することが可能である。ＧＳＭおよびＣＤＭＡ２０００において、対応する無線ネットワーク制御装置エンティティは、基地局コントローラ（ＢＳＣ）と呼ばれる。

図１は、非常に模式的であり、実用的な実施においては基地局の数が実質的に多くなるということを理解されたい。１つのアクセスネットワークは複数の基地局を備えることが可能である。基地局装置または基地局部もまた、複数のアクセスネットワークを提供することが可能である。これらの特徴は、実施および環境に依存する。

基地局１１は、モバイルユーザ、すなわち無線インターフェースを介した加入者のモバイルユーザ機器１０と信号を送受信するように構成される。それに応じて、モバイルユーザ機器１０は、無線インターフェースを介して基地局と信号を送受信することができる。モバイルユーザは、ネットワークに接続するためにインターネットプロトコル（ＩＰ）に適応されるあらゆる適切なモバイル機器を用いることが可能である。例えばモバイルユーザは、パーソナルコンピュータ（ＰＣ）、携帯情報端末（ＰＤＡ）、移動局（ＭＳ）などによってセルラーネットワークにアクセスすることが可能である。以下の例は、移動局のコンテキストに記載されている。

当業者は、代表的な移動局の特徴および動作に精通している。従って、これらは何らかの詳細な説明を必要としない。ユーザは、電話の使用、ネットワークとのデータの送受信、および、例えば、マルチメディアのコンテンツを体験するなどのタスクために移動局１０を使用することが可能であるということに十分気がつく。移動局は、モバイル通信ネットワークの基地局と無線での送受信のためのアンテナ要素を備えることが可能である。移動局１０はまた、モバイルユーザ機器のユーザに画像および他のグラフィック情報を表示するためのディスプレイも備えることが可能である。スピーカ手段もまた、概して提供される。モバイルユーザ機器の動作は、制御ボタンや音声コマンドなどの適切なユーザインタフェースによって制御することが可能である。さらに、モバイルユーザ機器は、プロセッサエンティティおよびメモリ手段を備える。明確にするために図１には１つの移動局しか示されていないが、複数の移動局をモバイル通信システムの各基地局と同時に通信するようにできると理解されたい。

コアネットワーク（ＣＮ）エンティティは、複数の無線アクセスネットワークを介した通信、および１つの通信システムを他のセルラーシステムおよび／または固定回線通信システムのような他の通信システムと接続することを可能にするためのスイッチング、他の制御エンティティおよびゲートウェイを概して備える。

現在の第三世代（３Ｇ）の無線ＩＰマルチメディアネットワークアーキテクチャでは、複数の異なるサーバエンティティが異なる機能を取り扱うために用いられることを前提とする。これらは、コールセッション制御機能（ＣＳＣＦ）を取り扱うエンティティを複数備える。このコールセッション機能は、プロキシコールセッション制御機能（Ｐ−ＣＳＣＦ）１２、問合せコールセッション制御機能（Ｉ−ＣＳＣＦ）２４、およびサービング・コールセッション制御機能（Ｓ−ＣＳＣＦ）１４などの様々なカテゴリに分類することが可能である。

サービング・コールセッション制御機能１４は、加入者１０を登録するエンティティを形成する。通信システムからサービスへ要求できるようにするために、登録が必要である。ユーザは、基地局１１などの通信システムのアクセスエンティティを経て、当人自身を登録することが可能である。サービング・コールセッション制御機能１４は、セッションまたはトランザクションの開始および終了において、開始に関するコールセッション制御機能（Originating-CSCF；Ｏ−ＣＳＣＦ）および終了に関するコールセッション制御機能（Terminating-CSCF；Ｔ−ＣＳＣＦ）を提供するとみなすことができる。

ユーザは、同時に複数のコールセッション制御機能に登録することが可能である。サービング制御エンティティ１４に加えて、ユーザは、図１のＰ−ＣＳＣＦ１２などのプロキシ制御エンティティと関連している必要がある。プロキシエンティティ１２は、ユーザが移動しているエリアに割り当てることが可能である。従って、ユーザが任意のタイプのアクセスネットワークを通じてネットワークにアクセスする場合、このアクセスネットワークは、例えばバンド幅の管理のためのネットワークの観点から、アクセスしたサービスを制御するためのプロキシ制御エンティティを割り当てることが可能である。ユーザが、アクセスネットワークからの支援なしに自分のユーザ機器によって適切なＰ−ＣＳＣＦを探し出すことも可能であると考えられる。

加入者管理サーバ（ＨＳＳ）２０も示される。上述のように、加入者管理サーバ（ＨＳＳ）２０は、加入者、すなわちユーザに関連した情報を格納するためのものである。加入者管理サーバ（ＨＳＳ）には、例えばセッションのセットアップ手順の間に適切なインターフェースについて、他の機能エンティティによってクエリーを行うことができる。

加入者管理サーバ（ＨＳＳ）２０とサービング・コールセッション制御機能（Ｓ−ＣＳＣＦ）１４とを接続するアプリケーションサーバ２２も示される。一般的に、アプリケーションサーバは、ユーザの申込みに基づいて、セッション／トランザクションで利用可能なサービスをホストするエンティティであるとみなすことができる。アプリケーションサーバに対するルーティングを、ユーザの申込みと関連するフィルタ基準の評価の結果として実行することができる。

上述のように、２組のフィルタ基準が用いられることが可能である。このフィルタ基準の内の１組を終了セッション／トランザクションのために、もう１組を開始に関するセッション／トランザクションのために用いることができる。代表的な動作において、フィルタリングは一番初めのメッセージ、すなわち最初の要求に対してのみ適用される。残りのメッセージは、その経路を最初の要求のルーティングの間に記録しておくことができるので、フィルタリングなしで取り扱うことができる。つまり、その後の要求メッセージは記録された経路によってルーティングされるので、フィルタ基準はその後の要求メッセージに影響を与える。従って、その後のメッセージ、すなわち同じダイアログにおける最初の要求の後のメッセージに対しては、フィルタ基準を評価しないことが起こりうる。しかしながら、最初の要求の後のメッセージにフィルタリングを適用することも可能である。

アプリケーションサーバ２２が、Ｓ−ＣＳＣＦ１４にメッセージを送信することによってセッションまたはトランザクションを開始する場合、このＳ−ＣＳＣＦ１４は、どの役割を機能させるのかを決定する必要がある。Ｓ−ＣＳＣＦ１４が、開始に関する役割を行うように選択する場合、Ｓ−ＣＳＣＦは、入力メッセージに開始フィルタ基準を適用する。終了に関する役割を行うにおいて、Ｓ−ＣＳＣＦは、終了に関するフィルタ基準を評価する。この選択を実施するための様々な代替方法を下記に記載する。その役割に従って、Ｓ−ＣＳＣＦはそれから登録メッセージに応答してＰ−ＣＳＣＦに戻るサービスのアドレスを構築することが可能である。Ｐ−ＣＳＣＦはそれから、Ｓ−ＣＳＣＦにメッセージを渡すときにそのアドレスを使用しなければならない。

登録（Registration）の間、Ｓ−ＣＳＣＦ１４は、終了に関するセッションまたはトランザクションで使用しなければならないアドレスをＨＳＳ２０に連絡することが好ましい。

図２に示される好適な実施態様によれば、アプリケーションサーバ１４は、ユーザ機器１０が登録されるＳ−ＣＳＣＦ１４に関するアドレス情報をＨＳＳ２０から受信する。アドレス情報は、例えばエンティティ間のＳｈインターフェースを通じてのクエリーに応答して提供されることが可能である。図２のステップ１を参照。アドレス情報は、Ｓ−ＣＳＣＦの名前またはＳ−ＣＳＣＦのＵＲＩ（ユニバーサルリソース識別子）などのあらゆる適切な情報の形式とすることが可能である。

本発明の好ましい形態によれば、アドレス情報は、所望の役割に関する情報を含めるように構成される。アドレス情報は、本発明の原理に従って、アプリケーションサーバ２２またはそのアプリケーションサーバの外部で構成されることが可能である。後者の場合、その情報を、アドレス情報が取り込まれた情報源において、リストやテーブルまたはデータベースなどに構成された形式に格納することが可能である。代わりに、ユーザ機器またはネットワークのエンティティから受信した要求から、アドレス情報を獲得および格納することが可能である。

図２において、アプリケーションサーバ２０は、アドレス情報の公正に対応するようにステップ番号２で表される。より詳しくは、アプリケーションサーバ２２は、適切なサービスのタイプが加入者に提供されるようにアドレス情報を修正することが可能である。例えば、アプリケーションサーバ２０は、必要とされるサービスのための適切なアドレスを構築するためにサービスの名前を修正することが可能である。Ｓ−ＣＳＣＦの名前は、例えば、ＨＳＳから受信した名前に対する接頭辞として表示子パラメータ「term」または「orig」を追加して修正することが可能である。例えば、アドレス

scscf12.operator.net name

を、アプリケーションサーバを開始するセッションまたはトランザクションが、送信側または終了に関するセッションまたはトランザクションであるかどうかによって、以下のうちの１つに修正することが可能である。

orig.scscf12.operator.net または、
term.scscf12.operator.net

ステップ３において、アドレスは、適切なサービスのＩＰアドレスを得るためにＤＮＳ（ドメインネームシステム）２６によって解決される。

この修正に従って、アドレスは、メッセージを開始サービスまたは終了サービスへと方向付ける。つまり、アプリケーションサーバ２２には、ステップ４において、サービス要求のメッセージを開始サービスまたは終了サービスへとルーティングするできる手段が設けられる。図１に示すように、これをＩＳＣ（ＩＰマルチメディアサービス制御）インターフェースにおいて生じさせることが可能である。

別の例では、アプリケーションサーバ２２は、開始サービスに適切なアドレスを構築するためにＵＲＩに特定のパラメータを付け加えることによって、サービスのＵＲＩを修正することが可能である。アプリケーションサーバ２０はそれから、ルーティングアドレスとしてのパラメータとともにＵＲＩを用いているメッセージの経路を定めることが可能である。

アプリケーションサーバ２２は、終了サービスのための名前またはＵＲＩを修正することを必ずしも必要としないと理解されたい。すなわち、修正が行われなければ、終了サービスが提供される。

また、終了サービスの場合にのみアドレスが修正され、開始サービスの場合にはアドレスの修正は行われない、ということも考えられる。

しかしながら、終了サービス及び開始に関するアドレスの修正が、例えば対称性の理由のために、特定のアプリケーションに要求されることがある。

以下の例は、可能な動作を上記の原理に従って更に詳細に示す。アプリケーションサーバが、ＨＳＳから終了に関するアドレスを獲得したと仮定する。例えば、セッション開始プロトコル（ＳＩＰ）を次の形式のアドレスにしてみる（ユーザ部分を省略していることに注意）

xx44@scscf7.operator.net

アプリケーションサーバ２２が終了に関するセッション／トランザクションを開始しようとしている場合、アプリケーションサーバ２２は、終了に関するセッション／トランザクションの役割を行わなければならないＳ−ＣＳＣＦであるターゲットＳ−ＣＳＣＦ１４に信号を送るために、前記アドレスを使用する。代表的な動作において、これは、入力メッセージの評価時にＳ−ＣＳＣＦ１４が終了に関するフィルタ基準を適用する必要があることを意味する。

アプリケーションサーバ２２が、開始に関するセッション／トランザクションを開始しようとしている場合、アプリケーションサーバ２２はアドレスを修正する。これは、そのアドレスに新たな「役割」パラメータを付け加えることによって行うことができる。従って、役割パラメータrole=origを備えている修正アドレスは、例えば次の形式を有することが可能である。

xx44@scscf7.operator.net;role=orig

その後、この修正アドレスは、ターゲットＳ−ＣＳＣＦが開始に関するセッション／トランザクションの役割を行わなければならないことを示す表示子として、ターゲットＳ−ＣＳＣＦに送られる。代表的な動作において、Ｓ−ＣＳＣＦが開始に関するフィルタ基準を評価する必要があることを意味する。

Ｓ−ＣＳＣＦのアドレスは、そのアドレスを必要とするアプリケーションサーバ２２の中で構成されることが可能である。代わりに、そのアドレスは、全てのアプリケーションサーバで構成されることが可能である。後者の代替案は、例えば、アプリケーションサーバ２２から加入者管理サーバ２０へのＳｈインターフェースがないか、またはインターフェースが一時的に利用できない場合に有利になりうる。

代替案によれば、アドレスそのものを修正するというよりも、アプリケーションサーバ２２は、データベース、ファイル、リスト、テーブルなどから修正データを取り込むことが可能である。データベースは、アプリケーションサーバ２２内に位置するか、またはこのアプリケーションサーバの外部のデータベースとすることが可能である。

パラメータがＳ−ＣＳＣＦ１４のアドレスとともにＨＳＳ２０に格納されるというアドレス構築の可能性がある。アプリケーションサーバ２２は、それから修正プロセスのための入力としてのＨＳＳからのアドレスおよびパラメータの情報を用いて、適切なアドレスを構築することが可能である。

図３に示される可能性によれば、アプリケーションサーバ２２は、ステップ１でＨＳＳから戻されるアドレス情報に基づいて、ＤＮＳ（ドメインネームシステム）クエリーを行う。戻されたＳ−ＣＳＣＦの名前は、例えば、必要とされる（開始または終了の）サービスが利用可能であるアドレスおよびポートを見つけ出すためのＳＲＶのリソースレコードを要求するために用いることが可能である。ＳＲＶは、サービス（ＤＮＳ ＳＲＶ）の位置を指定するためのＤＮＳのリソースレコード（ＲＲ）である。ＳＲＶのリソースレコードの使用は、特定のサービスおよび／または特定のドメインのプロトコルに対してクエリーを行うことを可能にする。その応答は、それから基準を満たすあらゆる利用可能なサーバ名前を含むことになる。

例えば、開始に関するフィルタ基準を評価しなければならない場合、ＳＲＶのリソースレコードからの以下のＤＮＳクエリーを実行することが可能である。ＳＲＶのリソースレコードは、概してプロトコルおよびサービスの両方を指定する。ＳＲＶのレコードは、以下のアドレスを引数として用いることによってステップ２でクエリーを行うことができる。

_orig._sip.scscf12.operator.net

ステップ２での応答は、ポート5060を用いて指定されたアドレス"orig.scscf12.operator.net"に経路を定めるための通知とすることが可能である。

_orig._sip.scscf12.operator.net SRV 0 0 5060 orig.scscf12.operator.net.

代わりに、その応答は、当初のアドレス"scscf12.operator.net"を有する指定されたポート55334に経路を定めることが可能である。

_orig._sip.scscf12.operator.net SRV 0 0 55334 scscf12.operator.net.

以下の引数は、終了に関するフィルタ基準を評価しなければならない場合に、ＤＮＳクエリー（ＳＲＶ）に用いることが可能である。

_term._sip.scscf12.operator.net

その応答は、ポート5060を用いて指定されたアドレス"term.scscf12.operator.net"に経路を定めるための通知とすることが可能である。

_term._sip.scscf12.operator.net SRV 0 0 5060 term.scscf12.operator.net.

または、上記のようにその応答は、例えば当初のアドレス"scscf12.operator.net"を有する指定されたポート55335に経路を定めることが可能である。

_term._sip.scscf12.operator.net SRV 0 0 55335scscf12.operator.net.

概して、アプリケーションサーバの開始に関する要求がどのように取り扱われるのかが示されるので、上記のタイプの経路指定は開始サービスには必要でないことがあると理解されたい。開始サービスに特別な経路指定のないアプリケーションも考えられる。アドレス修正と同様に、上述のタイプの経路指定は、例えば対称性の理由のために要求されることがある。

アプリケーションサーバは、その後、ステップ３でＤＮＳによってアドレスを解決することが可能で、ステップ４で示されたアドレスおよび／またはポートにメッセージをルーティングすることが可能である。

別の可能性によれば、加入者データベース（例えばＨＳＳ２０）は、ステップ１でＳ−ＣＳＣＦの名前を返す。アプリケーションサーバは、その後、利用可能なサービス（開始および／または終了）を見つけ出すためのＮＡＰＴＲ（ネーミングオーソリティポインタ）を要求する、返されたＳ−ＣＳＣＦの名前を有するＤＮＳクエリーを作成する。その応答に基づいて、アプリケーションサーバは、それから所望のアドレスに要求メッセージの経路を定めることが可能である。この実施態様によって、ドメインネームの構文にはない様々なリソースネームに対するルックアップサービスためのＤＮＳの使用が可能になる。可能なリソースネームは、サービスのためのＵＲＩを備える。

以下は、ＳＲＶを有するＮＡＰＴＲクエリーの例である。ＤＮＳクエリーは、例えば次のＳ−ＣＳＣＦアドレスのドメイン部分を用いてＮＡＰＴＲのリソースレコードを要求することによって行われる。

scscf12.operator.net

結果は、以下のようになりうる。

IN NAPTR 100 10 "S""sip+orig" ""_orig._sip.scscf12.operator.net.
IN NAPTR 100 10 "S""sip+term" ""_term._sip.scscf12.operator.net.

命令および優先フィールドが等しいので、任意のＲＲｓを選択することができる。開始に関するセッション／トランザクションのためのＳ−ＣＳＣＦのアドレスが必要である場合、最初のアドレスを選択することが可能である。フラグ「Ｓ」は、次のＤＮＳクエリーがＳＲＶ ＲＲを要求して実行されることを示す。このＤＮＳクエリーは、ドメインネーム、すなわち上述のようなアドレスによってＳＲＶ ＲＲを要求して実行することが可能である。

_orig._sip.scscf12.operator.net.

DNSクエリーの結果は、ＩＰアドレスまたは他のいずれの適切な経路指定情報であることが可能である。

また、ＳＲＶクエリーを行わないＮＡＰＴＲを実施することも考えられる。上記のように、ＤＮＳクエリーは、Ｓ−ＣＳＣＦアドレスのドメイン部分を用いてＮＡＰＴＲ ＲＲを要求して実行することが可能である。例えば、

scscf12.operator.net

その結果は、次のようになりうる。

IN NAPTR 100 10 "A" "sip+orig" "" orig.scscf12.operator.net.
IN NAPTR 100 10 "A" "sip+term" "" term.scscf12.operator.net.

命令および優先フィールドが等しいので、任意のＲＲｓを選択することができる。開始に関するセッション／トランザクションのためのＳ−ＣＳＣＦのアドレスが必要である場合、最初のアドレスを選択することが可能である。フラグ「Ａ」は、次のＤＮＳクエリーが、ＳＲＶ Ａ，ＡＡＡＡまたはＡ６のリソースレコードを要求して実行されることを示す。ＤＮＳクエリーは、それからドメインネームorig.scscf12.operator.netを有するＡ，ＡＡＡＡまたはＡ６ ＲＲを要求して実行される。クエリーは、結果としてＩＰアドレスになる。

更なる選択肢によれば、ＤＮＳクエリーは、Ｓ−ＣＳＣＦアドレスのドメイン部分を用いてＮＡＰＴＲ ＲＲを要求して実行され、以下のような結果となる。

IN NAPTR 100 10 "U" "sip+orig" "!(^.$)!sip:orig.\1!".
IN NAPTR 100 10 "U" "sip+term" "!(^.$)!sip:term.\1!".

この選択肢の利点は、全てのＳ−ＣＳＣＦが概して共通のＮＡＰＴＲのリソースレコードを有するということである。命令および優先フィールドが等しいので、任意のＲＲｓを選択することができ、従って開始に関するセッション／トランザクションの最初のものを選択することができる。フラグ「Ｕ」は、結果がＵＲＩとなることを示す。その結果は、次のようになりうる。

sip:orig.scscf12.operator.net.

ＵＲＩのドメイン部分は、ＩＰアドレスに対してＤＮＳクエリーによって解決される。このＤＮＳクエリーは、ドメインネームを有するＡ，ＡＡＡＡまたはＡ６ ＲＲを要求して実行することが可能で、その結果はＩＰアドレスとなる。

アプリケーションサーバがメッセージを送信する適切なポートを選択または修正するという可能性がある。そのポートはアドレスの最後に付け加えられることができる。

上記例において、示されたサービスタイプは、アドレスのドメイン部分に含められた。アプリケーションサーバがアドレスのユーザ部分を選択または修正するという可能性がある。例えば、アプリケーションサーバは、次のアドレスを

scscf12.operator.net

ユーザ部分としてタグ、文字、文字列またはビット列を付け加えることによって次のように修正することが可能であり、従って、開始サービス（またはその逆）のためのアドレスを構築する。

orig@scscf12.operator.net

上記の実施態様では、Ｓ−ＣＳＣＦのアドレスはＨＳＳに１つしか格納されていない。この例において、役割は、修正されたアドレスによってＳ−ＣＳＣＦへ伝えられるが、この修正アドレスは、修正ユーザ部分、修正ホストまたはドメインネーム、修正ポート番号、アドレスに付け加えられたパラメータ、またはこれらの任意の組み合わせを含むことが可能である。好ましい形態における動作では、パラメータが存在するか、またはアドレスが修正された場合、Ｓ−ＣＳＣＦは開始に関する役割を行わなければならないようなものとなる。付け加えられたパラメータが見つからない、またはアドレスが修正されていない場合、Ｓ−ＣＳＣＦは終了に関する役割を行う。

しかしながら、ＨＳＳ内にＳ−ＣＳＣＦのアドレスを２つ（すなわち、開始に対するアドレスおよび終了に関する役割に対するアドレス）格納しておくことも可能である。故に、図４に示される別の実施態様に従って、Ｓ−ＣＳＣＦに対する１つ以上のアドレスが加入者管理サーバ（ＨＳＳ）２０に格納される。

より詳しくは、ＨＳＳ２０は、開始に関するフィルタ基準をトリガーするためのＳ−ＣＳＣＦアドレスと、終了に関するフィルタ基準をトリガーするためのＳ−ＣＳＣＦアドレスとを格納することが可能である。アプリケーションサーバ２２は、ユーザ機器１０に代わって機能する必要がある場合に、それからＳｈインターフェースを介して所望のアドレスを取り込むことが可能である。または、アプリケーションサーバ２２は、両方のアドレスを取り込み、必要な１つを選択することが可能である。これは、実施に関わる問題である。

２つの曲線状の経路指定矢印３０および３１は、２つの異なるサービスタイプへのメッセージングを示す。メッセージング矢印３０は、終了サービスプロファイルに基づいて実行されるユーザの終了サービスの情報フローを示す。メッセージング矢印３１は、開始サービスプロファイルに基づいて実行されるユーザの開始サービスの情報フローを示す。

図５は、上記の実施態様によるサービスの提供の可能性を示す。ステップ１、２および４に対しては、図２および３の実施態様の説明を参照のこと。ステップ５において、サービスは、ユーザから要求されたサービスであるかのように、提供される。

上記の例証された通信環境において、現存のＳｈインターフェースへの拡張は、開始に関するＳ−ＣＳＣＦアドレスをＨＳＳからアプリケーションサーバに引き込むことが必要となる場合がある。これは、「Ｓ−ＣＳＣＦネーム」の情報要素を包含するためのＳｈ−ｐｕｌｌ要求への拡張によって提供することができる。同様に、ＨＳＳ２０とＳ−ＣＳＣＦ１４との間のＣｘインターフェースへの拡張は、Ｓ−ＣＳＣＦ１４からＨＳＳ２０までの開始に関するＳ−ＣＳＣＦアドレス情報をプッシュするために必要となる場合がある。

ストレージエンティティに格納される通信制御エンティティのアドレスまたは名前は、ユーザ部分を含んだり含まなかったりすることがあるということを理解されたい。アドレスまたは名前は、ポートを含むものまたは含まないものでも良い。

ＩＰマルチメディアサービスを有するユーザ機器の登録の間に、Ｓ−ＣＳＣＦが開始に関する要求のためにそのアドレスをＣｘインターフェースを介してＨＳＳにプッシュすることが可能であるように配置してよい。Ｃｘ：Ｓ−ＣＳＣＦ登録および／または登録の取り消し通知の要求が、開始に関するＳ−ＣＳＣＦおよび終了に関するＳ−ＣＳＣＦのアドレスのどちらも含むように延長することが可能である。

上記の例において、 ユーザ機器は、少なくとも１つのサービング・コールセッション制御機能によって登録されると考えられた。そのユーザに対する登録が見つからないか、またはＳ−ＣＳＣＦのアドレスがＨＳＳから受信されない場合は、デフォルトのアドレスか最新のアドレスを使用することが可能である。

簡潔に前述したように、アプリケーションサーバが外部のデータベースからアドレス情報を取り込むことを必要としない場合がある。上述のＨＳＳに加えて、アドレス情報は、加入者位置機能（ＳＬＦ）またはサービスおよび加入者リポジトリ（ＳＳＲ）などのあらゆる外部データベースから得ることが可能である。

アプリケーションサーバまたは他のいずれの適切なエンティティは、ユーザ機器から受信した要求からのＳ−ＣＳＣＦのアドレス情報を、最初に受信することも可能である。受信したアドレス情報を、アプリケーションサーバと一体化されたストレージエンティティに格納することが可能である。アドレス情報が開始に関する要求に対して後に必要とされる場合、その情報は、それからアプリケーションサーバに内蔵されたストレージエンティティから得ることが可能である。

ユーザは間接的にサービスの開始又は終了を生じさせることができるが、サービス通信制御エンティティ（例えばＳ−ＣＳＣＦ）のアドレスまたは名前を取り扱うことの責任は、アプリケーションサーバにあると理解されたい。従って、ユーザは、直接的にサービス通信制御エンティティのアドレス指定を行っていない。このように、アプリケーションサーバは、様々なソースから、ユーザ機器にサービスを提供することが可能な通信制御エンティティに関する情報を受信することが可能である。加入者データベース（例えばＨＳＳ）またはアプリケーションサーバの内部データベースなどのストレージエンティティに加えて、アプリケーションサーバは、サービス通信制御エンティティまたは他のいずれのネットワークエンティティから受信されるメッセージから、サービス通信制御エンティティの名前またはアドレスを得ることも可能である。このようなメッセージは、例えば、アプリケーションサーバに受信されるより以前の要求であってよい。

また、アプリケーションサーバが、ＨＳＳまたは他のデータベースから、サービス通信制御エンティティのアドレスのリストを得ることも可能である。そしてＡＳは、適切なものをそのリストから選択することが可能である。これは、例えばユーザが全く登録されておらず、ＨＳＳで利用可能なＳ−ＣＳＣＦのアドレスがない場合に有用なオプションになりうる。ＡＳは、その後、アドレスをデフォルトのＳ−ＣＳＣＦｓのリストから取り出すことが可能である。このような状況では、ＨＳＳは、それから単に機能を戻すことしかできない。ＡＳは、この情報に基づいて適切なＳ−ＣＳＣＦを選択することができる。

本発明の実施態様は移動局に関して記載されているが、本発明の実施態様は他のいずれの好適なタイプのユーザ機器にも適用可能であると理解されたい。

本発明の実施態様は、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）、ｉ−ｐｈｏｎｅまたはＣＤＭＡ２０００、および地上基盤無線（ＴＥＴＲＡ）システムなどの第三世代のモバイル通信システムというコンテキストにおいて説明された。さらにまた、所与の例は、全てのＳＩＰエンティティを有するいわゆる全ＳＩＰネットワークというコンテキストにおいて説明された。本発明はまた、他のいずれの適切な通信システム、無線あるいは固定回線システムの両方、そして規格およびプロトコルに適用可能である。これらを制限することなく、無線データ通信サービスを可能にする他の考えられる通信システムの例としては、汎用パケット無線システム（ＧＰＲＳ）、ＧＳＭ進化型高速データレート （ＥＤＧＥ）モバイルデータネットワーク、および様々な無線ローカルエリアネットワーク（Ｗ−ＬＡＮ）アプリケーションなどが挙げられる。固定回線システムの例としては、家庭やオフィスなどの異なる場所でユーザにインターネットへのアクセスを提供する様々なブロードバンド技術が挙げられる。本発明は、通信ネットワークに用いられる規格およびプロトコルに関係なく、ネットワークエンティティが開始に関するセッションまたはトランザクションを可能にするすべての通信ネットワークに適用することができる。

本発明の実施態様では、アプリケーションサーバエンティティとサービング・コールセッション制御機能エンティティとの間のインターフェースについて述べた。

しかしながら、このアプリケーションサーバはサーバの一例にすぎないということを理解されたい。本発明の実施態様は、該当する場合には、他のネットワークエンティティに適用可能である。従って、アプリケーションサーバは、ゲートウェイ、他のいずれかのサーバ、プロキシ、クライアント、ユーザエージェントまたは他のいずれのネットワーク要素、機能、またはセッションまたはトランザクションを開始することが可能である同種のものに対して有効であることも理解されたい。

通信という用語は、コール、データ（例えばウェブの閲覧）またはマルチメディア通信などのあらゆるセッションまたはトランザクションを指しているということを理解されたい。

上述した以外にも、それらを置き換えたり、それらに付け加えたりするいくつかの役割がある。類似的な機構を、他の役割を取り扱うために用いることが可能である。追加的な役割を用いる場合、その追加的な役割は、例えば、それから加入者データベースに格納されるか、または新しいパラメータによって示されるそれら自身のアドレスとともに割り当てられる。

上記の実施態様は、それらが互いに実施するか、または互いに同時に並行して用いられるように組み合わせることができる。通信システムは、異なる実施を異なるネットワークエンティティで使用することができる。例えば、通信システムのエンティティは、図２に記載された解決策を使用することが可能で、同一の通信システムの別のエンティティは、図４の実施態様を使用することが可能である。

また本願明細書には、上記の本発明の実施態様を例証する一方で、添付の請求の範囲に記載された本発明の範囲を逸脱することなく、開示された解決策に対して行うことが可能な様々なバリエーション、組み合わせおよび修正があるということにも注目されたい。

本発明を具体化することが可能である通信システムを示す。 本発明の実施態様を示す。 他の実施態様を示す。 他の実施態様を示す。 実施態様を用いたサービスの提供を表すフローチャートを示す。