(57)【特許請求の範囲】
【請求項１】
ユーザ端末と、ネットワークを構成するネットワークエンティティを含むネットワーク装置と、前記ユーザ端末の通信相手である所定の通信装置とを有する通信システムであって、
前記所定の通信装置が、
前記ネットワーク装置に対して前記ユーザ端末へ制御メッセージを送信することを要求するリクエストメッセージであって、前記ユーザ端末のアプリケーションを識別するアプリケーション識別情報を含むリクエストメッセージを前記ネットワークへ送信するメッセージ送信部を有し、
前記ネットワーク装置が、
前記リクエストメッセージを前記ユーザ端末の通信相手である前記所定の通信装置から受信したとき、前記リクエストメッセージに基づいて生成された前記アプリケーション識別情報を含む制御メッセージを前記ユーザ端末へ送信する制御メッセージ送信部と、
前記所定の通信装置を識別するための情報と、前記ネットワーク装置が前記制御メッセージを前記ユーザ端末へ送信するよう要求する情報とを含む制御メッセージ送信要求を前記ユーザ端末から受信する制御メッセージ送信要求受信部と、
前記制御メッセージ送信部により前記制御メッセージを前記ユーザ端末へ送信するか否かを判断するためのフィルタ情報として、前記制御メッセージ送信要求を保持する制御メッセージ送信要求保持部とを有し、
前記ユーザ端末が、
前記制御メッセージを前記ネットワークから受信する制御メッセージ受信部と、
前記制御メッセージ受信部で前記制御メッセージを受信したとき、前記アプリケーション識別情報によって特定されるアプリケーションを起動するアプリケーション起動部と、
前記制御メッセージ送信要求を前記ネットワーク装置へ送信する制御メッセージ送信要求部とを有する通信システム。
【請求項２】
ネットワークを介して、所定の通信装置と通信を行うユーザ端末であって、
前記所定の通信装置から送信されたリクエストメッセージであって、前記ユーザ端末のアプリケーションを識別するアプリケーション識別情報を含むリクエストメッセージに基づいて生成された前記アプリケーション識別情報を含む制御メッセージを前記ネットワークから受信する制御メッセージ受信部と、
前記制御メッセージ受信部で前記制御メッセージを受信したとき、前記アプリケーション識別情報によって特定されるアプリケーションを起動するアプリケーション起動部と、
前記所定の通信装置を識別するための情報と、前記ネットワークが前記制御メッセージを前記ユーザ端末へ送信するよう要求する情報とを含む制御メッセージ送信要求を前記ネットワークへ送信することによって、前記ネットワークが、前記制御メッセージを前記ユーザ端末へ送信するか否かを判断するためのフィルタ情報として、前記制御メッセージ送信要求を保持できるようにする制御メッセージ送信要求部とを、
有するユーザ端末。
【請求項３】
前記アプリケーション起動部で前記アプリケーションを起動したとき、前記アプリケーションの起動を示す応答メッセージを前記ネットワークへ送信する応答メッセージ送信部を更に有する請求項２に記載のユーザ端末。
【請求項４】
前記制御メッセージとしてＳＭＳを利用する請求項２に記載のユーザ端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示技術は、セルラー通信機能を利用して通信を行う通信システム、ユーザ端末並びに通信装置に関する。
【背景技術】
【０００２】
携帯電話やスマートフォンなどセルラー通信を用いた端末（以下、ＵＥ：User Equipment）を通して利用できるサービスには様々なものがある。ＷｅｂアクセスやＥ−Ｍａｉｌはもちろんのこと、電子地図を用いたナビゲーションサービスや、インターネットアクセスを介した音声通話サービスなど、ユーザ側の判断で必要なアプリケーション（以下、本明細書では、アプリと記載することもある）をインストールして利用するサービスが広がっている。ＵＥ上ではこれらの様々なアプリケーションが起動されるが、それぞれのアプリケーションが実現するサービスの形態によって動作が異なる。例えば、Ｗｅｂアクセスなどのように、ユーザによる操作を介して動作を開始するアプリケーションや、音声通話アプリケーションなどのように、常時他のユーザからの着信を待ち受けているアプリケーションもある。後者の場合のようなアプリケーションは、いつそのアプリケーション宛のメッセージが送信されてくるかが分からないため、常時アプリケーションを起動してメッセージが受信されるまで待機しておく必要がある。【０００３】
特に、マシン間コミュニケーション（Machine to Machine CommunicationやMachine Type Communicationと呼ばれる。以下、Ｍ２Ｍ通信と記載）で用いられるアプリケーションの中には、サーバやセルラーネットワーク内のノード、他のＵＥからのリクエストに応じてセンシングデータ（例えば、気温、震度、水量、カメラ、ＧＰＳ（Global Positioning System））を通知するという動作が必要なアプリケーションがあるため、アプリケーションを常時起動させておくことで不定期なメッセージ受信に対応する必要がある。例えば、スマートフォンを所持しているユーザが車を運転している際に、サーバや他のＵＥからの問い合わせを受けたスマートフォンが、ＧＰＳの位置情報をサーバへ通知するというアプリケーションが考えられる。なお、ＵＥとは、セルラー通信機能を備えている端末であって、携帯電話やスマートフォンだけでなく、通信機能付きのカーナビゲーションやＰＮＤ（Portable Navigation Device）、歩行者ナビゲーション、あるいは、Ｍ２Ｍサービスに特化した通信デバイスも含む。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】“3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Improvements for Machine-Type Communications”, 3GPP TR 23.888, V1.3.0, June 2011.
【非特許文献２】“3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Service requirements for machine-type communications”, 3GPP TS 22.368, V11.1.0, March 2011.
【発明の概要】
【０００５】
ＵＥはアプリケーションを起動していないと、サーバやセルラーネットワーク内のノード、他のＵＥから送られてくるアプリケーション用のメッセージを受信することはできないが、アプリケーションを常時起動させておくと、ＵＥのＣＰＵパワーやメモリが消費され、さらに、ＵＥのバッテリーの電力も消費してしまうことになる。特に、例えば、データ送信要求や着信待ち受けなどのような相手の都合によって不定期又は突発的に生じるリクエストを受信するためには、対応するアプリケーションを常時起動させておく必要があるが、いつ来るか明確ではないリクエストを待機するためにアプリケーションを常時起動させておくのは効率的ではないという問題点がある。
【０００６】
上記の問題を解決するため、本開示技術の一態様によれば、例えば、アプリケーションを起動していないときにサーバや他のユーザ端末などの通信相手端末からアプリケーション用のメッセージが送られてきたとしても、ユーザ端末が、当該アプリケーション用のメッセージの受信及び処理を行うためのアプリケーションを起動できるようにする技術が提供される。
【０００７】
例えば、本開示技術の一態様は、ユーザ端末と、ネットワークを構成するネットワークエンティティを含むネットワーク装置と、前記ユーザ端末の通信相手である所定の通信装置とを有する通信システムであって、
前記所定の通信装置が、
前記ネットワーク装置に対して前記ユーザ端末へ制御メッセージを送信することを要求するリクエストメッセージであって、前記ユーザ端末のアプリケーションを識別するアプリケーション識別情報を含むリクエストメッセージを前記ネットワークへ送信するメッセージ送信部を有し、
前記ネットワーク装置が、
前記リクエストメッセージを前記ユーザ端末の通信相手である前記所定の通信装置から受信したとき、前記リクエストメッセージに基づいて生成された前記アプリケーション識別情報を含む制御メッセージを前記ユーザ端末へ送信する制御メッセージ送信部と、
前記所定の通信装置を識別するための情報と、前記ネットワークが前記制御メッセージを前記ユーザ端末へ送信するよう要求する情報とを含む制御メッセージ送信要求を前記ユーザ端末から受信する制御メッセージ送信要求受信部と、
前記制御メッセージ送信部により前記制御メッセージを前記ユーザ端末へ送信するか否かを判断するためのフィルタ情報として、前記制御メッセージ送信要求を保持する制御メッセージ送信要求保持部とを有し、
前記ユーザ端末が、
前記制御メッセージを前記ネットワークから受信する制御メッセージ受信部と、
前記制御メッセージ受信部で前記制御メッセージを受信したとき、前記アプリケーション識別情報によって特定されるアプリケーションを起動するアプリケーション起動部と、
前記制御メッセージ送信要求を前記ネットワーク装置へ送信する制御メッセージ送信要求部とを有する通信システムを含む。
上記の構成により、ユーザ端末は、サーバや他のユーザ端末などの通信相手端末からアプリケーション用のメッセージが送られてくる前に、当該アプリケーション用のメッセージの受信及び処理を行うためのアプリケーションを起動できるようになる。
【０００８】
なお、本開示技術の態様は、上記の通信システム以外に、ユーザ端末、通信装置などによって実現されてもよい。
【０００９】
本開示技術は例えば上記の構成を有し、ユーザ端末は、サーバや他のユーザ端末などの通信相手端末からアプリケーション用のメッセージが送られてくる前に、当該アプリケーション用のメッセージの受信及び処理を行うためのアプリケーションを起動できるようになり、ユーザ端末の処理負荷やバッテリーの浪費を低減させるという効果を有する。
【００１０】
なお、本開示技術が有する効果及び利点は上記に限定されるものではなく、更なる効果及び利点が本明細書及び図面の開示内容から明らかとなるであろう。上記の更なる効果及び利点は、例えば、本明細書及び図面に開示されている様々な実施の形態及び特徴によって個別に提供されるものであり、必ずしも、本開示技術の一態様によってすべての効果及び利点が提供される必要はない。
【図面の簡単な説明】
【００１１】
【図１】本開示技術の第１の実施の形態におけるネットワーク構成の一例を示す図
【図２】本開示技術の第１の実施の形態におけるＵＥ及びネットワーク、サーバの動作の一例を示すシーケンス図
【図３】本開示技術の第１の実施の形態において、ＭＴＣサーバからＵＥ宛のパケットを受信した際のネットワークの処理の一例を示すフローチャート
【図４】本開示技術の第１の実施の形態において、制御メッセージを受信した際のＵＥの処理の一例を示すフローチャート
【図５】本開示技術の第１の実施の形態において、ネットワークがＵＥに対して送信するパケット受信通知を示す制御メッセージとして、ページングメッセージを用いた場合の処理の一例を示すシーケンス図
【図６】本開示技術の第１の実施の形態において、ページングメッセージを受信した際のＵＥの処理の一例を示すフローチャート
【図７】本開示技術の第１の実施の形態におけるＵＥの構成の一例を示すブロック図
【図８】本開示技術の第１の実施の形態におけるネットワークの構成の一例を示すブロック図
【図９】本開示技術の第１の実施の形態において、ネットワーク内に存在するエンティティを詳細に表したネットワーク構成の一例を示す図
【図１０】本開示技術の第１の実施の形態におけるＩＷＦの構成の一例を示すブロック図
【図１１】本開示技術の第１の実施の形態におけるＭＴＣサーバの構成の一例を示すブロック図
【図１２】本開示技術の第１の実施の形態において、ＩＷＦを介してメッセージを送信した場合の一例を示すシーケンス図
【図１３】本開示技術第１の実施の形態において、ＧＴＰプロトコルが用いられている場合のＰＧＷの処理の一例を示すフローチャート
【図１４】本開示技術の第１の実施の形態において、ＧＴＰプロトコルが用いられている場合のＳＧＷの処理の一例を示すフローチャート
【図１５】本開示技術の第１の実施の形態において、ＰＭＩＰプロトコルが用いられている場合のＳＧＷの処理の一例を示すフローチャート
【図１６】本開示技術の第１の実施の形態におけるページング要求の制御メッセージの一例を模式的に示す図
【図１７】本開示技術の第１の実施の形態におけるページング応答の制御メッセージの一例を模式的に示す図
【図１８】本開示技術の第２の実施の形態において、ＵＥとネットワークの間で確立されるベアラに対して割り当てるベアラＩＤの一例を示す図
【図１９】本開示技術の第２の実施の形態において、アプリケーションＡとアプリケーションＢに関して制御メッセージ送信要求を登録しているときに、サーバＢからアプリケーションＢ用のメッセージを受けた場合における処理の一例を示すシーケンス図
【図２０】本開示技術の第３の実施の形態において、サーバがＩＷＦへ送信するトリガメッセージの中に制御メッセージ送信要求としてのページング送信要求を付加した場合の処理の一例を示すシーケンス図
【図２１】本開示技術の第４の実施の形態において、ＵＥ上に、アプリケーションＡ宛のパケットが届いたことを検出する常駐アプリケーションを使用する方法の一例を示す図
【図２２】本開示技術の第３の実施の形態において、ＩＷＦがＭＭＥに対して直接ページングの送信を指示する場合の一例を示すシーケンス図
【図２３】本開示技術の第１の実施の形態において、ＩＷＦがＭＭＥに対して直接ページングの送信を指示する場合の一例を示すシーケンス図
【図２４】本開示技術の第３の実施の形態において、制御メッセージとしてページングを用いてＵＥからのデータ送信をトリガする場合の一例を示すシーケンス図
【図２５】本開示技術の第３の実施の形態において、制御メッセージとしてＳＭＳを用いてＵＥからのデータ送信をトリガする場合の一例を示すシーケンス図
【図２６】本開示技術の第１の実施の形態において、制御メッセージとしてページングを用いてＵＥからのデータ送信をトリガする場合の一例を示すシーケンス図
【図２７】本開示技術の第１の実施の形態において、制御メッセージとしてＳＭＳを用いてＵＥからのデータ送信をトリガする場合の一例を示すシーケンス図
【図２８】本開示技術の第３の実施の形態において、サーバが送信するトリガメッセージを模式的に示す図
【図２９】本開示技術の第１の実施の形態において、制御メッセージとしてＳＭＳを用いた場合の一例を示すシーケンス図
【図３０】本開示技術の第３の実施の形態において、制御メッセージとしてＳＭＳを用いた場合の一例を示すシーケンス図
【図３１】本開示技術の第１の実施の形態において、ＩＷＦがＣＢＣに対して制御メッセージとしてＣＢＳメッセージの送信を指示する場合の一例を示すシーケンス図
【図３２】本開示技術の第１の実施の形態において、制御メッセージとしてＣＢＳを用いてＵＥからのデータ送信をトリガする場合の一例を示すシーケンス図
【図３３】本開示技術の第３の実施の形態において、サーバが、トリガメッセージの中にＣＢＳメッセージを使用することを指示する情報（制御メッセージ送信要求）を含めてＩＷＦへ送信し、ＩＷＦがＣＢＳの使用を選択する場合の一例を示すシーケンス図
【図３４】本開示技術の第３の実施の形態において、サーバが、トリガメッセージの中にＣＢＳメッセージを使用することを指示する情報（制御メッセージ送信要求）を含めてＩＷＦへ送信し、ＩＷＦがＣＢＳの使用を選択してＵＥからのデータ送信をトリガする場合の一例を示すシーケンス図
【図３５】図３４において、ＵＥからのアプリケーションの停止通知を受け、サーバがＣＢＳ送信要求をトリガメッセージに含めて送信する場合の一例を示すシーケンス図
【発明を実施するための形態】
【００１２】
以下、図面を参照しながら、本開示技術の第１〜第４の実施の形態について説明する。本開示技術の第１の実施の形態では、特定のパケットの受信に対して制御メッセージ送信要求を登録しているＵＥは、制御メッセージを受信した際に、制御メッセージ送信要求に関係するアプリケーションを起動する。さらに、本開示技術の第２の実施の形態では、複数のアプリケーションがＵＥにインストールされている場合に、ベアラＩＤ（ＥＰＳベアラＩＤ、ベアラ識別子）を用いて起動するアプリケーションを特定する。本開示技術の第３の実施の形態では、サーバが送信するパケットの中に、制御メッセージ送信要求を付加する。本開示技術の第４の実施の形態では、アプリケーションＡ宛のパケットの受信を監視する常駐アプリを使用し、アプリケーションＡ宛のパケットの受信を検出したら、アプリケーションＡを起動する。
【００１３】
（第１の実施の形態）
まず、本開示技術の第１の実施の形態について説明する。図１は、本開示技術の第１の実施の形態におけるネットワーク構成の一例を示す図である。図１には、セルラー通信端末であるＵＥ１１０と、ＵＥ１１０と通信を行うＭＴＣサーバ（以下、単にサーバと記載することもある）１３０と、ＵＥ１１０とＭＴＣサーバ１３０を繋ぐセルラー通信網を形成する３ＧＰＰネットワーク（以下、単にネットワークと記載することもある）１２０と、ＭＴＣサーバ１３０において提供されるサービスの管理や制御を実施するＭＴＣユーザ１４０が描かれている。なお、ＭＴＣサーバ１３０は、３ＧＰＰネットワーク１２０の中に存在していてもよい。
【００１４】
ここでは、ＵＥ１１０上にはアプリケーションＡがインストールされており、ＭＴＣサーバ１３０とアプリケーションＡを用いた通信を行うものとする。ＵＥ１１０は、ネットワーク１２０に登録されており、ネットワーク１２０とＵＥ１１０との間にはアプリケーションＡ用のパケットを送受信するのに必要なコネクション（ＰＤＰコンテキスト（PDP context）／ＰＤＮコネクション（PDN Connection））及びベアラが確立されており、ＵＥ１１０はアイドルモード又はコネクティッドモードのいずれかの状態にある。なお、アイドルモードの状態のＵＥ１１０は、送信回路の動作を停止させているが、ページングと呼ばれる制御メッセージなどを受信するための受信回路を動作させており、当該制御メッセージの受信によって、通常の通信を行うために送信回路及び受信回路の両方を動作させるコネクティッドモードの状態へ移行する。また、ＵＥ１１０は、アイドルモード及びコネクティッドモードのいずれの状態においてもアプリケーションを常時起動させておく必要はなく、コネクションが確立されていたとしても、アプリケーションの終了及び起動を適宜行うことが可能である。また、ＵＥ１１０がＡＣＰＵ（Application CPU）とＣＣＰＵ（Communication CPU）により構成されている場合、アプリケーションを終了させることでＡＣＰＵの動作を停止し、ＣＣＰＵのみを動作させることで、ＡＣＰＵの動作に伴う消費電力を削減することが可能である。
【００１５】
また、ＭＴＣサーバ１３０はＵＥ１１０に対して、確立済みのコネクション及びベアラを介してパケット（アプリケーションＡ用のリクエストメッセージ）を送信することができる。なお、本明細書では、ＵＥ１１０の通信相手である通信装置としてＭＴＣサーバ１３０を想定して説明しているが、ＵＥ１１０の通信相手はＭＴＣサーバ１３０に限らず、セルラーネットワーク内のノードや他のＵＥ１１０であってもよい。また、図１で示す３ＧＰＰネットワーク１２０としては、ＬＴＥ／ＳＡＥ、ＵＭＴＳやＧＰＲＳ／ＧＳＭ（登録商標）、さらにはＷｉＭＡＸ（登録商標）やモバイルＷｉＭＡＸなどを用いてもよいが、その場合の各種エンティティの名称はその仕様に準ずる。
【００１６】
図２は、本開示技術の第１の実施の形態におけるＵＥ１１０及びネットワーク１２０、サーバ１３０の動作の一例を示すシーケンス図である。図２において、まず、ＵＥ１１０はネットワーク１２０に対して制御メッセージ送信要求を送信する（ステップＳ２０１）。この制御メッセージ送信要求は、ネットワーク１２０がＵＥ１１０をあて先とする特定のパケット（アプリケーションＡ用のリクエストメッセージ）をサーバ１３０から受信したとき、ＵＥ１１０に対して制御メッセージを送信することを要求するメッセージである。ＵＥ１１０は、アプリケーションＡが起動されていない場合に、アプリケーションＡ用のパケットがサーバ１３０から送信されていることを制御メッセージとして受信するために制御メッセージ送信要求をネットワーク１２０へ送信する。例えば、ＵＥ１１０がアプリケーションＡを終了しているときや、アプリケーションＡを終了したとき、まもなくアプリケーションＡを終了する場合などに、この制御メッセージ送信要求のメッセージを送信する。なお、後述するように、サーバ１３０が送信するパケットはトリガリクエストメッセージ（以下では、トリガメッセージとも呼ぶ）であってもよく、制御メッセージの受信によって行われるＵＥ１１０の動作は、アプリケーションＡの起動だけでなく、データ送信の開始やネットワークへの接続、さらにはコネクションの確立などであってもよい。さらには、アプリケーションＡが起動されていたとしてもパケットの受信処理による負荷を減らす必要があるときなどにも、制御メッセージ送信要求を送信してもよい。この場合、ＵＥ１１０の動作を引き起こすためのメッセージをコントロールプレーン（Ｃ−ｐｌａｎｅ）上のメッセージとすることができるため、ユーザプレーン上のメッセージによるネットワークへの負荷やＵＥ１１０の処理負荷を減らすことができる。この制御メッセージ送信要求には、サーバ１３０からのパケット（アプリケーションＡ用のリクエストメッセージ）を識別するための情報（パケット識別情報）と、そのパケット識別情報（パケットフィルタ）に該当するパケットを受信した際に制御メッセージをＵＥ１１０へ送信することを要求する情報（制御メッセージ要求）が含まれている。制御メッセージ送信要求を受信したネットワーク１２０は、制御メッセージ送信要求に含まれている情報をフィルタ情報として保持する。なお、パケット識別情報は、サーバ１３０からのパケットであることを特定可能とする情報であり、例えば、サーバ１３０のアドレスやポート番号、アプリケーションを特定するための情報、ＡＰＮ（Access Point Name）などが利用可能である。なお、ネットワーク１２０は、サーバ１３０から受信したパケットに該当するパケットフィルタが存在しない場合に、そのパケットが制御メッセージの送信対象であるパケットであると認識するようにしてもよい。この場合、ＵＥ１１０は、制御メッセージの送信対象であるパケットに関するパケットフィルタを削除するためのメッセージをステップＳ２０１において送信する。
【００１７】
ネットワーク１２０は、サーバ１３０からパケットを受信した場合（ステップＳ２０２）、このパケットに対して設定されたフィルタ情報の存在（保持）を確認すると、このパケットをバッファリングするとともに、アプリケーションＡ用のパケットをサーバ１３０から受信したこと（すなわち、ＵＥ１１０宛のパケットが存在すること）を通知する制御メッセージ（パケット受信通知）をＵＥ１１０へ送信する（ステップＳ２０３）。パケット受信通知を示す制御メッセージをネットワーク１２０から受信したＵＥ１１０は、アプリケーションＡを起動するとともに（ステップＳ２０４）、応答メッセージをネットワーク１２０へ送信する（ステップＳ２０５）。応答メッセージを受信したネットワーク１２０は、バッファリングしていたパケットをＵＥ１１０に対して転送する（ステップＳ２０６）。ＵＥ１１０は、既にアプリケーションＡを起動しているため、転送されたパケットをアプリケーションＡで受信及び処理することができる（ステップＳ２０７）。なお、ＵＥ１１０に対して送信する制御メッセージの中にパケットの中の情報を含めることができる場合、ＵＥ１１０は、制御メッセージの中の情報に基づいて特定の動作（アプリケーションの起動、データ送信の開始、ネットワークへの接続、さらにはコネクションの確立など）を行うことができるため、ネットワーク１２０はパケットのバッファリングや転送を実行する必要はない。
【００１８】
また、図３は、本開示技術の第１の実施の形態において、ＭＴＣサーバ１３０からＵＥ１１０宛のパケットを受信した際のネットワーク１２０の処理の一例を示すフローチャートである。なお、図３の処理は、ネットワーク１２０が、図２のステップＳ２０２でパケットを受信してから、ステップＳ２０３で制御メッセージをＵＥ１１０へ送信するまでに行われる処理に対応している。図３において、ネットワーク１２０は、ＵＥ１１０宛のパケットをサーバ１３０から受信すると（ステップＳ３０１）、そのパケットに該当するフィルタ情報が存在するかどうか（ネットワーク１２０にフィルタ情報が登録されているかどうか）を確認する（ステップＳ３０２）。
【００１９】
そのパケットに該当するフィルタ情報が存在する場合は、ネットワーク１２０は、ＵＥ１１０がコネクティッドモードの状態であったとしても、ＵＥ１１０に対してパケットを送信するのではなく、パケットをバッファリングするとともに制御メッセージをＵＥ１１０へ送信する（ステップＳ３０３）。つまり、ＵＥ１１０宛のパケットを送信するためのベアラが存在しており、かつ、ＵＥ１１０がコネクティッドモードであったとしても、そのベアラを用いてＵＥ１１０に対してすぐにパケットを送信せずに、制御メッセージを送信する。
【００２０】
ＵＥ１１０は、制御メッセージを受信すると、アプリケーションＡを起動し、制御メッセージに対する応答メッセージを返す。ネットワーク１２０は、この制御メッセージに対する応答メッセージを受信し（ステップＳ３０４）、バッファリングしていたパケットをＵＥ１１０に対して転送する（ステップＳ３０５）。ＵＥ１１０は、既にアプリケーションＡを起動しているため、転送されたパケットをアプリケーションＡで受信及び処理することができる。なお、ステップＳ３０２においてパケットに該当するフィルタ情報が存在しない場合には、ＵＥ１１０がアプリケーションＡを既に起動している状態とみなして、パケットをＵＥ１１０に対してすぐに転送してもよい。また、例えばステップＳ３０４において応答メッセージを受信した場合に、ネットワーク１２０は、このパケットに該当するフィルタ情報を削除してもよい。
【００２１】
また、図４は、本開示技術の第１の実施の形態において、制御メッセージを受信した際のＵＥ１１０の処理の一例を示すフローチャートである。なお、図４の処理は、ＵＥ１１０が、図２のステップＳ２０３で制御メッセージを受信した後に実行される処理に対応している。ＵＥ１１０は、制御メッセージを受信すると（ステップＳ４０１）、受信した制御メッセージがパケット受信通知を示す制御メッセージであるか否かを確認する（ステップＳ４０２）。パケット受信通知を示す制御メッセージである場合は、ＵＥ１１０はアプリケーションＡを起動し（ステップＳ４０３）、制御メッセージに対する応答メッセージを返信する（ステップＳ４０４）。一方、受信した制御メッセージがパケット受信通知ではない場合には、通常の制御メッセージ応答処理を実行する（ステップＳ４０５）。ＵＥ１１０は、登録済みのパケットフィルタが存在する場合に、受信した制御メッセージがパケット受信通知であると判断してもよいし、受信した制御メッセージにパケット受信通知であることを示す情報が含まれている場合に、受信した制御メッセージがパケット受信通知であると判断してもよい。
【００２２】
なお、制御メッセージ送信要求としては、デフォルトベアラや専用ベアラ(Dedicated Bearer)などの確立や変更をするためのメッセージ（BEARER RESOURCE ALLOCATION REQUEST、BEARER RESOURCE MODIFICATION REQUEST）や、ＰＤＰコンテキスト／ＰＤＮコネクションの確立や変更をするためのメッセージ（Activate PDP Context Request、Modify PDP Context Request、PDN CONNECTIVITY REQUEST、PDN DISCONNECT REQUEST）、在圏エリア情報を更新するためのメッセージ（Routing Area Update、Tracking Area Update）、サービス要求メッセージ（Service Request）などの既存の制御メッセージ（ＮＡＳ（Non-Access Stratum）メッセージやＡＳ（Access Stratum）メッセージ）や、専用のメッセージを用いることができる。また、ネットワーク１２０がＵＥ１１０に対して送信する制御メッセージとしては、ページングメッセージやＣＢＳ（Cell Broadcast Service）、ＭＢＭＳ（Multimedia Broadcast and Multicast Service）やＳＭＳ（Short Message Service）などのＵＥ１１０へ送信可能なブロードキャスト／マルチキャスト／ユニキャストメッセージを用いることができる。また、ネットワーク１２０がＵＥ１１０へ送信する制御メッセージとして、基地局が送信するＳＩＢ（System Information Block）などの報知情報を用いることもできる。この場合、ＵＥ１１０は、ページングを受信した際に、ページングの中にＳＩＢの変更の有無を示す情報が含まれている場合は、該当するＳＩＢを確認し、そこにパケット受信通知を示す情報が含まれている場合は、アプリケーションＡを起動して、応答メッセージを返す。
【００２３】
図５は、本開示技術の第１の実施の形態において、ネットワーク１２０がＵＥ１１０に対して送信するパケット受信通知を示す制御メッセージとして、ページングメッセージを用いた場合の処理の一例を示すシーケンス図である。ＵＥ１１０は、制御メッセージ送信要求（ページング送信要求）として、例えば、Bearer Modification Request（ベアラ変更要求）メッセージを送信し（ステップＳ５０１）、サーバ１３０からのメッセージに対してページングを送信することを要求する。Bearer Modification Requestメッセージには、ネットワーク１２０内にＴＦＴ（Traffic Flow Template、トラフィックフローテンプレート）として保持される情報として、サーバ１３０からのパケットを識別するパケット識別情報を含むパケットフィルタと、該当パケットを送信する際に使用するベアラの識別子（EPS Bearer Identifier、ベアラＩＤ）と、ページング送信要求が含まれている。Bearer Modification Requestメッセージを受信したネットワーク１２０は、メッセージに含まれている情報をＴＦＴとして保持する。
【００２４】
そして、ネットワーク１２０は、ＵＥ１１０宛のパケットを受信した際に（ステップＳ５０２）、そのパケットに該当するパケットフィルタがある場合は、そのパケットフィルタに関連付けられたベアラＩＤから送受信に使用するベアラを特定する。通常は、特定されたベアラを用いてパケットを転送するが、本実施の形態のネットワーク１２０は、パケットフィルタに対してページング送信要求が付加されている場合には、ＵＥ１１０がコネクティッドモードの状態であったとしても、ＵＥ１１０に対してパケットを送信するのではなく、パケットをバッファリングするとともにページングメッセージを送信する（ステップＳ５０３）。ネットワーク１２０からページングメッセージを受信したＵＥ１１０は、サーバ１３０からのパケットを受信及び処理するためのアプリケーションＡを起動し（ステップＳ５０４）、応答メッセージ（サービスリクエストメッセージ）を送信する（ステップＳ５０５）。サービスリクエストメッセージを受信したネットワーク１２０は、バッファリングしていたパケットをＵＥ１１０に対して転送する（ステップＳ５０７）。なお、このとき、例えばバッファリングしていたパケットのソースアドレスをチェックして、このパケットが、ＵＥ１１０から受信したサービスリクエストメッセージに含まれているパケット識別情報と対応しているかどうかを確認してもよい（ステップＳ５０６）。ＵＥ１１０は、ステップＳ５０４でアプリケーションＡを起動しているため、転送されたパケットを受信することができる（ステップＳ５０８）。
【００２５】
また、図６は、本開示技術の第１の実施の形態において、ページングメッセージを受信した際のＵＥ１１０の処理の一例を示すフローチャートである。なお、図６の処理は、ＵＥ１１０が、図５のステップＳ５０３でページングメッセージを受信してから、ステップＳ５０５でサービスリクエストメッセージを送信するまでの処理に対応している。制御メッセージとしてページングメッセージを用いる場合、コネクティッドモードであるＵＥ１１０は、登録済みのパケットフィルタが存在するか否かを確認し（ステップＳ６０２）、登録済みのパケットフィルタが存在する場合は、制御メッセージであるページングメッセージが、サーバ１３０からパケットを受信したことを示すパケット受信通知であると判断する。そして、パケット受信通知であると判断した場合は、アプリケーションＡを起動し（ステップＳ６０３）、サービスリクエストメッセージを送信する（ステップＳ６０４）。一方、登録済みのパケットフィルタが存在しない場合は、コネクティッドモードであるＵＥ１１０は、受信したページングの中にＥＴＷＳ（Earthquake and Tsunami Warning service）フラグやＳＩＢ（System Information Block）変更フラグがセットされていない限り受信処理を行わない。なお、図６において、ＵＥ１１０がアイドルモードである場合も同様に、登録済みのパケットフィルタが存在する場合は、アプリケーションＡを起動し、サービスリクエストを送信する。一方、パケットフィルタが存在しない場合は、アプリケーションの起動は行わず、サービスリクエストメッセージを送信する。また、制御メッセージとしてＳＭＳを用いた場合は、コネクティッドモードであるＵＥ１１０がＳＭＳを受信した際に、そのＳＭＳがパケット受信通知であると判断した場合は、アプリケーションＡを起動し、ＳＭＳ受信応答を返す。一方、ＵＥ１１０がアイドルモードである場合は、ページングを受信し、サービスリクエストを送信した後にＳＭＳを受信する。ＳＭＳ受信応答は、サービスリクエストに限らず、ネットワーク１２０又はサーバ１３０宛てのＳＭＳやＩＰパケットであってもよい。
【００２６】
また、図７は、本開示技術の第１の実施の形態におけるＵＥ１１０の構成の一例を示すブロック図である。ＵＥ１１０は、インタフェース７０１、コネクション管理部７０２、コンテキスト保持部７０３、制御メッセージ受信部７０４、アプリケーション制御部７０５、アプリケーション７０６を備えている。コネクション管理部７０２は、ＵＥ１１０がネットワーク１２０との間に確立したコネクション／ベアラを管理する機能であり、ベアラＩＤ（ＥＰＳベアラＩＤ）の管理を行うとともに、アプリケーション７０６のパケットを送受信するためのベアラの確立・維持などを行う。また、コネクション管理部７０２は、アプリケーション制御部７０５の指示を受け、アプリケーション７０６に関するパケットに対して制御メッセージ送信要求を生成し、ネットワーク１２０へ送信する。また、コンテキスト保持部７０３は、例えば、ネットワーク１２０に登録しているパケットフィルタの保持・管理などを行う。また、制御メッセージ受信部７０４は、コネクション管理部７０２が制御メッセージ送信要求を送信したあとに受信した制御メッセージの受信処理を行う。受信した制御メッセージが、制御メッセージ送信要求によってネットワーク１２０へ登録されたフィルタ情報に基づいてネットワーク１２０が送信した制御メッセージである場合は、制御メッセージ受信部７０４は、アプリケーション制御部７０５に対して、アプリケーション７０６を起動するよう指示する。また、アプリケーション制御部７０５は、アプリケーション７０６が停止した場合に、コネクション管理部７０２に対して、アプリケーション７０６用のパケットに対して制御メッセージ送信要求を送信するよう指示する。
【００２７】
なお、本開示技術の第１の実施の形態を実現するＵＥ１１０は、例えば、サーバ１３０などの所定の通信装置から送信されたＵＥ１１０のアプリケーション宛のリクエストメッセージが存在することを示す制御メッセージをネットワークから受信する制御メッセージ受信部、制御メッセージを受信したときにリクエストメッセージの処理を行うアプリケーションを起動するアプリケーション起動部、アプリケーションを起動したときにアプリケーションの起動を示す応答メッセージ（制御メッセージに対する応答）をネットワークへ送信する応答メッセージ送信部、ネットワーク装置がアプリケーション宛のリクエストメッセージを受信したときに制御メッセージをＵＥ１１０へ送信するよう要求する制御メッセージ送信要求を、例えば特定のアプリケーションを終了する際にネットワークへ送信する制御メッセージ送信要求部、アプリケーション宛のリクエストメッセージを識別するための識別情報を前記制御メッセージ送信要求に付加する識別情報付加部などを有しているとも言える。
【００２８】
なお、図７に図示されている各機能ブロック、あるいは、これらの機能ブロックと同等の機能を有する各処理部は、ハードウェア、ソフトウェア、あるいはこれらの組み合わせによって実現されてもよい。
【００２９】
また、図８は、本開示技術の第１の実施の形態におけるネットワーク１２０の構成の一例を示すブロック図である。なお、図８はネットワーク１２０を構成しているネットワークエンティティの機能を模式的に表すものであり、各ネットワークノードに機能が分散していてもよい。ネットワーク１２０は、インタフェース８０１、コネクション管理部８０２、パケット送信部８０３、パケット受信部８０４、制御メッセージ送信判断部８０５を備えている。コネクション管理部８０２は、ＵＥ１１０との間に確立されているコネクション／ベアラを管理する機能であり、アプリケーションＡのパケットを送受信するためのベアラの確立・維持なども行う。また、制御メッセージ送信判断部８０５は、パケット受信部８０４から受信パケットを渡された際に、保持しているフィルタ情報に基づき、受信したパケットに一致するフィルタ情報を特定する。特定したフィルタ情報に、制御メッセージ送信要求が含まれている場合には、制御メッセージ送信判断部８０５は、コネクション管理部８０２に対してＵＥ１１０宛の制御メッセージを送信するよう指示する。一方、制御メッセージ送信要求が含まれておらず、かつコネクティッドモードである場合には、制御メッセージ送信判断部８０５は、ベアラを用いてパケットを送信するようパケット送信部８０３へ指示する。また、制御メッセージ送信判断部８０５は、ＵＥ１１０から登録されたパケットフィルタ（フィルタ情報）を含むＴＦＴの保持・管理なども行う。また、パケット受信部８０４は、ＭＴＣサーバ１３０からＵＥ１１０宛に送信されたパケットを受信し、受信したパケットを制御メッセージ送信判断部８０５へ渡す。また、パケット送信部８０３は、制御メッセージ送信判断部８０５からの指示を受け、ベアラを用いてパケットを送信する。
【００３０】
なお、本開示技術の第１の実施の形態を実現するネットワーク１２０（ネットワーク装置）は、例えば、サーバ１３０などの所定の通信装置から受信したＵＥ１１０のアプリケーション宛のリクエストメッセージを格納するバッファ、ＵＥ１１０のアプリケーション宛のリクエストメッセージが存在することを示す制御メッセージをＵＥ１１０へ送信する制御メッセージ送信部、ＵＥ１１０でアプリケーションが起動されたことを示す応答メッセージをＵＥ１１０から受信すると、バッファリングしているＵＥ１１０のアプリケーション宛のリクエストメッセージを転送するメッセージ転送部、ＵＥ１１０のアプリケーション宛のリクエストメッセージを受信したときに制御メッセージを送信するよう要求する制御メッセージ送信要求を保持する制御メッセージ送信要求保持部、制御メッセージ送信要求に付加されているＵＥ１１０のアプリケーション宛のリクエストメッセージを識別するための識別情報に基づいて、制御メッセージを送信すべきＵＥ１１０のアプリケーション宛のリクエストメッセージを特定する制御メッセージ送信対象特定部などを有しているとも言える。
【００３１】
なお、図８に図示されている各機能ブロック、あるいは、これらの機能ブロックと同等の機能を有する各処理部は、ハードウェア、ソフトウェア、あるいはこれらの組み合わせによって実現されてもよい。
【００３２】
また、図９は、本開示技術の第１の実施の形態において、ネットワーク１２０内に存在するエンティティを詳細に表したネットワーク構成の一例を示す図である。ネットワーク１２０は、ＩＷＦ（Interworking Function、ＭＴＣ−ＩＷＦやプロキシ、ＤＴ−ＧＷ（Device Trigger Gateway、DT Functionとも呼ばれる）９０１、ＰＧＷ（Packet Data Network Gateway）（又はｅＰＤＧ（evolved Packet Data Network Gateway、ＧＧＳＮ（GPRS Gateway Supporting Node））９０２、ＳＧＷ（Serving Gateway）９０３、ＳＧＳＮ（Serving GPRS Supporting Node）／ＭＭＥ（Mobility Management Entity）９０４（以下、単にＭＭＥ９０４と記載する）、ｅＮＢ（eNodeB、又はNodeB、ＲＮＣ（Radio Network Controller））９０５、ＨＬＲ（Home Location Register）／ＨＳＳ（Home Subscriber Server）９０６によって構成される。なお、ＭＴＣサーバ１３０は、３ＧＰＰネットワーク１２０の中に存在していてもよい。また、ＭＴＣサーバ１３０とＩＷＦ９０１間のインタフェースは一般的にＭＴＣｓｐインタフェースと呼ばれる。
【００３３】
例えば、ＭＴＣサーバ１３０から送信されたトリガメッセージ又はパケットは、ＩＷＦ９０１又はＰＧＷ９０２によって受信される。図１０は、本開示技術の第１の実施の形態におけるＩＷＦ９０１の構成の一例を示すブロック図である。ＩＷＦ９０１は、ネットワークへ接続するインタフェース１００１、トリガメッセージ受信部１００２、メッセージ変換部１００３を有している。トリガメッセージ受信部１００２は、ＭＴＣサーバ１３０から送信されたトリガメッセージ（Ｃ−ｐｌａｎｅパケット）を受信する。また、メッセージ変換部１００３は、ＭＴＣサーバ１３０から受信したトリガメッセージに応じて、ＵＥ１１０をトリガするための方法を選択し、確立済みのベアラを用いる場合は、Ｃ−ｐｌａｎｅのトリガメッセージをＵ−ｐｌａｎｅのＩＰパケットに変換して送信するエンティティである。また、確立済みのベアラを用いてＵ−ｐｌａｎｅパケットを送信するのではなく、制御メッセージを送信すると判断した場合は、ＭＴＣサーバ１３０から受信したトリガメッセージの中の情報を含む制御メッセージに変換する。例えば、メッセージ変換部１００３は、ＭＴＣサーバ１３０から受信したトリガメッセージに応じて、ＳＭＳを用いることを判断した場合は、ＳＭＳ−ＳＣ／ＩＰ−ＳＭ−ＧＷなどのＳＭＳの送信を担うエンティティに対して、ＵＥ１１０宛てのＳＭＳの送信を指示する。別の例として、ＣＢＳを用いることを判断した場合は、ＣＢＣ（Cell Broadcast Center）などのＣＢＳメッセージの送信を担うエンティティに対して、ＵＥ１１０宛てのＣＢＳメッセージの送信を指示する。
【００３４】
なお、図１０に図示されている各機能ブロック、あるいは、これらの機能ブロックと同等の機能を有する各処理部は、ハードウェア、ソフトウェア、あるいはこれらの組み合わせによって実現されてもよい。
【００３５】
また、図１１は、本開示技術の第１の実施の形態におけるＭＴＣサーバ１３０の構成の一例を示すブロック図である。ＭＴＣサーバ１３０は、ネットワークへ接続するインタフェース１１０１、トリガメッセージ送信部１１０２、アプリケーション１１０３を有している。トリガメッセージ送信部１１０２は、アプリケーション１１０３の指示を受け、ＵＥ１１０宛のトリガメッセージ（パケット）を送信する。その際に、ＭＴＣサーバ１３０が、ＵＥ１１０のＩＰアドレスを知っている場合は、ＵＥ１１０宛のＵ−ｐｌａｎｅのデータパケットとして送信することで、ＰＧＷ９０２によって受信される。一方、ＵＥ１１０のＩＰアドレスを知らない場合は、ＵＥ１１０のＩＤ（ＩＭＳＩ（International Mobile Subscriber Identity）や、ＵＲＩ（Uniform Resource Identifier）など）を用いたＣ−ｐｌａｎｅのメッセージとしてＩＷＦ９０１へ送信する。なお、ＩＷＦ９０１によって行われるメッセージ変換機能を利用できる場合は、ＭＴＣサーバ１３０がＵＥ１１０のＩＰアドレスを知っていたとしてもＣ−ｐｌａｎｅのメッセージをＩＷＦ９０１へ送信してもよい。
【００３６】
なお、本明細書では、ＭＴＣサーバ１３０からネットワーク１２０へ送信されるメッセージ（ＰＧＷ９０２によって受信されるデータパケット（リクエストメッセージ）、又は、ＩＷＦ９０１によって受信されるＣ−Ｐｌａｎｅのメッセージ）をまとめて、ユーザ端末のアプリケーション宛のメッセージと呼ぶことがある。
【００３７】
なお、図１１に図示されている各機能ブロック、あるいは、これらの機能ブロックと同等の機能を有する各処理部は、ハードウェア、ソフトウェア、あるいはこれらの組み合わせによって実現されてもよい。
【００３８】
次に、図９に図示されているネットワーク構成に基づいて、本開示技術の第１の実施の形態に係る動作の一例について説明する。図１２は、本開示技術の第１の実施の形態において、ＩＷＦ９０１を介してメッセージを送信した場合の一例を示すシーケンス図である。図１２において、ＵＥ１１０は、制御メッセージ送信要求（ページング送信要求）として、Bearer Modification Request（ベアラ変更要求）メッセージを送信し（ステップＳ１２０１）、サーバ１３０からのメッセージに対して制御メッセージ（ページング）を送信することを要求する。Bearer Modification Requestメッセージには、例えば図１６に模式的に示されているように、ネットワーク１２０内にＴＦＴ（Traffic Flow Template、トラフィックフローテンプレート）として保持される情報として、サーバ１３０からのパケットを識別するパケットフィルタ（パケット識別情報を含む）と、該当パケットを送信する際に使用するベアラ識別子（ベアラＩＤ）と、制御メッセージ送信要求（ページング送信要求）が含まれている。Bearer Modification Requestメッセージは、ネットワーク１２０のＰＧＷ９０２によって受信され、ＰＧＷ９０２は、メッセージに含まれている情報をＴＦＴとして保持する（ステップＳ１２０２）。ＰＧＷ９０２が保持するＴＦＴによって、例えばパケットの送信に使用するベアラ識別子（ベアラＩＤ１）と、パケット識別情報（パケットのソースアドレスがサーバＡのアドレス）に一致するパケットを受信した場合には制御メッセージ（ページング）の送信を行うことが示される。
【００３９】
ここで、ＭＴＣサーバ１３０が、アプリケーションＡに関するパケットをＵＥ１１０へ送信するとする。ここでは、ＭＴＣサーバ１３０は、ＵＥ１１０のＩＰアドレスを知らないと想定し、ＭＴＣサーバ１３０は、ＵＥ１１０のＩＤを含むトリガメッセージをＩＷＦ９０１へ送信する(ステップＳ１２０３)。ＩＷＦ９０１は、受信したトリガメッセージに基づいてＩＰパケットを生成する（ステップＳ１２０４）。具体的には、ＩＷＦ９０１は、受信したメッセージを、メッセージ内のＩＤから特定したＵＥ１１０のＩＰアドレスをあて先アドレスとして設定したＩＰパケットに変換してＰＧＷ９０２へ転送する（ステップＳ１２０５）。
【００４０】
例えば、ＰＧＷ９０２とＳＧＷ９０３の間のインタフェース（Ｓ５／Ｓ８）としてＧＴＰ（GPRS Tunneling Protocol）プロトコルが用いられている場合は、ＰＧＷ９０２は、ＩＷＦ９０１からＵＥ１１０宛のパケットを受信した際に、そのパケットに該当するパケットフィルタを検索し、パケットフィルタの中に含まれているページング要求に従って、パケットにページング要求を付加して（ステップＳ１２０６）、ページング要求が付加されたパケットをＳＧＷ９０３へ転送する（ステップＳ１２０７）。その際、パケットを含むＧＴＰメッセージのＧＴＰヘッダの中にページング要求を付加することが望ましい。
【００４１】
ＳＧＷ９０３は、ページング要求が付加されているＧＴＰメッセージを受信すると、ＵＥ１１０がコネクティッドモードであったとしても、ＭＭＥ９０４に対してＤＤＮ（DownLink Data Notification）メッセージを送信する（ステップＳ１２０８）。つまり、ＳＧＷ９０３は、ＵＥ１１０が接続しているｅＮＢ９０５に関する情報を保持していたとしても、ページング要求が付加されている場合には、パケットをｅＮＢ９０５へ転送する代わりに、ＭＭＥ９０４に対してページングを送信するよう指示する。なお、ＳＧＷ９０３は、ＵＥ１１０の動作モード（コネクティッドモード又はアイドルモード）を把握することが可能である。
【００４２】
なお、図１２では、ＰＧＷとＳＧＷの間のインタフェース（Ｓ５／Ｓ８）としてＧＴＰプロトコルが用いられている場合が図示されているが、ＰＧＷとＳＧＷの間のインタフェース（Ｓ５／Ｓ８）でＰＭＩＰ（Proxy Mobile IP）プロトコルが用いられている場合には、ＰＧＷ９０２は、ＩＷＦ９０１からＵＥ１１０宛のパケットを受信した際に、そのパケットにＧＲＥ（Generic Routing Encapsulation）ヘッダを付加してＳＧＷ９０３宛に転送する。なお、ＧＴＰプロトコルが用いられている場合のＰＧＷ９０２及びＳＧＷ９０３の動作の一例は図１３及び図１４を参照しながら、ＰＭＩＰプロトコルが用いられている場合のＳＧＷ９０３の動作の一例は図１５を参照しながらそれぞれ後述する。
【００４３】
ＭＭＥ９０４は、ＳＧＷ９０３からＤＤＮを受信すると、ｅＮＢ９０５に対してページングメッセージを送信し（ステップＳ１２０９）、それを受けたｅＮＢ９０５はＵＥ１１０宛のページングを送信する（ステップＳ１２１０）。なお、ＭＭＥ９０４が、コネクティッドモードのＵＥ１１０に対するＤＤＮメッセージをエラーとして扱ってしまう場合は、ＳＧＷ９０３は、ＤＤＮメッセージの中にページング要求を付加することによって、ページングの送信を指示することが望ましい。これにより、ＭＭＥ９０４は、コネクティッドモードのＵＥ１１０に対するページングメッセージの送信が求められていることを認識することができる。
【００４４】
ｅＮＢ９０５からページングメッセージを受信したＵＥ１１０は、図６で説明したように、自身がコネクティッドモードである場合は、アプリケーションＡを起動して（ステップＳ１２１１）、サービスリクエストメッセージをページング応答として送信する（ステップＳ１２１２）。サービスリクエストメッセージを受信したＭＭＥ９０４は、ＳＧＷ９０３に対してＤＤＮ応答メッセージを送信する（ステップＳ１２１４）。そして、ＤＤＮ応答メッセージを受信したＳＧＷ９０３は、バッファリングしていたパケットをＵＥ１１０へ転送する（ステップＳ１２１６）。ＵＥ１１０は、既にアプリケーションＡを起動しているため、転送されたパケットを受信することができる（ステップＳ１２１７）。なお、ＤＤＮ応答メッセージとしては、Modify Bearer Requestメッセージなどを用いることができる。
【００４５】
なお、ＵＥ１１０は、例えば図１７に模式的に示されているように、サービスリクエストメッセージの中に、起動したアプリケーションＡのパケットの送受信に用いるベアラのベアラＩＤ及び／又はパケット識別情報を含めてもよい。この場合、サービスリクエストメッセージを受信したＭＭＥ９０４は、メッセージの中のベアラＩＤと、ＳＧＷ９０３から受信したベアラＩＤが一致した場合に、そのサービスリクエストメッセージが、そのベアラＩＤで識別されるベアラを用いてパケットの送受信が行われるアプリケーションを起動したコネクティッドモードであるＵＥ１１０が送信したメッセージであることを認識することができる。ＭＭＥ９０４は、ベアラＩＤを含むサービスリクエストメッセージを受信した際に、ベアラＩＤのチェックを行って（ステップＳ１２１３）、ＤＤＮ応答メッセージをＳＧＷ９０３へ送信するかどうかを決定してもよい。
【００４６】
また、ＭＭＥ９０４からＤＤＮ応答メッセージを受信したＳＧＷ９０３は、ＤＤＮ応答メッセージの中に含まれているパケット識別情報（例えば、サーバ１３０のアドレス）が、ＰＧＷ９０２から受信したＧＴＰメッセージの中のパケットの情報（例えば、パケットのソースアドレス）と一致している場合に、該当するアプリケーションＡを起動したＵＥ１１０が送信したメッセージに基づき送信されたＤＤＮ応答メッセージであることを認識することができる。ＳＧＷ９０３は、パケット識別情報を含むＤＤＮ応答メッセージを受信した際に、パケット識別情報のチェックを行って（ステップＳ１２１５）、パケットをＵＥ１１０へ転送するかどうかを決定してもよい。
【００４７】
また、図１３は、本開示技術の第１の実施の形態において、ＧＴＰプロトコルが用いられている場合のＰＧＷ９０２の処理の一例を示すフローチャートである。なお、図１３の処理は、図１２のステップＳ１２０６でＰＧＷ９０２によって行われる処理に対応している。ＰＧＷ９０２とＳＧＷ９０３の間のインタフェース（Ｓ５／Ｓ８）としてＧＴＰ（GPRS Tunneling Protocol）プロトコルが用いられている場合は、図１３に示すように、ＰＧＷ９０２は、ＩＷＦ９０１又はサーバ１３０からＵＥ１１０宛のパケットを受信した際に（ステップＳ１３０１）、そのパケットに該当するパケットフィルタを検索する（ステップＳ１３０２）。さらに、該当するパケットフィルタが見つかった場合には、パケットフィルタの中にページング要求が含まれているかどうかを確認する（ステップＳ１３０３）。パケットフィルタの中にページング要求が含まれている場合には、パケットにページング要求を付加してＳＧＷ９０３へ転送する（ステップＳ１３０４）。その際、パケットを含むＧＴＰメッセージのＧＴＰヘッダの中にページング要求を付加することが望ましい。なお、ステップＳ１３０３の確認でパケットフィルタの中にページング要求が含まれていなかった場合には、ページング要求を付加せずに、パケットを含むＧＴＰメッセージを送信する（ステップＳ１３０６）。また、ステップＳ１３０２でパケットフィルタが見つからなかった場合には、デフォルトベアラでパケットを転送するか、あるいは、パケットを廃棄する（ステップＳ１３０５）。
【００４８】
また、図１４は、本開示技術の第１の実施の形態において、ＧＴＰプロトコルが用いられている場合のＳＧＷ９０３の処理の一例を示すフローチャートである。なお、図１４の処理は、図１２のステップＳ１２０７でＧＴＰメッセージを受信した後にＳＧＷ９０３によって実行される処理に対応している。図１４において、ＳＧＷ９０３は、ＰＧＷ９０２からＧＴＰメッセージを受信すると（ステップＳ１４０１）、ＧＴＰメッセージにページング要求が付加されているかどうかを確認する（ステップＳ１４０２）。ＰＧＷ９０２から受信したＧＴＰメッセージにページング要求が付加されている場合には、ＳＧＷ９０３は、ＵＥ１１０がコネクティッドモードであったとしても、ＭＭＥ９０４に対してＤＤＮ（Down Link Data Notification）メッセージを送信する（ステップＳ１４０３）。つまり、ＳＧＷ９０３は、ＵＥ１１０が接続中のｅＮＢ９０５に関する情報を保持していたとしてもページング要求が付加されている場合には、パケットをｅＮＢ９０５へ転送する代わりに、ＭＭＥ９０４に対してページングを送信するよう指示する。この場合、ＵＥ１１０は、ページングを受信すると、アプリケーションを起動してＤＤＮ応答メッセージを送信する。ＳＧＷ９０３は、ＵＥ１１０からのＤＤＮ応答メッセージを待機及び受信した後（ステップＳ１４０４）、パケットをｅＮＢ９０５へ転送する（ステップＳ１４０５）。
【００４９】
一方、ＰＧＷ９０２から受信したＧＴＰメッセージにページング要求が付加されていない場合には、ＵＥ１１０がコネクティッドモードかどうかを確認する（ステップＳ１４０６）。ＵＥ１１０がコネクティッドモードであった場合は、ＳＧＷ９０３は、パケットをｅＮＢ９０５へ転送する（ステップＳ１４０５）。一方、ＵＥ１１０がアイドルモードであった場合は、ＭＭＥ９０４に対してＤＤＮメッセージを送信し（ステップＳ１４０７）、ＤＤＮ応答メッセージを待機及び受信した後（ステップＳ１４０８）、パケットをｅＮＢ９０５へ転送する（ステップＳ１４０５）。なお、この場合、ＵＥ１１０は、ページングを受信するとアイドルモードからコネクティッドモードに状態を変更するとともに、アプリケーションを起動してＤＤＮ応答メッセージを送信する。
【００５０】
また、図１５は、本開示技術の第１の実施の形態において、ＰＭＩＰプロトコルが用いられている場合のＳＧＷの処理の一例を示すフローチャートである。なお、図１５の処理は、図１２のステップＳ１２０７において、ＳＧＷ９０３が、ＧＴＰメッセージではなくＧＲＥパケットを受信した後に実行される処理に対応している。ＰＧＷ９０２とＳＧＷ９０３の間のインタフェース（Ｓ５／Ｓ８）でＰＭＩＰ（Proxy Mobile IP）プロトコルが用いられている場合には、ＰＧＷ９０２は、ＩＷＦ９０１又はサーバ１３０からＵＥ１１０宛のパケットを受信した際に、そのパケットにＧＲＥヘッダを付加してＳＧＷ９０３宛に転送する。ＳＧＷ９０３は、ＧＲＥヘッダが付加されたカプセル化パケット（ＧＲＥパケット）をＰＧＷ９０２から受信すると（ステップＳ１５０１）、受信したパケットに該当するパケットフィルタを検索し（ステップＳ１５０２）、見つかったパケットフィルタの中にページング要求が付加されているかどうか確認する（ステップＳ１５０３）。ページング要求が付加されている場合には、ＳＧＷ９０３は、ＭＭＥ９０４に対してＤＤＮメッセージを送信する（ステップＳ１５０４）。つまり、ここでもＳＧＷ９０３は、ＵＥ１１０が接続中のｅＮＢ９０５に関する情報を保持していたとしても、パケットフィルタの中にページング要求が付加されていた場合には、パケットをｅＮＢ９０５へ転送する代わりに、ＭＭＥ９０４に対してページングを送信するよう指示する。
【００５１】
一方、パケットフィルタの中にページング要求が付加されていない場合には、ＵＥ１１０がコネクティッドモードかどうかを確認する（ステップＳ１５０５）。ＵＥ１１０がコネクティッドモードであった場合は、ＳＧＷ９０３は、通常通り、パケットをｅＮＢ９０５へ転送する（ステップＳ１５０６）。一方、ＵＥ１１０がアイドルモードであった場合は、ＭＭＥ９０４に対してＤＤＮメッセージを送信し（ステップＳ１５０７）、ＤＤＮ応答メッセージを待機及び受信した後（ステップＳ１５０８）、パケットをｅＮＢ９０５へ転送する（ステップＳ１５０６）。なお、この場合、ＵＥ１１０は、ページングを受信するとアイドルモードからコネクティッドモードに状態を変更するとともに、アプリケーションを起動してＤＤＮ応答メッセージを送信する。また、ステップＳ１５０２でパケットフィルタが見つからなかった場合には、デフォルトベアラでパケットを転送するか、パケットを廃棄する（ステップＳ１５０９）。
【００５２】
また、図２３は、本開示技術の第１の実施の形態において、ＩＷＦ９０１がＭＭＥ９０４に対して直接ページングの送信を指示する場合の一例を示すシーケンス図である。なお、以下では、主に、上述の図１２に図示されているシーケンス図との相違点について説明し、同一又は類似の動作については説明を省略する。
【００５３】
図２３に示すように、ＵＥ１１０は制御メッセージ送信要求をＩＷＦ９０１へ送信することも可能である（ステップＳ２３０１）。この場合、ＩＷＦ９０１が、ＵＥ１１０のパケットフィルタを保持し（ステップＳ２３０３）、サーバ１３０から受信したトリガメッセージが、保持しているパケットフィルタに該当するパケットであった場合は、トリガメッセージをバッファリングするとともに、ＭＭＥ９０４に対して、ＵＥ１１０宛てのページングを送信するよう指示する（ステップＳ２３０５）。そして、ＵＥ１１０がページング受信に応じてアプリケーションを起動して応答メッセージを返した場合、ＭＭＥ９０４は、ページング要求応答をＩＷＦへ送信する（ステップＳ２３０７）。ＩＷＦ９０１は、ＭＭＥ９０４からページング要求応答を受信した場合、バッファリングしていたサーバ１３０から受信したトリガメッセージをＵＥ１１０宛てのパケットに変換して送信する（ステップＳ２３０９）。パケットは確立済みのコネクション／ベアラを介してＵＥ１１０へ転送される。なお、ＩＷＦ９０１は、サーバ１３０から受信したトリガメッセージをＵＥ１１０宛てのＳＭＳとして送信してもよい。
【００５４】
なお、ＵＥ１１０は、ページング要求応答をサーバ１３０へ送信してもよい。この場合、サーバ１３０は、ＵＥ１１０からページング要求応答を受信した後、ＵＥ１１０宛てにアプリケーションＡ用のパケットの送信を行う。また、この場合、ＩＷＦ９０１は、サーバ１３０から受信したトリガメッセージのバッファリングを省略してもよい。また、ページングを受信しアプリケーションを起動したＵＥ１１０は、ページング要求応答を返さずに、パケットの受信を待機していてもよい。この場合、ＩＷＦ９０１又はサーバ１３０は一定時間経過後に、ＵＥ１１０宛てにパケットを転送する。
【００５５】
また、図２９は、本開示技術の第１の実施の形態において、ＩＷＦ９０１がＳＭＳ−ＳＣ（SMS Service Center）／ＩＰ−ＳＭ−ＧＷ（IP Short Message Gateway）に対して制御メッセージとしてＳＭＳの送信を指示する場合の一例を示すシーケンス図である。なお、以下では、主に、上述の図２３に図示されているシーケンス図との相違点について説明し、同一又は類似の動作については説明を省略する。
【００５６】
図２９に示すように、ＩＷＦ９０１が、ＵＥ１１０のパケットフィルタを保持し、サーバ１３０から受信したトリガメッセージが、保持しているパケットフィルタに該当するパケットであった場合は、トリガメッセージをバッファリングするとともに、ＳＭＳ−ＳＣ／ＩＰ−ＳＭ−ＧＷ９１０に対して、ＵＥ１１０宛てのＳＭＳを送信するよう指示する（ステップＳ２９０１）。そして、ＳＭＳ−ＳＣ／ＩＰ−ＳＭ−ＧＷ９１０は、ＵＥ１１０に対してＳＭＳを送信し（ステップＳ２９０３）、ＵＥ１１０はＳＭＳの受信に応じてアプリケーションを起動する（ステップＳ２９０５）。アプリケーションを起動したＵＥ１１０は、ＩＷＦ９０１に対してＳＭＳ受信応答を返す（ステップＳ２９０７）。ＩＷＦ９０１は、ＵＥ１１０から、ＳＭＳ受信応答を受信した場合、バッファリングしていたサーバ１３０から受信したトリガメッセージをＵＥ１１０宛てのパケットに変換して送信する（ステップＳ２９０９）。パケットは確立済みのコネクション／ベアラを介してＵＥ１１０へ転送される。なお、ＵＥ１１０は、ＳＭＳ受信応答をサーバ１３０へ送信してもよい。この場合、サーバ１３０は、ＵＥ１１０からＳＭＳ受信応答を受信した後、ＵＥ１１０宛てにアプリケーションＡ用のパケットの送信を行う。また、この場合、ＩＷＦ９０１は、サーバ１３０から受信したトリガメッセージのバッファリングを省略してもよい。また、ＳＭＳを受信しアプリケーションを起動したＵＥ１１０は、ＳＭＳ受信応答を返さずに、パケットの受信を待機していてもよい。この場合、ＩＷＦ９０１又はサーバ１３０は一定時間経過後に、ＵＥ１１０宛てにパケットを転送する。
【００５７】
なお、ＵＥ１１０は、ＰＧＷ９０２又はＩＷＦ９０１に対して、ページングやＳＭＳ、ＣＢＳなどの特定の制御メッセージを指定した制御メッセージ送信要求を送信してもよいし、特に指定せずに制御メッセージ送信要求を送信してもよい。後者の場合、ＰＧＷ９０２又はＩＷＦ９０１が、サーバ１３０からパケットを受けた際に、どの制御メッセージを用いてＵＥ１１０をトリガするかを判断する。
【００５８】
また、図３１は、本開示技術の第１の実施の形態において、ＩＷＦ９０１がＣＢＣ９１３に対して制御メッセージとしてＣＢＳメッセージ（ブロードキャストメッセージ）の送信を指示する場合の一例を示すシーケンス図である。なお、以下では、主に、上述の図２３に図示されているシーケンス図との相違点について説明し、同一又は類似の動作については説明を省略する。
【００５９】
ＵＥ１１０は、ＩＷＦ９０１に対して、サーバ１３０からのトリガメッセージを受信した際にＣＢＳメッセージをＵＥ１１０宛てに送信することを要求する（ステップＳ３１０１）。ＩＷＦ９０１は、ＵＥ１１０宛てのトリガメッセージをサーバ１３０から受信した際に、受信したトリガメッセージが、ＵＥ１１０からＣＢＳメッセージの送信を要求されたトリガメッセージに該当する場合に、ネットワークに対してＣＢＳメッセージ（ブロードキャストメッセージ）を送信するよう要求する（ステップＳ３１０３）。なお、サーバ１３０から受信したトリガメッセージに、ＵＥ１１０へ通知するべき情報（例えば、起動するアプリケーションのＩＤやメッセージを特定するための情報、ＡＰＮ、サーバのＵＲＩやＩＰアドレスなどの確立するコネクションに関する情報）が含まれている場合には、ＩＷＦ９０１は、それらの情報をＣＢＳメッセージの中に含めるよう指示してもよい。ＣＢＳメッセージを送信する具体的な方法としては、ＣＢＥ（Cell Broadcast Entity）であるＩＷＦ９０１はＣＢＣ（Cell Broadcast Center）９１３に対してＵＥ１１０宛てのＣＢＳメッセージの送信を要求し、ＣＢＣ９１３がＲＮＣ９１４及びＮｏｄｅＢ９１５を介してＵＥ１１０へＣＢＳメッセージを送信する。また、ＩＷＦ９０１は、送信するＣＢＳメッセージの中に、受信するＵＥを識別するＩＤとして、ＵＥ１１０のＩＤのみを含めてもよいし、ＵＥ１１０が属するグループのＩＤを含めてもよい。
【００６０】
なお、サーバ１３０が、あるグループに属している複数のＵＥに対してトリガメッセージを送信する場合、ページングの代わりにＣＢＳメッセージを用いることで、ネットワークが送信するメッセージがブロードキャストメッセージ１つになるため、複数のページングやＳＭＳなどを送信する必要がなくなり、ネットワークへの負荷を減らせるという効果が得られる。
【００６１】
ＵＥ１１０は、自身宛のＣＢＳメッセージを受けた際に、アプリケーションＡを起動してから、ＩＷＦ９０１に対してＣＢＳメッセージの受信応答を返す（ステップＳ３１０５）。ＣＢＳメッセージの受信応答を受信したＩＷＦ９０１は、サーバ１３０から受信したトリガメッセージに基づいて生成したパケットをＵＥ１１０宛に送信する（ステップＳ３１０７）。ＩＷＦ９０１へ受信応答を返す方法の具体的な例としては、ＵＥ１１０は、ＣＢＳの受信応答をＲＮＣ９１４（ＬＴＥ／ＳＡＥではｅＮｏｄｅＢ）へ送信する。それを受けたＲＮＣ９１４は、ＣＢＣ９１３に対してＲｅｐｏｒｔ−Ｓｕｃｃｅｓｓを送信すると、ＣＢＣ９１３からＡｃｋがＩＷＦ９０１へ送信される。別の例としては、ＵＥ１１０は、ＣＢＳ受信応答をＳＧＳＮ９１２（ＬＴＥ／ＳＡＥではＭＭＥ）へ送信し、ＳＧＳＮ９１２がＩＷＦ９０１へＡｃｋを送信してもよい。この場合、ＳＧＳＮ９１２へ送信するメッセージとして、Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔを使用することができる。また、Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔには、ＣＢＳの受信応答であることをＳＧＳＮ９１２へ通知するための情報（Information Element）を含めてもよい。
【００６２】
ＩＷＦ９０１は、ＵＥ１１０がＣＢＳメッセージを受けてネットワークへ接続したことを示すＡｃｋを受信すると、サーバ１３０から受信したトリガメッセージに基づいてＩＰパケットを生成し、ＵＥ１１０宛てに送信する。以上によって、ＵＥ１１０は、アプリケーションＡを起動した状態でアプリケーションＡ宛のパケットを受信することができるため、アプリケーションを起動する前にパケットを受信した場合に必要なバッファリング処理も不要となる。
【００６３】
さらに、本開示技術の第１の実施の形態で説明した手法は、ＵＥ１１０に対してネットワークへの接続を要求する、及び／又は新たなコネクションの確立を要求するためにも有効である。
【００６４】
例えば、サーバ１３０は、ＵＥ１１０と通信をするために、ＩＷＦ９０１に対してＵＥ１１０宛てのトリガメッセージを送信する際に、ＵＥ１１０とサーバ１３０が存在するネットワークとの間にまだ適切なコネクションが確立されていないと判断される場合、トリガメッセージに制御メッセージ送信要求を付加する。これは、ＵＥ１１０が確立済みのコネクションを持っていたとしても、そのコネクションは上記のトリガメッセージをデータパケットとして転送するのに適していない、あるいはこれから開始する通信のデータ転送に適していないと判断される場合も含んでいる。適していないという意味は、例えば、既存のコネクションのＡＰＮ（Access Point Name）と新たに開始する通信のＡＰＮとが異なる場合や、既存のコネクションのＱｏＳ（Quality of Service）が新たな通信に合っていない場合などである。
【００６５】
これにより、ＩＷＦ９０１が、サーバ１３０から受信したＵＥ１１０宛てのトリガメッセージに含まれる制御メッセージ送信要求に従って、制御メッセージを用いてトリガメッセージを転送することで、その通信のデータパケットの転送に使用できるコネクションを確立するようＵＥ１１０に指示することができる。
【００６６】
なお、ＩＷＦ９０１は、ＵＥ１１０が制御メッセージに応答したことをネットワークから通知された際に、その通知をサーバに１３０に転送してもよい。この場合、ＩＷＦ９０１が、トリガメッセージを基に生成したパケットをＵＥ１１０宛てに転送するのではなく、ＵＥ１１０の応答の通知を受けたサーバ１３０が、ＵＥ１１０に対してパケットを送信する。つまり、サーバ１３０は、ＵＥ１１０のアプリケーションＡを起動、又はＵＥ１１０によるネットワーク接続やコネクションの確立を要求するためにトリガメッセージを送信し、その結果、ＵＥ１１０が制御メッセージに応答したこと（制御メッセージを受信し、アプリケーションＡの起動やネットワーク接続、コネクション確立）の通知を受けた後、ＵＥ１１０に対してデータパケットを送信する。これにより、ネットワーク又はＩＷＦ９０１におけるパケットの生成及びバッファリングによる負荷を減らすことができる。
【００６７】
なお、サーバ１３０は、ＩＷＦ９０１へ送信するトリガメッセージの中に、このトリガメッセージが、ＵＥ１１０に対してアプリケーションＡの起動やネットワーク接続、コネクション確立を要求するためのトリガメッセージであることを意味する情報を含めてもよい。つまり、上記のような情報がトリガメッセージに含まれている場合は、ＩＷＦ９０１は、トリガメッセージに基づいて生成したパケットをＵＥ１１０宛てに送信する必要がないことを認識することができる。
【００６８】
なお、本開示技術の第１の実施の形態で説明した手法は、ＵＥ１１０上のアプリケーションを起動するためだけでなく、ＵＥ１１０からのデータ送信（Mobile Originated Data）を要求するために、ＵＥ１１０に対してダウンリンクデータ（Mobile Terminated Data）を送信することが適切でない場合にも有効である。
【００６９】
例えば、ＵＥ１１０上で起動されているアプリケーションがダウンリンクデータの受信に対応していないアプリケーションであった場合に本開示技術の第１の実施の形態で説明した手法を用いることができる。アプリケーションがダウンリンクパケットの受信に対応していない場合、サーバ１３０やセルラーネットワーク内のノード、及び他のＵＥ１１０から送られてきたデータパケットはＰＧＷ９０２又はＵＥ１１０によって廃棄されてしまう。例えば、ＰＧＷ９０２が保持するＴＦＴにおいて、当該アプリケーション用のパケットにベアラが関連付けられていない場合、ＰＧＷ９０２はそのパケットの転送を行わずに廃棄する。本開示技術の第１の実施の形態で説明した手法を用いることができる別の場合として、ダウンリンクデータを用いてＵＥ１１０に対してデータの送信を指示する場合、複数のＵＥ１１０に対して同時に指示する場合などは、データトラフィック量が増加してしまうため、ダウンリンクデータを使わずにＵＥ１１０に対してデータの送信を指示したい、あるいは指示を受けたい場合なども用いることができる。
【００７０】
図２６は、本開示技術の第１の実施の形態において、制御メッセージとしてページングを用いてＵＥ１１０からのデータ送信をトリガする場合の一例を示すシーケンス図である。なお、以下では、主に、上述の図１２に図示されているシーケンス図との相違点について説明し、同一又は類似の動作については説明を省略する。上記のような場合にＵＥ１１０は、ダウンリンクデータの受信が適切でないアプリケーションに関するパケットを受信した際に制御メッセージを送信することを要求する制御メッセージ送信要求をＰＧＷ９０２へ送信する（ステップＳ２６０１）。ＰＧＷ９０２は、ＩＷＦ９０１から受信したパケットを基に生成したＧＴＰパケットをＳＧＷ９０３へ転送する（ステップＳ２６０２）。このＧＴＰパケットは、ＳＧＷ９０３に対してＵＥ１１０宛てのパケットを転送するためのものではなく、ＵＥ１１０に関するＤＤＮの送信を要求するためのものである。従って、ＳＧＷ９０３は、ＰＧＷ９０２からＧＴＰパケットを受けてＭＭＥ９０４へＤＤＮを送信するが、ＵＥ１１０へのパケットの転送は行わない。そして、ＵＥ１１０がページングを受信した際に、ＵＥ１１０のアプリケーションは、このページングをトリガとして、サーバ１３０やセルラーネットワーク内のノード、他のＵＥ１１０に対してデータの送信を開始する（ステップＳ２６０３）。なお、ページングを受信した際にアプリケーションが起動されていない場合は、ＵＥ１１０はアプリケーションを起動した後、データの送信を開始する。また、ページングを受信した際のＵＥ１１０の別の動作として、ネットワークに対して新たなコネクションの確立を行ってもよい。
【００７１】
また、図２７は、本開示技術の第１の実施の形態において、制御メッセージとしてＳＭＳを用いてＵＥ１１０からのデータ送信をトリガする場合の一例を示すシーケンス図である。ＵＥ１１０は、制御メッセージ（ここではＳＭＳ）を送信することを要求する制御メッセージ送信要求をＩＷＦ９０１へ送信し（ステップＳ２７０１）、パケットフィルタはＩＷＦ９０１に登録される（ステップＳ２７０３）。ＩＷＦ９０１は、サーバ１３０からトリガメッセージを受信した際に、制御メッセージとしてＳＭＳを用いることを判断し、ＳＭＳ−ＳＣ／ＩＰ−ＳＭ−ＧＷ９１０に対してＳＭＳを送信するよう要求する（ステップＳ２７０５）。これにより、例えばＳＭＳ−ＳＣ／ＩＰ−ＳＭ−ＧＷ９１０が、ＵＥ１１０に対してＳＭＳを送信する（ステップＳ２７０７）。
【００７２】
ＳＭＳを受信したＵＥ１１０のアプリケーションは、このＳＭＳの受信をトリガとして、サーバ１３０やセルラーネットワーク内のノード、他のＵＥ１１０に対してデータの送信を開始する（ステップＳ２７０９）。なお、ＳＭＳを受信した際にアプリケーションが起動されていない場合は、ＵＥ１１０はアプリケーションを起動した後、データの送信を開始する。また、サーバ１３０から受信したトリガメッセージに、ＵＥ１１０へ通知するべき情報（例えば、起動するアプリケーションやメッセージを特定するための情報や、ＡＰＮ、サーバのＵＲＩやＩＰアドレスなどの確立するコネクションに関する情報）が含まれている場合には、ＩＷＦ９０１は、その情報がＳＭＳメッセージの中に含まれるようにしてもよい。また、アプリＡには、起動された直後に送信するべきメッセージがあらかじめ設定されていてもよい。これにより、ダウンリンクデータを用いずにＵＥ１１０からのデータ送信を要求することができるため、データトラフィック量の増加を防ぐことができる。また、サーバ１３０が知っているＵＥ１１０のＩＰアドレスが変わっていたとしても、ＵＥ１１０からのデータ送信をトリガすることもできる。なお、ＳＭＳを受信した際のＵＥ１１０の別の動作として、ＳＭＳに含まれているコネクション確立に必要な情報を用いて、ネットワークに対して新たなコネクションの確立を行ってもよい。
【００７３】
また、図３２は、本開示技術の第１の実施の形態において、制御メッセージとしてＣＢＳを用いてＵＥ１１０からのデータ送信をトリガする場合の一例を示すシーケンス図である。ＩＷＦ９０１は、ＵＥ１１０宛てのトリガメッセージをサーバ１３０から受信した際に、受信したトリガメッセージが、ＵＥ１１０からＣＢＳメッセージの送信を要求されたトリガメッセージに該当する場合に、ネットワークに対してＣＢＳメッセージ（ブロードキャストメッセージ）を送信するよう要求する（ステップＳ３２０１）。なお、サーバ１３０から受信したトリガメッセージに、ＵＥ１１０へ通知するべき情報（例えば、起動するアプリケーションやメッセージを特定するための情報や、ＡＰＮ、サーバのＵＲＩやＩＰアドレスなどの確立するコネクションに関する情報）が含まれている場合には、ＩＷＦ９０１は、それらの情報をＣＢＳメッセージの中に含めるよう指示してもよい。ＣＢＳメッセージを送信する具体的な方法としては、ＣＢＥ（Cell Broadcast Entity）であるＩＷＦ９０１はＣＢＣ（Cell Broadcast Center）９１３に対してＵＥ１１０宛てのＣＢＳメッセージの送信を要求し、ＣＢＣ９１３がＲＮＣ９１４及びＮｏｄｅＢ９１５を介してＵＥ１１０へＣＢＳメッセージを送信する。また、ＩＷＦ９０１は、送信するＣＢＳメッセージの中に、受信するＵＥを識別するＩＤとして、ＵＥ１１０のＩＤのみを含めてもよいし、ＵＥ１１０が属するグループのＩＤを含めてもよい。
【００７４】
そのＣＢＳメッセージを受けたＵＥ１１０は、アプリケーションＡを起動した後、アプリケーションＡによるデータパケットをサーバ１３０に対して送信する（ステップＳ３２０３）。また、アプリケーションＡには、起動された直後に送信するべきメッセージがあらかじめ設定されていてもよい。また、ＣＢＳを受信した際のＵＥ１１０の別の動作として、ＣＢＳに含まれているコネクション確立に必要な情報を用いて、ネットワークに対して新たなコネクションの確立を行ってもよい。
【００７５】
なお、３ＧＰＰネットワーク１２０内にＵＥ１１０の情報を管理するノードを設け、ＵＥ１１０は、そのノードに対してフィルタ情報を登録してもよい。この場合、ＰＧＷ９０２又はＩＷＦ９０１は、ＵＥ１１０の情報を管理しているノードに問い合わせ、ＵＥ１１０に対して制御メッセージを送信するべきか否かを判断するようにしてもよい。
【００７６】
以上説明したように、本開示技術の第１の実施の形態によれば、ＵＥ１１０は、起動していないアプリケーション宛のパケットが届く前に、パケット受信通知を示す制御メッセージを受信することができるため、ＵＥ１１０は、制御メッセージの受信をトリガにしてアプリケーションの起動を行ってから、パケットの受信をすることが可能となる。これにより、アプリケーションを常時起動しておくことによるＣＰＵのパワー、ＣＰＵの動作による消費電力やメモリの消費を削減することができる。
【００７７】
（第２の実施の形態）
次に、本開示技術の第２の実施の形態について説明する。本開示技術の第２の実施の形態では、複数のアプリケーションを保持するＵＥ１１０が制御メッセージを受けた際に、どのアプリケーションを起動するべきかを判断できるようにする方法について説明する。
【００７８】
図１８は、本開示技術の第２の実施の形態において、ＵＥ１１０とネットワーク１２０の間で確立されるベアラに対して割り当てるベアラＩＤの一例を示す図である。通常は、１つのベアラに対して１つのＩＤのみが割り当てられるが、第２の実施の形態におけるＵＥ１１０は、アプリケーションごとにベアラＩＤの割り当てを要求する。例えば、ベアラＸを用いるアプリケーションとして２つ存在する場合、アプリケーションＡにはベアラＩＤ１が割り当てられ、アプリケーションＢにはベアラＩＤ２が割り当てられる。また、ベアラＹを用いるアプリケーションＣに対してはベアラＩＤ３が割り当てられる。これにより、ベアラＩＤに基づいて、ベアラＩＤに対応する特定のアプリケーションを識別することが可能となる。なお、各アプリケーションに割り当てられているアプリケーションＩＤを用いてベアラＩＤを生成してもよい。この場合、ベアラＩＤを用いることは、アプリケーションＩＤを用いることと同等である。
【００７９】
図１９は、本開示技術の第２の実施の形態において、アプリケーションＡとアプリケーションＢに関して制御メッセージ送信要求を登録しているときに、サーバＢからアプリケーションＢ用のメッセージを受けた場合における処理の一例を示すシーケンス図である。なお、以下では、主に、本開示技術の第１の実施の形態とは異なる動作（図１２に図示されているシーケンス図との相違点）について説明し、本開示技術の第１の実施の形態と同一又は類似の動作については説明を省略する。
【００８０】
ＵＥ１１０は、制御メッセージ送信要求によって、複数のベアラＩＤに対応したパケットフィルタを登録することが可能である。ここでは、例えば、パケット識別情報（サーバＡのアドレス）及びベアラＩＤ１のページング送信要求と、パケット識別情報（サーバＢのアドレス）及びベアラＩＤ２のページング送信要求とを含む制御メッセージ送信要求をＰＧＷ９０２へ送信したとする（ステップＳ１９０１）。これによって、ＰＧＷ９０２は、ベアラＸに関するコンテキストの中に、ベアラＩＤ１の情報とベアラＩＤ２の情報をＴＦＴとして保持する（ステップＳ１９０３）。例えばサーバＢ１３０又はＩＷＦ９０１からパケットを受信した場合には、ＰＧＷ９０２は、ＴＦＴに基づいて、サーバＢ１３０からＵＥ１１０宛のパケットにページング要求を付加してＳＧＷ９０３へ送信する（ステップＳ１９０５）。その結果、上述の本開示技術の第１の実施の形態と同様に、ＵＥ１１０は、コネクティッド状態であっても、パケット受信通知を示すページングを受信する（ステップＳ１９０７）。
【００８１】
ＵＥ１１０は、ページングの受信によってアプリケーションを起動する必要があることは分かるが、どのアプリケーションを起動すべきか（この場合、アプリケーションＡ、Ｂのどちらか）を特定することはできない。そこで、ＵＥ１１０はページングを受信した際に、ベアラＩＤの通知を要求するメッセージを送信し（ステップＳ１９０９）、その応答としてベアラＩＤ２の通知を受ける（ステップＳ１９１１）。その結果、ＵＥ１１０は、図１８に図示されている関係に基づき、ベアラＩＤ２はアプリケーションＢに割り当てられたＩＤであることが分かるため、ＵＥ１１０はアプリケーションＢを起動して（ステップＳ１９１３）、サービスリクエストを返す（ステップＳ１９１５）。その結果、ＵＥ１１０は、バッファリングされていたパケットをアプリケーションＢで受信することができる。
【００８２】
また、ＵＥ１１０が正しいアプリケーションを起動する別の方法として、ＵＥ１１０がページングを受信した時間や、タイミングなどに基づいて最も可能性の高いアプリケーションを起動し、起動したアプリケーションのベアラＩＤをサービスリクエストに含めて応答してもよい。この場合、ＵＥ１１０は、ベアラＩＤの問い合わせを行わず、最も可能性の高いアプリケーションを推定して起動し、サービスリクエストを送信する。ＭＭＥ９０４は、本開示技術の第１の実施の形態におけるＭＭＥ９０４と同様に、サービスリクエストの中のベアラＩＤが、ＳＧＷ９０３から受信したＤＤＮメッセージの中のベアラＩＤと一致している場合は、ＵＥ１１０が正しいアプリケーションを起動していると判断し、ＤＤＮ応答メッセージをＳＧＷ９０３へ返す。一方、ベアラＩＤが異なる場合は、ＭＭＥ９０４は、ＵＥ１１０に対して異なるアプリケーションの起動を求めるため、サービスリクエストに対する応答（起動すべきアプリケーションに割り当てられたベアラＩＤを含む）をＵＥ１１０へ送信する。
【００８３】
また別の方法として、ＵＥ１１０はページングメッセージを受信した際に、制御メッセージ通知要求の対象として登録しているアプリケーションの全て（ここでは、アプリケーションＡ、Ｂの両方）を起動してページング応答を返してもよい。これにより、アプリケーションＡ又はアプリケーションＢのどちらのパケットが転送されてきたとしても、ＵＥ１１０はそのパケットを受信することができる。
【００８４】
また、ＵＥ１１０がベアラＩＤを知る別の方法として、ＭＭＥ９０４及びｅＮＢ９０５が送信するページングメッセージの中にベアラＩＤを入れてもよい。これにより、ＵＥ１１０はページングを受けた際にすぐにベアラＩＤを知ることができ、適切なアプリケーションを起動することができる。さらに別の方法として、本開示技術の第１の実施の形態において図２９を用いて説明したように、ＵＥ１１０をトリガするための制御メッセージとしてＳＭＳを用いた場合、ＳＭＳの中にベアラＩＤ及び／又はアプリケーションＩＤなどを入れてＵＥ１１０へ送信してもよい。この場合、ＩＷＦ９０１は、ＳＭＳ−ＳＣ／ＩＰ−ＳＭ−ＧＷ９１０へ送信するＳＭＳ送信要求の中にベアラＩＤ及び／又はアプリケーションＩＤを入れて送信する。これにより、ＵＥ１１０は、ＳＭＳを受信した際に、起動するべきアプリケーションを特定し、適切なアプリケーションを起動することができる。また、ＵＥ１１０をトリガするための制御メッセージとして報知情報（ＳＩＢ）を用いた場合、該当するＳＩＢの中にベアラＩＤ及び／又はアプリケーションＩＤを入れてもよい。
【００８５】
以上のように、本開示技術の第２の実施の形態によれば、ＵＥ１１０は、起動すべきアプリケーションが複数存在する場合でも、パケットの受信に必要なアプリケーションを起動することができる。また、特に、各アプリケーションとベアラＩＤとを関連付けることで、ベアラＩＤに基づいて、複数のアプリケーションの中から起動すべきアプリケーションを判断することができる。
【００８６】
なお、本開示技術の第２の実施の形態を実現するＵＥ１１０は、第１の実施の形態の構成に加えて、例えば、アプリケーション宛のリクエストメッセージの処理を行うためのアプリケーションを特定するための情報をネットワークへ要求するアプリケーション情報要求部、アプリケーション宛のリクエストメッセージの処理を行うためのアプリケーションを特定するための情報をネットワークから受信するアプリケーション情報受信部、制御メッセージを受信したときにアプリケーション宛のリクエストメッセージの処理を行うためのアプリケーションを推定し、推定されたアプリケーションを起動するアプリケーション推定部、推定されたアプリケーションを示す情報をネットワークへ通知するアプリケーション通知部、推定されたアプリケーションが、アプリケーション宛のリクエストメッセージの処理を行うアプリケーションとして適切ではない場合に、アプリケーション宛のリクエストメッセージの処理を行うアプリケーションを特定するための情報をネットワークから受信するアプリケーション情報受信部などを更に有しているとも言える。
【００８７】
なお、本開示技術の第２の実施の形態を実現するネットワーク１２０（ネットワーク装置）は、第１の実施の形態の構成に加えて、例えば、ＵＥ１１０のアプリケーション宛のリクエストメッセージの処理を行うアプリケーションを特定するための情報をＵＥ１１０からの要求に応じて送信する情報送信部、ＵＥ１１０が制御メッセージを受信したときにＵＥ１１０で起動されたアプリケーションを示す情報を受信するアプリケーション情報受信部、ＵＥ１１０のアプリケーション宛のリクエストメッセージの処理を行うアプリケーションがＵＥ１１０で起動されたかどうかを判断するアプリケーション判断部、ＵＥ１１０で起動されたアプリケーションが、ＵＥ１１０のアプリケーション宛のリクエストメッセージの処理を行うアプリケーションとして適切ではない場合に、アプリケーション宛のリクエストメッセージの処理を行うアプリケーションを特定するための情報をＵＥ１１０へ送信するアプリケーション情報送信部、ＵＥ１１０のアプリケーション宛のリクエストメッセージの処理を行うアプリケーションを特定するための情報を制御メッセージに付加するアプリケーション特定情報付加部などを有しているとも言える。
【００８８】
（第３の実施の形態）
次に、本開示技術の第３の実施の形態について説明する。本開示技術の第３の実施の形態では、ＵＥ１１０がネットワーク１２０へ制御メッセージ送信要求を送信してフィルタ情報を登録する代わりに、サーバ１３０がＵＥ１１０宛に送信するパケットの中に、制御メッセージ送信要求を付加する方法について説明する。
【００８９】
図２０は、本開示技術の第３の実施の形態において、サーバ１３０がＩＷＦ９０１へ送信するトリガメッセージの中に制御メッセージ送信要求としてのページング送信要求を付加した場合の処理の一例を示すシーケンス図である。なお、以下では、主に、本開示技術の第１の実施の形態とは異なる動作（図１２に図示されているシーケンス図との相違点）について説明し、本開示技術の第１の実施の形態と同一又は類似の動作については説明を省略する。
【００９０】
図２０において、サーバ１３０は、トリガメッセージに、制御メッセージ送信指示としてページング送信要求を付加してＩＷＦ９０１へ送信する（ステップＳ２００１）。ＩＷＦ９０１は、受信したトリガメッセージの中にページング送信要求が付加されている場合は、パケットにページング送信要求を付加してＰＧＷ９０２へ送信する（ステップＳ２００３）。ＩＷＦ９０１からパケットを受信したＰＧＷ９０２は、ページング送信要求が付加されているパケットである場合は、本開示技術の第１の実施の形態と同様に、ＧＴＰメッセージにページング要求を付加して送信する（ステップＳ２００５）。なお、ＰＧＷ９０２とＳＧＷ９０３の間のインタフェースでＰＭＩＰプロトコルが使用されている場合も、本開示技術の第１の実施の形態と同様に、ＰＧＷ９０２は、ＧＲＥヘッダにページング要求を付加して送信する。その結果、ＵＥ１１０は、コネクティッドモードでページングを受けた場合にアプリケーションＡを起動して（ステップＳ２００７）、サービスリクエストを送信する（ステップＳ２００９）。なお、ＵＥ１１０がアイドルモードである場合は常にページングを受信するが、アイドルモードである場合にページングを受信した際にもアプリケーションＡを起動してから、サービスリクエストを送信してもよい。
【００９１】
図３０は、本開示技術の第３の実施の形態において、サーバ１３０がＩＷＦ９０１へ送信するトリガメッセージの中に制御メッセージ送信要求を含め、ＩＷＦ９０１がＳＭＳの使用を選択した場合の処理の一例を示すシーケンス図である。なお、以下では、主に、本開示技術の第１の実施の形態とは異なる動作（図２９に図示されているシーケンス図との相違点）について説明し、本開示技術の第１の実施の形態と同一又は類似の動作については説明を省略する。
【００９２】
図３０において、サーバ１３０は、トリガメッセージに、制御メッセージ送信指示を付加してＩＷＦ９０１へ送信する（ステップＳ３００１）。ＩＷＦ９０１は、受信したトリガメッセージの中に制御メッセージ送信指示が付加されている場合に、ＳＭＳを使用することを選択し、ＳＭＳ−ＳＣ／ＩＰ−ＳＭ−ＧＷ９１０に対して、ＵＥ１１０宛てのＳＭＳの送信要求を送信する（ステップＳ３００２）。その結果、ＵＥ１１０は、コネクティッドモードでＳＭＳを受けた場合にアプリケーションＡを起動して（ステップＳ３００５）、ＳＭＳ受信応答を送信する（ステップＳ３００７）。なお、ＵＥ１１０がアイドルモードである場合は、ページングを受信し、サービスリクエストを送信した後ＳＭＳを受信する。そして、アプリケーションＡを起動してからＳＭＳ受信応答を送信する。ＳＭＳ受信応答は、ＳＭＳやＩＰパケットであってもよい。
【００９３】
なお、ＵＥ１１０は、ＳＭＳ受信応答をサーバ１３０へ送信してもよい。また、ＳＭＳ受信応答は、ＭＭＥ９０４やＳＭＳ−ＳＣ９１０、ＩＷＦ９０１を介してサーバ１３０へ送信されてもよい。例えば、ＵＥ１１０が送信したＳＭＳ受信応答を受けたＭＭＥ９０４がＳＭＳ−ＳＣ９１０に対してトリガメッセージの送信が完了したことを示す応答（配送レポート）を送信し、さらにＳＭＳ−ＳＣ９１０がＩＷＦ９０１に対してその応答を送信してもよい。さらに、トリガメッセージの応答を受けたＩＷＦ９０１は、トリガメッセージの送信元であるサーバ１３０に対して、その応答（ＵＥ１１０へのトリガメッセージの送信が完了したことを示すメッセージ）を送信してもよい。この場合、サーバ１３０は、ＵＥ１１０からＳＭＳ受信応答を受信した後、ＵＥ１１０宛てにアプリケーションＡ用のパケットの送信を行う。また、この場合、ＩＷＦ９０１は、サーバ１３０から受信したトリガメッセージのバッファリングを省略してもよい。また、ページングを受信しアプリケーションを起動したＵＥ１１０は、ページング要求応答を返さずに、パケットの受信を待機していてもよい。この場合、ＩＷＦ９０１又はサーバ１３０は一定時間経過後に、ＵＥ１１０宛てにパケットを転送する。
【００９４】
また、図２２は、本開示技術の第３の実施の形態において、ＩＷＦ９０１がＭＭＥ９０４に対して直接ページングの送信を指示する場合の一例を示すシーケンス図である。なお、以下では、主に、上述の図２０に図示されているシーケンス図との相違点について説明し、同一又は類似の動作については説明を省略する。図２０との違いは、ＩＷＦ９０１が、サーバ１３０から受信したトリガメッセージの中にページング送信要求が付加されている場合は、ＭＭＥ９０４に対して、ＵＥ１１０宛てのページングを送信するよう指示する点である（ステップＳ２２０１）。そして、ＩＷＦ９０１は、ＭＭＥ９０４からページング要求応答を受信した場合（ステップＳ２２０３）、バッファリングしているサーバ１３０から受信したトリガメッセージをＵＥ１１０宛てのパケットに変換して送信する（ステップＳ２２０５）。パケットは確立済みのコネクション／ベアラを介してＵＥ１１０へ転送される。
【００９５】
また、図３３は、本開示技術の第３の実施の形態において、サーバ１３０が、トリガメッセージの中にＣＢＳメッセージを使用することを指示する情報（制御メッセージ送信要求）を含めてＩＷＦ９０１へ送信し、ＩＷＦ９０１が、ＣＢＳの使用を選択する場合の一例を示すシーケンス図である。
【００９６】
サーバ１３０は、トリガメッセージに、制御メッセージ送信指示（ＣＢＳ送信要求）を付加してＩＷＦ９０１へ送信する（ステップＳ３３０１）。ＩＷＦ９０１は、受信したトリガメッセージの中に制御メッセージ送信指示が付加されている場合に、ＣＢＳを使用することを選択し、ネットワークに対してＣＢＳメッセージ（ブロードキャストメッセージ）を送信するよう要求する（ステップＳ３３０３）。なお、サーバ１３０から受信したトリガメッセージに、ＵＥ１１０へ通知するべき情報（例えば、起動するアプリケーションのＩＤやメッセージを特定するための情報、ＡＰＮ、サーバのＵＲＩやＩＰアドレスなどの確立するコネクションに関する情報）が含まれている場合には、ＩＷＦ９０１は、それらの情報をＣＢＳメッセージの中に含めるよう指示してもよい。ＣＢＳメッセージを送信する具体的な方法としては、ＣＢＥ（Cell Broadcast Entity）であるＩＷＦ９０１はＣＢＣ（Cell Broadcast Center）９１３に対してＵＥ１１０宛てのＣＢＳメッセージの送信を要求し、ＣＢＣ９１３がＲＮＣ９１４及びＮｏｄｅＢ９１５を介してＵＥ１１０へＣＢＳメッセージを送信する。
【００９７】
ＵＥ１１０は、自身を宛先とするＣＢＳメッセージを受信した場合、アプリケーションＡを起動し、ＣＢＳメッセージの受信応答を、ネットワークを介してＩＷＦ９０１へ返す（ステップＳ３３０５）。ＣＢＳの受信応答を受けたＩＷＦ９０１は、サーバ１３０から受信したトリガメッセージに基づいて生成したパケットをＵＥ１１０へ送信する。ＩＷＦ９０１へ受信応答を返す方法の具体的な例としては、ＵＥ１１０は、ＣＢＳの受信応答をＲＮＣ９０４へ送信する。それを受けたＲＮＣ９１４が、ＣＢＣ９１３に対してＲｅｐｏｒｔ−Ｓｕｃｃｅｓｓを送信すると、ＣＢＣ９１３からＡｃｋがＩＷＦ９０１へ送信される。別の例としては、ＵＥ１１０は、ＣＢＳ受信応答をＳＧＳＮ９１２へ送信し、ＳＧＳＮ９１２がＩＷＦ９０１へＡｃｋを送信してもよい。この場合、ＳＧＳＮ９１２へ送信するメッセージとして、Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔを使用することができる。このＳｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔには、ＣＢＳの受信応答であることをＳＧＳＮ９１２へ通知するための情報（Information Element）を含めてもよい。
【００９８】
ＩＷＦ９０１は、ＵＥ１１０がＣＢＳメッセージを受けてネットワークへ接続したことを示すＡｃｋを受信すると、サーバ１３０から受信したトリガメッセージに基づいてＩＰパケットを生成し、ＵＥ１１０宛てに送信する。以上によって、ＵＥ１１０は、アプリケーションＡを起動した状態でアプリケーションＡ宛のパケットを受信することができるため、アプリケーションを起動する前にパケットを受信した場合に必要なバッファリング処理も不要となる。
【００９９】
なお、サーバ１３０は、ＩＷＦ９０１へ送信するトリガメッセージの中に、宛先であるＵＥ１１０が、制御メッセージの受信に対してデータパケットの送信を行うＵＥであることを示す情報を含めてもよい。この場合、ＩＷＦ９０１は、トリガメッセージに基づいて生成したパケットをＵＥ１１０宛てに送信する必要がないことを認識することができる。
【０１００】
なお、図２０、図３０、図２２、及び図３３において、ＵＥ１１０は、アプリケーションＡを停止しているときや、アプリケーションＡを停止したとき、まもなくアプリケーションＡを停止する場合などに、アプリケーションＡが停止されたことをサーバ１３０へ通知するためのアプリケーションメッセージを送信してもよい。さらには、アプリケーションＡが起動されていたとしてもパケットの受信処理による負荷を減らす必要があるときなどにも、その旨をサーバ１３０へ通知してもよい。
【０１０１】
また、ＵＥ１１０がネットワーク１２０へ送信したデータコネクションに関する制御メッセージ（コネクション／ベアラ確立メッセージ、サービスリクエスト）が拒絶されたことなどによって、ネットワーク１２０で輻輳が発生していることを認識した場合に、ＵＥ１１０はサーバ１３０に対して、データパケットを送信する代わりにトリガメッセージを送信することを要求するメッセージを送信してもよい。もし拒絶メッセージの中に、メッセージの送信ができない時間間隔を示すバックオフタイマが含まれていた場合は、その値をサーバ１３０へ送信する通知メッセージの中に含めてもよい。この場合、サーバ１３０は通知メッセージを受けた後にタイマをスタートし、バックオフタイマの値の時間が経過してから、データパケットを送信する代わりにトリガメッセージをＵＥ１１０へ送信する。
【０１０２】
サーバ１３０は、ＵＥ１１０からアプリケーションＡの停止通知を受けた場合には、ＵＥ１１０のアプリケーションＡが停止されていることを認識できるため、ＩＷＦ９０１に対して、ＵＥ１１０宛ての制御メッセージ（ページング、ＳＭＳ、ＣＢＳなど）の送信を要求する情報を含んだトリガメッセージを送信する。これにより、サーバ１３０は、ＵＥ１１０と通信を開始するときに、アプリケーションＡを停止しているＵＥ１１０に対しては、アプリケーションＡに関するデータパケットを送信する代わりに、ＵＥ１１０宛ての制御メッセージを送信することが可能となる。また、ＩＷＦ９０１は、ＵＥ１１０が確立済みのコネクション及びベアラを保持していたとしても、確立済みのコネクションを用いてデータパケットとしてトリガメッセージを転送するのではなく、制御メッセージとしてトリガメッセージを送信するべきと判断することができる。これにより、ＵＥ１１０は、アプリケーションＡを停止していても、制御メッセージの受信をトリガとしてアプリケーションＡを起動することができるため、実際の通信を開始する前にアプリケーションＡを適切なタイミングで起動することが可能となる。
【０１０３】
なお、ＵＥ１１０がサーバ１３０へ通知するメッセージには、サーバ１３０がＵＥ１１０へ制御メッセージ（トリガメッセージとしての制御メッセージ）を送信する必要があることを認識できるように、ＵＥ１１０の識別情報（ＵＥのＩＤやアプリケーションＩＤなど）が含まれていてもよい。これにより、サーバ１３０は、ＵＥ１１０から通知メッセージを受けた際に、ＵＥ１１０から通知された識別情報に対して制御メッセージ送信要求を意味する情報を関連付けて保持することができる。そして、サーバ１３０は、ＵＥ１１０と通信を開始する際にこの保持情報を参照し、ＵＥ１１０に対してデータパケットではなく制御メッセージを送信する必要があると判断する。
【０１０４】
なお、ＩＷＦ９０１は、ＵＥ１１０が制御メッセージに応答したことをネットワークから通知された際に、その通知をサーバに１３０に転送してもよい。この場合、ＩＷＦ９０１が、トリガメッセージを基に生成したパケットをＵＥ１１０宛てに転送するのではなく、ＵＥ１１０が応答したことを示すメッセージ通知を受けたサーバ１３０が、ＵＥ１１０に対してパケットを送信する。つまり、サーバ１３０は、ＵＥ１１０のアプリケーションＡを起動、又はＵＥ１１０によるネットワーク接続やコネクションの確立を要求するためにトリガメッセージを送信し、その結果、ＵＥ１１０が制御メッセージに応答したこと（制御メッセージを受信したＵＥ１１０がアプリケーションＡの起動やネットワークへの接続、コネクションの確立などを行ったこと）の通知を受けた後、ＵＥ１１０に対してデータパケットを送信する。これにより、ネットワーク又はＩＷＦ９０１におけるパケットの生成及びバッファリングによる負荷を減らすことができる。
【０１０５】
なお、サーバ１３０は、ＩＷＦ９０１へ送信するトリガメッセージの中に、このトリガメッセージが、ＵＥ１１０に対してアプリケーションＡの起動やネットワーク接続、コネクション確立を要求するためのトリガメッセージであることを意味する情報を含めてもよい。つまり、上記のような情報がトリガメッセージに含まれている場合は、ＩＷＦ９０１は、トリガメッセージに基づいて生成したパケットをＵＥ１１０宛てに送信する必要がないことを認識することができる。
【０１０６】
また、図２８は、本開示技術の第３の実施の形態において、サーバ１３０が送信するトリガメッセージを模式的に示したものである。サーバ１３０から送信されるトリガメッセージには、制御メッセージ送信要求（制御メッセージ送信指示）が含まれる。なお、トリガメッセージに含まれる制御メッセージ送信要求は、どのような形で表現されても構わない。例えば、フラグをセットすることで制御メッセージの送信が要求されていることを示してもよいし、ＩＰパケットへの変換に必要な情報であるアプリケーションに関する情報（ポート番号など）が含まれていない場合は、制御メッセージの送信を指示していることを意味するようにしてもよい。さらには、ＩＷＦ９０１が２つのアドレスを持っていて、その一方を制御メッセージ送信要求が含まれているトリガメッセージの宛先とし、他方を制御メッセージ送信要求が含まれていないトリガメッセージの宛先として用いることで、区別できるようにしてもよい。なお、制御メッセージ送信要求とは、ＵＥ１１０とネットワークとの間に既に確立されているコネクション（ＰＤＰコンテキスト／ＰＤＮコネクション）又は新たに確立するコネクションを用いない方法（ページング、ＳＭＳ、ＣＢＳなど）でトリガメッセージをＵＥ１１０へ転送することを求めていることを意味している。
【０１０７】
なお、本開示技術の第２の実施の形態で説明した方法を組み合わせることで、本開示技術の第３の実施の形態においても、ＵＥ１１０上に複数のアプリケーションが存在する場合であっても、パケットの受信に必要なアプリケーションを起動することができる。
【０１０８】
また、本開示技術の第３の実施の形態で説明した手法は、ＵＥ１１０上のアプリケーションを起動するためだけでなく、ＵＥ１１０からのデータ送信（Mobile Originated Data）を要求するために、ＵＥ１１０に対してダウンリンクデータ（Mobile Terminated Data）を送信することが相応しくない場合にも有効である。
【０１０９】
例えば、ＵＥ１１０上で起動されているアプリケーションがダウンリンクデータの受信に対応していないアプリケーションであった場合に本開示技術の第３の実施の形態で説明した手法を用いることができる。アプリケーションがダウンリンクパケットの受信に対応していない場合、サーバ１３０やセルラーネットワーク内のノード、及び他のＵＥ１１０から送られてきたデータパケットはＰＧＷ９０２又はＵＥ１１０によって廃棄されてしまう。例えば、ＰＧＷ９０２が保持するＴＦＴにおいて、当該アプリケーション用のパケットにベアラが関連付けられていない場合、ＰＧＷ９０２はそのパケットの転送を行わずに廃棄する。本開示技術の第３の実施の形態で説明した手法を用いることができる別の場合として、ダウンリンクデータを用いてＵＥ１１０に対してデータの送信を指示する場合、複数のＵＥ１１０に対して同時に指示する場合などは、データトラフィック量が増加してしまうため、ダウンリンクデータを使わずにＵＥ１１０に対してデータの送信を指示したい、あるいは指示を受けたい場合なども用いることができる。サーバ１３０は、ＵＥ１１０が使用しているアプリケーションが上記のような特徴を有しているとの情報に基づき、ＵＥ１１０に対してダウンリンクデータを送信するべきでないことを認識し、以下に説明するように、制御メッセージ送信要求を付加したトリガメッセージをＩＷＦ９０１へ送信する。
【０１１０】
さらに、本開示技術の第３の実施の形態で説明した手法は、ＵＥ１１０に対してネットワークへの接続を要求する、及び／又は新たなコネクションの確立を要求するためにも有効である。
【０１１１】
例えば、サーバ１３０は、ＵＥ１１０と通信をするために、ＩＷＦ９０１に対してＵＥ１１０宛てのトリガメッセージを送信する際に、ＵＥ１１０とサーバ１３０が存在するネットワークとの間にまだコネクションが確立されていない場合、トリガメッセージに制御メッセージ送信要求を付加する。これは、ＵＥ１１０が確立済みのコネクションを持っていたとしても、そのコネクションは上記のトリガメッセージをデータパケットとして転送するのに適していない、あるいはこれから開始する通信のデータ転送に適していないと判断される場合も含んでいる。適していないという意味は、例えば、既存のコネクションのＡＰＮ（Access Point Name）と新たに開始する通信のＡＰＮとが異なる場合や、既存のコネクションのＱｏＳが新たな通信に合っていない場合（リソースやＱｏＳが不十分である場合）などである。なお、サーバ１３０は制御メッセージ送信要求であるトリガメッセージの中に、ＵＥ１１０へ通知するデータ（アプリケーションデータ）を含めて送信してもよい。この場合、ＩＷＦ９０１はデータを含むトリガメッセージ（ＳＭＳ，ＣＢＳ，ＭＢＭＳ，ＥＴＷＳ、ＮＡＳなど）をＵＥ１１０へ送信するための処理を行う。
【０１１２】
また、サーバ１３０はＵＥ１１０と通信を開始する際に、制御メッセージを用いてトリガメッセージを送信する手段と、アプリケーションに関するデータパケットを用いてトリガメッセージを送信する手段のどちらが適切であるかを任意の観点（コスト、通信料、トラフィック状態、トラフィック負荷、送信メッセージサイズ、送信メッセージ数、セキュリティ強度、アプリケーションタイプなど）で比較し、より適切であると判断された方の手段を選択してもよい。例えば、トリガメッセージをデータパケットとして送信する場合に比べて、制御メッセージとして送信する方の通信料が安い場合や、送信するメッセージ数が少ない（例えば、１つの制御メッセージに複数のＵＥ１１０の宛先を含めることができる。複数のＵＥ１１０が属するグループＩＤを宛先として指定できる）場合は、制御メッセージを用いたトリガメッセージの送信を要求する。通常ＩＰパケットには１つのＩＰアドレスしか宛先に設定することができないため、複数のＵＥ１１０に同時にメッセージを送信したい場合は制御メッセージを用いる方が効率的である。
【０１１３】
また、ＵＥ１１０へ送信するデータをデータパケットとして送信する場合に比べて、制御メッセージに含めて送信する方の通信料が安い場合は、制御メッセージを用いたトリガメッセージの送信を要求する。ＵＥ１１０へ送信するトリガメッセージとして複数の種類（ＳＭＳ，ＣＢＳ，ＭＢＭＳ，ＮＡＳ）がある場合は、どの種類の制御メッセージが適切であるかをさらに判断し、その結果をＩＷＦ９０１へ送信するトリガメッセージの中に付加してもよい。
【０１１４】
また、ＳＭＳやＣＢＳなどのメッセージはリアルタイムな通知を保証するメッセージではないため、サーバ１３０は、ＵＥ１１０との間で行う通信が非リアルタイムな通信である場合に制御メッセージを用いてトリガメッセージを送信し、リアルタイムな通信である場合はデータパケットを用いると判断してもよい。さらにまた、サーバ１３０は、トリガメッセージの内容（宛先、送信元、データなど）が時間の経過によって変化しない場合は、制御メッセージを用いてトリガメッセージを送信すると判断してもよい。また、サーバ１３０は、ＵＥ１１０に対してデータパケットを送ることでＵＥ１１０のデータ通信用のコネクションを管理しているゲートウェイ（Ｐ−ＧＷ、Ｓ−ＧＷ、ｅＰＤＧ）の切り替えが発生する可能性がある場合は、制御メッセージを用いてトリガメッセージを送信すると判断してもよい。
【０１１５】
また、サーバ１３０は、ＵＥ１１０に対して送信したいデータ（アプリケーションデータ）のサイズがある規定値を下回る場合は、ＵＥ１１０宛てにデータパケットを直接送信する代わりに、トリガメッセージとしてデータを含む制御メッセージを送信するようＩＷＦ９０１に対して要求してもよい。この場合の規定値とは、ＵＥ１１０に送信されるトリガメッセージの種類（例えば、Mobile Terminated SMS，ＣＢＳ、ＮＡＳ）に応じて、含めることができるデータサイズの上限値であってもよい。なお、ＵＥ１１０に対して送信するデータのサイズは、ＵＥ１１０との通信に使用されるアプリケーションから通知された値を用いてもよい。また、そのアプリケーションは、トリガメッセージを送信する前にＵＥ１１０から受信したアプリケーションデータに基づいて送信するデータのサイズを決定してもよい。
【０１１６】
また、サーバ１３０は、ＵＥ１１０から受信したいデータのサイズがある規定値を下回る場合に、ＵＥ１１０宛てにデータパケットを送信する代わりに、トリガメッセージとして制御メッセージを送信するようＩＷＦ９０１に対して要求してもよい。この場合、トリガメッセージを受けたＵＥ１１０は、サーバ１３０へ送信するデータをデータパケットとして送信する代わりに、制御メッセージ（Mobile Originated SMS、ＮＡＳ）に含めてサーバ１３０へ送信するべきと判断することができる。
【０１１７】
また、サーバ１３０は、ネットワーク１２０においてデータパケットによる輻輳（U-plane congestion）が発生していることを認識した場合に、トリガメッセージとしてデータを含む制御メッセージを送信するようＩＷＦ９０１に対して要求してもよい。一方、サーバ１３０は、ネットワーク１２０において制御メッセージによる輻輳（C-plane congestion）が発生していることを認識した場合に、アプリケーションに関するデータパケットをＵＥ１１０へ直接送信すると判断してもよい。
【０１１８】
なお、上記で説明したように、サーバ１３０がＩＷＦに対して制御メッセージを用いたトリガメッセージの送信を要求するべきか、又はアプリケーションに関するデータパケットを直接ＵＥ１１０へ送信するべきかの判断をする際に参照する情報は、トリガメッセージを送信する前にＵＥ１１０から通知された情報であってもよい。つまり、ＵＥ１１０は、アプリケーションの状態に応じてサーバ１３０がトリガメッセージの送信方法を選択する際に参照する情報を通知する。
【０１１９】
なお、ＵＥ１１０がサーバ１３０へ通知するメッセージには、サーバ１３０がＵＥ１１０へ制御メッセージ（トリガメッセージとしての制御メッセージ）を送信する必要があることを認識できるように、ＵＥ１１０の識別情報（ＵＥのＩＤやアプリケーションＩＤなど）が含まれていてもよい。これにより、サーバ１３０は、ＵＥ１１０から通知メッセージを受けた際に、ＵＥ１１０から通知された識別情報に対して制御メッセージ送信要求を意味する情報を関連付けて保持することができる。そして、サーバ１３０は、ＵＥ１１０と通信を開始する際にこの保持情報を参照し、ＵＥ１１０に対してデータパケットではなく制御メッセージを送信する必要があると判断する。
【０１２０】
また、上記説明では、サーバ１３０によって行われる判断を個別に記述しているが、複数の条件に基づいて判断される場合は、優先度の高い条件に基づく判断の結果に従う。
【０１２１】
これにより、ＩＷＦ９０１が、サーバ１３０から受信したＵＥ１１０宛てのトリガメッセージに含まれる制御メッセージ送信要求に従って、制御メッセージを用いてトリガメッセージを転送することで、その通信のデータパケットの転送に使用できるコネクションを確立するようＵＥ１１０に指示することができる。
【０１２２】
また、図２４は、本開示技術の第３の実施の形態において、制御メッセージとしてページングを用いてＵＥ１１０からのデータ送信をトリガする場合の一例を示すシーケンス図である。なお、以下では、主に、上述の図２０に図示されているシーケンス図との相違点について説明し、同一又は類似の動作については説明を省略する。上記のような場合にサーバ１３０は、ＵＥ１１０に対して送信するトリガメッセージに制御メッセージ送信要求を付加したトリガメッセージをＩＷＦ９０１へ送信する（ステップＳ２４０１）。ＩＷＦ９０１は、制御メッセージとしてページングを用いることを選択し，ＭＭＥ９０４に対してページングを送信するよう要求する（ステップＳ２４０３）。そして、ＵＥ１１０がページングを受信した際に、ＵＥ１１０のアプリケーションは、このページングをトリガとして、サーバ１３０やセルラーネットワーク内のノード、他のＵＥ１１０に対してデータの送信を開始する（ステップＳ２４０５）。なお、ページングを受信した際にアプリケーションが起動されていない場合は、ＵＥ１１０はアプリケーションを起動した後、データの送信を開始する。また、ＵＥ１１０が送信するデータは、ＩＰパケットとして送信されてもよいし、データを含むＳＭＳとして送信されてもよい。また、ＵＥ１１０がアイドルモードである場合は常にページングを受信するが、アイドルモードである場合にページングを受信した際にもサービスリクエストを送信した後、サーバ１３０やセルラーネットワーク内のノード、他のＵＥ１１０に対してデータ送信を開始してもよい。また、ページングを受信した際のＵＥ１１０の別の動作として、ネットワークに対して新たなコネクションの確立を行ってもよい。
【０１２３】
また、図２５は、本開示技術の第３の実施の形態において、制御メッセージとしてＳＭＳを用いてＵＥからのデータ送信をトリガする場合の一例を示すシーケンス図である。上記のような場合にサーバ１３０は、ＵＥ１１０に対して送信するトリガメッセージに制御メッセージ送信要求（ＳＭＳ送信要求）を付加したトリガメッセージをＩＷＦ９０１へ送信する（ステップＳ２５０１）。ＩＷＦ９０１は、サーバ１３０からトリガメッセージを受信した際に、制御メッセージとしてＳＭＳを用いることを判断して、ネットワーク１２０に対してＵＥ１１０宛てのＳＭＳを送信するよう要求する。具体的には、ＩＷＦ９０１は、ＳＭＳ−ＳＣ／ＩＰ−ＳＭ−ＧＷ９１０に対してＳＭＳを送信するよう要求し（ステップＳ２５０３）、これによって、例えばＳＭＳ−ＳＣ／ＩＰ−ＳＭ−ＧＷ９１０がＵＥ１１０に対してＳＭＳを送信する（ステップＳ２５０５）。なお、ＵＥ１１０は、ＭＭＥ９０４によって送信されるDownLink NAS TransportメッセージによってＳＭＳを受信する。
【０１２４】
ＳＭＳを受信したＵＥ１１０のアプリケーションは、このＳＭＳをトリガとして、サーバ１３０やセルラーネットワーク内のノード、他のＵＥ１１０に対してデータの送信を開始する（ステップＳ２５０７）。なお、ＳＭＳを受信した際にアプリケーションが起動されていない場合は、ＵＥ１１０はアプリケーションを起動した後、データの送信を開始する。ＳＭＳを受信するレイヤ（Service Capability Layer）がＳＭＳに含まれているアプリケーション情報に基づいて適切なアプリケーションを起動する。また、ＵＥ１１０が送信するデータは、ＩＰパケットとして送信されてもよいし、データを含むＳＭＳとして送信されてもよい。また、ＵＥ１１０がアイドルモードである場合は、ページングを受信し、サービスリクエストを送信した後ＳＭＳを受信する。そして、ＳＭＳを受信した後、データの送信を開始する。これにより、ダウンリンクデータを用いずにＵＥ１１０からのデータ送信を要求することができるため、データトラフィック量の増加を防ぐことができる。また、サーバ１３０が知っているＵＥ１１０のＩＰアドレスが変わっていたとしても、ＵＥ１１０に対してメッセージを届けることもできる。また、ＳＭＳを受信した際のＵＥ１１０の別の動作として、ネットワークに対して新たなコネクションの確立を行ってもよい。
【０１２５】
また、図３４は、本開示技術の第３の実施の形態において、サーバ１３０が、トリガメッセージの中にＣＢＳメッセージを使用することを指示する情報（制御メッセージ送信要求）を含めてＩＷＦ９０１へ送信し、ＩＷＦ９０１が、ＣＢＳの使用を選択する場合の一例を示すシーケンス図である。
【０１２６】
サーバ１３０は、ＩＷＦ９０１へ送信するトリガメッセージの中に、ＣＢＳメッセージの使用を指示する制御メッセージ送信指示（ＣＢＳ送信要求）を含めて送信する（ステップＳ３４０１）。ＩＷＦ９０１は、サーバ１３０から受信したトリガメッセージの中に、ＣＢＳメッセージの使用を指示する情報が含まれていた場合には、ネットワークに対してＣＢＳメッセージを送信するよう要求する（ステップＳ３４０３）。なお、サーバ１３０から受信したトリガメッセージに、ＵＥ１１０へ通知するべき情報（例えば、起動するアプリケーションやメッセージを特定するための情報や、ＡＰＮ、サーバのＵＲＩやＩＰアドレスなどの確立するコネクションに関する情報）が含まれている場合には、ＩＷＦ９０１は、それらの情報をＣＢＳメッセージの中に含めるよう指示してもよい。ＣＢＳメッセージを送信する具体的な方法としては、ＣＢＥ（Cell Broadcast Entity）であるＩＷＦ９０１はＣＢＣ（Cell Broadcast Center）９１３に対してＵＥ１１０宛てのＣＢＳメッセージの送信を要求し、ＣＢＣ９１３がＲＮＣ９１４及びＮｏｄｅＢ９１５を介してＵＥ１１０へＣＢＳメッセージを送信する。また、ＩＷＦ９０１は、送信するＣＢＳメッセージの中に、受信するＵＥを識別するＩＤとして、ＵＥ１１０のＩＤのみを含めてもよいし、ＵＥ１１０が属するグループのＩＤを含めてもよい。ＵＥ１１０は、自身を宛先とするＣＢＳメッセージを受信した場合、アプリケーションＡに関するデータパケットをサーバ１３０へ送信する（ステップＳ３４０５）。なお、アプリケーションＡがまだ起動されていない場合は、アプリケーションＡを起動してからデータパケットをサーバ１３０へ送信する。また、ＣＢＳを受信した際のＵＥ１１０の別の動作として、ネットワークに対して新たなコネクションの確立を行ってもよい。
【０１２７】
なお、図２４、図２５、図３４において、ＵＥ１１０は、アプリケーションＡを停止（休止）した際に、アプリケーションＡが停止されたことをサーバ１３０へ通知するためのメッセージ（データパケット）を送信してもよい。サーバ１３０は、ＵＥ１１０からアプリケーションＡの停止通知を受けた後にＵＥ１１０と通信を開始する場合は、ＵＥ１１０宛てのデータパケットを送信するのではなく、ＵＥ１１０宛ての制御メッセージ（ページング、ＳＭＳ、ＣＢＳなど）の送信を要求する情報を含んだトリガメッセージをＩＷＦ９０１へ送信する。なお、ＵＥ１１０がサーバ１３０へ送信するメッセージは、コネクションを用いたデータパケットによるトリガメッセージの通知ではなく、コネクションを用いない他の方法でトリガメッセージを通知することを求めていることを示す情報を含むメッセージであればその形式は問わない。例えば、アプリケーションＡが生成するアプリケーションデータとして送信されてもよい。これにより、サーバ１３０は、ＵＥ１１０と通信を開始するときに、アプリケーションＡを停止しているＵＥ１１０に対しては、アプリケーションＡに関するデータパケットを送信する代わりに、ＵＥ１１０宛ての制御メッセージの送信を要求することが可能となる。一方、制御メッセージ送信要求を含んだトリガメッセージを受信したＩＷＦ９０１は、ＵＥ１１０が確立済みのコネクション及びベアラを保持していたとしても、確立済みのコネクションを用いてデータパケットとしてトリガメッセージを転送するのではなく、制御メッセージとしてトリガメッセージを送信するべきと判断することができる。また制御メッセージを受けたＵＥ１１０は、制御メッセージ受信部７０４及びアプリケーション制御部７０５が、制御メッセージに含まれている情報（アプリケーションＩＤなど）を基に適切なアプリケーションＡを起動し、起動されたアプリケーションＡは必要なデータパケットを送信してサーバ１３０との通信を開始する。
【０１２８】
このように、ＵＥ１１０がアプリケーションＡを停止している際には、サーバ１３０から送信されたトリガメッセージをデータパケットとして受けるのではなく、制御メッセージとして受けることができるため、アプリケーションＡを起動するなどの適切な処理を実行することができる。なお、上記ＵＥ１１０がサーバ１３０へ送信するメッセージによって通知される情報がＨＬＲ／ＨＳＳ９０６に保持されている場合は、ＩＷＦ９０１はＨＬＲ／ＨＳＳ９０６を参照してＵＥ１１０の情報を取得し、その情報が制御メッセージを使用することを指示している場合は、サーバ１３０から受けたトリガメッセージを制御メッセージとしてＵＥ１１０へ送信するべきと判断してもよい。
【０１２９】
図３５は、ＵＥ１１０からのアプリケーションの停止通知を受け、サーバ１３０がＣＢＳ送信要求をトリガメッセージに含めて送信する場合のシーケンスを表したものである。なお、図３５は、図３４に示すシーケンスにおいて、ＵＥ１１０がアプリケーションＡを停止した際にアプリＡ停止通知メッセージを送信することで（ステップＳ３５０１）、サーバ１３０は、ＵＥ１１０のアプリケーションＡが停止されていることを認識し、例えば、ＵＥ１１０と通信を開始する際にトリガメッセージを送信することができる場合が図示されている。図２４及び図２５に示すシーケンスにおいても同様に、ＵＥ１１０がアプリケーションＡを停止した際にアプリＡ停止通知メッセージを送信することで、サーバ１３０が、ＵＥ１１０のアプリケーションＡが停止されていることを認識できるため、データパケットとしてトリガメッセージを送信するのではなく、ページング又はＳＭＳとしてトリガメッセージを送信することができる。これにより、ＵＥ１１０は、アプリケーションＡを停止していても、制御メッセージの受信をトリガとしてアプリケーションＡを起動することができるため、実際の通信を開始する前にアプリケーションＡを適切なタイミングで起動することが可能となる。
【０１３０】
なお、本開示技術の第３の実施の形態においても、本開示技術の第１の実施の形態で説明したように、ネットワーク１２０がＵＥ１１０へ送信する制御メッセージとして、基地局が送信するＳＩＢ（System Information Block）などの報知情報を用いることもできる。この場合、ＵＥ１１０は、ページングを受信した際に、ページングの中にＳＩＢの変更の有無を示す情報が含まれている場合は、該当するＳＩＢを確認し、そこにパケット受信通知を示す情報が含まれている場合は、アプリケーションＡを起動して応答メッセージを返すか、又はサーバ１３０やセルラーネットワーク内のノード、他のＵＥ１１０に対してデータの送信を開始する。
【０１３１】
また、サーバ１３０は、ＰＧＷ９０２又はＩＷＦ９０１に対して、ページングやＳＭＳなどの特定の制御メッセージを指定したトリガメッセージを送信してもよいし、特に指定せずにトリガメッセージを送信してもよい。後者の場合、ＰＧＷ９０２又はＩＷＦ９０１が、サーバ１３０から制御メッセージ送信要求が付加されたトリガメッセージを受けた際に、どの制御メッセージを用いてＵＥ１１０をトリガするかを判断する。また、サーバ１３０は、本開示技術の第１の実施の形態におけるＵＥ１１０のように、ＰＧＷ９０２又はＩＷＦ９０１に対してフィルタ情報を登録してもよい。この場合、サーバ１３０は、トリガメッセージに制御メッセージ送信要求を付加する必要はない。また、３ＧＰＰネットワーク１２０内にＵＥ１１０の情報を管理するノードを設け、サーバ１３０は、そのノードに対してフィルタ情報を登録してもよい。この場合、ＰＧＷ９０２又はＩＷＦ９０１は、ＵＥ１１０の情報を管理しているノードに問い合わせ、ＵＥ１１０に対して制御メッセージを送信するべきか否かを判断するようにしてもよい。
【０１３２】
以上説明したように、本開示技術の第３の実施の形態によれば、ＵＥ１１０に対してデータ送信を要求するためのデータパケットが不要となるため、ネットワークトラフィックを削減することができる。また、起動していないアプリケーションに対するデータパケットの送信要求をＵＥ１１０へ通知することが可能となるため、ＵＥ１１０は、制御メッセージの受信をトリガにしてアプリケーションの起動を行ってから、パケットの送信をすることが可能となる。これにより、アプリケーションを常時起動しておくことによるＣＰＵのパワー、ＣＰＵの動作による消費電力やメモリの消費を削減することができる。
【０１３３】
（第４の実施の形態）
次に、本開示技術の第４の実施の形態について説明する。図２１は、本開示技術の第４の実施の形態において、ＵＥ１１０上に、アプリケーションＡ宛のパケットが届いたことを検出する常駐アプリケーションを使用する方法の一例を示す図である。図２１に示すように、ＵＥ１１０上にはアプリケーションＡで使用するポート番号（例えばポート番号７７７）を監視するアプリを常駐させる。このポート監視アプリは、監視対象のポート番号宛にパケットが届いたことを検出した場合、そのポート番号を使用しているアプリケーションを起動し、届いたパケットを起動したアプリケーションへ渡す。このポート監視アプリは、他のアプリケーションにも汎用的に使用できるため、個々のアプリケーションを起動する代わりにこのポート監視アプリを起動するだけでよいため、ＣＰＵのパワー、ＣＰＵの動作による消費電力やメモリの消費を抑えることができる。
【０１３４】
本開示技術の一態様は、ネットワークを介して、所定の通信装置と通信を行うユーザ端末であって、
前記所定の通信装置から送信されたリクエストメッセージであって、前記ユーザ端末のアプリケーションを識別するアプリケーション識別情報を含むリクエストメッセージに基づいて生成された前記アプリケーション識別情報を含む制御メッセージを前記ネットワークから受信する制御メッセージ受信部と、
前記制御メッセージ受信部で前記制御メッセージを受信したとき、前記アプリケーション識別情報によって特定されるアプリケーションを起動するアプリケーション起動部とを、
有するユーザ端末を含むことができる。
上記の構成により、ユーザ端末は、サーバや他のユーザ端末などの通信相手端末からアプリケーション用のメッセージが送られてくる前に、当該アプリケーション用のメッセージの受信及び処理を行うためのアプリケーションを起動できるようになる。
【０１３５】
また、本開示技術の一態様では、ユーザ端末は、前記アプリケーション起動部で前記アプリケーションを起動したとき、前記アプリケーションの起動を示す応答メッセージを前記ネットワークへ送信する応答メッセージ送信部を更に有していてもよい。
【０１３６】
また、本開示技術の一態様では、ユーザ端末は、前記所定の通信装置が前記リクエストメッセージを前記ネットワークに送信するよう要求する制御メッセージ送信要求を前記所定の通信装置へ送信する制御メッセージ送信要求部を更に有していてもよい。
【０１３７】
また、本開示技術の一態様では、ユーザ端末において、前記ユーザ端末において特定のアプリケーションを終了する際に、前記制御メッセージ送信要求部が、前記制御メッセージ送信要求を前記所定の通信装置へ送信してもよい。
【０１３８】
また、本開示技術の一態様では、ユーザ端末は、前記ユーザ端末のアプリケーション宛のメッセージを識別するための識別情報を前記制御メッセージ送信要求に付加する識別情報付加部を更に有していてもよい。
【０１３９】
また、本開示技術の一態様では、ユーザ端末は、前記制御メッセージとしてＳＭＳを利用してもよい。
【０１４０】
また、本開示技術の一態様は、ネットワークを介して、ユーザ端末と通信を行う通信装置であって、
前記ネットワークを構成するネットワークエンティティを含むネットワーク装置に対して前記ユーザ端末へ制御メッセージを送信することを要求するリクエストメッセージであって、前記ユーザ端末のアプリケーションを識別するアプリケーション識別情報を含むリクエストメッセージを前記ネットワークへ送信するメッセージ送信部を有する通信装置を含むことができる。
上記の構成により、ユーザ端末は、サーバや他のユーザ端末などの通信相手端末からアプリケーション用のメッセージが送られてくる前に、当該アプリケーション用のメッセージの受信及び処理を行うためのアプリケーションを起動できるようになる。
【０１４１】
また、本開示技術の一態様では、通信装置は、前記制御メッセージの受信に基づいて前記ユーザ端末でアプリケーションが起動されたことを示す応答メッセージを前記ユーザ端末から受信すると、前記アプリケーションに関するデータパケットを前記ユーザ端末へ転送するメッセージ転送部を更に有していてもよい。
【０１４２】
また、本開示技術の一態様では、通信装置は、前記リクエストメッセージを前記ネットワークに送信するよう要求する制御メッセージ送信要求を前記ユーザ端末から受信したとき、前記制御メッセージ送信要求を保持する制御メッセージ送信要求保持部を更に有し、
前記前記ユーザ端末と通信を開始するとき、前記制御メッセージ送信要求保持部に前記制御メッセージ送信要求が保持されている場合に、前記メッセージ送信部が、前記リクエストメッセージを前記ネットワークへ送信してもよい。
【０１４３】
また、本開示技術の一態様では、通信装置において、前記メッセージ送信部は、前記ユーザ端末から受信した制御メッセージ送信要求に基づいて、前記リクエストメッセージを前記ネットワーク装置へ送信してもよい。
【０１４４】
また、本開示技術の一態様では、通信装置は、前記制御メッセージとしてＳＭＳを利用することを要求してもよい。
【０１４５】
なお、例えば、上記の本開示技術の各態様は適宜組み合わせることが可能である。また、本開示技術の一態様は、通信システム、ユーザ端末、通信装置に加えて、ネットワークを構成するネットワークエンティティを含むネットワーク装置、ユーザ端末や通信装置あるいはネットワーク装置によって実行される方法、この方法をコンピュータに実行させるためのプログラム、及び、このプログラムを記録した記録媒体などによって実現されてもよい。
【０１４６】
また、上記実施の形態の説明に用いた各機能ブロックや各処理部は、ハードウェア、ソフトウェア、あるいはこれらの組み合わせによって実現されてもよい。例えば、図７、８、１０、１１などに図示されている各装置に含まれる機能ブロック、あるいは、同等の機能を有する各処理部は、任意のコンピュータのＣＰＵ及びメモリなどのハードウェアによって実現されてもよい。また、各機能に係る動作が記述されたプログラムをコンピュータによって実行させることで、各機能ブロックや各処理部が実現されてもよい。
【０１４７】
また、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現されてもよい。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。
【産業上の利用可能性】
【０１４８】
本開示技術は、ユーザ端末が、サーバや他のユーザ端末などの通信相手端末からアプリケーション用のメッセージが送られてくる前に、当該アプリケーション用のメッセージの受信及び処理を行うためのアプリケーションを起動できるようになり、ユーザ端末の処理負荷やバッテリーの浪費を低減させるという効果を有しており、セルラー通信機能を利用した通信技術に適用可能である。
【図１】
0006023054.tif 000002
【図２】
0006023054.tif 000003
【図３】
0006023054.tif 000004
【図４】
0006023054.tif 000005
【図５】
0006023054.tif 000006
【図６】
0006023054.tif 000007
【図７】
0006023054.tif 000008
【図８】
0006023054.tif 000009
【図９】
0006023054.tif 000010
【図１０】
0006023054.tif 000011
【図１１】
0006023054.tif 000012
【図１２】
0006023054.tif 000013
【図１３】
0006023054.tif 000014
【図１４】
0006023054.tif 000015
【図１５】
0006023054.tif 000016
【図１６】
0006023054.tif 000017
【図１７】
0006023054.tif 000018
【図１８】
0006023054.tif 000019
【図１９】
0006023054.tif 000020
【図２０】
0006023054.tif 000021
【図２１】
0006023054.tif 000022
【図２２】
0006023054.tif 000023
【図２３】
0006023054.tif 000024
【図２４】
0006023054.tif 000025
【図２５】
0006023054.tif 000026
【図２６】
0006023054.tif 000027
【図２７】
0006023054.tif 000028
【図２８】
0006023054.tif 000029
【図２９】
0006023054.tif 000030
【図３０】
0006023054.tif 000031
【図３１】
0006023054.tif 000032
【図３２】
0006023054.tif 000033
【図３３】
0006023054.tif 000034
【図３４】
0006023054.tif 000035
【図３５】
0006023054.tif 000036