(57)【要約】【課題】Ｐ−ＣＳＣＦ復旧は加入者用のネットワークノードの能力を考慮することなく実行され、且つ、着信セッション要求がコアネットワークノードに到着しているときにしか新たなＰ−ＣＳＣＦを決定しない。このため、Ｐ−ＣＳＣＦ復旧に時間がかかるという課題があった。【解決手段】Ｐ−ＣＦＣＦ復旧をサポートしているかどうか示すサポート情報を送信するコアネットワークノードと、当該サポート情報を識別する加入者用のネットワークノードを含む通信システム及び方法が提案される。当該通信システムに用いられるコアネットワークノード及び加入者用のネットワークノードも提案される。【選択図】図２
2020145731.tif 000002
【特許請求の範囲】
【請求項１】
加入者データ用のネットワークノードによって実行される、プロキシコールセッション制御機能(Proxy Call Session Control Function：Ｐ−ＣＳＣＦ)復旧(P-CSCF restoration)を容易にする方法であって、
コアネットワークノードから、当該コアネットワークノードが前記Ｐ−ＣＳＣＦ復旧をサポートしていることを示すためのサポート情報を含むUpdate Location Request (ULR)を受信し、
前記サポート情報を含む前記ULRを受信したのちに、Ｐ−ＣＳＣＦ復旧指示子(restoration indication)を受信した場合に、当該コアネットワークノードへ前記Ｐ−ＣＳＣＦ復旧指示子を送信する、方法。
【請求項２】
前記ULRはAttach手続、Routing Area Update手続、およびTracking Area Update手続の少なくともいずれかの際に送信される、請求項１に記載の方法。
【請求項３】
前記コアネットワークノードはMobility Management Entity (MME)又はServing General Packet Radio Service (GPRS) Support Node (SGSN)のいずれかを含む、請求項１又は２に記載の方法。
【請求項４】
複数の前記コアネットワークノードを備える通信システムに適用され、コアネットワークノードごとに前記サポート情報を記憶する、請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
コアネットワークノードによって実行される、プロキシコールセッション制御機能(Proxy Call Session Control Function：Ｐ−ＣＳＣＦ)復旧(P-CSCF restoration)を容易にする方法であって、
前記コアネットワークノードが前記Ｐ−ＣＳＣＦ復旧をサポートしている場合に前記Ｐ−ＣＳＣＦ復旧をサポートしていることを示すためのサポート情報を含むUpdate Location Request (ULR)を加入者データ用のネットワークノードに送信し、
前記サポート情報を含むULRの送信ののちにＰ−ＣＳＣＦの障害があった場合に、前記加入者データ用のネットワークノードから前記Ｐ−ＣＳＣＦ復旧指示子を受信し、
前記Ｐ−ＣＳＣＦ復旧指示子を受信したのちに、対応するユーザ機器(User Equipment：ＵＥ)のインターネットプロトコルマルチメディアサブシステム(Internet Protocol (IP) Multimedia Subsystem：ＩＭＳ)セッションを解放する、方法。
【請求項６】
前記ULRはAttach手続、Routing Area Update手続、およびTracking Area Update手続の少なくともいずれかの際に送信される、請求項５に記載の方法。
【請求項７】
前記コアネットワークノードはMobility Management Entity (MME)又はServing General Packet Radio Service (GPRS) Support Node (SGSN)のいずれかを含む、請求項５又は６に記載の方法。
【請求項８】
通信システムにおけるプロキシコールセッション制御機能(Proxy Call Session Control Function：Ｐ−ＣＳＣＦ)の障害が発生したときに、ユーザ機器(User Equipment：ＵＥ)によって実行される、Ｐ−ＣＳＣＦ復旧を容易にする方法であって、
前記通信システムのコアネットワークノードが開始する手順の一部分として、現在のインターネットプロトコルマルチメディアサブシステム(Internet Protocol (IP) Multimedia Subsystem:ＩＭＳ)セッションを解放し、当該解放することは前記コアネットワークノードから前記通信システムの加入者データ用のネットワークノードへサポート情報を含むUpdate Location Request (ULR)が送信される後にＰ−ＣＳＣＦの障害があった場合に、前記加入者データ用のネットワークノードから前記コアネットワークノードに送信されるＰ−ＣＳＣＦ復旧指示子(restoration indication)に基づいて開始されるものであり、前記サポート情報は前記コアネットワークノードが前記Ｐ−ＣＳＣＦ復旧をサポートしていることを示すためのものであり、
前記ULRは前記ＵＥからのAttach手続、Routing Area Update手続、およびTracking Area Update手続の少なくともいずれかに基づいて送信され、
前記Ｐ−ＣＳＣＦ復旧指示子(restoration indication)が送信された後に、前記ＵＥのＩＭＳへの登録のためのセッション開始プロトコル(Session InitＡiation Protocol：ＳＩＰ)メッセージを送信する、方法。
【請求項９】
通信システムにおいて実行される、インターネットプロトコルマルチメディアサブシステム(Internet Protocol (IP) Multimedia Subsystem：ＩＭＳ)の、プロキシコールセッション制御機能(Proxy Call Session Control Function：Ｐ−ＣＳＣＦ)復旧(P-CSCF restoration)を容易にする方法であって、
コアネットワークノードは、当該コアネットワークノードが前記Ｐ−ＣＳＣＦ復旧をサポートしていることを示すためのサポート情報を含むUpdate Location Request (ULR)を、加入者データ用のネットワークノードに送信し、
前記加入者データ用のネットワークノードは、前記コアネットワークノードから前記サポート情報を含む前記ULRを受信し、
前記加入者データ用のネットワークノードは、前記サポート情報を受信したのちに、Ｐ−ＣＳＣＦ復旧指示子を受信した場合に、当該コアネットワークノードへ前記Ｐ−ＣＳＣＦ復旧指示子を送信し、
前記コアネットワークノードは、前記Ｐ−ＣＳＣＦ復旧指示子(restoration indication)を受信し、
前記コアネットワークノードは、前記Ｐ−ＣＳＣＦ復旧指示子(restoration indication)を受信したのちに、対応するユーザ機器(User Equipment：ＵＥ)のインターネットプロトコルマルチメディアサブシステム(Internet Protocol (IP) Multimedia Subsystem：ＩＭＳ)セッションを解放する、方法。
【請求項１０】
プロキシコールセッション制御機能(Proxy Call Session Control Function：Ｐ−ＣＳＣＦ)復旧(P-CSCF restoration)を容易にする加入者データ用のネットワークノードであって、
コアネットワークノードから、当該コアネットワークノードが前記Ｐ−ＣＳＣＦ復旧をサポートしていることを示すためのサポート情報を含むUpdate Location Request (ULR)を受信する受信手段と、
前記サポート情報を含む前記ULRを受信したのちに、Ｐ−ＣＳＣＦ復旧指示子(restoration indication)を受信した場合に、当該コアネットワークノードへ前記Ｐ−ＣＳＣＦ復旧指示子(restoration indication)を送信する送信手段と、を備える加入者データ用のネットワークノード。
【請求項１１】
プロキシコールセッション制御機能(Proxy Call Session Control Function：Ｐ−ＣＳＣＦ)復旧(P-CSCF restoration)を容易にするコアネットワークノードであって、
前記コアネットワークノードが前記Ｐ−ＣＳＣＦ復旧をサポートしている場合に前記Ｐ−ＣＳＣＦ復旧をサポートしていることを示すためのサポート情報を含むUpdate Location Request (ULR)を加入者データ用のネットワークノードに送信する送信手段と、
前記サポート情報を含む前記ULRの送信ののちにＰ−ＣＳＣＦの障害があった場合に、前記加入者データ用のネットワークノードから前記Ｐ−ＣＳＣＦ復旧指示子(restoration indication)を受信する受信手段と、
前記Ｐ−ＣＳＣＦ復旧指示子(restoration indication)を受信したのちに、対応するユーザ機器(User Equipment：ＵＥ)のインターネットプロトコルマルチメディアサブシステム(Internet Protocol (IP) Multimedia Subsystem：ＩＭＳ)セッションを解放する、解放手段とを備える、コアネットワークノード。
【請求項１２】
通信システムにおけるプロキシコールセッション制御機能(Proxy Call Session Control Function：Ｐ−ＣＳＣＦ)の障害が発生したときにＰ−ＣＳＣＦ復旧を容易にする、ユーザ機器(User Equipment：ＵＥ)であって、
前記通信システムのコアネットワークノードが開始する手順の一部分として、現在のインターネットプロトコルマルチメディアサブシステム(Internet Protocol (IP) Multimedia Subsystem:ＩＭＳ)セッションを解放する解放手段を備え、当該解放することは前記コアネットワークノードから前記通信システムの加入者データ用のネットワークノードへサポート情報を含むUpdate Location Request (ULR)が送信される後にＰ−ＣＳＣＦの障害があった場合に、前記加入者データ用のネットワークノードから前記コアネットワークノードに送信されるＰ−ＣＳＣＦ復旧指示子(restoration indication)に基づいて開始されるものであり、前記サポート情報は前記コアネットワークノードが前記Ｐ−ＣＳＣＦ復旧をサポートしていることを示すためのものであり、
前記ULRは前記ＵＥからのAttach手続、Routing Area Update手続、およびTracking Area Update手続の少なくともいずれかに基づいて送信され、
前記Ｐ−ＣＳＣＦ復旧指示子(restoration indication)が送信された後に、前記ＵＥのＩＭＳへの登録のためのセッション開始プロトコル(Session Initiation Protocol：ＳＩＰ)メッセージを送信する送信手段を備える、ＵＥ。
【請求項１３】
インターネットプロトコルマルチメディアサブシステム(Internet Protocol (IP) Multimedia Subsystem：ＩＭＳ)の、プロキシコールセッション制御機能(Proxy Call Session Control Function：Ｐ−ＣＳＣＦ)復旧（P-CSCF restoration）を容易にする通信システムであって、
コアネットワークノードと、
加入者データ用のネットワークノードと、を備え、
前記コアネットワークノードは、当該コアネットワークノードが前記Ｐ−ＣＳＣＦ復旧をサポートしていることを示すためのサポート情報を含むUpdate Location Request (ULR)を、前記加入者データ用のネットワークノードに送信する送信手段を備え、
前記加入者データ用のネットワークノードは、
前記コアネットワークノードから前記サポート情報を含む前記ULRを受信する受信手段と、
前記サポート情報を受信したのちに、Ｐ−ＣＳＣＦ復旧指示子(restoration indication)を受信した場合に、当該コアネットワークノードへ前記Ｐ−ＣＳＣＦ復旧指示子(restoration indication)を送信する送信手段と、を備え、
前記コアネットワークノードは、
前記Ｐ−ＣＳＣＦ復旧指示子(restoration indication)を受信する受信手段と、
前記コアネットワークノードは、前記Ｐ−ＣＳＣＦ復旧指示子(restoration indication)を受信したのちに、対応するユーザ機器（User Equipment：ＵＥ）のインターネットプロトコルマルチメディアサブシステム(Internet Protocol (IP) Multimedia Subsystem：ＩＭＳ)セッションを解放する解放手段と、
を備える、通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムにおけるプロキシコールセッション制御機能（Ｐ−ＣＳＣＦ）の方法及び関連装置に関する。
【背景技術】
【０００２】
ＩＰマルチメディアサブシステム(IP Multimedia Subsystem:ＩＭＳ）は、ＩＰベースのマルチメディアサービスをＵＥが用いることを可能にするために３ＧＰＰ  ＴＳ２３．２２８によって仕様化されている。ＳＩＰ(Session Initiation Protocol)シグナリング交換がＵＥとプロキシコールセッション制御機能(Proxy-Call Session Control Function)（Ｐ−ＣＳＣＦ）との間で暗号化通信を介して行われるので、Ｐ−ＣＳＣＦは、ＵＥの観点からみればＳＩＰピアである。このため、Ｐ−ＣＳＣＦは、ＵＥセキュリティパラメーター及びＩＰセッションパラメーターを記憶している。さらに、Ｐ−ＣＳＣＦは、ＩＰセッションに必要なリソースを認可し、このＵＥの次のホップのＣＳＣＦを（登録プロセスから）想起する（remembers）。
【０００３】
本発明は、ＵＥのセキュリティパラメーター及びセッションパラメーターの喪失を意味するＰ−ＣＳＣＦの障害の問題と、Ｐ−ＣＳＣＦ復旧プロセスとを対象とする。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
現在の標準化されているＰ−ＣＳＣＦ復旧手順は、ＩＰレイヤ上でのＰ−ＧＷ(PDN-Gateway)／ＧＧＳＮ(Gateway GPRS Support Node)の監視に基づいており、ハートビートメッセージ(Heartbeat Message)に対する応答がない場合には、Ｐ−ＧＷ／ＧＧＳＮは、利用可能なＰ−ＣＳＣＦアドレスの新たなリストを、影響を受ける全てのＵＥに送信して、（代替のＰ−ＣＳＣＦへの）新たなＩＭＳ登録をトリガーする。
【０００５】
既存の解決策に関する問題
この解決策は、現在のところ、コアネットワーク及び無線ネットワークにとってシグナリングが大量になるという弱点を有する。なぜなら、Ｐ−ＧＷ／ＧＧＳＮは、障害が発生しているＰ−ＣＳＣＦに現在登録されているあらゆるＵＥにアドレス指定された利用可能なＰ−ＣＳＣＦの新たなリストを更新しなければならないからである。加えて、その後、ＩＭＳ再登録の試みが、影響を受けるあらゆるＵＥによって行われる。
【０００６】
現在の解決策は、十分に信頼できるものではない。なぜなら、Ｐ−ＣＳＣＦの部分的障害（すなわち、あるユーザ群についてのみの障害）の場合、Ｐ−ＣＳＣＦは、Ｐ−ＧＷ／ＧＧＳＮによって利用可能であるように見える場合があり、したがって、復旧メカニズムが実行されず、影響を受けるユーザの着信呼が失敗する。他方、（一時的な）ネットワーク問題によって、Ｐ−ＣＳＣＦがダウンしたものとＰ−ＧＷ／ＧＧＳＮが推測し、それによって、復旧手順を不必要にトリガーする場合がある。
【０００７】
この問題は、３ＧＰＰ  ＣＴ４ワーキンググループに寄稿された文書Ｃ４−１３１２７７において既に調査されており、一変形形態に関する解決策がこの文書に記載されている。この提案は、図１に示されている。
【０００８】
Ｐ−ＣＳＣＦ復旧の方法及びシステム
この解決策は、新たなＰ−ＣＳＣＦの決定が、着信セッション要求（terminating session request）がＳ−ＣＳＣＦ(Serving-Call Session Control Function)に到着しているときにしか実行されず、以前のＰ−ＣＳＣＦに達することができないか又は以前のＰ−ＣＳＣＦがエラーコードを送信するという点で「事後対応的」(re-active)である。このエラーコードは、その後、ＩＭＳ  ＰＤＮ(Packet Data Network)解放をＨＳＳ(Home Subscriber Server)に要求しているアプリケーションサーバー（ＡＳ）に提供され、更にＭＭＥ(Mobility Management Entity／ＳＧＳＮ(Serving GPRS Support Node)を介してＵＥに提供される。そのため、次のステップにおいて、ＵＥは、新たなＰ−ＣＳＣＦの選択とともにＩＭＳに登録することができる。
【０００９】
この「事後対応的」(re-active)解決策は、着信呼／接続確立に大きな遅延をもたらす。この解決策の別の考慮すべき影響は、ＨＳＳ(Home Subscriber Server)／ＨＬＲ(Home Location Register) エンティティを拡張する必要があることであり、ＨＳＳ／ＨＬＲとＭＭＥとの間のインターフェースが高度化されるべきである。
【図面の簡単な説明】
【００１０】
【図１】Ｃ４−１３１２７７で提案されている解決案を示す図である。
【図２】３ＧＰＰ  ＴＳ２３．４０１に従ったアタッチ手順を示している。
【図３】本発明の実施例において、ＰＣＲＦによるＰ−ＣＳＣＦ障害を検出した場合の動作を示す図である。
【図４】本発明の実施例において、ＶＰＬＭＮ(Visited Public Land Mobile Network)内のＡＴＣＦ(Access Transfer Control Function)によって、Ｐ−ＣＳＣＦ障害を検出した場合の動作を示す図である。
【図５】本発明の実施例において、ＶＰＬＭＮ内のＡＴＣＦ及びＥＰＳ(Evolved Packet Switch System)によってＰ−ＣＳＣＦ障害を検出した場合の動作を示す図である。
【図６】本発明の実施例において、ＶＰＬＭＮ内のＡＴＣＦ＋ＭＭＥによってＰ−ＣＳＣＦ障害を検出した場合の動作を示す図である。
【発明を実施するための形態】
【００１１】
実施形態を用いた本発明の説明
可能な解決策
１つの可能な解決策は、以下に説明するように、図１に示す従来技術の解決策の拡張に基づいている。
【００１２】
図１に提案された解決策は、ＩＭＳ  ＰＤＮ解放要求メッセージ（メッセージ番号７に示す）がＭＭＥによってサポートされていない場合を考慮していない。現在の仕様では、ＨＳＳは、特定のＰＤＮ接続の解放を送信することが可能でない。ＨＳＳは、例えば、加入者との新たな契約に起因して加入状況が変化した場合にＭＭＥに更新を送信するだけである。
【００１３】
これは、ＨＳＳにおいて更なる情報を伴うことなく適用されると、その結果、所望の挙動が得られないことになる。上記状況は、特にローミングの場合、すなわち、Ｓ−ＣＳＣＦがホームネットワークに位置している一方、ＭＭＥが在圏ネットワークに位置しているときに起こる可能性がある。この場合、ＭＭＥによるサポートがないことに起因して、ＨＳＳが、この解決策が機能するか否かを知る方法はない。ＨＳＳがＭＭＥ能力を知らないことは、大きな欠点である。なぜならば、ホームオペレーターは、ＳＩＰエラーコードを発呼側に応答すること以外に何らの動作も取ることができないからである。ＨＳＳが、関連付けられたＭＭＥの能力を事前に知っている場合、ホームオペレーターは、着信するＩＭＳ呼の発呼側にＳＩＰエラーコードを応答する以外の代替の手法を取ることができる。例えば、ホームオペレーターは、未登録ユーザ処理をアクティブ化することができる。例えば、着信するＩＭＳ呼をボイスメールシステムにリダイレクトすることができる。
【００１４】
この理由から、ＭＭＥは、上述した手順をサポートするその能力を、能力情報（capability indication）を用いてアタッチ時及びその後の任意のＭＭＥ移動イベント時、すなわち、ＴＡＵ(Tracking Area Update)更新手順又はＲＡＵ(Routing Area Update)更新手順時に示さなければならない。図２は、以下の追加事項を有する３ＧＰＰ  ＴＳ２３．４０１に従ったアタッチ手順を示している。
【００１５】
ステップ４及びステップ５に示すようなメッセージ交換も、ＴＡＵ更新手順及び／又はＲＡＵ更新手順に適用可能である。
【００１６】
ステップ４において、ＭＭＥがＵｐｄａｔｅ  Ｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔを送信するとき、この要求は、ＨＳＳに向けてそのＰ−ＣＳＣＦ障害能力を示すフラグを含むものとする。ＭＭＥは、在圏ネットワークに位置している場合があり、ＵＥ単位でこの能力を送信することができる。
【００１７】
最適化において、ＨＳＳが、ＵＥ単位だけでなく、ＭＭＥごとにもＭＭＥ能力を記憶することをサポートしている場合、ＭＭＥの能力は、時々ＨＳＳにおいてリフレッシュされていればよい。その理由から、ＨＳＳは、Ｕｐｄａｔｅ  Ｌｏｃａｔｉｏｎ  ＡＣＫにＭＭＥフラグごとのＰ−ＣＳＣＦ障害能力を含めることでこの能力を示す。その場合、ＭＭＥは、アタッチ時ごとに又は再配置時ごとにＵＥごとにフラグをＨＳＳに送信する必要がないことを知る。ＭＭＥは、その場合でも、能力情報を随時送信して、ＨＳＳにおいてリフレッシュすることができる。これは、構成された複数のＵＥインターラクション、例えば、ＭＭＥへの１００×アタッチ、５０×ＭＭＥ再配置等に基づいて、又は時刻に基づいて、例えば、１日に１つのアタッチにつき１回行うことができる。
【００１８】
ＨＳＳがＭＭＥ能力を理解すると、この情報は、現在、そのようなＭＭＥ又はＳＧＳＮに属するＵＥ用に、関連付けられたＡＳ又はＳ−ＣＳＣＦに更に転送することができる。その後、関連付けられたＡＳ又はＳ−ＣＳＣＦは、関連付けられたＰ−ＣＳＣＦが障害を起こしているように見える場合、着信するＩＭＳ呼の発呼側にＳＩＰエラーコードを応答する以外の代替動作を取ることができる。
【００１９】
１つの実施形態では、ＨＳＳは、ＴＳ２３．４０１の図５．３．９．２−１に示すような「加入者データ挿入」手順を用いて、（対応するＡＰＮを許可しないことによって）ＩＭＳのＰＤＮ接続を取り消す（withdraw）。その後、ＵＥがＥＣＭ  ＩＤＬＥ状態にあるとともに、ＩＳＲがアクティブ化されておらず、かつ、加入変更がＰＤＮ接続をもはや許可しない場合、ＴＳ２３．４０１の５．１０．３節におけるＭＭＥ側開始ＰＤＮ切断手順（MME initiated PDN disconnection procedure）が用いられて、関係するＰＤＮ接続が削除される。ＵＥがＥＣＭ  ＩＤＬＥ状態にあるとともに、ＩＳＲがアクティブ化されている場合、この手順は、次のＥＣＭ  ＩＤＬＥからＥＣＭ  ＣＯＮＮＥＣＴＥＤへの遷移時に起動される。
【００２０】
ＴＳ２３．４０１の図５．１０．３−１のステップ１ｂに記載されているように、ＭＭＥは、ＰＤＮ接続を解放することを決定する。ＨＳＳは、その後、ＩＭＳ  ＡＰＮが再び許可されることを示す新たな「加入者データ挿入」を（短い、設定可能なオフセットタイマーを用いて）発行する。このようにして、ＵＥは、ＩＭＳ  ＰＤＮ接続を再確立するようにトリガーされる。
【００２１】
要約すれば、上記可能な解決策（図１の従来技術の提案された高度化）は、ＭＭＥ及びＨＳＳがＰ−ＳＣＳＦ障害能力についての情報を交換する解決策を示している。
【００２２】
第１の高度化は、Ｐ−ＣＳＣＦ障害シナリオをサポートするＭＭＥの能力を交換することを提案している。ＭＭＥがこれをサポートしておらず、ＨＳＳがＩＭＳ  ＰＤＮ解放要求を送信する場合、これは単に廃棄され、ＭＴセッションは或る時点でタイムアウトする。
【００２３】
第２の高度化は、ＨＳＳからＭＭＥに向けた加入者データ挿入（InsertSubscriberData）においてＩＭＳ  ＡＰＮを非アクティブ化して、ＩＭＳベアラをＵＥに強制的に解放させ、次いで、ＭＭＥに向けたＩＭＳ  ＡＰＮを再びアクティブ化させ、その結果、ＭＭＥが、ネットワークトリガーサービス要求（Network Triggered Service Request）手順を介してページングを開始して、ＩＭＳベアラを再確立することができることを提案している。この第２の高度化は、ＭＭＥがＩＭＳ  ＰＤＮ接続解放をハンドリングすることが可能でない場合に機能するが、より長い時間を要する。
【００２４】
さらに、本発明は、図１に概説したような解決策とは別の実施形態を提案する。以下の実施形態の重要な態様は、Ｐ−ＣＳＣＦ障害回復の解決策を専ら在圏ネットワーク内で実行することができるというものである。この態様は、Ｐ−ＣＳＣＦ障害回復の解決策を可能な限り迅速に市場に展開するのに非常に重要である。
【００２５】
本発明は、様々な実施形態において説明される幾つかの解決策を提案する。これらの解決策は、発信呼又は着信呼が開始される前にＵＥが新たなＰ−ＣＳＣＦエンティティの構成を開始するので、「事前対応的」と表現することができる。そのような「事前対応的」解決策の利点は、発信／着信呼セットアップ時間が削減され、ユーザーエクスペリエンスが改善されることである。
【００２６】
第１の実施形態では、Ｐ−ＣＳＣＦがＤｉａｍｅｔｅｒ（ダイアメーター）レベル又は他の任意のプロトコル上でＰＣＲＦによって監視される解決策が説明される。この監視は、ＵＥがＩＭＳに登録され、Ｐ−ＣＳＣＦがこのセッションのＰＣＲＦとのバインディング（対応づけ）を作成すると開始することができる。
【００２７】
図３は、この提案された解決策を詳細に記載している。
【００２８】
１．ＰＣＲＦは、Ｐ−ＣＳＣＦが（例えば、保守点検目的で）いずれの要求にも応答しないとき、及びそれらの２つのノード間のＨｅａｒｔｂｅａｔ（ハートビート）が中断されたときを検出する。ＰＣＲＦとＰ−ＣＳＣＦとの間では、Ｄｉａｍｅｔｅｒプロトコルが情報交換に用いられ、そのため、Ｄｉａｍｅｔｅｒプロトコル固有のメカニズムをＰＣＲＦが用いてＰ−ＣＳＣＦの障害を検出することができることに留意されたい。別の選択肢は、それらの２つのノード間にセキュリティ関連付けが存在し、障害検出用のメカニズムが、用いられているセキュリティプロトコルに固有のものとすることができるというものである。双方のノードは、ＵＥがローミングしているとき、在圏ネットワークに位置している可能性があるので、検出及び障害表示は、ホームネットワークを伴うことなく在圏ネットワークに留まる。
【００２９】
２．ＰＣＲＦは、Ｐ−ＣＳＣＦ障害をＰ−ＧＷに通知する。このステップは、ＵＥ単位又はノード単位のいずれかで行うことができる。これがＵＥ単位で行われ、障害が発生したＰ−ＣＳＣＦに登録された膨大な数のＵＥが存在する場合、ＰＣＲＦは、シグナリングのバーストを回避するために、ＵＥへのシグナリングの時間を分散させる（すなわち、遅延させる）手段を講じることができる。ＵＥがＩＭＳセッションをセットアップしていなかった場合、ＰＣＲＦ(Policy and Charging Rules Function) は、例えば、ＩＭＳシグナリングベアラ内のデフォルトのベアラを、ＱＣＩ(QoS Class Identifier)＝５、などを用いて変更するために、ＩＭＳ登録時にＰ−ＣＳＣＦとインターラクトしていた場合がある。
このインターラクトが行われなかった場合、ＰＣＲＦは、以前にＩＭＳセッションをセットアップしていたＵＥのみを知ることができ、それに応じてＰ-ＧＷに通知することができる。Ｐ-ＧＷ自体は、ＵＥ  ＩＰアドレスとＰ−ＣＳＣＦ  ＩＰアドレスとのバインディングを作成することができ、どのＵＥが特定のＰ−ＣＳＣＦの障害による影響を受けるのかを解決することもできる。
このステップは、新たなＰＣＣ(Policy Charging Control) ルールをＰ−ＧＷに伝達することによるか又はＰＣＲＦイベント及びイベント報告表示ＡＶＰ(Attribute-Value Pair)の新たなイベントトリガー値「Ｐ−ＣＳＣＦ障害」に従うことによるかのいずれかで行われる。ＰＣＲＦは、セッション解放原因を新たな原因ＰＣＳＣＦ＿ＦＡＩＬＵＲＥに設定することができる。原因値に他の任意の理由又は他の任意のＤｉａｍｅｔｅｒ  ＡＶＰも用いることができる。
【００３０】
３．Ｐ−ＧＷは、ＵＥにＰ−ＣＳＣＦ障害を通知する動作を取る。例えば、１つの可能な案は、Ｐ-ＧＷがプロトコル構成オプション(Protocol Configuration Option)（ＰＣＯ）を用いて、ＰＤＰコンテキスト作成応答（CreatePDPContextResponse）／ベアラ作成要求（Create Bearer Request）内で新たなＰ−ＣＳＣＦのリストをＵＥに送信することである。ＰＣＲＦが、ノード単位でＰ−ＣＳＣＦ障害を通知する場合、及び障害が発生したＰ−ＣＳＣＦに登録された膨大な数のＵＥが存在する場合、Ｐ-ＧＷは、シグナリングのバーストを回避するために、ＵＥへのシグナリングの時間を分散させる（すなわち、遅延させる）手段を講じることができる。別の代替形態では、Ｐ-ＧＷは、ＵＥの応答を遅延させるために、ＵＥへの情報（例えば、ＰＣＯ）内に遅延時間を示すことができる。これは、ＵＥから発信されたシグナリングを分散させる別の方法である。
【００３１】
４．ＵＥは、この要求に肯定応答する。
【００３２】
５．Ｐ−ＣＳＣＦの新たなリストを受信すると、使用中のＰ−ＣＳＣＦが見つからない場合には、各ＵＥは、新たなＰ−ＣＳＣＦ２に対する初期登録を行う。
【００３３】
Ｐ-ＧＷからＵＥへの高度化されたＰＣＯシグナリングに基づく上記解決策の１つの代替形態は、ＩＭＳ  ＡＰＮ(Access Point Name)へのＥＰＳ(Evolved Packet System) ベアラが非アクティブ化され、ＵＥから再確立されるベアラ再確立手順をＰ-ＧＷが開始するものである。
【００３４】
更に別の代替形態は、ステップ（３）、（４）及び（５）について記載されている。この代替形態では、Ｐ-ＧＷは、ＩＭＳ接続（例えば、ＩＭＳアクセスポイント名、すなわちＩＭＳ  ＡＰＮ）のＰＤＮ接続解放手順又はＩＭＳベアラのベアラ解放手順を開始する。例えば、ＰＤＮ接続解放手順の原因は、「再確立」に設定することができ、そのため、ＵＥは、新たなＩＭＳ接続セットアップを開始するように告げられる。ＵＥによって開始された新たなＩＭＳ接続確立の間、ネットワークは新たなＰ−ＣＳＣＦを割り当てるか、又は代替的に、ＵＥは、Ｐ−ＣＳＣＦ  ＦＱＤＮ解決手順の間、新たなＰ−ＣＳＣＦを解決する。最後に、ＵＥは、新たなＩＭＳ  ＰＤＮ接続を確立し、新たなＰ−ＣＳＣＦに接続する。
【００３５】
要約すれば、第１の実施形態は、ＰＣＲＦ機能によって障害のないＰ−ＣＳＣＦ機能を監視することに基づくアイデアを開示している。ＰＣＲＦがＰ−ＣＳＣＦの障害を検出した場合、ＰＣＲＦは、Ｐ−ＧＷに通知する動作を取り、それに対応して、ＵＥは新たなＰ−ＣＳＣＦに登録する動作を取る。
【００３６】
別の実施形態では、Ｐ−ＣＳＣＦ障害は、アクセス転送制御機能（ＡＴＣＦ）又は他の任意の近いＳＩＰノードによって認識される。例えば、ローミングの場合、このＳＩＰノードは、セッションボーダーコントローラー、例えばＩＢＣＦとすることができるが、Ｓ−ＣＳＣＦ若しくはＩ−ＣＳＣＦ又はアプリケーションサーバー自体とすることもできる。これには、ＡＴＣＦが、ネットワーク内の他の代替のＰ−ＣＳＣＦを知ることが必要とされる。ＡＴＣＦは、登録プロセス中に代替のＰ−ＣＳＣＦについて知ることができ、例えば、Ｐ−ＣＳＣＦは、バックアップＰ−ＣＳＣＦ又はバックアップＰ−ＣＳＣＦのリストをＵＥからネットワークへの要求に含めるか、又は、Ｐ−ＣＳＣＦは、全てのバックアップＰ−ＣＳＣＦノード上で構成される。ＡＴＣＦは、Ｐ−ＣＳＣＦロードバランシングを実行するように構成されている場合、全てのＰ−ＣＳＣＦの負荷を既に監視しており、したがって、全てのＰ−ＣＳＣＦを知っている。ＡＴＣＦは、登録隠蔽（registration hiding）を行うことができ、Ｐ−ＣＳＣＦ障害の場合にＵＥのローカルな再登録のための追加の認証データセットを提供するようにＨＳＳに依頼することができる。通常の登録が行われる場合、すなわち、ＵＥが以前は登録状態になく、Ｐ−ＣＳＣＦ障害がない場合、レジスタメッセージがホームネットワーク内のＨＳＳに転送される。ＡＴＣＦ及びＰ−ＣＳＣＦは、在圏ネットワークに位置することができる。
【００３７】
図４は、Ｐ−ＣＳＣＦ障害のＡＴＣＦベースの検出の解決策のより詳細な内容を示している。
【００３８】
１．移動着信（mobile terminating）ＳＩＰ  ＩＮＶＩＴＥがＡＴＣＦに到着しているとき、障害状況にあるＰ−ＣＳＣＦは、エラーコードを用いて応答する場合があるか、又は、ＡＴＣＦにおけるタイムアウトによって、ＡＴＣＦは、Ｐ−ＣＳＣＦがダウンしていることを検出する。ＡＴＣＦは、ＳＩＰ要求を記憶する。代替的に、ＡＴＣＦは、ＡＴＣＦとＰ−ＣＳＣＦとの間のキープアライブハートビート検出メカニズムによってＰ−ＣＳＣＦ障害を検出する場合がある。このキープアライブハートビート検出メカニズムは、ＳＩＰシグナリング方法又は他の下位レイヤメカニズムによって行うことができる。
【００３９】
２．ＡＴＣＦは、Ｐ−ＣＳＣＦ障害を検出すると、別の適切なＰ−ＣＳＣＦを選択する。ＡＴＣＦは、現在の負荷状況を考慮に入れることができる。
【００４０】
３．ＡＴＣＦは、好ましくは、ＳＩＰ  ＮＯＴＩＦＹ（通知）を選択されたＰ−ＣＳＣＦ２に送信して、この新たなＰ−ＣＳＣＦ２に向けてＩＭＳに再登録するようにＵＥをトリガーする。Ｐ−ＣＳＣＦ２は、ＡＴＣＦアドレスとＵＥアドレスとのバインディングを作成して記憶する。
【００４１】
４．Ｐ−ＣＳＣＦ２は、ＮＯＴＩＦＹをＵＥに保護なしで転送する。
【００４２】
５．ＵＥは、新たなＰ−ＣＳＣＦ２に向かってＡＴＣＦへＩＭＳ再登録する。ＡＴＣＦは、ＨＳＳからの認証データを有することができ、４０１未認可応答（unauthorized response）を用いてＵＥにチャレンジすることができる。ＵＥは、このチャレンジに対する応答を計算し、別のＲＥＧＩＳＴＥＲ（登録）メッセージを送信し、これがＯＫである場合、ＡＴＣＦは、２００ＯＫを用いて再登録に肯定応答する。
【００４３】
６．ＡＴＣＦは、記憶されたＳＩＰ  ＩＮＶＩＴＥをＵＥに転送する。
【００４４】
図５に示す別の実施形態では、ＡＴＣＦ（又はＩＢＣＦ、Ｉ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、ＡＳ）は、図４に記載したようにＰ−ＣＳＣＦ障害を検出する。唯一の相違は、ＩＭＳ  ＰＤＮ接続解放によって再登録要求をＵＥに伝達することである。すなわち、ステップ１．〜３．並びにステップ６．及び７．は、図４に記載したように実行される。
【００４５】
４．Ｐ−ＣＳＣＦ２が、ＮＯＴＩＦＹをＡＴＣＦから受信すると、Ｐ−ＣＳＣＦ障害は、関連付けられたＰ−ＧＷに通知される。代替的に、Ｐ−ＣＳＣＦ障害は、関連付けられたＰＣＲＦに通知される。この場合、ＰＣＲＦは、図３のステップ２に記載したのと同じ方法でＰ−ＣＳＣＦ障害を関連付けられたＰ−ＧＷに通知する。Ｐ−ＧＷは、その後、ＩＭＳ  ＰＤＮ接続解放要求を作成し、これをＳ−ＧＷを介してＭＭＥに送信する。ＩＭＳ  ＰＤＮ接続解放は、ベアラ削除要求メッセージとすることができ、ＭＭＥは、この要求がＩＭＳベアラ用であることを検出することができる。
【００４６】
５．ＭＭＥは、ＩＭＳ  ＰＤＮ接続解放要求を原因値「再アクティブ化要求（Reactivation requested）」とともにＵＥに送信する。
【００４７】
図６に示す別の実施形態では、ＡＴＣＦ（又はＩＢＣＦ、Ｉ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、ＡＳ）は、図４に記載したようなＰ−ＣＳＣＦ障害を検出する。主な相違は、ＭＭＥへのＩＭＳ  ＰＤＮ接続解放の伝達にある。この実施形態では、ＡＴＣＦ及びＭＭＥは同じネットワーク、例えば、ローミングの場合の在圏ネットワークに位置していると仮定される。双方のノードは、新たなインターフェースと接続される。このインターフェースは、ＭＡＰ、ＤＩＡＭＥＴＥＲ、ＳＩＰ、又は他の任意の適したプロトコルに基づくことができる。ＡＴＣＦは、ＭＭＥアドレスを用いて構成される。ＡＴＣＦは、ＩＭＳ登録中にこのアドレスを知ることができ、ＨＳＳは、ＵＥに向けたアンサーメッセージにサービングノード情報を含めることができる。ＡＴＣＦは、メッセージがＵＥに向かう途中で通過するとこの情報を除去することができる。
【００４８】
Ｐ−ＣＳＣＦ障害のＡＴＣＦ検出に基づく解決策の問題は、ＡＴＣＦが、主としてローミングＵＥに適用されるオプションのエンティティであるということである。換言すれば、非ローミングＵＥの場合、ＡＴＣＦは、用いられない場合がある。したがって、提案された解決策は、主としてローミングＵＥのＰ−ＣＳＣＦ復旧に適用可能である。非ローミングの場合、Ｉ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、又はＡＳをＰ−ＣＳＣＦのＳＩＰ監視に用いることができる。さらに、図３に記載した解決策は、非ローミングＵＥにも同様に適用することができる。
【００４９】
上記実施形態における全ての方法は、Ｉ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、ＩＢＣＦ、ＡＴＣＦ、ＡＳ、又は他の任意のＩＭＳシグナリングノード等の複数のＳＩＰノードに適用することができる。
【００５０】
実施形態を伴った本発明の進歩性
１）ＭＭＥのＰ−ＣＳＣＦ障害ハンドリング能力のＨＳＳへの伝達。
２）代替的に、加入情報の変更を用いたＨＳＳからＭＭＥへのＩＭＳ  ＡＰＮの非アクティブ化／アクティブ化。
３）代替的に、ＰＣＲＦからのＤｉａｍｅｔｅｒレイヤ上でのＰ−ＣＳＣＦの監視。
４）代替的に、ＡＴＣＦ、ＩＢＣＦ、Ｉ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、又はＡＳからのＳＩＰレイヤ上でのＰ−ＣＳＣＦの監視。
５）代替的に、Ｐ−ＣＳＣＦを再選択し、ＶＰＬＭＮにおけるＡＴＣＦ又はＩＢＣＦまでローカルでのみ再登録を維持することによるローカルな障害ハンドリング。
６）代替的に、ＡＴＣＦ又はＩＢＣＦからＭＭＥへのＰ−ＣＳＣＦ障害の直接伝達。
【００５１】
実施形態を伴った本発明の重要な態様
本発明の重要な特徴は以下のとおりである。
１）ＶＰＬＭＮに存在する場合があるＭＭＥの能力に基づいてＩＭＳ  ＰＤＮ接続解放に対処する方法のＨＳＳにおける決定。
ａ．ＩＭＳ  ＰＤＮ接続解放の送信（ＭＭＥは、これをサポートする）。
ｂ．ＩＭＳ  ＡＰＮの加入者プロファイルパラメーターを非アクティブ化及びアクティブ化する（ＭＭＥは、これをサポートしない）。
２）ＰＣＲＦからのＤｉａｍｅｔｅｒレイヤ上でのＰ−ＣＳＣＦの監視及び障害の場合におけるイベント報告表示ＡＶＰの新たなイベントトリガー値「Ｐ−ＣＳＣＦ障害」の送信。ＰＣＲＦは、セッション解放原因を新たな原因ＰＣＳＣＦ＿ＦＡＩＬＵＲＥに設定することができる。
３）ＡＴＣＦ、ＩＢＣＦ、Ｉ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、又はＡＳからのＳＩＰレイヤ上でのＰ−ＣＳＣＦの監視及び更なるセッションハンドリング用の新たなＰ−ＣＳＣＦの選択。
４）新たなＰ−ＣＳＣＦは、ＵＥとＡＴＣＦ（及び／又はＩＢＣＦ／Ｉ−ＣＳＣＦ／Ｓ−ＣＳＣＦ／ＡＳ）との間のバインディングを記憶し、
ａ．保護されていないＮＯＴＩＦＹをＵＥに送信して、ＩＭＳ再登録をトリガーする。
ｂ．イベント報告表示ＡＶＰの新たなイベントトリガー値「Ｐ−ＣＳＣＦ障害」を送信するＰＣＲＦに通知する。ＰＣＲＦは、セッション解放原因を新たな原因ＰＣＳＣＦ＿ＦＡＩＬＵＲＥに設定することができる。
５）ＭＡＰ、ＤＩＡＭＥＴＥＲ、ＳＩＰ、又は他の任意の適したプロトコルに基づく新たなインターフェースを用いたＡＴＣＦ又はＩＢＣＦからＭＭＥへのＰ−ＣＳＣＦ障害の直接伝達。
【００５２】
実施形態を伴った本発明の利点
ホームネットワークへの影響がないローミング加入者、ローカルな障害ハンドリングの最適化。
【００５３】
本明細書で述べた本発明の多くの変更及び他の実施形態が、上記説明及び関連図面に提示された教示の利益を有する、本発明が関係する技術分野の当業者には思い付くであろう。したがって、本発明は、開示された特定の実施形態に限定されるものではなく、変更及び他の実施形態が、本発明の範囲内に含まれることが意図されていることが理解されるべきである。特定の用語が本明細書において用いられているが、それらの用語は、限定の目的で用いられているのではなく、一般的かつ説明的な意味でのみ用いられている。
【図１】
2020145731.tif 000003
【図２】
2020145731.tif 000004
【図３】
2020145731.tif 000005
【図４】
2020145731.tif 000006
【図５】
2020145731.tif 000007
【図６】
2020145731.tif 000008