(57)【要約】【課題】使用可能なセッション数が全て使用されている場合であっても、セッションのひとつを切断することで新規セッションの接続を可能にし、かつ、切断されたセッションを自動的に復旧する。【解決手段】通信元端末のＵＲＩ及び通信先相手のＵＲＩに対応して通信セッションの重要度と復旧要否の情報が予め設定され、セッション重要度テーブル１３０に記憶されている。例えば、緊急セッションなどの重要度の高いセッションの接続要求を受信すると、既存セッションのうち重要度のもっとも低いものを選択して切断する。切断された通信セッションの情報（例えば、通信元ＵＲＩ及び通信先ＵＲＩ）を、セッション復旧テーブル１４０に記憶しておく。セッションリソースに空きができ次第、セッション復旧テーブル１４０に記憶された通信元ＵＲＩ及び通信先ＵＲＩに従い、セッションを自動的に復旧させる。【選択図】図２
2009049550.tif 000002
【特許請求の範囲】
【請求項１】
端末と通信先の装置間で網を介してセッションが接続されるシステムにおいて、複数の前記端末と前記網との間に配置され、使用可能なセッション数が予め設定されたゲートウェイ装置であって、
セッションの通信元識別情報と通信先識別情報に対応して、セッションの重要度が予め記憶されたセッション重要度記憶領域と、
接続中のひとつ又は複数のセッション毎に通信元識別情報と通信先識別情報とがそれぞれ記憶されたセッション状況記憶領域と、
切断したセッションの通信元識別情報と通信先識別情報とが記憶されるセッション復旧記憶領域と、
前記セッション復旧記憶領域に記憶された通信元識別情報と通信先識別情報とが示す装置間のセッションを復旧させるセッション復旧部と、
セッションの接続及び切断を制御するセッション制御部と
を備え、
前記セッション制御部は、
接続中のセッション数が使用可能なセッション数と同じ場合に、前記端末のひとつから該端末を示す通信元識別情報と通信先識別情報を含む新規セッションの接続要求を受信すると、前記セッション状況記憶領域を参照して、すでに接続されているひとつ又は複数のセッションについて通信元識別情報と通信先識別情報とをそれぞれ特定し、特定された通信元識別情報と通信先識別情報とに基づき前記セッション重要度記憶領域を参照して、接続中のセッション毎の重要度を求め、
求められた重要度が最も低いセッション又は重要度が予め定められた基準よりも低いセッションのひとつを選択し、
選択されたセッションを切断し、
選択されたセッションの通信元識別情報と通信先識別情報とを、前記セッション復旧記憶領域に記憶し、
新規セッションの接続要求に含まれる通信元識別情報と通信先識別情報に従い、通信元の前記端末と通信先の装置との新規セッションを接続し、
前記セッション復旧部及び／又は前記セッション制御部は、
前記新規セッション又は他のセッションが切断されることにより使用可能なセッションができると、前記セッション復旧記憶領域に記憶された通信元識別情報と通信先識別情報とが示す端末又は装置間のセッションを接続することで、切断された前記セッションを復旧させる前記ゲートウェイ装置。
【請求項２】
前記セッション重要度記憶領域は、通信元識別情報及び通信先識別情報に対応して、切断されたセッションの復旧が必要か否かを示す復旧要否情報がさらに記憶され、
前記セッション制御部は、新規セッションの接続要求に含まれる新規セッションの通信元識別情報及び通信先識別情報に基づき前記セッション重要度記憶領域を参照し、対応する復旧要否情報が復旧が必要であることを示す場合に、前記選択されたセッションの通信元識別情報と通信先識別情報とを、前記セッション復旧記憶領域に記憶する請求項１に記載のゲートウェイ装置。
【請求項３】
前記セッション復旧部及び／又は前記セッション制御部は、
前記セッション復旧記憶領域に記憶された通信元識別情報と通信先識別情報を読み出し、該通信元識別情報が示す端末又は装置と、該通信先識別情報が示す端末又は装置とに、該通信元識別情報と該通信先識別情報が示す端末又は装置間を接続するための接続要求を送信することで、切断された前記セッションを復旧させる請求項１に記載のゲートウェイ装置。
【請求項４】
選択されたセッションの通信元識別情報と通信先識別情報とを前記セッション状況記憶領域から削除し、
新規セッションの接続要求に含まれる通信元識別情報と通信先識別情報を前記セッション状況記憶領域に記憶する請求項１に記載のゲートウェイ装置。
【請求項５】
接続中のセッション数と、予め定められた使用可能なセッション数とが記憶されるセッションリソース記憶領域と、
セッションを監視して、前記セッションリソース記憶領域に、接続中のセッション数を記憶するセッション監視部と
をさらに備え、
前記セッション制御部は、
新規セッションの接続要求を受信すると、前記セッションリソース記憶領域を参照し、接続中のセッション数と使用可能なセッション数とが同じ値の場合に、前記選択されたセッションを切断し、及び、新規セッションを接続する請求項１に記載のゲートウェイ装置。
【請求項６】
前記セッション監視部は、前記新規セッション又は他のセッションが開放されると、前記セッションリソーステーブルに記憶された接続中のセッション数を減少させ、
前記セッション復旧部は、前記セッションリソーステーブルの接続中のセッション数が、使用可能なセッション数よりも小さい場合に、切断した前記セッションを復旧させる請求項５に記載のゲートウェイ装置。
【請求項７】
前記新規セッションは、セキュリティに関するセッションである請求項１に記載のゲートウェイ装置。
【請求項８】
前記セッション制御部は、新規セッションの接続要求を受信すると、該接続要求に含まれる通信元識別情報と通信先識別情報に基づき、前記セッション重要度記憶領域を参照して新規セッションの重要度を求め、該重要度が最も高い又は予め定められた基準より高い場合に、前記選択された重要度の低いセッションを切断し、及び、該新規セッションを接続する請求項１に記載のゲートウェイ装置。
【請求項９】
前記セッション制御部は、セキュリティを監視する前記端末から、通信元識別情報を該端末の識別情報とし、通信先識別情報をセキュリティセンタの識別情報とする新規セッションの接続要求を受信し、
前記セッション重要度記憶領域には、該端末を示す通信元識別情報とセキュリティセンタを示す通信先識別情報とに対応して、重要度が最も高い第１の重要度が記憶されており、
該端末と該セキュリティセンタとのセッションが優先的に接続される請求項８に記載のゲートウェイ装置。
【請求項１０】
前記セッション重要度記憶領域は、
ビデオを表示する端末又はセットトップボックスを示す通信元識別情報とビデオストリーム配信を行うサーバを示す通信先識別情報とに対応して、第２の重要度が記憶され、
第２の重要度は、第１の重要度よりも低くかつ他のセッションの重要度よりも高く設定されている請求項９に記載のゲートウェイ装置。
【請求項１１】
前記セッション重要度記憶領域は、
テレビ会議を行う端末を示す通信元識別情報と予め定められた会議サーバを示す通信先識別情報に対応して、第３の重要度が記憶され、
音声通信を行う端末を示す通信元識別情報と予め定められた端末を示す通信先識別情報に対応して、第４の重要度が記憶され、
第３及び第４の重要度は、第１の重要度よりも低くかつ他のセッションの重要度よりも高く設定されている請求項９に記載のゲートウェイ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ゲートウェイ装置に係り、特に、使用可能なセッション数が全て使用されている場合に、特定の新規セッションを接続させるためのゲートウェイ装置に関する。
【背景技術】
【０００２】
ＩＳＤＮネットワークにおいて、回線リソースが尽きた（Ｂチャネル２つとも使用された）場合に、新たな重要発呼を可能にするために物理回線を切断することが特許文献１にて開示されている。例えば、特許文献１には、呼が優先呼であると判定するとリレーの接点を開き、回線終端装置から複数のＩＳＤＮ通信端末へ接続されているＩインタフェースの回線を切断することが開示されている。
【０００３】
また、優先度の高いユーザ端末からの接続要求に対して、例えば、優先度の低い他のセッションを切断することが知られている（例えば、特許文献２〜５参照）。
【特許文献１】特開平１１−２６６３２４号公報
【特許文献２】特開２００６−１４８６４８号公報
【特許文献３】特開平１０−１１１８５３号公報
【特許文献４】特開２００３−１６０３１号公報
【特許文献５】特開２００４−１８７０９４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述の特許文献１に開示された技術では、使用中の各回線の通信重要度を比較して選択することなくすべて切断しており、切断不必要な回線も停止される。このため、通信回線の効率が落ちる場合がある。また、特許文献１〜５の技術はいずれも、回線が空いても、切断された通信を特定して自動的に再開させる方法は考慮されていない。このため、ユーザが手動で再接続する手間が発生する。
【０００５】
さらに、優先度の高いユーザ端末がまだ接続している場合には、優先度の低いユーザが再接続を試みても、通信が切断された優先度の低いユーザの接続は許可されない場合があり、ユーザが何度も再接続を試みる手間が発生する。一方、ユーザが再接続を試みるタイミングは、セッションの切断・開放と無関係であるため、優先度の高い他のユーザ端末のセッションが切断・開放されてから、ユーザが再接続を試みるまでには空き時間ができる場合がある。従って、回線の利用効率が低下する。
【０００６】
以上の点に鑑み、本発明は、使用可能なセッション数が全て使用されている場合であっても、セッションのひとつを切断することで重要度の高い新規セッションの接続を可能にし、かつ、切断されたセッションを自動的に復旧できるゲートウェイ装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、例えば、あらかじめ設定された、通信元端末、通信先相手などがパラメータとして構成された通信セッションの重要度によって、既存セッションのうち重要度のもっとも低いものを選択して切断する。
【０００８】
本発明は、例えば、あらかじめ重要度とともに設定された再接続要否によって、切断された通信セッションの情報をＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）ゲートウェイの中で記憶することによって、セッションリソースに空きがあり次第自動的に再接続される。
【０００９】
本ＳＩＰゲートウェイは、例えば、ＳＩＰを用いたＩＰネットワークに接続する、通信中セッション状況をリアルタイムに監視するセッション監視部、セッションの切断・接続をするセッション制御部、切断されたセッションの復旧を担当するセッション復旧部、通信パケットのルーティングを管理する回線制御部、通信パケットの転送を担当する回線Ｉ／Ｆ部、前記通信中セッション状況の情報を格納するセッション状況テーブル、使用可能なセッションリソースおよび消費状況に関する情報を格納するセッションリソーステーブル、セッションの重要度情報を格納するセッション重要度テーブル、切断されかつ復旧が必要なセッションの情報を格納するセッション復旧テーブルを備えることを特徴のひとつとする。
【００１０】
また、上記ＳＩＰゲートウェイは、ＳＩＰを用いたＩＰネットワークに接続する加入者宅内において、加入サービス契約で規定された最大セッション数のセッションがすべて占有された場合に発生した重要度最高と設定された端末（例えば緊急通報端末）からの新しいセッション接続要求に対して、あらかじめ設定された、端末、通信相手などがパラメータとして構成された通信セッションの重要度によって、既存セッションのうち重要度のもっとも低いものを選択して切断することによって、新しいセッション接続を可能にすることを特徴のひとつとする。
【００１１】
また、上記ＳＩＰゲートウェイは、前記の切断された既存セッションを、あらかじめ重要度とともに設定された再接続要否によって、当該ＳＩＰゲートウェイのセッションリソースが空き次第、自動的に再接続することを特徴のひとつとする。
ＳＩＰゲートウェイは、前記のセッション重要度をユーザが自由に設定できることを特徴のひとつとする。
【００１２】
本発明の解決手段によると、
端末と通信先の装置間で網を介してセッションが接続されるシステムにおいて、複数の前記端末と前記網との間に配置され、使用可能なセッション数が予め設定されたゲートウェイ装置であって、
セッションの通信元識別情報と通信先識別情報に対応して、セッションの重要度が予め記憶されたセッション重要度記憶領域と、
接続中のひとつ又は複数のセッション毎に通信元識別情報と通信先識別情報とがそれぞれ記憶されたセッション状況記憶領域と、
切断したセッションの通信元識別情報と通信先識別情報とが記憶されるセッション復旧記憶領域と、
前記セッション復旧記憶領域に記憶された通信元識別情報と通信先識別情報とが示す装置間のセッションを復旧させるセッション復旧部と、
セッションの接続及び切断を制御するセッション制御部と
を備え、
前記セッション制御部は、
接続中のセッション数が使用可能なセッション数と同じ場合に、前記端末のひとつから該端末を示す通信元識別情報と通信先識別情報を含む新規セッションの接続要求を受信すると、前記セッション状況記憶領域を参照して、すでに接続されているひとつ又は複数のセッションについて通信元識別情報と通信先識別情報とをそれぞれ特定し、特定された通信元識別情報と通信先識別情報とに基づき前記セッション重要度記憶領域を参照して、接続中のセッション毎の重要度を求め、
求められた重要度が最も低いセッション又は重要度が予め定められた基準よりも低いセッションのひとつを選択し、
選択されたセッションを切断し、
選択されたセッションの通信元識別情報と通信先識別情報とを、前記セッション復旧記憶領域に記憶し、
新規セッションの接続要求に含まれる通信元識別情報と通信先識別情報に従い、通信元の前記端末と通信先の装置との新規セッションを接続し、
前記セッション復旧部及び／又は前記セッション制御部は、
前記新規セッション又は他のセッションが切断されることにより使用可能なセッションができると、前記セッション復旧記憶領域に記憶された通信元識別情報と通信先識別情報とが示す端末又は装置間のセッションを接続することで、切断された前記セッションを復旧させる前記ゲートウェイ装置が提供される。
【発明の効果】
【００１３】
本発明によると、使用可能なセッション数が全て使用されている場合であっても、セッションのひとつを切断することで重要度の高い新規セッションの接続を可能にし、かつ、切断されたセッションを自動的に復旧できるゲートウェイ装置を提供することができる。
【発明を実施するための最良の形態】
【００１４】
（ハードウェア構成）
図１は、ＳＩＰゲートウェイを含むネットワーク構成概念図である。
本ネットワークシステムは、例えば、複数の端末ＵＡ２０（例えば、端末ＵＡ−Ａ２１〜Ｎ２４）と、ＳＩＰゲートウェイ装置（以下、ＳＩＰ  ＧＷ）１０と、ひとつ又は複数の通信先装置ＵＡ３０（例えば、通信先ＵＡ−ａ３１〜ｍ３４）とを備える。なお、本実施の形態では、ＳＩＰを例に説明するが、他のプロトコルでもよい。また、端末ＵＡ２０、通信先装置ＵＡ３０は、それぞれ物理的な端末・装置でなくてもよく、それぞれが論理的なアプリケーションであってもよい。
【００１５】
ＳＩＰ  ＧＷ１０が例えば加入者（ユーザ）宅内に設置され、宅内端末ＵＡ２０と公衆ＳＩＰ網４０との間に位置する。例えば、ホームネットワークと公衆網４０の境界に位置することができる。端末ＵＡ２０と通信先ＵＡ３０間で、ＩＰネットワーク４０、ＳＩＰ  ＧＷ１０を介してセッションが接続される。このようなネットワーク構成において、該加入者の加入サービス契約により、宅内から使用可能な最大セッション数（この例では２セッションと仮定する）が予め規定されている。
【００１６】
通信先装置ＵＡ３０は、例えば、ビデオストリームを配信するサーバ、テレビ会議サーバ、音声通信などを行う端末、セキュリティを監視するサーバ（セキュリティセンタ）などである。
端末ＵＡ２０は、例えば、ＰＣ、電話機、セットトップボックス、セキュリティ監視のためのセンサ・コントローラなどである。なお、これに限らず、適宜の端末、装置であってもよい。
【００１７】
セットトップボックスは、例えば、ビデオストリームを配信する通信先ＵＡ３０から、ビデオストリームを受信する。電話機は、通信先ＵＡ３０と音声通信を行う。ＰＣは、例えば、テレビ会議をするための通信先ＵＡ３０に接続し、テレビ会議を行う。例えば、会社にあるテレビ会議サーバと通信する。なお、ＰＣは上述のセットトップボックスや電話と同じ機能を有することもできる。
【００１８】
セキュリティ監視のためのセンサは、例えば、ドア又はドア付近に取り付けられ、不審者の侵入等を検知する。また、防犯のためのセンサ、火災やガス漏れ、漏電を検知するセンサなどであってもよい。また、介護、医療等の緊急通報をするためのスイッチ等であってもよい。セキュリティ監視のためのセンサを制御するコントローラ（例えば、端末ＵＡ−Ｃ２３）は、不審者の侵入など異常を検知すると、セキュリティ監視サーバ（例えば、通信先ＵＡ−ｃ３３）に異常を示す情報を通知する。本実施の形態では、例えば、セキュリティに関する緊急セッションは、他のセッションがすでに接続されていても、優先的に接続される。例えば、加入者が宅内にいて電話やＰＣなどにより使用可能な最大セッション数をすべて使用していても、セキュリティに関するセッションは接続され、異常を示す情報をセキュリティを監視するサーバ（例えば、セキュリティセンタ）などに通知することができる。
【００１９】
各端末ＵＡ２０、各通信先ＵＡ３０は、予めＵＲＩ（識別情報）が割り当てられている。なお、ＵＲＩは、物理的な端末、装置に限らず、アプリケーションに対して割り当てられていてもよい。
【００２０】
図２は、ＳＩＰ  ＧＷ１０の内部構成概念図である。
ＳＩＰ  ＧＷ１０は、例えば、ＣＰＵ１１と、回線制御部１２と、回線インタフェース部（回線Ｉ／Ｆ部）１３と、セッション制御部１４と、セッション監視部１５と、セッション復旧部１６と、メモリ１００とを有する。メモリ１００は、例えば、セッション状況テーブル（セッション状況記憶領域）１１０と、セッションリソーステーブル（セッションリソース記憶領域）１２０と、セッション重要度テーブル（セッション重要度記憶領域）１３０と、セッション復旧テーブル（セッション復旧記憶領域）１４０とを含む。なお、各部はバス等で接続されている。
【００２１】
回線制御部１２は、通信パケットのルーティングを管理する。回線Ｉ／Ｆ部１３は、通信パケットの転送を担当するインタフェースである。セッション制御部１４は、セッションの切断・接続を制御する。セッション監視部１５は、通信中セッション状況をリアルタイムに監視する。例えば、セッション監視部１５は、セッションを監視して、セッションリソース管理テーブルに、通信中のセッション数を記憶する。セッション復旧部１６は、切断されたセッションの復旧を担当する。例えば、セッション復旧部１６は、セッションに空きがある場合に、セッション復旧テーブル１４０に記憶された端末ＵＡ  ＵＲＩ（通信元ＵＲＩ、通信元識別情報）と通信先ＵＡ  ＵＲＩ（通信先識別情報）とが示す装置間のセッションを、セッション制御部１４により復旧させる。
【００２２】
セッション状況テーブル１１０は、通信中セッション状況の情報を格納する。セッションリソーステーブル１２０は、使用可能なセッションリソース数および消費状況に関する情報を格納する。セッション重要度テーブル１３０は、予め定められたセッションの重要度情報を格納する。セッション復旧テーブル１４０は、切断されかつ復旧が必要なセッションの情報を格納する。なお、各テーブルの構成については、後に詳細に説明する。
【００２３】
（テーブル構成）
図４は、セッションリソーステーブル１２０の構成図である。
セッションリソーステーブル１２０は、例えば、ユーザとキャリアとのサービス契約で規定された最大セッション数と、セッションリソースの消費状況を表す通信中セッション数カウンターとを含む。通信セッション数カウンターは、セッションの接続／切断に従い、インクリメント／デクリメントされる。
【００２４】
図５は、セッションの重要度情報を格納するセッション重要度テーブル１３０の構成図である。
セッション重要度テーブル１３０は、ユーザがあらかじめ自由に設定できる。セッション重要度テーブル１３０は、例えば、端末ＵＡ  ＵＲＩと、通信先ＵＡ  ＵＲＩと、重要度情報と、復旧要否情報とを含む。
【００２５】
端末ＵＡ  ＵＲＩは、ＳＩＰ  ＧＷ１０に接続されるそれぞれ異なるアプリケーションに対応する複数の端末ＵＡ２０を識別するための識別情報である。通信先ＵＡ  ＵＲＩは、通信先ＵＡ３０を識別するための識別情報である。復旧要否情報は、強制切断された場合におけるセッションの再接続の必要性を規定する。復旧要否についてもユーザが自由に設定できる。なお、復旧要否情報は省略することもできる。
【００２６】
重要度の例として、図示の例では、重要度を高いものから低いものへの順にＰ０からＰ６の順を想定している。Ｐ０は重要度が最も高いもので、この重要度の発信要求に対しては必ず満足させる必要がある。ここでは、Ｐ０を、例えばセキュリティ監視のためのセッションに設定している。なお、１１０番通報などの緊急セッションであってもよい。重要度Ｐ０のセッションは、この例ではひとつであるが、複数のセッションであってもよい。
【００２７】
Ｐ１からＰ６は、切断しなければいけない場合の各種セッションの切断順番（優先順位）を表している。Ｐ６からＰ１の順で切断対象セッションとなる。図示の例では、Ｐ１を特定のサーバ（例えば有料コンテンツサーバ）からのビデオストリーム受信のセッションに、Ｐ２を会社とのテレビ会議のセッションに、Ｐ３を会社との電話のセッションに、Ｐ４を任意のサーバからのビデオストリーム受信のセッションに、Ｐ５を任意の相手とのテレビ会議のセッションに、Ｐ６を任意の相手との電話のセッションに設定されている。
【００２８】
有料コンテンツサーバからのビデオストリーム受信のセッションは、途中で切断されると、次回接続したときに最初からダウンロードをやり直すなど、二重で課金される場合もある。この例では、有料コンテンツサーバからのビデオストリーム受信のセッションは、重要度を高く設定しており、このような二重課金を防止することができる。
なお、重要度のレベル数は、図示のような７段階固定でなくてもよく、ユーザによって適宜設定できる。
【００２９】
図６は、通信中セッション状況の情報を格納するセッション状況テーブル１１０の構成図である。
セッション状況テーブル１１０は、セッションを内部で識別するためのセッション管理番号（固定）と、セッション生起度に生成される一意的なセッションＩＤ（Ｃａｌｌ  ＩＤ）と、セッションの通信元の端末ＵＡのＵＲＩと、通信先ＵＡのＵＲＩとを含む。図示の例は、最大セッション数が２と仮定したときのセッション状況テーブル１１０である。
【００３０】
図６（ａ）に示すテーブルは、すでに最大セッション数に達するセッションが通信中の場合の例である。この例では、セッション管理番号Ｓ１のセッションでは、セットトップボックスである端末ＵＡ−Ａ２１（ＵＲＩ：ｓｔｂ−ｔａｎａｋａ@ｈｏｍｅ１．ｃｏｍ）と、ビデオ配信サーバである通信先ＵＡ−ａ３１（ＵＲＩ：ｄｏｗｌｏａｄ@ｉｃｐ２．ｃｏｍ）とが、セッションＩＤ  ａａａで接続されている。また、セッション管理番号Ｓ２のセッションでは、ＰＣである端末ＵＡ−Ｂ２２（ＵＲＩ：ｖｉｄｅｏｃｏｎ−ｔａｎａｋａ@ｈｏｍｅ１．ｃｏｍ）と、テレビ会議サーバである通信先ＵＡ−ｂ３２（ＵＲＩ：ｖｉｄｅｏｃｏｎ@ｃｏｍｐａｎｙ１．ｃｏｍ）とが、セッションＩＤ  ａａａで接続されている。
【００３１】
図６（ｂ）に示すテーブルは、セッション管理番号Ｓ１のセッションが切断された後のテーブルである。
図６（ｃ）に示すテーブルは、新規セッション確立後、Ｓ１に新規セッションの情報が記憶された状態のテーブルである。新規セッションは、例えば、セキュリティ監視の端末ＵＡ−Ｃ２３（ＵＲＩ：ｓｅｃ−ｔａｎａｋａ@ｈｏｍｅ１．ｃｏｍ）と、セキュリティセンタのサーバである通信先ＵＡ−ｃ３３（ＵＲＩ：ｃｅｎｔｅｒ＠ｓｅｃｕｒｉｔｙ１．ｃｏｍ）とが、セッションＩＤ  ｃｃｃで接続されている。なお、図６（ａ）から（ｃ）へ遷移する処理の詳細は後述する。
【００３２】
図８は、セッションが切断されかつ復旧が必要なセッションの情報を格納するセッション復旧テーブル１４０の構成図である。
セッション復旧テーブル１４０は、例えば、セッションが切断された時刻情報を格納する「切断時刻」と、復旧された時刻情報を格納する「復旧時刻」と（復旧されるまでは空欄でもよい）、切断されたセッションのセッションＩＤと、端末ＵＡ  ＵＲＩと、通信先ＵＡ  ＵＲＩとを含む。セッションが復旧された後に、セッション制御部１４より復旧された時刻情報を「復旧時刻」フィールドに入力される。
【００３３】
（セッションの接続処理）
図３は、セッション制御部１４による、新規セッション接続要求に対する処理フローチャートである。
まず、端末ＵＡ２０は、自端末の端末ＵＡ  ＵＲＩ（通信元ＵＲＩ）と通信先ＵＡ  ＵＲＩ（通信先ＵＲＩ）を含む、新規セッションの接続要求をＳＩＰ  ＧＷ１０に送信する。例えば、端末ＵＡ−Ｃ２３が新規セッションの接続要求を送信する。なお、新規セッションの接続要求は、セッションＩＤをさらに含んでいてもよい。
【００３４】
ＳＩＰ  ＧＷ１０のセッション制御部１４は、回線Ｉ／Ｆ部１３経由で、新規セッションの接続要求を端末ＵＡ２０から受信する（Ｓ１０１）。セッション制御部１４は、新規セッションに割り当てるセッションリソースがあるか否かを判断するために、セッションリソーステーブル１２０を検索する（Ｓ１０３）。例えば、セッション制御部１４は、セッションリソーステーブル１２０を参照し、通信中のセッション数と最大セッション数とが同じ値の場合（空きリソースがない場合）は（Ｓ１０５：Ｙｅｓ）、ステップＳ１０７へ移り、それ以外の場合（空きリソースがある場合）は（Ｓ１０５：Ｎｏ）、ステップＳ１３１へ移る。
【００３５】
ステップＳ１０７では、セッション制御部１４は、新規セッションの接続要求に含まれる通信元ＵＲＩと通信先ＵＲＩに基づきセッション重要度テーブル１３０を検索し、対応する重要度を求める（Ｓ１０７）。セッション制御部１４は、求められた当該新規セッションの重要度が最も高いもの（Ｐ０）なのかを判断する（Ｓ１０９）。求められた重要度がＰ０でない場合は（Ｓ１０９:Ｎｏ）、セッション制御部１４は、セッション接続拒否メッセージを端末ＵＡ２０に返送する（Ｓ１３７）。一方、求められた重要度がＰ０であれば（Ｓ１０９:Ｙｅｓ）、ステップＳ１１１に移る。なお、求められた重要度がＰ０の場合（最も高いもの）以外にも、予め定められた基準より高い場合、ステップＳ１１１に移るようにしてもよい。
【００３６】
ステップＳ１１１では、セッション制御部１４は、セッション状況テーブル１１０を検索し、既存セッションの通信元ＵＲＩと通信先ＵＲＩを取得する（Ｓ１１１）。また、セッション制御部１４は、取得された通信元ＵＲＩと通信先ＵＲＩに基づきセッション重要度テーブル１３０に照合することによって、セッションの重要度情報と復旧要求情報（復旧要求の有否）を取得する（Ｓ１１３）。セッション制御部１４は、ステップＳ１１１とＳ１１３の処理を、既存のセッション全てについて実行し、接続中のセッション毎の重要度情報と復旧要求情報を取得する。
【００３７】
セッション制御部１４は、取得されたセッション毎の重要度を相互比較して、重要度の最も低いセッションを特定する（Ｓ１１５〜Ｓ１１９）。なお、セッション制御部１４は、重要度が予め定められた基準よりも低いセッションのひとつを特定してもよい。
セッション制御部１４は、特定されたセッションを切断する（Ｓ１２１）。セッション制御部１４は、切断されたセッションの復旧要求情報に従い、復旧要求の有無を判断する（Ｓ１２３）。
【００３８】
セッション制御部１４は、切断されたセッションが復旧を要求する場合（Ｓ１２３：Ｙｅｓ）、当該セッションに関する情報をセッション状況テーブル１１０からセッション復旧テーブル１４０に移動、保存する（Ｓ１２７）。より具体的には、セッション制御部１４は、ステップＳ１１３で取得された復旧要求情報が復旧が必要であることを示す場合、セッション状況テーブル１１０内の特定されたセッションの通信元ＵＲＩと通信先ＵＲＩとを読み出してセッション復旧テーブル１４０に記憶し、及び、当該通信元ＵＲＩと通信先ＵＲＩとをセッション状況テーブル１１０から削除する。
【００３９】
一方、セッション制御部１４は、切断されたセッションが復旧を要求しない場合（Ｓ１２３：Ｎｏ）、当該セッションに関する通信元ＵＲＩと通信先ＵＲＩとをセッション状況テーブル１１０から削除する（Ｓ１２５）。
【００４０】
ステップＳ１２９では、セッション制御部１４（又はセッション監視部１５）は、セッションリソーステーブル１２０を更新する（Ｓ１２９）。例えば、セッション制御部１４は、セッションリソーステーブル１２０の通信中のセッション数カウンターを１デクリメントする。
【００４１】
セッション制御部１４は、新規セッションを許可し、接続する（Ｓ１３１）。例えば、セッション制御部１４は、新規セッションの接続要求に含まれる通信元ＵＲＩと通信先ＵＲＩに従い、通信元の端末ＵＡと通信先ＵＡとの新規セッションを接続する。また、セッション制御部１４は、通信元ＵＲＩと通信先ＵＲＩとセッションＩＤとをセッション状況テーブル１１０に記憶する。なお、セッションＩＤは、適宜付与されることができる。
セッション制御部１４は、セッションリソーステーブル１２０の通信中セッション数カウンターを１インクリメントする（Ｓ１３５）。
【００４２】
（セッションの復旧処理）
図７は、セッション復旧部１６による、切断されたセッションの復旧処理フローチャートである。
セッション復旧部１６は、セッション復旧テーブル１４０に新規入力があると（Ｓ２０１、図３のＳ１２７に対応）、セッション復旧部１６は、セッションリソーステーブル１２０を検索し（Ｓ２０３）、リソースの空きがあるか否かを確認する（Ｓ２０５）。例えば、セッション復旧部１６は、セッションリソーステーブル１２０の通信中セッション数カウンターの値が最大セッション数より小さければ、リソースの空きがあると判断し、一方、通信中セッション数カウンターの値が最大セッション数より小さくなければ、リソースの空きがないと判断できる。
【００４３】
セッション復旧部１６は、リソースの空きがない場合は（Ｓ２０５：Ｎｏ）、例えば所定時間後に、再びセッションリソーステーブル１２０を検索し、リソースの空きがあるか否かを確認する（Ｓ２０３、Ｓ２０５）。一方、セッション復旧部１６は、リソースの空きがある場合は（Ｓ２０５：Ｙｅｓ）、セッション制御部１４に対して復旧するセッションの情報を送信するとともに、復旧処理を要求する（Ｓ２０７）。セッション制御部１４は、要求に従い、後述するセッション復旧処理を実行する。セッション制御部１４は、セッション復旧処理において、セッションの復旧に成功した場合は、実際の復旧時刻をセッション復旧テーブル１４０の「復旧時刻」フィールドに入力する（後述するステップＳ３１７）。
【００４４】
セッション復旧部１６は、セッション復旧テーブル１４０の「復旧時刻」フィールドに入力（記憶されたデータ）があるか否かを確認する（Ｓ２０９）。セッション復旧部１６は、「復旧時刻」フィールドに入力がない場合は（Ｓ２０９：Ｎｏ）、セッション制御部１４に対して復旧処理を再要求する（Ｓ２０７）。セッション復旧部１６は、「復旧時刻」フィールドに入力がある場合は（Ｓ２０９：Ｙｅｓ）、セッション復旧テーブル１４０より該当セッションの情報を削除する（Ｓ２１１）。
【００４５】
図９は、セッション制御部１４におけるセッション復旧処理のフローチャートである。
セッション制御部１４は、セッション復旧部１６より復旧要求を受信する（Ｓ３０１、図７のＳ２０７）。セッション制御部１４は、セッション復旧テーブル１４０を検索し（Ｓ３０３）、端末ＵＡ  ＵＲＩと通信先ＵＡ  ＵＲＩを取得する（Ｓ３０５）。セッション制御部１４は、取得された端末ＵＡ  ＵＲＩあてにＩＮＶＩＴＥメッセージ送信する（Ｓ３０７）。セッション制御部１４は、端末ＵＡより２００ＯＫ回答メッセージを受信があったかどうか判断する（Ｓ３０９）。受信がない場合はＩＮＶＩＴＥメッセージを再送信する（Ｓ３０７）。受信がある場合はステップＳ３１１にすすむ。
【００４６】
セッション制御部１４は、取得された通信先ＵＡ  ＵＲＩあてにＩＮＶＩＴＥメッセージ送信する（Ｓ３１１）。このＩＮＶＩＴＥメッセージは、例えば、取得された端末ＵＡ  ＵＲＩ（通信元ＵＲＩ）と通信先ＵＡ  ＵＲＩとを含む。セッション制御部１４は、通信先ＵＡより２００ＯＫ回答メッセージを受信があったかどうか判断する（Ｓ３１３）。受信がない場合はＩＮＶＩＴＥメッセージを再送信する（Ｓ３１１）。受信がある場合はステップＳ３１５にすすむ。
【００４７】
セッション制御部１４は、端末ＵＡ宛と通信先ＵＡ宛にそれぞれＡＣＫメッセージを送信する（Ｓ３１５）。以上の処理により、セッション復旧テーブル１４０に記憶されたセッションが再接続される。セッション制御部１４は、現在時刻をセッション復旧テーブル１４０の「復旧時刻」フィールドに書き込む（Ｓ３１７）。
なお、この例では、セッション制御部１４とセッション復旧部１６に分けて処理を行っているが、ひとつの制御部が処理をおこなってもよい。
【００４８】
図１０は、通信シーケンス図である。
例えば、端末ＵＡ−Ａ２１／通信先ＵＡ−ａ３１間、端末ＵＡ−Ｂ２２／通信先ＵＡ−ｂ３２間の通信で最大セッション数の２セッションを使い切った場合において、端末ＵＡ−Ｃ２３から重要度の最も高い緊急セッション接続要求があった場合のシーケンス図である。
【００４９】
端末ＵＡ−Ａ２１／通信先ＵＡ−ａ３１間、端末ＵＡ−Ｂ２２／通信先ＵＡ−ｂ３２間で、Ｓ１（ＳｅｓｓｉｏｎＩＤ  ａａａ）とＳ２（ＳｅｓｓｉｏｎＩＤ  ｂｂｂ）のセッションが確立され通信中の状態にある。このとき、セッション状況テーブル１１０は、図６（ａ）のようになっている。
【００５０】
端末ＵＡ−Ｃ２３は、通信先ＵＡ−ｃ３３宛のセッション接続要求（ＩＮＶＩＴＥメッセージ）をＳＩＰ  ＧＷ１０に送出する（Ｓ５０１）。セッション接続要求は、例えば、Ｆｒｏｍヘッダに端末ＵＡ−Ｃ２３の端末ＵＡ  ＵＲＩ（ｓｅｃ−ｔａｎａｋａ＠ｈｏｍｅ１．ｃｏｍ）と、Ｔｏヘッダに通信先ＵＡ−ｃ３３の通信先ＵＡ  ＵＲＩ（ｃｅｎｔｅｒ＠ｓｅｃｕｒｉｔｙ．ｃｏｍ）を含む。
【００５１】
ＳＩＰ  ＧＷ１０は、セッションリソーステーブル１２０を参照し、ここでは通信中のセッション数が最大セッション数に達していると判断する（Ｓ５０３、図３のＳ１０３、Ｓ１０５に対応）。
ＳＩＰ  ＧＷ１０は、セッション重要度テーブル１３０を参照し、ここでは新規セッションは重要度が最高のＰ０であると判断する（Ｓ５０５、図３のＳ１０７、Ｓ１０９に対応）。
【００５２】
ＳＩＰ  ＧＷ１０は、重要度の最も低い既存セッションＳ１（ａａａ）を特定する（Ｓ５０７、図３のＳ１１１〜Ｓ１１９に対応）。セッション状況テーブル１１０とセッション重要度テーブル１３０を参照すると、セッション管理番号Ｓ１のセッションは重要度がＰ４、セッション管理番号Ｓ２のセッションは重要度がＰ２である。したがって、ＳＩＰ  ＧＷ１０により、重要度の低いセッション管理番号Ｓ１のセッションが特定される。
【００５３】
セッションの切断処理は、セッション状況テーブル１１０のセッション管理番号Ｓ１の通信元ＵＲＩと通信先ＵＲＩに従い、ＳＩＰ  ＧＷ１０より端末ＵＡ−Ａ２１と通信先ＵＡ−ａ３１にそれぞれＢＹＥメッセージ（切断要求）を送出することによって行われる（Ｓ５０９、Ｓ５１１）。なお、ＢＹＥメッセージの中には切断理由として、ｒｅａｓｏｎ＝ｅｍｅｒｇｅｎｃｙ（緊急）の行を含むことができる。また、ＳＩＰ  ＧＷ１０は、端末ＵＡ−Ａ２１と通信先ＵＡ−ａ３１から２００  ＯＫを受信する（Ｓ５１３、Ｓ５１５）。
【００５４】
また、ＳＩＰ  ＧＷ１０は、復旧要求がある場合には、セッション復旧テーブル１４０にセッション状況テーブル１１０のセッション管理番号Ｓ１の通信元ＵＲＩと通信先ＵＲＩを記憶し、切断時刻を書き込む（図３のＳ１２７）。ＳＩＰ  ＧＷ１０は、セッション状況テーブル１１０のセッション管理番号Ｓ１のエントリを削除する（図３のＳ１２７、Ｓ１２５）。削除後のテーブル１１０は、例えば、図６（ｂ）のようになる。
【００５５】
特定されたセッションＳ１（ＳｅｓｓｉｏｎＩＤ  ａａａ）を切断した後、ＳＩＰ  ＧＷ１０は、新規セッションの通信先ＵＡ−ｃ３３に対してＩＮＶＩＴＥメッセージを送出して、端末ＵＡ−Ｃ２３／通信先ＵＡ−ｃ３３間のセッションＳ１（ＳｅｓｓｉｏｎＩＤ  ｃｃｃ）を確立させる（Ｓ５１７〜Ｓ５２５、図３のＳ１３１に対応）。
以上の処理により、端末ＵＡ−Ｃ２３／通信先ＵＡ−ｃ３３間が通信できる（Ｓ５２７）。
【００５６】
新規セッションＳ１（ＳｅｓｓｉｏｎＩＤ  ｃｃｃ）が通信後、セッションを終了するために、端末ＵＡ−Ｃ２３からＳＩＰ  ＧＷ１０に、そしてＳＩＰ  ＧＷ１０から通信先ＵＡ−ｃ３３にそれぞれＢＹＥメッセージを送出する（Ｓ５２９、Ｓ５３１）。また、ＳＩＰ  ＧＷ１０は、２００  ＯＫを通信先ＵＡ−ｃ３３から受信し、端末ＵＡ−Ｃ２３へ送信する（Ｓ５３３、Ｓ５３５）。それによって、Ｓ１分のセッションリソースが開放されることになる。
【００５７】
上記新規セッションリソースの開放（セッションの切断）により、又は、他のセッションの切断によりセッションに空きがあると判断したセッション復旧部１６から、セッション制御部１４に復旧要求が送出されることによって、ＳＩＰ  ＧＷ１０として復旧可能と判断する（Ｓ５３７）。
【００５８】
復旧処理は、セッション復旧テーブル１４０に記憶された情報に基づき、ＳＩＰ  ＧＷ１０から端末ＵＡ−Ａ２１と通信先ＵＡ−ａ３１にそれぞれＩＮＶＩＴＥメッセージを送出することによってなされる（Ｓ５３９〜Ｓ５４９）。
それによって、切断された端末ＵＡ−Ａ２１／通信先ＵＡ−ａ３１間のセッションをＳ１（ＳｅｓｓｉｏｎＩＤ  ｄｄｄ）の形で復旧されることとなる。
【産業上の利用可能性】
【００５９】
本発明は、例えば、ゲートウェイ装置、ゲートウェイ装置を介して端末・装置間が通信するシステム等に利用可能である。
【図面の簡単な説明】
【００６０】
【図１】ＳＩＰ  ＧＷのネットワーク構成概念図。
【図２】ＳＩＰ  ＧＷの内部構成概念図。
【図３】ＳＩＰ  ＧＷにおいて、新規セッション接続要求に対する処理フローチャート。
【図４】使用可能なセッションリソースおよび消費状況に関する情報を格納するセッションリソーステーブルの構成図。
【図５】セッションの重要度情報を格納するセッション重要度テーブルの構成図。
【図６】通信中セッション状況の情報を格納するセッション状況テーブルの構成図。
【図７】切断されかつ復旧必要性のあるセッションの復旧処理フローチャート。
【図８】切断されかつ復旧が必要なセッションの情報を格納するセッション復旧テーブルの構成図。
【図９】セッション制御部における復旧処理のフローチャート。
【図１０】ＵＡ−Ａ／ＵＡ−ａ間、ＵＡ−Ｂ／ＵＡ−ｂ間の通信で最大セッション数の２セッションを使い切った場合において、ＵＡ−Ｃ重要度の最も高い緊急セッション接続要求があった場合のシーケンス図。
【符号の説明】
【００６１】
１０  ＳＩＰゲートウェイ装置
２０  端末ＵＡ
３０  通信先装置ＵＡ
１１  ＣＰＵ
１２  回線制御部
１３  回線インタフェース部
１４  セッション制御部
１５  セッション監視部
１６  セッション復旧部
１００  メモリ
１１０  セッション状況テーブル（セッション状況記憶領域）
１２０  セッションリソーステーブル（セッションリソース記憶領域）
１３０  セッション重要度テーブル（セッション重要度記憶領域）
１４０  セッション復旧テーブル（セッション復旧記憶領域）
【図１】
2009049550.tif 000003
【図２】
2009049550.tif 000004
【図３】
2009049550.tif 000005
【図４】
2009049550.tif 000006
【図５】
2009049550.tif 000007
【図６】
2009049550.tif 000008
【図７】
2009049550.tif 000009
【図８】
2009049550.tif 000010
【図９】
2009049550.tif 000011
【図１０】
2009049550.tif 000012