以下、図面に基づいて本発明の実施の形態を説明する。図2は、本発明の実施の形態における通信システムの構成例を示す図である。図2において、通信システム1は、移動体通信に関するシステムであり、発側エリアAs、着側エリアAr、セッション管理装置20、及びリソース管理装置10等を含む。
発側エリアAsは、本実施の形態において発呼側の通話エリアである。着側エリアArは、本実施の形態において着呼側の通話エリアである。なお、発側及び着側は、相対的な関係にすぎない。したがって、発側エリアAsにおいて着呼されてもよいし、着側エリアArにおいて発呼されてもよい。また、発側エリアAs及び着側エリアArを区別しない場合、単に「エリア」という。エリアは、端末の居場所を特定するための最小単位の範囲である。
各エリアは、1以上の端末50、基地局40、及び通信装置30等を含む。端末50は、例えば、フィーチャーフォン、スマートフォン、又はタブレット端末等、移動体通信網を利用した通話に用いられる携帯端末である。基地局40は、移動体通信網における基地局40である。すなわち、基地局40は、移動体通信網の末端に位置し、端末50と直接通信を行う。通信装置30は、交換機等を含む通信設備である。各基地局40は、通信装置30に接続される。なお、発側エリアAsに含まれる各装置の符号の末尾には「s」が付与され、着側エリアArに含まれる各装置の符号の末尾には「r」が付与される。
セッション管理装置20は、いずれかの端末50からの発呼に応じ、当該発呼の発側及び着側のそれぞれの通信装置30に対して通信リソースの割り当てを指示し、当該発呼に関する通信の接続を制御するコンピュータである。
リソース管理装置10は、発側エリアAsの端末50sと着側エリアArの端末50rとの双方が被災地である場合に、移動体端末網における輻輳を早期に解消するための処理を実行するコンピュータである。
なお、セッション管理装置20及びリソース管理装置10は、ネットワーク等を介して各通信装置30と通信可能に接続される。
図3は、本発明の実施の形態におけるリソース管理装置のハードウェア構成例を示す図である。図3のリソース管理装置10は、それぞれバスBで相互に接続されているドライブ装置100、補助記憶装置102、メモリ装置103、CPU104、及びインタフェース装置105等を有する。
リソース管理装置10での処理を実現するプログラムは、CD−ROM等の記録媒体101によって提供される。プログラムを記憶した記録媒体101がドライブ装置100にセットされると、プログラムが記録媒体101からドライブ装置100を介して補助記憶装置102にインストールされる。但し、プログラムのインストールは必ずしも記録媒体101より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置102は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
メモリ装置103は、プログラムの起動指示があった場合に、補助記憶装置102からプログラムを読み出して格納する。CPU104は、メモリ装置103に格納されたプログラムに従ってリソース管理装置10に係る機能を実行する。インタフェース装置105は、ネットワークに接続するためのインタフェースとして用いられる。
図4は、本発明の実施の形態におけるリソース管理装置及び通信装置の機能構成例を示す図である。図4において、リソース管理装置10は、専用リソース制御部11、端末情報制御部12、及び呼損端末接続部13等を有する。これら各部は、リソース管理装置10にインストールされたプログラムが、CPU104に実行させる処理により実現される。又は、これら各部は、回路等のハードウェアによって実現されてもよい。リソース管理装置10は、また、通信要求情報記憶部111、呼損リスト記憶部112、及び被災地リスト記憶部113等を利用する。これら各記憶部は、補助記憶装置102、又はリソース管理装置10にネットワークを介して接続される記憶装置等を用いて実現可能である。
専用リソース制御部11は、被災地の各エリア(以下、「被災地エリア」という。)の通信装置30通信リソースを、汎用リソースと専用リソースとに分割する。具体的には、専用リソース制御部11は、被災地エリアの通信装置30の専用リソースの上限値を算出する。本実施の形態において、専用リソースとは、被災地エリア間において呼損となった呼に関して使用される通信リソースをいう。汎用リソースとは、専用リソースが使用される呼以外の呼に関して使用される通信リソースをいう。例えば、汎用リソースは、発側及び着側の少なくともいずれか一方が、非被災地エリアである呼に関して使用される。なお、通信リソースとは、例えば、回線数や、周波数帯域等である。また、被災地エリアの通信装置30は、被災地リスト記憶部113を参照することにより特定可能である。すなわち、被災地リスト記憶部113には、例えば、オペレータによる操作等に応じて、被災地エリアの通信装置30の識別子が記憶される。
専用リソース制御部11は、通信要求情報記憶部111に記憶される通信要求情報に基づいて、一定期間ごとに専用リソースの上限値を算出する。なお、専用リソースの上限値を算出することは、汎用リソースの上限値を算出することにもなる。或る通信装置30の専用リソースの上限値と、汎用リソースの上限値との和は、当該通信装置30の通信リソースの上限値となるからである。
通信要求情報記憶部111は、発側及び着側の少なくともいずれか一方が被災地エリアである呼の発側の通信装置30及び着側の通信装置30ごとに、通信要求情報を記憶する。通信要求情報には、当該各通信装置30の着信端末数や発信端末数等が含まれる。
端末情報制御部12は、発側及び着側の双方が被災地エリアである発呼に関して呼損が発生した場合に、発側の端末50の発呼を規制すると共に、当該呼損に係る発呼に関する情報(発呼情報)を、呼損リスト記憶部112に登録する。なお、呼損リスト記憶部112には、通信装置30ごとに呼損リストが記憶されている。発呼情報は、呼損に係る発呼の着側の通信装置30に対応する呼損リストに登録される。
呼損端末接続部13は、呼損リスト記憶部112に登録されている発呼情報に基づいて、当該発呼情報に係る発側の端末50と着側の端末50との通信の接続を、セッション管理装置20に要求する。当該通信の接続に成功した場合、当該発呼情報は、呼損リストから削除され、当該発呼情報に係る発側の端末50の発呼規制は解除される。呼損端末接続部13は、また、セッション管理装置20から通知される、端末50からの発呼の成否を示す情報等に基づいて、当該発呼の発側の通信装置30及び着側の通信装置30のそれぞれの通信要求情報を更新する。
一方、各通信装置30は、リソース情報送信部31、リソース設定部32、及びリソース割当制御部33等を有する。これら各部は、通信装置30にインストールされたプログラムが、通信装置30のCPUに実行させる処理により実現される。又は、これら各部は、回路等のハードウェアによって実現されてもよい。通信装置30は、また、リソース情報記憶部301を利用する。これらリソース情報記憶部301は、通信装置30の補助記憶装置、又は通信装置30にネットワークを介して接続される記憶装置等を用いて実現可能である。
リソース情報送信部31は、リソース情報記憶部301に記憶されているリソース情報を参照して、リソースの空き状況をリソース管理装置10に通知する。リソース情報は、専用リソース及び汎用リソースの上限値や使用値等を含む情報である。
リソース設定部32は、リソース管理装置10の専用リソース制御部11によって算出される専用リソースの上限値と、専用リソースの上限値によって特定される汎用リソースの上限値とをリソース情報記憶部301に設定する。
リソース割当制御部33は、セッション管理装置20からリソースの割り当ての可否について問い合わせを受けた場合に、リソース情報に基づいて応答を行う。
以下、通信システム1において実行される処理手順について説明する。本実施の形態における処理手順は、例えば、災害発生時に、オペレータによって被災地エリアの通信装置30のリストが、リソース管理装置10の被災地リスト記憶部113に登録されることにより有効となる。
図5は、リソース管理装置の起動時に実行される処理手順の一例を説明するためのシーケンス図である。リソース管理装置10は、例えば、災害発生時に起動される。
リソース管理装置10の起動に応じ、専用リソース制御部11は、各被災地エリアの通信装置30に、リソース情報の取得要求を送信する(S101)。各被災地エリアの通信装置30は、被災地リスト記憶部113に記憶されている、各通信装置30の識別子に基づいて特定可能である。
当該取得要求を受信した各通信装置30のリソース情報送信部31は、当該通信装置30のリソース情報記憶部301に記憶されているリソース情報を返信する(S102)。
図6は、リソース情報記憶部の構成例を示す図である。図6において、リソース情報記憶部301は、着側汎用リソースの上限値RGR及び使用値Rgr、着側専用リソースの上限値RSR及び使用値Rsr、発側汎用リソースの上限値SGR及び使用値Sgr、並びに発側専用リソースの上限値SSR及び使用値Ssr等を含むリソース情報を記憶する。
着側汎用リソースとは、着信用の汎用リソースをいう。本実施の形態において、通信リソースの上限値及び使用値の単位は、端末数であるとする。すなわち、例えば、上限値は、当該通信リソースを使用可能な端末数の上限値であり、使用値は、当該通信リソースを使用している端末50の数である。
着側専用リソースとは、着信用の専用リソースをいう。発側汎用リソースとは、発信用の汎用リソースをいう。発側専用リソースとは、発信用の専用リソースをいう。
なお、災害発生前、すなわち、図5の処理が実行される前において、着側汎用リソース上限値RGRは、通信装置30の着信用の通信リソースの上限値に一致する。また、発側汎用リソース上限値SGRは、通信装置30の発信用の通信リソースの上限値に一致する。換言すれば、災害発生前において、着側専用リソース上限値RSR及び発側専用リソース上限値SSRは、いずれも0である。
続いて、専用リソース制御部11は、着側専用リソース上限値RSR及び発側専用リソース上限値SSRの初期値を、被災地エリアの各通信装置30に送信する(S103)。各通信装置30の当該初期値は、例えば、各通信装置30の着側汎用リソース上限値RGR又は発側汎用リソース上限値SGRに基づいて決定される。例えば、着側専用リソース上限値RSRの初期値は、着側汎用リソース上限値RGRの50%とされ、発側専用リソース上限値SSRの初期値は、発側汎用リソース上限値SGRの50%とされる。
各通信装置30のリソース設定部32は、当該初期値の受信に応じ、リソース情報記憶部301に記憶されているリソース情報を更新する(S104)。具体的には、当該リソース情報の着側専用リソース上限値RSR及び着側専用リソース上限値RSRのそれぞれは、受信された初期値によって更新される。また、当該リソース情報の着側汎用リソース上限値RGRからは、更新後の着側専用リソース上限値RSRが差し引かれる。また、当該リソース情報の発側汎用リソース上限値SGRからは、更新後の発側専用リソース上限値SSRが差し引かれる。その結果、各通信装置30の着側及び発側のそれぞれの通信リソースは、汎用リソースと専用リソースとに分割される。
リソース管理装置10の専用リソース制御部11は、ステップS103の実行後、一定時間待機する(S105)。一定時間待機後、専用リソース制御部11は、通信要求情報記憶部111から、被災地エリアに属する各通信装置30の通信要求情報を取得し、当該通信要求情報に基づいて、当該各通信装置30の着側専用リソース上限値RSR及び発側専用リソース上限値SSRのそれぞれを算出する(S106)。
図7は、通信要求情報記憶部の構成例を示す図である。図7に示されるように、通信要求情報記憶部111は、発側及び着側の少なくともいずれか一方が被災地エリアである呼の発側の通信装置30及び着側の通信装置30ごとに、通信要求情報を記憶する。
通信要求情報は、非被災地着信端末数NTi、被災地着信端末数Ti、非被災地発信端末数nti、及び被災地発信端末数ti等を含む。ここで、iは、被災地エリアに属する各通信装置30の識別子である。
非被災地着信端末数NTiは、通信装置30iが非被災地エリアに属する場合に、通信装置30iのエリア内において、被災地エリアに属する端末50からの呼の着信に成功した端末50の数である。
被災地着信端末数Tiは、通信装置30iが被災地エリアに属する場合に、通信装置30iのエリア内において、被災地エリア又は非被災地エリアに属する端末50からの呼の着信に成功した端末50の数である。
非被災地発信端末数ntiは、通信装置30iが非被災地エリアに属する場合に、通信装置30iのエリア内において、被災地エリアに属する端末50への発呼に成功した端末50の数である。発呼の成功とは、発信された呼に関して通信が接続されたことをいう。
被災地発信端末数tiは、通信装置30iが被災地エリアに属する場合に、通信装置30iのエリア内において、被災地エリア又は非被災地エリアに属する端末50への発呼に成功した端末50の数である。
なお、非被災地着信端末数NTi、被災地着信端末数Ti、非被災地発信端末数nti、及び被災地発信端末数tiの初期値は、いずれも0である。したがって、ステップS106におけるこれらのパラメータの値は、ステップS105において待機される一定時間において計測された値である。
このようなパラメータを含む通信要求情報に基づく着側専用リソース上限値RSR及び発側専用リソース上限値SSRの算出は、例えば、以下のように行われる。
まず、専用リソース制御部11は、通信装置30iについて、ステップS105の一定時間における、非被災地発信端末数nti、被災地発信端末数ti、非被災地着信端末数NTi、及び被災地着信端末数Tiの平均値を算出する。
当該一定時間を、「time(秒)」とすると、非被災地発信端末数ntiの平均値は、nti/timeによって算出される。被災地発信端末数tiの平均値は、ti/timeによって算出される。非被災地着信端末数NTiの平均値は、NTi/timeによって算出される。被災地着信端末数Tiの平均値は、Ti/timeによって算出される。
続いて、専用リソース制御部11は、非被災地発信端末数ntiの平均値と発側汎用リソース上限値SGRとの差分(以下、「発側汎用差分」という。)、被災地発信端末数tiの平均値と発側専用リソース上限値SSRとの差分(以下、「発側専用差分」という。)、非被災地着信端末数NTiの平均値と着側汎用リソース上限値RGRとの差分(以下、「着側汎用差分」という。)、被災地着信端末数Tiの平均値と着側専用リソース上限値RSRとの差分(以下、「着側専用差分」という。)のそれぞれを算出する。
発側汎用差分が1未満であり、かつ、発側専用差分が1以上の場合、専用リソース制御部11は、発側専用リソース上限値SSRを1減少させる。発側汎用差分が1以上であり、かつ、発側専用差分が1未満の場合、専用リソース制御部11は、発側専用リソース上限値SSRを1増加させる。同様に、着側汎用差分が1未満であり、かつ、着側専用差分が1以上の場合、専用リソース制御部11は、着側専用リソース上限値RSRを1減少させる。着側汎用差分が1以上であり、かつ、着側専用差分が1未満の場合、専用リソース制御部11は、着側専用リソース上限値RSRを1増加させる。
すなわち、相対的に余裕の大きい通信リソースの上限値は減少され、相対的に余裕の小さい通信リソースの上限値は増加される。
なお、各上限値の更新には、通信装置30iの発側汎用リソースの平均利用量、発側専用リソースの平均利用量、着側汎用リソースの平均利用量、及び着側専用リソースの平均利用量が用いられてもよい。この場合、通信要求情報には、非被災地発信端末数nti、被災地発信端末数ti、非被災地着信端末数NTi、及び被災地着信端末数Tiの代わりに、発側汎用リソースの利用回数、発側専用リソースの利用回数、着側汎用リソースの利用回数、及び着側専用リソースの利用回数が含まれてもよい。通信装置30iの発側汎用リソースの利用回数は、端末50からの発呼に応じて通信装置30iの発側汎用リソースが割り当てられるたびに1加算される。通信装置30iの発側専用リソースの利用回数は、リソース管理装置10からの発呼に応じて通信装置30iの発側専用リソースが割り当てられるたびに1加算される。通信装置30iの着側汎用リソースの利用回数は、端末50からの発呼に応じて通信装置30iの着側汎用リソースが割り当てられるたびに1加算される。通信装置30iの着側専用リソースの利用回数は、リソース管理装置10からの発呼に応じて通信装置30iの着側専用リソースが割り当てられるたびに1加算される。各利用回数の平均利用量は、各利用回数をtimeで除することにより求められる。
ステップS106に続いて、専用リソース制御部11は、通信装置30iごとに算出された発側専用リソース上限値SSR及び着側専用リソース上限値RSRを、各通信装置30iに送信する(S107)。通信装置30iのリソース設定部32は、受信された値によって、リソース情報記憶部301に記憶されているリソース情報を更新する(S108)。リソース情報の更新方法は、ステップS104と同様でよい。
続いて、専用リソース制御部11は、通信装置30iに関して通信要求情報記憶部111に記憶されている通信要求情報の各パラメータの値を0に初期化する。
ステップS106〜S109は、被災地エリアに属する各通信装置30に関して実行される。続いて、ステップS105以降が繰り返される(S110)。
このように、各通信装置30の発側専用リソース上限値SSR及び着側専用リソース上限値RSRは、各通信装置30における発呼又は着呼の成功状況に応じて、一定時間ごとに更新される。
続いて、発側エリアAsの端末50sが発呼した際に実行される処理手順について説明する。図8は、端末からの発呼に応じて実行される処理手順の一例を説明するためのシーケンス図である。
発側エリアAsにおけるいずれかの端末50sが発呼すると(S201)、当該発呼は、基地局40s及び通信装置30sを経由してセッション管理装置20に通知される(S202)。
セッション管理装置20は、当該発呼の発側の通信装置30sに対して、通信リソースの割り当て可否の問い合わせを送信する(S203)。当該問い合わせには、割り当て対象が発側の通信リソースであること、及び端末50の発呼による通信リソースの割り当てであることを示す情報が含まれる。
通信装置30sのリソース割当制御部33は、当該問い合わせを受信すると、当該問い合わせが発側の通信リソースに関する問い合わせであり、かつ、端末50の発呼による通信リソースの割り当てであることに応じ、リソース情報記憶部301を参照して、発側汎用リソース上限値SGR−発側汎用リソース使用値Sgr≧1であるか否かを判定する(S204)。すなわち、発側汎用リソースに空きがあるか否かが判定される。続いて、リソース割当制御部33は、割り当ての可否を示す判定結果をセッション管理装置20に返信する(S205)。
セッション管理装置20は、また、当該呼の着側の通信装置30rに対して、通信リソースの割り当て可否の問い合わせを送信する(S206)。当該問い合わせには、割り当て対象が着側の通信リソースであること、及び端末50の発呼による通信リソースの割り当てであることを示す情報が含まれる。
通信装置30rのリソース割当制御部33は、当該問い合わせを受信すると、当該問い合わせが着側の通信リソースに関する問い合わせであり、かつ、端末50の発呼による通信リソースの割り当てであることに応じ、リソース情報記憶部301を参照して、着側汎用リソース上限値RGR−着側汎用リソース使用値Rgr≧1であるか否かを判定する(S207)。すなわち、着側汎用リソースに空きがあるか否かが判定される。続いて、リソース割当制御部33は、割り当ての可否を示す判定結果をセッション管理装置20に返信する(S208)。
なお、ステップS203〜S205と、ステップS206〜S208とは並列的に実行されてもよいし、直列的に実行されてもよい。直列的に実行される場合、先に実行された問い合わせに関する判定結果が、割り当て不可(通信リソースの不足)を示す場合、他方の問い合わせは実行されなくてもよい。
双方の判定結果が、割り当ての可能を示す場合、セッション管理装置20は、当該発呼に関する接続要求を、通信装置30s及び通信装置30rのそれぞれに送信する(S209、S211)。通信装置30sのリソース割当制御部33は、発側汎用リソースを当該発呼に対して1つ割り当てる(S210)。したがって、発側汎用リソース使用値Sgrに1が加算される。また、通信装置30rのリソース割当制御部33は、着側汎用リソースを当該発呼に対して1つ割り当てる(S212)。したがって、着側汎用リソース使用値Rgrに1が加算される。
続いて、セッション管理装置20は、リソース管理装置10の端末情報制御部12に、通信接続の成否を示す情報と、発呼情報とを送信する(S213)。発呼情報には、発側の端末50s及び通信装置30sのそれぞれの識別子、並びに着側の端末50r及び通信装置30rのそれぞれの識別子と、発呼の成否を示す情報とが含まれる。
通信接続の失敗(すなわち、呼損)を示す情報が受信され、かつ、受信された発呼情報に含まれている、発側の通信装置30sの識別子及び着側の通信装置30rの識別子の双方が被災地リスト記憶部113に記憶されている場合(すなわち、被災地エリア間の発呼の場合)、端末情報制御部12は、当該発呼情報を呼損リスト記憶部112に記憶されている呼損リストのうち、着側の通信装置30rに対応する呼損リストに登録する(S214)。すなわち、呼損リストは、呼損となった発呼の着側の通信装置30rごとに記憶される。また、各呼損リストには、発側及び着側の双方が、被災地エリアである発呼における呼損に関する発呼情報が含まる。
図9は、一つの通信装置に対する呼損リストの構成例を示す図である。図9には、3つのエントリを含む呼損リストが示されている。呼損リストの一つのエントリは、一つの発呼情報に基づいて生成される。当該エントリは、発側端末識別子、発側通信装置識別子、着側端末識別子、及び確認フラグ等を含む。発側端末識別子は、発側の端末50sの識別子(例えば、電話番号)である。発側通信装置識別子は、発側の通信装置30sの識別子である。着側端末識別子は、着側の端末50rの識別子(例えば、電話番号)である。確認フラグは、一つの呼損リスト内における各エントリを、公平に処理するために利用されるフラグである。なお、呼損リストは、着側の通信装置30の識別子(着側通信装置識別子)ごとにまとめられる。したがって、図9に示されるように、呼損リストの各エントリには、着側の通信装置30の識別子は含まれなくてもよい。
続いて、端末情報制御部12は、通信装置30sを介して、発側の端末50sに対して、呼損となったことを通知すると共に、当該端末50sに関して発呼規制を実施する(S215、S216)。発呼規制の実施は、例えば、発呼を規制することを示す情報を、端末50sに送信することにより行われてもよい。端末50sは、当該情報を解釈し、ユーザによって発呼の指示が入力されても、発呼の実行を拒否する。
一方、通信接続の成功を示す情報が受信され、かつ、受信された発呼情報に含まれている、発側の通信装置30sの識別子及び着側の通信装置30rの識別子の少なくともいずれか一方が、被災地リスト記憶部113に記憶されている場合、端末情報制御部12は、発側の通信装置30s及び着側の通信装置30rのそれぞれに関する通信要求情報を更新する(S217)。
具体的には、通信装置30sを通信装置30i、通信装置30rを通信装置30jとすると、通信装置30iが被災地エリアに属する場合、tiに1が加算される。一方、通信装置30iが非被災地エリアに属する場合、ntiに1が加算される。また、通信装置30jが被災地エリアに属する場合、Tjに1が加算される。一方、通信装置30jが非被災地エリアに属する場合、NTjに1が加算される。
続いて、呼損リストに基づいて、リソース管理装置10から発呼が行われる場合に実行される処理手順について説明する。図10は、呼損リストに基づく発呼に応じて実行される処理手順の一例を説明するためのシーケンス図である。
着側専用リソース上限値RSRの値が1以上である各通信装置30のリソース情報送信部31は、当該通信装置30の着側専用リソース使用値Rsrを監視しており、着側専用リソース使用値Rsrが減少した場合(着側専用リソースに空きが発生した場合)、着側専用リソースの空きリソース量(RSR−Rgr)を、リソース管理装置10の呼損端末接続部13に送信する。図5では、通信装置30rによって、当該空きリソース量が送信された例が示されている(S301)。
呼損端末接続部13は、当該空きリソース量を受信すると、当該空きリソース量の送信元の通信装置30rに関して呼損リスト記憶部112に記憶されている呼損リストから、確認フラグの値が0であるエントリに含まれる発呼情報を取得する(S302)。該当する発呼情報が1以上取得された場合、呼損端末接続部13は、当該発呼情報のエントリの確認フラグの値を1に更新する。なお、全てのエントリの確認フラグの値が1であった場合、全てのエントリの確認フラグの値を0に更新した後、ステップS302が実行される。また、ステップS302において、該当する発呼情報が複数取得された場合、複数の発呼情報のうちの一つが選択されて、ステップS303以降が実行される。以下、選択された発呼情報を「対象発呼情報」という。
続いて、呼損端末接続部13は、対象発呼情報に含まれる発側通信装置識別子に係る通信装置30sに、発側専用リソースの空き状況を問い合わせる(S303)。当該通信装置30sのリソース情報送信部31は、当該問い合わせに応じ、発側専用リソース上限値SSR−発側専用リソース使用値Ssr(すなわち、発側専用リソースの空きリソース量)を算出する(S304)。続いて、リソース情報送信部31は、算出結果を呼損端末接続部13に返信する(S305)。
呼損端末接続部13は、受信されたリソース空き量が1以上の値を示す場合(すなわち、発側専用リソースに空きが有る場合)、セッション管理装置20に対して発呼を実施する(S306)。当該発呼において、対象発呼情報に含まれる発側端末識別子に係る端末50が発側の端末50sであり、着側端末識別子に係る端末50が着側の端末50rである。
セッション管理装置20は、呼損端末接続部13からの発呼に応じて、当該呼の発側の通信装置30sに対して、通信リソースの割り当て可否の問い合わせを送信する(S307)。当該問い合わせには、割り当て対象が発側のリソースであること、及びリソース管理装置10からの発呼による通信リソースの割り当てであることを示す情報が含まれる。
通信装置30sのリソース割当制御部33は、当該問い合わせを受信すると、当該問い合わせが発側の通信リソースに関する問い合わせであり、かつ、リソース管理装置10の発呼による通信リソースの割り当てであることに応じ、リソース情報記憶部301を参照して、発側専用リソース上限値SSR−発側専用リソース使用値Ssr≧1であるか否かを判定する(S308)。すなわち、発側専用リソースに空きがあるか否かが判定される。続いて、リソース割当制御部33は、割り当ての可否を示す判定結果をセッション管理装置20に返信する(S309)。
セッション管理装置20は、また、当該発呼の着側の通信装置30rに対して、通信リソースの割り当て可否の問い合わせを送信する(S310)。当該問い合わせには、割り当て対象が着側の通信リソースであること、及びリソース管理装置10の発呼による通信リソースの割り当てであることを示す情報が含まれる。
通信装置30rのリソース割当制御部33は、当該問い合わせを受信すると、当該問い合わせが着側の通信リソースに関する問い合わせであり、かつ、リソース管理装置10の発呼による通信リソースの割り当てであることに応じ、リソース情報記憶部301を参照して、着側専用リソース上限値RSR−着側専用リソース使用値Rsr≧1であるか否かを判定する(S311)。すなわち、着側専用リソースに空きがあるか否かが判定される。続いて、リソース割当制御部33は、割り当ての可否を示す判定結果をセッション管理装置20に返信する(S312)。
なお、ステップS307〜S309と、ステップS310〜S312とは並列的に実行されてもよいし、直列的に実行されてもよい。直列的に実行される場合、先に実行された問い合わせに関する判定結果が、割り当て不可(通信リソースの不足)を示す場合、他方の問い合わせは実行されなくてもよい。
双方の判定結果が、割り当ての可能を示す場合、セッション管理装置20は、当該発呼に関する接続要求を、通信装置30s及び通信装置30rのそれぞれに送信する(S313、S315)。通信装置30sのリソース割当制御部33は、発側専用リソースを当該発呼に対して1つ割り当てる(S314)。したがって、発側専用リソース使用値Ssrに1が加算される。また、通信装置30rのリソース割当制御部33は、着側専用リソースを当該発呼に対して1つ割り当てる(S316)。したがって、着側専用リソース使用値Rgrに1が加算される。なお、通信装置30sは、発側の端末50sを呼び出し、通信装置30rは、着側の端末50rを呼び出してもよい。そうすることにより、端末50sのユーザ及び端末50rのユーザのそれぞれは、通信が接続されたことを認識することができる。
続いて、セッション管理装置20は、リソース管理装置10の呼損端末接続部13に、通信接続の成否を示す情報と、対象発呼情報とを送信する(S317)。対象発呼情報には、発側の端末50s及び通信装置30sのそれぞれの識別子、並びに着側の端末50r及び通信装置30rのそれぞれの識別子と、発呼の成否を示す情報とが含まれる。
呼損端末接続部13は、発呼の成功を示す情報が受信された場合、受信された対象発呼情報の削除を端末情報制御部12に指示する(S318)。端末情報制御部12は、対象発呼情報を含むエントリを、当該エントリが属する呼損リストから削除する(S319)。続いて、端末情報制御部12は、対象発呼情報の発側通信装置識別子に係る通信装置30sを介して、対象発呼情報の発側端末識別子に係る端末50sの発呼規制を解除する(S320、S321)。
なお、ステップS306以降は、ステップS301において受信された着側専用リソース量の空きリソース量とステップS305で受信された発側専用リソースの空きリソース量との許容範囲内において、ステップS302において取得された各発呼情報に関して順番に繰り返し実行される。
続いて、各シーケンス図において説明した処理手順に関して、専用リソース制御部11、端末情報制御部12、及び呼損端末接続部13のそれぞれが実行する処理手順について、フローチャートを用いて説明する。
図11は、専用リソース制御部が実行する処理手順の一例を説明するためのフローチャートである。図11中、括弧内のステップ番号は、図5において対応するステップのステップ番号である。
ステップS501において、専用リソース制御部11は、その識別子が被災地リスト記憶部113に記憶されている各通信装置30からリソース情報を取得し、当該リソース情報に基づいて算出される、発側専用リソース上限値SSR及び着側専用リソース上限値RSRのそれぞれの初期値を、当該各通信装置30に通知する。
その後、専用リソース制御部11は、一定時間間隔で(S502)、ステップS503〜S505を繰り返し実行する。
ステップS503において、専用リソース制御部11は、被災地エリアに属する各通信装置30に関して通信要求情報記憶部111に記憶されている通信要求情報を取得し、各通信要求情報に基づいて、当該通信要求情報に対応する通信装置30の発側専用リソース上限値SSR及び着側専用リソース上限値RSRを算出する。算出方法は、ステップS106において説明した通りである。
続いて、専用リソース制御部11は、算出された着側専用リソース上限値RSRが0より大きい通信装置30の有無を判定する(S504)。該当する通信装置30が有る場合(S504でYES)、専用リソース制御部11は、通信装置30ごとに算出された発側専用リソース上限値SSR及び着側専用リソース上限値RSRを、各通信装置30に送信する(S505)。続いて、専用リソース制御部11は、各通信要求情報の各パラメータを0に初期化する(S506)。なお、ステップS504でYESのケースは、図5において説明済みである。
一方、各通信装置30に関して算出された着側専用リソース上限値RSRの全てが0である場合(S504でNO)、専用リソース制御部11は、被災地エリアに属する各通信装置30に対して、発側専用リソース上限値SSR及び着側専用リソース上限値RSRのそれぞれを0にすることの指示を送信する(S507)。その結果、当該各通信装置30において、発側及び着側のそれぞれの通信リソースの分割は解除される。
続いて、専用リソース制御部11は、端末情報制御部12に対し、呼損リストの解放を指示し(S508)、図11の処理を終了する。端末情報制御部12は、当該指示に応じ、各呼損リストの各エントリに含まれている各発呼情報の発側端末識別子に係る端末50の発呼規制を解除し、全ての呼損リストを削除する。
すなわち、全ての被災地エリアの全ての通信装置30の着側専用リソース上限値RSRが0になったということは、一定時間において呼損が解消されたことを意味する。したがって、専用リソースを解放し、通常の通信状態に戻すための処理が実行される。
続いて、端末情報制御部12が実行する処理手順について説明する。図12は、端末情報制御部がセッション管理装置から発呼情報を受信した際に実行する処理手順の一例を説明するためのフローチャートである。図12中、括弧内のステップ番号は、図8において対応するステップのステップ番号である。
端末情報制御部12は、セッション管理装置20から発呼の成否を示す情報及び発呼情報を受信すると、当該発呼の成否を示す情報が失敗(呼損)を示すものであるか否かを判定する(S601)。呼損である場合(S601でYES)、端末情報制御部12は、当該発呼情報に含まれている発側通信装置識別子及び着側通信装置識別子の双方が、被災地リスト記憶部113に記憶されているか否かを判定する(S602)。少なくともいずれか一方の識別子が、被災地リスト記憶部113に記憶されていない場合(S602でNO)、図12の処理は終了する。
双方の識別子が被災地リスト記憶部113に記憶されている場合(S602でYES)、端末情報制御部12は、当該発呼情報に含まれている着側通信装置識別子に係る呼損リストに、当該発呼情報を含むエントリを追加する(S603)。続いて、端末情報制御部12は、当該発信情報の発側版末識別子に係る端末50に呼損を通知し、当該端末50に関して発呼規制を実施して(S604)、図12の処理を終了する。
一方、呼損でない場合(S601でNO)、端末情報制御部12は、発側及び着側の少なくともいずれか一方の通信装置30が被災地エリアに属するか否かを判定する(S605)。発側及び着側の少なくともいずれか一方の通信装置30が被災地エリアに属する場合(S605でYES)、端末情報制御部12は、発側の通信装置30と着側の通信装置30とのそれぞれに関する通信要求情報(図7)を更新する(S606)。
図13は、端末情報制御部が呼損端末接続部から成功した発呼に関する発呼情報を受信した際に実行する処理手順の一例を説明するためのフローチャートである。図13中、括弧内のステップ番号は、図10において対応するステップのステップ番号である。
端末情報制御部12は、発呼の成功を示す情報と当該発呼に関する発呼情報とを呼損端末接続部13から受信すると、当該発呼情報を含むエントリを、当該発呼情報が属する呼損リストから削除する(S701)。続いて、端末情報制御部12は、当該発呼情報の発側端末識別子に係る端末50の発呼規制を解除する(S702)。
続いて、呼損端末接続部13が実行する処理手順について説明する。図14は、呼損端末接続部が実行する処理手順の一例を説明するためのフローチャートである。図14中、括弧内のステップ番号は、図10において対応するステップのステップ番号である。
呼損端末接続部13は、被災地エリア内のいずれかの通信装置30から着側専用リソースの空きリソース量を受信すると、当該通信装置30の呼損リストを呼損リスト記憶部112から取得する(S801)。続いて、呼損端末接続部13は、当該呼損リストに1以上のエントリが有るか否かを判定する(S802)。エントリが無い場合(S802でNO)、呼損端末接続部13は、一定時間待機後(S803)、ステップS802を繰り返す。
エントリが有る場合(S803でYES)、呼損端末接続部13は、当該呼損リストの並び順の先頭から、確認フラグ=0であるエントリを探索する(S804)。確認フラグ=0であるエントリが無い場合(S804でYES)、呼損端末接続部13は、当該当該呼損リストの全てのエントリの確認フラグの値に0を設定し(S806)、ステップS804以降を繰り返す。
確認フラグ=0であるエントリが有る場合(S805でNO)、呼損端末接続部13は、当該エントリの確認フラグに1を設定する(S807)。続いて、呼損端末接続部13は、当該エントリに含まれている発呼情報の発側通信装置識別子に係る通信装置30に、発側専用リソースの空き状況を問い合わせる(S808)。
当該発側専用リソースに1以上の空きが無い場合(S809でNO)、呼損端末接続部13は、ステップS804以降を繰り返す。当該発側専用リソースに1以上の空きが有る場合(S809でYES)、呼損端末接続部13は、当該発呼情報に係る発側の端末50と着側の端末50との通信接続を実施する(S810)。通信接続が失敗した場合(S811でNO)、呼損端末接続部13は、ステップS804以降を繰り返す。通信接続が成功した場合(S811でYES)、呼損端末接続部13は、端末情報制御部12に発呼情報を通知し、当該発呼情報を含むエントリについて、呼損リストからの削除を指示する(S812)。
続いて、呼損端末接続部13は、ステップS801において取得された呼損リストに係る通信装置30に着側専用リソースの空きが有るか否かを判定する(S813)。当該判定は、当該通信装置30に対して問い合わせを行うことにより実行されてもよい。当該着側専用リソースに空きが有る場合(S813でNO)、呼損端末接続部13は、ステップS804以降を繰り返す。当該着側専用リソースに空きが無い場合(S813でNO)、図14の処理は終了する。
上述したように、本実施の形態によれば、災害発生時に、被災地間の通信に備えて専用の通信リソースが発側及び着側それぞれの通信装置30に用意されるため、被災地間以外の通信によって、通信リソースが使い切られてしまうことを防ぐことができる。また、呼損となった被災地間の通信が管理され、発側専用リソース及び着側専用リソースの空きが確認され次第、呼損となった通信が移動体通信網側の主導により順次接続されるため、専用リソースの空き時間を削減し、通信リソースの利用効率を維持することができる。
これにより、被災地間通信において、発側及び着側の双方の通信リソースを同時に確保し、確保した通信リソースの空き時間を長引かせない運用が可能となる。その結果、発側又は着側の一方の通信リソースの不足による呼損が回避され、不要な再呼を減らすことが可能となる。
したがって、被災地における発側及び着側の通信リソースが必要となる被災地間通信を迅速に処理することが可能となり、再呼する端末50の減少及び通信リソースの利用率低下が促進され、輻輳の早期解消を期待することができる。なお、被災地間通信とは、同じ被災地エリア内の通信であってもよいし、異なる被災地エリア間の通信であってもよい。
続いて、本実施の形態による、輻輳を早期に解消させる効果に関する評価結果について以下に記す。本実施の形態の評価においては、図15に示されるような発呼要求が有るものとする。
図15は、本実施の形態の評価のためのシミュレーションの条件を説明するための図である。図15に示されるように、被災地エリアA1内に500台の端末50(以下、「被災地端末50」という。)、非被災地エリアA2内に500台の端末50(以下、「非被災地端末50」という。)が存在し、発呼要求C1〜C3が有るものとする。発呼要求C1は、500台の非被災地端末50から被災地端末50への発呼要求である。発呼要求C2は、250台の被災地端末50から非被災地端末50への発呼要求である。発呼要求C3は、250台の被災地端末50から被災地端末50への発呼要求である。各端末50の通信相手は、3人居るものとし、一様乱数にて設定される。
シミュレーション開始と同時に、各端末50は、図16に示されるような状態遷移を実施する。図16は、本実施の形態の評価のためのシミュレーションにおいて端末が実施する状態遷移を示す図である。
まず、端末50は、それぞれに設定されている通信相手の中から1台を発信先として選択した後、発呼状態に遷移する。発呼状態において、通信リソースが空いており、相手の端末50が話中でない場合、通信状態に遷移する。一定時間通信後、全ての通信相手と通信が成功した場合、行動終了となる。発呼状態において、通信リソースが不足している、又は当該端末50が、%規制グループに属していた場合、待機状態に遷移して一定時間経過した後、発信相手を変更して発呼状態に戻る。待機時間は、平均10分の正規分布に従い、通信時間は平均3分の正規分布に従うものとする(標準偏差は1)。また、発側及び着側のそれぞれについて、最大10台の端末50まで同時に通信可能であるとする。
上記の条件によるシミュレーションを、%規制による発呼規制が動作している状況で、本実施の形態を適用して実行した場合(以下、「ケースA」という。)、及び本実施の形態を適用しないで実行した場合(以下、「ケースB」という。)のそれぞれについて、行動中の端末数の時間経過について比較する。
%規制における規制の内容は、被災地エリアA1内の全端末50を10グループに分割し、そのうちの9グループに属する端末50の発呼を一定時間禁止するというものである。なお、発呼が禁止される規制グループは、10分毎にスライドするものとする。例えば、グループ1〜9までが規制グループの状態で10分経過すると、グループ2〜10までが規制グループとなる。
図17は、ケースA及びケースBのそれぞれにおける行動中の端末数の推移を示す図である。図17において、太い実線はケースAについて行動中の全端末数、太い破線はケースBについて行動中の全端末数、細い実線はケースAについて被災地エリアA1で行動中の端末数、細い破線はケースBについて被災地エリアA1で行動中の端末数である。
図17より、ケースAは、ケースBに対して、全端末50が行動終了となるまでに要される時間が短縮されることが確認できる。また、被災地端末50が行動終了となるまでに要される時間についてもケースAの方が短いが、これは、本実施の形態によって、被災地間通信用の専用のリソースが用意されることで、被災地エリアA1内での発呼が成功し易くなったためであると考えられる。本実施の形態が適用されない場合、被災地端末50に向けた発呼は、非被災地端末50(500台)の方が、被災地端末50(250台)より多く、シミュレーション終了まで、発呼が成功しづらい状況になっている。
本実施の形態の適用により、全端末50が行動終了になるまでの所要時間が短縮されるのは、被災地エリアA1内の発信用の通信リソースと着信用の通信リソースが空き次第、(呼損リストに基づいて)発側の端末50と着側との端末50とを即時的に接続することで、リソースが空く時間を削減出来ているためであると考えられる。
上記より、本実施の形態によれば、輻輳を早期に解消させる効果が得られることが確認できた。
なお、本実施の形態では、被災地エリアの通信装置30が、被災地リスト記憶部113に登録される例を示したが、被災地エリア以外の通信装置30であって、被災地に類似した輻輳が発生する通話エリアの通信装置30が、被災地リスト記憶部113に登録されてもよい。例えば、年末年始等や何らかの行事等によって人(端末50)が集中する通話エリア等が、被災地リスト記憶部113に登録されてもよい。そうすることで、被災地間通信のみならず、他の混雑エリア間通信に関しても、輻輳を早期に解消させることができる。
なお、本実施の形態において、専用リソース制御部11は、分割部の一例である。呼損リスト記憶部112は、第一の記憶部の一例である。端末情報制御部12は、規制部の一例である。呼損端末接続部13は、接続部の一例である。発側汎用リソース、発側専用リソース、着側汎用リソース、着側専用リソースは、それぞれ第一の通信リソース、第二の通信リソース、第三の通信リソース、第四の通信リソースの一例である。被災地リスト記憶部113は、第二の記憶部の一例である。
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。