(57)【特許請求の範囲】
【請求項１】
通信網を介した端末間の通信時に各端末において確保されるリソースに係る制御を行うリソース制御システムであって、
接続が確立される端末間の通信履歴を取得する通信履歴取得手段と、
前記通信履歴取得手段によって取得された通信履歴に基づいて、前記接続が切断された際の端末におけるリソースの確保時間を決定する確保時間決定手段と、
前記確保時間決定手段によって決定されたリソースの確保時間を示す確保時間情報を端末に送信する確保時間情報送信手段と、
を備えるリソース制御システム。
【請求項２】
前記通信履歴取得手段は、前記通信履歴として、端末間の接続の頻度及び接続の時間を示す情報の少なくとも何れかを取得する請求項１に記載のリソース制御システム。
【請求項３】
前記接続が切断された時刻を示す情報を取得すると共に、当該接続に係る端末間の新たな接続の要求を入力し、当該時刻及び前記確保時間決定手段によって決定されたリソースの確保時間に応じて、当該接続に係る端末において前記リソースが確保されたものとして接続処理を行う接続制御手段を更に備える請求項１又は２に記載のリソース制御システム。
【請求項４】
前記通信履歴取得手段は、前記接続が切断されてから当該接続に係る端末間の新たな接続の要求が行われるまでの経過時間を示す情報を取得し、
前記確保時間決定手段は、前記通信履歴に加えて、前記通信履歴取得手段によって取得された前記経過時間を示す情報にも基づいて、前記新たな接続が切断された際の端末におけるリソースの確保時間を決定する、請求項１〜３の何れか一項に記載のリソース制御システム。
【請求項５】
前記確保時間決定手段は、自システムの処理負荷を検出し、前記通信履歴に加えて、検出した処理負荷にも基づいて、前記接続が切断された際の端末におけるリソースの確保時間を決定する請求項１〜４の何れか一項に記載のリソース制御システム。
【請求項６】
前記確保時間決定手段は、前記端末が在圏している通信網を検出し、検出した通信網に応じて、前記接続が切断された際の端末におけるリソースの確保時間を決定する請求項１〜５の何れか一項に記載のリソース制御システム。
【請求項７】
通信網を介した端末間の通信時に各端末において確保されるリソースに係る制御を行うリソース制御システムの動作方法であるリソース制御方法であって、
接続が確立される端末間の通信履歴を取得する通信履歴取得ステップと、
前記通信履歴取得ステップにおいて取得された通信履歴に基づいて、前記接続が切断された際の端末におけるリソースの確保時間を決定する確保時間決定ステップと、
前記確保時間決定ステップにおいて決定されたリソースの確保時間を示す確保時間情報を端末に送信する確保時間情報送信ステップと、
を含むリソース制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信時に端末において確保されるリソースの制御に係るリソース制御システム及びリソース制御方法に関する。
【背景技術】
【０００２】
従来から、ＳＩＰ（Session Initiation Protocol）によって、移動体通信網を介して端末間の接続を行い、端末間での電話通信を行うことが知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２７０５５８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ＳＩＰによって通話を行うためには、通常、発呼時にＳＩＰ呼制御が行われた後、プレコンディション制御（precondition制御）が行われる必要がある。プレコンディション制御とは、発側の端末と着側の端末とにおいて、通話に必要なリソース、例えば、音声出力等に係るリソースの確保を確認するための制御である。
【０００５】
しかしながら、一度プレコンディション制御を実施し、終話後に同一端末（同一ユーザ）と再接続するケースにおいては、初回通話時と同様にプレコンディション制御が行われることとなる。このプレコンディション制御によって処理時間を要するため、迅速な接続が難しくなっていた。
【０００６】
本発明は、以上の問題点を解決するためになされたものであり、端末間の再接続時に迅速な接続を確立させると共に端末のリソースを適切に管理することができるリソース制御システム及びリソース制御方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記の目的を達成するために、本発明に係るリソース制御システムは、通信網を介した端末間の通信時に各端末において確保されるリソースに係る制御を行うリソース制御システムであって、接続が確立される端末間の通信履歴を取得する通信履歴取得手段と、通信履歴取得手段によって取得された通信履歴に基づいて、接続が切断された際の端末におけるリソースの確保時間を決定する確保時間決定手段と、確保時間決定手段によって決定されたリソースの確保時間を示す確保時間情報を端末に送信する確保時間情報送信手段と、を備える。
【０００９】
本発明では、端末間の通信履歴に基づいて、端末間の接続が切断された際のリソースの確保時間が決定されて、切断から当該確保時間が経過するまでリソースが確保される。従って、切断から当該確保時間が経過するまでに端末間の再接続を行う場合に、プレコンディション制御等のリソースを確保するための処理が不要となる。また、上記の通り、当該確保時間は、端末間の通信履歴に基づいて決定されているため、端末間の通信履歴に基づいて適切なものとすることができる。即ち、本発明によれば、端末間の再接続時に迅速な接続を確立させると共に端末のリソースを適切に管理することができる。
【００１０】
通信履歴取得手段は、通信履歴として、端末間の接続の頻度及び接続の時間を示す情報の少なくとも何れかを取得することとしてもよい。この構成によれば、リソースの確保時間を確実かつ適切に決定することができる。
【００１１】
リソース制御システムは、接続が切断された時刻を示す情報を取得すると共に、当該接続に係る端末間の新たな接続の要求を入力し、当該時刻及び確保時間決定手段によって決定されたリソースの確保時間に応じて、当該接続に係る端末においてリソースが確保されたものとして接続処理を行う接続制御手段を更に備えることとしてもよい。この構成によれば、プレコンディション制御等のリソースを確保するための処理の発生を防止することができる。
【００１２】
通信履歴取得手段は、接続が切断されてから当該接続に係る端末間の新たな接続の要求が行われるまでの経過時間を示す情報を取得し、確保時間決定手段は、通信履歴に加えて、通信履歴取得手段によって取得された経過時間を示す情報にも基づいて、新たな接続が切断された際の端末におけるリソースの確保時間を決定する、こととしてもよい。この構成によれば、リソースの確保時間を更に適切なものとすることができる。
【００１３】
確保時間決定手段は、自システムの処理負荷を検出し、通信履歴に加えて、検出した処理負荷にも基づいて、接続が切断された際の端末におけるリソースの確保時間を決定することとしてもよい。この構成によれば、リソース制御システムの処理負荷にも応じて、リソースの確保時間を適切なものとすることができる。
【００１４】
確保時間決定手段は、端末が在圏している通信網を検出し、検出した通信網に応じて、接続が切断された際の端末におけるリソースの確保時間を決定することとしてもよい。この構成によれば、例えば、リソースの確保が不要あるいは不適切な場合にリソースの確保を防止することができる。
【００１５】
ところで、本発明は、上記のようにリソース制御システムの発明として記述できる他に、以下のようにリソース制御方法の発明としても記述することができる。これはカテゴリが異なるだけで、実質的に同一の発明であり、同様の作用及び効果を奏する。
【００１６】
即ち、本発明に係るリソース制御方法は、通信網を介した端末間の通信時に各端末において確保されるリソースに係る制御を行うリソース制御システムの動作方法であるリソース制御方法であって、接続が確立される端末間の通信履歴を取得する通信履歴取得ステップと、通信履歴取得ステップにおいて取得された通信履歴に基づいて、接続が切断された際の端末におけるリソースの確保時間を決定する確保時間決定ステップと、確保時間決定ステップにおいて決定されたリソースの確保時間を示す確保時間情報を端末に送信する確保時間情報送信ステップと、を含む。
【発明の効果】
【００１８】
本発明では、端末間の接続の切断から確保時間が経過するまでに端末間の再接続を行う場合に、プレコンディション制御等のリソースを確保するための処理が不要となる。また、当該確保時間は、端末間の通信履歴に基づいて適切なものとすることができる。即ち、本発明によれば、端末間の再接続時に迅速な接続を確立させると共に端末のリソースを適切に管理することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施形態に係るリソース制御システムであるＡＳ、及び本発明の実施形態に係る端末であるＵＥの構成を示す図である。
【図２】従来のＵＥ間の接続を確立する処理を示すシーケンス図である。
【図３】本発明の実施形態に係るリソース制御システムであるＡＳのハードウェア構成を示す図である。
【図４】本発明の実施形態に係る端末であるＵＥのハードウェア構成を示す図である。
【図５】本発明の実施形態に係るリソース制御システム及び端末であるＡＳ及びＵＥで、ＵＥ間の接続の確立時に実行される処理（リソース制御方法）を示すシーケンス図である。
【図６】本発明の実施形態に係るリソース制御システム及び端末であるＡＳ及びＵＥで、ＵＥ間の接続の切断時に実行される処理（リソース制御方法）を示すシーケンス図である。
【発明を実施するための形態】
【００２０】
以下、図面と共に本発明に係るリソース制御システム、端末及びリソース制御方法の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。
【００２１】
図１に実施形態に係るリソース制御システムであるＡＳ（Application Server）１０、及び本発明の実施形態に係る端末であるＵＥ（UserEquipment）２０を示す。ＡＳ１０は、移動体通信網３０の構成要素である。移動体通信網３０は、ＵＥ２０に移動体通信の機能を提供する通信網である。ＵＥ２０は、ユーザに用いられて、移動体通信網３０に無線通信によって接続して移動体通信を行う装置である。具体的には、ＵＥ２０は、携帯電話機等に相当する。ＵＥ２０は、移動体通信網３０を介して、例えば、別のＵＥ２０との間に呼接続等の接続を確立して通信を行う。ＵＥ２０は、ＵＥ２０のユーザが移動体通信網３０の通信事業者と契約することによって移動体通信を行うことが可能になる。
【００２２】
ＵＥ２０間の接続によって、ＵＥ２０のユーザ間での通話が可能となる。ＵＥ２０は、通話のための接続を確立する際、当該通話に必要なリソースを確保する。当該リソースは、ＵＥ２０に予め備えられたものであり、例えば、ＵＥ２０から音声出力を行うためのものである。即ち、ＵＥ２０は、自端末２０が有するリソースを確保した上で移動体通信網３０を介して別のＵＥ２０との間で通信を行う。なお、ＵＥ２０は、以下に説明する本発明に係る機能を有していることを除けば、従来のＵＥと同様のものでよい。
【００２３】
本実施形態においては、移動体通信網３０は、ＩＭＳ（IP Multimedia Subsystem）基盤及びＳＥＮ（ServiceEnabler Network）基盤によって構成されているものとする。但し、本発明は、上記の通信方式に限られるものではない。また、移動体通信網３０では、端末間の接続は、ＳＩＰ（Session Initiation Protocol）に基づいて確立される。
【００２４】
ＡＳ１０は、移動体通信網３０において、ＵＥ２０間の接続を確立するための信号（ＳＩＰの制御信号）を送受信するノード（装置）である。また、ＡＳ１０は、移動体通信網３０を介したＵＥ間の通信時に各ＵＥにおいて確保されるリソースに係る制御を行うシステムである。なお、ＡＳ１０は、以下に説明する本発明に係る機能を有していることを除けば、従来のＡＳと同様に移動体通信網３０で機能する。
【００２５】
図１に示すように移動体通信網３０には、ＭＲＦ（Media Resource Function）４０が含まれている。ＭＲＦ４０は、移動体通信網３０における音声データの生成等の機能を有するノード（装置）である。ＭＲＦ４０は、従来のＭＲＦと同様に移動体通信網３０で機能する。ＡＳ１０と、ＭＲＦ４０とは、情報の送受信が可能なように接続されている。なお、ＵＥ２０間の接続は、実際には、一方のＵＥ２０とＭＲＦ４０との間の接続と、もう一方のＵＥ２０とＭＲＦ４０との間の接続との２つの接続から構成される。移動体通信網３０には、図１に示すＡＳ１０及びＭＲＦ４０以外にも、従来の移動体通信網に含まれる装置、例えば、ＣＳＣＦ（Call Session Control Function）、無線制御装置、基地局等のノード（装置）が含まれ、従来のノードと同様に移動体通信網３０で機能する。
【００２６】
ここで、図２のシーケンス図を用いて、従来のＵＥ間の接続を確立する処理を説明する。なお、この処理は、ＲＦＣ３３１２で規定されているシーケンスによるものである。また、本処理は、本実施形態の処理と共通する部分があるため、便宜上、処理に係る装置に本実施形態と同様の符号を付けて説明する。本処理では、まず、発側のＵＥ２０によって、着側のＵＥ２０との間の接続の確立を要求する信号であるＩＮＶＩＴＥが移動体通信網３０に対して送信される（Ｓ０１）。ＩＮＶＩＴＥの送信は、発側のＵＥ２０に対するユーザの発信の操作が行われることをトリガとして行われる。
【００２７】
ＵＥ２０間の接続を確立する処理における信号には、ＵＥ２０におけるリソースの確保状況を示す情報が含められる。具体的には、例えば、ＩＮＶＩＴＥには、“ｌｏｃａｌ：ｎｏｎｅ，ｒｅｍｏｔｅ：ｎｏｎｅ”との情報が含められる。“ｌｏｃａｌ”は、自身（信号の送信元）のリソースの確保状況を示しており、“ｒｅｍｏｔｅ”は、通信相手となる端末のリソースの確保状況を示している。また、ｎｏｎｅは、リソースが確保されていないことを示しており、後述するようにｓｅｎｄｒｅｃｖが、リソースが確保されていることを示している。即ち、ＩＮＶＩＴＥ（ｌｏｃａｌ：ｎｏｎｅ，ｒｅｍｏｔｅ：ｎｏｎｅ）によって示されるリソースの確保状況は、発側のＵＥ２０及び着側のＵＥ２０共にリソースが確保されてないことを示している。なお、ＩＮＶＩＴＥには、“ｌｏｃａｌ：ｎｏｎｅ，ｒｅｍｏｔｅ：ｎｏｎｅ”との情報が含められることが予め定められている。
【００２８】
発側のＵＥ２０から移動体通信網３０に対して送信されたＩＮＶＩＴＥは、ＡＳ１０によって受信される。受信されたＩＮＶＩＴＥは、ＡＳ１０からＭＲＦ４０に送信される（Ｓ０２）。ＭＲＦ４０では、当該ＩＮＶＩＴＥが受信されて、当該ＩＮＶＩＴＥに対する暫定応答の信号である１８３がＡＳ１０に送信される（Ｓ０３）。
【００２９】
ＡＳ１０では、当該１８３が受信される。続いて、ＡＳ１０から、着側のＵＥ２０に対してＩＮＶＩＴＥが送信される（Ｓ０４）。なお、送信先の着側のＵＥ２０は、ＩＮＶＩＴＥに含まれる発信先を示す情報（例えば、着側のＵＥ２０の電話番号）から特定される。図２に示すようにここまでの信号には、発側のＵＥから送信されるＩＮＶＩＴＥに含められる情報と同様に、全て“ｌｏｃａｌ：ｎｏｎｅ，ｒｅｍｏｔｅ：ｎｏｎｅ”との情報が含められる。
【００３０】
着側のＵＥ２０では、当該ＩＮＶＩＴＥが受信されて、当該ＩＮＶＩＴＥに対する暫定応答の信号である１８３が移動体通信網３０に送信される（Ｓ０５）。当該１８３には、“ｌｏｃａｌ：ｎｏｎｅ，ｒｅｍｏｔｅ：ｎｏｎｅ”との情報が含められる。着側のＵＥ２０から送信される信号に含まれる情報における“ｌｏｃａｌ”は、着側のＵＥ２０自身を示しており、“ｒｅｍｏｔｅ”は、発側のＵＥ２０を示している。即ち、発側のＵＥ２０からの信号に含まれる情報と、“ｌｏｃａｌ”及び“ｒｅｍｏｔｅ”を意味するＵＥ２０が逆になる。
【００３１】
着側のＵＥ２０から移動体通信網３０に対して送信された１８３は、ＡＳ１０によって受信される。続いて、ＡＳ１０から、ＭＲＦ４０に対してＵＰＤＡＴＥが送信される（Ｓ０６）。ＭＲＦ４０では、当該ＵＰＤＡＴＥが受信されて、当該ＵＰＤＡＴＥに対する応答の信号である２００ＯＫ（ＵＰＤＡＴＥ）がＡＳ１０に送信される（Ｓ０７）。ＡＳ１０では、当該２００ＯＫ（ＵＰＤＡＴＥ）が受信される。続いて、ＡＳ１０から、発側のＵＥ２０に対してＩＮＶＩＴＥに対する暫定応答である１８３が送信される（Ｓ０８）。発側のＵＥ２０では、当該１８３が受信される。図２に示すように、着側のＵＥ２０からの１８３（Ｓ０５）から、ここまでの信号には、着側のＵＥ２０から送信される１８３に含められる情報と同様に、全て“ｌｏｃａｌ：ｎｏｎｅ，ｒｅｍｏｔｅ：ｎｏｎｅ”との情報が含められる。本処理では、上記のようにまずＳＩＰ呼制御（Ｓ０１〜Ｓ０８の信号のやりとり）が行われる。
【００３２】
続いて、プレコンディション制御が行われる。上述したように、プレコンディション制御とは、発側のＵＥ２０と着側のＵＥ２０とにおいて、通話に必要なリソースの確保を確認するための制御である。この制御に先立って、発側のＵＥ２０、及び着側のＵＥ２０では、それぞれリソース確保の処理が行われる（Ｓ０９、Ｓ１０）。なお、リソースの確保は、自端末においてリソースが確保された旨の情報を含む信号を送信する前までに行われる。発側のＵＥ２０ではＳ１１の処理までに、着側のＵＥ２０ではＳ１５の処理までにリソースの確保が行われる。即ち、それぞれのＵＥ２０においてリソースの確保が行われてから、発側のＵＥ２０ではＳ１１の処理が、着側のＵＥ２０ではＳ１５の処理がそれぞれ行われる。
【００３３】
プレコンディション制御では、発側のＵＥ２０から、自身のリソースが確保されたことを通知する信号であるＵＰＤＡＴＥが移動体通信網３０に対して送信される（Ｓ１１）。発側のＵＥ２０では、リソースが確保されているため、当該ＵＰＤＡＴＥには、“ｌｏｃａｌ：ｓｅｎｄｒｅｃｖ，ｒｅｍｏｔｅ：ｎｏｎｅ”との情報が含められる。
【００３４】
発側のＵＥ２０から移動体通信網３０に対して送信されたＵＰＤＡＴＥは、ＡＳ１０によって受信される。受信されたＵＰＤＡＴＥは、ＡＳ１０からＭＲＦ４０に送信される（Ｓ１２）。ＭＲＦ４０では、当該ＵＰＤＡＴＥが受信されて、当該ＵＰＤＡＴＥに対する応答の信号である２００ＯＫ（ＵＰＤＡＴＥ）がＡＳ１０に送信される（Ｓ１３）。
【００３５】
ＡＳ１０では、当該２００ＯＫ（ＵＰＤＡＴＥ）が受信される。続いて、ＡＳ１０から、着側のＵＥ２０に対してＵＰＤＡＴＥが送信される（Ｓ１５）。図２に示すように発側のＵＥ２０からのＵＰＤＡＴＥ（Ｓ１１）から、ここまでの信号には、発側のＵＥ２０から送信されるＵＰＤＡＴＥに含められる情報と同様に、全て“ｌｏｃａｌ：ｓｅｎｄｒｅｃｖ，ｒｅｍｏｔｅ：ｎｏｎｅ”との情報が含められる。
【００３６】
着側のＵＥ２０では、当該ＵＰＤＡＴＥが受信されて、当該ＵＰＤＡＴＥに対する応答の信号である２００ＯＫ（ＵＰＤＡＴＥ）が移動体通信網３０に送信される（Ｓ１５）。着側のＵＥ２０では、リソースが確保されているため、当該ＵＰＤＡＴＥには、“ｌｏｃａｌ：ｓｅｎｄｒｅｃｖ，ｒｅｍｏｔｅ：ｓｅｎｄｒｅｃｖ”との情報が含められる。
【００３７】
着側のＵＥ２０から移動体通信網３０に対して送信された２００ＯＫ（ＵＰＤＡＴＥ）は、ＡＳ１０によって受信される。続いて、ＡＳ１０から、ＭＲＦ４０に対してＵＰＤＡＴＥが送信される（Ｓ１６）。ＭＲＦ４０では、当該ＵＰＤＡＴＥが受信されて、当該ＵＰＤＡＴＥに対する応答の信号である２００ＯＫ（ＵＰＤＡＴＥ）がＡＳ１０に送信される（Ｓ１７）。ＡＳ１０では、当該２００ＯＫ（ＵＰＤＡＴＥ）が受信される。続いて、ＡＳ１０から、発側のＵＥ２０に対してＵＰＤＡＴＥに対する応答である２００ＯＫ（ＵＰＤＡＴＥ）が送信される（Ｓ１８）。図２に示すように、着側のＵＥ２０からの２００ＯＫ（ＵＰＤＡＴＥ）（Ｓ１５）から、ここまでの信号には、当該２００ＯＫ（ＵＰＤＡＴＥ）に含められる情報と同様に、全て“ｌｏｃａｌ：ｓｅｎｄｒｅｃｖ，ｒｅｍｏｔｅ：ｓｅｎｄｒｅｃｖ”との情報が含められる。以上が、プレコンディション制御である。
【００３８】
上記のプレコンディション制御により、ＵＥ２０間で互いのリソースが確立されたことが確認されると、接続が確立されて通話が可能な状態となる。従来のＵＥ２０では、通話が終了して、接続が切断されると、確保されたリソースが解放される。従って、従来では、ＵＥ２０間で再接続が行われる際にも、再度、リソース確保の処理（Ｓ０９，Ｓ１０）及びプレコンディション制御（Ｓ１１〜Ｓ１８）が行われていた。従来のＵＥ間の再接続では、上述したように、これらの処理に処理時間を毎回、要するため、迅速な接続が難しくなっていた。
【００３９】
引き続いて、本実施形態に係るＡＳ１０及びＵＥ２０の機能について説明する。図１に示すように、ＡＳ１０は、接続制御部１１と、通信履歴取得部１２と、確保時間決定部１３と、確保時間情報送信部１４とを備えて構成される。
【００４０】
接続制御部１１は、ＵＥ２０間の接続を確立するための信号を送受信する接続制御手段である。基本的には、接続制御部１１は、図２を用いて説明した従来と同様に信号の送受信を行うが、特定の場合には、従来とは異なる本実施形態ならではの信号の送受信を行う。また、接続制御部１１は、ＵＥ２０間の接続を切断するための信号を送受信する。具体的には後述する。
【００４１】
通信履歴取得部１２は、接続が確立されるＵＥ２０間の通信履歴を取得する通信履歴取得手段である。ＵＥ２０の通信履歴は、移動体通信網３０の構成要素であるＨＬＲ（Home Location Register）（図示せず）に格納されている。ＡＳ１０と、ＨＬＲとは、情報の送受信が可能なように接続されている。通信履歴取得部１２は、接続制御部１１を介して、ＨＬＲに記憶されている通信履歴を取得する。但し、通信履歴取得部１２は、必ずしもＨＬＲから通信履歴を取得する必要はなく、移動体通信網３０で用いられえる任意の手法によって通信履歴を取得することとしてもよい。
【００４２】
通信履歴取得部１２によって取得される通信履歴は、例えば、通信を行った２つのＵＥ２０を特定する情報（例えば、２つのＵＥ２０それぞれの電話番号）、通信の開始時刻（接続が確立された時刻）及び通信の終了時刻（接続が切断された時刻）が対応付けられた情報である。即ち、通信履歴取得部１２は、通信履歴として、ＵＥ２０間の接続の頻度及び接続の時間を示す情報を取得する。
【００４３】
例えば、通信履歴取得部１２は、接続制御部１１によって発側のＵＥ２０からＩＮＶＩＴＥが受信された際に、当該ＩＮＶＩＴＥによって示される発側のＵＥ２０と着側のＵＥ２０との組み合わせについての通信履歴を取得することとしてもよい。当該組み合わせは、ＩＮＶＩＴＥに含まれる情報によって示される発側のＵＥ２０を特定する情報及び着側のＵＥ２０を特定する情報（例えば、それらのＵＥ２０の電話番号）によって特定される。あるいは、通信履歴取得部１２は、一定時間毎に移動体通信網３０において通信を行ったＵＥ２０の組み合わせ毎に通信履歴を取得することとしてもよい。通信履歴取得部１２は、取得した通信履歴を確保時間決定部１３に出力する。
【００４４】
確保時間決定部１３は、通信履歴取得部１２から入力された通信履歴に基づいて、接続が切断された際のＵＥ２０におけるリソースの確保時間を決定する確保時間決定手段である。例えば、確保時間決定部１３は、以下のようにリソースの確保時間を決定する。確保時間決定部１３は、通信履歴に基づいて、平均通話時間（分）と１時間あたりの平均呼数（接続数）とを算出する。当該算出には、例えば、算出時点から予め設定された期間、例えば、現時点から遡って特定の日数分、あるいは特定の数時間分の通信履歴を用いることとしてもよい。また、当該算出は、接続に係る２つのＵＥ２０の組み合わせ毎に行われる。
【００４５】
平均通話時間については、確保時間決定部１３は、例えば、通信履歴に含まれる個々の通信の開始時刻及び通信の終了時刻から、個々の通信の時間を算出し、それらを平均することで算出する。平均呼数については、確保時間決定部１３は例えば、通信履歴によって示される通信の回数を上記の予め設定された期間（時間）で割ることで算出する。
【００４６】
確保時間決定部１３は、算出した平均通話時間と１時間あたりの平均呼数とから、以下の式によって確保時間（分）を算出して決定する。
確保時間（分）＝平均通話時間×１時間あたりの平均呼数×２４
例えば、平均通話時間が５分、平均呼数が０．５回である場合、確保時間（分）は、５×０．５×２４＝６０（分）（＝１時間）となる。このように算出することで、ＵＥ２０間の接続の頻度が高く、また接続の時間が長いＵＥ２０の組み合わせほど、確保時間を長くし、再接続の際のプレコンディション制御を防止することができる。また、パラメータである×２４は、平均呼数が比較的多いユーザには、１日あたり数回程度、リソースを有効活用できるように想定したものである。但し、当該パラメータは、任意に調整することとしてもよい。なお、上記の平均通話時間と、１時間あたりの平均呼数とは、予め設定された時間帯毎（例えば、昼の時間、夜の時間）に算出することとしてもよい。また、確保時間の算出の式は、必ずしも上記である必要はなく、移動体通信網のポリシーに従って適宜決めることができる。
【００４７】
確保時間決定部１３は、例えば、ＵＥ２０間の接続を切断するための信号であるＢＹＥが、接続制御部１１によって当該接続に係る一方のＵＥ２０から受信された際に、当該接続に係る２つのＵＥ２０について上記のようにリソースの確保時間を決定する。確保時間決定部１３は、決定したリソースの確保時間を確保時間情報送信部１４に通知する。
【００４８】
確保時間情報送信部１４は、確保時間決定部１３によって決定されたリソースの確保時間を示す確保時間情報をＵＥ２０に送信する確保時間情報送信手段である。例えば、確保時間情報送信部１４は、接続制御部１１に送受信される信号に確保時間情報を含めることで確保時間情報をＵＥ２０に送信する。具体的には、ＢＹＥに確保時間情報を含める。
【００４９】
また、リソースの確保時間は、直近の接続が切断された時刻と共に接続制御部１１によって把握できるようにしておく。例えば、ＨＬＲに、ＵＥ２０の組み合わせに対応付けて確保時間情報及び直近の接続が切断された時刻を記憶させておき、上記の履歴情報と併せて取得できるようにしておく。なお、直近の接続が切断された時刻は、従来のＨＬＲが通信履歴として記憶している情報と同様に取得される。
【００５０】
接続制御部１１は、接続に係るＵＥ２０間の新たな接続の要求を入力する。具体的には、接続制御部１１は、リソースの確保時間が決定された２つのＵＥ２０のうち一方のＵＥ２０から、もう一方のＵＥ２０へ接続するＩＮＶＩＴＥを受信する。接続制御部１１は、ＩＮＶＩＴＥを受信した際、上記のように決定された確保時間に基づき、それらのＵＥ２０においてリソースが確保されている状態か否かを判断する。具体的には、接続制御部１１は、当該２つのＵＥ２０間での直近の接続が切断された時刻を示す情報、及び当該２つのＵＥ２０についての確保時間情報を取得する。例えば、それらの情報は、上記のようにＨＬＲから取得される。
【００５１】
接続制御部１１は、当該直近の接続が切断された時刻から現時点までの経過時間が、確保時間情報によって示されるリソースの確保時間を超えているか否かを判断する。経過時間が、リソースの確保時間を超えていなければ、接続制御部１１は、それらのＵＥ２０においてリソースが確保されているものと判断する。この場合、接続制御部１１は、当該ＩＮＶＩＴＥに係るＵＥ２０においてリソースが確保されたものとして接続処理を行う。具体的には、ＩＮＶＩＴＥに含まれるリソースの確保状況を示す情報を“ｌｏｃａｌ：ｎｏｎｅ，ｒｅｍｏｔｅ：ｎｏｎｅ”から、“ｌｏｃａｌ：ｓｅｎｄｒｅｃｖ，ｒｅｍｏｔｅ：ｓｅｎｄｒｅｃｖ”に書き換える。このように書き換えが行われることで、ＩＮＶＩＴＥの処理であるＳＩＰ呼制御において、リソース確保の確認が行われる。これにより、プレコンディション制御が不要となり、行われない。なお、上記の書き換え以降の信号の送受信については、シーケンス図を用いた説明で説明する。
【００５２】
経過時間が、リソースの確保時間を超えていれば、接続制御部１１は、それらのＵＥ２０においてリソースが確保されていないものと判断する。この場合、接続制御部１１は、従来と同様の接続処理（図２に示す処理）を行う。この場合には、プレコンディション制御が行われる。以上が、ＡＳ１０の機能である。
【００５３】
図１に示すように、ＵＥ２０は、通信部２１と、確保時間情報受信部２２と、リソース確保部２３とを備えて構成される。
【００５４】
通信部２１は、移動体通信網３０に接続して、他のＵＥ２０との間で通信を行う。基本的には、接続の確立時には、通信部２１は、図２を用いて説明した従来と同様に信号の送受信を行う。また、通信部２１は、ＵＥ２０間の接続を切断するための信号を送受信する。但し、リソースが確保済みである場合には、通信部２１は、従来とは異なる本実施形態に応じた処理を行う。なお、本実施形態に係る機能の信号の送受信については、シーケンス図を用いた説明で説明する。
【００５５】
確保時間情報受信部２２は、リソースの確保時間を示す確保時間情報をＡＳ２０から受信する確保時間情報受信手段である。確保時間情報受信部２２は、通信部２１を介して確保時間情報を受信する。上述したように確保時間情報は、ＡＳ２０によって、ＢＹＥに含められる。また、後述するように、確保時間情報は、ＢＹＥの応答の信号である２００ＯＫ（ＢＹＥ）にも含められる。従って、ＵＥ２０が、ＢＹＥを送信した側である場合には、確保時間情報受信部２２は、２００ＯＫ（ＢＹＥ）を受信することで確保時間情報を受信する。また、ＵＥ２０が、ＢＹＥを送信された側である場合には、確保時間情報受信部２２は、ＢＹＥを受信することで確保時間情報を受信する。確保時間情報受信部２２は、受信した確保時間情報をリソース確保部２３に出力する。
【００５６】
リソース確保部２３は、リソースを確保したままにしておくリソース確保手段である。リソース確保部２３は、別のＵＥ２０との接続の切断時に、確保時間情報受信部２２によって受信された確保時間情報を入力する。リソース確保部２３は、別のＵＥ２０との接続が切断されてから、確保時間情報によって示されるリソースの確保時間が経過するまで、当該通信の際に確保されたリソースを解放せずにリソースを確保したままにしておく。接続が切断されてからリソースの確保時間が経過するまでに、当該別のＵＥ２０との間で再接続が行われる場合には、当該確保されたままのリソースが通信に利用される。リソース確保部２３は、別のＵＥ２０との接続が切断されてから、確保時間情報によって示されるリソースの確保時間が経過すると、リソースを開放する。以上が、ＵＥ２０の機能である。
【００５７】
図３に本実施形態に係るＡＳ１０のハードウェア構成を示す。図３に示すようにＡＳ１０は、ＣＰＵ（Central Processing Unit）１０１、主記憶装置であるＲＡＭ（RandomAccess Memory）１０２及びＲＯＭ（Read Only Memory）１０３、通信を行うための通信モジュール１０４、並びにハードディスク等の補助記憶装置１０５等のハードウェアを備えるサーバ装置として構成される。これらの構成要素がプログラム等により動作することにより、上述したＡＳ１０の機能が発揮される。
【００５８】
図４に本実施形態に係るＵＥ２０のハードウェア構成を示す。図４に示すように、ＵＥ２０は、ＣＰＵ２０１、主記憶装置であるＲＡＭ２０２及びＲＯＭ２０３、操作モジュール２０４、無線通信モジュール２０５、アンテナ２０６、ディスプレイ２０７等のハードウェアにより構成されている。これらの構成要素がプログラム等により動作することにより、上述したＵＥ２０の機能が発揮される。以上が、本実施形態に係るＡＳ１０及びＵＥ２０の構成である。
【００５９】
引き続いて、図５及び図６のシーケンス図を用いて、本実施形態に係るＡＳ１０及びＵＥ２０で実行される処理（ＡＳ１０及びＵＥ２０の動作方法）であるリソース制御方法を説明する。まず、図５のシーケンス図を用いて、ＵＥ２０間の接続の確立時、即ち、通話の開始時に実行される処理を説明する。
【００６０】
本処理では、まず、発側のＵＥ２０の通信部２１によって、着側のＵＥ２０との間の接続の確立を要求する信号であるＩＮＶＩＴＥが移動体通信網３０に対して送信される（Ｓ２１）。ＩＮＶＩＴＥの送信は、発側のＵＥ２０に対するユーザの発信の操作が行われることをトリガとして行われる。従来と同様にＩＮＶＩＴＥには、“ｌｏｃａｌ：ｎｏｎｅ，ｒｅｍｏｔｅ：ｎｏｎｅ”との情報が含められる。
【００６１】
発側のＵＥ２０から移動体通信網３０に対して送信されたＩＮＶＩＴＥは、ＡＳ１０の接続制御部１１によって受信される（Ｓ２１、接続制御ステップ）。受信されたＩＮＶＩＴＥは、接続制御部１１から通信履歴取得部１２に出力される。続いて、通信履歴取得部１２によって、受信されたＩＮＶＩＴＥに含まれる発側のＵＥ２０及び着側のＵＥ２０の電話番号が特定されて、当該２つのＵＥ２０の組み合わせについての通信履歴がＨＬＲから取得される（Ｓ２２、通信履歴取得ステップ、接続制御ステップ）。この際、当該２つのＵＥ２０の前回の通信時（通話時）に決定されて当該２つのＵＥ２０に通知された確保時間情報もＨＬＲから取得される。取得された通信履歴は、通信履歴取得部１２から確保時間決定部１３に入力される。
【００６２】
続いて、接続制御部１１によって、当該２つのＵＥ２０においてリソースが確保済か否かが判断される（Ｓ２３、接続制御ステップ）。具体的には、まず、通信履歴取得部１２によって取得された通信履歴に示される、当該２つのＵＥ２０間の前回の接続が切断された時刻が参照される。続いて、当該時刻から現時点までの経過時間が、確保時間情報によって示されるリソースの確保時間を超えているか否かが判断される。
【００６３】
経過時間が、リソースの確保時間を超えていれば、当該２つのＵＥ２０においてリソースが確保されていないものと判断される。この場合、従来と同様の接続処理（図２に示すＳ０２以降の処理）が行われて、ＵＥ２０間の接続が確立される。即ち、プレコンディション制御が行われる。
【００６４】
経過時間が、リソースの確保時間を超えていなければ、当該２つのＵＥ２０においてリソースが確保されているものと判断される。この場合、接続制御部１１によって、当該ＩＮＶＩＴＥに係るＵＥ２０においてリソースが確保されているものとして接続処理が行われる。具体的には、ＩＮＶＩＴＥに含まれるリソースの確保状況を示す情報が“ｌｏｃａｌ：ｎｏｎｅ，ｒｅｍｏｔｅ：ｎｏｎｅ”から、“ｌｏｃａｌ：ｓｅｎｄｒｅｃｖ，ｒｅｍｏｔｅ：ｓｅｎｄｒｅｃｖ”に書き換えられる（Ｓ２４、接続制御ステップ）。
【００６５】
書き換えられたＩＮＶＩＴＥは、接続制御部１１からＭＲＦ４０に送信される（Ｓ２５、接続制御ステップ）。ＭＲＦ４０では、当該ＩＮＶＩＴＥが受信されて、当該ＩＮＶＩＴＥに対する暫定応答の信号である１８３がＡＳ１０に送信される（Ｓ２６）。また、当該ＩＮＶＩＴＥに示される２つのＵＥ２０のリソースの確保状況が、リソースが確保されていることを示すものであるので、１８３の送信に続いて、ＭＲＦ４０から、当該ＩＮＶＩＴＥに対する応答の信号である２００ＯＫ（ＩＮＶＩＴＥ）がＡＳ１０に送信される（Ｓ２７）。
【００６６】
ＡＳ１０では、接続制御部１１によって、当該１８３及び２００ＯＫ（ＩＮＶＩＴＥ）が受信される。続いて、ＡＳ１０の接続制御部１１から、着側のＵＥ２０に対してＩＮＶＩＴＥが送信される（Ｓ２８、接続制御ステップ）。
【００６７】
着側のＵＥ２０では、通信部２１によって、当該ＩＮＶＩＴＥが受信されて、当該ＩＮＶＩＴＥに対する暫定応答の信号である１８３が移動体通信網３０に送信される（Ｓ２９）。また、当該ＩＮＶＩＴＥに示される２つのＵＥ２０のリソースの確保状況が、リソースが確保されていることを示すものであるので、１８３の送信に続いて、着側のＵＥ２０の通信部２１から、当該ＩＮＶＩＴＥに対する応答の信号である２００ＯＫ（ＩＮＶＩＴＥ）が移動体通信網３０に送信される（Ｓ３０）。
【００６８】
着側のＵＥ２０から移動体通信網３０に対して送信された１８３及び２００ＯＫ（ＩＮＶＩＴＥ）は、ＡＳ１０の接続制御部１１によって受信される。続いて、ＡＳ１０の接続制御部１１から、発側のＵＥ２０に対してＩＮＶＩＴＥに対する暫定応答である１８３が送信される（Ｓ３１）。発側のＵＥ２０では、当該１８３が受信される。続いて、ＡＳ１０の接続制御部１１から、ＭＲＦ４０に対してｒｅＩＮＶＩＴＥが送信される（Ｓ３２、接続制御ステップ）。また、Ｓ３０で着側のＵＥ２０から送信された２００ＯＫ（ＩＮＶＩＴＥ）に示される２つのＵＥ２０のリソースの確保状況が、リソースが確保されていることを示すものであるので、Ｓ３１の１８３の送信に続いて、ＡＳ１０の接続制御部１１から、ＩＮＶＩＴＥに対する応答の信号である２００ＯＫ（ＩＮＶＩＴＥ）が発側のＵＥ２０に送信される（Ｓ３３、接続制御ステップ）。
【００６９】
ＭＲＦ４０では、Ｓ３２でＡＳ１０から送信されたｒｅＩＮＶＩＴＥが受信されて、当該ｒｅＩＮＶＩＴＥに対する応答の信号である２００ＯＫ（ｒｅＩＮＶＩＴＥ）がＡＳ１０に送信される（Ｓ３４）。ＡＳ１０では、接続制御部１１によって当該２００ＯＫ（ｒｅＩＮＶＩＴＥ）が受信される。以上の処理により、ＵＥ２０間で互いのリソースが確立されたことが確認されると、接続が確立されて通話が可能な状態となる。Ｓ２３において、２つのＵＥ２０においてリソースが確保されているものと判断された場合、上記のようにプレコンディション制御が行われずに、ＳＩＰ呼制御の処理のみでＵＥ２０間の接続が確立される。以上が、ＵＥ２０間の接続の確立時、即ち、通話の開始時に実行される処理である。
【００７０】
続いて、図６のシーケンス図を用いて、ＵＥ２０間の接続の切断時、即ち、通話の終了時に実行される処理を説明する。本処理では、まず、発側のＵＥ２０の通信部２１によって、ＵＥ２０間の接続を切断するための信号であるＢＹＥが移動体通信網３０に対して送信される（Ｓ４１）。なお、ＢＹＥは、通信が確立されている２つのＵＥ２０の何れかから送信されてもよいが、本実施形態では、発側のＵＥ２０から送信されるものとする。ＢＹＥの送信は、発側のＵＥ２０に対するユーザの切断（通話終了）の操作が行われることをトリガとして行われる。
【００７１】
ＡＳ１０では、接続制御部１１によって、ＢＹＥが受信される。続いて、接続制御部１１から、確保時間決定部１３にＢＹＥが受信された旨が通知される。続いて、確保時間決定部１３によって、Ｓ２２において通信履歴取得部１２から入力された通信履歴に基づいて、接続が切断された際のＵＥ２０におけるリソースの確保時間が算出される（Ｓ４２、確保時間決定ステップ）。算出されたリソースの確保時間は、確保時間決定部１３から確保時間情報送信部１４に通知される。なお、確保時間の算出は、必ずしもＢＹＥが受信されたタイミングで行われる必要はなく、ＢＹＥが受信される前のＵＥ２０間の通信中に行われてもよい。
【００７２】
続いて、確保時間情報送信部１４によって、確保時間決定部１３によって決定されたリソースの確保時間を示す確保時間情報を２つのＵＥ２０に送信するための処理が行われる。具体的には、接続制御部１１によって受信されたＢＹＥに、確保時間情報が含められる（Ｓ４３、確保時間情報送信ステップ）。確保時間情報が含められたＢＹＥは、接続制御部１１からＭＲＦ４０に送信される（Ｓ４４、確保時間情報送信ステップ）。ＭＲＦ４０では、当該ＢＹＥが受信されて、当該ＢＹＥに対する応答の信号である２００ＯＫ（ＢＹＥ）がＡＳ１０に送信される（Ｓ４５）。なお、ＢＹＥに含まれていた確保時間情報は、２００ＯＫ（ＢＹＥ）にも含められる。
【００７３】
ＡＳ１０では、接続制御部１１によって、当該２００ＯＫ（ＢＹＥ）が受信される。続いて、ＡＳ１０の接続制御部１１から、着側のＵＥ２０に対して確保時間情報が含められたＢＹＥが送信される（Ｓ４６、確保時間情報送信ステップ）。着側のＵＥ２０では、通信部２１を介して確保時間情報受信部２２によってＢＹＥが受信される（Ｓ４６、確保時間情報受信ステップ）。ＢＹＥに含まれる確保時間情報は、確保時間情報受信部２２からリソース確保部２３に出力される。また、通信部２１によって、ＢＹＥに対する応答の信号である２００ＯＫ（ＢＹＥ）が移動体通信網３０に送信される（Ｓ４７）。なお、ＢＹＥに含まれていた確保時間情報は、２００ＯＫ（ＢＹＥ）にも含められる。
【００７４】
着側のＵＥ２０から移動体通信網３０に対して送信された２００ＯＫ（ＢＹＥ）は、ＡＳ１０の接続制御部１１によって受信される。続いて、ＡＳ１０の接続制御部１１から、発側のＵＥ２０に対して２００ＯＫ（ＢＹＥ）が送信される（Ｓ４８）。発側のＵＥ２０では、通信部２１を介して確保時間情報受信部２２によって２００ＯＫ（ＢＹＥ）が受信される（Ｓ４８、確保時間情報受信ステップ）。ＢＹＥに含まれる確保時間情報は、確保時間情報受信部２２からリソース確保部２３に出力される。以上の処理によって、ＵＥ２０間の接続が切断される。
【００７５】
続いて、着側のＵＥ２０では、発側のＵＥ２０との通信の際に確保されていたリソースが、リソース確保部２３によって解放されずに確保されたままにされる（Ｓ４９、リソース確保ステップ）。リソースの保持は、接続の切断時（例えば、２００ＯＫ（ＢＹＥ）の送信時）から、確保時間情報によって示されるリソースの確保時間が経過するまで行われる。一方、発側のＵＥ２０では、着側のＵＥ２０との通信の際に確保されていたリソースが、リソース確保部２３によって解放されずに確保されたままにされる（Ｓ５０、リソース確保ステップ）。リソースの保持は、接続の切断時（例えば、２００ＯＫ（ＢＹＥ）の受信時）から、確保時間情報によって示されるリソースの確保時間が経過するまで行われる。
【００７６】
上記のように接続が切断されても、即ち、通信が終了しても、リソースを確保しておき、図５に示すシーケンス図で説明した処理が行われることで、プレコンディション制御が行われずに、ＵＥ２０間の接続が確立される。
【００７７】
上述したように、本実施形態では、ＵＥ２０間の通信履歴に基づいて、ＵＥ２０間の接続が切断された際のリソースの確保時間が決定されて、切断から当該確保時間が経過するまでリソースが確保される。従って、切断から当該確保時間が経過するまでにＵＥ２０間の再接続を行う場合に、既に確保されているリソースが流用されて、プレコンディション制御等のリソースを確保するための処理が不要となる。これにより、再接続時の処理シーケンスが簡略化される。また、上記の通り、当該確保時間は、ＵＥ２０間の通信履歴に基づいて決定されているため、ＵＥ２０間の通信履歴に基づいて適切なものとすることができる。即ち、本実施形態によれば、ＵＥ２０間の再接続時に迅速な接続を確立させると共にＵＥ２０のリソースを適切に管理することができる。これにより、再接続時の通信可能となるまでの時間が短縮され、ユーザがストレスなく利用することができる。
【００７８】
また、本実施形態のように、リソースの確保時間を決定するための通信履歴として、ＵＥ２０間の接続の頻度及び接続の時間を示す情報を用いることとしてもよい。この構成によれば、リソースの確保時間を確実かつ適切に決定することができる。但し、接続の頻度及び接続の時間の何れか一方を用いることとしてもよい。例えば、上述したリソースの確保時間の式において、算出に用いない方の一方を予め設定した固定値とすることとしてもよい。また、リソースの確保時間の算出には、上記以外の通信履歴の情報を用いることとしてもよい。
【００７９】
また、上述したように決定されたＵＥ２０でのリソースの確保時間に応じて、リソースが確保されたものとして接続処理を行うこととしてもよい。本実施形態によれば、プレコンディション制御等のリソースを確保するための処理の発生を防止することができる。
【００８０】
引き続いて、本実施形態の変形例について説明する。リソースの確保時間の算出は、以下のように行われてもよい。この場合、ＡＳ１０の通信履歴取得部１２は、ＵＥ２０間の接続が切断されてから当該接続に係るＵＥ２０間の新たな接続の要求までの経過時間を示す情報を取得する。具体的には、発側のＵＥ２０が、ＩＮＶＩＴＥを送信する際（図５のＳ２１）に、前回の接続が切断されてから、即ち、前回の通話が終了してから当該ＩＮＶＩＴＥを送信するまでの経過時間を示す情報をフィードバック情報として当該ＩＮＶＩＴＥに含める。なお、発側のＵＥ２０は、前回の接続と異なるＵＥ２０との接続をしようとする場合には、上記のフィードバック情報を含めないこととしてもよい。
【００８１】
通信履歴取得部１２は、ＩＮＶＩＴＥからフィードバック情報を取得する。通信履歴取得部１２は、取得したフィードバック情報も確保時間決定部１３に出力する。なお、上記の経過時間は、ＨＬＲによって記憶されている履歴情報に基づいて算出されてもよい。なお、ＩＮＶＩＴＥにフィードバック情報が含まれない場合には、上述した実施形態と同様に算出してもよい。
【００８２】
確保時間決定部１３は、通信履歴に加えて、フィードバック情報にも基づいて、ＵＥ２０におけるリソースの確保時間を決定する。具体的には、以下の式によって確保時間（分）を算出して決定する。
確保時間（分）＝ｙ×α＋ｘ
ここで、ｘは（平均通話時間×１時間あたりの平均呼数×２４）であり、ｙは｛フィードバック情報に示される経過時間−（平均通話時間×１時間あたりの平均呼数×２４）｝である。また、αは、ｘとｙとの以下の関係を満たすｎの値である。
ｙ＜ｘ×（ｎ／１０）
なお、ｎは１〜１０の整数の値である。例えば、ｙ及びｘが、ｙ＜ｘ×０．１を満たす場合には、αは１となる。複数のｎの値で上記の関係を満たす場合、最も小さいｎをαとする。また、αは、予め設定された固定値としてもよい。この構成によれば、前回の切断から新たな接続の要求までの経過時間が考慮され、リソースの確保時間を更に適切なものとすることができる。
【００８３】
また、リソースの確保時間の算出は、更に以下のように行われてもよい。確保時間決定部１３は、自システムであるＡＳ１０の処理負荷を検出する。具体的には、確保時間決定部１３は、ＡＳ１０の処理負荷として、ＡＳ１０が実現されるサーバ装置のＣＰＵ使用率を検出する。確保時間決定部１３は、この検出を、例えば、リソースの確保時間の算出の直前（図６のＳ４２の直前）行う。
【００８４】
確保時間決定部１３は、通信履歴に加えて、検出したＣＰＵ使用率にも基づいて、ＵＥ２０におけるリソースの確保時間を決定する、具体的には、以下の式によって確保時間（分）を算出して決定する。
確保時間（分）＝（平均通話時間×１時間あたりの平均呼数×２４）×ｎ
ここで、ｎは検出したＣＰＵ使用率に基づいて決定される値である。まず、ＣＰＵ使用率が、予め設定された閾値を超えるか否かが判断される。ＣＰＵ使用率が、閾値を超えていない場合、ｎを１とする。ＣＰＵ使用率が、閾値を超えている場合、ＣＰＵ使用率が、閾値を超えている度合いに応じてｎを変化させる。例えば、閾値を超えている度合いが１０％未満であればｎを２とし、当該度合いが１０〜２０％であればｎを３とし、当該度合いが２０〜３０％であればｎを５とする。即ち、ＣＰＵ使用率が高いほど、リソースの確保時間を長くする。
【００８５】
リソースの確保時間を長くすれば、プレコンディション制御を行う可能性が低くなるため、ＡＳ１０の処理負荷を軽減することができる。従って、ＡＳ１０の処理負荷にも応じて、リソースの確保時間を適切なものとすることができる。
【００８６】
また、リソースの確保時間の決定及びリソース確保の制御は、必要な場合のみに行われてもよい。例えば、接続に係る２つのＵＥ２０のうち、少なくとも一方のＵＥ２０が、移動体通信網３０がサービスを提供しているエリア以外に位置している場合（例えば、ＵＥ２０が海外に位置している場合）には、リソースの確保時間の決定及びリソース確保の制御を行わないこととしてもよい。このような場合、そのＵＥ２０は、移動体通信網３０とは別の移動体通信網に在圏している、即ち、ローミングによって移動体通信網３０に接続している。ローミングの場合まで、切断後にリソースの確保を行う必要はないからである。また、ローミングの場合には、通常、発信頻度が減ると考えられるためである。
【００８７】
この場合、確保時間決定部１３は、ＵＥ２０が在圏している移動体通信網を検出し、検出した移動体通信網に応じて、ＵＥ２０におけるリソースの確保時間を決定する。ＵＥ２０が在圏している移動体通信網は、ＨＬＲにおいて管理されている情報を参照することで検出することができる。確保時間決定部１３は、ＨＬＲの情報を参照して、当該情報によって示されるＵＥ２０の在圏網が自身を含む移動体通信網３０であった場合には、上述した実施形態のようにリソースの確保時間を決定する。一方、当該情報によって示されるＵＥ２０の在圏網が自身を含む移動体通信網３０でなかった場合には、確保時間決定部１３は、リソースの確保時間を決定しない。あるいは、リソースの確保時間をゼロと決定する。この場合、ＢＹＥに確保時間情報を含めないか、リソースの確保時間がゼロであることを示す確保時間情報（リソース確保無し通知）をＢＹＥに含める。
【００８８】
この構成によれば、例えば、リソースの確保が不要あるいは不適切な場合にリソースの確保を防止することができる。
【００８９】
上述した実施形態では、発側のＵＥ２０から、移動体通信網３０にＩＮＶＩＴＥが送信された場合、着側のＵＥ２０が移動体通信網３０に在圏している、即ち、着側のＵＥ２０が移動体通信可能な状態であることを前提としていた。もし、着側のＵＥ２０が移動体通信可能な状態でない場合、例えば、着側のＵＥ２０が圏外である、あるいは、着側のＵＥ２０が既に解約されている場合には、接続を確立することができない。また、この場合、発側のＵＥ２０においてリソースを確保しておく必要がない。
【００９０】
従って、ＩＮＶＩＴＥによって特定される着側のＵＥ２０が移動体通信可能な状態でない場合、ＡＳ１０の接続制御部１１は、接続できない旨のエラー応答を発側のＵＥ２０に通知する。また、当該エラー応答にリソースを直ちに開放する（リソース確保時間削除）旨の情報を含める。発側のＵＥ２０は、当該情報を含むエラー応答を受信すると直ちにリソースを開放する。
【００９１】
なお、本実施形態においては、リソース制御システムをＡＳ１０としたが、必ずしもＡＳ１０とする必要はなく、移動体通信網３０において信号を中継する別の装置をリソース制御システムとしてもよい。例えば、ＣＳＣＦを本実施形態に係るリソース制御システムとしてもよい。
【符号の説明】
【００９２】
１０…ＡＳ、１１…接続制御部、１２…通信履歴取得部、１３…確保時間決定部、１４…確保時間情報送信部、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…補助記憶装置、２０…ＵＥ、２１…通信部、２２…確保時間情報受信部、２３…リソース確保部、２０１…ＣＰＵ、２０２…ＲＡＭ、２０３…ＲＯＭ、２０４…操作モジュール、２０５…無線通信モジュール、２０６…アンテナ、２０７…ディスプレイ、３０…移動体通信網、４０…ＭＲＦ。
【図１】
0006353384.tif 000002
【図２】
0006353384.tif 000003
【図３】
0006353384.tif 000004
【図４】
0006353384.tif 000005
【図５】
0006353384.tif 000006
【図６】
0006353384.tif 000007