JP2014171012A - Ipマルチメディアサブシステム - Google Patents

Ipマルチメディアサブシステム Download PDF

Info

Publication number
JP2014171012A
JP2014171012A JP2013040692A JP2013040692A JP2014171012A JP 2014171012 A JP2014171012 A JP 2014171012A JP 2013040692 A JP2013040692 A JP 2013040692A JP 2013040692 A JP2013040692 A JP 2013040692A JP 2014171012 A JP2014171012 A JP 2014171012A
Authority
JP
Japan
Prior art keywords
server
data
user
cscf
user data
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
Application number
JP2013040692A
Other languages
English (en)
Inventor
Masaaki Kanetani
正章 金谷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oki Electric Industry Co Ltd
Original Assignee
Oki Electric Industry Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Oki Electric Industry Co Ltd filed Critical Oki Electric Industry Co Ltd
Priority to JP2013040692A priority Critical patent/JP2014171012A/ja
Publication of JP2014171012A publication Critical patent/JP2014171012A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

【課題】P−CSCFサーバが障害状態から復旧した後においても、P−CSCFサーバの間での分散処理の負荷バランスを適正に調整可能なIPマルチメディアサブシステムを提供する。
【解決手段】
プロキシサーバの各々は、ユーザ端末から登録要求があったときに、ユーザ端末のユーザデータを記憶するユーザデータ記憶手段と、ユーザデータを記憶した後に、データサーバにユーザデータの複製を転送するユーザデータ転送手段と、を含み、データサーバは、プロキシサーバの各々から転送されたユーザデータの各々の内容を含むデータをバックアップデータとして記憶することを特徴とするIPマルチメディアサブシステム。
【選択図】図1

Description

本発明は、プロキシ制御機能(英語表記:Proxy-CSCF、以下、P−CSCFという)を有する複数のサーバを含むIPマルチメディアサブシステム(以下、IMSという)に関する。
IMSは、次世代ネットワークとして、固定通信や移動通信を問わず、音声や映像などを含むマルチメディアアプリケーションを、インターネットプロトコル(以下、IPという)をベースにしたパケット通信網で提供する中核的な技術である。IMSは、通常、セッション制御機能(英語表記:Call Session Control Function、以下、CSCFという)として、P−CSCF、問い合わせ制御機能(英語表記:Interrogating-CSCF、以下、I−CSCFという)、呼セッション制御機能(英語表記:Serving-CSCF、以下、S−CSCFという)の3種類の機能のうちいずれか少なくとも1つを有する複数のサーバを含んでいる。CSCFサーバの各々は、SIP(Session Initiation Protocol)を用いて互いにSIPメッセージをやり取りしてセッション制御を行っている(非特許文献1参照)。
ここで、P−CSCFサーバが複数配置されて冗長化されることによって、P−CSCFサーバに障害が発生したときには、他のP−CSCFサーバに切り替えてユーザ端末との通信の継続を図ることが知られている(非特許文献2参照)。複数のP−CSCFサーバの冗長化の構成には、複数のP−CSCFサーバのうちの1つが運用系、運用系以外のP−CSCFサーバが待機系であるアクティブ・スタンバイ構成と、複数のP−CSCFサーバを同時に運用系として稼働させてユーザ端末とのプロキシ制御を分散処理する負荷分散構成とがある。
P−CSCFサーバに障害が発生したときに、アクティブ・スタンバイ構成の場合には、それまで待機系であったP−CSCFサーバが運用系として稼働する。また、負荷分散構成の場合には、障害状態のP−CSCFサーバの代わりに当該障害状態のP−CSCFサーバ以外のP−CSCFサーバが当該障害状態のP−CSCFサーバの分の処理を実施する。
IETF RFC5626,"Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)" 3GPP TS23.380,"IMS Restoration Procedure"
しかしながら、アクティブ・スタンバイ構成では、必要とされるCPUやメモリなどの性能要件を満たすP−CSCFサーバが少なくとも2台必要である。また、負荷分散構成では、アクティブ・スタンバイ構成と比べて必要とされる性能要件は緩和されるが、ユーザ端末とP−CSCFサーバとの間で暗号化通信などの鍵交換が行われる。故に、あるユーザ端末と通信を行っていたP−CSCFサーバに障害が発生したとき、当該ユーザ端末が当該P−CSCFサーバ以外のP−CSCFサーバと通信を行おうとする場合には、改めて鍵交換の手順から始める必要がある。もしくは、当該P−CSCFサーバ以外のP−CSCFサーバに当該P−CSCFサーバと当該ユーザ端末との鍵情報が事前に引き継がれている必要がある。
さらに、障害が発生したP−CSCFサーバが復旧した後に、当該P−CSCFサーバが鍵情報を消失して保持していない場合には、当該P−CSCFサーバの代替処理をしていたP−CSCFサーバから鍵情報を引き継ぎなおすか、新たにユーザ端末と鍵交換を行わないとユーザ端末との通信を行うことができない。故に、ユーザ端末は、代替処理をしていたP−CSCFサーバを経由した通信を継続する。従って、当該P−CSCFサーバが復旧した後においても、P−CSCFサーバの間での分散処理の負荷バランスが障害前と同じ状態に戻らないという問題がある。
本発明は、上記した如き問題点に鑑みてなされたものであって、P−CSCFサーバが障害状態から復旧した後においても、P−CSCFサーバの間での分散処理の負荷バランスを適正に調整可能なIPマルチメディアサブシステムを提供することを目的としている。
請求項1に係る発明のIPマルチメディアサブシステムは、複数のユーザ端末の各々のユーザデータを保持して前記ユーザ端末毎に分散して中継する複数のプロキシサーバと、前記プロキシサーバの各々から転送された前記ユーザデータの内容を含むデータを保持するデータサーバと、を有するIPマルチメディアサブシステムであって、前記プロキシサーバの各々は、前記ユーザ端末から登録要求があったときに、前記ユーザ端末の前記ユーザデータを記憶するユーザデータ記憶手段と、前記ユーザデータを記憶した後に、前記データサーバに前記ユーザデータの複製を転送するユーザデータ転送手段と、を含み、前記データサーバは、前記プロキシサーバの各々から転送された前記ユーザデータの各々の内容を含むデータをバックアップデータとして記憶することを特徴としている。
本発明の実施例であるIMSの構成を示すブロック図である。 ユーザ端末が図1のIMSに登録する際の動作例のシーケンス図である。 図2の一部を詳細に説明するシーケンス図である。 図3の一部を詳細に説明するフローチャートである。 図1のIMSの全ユーザデータをリカバリする際のシーケンス図である。 図1のIMSのユーザデータを個別にリカバリする際のシーケンス図である。 図1のIMSの全ユーザデータをリカバリする際のシーケンス図である。 図1のIMSのユーザデータを個別にリカバリする際のシーケンス図である。
[実施例]
本発明の実施例であるIMSを図1乃至図8を参照しつつ説明する。
図1において、本発明によるIMS500はアクセス網600に接続され、アクセス網600の先には、ユーザ端末群100が接続されている。また、IMS500は、IP網700にも接続され、必要に応じて他の事業者のネットワークのサーバや他のIMSにも接続される。
ユーザ端末群100は、ユーザ端末101〜10xの複数の端末から構成される。ユーザ端末群100は、携帯電話、スマートフォン、PCなどの端末である。ユーザとユーザ端末との関係は、1対1に対応するとは限らないが、本実施例においては、説明を簡単にする故にユーザとユーザ端末とは1対1に対応するものとし、ユーザA〜Iの9人のユーザのユーザ端末101〜109がIMS500に登録されていることを前提に以下説明する。ユーザ端末群100は、アクセス網600を介してIMS500に接続する。アクセス網600は、IPなどのパケット通信網、無線LANや携帯電話網などのネットワークである。
IMS500は、P−CSCF#1サーバ210を含んでいる。P−CSCF#1サーバ210は、ユーザ端末群100が直接またはアクセス網600を介して通信するSIPサーバである。すなわち、P−CSCF#1サーバ210は、IMS500の中でユーザ端末群100と接し、ユーザ端末群100との間でSIPメッセージのやりとりを行う。
P−CSCF#1サーバ210は、ユーザ端末が通信するための暗号化アルゴリズム、IPsecで用いる鍵情報データ、当該ユーザ端末に関連する登録状態データ、通信状態データなどを含むユーザデータを保持している。すなわち、ユーザデータは、当該ユーザ端末とP−CSCF#1サーバ210との間において通信データの暗号化や完全性のチェック(データが改ざんされていないことの確認)が行われ、通信データの暗号化・完全性のチェックに使用される情報(アルゴリズム情報や通信先のアドレス情報、ポート情報など)を含んでいる。これらの情報は、当該ユーザ端末とP−CSCF#1サーバ210との間で通信を始めるときの手順でネゴシエートされる。
登録状態データは、P−CSCF#1サーバ210がS−CSCFサーバ420に送信するSUBSCRIBE信号、S−CSCFサーバ420がP−CSCF#1サーバ210に送信するNOTIFY信号に含まれる情報データである。また、登録状態データは、SUBSCRIBE信号を送信している情報とSUBSCRIBE信号の有効期限の情報とを含んでいる。
通信状態データは、例えば、呼び出し中や通信中などの状態データである。すなわち、INVITEやその応答(180 Ringing、200 OK)、BYE等、通信を開始して切断終了するまでに送受信する信号によって、通信状態データの内容が変化する。P−CSCF#1サーバ210がこれらの信号の送受信に応じて、通信状態データを生成する。
また、ユーザデータは、1つのユーザ端末(例えば、ユーザ端末101)が接続する1つのP−CSCFサーバ(例えばP−CSCF#1サーバ210)に記憶されていればよい。なお、P−CSCF#1サーバ210は、プロキシサーバとも称する。本実施例においては、IMS500は、P−CSCF#1サーバ210と各々が同一の構成を有するP−CSCF#2サーバ220、P−CSCF#3サーバ230を含んでおり、複数のP−CSCFサーバによって冗長化されてユーザ端末毎にプロキシ制御を分散処理する負荷分散構成である。また、P−CSCFサーバは、図示した数に限定されず、複数配置されていればよい。
本実施例では、表1に示すように、P−CSCF#1サーバ210は、ユーザAのユーザデータDA、ユーザDのユーザデータDD、ユーザIのユーザデータDIを保持している。P−CSCF#2サーバ220は、ユーザBのユーザデータDB、ユーザGのユーザデータDG、ユーザHのユーザデータDHを保持している。P−CSCF#3サーバ230は、ユーザCのユーザデータDC、ユーザEのユーザデータDE、ユーザFのユーザデータDFを保持している。
Figure 2014171012
データサーバ300は、P−CSCFサーバの各々が保持しているユーザデータを含む内容のデータをバックアップデータとして保持するサーバである。すなわち、データサーバ300は、複数のP−CSCFサーバのユーザデータの各々の内容を含むデータを保持しており、複数のP−CSCFサーバのうち1つが障害状態などでそれまで保持していたユーザデータが消失した際のバックアップ用のデータサーバとなる。データサーバ300は、当該1つP−CSCFサーバが障害状態などから復旧した際に、当該1つのP−CSCFサーバのユーザデータ取得要求に従い、当該1つのP−CSCFサーバにユーザデータを転送する。
データサーバ300は、表1に示す各ユーザと各ユーザのユーザデータを保持している各P−CSCFサーバとの対応テーブルを有していてもよい。すなわち、複数のP−CSCFサーバの各々に登録されているユーザデータがそのままデータサーバ300に記憶されていてもよい。この場合、データサーバ300は、ユーザ端末毎のユーザデータを保持する必要がある。ユーザデータは、データ容量が大きく、ユーザ端末数が多くなればなるほど、記憶データは膨大なデータ容量となる。故に、データサーバ300は、表2に示す各ユーザのユーザデータとデータサーバ300の記憶領域に対応するインデックスとのインデックス対応テーブルと、表3に示すデータサーバ300のインデックスと各P−CSCFサーバとのユーザデータ対応テーブルとを有して、各インデックスに記憶されるデータは、ユーザデータの内容を含むデータであるパリティデータである方が好ましい。各インデックスは、1つのユーザデータが登録できる記憶容量を有する。
Figure 2014171012
Figure 2014171012
表2において、ユーザA、ユーザB、ユーザCのユーザデータDA、DB、DCは、それぞれインデックス0の記憶領域に対応し、ユーザD、ユーザE、ユーザGのユーザデータDD、DE、DGは、それぞれインデックス1の記憶領域に対応し、ユーザF、ユーザH、ユーザIのユーザデータDF、DH、DIは、それぞれインデックス2の記憶領域に対応することを示す。
表3において、各インデックスには、表2に対応したユーザデータの各々から生成されたパリティデータが記憶されていることを示す。また、パリティデータが複数のP−CSCFサーバのうちのどのサーバのユーザデータの内容を含んでいるかを示す。例えば、インデックス0には、ユーザデータDA、ユーザデータDB、ユーザデータDCから生成されたパリティデータPABCが記憶されていることを示す。更に、パリティデータPABCは、P−CSCF#1サーバ210、P−CSCF#2サーバ220、P−CSCF#3サーバ230の1つのユーザデータから生成されていることを示す。具体的には、パリティデータPABCは、ユーザデータDA、DB、DCを排他的論理和(XOR)の演算を行い生成される。すなわち、パリティデータは、P−CSCFサーバ毎に単一ユーザ端末に対応するユーザデータを抽出してこれらを互いに論理演算するシーケンスを少なくとも1回行うことによって得られた演算データである。
1つのパリティデータの容量は、1ユーザ分のユーザデータの容量と同じである。表3には、3つのインデックスが示されているが、インデックスの数はこれに限らない。例えば、複数のP−CSCFサーバに均一にユーザデータが分散していた場合には、インデックスの数は、ユーザ数をP−CSCFサーバの数で除算して得られた数が好ましい。これによって、複数のP−CSCFサーバ毎にユーザデータの1つを抽出して効率的にパリティデータが生成される。
なお、1つのインデックスに単一のユーザデータのみを記憶する場合には、ユーザデータの複製をそのまま記憶する。データサーバ300は、複数のP−CSCFサーバの各々のユーザデータ登録の要求の際に、当該ユーザデータを含むデータを記憶するインデックスを設定し、ユーザデータ登録後に当該インデックスの番号を当該P−CSCFサーバに通知する。
表4は、P−CSCF#1サーバ210が保持しているユーザとインデックスとの対応を示す。表5は、P−CSCF#2サーバ220が保持しているユーザとインデックスとの対応を示す。表6は、P−CSCF#3サーバ230が保持しているユーザとインデックスとの対応を示す。
Figure 2014171012
Figure 2014171012
Figure 2014171012
I−CSCFサーバ410は、SIPメッセージの経路を制御する機能を有するSIPサーバである。I−CSCFサーバ410は、例えば、複数のP−CSCFサーバの各々からSIPメッセージを受信して、ホーム加入者サーバ430に問い合わせを行い、SIPメッセージをS−CSCFサーバ420に転送する。
S−CSCFサーバ420は、サービス実行、呼セッション制御のための中心的なSIPサーバである。S−CSCFサーバ420は、ホーム加入者サーバ430と通信することによってユーザ認証を実行する。また、S−CSCFサーバ420は、アプリケーションサーバ440と通信することによって、ユーザ端末に対して多様なサービスを提供する。
ホーム加入者サーバ430は、IMSサービスを提供する上でのサービス情報や認証情報などの加入者プロファイルデータが記録されているデータベースを有する。アプリケーションサーバ440は、各種サービスをユーザ端末群100に対して提供する。
図2において、ユーザAのユーザ端末101をIMS500に登録する際の動作例を説明する。まず、ユーザ端末101が複数のP−CSCFサーバのうちの1つ(例えばP−CSCF#1サーバ210)を選択してREGISTER信号を送信する(ステップS101)。REGISTER信号を受信したP−CSCF#1サーバ210は、I−CSCFサーバ410にREGISTER信号を送信する(ステップS102)。I−CSCFサーバ410は、ホーム加入者サーバ430に問い合わせを行い、ホーム加入者サーバ430からS−CSCFサーバ420の情報を取得する。I−CSCFサーバ410は、取得したS−CSCFサーバ420の情報のうちの当該ユーザ端末101に適するS−CSCFサーバ420を選択してREGISTER信号を送信する(ステップS103)。
S−CSCFサーバ420は、ホーム加入者サーバ430に認証情報(乱数、認証トークン、IPsecで用いる鍵情報、認証応答の期待値)の計算を依頼し、ホーム加入者サーバ430から認証情報を取得して、ユーザ端末101から返送される認証応答の期待値を保持しておく。S−CSCFサーバ420は、401 UNAUTHORIZED信号をI−CSCFサーバ410を介してP−CSCF#1サーバ210に送信する(ステップS104、S105)。ここで、401 UNAUTHORIZED信号には、乱数、認証トークン、IPsecで用いる鍵情報が含まれる。P−CSCF#1サーバ210は、401 UNAUTHORIZED信号からIPsecで用いる鍵情報を取り出しこれを保持する。また、P−CSCF#1サーバ210は、ユーザ端末101に401 UNAUTHORIZED信号を送信する(ステップS106)。ユーザ端末101に転送される401 UNAUTHORIZED信号には、乱数、認証トークンが含まれる。
ユーザ端末101は、乱数と共通鍵とを用いてIMS500の認証トークンの認証を行うとともに、認証応答の応答値とIPsecで用いる鍵情報とを生成する。ユーザ端末101は、IPsecを確立して、認証応答の応答値を含むREGISTER信号をP−CSCF#1サーバ210に送信する(ステップS107)。P−CSCF#1サーバ210は、REGISTER信号をI−CSCFサーバ410を介してS−CSCFサーバ420に送信する(ステップS108、S109)。S−CSCFサーバ420は、自身が保持している認証応答の期待値と、ユーザ端末101から返送された認証応答の応答値とが一致することでユーザを認証する。S−CSCFサーバ420は、ユーザ認証が成功すると、ホーム加入者サーバ430に当該ユーザが登録されたことを通知し、ホーム加入者サーバ430から当該ユーザの加入者プロファイルデータを取得する。S−CSCFサーバ420は、当該ユーザ端末101の登録が完了した旨を示す200 OK信号をI−CSCFサーバ410を介してP−CSCF#1サーバ210に送信する(ステップS110、S111)。
P−CSCF#1サーバ210は、当該ユーザのユーザデータを保持する(ステップS112)。P−CSCF#1サーバ210は、当該ユーザのユーザデータの複製を作成し、データサーバ300にユーザデータの複製を転送する。データサーバ300は、P−CSCF#1サーバ210から転送された当該ユーザのユーザデータの内容を含むデータをバックアップデータとして保持する(ステップS113)。P−CSCF#1サーバ210は、ユーザ端末101に200 OK信号を送信する(ステップS114)。ユーザ端末101は、IMS500に登録されてIMS500との発着信などの通信が可能となる。なお、ステップS113のP−CSCF#1サーバ210からデータサーバへのユーザデータの転送は、ステップS114の後に行われてもよい。
次に、図2のステップS113のデータサーバ300におけるユーザデータの登録について、図3を参照しつつ、より詳細に説明する。ユーザAのユーザ端末101がP−CSCF#1サーバ210を選択してIMS500への登録処理が完了したものとする。説明を簡単にするために、本シーケンスにおいては、表7及び表8に示す如く、データサーバ300におけるインデックス対応テーブル及びユーザデータ対応テーブルには、ユーザデータを含む内容がまだ記憶されていない状態であるものとして説明する。
Figure 2014171012
Figure 2014171012
ユーザAの認証が終わると、P−CSCF#1サーバ210は、ユーザデータDAを保持し、ユーザデータDAの登録要求信号をデータサーバに送信する(ステップS201)。登録要求信号の中には、ユーザ名(例えばユーザA)、P−CSCFサーバ名(例えばP−CSCF#1サーバ210)、ユーザデータ(例えばユーザデータDA)が含まれる。
データサーバ300は、P−CSCF#1サーバ210から登録要求信号を受信すると、ユーザデータを保存するインデックスを割り当て(ステップS202)、当該ユーザデータを含む内容のデータを保存する(ステップS203)。例えば、データサーバ300は、ユーザデータDAの保存場所をインデックス0に設定したとする。このときのインデックス対応テーブル及びユーザデータ対応テーブルは表9及び表10の如くユーザデータDAが保存される。表9においては、ユーザAのユーザデータDAはインデックス0に保存されていることを示し、表10においては、インデックス0にP−CSCF#1サーバ210のユーザデータDAの複製が保存されていることを示している。ここで、インデックス0には、他のユーザのユーザデータが含まれていない故に、ユーザデータDAの複製がそのまま保存される。
Figure 2014171012
Figure 2014171012
例えば、次に、ユーザBがP−CSCF#2サーバ220を経由してIMS500に登録されたときのデータサーバ300内のユーザデータの登録について説明する。データサーバ300は、ユーザBのユーザデータDBの保存場所をインデックス0に割り当てたとする。このときのインデックス対応テーブル及びユーザデータ対応テーブルには、表11及び表12の如くユーザデータDBが保存される。
Figure 2014171012
Figure 2014171012
すなわち、インデックス0にユーザデータDBを登録する際には、既にインデックス0に保存されているユーザデータDAを上書きもしくは消去するのではなく、ユーザデータDAとユーザデータDBとを用いたパリティデータPABが生成され、当該パリティデータPABがインデックス0に保存される。データサーバ300は、ユーザ端末のIMS500への登録毎にユーザデータの複製が転送され、ユーザデータを含む内容のデータを表2及び表3の如くインデックス対応テーブル及びユーザデータ対応テーブルに保存する。
データサーバ300は、ユーザデータの登録が完了すると、登録結果の応答として登録完了信号をP−CSCF#1サーバ210に送信する(ステップS204)。登録完了信号には、ユーザ名、P−CSCFサーバ名、割り当てられたインデックス番号が含まれる。登録完了信号を受信したP−CSCF#1サーバ210は、当該ユーザに割り当てられたインデックス番号を、表4に示す如くユーザとインデックスとの対応テーブルに保存する(ステップS205)。
次に、図3のステップS202におけるインデックスの割り当てについて、図4を参照しつつ、より詳細に説明する。図4は、データサーバ300がユーザデータの内容を含むデータを保持するインデックスを割り当てる際の動作例のフローチャートである。
まず、登録要求のあったユーザAが表7に示す如くインデックス対応テーブルに登録されているか検索する(ステップS301)。ステップS301の検索結果から当該ユーザに登録されているインデックスがあるか否かを判定する(ステップS302)。
ユーザAに登録されているインデックスがないので(ステップS302のNo)、指定されているP−CSCFサーバのうちの未割り当てのインデックスを検索する(ステップS306)。すなわち、表8に示す如くユーザデータ対応テーブルにおいて、P−CSCF#1サーバ210で未割り当てのインデックスを検索すると、インデックス”0”、”1”、”2”の検索結果が得られる。未割り当てのインデックス”0”、”1”、”2”の中から1つを選択し、当該1つのインデックスを登録対象のインデックスに割り当てる(ステップS307)。インデックスの選択方法は、例えば、検索結果で得られた最小のインデックスを選択する方法やランダムにインデックスを選択する方法であってもよい。ここでは、インデックス”0”を選択したものとする。
例えば、登録要求のあったユーザが既にインデックス対応テーブルに登録されているインデックスが存在する場合には(ステップS302のYes)、ユーザデータ対応テーブルから当該インデックスに対応するP−CSCFサーバを検索する(ステップS303)。ステップS303の検索結果で得られたP−CSCFサーバとデータサーバ300に登録要求を行ったP−CSCFサーバとが一致するか否かを判定する(ステップS304)。P−CSCFサーバが一致する場合には(ステップS304のYes)、同一のP−CSCFサーバへの再登録と見做して既に当該ユーザ向けに登録されているインデックスを選択し再割り当てを行う(ステップS308)。
P−CSCFサーバが一致しない場合には(ステップS304のNo)、インデックスの再割り当て要求と見做し、インデックス対応テーブル及びユーザデータ対応テーブルから、当該ユーザ向けに登録されているデータの登録を解除する(ステップS305)。当該登録の解除の後に、インデックスの未登録のときと同様に(ステップS302のNo)、登録要求を行ったP−CSCFサーバの未割り当てインデックスを検索して(ステップS306)、インデックスを割り当てる(ステップS307)。
図5において、P−CSCF#3サーバ230が障害状態から復旧したときに、障害前に保持していた全ユーザデータをリカバリする際の動作例を説明する。P−CSCF#3サーバ230に障害が発生して、P−CSCF#3サーバ230は、ユーザデータを消失したことを前提として以下説明する。
障害状態から復旧した非運用のP−CSCF#3サーバ230は、データサーバ300にユーザデータ要求信号を送信する(ステップS401)。ここで、P−CSCF#3サーバ230が保持していた全ユーザデータを要求する場合には、ユーザ名の指定を行わない。ユーザデータ要求信号の中には、ユーザ名(例えば、未設定)、P−CSCFサーバ名(例えば、P−CSCF#3サーバ230)が含まれる。
データサーバ300は、当該ユーザデータ要求信号を受信すると、ユーザデータ対応テーブルにおいてP−CSCF#3サーバ230の登録があるインデックスを検索する(ステップS402)。表3に示す如くユーザデータ対応テーブルにおいて、P−CSCF#3サーバ230のユーザデータが含まれる内容のデータが登録されているのは、インデックス”0”、”1”、”2”である。
次に、上記で得られたインデックスにおいて、当該ユーザデータ要求信号を送信したP−CSCF#3サーバ230以外のP−CSCFサーバ毎のユーザデータの内容が含まれているか否かを検索する。P−CSCF#1サーバ210及びP−CSCF#2サーバ220は、いずれもインデックス”0”、”1”、”2”にユーザデータの内容を含んでいる。
次に、データサーバ300は、P−CSCF#1サーバ210にインデックス”0”、”1”、”2”に含まれるユーザデータの複製の転送を要求する(ステップS403)。P−CSCF#1サーバ210は、ユーザデータの複製の転送要求を受信すると、インデックス0に含まれるユーザAのユーザデータDAの複製、インデックス1に含まれるユーザDのユーザデータDDの複製、インデックス2に含まれるユーザIのユーザデータDIの複製をデータサーバ300に転送する(ステップS404)。
また、データサーバ300は、P−CSCF#2サーバ220にインデックス”0”、”1”、”2”に含まれるユーザデータの複製の転送を要求する(ステップS405)。P−CSCF#2サーバ220は、ユーザデータの複製の転送要求を受信すると、インデックス0に含まれるユーザBのユーザデータDBの複製、インデックス1に含まれるユーザGのユーザデータDGの複製、インデックス2に含まれるユーザHのユーザデータDHの複製をデータサーバ300に転送する(ステップS406)。
データサーバ300は、P−CSCF#1サーバ210及びP−CSCF#2サーバ220から転送されたユーザデータの複製の各々を受信して、各インデックスに対応するユーザデータと各インデックスに対応するパリティデータとを用いて、P−CSCF#3サーバ230に対応するユーザデータを復元する(ステップS407)。具体的には、インデックス0については、ユーザデータDA、ユーザデータDB、パリティデータPABCの排他的論理和の演算を行い、P−CSCF#3サーバ230に対応するユーザデータDCを生成する。インデックス1については、ユーザデータDD、ユーザデータDG、パリティデータPDEGの排他的論理和の演算を行い、P−CSCF#3サーバ230に対応するユーザデータDEを生成する。インデックス2については、ユーザデータDI、ユーザデータDH、パリティデータPFHIの排他的論理和の演算を行い、P−CSCF#3サーバ230に対応するユーザデータDFを生成する。
次に、データサーバ300は、インデックス0に対応するユーザCのユーザデータDC、インデックス1に対応するユーザEのユーザデータDE、インデックス2に対応するユーザFのユーザデータDFをP−CSCF#3サーバ230に転送する(ステップS408)。P−CSCF#3サーバ230は、ユーザデータの各々及びユーザデータの各々に対応するインデックス番号の各々を受信してこれらを保持する(ステップS409)。
これによって、P−CSCF#3サーバ230は、障害状態から復旧した後に、障害前に保持していたユーザデータを回復するので、ユーザ端末群100とのプロキシ制御を継続することが可能となり、複数のP−CSCFサーバの間での分散処理の負荷バランスが障害前と比べて大きく崩れない。故に、複数のP−CSCFサーバの間での分散処理の負荷バランスが大きく崩れる従来のP−CSCFサーバと比べて、P−CSCFサーバの処理能力の余裕(マージン)を大きくとらなくてもよい。
また、データサーバ300は、複数のユーザデータをまとめて1つのパリティデータとして記憶している。すなわち、ユーザデータ3個分のデータの論理演算を行い、当該ユーザデータ3個分を含む内容を1つのデータとして記憶して記憶容量が3分の1となるので、バックアップデータのユーザデータのデータ容量の削減が可能である。
なお、ステップS402において、ユーザデータ対応テーブルにおいてP−CSCF#3サーバ230の登録があるインデックスにおいて、P−CSCF#3サーバ230のユーザデータのみが記憶されている場合には、故に、データサーバ300は、当該インデックスに記憶されているユーザデータをP−CSCF#3サーバ230に転送する。
図6において、一部のユーザデータをリカバリする際の動作例を説明する。障害状態から復旧した非運用のP−CSCF#3サーバ230は、データサーバ300にユーザデータ要求信号を送信する(ステップS501)。ユーザデータ要求信号の中には、ユーザ名(例えば、ユーザE)、P−CSCFサーバ名(例えば、P−CSCF#3サーバ230)が含まれる。
データサーバ300は、当該ユーザデータ要求信号を受信すると、インデックス対応テーブルにおいて、ユーザEに対応するインデックスを検索する(ステップS502)。表2に示す如くインデックス対応テーブルにおいて、ユーザEのユーザデータが含まれる内容のデータが登録されているのは、インデックス”1”である。
次に、上記で得られたインデックスにおいて、当該ユーザデータ要求信号を送信したP−CSCF#3サーバ230以外のP−CSCFサーバ毎のユーザデータの内容が含まれているか否かを検索する。P−CSCF#1サーバ210及びP−CSCF#2サーバ220は、いずれもインデックス”1”にユーザデータの内容を含んでいる。
次に、データサーバ300は、P−CSCF#1サーバ210にインデックス”1”に含まれるユーザデータの複製の転送を要求する(ステップS503)。P−CSCF#1サーバ210は、ユーザデータの複製の転送要求を受信すると、インデックス1に含まれるユーザDのユーザデータDDの複製をデータサーバ300に転送する(ステップS504)。また、データサーバ300は、P−CSCF#2サーバ220にインデックス”1”に含まれるユーザデータの複製の転送を要求する(ステップS505)。P−CSCF#2サーバ220は、ユーザデータの複製の転送要求を受信すると、インデックス1に含まれるユーザGのユーザデータDGの複製をデータサーバ300に転送する(ステップS506)。データサーバ300は、P−CSCF#1サーバ210から転送されたユーザデータDD、P−CSCF#2サーバ220からユーザデータDG、パリティデータPDEGの排他的論理和の演算を行い、P−CSCF#3サーバ230に対応するユーザデータDEを生成する。(ステップS507)。
次に、データサーバ300は、ステップS507で復元されたインデックス1に対応するユーザEのユーザデータDEをP−CSCF#3サーバ230に転送する(ステップS508)。P−CSCF#3サーバ230は、ユーザデータDE及びインデックス番号1を受信してこれらを保持する(ステップS509)。
これによって、ユーザ端末からのリクエストがあった場合など、必要とする特定のユーザのユーザデータをタイムリーにリカバリすることができる。すなわち、P−CSCF#3サーバ230が復旧後に、ユーザ端末群100からのリクエストを迅速に処理することが可能となる。
なお、IMS500にP−CSCF#4サーバ240が追加された場合には、表3に示す如くユーザデータ対応テーブルの列方向にP−CSCF#4サーバ240のフィールドを追加すればよく、同一インデックスにP−CSCF#4サーバ240が保持しているユーザデータを含む内容のデータも記憶可能となる。
また、I−CSCFサーバ410、S−CSCFサーバ420、アプリケーションサーバ420、ホーム加入者サーバ430が複数配置されてもよい。
<変形例>
表13は、表1のインデックス対応テーブルのインデックスの数を2倍増加したものである。表14は、インデックスの数が2倍増加したので、データの記憶容量も表3のユーザデータ対応テーブルと比べて2倍増加している。表15は、P−CSCF#1サーバ210が保持しているユーザとインデックスとの対応を示す。表16は、P−CSCF#2サーバ220が保持しているユーザとインデックスとの対応を示す。表17は、P−CSCF#3サーバ230が保持しているユーザとインデックスとの対応を示す。
Figure 2014171012
Figure 2014171012
Figure 2014171012
Figure 2014171012
Figure 2014171012
変形例においては、図1に示すIMS500の全体構成、図2に示すユーザ端末がIMSに登録する際のシーケンス、図3に示すデータサーバがユーザデータの内容を含むデータを保持する際の動作例のシーケンス、図4に示すデータサーバがユーザデータの内容を含むデータを保持するインデックスを割り当てる際の動作例のフローチャートは、共通である。
図7において、全ユーザデータをリカバリする際の動作例を説明する。障害状態から復旧した非運用のP−CSCF#3サーバ230は、図5のステップS401と同様にデータサーバ300にユーザデータ要求信号を送信する(ステップS601)。
データサーバ300は、図5のステップS402と同様にユーザデータ対応テーブルにおいてP−CSCF#3サーバ230の登録があるインデックスを検索する(ステップS602)。表14に示す如くユーザデータ対応テーブルにおいて、P−CSCF#3サーバ230のユーザデータが含まれる内容のデータが登録されているのは、インデックス”3”、”4”、”5”である。
次に、上記で得られたインデックスにおいて、当該ユーザデータ要求信号を送信したP−CSCF#3サーバ230以外のP−CSCFサーバ毎のユーザデータの内容が含まれているか否かを検索する。ここで、インデックス”3”においては、P−CSCF#3サーバ230のみが保存されているので、ユーザCのユーザデータDCの複製がそのまま保存されている。P−CSCF#1サーバ210は、インデックス”5”にユーザデータの内容を含んでいる。P−CSCF#2サーバ220は、インデックス”4”にユーザデータの内容を含んでいる。
次に、データサーバ300は、P−CSCF#1サーバ210にインデックス”5”に含まれるユーザデータの複製の転送を要求する(ステップS603)。P−CSCF#1サーバ210は、ユーザデータの複製の転送要求を受信すると、ユーザIのユーザデータDIの複製をデータサーバ300に転送する(ステップS604)。
また、データサーバ300は、P−CSCF#2サーバ220にインデックス”4”に含まれるユーザデータの複製の転送を要求する(ステップS605)。P−CSCF#2サーバ220は、ユーザデータの複製の転送要求を受信すると、ユーザHのユーザデータDHの複製をデータサーバ300に転送する(ステップS606)。
データサーバ300は、P−CSCF#1サーバ210及びP−CSCF#2サーバ220から転送されたユーザデータの複製の各々を受信して、各インデックスに対応するユーザデータと各インデックスに対応するパリティデータとを用いて、P−CSCF#3サーバ230に対応するユーザデータを復元する(ステップS607)。具体的には、インデックス4については、ユーザデータDH、パリティデータPEHの排他的論理和の演算を行い、P−CSCF#3サーバ230に対応するユーザデータDEを生成する。インデックス5については、ユーザデータDI、パリティデータPFIの排他的論理和の演算を行い、P−CSCF#3サーバ230に対応するユーザデータDFを生成する。
次に、データサーバ300は、インデックス3に対応するユーザCのユーザデータC、インデックス4に対応するユーザEのユーザデータDE、インデックス5に対応するユーザFのユーザデータDFをP−CSCF#3サーバ230に転送する(ステップS608)。P−CSCF#3サーバ230は、ユーザデータの各々及びユーザデータの各々に対応するインデックス番号の各々を受信してこれらを保持する(ステップS609)。
図8において、一部のユーザデータをリカバリする際の動作例を説明する。障害状態から復旧した非運用のP−CSCF#3サーバ230は、図6のステップS501と同様にデータサーバ300にユーザ名(例えばユーザE)を指定したユーザデータ要求信号を送信する(ステップS701)。データサーバ300は、ステップS502と同様にインデックス対応テーブルにおいて、ユーザEに対応するインデックスを検索する(ステップS702)。インデックス対応テーブルにおいて、ユーザEのユーザデータが含まれる内容のデータが登録されているのは、インデックス”4”である。
次に、インデックス”4”において、当該ユーザデータ要求信号を送信したP−CSCF#3サーバ230以外のP−CSCFサーバ毎のユーザデータの内容が含まれているか否かを検索する。インデックスP−CSCF#2サーバ220は、インデックス”4”にユーザデータの内容を含んでいる。
次に、データサーバ300は、P−CSCF#2サーバ220にインデックス”4”に含まれるユーザデータの複製の転送を要求する(ステップS703)。P−CSCF#2サーバ220は、ユーザデータの複製の転送要求を受信すると、インデックス4に含まれるユーザHのユーザデータDHの複製をデータサーバ300に転送する(ステップS704)。
データサーバ300は、ユーザデータDHの複製を受信して、ユーザデータDHとパリティデータPEHとを排他的論理和の演算を行い、P−CSCF#3サーバ230に対応するユーザデータDEを復元する(ステップS705)。
次に、データサーバ300は、インデックス4に対応するユーザEのユーザデータDEをP−CSCF#3サーバ230に転送する(ステップS706)。P−CSCF#3サーバ230は、ユーザEのユーザデータDE及びインデックス番号4を受信してこれらを保持する。(ステップS707)。
変形例においては、データサーバ300のユーザデータを含む内容のデータの記憶容量は表3のユーザデータ対応テーブルと比べて2倍に増えているが、表1のデータ記憶容量と比べると3分の2倍となっている。また、表3のユーザデータ対応テーブルと比べて、データサーバ300が、1つのインデックスに含んでいるユーザデータの数が少ない故に、ユーザデータのリカバリ処理における排他的論理和の演算回数が少ない。すなわち、図5のユーザデータのリカバリでは、演算回数が6回必要であったのに対し、図7のユーザデータのリカバリでは、演算回数が2回となっている。従って、演算回数が少なくなるのでユーザデータのリカバリ処理にかかる時間が短縮される。
なお、表3及び表14に示したユーザデータ対応テーブルは、インデックスと記憶データとの対応を示すテーブルと、インデックスとP−CSCFサーバとの対応を示すテーブルとに分けてもよい。また、当該記憶データは、公知の可逆圧縮アルゴリズムを用いてデータ容量を小さくしてもよい。
100 ユーザ端末群
210 P−CSCF#1サーバ
220 P−CSCF#2サーバ
230 P−CSCF#3サーバ
300 データサーバ
410 I−CSCFサーバ
420 S−CSCFサーバ
430 ホーム加入者サーバ
440 アプリケーションサーバ
500 IPマルチメディアサブシステム
600 アクセス網
700 IP網

Claims (5)

  1. 複数のユーザ端末の各々のユーザデータを保持して前記ユーザ端末毎に分散して中継する複数のプロキシサーバと、前記プロキシサーバの各々から転送された前記ユーザデータの内容を含むデータを保持するデータサーバと、を有するIPマルチメディアサブシステムであって、
    前記プロキシサーバの各々は、
    前記ユーザ端末から登録要求があったときに、前記ユーザ端末の前記ユーザデータを記憶するユーザデータ記憶手段と、
    前記ユーザデータを記憶した後に、前記データサーバに前記ユーザデータの複製を転送するユーザデータ転送手段と、を含み、
    前記データサーバは、前記プロキシサーバの各々から転送された前記ユーザデータの各々の内容を含むデータをバックアップデータとして記憶することを特徴とするIPマルチメディアサブシステム。
  2. 前記データサーバは、前記プロキシサーバの各々から転送された前記ユーザデータの複製のうち前記プロキシサーバ毎に単一ユーザ端末に対応するユーザデータを抽出してこれらを互いに論理演算するシーケンスを少なくとも1回行うことによって得られる演算データを生成する演算データ生成手段を有し、前記演算データをバックアップデータとすることを特徴とする請求項1に記載のIPマルチメディアサブシステム。
  3. 前記演算データは、パリティデータであることを特徴とする請求項2に記載のIPマルチメディアサブシステム。
  4. 前記データサーバは、前記プロキシサーバのうちの非運用のプロキシサーバから前記ユーザデータの要求があったときに、前記演算データから当該非運用のプロキシサーバに対応するユーザデータを復元するユーザデータ復元手段を更に有することを特徴とする請求項2又は3に記載のIPマルチメディアサブシステム。
  5. 前記ユーザデータ復元手段は、当該非運用のプロキシサーバ以外のプロキシサーバからユーザデータを取得し、前記演算データと当該非運用のプロキシサーバ以外のプロキシサーバから取得したユーザデータとを用いて当該非運用のプロキシサーバに対応するユーザデータを復元することを特徴とする請求項4に記載のIPマルチメディアサブシステム。
JP2013040692A 2013-03-01 2013-03-01 Ipマルチメディアサブシステム Pending JP2014171012A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013040692A JP2014171012A (ja) 2013-03-01 2013-03-01 Ipマルチメディアサブシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013040692A JP2014171012A (ja) 2013-03-01 2013-03-01 Ipマルチメディアサブシステム

Publications (1)

Publication Number Publication Date
JP2014171012A true JP2014171012A (ja) 2014-09-18

Family

ID=51693112

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013040692A Pending JP2014171012A (ja) 2013-03-01 2013-03-01 Ipマルチメディアサブシステム

Country Status (1)

Country Link
JP (1) JP2014171012A (ja)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002268952A (ja) * 2001-03-13 2002-09-20 Mitsubishi Heavy Ind Ltd データの分散保存システム、プログラムおよびサーバ
JP2003008607A (ja) * 2001-06-26 2003-01-10 Nec Corp リモートvpn認証・管理システムおよびリモートvpn認証・管理システム構築方法
JP2005084771A (ja) * 2003-09-05 2005-03-31 Hitachi Ltd バックアップシステム及び方法
JP2007221265A (ja) * 2006-02-14 2007-08-30 Fujitsu Ltd 呼制御装置および呼制御方法
JP2010263597A (ja) * 2009-05-01 2010-11-18 Kddi Corp Imsネットワークシステムおよびノード変更方法
JP2010541349A (ja) * 2007-09-28 2010-12-24 テレフオンアクチーボラゲット エル エム エリクソン(パブル) Ipマルチメディア・サブシステム・ネットワークにおける障害復旧
JP2011211710A (ja) * 2010-03-29 2011-10-20 Hitachi Ltd ステートフルな(通信状態を維持する)地理的冗長性を有するモビリティ管理エンティティ(mme)の効率的な配備

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002268952A (ja) * 2001-03-13 2002-09-20 Mitsubishi Heavy Ind Ltd データの分散保存システム、プログラムおよびサーバ
JP2003008607A (ja) * 2001-06-26 2003-01-10 Nec Corp リモートvpn認証・管理システムおよびリモートvpn認証・管理システム構築方法
JP2005084771A (ja) * 2003-09-05 2005-03-31 Hitachi Ltd バックアップシステム及び方法
JP2007221265A (ja) * 2006-02-14 2007-08-30 Fujitsu Ltd 呼制御装置および呼制御方法
JP2010541349A (ja) * 2007-09-28 2010-12-24 テレフオンアクチーボラゲット エル エム エリクソン(パブル) Ipマルチメディア・サブシステム・ネットワークにおける障害復旧
JP2010263597A (ja) * 2009-05-01 2010-11-18 Kddi Corp Imsネットワークシステムおよびノード変更方法
JP2011211710A (ja) * 2010-03-29 2011-10-20 Hitachi Ltd ステートフルな(通信状態を維持する)地理的冗長性を有するモビリティ管理エンティティ(mme)の効率的な配備

Similar Documents

Publication Publication Date Title
KR100909533B1 (ko) 사용자 아이덴티티들
US8335852B2 (en) Contact destination information registration method, network system, node, and contact destination information registration program
CN107925848B (zh) 用于跨多个平面的标识管理的方法和系统
ES2401301T3 (es) Método y aparato para su uso en una red de comunicaciones
US20080056234A1 (en) Methods, systems, and computer program products for inhibiting message traffic to an unavailable terminating SIP server
US9363319B2 (en) Method and system of transferring a message in a session initiation protocol based communications network
US7936665B2 (en) IMS network system and data restoring method
US20110149750A1 (en) Subscriber fallback/migration mechanisms in ims geographic redundant networks
CN103098437B (zh) 基于sip的呼叫会话服务器和消息路由选择方法
CN101127722A (zh) 核心网元重启/故障恢复后的处理方法
CN101667936A (zh) 接入会话控制服务器的故障处理方法、设备及系统
CN109995721A (zh) 业务请求处理方法、装置及通信系统
CN101227474A (zh) 软交换网络中的会话初始化协议用户鉴权方法
CN102884858A (zh) 使能来自ims中未登记ue的连接的设置
CN101336539B (zh) 网关实体
KR101926483B1 (ko) 임시 gruu에 대한 ims 복원 지원
CN101674178A (zh) 一种用户信息保存方法、用户信息验证方法及装置
JP2016213604A (ja) 通信装置及び管理方法
US20160302055A1 (en) Information processing system
JP2014171012A (ja) Ipマルチメディアサブシステム
CN102647397B (zh) 一种sip会话保护的方法和系统
CN101621501A (zh) 通信系统的用户注册控制方法和会话功能控制实体
JP5078661B2 (ja) 呼制御システム、通信制御装置及び呼制御方法
JP5809048B2 (ja) Ipサブシステムネットワークの切り替えに基づく端末認証方法及びプロキシ加入者情報サーバ
KR102065019B1 (ko) Ims 망에서 가입자를 관리하는 가입자 정보 관리 서버 및 방법

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20151117

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160727

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160816

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20170404