説明

IPマルチメディア・サブシステム・ネットワークの緊急シグナリング

IPマルチメディア・サブシステム・ネットワークにおいて緊急シグナリングを処理する方法及び装置である。プロキシ呼セッション制御機能は、セッションの設定を要求するメッセージを受信する。当該メッセージは、IPマルチメディア・プライベート識別子に関連する。プロキシ呼セッション制御機能は、メッセージが緊急呼に関連するかを判定する。プロキシ呼セッション制御機能にIPマルチメディア・プライベート識別子に関連する緊急オーバライド・タグが提供又は設定されている場合、メッセージは、サービング呼セッション制御機能(S−CSCF)にSIPメッセージを転送する。プロキシ呼セッション制御機能にIPマルチメディア・プライベート識別子に関連する緊急オーバライド・タグが提供又は設定されていない場合、メッセージは、緊急呼セッション制御機能(E−CSCF)に転送される。本発明は、P−CSCFが緊急シグナリングの処理の制御を行うことを可能にする。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、IPマルチメディア・サブシステム・ネットワークの緊急シグナリングの分野に関する。
【背景技術】
【0002】
IPマルチメディア・サブシステム(IMS)は、移動通信ネットワーク経由でIPマルチメディア・サービスを提供するために、第3世代パートナーシップ・プロジェクト(3GPP)で定義される技術である。
【0003】
IMSは、ユーザ端末間の呼又はセッションを設定し制御するために、セッション開始プロトコル(SIP)を利用する。SIP信号により搬送されるセッション記述プロトコル(SDP)は、セッションのメディア・コンポーネンツを記述し、交渉するために使用される。SIPはユーザ間のプロトコルとして作成されたが、IMSは、オペレータやサービス・プロバイダが、ユーザによるサービスへのアクセスや、それによるユーザへの課金を制御することを許可している。
【0004】
図1は、汎用パケット無線サービス(GPRS)アクセス・ネットワークの場合に、IMSがどの様に移動通信網のアーキテクチャに適合するかを概略的に示している。図1に示す様に、通信制御は、3つのレイヤ(又はプレーン)で生じる。最下位レイヤは、ベアラ・プレーンとしても参照される接続レイヤ1であり、このレイヤ経由で、信号は、ネットワークにアクセスするユーザ装置(UE)から/へ送信される。IMS加入者をIMSサービスに接続する接続レイヤ1内のエンティティは、IP接続アクセス・ネットワーク(IP−CAN)として参照されるネットワークを形成する。GPRSネットワークは、種々のGPRSサポート・ノード(GSN)を含んでいる。ゲートウェイGPRSサポート・ノード(GGSN)2は、GPRSバックボーン・ネットワークと他のネットワーク(無線ネットワーク及びIMSネットワーク)間のインタフェースとして動作する。中間レイヤは、制御レイヤ4であり、最上位レイヤは、アプリケーション・レイヤ6である。
【0005】
IMS3は、中間の制御レイヤ4と接続レイヤ1上で動作するコア・ネットワーク3aと、サービス・ネットワーク3bとを備えている。IMSコア・ネットワーク3aは、接続レイヤ1において、GGSN2経由でGPRSネットワークから/へ信号を送受信するノードと、中間の制御レイヤ4でIMS内のSIPプロキシとして動作する呼/セッション制御機能(CSCF)5を含むネットワーク・ノードを有している。3GPPアーキテクチャは、SIP端末にとって、IMS内の最初のコンタクト・ポイントであるプロキシCSCF(P−CSCF)と、ユーザが加入しているサービスをユーザに提供するサービングCSCF(S−CSCF)と、正しいS−CSCFを識別し、SIP端末からP−CSCF経由で受信した要求を、正しいS−CSCFに転送するインタロゲーティングCSCF(I−CSCF)という3つの種別のCSCFを定義している。最上位のアプリケーション・レイヤ6は、IMSサービス・ネットワーク3bを含んでいる。アプリケーション・サーバ(AS)7は、IMSサービス機能を実行するために設けられる。
【0006】
UEにより緊急呼を行う場合、通常、P−CSCFから緊急CSCF(E−CSCF)に緊急呼はルーティングされる。E−CSCFは、緊急呼のみを処理するために接続される。E−CSCFは、最も適切な公共安全応答ポイント(PSAP)、例えば、最も近い緊急サービス・コール・センタを決定し、緊急INVITEメッセージをPSAPに転送しなければならない。E−CSCFは、発呼しているUEの位置の決定を可能にする位置読み出し機能(LRF)にアタッチされる。
【0007】
ある状況において、S−CSCF経由で緊急呼をルーティングすることが必要であるかもしれない。これは、例えば、登録時、P−CSCFとUEとの間にセキュリティ・アソシエーションが確立されず、地域の緊急機関が認証されていない緊急呼を受け入れない場合である。これは、3GPP TSG−SA WG2 S2−095075で議論されている。セキュリティ・アソシエーションがないところでは、S−CSCFは、各やり取りのための、SIPダイジェスト認証を実行する。緊急セッションは、よって、UEのクレデンシャルを尋ねるS−CSCF経由で送信される。緊急呼がS−CSCF経由でルーティングされ得る他のシナリオは、S−CSCF又はASが更なる電話番号分析を実行することが必要な場合である。自身の緊急応答手順を有する大きな企業がその例である。この場合、企業は、112の様な公的な緊急電話番号への呼を、適切なPSAPにコンタクトする前に、自身の緊急センタにルーティングすることを選択するかもしれない。
【発明の概要】
【発明が解決しようとする課題】
【0008】
P−CSCFと共にセキュリティ・アソシエーションが確立しないUEの動作を可能にするこの解決策は、多くのネットワークの場合において動作する。しかしながら、固定及び移動ユーザの両方を扱うネットワークを使用する移動ユーザにとって、E−CSCFへの直接ルーティングが、特に、ユーザがローミングしている場合に(部分的には、義務及び責任の問題により)必要であるので、その様なネットワークでは、前記解決策は動作しないかもしれない。さらに、S−CSCF経由の緊急セッションのルーティングは、追加のプロキシ・ノードがパス内に必要であり、多くのユーザが緊急サービスへのアクセスを試みると(P−CSCFより多くのユーザに通常サービス提供するので)、緊急状態の間に過負荷となってボトルネックとなり得るので、既に認証された固定アクセス・ユーザの場合には最適ではない。
【0009】
本発明の目的は、ユーザ装置(UE)がプロキシ呼/セッション制御機能(P−CSCF)と共にセキュリティ・アソシエーションを確立しないIPマルチメディア・サブシステム・ネットワークにおいて緊急シグナリングの処理を改善することである。
【課題を解決するための手段】
【0010】
本発明の第1の側面によると、IPマルチメディア・サブシステム(IMS)ネットワークにおいて緊急シグナリングを処理する方法が提供される。プロキシ呼セッション制御機能(P−CSCF)は、セッションの設定を要求するメッセージを受信する。このメッセージは、IPマルチメディア・プライベート識別子(IMPI)に関連する。P−CSCFは、メッセージが緊急呼に関連するかを判定する。IMPIに関連する緊急オーバライド・タグがP−CSCFに提供又は設定されている場合、メッセージは、更なる処理のため、サービング呼セッション制御機能(S−CSCF)にSIPメッセージを転送する。IMPIに関連する緊急オーバライド・タグがP−CSCFに提供又は設定されていない場合、メッセージは、緊急呼セッション制御機能(E−CSCF)に転送される。本発明は、UEがP−CSCFとセキュリティ・アソシエーションを確立していない場合、自動的にS−CSCFにシグナリングを転送するのではなく、P−CSCFが、緊急シグナリングの処理のある程度の制御を行うことを可能にする。
【0011】
オプションとして、IMPIが所定のアクセス・ネットワーク、所定のアクセス・ネットワーク種別(例えば、固定ライン・アクセス・ネットワーク)、所定の認証方法(例えば、ダイジェスト認証)及び訪問先ネットワークに位置していないユーザ装置のいずれか1つに関連する場合、緊急オーバライド・タグが提供又は設定される。
【0012】
更なるオプションとして、IMPIのための緊急オーバライド・タグは、SIP 200 OKメッセージ及びSIP通知メッセージのいずれかで、S−CSCFから受信する。
【0013】
本発明の第2の側面によると、IMSネットワークにおいて使用されるP−CSCFが提供される。受信機は、IMPIに関連し、セッションの設定を要求するメッセージを受信するために設けられる。判定機能部は、メッセージが緊急呼に関連するかを判定するために設けられ、緊急オーバライド・タグ機能部は、P−CSCFにIMPIに関連する緊急オーバライド・タグが提供又は設定されているかを判定するために設けられる。送信機も設けられる。P−CSCFにIMPIに関連する緊急オーバライド・タグが提供又は設定されていると判定されると、送信機は、更なる処理のためにメッセージをS−CSCFに転送する様に構成される。P−CSCFにIMPIに関連する緊急オーバライド・タグが提供又は設定されていないと判定されると、送信機は、メッセージをE−CSCFに転送する様に構成される。
【0014】
オプションとして、受信機は、SIP 200 OKメッセージ及びSIP通知メッセージのいずれかで、S−CSCFから、登録されたIMPIのための緊急オーバライド・タグを受信する様に構成されている。
【0015】
本発明の第3の側面によると、IMSネットワークにおいて使用されるS−CSCFが提供される。第1の受信機は、IMPIに関連する登録要求を、P−CSCFから受信するために設けられる。第1の送信機は、ホーム加入者サーバ(HSS)に、問い合わせを送信するために設けられる。問い合わせは、IMPIに関連し、HSSに保存されている緊急オーバライド・タグを要求するものである。第2の受信機は、IMPIに関連する緊急オーバライド・タグを含む問い合わせに対する応答を受信するために設けられる。第2の送信機は、IMPIに関連する緊急オーバライド・タグを含むメッセージを、P−CSCFに送信するために設けられる。
【0016】
オプションとして、P−CSCFに送信されるメッセージは、登録要求及びユーザ・データの読み出し要求のいずれか1つに応答して送信される。
【0017】
本発明の第4の側面によると、IMSネットワークにおいて使用されるHSSが提供される。HSSは、IMPIに関連し、緊急シグナリングをどこにルーティングするかを判定するためにP−CSCFが使用する緊急オーバライド・タグを保存するメモリを備えている。受信機は、S−CSCFから、緊急オーバライド・タグを要求する問い合わせを受信するために設けられる。送信機は、緊急オーバライド・タグを含む応答を、S−CSCFに送信するために設けられる。
【0018】
本発明の第5の側面によると、P−CSCFで実行されると、P−CSCFを上述した本発明の第2の側面のP−CSCFとして動作させるコンピュータ可読コードを含むコンピュータ・プログラムが提供される。
【0019】
本発明の第6の側面によると、S−CSCFで実行されると、S−CSCFを上述した本発明の第3の側面のS−CSCFとして動作させるコンピュータ可読コードを含むコンピュータ・プログラムが提供される。
【0020】
本発明の第7の側面によると、HSSで実行されると、HSSを上述した本発明の第4の側面のHSSとして動作させるコンピュータ可読コードを含むコンピュータ・プログラムが提供される。
【0021】
本発明の第8の側面によると、上述した本発明の第5、6又は7の側面のコンピュータ・プログラムを含むコンピュータ可読記録媒体が提供される。
【図面の簡単な説明】
【0022】
【図1】汎用パケット無線サービス(GPRS)アクセス・ネットワークの移動ネットワーク・アーキテクチャに関するIMSネットワークの概略的なブロック図。
【図2】本発明の一実施形態によるホーム加入者サーバへのP−CSCF緊急オーバライド・タグのプロビジョニングを示す信号ダイアグラム。
【図3】プライベート識別子に関連する緊急オーバライド・タグとユーザ加入の例を示すブロック図。
【図4】本発明の一実施形態による登録処理を示す信号ダイアグラム。
【図5】本発明の一実施形態による呼開始処理を示す信号ダイアグラム。
【図6】本発明の一実施形態によるプロキシ呼セッション制御機能の概略的なブロック図。
【図7】本発明の一実施形態によるサービング呼セッション制御機能の概略的なブロック図。
【図8】本発明の一実施形態によるホーム加入者サーバの概略的なブロック図。
【発明を実施するための形態】
【0023】
インジケータは、ユーザ・アカウントと関連付けられ、ホーム加入者サーバ(HSS)に用意される。その後、インジケータは、プロキシ呼セッション制御機能(P−CSCF)に提供され、P−CSCFは、緊急シグナリングをどこにルーティングするかを決定するために使用される。インジケータは、以下では、緊急オーバライド・タグとして参照する。図2によると、プロビジョニング・システム8は、緊急オーバライド・タグを提供するためにHSS9にメッセージを送信する(S1)。HSS9は、肯定応答を行う(S2)。
【0024】
図3によると、本例の緊急オーバライド・タグは、HSS9に提供されるIPマルチメディア・プライベート識別子(IMPI)と関連付けられる。緊急オーバライド・タグは、プライベート・ユーザ識別子1のみに関連付けられるのではなく、使用される認証方法の種別にさらに関連付けられ得る。例えば、IMPI1は、ダイジェスト認証と、IMS認証及び鍵生成(AKA)の両方の秘密値で提供されるのであれば、緊急オーバライド・タグは、ダイジェスト認証法が使用される場所にのみ設定することができる。
【0025】
図4によると、ユーザ装置(UE)10と、P−CSCF11と、サービング呼セッション制御機能(S−CSCF)12と、HSS9と、アプリケーション・サーバ13とが示されている。UE10の登録の間、図4の番号に対応する以下の番号のステップが実行される。
【0026】
S3.UE10は、P−CSCF11に登録要求を送信する。これは、緊急登録と非緊急登録の両方で同じである。
【0027】
S4.P−CSCFは、S−CSCF12に登録要求を転送する。
【0028】
S5.S−CSCFは、Cxインタフェース経由でUE10のユーザに関してHSS9に問い合わせを送信する。
【0029】
S6.HSS9は、Cxインタフェース経由で質問に応答し、応答は、緊急オーバライド・タグを含んでいる。緊急オーバライド・タグは、ユーザ登録の間、S−CSCFで保存される。
【0030】
緊急オーバライド・タグは、登録応答(200 OK)メッセージ(ステップS7及びS9参照)、或いは、P−CSCF11がS−CSCF12からユーザ・データを読み出すイベントで送られる通知メッセージの部分(ステップS10及びS11参照)のいずれかで、P−CSCF11に送信され得る。
【0031】
S7.第1の置換形態として、S−CSCF12は、緊急オーバライド・タグをSIP 200 OKメッセージに追加し、登録メッセージ(ステップS4で送信)への応答としてP−CSCF11にSIP 200 OKメッセージを送信する。P−CSCFは、その後、緊急オーバライド・タグを保存し、SIP 200 OKメッセージから緊急オーバライド・タグを除去する。処理はステップS9へと続く。
【0032】
S8.第2の置換形態として、S−CSCF12は、登録メッセージ(ステップS4で送信)への応答としてP−CSCF11にSIP 200 OKメッセージを送信する。
【0033】
S9.SIP 200 OKメッセージは、P−CSCF11からUE10に送信される。
【0034】
S10.第2の置換形態として、P−CSCF11は、ユーザ・データを読み出すために、読み出し要求をS−CSCF12に送信する。
【0035】
S11.S−CSCF12は緊急オーバライド・タグを保存しているので、緊急オーバライド・タグを通知メッセージに含めて、P−CSCF11にその通知メッセージを送信する。
【0036】
第1の置換形態と第2の置換形態のどちらが使用されたかに拘らず、P−CSCFには緊急オーバライド・タグが提供される。
【0037】
S−CSCF12とHSS9の間のCxインタフェースは、S−CSCF12がHSS9に緊急オーバライド・タグを要求できる様に拡張されなければならない。例えば、新しい属性/値ペア(AVP)が提供され得る。適切なAVPのフォーマット例は、以下の通りである。
【0038】
AVPフォーマット
Emergency−Data−Item::=<AVP Header:1234567>
[緊急オーバライド]
【0039】
新しいAVPを導入する代わりに、緊急オーバライド・パラメータを、ユーザ・データAVPの様な既存AVPに含めることもできる。
【0040】
UEが呼を開始し、その呼が、例えば112といったIMS緊急に関連するURIに向けられている場合、P−CSCFは、当該呼を、S−CSCF12又はE−CSCF14に送信すべきか否かを決定しなければならない。図5に呼シグナリングを示し、以下の番号は、図5の番号に対応する。
【0041】
S12.UE10は、緊急呼を設定するためにSIP INVITEをP−CSCF11に送信する。
【0042】
S13.P−CSCF11は、SIP INVITEが緊急呼に関連するかを決定する。これは、例えば、緊急サービスに関するURI及び電話番号をP−CSCFに用意しておくことで行われ得る。呼が緊急呼である場合、P−CSCFは、緊急オーバライド・タグが存在する、或いは、設定されているか否かを判定する。存在しない、或いは、設定されていない場合、処理はステップS18に進む。IMPIに関連する緊急オーバライド・タグが存在又は設定されている場合、処理はS14に進む。
【0043】
S14.SIP INVITEは、P−CSCF11からS−CSCF12に転送される。S−CSCF12は、その後、必要に応じて、SIPダイジェスト認証を実行できる。このステップは、次のステップに移る前に、ユーザにチャレンジを送信する(図示せず)。
【0044】
S15.例えば、企業でのサービスの場合の様に、呼が緊急呼であるかを判定するためにASによる更なる電話番号の分析が必要であれば、SIP INVITEはS−CSCF12からAS13に転送される。
【0045】
S16.AS13は、電話番号が緊急センタにルーティングされるべき緊急番号であるかのルーティング決定を行う。AS13は、緊急番号であると決定すると、要求をS−CSCF12に転送する。
【0046】
S17.SIPダイジェスト認証が完了、或いは、AS呼び出しが完了すると、SIP INVITEは、その後、S−CSCF12からE−CSCFへとルーティングされる。処理は、ステップS19に進む。
【0047】
S18.緊急オーバライド・タグが存在しない、或いは、設定されていない場合、P−CSCFはSIP INVITEをE−CSCF14に転送する。
【0048】
S19.E−CSCFはPSAP(図示せず)を選択し、SIP INVITEを選択したPSAPに転送する。
【0049】
本発明は、IMPIに関連する緊急オーバライド・タグをHSSに提供することを可能にする。これは、P−CSCFが行う、緊急呼をE−CSCFに直接ルーティングするか、S−CSCF経由でルーティングするかに関する決定に役立たせるため、P−CSCFに送られる。これは、UEが固定及び移動アクセスの両方を処理するネットワークに位置する場合に特に役に立つ。従来技術の方法を利用するその様なネットワークは、総ての緊急呼をS−CSCF経由でルーティングするが、これは、UEが認証された固定ライン・アクセス・ネットワークを使用する場合には不必要である。さらに、移動UEがS−CSCFが配置されるホーム・ネットワークとは異なるネットワークにローミングしている場合には、ある国の緊急呼により、他の(ホーム)国のネットワークが影響を受けることを防ぐために、緊急呼は理想的にはその国内で局所的にルーティングされるべきであるので、S−CSCF経由での緊急呼は望ましくない。緊急オーバライド・タグは、IMPIが固定ライン・アクセスに関連されている場合や、UEがホーム・ネットワークにいない場合には、緊急呼がS−CSCF経由でルーティングされないことを確実にするためにセットされ得る。
【0050】
図6によると、P−CSCF11は、ステップS12で述べた様に、SIP INVITEの様なセッション設定メッセージを受信する受信機15と共に設けられる。受信機15は、ステップS7及びS11でそれぞれ述べた様に、SIP 200 OKメッセージ、或いは、SIP通知メッセージで、S−CSCF12から緊急オーバライド・タグを受信する様にも構成され得る。もちろん、これは、P−CSCF11の異なる受信機(図示せず)でも実行され得る。
【0051】
緊急呼判定機能16は、例えば、セッション設定メッセージに含まれるURIを緊急サービスに関連する公知のURIのリストと比較することにより、緊急呼に関連するセッション設定メッセージを判定するために設けられる。
【0052】
緊急オーバライド機能17は、IPマルチメディア・プライベート識別子に関連する緊急オーバライド・タグ18がP−CSCF11に提供又は設定されているかを判定するために設けられる。緊急オーバライド・タグ18は、典型的には、メモリ19に保存される。
【0053】
送信機20は、セッション設定メッセージを、緊急オーバライド・タグ18が提供又は設定されている場合にはS−CSCF12に、緊急オーバライド・タグ18が提供も設定もされていない場合にはE−CSCF14に転送するために設けられる。
【0054】
受信機及び送信機の異なる構成が利用できることが理解される。例えば、上記総ての受信機及び送信機は、単一の送受信機として実装され得る。
【0055】
P−CSCF11の上記記載は、本発明のハードウェアによる実装を想定しているが、当業者は、例えば、緊急呼判定機能16及び緊急オーバライド機能17の様な構成要素を、ソフトウェアを用いて実装できることを理解する。この場合、メモリ19はコンピュータ・プログラム21が保存されるコンピュータ可読媒体であり、プロセッサ22がコンピュータ・プログラムを実行するために設けられる。
【0056】
図7によると、S−CSCF12には、ステップS4で述べた様に、P−CSCF11から登録要求を受信する第1の受信機23が設けられる。第1の送信機24は、ステップS5で述べた様に、HSSPにCx問い合わせを送信するために設けられる。第2の受信機25は、ステップS6で述べた様に、Cx応答を受信するために設けられる。第2の送信機26は、緊急オーバライド・タグ18を含むメッセージをP−CSCF11に送信するために設けられる。メッセージは、登録要求又はユーザ・データの1つに応答してP−CSCF11に送信される。プロセッサ27は、信号を処理するために設けられ、メモリ28は、緊急オーバライド・タグ18を保存するために設けられる。
【0057】
受信機及び送信機の異なる構成が利用できることが理解される。例えば、上記総ての受信機及び送信機は、単一の送受信機として実装され得る。
【0058】
S−CSCF12の上記記載は、本発明のハードウェアによる実装を想定しているが、当業者は、信号を処理する命令の様な構成要素を、ソフトウェアを用いて実装できることを理解する。この場合、メモリ28はコンピュータ・プログラム29を保存するコンピュータ可読媒体であり、プロセッサ27がコンピュータ・プログラムを実行する。
【0059】
図8は、IMPI31に関連付けられた緊急オーバライド・タグ18を保存するメモリを設けたHSS9を示している。もちろん、メモリは多くのユーザのIMPI及び緊急オーバライド・タグを保存し得る。受信機32は、ステップS5で述べた様に、S−CSCF12からCx問い合わせを受信するために設けられ、送信機33は、要求されたタグ18でCx問い合わせに応答するために設けられる。プロセッサ34は、信号を処理し、メモリ30から要求された情報を得るために設けられる。
【0060】
HSS9の上記記載は、本発明のハードウェアによる実装を想定しているが、当業者は、ある構成要素を、ソフトウェアを用いて実装できることを理解する。この場合、メモリ30はコンピュータ・プログラム35を保存するコンピュータ可読媒体であり、プロセッサ34がコンピュータ・プログラムを実行する。当業者は、HSS9の異なる物理メモリに異なる情報を保存できることを理解する。
【0061】
当業者は、添付の特許請求の範囲で定義する発明の範囲から逸脱することなく、上記実施形態に様々な修正を行うことを理解する。
【0062】
本明細書において以下の略語を使用した。
3GPP 第3世代パートナーシップ・プロジェクト
AS アプリケーション・サーバ
AVP 属性−値ペア
E−CSCF 緊急呼セッション制御機能
GGSN ゲートウェイGPRSサポート・ノード
GPRS 汎用パケット無線サービス
GSN GPRSサポート・ノード
HSS ホーム加入者サーバ
I−CSCF インタロゲーティング呼セッション制御機能
IMPI IPマルチメディア・プライベート識別子
IMS IPマルチメディア・サブシステム
LRF 位置読み出し機能
P−CSCF プロキシ呼セッション制御機能
PSAP 公共安全応答ポイント
S−CSCF サービング呼セッション制御機能
SDP セッション記述プロトコル
SIP セッション開始プロトコル
UE ユーザ装置

【特許請求の範囲】
【請求項1】
IPマルチメディア・サブシステム・ネットワークにおいて緊急シグナリングを処理する方法であって、
プロキシ呼セッション制御機能で、IPマルチメディア・プライベート識別子に関連し、セッションの設定を要求するメッセージを受信するステップと、
前記プロキシ呼セッション制御機能で、前記メッセージが緊急呼に関連するかを判定するステップと、
前記プロキシ呼セッション制御機能に前記IPマルチメディア・プライベート識別子に関連する緊急オーバライド・タグが提供又は設定されている場合、更なる処理のために前記SIPメッセージをサービング呼セッション制御機能に転送するステップと、
前記プロキシ呼セッション制御機能に前記IPマルチメディア・プライベート識別子に関連する緊急オーバライド・タグが提供又は設定されていない場合、前記メッセージを緊急呼セッション制御機能に転送するステップと、
を含むことを特徴とする方法。
【請求項2】
前記IPマルチメディア・プライベート識別子が、所定のアクセス・ネットワーク、所定のアクセス・ネットワーク種別、所定の認証方法及び訪問先ネットワークに位置していないユーザ装置のいずれか1つに関連する場合、前記緊急オーバライド・タグが提供又は設定される、
ことを特徴とする請求項1に記載の方法。
【請求項3】
セッションの設定を要求する前記メッセージを受信する前に、SIP 200 OKメッセージ及びSIP通知メッセージのいずれかで、サービング呼セッション制御機能から、登録された前記IPマルチメディア・プライベート識別子のための緊急オーバライド・タグを受信するステップをさらに含む、
ことを特徴とる請求項1又は2に記載の方法。
【請求項4】
IPマルチメディア・サブシステム・ネットワークにおいて使用されるプロキシ呼セッション制御機能であって、
IPマルチメディア・プライベート識別子に関連し、セッションの設定を要求するメッセージを受信する受信機と、
前記メッセージが緊急呼に関連するかを判定する判定機能部と、
前記プロキシ呼セッション制御機能に前記IPマルチメディア・プライベート識別子に関連する緊急オーバライド・タグが提供又は設定されているかを判定する緊急オーバライド機能部と、
前記プロキシ呼セッション制御機能に前記IPマルチメディア・プライベート識別子に関連する緊急オーバライド・タグが提供又は設定されていると判定されると、更なる処理のために前記メッセージをサービング呼セッション制御機能に転送し、前記プロキシ呼セッション制御機能に前記IPマルチメディア・プライベート識別子に関連する緊急オーバライド・タグが提供又は設定されていないと判定されると、前記メッセージを緊急呼セッション制御機能に転送する送信機と、
を備えていることを特徴とするプロキシ呼セッション制御機能。
【請求項5】
前記受信機は、SIP 200 OKメッセージ及びSIP通知メッセージのいずれかで、サービング呼セッション制御機能から、登録された前記IPマルチメディア・プライベート識別子のための緊急オーバライド・タグを受信する様に構成されている、
ことを特徴とする請求項4に記載のプロキシ呼セッション制御機能。
【請求項6】
IPマルチメディア・サブシステム・ネットワークにおいて使用されるサービング呼セッション制御機能であって、
IPマルチメディア・プライベート識別子に関連する登録要求を、プロキシ呼セッション制御機能から受信する第1の受信機と、
前記IPマルチメディア・プライベート識別子に関連し、ホーム加入者サーバに保存されている緊急オーバライド・タグを要求する問い合わせを、前記ホーム加入者サーバに送信する第1の送信機と、
前記IPマルチメディア・プライベート識別子に関連する前記緊急オーバライド・タグを含む前記問い合わせに対する応答を受信する第2の受信機と、
前記IPマルチメディア・プライベート識別子に関連する前記緊急オーバライド・タグを含むメッセージを、前記プロキシ呼セッション制御機能に送信する第2の送信機と、
を備えていることを特徴とするサービング呼セッション制御機能。
【請求項7】
前記プロキシ呼セッション制御機能に送信される前記メッセージは、登録要求及びユーザ・データの読み出し要求のいずれか1つに応答して送信される、
ことを特徴とする請求項6に記載のサービング呼セッション制御機能。
【請求項8】
IPマルチメディア・サブシステム・ネットワークにおいて使用されるホーム加入者サーバであって、
IPマルチメディア・プライベート識別子に関連し、緊急シグナリングをどこにルーティングするかを判定するためにプロキシ呼セッション制御機能が使用する緊急オーバライド・タグを保存するメモリと、
サービング呼セッション制御機能から、前記緊急オーバライド・タグを要求する問い合わせを受信する受信機と、
前記緊急オーバライド・タグを含む応答を、前記サービング呼セッション制御機能に送信する送信機と、
を備えていることを特徴とするホーム加入者サーバ。
【請求項9】
プロキシ呼セッション制御機能で実行されると、前記プロキシ呼セッション制御機能を請求項4又は5に記載のプロキシ呼セッション制御機能として動作させるコンピュータ可読コードを含むことを特徴とするコンピュータ・プログラム。
【請求項10】
サービング呼セッション制御機能で実行されると、前記サービング呼セッション制御機能を請求項5又は6に記載のサービング呼セッション制御機能として動作させるコンピュータ可読コードを含むことを特徴とするコンピュータ・プログラム。
【請求項11】
ホーム加入者サーバで実行されると、前記ホーム加入者サーバを請求項7に記載のホーム加入者サーバとして動作させるコンピュータ可読コードを含むことを特徴とするコンピュータ・プログラム。
【請求項12】
請求項9から11のいずれか1項に記載のコンピュータ・プログラムを保存していることを特徴とするコンピュータ可読記録媒体。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate


【公表番号】特表2013−509757(P2013−509757A)
【公表日】平成25年3月14日(2013.3.14)
【国際特許分類】
【出願番号】特願2012−535637(P2012−535637)
【出願日】平成21年11月2日(2009.11.2)
【国際出願番号】PCT/EP2009/064463
【国際公開番号】WO2011/050861
【国際公開日】平成23年5月5日(2011.5.5)
【出願人】(598036300)テレフオンアクチーボラゲット エル エム エリクソン(パブル) (2,266)
【Fターム(参考)】