JP2013219524A - ネットワークノード及び通信端末 - Google Patents

Abstract

【課題】データ通信のために利用されるコネクションに対してゲートウェイの切り替えを実行できるようにする。
【解決手段】ネットワーク（例えば、ＭＭＥ２２０）が、ＵＥ（通信端末）１００のコネクションに対してゲートウェイの切り替えが必要であると判断した場合（ステップＳ２００３）、ＵＥがデータ通信を開始すると判断できるタイミングでゲートウェイの切り替え処理を開始する。例えば、ＭＭＥは、ＵＥ宛のトリガリクエストを受けた際に、トリガメッセージの通知と共に、切り替え前のゲートウェイ（ＳＧＷ１／ＰＧＷ１）とＵＥとのコネクションを切断することを通知する情報（切断通知）をＵＥに対して送信し（ステップＳ２０１１）、ＵＥがトリガメッセージに応じて開始するデータ通信に利用されるコネクションは、切り替え後のゲートウェイ（ＳＧＷ２／ＰＧＷ２）との間で確立される。
【選択図】図２

Description

本発明は、セルラー通信機能を利用して通信技術に関し、特に、マシン間コミュニケーション（Machine to Machine CommunicationやMachine Type Communicationと呼ばれる。以下、Ｍ２Ｍ通信と記載）の技術を利用して通信を行うネットワークノード及び通信端末に関する。

セルラー通信機能は、携帯電話やスマートフォンなどの音声通話やデータ通信で利用されるだけでなく、Ｍ２Ｍ通信向けの機器（ＭＴＣデバイスとも呼ばれる）でも広く利用されており、ＭＴＣデバイスを含むセルラー通信端末（以下、ＵＥ（User Equipment）又は通信端末と記載する）の数は今後も増加の一途を辿っている。

ＵＥの数が増えることで、オペレータが提供するセルラー通信システムのネットワークにはセッション数の増加やトラフィック量の増加などの負荷が増大し、輻輳などの問題が発生する可能性がある。そのため、ネットワークは、ＵＥとコネクションを確立するゲートウェイ（以下、ＧＷと記載することもある）を切り替える処理（GW relocation）を実行することができる。ゲートウェイ切り替えによって、よりＵＥに近い位置（ロケーション）に存在するゲートウェイや、より負荷の低いゲートウェイへＵＥのコネクションを切り替えることができ、ＵＥが行うデータ通信の状態を適切に保つことができる。

ゲートウェイの切り替えの実行は、ネットワーク内のエンティティ（ＳＧＳＮ／ＭＭＥ（Serving GPRS Support Node/Mobility Management Entity）、以下ＭＭＥ）によって判断される。ゲートウェイの切り替えが必要と判断された場合、ＭＭＥはＵＥに対して、ゲートウェイの切り替えの影響を受けるＰＤＮコネクションの切断を通知し、ＵＥは切断したコネクションを再確立する。ＵＥからコネクションの確立要求を受けたＭＭＥは、切り替え先のゲートウェイに対してコネクションを確立することで、ＵＥとの間のコネクションを管理するゲートウェイの切り替えを実行する。

"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Improvements for Machine-Type Communications", 3GPP TR 23.888, V1.6.0, November 2011. "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Service requirements for machine-type communications", 3GPP TS 22.368, V11.3.1, September 2011. "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture Enhancements to facilitate communications with Packet Data Networks and Applications", 3GPP TS 23.682, V0.2.0, February 2012. "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network", 3GPP TS 23.401, V11.0.0, December 2011.

ネットワークは、ＵＥのロケーションやゲートウェイの状態などに応じてゲートウェイの切り替えが必要と判断した場合、ＵＥに対してコネクションの切断を通知し、コネクションの再確立を要求する。現状のＭＭＥによるゲートウェイの切り替えの要否の判断は、ＵＥがコネクションを利用しているか否かにかかわらず行われるため、利用されていないコネクションに対してもゲートウェイの切り替えが実行されてしまう。このため、再確立されたコネクションが利用されない場合であっても、ゲートウェイの切り替えに伴ってコネクションの再確立が行われるため、不要なシグナリングやネットワークノードの処理が発生してしまうという問題がある。

上記の問題を解決するため、本明細書では、データ通信のために利用されるコネクションに対してゲートウェイの切り替えを実行できるようにする技術が開示される。

上記の目的を達成するため、例えば、本発明の一態様は、通信端末がネットワーク上のゲートウェイとの間で確立しているコネクションを管理するネットワークノードであって、
前記通信端末が前記ゲートウェイとの間で確立しているコネクションに関して、前記ゲートウェイの切り替えを行う必要があるか否かを判断するゲートウェイ切り替え判断部と、
前記通信端末がデータ通信を開始することを検出するデータ通信要求検出部と、
前記ゲートウェイの切り替えを行う必要がある前記通信端末が前記データ通信を開始することを検出した場合に、前記ゲートウェイの切り替えに関する情報を前記通信端末へ送信するゲートウェイ切り替え処理部とを、
有するネットワークノードを含む。

また、上記の目的を達成するため、例えば、本発明の一態様は、ネットワーク上のゲートウェイとの間でコネクションを確立してデータ通信を行う通信端末であって、
前記ゲートウェイとの間で確立している前記コネクションに関して前記ゲートウェイの切り替えを行う必要があると判断され、かつ、前記通信端末が前記データ通信を開始することが前記ネットワークで検出された場合に前記ネットワークから送信される情報であって、前記ゲートウェイの切り替えに関する情報を前記ネットワークから受信する情報受信部を有する通信端末を含む。

本発明の一態様によれば、例えば、データ通信のために利用されるコネクションに対してゲートウェイの切り替えを実行できるようになるという効果が実現される。

本発明の第１の実施の形態におけるネットワーク構成の一例を示す図 本発明の第１の実施の形態におけるＵＥ及びネットワーク、サーバの動作の一例を示すシーケンス図 本発明の第１の実施の形態において、切断通知を受信した際のＵＥの処理の一例を示すフローチャート 本発明の第１の実施の形態において、切断実行要求と共にトリガを送信するためのメッセージの一例を示す図 本発明の第１の実施の形態において、切断通知としてDetach Requestを受信した場合のＵＥの処理を示すフローチャート 本発明の第１の実施の形態において、切断通知としてDeactivate Bearer Context Requestを受信した場合のＵＥの処理を示すフローチャート 本発明の第１の実施の形態において、トリガリクエストを受けた際のＭＭＥの処理の一例を示すフローチャート 本発明の第１の実施の形態において、ゲートウェイ切り替えが必要と判断した際のＭＭＥの処理の一例を示すフローチャート 本発明の第１の実施の形態におけるＵＥの構成の一例を示すブロック図 本発明の第１の実施の形態におけるＭＭＥの構成の一例を示すブロック図 本発明の第２の実施の形態におけるＵＥ及びネットワーク内のエンティティ、ＭＴＣサーバの動作の一例を示すシーケンス図 本発明の第２の実施の形態において、トリガを受信したＵＥの処理の一例を示すフローチャート 本発明の第２の実施の形態において、切断実行要求と共にトリガを送信するためのメッセージの一例を示す図 本発明の第２の実施の形態において、Detach Request相当の切断実行要求を含むトリガを受信した場合のＵＥの処理の一例を示すフローチャート 本発明の第２の実施の形態において、Deactivate Bearer Context Request相当の切断実行要求を含むトリガを受信した場合のＵＥの処理の一例を示すフローチャート 本発明の第２の実施の形態において、トリガリクエストを受けた際のＭＭＥの処理の一例を示すフローチャート 本発明の第３の実施の形態におけるＵＥ及びネットワーク内のエンティティ、ＭＴＣサーバの動作の一例を示すシーケンス図 本発明の第３の実施の形態において、サービス拒絶を受信したＵＥの処理の一例を示すフローチャート 本発明の第３の実施の形態において、サービス要求を受信したＭＭＥの処理の一例を示すフローチャート 本発明の第３の実施の形態において、ＰＤＮコネクション切断リクエストを受信したＵＥの処理の一例を示すフローチャート

以下、図面を参照しながら、本発明の第１〜第３の実施の形態について説明する。

本発明の一態様では、例えば、ネットワークは、ＵＥのコネクションに対してゲートウェイの切り替えが必要であると判断した場合に、ＵＥがデータ通信を開始すると判断できるタイミングでゲートウェイの切り替え処理を開始する。以下に説明する本発明の第１の実施の形態では、ネットワークノード（例えばＭＭＥ）が、ＵＥ宛のトリガリクエストを受けた際に、トリガメッセージの通知と共に、コネクション切断通知をＵＥに対して送信する。さらに、本発明の第２の実施の形態では、ネットワークノード（例えばＭＭＥ）が、ＵＥ宛のトリガリクエストを受けた際に、コネクションの切断実行要求と共にトリガメッセージを通知する。また、本発明の第３の実施の形態では、ネットワークノード（例えばＭＭＥ）が、ＵＥからサービス要求を受けた際に、サービス要求を拒絶することでコネクション切断を通知する。

（第１の実施の形態）
まず、本発明の第１の実施の形態について説明する。図１は、本発明の第１の実施の形態におけるネットワーク構成の一例を示す図である。図１には、セルラー通信端末であるＵＥ１００と、ＵＥ１００が接続する３ＧＰＰネットワーク（セルラーネットワークとも呼ぶ。以下、単にネットワークと記載することもある）２００と、ＵＥ１００と通信を行うサーバ（ＭＴＣサーバ、Service Capability Server (SCS)とも呼ぶ）３００及びアプリケーション（ＭＴＣアプリケーション、Application Serverとも呼ぶ）４００が図示されている。

また、図１には、３ＧＰＰネットワーク２００の構成要素として、３ＧＰＰネットワーク２００とＭＴＣサーバ３００を繋ぐＩＷＦ（Interworking Function）２１０、ＵＥ１００の位置情報（ロケーション）の管理やＵＥ１００の通信制御（回線交換制御又はパケット交換制御）などを行うＭＭＥ／ＳＧＳＮ／ＭＳＣ（Mobility Management Entity/Serving GPRS Support Node/Mobile Switching Center）２２０、ＵＥ１００のコネクション管理や外部ネットワークへのデータ転送、ユーザ認証やＱｏＳ制御などを行うＰ−ＧＷ／ＧＧＳＮ／ｅＰＤＧ（Packet Data Network Gateway/Gateway GPRS Support Node/evolved Packet Data Gateway）２３０、ＵＥ１００が接続（アタッチ）する基地局と３ＧＰＰネットワーク２００内のエンティティ（例えばＰ−ＧＷ）との間のコネクション管理やユーザデータ転送を行うＳ−ＧＷ（Serving Gateway）２４０、ＵＥ１００に対して３ＧＰＰネットワーク２００への接続ポイントを提供する基地局として機能するｅＮＢ／ＮＢ／ＢＳ２５０（evolved Node B/Node B/Base Station）、ユーザのサブスクリプションデータの管理を行うＨＳＳ／ＨＬＲ（Home Subscriber Server/Home Location Register）２６０、ＵＥ１００へＳＭＳを送信する役割を持つＳＭＳ−ＳＣ（Short Message Service-Service Center、又はＧＭＳＣ／ＩＷＭＳＣ）２７０が図示されている。

なお、図１には、３ＧＰＰで規定されている機能を実現するためのネットワーク構成の一例が図示されているが、本発明が適用されるネットワーク構成は図１に図示されているものに限定されるものではない。また、以下の説明では、本発明に係る技術的思想を明確にするため、図１に図示されているＭＭＥ／ＳＧＳＮ／ＭＳＣ２２０をＭＭＥ２２０と記載し、図１に図示されているＰ−ＧＷ／ＧＧＳＮ／ｅＰＤＧ２３０をＰ−ＧＷ２３０と記載することがある。

ＭＴＣサーバ３００は、ＵＥ１００によるデータ通信の開始や制御メッセージの送信を要求するため、ＩＷＦ２１０に対してＵＥ１００宛のトリガメッセージ（以下、トリガと記載することもある）を送信するよう要求する。一方、ＩＷＦ２１０は、ＭＴＣサーバ３００からトリガメッセージの送信要求を受けた場合、ネットワーク２００を介してトリガメッセージをＵＥ１００へ送信する。なお、トリガメッセージを送信する手段としては、ＳＭＳ（Short Message Service）やＮＡＳ（Non-Access Stratum）メッセージなどのＣ−ｐｌａｎｅ（コントロールプレーン）を用いる方法やデータパケットのＵ−ｐｌａｎｅ（ユーザプレーン）を用いる方法など複数あるが、ＩＷＦ２１０はどの手段を選択してもよい。３ＧＰＰネットワーク２００内には、３ＧＰＰの無線ネットワーク及びコアネットワークを構成する複数のエンティティが存在し、ＭＭＥ２２０及びＳＭＳ−ＳＣ２７０は、ＩＷＦ２１０からの要求を受け、Ｃ−ｐｌａｎｅのトリガメッセージをＵＥ１００へ送信する役割を持つ。トリガメッセージとして従来のＳＭＳを用いる場合、ＩＷＦ２１０はＳＭＳ−ＳＣ２７０へトリガメッセージの送信を要求し、ＳＭＳ−ＳＣ２７０はＭＭＥ２２０に対してＳＭＳの送信を要求する。ＭＭＥ２２０は、ＳＭＳ−ＳＣ２７０から受信したＳＭＳをＵＥ１００へ送信する。例えば、ＭＭＥ２２０は、Downlink NAS TransportのNAS message containerにＳＭＳを含めてＵＥ１００へ送信する。一方、ＭＳＣ２２０の場合は、ＳＭＳ専用のメッセージをＵＥ１００へ送信する。

また、トリガメッセージの送信要求（トリガリクエスト）をＭＭＥ２２０へ通知するために、ＩＷＦ２１０は、ＭＭＥ２２０と直接つながっているインタフェースを用いてトリガリクエストを送信することもできる。この場合、ＭＭＥ２２０は、ＩＷＦ２１０からトリガリクエストを受けたら、そのトリガリクエストをＳＭＳのフォーマット形式に変換し、Downlink NAS TransportのNAS message containerに含めてトリガを送信してもよいし、他のフォーマット形式のトリガをＮＡＳメッセージに含めて送信してもよい。

一方、Ｐ−ＧＷ２３０及びＳ−ＧＷ２４０は、ＩＷＦ２１０が生成したＵ−ｐｌａｎｅのトリガメッセージをデータパケットとしてＵＥ１００へ転送する役割を持つ。

以下では、説明を簡略化するため、ＭＴＣサーバ３００がＩＷＦ２１０へトリガメッセージの送信要求（トリガリクエスト）を送信し、そのトリガリクエストがＩＷＦ２１０によって選択された手段を用いてＭＭＥ２２０へ送信され、ＭＭＥ２２０は、ＩＷＦ２１０（又はＳＭＳ−ＳＣ２７０）から受信したトリガリクエストを基に、制御メッセージ（ＮＡＳメッセージ）を用いてトリガメッセージをＵＥ１００へ送信する場合を一例として説明する。なお、ＵＥ１００との間でアプリケーションレイヤの通信を行うＭＴＣアプリケーション４００はＭＴＣサーバ３００上で動作してもよいし、ＭＴＣサーバ３００と接続された他のノード上で動作してもよい。ＭＴＣサーバ３００は自らの判断、又はＭＴＣアプリケーション４００の指示を受けてトリガリクエストを送信する。また、ＭＴＣサーバ３００は３ＧＰＰネットワーク２００内に配置されてもよい。

ＵＥ１００はトリガメッセージを受けると、必要に応じて制御メッセージを送信し、３ＧＰＰネットワーク２００との間でコネクションの確立や変更などの処理を実行する。このとき送信される制御メッセージとしては、例えば、接続要求（ATTACH REQUEST）や切断要求（DETACH REQUEST）、サービス要求（SERVICE REQUEST）、ＰＤＮコネクション確立要求（PDN CONNECTIVITY REQUEST）、専用ベアラ確立要求（ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST）、ベアラリソース割り当て要求（BEARER RESOURCE ALLOCATION REQUEST）、ベアラリソース変更要求（BEARER RESOURCE MODIFICATION REQUEST）などがあるが、どの制御メッセージを送信するべきかについては、トリガメッセージの対象となるアプリケーションの種類やアプリケーションの状態、トリガメッセージを受けた際のＵＥ１００の接続状況などに基づいて判断される。例えば、トリガメッセージを受けたアプリケーションがデータ通信を行うために必要なコネクション（ＰＤＮコネクション、デフォルトベアラ、専用ベアラ）が未確立であった場合は、必要なコネクションを確立するために制御メッセージ（ＰＤＮコネクション確立要求、専用ベアラ確立要求（ベアラ確立要求、ベアラ変更要求））を送信する。なお、新たに専用ベアラを確立する代わりに、既存のベアラを更新してアプリケーションの要求を満たすベアラに変更してもよい。コネクションが確立されるとＵＥ１００はＭＴＣサーバ３００に対して、確立済みのコネクションを介してデータパケット（アプリケーションのメッセージ）を送信することができる。

なお、ＰＤＮコネクションとは、ＵＥ１００とＰＧＷ２３０との間で確立されるデータ通信用のコネクションであり単一のＩＰアドレスが割り当てられる。一方、ベアラ（ＥＰＳベアラとも呼ぶ）とは、そのＰＤＮコネクションに関連付けられて確立されるコネクションであり、ビットレートが保証されたＧＢＲ（Guaranteed Bit Rate）ベアラとベストエフォートのＮｏｎ−ＧＢＲベアラの２つの種類がある。特定のＡＰＮ（Access Point Name、ＰＤＮ（Packet Data Network）の識別子）に対してＰＤＮコネクションが確立される際に、デフォルトベアラ（Ｎｏｎ−ＧＢＲ）も同時に確立される。ＰＤＮコネクション及びデフォルトベアラが確立された後、ＵＥ１００はアプリケーションなどの要求に応じて任意の専用ベアラを確立する。なお、ＥＰＳ（Evolved Packet System）におけるベアラは、ＵＭＴＳ（Universal Mobile Telecommunications System）におけるＰＤＰ（Packet Data Protocol）コンテキストに対応する。

なお、本発明の第１の実施の形態では、ＵＥ１００の通信相手としてＭＴＣサーバ３００を想定して説明しているが、ＵＥ１００の通信相手はＭＴＣサーバ３００に限らず、アプリケーション４００が動作しているサーバや他のＵＥであってもよい。また、図１で示す３ＧＰＰネットワーク２００としては、ＬＴＥ／ＳＡＥ／ＥＰＳ（Long Term Evolution／System Architecture Evolution／Evolved Packet System）、ＵＭＴＳ、ＧＰＲＳ（General Packet Radio Service.）やＧＳＭ（登録商標）（Global System for Mobile Communications）などのほかに、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）（登録商標）やモバイルＷｉＭＡＸ、ＷＬＡＮ（Wireless Local Access Network）などを用いてもよいが、その場合の各種エンティティの名称はその仕様に準ずる。

図２は、本発明の第１の実施の形態におけるＵＥ１００及び３ＧＰＰネットワーク２００内の主要なエンティティ、ＭＴＣサーバ３００の動作の一例を示すシーケンス図である。なお、図２では、Ｐ−ＧＷ２３０及びＳ−ＧＷ２４０によって実現されるネットワークエンティティの機能をＳＧＷ／ＰＧＷ２３５と記載し、ゲートウェイ切り替え前にＵＥ１００がＰＤＮコネクションを確立しているゲートウェイをＳＧＷ１／ＰＧＷ１、ゲートウェイ切り替え後にＵＥ１００がＰＤＮコネクションを確立するゲートウェイをＳＧＷ２／ＰＧＷ２と記載する。

図２では、ＵＥ１００が、ＳＧＷ１／ＰＧＷ１との間で、あるＡＰＮ（例えばＡＰＮ−１）に対するＰＤＮコネクションを確立している状態を初期状態とし（ステップＳ２００１）、ＭＭＥ２２０が、例えば、ＵＥ１００のロケーションやゲートウェイの負荷状態などに基づいて、ＵＥ１００のＳＧＷ１／ＰＧＷ１との間で確立されているＡＰＮ−１に対するＵＥ１００のＰＤＮコネクションに関してゲートウェイの切り替えが必要であると判断したとする（ステップＳ２００３）。なお、ＭＭＥ２２０は、ＵＥ１００のロケーションに基づいてゲートウェイの切り替えが必要であるか否かを判断する場合、例えば、ＵＥ１００からエリア更新メッセージ（ＴＡＵ：Tracking Area Update／ＲＡＵ：Routing Area Update）を受信した際にその判断を実行することが可能である。

ゲートウェイの切り替えが必要であると判断された場合には、ＭＭＥ２２０は、ゲートウェイの切り替えが必要であると判断されたＵＥ１００に対して、コネクションの切断をすぐに通知（再確立の要求を含む）するべきか否か（あるいは、トリガリクエストを受信した際に、トリガメッセージと共に切断通知を送信するべきか否か）を判断する。また、この判断は、後述するようにＵＥ１００の特徴に基づいて行うことができる。

ここでは、ＭＭＥ２２０は、ゲートウェイの切り替えが必要と判断されたＵＥ１００に対してコネクションの切断をすぐには通知しない（すなわち、トリガリクエストを受信した際に、トリガリクエストと共に切断通知を送信する）と判断したとする（ステップＳ２００５）。なお、このときＭＭＥ２２０は、コネクションの切断をすぐには通知しないと判断した判断結果（すなわち、ゲートウェイの切り替えが必要であると判断されたが、切断通知は未送信であることを示す情報）を、ＵＥ１００のコンテキスト中に格納してもよい。

次に、ＭＭＥ２２０はＭＴＣサーバ３００から送信されたトリガリクエストをＩＷＦ２１０経由で受信し（ステップＳ２００７）、その宛先がゲートウェイの切り替えが必要と判断したＵＥ１００宛であるか否かを確認する。この確認は、例えば、ＵＥ１００のコンテキストの中に含まれる判断結果（ゲートウェイの切り替えが必要であると判断されたが、切断通知は未送信であることを示す情報）を参照して行ってもよい。ここでは、トリガリクエストの宛先が、ゲートウェイの切り替えが必要であると判断されたが切断通知は未送信であるＵＥ１００であることが確認され、ＭＭＥ２２０が、トリガを含めた切断通知（又は切断通知を含めたトリガ）をＵＥ１００へ送信すると判断したとする（ステップＳ２００９）。

なお、図２では、ＭＭＥ２２０は、ゲートウェイの切り替えが必要であるか否かの判断をトリガリクエストの受信前に行っているが、トリガリクエストを受信した際（例えば、ステップＳ２００７においてトリガリクエストを受信した後）に行ってもよい。

受信したトリガリクエストの宛先が、ゲートウェイの切り替えが必要と判断されたＵＥ１００である場合、ＭＭＥ２２０は、トリガを含めた切断通知（又は切断通知を含めたトリガ）をＵＥ１００へ送信するとともに（ステップＳ２０１１）、ゲートウェイ（ＳＧＷ１／ＰＧＷ１）に対して現在のコネクションを切断する処理（Delete Session Requestの送信、Responseの受信）を実行する（ステップＳ２０１３、Ｓ２０１４）。なお、ゲートウェイに対するコネクションの切断処理は、ＵＥ１００に対して切断通知を送信する前又は後、あるいは、ＵＥ１００に対する切断通知の送信と同時に行ってもよい。また、ＭＭＥ２２０がトリガリクエストを受信した際にゲートウェイの切り替えが必要か否かの判断を行う場合、ＭＭＥ２２０は、例えば、トリガリクエストを受信した時点でＵＥ１００のコンテキストの中に含まれているＵＥ１００のロケーション情報に基づいて、ゲートウェイの切り替えが必要であるか否かの判断を行うことが可能である。

ＵＥ１００は、トリガが含まれている切断通知（又は、切断通知が含まれているトリガ）を受信した場合、まずトリガに含まれているペイロード（アプリケーション情報）をＮＡＳからアプリケーション（又は複数のアプリケーションを管理する中間レイヤであるService Capability Layer／Service Enablement Layer、又は複数のアプリケーションを管理する常駐アプリ）へ渡し、トリガの受信処理を実行する（ステップＳ２０１５、Ｓ２０１７）。ＵＥ１００は、アプリケーションから通知された情報（コマンド）に基づき、新たなコネクション（ＰＤＮコネクション、又は専用ベアラ（Dedicated Bearer））の確立が必要であると判断した場合には（ステップＳ２０１９）、切断されたコネクションの再確立を要求するためのコネクション確立リクエストの中に新たなコネクション確立リクエストを含めて送信する（ステップＳ２０２１）。このコネクション確立リクエストを受信したＭＭＥ２２０は、ゲートウェイの切り替え先であるＳＧＷ２／ＰＧＷ２に対してコネクションを確立する（ステップＳ２０２３、Ｓ２０２４）とともに、新たなコネクションの確立も行って、ＵＥ１００とＳＧＷ２／ＰＧＷ２（切り替え後のゲートウェイ）との間のＡＰＮ−１に対するコネクションを確立する（ステップＳ２０２５）。なお、ＵＥ１００が新たなＰＤＮコネクションの確立が必要な場合で、かつ切断されたＰＤＮコネクションの再確立が不要である場合は、新たなＰＤＮコネクションの確立リクエストのみを送信してもよい。

なお、図２では、切り替え前のゲートウェイをＳＧＷ１／ＰＧＷ１とし、切り替え後のゲートウェイをＳＧＷ２／ＰＧＷ２と表現しているが、切り替えられるゲートウェイは、Ｓ−ＧＷ２４０又はＰ−ＧＷ２３０のどちらか一方のみであってもよいし、両方であってもよい。また、ＭＭＥ２２０は、トリガ及び切断通知をＵＥ１００へ送信する際（ステップＳ２０１１）、切断通知の中にトリガを含めてもよく、あるいは、トリガの中に切断通知を含めてもよい。以下では、主に、ＭＭＥ２２０が切断通知の中にトリガを含めて送信する場合について説明するが、トリガの中に切断通知を含めて送信する場合も同様の処理が行われる。

また、図３は、本発明の第１の実施の形態において、切断通知を受信した際のＵＥ１００の処理の一例を示すフローチャートである。なお、ここでは、トリガの対象となるアプリケーションが利用するＰＤＮコネクションは、ゲートウェイ切り替えの対象となったＰＤＮコネクション（確立済みのＰＤＮコネクション）と同じであることを想定している。つまり、トリガの対象となるアプリケーションが通信を行うためには、切断されたＰＤＮコネクションと同じＡＰＮに対するＰＤＮコネクションが再確立される必要がある。

ＵＥ１００はＭＭＥ２２０から切断通知を受信した際に（ステップＳ３００１）、切断通知の中にトリガが含まれているか否かを確認する（ステップＳ３００３）。切断通知にトリガが含まれていない場合には、ＵＥ１００は、通常の切断通知の処理を実行する（ステップＳ３００４）。一方、切断通知にトリガが含まれている場合には、ＵＥ１００は、トリガの受信処理を実行し、専用ベアラ（Dedicated Bearer）の確立が必要か否かを確認する（ステップＳ３００５）。専用ベアラの確立が必要な場合は、ＵＥ１００は、切断されたコネクションの再確立リクエストの中に専用ベアラ確立リクエストを含めて送信する（ステップＳ３００７）。一方、専用ベアラの確立が不要な場合は、ＵＥ１００は、専用ベアラ確立リクエストを含まない、切断されたコネクションの再確立リクエストを送信する（ステップＳ３００９）。

なお、上記の説明において、ＭＭＥ２２０から通知される切断通知は、確立済みのＰＤＮコネクションの中から特定のＰＤＮコネクションのみを切断したことを意味するメッセージである場合と、全ての確立済みのＰＤＮコネクションを切断したこと、つまりＵＥ１００自体をネットワーク２００から切断したことを示すメッセージである場合がある。前者の場合は、ＵＥ１００は切断通知としてDeactivate Bearer Context Request（reactivation requestedを含む）を受信し、例えば、切断されたコネクションの再確立リクエストとしてPDN Connectivity Requestを送信する。なお、専用ベアラの確立が必要な場合は、さらに専用ベアラ確立リクエスト（ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST）が含まれる。また、ＭＭＥ２２０は、ＰＤＮコネクションとデフォルトベアラの確立と共に、専用ベアラの確立を行うことができる。一方、後者の場合は、ＵＥ１００は切断通知としてDetach Request（reattach requiredを含む）を受信し、例えば、切断されたコネクションの再確立リクエストとしてAttach Request（PDN Connectivity Requestを含む）を送信する。なお、専用ベアラの確立が必要な場合は、さらに専用ベアラ確立リクエストが含まれる。また、ＭＭＥ２２０は、ＵＥ１００のネットワーク２００への接続処理とＰＤＮコネクションとデフォルトベアラの確立と共に、必要に応じて専用ベアラの確立を行うことができる。

なお、上記の説明では、トリガの対象となるアプリケーションが利用するＰＤＮコネクションは、ゲートウェイ切り替えの対象となったＰＤＮコネクション（確立済みのＰＤＮコネクション）と同じであることを想定していたが、トリガの対象となるアプリケーションが利用するＰＤＮコネクションが、ゲートウェイの切り替え対象となったＰＤＮコネクションと異なる場合は、トリガに関係するアプリケーションが利用するＰＤＮコネクションを確立するためのリクエストをコネクション確立リクエストに含めて送信する。さらに、そのアプリケーションに対して専用ベアラの確立が必要な場合は、そのＰＤＮコネクション確立リクエストの中に専用ベアラの確立リクエストを含めてもよい。なお、切断されたＰＤＮコネクションの再確立リクエストは省略してもよいし、トリガに関係するアプリケーションが利用するＰＤＮコネクションの確立リクエストの中に含めてもよいし、トリガに関係するアプリケーションが利用するＰＤＮコネクションを確立した後に送信してもよい。

なお、切断通知と共にトリガを送信する方法としては、例えば図４に示すように、トリガを挿入したNAS message containerをDeactivate Bearer Context Request又はDetach Requestに付加する方法があるが、これに限定されない。

図５は、本発明の第１の実施の形態において、切断通知としてDetach Requestを受信した場合のＵＥ１００の処理の一例を示すフローチャートである。ＵＥ１００はＭＭＥ２２０からDetach Requestを受信した際に（ステップＳ５００１）、Detach Requestの中にトリガが含まれているか否かを確認する（ステップＳ５００３）。Detach Requestの中にトリガが含まれていない場合には、ＵＥ１００は、通常のDetach Request処理を実行する（ステップＳ５００４）。一方、Detach Requestの中にトリガが含まれている場合には、ＵＥ１００は、トリガの受信処理を実行し、そのトリガの対象アプリケーションが、Detach Requestの送信の際にネットワークにおいて切断されたＰＤＮコネクションに関係するか否かを確認する（ステップＳ５００５）。この確認は、トリガが対象とするＡＰＮが、切断されたＰＤＮコネクションと同じＡＰＮであるか否かに基づいて行うことができる。つまり、トリガの中のペイロードに含まれている情報の提供先となるアプリケーションが、切断されたＰＤＮコネクションを用いてデータ通信を行う場合は、切断されたＰＤＮコネクションに関係すると判断する。トリガが対象とするＡＰＮが、確立済みのＰＤＮコネクションのＡＰＮと同じである場合は、切断されたＰＤＮコネクションと同じＡＰＮに対してＰＤＮコネクションの再確立が必要であると判断する。一方、トリガが対象とするＡＰＮが、切断されたＰＤＮコネクションのＡＰＮと異なる場合は、切断されたＰＤＮコネクションとは異なるＡＰＮに対して新たなＰＤＮコネクションの確立が必要であると判断する。なお、図５のステップＳ５００５における判断を行わずに、トリガが対象とするＡＰＮに対してＰＤＮコネクションの確立を行ってもよい。

ステップＳ５００５において、Detach Requestの中に含まれるトリガの対象アプリケーションが、Detach Requestにより切断されたＰＤＮコネクションに関係する（トリガが対象とするＡＰＮが、切断されたＰＤＮコネクションと同じＡＰＮである）と判断された場合には、さらに、ＵＥ１００は、専用ベアラの確立が必要か否かを確認する（ステップＳ５００７）。この確認は、アプリケーションが判断した、データ通信に必要となるビットレートや許容遅延などのＱｏＳ情報に基づいて行われる。要求を満たす専用ベアラの確立が必要な場合は、ネットワークへの再接続及びＰＤＮコネクションの確立とともに、新たな専用ベアラの確立が必要であると判断される。一方、デフォルトベアラのみで充足する場合は、新たな専用ベアラの確立は不要であると判断される。

ステップＳ５００７において専用ベアラの確立が必要であると判断された場合には、ＵＥ１００は、Attach Requestの中に、切断されたＰＤＮコネクションと同じＡＰＮに対するＰＤＮコネクションを確立するためのＰＤＮコネクション確立リクエストに加えて、そのＰＤＮコネクションに対する専用ベアラ確立リクエストを更に含めて送信する（ステップＳ５００９、Ｓ５０１１）。一方、専用ベアラの確立が不要であると判断された場合には、ＵＥ１００は、Attach Requestの中に、切断されたＰＤＮコネクションと同じＡＰＮに対するＰＤＮコネクションを確立するためのＰＤＮコネクション確立リクエストのみを含めて送信する（ステップＳ５０１１）。なお、ＰＤＮコネクション確立リクエストの中に専用ベアラ確立リクエストを含めることができない場合は、ＰＤＮコネクション確立リクエストのみを含むAttach Requestを送信し、接続処理、及びＰＤＮコネクションの確立が完了した後に専用ベアラ確立リクエストを送信してもよい。

また、ステップＳ５００５において、切断されたＰＤＮコネクションに関係しないと判断された場合には、ＵＥ１００は、ネットワークへの再接続と共に、切断されたＰＤＮコネクションと異なるＡＰＮに対する新たなＰＤＮコネクションを確立するためのＰＤＮコネクション確立リクエストを含むAttach Requestを送信する（ステップＳ５０１７）。なお、この場合において、ＵＥ１００は、確立すべきＰＤＮコネクションに対して専用ベアラの確立が必要であるか否かを判断し（ステップＳ５０１３）、専用ベアラの確立が必要であると判断された場合には、ＰＤＮコネクション確立リクエストに加えて、さらに専用ベアラ確立リクエストをAttach Request又はＰＤＮコネクション確立リクエストに含める（ステップＳ５０１５）。なお、トリガが切断されたＰＤＮコネクションに関係するか否かの判断（ステップＳ５００５）、又は、専用ベアラの確立が必要であるか否かの判断（ステップＳ５００７及びＳ５０１３）は、アプリケーションから情報を通知された際に、その情報に基づいてＮＡＳが同時に行ってもよい。なお、Attach Request又はＰＤＮコネクション確立リクエストの中に専用ベアラ確立リクエストを含めることができない場合は、切断されたＰＤＮコネクションと異なるＡＰＮに対するＰＤＮコネクション確立リクエストのみを含むAttach Requestを送信し、接続処理、及びＰＤＮコネクションの確立が完了した後に専用ベアラ確立リクエストを送信してもよい。

また、図６は、本発明の第１の実施の形態において、切断通知としてDeactivate Bearer Context Requestを受信した場合のＵＥ１００の処理の一例を示すフローチャートである。ＵＥ１００はＭＭＥ２２０からDeactivate Bearer Context Requestを受信した際に（ステップＳ６００１）、Deactivate Bearer Context Requestの中にトリガが含まれているか否かを確認する（ステップＳ６００３）。Deactivate Bearer Context Requestの中にトリガが含まれていない場合には、ＵＥ１００は、通常のDeactivate Bearer Context Request処理を実行する（ステップＳ６００４）。一方、Deactivate Bearer Context Requestの中にトリガが含まれている場合には、ＵＥ１００は、トリガの受信処理を実行し、そのトリガの対象アプリケーションがＰＤＮコネクション（Deactivate Bearer Context Requestにより切断されたＰＤＮコネクション）に関係するか否かを確認する（ステップＳ６００５）。この確認は、図５を用いて説明したDetach Requestの場合と同様に、トリガが対象とするＡＰＮが、切断されたＰＤＮコネクションと同じＡＰＮであるか否かに基づいて行われる。

ステップＳ６００５において、Deactivate Bearer Context Requestの中に含まれるトリガの対象アプリケーションが、Deactivate Bearer Context Requestにより切断されたＰＤＮコネクションに関係する（トリガが対象とするＡＰＮが、切断されたＰＤＮコネクションと同じＡＰＮである）と判断された場合には、さらに、ＵＥ１００は、専用ベアラの確立が必要か否かを確認する（ステップＳ６００７）。この確認も、図５を用いて説明したDetach Requestの場合と同様に、データ通信に必要となるビットレートや許容遅延などのＱｏＳ情報に基づいて行われる。

ステップＳ６００７において専用ベアラが必要であると判断された場合には、ＵＥ１００は、切断されたＰＤＮコネクションを再確立するためのＰＤＮコネクション確立要求（PDN Connectivity Request）の中に専用ベアラ確立リクエストを含め（ステップＳ６００９）、専用ベアラ確立リクエストが挿入されたＰＤＮコネクション確立要求（PDN Connectivity Request）を送信する（ステップＳ６０１１）。一方、専用ベアラが不要であると判断された場合には、ＵＥ１００は、切断されたＰＤＮコネクションを再確立するためのＰＤＮコネクション確立要求（PDN Connectivity Request）のみを送信する（ステップＳ６０１１）。

一方、ステップＳ６００５において、トリガが切断されたＰＤＮコネクションに関係しないと判断された場合には、ＵＥ１００は、既に確立済みのＰＤＮコネクションに対して専用ベアラの確立が必要であるか否かを判断し（ステップＳ６０１３）、専用ベアラの確立が必要であると判断された場合には、専用ベアラ確立リクエストを送信し（ステップＳ６０１５）、一方、専用ベアラの確立が不要であると判断された場合には、制御メッセージの送信は行わない（ステップＳ６０１７）。なお、トリガが関係する新たなＰＤＮコネクションの確立が必要な場合は、新たなＰＤＮコネクションを確立するためのリクエストの中にステップＳ６００５の専用ベアラ確立リクエストを含めて送信する。また、トリガが切断されたＰＤＮコネクションに関係するか否かの判断（ステップＳ６００５）、又は、専用ベアラの確立が必要であるか否かの判断（ステップＳ６００７及びＳ６０１３）は、アプリケーションから情報を通知された際に、その情報に基づいてＮＡＳが同時に行ってもよい。

また、図７は、本発明の第１の実施の形態において、トリガリクエストを受けた際のＭＭＥ２２０の処理の一例を示すフローチャートである。ＭＭＥ２２０はトリガリクエストを受信すると（ステップＳ７００１）、トリガリクエストの宛先が、ゲートウェイ切り替えが必要なＵＥ１００であるか否かを確認する（ステップＳ７００３）。トリガリクエストの宛先が、ゲートウェイ切り替えが必要なＵＥ１００であった場合には、ＭＭＥ２２０は、トリガを含めた切断通知（又は切断通知を含めたトリガ）をＵＥ１００へ送信する（ステップＳ７００５）。一方、トリガリクエストの宛先が、ゲートウェイ切り替えが不要なＵＥ１００であった場合は、通常のトリガを送信する（ステップＳ７００７）。

トリガリクエストの宛先であるＵＥ１００に対してゲートウェイの切り替えが必要か否かの確認は、例えば、ＵＥ１００のコンテキストの中に含まれる判断結果（ゲートウェイの切り替えが必要であると判断されたが、切断通知は未送信であることを示す情報。後述する図８の判断結果）を参照して行ってもよい。なお、ＭＭＥ２２０がトリガリクエストを受信した際に、ＵＥのロケーションや確立済みのＰＤＮコネクションを管理しているゲートウェイの負荷の状態などに応じてゲートウェイの切り替えが必要か否かの判断（後述する図８のステップＳ８００１に相当）を行う場合は、受信したトリガリクエストの中にLow Access PriorityやDelay Tolerant Accessなどの通知情報が含まれている場合にその判断を行ってもよい。この場合、トリガリクエストを送信又は転送するＩＷＦ２１０やＭＴＣサーバ３００（又はＭＴＣアプリケーション４００）、ＳＭＳ−ＳＣ２７０などが、トリガリクエストの中にLow Access PriorityやDelay Tolerant Accessなどの情報を含めて送信する。この通知情報は、トリガリクエストの宛先であるＵＥ１００が、ゲートウェイの切り替えを事前に行う必要がないＵＥであることを認識できる情報であれば何でもよい。

また、図８は、本発明の第１の実施の形態において、ゲートウェイ切り替えが必要と判断した際のＭＭＥ２２０の処理の一例を示すフローチャートである。ＭＭＥ２２０は、ＴＡＵ／ＲＡＵで通知されたＵＥ１００のロケーションや確立済みのＰＤＮコネクションを管理しているゲートウェイの負荷の状態などに基づいてゲートウェイの切り替えが必要であると判断した場合（ステップＳ８００１）、そのＵＥ１００に対して切断通知をすぐに送信するべきか否かを判断する（ステップＳ８００３）。この切断通知はゲートウェイ切り替えのための切断通知であり、切断されたコネクションの再確立の要求を含んでいる。

なお、ステップＳ８００１におけるゲートウェイの切り替えが必要であるか否かの判断は、ＵＥ１００のロケーションやゲートウェイの負荷の状態に基づいて判断する方法に限定されない。例えば、ＵＥ１００が確立しているＰＤＮコネクションの数や、確立済みのベアラ上で転送されているトラフィック量やビットレートの値（ＵＥ１００の複数のベアラのビットレート合計値）がある閾値（ＡＭＢＲ：Aggregate Maximum Bit Rate）を超えている場合などに、ゲートウェイの切り替えが必要であると判断してもよい。なお、複数のＵＥ１００によって構成されるグループを形成している場合には、そのグループに属する一部又は全てのＵＥ１００のＰＤＮコネクションの数やトラフィック量、ビットレートなどの合計値がある閾値を超えている場合に、ゲートウェイの切り替えが必要であると判断してもよい。また、ＵＥ１００が上記の条件を満たしており、かつＵＥ１００がLow Access PriorityやDelay Tolerant Accessである場合に、ゲートウェイの切り替えが必要であると判断してもよい。

ＵＥ１００に対して切断通知を送信するべきか否かの判断（ステップＳ８００３）は、ＵＥ１００の特徴に基づいて判断することができるが、これに限定されない。例えば、そのＵＥ１００がトリガを受けたときだけデータ通信を行う特徴を持ったＵＥ（Device Triggered Only）である場合は、トリガを受信するまでコネクションを使用しないと想定できるため、事前にゲートウェイを切り替えておく必要はないと判断し、切断通知をすぐには送信しないと判断する（ステップＳ８００５）。一方、トリガを受けたときだけに限らず、ＵＥ１００の判断でデータ通信を開始するＵＥ１００（Mobile Originated Only）である場合は、ＵＥ１００自身が任意のタイミングでデータ通信を開始すると想定できるため、事前にゲートウェイを切り替えておく必要があると判断し、切断通知をすぐに送信すると判断する（ステップＳ８００７）。

なお、ＵＥ１００がＭ２Ｍ専用のＵＥ１００である場合や、デバイストリガ機能を備えたＵＥ１００である場合や、Low Access PriorityやDelay Tolerant Accessと設定されているＵＥ１００である場合など、ＵＥ１００の判断でデータ通信を開始する可能性が低いと想定できる場合や、トリガの受信に応じてデータ通信を開始する前にゲートウェイの切り替えを実行することによってデータ通信に遅延が生じても問題ないＵＥ１００である場合は、ＭＭＥ２２０は、ステップＳ８００１においてＵＥ１００に対してゲートウェイの切り替えが必要であると判断したとしても、事前にゲートウェイを切り替えておく必要はない（すなわち、切断通知をすぐには送信しない）と判断してもよい。さらに、ＭＭＥ２２０は、ゲートウェイ切り替えの対象であるＰＤＮコネクション内に専用ベアラが確立されていない場合は、そのＵＥ１００は自ら専用ベアラを確立すると判断するのではなく、トリガを受けた際に新たに専用ベアラを確立すると判断する可能性があると判断し、切断通知をすぐには送信しないと判断してもよい。

なお、ステップＳ８００３の判断を、ＵＥ１００に対して切断通知をすぐに送信するべきか否かの判断と表現しているが、この判断は、例えば、トリガリクエストを受信した際に、ＵＥ１００に対してトリガメッセージと共に切断通知を送信してもよいか否かの判断と表現することもできる。すなわち、図８に図示されている動作では、ゲートウェイの切り替えが必要と判断されたＵＥ１００であっても、例えば、トリガを受けたときだけデータ通信を開始するＵＥ１００に対しては、トリガリクエストを受信したタイミングでトリガメッセージと共に切断通知が送信されればよいと判断される。

次に、本発明の第１の実施の形態におけるＵＥ１００の構成例について説明する。図９は、本発明の第１の実施の形態におけるＵＥ１００の構成の一例を示すブロック図である。図９に図示されているＵＥ１００は、インタフェース１０１、トリガメッセージ受信部１０２、制御メッセージ送受信部１０３、アプリケーション１０４を有している。なお、アプリケーション１０４（ＭＴＣアプリケーションとも呼ぶ）は、複数のアプリケーションを管理するレイヤ（Service Capability Layer）であってもよい。

インタフェース１０１は、ＵＥ１００がネットワークに接続してメッセージ（又はパケット）を送受信するための機能を有している。インタフェース１０１には、他の通信装置（例えば、ネットワーク上に配置されているネットワークノードや他のＵＥ１００など）と通信を行うために、情報を電気的な信号に変調及び復調するハードウェアも含まれる。

また、トリガメッセージ受信部１０２は、ＭＴＣサーバ３００によって送信されたトリガリクエストに基づきネットワーク（例えば、ＭＭＥ２２０）からＵＥ１００へ転送されるトリガメッセージの受信及び処理を行う。トリガメッセージ受信部１０２は、トリガメッセージに含まれるペイロードをアプリケーション１０４へ渡す。アプリケーション１０４は、ペイロードに基づいてデータ通信に必要な要求情報を制御メッセージ送受信部１０３へ渡す。なお、本発明の第１の実施の形態では、ＵＥ１００は、例えばトリガメッセージと共に、ゲートウェイの切り替えに関する情報として切断通知を受信する。切断通知に関しては、例えば制御メッセージ送受信部１０３によって処理される。制御メッセージ送受信部１０３は、ネットワーク２００とのコネクションを確立する処理を行う機能を有しており、アプリケーションから取得した要求情報に基づき、専用ベアラを確立すると判断した場合は、専用ベアラ確立リクエストを含めたコネクション確立リクエストをＭＭＥ２２０へ送信する。なお、図９におけるアプリケーション１０４が複数のアプリケーションを管理するレイヤである場合は、そのレイヤはトリガメッセージ受信部１０２から取得したペイロードを適切なアプリケーション１０４へ渡す。

また、アプリケーション１０４は、制御メッセージ送受信部１０３によってコネクションが確立されたことを受け、例えば、ＭＴＣサーバ３００との間でアプリケーションデータの送受信を開始する。

なお、トリガメッセージ受信部１０２及び制御メッセージ送受信部１０３は、各機能を実施するためのハードウェア（集積回路）で実現されてもよく、あるいは、プロセッサがソフトウェア（プログラム）を実行することによって実現されてもよい。また、トリガメッセージ受信部１０２及び制御メッセージ送受信部１０３は、１つの集積回路又はプロセッサによって実現されてもよく、あるいは、個別の集積回路又はプロセッサによって実現されてもよい。また、ＵＥ１００は、必要な情報やメッセージを一時的に格納するためのメモリを有していてもよく、各処理部で処理を行う際に、当該メモリに情報を格納しながら処理を行ってもよい。

次に、本発明の第１の実施の形態におけるＭＭＥ２２０の構成例について説明する。図１０は、本発明の第１の実施の形態におけるＭＭＥ２２０の構成の一例を示すブロック図である。図１０に図示されているＭＭＥ２２０は、インタフェース２２１、ＧＷ切り替え判断部２２２、制御メッセージ送受信部２２３、トリガリクエスト処理部２２４、コンテキスト保持部２２５を有している。

インタフェース２２１は、ＭＭＥ２２０がネットワークに接続してメッセージ（又はパケット）を送受信するための機能を有している。インタフェース２２１には、他の通信装置（例えば、ＵＥ１００や他のネットワークノードなど）と通信を行うために、情報を電気的な信号に変調及び復調するハードウェアも含まれる。

また、ＧＷ切り替え判断部２２２は、特定のＵＥ１００のコネクションを管理しているゲートウェイを切り替える必要があるか否かを判断し、さらに、そのＵＥ１００に対してコネクションの切断通知及び再確立要求をすぐに送信するか否かを判断し、その判断結果をＵＥ１００のコンテキストとして、情報格納媒体（メモリ）であるコンテキスト保持部２２５に保持する。ゲートウェイの切り替えの要否は、ＵＥ１００のロケーションやゲートウェイの負荷状態などに基づいて判断されるが、これらに限定されない。この判断は、コンテキスト保持部２２５に保持されているＵＥ１００のコンテキストに基づいて判断することができるが、これに限定されない。例えば、トリガメッセージを受けた場合だけデータ通信を行うＵＥ１００や、Low Access Priorityとして設定されているＵＥ１００などのように、自らデータ通信を行う可能性がない、あるいはその可能性が低いＵＥ１００に対しては切断通知を送信しないと判断する。

トリガリクエスト処理部２２４は、コンテキスト保持部２２５を参照し、受信したトリガリクエストの宛先が、ゲートウェイの切り替えが必要であるが、まだその切り替えが実行されていないＵＥ１００であるか否かを確認する。ゲートウェイの切り替えが実行されていないＵＥ１００である場合は、制御メッセージ送受信部２２３に対してトリガメッセージを渡し、トリガメッセージを含むコネクション切断通知をＵＥ１００へ送信するよう指示する。なお、トリガリクエスト処理部２２４は、例えば、ＵＥ１００がデータ通信を開始することを検出するデータ通信要求検出部としての機能も有している。トリガリクエスト処理部２２４は、トリガリクエストの宛先であるＵＥ１００はデータ通信を行うことを要求されており、ＵＥ１００がトリガメッセージに応じてデータ通信を開始するであろうことを検出することが可能である。

また、制御メッセージ送受信部２２３は、トリガリクエスト処理部２２４の指示を受け、トリガメッセージを含む切断通知（ゲートウェイ切り替えに関する情報）を生成し、ＵＥ１００へ送信する。また、制御メッセージ送受信部２２３は、切断通知に対応して、ＵＥ１００とゲートウェイの間のコネクションを切断する処理を開始することも可能である。また、切断通知の応答としてＵＥ１００から受信したコネクション確立リクエストの中に専用ベアラ確立リクエストが含まれていた場合には、新たなゲートウェイに対するコネクションの確立と共に、専用ベアラの確立を行う。一方、コネクション確立リクエストの中に専用ベアラ確立リクエストが含まれていない場合には、新たなゲートウェイに対するコネクションのみを確立する。

例えば、コネクション確立リクエストがAttach Requestであり、PDN Connectivity Requestに加えて、専用ベアラ確立リクエストが含まれていた場合は、ＭＭＥ２２０は、ネットワークに接続するための処理、及びＰＤＮコネクション・デフォルトベアラの確立に加えて、専用ベアラの確立を行う。また、コネクション確立リクエストがPDN Connectivity Requestであり、専用ベアラ確立リクエストが含まれていた場合は、ＭＭＥ２２０は、ＰＤＮコネクション及びデフォルトベアラの確立に加えて、専用ベアラの確立を行う。

なお、ＧＷ切り替え判断部２２２、制御メッセージ送受信部２２３及びトリガリクエスト処理部２２４は、各機能を実施するためのハードウェア（集積回路）で実現されてもよく、あるいは、プロセッサがソフトウェア（プログラム）を実行することによって実現されてもよい。また、ＧＷ切り替え判断部２２２、制御メッセージ送受信部２２３及びトリガリクエスト処理部２２４は、１つの集積回路又はプロセッサによって実現されてもよく、あるいは、個別の集積回路又はプロセッサによって実現されてもよい。また、ＭＭＥ２２０は、必要な情報やメッセージを一時的に格納するためのメモリを有していてもよく、各処理部で処理を行う際に、当該メモリに情報を格納しながら処理を行ってもよい。

以上説明したように、本発明の第１の実施の形態によれば、ネットワーク２００は、ＵＥ１００に対するトリガリクエストを受信した際にコネクションの切断を通知することができるため、データ通信を行うためのコネクションを必要とするＵＥ１００に対してゲートウェイの切り替えを実行することができる。これにより、データ通信を行わないＵＥ１００に対してゲートウェイの切り替えを行うことで発生するシグナリングや処理負荷、バッテリー消費量を軽減することができる。

（第２の実施の形態）
次に、本発明の第２の実施の形態において、ＭＭＥが切断実行要求を含むトリガをＵＥへ送信する場合について説明する。

図１１は、本発明の第２の実施の形態におけるＵＥ１００及びネットワーク２００内のエンティティ、ＭＴＣサーバ３００の動作の一例を示すシーケンス図である。図１１では、ＵＥ１００が、ＳＧＷ１／ＰＧＷ１との間で、あるＡＰＮ（例えばＡＰＮ−１）に対するＰＤＮコネクションを確立している状態を初期状態とし（ステップＳ１１００１）、ＭＭＥ２２０が、例えば、ＵＥ１００のロケーションやゲートウェイの負荷状態などに基づいて、ＵＥ１００のＳＧＷ１／ＰＧＷ１との間で確立されているＡＰＮ−１に対するＵＥ１００のＰＤＮコネクションに関してゲートウェイの切り替えが必要であると判断したとする（ステップＳ１１００３）。なお、ステップＳ１１００１及びＳ１１００３の処理は、上述の図２のステップＳ２００１及びＳ２００３の処理と同様である。

ゲートウェイの切り替えが必要である判断した場合、ＭＭＥ２２０は、ゲートウェイの切り替えが必要と判断されたＵＥ１００に対して、コネクションの切断実行要求をすぐに送信するべきか否かを更に判断する。この判断は、上述の第１の実施の形態における切断通知を送信するべきか否かの判断と同様に、例えば、ＵＥ１００の特徴（ＵＥ１００の判断でデータ通信を開始するＵＥ１００であるか否かなど）に基づいて行うことが可能である。ここでは、ＭＭＥ２２０は、ゲートウェイの切り替えが必要と判断されたＵＥ１００に対してコネクションの切断実行要求をすぐには通知しないと判断したとする（ステップＳ１１００５）。なお、ＭＭＥ２２０は、コネクションの切断実行要求をすぐには通知しないと判断した判断結果（すなわち、ゲートウェイの切り替えが必要であると判断されたが、切断実行要求は未送信であることを示す情報）を、ＵＥ１００のコンテキスト中に格納してもよい。

次に、ＭＭＥ２２０はＭＴＣサーバ３００から送信されたトリガリクエストをＩＷＦ２１０経由で受信し（ステップＳ１１００７）、その宛先がゲートウェイの切り替えが必要と判断したＵＥ１００宛であるか否かを確認する。この確認は、ＵＥ１００のコンテキストの中に含まれる、ＭＭＥ２２０がステップＳ１１００３で実行したゲートウェイの切り替えが必要であるか否かの判断結果（ゲートウェイの切り替えが必要であると判断されたが、切断実行要求は未送信であることを示す情報）を参照して行ってもよい。ここでは、トリガリクエストの宛先が、ゲートウェイの切り替えが必要であると判断されたが切断実行要求は未送信であるＵＥ１００であり、ＭＭＥ２２０が、切断実行要求を含めたトリガ（又はトリガを含めた切断実行要求）をＵＥ１００へ送信すると判断したとする（ステップＳ１１００９）。

なお、図１１では、ＭＭＥ２２０は、ゲートウェイの切り替えが必要であるか否かの判断をトリガリクエストの受信前に行っているが、トリガリクエストを受信した際（例えば、ステップＳ１１００７においてトリガリクエストを受信した後）に行ってもよい。

受信したトリガリクエストの宛先が、ゲートウェイの切り替えが必要と判断されたＵＥ１００である場合、ＭＭＥ２２０は、切断実行要求を含めたトリガ（又はトリガを含めた切断実行要求）をＵＥ１００へ送信する（ステップＳ１１０１１）。なお、ＭＭＥ２２０がトリガリクエストを受信した際にゲートウェイの切り替えが必要か否かの判断を行う場合、ＭＭＥ２２０は、例えば、トリガリクエストを受信した時点でＵＥ１００のコンテキストの中に含まれているＵＥ１００のロケーション情報に基づいて、ゲートウェイの切り替えが必要であるか否かの判断を行うことが可能である。

ＵＥ１００は、切断実行要求が含まれているトリガ（又は、トリガが含まれている切断実行要求）を受信した場合、まずトリガに含まれているペイロード（アプリケーション情報）をＮＡＳからアプリケーション（又はService Capability Layer／Service Enablement Layer：複数のアプリケーションを管理する中間レイヤ、又は複数のアプリケーションを管理する常駐アプリ）へ渡し、トリガの受信処理を実行する（ステップＳ１１０１３、Ｓ１１０１５）。その結果、専用ベアラ（Dedicated Bearer）の確立が必要と判断された場合には（ステップＳ１１０１７）、ＵＥ１００は切断リクエストを送信する（ステップＳ１１０１９）。この切断リクエストを受信したＭＭＥ２２０は、ＵＥ１００とＳＧＷ１／ＰＧＷ１とのコネクションを切断する（ステップＳ１１０２１、Ｓ１１０２３）。なお、ＭＭＥ２２０は、コネクションが切断された際に、切断リクエストへの応答である切断応答をＵＥ１００へ送信してもよい（ステップＳ１１０２５）。その後、ＵＥ１００は、コネクション確立リクエストの中に専用ベアラ確立リクエストを含めて送信する（ステップＳ１１０２７）。ＵＥ１００からコネクション確立リクエストを受信したＭＭＥ２２０は、ＳＧＷ２／ＰＧＷ２に対してコネクションを確立するとともに専用ベアラの確立も行って、ＵＥ１００とＳＧＷ２／ＰＧＷ２（切り替え後のゲートウェイ）との間のＡＰＮ−１に対するコネクションを確立する（ステップＳ１１０２９、Ｓ１１０３１、Ｓ１１０３３）。

なお、図１１では、切り替え前のゲートウェイをＳＧＷ１／ＰＧＷ１とし、切り替え後のゲートウェイをＳＧＷ２／ＰＧＷ２としているが、切り替えられるゲートウェイは、Ｓ−ＧＷ２４０又はＰ−ＧＷ２３０のどちらか一方のみであってもよいし、両方であってもよい。また、ＭＭＥ２２０は、トリガ及び切断通知をＵＥ１００へ送信する際（ステップＳ２０１１）、切断実行要求の中にトリガを含めてもよく、あるいは、トリガの中に切断実行要求を含めてもよい。以下では、主に、ＭＭＥ２２０がトリガの中に切断実行要求を含めて送信する場合について説明するが、切断実行要求の中にトリガを含めて送信する場合も同様の処理が行われる。

また、図１２は、本発明の第２の実施の形態において、トリガを受信したＵＥ１００の処理の一例を示すフローチャートである。なお、ここでは、トリガの対象となるアプリケーションが利用するＰＤＮコネクションは、ゲートウェイ切り替えの対象となったＰＤＮコネクション（確立済みのＰＤＮコネクション）と同じであることを想定している。つまり、トリガの対象となるアプリケーションが通信を行うためには、切断されたＰＤＮコネクションと同じＡＰＮに対するＰＤＮコネクションが再確立される必要がある。

ＵＥ１００はＭＭＥ２２０からトリガを受信した際に（ステップＳ１２００１）、トリガの中に切断実行要求が含まれているか否かを確認する（ステップＳ１２００３）。トリガに切断実行要求が含まれていない場合には、ＵＥ１００は、通常のトリガ処理を実行する（ステップＳ１２００４）。一方、トリガに切断実行要求が含まれている場合には、ＵＥ１００は、Detach Requestを送信し（ステップＳ１２００５）、さらに、トリガの受信処理を実行して、専用ベアラの確立が必要か否かを確認する（ステップＳ１２００７）。専用ベアラの確立が必要であると判断された場合には、ＵＥ１００は、切断されたコネクションの再確立リクエストの中に専用ベアラ確立リクエストを含め（ステップＳ１２００９）、専用ベアラ確立リクエストを含んだ、切断されたＰＤＮコネクションの再確立リクエストを送信する（ステップＳ１２０１１）。一方、専用ベアラの確立が不要（デフォルトベアラのみ必要）であると判断された場合には、ＵＥ１００は、専用ベアラ確立リクエストを含まない、切断されたＰＤＮコネクションの再確立リクエストを送信する（ステップＳ１２０１１）。なお、ステップＳ１２００５におけるDetach Requestの送信処理は、ステップＳ１２００７における専用ベアラの確立が必要か否かの確認処理の前又は後、あるいは、同時に行ってもよい。

なお、上記の説明において、ＭＭＥ２２０から通知される切断実行要求は、確立済みのＰＤＮコネクションの中から特定のＰＤＮコネクションのみを切断することを要求する場合と、全ての確立済みのＰＤＮコネクションを切断すること、つまりＵＥ１００自体をネットワーク２００から切断することを要求する場合がある。前者の場合は、切断実行要求（Deactivate Bearer Context Requestに相当する）を受信したＵＥ１００は、例えば、Bearer Resource Modification Requestを送信してＰＤＮコネクションを切断した後、PDN Connectivity Requestを送信して切断されたＰＤＮコネクションを確立する。また、ＭＭＥ２２０は、図１２のＳ１２００９に示すように、ＰＤＮコネクションとデフォルトベアラの確立と共に、必要に応じて専用ベアラの確立を行うことができる。一方、後者の場合は、切断実行要求（Detach Requestに相当する）を受信したＵＥ１００は、例えば、Detach Requestを送信してネットワーク２００から切断した後、Attach Request（PDN Connectivity Requestを含む）を送信して再接続する。また、ＭＭＥ２２０は、図１２のＳ１２００９に示すように、ネットワーク２００への接続処理とＰＤＮコネクションとデフォルトベアラの確立と共に、必要に応じて専用ベアラの確立を行うことができる。

なお、切断実行要求と共にトリガを送信する方法としては、例えば図１３に示すように、トリガを挿入したNAS message containerの中に切断実行要求を付加する方法があるが、これに限定されない。

また、図１４は、本発明の第２の実施の形態において、Detach Request相当の切断実行要求を含むトリガを受信した場合のＵＥ１００の処理の一例を示すフローチャートである。ＵＥ１００はＭＭＥ２２０からトリガを受信した際に（ステップＳ１４００１）、トリガの中にDetach Request相当の切断実行要求が含まれているか否かを確認する（ステップＳ１４００３）。トリガの中にDetach Request相当の切断実行要求が含まれていない場合には、ＵＥ１００は、通常のトリガ処理を実行する（ステップＳ１４００４）。一方、トリガの中にDetach Request相当の切断実行要求が含まれている場合には、ＵＥ１００は、トリガの受信処理を実行し、そのトリガの対象アプリケーションが、既存のＰＤＮコネクション（切断実行要求の対象であるＰＤＮコネクション）に関係するか否かを確認する（ステップＳ１４００５）。この確認は、トリガが対象とするＡＰＮが、確立済みのＰＤＮコネクションと同じＡＰＮであるか否かに基づいて行うことができる。

ステップＳ１４００５においてトリガの対象アプリケーションが既存のＰＤＮコネクションに関係すると判断された場合には、ＵＥ１００は、切断実行要求に応じてDetach Requestを送信し、ネットワーク２００から切断する（ステップＳ１４００７）。さらに、ＵＥ１００は、専用ベアラの確立が必要か否かを確認し（ステップＳ１４００９）、専用ベアラの確立が必要であると判断された場合には、Attach Requestの中に専用ベアラ確立リクエストを含め（ステップＳ１４０１１）、専用ベアラ確立リクエストを含んだAttach Requestを送信する（ステップＳ１４０１３）。一方、専用ベアラの確立が不要であると判断された場合には、ＵＥ１００は、Attach Requestのみを送信する（ステップＳ１４０１３）。なお、ステップＳ１４００７におけるDetach Requestの送信処理は、ステップＳ１４００９における専用ベアラの確立が必要か否かの確認処理の前又は後、あるいは、同時に行ってもよい。

一方、ステップＳ１４００５において既存のＰＤＮコネクションに関係しない、つまり異なるＡＰＮに対するＰＤＮコネクションの確立が必要と判断された場合には、ＵＥ１００は、さらに、専用ベアラの確立が必要か否かを確認する（ステップＳ１４０１５）。ステップＳ１４０１５において専用ベアラの確立が必要であると判断された場合には、ＵＥ１００は、新たなＰＤＮコネクションを確立するためのＰＤＮコネクション確立リクエスト（PDN Connectivity Request）の中に専用ベアラ確立リクエストを含め（ステップＳ１４０１７）、専用ベアラ確立リクエストを含んだＰＤＮコネクション確立リクエスト（PDN Connectivity Request）を送信する（ステップＳ１４０１９）。一方、ステップＳ１４０１５において専用ベアラの確立が不要であると判断された場合には、ＵＥ１００は、新たなＰＤＮコネクションを確立するためのＰＤＮコネクション確立リクエスト（PDN Connectivity Request）のみを送信する（ステップＳ１４０１９）。なお、ステップＳ１４００５において既存のＰＤＮコネクションに関係しないと判断された場合には、既存のＰＤＮコネクションの再確立（既存のＰＤＮコネクションに係るゲートウェイの切り替え）は必要ないためDetach Requestを送信する必要はなく、新たなＰＤＮコネクションの確立リクエストが送信されることになる。

また、図１５は、本発明の第２の実施の形態において、Deactivate Bearer Context Request相当の切断実行要求を含むトリガを受信した場合のＵＥ１００の処理の一例を示すフローチャートである。ＵＥ１００はＭＭＥ２２０からトリガを受信した際に（ステップＳ１５００１）、トリガの中にDeactivate Bearer Context Request相当の切断実行要求が含まれているか否かを確認する（ステップＳ１５００３）。トリガの中にDeactivate Bearer Context Request相当の切断実行要求が含まれていない場合には、ＵＥ１００は、通常のトリガ処理を実行する（ステップＳ１５００４）。一方、トリガの中にDeactivate Bearer Context Request相当の切断実行要求が含まれている場合には、トリガの受信処理を実行し、そのトリガが切断対象のＰＤＮコネクション（切断実行要求の対象であるＰＤＮコネクション）に関係するか否かを確認する（ステップＳ１５００５）。

ステップＳ１５００５においてトリガが切断対象のＰＤＮコネクションに関係すると判断された場合は、ＰＤＮコネクション切断リクエスト（PDN Disconnect Request）を送信する（ステップＳ１５００７）。さらに、ＵＥ１００は、専用ベアラの確立が必要であるか否かを確認し（ステップＳ１５００９）、専用ベアラの確立が必要である場合には、ＰＤＮコネクション確立リクエスト（PDN Connectivity Request）の中に専用ベアラ確立リクエストを含め（ステップＳ１５０１１）、専用ベアラ確立リクエストを含んだＰＤＮコネクション確立リクエスト（PDN Connectivity Request）を送信する（ステップＳ１５０１３）。一方、ステップＳ１５００９において専用ベアラが不要であると判断された場合には、ＵＥ１００は、ＰＤＮコネクション確立リクエスト（PDN Connectivity Request）のみを送信する（ステップＳ１５０１３）。

一方、ステップＳ１５００５においてトリガが切断対象のＰＤＮコネクションに関係しないと判断された場合は、ＵＥ１００は、そのトリガが切断対象ではない他の既存のＰＤＮコネクションに関係するか否かを確認する（ステップＳ１５０１５）。トリガが切断対象ではない他の既存のＰＤＮコネクションに関係する場合には、ＵＥ１００は、さらに、専用ベアラの確立が必要か否かを確認する（ステップＳ１５０１７）。ステップＳ１５０１７において専用ベアラの確立が必要と判断された場合には、ＵＥ１００は、専用ベアラ確立リクエストを送信する（ステップＳ１５０１９）。一方、ステップＳ１５０１７において専用ベアラが不要と判断された場合には、ＵＥ１００は、制御メッセージの送信は行わない（ステップＳ１５０２１）。なお、ステップＳ１５０１５において他の既存のＰＤＮコネクションに関係すると判断される場合、トリガは、既存のＰＤＮコネクションに関連する通信を開始させるものである。

一方、ステップＳ１５０１５においてトリガが切断対象ではない他のＰＤＮコネクションに関係しないと判断された場合には、ＵＥ１００は、さらに、専用ベアラの確立が必要か否かを確認する（ステップＳ１５０２３）。ステップＳ１５０２３において専用ベアラの確立が必要であると判断された場合は、ＵＥ１００は、アプリケーションが関係するＡＰＮに対するＰＤＮコネクション確立リクエストの中に専用ベアラ確立リクエストを含め（ステップＳ１５０２５）、専用ベアラ確立リクエストを含んだＰＤＮコネクション確立リクエストを送信する（ステップＳ１５０２７）。一方、ステップＳ１５０２３において専用ベアラが不要であると判断された場合には、ＵＥ１００は、アプリケーションが関係するＡＰＮに対するＰＤＮコネクション確立リクエストのみを送信する（ステップＳ１５０２７）。なお、ステップＳ１５０１５において既存のＰＤＮコネクションに関係しないと判断された場合には、新たなＰＤＮコネクションが確立されることになる。

また、図１６は、本発明の第２の実施の形態において、トリガリクエストを受けた際のＭＭＥ２２０の処理の一例を示すフローチャートである。ＭＭＥ２２０はトリガリクエストを受信すると（ステップＳ１６００１）、トリガリクエストの宛先が、ゲートウェイ切り替えが必要なＵＥ１００であるか否かを確認する（ステップＳ１６００３）。トリガリクエストの宛先が、ゲートウェイ切り替えが必要なＵＥ１００であった場合には、ＭＭＥ２２０は、切断実行要求を含めたトリガ（又はトリガを含めた切断実行要求）をＵＥ１００へ送信する（ステップＳ１６００５）。一方、トリガリクエストの宛先が、ゲートウェイ切り替えが不要なＵＥ１００であった場合は、通常のトリガを送信する（ステップＳ１６００７）。

また、ゲートウェイ切り替えが必要と判断した際のＭＭＥ２２０の処理は、図８に示すフローチャートの切断通知を切断実行要求と読み替えた場合と同じである。すなわち、ＭＭＥ２２０は、事前にゲートウェイを切り替える必要があるか否かを判断し、事前にゲートウェイを切り替える必要があると判断された場合には切断実行要求をＵＥ１００へ送信し、事前にゲートウェイを切り替える必要がないと判断された場合には、トリガリクエストを受信した際に、トリガと共に切断実行要求をＵＥ１００へ送信する。

また、本発明の第２の実施の形態におけるＵＥ１００及びＭＭＥ２２０の構成は、基本的に図９及び図１０にそれぞれ図示されているものと同様であり、本発明の第２の実施の形態に係る上述の動作を実行できる構成を有している。本発明の第２の実施の形態では、ＵＥ１００は、例えば、トリガメッセージと共に、ゲートウェイの切り替えに関する情報として切断実行要求を受信する。本発明の第２の実施の形態におけるＵＥ１００は、切断実行要求に関しては、例えば制御メッセージ送受信部１０３において処理を行うことが可能である。また、本発明の第２の実施の形態におけるＭＭＥ２２０は、トリガメッセージと共に、ゲートウェイの切り替えに関する情報として切断実行要求を送信する。

以上説明したように、本発明の第２の実施の形態によれば、ネットワーク２００は、ＵＥに対するトリガリクエストを受信した際にコネクションの切断を実行するようＵＥ１００へ要求することができるため、データ通信を行うためのコネクションを必要とするＵＥ１００に対してゲートウェイの切り替えを実行することができる。これにより、データ通信を行わないＵＥ１００に対してゲートウェイの切り替えを行うことで発生するシグナリングや処理負荷、バッテリー消費量を軽減することができる。

（第３の実施の形態）
次に、本発明の第３の実施の形態において、ＭＭＥ２２０が、サービス要求を受信した際に、その送信元のＵＥ１００がゲートウェイの切り替えが必要なＵＥ１００であった場合に、サービス要求を拒絶することで、コネクション切断をＵＥ１００へ通知する場合について説明する。

図１７は、本発明の第３の実施の形態におけるＵＥ１００及びネットワーク２００内のエンティティ、ＭＴＣサーバ３００の動作の一例を示すシーケンス図である。なお、図１７に図示されているステップＳ１７００１からステップＳ１７００５までの処理は、図２に図示されているステップＳ２００１からステップＳ２００５までの処理と同様であり、ここでは説明を省略する。

図１７において、ＵＥ１００はアプリケーション（又はService Capability Layer／Service Enablement Layer：複数のアプリケーションを管理する中間レイヤ、又は複数のアプリケーションを管理する常駐アプリ）からの情報（コマンド）を受けた際に（ステップＳ１７００７）、ＵＥ１００がアイドルモードであった場合は、サービス要求（Service Request）をＭＭＥ２２０へ送信する（ステップＳ１７００９）。なお、不図示ではあるが、サービス要求の送信前には、ＵＥ１００と基地局との間のコネクション（ＲＲＣコネクション、Ｒａｄｉｏベアラ）の確立が行われる。

ＭＭＥ２２０は、ステップＳ１７００１〜Ｓ１７００５の処理により、ゲートウェイの切り替えが必要と判断されたＵＥ１００に対して切断通知を送信せずに待機する状態となっている。なお、ＭＭＥ２２０は、ＵＥ１００がアイドルモードである場合に、ゲートウェイを切り替える必要性が生じたとしても、ＵＥ１００に対して切断通知を送信しないと判断してもよい。サービス要求を受信したＭＭＥ２２０は、送信元のＵＥ１００がゲートウェイの切り替えが必要なＵＥ１００であると判断した場合にはサービス要求を拒絶するべきと判断し（ステップＳ１７０１１）、受信したサービス要求を拒絶することを示すサービス拒絶をＵＥ１００へ送信するとともに（ステップＳ１７０１３）、ゲートウェイ（ＳＧＷ１／ＰＧＷ１）に対して現在のコネクションを切断する処理（Delete Session Requestの送信、Responseの受信）を実行する（ステップＳ１７０１５、Ｓ１７０１６）。なお、ＭＭＥ２２０がサービス要求に対する応答として送信するメッセージはサービス拒絶に限らず、ＵＥ１００に対して再接続を指示することができるメッセージであればどのメッセージを用いてもよく、例えば、切断要求（Detach RequestやDeactivate Bearer Context Request）を用いてもよい。また、ゲートウェイの切り替えが必要であるか否かの判断は、ＵＥ１００からエリア更新メッセージ（ＴＡＵ:Tracking Area Update ／ ＲＡＵ:Routing Area Update）などのメッセージを受信した際に行ってもよいし、サービス要求を受信した際にＵＥ１００のコンテキスト情報を参照して判断してもよい。

サービス拒絶を受信したＵＥ１００は、アプリケーションからの情報を基に、新たなコネクション（ＰＤＮコネクション、又は専用ベアラ（ＰＤＰコンテキスト））の確立が必要であるか否かの確認を行う（ステップＳ１７０１７）。この確認は、ステップＳ１７００７でアプリケーションから通知された情報が、新たなコネクションの確立を必要であることを示す情報であるか否かを確認することで行われる。ステップＳ１７００７においてアプリケーションは、データ通信を開始する際にデータ通信に関する情報をＮＡＳへ通知するが、この通知は、アプリケーションがデータ通信を行うために必要なコネクションを確立するようＮＡＳへ要求するための通知とも言える。ＵＥ１００は、新たなコネクション（ＰＤＮコネクション又は専用ベアラ）の確立が必要であると判断した場合には、新たなコネクション（ＰＤＮコネクション又は専用ベアラ）の確立要求を含めた接続要求（Attach Request）をＭＭＥ２２０へ送信する（ステップＳ１７０１９）。

なお、ステップＳ１７００７で通知される情報が、確立済みのＡＰＮ−１に対するＰＤＮコネクションを用いてデータを送信することを要求する情報であった場合は、ステップＳ１７０１７において新たなコネクションの確立が不要であると判断されるため、ステップＳ１７０１９で送信する接続要求には、ＡＰＮ−１に対するＰＤＮコネクションの確立要求が含まれる。一方、ステップＳ１７００７で通知される情報が、新たなＰＤＮコネクションの確立が必要であることを示す情報であった場合は、ステップＳ１７０１９で送信する接続要求には、新たなＡＰＮに対するＰＤＮコネクションの確立要求が含まれる。この場合、ＡＰＮ−１に対するＰＤＮコネクションの確立要求の送信は省略してもよいし、新たなＡＰＮに対するＰＤＮコネクションを確立した後の任意のタイミングで行ってもよい。また、ステップＳ１７００７で通知される情報が、確立済みのＡＰＮ−１に対するＰＤＮコネクションに対して新たな専用ベアラの確立や既存の専用ベアラの変更が必要であることを示す情報であった場合は、ステップＳ１７０１９で送信する接続要求には、ＡＰＮ−１に対するＰＤＮコネクションの確立要求と共に、新たな専用ベアラの確立要求や専用ベアラの変更要求などが含まれる。

ＵＥ１００から接続要求を受信したＭＭＥ２２０は、接続要求に含まれているコネクションの確立要求がＡＰＮ−１に対するものであった場合は、ゲートウェイ切り替え先であるＳＧＷ２／ＰＧＷ２に対してコネクションを確立する（ステップＳ１７０２１、Ｓ１７０２２、Ｓ１７０２３）。なお、図１７では切り替え前のゲートウェイをＳＧＷ１／ＰＧＷ１とし、切り替え後のゲートウェイをＳＧＷ２／ＰＧＷ２としているが、切り替えられるゲートウェイは、Ｓ−ＧＷ２４０又はＰ−ＧＷ２３０のどちらか一方のみであってもよいし、両方であってもよい。一方、接続要求に含まれているコネクションの確立要求が新たなＡＰＮに対するものであった場合は、そのＡＰＮに対応するゲートウェイに対してコネクションの確立を行う。

また、図１８は、本発明の第３の実施の形態において、サービス拒絶を受信したＵＥ１００の処理の一例を示すフローチャートである。ここでは、アプリケーションが利用するＰＤＮコネクションは、ゲートウェイ切り替えの対象となったＰＤＮコネクション（確立済みのＰＤＮコネクション）と同じであることを想定している。つまり、アプリケーションが通信を行うためには、切断されたＰＤＮコネクションと同じＡＰＮに対するＰＤＮコネクションが再確立される必要がある。そのため、ＵＥ１００が送信する接続要求の中には、ゲートウェイ切り替えの対象となったＰＤＮコネクションを再確立するためのＰＤＮコネクション確立リクエストが含まれる。

ＵＥ１００はＭＭＥ２２０からサービス拒絶を受信した際に（ステップＳ１８００１）、専用ベアラの確立が必要か否かを確認する（ステップＳ１８００３）。ステップＳ１８００３において専用ベアラの確立が必要であると判断された場合には、ＭＭＥ２２０は、接続要求の中に専用ベアラ確立リクエストを含め（ステップＳ１８００５）、専用ベアラ確立リクエストを含む接続要求を送信する（ステップＳ１８００７）。一方、ステップＳ１８００３において専用ベアラの確立が不要（デフォルトベアラのみ必要）であると判断された場合には、ＭＭＥ２２０は、専用ベアラ確立リクエストを含まない接続要求を送信する（ステップＳ１８００７）。なお、専用ベアラ確立リクエストは、接続要求の中に含まれているＰＤＮコネクション確立要求の中に含めてもよい。専用ベアラの確立が必要か否かの判断は、図１７のステップＳ１７００７においてアプリケーションからコマンドを受けた際に実行し、その結果をＵＥ１００のコンテキストに保持しておいてもよい。この場合、ＮＡＳはサービス拒絶を受信した際に、そのコンテキストを参照し、専用ベアラの確立が必要であるか否かを知ることができる。

なお、上記の説明では、アプリケーションが利用するＰＤＮコネクションは、ゲートウェイ切り替えの対象となったＰＤＮコネクション（確立済みのＡＰＮ−１に対するＰＤＮコネクション）と同じであることを想定していたが、アプリケーションが利用するＰＤＮコネクションが、ゲートウェイの切り替え対象となったＰＤＮコネクションと異なる場合は、アプリケーションが利用するＰＤＮコネクション（新たなＡＰＮに対するＰＤＮコネクション）を確立するためのリクエストを接続要求に含めて送信する。さらに、そのアプリケーションに対して専用ベアラの確立が必要な場合は、そのＰＤＮコネクション確立リクエストの中に専用ベアラの確立リクエストを含めてもよい。なお、切断されたＰＤＮコネクションの再確立リクエストは省略してもよいし、アプリケーションが利用するＰＤＮコネクションの確立リクエストの中に含めてもよいし、アプリケーションが利用するＰＤＮコネクションを確立した後に送信してもよい。

なお、ＵＥ１００はサービス拒絶の中に含まれている拒絶要因（Cause）を示す値に基づいて、接続要求を送信するべきか否かを判断してもよい。拒絶要因が、コネクションの切断を示す値（例：Implicitly Detach（#10）やNo EPS bearer context activated（#40））であった場合は、ＵＥ１００はＭＭＥ２２０によってコネクションが切断されたと認識し、接続要求を送信する必要があると判断する。つまり、サービス拒絶を受信した際に、拒絶要因の値から接続処理が必要であると判断した場合には、専用ベアラを確立するためのメッセージを、ネットワーク２００へ接続するためのメッセージに含めて送信する。これにより、ＵＥ１００は、ネットワーク２００への接続（ＰＤＮコネクションとデフォルトベアラの確立を含む）と専用ベアラの確立を同時に行うことができるため、別々に行った場合よりもシグナリングの数を低減することができる。

また、図２０は、本発明の第３の実施の形態において、サービス要求の応答として特定のＰＤＮコネクション切断リクエスト（Deactivate Bearer Context Request）を受信した場合のＵＥ１００の処理の一例を示すフローチャートである。

ＵＥ１００は、ＭＭＥ２２０からＰＤＮコネクション切断リクエストを受信した際に（ステップＳ２０００１）、新たなＰＤＮコネクションの確立が必要か否かを確認する（ステップＳ２０００２）。新たなＰＤＮコネクションの確立が必要か否かは、ＮＡＳがアプリケーションからの通知に基づいて送信する必要があると判断した制御メッセージ、すなわちサービス要求の送信をトリガした制御メッセージを特定することで確認することができる。

ステップＳ２０００２において、切断されたＰＤＮコネクションと異なるＡＰＮに対するＰＤＮコネクションの確立が必要であると判断された場合には、ＵＥ１００は、新たなＡＰＮに対するＰＤＮコネクションの確立要求を送信する（ステップＳ２０００３）。なお、ＵＥ１００は、切断されたＰＤＮコネクションの再確立を省略してもよいし、新たなＡＰＮに対するＰＤＮコネクションの確立を実行した後に切断されたＰＤＮコネクションの再確立を行ってもよい。これにより、ＵＥ１００が必要とするコネクションの確立を優先して行うことができる。

一方、新たなＡＰＮに対するＰＤＮコネクションの確立が不要である場合、つまり、ＵＥ１００のアプリケーションが、切断されたＰＤＮコネクションを利用するアプリケーションであった場合、そのＰＤＮコネクションに対して専用ベアラの確立が必要であったか否かを判断する（ステップＳ２０００４）。専用ベアラの確立が必要であるか否かの確認も、ＮＡＳがアプリケーションからの通知に基づいて送信する必要があると判断した制御メッセージ、すなわちサービス要求の送信をトリガした制御メッセージを特定することで確認することができる。専用ベアラの確立が必要であった場合は、専用ベアラ確立要求を含む、切断されたＰＤＮコネクションを再確立するための要求メッセージを送信する（ステップＳ２０００５、Ｓ２０００６）。一方、専用ベアラの確立が不要である場合は、専用ベアラ確立要求を含める必要はなく、切断されたＰＤＮコネクションの再確立するための要求メッセージを送信する（ステップＳ２０００６）。

また、図１９は、本発明の第３の実施の形態において、サービス要求を受信したＭＭＥ２２０の処理の一例を示すフローチャートである。ＭＭＥ２２０は、ＵＥ１００からサービス要求を受信した際に（ステップＳ１９００１）、送信元のＵＥ１００がゲートウェイの切り替えを必要とするＵＥ１００であるか否かを判断する（ステップＳ１９００３）。
ステップＳ１９００３においてゲートウェイの切り替えが必要なＵＥ１００であると判断された場合には、ＭＭＥ２２０はサービス拒絶をＵＥ１００へ送信する（ステップＳ１９００５）。ＭＭＥ２２０は、サービス拒絶に適切な拒絶要因（例えば、上述したコネクションの切断を示す値）を含めてもよく、拒絶要因を参照したＵＥ１００が、接続要求を送信する必要があることを認識できるようにしてもよい。一方、ステップＳ１９００３においてゲートウェイの切り替えが不要なＵＥ１００であると判断された場合には、ＭＭＥ２２０は、サービス要求を受け入れたことを示すサービス受入（Service Accept）を送信する（ステップＳ１９００７）。サービス受入を受信したＵＥ１００は、必要に応じて専用ベアラ確立要求を送信することが可能である。

ステップＳ１９００３における判断は、上述の第１の実施の形態において図７及び図８を用いて説明した方法を用いて行うことができる。例えば、ＭＭＥ２２０はサービス要求を受信した際に、送信元のＵＥ１００のコンテキストを参照し、ゲートウェイの切り替えが必要であることを示す情報が含まれていた場合にサービス拒絶を送信する。つまり、ＭＭＥ２２０は図８を用いて説明した方法に従って、ゲートウェイの切り替えが必要なＵＥ１００に対して切断通知を送信するべきか否かを判断する。また、ＭＭＥ２２０はサービス要求を受信した際に、ＵＥ１００のロケーションやゲートウェイの負荷の状況（その他、ＵＥ１００が確立しているＰＤＮコネクションの数や、確立済みのベアラ上で転送されているトラフィック量やビットレートの値など）に応じて、ＵＥ１００に対してゲートウェイの切り替えが必要か否かを判断してもよい。この場合、サービス要求にLow Access PriorityやDelay Tolerant AccessなどのIndicationが含まれている場合に、ステップＳ１９００３における判断を実行してもよい。この場合、ＵＥ１００が、ＵＥ１００及びアプリケーションや送信データの設定情報（優先度情報（優先度が低い）、又はLow Access Priorityと設定されている）に基づいてサービス要求の中にLow Access PriorityやDelay Tolerant Accessなどの情報を含めて送信する。

また、本発明の第３の実施の形態におけるＵＥ１００及びＭＭＥ２２０の構成は、基本的に図９及び図１０にそれぞれ図示されているものと同様であり、本発明の第３の実施の形態に係る上述の動作を実行できる構成を有している。本発明の第３の実施の形態では、ＵＥ１００は、例えば、アイドルモードの状態からデータ通信を行うために、ネットワーク２００へサービス要求を送信することが可能である。また、本発明の第３の実施の形態におけるＭＭＥ２２０は、ＵＥ１００からサービス要求を受信することで、ＵＥ１００がデータ通信を開始しようとしていることを検出することが可能であり、また、サービス要求に対してサービス拒絶（例えば、ゲートウェイの切り替えに関する情報として、切断通知に相当する拒絶要因を挿入）をＵＥ１００へ送信することが可能である。

以上説明したように、本発明の第３の実施の形態によれば、ネットワーク２００は、ＵＥ１００からサービス要求を受信した際にコネクションの切断を通知することができるため、データ通信を行うためにサービス要求を送信したＵＥ１００（データ通信のためのコネクションを必要とするＵＥ１００）に対してゲートウェイの切り替えを実行することができる。これにより、データ通信を行わないＵＥ１００に対してゲートウェイの切り替えを行うことで発生するシグナリングや処理負荷、バッテリー消費量を軽減することができる。

なお、上記の各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブ ル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。

本発明は、コネクションを利用してデータ通信を行うＵＥに対してゲートウェイの切り替えを実行することができるという効果を有しており、セルラー通信機能を利用して通信技術（特に、Ｍ２Ｍ通信の技術）に適用可能である。

１００ ＵＥ（通信端末）
１０１、２２１ インタフェース
１０２ トリガメッセージ受信部
１０３、２２３ 制御メッセージ送受信部
１０４ アプリケーション
２００ ３ＧＰＰネットワーク（ネットワーク）
２１０ ＩＷＦ
２２０ ＭＭＥ／ＳＧＳＮ／ＭＳＣ（ＭＭＥ）
２２２ ＧＷ切り替え判断部
２２４ トリガリクエスト処理部
２２５ コンテキスト保持部
２３０ Ｐ−ＧＷ／ＧＧＳＮ／ｅＰＤＧ（Ｐ−ＧＷ）
２３５ ＳＧＷ／ＰＧＷ
２４０ Ｓ−ＧＷ
２５０ ｅＮＢ／ＮＢ／ＢＳ
２６０ ＨＳＳ／ＨＬＲ
２７０ ＳＭＳ−ＳＣ／ＧＭＳＣ／ＩＷＭＳＣ
３００ サーバ（ＭＴＣサーバ）
４００ アプリケーション（ＭＴＣアプリケーション）

Claims (19)

1. 通信端末がネットワーク上のゲートウェイとの間で確立しているコネクションを管理するネットワークノードであって、
   前記通信端末が前記ゲートウェイとの間で確立しているコネクションに関して、前記ゲートウェイの切り替えを行う必要があるか否かを判断するゲートウェイ切り替え判断部と、
   前記通信端末がデータ通信を開始することを検出するデータ通信要求検出部と、
   前記ゲートウェイの切り替えを行う必要がある前記通信端末が前記データ通信を開始することを検出した場合に、前記ゲートウェイの切り替えに関する情報を前記通信端末へ送信するゲートウェイ切り替え処理部とを、
   有するネットワークノード。
2. 前記データ通信要求検出部は、前記通信端末に前記データ通信を開始させるトリガメッセージの送信要求を検出することによって、前記通信端末が前記データ通信を開始することを検出する請求項１に記載のネットワークノード。
3. 前記ゲートウェイ切り替え処理部は、前記トリガメッセージの送信要求に応じて前記通信端末へ送信する前記トリガメッセージと共に、前記ゲートウェイの切り替えに関する情報を前記通信端末へ送信する請求項２に記載のネットワークノード。
4. 前記ゲートウェイ切り替え処理部は、前記ゲートウェイの切り替えに関する情報として、前記通信端末が前記ゲートウェイとの間で確立している前記コネクションの切断を示す切断通知を前記通信端末へ送信するとともに、前記通信端末が前記ゲートウェイとの間で確立している前記コネクションの切断処理を開始する請求項３に記載のネットワークノード。
5. 前記ゲートウェイ切り替え処理部は、前記ゲートウェイの切り替えに関する情報として、前記通信端末が前記ゲートウェイとの間で確立しているコネクションを切断するよう要求する切断実行要求を前記通信端末へ送信する請求項３に記載のネットワークノード。
6. 前記データ通信要求検出部は、前記データ通信を開始するためのサービス要求を前記通信端末から受信することによって、前記通信端末が前記データ通信を開始することを検出する請求項１に記載のネットワークノード。
7. 前記ゲートウェイ切り替え処理部は、前記サービス要求を拒絶するサービス拒絶と共に、前記ゲートウェイの切り替えに関する情報を前記通信端末へ送信する請求項６に記載のネットワークノード。
8. 前記ゲートウェイ切り替え処理部は、前記ゲートウェイの切り替えに関する情報として、前記通信端末が前記ゲートウェイとの間で確立している前記コネクションの切断を示す拒絶要因を前記サービス拒絶に挿入するとともに、前記通信端末が前記ゲートウェイとの間で確立している前記コネクションの切断処理を開始する請求項６に記載のネットワークノード。
9. 前記ゲートウェイ切り替え判断部は、前記データ通信要求検出部によって前記データ通信を開始することが検出された前記通信端末に関して、前記ゲートウェイの切り替えを行う必要があるか否かを判断する請求項１に記載のネットワークノード。
10. 前記ゲートウェイ切り替え判断部によって前記ゲートウェイの切り替えを行う必要があると判断された前記通信端末に関する情報を格納する情報格納部を有し、
    前記ゲートウェイ切り替え処理部は、前記情報格納部に格納されている前記通信端末に関する情報を参照することによって、前記データ通信要求検出部によって前記データ通信を開始することが検出された前記通信端末に対して、前記ゲートウェイの切り替えに関する情報を送信すべきか否かを判断する請求項１に記載のネットワークノード。
11. ネットワーク上のゲートウェイとの間でコネクションを確立してデータ通信を行う通信端末であって、
    前記ゲートウェイとの間で確立している前記コネクションに関して前記ゲートウェイの切り替えを行う必要があると判断され、かつ、前記通信端末が前記データ通信を開始することが前記ネットワークで検出された場合に前記ネットワークから送信される情報であって、前記ゲートウェイの切り替えに関する情報を前記ネットワークから受信する情報受信部を有する通信端末。
12. 前記情報受信部は、前記通信端末に前記データ通信を開始させるトリガメッセージの送信要求が前記ネットワークによって検出された際に前記トリガメッセージの送信要求に応じて前記ネットワークから送信される前記トリガメッセージと共に、前記ゲートウェイの切り替えに関する情報を前記ネットワークから受信する請求項１１に記載の通信端末。
13. 前記情報受信部は、前記ゲートウェイの切り替えに関する情報として、前記通信端末が前記ゲートウェイとの間で確立している前記コネクションの切断を示す切断通知を受信する請求項１２に記載の通信端末。
14. 前記トリガメッセージによって開始されるデータ通信を行うために専用ベアラの確立が必要か否かを確認し、前記専用ベアラの確立が必要な場合には、前記ネットワークとの間で新たにコネクションの確立を行うためのコネクション確立要求に、専用ベアラの確立を要求する専用ベアラ確立要求を挿入して前記ネットワークへ送信するコネクション確立処理部を有する請求項１３に記載の通信端末。
15. 前記情報受信部は、前記ゲートウェイの切り替えに関する情報として、前記通信端末が前記ゲートウェイとの間で確立しているコネクションを切断するよう要求する切断実行要求を受信する請求項１２に記載の通信端末。
16. 前記切断実行要求に応じて前記コネクションを切断するとともに、前記トリガメッセージによって開始される通信を行うために専用ベアラの確立が必要か否かを確認し、前記専用ベアラの確立が必要な場合には、前記ネットワークとの間で新たにコネクションの確立を行うためのコネクション確立要求に、専用ベアラの確立を要求する専用ベアラ確立要求を挿入して前記ネットワークへ送信するコネクション確立処理部を有する請求項１５に記載の通信端末。
17. 前記データ通信を開始するためのサービス要求を前記ネットワークへ送信するサービス要求送信部を有し、前記情報受信部は、前記サービス要求を拒絶するサービス拒絶と共に、前記ゲートウェイの切り替えに関する情報を受信する請求項１１に記載の通信端末。
18. 前記情報受信部は、前記ゲートウェイの切り替えに関する情報として、前記サービス拒絶に挿入されており、前記通信端末が前記ゲートウェイとの間で確立している前記コネクションの切断を示す拒絶要因を受信する請求項１７に記載の通信端末。
19. 前記サービス要求によって開始される前記データ通信を行うために専用ベアラの確立が必要か否かを確認し、前記専用ベアラの確立が必要な場合には、前記ネットワークへの接続要求に、専用ベアラの確立を要求する専用ベアラ確立要求を挿入して前記ネットワークへ送信するコネクション確立処理部を有する請求項１８に記載の通信端末。