JP2015041906A - ルーティングエージェント装置 - Google Patents
ルーティングエージェント装置 Download PDFInfo
- Publication number
- JP2015041906A JP2015041906A JP2013172325A JP2013172325A JP2015041906A JP 2015041906 A JP2015041906 A JP 2015041906A JP 2013172325 A JP2013172325 A JP 2013172325A JP 2013172325 A JP2013172325 A JP 2013172325A JP 2015041906 A JP2015041906 A JP 2015041906A
- Authority
- JP
- Japan
- Prior art keywords
- pcrf
- dra
- message
- terminal
- call information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
【課題】3gppが規定するVoLTEの場合、PCRF内部の情報が失われると、そのPCRFに収容されていた端末は、一度PDN Connectionを解放しない限り音声通話の発着信ができない。【解決手段】PCRFの障害により音声通信の発着信不可をDRAが検出する。DRAは、音声通信の発着信のシーケンスを一時中断し、自身が持つ情報をPCRFに通知して、PCRFに情報の再構築を促す。PCRFの情報再構築完了後に、音声通信の発着信シーケンスを再開する。【選択図】図18
Description
本発明は、3gpp(3rd Generation Partnership Project)で規定されている移動体通信網のコアネットワークの中のDiameterメッセージを他の装置に転送するルーティングエージェント装置に係り、同一の通信システム内の別の装置に障害が発生したときの通信システムを復旧するルーティングエージェント装置に関する。
3gppではLTE(Long Term Evolution)と呼ばれる移動体通信網が規定されている。そして、LTEの通信網上で音声通信を実現する方式として、VoLTE(Voice over LTE)が規定されている。VoLTEはLTE上で、SIP(Session Initiation Protocol)の技術を用いて音声通信を実現している。
先行特許文献1は、PCRF(Policy Charging and Rules Function:優先制御・課金設定部)の障害に関する開示があるが、VoLTEの構成の時に発生する音声発着信不可能に関する問題については記載されていない。
PCRFは、他装置からメッセージを受信する度に、呼情報の追加・削除・変更を実施する。そのため、頻繁に書き換わる呼情報をHDD等、アクセス速度の遅いデバイスに記録するのは現実的ではない。その結果、PCRFは、呼情報について、アクセス速度が高速なメモリ上のみに格納させる。呼情報をメモリ上のみに存在すると、PCRF400に障害が発生した場合、呼情報が失われる。PCRFの呼情報が失われた場合、VoLTEの構成では、PCRFに収容されていた端末の音声発着信が不可能になる。
本発明は、この課題に鑑みてなされたもので、優先制御・課金設定部に情報が喪失するような障害が発生しても、端末による音声通信の発着信が可能とするルーティングエージェント装置を提供することにある。
呼情報を格納する呼情報格納部と、発信メッセージを一時格納する発信メッセージ格納部と、優先制御・課金設定部を含む対向装置とメッセージを交換する信号処理部と、を含んで構成されたルーティングエージェント装置であって、発信メッセージを送信した優先制御・課金設定部から受信した応答メッセージがエラー応答のとき、呼情報格納部からセッション情報を取得して、優先制御・課金設定部へセッション確立メッセージを送信し、優先制御・課金設定部から送信したセッション確立メッセージに対する応答メッセージを受信したとき、発信メッセージ格納部から発信メッセージを取得して、優先制御・課金設定部へ発信メッセージを再送するルーティングエージェント装置により、達成できる。
本発明によれば、PCRFに情報が喪失するような障害が発生しても、端末による音声通信の発着信が可能になる。
以下、図面を参照して本発明の実施の形態について説明する。
図1を参照して、VoLTEシステムの構成を説明する。図1において、VoLTEシステム1000は、端末100と、S−GW(Serving Gateway)200と、P−GW(PDN Gateway)300と、PCRF400と、DRA500と、電話網600と、SIPサーバ700と、AF800(Application Function)と、から構成されている。
端末100は、通信を実施するために、PDN Connectionを確立する。PDN Connectionは、S−GW(Serving Gateway)200と、P−GW(PDN Gateway)300とによって構築される。
図1を参照して、VoLTEシステムの構成を説明する。図1において、VoLTEシステム1000は、端末100と、S−GW(Serving Gateway)200と、P−GW(PDN Gateway)300と、PCRF400と、DRA500と、電話網600と、SIPサーバ700と、AF800(Application Function)と、から構成されている。
端末100は、通信を実施するために、PDN Connectionを確立する。PDN Connectionは、S−GW(Serving Gateway)200と、P−GW(PDN Gateway)300とによって構築される。
また、PDN Connectionの確立に必要な装置として、PCRF(Policy Charging and Rules Function)400がある。PCRF400は、サービスのポリシー制御、および、課金制御を行う。また、同一のネットワーク内部に複数のPCRF400が存在した場合に、PCRF400が送受信するメッセージを適切な宛先に転送する装置として、DRA(Diameter Routing Agent)500が存在する。DRA500は、内部で端末100毎に収容先のPCRF400を保持する。DRA500は、各端末100からの要求に応じて、それぞれの端末100が収容されているPCRF400に対してメッセージの転送を行う。
PDN Connectionは、1個または複数のベアラから構成される。端末100が通信に用いるパケットは、必ずいずれかのベアラを経由する。VoLTEでは、少なくとも、PDN Connectionの中に、SIP信号用ベアラと音声通信用ベアラの2個のベアラが存在する。
SIP信号用のベアラには、電話の発信および着信の時に用いるSIPの信号メッセージが流れる。端末100は、SIP信号用ベアラを経由してSIPサーバ700と通信する。一方、音声通信用ベアラには、端末の利用者が会話している音声データが流れる。端末100は、音声通信用ベアラを経由して、電話網600と通信する。
各ベアラにはQoSが設定されており、音声通信の品質を保証している。QoSの情報とは、(1)利用可能な最大の帯域、(2)パケットロス率、(3)許容パケット転送遅延時間の集合体である。それぞれのベアラの生成、解放、設定するQoSは、PCRF400が管理している。PCRF400は、DRA500を経由して、S−GW200、P−GW300,AF800と通信する。
AF800は、SIPサーバ700から情報を得て、VoLTEの実現に必要な、ベアラの追加および削除の要求をPCRF400に対して送信する。端末100、S−GW200、P−GW300、SIPサーバ700、AF800、DRA500、PCRF400は、それぞれ呼情報がメモリ上に展開されている。呼情報には、SIPに関する呼情報とPDN Connectionに関する呼情報の2種類が存在する。端末100は、SIPに関する呼情報110とPDN Connectionに関する呼情報120の2種類の呼情報を保持する。
S−GW200は、呼情報210を保持する。P−GW300は、呼情報310を保持する。PCRF400は、QoS設定ポリシー410と、呼情報420を保持する。DRA500は、呼情報510を保持する。SIPサーバ700は、呼情報710を保持する。AF800は、呼情報810を保持する。
図2を参照して、端末100が保持している呼情報120の内容を説明する。図2において、呼情報120は、IMSI(International Mobile Subscriber Identity)と、端末のIPとの2種類のデータから構成されている。IMSIは、移動体通信網の加入者に割り当てられている一意な識別番号である。IMSIは、端末100の中に格納されている。端末のIPは、端末100がPDN Connectionを経由して通信を実施する時に用いるIPアドレスである。端末のIPは、端末100が電源を入れてPDN Connectionを確立する時にP−GW300より割り当てられるIPアドレスである。
図3を参照して、端末100が保持している呼情報110の内容を説明する。図3において、呼情報110は、通話先のIPとSIPサーバのIPとから構成されている。通話先のIPは、VoLTEの発信を行った時に、SIPサーバ700より通知される。SIPサーバ700のIPは、端末100が電源を入れてPDN Connectionを確立する時にP−GW300より通知されるIPアドレスである。
図4を参照して、S−GW200が保持するPDN Connectionに関する呼情報210を説明する。図4において、呼情報210は、端末のIMSIと、端末のIPと、Gxx SessionIDとから構成されている。端末のIMSIは、端末100が電源を入れてPDN Connectionを確立する時に端末より通知される。端末のIPは、PDN Connectionの確立の時にP−GW300より払い出されて通知されるIPアドレスである。Gxx SessionIDは、PDN Connectionの確立の時にS−GW200の内部でその都度生成されるIDである。
図5を参照して、P−GW300が保持するPDN Connectionに関する呼情報310を説明する。図5において、呼情報310は、端末のIMSIと、端末のIPと、Gx SessionIDとから構成されている。端末のIMSIは、PDN Connection2を確立する時にS−GW200を経由して、端末100から通知される。端末のIPは、P−GW300の内部で払い出されるIPアドレスである。Gx SessionIDは、PDN Connectionの確立の時に、P−GW300の内部でその都度生成されるIDである。
図6を参照して、SIPサーバ700が保持するSIPに関する呼情報710を説明する。図6において、呼情報710は、端末のIPと、通話状態と、通話先のIPとから構成されている。端末のIPは、端末100からアクセスを受けたタイミングで記録する。通話状態は、端末100が通話中であるか、待ち受け中であるかを記録する。もし、通話状態が通話中であれば、通話先のIPに情報が記録されている。
図7を参照して、AF800が保持するPDN Connectionに関する呼情報810を説明する。図7において、呼情報710は、端末のIPと、Rx SessionIDとから構成されている。端末のIPは、SIPサーバより通知される。Rx SessionIDは、AF800が該当の呼に関して初めてDRA500を経由してPCRF400と通信をするタイミングでAF800の内部で生成される。
DRA500は、PCRF400と他装置のDiameter通信を中継する装置である。DRA500は、PCRF400が複数台存在する時に、端末100単位に収容先のPCRF400を決定する。収容先のPCRF400を決定後、DRA500は、その端末100に関連するメッセージについて、全て収容先のPCRF400に転送する。DRA500は、PDN Connectionに関する呼情報510を保持している。
図8を参照して、呼情報510の内容を説明する。図8において、呼情報510は、端末のIMSIと、端末のIPと、収容先PCRFと、Gxx SessionIDと、Gx SessionIDと、Rx SessionIDとから構成されている。端末のIMSIは、PDN Connectionを確立するとき、S−GW200およびP−GW300から送信される。端末のIPは、PDN Connectionを確立するとき、P−GWから送信される。収容先PCRFは、端末100が初めてPDN Connectionを確立するタイミングでDRA500の内部で割り当てを実施する。Gxx SessionIDは、PDN Connectioを確立するタイミングでS−GW200より送信される。Gx SessionIDは、PDN Connectionを確立するタイミングでP−GW300より送信される。Rx SessionIDは、SIPセッションを確立するタイミングでAF800より通知される。
PCRF400は、サービスのポリシー制御および課金制御を行う装置である。PCRF400は、QoS設定ポリシー410と、PDN Connectionに関する呼情報420とを保持している。QoS設定ポリシー410は、PDN Connectionの各ベアラに設定すべきQoSの情報が保存されている。QoS設定ポリシー410は、LTEのネットワークの保守者により設定される。PCRF400は、PDN Connectionの確立処理および音声通信用ベアラを確立する処理の中で、QoS設定ポリシー410から、各ベアラに対応するQoSの設定を読み込む。PCRF400は、S−GW200とP−GW300に対して送信するベアラ確立のメッセージの中に、QoSの設定を含める。
QoS設定ポリシー410は、頻繁に書き換わるデータでは無いので、HDDに記録されている。このため、QoS設定ポリシー410は、障害が発生しても情報は残存する。
図9を参照して、呼情報420を説明する。図9において、呼情報420は、端末のIMSIと、端末のIPと、Gxx SessionIDと、Gx SessionIDと、Rx SessionIDと、QoSとから構成されている。端末のIMSIは、PDN Connectionを確立するタイミングで、S−GW200およびP−GW300から送信される。端末のIPは、PDN Connectionを確立する時にP−GWから送信される。Gxx SessionIDは、PDN Connectionを確立するタイミングでS−GW200より送信される。Gx SessionIDは、PDN Connectionを確立するタイミングでP−GW300より送信される。Rx SessionIDは、SIPセッションを確立するタイミングでAF800より通知される。QoSは、通信速度であり、PDN Connectionを確立するタイミングで、PCRF400の内部に保存されているQoS設定ポリシー410を元にして、決定される。
図10を参照して、端末100の電源がOFFの状態のVoLTEシステム1000Aの構成を説明する。図10において、VoLTEシステム1000は、端末100に電源が入っていない場合、PDN Connetionと音声通信用ベアラ、SIP信号用ベアラは、いずれも未確立である(図10で破線で図示)。PDN Connectionが未確立のため、端末100の内部に保存されているPDN Connection関連の呼情報120とSIP関連の呼情報110とは、存在しない(破線で図示)。同様にS−GW200の内部にある呼情報210、P−GW300の内部にある呼情報310、SIPサーバ700の内部にある呼情報710、AF800の内部にある呼情報810、DRA500の内部にある呼情報510、PCRF400の内部にある呼情報420も存在しない(破線で図示)。ただし、PCRF400の内部にある、QoS設定ポリシー410は、呼に依存しない設定データであるため、存在する(実線で図示)。
図11を参照して、端末100の電源がOFFの状態から、電源をONにしてPDN Connectionを確立する時にPCRF400が実施するセッション確立の処理を説明する。図11において、PCRF400は、セッション確立要求のDiameterメッセージを受信する(S1401)。PCRF400は、受信したDiameterメッセージの中に含まれるIMSIの情報をキーにして、呼情報を検索する(S1402)。検索の結果から、PCRF400は、該当するIMSIの呼情報を保持しているか判断する(S1403)。呼情報を保持していれば(YES)、PCRF400は、該当する呼情報を更新して(S1404)、終了する。
ステップ1403で該当するIMSIの呼情報を持っていなければ(NO)、PCRF400は、呼情報にレコードを追加する(S1405)。PCRF400は、内部に保存されているQoS設定ポリシー410を読み込む(S1406)。PCRF400は、読み込んだQoS設定ポリシーの情報を元にして、呼情報にQoSの情報を追記して(S1407)、終了する。
図12を参照して、端末100の電源がOFFの状態から、電源をONにしてPDN Connectionを確立するまでの、端末、S−GW、P−GW、DRA、PCRF、AF、SIPサーバ間のシーケンスを説明する。図12において、端末100は、S−GW200に対してPDN Connection確立要求を送信する(S501)。端末100は、この中にIMSIの情報を含める。S−GW200は、DRA500に対してGxx Session確立要求を送信する(S502)。S−GW200は、この中に、端末100から送られてきたIMSIと自身の内部で生成したGxx SessionIDを含める。DRA500は、PCRF400の選択処理を実施する(S503)。DRA500は、選択処理によって選択したPCRF400に対してGxx Session確立要求を送信する(S504)。PCRF400は、図11のフローチャートに示す動作に従ってセッション確立の処理を実行する(図示省略)。
S−GW200は、ステップ502の処理が完了した後、続けてP−GW300に対してPDN Connection確立要求を送信する(S505)。P−GW300は、DRA500に対してGx Session確立要求を送信する(S506)。P−GW300は、確率要求の中に、端末100に割り当てたIPアドレスの情報を含める。DRA500は、Gx Session確立要求をPCRF400に転送する(S507)。PCRF400は、Gxx Session確立要求と、Gx Session確立要求の2個の要求が届いた時点で、QoSの割り当て処理を実施する(図示省略)。QoSの割り当て処理が完了した後、PCRF400は、Gxx Session確立応答をDRA500に対して送信する(S508)。DRA500は、PCRF400から送信されたGxx Session確立応答をS−GW200に対して転送する(S509)。
また、PCRF400は、ステップ508の後、続けてGx Session確立応答をDRA500に送信する(S510)。PCRF400は、確立応答メッセージの中に、QoSの情報を含める。DRA500は、Gx Session確立応答をP−GW300に対して転送する(S511)。P−GW300は、Gx Session確立応答を受信後、S−GW200に対して、PDN Connection確立応答を送信する(S512)。P−GW300は、確立応答メッセージの中に端末のIPとSIPサーバのIPを含める。S−GW200は、PDN Connection確立応答を受信後、そのメッセージを端末100に転送する(S513)。
ここまでのシーケンスで、PDN ConnectionおよびSIP信号用ベアラは確立される。続いて端末100は、SIP Sessionの確立シーケンスを開始する。端末100は、SIP信号用ベアラを用いてSIPサーバ700に対してSIP登録要求を送信する(S514)。SIPサーバ700は、登録要求を受信したら、AF800に対してSIP Session登録要求を送信する(S515)。AF800は、SIP Session登録要求を受信したタイミングでRx Session確立要求をDRA500に対して送信する(S516)。AF800は、Rx Session確立要求の中に端末のIPを含める。DRA500は、Rx Session確立要求を受信後、端末100のIPの情報を元にして該当する端末100を収容しているPCRF400を探す。ここでは、収容先のPCRF400を発見できたので、DRA500は、Rx Session確立要求をPCRF400に対して転送する(S517)。PCRF400は、Rx Session確立要求を受信後、Rx Session確立応答をDRA500に対して返す(S518)。DRA500は、Rx Session確立応答をAF800に対して転送する(S519)。AF800は、Rx Session確立応答を受信したとき、SIPサーバ700に対して、SIP Session登録応答を送信する(S520)。SIPサーバ700は、SIP Session登録応答を受信したとき、端末100に対してSIP登録応答を送信する(S521)。
図13を参照して、図12のステップ503の動作の詳細を説明する。図13において、DRA500は、S−GW200またはP−GW300からDiameterメッセージを受信する(S1301)。DRA500は。受信したDiameterメッセージの中に含まれるIMSIをキーにして、呼情報510の中を検索して、IMSIが既知のIMSIであるかの判定を実施する(S1302)。既知のIMSIであった場合(YES)、DRA500は、呼情報510から選択先のPCRFの情報を取得して(S1303)、終了るる。
Diameterメッセージの中に含まれるIMSIが既知でなければ(S1302:NO)、DRA500は、内部に保存されているPCRF情報の中から任意の一台を選択する(S1304)。PCRFを選択後、DRA500は、呼情報510に選択したPCRFの情報を追加格納して(S1305)、終了する。
図14を参照して、端末100の電源をONにしたときのシーケンスが完了した状態でのVoLTEシステムの構成を説明する。図14において、VoLTEシステム1000BのPDN ConnectionおよびSIP信号用ベアラは、確立済みである。一方、音声通信用ベアラは、未確立である。端末100は、SIP Sessionに関する呼情報110とPDN Connectionに関する呼情報120が生成されている。SIPサーバ700も、SIP Sessionに関する呼情報710が生成されている。S−GW200、P−GW300、AF800、DRA500、PCRF400にも、それぞれPDN Connectionに関する呼情報が生成されている。
図15を参照して、待ち受け状態から音声通話を開始するために音声通信用ベアラを確立するまでのシーケンスを説明する。図15において、端末100は、SIPサーバ700に対してSIP信号用ベアラを経由してVoLTE発信メッセージを送信する(S601)。SIPサーバ700は、端末100に対して呼び出し中を送信する(S602)。SIPサーバ700は、通話先を呼び出す処理を実行する(S603)。SIPサーバ700は、通話先から準備完了信号を受信する(S604)。SIPサーバ700は、AF800に対してVoLTE発信のメッセージを送信する(S605)。AF800は、DRA500に対してVoLTE発信のメッセージを送信する(S606)。DRA500は、PCRF400に対してVoLTE発信のメッセージを転送する(S607)。PCRF400は、VoLTE発信のメッセージを受信後、VoLTEの発信応答メッセージをDRA500に返す(S608)。DRA500は、VoLTEの発信応答メッセージをAF800に対して転送する(S609)。AF800は、SIPサーバ700に対してVoLTEの発信応答メッセージを送信する(S610)。
PCRF400は、DRA500に対してベアラ確立要求を送信する(S611)。DRA500は、ベアラ確立要求をP−GW300に転送する(S612)。P−GW300は、DRA500からのベアラ確立要求を受けて、S−GW200に対してベアラの確立要求を送信する(S613)。S−GW200は、ベアラ確立要求を受けて、ベアラ確立応答をP−GW300に対して返す(S614)。P−GW300は、DRA500に対してベアラ確立応答を送信する(S615)。DRA500は、ベアラ確立応答をPCRF400に対して転送する(S616)。以上のシーケンスにより、音声通話用のベアラが成立する。
SIPサーバ700は、端末100に対して呼び出し成功のメッセージを送信する(S617)。端末100は、呼び出し成功のメッセージを受信後、音声通話を開始する(S618)。
図16を参照して、VoLTEシステムの問題が発生する場合のシーケンスを説明する。図16において、初期の状態では、S−GW200、P−GW300、DRA500、PCRF400、AF800は、PDN Connectionに関する呼情報が保持されている。その状態でPCRF400に障害が発生したとする(S701)。その後、PCRF400は、障害から回復する(S702)。しかし、PCRF400は、障害から回復しても、障害のタイミングで喪失した呼情報420を復元する事は出来ない。そのため、PCRF400の呼情報420は存在しない(破線で示す)ままとなる。
この状態で端末100は、SIPサーバ700に対してVoLTEの発信を実施する(S703)。SIPサーバ700は、端末100に対して呼び出し中を送信する(S704)。SIPサーバ700は、VoLTE発信のメッセージを受けて、AF800に対して、VoLTE発信のメッセージを送信する(S705)。AF800は、SIPサーバ700からの信号を受けてDRA500に対して、VoLTE発信のメッセージを送信する(S706)。DRA500は、AF800から送信されてきた、VoLTE発信のメッセージをPCRF400に転送する(S707)。PCRF400は、DRA500から送信されてきたVoLTE発信のメッセージに含まれるRx SessionIDをキーにして、呼情報420から関連するPDN Connectionの情報を検索する。
PCRF400の呼情報420の内容が消失している場合、検索を実行しても対応するPDN Connectionの情報が見つからずにエラーとなる(S708)。その結果、PCRF400は、DRA500に対してエラー応答を送信する(S709)。DRA500は、PCRF400からのエラー応答をAF800に転送する(S710)。AF800は、エラー応答をDRA500から受信したら、SIPサーバ700に対してエラー応答を送信する。(S711)。SIPサーバ700は、AF800からのエラー応答を受けて、端末100に対して。VoLTE発信失敗のメッセージを送信する(S712)。
ステップ707でPCRF400がエラーを返すのはPCRF400の呼情報210に関連するRx SessionIDが存在しないからである。
ステップ707でPCRF400がエラーを返すのはPCRF400の呼情報210に関連するRx SessionIDが存在しないからである。
図17を参照して、この時のPCRF400の動作の詳細を説明する。図17において、PCRF400は、DRA500を経由してAF800からVoLTEの発信メッセージを受信する(S1201)。このメッセージの中には、AF800が払い出したRx SessionIDが含まれている。PCRF400は、Rx SessionIDをキーにして、該当する端末100が確立したPDN Connectionに関する情報を呼情報420から検索する(S1202)。PCRF400は、検索で発見できたか判定する(S1203)。PCRF400が呼情報420の中から該当するRx SessionIDを保持するPDN Connectionに関する情報を発見できなかったとき(NO)、PCRF400は、DRA500に対してエラー応答を送信して(S1204)、終了する。ステップ1204において、PCRF400がエラー応答を返すために、結果的に端末100は、音声発信をできない。
ステップ1203において、PCRF400が呼情報420の中から該当するRx SessionIDを保持するPDN Connectionに関する情報を発見できたら(YES)、PCRF400は、VoLTE発信応答をDRA500に対して送信する(S1205)。PCRF400は、呼情報の中に設定されているGx SessionIDを用いて、P−GWに対してベアラ確立要求を送信して(S1206)、終了する。
図18を参照して、DRA装置の構成を説明する。図18において、DRA500Aは、呼情報510と、PCRF一覧520と、VoLTE発信メッセージ一時格納領域530と、信号処理部540とから構成されている。
呼情報510は、PDN Connectionの呼情報を格納する。呼情報510は、図9に示すテーブルの内容が保存されている。PCRF一覧520は、DRA500を利用するオペレータにより設定される情報である。PCRF一覧520は、DRA500が選択するべきPCRFの一覧が保存されている。
信号処理部540は、DRA500の対向装置であるS−GW200、P−GW300、PCRF400、AF800とDiameterの通信を実施する。信号処理部540は、Diameter信号を処理する毎に、呼情報510の内容を更新する。信号処理部540は、Diameter信号を処理する。
DRA500Bは、VoLTE発信メッセージ一時格納領域530を保持する。VoLTE発信メッセージ一時格納領域530は、Diameter Sessionを確立するまでの間、AF800より送信されてきたDiameter信号を一時的に格納する。
図19を参照して、VoLTE発信メッセージ一時格納領域530の使い方を説明する。図19は、DRA500AがAF800からVoLTE発信のためのDiameterメッセージを受信したときのフローチャートである。図19において、DRA500Aは、AF800から送られてきたDiameterメッセージの受信処理を実施する(S901)。DRA500Aは、AF800から送られて来たDiameterメッセージの中をそのまま、VoLTE発信メッセージ一時格納領域530にコピーする(S902)。DRA500Aは、PCRF400に対してVoLTE発信のメッセージを送信して(S903)、終了する。
図20を参照して、DRAがPCRFからVoLTE発信のDiameterメッセージに対する応答のDiameterメッセージを受信した場合のDRAの処理を説明する。図20において、DRA500Aは、PCRF400からVoLTE発信のDiameterメッセージに対する応答のDiameterメッセージを受信する(S1001)。DRA500Aは、受信したDiameterメッセージの内容を解析する。DRA500Aは、受信したDiameterメッセージがエラー応答である判定する(S1002)。正常応答であると判断した場合(NO)、DRA500Aは、AF800にPCRF400から受信したDiameterメッセージを転送する(S1003)。DRA500Aは、VoLTE発信メッセージ一時格納領域530から、該当するDiameterメッセージの情報を削除して(S1004)、終了する。
ステップ1002でエラー応答だったとき(YES)、DRA500は、呼情報510からGx Session、Gxx Session、Rx Sessionの情報を呼び出す(S1005)。DRA500は、Gx Session、Gxx Session、Rx Sessionをそれぞれ確立する為のDiameterメッセージをPCRF400に対して送信して(S1006)、終了する。
PCRF400に対して、各Sessionの確立メッセージの送信が終了した時点で、DRA500AがPCRF400からVoLTE発信のDiameterメッセージに対する、応答のDiameterメッセージを受信した場合の処理は終了する。
図21を参照して、DRAがPCRFからセッション確立完了のDiameterメッセージを受信したときのDRAの処理を説明する。図21において、DRA500Aは、PCRF400からDiameterセッション確立要求に対する応答のDiameterメッセージを受信する(S1101)。DRA500Aは、自身が送信したDiameterセッションの確立要求に対する応答メッセージである判定する(S1102)。他装置が送信したDiameterメッセージに対する確立応答メッセージであれば(NO)、DRA500Aは、そのメッセージを送信した装置に対してDiameterメッセージを転送して(S1103)、終了する。
ステップ1102において、DRA500Aが送信したセッション確立要求に対する応答であったとき(YES)、DRA500Aは、VoLTE発信メッセージを一時格納領域530から呼び出す(S1104)。DRA500Aは、VoLTE発信メッセージ一時格納領域530から呼び出したDiameterメッセージをPCRF400に対して送信して(S1105)、終了する。
図22を参照して、VoLTEシステムの処理シーケンスを説明する。図22において、正常な状態では、S−GW200、P−GW300、DRA500A、PCRF400、AF800にPDN Connectionに関する呼情報が保持されている。この状態で、PCRF400に障害が発生する(S801)。その後、PCRF400は、障害から復旧する(S802)。PCRF400は、障害から復旧したためサービスを再開する。しかし、PCRF400の内部に保存されている呼情報420の内容は失われている。
この状態で、端末100からSIP信号用ベアラを経由して、SIPサーバ700に対してVoLTE発信のメッセージが送信される(S803)。SIPサーバ700は、端末100に対して呼び出し中のSIPメッセージを送信する(S804)。SIPサーバ700は、端末100からのVoLTE発信メッセージを受けて、AF800に対してVoLTE発信のメッセージを送信する(S805)。AF800は、DRA500Aに対して、VoLTE発信に関するDiameterメッセージを送信する(S806)。DRA500Aは、図19のフローチャートに示す動作を実行し、PCRF400に対してVoLTE発信に関するDiameterメッセージを転送する(S807)。PCRF400は、図17のフローチャートに示す動作を実行し、DRA500Aに対してエラー応答を送信する(S808)。DRA500Aは、図20のフローチャートに示す動作を実行し、PCRF400に対してDiameterセッションを確立する為のDiameterメッセージを送信する(S809)。PCRF400がこのメッセージを受信した結果、PCRF400は、図11のフローチャートに示す処理が実行さる。そして、セッション確立の処理が実行される事により、PCRF400の内部で呼情報420が再構築される。
PCRF400は、セッションの確立応答を送信する(S810)。DRA500Aは、図21のフローチャートに示す動作を実行し、PCRF400に対してVoLTE発信のDiameterメッセージを送信する(S811)。PCRF400は、図17のフローチャートに示す動作を実行し、VoLTE発信応答を送信する(S812)。DRA500Aは、VoLTE発信応答のDiameterメッセージをAF800に対して転送する(S813)。AF800は、VoLTE発信応答のDiameterメッセージを受けて、SIPサーバ700に対して、VoLTE発信応答を送信する(S814)。
PCRF400は、ステップ811でVoLTE送信した後に、ベアラ確立要求もDRA500Aに対して送信する(S815)。DRA500Aは、ベアラ確立要求のDiameterメッセージを受信したら、それをP−GW300に転送する(S816)。P−GW300は、DRA500Aからのベアラ確立要求を受けて、S−GW200に対してベアラ確立要求を送信する(S817)。S−GW200は、P−GW300に対してベアラ確立応答を送信する(S818)。P−GW300は、DRA500Aに対してベアラ確立応答のDiameterメッセージを送信する(S819)。DRA500Aは、ベアラ確立応答のDiameterメッセージをPCRF400に対して転送する(S820)。ここまでの処理で、音声通話用のベアラが成立する。
SIPサーバ700は、端末100に対して呼び出し成功のSIPメッセージを送信する(S821)。端末100は、呼び出し成功のSIPメッセージを受けて、音声通信を開始する(S822)。
本実施例によれば、PCRFに情報が喪失するような障害が発生しても、端末による音声通信の発着信が可能になる。
ルーティングエージェント装置(DRA)は、ソフトウェアで実現しても、ハードウェアで実現してもよい。
ルーティングエージェント装置(DRA)は、ソフトウェアで実現しても、ハードウェアで実現してもよい。
100…移動端末、110…呼情報、120…PDN Connectionの呼情報、200…S−GW、210…PDN Connectionの呼情報、300…P−GW、310…PDN Connectionの呼情報、400…PCRF、410…QoSの設定ポリシー、420…PDN Connectionの呼情報、500…DRA、510…PDN Connectionの呼情報、520…PCRF一覧、530…VoLTE発信メッセージ一時格納領域、540…信号処理部、600…電話網、700…SIPサーバ、710…SIPの呼情報、800…AF、810…PDN Connectionの呼情報、1000…VoLTEシステム。
Claims (2)
- 呼情報を格納する呼情報格納部と、発信メッセージを一時格納する発信メッセージ格納部と、優先制御・課金設定部を含む対向装置とメッセージを交換する信号処理部と、を含んで構成されたルーティングエージェント装置であって、
前記発信メッセージを送信した前記優先制御・課金設定部から受信した応答メッセージがエラー応答のとき、前記呼情報格納部からセッション情報を取得して、前記優先制御・課金設定部へセッション確立メッセージを送信し、
前記優先制御・課金設定部から送信した前記セッション確立メッセージに対する応答メッセージを受信したとき、前記発信メッセージ格納部から前記発信メッセージを取得して、前記優先制御・課金設定部へ前記発信メッセージを再送することを特徴とするルーティングエージェント装置。 - 請求項1に記載のルーティングエージェント装置であって、
前記セッション確立メッセージは、Gx Sessionと、Gxx Sessionと、Rx Sessionとをそれぞれ確立するメッセージであることを特徴とするルーティングエージェント装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013172325A JP2015041906A (ja) | 2013-08-22 | 2013-08-22 | ルーティングエージェント装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013172325A JP2015041906A (ja) | 2013-08-22 | 2013-08-22 | ルーティングエージェント装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2015041906A true JP2015041906A (ja) | 2015-03-02 |
Family
ID=52695822
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013172325A Pending JP2015041906A (ja) | 2013-08-22 | 2013-08-22 | ルーティングエージェント装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2015041906A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108259327A (zh) * | 2016-12-29 | 2018-07-06 | ***通信集团河南有限公司 | VoLTE业务恢复方法、***及装置 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011099523A1 (ja) * | 2010-02-10 | 2011-08-18 | 日本電気株式会社 | Pcrfと障害復旧方法とシステム |
-
2013
- 2013-08-22 JP JP2013172325A patent/JP2015041906A/ja active Pending
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011099523A1 (ja) * | 2010-02-10 | 2011-08-18 | 日本電気株式会社 | Pcrfと障害復旧方法とシステム |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108259327A (zh) * | 2016-12-29 | 2018-07-06 | ***通信集团河南有限公司 | VoLTE业务恢复方法、***及装置 |
CN108259327B (zh) * | 2016-12-29 | 2020-11-06 | ***通信集团河南有限公司 | VoLTE业务恢复方法、***及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7481007B2 (ja) | ノード装置及び通信端末のユーザデータを中継するノード装置の方法 | |
WO2017054178A1 (zh) | 保持业务连续性的方法、控制面网关和移动管理网元 | |
US11284312B2 (en) | User equipment and communication control method performed by user equipment | |
EP3739965A1 (en) | User device | |
KR101364290B1 (ko) | 향상된 성능을 위한 서빙 게이트웨이의 관리 | |
EP3740026A1 (en) | User device | |
KR20210116555A (ko) | 향상된 up 기능 요청된 pfcp 연관 해제 | |
CN101588326A (zh) | 网关控制会话和Gx会话关联的方法、设备和*** | |
EP2976867B1 (en) | Re-routing of diameter commands for correct charging | |
EP3214801B1 (en) | Aggregation of congestion information | |
US8737202B2 (en) | Automatic connection recovery | |
EP3043598A1 (en) | Routing method between base stations, serving gateway and base station | |
JP2015041906A (ja) | ルーティングエージェント装置 | |
CN103379479A (zh) | 一种确定用户标识和通知参数信息的方法、***及设备 | |
CN109451543B (zh) | 信息处理方法及装置 | |
JP7247477B2 (ja) | 制御装置、課金取得方法、課金取得プログラムおよび課金システム | |
JP5756705B2 (ja) | ネットワーク再接続システム | |
JP5533300B2 (ja) | ルーティング管理システム、その処理方法及びプログラム | |
WO2018148861A1 (zh) | 下行数据的传输方法及装置 | |
KR20190045759A (ko) | 세션 관리 방법 및 세션 관리 장치 | |
KR102340394B1 (ko) | Gtp-u 프로토콜을 사용하는 이동통신 네트워크에서의 오과금 방지 방법 및 시스템 | |
JP5740229B2 (ja) | 移動通信方法及び呼セッション制御サーバ装置 | |
KR101735382B1 (ko) | Mme 장애 시 착신 통화 서비스를 제공하는 방법 및 장치 | |
WO2014125778A1 (ja) | 移動通信システム、制御装置、移動端末装置、通信制御方法、及び非一時的なコンピュータ可読媒体 | |
KR101772503B1 (ko) | Mme, s-gw, p-gw 및 시스템 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20160113 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20160930 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20161011 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20170411 |