JP2013153481A

JP2013153481A - Ｉｐマルチメディアサブシステムにおけるユーザｉｄの処理

Info

Publication number: JP2013153481A
Application number: JP2013042327A
Authority: JP
Inventors: Przybysz Hubert; ヒュベルトプリツィビイズ，; Forsman Timo; ティモフォルスマン，
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2013-03-04
Filing date: 2013-03-04
Publication date: 2013-08-08

Abstract

【課題】IPマルチメディアサブシステムネットワークによって受信されたSIPリクエストを処理する方法を提供する。
【解決手段】SIP宛先IDが前記ネットワークのオペレータによって所有されているIDの範囲内であるが、ネットワークの加入者又はサービスに現在割り当てられていないか否かを判別するステップと、もしそうであれば、メッセージをネットワーク内の１つ以上のSIPアプリケーションサーバへルーティングするステップと、ネットワークが所有するが割り当てされていないSIP宛先ID、に特有なサービスロジックを１つ以上のアプリケーションサーバで実行するステップとを有する。
【選択図】図１

Description

本発明はIPサブシステムにおけるユーザIDの処理に関する。本発明は特に、IPマルチメディアサブシステムネットワークオペレータによって割り当てされていないユーザ及び／又はサービスIDの処理に関する。

IPマルチメディアサービスは、音声、映像、メッセージ、データ等の動的な組み合わせを同一セッション内で提供する。組み合わせ可能な基本アプリケーション及びメディアの数を増やせば、エンドユーザに提供されるサービスの数も増加し、個人間の通信体験も豊かなものになるであろう。これは、所謂「組み合わせIPマルチメディア」サービスを含む、個人向けのリッチマルチメディア通信サービスの新世代へ繋がるであろう。

UMTS (Universal Mobile Telecommunications System)は、高速データレート及び拡張されたサービスを加入者に提供するように設計された第３世代無線システムである。UMTSはＧＳＭ（登録商標） (Global System for Mobile Communications)の後継であり、GPRS (General Packet Radio Service)を含んでいる。GPRSはコアネットワークにパケット交換を導入し、パケットデータネットワーク(PDN)への直接アクセスを可能にしている。UMTSは、欧州電気通信標準化機構(ETSI)や電波産業会(ARIB)など、地域的な標準化団体の集まりである第三世代パートナシッププロジェクト(3GPP)によって標準化されている。詳細については3GPP TS 23.002を参照されたい。

3GPP機関は、従来の電話通信だけでなく新たなIPマルチメディアサービスもサポートするために、UMTSネットワークへの具体的な適用性を有する、IPマルチメディアサブシステム(IMS)として知られるサブシステムを策定した(3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 及び TS 29.329 リリース 5〜7)。IMSはエンドユーザの個人間通信体験を豊かにするための鍵となる機能であり、IPベースのネットワークを通じた、新たでリッチな個人間（クライアント間）通信サービス並びに個人−コンテンツ間（クライアント−サーバ間）サービスを促進する機能を、標準化されたIMSサービスイネーブラの使用を通じて提供する。

IMSはユーザ端末間（又はユーザ端末とアプリケーションサーバ間）の呼又はセッションの設定及び制御に、セッション開始プロトコル(SIP)を用いる。SIPシグナリングで搬送されるセッション記述プロトコル(SDP)は、セッションのメディアコンポーネンツの記述及びネゴシエーションに用いられる。SIPはユーザ間プロトコルとして作られたが、IMSはオペレータ及びサービスプロバイダがサービスへのユーザアクセスを制御したり、サービスへのアクセスに応じてユーザに課金することを可能にしている。

添付図面の図１は、IMSがどのようにして移動体ネットワークアーキテクチャに適合しているのかを、GPRS/PSアクセスネットワークの場合について模式的に示している（もちろん、IMSは他のアクセスネットワーク上でも動作可能である）。呼/セッション制御機能(CSCF)は、IMS内でSIPプロキシとして動作する。IMSアーキテクチャは以下の３種類のCSCFを規定している。プロキシCSCF(P-CSCF)は、IMS内でSIP端末に対する最初の接触点である。サービングCSCF(S-CSCF)は、ユーザにユーザが加入しているサービスを提供する。問い合わせCSCF(I-CSCF)は、正しいS-CSCFを特定し、P-CSCFを介してSIP端末から受信したリクエストを、特定したS-CSCFへ転送する。

ユーザは、規定されたSIP REGISTERメソッドを用いてIMSに登録する。これは、IMSにアタッチし、SIPユーザIDに到達可能なIMSアドレスをアナウンスするための仕組みである。IMSにおいて、SIP端末が登録を実行する際、IMSはユーザ認証を行い、利用可能なS-CSCFのセットから、そのユーザにあるS-CSCFを割り当てる。S-CSCFを割り当てる条件はIMSに規定されていないが、負荷分散及びサービス要件を含むであろう。S-CSCFの割り当ては、IMSベースのシステムへのユーザアクセスを制御するため（そしてユーザアクセスに対して課金するため）の鍵となることに留意されたい。オペレータはIMSをバイパスするであろうユーザ間の直接SIPセッションを阻止するための仕組みを提供してもよい。

登録処理の間、S-CSCFがまだ選択されていなければ、S-CSCFの選択はI-CSCFが受け持つ。I-CSCFはホームネットワークのホーム加入者サーバ(HSS)から必要なS-CSCF能力を受信し、受信した能力に基づいて適切なS-CSCFを選択する。（ユーザが別の加入者から着呼した場合で、ユーザがその時点でS-CSCFを割り当てられていない場合には、I-CSCFによってユーザに対するS-CSCF割り当てが実行されることに留意されたい。）登録済みユーザが引き続きセッションリクエストをIMSに送信する際、P-CSCFはそのリクエストを、登録処理中にS-CSCFから受信した情報に基づいて、選択されたS-CSCFに転送することが可能である。

IMSサービスネットワーク内には、IMSサービス機能を実装するためアプリケーションサーバ(AS)が設けられている。アプリケーションサーバはIMSシステム内のエンドユーザにサービスを提供し、エンドポイントとして3GPPが規定するMrインタフェース上で接続されても、3GPPが規定するISCインタフェース上でS-CSCFによって「接続(linked in)」されてもよい。後者の場合、S-CSCFは、SIPセッション確立中にどのアプリケーションサーバを「接続」すべきか、初期フィルタ基準(IFC)を用いて決定する。呼の状況に応じて異なるIFCが用いられてもよい。S-CSCFはIFCをユーザのユーザプロファイルの一部として、IMS登録手順の間にHSSから受信する。一部のアプリケーションサーバは、アプリケーションサーバを制御するネットワークが「所有」する加入者ID（被呼加入者か発呼加入者かを問わず）に応じて、アクションを実行するであろう。例えば、自動転送(call forwarding)の場合、適切な（終端）アプリケーションサーバが、ある加入者への呼が転送される新たな終端加入者を決定する。S-CSCFで受信されたSIPメッセージを特定のSIP ASへ転送すべきであることがIFCに示される場合、そのASがメッセージパスに追加される。そのSIPメッセージがそのASからS-CSCFへ戻されると、そのSIPメッセージは最終宛先へ転送されるか、IFCに示されている場合には他のASへ転送される。

IMSにおけるアドレス指定は、IMSネットワークオペレータによってユーザに割り当てられた公衆ユーザID（SIPアドレス）を用いて処理される。ユーザは１つ以上の公衆ユーザIDを割り当てられてもよい。”ims-operator.com”ドメインを所有するオペレータは、公衆ユーザIDを”sip:john.smith@ims-operator.com”のように割り当てるであろう。ここで、SIP URIのユーザ部分はユーザを区別するために用いられ、ドメインはIMSオペレータのネットワークを指定する。

一般に、IMSオペレータはその加入者に対するE.164番号の範囲を割り当てられるであろう。例えば、IMSオペレータが”+4685520XXXX”の番号範囲を割り当てされているとすると、IMSオペレータはその中から自身のユーザに対する電話番号を割り当てる。これらの番号は、例えば、電話URIについては”tel:+46855201234”、SIP URIについては”sip:+46855201234@ims-operator.com”という形式で、追加のIMS公衆ユーザIDも提供することもできる。

IMSオペレータが、自身に属するIDの範囲内ではあるが、実際のユーザに割り当てられていないIDを宛先とするSIPリクエストを受信すると、問題が生じる。今日のIMSはそのようなリクエストは”404 Not Found”という応答と共に送信者へ戻して拒否するであろう。リクエストのこのような単純処理は、例えばアドレス指定されたユーザが（例えばGSTNに）存在しない場合にそのリクエストを他のオペレータや子会社に転送したり、そのリクエストの送信者がオンラインで宛先アドレスを修正することを助けるサーチサービスを提供し、修正されたアドレスへリクエストを進ませたり、アナウンスを提供したりといった、よりインテリジェントなサービスロジックをIMSオペレターが実行することを妨げている。

この問題は、初期のIMS案がTel URIではなくSIP URIの利用に特化していたため、これまで認識されずに来たことに留意されたい。SIP URIを用いる場合、SIP URIは命名規則に従っているであろうから、”404 Not Found”応答で十分であった。しかし、Tel URI及び電話番号に基づくSIP URIの導入は、番号は範囲外だがアドレスは範囲内であることがIMS内で実際の問題となることを意味する。

本発明の第１の見地によれば、IPマルチメディアサブシステムネットワークで受信したSIPリクエストを処理する方法が提供される。この方法は、SIP宛先IDが前記ネットワークのオペレータによって所有されているIDの範囲内であるが、前記ネットワークの加入者又はサービスに現在割り当てられていないか否かを判別するステップと、もしそうであれば、前記メッセージを前記ネットワーク内の１つ以上のSIPアプリケーションサーバへルーティングするステップと、ネットワークが所有するが割り当てされていないSIP ID、に特有なサービスロジックを前記１つ以上のアプリケーションサーバで実行するステップとを有する。

本発明の実施形態は、未割り当てのアドレスを宛先とするSIPリクエストを、例えば404 Not Foundに基づく応答よりもずっと柔軟に処理することを可能にする。特に、そのようなリクエストを、適切なサービスロジックを有するアプリケーションサーバへ導いて処理することを可能にする。

SIP宛先IDが未割り当てか否かの判別は、I-CSCF又はS-CSCFのようなSIPプロキシが直接行うこともできるし、そのようなプロキシからHSS又はSLFエンティティに委託することもできる。

本発明の好ましい実施形態は、リクエストを受信し、前記判別をHSS及び／又はSLFとコンタクトすることによって実行するI-CSCFを含む。SIP宛先IDが未割り当てである場合、前記I-CSCFは前記リクエストをS-CSCFへ転送する。前記I-CSCFは前記リクエストに、前記宛先アドレスが未割り当てであるとの表示を含ませることができる。SIP宛先IDが未割り当てでなければ、S-CSCFがHSS/SLFへの問い合わせを実行することができる。

S-CSCFは、前記ネットワークオペレータが所有する未割り当てIDに対する初期フィルタ基準であって、少なくとも１つのアプリケーションサーバを指定する初期フィルタ基準を予め設定されていてよい。あるいは、前記S-CSCFはリクエストを受信すると、前記ネットワークオペレータが所有する未割り当てIDに対する初期フィルタ基準であって、少なくとも１つのアプリケーションサーバを指定する初期フィルタ基準を、ホーム加入者サーバからダウンロードしてもよい。

前記判定がI-CSCFで実行される場合、前記I-CSCFはアプリケーションサーバのIDを予め設定されていて良く、前記方法は、前記SIP宛先IDが前記ネットワークのオペレータによって所有されているIDの範囲内であるが、前記ネットワークの加入者又はサービスに現時点で未割り当てであると判別された場合、前記I-CSCFにおいて前記受信したリクエストのために前記アプリケーションサーバを呼び出すステップを有する。「呼び出す」とは、前記リクエストがアプリケーションサーバへ転送されること、すなわち、前記アプリケーションサーバが前記SIPパスに「接続」されることを示す。

本発明の第２の見地によれば、SIPリクエストを受信する手段と、前記リクエストのSIP宛先IDが前記ネットワークのオペレータによって所有されているIDの範囲内であるが、前記ネットワークの加入者又はサービスに現時点で未割り当てであるか否かを判別し、もしそうであれば、前記メッセージを前記ネットワーク内の１つ以上のSIPアプリケーションサーバもしくは他のネットワークノードへルーティングする手段とを有するIPマルチメディアサブシステムノードが提供される。前記ノードはI-CSCF又はI-CSCFであってよい。

本発明の第３の見地によれば、ネットワークのオペレータによって所有されているIDの範囲内であるが、前記ネットワークの加入者又はサービスに現時点で未割り当てである要求SIP宛先IDを有するSIPに関するサービスロジックを実行する手段を有するIPマルチメディアサブシステムアプリケーションサーバが提供される。

本発明の第４の見地によれば、IPマルチメディアサブシステムで用いるためのホーム加入者サーバであって、IPマルチメディアサブシステムノードからSIP宛先IDを含んだ問い合わせを受信する手段と、前記SIP宛先IDが前記ネットワークのオペレータによって所有されているIDの範囲内であるが、前記ネットワークの加入者又はサービスに現時点で未割り当てであるか否かを判別する手段と、前記判別の結果を前記ノードへ通知する手段とを有するホーム加入者サーバが提供される。

本発明の第５の見地によれば、IPマルチメディアサブシステムで用いるための加入者ロケーション機能であって、IPマルチメディアサブシステムノードからSIP宛先IDを含んだ問い合わせを受信する手段と、前記SIP宛先IDが前記ネットワークのオペレータによって所有されているIDの範囲内であるが、前記ネットワークの加入者又はサービスに現時点で未割り当てであるか否かを判別する手段と、このようなIDの処理を受け持つホーム加入者サーバを特定する手段と、前記ホーム加入者サーバを前記ノードへ通知する手段とを有する加入者ロケーション機能が提供される。

IPマルチメディアサブシステムの3G移動体通信システムへの統合を模式的に示す図である。未割り当てアドレスをIMS内で処理するための仕組みの概要を示す図である。未割り当てアドレスをIMS内で処理するための仕組みであって、S-CSCFでAS呼び出しを実行する第１の実施形態を模式的に示す図である。、図３の実施形態のための信号フローを表す図である。図３及び図４の実施形態についてHSSで実行されるロジックであり、I-CSCFから受信したロケーションクエリを処理するためのロジックを説明するフローチャートである。図３及び図４の実施形態についてHSSが保持するデータ構造を示す図である。未割り当てアドレスをIMS内で処理するための仕組みであって、I-CSCFでAS呼び出しを実行する第２の実施形態を模式的に示す図である。、図７の実施形態のための信号フローを表す図である。

従来の仕組みで提供される柔軟性よりも遙かに高い柔軟性を提供する、未割り当てのユーザIDを処理するための仕組みをIMSに導入することを提案する。この新規な仕組みは、以下の主要機能を含む。

1. 未割り当てID判別(UID)：オペレータの範囲(scope/range)に属するが、現時点で未割り当てである特定のユーザIDをIMSシステムが判別／認識できるように、オペレータが所有する公衆ユーザIDの範囲及び電話番号の範囲についての新たな情報がIMSシステムに導入される。

UID機能はまず、SIPリクエストの宛先アドレスに指定されているIDが未割り当てかどうか、すなわちそのIDがオペレータによって所有されているが実際のユーザ又はサービスに現時点で未割り当てであるかどうか、を調べるために用いられる IDがオペレータに属するかどうかを調べるための実際のデータ及びロジックは、そのオペレータがどのようにしてIDを生成しているかに依存する。一般的な場合、オペレータが所有するドメイン及び番号列の組に対する単純なチェックであってよい。より複雑な場合には、データは合致したらそのIDがオペレータの所有するIDの範囲内であることを示す（１つ以上の）正規表現であってよい。

IDが未割り当てであれば、リクエストの処理は以下に説明するサービス呼び出し機能において継続する。IDが未割り当てでなければ（すなわち、IDがこのオペレータに未知であるか、オペレータが所有しており実際のユーザ又はサービスに割り当てされていれば）、リクエストの処理は現時点のIMS手順に従って継続する（すなわち、それぞれリクエストは拒否されるか、サービスが提供される）。この機能は、IDがオペレータに所有されていたが、今は他のオペレータに”移転(port)”されていることを考慮に入れる必要がある。オペレータ間のIDの移転は、現在E.164電話番号に適用可能な規定のサービスである。

2. 未割り当てユーザIDについてのサービス呼び出し機構(SIUI)：トラフィックリクエストが現時点で未割り当てのIDへアドレス指定されている場合、１つ以上のアプリケーションサーバをIMSシステムによって呼び出す必要があるか、またどのアプリケーションサーバを呼び出す必要があるかをオペレータが制御することを可能にする新規な仕組みである。

SIUI機能は、未割り当てID用に実行すべき１つ以上のサービスが存在するかどうかを調べるために用いられる。もし存在すれば、SIUI機能はそのサービスロジックが位置する１つ以上のアプリケーションサーバのアドレスを返送する。SIUI機能は、SIPリクエストを優先順位に従って１つ以上のアプリケーションサーバへ転送する。未割り当てIDに対するサービスがこのネットワークに準備されていない場合、IDがオペレータに未知であるものとして、すなわち現在のIMS手順に従って、リクエストの処理が継続されるであろう。ここで、「アプリケーションサーバ」は、概して未割り当てIDへのSIPリクエストを処理可能なIMSノードを指すものとして用いられる。IMS用語では、ASはTS 23.002で規定されているものに加え、そのようなIMSノードはMRF, BGCF, MGCF, IBCFなどであってよい。

3. 未割り当てユーザID用のサービスロジック(SEUI)：未割り当てIDに対して１つ以上のアプリケーションサーバで実行されるサービスロジックである。例えば、特定のサービスロジックは、リクエストをアドレス指定されたユーザが存在する他のオペレータ又は子会社（例えばGSTN内）へ転送可能であっても、リクエストの発信者がオンラインで目標アドレスを訂正することを助ける探索サービスを提供し、訂正されたアドレスへリクエストを進めてもよいし、アナウンスを提供してもよいし、また他のことを行ってもよい。他のサービスももちろん可能である。

図２はこの仕組みを模式的に示している。

本発明の第１の実施形態

図３は、本発明の第１の実施形態を模式的に示しており、以下のように動作する。

1. HSSノードはIMSネットワークオペレータが所有するID（電話番号を含む）の範囲を知るようになり、オペレータに属するが未割り当てのIDを判別することが可能になる。Cx又はShインタフェース上でそのようなIDに関する問い合わせを受けると、HSSは問い合わせ元ノードにその番号が未割り当てであることを示す新規な情報を返送するであろう。

2. HSSは未割り当てIDに対して新規な形式のプロファイルを有するであろう。この新規なプロファイルは、未割り当てユーザIDの一般的な処理に必要な情報を提供並びに格納するために用いられる。未割り当てIDの異なる組み合わせ処理するため、HSSはそのようなプロファイルを１つ以上有することができる。この新規なプロファイルは、S-CSCFがサービス呼び出しのために用いる初期フィルタ基準を含むであろう。そして、ユーザプロファイルに通常含まれる全ての情報を含んでもよい。新規なプロファイル形式はまた、未割り当てID（のある組み合わせ）に対するサービスが存在しないことを示すことが可能であってもよい。

3. 今日のIMSにおける割り当て済みIDの場合と同様、現在割り当て済みのS-CSCFが存在しない場合にS-CSCFを選択する処理においてI-CSCFを補助するため、HSSは未割り当てIDの場合に必要なS-CSCF能力を格納及び提供することが可能であろう。HSSは未割り当てIDに対するサービスが存在しない場合、それを示すことも可能であろう。

4. 現在のIMSにおいて割り当て済みIDに対して行うのと同様、HSSは、ある未割り当てIDが属する（一式の）未割り当てIDを処理するように割り当てられたS-CSCFのアドレスを格納並びに提供することが可能であろう。

5. 現在のIMSにおいて割り当て済みIDに対して行うのと同様、加入者ロケーション機能(SLF)はどの１つ以上のHSSノードが未割り当てのユーザIDを処理することが可能であるかを判別可能であろう。そして、Dx及びDhインタフェース上で未割り当てIDに関する問い合わせを受けると、正しいHSSアドレスを返送するであろう。

6. 終端(terminating)SIPリクエストを受信すると、I-CSCFはHSSに（場合によっては最初にSLFに問い合わせして、問い合わせべきHSSのアドレスを取得した後で）、リクエスト-URIにおいて受信されたIDの位置情報を問い合わせ、IDが未割り当てであるという新規な表示を、そのIDに対するサービスが存在し、そのサービスに割り当てられているS-CSCFがあればそのアドレスと、S-CSCFが割り当てられていなければS-CSCF能力とともに取得するであろう。この新規な表示は、HSS内の新規なプロファイルへの参照の形式を有していてよい。I-CSCFは、S-CSCFが割り当てされていない場合、受信した能力に基づいてS-CSCFを選択するであろう。さもなくば、I-CSCFはHSSから受信した、割り当てされているS-CSCFのアドレスを用いるであろう。未割り当てユーザIDは、ユーザ未登録ステータスを有するであろう。I-CSCFはSIPリクエストをS-CSCFへ転送し、このリクエストに、IDが未割り当てであることの表示を含めるであろう。I-CSCFは、未割り当てIDに対するが存在しないとの表示をHSSから受信すると、SIPリクエストを拒否するであろう。

7. 終端SIPリクエストを受信すると、S-CSCFはI-CSCFによって挿入された新規な表示により、リクエストが未割り当てユーザIDにアドレス指定されていることを知るであろう。S-CSCFは、関連するプロファイルがS-CSCFにキャッシュされていなければ、（一式の）未割り当てユーザに対する新規プロファイルをHSSからダウンロードするため、HSSにコンタクトすることができる。S-CSCFはまた、（一式の）未割り当てIDにサービスを提供するS-CSCFとして自身のアドレスをHSSに格納してもよい。そしてS-CSCFは、現在の手順と同様にIFC評価手順を実行し、提供されたIFCに従って１つ以上のアプリケーションサーバを呼び出すであろう。SIPリクエストをASに転送する際、IDが未割り当てであることをアプリケーションサーバが認識しやすくするために、S-CSCFはIDが未割り当てであることの表示も転送することができる。

8. 終端SIPリクエストを受信するASは、リクエストが未割り当てIDにアドレス指定されたものであることを判別するため、リクエスト中のその表示を用いることができる。ASは、（一式の）未割り当てIDに対するサービスロジックを実行する。ASは新規プロファイルに関連するサービス実行についてのさらなるサービス情報の格納及び取得のために、Shインタフェース上でHSSとやりとりすることができる。

図４ａ及び４ｂは、本実施形態のIMS内の例示的な情報の流れを示す。図中、番号が振られたステップは以下の通りである。

1. I-CSCFが、あるID宛の終端SIPリクエスト（SIP REGISTERリクエスト以外のどのリクエストであってもよい）を受信する。複数のHSSノードを有する環境では、I-CSCFはIDを処理するHSSのアドレスを見つけ出さねばならず、また、I-CSCFは以下のステップ２のように、受信したIDとともにSLFクエリをDxインタフェース上でSLFへ送信する。さもなくば、I-CSCFはCxロケーションクエリを受信したIDとともに直接HSSへ送信し、手順はステップ４へ継続する。

2. SLFはSLFクエリをDxインタフェース上でIDと共に受信する。ここで分析されているケースでは、IDはオペレータに属するが、どのユーザにも割り当てされていない。そのため、SLFにおいて新たな処理が必要である。SLFは、未割り当てIDに対してもHSSノードを示し、受信したIDが属する（一式の）未割り当てIDを処理する能力を有するHSSノードのアドレスと共にSLF応答を返送する能力を有するであろう。SLFは、Dx SLF 応答において、未割り当てIDを処理するHSSのアドレスを返送する。

3. I-CSCFはSLF応答をHSSのアドレスと共に受信する。I-CSCFは、IDに関する情報を取得するため、ロケーションクエリを、受信したIDとともにCxインタフェース上でHSSへ送信する。

4. HSSはロケーションクエリをCxインタフェース上でIDと共に受信する。今日のHSSはIDが割り当てされていないことを、そのIDに対してデータが提供されていないことによって判別することができる。ここで分析されているケースでは、IDはオペレータに属するが、どのユーザ又はサービスにも割り当てされていない。そのため、新規データ並びに処理がHSSに必要である。HSSは、IDがオペレータに所有されるものであることをHSSが判別できるようにするであろう新規データを提供されるであろう。IDが未割り当てであるがオペレータに属していることをHSSが見出した場合、HSSはそれを”未割り当て”と判別する。HSSはさらに、受信した未割り当てIDが属する（一式の）未割り当てIDに対するサービスが存在するかを調べるであろう。もし存在すれば、HSSはCxロケーション応答でIDが未割り当てであるとの表示を返送するであろう。もし存在しなければ、HSSは”見つからない”又は”未割り当てであるがサービス無し”との形式の応答を返送するであろう。HSSロジックを図５に示す。図５は、問い合わせに対してHSSがどのような形式の結果を返送するかを詳細に示している。”未割り当てID”応答は、例えば明示的な表示として、あるいは未割り当てIDプロファイルへの参照としてなど、様々な方法で実施可能である（他の方法も可能である）。

図６は、２つの未割り当てIDプロファイルを示す：未割り当てIDセット１用と未割り当てIDセット２用である。セット１は関連付けられたIFCのリストを有するが、セット２は有していない（セット２内のIDに対するサービスが存在しないという意味である）。未割り当てIDセットを定義するデータは、例えば実際のIDのセットとして、またワイルドカード、正規表現又は数値範囲を用いて、など（他の方法も可能である）、様々な方法で実施可能であるため、これ以上詳細な説明は行わない。図は単なる例示であり、HSS内の新規データは様々な方法でモデル化されてよいことに留意されたい。HSSが（一式の）未割り当てIDにサービスを提供するS-CSCFのアドレスを格納していれば、HSSはこのアドレスを返し、そうでなければHSSは受信したIDが属する（一式の）未割り当てIDを処理するのに必要なS-CSCF能力を返送するであろう。

5. I-CSCFはロケーションクエリ応答をクエリの結果と共にCxインタフェース上で受信する。応答が”見つかりません”又は”未割り当てでサービス無し”を示す場合、引き続き既存の手順を行う（すなわち、I-CSCFが典型的にはSIPリクエストを拒否するか、IDが移転されている場合にはSIPリクエストを他のオペレータに転送するであろう）。応答が、IDの未割り当てを示す場合、I-CSCFは、S-CSCFが（受信した能力に基づいて）割り当てされていなければS-CSCFを選択するか、HSSから受信した割り当て済みS-CSCFのアドレスを、SIPリクエストを転送するために用いるであろう。

I-CSCFは、S-CSCFに転送するSIPリクエストに、未割り当てID表示を含めるであろう。この表示は、HSSから受信した未割り当てIDプロファイルへの参照形式であってよい。この表示は、例えばリクエストURI内、SIPヘッダ内又はSIPメッセージ本体内のURIパラメータとしてなど、様々な方法で実施することができる。１つの考えられる実現は、未割り当てIDがHSS内で共通のユーザプロファイルを有するとするとdraft-camarillo-sipping-profile-key-01.txtに記述されるP-プロファイルキーP-ヘッダを使うことであろう。

6. S-CSCFは、未割り当てID表示と共に、あるIDへ宛てられた終端SIPリクエストを受信する。未割り当てID表示を受信すると、S-CSCFは、受信した未割り当てIDに適用可能な関連未割り当てIDプロファイルを既に有しているかどうかを調べることができる。関連プロファイルが未だキャッシュされていなければ、S-CSCFは関連プロファイルをHSSから取得する必要があるだろう。S-CSCFはまた、受信したIDが属する（一式の）未割り当てIDに対してHSSに自身のアドレスを格納することにより、（一式の）未割り当てIDにサービスを提供するように自身を割り当てることを決定してもよい。これらの何らかの理由により、S-CSCFはこの時点でCxインタフェース上でHSSとのやりとりを必要としてもよい。複数のHSSノードが存在する環境では、S-CSCFは未割り当てIDを処理するHSSのアドレスを見つける必要がある。受信したIDが属する（一式の）未割り当てIDに対するHSSアドレスをS-CSCFが既にキャッシュしている場合、ステップ８に記述されているように、S-CSCFはCx Put/PullリクエストをHSSアドレスに直接送信する。そうでなければ、S-CSCFはDxインタフェース上でSLFへ受信したIDとSLFクエリを送信して、SLFからHSSのアドレスを取得する必要がある。

7. ステップ２と同様、SLFは、Dx SLF 応答において、未割り当てIDを処理するHSSのアドレスを返送する。

8. S-CSCFはSLF応答をHSSのアドレスと共に受信する。S-CSCFは未割り当てIDプロファイルを取得及び／又は自身のアドレスをHSSに保存するため、Cx Put/Pullリクエストを送信する。このリクエストは受信したIDを含み、最適化オプションとして、受信した未割り当てID表示をさらに含んでもよい。未割り当てID表示は、HSS内の未割り当てIDプロファイルへの参照形式である場合に特に有用である。

9. HSSはCx Put/PullリクエストをIDとともに、また場合によってはさらに未割り当てID表示（潜在的に未割り当てIDプロファイルへの参照形式である）とともに受信する。HSSは、S-CSCFのアドレスがリクエスト内で提供されれば、それを（一式の）未割り当てIDに対して格納する。HSSは受信したID及び未割り当てID表示を解析し、受信したIDが属する（一式の）未割り当てIDに関連する未割り当てIDプロファイルをCx Put/Pull応答で返送するであろう。

10. S-CSCFは１つ以上のIFCを含んだ未割り当てIDプロファイルをCx Put/Pull応答で受信する。S-CSCFは受信したプロファイルをキャッシュする。S-CSCFはまた、HSSアドレスを格納し、HSSアドレスを（一式の）未割り当てIDと関連付けてもよい。S-CSCFは引き続き、現在行われているようにサービス呼び出し手順を実行する。S-CSCFは、受信した初期SIPリクエストを優先順位に従ってIFCと突き合わせ、一致するものが見つかれば、そのIFCに関連付けられたASアドレスへ（未割り当てID表示を含んだ）SIPリクエストを転送する。ASアドレスはFQDNであってよく、I-CSCFがASインスタンスを選択した場合には（例えばDNSによって）ASインスタンスの番号に解決することができる。

11. ASは、あるID宛の、未割り当てID表示を含んだ終端SIPリクエストを受信する。ASが自身のサービスロジックを実行するためにHSSとやりとりする必要があれば、ASはステップ１２〜１４を実行することができる。HSSとのやりとりが不要なら、ASは未割り当てID用のサービスロジックを実行する。この例示的な手順においては、ASがプロキシ又はB2BUA（バックツーバックユーザエージェント）として機能し、ステップ１６に示すようにSIPリクエストをS-CSCFに返送する。

12. 複数のHSSがネットワーク中で用いられている場合、ASは未割り当てユーザIDを処理するHSSノードを見つけるため、SLFノードとコンタクトする必要がある。そのために、ASはSLFクエリを受信したIDと共にDhインタフェース上で送信する。SLFにおける新しい処理が必要である。Dh SLFクエリを受信すると、SLFは未割り当てIDのためのHSSノードを示す能力を有するようになるであろう。そして、SLFは、受信したIDが属する（一式の）未割り当てIDを処理可能なHSSノードのアドレスと共にSLF応答を返送することが可能であろう。SLFは、Dh SLF 応答において、未割り当てIDを処理するHSSのアドレスを返送する。

13. ASは、Shインタフェース上でリクエストを受信したIDとともにHSSへ送信する場合には、未割り当てIDが属する（一式の）未割り当てIDに関する（HSSが保持する）データを読み出し、格納し、あるいは購読するために、HSSとやりとりすることを望んでもよい。リクエストはSh-Pull, Sh-Update, 又はSh-Sub-Notifyリクエストであってよい。ASは新規な未割り当てID表示をShリクエストに含める。

14. HSSはShリクエストをID並びに新規な未割り当てID表示とともに受信し、受信したIDが属する（一式の）未割り当てIDに関連付けられたデータへの参照を見つける。HSSはSh応答を返送する。Sh応答は（一式の）未割り当てIDに対する新規な未割り当てIDプロファイルを含んでよい。

15. 未割り当てID用のサービスロジックを実行した後、ASはSIPリクエストを未割り当てIDにアドレス指定されたS-CSCFに転送してよい（この例ではASがプロキシ又はB2BUAとして機能するため）。SIPリクエストは未割り当てID表示を含んでいる。

16. S-CSCFはSIPリクエストをASから受信し、通常のIFC評価処理を継続する。この例示的な手順において、別の一致するIFCが見出され、S-CSCFはこの別のIFCに関連付けられたASへ受信したSIPリクエストを転送する。

本発明の第２の実施形態

図７は、本発明の第２の実施形態を模式的に示しており、以下のように動作する。

1. IDが未割り当てかどうかの判別を必要とする各IMSノードは、新規な未割り当てIDデータを所有している。そのようなノードの各々は、IDがHSSにおいて割り当て済みかどうかを調べるため、まずHSSに問い合わせる。もし割り当て済みでなければ、IDを自身のデータと照合し、IDがオペレータによって所有されているかどうかを判別する。この手法において、I-CSCFはこの新規なデータを有するであろう。そして、ASはそのデータを必要としてもよい。

2. 終端SIPリクエストを受信すると、I-CSCFはHSS又は（HSSが複数存在する環境においては）SLFに、リクエストURIで受信したIDのユーザ登録ステータスに関して問い合わせ、現在の手順と同様にそのIDが”見つからない(Not Found)”との表示を取得するであろう。そしてI-CSCFは、受信したIDを自身が有する新規な未割り当てIDデータと照合し、そのIDがオペレータによって所有されているかどうかを判別する。もし、IDがオペレータによって所有されていなければ、既存の手順が実行されるであろう。IDがオペレータによって所有されていれば、I-CSCFはIDが未割り当てであろうと見なす。

3. I-CSCFは、未割り当てID用に予め設定されたサービスロジックを有するIMSノード（一般にはAS）のアドレスを予め設定されている。受信したIDが未割り当てであろうとI-CSCFが判定すると、I-CSCFはSIPリクエストをそのアドレスへ転送する。I-CSCFはまた、未割り当てID用のサービスロジックが予め設定されているエンティティがなければ、未割り当てIDへのリクエストを拒否する能力も有するであろう。ASアドレスはFQDNであってよく、I-CSCFがASインスタンスを選択した場合には（例えばDNSによって）ASインスタンスの番号に解決することができる。

4. SIPリクエストを受信すると、ASはそのリクエストが未割り当てID宛かどうか判別することを必要としてもよい（例えば、ASが割り当て済みIDと未割り当てIDの両方に対するサービスをホスティングしている場合）。これを行うため、ASはまずHSS又は（HSSが複数存在する環境においては）SLFに、IDに関して問い合わせ、IDが”見つからない”という表示を、現在の手順と同様に取得するであろう。そしてASは、受信したIDを自身が有する新規な未割り当てIDデータと照合し、そのIDがオペレータによって所有されているかどうかを判別する。もしIDがオペレータによって所有されていなければ、ASはSIPリクエストを拒否してよい。IDがオペレータによって所有されていれば、ASはIDが未割り当てであろうと見なす。

5. ASは未割り当てIDに対して１つ以上の新規なサービスを実行するであろう。

図８ａ及び８ｂは、本実施形態に関する情報の流れの例を示し、番号が振られたステップは以下のようなものである。

1. I-CSCFが、あるID宛の終端SIPリクエスト（SIP REGISTERリクエスト以外のどのリクエストであってもよい）を受信する。複数のHSSノードを有する環境では、I-CSCFはIDを処理するHSSのアドレスを見つけ出さねばならず、I-CSCFは以下のステップ2のように、受信したIDとともにSLFクエリをDxインタフェース上でSLFへ送信する。さもなくば、I-CSCFはCxロケーション問い合わせを受信したIDとともに直接HSSへ送信し、手順はステップ４へ継続する。

2. SLFはSLFクエリをDxインタフェース上でIDと共に受信する。今日のSLFと同様、SLFは未割り当てID用のHSSを見出さず、”見つからない(Not found)”表示をSLF応答で返す。

3. I-CSCFは、”見つからない”表示と共にSLF応答を受信する。手順はステップ６へ継続する。

4. HSSはロケーションクエリをCxインタフェース上でIDと共に受信する。今日のHSSと同様、IDが未割り当てであればHSSはIDのレコードを見出さず、Cxロケーション応答において”見つからない”を返す。

5. I-CSCFは、”見つからない”表示と共にCxロケーション応答を受信する。手順はステップ６へ継続する。

6. 受信したIDが”見つからない”という表示をSLF/HSSで受信すると、I-CSCFは、受信したIDがオペレータによって所有されているかどうかを、I-CSCFに予め設定されている新規な未割り当てIDデータに基づいて調べるであろう。ここで検討しているケースでは、受信したIDはオペレータによって所有されているものであるため、I-CSCFはそれを未割り当てであろうと見なす。I-CSCFは、さらに、新規なデータを未割り当てIDを処理可能なASのアドレスと共に用いて、SIPリクエストをASへ転送するであろう。未割り当てID用のサービスロジックを実行するASが存在しない場合、I-CSCFはSIPリクエストを拒否する（この場合は図示していない）。

7. ASは未割り当てID宛のSIPリクエストを受信する。ASが、割り当て済みIDと未割り当てIDの両方に対するリクエストにサービスを提供している場合、ASは受信したIDが未割り当てかどうかを判別すること、つまりはSLF/HSSとやりとりすることを必要としてもよい。そうでなければ、ASは処理をステップ１３で継続する。HSSノードが複数存在する環境では、ASはIDを処理するHSSのアドレスを見つけなければならず、以下のステップ８に示すように、受信したIDとともにSLFクエリをDhインタフェース上でSLFへ送信する。HSSが１つの環境では、ASはShリクエスト（例えばSh-Pull）を受信したIDとともにHSSへ直接送信し、手順はステップ１０で継続する。

8. SLFはSLFクエリをDhインタフェース上でIDと共に受信する。今日のSLFと同様、SLFは未割り当てID用のHSSを見出さず、”見つからない(Not found)”表示をSLF応答で返送する。

9. ASは、”見つからない”表示と共にSLF応答を受信する。手順はステップ１２へ継続する。

10. HSSはShリクエスト（例えばSh-Pull）をIDとともに受信する。今日のHSSと同様、IDが未割り当てであればHSSはIDのレコードを見出さず、ShΩロケーション応答において”見つからない”を返送する。

11. ASは、”見つからない”表示と共にSh応答を受信する。手順はステップ12へ継続する。

12. 受信したIDが”見つからない”という表示をSLF/HSSで受信すると、I-CSCFは、受信したIDがオペレータによって所有されているかどうかを、ASに予め設定されている新規な未割り当てIDデータに基づいて調べるであろう。ここで解析しているケースでは、受信したIDはオペレータによって所有されているものであるため、ASはそれを未割り当てであろうと見なす。

13. ASは未割り当てIDに対する新規なサービスロジックを実行する。

本技術分野に属する当業者には理解されるであろうが、本発明の範囲を出脱することなく様々な上述の実施形態に対して様々な変更をおこなうことが可能であろう。例えば、未割り当てIDの様々なグループ又はクラスを異なる方法で処理可能であることが予期されている。これは、様々なアプリケーションサーバを様々な範囲のIDに対してサービスを提供するように割り当てたり、同一のアプリケーションサーバ内で異なるサービスロジックを異なる範囲に対して適用したりすることによって実現してもよい。

Claims

IPマルチメディアサブシステムネットワークによって受信されたSIPリクエストを処理する方法であって、
前記SIP宛先IDが、前記ネットワークのオペレータによって所有されているIDの範囲内であるが前記ネットワークの加入者又はサービスに現時点で未割り当てか否かを判別するステップと、もしこの判別が肯定であれば、前記メッセージを前記ネットワーク内の１つ以上のSIPアプリケーションサーバへルーティングするステップと、ネットワークが所有するが割り当てされていないSIP ID、に特有なサービスロジックを前記１つ以上のアプリケーションサーバで実行するステップとを有することを特徴とする方法。
さらに、SIPリクエストをIPマルチメディアサブシステムネットワークノードで受信するステップと、前記ノードからホーム加入者サーバ又は加入者ロケーション機能へ問い合わせを送信するステップと、前記判別するステップを前記ホーム加入者サーバ又は加入者ロケーション機能において実行するステップと、結果を前記ネットワークノードへ返送するステップとを有することを特徴とする請求項１記載の方法。
さらに、SIPリクエストをIPマルチメディアサブシステムネットワークノードで受信するステップと、前記ノードからホーム加入者サーバ又は加入者ロケーション機能へ問い合わせを送信するステップと、前記ホーム加入者サーバ又は加入者ロケーション機能において、前記SIP宛先IDが前記ネットワークのオペレータに属しているかを判定し、もし属していないならば前記ネットワークノードへ”見つからない”表示を返送するステップと、前記ネットワークノードにおいて、前記SIP宛先IDが前記ネットワークのオペレータが所有するIDの範囲内であるか判別するステップとを有することを特徴とする請求項１記載の方法。
前記ネットワークノードがI-CSCFであることを特徴とする請求項２又は請求項３記載の方法。
前記I-CSCFはアプリケーションサーバのIDを予め設定されており、前記方法が、前記SIP宛先IDが前記ネットワークのオペレータによって所有されているIDの範囲内であるが、前記ネットワークの加入者又はサービスに現時点で未割り当てであると判別された場合、前記I-CSCFにおいて、前記受信したリクエストのために前記アプリケーションサーバを呼び出すステップをさらに有することを特徴とする請求項４記載の方法。
ホーム加入者サーバ又は加入者ロケーション機能から前記I-CSCFへ、アプリケーションサーバのIDを送信するステップと、前記I-CSCFにおいて、前記受信したリクエストのために前記アプリケーションサーバを呼び出すステップとをさらに有することを特徴とする請求項４記載の方法。
前記ホーム加入者サーバ又は加入者ロケーション機能から前記I-CSCFへ送信される応答にS-CSCF IDを含めるステップと、前記リクエストを前記S-CSCFに転送するステップとをさらに有することを特徴とする請求項４記載の方法。
前記I-CSCFにおいて、前記ホーム加入者サーバ又は加入者ロケーション機能から前記I-CSCFに供給された情報に基づいてS-CSCFを割り当てるステップと、前記リクエストを前記S-CSCFに転送するステップとをさらに有することを特徴とする請求項４記載の方法。
前記I-CSCFから前記S-CSCFへ送信される前記リクエストに、前記判別の結果の表示を含めるステップをさらに有することを特徴とする請求項７又は請求項８記載の方法。
前記S-CSCFから前記ホーム加入者サーバ又は加入者ロケーション機能に問い合わせを送信するステップと、前記ホーム加入者サーバ又は加入者ロケーション機能において、前記SIP宛先IDが前記ネットワークのオペレータが所有するIDの範囲内であるが、現時点で前記ネットワークの加入者又はサービスに未割り当てかどうか判別するステップと、結果を前記S-CSCFに返送するステップとをさらに有することを特徴とする請求項７又は請求項８記載の方法。
前記S-CSCFからホーム加入者サーバ又は加入者ロケーション機能に問い合わせを送信するステップと、前記ホーム加入者サーバ又は加入者ロケーション機能において、前記SIP宛先IDが前記ネットワークのオペレータに属しているかを判定し、もし属していないならば前記S-CSCFへ”見つからない”表示を返送するステップと、前記S-CSCFにおいて、前記SIP宛先IDが前記ネットワークのオペレータが所有するIDの範囲内であるか判別するステップとをさらに有することを特徴とする請求項７又は請求項８記載の方法。
前記ネットワークノードがS-CSCFであることを特徴とする請求項2又は請求項3記載の方法。
前記受信したリクエストに含まれている前記判別又は前記S-CSCFで得た前記判別に応答して、前記S-CSCFにおいて１つ以上のアプリケーションサーバを呼び出すステップをさらに有することを特徴とする請求項７乃至請求項１２のいずれか１項に記載の方法。
前記S-CSCFに、前記オペレータが所有する未割り当てIDに対する初期フィルタ基準であって、少なくとも１つのアプリケーションサーバを指定する初期フィルタ基準を予め設定するステップをさらに有することを特徴とする請求項１３記載の方法。
前記S-CSCFでリクエストを受信すると、前記ネットワークのオペレータが所有する未割り当てIDに対する初期フィルタ基準であって、少なくとも１つのアプリケーションサーバを指定する初期フィルタ基準をホーム加入者サーバから前記S-CSCFにダウンロードするステップをさらに有することを特徴とする請求項１３記載の方法。
前記問い合わせがホーム加入者サーバへ送信され、前記方法が、初期問い合わせを加入者ロケーション機能へ送信するステップと、前記加入者ロケーション機能において、未割り当てのSIP IDを受け持つホーム加入者サーバを特定するステップと、前記IDを前記加入者ロケーション機能から前記ホーム加入者サーバへ返送するステップとをさらに有することを特徴とする請求項２乃至請求項１５のいずれか１項に記載の方法。
IPマルチメディアサブシステムノードであって、
SIPリクエストを受信する手段と、
前記リクエストのSIP宛先IDが前記ネットワークのオペレータによって所有されているIDの範囲内であるが、前記ネットワークの加入者又はサービスに現時点で未割り当てであるか否かを判別し、もしこの判別が肯定であれば、前記メッセージを前記ネットワーク内の１つ以上のSIPアプリケーションサーバもしくは他のネットワークノードへルーティングする手段とを有することを特徴とするノード。
前記判別する手段が、前記リクエストをホーム加入者サーバ又は加入者ロケーション機能へ転送し、前記リクエストの前記SIP宛先IDが前記ネットワークのオペレータによって所有されているIDの範囲内であるが、前記ネットワークの加入者又はサービスに現時点で未割り当てであるかどうかの判別を前記ホーム加入者サーバ又は加入者ロケーション機能から受信する手段を有することを特徴とする請求項１７記載のノード。
前記ノードがI-CSCF又はS-CSCFであることを特徴とする請求項１７又は請求項１８記載のノード。
IPマルチメディアサブシステムアプリケーションサーバであって、前記ネットワークのオペレータによって所有されているIDの範囲内であるが、前記ネットワークの加入者又はサービスに現時点で未割り当てである要求SIP宛先IDを有するSIPに関するサービスロジックを実行する手段を有することを特徴とするアプリケーションサーバ。
IPマルチメディアサブシステムで用いるためのホーム加入者サーバであって、IPマルチメディアサブシステムノードからSIP宛先IDを含んだ問い合わせを受信する手段と、前記SIP宛先IDが前記ネットワークのオペレータによって所有されているIDの範囲内であるが、前記ネットワークの加入者又はサービスに現時点で未割り当てであるか否かを判別する手段と、前記判別の結果を前記ノードへ通知する手段とを有することを特徴とするホーム加入者サーバ。
IPマルチメディアサブシステムで用いるための加入者ロケーション機能であって、IPマルチメディアサブシステムノードからSIP宛先IDを含んだ問い合わせを受信する手段と、前記SIP宛先IDが前記ネットワークのオペレータによって所有されているIDの範囲内であるが、前記ネットワークの加入者又はサービスに現時点で未割り当てであるか否かを判別する手段と、そのようなIDの処理を受け持つホーム加入者サーバを特定する手段と、前記ホーム加入者サーバを前記ノードへ通知する手段とを有することを特徴とする加入者ロケーション機能。