移動通信システムにおいて移動端末に移動性を確保するためのアンカとしての機能を提供するパケット網ゲートウェイのリロケーションを制御するリロケーション制御装置であって、前記リロケーションの契機が発生したときに、前記移動端末と前記パケット網ゲートウェイとの間の通信の重要度およびその使用状況を得るための通信状況情報を取得する情報取得手段と、前記通信の重要度およびその使用状況に基づいて前記リロケーションの実行の可否を判定するリロケーション判定手段と、を有することを特徴とするリロケーション制御装置。前記情報取得手段は、前記移動端末と前記パケット網ゲートウェイとの間で確立している1以上の論理的データパスに割り当てられた通信品質プロファイルから前記通信の重要度を決定することを特徴とする請求項1に記載のリロケーション制御装置。前記情報取得手段は、前記通信状況情報を当該論理的データパス上にあるノードから取得することを特徴とする請求項1または2に記載のリロケーション制御装置。当該論理的データパス上にあるノードは、前記移動通信システムにおけるアクセス網ゲートウェイ、無線基地局または前記パケット網ゲートウェイのいずれかであることを特徴とする請求項3に記載のリロケーション制御装置。前記リロケーション判定手段は、通信途絶を回避すべき通信を重要通信として選択することを特徴とする請求項1-4のいずれか1項に記載のリロケーション制御装置。前記移動通信システムは3GPPにおいて標準化されたEPSであることを特徴とする請求項1-5のいずれか1項に記載のリロケーション制御装置。移動通信システムにおいて移動端末に移動性を確保するためのアンカとしての機能を提供するパケット網ゲートウェイのリロケーションを制御する方法であって、前記移動通信システムの移動管理ノードが、前記リロケーションの契機が発生したときに、前記移動端末と前記パケット網ゲートウェイとの間の通信の重要度およびその使用状況に基づいて前記リロケーションの実行の可否を判定することを特徴とするリロケーション制御方法。請求項1-6のいずれか1項に記載のリロケーション制御装置を備えた移動管理ノード。請求項8に記載の移動管理ノードを有する移動通信システム。移動通信システムにおいて移動端末に移動性を確保するためのアンカとしての機能を提供するパケット網ゲートウェイのリロケーションを制御するようにプログラム制御プロセッサを機能させるプログラムであって、情報取得手段が、前記リロケーションの契機が発生したときに、前記移動端末と前記パケット網ゲートウェイとの間の通信の重要度およびその使用状況を得るための通信状況情報を取得し、リロケーション判定手段が前記重要度およびその使用状況に基づいて前記リロケーションの実行の可否を判定する、ように前記プログラム制御プロセッサを機能させることを特徴とするプログラム。上述した手順によりパケット網GWのリロケーションが実行されると、図2に示すMMErequestedPDNdisconnection手順と図3に示すMMEinitiatedDetach手順のいずれにおいても、移動端末50と元のパケット網GW100との間で張られたPDNコネクションが削除される。したがって、移動端末50が通信を行っていた場合には当該通信が切断されてしまい、特に音声通話などの重要通信であった場合には、サービス途絶がユーザの通話体感を大きく劣化させる。このように、移動体自体、もしくは移動体に乗っているユーザが通信を継続しながら移動する場合や、ローカルGWの無いエリアからローカルGWのある領域に移動した場合などに、冗長経路を回避するために、アンカとして機能するP-GWあるいはローカルGWのリロケーションを行う必要性が生じる。しかしながら3GPPで採用されたリロケーション手順では、通信の継続性は確保されない。MME300はC-Planeを処理するノードであり、ユーザデータが転送されるパスU-Plane上にはなく、どのようなユーザデータがどれくらい流れているといった通信状況を知ることができない。このために、MME300は、重要な通信を行っている場合など実際の通信状況を考慮したリロケーションを行うことができない。また、特許文献1に開示された方法では、移転先のGWの負荷状況に応じてリロケーションを実行するか否かを判定するものであり、経路を変更する通信の重要性を考慮したリロケーション制御方法を教示するものではない。すなわち、重要な通信であるかどうかに関係なく、移転先のGWの負荷状況だけをリロケーション実行の判定基準としているので、音声通話などの重要通信中のサービス途絶を回避できない。そこで本発明の目的は、ユーザのサービス利用体感を損なうことなく適切なタイミングでリロケーションを実行可能な制御方法および装置ならびにシステムを提供することにある。本発明によるリロケーション制御装置は、移動通信システムにおいて移動端末に移動性を確保するためのアンカとしての機能を提供するパケット網ゲートウェイのリロケーションを制御するリロケーション制御装置であって、前記リロケーションの契機が発生したときに、前記移動端末と前記パケット網ゲートウェイとの間の通信の重要度およびその使用状況を得るための情報を取得する情報取得手段と、前記通信の重要度およびその使用状況に基づいて前記リロケーションの実行の可否を判定するリロケーション判定手段と、を有することを特徴とする。本発明によるリロケーション制御方法は、移動通信システムにおいて移動端末に移動性を確保するためのアンカとしての機能を提供するパケット網ゲートウェイのリロケーションを制御する方法であって、前記移動通信システムの移動管理ノードが、前記リロケーションの契機が発生したときに、前記移動端末と前記パケット網ゲートウェイとの間の通信の重要度およびその使用状況に基づいて前記リロケーションの実行の可否を判定することを特徴とする。本発明によれば、ユーザのサービス利用体感を損なうことなく適切なタイミングでリロケーションを実行することができる。以下詳述するように、本発明の各実施形態によるリロケーション制御装置は移動通信システムの制御信号を処理する移動管理ノードに配置され、ここでは3GPPで標準化されたEPSにおける移動通信システムのMME移動管理装置に実装される。移動通信システムの全体的構成は図1に示すものと基本的に同じである。以下、リロケーション前の通信経路上の無線基地局、アクセス網GWおよびパケット網GWを各参照番号にサフィックスaを付加して表し、リロケーション後の通信経路上のそれらを各参照番号にサフィックスbを付加して表すものとする。1.第1実施形態1.1システム構成図4に示すように、本発明を適用する移動通信システムは、図1において既に説明したように、コアネットワーク10、アクセスネットワーク20、外部IPネットワーク30およびインターネット40と、アクセスネットワーク20に接続する移動可能な移動端末50とにより構成されるものとする。なお、図1において説明したローカルGWを含んでもよい。移動端末50は、現在、無線基地局600aに接続し、移動端末50とパケット網GW100aとの間にアクセス網GW201aを介してユーザデータ伝送用のパスベアラが設定されており、このデータパスを通して外部IPネットワーク30やインターネット40により提供されるサービスを利用しているものとする。後述するように、アクセス網GW201aは当該ベアラの使用状況をモニタし、要求に応じてモニタ情報をMME301aへ送信する。この移動端末50が移動することで他の無線基地局600bに接続すると、MME301は、後述するようにモニタされたベアラ使用状況に基づいて、パケット網GW100bへのリロケーション処理を実行するか否かを判断する。リロケーション処理を実行しない場合には、移動端末50とパケット網GW100aとの間にアクセス網GW201aおよび無線基地局600bを介してユーザデータ伝送用のパスベアラが設定される。一方、リロケーション処理を実行することで、移動端末50とパケット網GW100bとの間に無線基地局600bおよびアクセス網GW201bを介したユーザデータ伝送用のパスベアラが設定される。こうして設定されたデータパスを通して移動端末50は、外部IPネットワーク30やインターネット40により提供されるサービスを再度利用することができる。なお、パケット網GW100aのリロケート前に開始していた通信については、従来例で示したように、継続利用はできない。1.2ベアラ情報の収集本実施形態におけるアクセス網GW201a、201bは、通常のアクセス網GW機能の他に、ベアラ使用状況収集部211、ベアラ情報要求処理部212および記録部213からなる機能を有する。ベアラ使用状況収集部211は、移動端末50のPDNconnectionに属する各ベアラを通過するユーザデータのパケット情報を収集し、少なくとも次のいずれか一つの情報を生成する。送受信されたパケットの最新検出時間単位時間例えば1秒あたりのパケット送信数および受信数単位時間例えば1秒あたりのパケット送信ビットレートおよび受信ビットレートTCPセッションの有無以下、これらの情報をまとめて通信状況情報と呼ぶ。なお、通信状況情報には、上記したもの以外を含むこととしても良い。例えば、上記した情報に基づき使用/不使用を判定し、この判定結果を通信状況情報としても良い。また、ベアラ単位よりも細かい粒度での通信状況情報を生成しても良い。例えば、ベアラ上を流れるIPパケットのアドレスやポート番号といった情報を用いて特定のアプリケーションや特定のアドレス単位での通信状況情報としても良い。ベアラ使用状況収集部211は、さらに、定期的あるいはパケット検出のタイミングで、移動端末50の端末識別子ユーザ識別子でも良いが、ここではそれも含めて端末識別子と表現するとベアラ識別子とを対応づけて、収集された通信状況情報を記録部213にたとえばテーブル形式で記録する。ベアラ情報要求処理部212は、MME301からベアラ情報要求信号を受信すると、当該信号に含まれている端末識別子およびベアラ識別子をキーとして記録部213に記録された通信状況情報テーブルを検索して対応する通信状況情報を取得する検索機能と、取得した通信状況情報をベアラ情報応答信号に格納してMME301へ返送する応答機能と、を備える。図5に示すように、通信状況情報は例えばテーブル形式で記録部213に記録される。ここで、移動端末50の識別子としては、例えばIMSI、MEIdentityあるいはMSISDNが使用できる。なお、アクセス網GW201aが移動端末50を識別できる他の情報を保持している場合には、これら以外の識別子を用いることもできる。ベアラ識別子としてはEPSBearerIDが使用できる。EPSBearerIDは端末識別子と共に使用することで、ベアラを一意に特定できる。ただし、特定の移動端末の特定のベアラを一意に識別できるのであれば、TEIDなど他の識別情報を用いても構わない。また、上述したように、より細かい粒度で通信状況情報を収集した場合は、その粒度での通信状況情報を識別するための情報を使用する。記録部213に保存された通信状況情報テーブルは、ベアラ使用状況収集部211により更新され、ベアラ情報要求処理部212により読み出される。図5において、IMSInは移動端末nの識別子である。BearerIDmは端末識別子IMSInで識別される移動端末の特定のベアラmの識別子である。ConnInfoSetnmは移動端末識別子およびベアラ識別子により一意に特定されるベアラについての通信状況情報を示す。当該通信状況情報は1つないしは複数の通信状況を示す情報のセットとして記録される。なお、ベアラ使用状況収集部211およびベアラ情報要求処理部212はハードウェアにより実現することもできるが、同等の機能は、CPU等のプログラム制御プロセッサ上で図示しないメモリに格納されたプログラムを実行することにより実現することもできる。1.3MME本実施形態によるMME301は、図4に示すように、既存のMMEが有する制御機能に加えて、ベアラ情報取得部311、リロケーション判定部312およびリロケーション実行部313からなる機能を有する。ベアラ情報取得部311は、移動端末50が移動した結果、その時点でアンカとなっているパケット網GW100aよりも適切なパケット網GW100bが検出された場合、この移動端末50がPDNconnectionを確立している経路上のアクセス網GW201aに対し、PDNconnectionに属する各ベアラの実際の使用状況を問い合わせる。具体的には、当該PDNconnectionに属する各ベアラ識別子および端末識別子の情報を格納したベアラ情報要求信号をアクセス網GW201aへ送信し、その応答となるベアラ情報応答信号を受信することで通信状況情報を取得する。移動端末50がPDNconnectionを確立している相手がローカルGW500である場合は、ここでのベアラ情報要求はローカルGW500厳密にはローカルGW500内のアクセス網GW機能に対して送信される。なお、より適切なパケット網GW100bローカルGW500の場合も含む。を検出する機能は既存のものであればよく、本実施形態では特に限定されない。詳細は省略するが、移動端末50の位置がわかる情報例えば、無線基地局の識別子あるいは無線基地局の集合の識別子と、その地理的もしくはネットワークトポロジ的に近傍となるパケット網GW100bあるいはローカルGW500の識別子IPアドレスなどを通信システム内に保持していれば良い。また、検出を行う契機としては、当該MME301が移動端末50が自らの位置情報を通知するための信号であるTAUを受信した時となるが、その他の契機としても構わない。ベアラ情報要求信号には、移動端末50の識別子および通信状況情報の取得対象であるベアラ識別子が格納される。移動端末50が確立しているベアラのベアラ識別子は、図1で説明したように移動端末50の処理時にMME301に設定される。ベアラ単位より小さい粒度で通信状況情報を収集する場合は、その粒度を識別可能な情報をさらに格納しても良い。また、当該移動端末50についての全てのベアラの通信状況情報を取得する場合は、移動端末50の識別子のみを入れることとしても構わない。リロケーション判定部312は、ベアラ情報取得部311で取得した移動端末50の各ベアラの通信状況情報を用いて重要な通信が実際に使用されている否かを判定し、移動端末50がアンカとするパケット網GW100aのリロケーションを実行するかどうかを判断する。ここで重要な通信とは、たとえば音声会話やライブストリーミングのようなサービス途絶を回避することが望ましい通信をいう。リロケーションを実行すると判定された場合は、既に述べた図2あるいは図3で示した手順によりリロケーションが実施される。なお、MMEは、各ベアラの重要性QCIの手がかりを持っているが、そのベアラが実際に使われているかどうかは分からない。そこで、当該ベアラが実際に使われているかどうかの手がかりとして通信状況情報をアクセス網GWから取得する。ただし、同じベアラを通る通信つまり同じQCIの中にも重要度の高い低いがあるので、通信状況情報を用いて重要な通信の識別を行うこともできる。例えば、インターネット向けのベアラはQCIは低いレベルベストエフォートに設定されると思われるが、インターネット向けのトラフィックにもスカイプ登録商標のようにサービス途絶の回避が望ましい音声サービスもあれば、単なるWEBアクセスのように通信の継続TCPセッションの継続が重要でない通信もある。リロケーション実行部313は、図2に示すMMErequestedPDNdisconnection手順もしくは図3に示すMMEinitiatedDetach手順によるリロケーションを実行する。この機能は既存のMME300とほぼ同様である。ただし、図2に示すMMErequestedPDNdisconnection手順の場合はステップ7のDeactivationBearerRequestに、図3のMMEinitiatedDetach手順の場合はステップ1のDetachRequestに、それぞれリロケーションを意図していることを通知する情報例えば、Relocationを設定する。既に述べたように、図2の手順は、一度移動端末のPDNconnectionを終了し再度PDNconnectionを確立する際に、より適切なパケット網GW100を割当てる処理となる。また、図3の手順は、一度移動端末を切断した後に再接続する際に、より適切なパケット網GW100を割当てる処理となる。つまり、いずれの場合も一度論理的なデータパスであるベアラが失われる。こういった場合でも、移動端末50に対し、リロケーションを意図した一時的なベアラ喪失であることを通知できれば、移動端末50で動作するアプリケーションレベルでユーザに対してサービス途絶を隠蔽することが可能となる。なお、ベアラ情報取得部311、リロケーション判定部312およびリロケーション実行部313はハードウェアにより実現することもできるが、同等の機能は、CPU等のプログラム制御プロセッサ上で図示しないメモリに格納されたプログラムを実行することにより実現することもできる。1.4リロケーション制御図6~図8を参照しながら、本実施形態によるリロケーション制御動作について詳細に説明する。図6において、アクセス網GW201aのベアラ使用状況収集部211は、定期的あるいはパケット検出のタイミングで、移動端末50の端末識別子とベアラ識別子とを対応づけて通信状況情報を記録部213に記録しているステップS400。移動端末50の移動などに起因するTAU受信などを契機として、移動端末50にとってより適切なパケット網GW100bが検出されると、MME301はパケット網GWのリロケーションを実施するかどうかの判定プロセスを開始するステップS401。まず、ベアラ情報取得部311は、アクセス網GW201aに対してベアラ情報要求を送信するステップS402。ベアラ情報要求には、移動端末50の識別子、移動端末50とパケット網GW100aとの間で確立している1つないしは複数のベアラ識別子が格納される。ただし、前述したとおり移動端末50の識別子だけでも良いし、より小さい粒度での通信状況情報識別のために他の情報を格納することとしても良い。ベアラ情報要求を送信すると、ベアラ情報取得部311はアクセス網GW201aからの応答を待つ。アクセス網GW201aのベアラ情報要求処理部212は、ベアラ情報要求を受信すると、そのベアラ情報要求に格納された端末識別子やベアラ識別子を用いて、記録部213に記録された通信状況情報テーブルを検索し、対応する通信状況情報を取得するステップS403。移動端末50が確立している各ベアラの通信状況情報を取得すると、ベアラ情報要求処理部212は当該通信状況情報をベアラ情報応答に格納し、ベアラ情報要求に対する応答としてMME301へ返信するステップ404。ベアラ情報応答を受信すると、MME301のベアラ情報取得部311は移動端末50が確立している各ベアラの通信状況情報をリロケーション判定部312へ出力し、リロケーション判定部312がリロケーションを実行すべきか否かを判定するステップ405。パケット網GWのリロケーションを実行する場合には、リロケーション実行部313が図2に示すMMErequestedPDNdisconnection手順もしくは図3に示すMMEinitiatedDetach手順によりパケット網GW100aからパケット網GW100bへのリロケーションを実行する。その際、上述したように、移動端末50に対し、リロケーションを意図した一時的なベアラ喪失であることを通知できれば、移動端末50で動作するアプリケーションレベルでユーザに対してサービス途絶を隠蔽することが可能となる。次に、図7および図8を参照しながら、MME301のリロケーション判定部312の判定処理をより詳細に説明する。なお、図7のステップS401、S402、S404-S406は、図6と同じステップであるから同じ参照記号を用いている。リロケーション判定ステップS405において、リロケーション判定部312は、ベアラ情報取得部311から受け取った通信状況情報からベアラの重要度およびその使用状況を推測可能な情報を収集し、この情報に基づいて重要なベアラが使用されているか否かを判定するステップS501。重要なベアラが使用されていなければステップS501:NO、リロケーションが許可されステップS502、上述したリロケーションが実行されるステップS406。重要なベアラが使用されていればステップS501:YES、リロケーションが禁止されるステップS504。ベアラの重要度を示す情報としては通信品質プロファイル、例えば3GPPで定義されたQCI、を用いることができる。QCIはベアラ上の通信に求められる通信品質を示す識別子であり、MME301が保持しているQCIの詳細については非特許文献2の30ページ、Table6.1.7を参照。図8に示すように、ベアラの重要度判定にQCIを利用する場合、QCI=1~4はGBR、つまり帯域が保障された通信なので重要なベアラと考えられる。また、QCI=5、7についても、IMSsignalingやライブストリーム、対話型ゲーミングがアプリケーション例として示されているので、サービス途絶を回避すべき通信とみなすのが妥当である。そこで、QCI=1~5、7であれば重要ベアラと判定することができる。また、ベアラの重要度判定にGBRなど他の情報を用いることもできるし、それらを組み合わせることも可能である。たとえば図8において、リソースタイプがGRBであれば重要ベアラと判定する。これはQCI=1~4に相当するので、QCIのしきい値として4を設定し、QCIが4以下の時を重要ベアラと判定することもできる。さらに、通信状況情報に含まれるIPアドレスやTCPあるいはUDPのポート番号などから重要度を推測することとしても良い。この場合は、通信状況情報は、実際の通信状況のみならず、重要度の判定そのものにも利用されることとなる。1.5効果上述したように、本発明の第1実施形態によれば、リロケーション元のアクセス網GW201aにおいて移動端末50の通信使用状況を収集しておき、リロケーションを開始する前にMME301が当該ベアラの重要度に基づいてリロケーション実行の可否を判定する。これにより音声通話やライブストリーミングなどの重要通信中のサービス途絶を回避することができ、ユーザのサービス享受感の劣化を抑制することが可能となる。また、リロケーション処理を実施するかどうかを判定する際に移動端末が行っている通信の重要度を考慮にいれることができるので、たとえばベストエフォート型の通信が行われている場合のみリロケーションを実施するなど、適切なタイミングでのリロケーションの実行が可能となる。2.第2実施形態2.1システム構成本発明の第2実施形態では、MMEがベアラの使用状況をアクセス網GWではなく無線基地局から取得する点が上記第1実施形態と異なっている。図9において、無線基地局601a、601bは、通常の無線基地局が有する機能に加え、ベアラ使用状況収集部611、ベアラ情報要求処理部612および記録部613を備えた構成となる。ベアラ使用状況収集部611は図4におけるベアラ使用状況収集部211に、ベアラ情報要求処理部612は図4におけるベアラ情報要求処理部212に、記録部613は図4における記録部213にそれぞれ対応し、それぞれ同様の機能を有するので詳細な説明は省略する。またMME302は、既存のMMEが有する制御機能に加えて、ベアラ情報取得部311、リロケーション判定部312およびリロケーション実行部313からなる機能を有し、ベアラ情報要求信号およびベアラ情報応答信号を送受信する相手ノードが異なる点を除けば、図4に示すMME301と同様の機能であるから同一の参照番号を付して説明は省略する。2.2リロケーション制御本実施形態におけるMME302は、ベアラ情報要求信号およびベアラ情報応答信号を送受信する相手ノードがアクセス網GWではなく無線基地局601aである点が第1実施形態におけるMME301と異なる。図10において、無線基地局601aのベアラ使用状況収集部611は、定期的あるいはパケット検出のタイミングで、移動端末50の端末識別子とベアラ識別子とを対応づけて通信状況情報を記録部613に記録しているステップS700。移動端末50の移動などに起因するTAU受信などを契機として、移動端末50にとってより適切なパケット網GW100bが検出されると、MME302はパケット網GWのリロケーションを実施するかどうかの判定プロセスを開始するステップS401。まず、ベアラ情報取得部311は、無線基地局601aに対してベアラ情報要求を送信するステップS701。ベアラ情報要求には、移動端末50の識別子、移動端末50とパケット網GW100aとの間で確立している1つないしは複数のベアラ識別子が格納される。ただし、前述したとおり移動端末50の識別子だけでも良いし、より小さい粒度での通信状況情報識別のため他の情報を格納することとしても良い。ベアラ情報要求を送信すると、ベアラ情報取得部311は無線基地局601aからの応答を待つ。無線基地局601aのベアラ情報要求処理部612は、ベアラ情報要求を受信すると、ベアラ情報要求に格納された端末識別子やベアラ識別子を用いて、記録部613に記録された通信状況情報テーブルを検索し、対応する通信状況情報を取得するステップS702。移動端末50が確立している各ベアラの通信状況情報を取得すると、ベアラ情報要求処理部612は当該通信状況情報をベアラ情報応答に格納し、ベアラ情報要求に対する応答としてMME302へ返信するステップ703。ベアラ情報応答を受信すると、MME302のベアラ情報取得部311は移動端末50が確立している各ベアラの通信状況情報をリロケーション判定部312へ出力し、リロケーション判定部312がリロケーションを実行すべきか否かを判定するステップ405。パケット網GWのリロケーションを実行する場合には、リロケーション実行部313が図2に示すMMErequestedPDNdisconnection手順もしくは図3に示すMMEinitiatedDetach手順によりパケット網GW100aからパケット網GW100bへのリロケーションを実行する。その際、上述したように、移動端末50に対し、リロケーションを意図した一時的なベアラ喪失であることを通知できれば、移動端末50で動作するアプリケーションレベルでユーザに対してサービス途絶を隠蔽することが可能となる。MME302のリロケーション判定部312の判定処理は、図7および図8で説明した判定処理と同様であるから説明は省略する。2.3効果上述したように、本発明の第2実施形態によれば、移動端末50の移動する前に接続していた無線基地局601aが当該移動端末50の通信使用状況を収集して記録しておき、リロケーションを開始する前にMME302がベアラの重要度およびその使用状況に基づいてリロケーション実行の可否を判定する。これにより、第1実施形態と同様に、音声通話やライブストリーミングなどの重要通信中のサービス途絶を回避することができ、ユーザのサービス享受感の劣化を抑制することが可能となる。また、リロケーション処理を実施するかどうかを判定する際に移動端末が行っている通信の重要度およびその使用状況を考慮にいれることができるので、たとえばベストエフォート型の通信が行われている場合のみリロケーションを実施するなど、適切なタイミングでのリロケーションの実行が可能となる。さらに、本実施形態では無線基地局がベアラ使用状況を収集するので、アクセス網GWよりも処理の集中を回避できるという利点がある。3.第3実施形態3.1システム構成本発明の第3実施形態では、MMEがベアラの使用状況をパケット網GWから取得する点が上記第1および第2実施形態と異なっている。図11において、パケット網GW101a、101bは、通常のパケット網GW100の有する機能に加え、ベアラ使用状況収集部111、ベアラ情報要求処理部112および記録部113を備えた構成となる。ベアラ使用状況収集部111は図4におけるベアラ使用状況収集部211に、ベアラ情報要求処理部112は図4におけるベアラ情報要求処理部212に、記録部113は図4における記録部213にそれぞれ対応し、それぞれ同様の機能を有するので詳細な説明は省略する。アクセス網GW202a、202bは、通常のアクセス網GW200の有する機能を有するが、本実施形態ではベアラ情報要求転送部231の機能を更に有する。またMME301は、既存のMMEが有する制御機能に加えて、ベアラ情報取得部311、リロケーション判定部312およびリロケーション実行部313からなる機能を有し、ベアラ情報要求信号およびベアラ情報応答信号を送受信する相手ノードが異なる点を除けば、図4に示すMME301と基本的機能は同じであるから同一の参照番号を付して説明は省略する。3.2リロケーション制御本実施形態におけるMME301は、ベアラ情報をアクセス網GW202aを介してパケット網GW101aから取得する点で第1および第2実施形態におけるMME301と異なる。図12において、パケット網GW101aのベアラ使用状況収集部111は、定期的あるいはパケット検出のタイミングで、移動端末50の端末識別子とベアラ識別子とを対応づけて通信状況情報を記録部113に記録しているステップS800。移動端末50の移動などに起因するTAU受信などを契機として、移動端末50にとってより適切なパケット網GW100bが検出されると、MME301はパケット網GWのリロケーションを実施するかどうかの判定プロセスを開始するステップS401。まず、ベアラ情報取得部311は、パケット網GW101aから当該移動端末50のベアラ情報を取得するために、アクセス網GW202aに対してベアラ情報要求を送信しステップS801、アクセス網GW202aのベアラ情報要求転送部231は当該ベアラ情報要求を宛先のパケット網GW101aへ転送するステップS802。このとき、そのまま転送するのではなく、アクセス網GW202aとパケット網GW101aとの間でプロトコルが異なる場合には、信号形式を適切に変換して送信することとしても良い。ベアラ情報要求には、移動端末50の識別子、移動端末50とパケット網GW101aとの間で確立している1つないしは複数のベアラ識別子が格納される。ただし、前述したとおり移動端末50の識別子だけでも良いし、より小さい粒度での通信状況情報識別のため他の情報を格納することとしても良い。ベアラ情報要求を送信すると、ベアラ情報取得部311はパケット網GW101aからの応答を待つ。パケット網GW101aのベアラ情報要求処理部112は、ベアラ情報要求を受信すると、ベアラ情報要求に格納された端末識別子やベアラ識別子を用いて、記録部113に記録された通信状況情報テーブルを検索し、対応する通信状況情報を取得するステップS803。移動端末50が確立している各ベアラの通信状況情報を取得すると、ベアラ情報要求処理部112は当該通信状況情報をベアラ情報応答に格納し、MME301を宛先としてアクセス網GW202aへ返信するステップ804。アクセス網GW202aのベアラ情報要求転送部231は当該ベアラ情報応答を宛先のMME301へ転送するステップS805。このときも、そのまま転送するのではなく、アクセス網GW202aとパケット網GW101aとの間でプロトコルが異なる場合には、信号形式を適切に変換して送信することとしても良い。ベアラ情報応答を受信すると、MME301のベアラ情報取得部311は移動端末50が確立している各ベアラの通信状況情報をリロケーション判定部312へ出力し、リロケーション判定部312がリロケーションを実行すべきか否かを判定するステップ405。パケット網GWのリロケーションを実行する場合には、リロケーション実行部313が図2に示すMMErequestedPDNdisconnection手順もしくは図3に示すMMEinitiatedDetach手順によりパケット網GW101aからパケット網GW101bへのリロケーションを実行する。その際、上述したように、移動端末50に対し、リロケーションを意図した一時的なベアラ喪失であることを通知できれば、移動端末50で動作するアプリケーションレベルでユーザに対してサービス途絶を隠蔽することが可能となる。MME301のリロケーション判定部312の判定処理は、図7および図8で説明した判定処理と同様であるから説明は省略する。上述したように、本実施形態では、ベアラ情報要求信号およびベアラ情報応答信号をやりとりする相手がアクセス網GW202aを介したパケット網GW101aとなる。ベアラ情報要求信号の送信先をアクセス網GW202aとするかパケット網GW101aとするかについては、モバイル網のオペレータ依存でどちらを選択しても良いが、3GPP標準化において、MMEとパケット網GWとの間のインタフェースは規定されていない点から考慮すると、MME301はベアラ情報要求信号をアクセス網GW202aに送信し、アクセス網GW202aが当該信号を必要に応じて信号形式を変換した後にパケット網GW101aに送信する方が適用しやすいといえる。3.3効果上述したように、本発明の第3実施形態によれば、リロケーション元のアクセス網GW201aにおいて移動端末50の通信使用状況を収集しておき、リロケーションを開始する前にMME301が当該ベアラの重要度およびその使用状況に基づいてリロケーション実行の可否を判定する。これにより音声通話やライブストリーミングなどの重要通信中のサービス途絶を回避することができ、ユーザのサービス享受感の劣化を抑制することが可能となる。また、リロケーション処理を実施するかどうかを判定する際に移動端末が行っている通信の重要度およびその使用状況を考慮にいれることができるので、たとえばベストエフォート型の通信が行われている場合のみリロケーションを実施するなど、適切なタイミングでのリロケーションの実行が可能となる。さらに、本実施形態ではコアネットワーク10内にあるパケット網GWおよびMMEによりリロケーション制御が可能となり、アクセスネットワーク20のノードを変更する必要がないので設備変更が容易になるという利点がある。4.第4実施形態4.1システム構成本発明の第4実施形態では、MMEがベアラの使用状況をアクセス網GWを介することなくパケット網GWから直接取得する点が上記第3実施形態と異なっている。図13に示すように、パケット網GW101a、101bは、第3実施形態におけるパケット網GWと同じであるが、アクセス網GW200a、200bは通常のアクセス網GW機能を有しておりベアラ情報要求転送機能は不要である。またMME301は、既存のMMEが有する制御機能に加えて、ベアラ情報取得部311、リロケーション判定部312およびリロケーション実行部313からなる機能を有し、ベアラ情報要求信号およびベアラ情報応答信号を送受信する相手ノードが異なる点を除けば、図4に示すMME301と基本的機能は同じであるから同一の参照番号を付して説明は省略する。4.2リロケーション制御本実施形態におけるMME301は、ベアラ情報をパケット網GW101aから直接取得する点で第3実施形態におけるMME301と異なる。図14において、パケット網GW101aのベアラ使用状況収集部111は、定期的あるいはパケット検出のタイミングで、移動端末50の端末識別子とベアラ識別子とを対応づけて通信状況情報を記録部113に記録しているステップS900。移動端末50の移動などに起因するTAU受信などを契機として、移動端末50にとってより適切なパケット網GW100bが検出されると、MME301はパケット網GWのリロケーションを実施するかどうかの判定プロセスを開始するステップS401。まず、ベアラ情報取得部311は、パケット網GW101aに対してベアラ情報要求を送信するステップS901。ベアラ情報要求には、移動端末50の識別子、移動端末50とパケット網GW101aとの間で確立している1つないしは複数のベアラ識別子が格納される。ただし、前述したとおり移動端末50の識別子だけでも良いし、より小さい粒度での通信状況情報識別のため他の情報を格納することとしても良い。ベアラ情報要求を送信すると、ベアラ情報取得部311はパケット網GW101aからの応答を待つ。パケット網GW101aのベアラ情報要求処理部112は、ベアラ情報要求を受信すると、ベアラ情報要求に格納された端末識別子やベアラ識別子を用いて、記録部113に記録された通信状況情報テーブルを検索し、対応する通信状況情報を取得するステップS902。移動端末50が確立している各ベアラの通信状況情報を取得すると、ベアラ情報要求処理部112は当該通信状況情報をベアラ情報応答に格納し、MME301へ返信するステップ903。ベアラ情報応答を受信すると、MME301のベアラ情報取得部311は移動端末50が確立している各ベアラの通信状況情報をリロケーション判定部312へ出力し、リロケーション判定部312がリロケーションを実行すべきか否かを判定するステップ405。パケット網GWのリロケーションを実行する場合には、リロケーション実行部313が図2に示すMMErequestedPDNdisconnection手順もしくは図3に示すMMEinitiatedDetach手順によりパケット網GW101aからパケット網GW101bへのリロケーションを実行する。その際、上述したように、移動端末50に対し、リロケーションを意図した一時的なベアラ喪失であることを通知できれば、移動端末50で動作するアプリケーションレベルでユーザに対してサービス途絶を隠蔽することが可能となる。MME301のリロケーション判定部312の判定処理は、図7および図8で説明した判定処理と同様であるから説明は省略する。4.3効果上述したように、本発明の第4実施形態によれば、リロケーション元のアクセス網GW201aにおいて移動端末50の通信使用状況を収集しておき、リロケーションを開始する前にMME301が当該ベアラの重要度およびその使用状況に基づいてリロケーション実行の可否を判定する。これにより音声通話やライブストリーミングなどの重要通信中のサービス途絶を回避することができ、ユーザのサービス享受感の劣化を抑制することが可能となる。また、リロケーション処理を実施するかどうかを判定する際に移動端末が行っている通信の重要度およびその使用状況を考慮にいれることができるので、たとえばベストエフォート型の通信が行われている場合のみリロケーションを実施するなど、適切なタイミングでのリロケーションの実行が可能となる。さらに、本実施形態ではコアネットワーク10内にあるパケット網GWおよびMMEによりリロケーション制御が可能となり、アクセスネットワーク20のノードを変更する必要がないので設備変更が容易になるという利点に加えて、アクセス網GWの負荷を軽減できるという利点もある。5.他の実施形態上述した各実施形態におけるベアラ使用状況の記録部213、613、113は、例えば半導体メモリ、ハードディスクドライブなど情報を記録可能な装置で実現することができる。その他の機能ブロックは、ソフトウェアおよびそれを動作させるためのCPU、あるいはハードウェアで実施できる。一部をソフトウェアで実施し、それ以外をハードウェアで実施することとしても良い。上記各実施形態における各ノードと3GPPで定義されているノードとの対応については以下の通りである。パケット網GWは3GPPにおけるパケットデータ網ゲートウェイもしくはGGSNSupportNodeに対応する。アクセス網GWは主ゲートウェイもしくはSGSNに対応する。移動管理ノードMMEは3GPPで定義されているMMEに対応する。無線基地局は3GPPで定義されているeNodeBあるいはRNCとNodeBのセットに対応する。6.付記上述した実施形態の一部あるいは全部は、以下の付記のようにも記載されうるが、これらに限定されるものではない。付記1移動通信システムにおいて移動端末に移動性を確保するためのアンカとしての機能を提供するパケット網ゲートウェイのリロケーションを制御するリロケーション制御装置であって、前記リロケーションの契機が発生したときに、前記移動端末と前記パケット網ゲートウェイとの間の通信の重要度およびその使用状況を得るための通信状況情報を取得する情報取得手段と、前記通信の重要度およびその使用状況に基づいて前記リロケーションの実行の可否を判定するリロケーション判定手段と、を有することを特徴とするリロケーション制御装置。付記2前記情報取得手段は、前記移動端末と前記パケット網ゲートウェイとの間で確立している1以上の論理的データパスに割り当てられた通信品質プロファイルから前記通信の重要度を決定することを特徴とする付記1に記載のリロケーション制御装置。付記3前記情報取得手段は、前記通信状況情報を当該論理的データパス上にあるノードから取得することを特徴とする付記1または2に記載のリロケーション制御装置。付記4当該論理的データパス上にあるノードは、前記移動通信システムにおけるアクセス網ゲートウェイ、無線基地局または前記パケット網ゲートウェイのいずれかであることを特徴とする付記3に記載のリロケーション制御装置。付記5前記リロケーション判定手段は、通信途絶を回避すべき通信を重要通信として選択することを特徴とする付記1-4のいずれか1項に記載のリロケーション制御装置。付記6前記移動通信システムは3GPPにおいて標準化されたEPSであることを特徴とする付記1-5のいずれか1項に記載のリロケーション制御装置。付記7移動通信システムにおいて移動端末に移動性を確保するためのアンカとしての機能を提供するパケット網ゲートウェイのリロケーションを制御する方法であって、前記移動通信システムの移動管理ノードが、前記リロケーションの契機が発生したときに、前記移動端末と前記パケット網ゲートウェイとの間の通信の重要度およびその使用状況に基づいて前記リロケーションの実行の可否を判定することを特徴とするリロケーション制御方法。付記8前記移動管理ノードが、前記移動端末と前記パケット網ゲートウェイとの間で確立している1以上の論理的データパスに割り当てられた通信品質プロファイルを参照して前記通信の重要度を決定することを特徴とする付記7に記載のリロケーション制御方法。付記9前記移動管理ノードが、前記1以上の論理的データパスの通信状況情報を当該論理的データパス上にあるノードから取得することを特徴とする付記8に記載のリロケーション制御方法。付記10当該論理的データパス上にあるノードは、前記移動通信システムにおけるアクセス網ゲートウェイ、無線基地局または前記パケット網ゲートウェイのいずれかであることを特徴とする付記3に記載のリロケーション制御方法。付記11前記移動管理ノードが、通信途絶を回避すべき通信を重要通信として選択することを特徴とする付記7-10のいずれか1項に記載のリロケーション制御方法。付記12前記移動通信システムは3GPPにおいて標準化されたEPSであることを特徴とする付記7-11のいずれか1項に記載のリロケーション制御方法。付記13付記1-6のいずれか1項に記載のリロケーション制御装置を備えた移動管理ノード。付記14付記13に記載の移動管理ノードを有する移動通信システム。付記15付記14に記載の移動通信システムにおけるアクセス網ゲートウェイであって、定期的あるいはパケット検出時に前記通信状況情報を収集する通信状況収集手段と、前記通信状況情報を所定の形式で格納する格納手段と、前記情報取得手段からの要求に応じて前記通信状況情報を送信する要求処理手段と、を有することを特徴とするアクセス網ゲートウェイ。付記16付記14に記載の移動通信システムにおけるパケット網ゲートウェイであって、定期的あるいはパケット検出時に前記通信状況情報を収集する通信状況収集手段と、前記通信状況情報を所定の形式で格納する格納手段と、前記情報取得手段からの要求に応じて前記通信状況情報を送信する要求処理手段と、を有することを特徴とするパケット網ゲートウェイ。付記17付記14に記載の移動通信システムにおける無線基地局であって、定期的あるいはパケット検出時に前記通信状況情報を収集する通信状況収集手段と、前記通信状況情報を所定の形式で格納する格納手段と、前記情報取得手段からの要求に応じて前記通信状況情報を送信する要求処理手段と、を有することを特徴とする無線基地局。付記18移動通信システムにおいて移動端末に移動性を確保するためのアンカとしての機能を提供するパケット網ゲートウェイのリロケーションを制御するようにプログラム制御プロセッサを機能させるプログラムであって、情報取得手段が、前記リロケーションの契機が発生したときに、前記移動端末と前記パケット網ゲートウェイとの間の通信の重要度およびその使用状況を得るための通信状況情報を取得し、リロケーション判定手段が前記重要度およびその使用状況に基づいて前記リロケーションの実行の可否を判定する、ように前記プログラム制御プロセッサを機能させることを特徴とするプログラム。付記19前記情報取得手段は、前記移動端末と前記パケット網ゲートウェイとの間で確立している1以上の論理的データパスに割り当てられた通信品質プロファイルから前記通信の重要度を決定することを特徴とする付記14に記載のプログラム。付記20前記情報取得手段は、前記通信状況情報を当該論理的データパス上にあるノードから取得することを特徴とする付記18または19に記載のプログラム。付記21当該論理的データパス上にあるノードは、前記移動通信システムにおけるアクセス網ゲートウェイ、無線基地局または前記パケット網ゲートウェイのいずれかであることを特徴とする付記20に記載のプログラム。付記22前記リロケーション判定手段は、通信途絶を回避すべき通信を重要通信として選択することを特徴とする付記18-21のいずれか1項に記載のプログラム。