JP6186323B2 - 通信システム、リソース管理装置、及び通信方法 - Google Patents

Description

本発明は、通信システム、リソース管理装置、及び通信方法に関する。

災害時には、非被災地と被災地との間や被災地と被災地との間において、安否確認等の呼が大量に発生し、被災地の通信設備において、想定を超えた呼処理の負荷や回線等の通信リソースの不足等により輻輳が生じる。輻輳による通話サービスの接続品質の低下を避けるためのアプローチの一つとして、端末の発呼を規制する手法が従来から検討されており、一部の手法は通信キャリアにおいて導入されている。

例えば、通信設備の呼処理に対する負荷の増大や災害の規模等に応じて、一部の端末の発呼を定期的に禁止する手法（以下「％規制」という。）が、通信キャリアにおいて導入されている（例えば、特許文献１、非特許文献１等参照）。

図１は、％規制を説明するための図である。％規制は、端末の居場所を特定するための最小単位のエリア内に存在する端末群を複数のグループに分けて管理し、グループ単位で端末による発呼を規制する手法である。図１では、端末群が、１０個のグループに分けられて管理される例が示されている。

規制対象となるグループは一定時間毎に変化し、発呼を規制するための規制情報は、無線基地局（ＢＴＳ）から規制対象のグループに属する端末に送信される。図１では、グループ２〜６の５０％のグループに関して規制が行われる状態が示されている。

％規制は、端末の発呼を一定時間規制することで、端末が発呼可能な機会を平等にしつつ、通信設備の呼処理に係る負荷を軽減し、通信設備の呼処理性能の低下や機能停止を避けることを目的としている。しかし、規制のタイミングを端末が知ることができず、空いた回線リソースの使用は発呼の受け付け順となるため、一部の端末が長期間回線を占有してしまう可能性があり、回線利用数に関して端末間の公平性が損なわれる可能性が有る。例えば、通信が何度も成功する端末が発生する一方で、一度も通信が成功しない端末が発生する可能性が有る。

そこで、回線利用数の不公平性に着目し、災害時における見舞い呼は、"家族や友人など通信相手の数が少数であるユーザの割合が多い"との仮定に基づき、通信接続に成功した端末に関してはその後の発呼を一時的に規制し、通信に成功していない端末を繋がり易くすることで、通信相手が少数な端末の発呼要求を早い段階で満たし、再呼する端末の数を減らし、輻輳を早期に解消させる手法（以下「成功端末規制」という。）が検討されている（例えば、非特許文献２参照）。

特開平８−３１７４７１号公報

伊藤正憲，"NTTドコモの防災への取り組み 携帯電話を活用した情報配信"，デジタル放送研究会 第2回勉強会，Jun. 2007 塩津晃明，土屋利明，長谷川治久，"通信履歴を用いた発呼制御法による輻輳解消効果の評価"，信学会総大，B-6-81, Mar. 2013

しかしながら、成功端末規制は、非被災地端末から被災地に向かう発呼の制御を対象としており、発側の通信リソースが不足していないことを仮定している。そのため、非被災地から被災地に向かう呼と、被災地間における呼との間では、成功端末規制の適用時の効果が異なると考えられる。すなわち、被災地間における発呼に関して成功端末規制が適用された場合、発側の通信リソース不足による呼損が多く発生することが想定され、非被災地から被災地に向かう呼と比較して、発着端末の通信成功までに要する時間が長くなり、輻輳時間の短縮効果が小さくなることが見込まれる。

本発明は、上記の点に鑑みてなされたものであって、発側及び着側の双方において通信リソースの不足が発生する場合でも輻輳を早期に解消可能とすることを目的とする。

そこで上記課題を解決するため、本発明は、移動体通信網の通話エリアごとの発信用の通信リソースを第一の通信リソースと第二の通信リソースとに分割し、前記通話エリアごとの着信用の通信リソースを第三の通信リソースと第四の通信リソースとに分割する分割部と、第一の端末からの発呼に応じ、当該発呼の発側の第一の通話エリアの前記第一の通信リソース及び当該発呼の着側の第二の通話エリアの前記第三の通信リソースの少なくともいずれか一方が不足している場合に、前記第一の端末の識別子及び当該発呼に係る着側の第二の端末の識別子を記憶する第一の記憶部と、前記第一の記憶部に前記識別子が記憶された前記第一の端末からの発呼を規制する規制部と、前記第二の通話エリアの前記第四の通信リソースの空きの発生に応じ、前記第一の記憶部に記憶されている前記識別子に基づいて、前記第一の端末と前記第二の端末との通信を、前記第一の通話エリアの前記第二の通信リソースと当該第四の通信リソースとを用いて接続させる接続部と、を有する。

発側及び着側の双方において通信リソースの不足が発生する場合でも輻輳を早期に解消可能とすることができる。

％規制を説明するための図である。 本発明の実施の形態における通信システムの構成例を示す図である。 本発明の実施の形態におけるリソース管理装置のハードウェア構成例を示す図である。 本発明の実施の形態におけるリソース管理装置及び通信装置の機能構成例を示す図である。 リソース管理装置の起動時に実行される処理手順の一例を説明するためのシーケンス図である。 リソース情報記憶部の構成例を示す図である。 通信要求情報記憶部の構成例を示す図である。 端末からの発呼に応じて実行される処理手順の一例を説明するためのシーケンス図である。 一つの通信装置に対する呼損リストの構成例を示す図である。 呼損リストに基づく発呼に応じて実行される処理手順の一例を説明するためのシーケンス図である。 専用リソース制御部が実行する処理手順の一例を説明するためのフローチャートである。 端末情報制御部がセッション管理装置から発呼情報を受信した際に実行する処理手順の一例を説明するためのフローチャートである。 端末情報制御部が呼損端末接続部から成功した発呼に関する発呼情報を受信した際に実行する処理手順の一例を説明するためのフローチャートである。 呼損端末接続部が実行する処理手順の一例を説明するためのフローチャートである。 本実施の形態の評価のためのシミュレーションの条件を説明するための図である。 本実施の形態の評価のためのシミュレーションにおいて端末が実施する状態遷移を示す図である。 ケースＡ及びケースＢのそれぞれにおける行動中の端末数の推移を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。図２は、本発明の実施の形態における通信システムの構成例を示す図である。図２において、通信システム１は、移動体通信に関するシステムであり、発側エリアＡｓ、着側エリアＡｒ、セッション管理装置２０、及びリソース管理装置１０等を含む。

発側エリアＡｓは、本実施の形態において発呼側の通話エリアである。着側エリアＡｒは、本実施の形態において着呼側の通話エリアである。なお、発側及び着側は、相対的な関係にすぎない。したがって、発側エリアＡｓにおいて着呼されてもよいし、着側エリアＡｒにおいて発呼されてもよい。また、発側エリアＡｓ及び着側エリアＡｒを区別しない場合、単に「エリア」という。エリアは、端末の居場所を特定するための最小単位の範囲である。

各エリアは、１以上の端末５０、基地局４０、及び通信装置３０等を含む。端末５０は、例えば、フィーチャーフォン、スマートフォン、又はタブレット端末等、移動体通信網を利用した通話に用いられる携帯端末である。基地局４０は、移動体通信網における基地局４０である。すなわち、基地局４０は、移動体通信網の末端に位置し、端末５０と直接通信を行う。通信装置３０は、交換機等を含む通信設備である。各基地局４０は、通信装置３０に接続される。なお、発側エリアＡｓに含まれる各装置の符号の末尾には「ｓ」が付与され、着側エリアＡｒに含まれる各装置の符号の末尾には「ｒ」が付与される。

セッション管理装置２０は、いずれかの端末５０からの発呼に応じ、当該発呼の発側及び着側のそれぞれの通信装置３０に対して通信リソースの割り当てを指示し、当該発呼に関する通信の接続を制御するコンピュータである。

リソース管理装置１０は、発側エリアＡｓの端末５０ｓと着側エリアＡｒの端末５０ｒとの双方が被災地である場合に、移動体端末網における輻輳を早期に解消するための処理を実行するコンピュータである。

なお、セッション管理装置２０及びリソース管理装置１０は、ネットワーク等を介して各通信装置３０と通信可能に接続される。

図３は、本発明の実施の形態におけるリソース管理装置のハードウェア構成例を示す図である。図３のリソース管理装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

リソース管理装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってリソース管理装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

図４は、本発明の実施の形態におけるリソース管理装置及び通信装置の機能構成例を示す図である。図４において、リソース管理装置１０は、専用リソース制御部１１、端末情報制御部１２、及び呼損端末接続部１３等を有する。これら各部は、リソース管理装置１０にインストールされたプログラムが、ＣＰＵ１０４に実行させる処理により実現される。又は、これら各部は、回路等のハードウェアによって実現されてもよい。リソース管理装置１０は、また、通信要求情報記憶部１１１、呼損リスト記憶部１１２、及び被災地リスト記憶部１１３等を利用する。これら各記憶部は、補助記憶装置１０２、又はリソース管理装置１０にネットワークを介して接続される記憶装置等を用いて実現可能である。

専用リソース制御部１１は、被災地の各エリア（以下、「被災地エリア」という。）の通信装置３０通信リソースを、汎用リソースと専用リソースとに分割する。具体的には、専用リソース制御部１１は、被災地エリアの通信装置３０の専用リソースの上限値を算出する。本実施の形態において、専用リソースとは、被災地エリア間において呼損となった呼に関して使用される通信リソースをいう。汎用リソースとは、専用リソースが使用される呼以外の呼に関して使用される通信リソースをいう。例えば、汎用リソースは、発側及び着側の少なくともいずれか一方が、非被災地エリアである呼に関して使用される。なお、通信リソースとは、例えば、回線数や、周波数帯域等である。また、被災地エリアの通信装置３０は、被災地リスト記憶部１１３を参照することにより特定可能である。すなわち、被災地リスト記憶部１１３には、例えば、オペレータによる操作等に応じて、被災地エリアの通信装置３０の識別子が記憶される。

専用リソース制御部１１は、通信要求情報記憶部１１１に記憶される通信要求情報に基づいて、一定期間ごとに専用リソースの上限値を算出する。なお、専用リソースの上限値を算出することは、汎用リソースの上限値を算出することにもなる。或る通信装置３０の専用リソースの上限値と、汎用リソースの上限値との和は、当該通信装置３０の通信リソースの上限値となるからである。

通信要求情報記憶部１１１は、発側及び着側の少なくともいずれか一方が被災地エリアである呼の発側の通信装置３０及び着側の通信装置３０ごとに、通信要求情報を記憶する。通信要求情報には、当該各通信装置３０の着信端末数や発信端末数等が含まれる。

端末情報制御部１２は、発側及び着側の双方が被災地エリアである発呼に関して呼損が発生した場合に、発側の端末５０の発呼を規制すると共に、当該呼損に係る発呼に関する情報（発呼情報）を、呼損リスト記憶部１１２に登録する。なお、呼損リスト記憶部１１２には、通信装置３０ごとに呼損リストが記憶されている。発呼情報は、呼損に係る発呼の着側の通信装置３０に対応する呼損リストに登録される。

呼損端末接続部１３は、呼損リスト記憶部１１２に登録されている発呼情報に基づいて、当該発呼情報に係る発側の端末５０と着側の端末５０との通信の接続を、セッション管理装置２０に要求する。当該通信の接続に成功した場合、当該発呼情報は、呼損リストから削除され、当該発呼情報に係る発側の端末５０の発呼規制は解除される。呼損端末接続部１３は、また、セッション管理装置２０から通知される、端末５０からの発呼の成否を示す情報等に基づいて、当該発呼の発側の通信装置３０及び着側の通信装置３０のそれぞれの通信要求情報を更新する。

一方、各通信装置３０は、リソース情報送信部３１、リソース設定部３２、及びリソース割当制御部３３等を有する。これら各部は、通信装置３０にインストールされたプログラムが、通信装置３０のＣＰＵに実行させる処理により実現される。又は、これら各部は、回路等のハードウェアによって実現されてもよい。通信装置３０は、また、リソース情報記憶部３０１を利用する。これらリソース情報記憶部３０１は、通信装置３０の補助記憶装置、又は通信装置３０にネットワークを介して接続される記憶装置等を用いて実現可能である。

リソース情報送信部３１は、リソース情報記憶部３０１に記憶されているリソース情報を参照して、リソースの空き状況をリソース管理装置１０に通知する。リソース情報は、専用リソース及び汎用リソースの上限値や使用値等を含む情報である。

リソース設定部３２は、リソース管理装置１０の専用リソース制御部１１によって算出される専用リソースの上限値と、専用リソースの上限値によって特定される汎用リソースの上限値とをリソース情報記憶部３０１に設定する。

リソース割当制御部３３は、セッション管理装置２０からリソースの割り当ての可否について問い合わせを受けた場合に、リソース情報に基づいて応答を行う。

以下、通信システム１において実行される処理手順について説明する。本実施の形態における処理手順は、例えば、災害発生時に、オペレータによって被災地エリアの通信装置３０のリストが、リソース管理装置１０の被災地リスト記憶部１１３に登録されることにより有効となる。

図５は、リソース管理装置の起動時に実行される処理手順の一例を説明するためのシーケンス図である。リソース管理装置１０は、例えば、災害発生時に起動される。

リソース管理装置１０の起動に応じ、専用リソース制御部１１は、各被災地エリアの通信装置３０に、リソース情報の取得要求を送信する（Ｓ１０１）。各被災地エリアの通信装置３０は、被災地リスト記憶部１１３に記憶されている、各通信装置３０の識別子に基づいて特定可能である。

当該取得要求を受信した各通信装置３０のリソース情報送信部３１は、当該通信装置３０のリソース情報記憶部３０１に記憶されているリソース情報を返信する（Ｓ１０２）。

図６は、リソース情報記憶部の構成例を示す図である。図６において、リソース情報記憶部３０１は、着側汎用リソースの上限値ＲＧＲ及び使用値Ｒｇｒ、着側専用リソースの上限値ＲＳＲ及び使用値Ｒｓｒ、発側汎用リソースの上限値ＳＧＲ及び使用値Ｓｇｒ、並びに発側専用リソースの上限値ＳＳＲ及び使用値Ｓｓｒ等を含むリソース情報を記憶する。

着側汎用リソースとは、着信用の汎用リソースをいう。本実施の形態において、通信リソースの上限値及び使用値の単位は、端末数であるとする。すなわち、例えば、上限値は、当該通信リソースを使用可能な端末数の上限値であり、使用値は、当該通信リソースを使用している端末５０の数である。

着側専用リソースとは、着信用の専用リソースをいう。発側汎用リソースとは、発信用の汎用リソースをいう。発側専用リソースとは、発信用の専用リソースをいう。

なお、災害発生前、すなわち、図５の処理が実行される前において、着側汎用リソース上限値ＲＧＲは、通信装置３０の着信用の通信リソースの上限値に一致する。また、発側汎用リソース上限値ＳＧＲは、通信装置３０の発信用の通信リソースの上限値に一致する。換言すれば、災害発生前において、着側専用リソース上限値ＲＳＲ及び発側専用リソース上限値ＳＳＲは、いずれも０である。

続いて、専用リソース制御部１１は、着側専用リソース上限値ＲＳＲ及び発側専用リソース上限値ＳＳＲの初期値を、被災地エリアの各通信装置３０に送信する（Ｓ１０３）。各通信装置３０の当該初期値は、例えば、各通信装置３０の着側汎用リソース上限値ＲＧＲ又は発側汎用リソース上限値ＳＧＲに基づいて決定される。例えば、着側専用リソース上限値ＲＳＲの初期値は、着側汎用リソース上限値ＲＧＲの５０％とされ、発側専用リソース上限値ＳＳＲの初期値は、発側汎用リソース上限値ＳＧＲの５０％とされる。

各通信装置３０のリソース設定部３２は、当該初期値の受信に応じ、リソース情報記憶部３０１に記憶されているリソース情報を更新する（Ｓ１０４）。具体的には、当該リソース情報の着側専用リソース上限値ＲＳＲ及び着側専用リソース上限値ＲＳＲのそれぞれは、受信された初期値によって更新される。また、当該リソース情報の着側汎用リソース上限値ＲＧＲからは、更新後の着側専用リソース上限値ＲＳＲが差し引かれる。また、当該リソース情報の発側汎用リソース上限値ＳＧＲからは、更新後の発側専用リソース上限値ＳＳＲが差し引かれる。その結果、各通信装置３０の着側及び発側のそれぞれの通信リソースは、汎用リソースと専用リソースとに分割される。

リソース管理装置１０の専用リソース制御部１１は、ステップＳ１０３の実行後、一定時間待機する（Ｓ１０５）。一定時間待機後、専用リソース制御部１１は、通信要求情報記憶部１１１から、被災地エリアに属する各通信装置３０の通信要求情報を取得し、当該通信要求情報に基づいて、当該各通信装置３０の着側専用リソース上限値ＲＳＲ及び発側専用リソース上限値ＳＳＲのそれぞれを算出する（Ｓ１０６）。

図７は、通信要求情報記憶部の構成例を示す図である。図７に示されるように、通信要求情報記憶部１１１は、発側及び着側の少なくともいずれか一方が被災地エリアである呼の発側の通信装置３０及び着側の通信装置３０ごとに、通信要求情報を記憶する。

通信要求情報は、非被災地着信端末数ＮＴ_ｉ、被災地着信端末数Ｔ_ｉ、非被災地発信端末数ｎｔ_ｉ、及び被災地発信端末数ｔ_ｉ等を含む。ここで、ｉは、被災地エリアに属する各通信装置３０の識別子である。

非被災地着信端末数ＮＴ_ｉは、通信装置３０ｉが非被災地エリアに属する場合に、通信装置３０ｉのエリア内において、被災地エリアに属する端末５０からの呼の着信に成功した端末５０の数である。

被災地着信端末数Ｔ_ｉは、通信装置３０ｉが被災地エリアに属する場合に、通信装置３０ｉのエリア内において、被災地エリア又は非被災地エリアに属する端末５０からの呼の着信に成功した端末５０の数である。

非被災地発信端末数ｎｔ_ｉは、通信装置３０ｉが非被災地エリアに属する場合に、通信装置３０ｉのエリア内において、被災地エリアに属する端末５０への発呼に成功した端末５０の数である。発呼の成功とは、発信された呼に関して通信が接続されたことをいう。

被災地発信端末数ｔ_ｉは、通信装置３０ｉが被災地エリアに属する場合に、通信装置３０ｉのエリア内において、被災地エリア又は非被災地エリアに属する端末５０への発呼に成功した端末５０の数である。

なお、非被災地着信端末数ＮＴ_ｉ、被災地着信端末数Ｔ_ｉ、非被災地発信端末数ｎｔ_ｉ、及び被災地発信端末数ｔ_ｉの初期値は、いずれも０である。したがって、ステップＳ１０６におけるこれらのパラメータの値は、ステップＳ１０５において待機される一定時間において計測された値である。

このようなパラメータを含む通信要求情報に基づく着側専用リソース上限値ＲＳＲ及び発側専用リソース上限値ＳＳＲの算出は、例えば、以下のように行われる。

まず、専用リソース制御部１１は、通信装置３０ｉについて、ステップＳ１０５の一定時間における、非被災地発信端末数ｎｔ_ｉ、被災地発信端末数ｔ_ｉ、非被災地着信端末数ＮＴ_ｉ、及び被災地着信端末数Ｔ_ｉの平均値を算出する。

当該一定時間を、「ｔｉｍｅ（秒）」とすると、非被災地発信端末数ｎｔ_ｉの平均値は、ｎｔ_ｉ／ｔｉｍｅによって算出される。被災地発信端末数ｔ_ｉの平均値は、ｔ_ｉ／ｔｉｍｅによって算出される。非被災地着信端末数ＮＴ_ｉの平均値は、ＮＴ_ｉ／ｔｉｍｅによって算出される。被災地着信端末数Ｔ_ｉの平均値は、Ｔ_ｉ／ｔｉｍｅによって算出される。

続いて、専用リソース制御部１１は、非被災地発信端末数ｎｔ_ｉの平均値と発側汎用リソース上限値ＳＧＲとの差分（以下、「発側汎用差分」という。）、被災地発信端末数ｔ_ｉの平均値と発側専用リソース上限値ＳＳＲとの差分（以下、「発側専用差分」という。）、非被災地着信端末数ＮＴ_ｉの平均値と着側汎用リソース上限値ＲＧＲとの差分（以下、「着側汎用差分」という。）、被災地着信端末数Ｔ_ｉの平均値と着側専用リソース上限値ＲＳＲとの差分（以下、「着側専用差分」という。）のそれぞれを算出する。

発側汎用差分が１未満であり、かつ、発側専用差分が１以上の場合、専用リソース制御部１１は、発側専用リソース上限値ＳＳＲを１減少させる。発側汎用差分が１以上であり、かつ、発側専用差分が１未満の場合、専用リソース制御部１１は、発側専用リソース上限値ＳＳＲを１増加させる。同様に、着側汎用差分が１未満であり、かつ、着側専用差分が１以上の場合、専用リソース制御部１１は、着側専用リソース上限値ＲＳＲを１減少させる。着側汎用差分が１以上であり、かつ、着側専用差分が１未満の場合、専用リソース制御部１１は、着側専用リソース上限値ＲＳＲを１増加させる。

すなわち、相対的に余裕の大きい通信リソースの上限値は減少され、相対的に余裕の小さい通信リソースの上限値は増加される。

なお、各上限値の更新には、通信装置３０ｉの発側汎用リソースの平均利用量、発側専用リソースの平均利用量、着側汎用リソースの平均利用量、及び着側専用リソースの平均利用量が用いられてもよい。この場合、通信要求情報には、非被災地発信端末数ｎｔ_ｉ、被災地発信端末数ｔ_ｉ、非被災地着信端末数ＮＴ_ｉ、及び被災地着信端末数Ｔ_ｉの代わりに、発側汎用リソースの利用回数、発側専用リソースの利用回数、着側汎用リソースの利用回数、及び着側専用リソースの利用回数が含まれてもよい。通信装置３０ｉの発側汎用リソースの利用回数は、端末５０からの発呼に応じて通信装置３０ｉの発側汎用リソースが割り当てられるたびに１加算される。通信装置３０ｉの発側専用リソースの利用回数は、リソース管理装置１０からの発呼に応じて通信装置３０ｉの発側専用リソースが割り当てられるたびに１加算される。通信装置３０ｉの着側汎用リソースの利用回数は、端末５０からの発呼に応じて通信装置３０ｉの着側汎用リソースが割り当てられるたびに１加算される。通信装置３０ｉの着側専用リソースの利用回数は、リソース管理装置１０からの発呼に応じて通信装置３０ｉの着側専用リソースが割り当てられるたびに１加算される。各利用回数の平均利用量は、各利用回数をｔｉｍｅで除することにより求められる。

ステップＳ１０６に続いて、専用リソース制御部１１は、通信装置３０ｉごとに算出された発側専用リソース上限値ＳＳＲ及び着側専用リソース上限値ＲＳＲを、各通信装置３０ｉに送信する（Ｓ１０７）。通信装置３０ｉのリソース設定部３２は、受信された値によって、リソース情報記憶部３０１に記憶されているリソース情報を更新する（Ｓ１０８）。リソース情報の更新方法は、ステップＳ１０４と同様でよい。

続いて、専用リソース制御部１１は、通信装置３０ｉに関して通信要求情報記憶部１１１に記憶されている通信要求情報の各パラメータの値を０に初期化する。

ステップＳ１０６〜Ｓ１０９は、被災地エリアに属する各通信装置３０に関して実行される。続いて、ステップＳ１０５以降が繰り返される（Ｓ１１０）。

このように、各通信装置３０の発側専用リソース上限値ＳＳＲ及び着側専用リソース上限値ＲＳＲは、各通信装置３０における発呼又は着呼の成功状況に応じて、一定時間ごとに更新される。

続いて、発側エリアＡｓの端末５０ｓが発呼した際に実行される処理手順について説明する。図８は、端末からの発呼に応じて実行される処理手順の一例を説明するためのシーケンス図である。

発側エリアＡｓにおけるいずれかの端末５０ｓが発呼すると（Ｓ２０１）、当該発呼は、基地局４０ｓ及び通信装置３０ｓを経由してセッション管理装置２０に通知される（Ｓ２０２）。

セッション管理装置２０は、当該発呼の発側の通信装置３０ｓに対して、通信リソースの割り当て可否の問い合わせを送信する（Ｓ２０３）。当該問い合わせには、割り当て対象が発側の通信リソースであること、及び端末５０の発呼による通信リソースの割り当てであることを示す情報が含まれる。

通信装置３０ｓのリソース割当制御部３３は、当該問い合わせを受信すると、当該問い合わせが発側の通信リソースに関する問い合わせであり、かつ、端末５０の発呼による通信リソースの割り当てであることに応じ、リソース情報記憶部３０１を参照して、発側汎用リソース上限値ＳＧＲ−発側汎用リソース使用値Ｓｇｒ≧１であるか否かを判定する（Ｓ２０４）。すなわち、発側汎用リソースに空きがあるか否かが判定される。続いて、リソース割当制御部３３は、割り当ての可否を示す判定結果をセッション管理装置２０に返信する（Ｓ２０５）。

セッション管理装置２０は、また、当該呼の着側の通信装置３０ｒに対して、通信リソースの割り当て可否の問い合わせを送信する（Ｓ２０６）。当該問い合わせには、割り当て対象が着側の通信リソースであること、及び端末５０の発呼による通信リソースの割り当てであることを示す情報が含まれる。

通信装置３０ｒのリソース割当制御部３３は、当該問い合わせを受信すると、当該問い合わせが着側の通信リソースに関する問い合わせであり、かつ、端末５０の発呼による通信リソースの割り当てであることに応じ、リソース情報記憶部３０１を参照して、着側汎用リソース上限値ＲＧＲ−着側汎用リソース使用値Ｒｇｒ≧１であるか否かを判定する（Ｓ２０７）。すなわち、着側汎用リソースに空きがあるか否かが判定される。続いて、リソース割当制御部３３は、割り当ての可否を示す判定結果をセッション管理装置２０に返信する（Ｓ２０８）。

なお、ステップＳ２０３〜Ｓ２０５と、ステップＳ２０６〜Ｓ２０８とは並列的に実行されてもよいし、直列的に実行されてもよい。直列的に実行される場合、先に実行された問い合わせに関する判定結果が、割り当て不可（通信リソースの不足）を示す場合、他方の問い合わせは実行されなくてもよい。

双方の判定結果が、割り当ての可能を示す場合、セッション管理装置２０は、当該発呼に関する接続要求を、通信装置３０ｓ及び通信装置３０ｒのそれぞれに送信する（Ｓ２０９、Ｓ２１１）。通信装置３０ｓのリソース割当制御部３３は、発側汎用リソースを当該発呼に対して１つ割り当てる（Ｓ２１０）。したがって、発側汎用リソース使用値Ｓｇｒに１が加算される。また、通信装置３０ｒのリソース割当制御部３３は、着側汎用リソースを当該発呼に対して１つ割り当てる（Ｓ２１２）。したがって、着側汎用リソース使用値Ｒｇｒに１が加算される。

続いて、セッション管理装置２０は、リソース管理装置１０の端末情報制御部１２に、通信接続の成否を示す情報と、発呼情報とを送信する（Ｓ２１３）。発呼情報には、発側の端末５０ｓ及び通信装置３０ｓのそれぞれの識別子、並びに着側の端末５０ｒ及び通信装置３０ｒのそれぞれの識別子と、発呼の成否を示す情報とが含まれる。

通信接続の失敗（すなわち、呼損）を示す情報が受信され、かつ、受信された発呼情報に含まれている、発側の通信装置３０ｓの識別子及び着側の通信装置３０ｒの識別子の双方が被災地リスト記憶部１１３に記憶されている場合（すなわち、被災地エリア間の発呼の場合）、端末情報制御部１２は、当該発呼情報を呼損リスト記憶部１１２に記憶されている呼損リストのうち、着側の通信装置３０ｒに対応する呼損リストに登録する（Ｓ２１４）。すなわち、呼損リストは、呼損となった発呼の着側の通信装置３０ｒごとに記憶される。また、各呼損リストには、発側及び着側の双方が、被災地エリアである発呼における呼損に関する発呼情報が含まる。

図９は、一つの通信装置に対する呼損リストの構成例を示す図である。図９には、３つのエントリを含む呼損リストが示されている。呼損リストの一つのエントリは、一つの発呼情報に基づいて生成される。当該エントリは、発側端末識別子、発側通信装置識別子、着側端末識別子、及び確認フラグ等を含む。発側端末識別子は、発側の端末５０ｓの識別子（例えば、電話番号）である。発側通信装置識別子は、発側の通信装置３０ｓの識別子である。着側端末識別子は、着側の端末５０ｒの識別子（例えば、電話番号）である。確認フラグは、一つの呼損リスト内における各エントリを、公平に処理するために利用されるフラグである。なお、呼損リストは、着側の通信装置３０の識別子（着側通信装置識別子）ごとにまとめられる。したがって、図９に示されるように、呼損リストの各エントリには、着側の通信装置３０の識別子は含まれなくてもよい。

続いて、端末情報制御部１２は、通信装置３０ｓを介して、発側の端末５０ｓに対して、呼損となったことを通知すると共に、当該端末５０ｓに関して発呼規制を実施する（Ｓ２１５、Ｓ２１６）。発呼規制の実施は、例えば、発呼を規制することを示す情報を、端末５０ｓに送信することにより行われてもよい。端末５０ｓは、当該情報を解釈し、ユーザによって発呼の指示が入力されても、発呼の実行を拒否する。

一方、通信接続の成功を示す情報が受信され、かつ、受信された発呼情報に含まれている、発側の通信装置３０ｓの識別子及び着側の通信装置３０ｒの識別子の少なくともいずれか一方が、被災地リスト記憶部１１３に記憶されている場合、端末情報制御部１２は、発側の通信装置３０ｓ及び着側の通信装置３０ｒのそれぞれに関する通信要求情報を更新する（Ｓ２１７）。

具体的には、通信装置３０ｓを通信装置３０ｉ、通信装置３０ｒを通信装置３０ｊとすると、通信装置３０ｉが被災地エリアに属する場合、ｔ_ｉに１が加算される。一方、通信装置３０ｉが非被災地エリアに属する場合、ｎｔ_ｉに１が加算される。また、通信装置３０ｊが被災地エリアに属する場合、Ｔ_ｊに１が加算される。一方、通信装置３０ｊが非被災地エリアに属する場合、ＮＴ_ｊに１が加算される。

続いて、呼損リストに基づいて、リソース管理装置１０から発呼が行われる場合に実行される処理手順について説明する。図１０は、呼損リストに基づく発呼に応じて実行される処理手順の一例を説明するためのシーケンス図である。

着側専用リソース上限値ＲＳＲの値が１以上である各通信装置３０のリソース情報送信部３１は、当該通信装置３０の着側専用リソース使用値Ｒｓｒを監視しており、着側専用リソース使用値Ｒｓｒが減少した場合（着側専用リソースに空きが発生した場合）、着側専用リソースの空きリソース量（ＲＳＲ−Ｒｇｒ）を、リソース管理装置１０の呼損端末接続部１３に送信する。図５では、通信装置３０ｒによって、当該空きリソース量が送信された例が示されている（Ｓ３０１）。

呼損端末接続部１３は、当該空きリソース量を受信すると、当該空きリソース量の送信元の通信装置３０ｒに関して呼損リスト記憶部１１２に記憶されている呼損リストから、確認フラグの値が０であるエントリに含まれる発呼情報を取得する（Ｓ３０２）。該当する発呼情報が１以上取得された場合、呼損端末接続部１３は、当該発呼情報のエントリの確認フラグの値を１に更新する。なお、全てのエントリの確認フラグの値が１であった場合、全てのエントリの確認フラグの値を０に更新した後、ステップＳ３０２が実行される。また、ステップＳ３０２において、該当する発呼情報が複数取得された場合、複数の発呼情報のうちの一つが選択されて、ステップＳ３０３以降が実行される。以下、選択された発呼情報を「対象発呼情報」という。

続いて、呼損端末接続部１３は、対象発呼情報に含まれる発側通信装置識別子に係る通信装置３０ｓに、発側専用リソースの空き状況を問い合わせる（Ｓ３０３）。当該通信装置３０ｓのリソース情報送信部３１は、当該問い合わせに応じ、発側専用リソース上限値ＳＳＲ−発側専用リソース使用値Ｓｓｒ（すなわち、発側専用リソースの空きリソース量）を算出する（Ｓ３０４）。続いて、リソース情報送信部３１は、算出結果を呼損端末接続部１３に返信する（Ｓ３０５）。

呼損端末接続部１３は、受信されたリソース空き量が１以上の値を示す場合（すなわち、発側専用リソースに空きが有る場合）、セッション管理装置２０に対して発呼を実施する（Ｓ３０６）。当該発呼において、対象発呼情報に含まれる発側端末識別子に係る端末５０が発側の端末５０ｓであり、着側端末識別子に係る端末５０が着側の端末５０ｒである。

セッション管理装置２０は、呼損端末接続部１３からの発呼に応じて、当該呼の発側の通信装置３０ｓに対して、通信リソースの割り当て可否の問い合わせを送信する（Ｓ３０７）。当該問い合わせには、割り当て対象が発側のリソースであること、及びリソース管理装置１０からの発呼による通信リソースの割り当てであることを示す情報が含まれる。

通信装置３０ｓのリソース割当制御部３３は、当該問い合わせを受信すると、当該問い合わせが発側の通信リソースに関する問い合わせであり、かつ、リソース管理装置１０の発呼による通信リソースの割り当てであることに応じ、リソース情報記憶部３０１を参照して、発側専用リソース上限値ＳＳＲ−発側専用リソース使用値Ｓｓｒ≧１であるか否かを判定する（Ｓ３０８）。すなわち、発側専用リソースに空きがあるか否かが判定される。続いて、リソース割当制御部３３は、割り当ての可否を示す判定結果をセッション管理装置２０に返信する（Ｓ３０９）。

セッション管理装置２０は、また、当該発呼の着側の通信装置３０ｒに対して、通信リソースの割り当て可否の問い合わせを送信する（Ｓ３１０）。当該問い合わせには、割り当て対象が着側の通信リソースであること、及びリソース管理装置１０の発呼による通信リソースの割り当てであることを示す情報が含まれる。

通信装置３０ｒのリソース割当制御部３３は、当該問い合わせを受信すると、当該問い合わせが着側の通信リソースに関する問い合わせであり、かつ、リソース管理装置１０の発呼による通信リソースの割り当てであることに応じ、リソース情報記憶部３０１を参照して、着側専用リソース上限値ＲＳＲ−着側専用リソース使用値Ｒｓｒ≧１であるか否かを判定する（Ｓ３１１）。すなわち、着側専用リソースに空きがあるか否かが判定される。続いて、リソース割当制御部３３は、割り当ての可否を示す判定結果をセッション管理装置２０に返信する（Ｓ３１２）。

なお、ステップＳ３０７〜Ｓ３０９と、ステップＳ３１０〜Ｓ３１２とは並列的に実行されてもよいし、直列的に実行されてもよい。直列的に実行される場合、先に実行された問い合わせに関する判定結果が、割り当て不可（通信リソースの不足）を示す場合、他方の問い合わせは実行されなくてもよい。

双方の判定結果が、割り当ての可能を示す場合、セッション管理装置２０は、当該発呼に関する接続要求を、通信装置３０ｓ及び通信装置３０ｒのそれぞれに送信する（Ｓ３１３、Ｓ３１５）。通信装置３０ｓのリソース割当制御部３３は、発側専用リソースを当該発呼に対して１つ割り当てる（Ｓ３１４）。したがって、発側専用リソース使用値Ｓｓｒに１が加算される。また、通信装置３０ｒのリソース割当制御部３３は、着側専用リソースを当該発呼に対して１つ割り当てる（Ｓ３１６）。したがって、着側専用リソース使用値Ｒｇｒに１が加算される。なお、通信装置３０ｓは、発側の端末５０ｓを呼び出し、通信装置３０ｒは、着側の端末５０ｒを呼び出してもよい。そうすることにより、端末５０ｓのユーザ及び端末５０ｒのユーザのそれぞれは、通信が接続されたことを認識することができる。

続いて、セッション管理装置２０は、リソース管理装置１０の呼損端末接続部１３に、通信接続の成否を示す情報と、対象発呼情報とを送信する（Ｓ３１７）。対象発呼情報には、発側の端末５０ｓ及び通信装置３０ｓのそれぞれの識別子、並びに着側の端末５０ｒ及び通信装置３０ｒのそれぞれの識別子と、発呼の成否を示す情報とが含まれる。

呼損端末接続部１３は、発呼の成功を示す情報が受信された場合、受信された対象発呼情報の削除を端末情報制御部１２に指示する（Ｓ３１８）。端末情報制御部１２は、対象発呼情報を含むエントリを、当該エントリが属する呼損リストから削除する（Ｓ３１９）。続いて、端末情報制御部１２は、対象発呼情報の発側通信装置識別子に係る通信装置３０ｓを介して、対象発呼情報の発側端末識別子に係る端末５０ｓの発呼規制を解除する（Ｓ３２０、Ｓ３２１）。

なお、ステップＳ３０６以降は、ステップＳ３０１において受信された着側専用リソース量の空きリソース量とステップＳ３０５で受信された発側専用リソースの空きリソース量との許容範囲内において、ステップＳ３０２において取得された各発呼情報に関して順番に繰り返し実行される。

続いて、各シーケンス図において説明した処理手順に関して、専用リソース制御部１１、端末情報制御部１２、及び呼損端末接続部１３のそれぞれが実行する処理手順について、フローチャートを用いて説明する。

図１１は、専用リソース制御部が実行する処理手順の一例を説明するためのフローチャートである。図１１中、括弧内のステップ番号は、図５において対応するステップのステップ番号である。

ステップＳ５０１において、専用リソース制御部１１は、その識別子が被災地リスト記憶部１１３に記憶されている各通信装置３０からリソース情報を取得し、当該リソース情報に基づいて算出される、発側専用リソース上限値ＳＳＲ及び着側専用リソース上限値ＲＳＲのそれぞれの初期値を、当該各通信装置３０に通知する。

その後、専用リソース制御部１１は、一定時間間隔で（Ｓ５０２）、ステップＳ５０３〜Ｓ５０５を繰り返し実行する。

ステップＳ５０３において、専用リソース制御部１１は、被災地エリアに属する各通信装置３０に関して通信要求情報記憶部１１１に記憶されている通信要求情報を取得し、各通信要求情報に基づいて、当該通信要求情報に対応する通信装置３０の発側専用リソース上限値ＳＳＲ及び着側専用リソース上限値ＲＳＲを算出する。算出方法は、ステップＳ１０６において説明した通りである。

続いて、専用リソース制御部１１は、算出された着側専用リソース上限値ＲＳＲが０より大きい通信装置３０の有無を判定する（Ｓ５０４）。該当する通信装置３０が有る場合（Ｓ５０４でＹＥＳ）、専用リソース制御部１１は、通信装置３０ごとに算出された発側専用リソース上限値ＳＳＲ及び着側専用リソース上限値ＲＳＲを、各通信装置３０に送信する（Ｓ５０５）。続いて、専用リソース制御部１１は、各通信要求情報の各パラメータを０に初期化する（Ｓ５０６）。なお、ステップＳ５０４でＹＥＳのケースは、図５において説明済みである。

一方、各通信装置３０に関して算出された着側専用リソース上限値ＲＳＲの全てが０である場合（Ｓ５０４でＮＯ）、専用リソース制御部１１は、被災地エリアに属する各通信装置３０に対して、発側専用リソース上限値ＳＳＲ及び着側専用リソース上限値ＲＳＲのそれぞれを０にすることの指示を送信する（Ｓ５０７）。その結果、当該各通信装置３０において、発側及び着側のそれぞれの通信リソースの分割は解除される。

続いて、専用リソース制御部１１は、端末情報制御部１２に対し、呼損リストの解放を指示し（Ｓ５０８）、図１１の処理を終了する。端末情報制御部１２は、当該指示に応じ、各呼損リストの各エントリに含まれている各発呼情報の発側端末識別子に係る端末５０の発呼規制を解除し、全ての呼損リストを削除する。

すなわち、全ての被災地エリアの全ての通信装置３０の着側専用リソース上限値ＲＳＲが０になったということは、一定時間において呼損が解消されたことを意味する。したがって、専用リソースを解放し、通常の通信状態に戻すための処理が実行される。

続いて、端末情報制御部１２が実行する処理手順について説明する。図１２は、端末情報制御部がセッション管理装置から発呼情報を受信した際に実行する処理手順の一例を説明するためのフローチャートである。図１２中、括弧内のステップ番号は、図８において対応するステップのステップ番号である。

端末情報制御部１２は、セッション管理装置２０から発呼の成否を示す情報及び発呼情報を受信すると、当該発呼の成否を示す情報が失敗（呼損）を示すものであるか否かを判定する（Ｓ６０１）。呼損である場合（Ｓ６０１でＹＥＳ）、端末情報制御部１２は、当該発呼情報に含まれている発側通信装置識別子及び着側通信装置識別子の双方が、被災地リスト記憶部１１３に記憶されているか否かを判定する（Ｓ６０２）。少なくともいずれか一方の識別子が、被災地リスト記憶部１１３に記憶されていない場合（Ｓ６０２でＮＯ）、図１２の処理は終了する。

双方の識別子が被災地リスト記憶部１１３に記憶されている場合（Ｓ６０２でＹＥＳ）、端末情報制御部１２は、当該発呼情報に含まれている着側通信装置識別子に係る呼損リストに、当該発呼情報を含むエントリを追加する（Ｓ６０３）。続いて、端末情報制御部１２は、当該発信情報の発側版末識別子に係る端末５０に呼損を通知し、当該端末５０に関して発呼規制を実施して（Ｓ６０４）、図１２の処理を終了する。

一方、呼損でない場合（Ｓ６０１でＮＯ）、端末情報制御部１２は、発側及び着側の少なくともいずれか一方の通信装置３０が被災地エリアに属するか否かを判定する（Ｓ６０５）。発側及び着側の少なくともいずれか一方の通信装置３０が被災地エリアに属する場合（Ｓ６０５でＹＥＳ）、端末情報制御部１２は、発側の通信装置３０と着側の通信装置３０とのそれぞれに関する通信要求情報（図７）を更新する（Ｓ６０６）。

図１３は、端末情報制御部が呼損端末接続部から成功した発呼に関する発呼情報を受信した際に実行する処理手順の一例を説明するためのフローチャートである。図１３中、括弧内のステップ番号は、図１０において対応するステップのステップ番号である。

端末情報制御部１２は、発呼の成功を示す情報と当該発呼に関する発呼情報とを呼損端末接続部１３から受信すると、当該発呼情報を含むエントリを、当該発呼情報が属する呼損リストから削除する（Ｓ７０１）。続いて、端末情報制御部１２は、当該発呼情報の発側端末識別子に係る端末５０の発呼規制を解除する（Ｓ７０２）。

続いて、呼損端末接続部１３が実行する処理手順について説明する。図１４は、呼損端末接続部が実行する処理手順の一例を説明するためのフローチャートである。図１４中、括弧内のステップ番号は、図１０において対応するステップのステップ番号である。

呼損端末接続部１３は、被災地エリア内のいずれかの通信装置３０から着側専用リソースの空きリソース量を受信すると、当該通信装置３０の呼損リストを呼損リスト記憶部１１２から取得する（Ｓ８０１）。続いて、呼損端末接続部１３は、当該呼損リストに１以上のエントリが有るか否かを判定する（Ｓ８０２）。エントリが無い場合（Ｓ８０２でＮＯ）、呼損端末接続部１３は、一定時間待機後（Ｓ８０３）、ステップＳ８０２を繰り返す。

エントリが有る場合（Ｓ８０３でＹＥＳ）、呼損端末接続部１３は、当該呼損リストの並び順の先頭から、確認フラグ＝０であるエントリを探索する（Ｓ８０４）。確認フラグ＝０であるエントリが無い場合（Ｓ８０４でＹＥＳ）、呼損端末接続部１３は、当該当該呼損リストの全てのエントリの確認フラグの値に０を設定し（Ｓ８０６）、ステップＳ８０４以降を繰り返す。

確認フラグ＝０であるエントリが有る場合（Ｓ８０５でＮＯ）、呼損端末接続部１３は、当該エントリの確認フラグに１を設定する（Ｓ８０７）。続いて、呼損端末接続部１３は、当該エントリに含まれている発呼情報の発側通信装置識別子に係る通信装置３０に、発側専用リソースの空き状況を問い合わせる（Ｓ８０８）。

当該発側専用リソースに１以上の空きが無い場合（Ｓ８０９でＮＯ）、呼損端末接続部１３は、ステップＳ８０４以降を繰り返す。当該発側専用リソースに１以上の空きが有る場合（Ｓ８０９でＹＥＳ）、呼損端末接続部１３は、当該発呼情報に係る発側の端末５０と着側の端末５０との通信接続を実施する（Ｓ８１０）。通信接続が失敗した場合（Ｓ８１１でＮＯ）、呼損端末接続部１３は、ステップＳ８０４以降を繰り返す。通信接続が成功した場合（Ｓ８１１でＹＥＳ）、呼損端末接続部１３は、端末情報制御部１２に発呼情報を通知し、当該発呼情報を含むエントリについて、呼損リストからの削除を指示する（Ｓ８１２）。

続いて、呼損端末接続部１３は、ステップＳ８０１において取得された呼損リストに係る通信装置３０に着側専用リソースの空きが有るか否かを判定する（Ｓ８１３）。当該判定は、当該通信装置３０に対して問い合わせを行うことにより実行されてもよい。当該着側専用リソースに空きが有る場合（Ｓ８１３でＮＯ）、呼損端末接続部１３は、ステップＳ８０４以降を繰り返す。当該着側専用リソースに空きが無い場合（Ｓ８１３でＮＯ）、図１４の処理は終了する。

上述したように、本実施の形態によれば、災害発生時に、被災地間の通信に備えて専用の通信リソースが発側及び着側それぞれの通信装置３０に用意されるため、被災地間以外の通信によって、通信リソースが使い切られてしまうことを防ぐことができる。また、呼損となった被災地間の通信が管理され、発側専用リソース及び着側専用リソースの空きが確認され次第、呼損となった通信が移動体通信網側の主導により順次接続されるため、専用リソースの空き時間を削減し、通信リソースの利用効率を維持することができる。

これにより、被災地間通信において、発側及び着側の双方の通信リソースを同時に確保し、確保した通信リソースの空き時間を長引かせない運用が可能となる。その結果、発側又は着側の一方の通信リソースの不足による呼損が回避され、不要な再呼を減らすことが可能となる。

したがって、被災地における発側及び着側の通信リソースが必要となる被災地間通信を迅速に処理することが可能となり、再呼する端末５０の減少及び通信リソースの利用率低下が促進され、輻輳の早期解消を期待することができる。なお、被災地間通信とは、同じ被災地エリア内の通信であってもよいし、異なる被災地エリア間の通信であってもよい。

続いて、本実施の形態による、輻輳を早期に解消させる効果に関する評価結果について以下に記す。本実施の形態の評価においては、図１５に示されるような発呼要求が有るものとする。

図１５は、本実施の形態の評価のためのシミュレーションの条件を説明するための図である。図１５に示されるように、被災地エリアＡ１内に５００台の端末５０（以下、「被災地端末５０」という。）、非被災地エリアＡ２内に５００台の端末５０（以下、「非被災地端末５０」という。）が存在し、発呼要求Ｃ１〜Ｃ３が有るものとする。発呼要求Ｃ１は、５００台の非被災地端末５０から被災地端末５０への発呼要求である。発呼要求Ｃ２は、２５０台の被災地端末５０から非被災地端末５０への発呼要求である。発呼要求Ｃ３は、２５０台の被災地端末５０から被災地端末５０への発呼要求である。各端末５０の通信相手は、３人居るものとし、一様乱数にて設定される。

シミュレーション開始と同時に、各端末５０は、図１６に示されるような状態遷移を実施する。図１６は、本実施の形態の評価のためのシミュレーションにおいて端末が実施する状態遷移を示す図である。

まず、端末５０は、それぞれに設定されている通信相手の中から１台を発信先として選択した後、発呼状態に遷移する。発呼状態において、通信リソースが空いており、相手の端末５０が話中でない場合、通信状態に遷移する。一定時間通信後、全ての通信相手と通信が成功した場合、行動終了となる。発呼状態において、通信リソースが不足している、又は当該端末５０が、％規制グループに属していた場合、待機状態に遷移して一定時間経過した後、発信相手を変更して発呼状態に戻る。待機時間は、平均１０分の正規分布に従い、通信時間は平均３分の正規分布に従うものとする（標準偏差は１）。また、発側及び着側のそれぞれについて、最大１０台の端末５０まで同時に通信可能であるとする。

上記の条件によるシミュレーションを、％規制による発呼規制が動作している状況で、本実施の形態を適用して実行した場合（以下、「ケースＡ」という。）、及び本実施の形態を適用しないで実行した場合（以下、「ケースＢ」という。）のそれぞれについて、行動中の端末数の時間経過について比較する。

％規制における規制の内容は、被災地エリアＡ１内の全端末５０を１０グループに分割し、そのうちの９グループに属する端末５０の発呼を一定時間禁止するというものである。なお、発呼が禁止される規制グループは、１０分毎にスライドするものとする。例えば、グループ１〜９までが規制グループの状態で１０分経過すると、グループ２〜１０までが規制グループとなる。

図１７は、ケースＡ及びケースＢのそれぞれにおける行動中の端末数の推移を示す図である。図１７において、太い実線はケースＡについて行動中の全端末数、太い破線はケースＢについて行動中の全端末数、細い実線はケースＡについて被災地エリアＡ１で行動中の端末数、細い破線はケースＢについて被災地エリアＡ１で行動中の端末数である。

図１７より、ケースＡは、ケースＢに対して、全端末５０が行動終了となるまでに要される時間が短縮されることが確認できる。また、被災地端末５０が行動終了となるまでに要される時間についてもケースＡの方が短いが、これは、本実施の形態によって、被災地間通信用の専用のリソースが用意されることで、被災地エリアＡ１内での発呼が成功し易くなったためであると考えられる。本実施の形態が適用されない場合、被災地端末５０に向けた発呼は、非被災地端末５０（５００台）の方が、被災地端末５０（２５０台）より多く、シミュレーション終了まで、発呼が成功しづらい状況になっている。

本実施の形態の適用により、全端末５０が行動終了になるまでの所要時間が短縮されるのは、被災地エリアＡ１内の発信用の通信リソースと着信用の通信リソースが空き次第、（呼損リストに基づいて）発側の端末５０と着側との端末５０とを即時的に接続することで、リソースが空く時間を削減出来ているためであると考えられる。

上記より、本実施の形態によれば、輻輳を早期に解消させる効果が得られることが確認できた。

なお、本実施の形態では、被災地エリアの通信装置３０が、被災地リスト記憶部１１３に登録される例を示したが、被災地エリア以外の通信装置３０であって、被災地に類似した輻輳が発生する通話エリアの通信装置３０が、被災地リスト記憶部１１３に登録されてもよい。例えば、年末年始等や何らかの行事等によって人（端末５０）が集中する通話エリア等が、被災地リスト記憶部１１３に登録されてもよい。そうすることで、被災地間通信のみならず、他の混雑エリア間通信に関しても、輻輳を早期に解消させることができる。

なお、本実施の形態において、専用リソース制御部１１は、分割部の一例である。呼損リスト記憶部１１２は、第一の記憶部の一例である。端末情報制御部１２は、規制部の一例である。呼損端末接続部１３は、接続部の一例である。発側汎用リソース、発側専用リソース、着側汎用リソース、着側専用リソースは、それぞれ第一の通信リソース、第二の通信リソース、第三の通信リソース、第四の通信リソースの一例である。被災地リスト記憶部１１３は、第二の記憶部の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１ 通信システム
１０ リソース管理装置
１１ 専用リソース制御部
１２ 端末情報制御部
１３ 呼損端末接続部
２０ セッション管理装置
３０ 通信装置
３１ リソース情報送信部
３２ リソース設定部
３３ リソース割当制御部
４０ 基地局
５０ 端末
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１１１ 通信要求情報記憶部
１１２ 呼損リスト記憶部
１１３ 被災地リスト記憶部
３０１ リソース情報記憶部
Ａｓ 発側エリア
Ａｒ 着側エリア
Ｂ バス

Claims (6)

1. 移動体通信網の通話エリアごとの発信用の通信リソースを第一の通信リソースと第二の通信リソースとに分割し、前記通話エリアごとの着信用の通信リソースを第三の通信リソースと第四の通信リソースとに分割する分割部と、
   第一の端末からの発呼に応じ、当該発呼の発側の第一の通話エリアの前記第一の通信リソース及び当該発呼の着側の第二の通話エリアの前記第三の通信リソースの少なくともいずれか一方が不足している場合に、前記第一の端末の識別子及び当該発呼に係る着側の第二の端末の識別子を記憶する第一の記憶部と、
   前記第一の記憶部に前記識別子が記憶された前記第一の端末からの発呼を規制する規制部と、
   前記第二の通話エリアの前記第四の通信リソースの空きの発生に応じ、前記第一の記憶部に記憶されている前記識別子に基づいて、前記第一の端末と前記第二の端末との通信を、前記第一の通話エリアの前記第二の通信リソースと当該第四の通信リソースとを用いて接続させる接続部と、
   を有することを特徴とする通信システム。
2. 前記分割部は、前記第一の通話エリアにおける一定時間内の発呼に成功状況に基づいて、前記第一の通話エリアの前記第二の通信リソースの上限値を決定し、前記第二の通話エリアにおける前記一定時間内の着呼に成功状況に基づいて、前記第二の通話エリアの前記第四の通信リソースの上限値を決定する、
   ことを特徴とする請求項１記載の通信システム。
3. 前記移動体通信網の通話エリアのうちの一部の通話エリアに関する識別子を記憶する第二の記憶部を有し、
   前記分割部は、前記第二の記憶部に識別子が記憶されている通話エリアの発信用の通信リソース及び着信用の通信リソースを分割する、
   ことを特徴とする請求項１又は２記載の通信システム。
4. 前記一部の通話エリアは、災害の発生に応じて特定される、
   ことを特徴とする請求項３記載の通信システム。
5. 移動体通信網の通話エリアごとの発信用の通信リソースを第一の通信リソースと第二の通信リソースとに分割し、前記通話エリアごとの着信用の通信リソースを第三の通信リソースと第四の通信リソースとに分割する分割部と、
   第一の端末からの発呼に応じ、当該発呼の発側の第一の通話エリアの前記第一の通信リソース及び当該発呼の着側の第二の通話エリアの前記第三の通信リソースの少なくともいずれか一方が不足している場合に、前記第一の端末の識別子及び当該発呼に係る着側の第二の端末の識別子を記憶する第一の記憶部と、
   前記第一の記憶部に前記識別子が記憶された前記第一の端末からの発呼を規制する規制部と、
   前記第二の通話エリアの前記第四の通信リソースの空きの発生に応じ、前記第一の記憶部に記憶されている前記識別子に基づいて、前記第一の端末と前記第二の端末との通信を、前記第一の通話エリアの前記第二の通信リソースと当該第四の通信リソースとを用いて接続させる接続部と、
   を有することを特徴とするリソース管理装置。
6. コンピュータが、
   移動体通信網の通話エリアごとの発信用の通信リソースを第一の通信リソースと第二の通信リソースとに分割し、前記通話エリアごとの着信用の通信リソースを第三の通信リソースと第四の通信リソースとに分割する分割手順と、
   第一の端末からの発呼に応じ、当該発呼の発側の第一の通話エリアの前記第一の通信リソース及び当該発呼の着側の第二の通話エリアの前記第三の通信リソースの少なくともいずれか一方が不足している場合に、前記第一の端末の識別子及び当該発呼に係る着側の第二の端末の識別子を第一の記憶部に記憶する記憶手順と、
   前記第一の記憶部に前記識別子が記憶された前記第一の端末からの発呼を規制する規制手順と、
   前記第二の通話エリアの前記第四の通信リソースの空きの発生に応じ、前記第一の記憶部に記憶されている前記識別子に基づいて、前記第一の端末と前記第二の端末との通信を、前記第一の通話エリアの前記第二の通信リソースと当該第四の通信リソースとを用いて接続させる接続手順と、
   を実行することを特徴とする通信方法。

Images