(57)【特許請求の範囲】
【請求項１】
一般呼を制御する一般呼制御ノードおよび緊急呼を制御する緊急呼制御ノードが協調して端末間の通話を制御するVoLTEサービスの通信規制システムにおいて、
前記各制御ノードから呼制御の情報を取得し、各端末の識別情報と当該端末に関して確立されているベアラとを紐付けて管理するベアラ紐付管理手段と、
前記ベアラ紐付管理手段で管理されている紐付け情報に基づいて、緊急呼のベアラが確立されている端末の一般呼を制御する一般呼制御ノードに対して、一般呼の規制を要求する規制要求手段とを具備し、
前記一般呼制御ノードでは、前記規制要求に応答して一般呼の規制が実施されることを特徴とするVoLTEサービスの通信規制システム。
【請求項２】
前記規制要求手段は、緊急呼のベアラが確立されている端末の緊急呼制御ノードに対して、当該緊急呼の保留規制をさらに要求し、
前記緊急呼制御ノードでは、前記規制要求に応答して緊急呼の保留規制が実施されることを特徴とする請求項１に記載のVoLTEサービスの通信規制システム。
【請求項３】
前記一般呼制御ノードでは、前記一般呼の規制要求に応答して一般呼の発信を規制することを特徴とする請求項１または２に記載のVoLTEサービスの通信規制システム。
【請求項４】
前記一般呼制御ノードでは、前記一般呼の規制要求に応答して一般呼の着信を規制することを特徴とする請求項１または２に記載のVoLTEサービスの通信規制システム。
【請求項５】
前記一般呼の発信規制が、三者通話への移行規制を含むことを特徴とする請求項３に記載のVoLTEサービスの通信規制システム。
【請求項６】
一般呼通話中に、当該一般呼の保留および緊急呼通話への移行は許容されて三者通話への移行は規制されることを特徴とする請求項５に記載のVoLTEサービスの通信規制システム。
【請求項７】
一般呼通話中に、当該一般呼の保留および緊急呼通話への移行は許容されて三者通話への移行は規制されることを特徴とする請求項５または６に記載のVoLTEサービスの通信規制システム。
【請求項８】
一般呼通話中の緊急機関からの呼び返しに係る緊急呼着信が許容されることを特徴とする請求項１ないし７のいずれかに記載のVoLTEサービスの通信規制システム。
【請求項９】
一般呼を制御する一般呼制御ノードおよび緊急呼を制御する緊急呼制御ノードが協調して端末間の通話を制御するVoLTEサービスの通信規制方法において、
前記各制御ノードから呼制御の情報を取得し、各端末の識別情報と当該端末に関して確立されているベアラとを紐付けて、これを紐付け情報として管理する手順と、
前記管理されている紐付け情報に基づいて、緊急呼のベアラが確立されている端末の一般呼を制御する一般呼制御ノードに対して、一般呼の規制を要求する手順と、
前記一般呼制御ノードが、前記規制要求に応答して一般呼の規制を実施する手順とを含むことを特徴とするVoLTEサービスの通信規制方法。
【請求項１０】
前記規制を要求する手順が、緊急呼のベアラが確立されている端末の緊急呼制御ノードに対して、当該緊急呼の保留規制を要求する手順と、
前記緊急呼制御ノードが、前記規制要求に応答して緊急呼の保留規制を実施する手順とを更に含むことを特徴とする請求項９に記載のVoLTEサービスの通信規制方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、VoLTE (Voice over Long Term Evolution)サービスの通信規制方法およびシステムに係り、特に、一般呼と緊急呼とが競合した場合に、ネットワーク側で一般呼の発着信や緊急呼の保留を規制して緊急呼およびその通話を優先させる通信規制方法およびシステムに関する。
【背景技術】
【０００２】
VoLTEは、次世代の携帯電話向け高速無線通信規格のLTEアクセス環境において、IPベースの音声サービスを提供する技術であり、現状の1x音声サービスの代替となるものとして期待されている。VoLTEでは、LTEアクセス網を収容するコアネットワークとしてEPC(Evolved Packet Core)が用いられ、音声サービスを提供するための呼制御ネットワークとしてIMS(IP Multimedia Subsystem)が用いられる。VoLTEについては、非特許文献１〜５に開示されている。
【０００３】
以下、図９，１０，１１の機能ブロック図を参照してVoLTEサービスにおける従来の発信手順を説明する。なお、各図およびその説明で参照する略語は以下の通りである。  
TAS：Telephony Application Server
P-CSCF：Proxy Call Session Control Function
S-CSCF：Serving-CSCF
E-CSCF：Emergency-CSCF
EPC：Evolved Packet Core
PCRF：Policy Charging and Resource Function
PGW：Packet Data Network Gateway
SGW：Serving Gateway
eNB：evolutional Node B
UE：User Equipment
MGCF：Media Gateway Control Function
MGW：Media Gateway
PSAP：Public Safety Answering Point
【０００４】
図９は、VoLTEサービスにおける従来の一般呼の発信手順を示したブロック図である。ステップＳ１では、UE（ユーザ端末）の電源ON等を契機に、当該UEとPGW1との間に一般呼用のDefaultベアラ(SIPシグナリング用)が確立される。ステップＳ２では、UEにおいて、前記Defaultベアラを用いてSIPによるREGISTERが実行され、P-CSCFおよびS-CSCFに対してUEが登録される。
【０００５】
この過程で、P-CSCFはPCRFとDiameterプロトコルによる通信セッションを確立して通知予約を行う。この通知予約により、確立されたDefaultベアラの状態が変化(圏外や無線リソース不足によるベアラ消失等)した場合に、P-CSCFはPCRFから通知を受け取れるようになる。
【０００６】
ステップＳ３では、一般呼の発信時に、UEが前記Defaultベアラを用いてSIP INVITEを送信することで通信相手（図示省略）との間に通信セッションが確立される。この過程で、P-CSCFはPCRFに対して、メディア情報の送信および通知予約を行う。この通知予約により、P-CSCFはPCRFから、これから確立されるベアラ(一般呼用のDedicatedベアラ)の状態変化の通知を受けられるようになる。
【０００７】
ステップＳ４では、PCRFが前記受信したメディア情報に基づき、確立するベアラに割り当てるリソース(帯域/QoS/優先度等)を決定し、一般呼用のDedicatedベアラ(音声用)が確立される。ステップＳ５では、UEが前記一般呼用のDedicatedベアラを用いて、通信相手と音声パケット(RTP等)の送受信を行う。
【０００８】
図１０は、VoLTEサービスにおける従来の緊急呼の発信手順を示したブロック図である。ステップＳ１１では、UEの電源ON等を契機にして、前記と同様の手順で一般呼用のDefaultベアラが確立される。UEは、このDefaultベアラを用いてSIPによるREGISTERを行い、P-CSCFおよびS-CSCFへ自身を登録する。この過程で、P-CSCFはPCRFとDiameterプロトコルによる通信セッションを確立して通知予約を行う。
【０００９】
ステップＳ１２では、UEが緊急呼発信を契機にして、緊急呼用のDefaultベアラ(SIPシグナリング用)を確立する。ステップＳ１３では、UEが前記緊急呼用のDefaultベアラを用いて、SIPによる緊急呼用のREGISTERを行い、P-CSCFおよびS-CSCFへ自身を登録する。この過程で、P-CSCFはPCRFとDiameterプロトコルによる通信セッションを確立して通知予約を行う。
【００１０】
ステップＳ１４では、UEが緊急呼の発信時に前記緊急呼用のDefaultベアラを用いて緊急呼用のSIP INVITEを送信することで通信セッションを確立する。この過程で、P-CSCFはPCRFに対しメディア情報の送信および通知予約を行う。ステップＳ１５では、PCRFが前記受信したメディア情報に基づき、確立するベアラに割り当てるリソース(帯域/QoS/優先度等)を決定し、緊急呼用のDedicatedベアラ(音声用)を確立する。ステップＳ１６では、UEが緊急呼用のDedicatedベアラを用いてPSAP(緊急機関)と音声パケットの送受信を行う。
【００１１】
図１１は、VoLTEにおける従来の緊急呼呼び返し(Call Back)手順を示したブロック図である。緊急呼呼び返しとは、緊急呼通話中にUEから切断を行った場合、一定時間は回線が切断されず、緊急機関からUEへ発信するもので、ここでは、緊急呼での通話中にUEから通話を終了し、通話終了を契機に緊急呼用のDedicatedベアラが削除された状態から説明する。
【００１２】
ステップＳ２１では、緊急機関がUEに対してSIP INVITEを送信し、通信セッション(Emergency INVITE session)を確立することで呼び返しを行う。このSIP INVITEがUEへ到達する経路は、P-CSCF3を経由する場合およびP-CSCF1を経由する場合の2通りがある。緊急機関からの通信セッション確立の過程で、P-CSCFはPCRFに対しメディア情報の送信および通知予約を行う。
【００１３】
ステップＳ２２では、PCRFが前記受信したメディア情報に基づき、確立するベアラに割り当てるリソース(帯域/QoS/優先度等)を決定し、緊急呼用のDedicatedベアラ(音声用)を確立する。ステップＳ２３では、緊急機関が前記緊急呼用のDedicatedベアラを用いて、UEと音声パケットの送受信を行う。
【先行技術文献】
【非特許文献】
【００１４】
【非特許文献１】GSMA IR.92 V5.0  IMS Profile for Voice and SMS
【非特許文献２】3GPP TS 23.401  General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access
【非特許文献３】3GPP TS 24.229  IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
【非特許文献４】3GPP TS 23.167  IP Multimedia Subsystem (IMS) emergency sessions
【非特許文献５】3GPP TS 29.214  Policy and charging control over Rx reference point
【発明の概要】
【発明が解決しようとする課題】
【００１５】
音声サービスの付加サービスとして、一般呼に対して三者通話サービスや割込通話サービスが用意されているが、緊急呼に対しては、これらサービスを制限する必要がある。具体的には、緊急呼通話中における当該緊急呼の保留および一般呼の発信/着信の規制が必要となる。また、一般呼通話中に緊急呼が発信された場合には、一般呼を保留して緊急呼通話への移行のみは許容し、三者通話への移行は規制することが望ましい。その一方、緊急呼着信(緊急機関からの再呼び出し)については、一般呼通話中であっても規制せずに割り込ませる必要がある。
【００１６】
緊急呼のセッション情報は、一般的にはP-CSCFおよびE-CSCFで保持され、一般呼のセッション情報はP-CSCFおよびS-CSCFで保持される。ここで、同じ端末であっても緊急呼と一般呼とで、そのセッション情報が保持されるP-CSCFは必ずしも同じにならない。これは、負荷分散を目的として端末に通知するP-CSCFのIPアドレスをDHCPにて動的に制御していることや、輻輳時においても緊急呼を確実に疎通させることを目的として緊急呼用のP-CSCFを設置していることがあるためである。
【００１７】
このように、緊急呼および一般呼の各セッション情報の保持されるCSCFノードが異なると、緊急呼のセッション情報を保持しているCSCFノードでは緊急呼通話中の端末が一般呼を発着信したことを検知することができない。同様に、一般呼のセッション情報を保持しているCSCFノードでは一般呼通話中の端末が緊急呼を発信したことを検知することができない。このため、緊急呼と一般呼とが競合した場合に、IMSネットワーク側の制御のみでサービスを制限することは困難であった。
【００１８】
本発明の目的は、上記した従来技術の課題を解決し、緊急呼と一般呼とが競合した場合に、ネットワーク側の制御で一般呼を規制して緊急呼通話を確実に提供できる通信規制方法およびシステムを提供することにある。
【課題を解決するための手段】
【００１９】
上記の目的を達成するために、本発明は、一般呼を制御する一般呼制御ノードおよび緊急呼を制御する緊急呼制御ノードが協調して端末間の通話を制御するVoLTEサービスの通信規制システムにおいて、以下のような構成を具備した点に特徴がある。
【００２０】
(1)各制御ノードから呼制御の情報を取得し、各端末の識別情報と当該端末に関して確立されているベアラとを紐付けて管理するベアラ紐付管理手段と、ベアラ紐付管理部で管理されている紐付け情報に基づいて、緊急呼のベアラが確立されている端末の一般呼を制御する一般呼制御ノードに対して、一般呼の規制を要求する規制要求手段とを設け、一般呼制御ノードでは、この規制要求に応答して一般呼が規制されるようにした。
【００２１】
(2)規制要求手段は、緊急呼のベアラが確立されている端末の緊急呼制御ノードに対して、当該緊急呼の保留規制をさらに要求し、緊急呼制御ノードでは、この規制要求に応答して緊急呼の保留が規制されるようにした。
【発明の効果】
【００２２】
本発明によれば、LTEアクセス環境において、緊急呼と一般呼とが競合した場合に一般呼を規制して緊急呼を優先的に通話させる、以下のような通信規制を、ネットワーク側での制御により実現できるようになる。
【００２３】
(1)緊急呼通話中に一般呼発信があった場合に、緊急通話の保留および一般呼の発信を規制できる。
【００２４】
(2)緊急呼通話中の一般呼の着信を規制できる。
【００２５】
(3)一般呼通話中に緊急呼発信する場合、一般呼の保留および緊急呼通話への移行が許容されるが三者通話への移行は規制できる。
【００２６】
(4)一般呼通話中に緊急呼着信(緊急機関からの呼び返し)を割り込ませることができる。
【図面の簡単な説明】
【００２７】
【図１】緊急呼通話中の緊急呼保留規制および一般呼発着信規制の手順を示したブロック図である。
【図２】緊急呼通話中の緊急呼保留規制および一般呼発着信規制のシーケンスフローである。
【図３】一般呼通話中に緊急呼発信された際の三者通話への移行規制の手順を示したブロック図である。
【図４】一般呼通話中に緊急呼発信された際の三者通話への移行規制のシーケンスフローである。
【図５】一般呼通話中に緊急呼着信(呼び返し)を許容する手順を示したブロック図である。
【図６】一般呼通話中に緊急呼着信(呼び返し)を許容する着信規制のシーケンスフローである。
【図７】ベアラ規制の要否判断手順を示したフローチャートである。
【図８】ベアラ規制の手順、条件および規制内容を一覧表示した図である。
【図９】VoLTEにおける従来の一般呼の発信手順を示したブロック図である。
【図１０】VoLTEにおける従来の緊急呼の発信手順を示したブロック図である。
【図１１】VoLTEにおける従来の緊急呼呼び返し手順を示したブロック図である。
【発明を実施するための形態】
【００２８】
以下、図面を参照して本発明の実施の形態について詳細に説明する。ここでは、UEが緊急呼の通信にはP-CSCF2を利用し、一般呼の通信にはP-CSCF1を利用するものとする。このように、緊急呼と一般呼とでUEが通信するP-CSCFを異ならせている理由は、負荷分散を目的としてUEに通知するP-CSCFのIPアドレスをDHCPにより動的に制御していること、および輻輳時にも緊急呼を確実に疎通させるために緊急呼用のP-CSCFを設置していることにある。
【００２９】
本発明では、PCRFにベアラ紐付管理部１が設けられ、以下に詳述するように、UEにより確立された全てのベアラ情報を、当該UEのSubscription ID(IMSI, MSISDN, etc.)と紐付け管理することで、UEが緊急呼通話中であるか否かをPCRFが一元的に管理できるようにしている。
【００３０】
[第１実施形態]
図1は、本発明の第１実施形態に係るVoLTEサービスの緊急呼優先方法を示した機能ブロック図、図２は、そのシーケンスフローであり、特に、緊急呼通話中における緊急呼保留規制および一般呼発着信規制の手順を示している。
【００３１】
時刻t1では、UEからPGW1に対して、その電源ON等を契機にベアラ確立が要求され、これにPGW1が応答することで一般呼のDefaultベアラが確立される。このベアラ確立は、3GPP TS 23.401 5.3.2.1に準拠した手順で実施される。PCRFでは、PGW1から前記Defaultベアラの確立が通知されると、これを契機にベアラ規制の要否が判断される。
【００３２】
図７は、ベアラ規制の要否判断手順を示したフローチャートであり、図８は、ベアラ規制の手順、条件および規制内容を一覧表示した図である。
【００３３】
ステップＳ１０１では、一般呼のDefaultベアラが存在するか否かが判定される。ここでは存在すると判定されるのでステップＳ１０２へ進む。ステップＳ１０２では、緊急呼のDefaultベアラが存在するか否かが判定される。ここでは存在しないと判定されるので当該処理を終了する。したがって、当該時点では緊急呼保留規制および一般呼発着信規制のいずれも実施されない。
【００３４】
時刻t2では、UEが前記一般呼用のDefaultベアラを用いてREGISTERをP-CSCF1へ送信する。これにより、P-CSCF1およびS-CSCF1に対してユーザ情報の登録が行われる。P-CSCF1は更に、ベアラのPCCルールの設定・管理を行うPCRFとの間でAAR(認証要求)/AAA(認可回答)の各メッセージを送受信することで、通知予約(Subscription)およびベアラとセッションとの関連付けが行われる。
【００３５】
この通知予約は本来、セッションに関連付けられたベアラの状態変更が生じたときに、この変更をPCRFがP-CSCFへ通知できるようにするために実施されるが、本実施形態では、端末ID(Subscription ID)に紐づけられたすべてのベアラについて、特定の組み合わせのベアラが確立した場合にもPCRFがP-CSCFへ通知できるように拡張するもので、3GPP TS 29.214 4.4.5に準拠した手順で実施される。これにより、PCRFでは端末IDと確立済みの各ベアラとがベアラ紐付管理部１において紐付けられる。すなわち、この段階ではUEの端末IDと前記時刻t1で確立された一般呼用のDefaultベアラの識別情報とが紐付けられる。
【００３６】
時刻t3では、UEによる緊急呼の発信に際し、UEからPGW2に対して緊急呼の確立が要求され、これにPGW2が応答することで緊急呼のDefaultベアラ(SIP信号用)が確立される。PCRFでは、この緊急呼のDefaultベアラ確立を契機に、ベアラ規制の要否判断が実行される。
【００３７】
図７のフローチャートを再び参照し、ステップＳ１０１では、一般呼のDefaultベアラが存在すると判定されるのでステップＳ１０２へ進む。ステップＳ１０２では、緊急呼のDefaultベアラが存在すると判定されるのでステップＳ１０３へ進む。ステップＳ１０３では、緊急呼のDedicatedベアラ(音声用ベアラ)が存在するか否かが判定される。ここでは存在しないと判定されるので当該処理を終了する。したがって、当該時点では緊急呼保留規制および一般呼発着信規制のいずれも実施されない。
【００３８】
時刻t4では、UEが前記緊急呼用のDefaultベアラを用いてEmergency REGISTERをP-CSCF2へ送信する。これにより、P-CSCF2およびS-CSCF1に対してユーザ情報が登録される。この際、P-CSCF2はPCRFとAAR/AAAを送受信することで、通知予約およびベアラとセッションとの関連付けを行う。なお、PCRFに対する通知予約およびベアラとセッションとの関連付けも、一般呼のREGISTERの場合と同様に、3GPP TS 29.214 4.4.5に準拠した手順で実施される。
【００３９】
時刻t5では、UEがPSAP宛てに発信した緊急呼(Emergency INVITE)が、P-CSCF2およびE-CSCFを経由して緊急機関(PSAP)へ到達し、これにより緊急呼用のセッションが確立される。この過程において、P-CSCF2がPCRFに対してメディア情報を通知することで、緊急呼のDedicatedベアラ(音声用)が確立される。PCRFでは、このベアラ確立を契機にしてベアラ規制の要否判断が実行される。
【００４０】
図７のフローチャートを再び参照し、ステップＳ１０１では、一般呼のDefaultベアラが存在すると判定されるのでステップＳ１０２へ進む。ステップＳ１０２では、緊急呼のDefaultベアラが存在すると判定されるのでステップＳ１０３へ進む。ステップＳ１０３では、緊急呼のDedicatedベアラ(音声用ベアラ)が存在するか否かが判定され、ここでは存在すると判定されるのでステップＳ１０４へ進む。
【００４１】
このように、本実施形態では一般呼用のDefaultベアラおよび緊急呼用のDefault/Dedicatedベアラが共に存在していると、ステップＳ１０４では、規制が必要だと判断される。そして、規制対象端末の登録情報が保持されているP-CSCF1およびP-CSCF2へRARメッセージ (例えば、INDICATION OF FAILED RESOURCES ALLOCATION) が通知されて規制が要求される。
【００４２】
このRARメッセージに応答して、P-CSCF1ではUEの一般呼発着信が規制され、P-CSCF2ではUEからの緊急呼に関する保留要求(reINVITE/UPDATE)が規制される。これらの規制が行われることにより、緊急呼通話中の三者通話への移行および割り込み通話が規制される。
【００４３】
このようにして規制が開始されると、時刻t6において、UEが緊急呼を保留するためにreINVITEおよびUAPDATEを送信しても、P-CSCF2によりエラーレスポンス(例えば、403 Forbidden)が応答される。
【００４４】
また、時刻t7のように、UEが一般呼を発信(INVITE)しても、P-CSCF1によりエラーレスポンス(例えば、403 Forbidden)が応答される。
【００４５】
さらに、時刻t8のように、UEに対して一般呼が発信(INVITE)された際は、そのINVITEがP-CSCF1へ到達するものの、P-CSCF1によりエラーレスポンス(例えば、403 Forbidden)が応答される。
【００４６】
[第２実施例]
図３は、本発明の第２実施形態に係るVoLTEサービスの緊急呼優先方法を示した機能ブロック図、図４は、そのシーケンスフローであり、特に、一般呼通話中に緊急呼が発信された場合の三者通話への移行の規制手順を示している。
【００４７】
本実施形態では、UEが一般呼通話中に緊急呼発信し、一般呼を保留して緊急呼へ移行したことをPCRFが判断してP-CSCF1およびP-CSCF2へ通知を行うことで、UEからの三者通話のための発信が規制される。
【００４８】
時刻t21では、UEからPGW1に対して、その電源ON等を契機にベアラ確立が要求され、これにPGW1が応答することで一般呼のDefaultベアラが確立される。PCRFでは、前記一般呼ベアラの確立を契機に、前記図７の手順でベアラ規制の要否判断が実行されるが、ここでは、緊急呼のDefaultベアラが存在しない（ステップＳ１０２の判断が否定）ので、ベアラ規制は未だ不要と判断される。
【００４９】
時刻t22では、UEが前記一般呼用のDefaultベアラを用いてREGISTERをP-CSCF1へ送信する。これにより、P-CSCF1およびS-CSCF1に対してユーザ情報が登録される。P-CSCF1は更に、ベアラのPCCルールの設定・管理を行うPCRFに対してAAR/AAAを送受信することで、通知予約(Subscription)およびベアラとセッションとの関連付けが行われる。
【００５０】
時刻t23では、UEが発信した一般呼(INVITE)がP-CSCF1およびS-CSCF1を経由して通話相手へ到達し、一般呼用のセッションが確立される。この過程において、P-CSCF1がPCRFに対してメディア情報を通知することで、一般呼用のDedicatedベアラ(音声用)が確立される。PCRFでは、このベアラ確立を契機にしてベアラ規制判断が実行されるが、上記と同様に、ここでは緊急呼のDefaultベアラが存在しない（ステップＳ１０２の判断が否定）ので、ベアラ規制は未だ不要と判断される。
【００５１】
時刻t24において、UEが緊急呼を発信しようとした場合、UEではまず、一般呼通話が保留される。次いで、UEからreINVITEおよびUAPDATEが送信されて公知の保留処理が進行する。
【００５２】
時刻t25では、一般呼の通話保留後に緊急呼を発信する際、UEからPGW2に対して緊急呼の確立が要求され、これにPGW2が応答することで緊急呼のDefaultベアラが確立される。PCRFでは、この緊急呼のDefaultベアラ確立を契機に、前記図７に示したベアラ規制の要否判断が実行される。ここでは、緊急呼のDedicatedベアラが存在しない（ステップＳ１０３の判断が否定）ので、ベアラ規制は未だ不要と判断される。
【００５３】
次いで、UEが、この緊急呼用Defaultベアラを用いて緊急呼(Emergency INVITE)を発信すると、これがP-CSCF2およびE-CSCFを経由してPSAP（緊急機関）へ到達し、緊急呼用のセッションが確立される。この過程において、P-CSCF2がPCRFに対してメディア情報を通知することで緊急呼のDedicatedベアラ(音声用)が確立される。
【００５４】
時刻t26では、このベアラ確立を契機に、前記図７に示したベアラ規制の要否判断がPCRFにおいて実行される。ここでは、一般呼用Defaultベアラおよび緊急呼用Default/Dedicatedベアラがいずれも存在する（ステップＳ１０３の判断が肯定）のでステップＳ１０４へ進み、規制が必要と判断される。そして、規制対象のUEの登録情報が保持されている各P-CSCFへRARメッセージが通知されて規制が要求される。各P-CSCFでは、前記RARメッセージの受信に応答して、UEからの保留要求(reINVITE/UPDATE)および発信(INVITE)ならびにUEへの着信呼が規制される。
【００５５】
したがって、時刻t7において、UEが緊急呼を保留するためにreINVITEおよびUAPDATEを送信しても、上記の第１実施形態と同様に、P-CSCF2によりエラーレスポンス(例えば、403 Forbidden)が応答（図示省略）される。また、UEが三者通話への移行を目的として一般呼用のDefaultベアラを用いてINVITEをP-CSCF1へ送信しても、P-CSCF1からエラーレスポンスが応答されることになる。
【００５６】
[第３実施例]
図５は、本発明の第３実施形態に係るVoLTEサービスの緊急呼優先方法を示した機能ブロック図、図６は、そのシーケンスフローであり、特に、一般呼の通話中に緊急呼着信(呼び返し)を許容する手順を示している。
【００５７】
本実施形態では、PCRFがベアラの確立状態に基づいて各P-CSCFへ通知を行わない判断を下し、緊急機関からの呼び返しを割り込ませるようにしている。ここで、呼び返しがUEに到達する経路は、PSAP Callback Indication(MGCFで付与されることがある)があるか否かで異なる。
【００５８】
時刻t41では、前記第１実施形態の時刻t1〜t5と同様の手順で一般呼用Defaultベアラおよび緊急呼用Default/Dedicatedベアラが確立され、UEから緊急呼が発信される。PCRFでは、前記緊急呼用Dedicatedベアラの確立を契機にベアラ規制判断が実施され、ここでは、一般呼用Defaultベアラおよび緊急呼用Default/Dedicatedベアラが存在する（ステップＳ１０３の判断が肯定）のでステップＳ１０４へ進み、規制が必要と判断される。その結果、規制対象のUEの登録情報が保持されている各P-CSCFへRARメッセージが通知されるので、各P-CSCFでは、UEからの保留要求(reINVITE/UPDATE)および発信(INVITE)ならびにUEへの着信呼が規制される。
【００５９】
時刻t42では、UEでの緊急呼切断操作に応答して、UEからP-CSCF2へ緊急呼用のDefaultベアラを用いてBYEが送信される。この過程で、緊急呼用のDedicatedベアラが削除されると、PCRFは規制を解除するために各P-CSCFへRARメッセージを送信する。
【００６０】
時刻t43では、UEからの一般呼発信の要求に応じて、一般呼用のDefaultベアラを用いてINVITEが送信される。この過程において、一般呼用のDedicatedベアラが確立されたとしても、PCRFでの規制判断の条件に合致しないため、PCRFからP-CSCFに対して規制が要求されることはない。
【００６１】
時刻t44では、緊急機関からの呼び返しが、P-CSCFにより規制されることなく透過されるのでUEに着信する。なお、呼び返しがUEまで到達する際の経路は、PSAP Callback Indication(MGCFで付与されることがある)があるか否かで異なる。この識別子が付与されている場合は、時刻t4aのように、S-CSCF1、P-CSCF2および緊急呼用Defaultベアラを経由してUEまで到達する。これに対して、識別子が付与されていない場合は、時刻t4bのように、S-CSCF1、P-CSCF1および一般呼用Defaultベアラを経由してUEまで到達する。
【符号の説明】
【００６２】
１…ベアラ紐付管理部
【図１】
0005841468.tif 000002
【図２】
0005841468.tif 000003
【図３】
0005841468.tif 000004
【図４】
0005841468.tif 000005
【図５】
0005841468.tif 000006
【図６】
0005841468.tif 000007
【図７】
0005841468.tif 000008
【図８】
0005841468.tif 000009
【図９】
0005841468.tif 000010
【図１０】
0005841468.tif 000011
【図１１】
0005841468.tif 000012