特許 6138058 サーバ及び通信端末

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6138058

(24)【登録日】2017年5月12日

(45)【発行日】2017年5月31日

(54)【発明の名称】サーバ及び通信端末

(51)【国際特許分類】

   H04L 12/70 20130101AFI20170522BHJP

【ＦＩ】

   H04L12/70 A

   H04L12/70 B

【請求項の数】7

【全頁数】20

(21)【出願番号】特願2013-557681(P2013-557681)

(86)(22)【出願日】2013年4月23日

(86)【国際出願番号】JP2013002741

(87)【国際公開番号】WO2014006803

(87)【国際公開日】20140109

【審査請求日】2015年10月14日

(31)【優先権主張番号】特願2012-148619(P2012-148619)

(32)【優先日】2012年7月2日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】514136668

【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ

【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100093067

【弁理士】

【氏名又は名称】二瓶 正敬

(72)【発明者】

【氏名】阿相 啓吾

(72)【発明者】

【氏名】ヴェレブ ゲナディ

【審査官】 宮島 郁美

(56)【参考文献】

【文献】 特開２００１−１０３１５５（ＪＰ，Ａ）

【文献】 特開２００６−０１４１８８（ＪＰ，Ａ）

【文献】 国際公開第２０１１／１２７３２０（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ１２／００−１２／２６，１２／５０−１２／９５５

Ｈ０４Ｂ７／２４−７／２６，Ｈ０４Ｗ４／００−９９／００

Ｈ０４Ｍ３／００，３／１６−３／２０，３／３８−３／５８，７／００−７／１６，１１／００−１１／１０

(57)【特許請求の範囲】

【請求項1】

ネットワークを介して、所定の通信装置と通信を行う通信端末であって、
前記所定の通信装置から送信され、制御メッセージを前記通信端末へ送信することを要求するトリガ要求メッセージに基づいて生成された前記制御メッセージを前記ネットワークから受信する制御メッセージ受信部と、
前記所定の通信装置とＩＰパケットを使って前記通信をするか否かを判断する判断部と、
前記制御メッセージ受信部で前記制御メッセージを受信したとき、ＩＰパケットを使って前記通信をすると判断した場合に、前記所定の通信装置との前記通信に使用するＩＰコネクションに割り当てられているＩＰアドレスを取得するコネクション管理部と、
前記制御メッセージに対する応答メッセージであって、前記コネクション管理部が取得した前記ＩＰアドレスを含む応答メッセージを前記ネットワークに送信する応答メッセージ送信部とを、
有し、
前記応答メッセージ送信部は、
前記制御メッセージの中にアプリケーションデータが含まれていない場合に、ＩＰパケットを使って前記通信をすると判断する通信端末。

【請求項2】

前記コネクション管理部は、
前記ＩＰアドレスを取得する際、前記ＩＰコネクションが確立されていない場合に新たにＩＰコネクションを確立する請求項１に記載の通信端末。

【請求項3】

前記応答メッセージ送信部は、
前記ＩＰアドレスを、前記応答メッセージの中のアプリケーション情報を入れるためのフィールドに挿入する請求項１に記載の通信端末。

【請求項4】

前記応答メッセージ送信部は、
前記所定の通信装置へ送信すべきアプリケーションデータを前記通信端末が有する場合に、ＩＰパケットを使って前記通信をすると判断する請求項１に記載の通信端末。

【請求項5】

通信端末とアプリケーションサーバとの通信を仲介するサーバであって、
前記アプリケーションサーバからデータを取得した際、制御メッセージを前記通信端末へ送信することを要求するトリガ要求をネットワークノードへ送信するトリガ要求送信部と、
前記トリガ要求に基づいて前記ネットワークノードから前記通信端末へ送信された前記制御メッセージに対する応答メッセージであって、前記通信端末のＩＰアドレスを含む応答メッセージを受信した前記ネットワークノードから前記ＩＰアドレスを含むレポートメッセージを受信し、前記レポートメッセージの中に含まれる前記通信端末のＩＰアドレスを取得するレポート受信部と、
前記ＩＰアドレスと前記通信端末の識別情報を関連付けて保持する通信端末情報保持部とを、
有するサーバ。

【請求項6】

前記ＩＰアドレスは、前記レポートメッセージのアプリケーション情報を入れるためのフィールドに挿入されている請求項５に記載のサーバ。

【請求項7】

受信したＩＰパケットの送信元アドレスが、前記通信端末情報保持部に保持されているＩＰアドレスと一致する場合に、前記ＩＰパケットに含まれているペイロードを前記アプリケーションサーバへ通知するＩＰパケット受信部を更に有する請求項５に記載のサーバ。

【発明の詳細な説明】

【技術分野】

【0001】

本開示技術は、セルラー通信機能を利用して通信技術に関し、特に、マシン間コミュニケーション（Machine to Machine CommunicationやMachine Type Communicationと呼ばれる。以下、Ｍ２Ｍ通信（又はＭＴＣと記載））の技術を利用して通信を行うサーバ及び通信端末に関する。

【背景技術】

【0002】

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

【0003】

ユーザ及びユーザが操作するアプリケーション（以下、ＭＴＣアプリケーション、アプリケーションサーバ、又はＡＳ（Application Server）とも呼ぶ）がＵＥに対してアプリケーションデータ（以下、アプリケーションＰＤＵ、アプリケーションペイロード、又はデータとも呼ぶ）を送信する場合、ＳＣＳ（Service Capability Server、又はＭＴＣサーバ、あるいは単にサーバとも呼ぶ）へデータを渡して、そのデータをＵＥへ送信することを依頼することができる（Indirect Model）。ＡＳからデータを受けたＳＣＳは、適切な送信手段を用いてデータをＵＥへ送信する。送信手段としては、例えば、ＵＥのＩＰアドレス宛のＩＰパケットを作成し、アプリケーションデータパケットとしてＵＥへ送信する方法や、セルラーネットワーク内のエンティティへ送信する制御メッセージの中にデータを含めて送信する方法などがある。制御メッセージを用いる場合、ＳＣＳは、セルラーネットワークへのゲートウェイであるＩＷＦ（Interworking Function）に対して、データを含む制御メッセージを送信する。

【0004】

このメッセージはデバイストリガ要求（Device Trigger Request、以下トリガ要求とも呼ぶ）と呼ばれ、デバイストリガ要求を受けたＭＴＣ−ＩＷＦは、データなどのトリガ情報をＵＥに対して通知するための手段を選択し、送信処理を開始する。ＵＥへトリガ情報を通知するメッセージ（デバイストリガ、以下トリガとも呼ぶ）としては、ＳＭＳ−ＳＣを介してＳＭＳ（Short Message Service）メッセージとして送信する方法や、ＣＢＣを介してＣＢＳ（Cell Broadcast Service）メッセージとして送信する方法、ＭＢＭＳ（Multicast Broadcast Message Service）メッセージとして送信する方法、さらにはコアネットワーク内のエンティティを介して送信される制御メッセージとして送信する方法などを用いることができる。例えば、ＩＷＦが制御メッセージを用いることを選択した場合、ＩＷＦはＭＭＥ／ＳＧＳＮ／ＭＳＣに対してトリガ情報を含めた制御メッセージ（Ｔ５インタフェース）を送信し、その制御メッセージを受けたＭＭＥ／ＳＧＳＮ／ＭＳＣは、ＵＥに対してトリガ情報を含んだＮＡＳ（Network Access Stratum）メッセージを送信する。トリガを受けたＵＥは、ＭＭＥ／ＳＧＳＮ／ＭＳＣに対してトリガ応答を送信する。トリガ応答には必要に応じてＵＥのアプリケーションデータを含めることもできる。

【0005】

また、ＵＥがＳＣＳとデータ通信をするためのコネクション（ユーザプレーン、ＰＤＰコンテキスト、ＰＤＮコネクションなどと呼ぶ）がまだ利用可能でない場合、デバイストリガに関する処理が完了した後、ＵＥは必要に応じて適切なプロシージャ（接続、コネクション確立、コネクション有効化、ベアラ確立、ベアラ有効化、ベアラ変更）を実行する。これらのプロシージャは、コネクション確立要求やサービスリクエスト、ベアラ確立要求などの制御メッセージを送信することで開始される。トリガを受けたＵＥはコネクションを確立することでＩＰアドレスを取得でき、ＡＳへ渡すアプリケーションデータを含むＩＰパケットをＳＣＳへ送信することができる。一方、ＳＣＳは、ＵＥから受けたＩＰパケットに含まれるデータを適切なＡＳへ渡す必要がある。

【先行技術文献】

【非特許文献】

【0006】

【非特許文献1】“3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Improvements for Machine-Type Communications”, 3GPP TR 23.888, V1.6.1, February 2012.

【非特許文献2】“3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Service requirements for machine-type communications”, 3GPP TS 22.368, V11.4.0, March 2012.

【非特許文献3】“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, V11.1.0, June 2012.

【非特許文献4】“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.2.0, June 2012.

【発明の概要】

【0007】

ＳＣＳは、ＵＥのＩＰアドレスを保持していないためＩＰパケットを送信する代わりに制御メッセージを送信する。そのため、制御メッセージを送信した後にＵＥからアプリケーションデータを含むＩＰパケット受けたＳＣＳは、ＩＰヘッダの送信元アドレスに設定されているＩＰアドレスに関する情報を持っていないため、送信元のＵＥを特定することができない。また、ＩＰパケット内のアプリケーションデータの中にＵＥの識別子が含まれていたとしても、アプリケーションデータはＡＳによって解釈されるフォーマットで作成されているため、ＳＣＳはアプリケーションデータのフォーマットを解釈することができない。このため、ＳＣＳはＩＰパケットを受信する際に送信元ＵＥを認証することができないため、ＩＰパケットの送信元であるＵＥを特定しないままデータをＡＳへ渡すことになり、セキュリティリスクが生じてしまう。

【0008】

上記の問題を解決するため、本開示技術は、ＩＰパケットの送信を開始する前に制御メッセージを用いてＩＰアドレスをＳＣＳへ通知することができるようにする技術を開示する。例えば、本開示技術の一態様は、ネットワークを介して、所定の通信装置と通信を行う通信端末であって、前記所定の通信装置から送信され、制御メッセージを前記通信端末へ送信することを要求するトリガ要求メッセージに基づいて生成された前記制御メッセージを前記ネットワークから受信する制御メッセージ受信部と、前記所定の通信装置とＩＰパケットを使って前記通信をするか否かを判断する判断部と、前記制御メッセージ受信部で前記制御メッセージを受信したとき、ＩＰパケットを使って前記通信をすると判断した場合に、前記所定の通信装置との前記通信に使用するＩＰコネクションに割り当てられているＩＰアドレスを取得するコネクション管理部と、前記制御メッセージに対する応答メッセージであって、前記コネクション管理部が取得した前記ＩＰアドレスを含む応答メッセージを前記ネットワークに送信する応答メッセージ送信部とを有する通信端末を含む。上記の構成により、例えば、ＳＣＳと通信を開始する前に、ＵＥのＩＰアドレスを制御メッセージであるトリガ応答に含めてＳＣＳへ通知することができるという効果が実現される。

【0009】

なお、本開示技術の態様は、上記通信端末以外に、通信システム、コンピュータプログラム、あるいはこれらの組み合わせなどによって実現されてもよい。

【0010】

なお、本開示技術が有する効果及び利点は、上記に限定されるものではなく、更なる効果及び利点は、本明細書及び図面の開示内容から明らかとなるであろう。上記更なる効果及び利点は、本明細書及び図面に開示されている様々な実施の形態及び特徴によって個別に提供されてもよく、必ずしもすべての効果及び利点が提供される必要はない。

【0011】

本開示技術の一態様によれば、例えば、ＳＣＳと通信を開始する前に、ＵＥのＩＰアドレスを制御メッセージであるトリガ応答に含めてＳＣＳへ通知することができるという効果が実現される。

【図面の簡単な説明】

【0012】

【図1】本開示技術の第１の実施の形態におけるネットワーク構成の一例を示す図

【図2】本開示技術の第１の実施の形態におけるＳＣＳ３００及びＵＥ１００の動作の第1の例を示すシーケンス図

【図3】本開示技術の第１の実施の形態において、デバイストリガを受けたＵＥ１００が行う処理の一例を示すシーケンス図

【図4】本開示技術の第１の実施の形態において、トリガレポートを受けたＳＣＳ３００が行う処理の一例を示すシーケンス図

【図5】本開示技術の第１の実施の形態において、ＳＣヘッダが付加された場合のトリガ応答のメッセージ構成の一例を示す図

【図6】本開示技術の第１の実施の形態におけるＳＣＳ３００及びＵＥ１００の動作の第２の例を示すシーケンス図

【図7】本開示技術の第１の実施の形態において、デバイストリガを受けたＵＥ１００が行う処理の一例を示すフローチャート

【図8】本開示技術の第１の実施の形態におけるＵＥ１００の構成の一例を示すブロック図

【図9】本開示技術の第１の実施の形態におけるＳＣＳ３００の構成の一例を示すブロック図

【図10】本開示技術の第２の実施の形態におけるＳＣＳ３００及びＵＥ１００の動作の例を示すシーケンス図

【図11】デバイストリガを受けたＵＥ１００が行う処理の第１の例を示すフローチャート

【図12】デバイストリガを受けたＵＥ１００が行う処理の第２の例を示すフローチャート

【発明を実施するための形態】

【0013】

以下、図面を参照しながら、本開示技術の第１〜第２の実施の形態について説明する。本開示技術の第１の実施の形態では、デバイストリガを受信したＵＥがＡＳへ送信するアプリケーションデータに基づいて、ＩＰアドレスをＳＣＳへ通知するか否かを判断する方法について説明する。また、本開示技術の第２の実施の形態では、デバイストリガの中のトリガペイロードに含まれているアプリケーションデータに基づいて、ＩＰアドレスをＳＣＳへ通知するか否かを判断する方法について説明する。

【0014】

（第１の実施の形態）
まず、本開示技術の第１の実施の形態について説明する。図１は、本開示技術の第１の実施の形態におけるネットワーク構成の一例を示す図である。図１には、セルラー通信端末であるＵＥ１００と、ＵＥ１００が接続するセルラーネットワーク（コアネットワーク、３ＧＰＰネットワークとも呼ぶ。以下、単にネットワークと記載することもある）２００と、ＵＥ１００宛てのトリガ要求の送信を行うＳＣＳ３００、及びＵＥ１００とデータ通信を行うアプリケーションサーバ４００が図示されている。

【0015】

また、図１には、セルラーネットワーク２００の構成要素として、セルラーネットワーク２００とＳＣＳ３００を繋ぐＩＷＦ２１０、ＵＥ１００の位置情報（ロケーション）の管理やＵＥ１００の通信制御（回線交換制御又はパケット交換制御）などを行うＭＭＥ／ＳＧＳＮ／ＭＳＣ（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、又はＧＭＳＣ／ＩＷＭＳＣ）２７０、ＩＷＦ２１０のＩＤとＩＰアドレスの対応関係を保持するＤＮＳ２８０が図示されている。

【0016】

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

【0017】

ＳＣＳ３００は、ＡＳ４００からアプリケーションデータを取得した際にＵＥ１００のＩＰアドレスを保持していない場合は、ＩＷＦ２１０に対してＵＥ１００宛のデバイストリガ（制御メッセージ）の送信要求を送信する。一方、ＩＷＦ２１０は、ＳＣＳ３００からトリガ要求を受けた場合、ネットワーク２００を介してデータを含むトリガ情報をＵＥ１００へ送信する。なお、トリガ情報を送信する手段としては、ＳＭＳメッセージやＣＢＳメッセージ、ＭＭＥ２２０宛のメッセージなどの制御メッセージ（Ｃ−ｐｌａｎｅ（コントロールプレーン））を用いる方法など複数あるが、ＩＷＦ２１０はＵＥの情報やネットワークの混雑状況などに基づいていずれかの手段を選択する。

【0018】

セルラーネットワーク２００内には、３ＧＰＰの無線ネットワーク及びコアネットワークを構成する複数のエンティティが存在し、ＭＭＥ２２０及びＳＭＳ−ＳＣ２７０は、ＩＷＦ２１０からの要求を受け、トリガ情報を含むＳＭＳメッセージであるデバイストリガをＵＥ１００へ送信する役割を持つ。デバイストリガとして従来のＳＭＳを用いる場合、ＩＷＦ２１０はＳＭＳ−ＳＣ２７０へデバイストリガの送信を要求し、ＳＭＳ−ＳＣ２７０はＭＭＥ２２０に対してＳＭＳの送信を要求する。ＭＭＥ２２０は、ＳＭＳ−ＳＣ２７０から受信したＳＭＳをＵＥ１００へ送信する。例えば、ＭＭＥ２２０は、Downlink NAS TransportのNAS message containerにＳＭＳを含めてＵＥ１００へ送信する。一方、ＭＳＣ２２０の場合は、ＳＭＳ専用のメッセージをＵＥ１００へ送信する。

【0019】

また、デバイストリガをＭＭＥ２２０へ通知するために、ＩＷＦ２１０は、ＭＭＥ２２０と繋がるインタフェースを用いてトリガ要求を送信することもできる。この場合、ＭＭＥ２２０は、ＩＷＦ２１０からトリガ要求を受けたら、そのトリガ要求に含まれるトリガ情報をDownlink NAS TransportのNAS message containerに含めてデバイストリガとして送信してもよいし、他のＮＡＳメッセージに含めてデバイストリガとして送信してもよい。NAS message containerにトリガ情報を入れる際、トリガ情報をＳＭＳのフォーマットに変換したものを入れてもよい。

【0020】

一方、ＩＷＦ２１０がＰ−ＧＷ２３０へ繋がるインタフェースを持っている場合、Ｐ−ＧＷ２３０に対してトリガ情報を含むＩＰパケットをＵＥ１００へ送信するよう要求することもできる。しかし、本開示技術のＩＷＦ２１０はこの方法を用いない。

【0021】

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

【0022】

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

【0023】

例えば、デバイストリガを受けたアプリケーションがＳＣＳ３００とデータ通信を行うために必要なコネクション（ＰＤＮコネクション、デフォルトベアラ、専用ベアラ）が未確立（利用可能でない）であった場合は、必要なコネクションを確立するために制御メッセージ（ＰＤＮコネクション確立要求、専用ベアラ確立要求（ベアラ確立要求、ベアラ変更要求））を送信する。なお、新たに専用ベアラを確立する代わりに、既存のベアラを更新してアプリケーションの要求を満たすベアラに変更してもよい。コネクションが確立されるとＵＥ１００はＩＰアドレスを取得でき、確立済みのコネクションを介してＳＣＳ３００へデータパケット（アプリケーションのメッセージ）を送信することができる。

【0024】

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

【0025】

なお、本開示技術の第１の実施の形態では、ＵＥ１００の通信相手としてアプリケーションサーバ４００を想定して説明しているが、ＵＥ１００の通信相手はアプリケーションサーバ４００に限らず、他のＵＥであってもよい。また、図１で示すセルラーネットワーク２００としては、ＬＴＥ／ＳＡＥ／ＥＰＳ（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）などを用いてもよいが、その場合の各種エンティティの名称はその仕様に準ずる。

【0026】

図２は、本開示技術の第１の実施の形態におけるＳＣＳ３００及びＵＥ１００の動作の第1の例を示すシーケンス図である。ＳＣＳ３００はＡＳ４００から取得したデータをＵＥ１００へ送信するためにトリガ要求をＩＷＦ２１０へ送信する。なお、ＳＣＳ３００は、トリガ要求の送信先であるＩＷＦ２１０のＩＰアドレスをＤＮＳ２８０へ問い合わせてもよい。すでにＩＷＦ２１０のＩＰアドレスを保持している場合は、ＤＮＳ２８０への問合せは省略される。ＳＣＳ３００はＩＷＦ２１０に対してＵＥ１００のＩＤ（External Identifier又はMSISDN（Mobile Subscriber ISDN Number））、ＳＣＳ３００のＩＤなどを含めたトリガ要求を送信する（ステップＳ２００２）。

【0027】

また、ＳＣＳ３００は、トリガ要求の中のペイロードフィールド（以下、トリガペイロードと呼ぶ）にＵＥ１００のアプリケーションへ通知する情報を含める。ＵＥ１００のアプリケーションに通知する情報とは、ＡＳ４００から取得したデータやＳＣＳ３００が生成したデータである。ＳＣＳ３００は、ＡＳ４００から取得したデータのサイズがトリガペイロードのサイズよりも小さい場合は、全てのデータをトリガペイロードに含めてもよい。一方、ＡＳ４００から取得したデータのサイズがトリガペイロードのサイズよりも大きい場合は、データの一部をトリガペイロードに含め、残りをＩＰパケットとして送信してもよいし、又は全てのデータをＩＰパケットとして送信してもよい。

【0028】

なお、トリガペイロード内のデータは、コアネットワーク内のエンティティ（ＩＷＦ２１０やＭＭＥ２２０など）に対しては透過的であり、ＳＣＳ３００によって挿入された情報のままＵＥ１００へ通知される。トリガ要求に含まれるＵＥ１００のＩＤは、ＩＷＦ２１０及びＭＭＥ２２０が送信する制御メッセージの送信先（ターゲット）を示している。トリガ要求を受けたＩＷＦ２１０は、トリガ要求の送信元であるＳＣＳ３００の確認や、トリガの送信先であるＵＥ１００の登録情報（サブスクリプション情報）の確認、及びトリガ要求のロードコントロールのチェックなどを行う。ＳＣＳ３００の確認とは、ＳＣＳ３００から受信したトリガ要求を受け入れてもよいか否かのチェックであり、例えば、デバイストリガの送信を許可（Authorize）されたＳＣＳであるか否か、ＳＣＳ３００がトリガ要求の送信を制限されているＳＣＳでないか、受信したトリガ要求のメッセージにフォーマットエラーがないか、などの確認である。

【0029】

また、トリガ要求のロードコントロールをチェックとは、トリガ要求の送受信によるネットワーク帯域やトラフィックロード、契約内容に関するチェックであり、例えば、ＳＣＳ３００が送信したトリガ要求の送信回数（Submission Quota）が規定値を超えていないか、トリガ要求の送信頻度（Submission Rate）が規定値を超えていないか、ＩＷＦの処理負荷が過負荷（Overload）になっていないかなどの負荷状況の確認である。例えば、ＳＣＳ３００から受信したトリガ要求の送信頻度が規定値（契約で決められた上限値など）を超えていた場合は、ロードコントロールに問題があると判断してトリガ要求を拒絶する。

【0030】

さらに、ＵＥ１００の登録情報のチェックとは、ＨＳＳ（Home Subscription Server）へＵＥ１００の情報を問い合わせ、デバイストリガをＵＥへ送信できるか否かなどを確認する。例えば、ＵＥの情報を確認した結果、ＵＥがデバイストリガの受信資格がなかった場合や、ＵＥがデバイストリガを受信できる状態にない場合は、ＵＥの情報に問題があると判断しトリガ要求を拒絶する。これらのチェックに問題がなかった場合、ＩＷＦ２１０は、ＭＭＥ２２０に対してデバイストリガの要求を送信する（ステップＳ２００３）。これを受けたＭＭＥ２２０は、ＵＥ１００に対してトリガ情報を含む制御メッセージ（デバイストリガ）を送信する（ステップＳ２００４）。

【0031】

図３は、デバイストリガを受けたＵＥ１００が行う処理（図２のステップＳ２００４〜Ｓ２００６）の一例を示すフローチャートである。デバイストリガを受けたＵＥ１００は（Ｓ３００１）、ＡＳ４００とデータ通信をするためのコネクションがあるか否かを確認する（Ｓ３００２）。コネクションがない場合は、コネクションを確立するための処理を実行する（Ｓ３００３）。この場合、ＵＥ１００は、コネクションを確立してＩＰアドレスを取得することができるまで、デバイストリガに対するトリガ応答を送信しない。そして、そのコネクションに割り当てられているＩＰアドレスをトリガ応答の所定のフィールド（トリガペイロード）に含め（Ｓ３００４）、ＭＭＥ２２０へ送信する（Ｓ３００５）。

【0032】

ＡＳ４００とデータ通信をするためのコネクションとは、ＡＳ４００が存在するＰＤＮ（Packet Data Network）に接続するコネクションである。つまり、受信したデバイストリガの中のトリガペイロードに含まれているデータから導かれたＡＰＮ（Access Point Name）や、デバイストリガの対象であるアプリケーションに対応するＡＰＮによって識別されるＰＤＮ上のＳＣＳ３００と通信をするためのコネクションである。ＵＥ１００は、ＳＣＳ３００がＩＷＦ２１０から受信するトリガレポートからＩＰアドレスを適切に取り出すことができるよう、ＳＣＳ３００が解釈できるフォーマットにＩＰアドレスを含めてトリガペイロードに挿入する。

【0033】

例えば、ＳＣＳ３００が解釈できるフォーマットで構成されたヘッダ（以下、ＳＣ（Service Capability）ヘッダと呼ぶ）を作成し、そのヘッダにＩＰアドレスを含めてトリガペイロードの所定の位置（最前部又は最後部）に配置する。もしＵＥ１００からＡＳ４００へ通知するデータがある場合は、そのデータの先頭にＳＣヘッダを付加したものをトリガペイロードに挿入する。

【0034】

図５は、ＳＣヘッダが付加された場合のトリガ応答のメッセージ構成の一例を示す図である。ＵＥ１００から送信されたトリガ応答を受けたＭＭＥ２２０は、トリガ応答に含まれているトリガペイロードをトリガレポートに含めＩＷＦ２１０へ送信し、さらにＩＷＦ２１０はそのトリガレポートをＳＣＳ３００へ送信する(ステップＳ２００７、Ｓ２００８)。なお、図２では、ステップＳ２００６をトリガ応答と呼び、ステップＳ２００７、Ｓ２００８をトリガレポートと呼んで区別しているが、ＵＥ１００が挿入したトリガペイロード（ＳＣヘッダ及びデータ）をＳＣＳ３００へ通知することができるメッセージであればどのようなメッセージを用いてもよい。

【0035】

図４は、トリガレポートを受けたＳＣＳ３００が行う処理（図２のステップＳ２００８〜Ｓ２０１０）の一例を示すフローチャートである。トリガレポートを受けたＳＣＳ３００は（Ｓ４００１）、トリガレポートのトリガペイロードに含まれている情報を取得し（Ｓ４００２）、そのトリガペイロードにＩＰアドレスを含むＳＣヘッダが含まれているか否かを確認する（Ｓ４００３）。ＳＣヘッダがある場合は、ＳＣヘッダに含まれているＩＰアドレスを取得し、ＩＰアドレスとＵＥのＩＤを関連付けて保持する（Ｓ４００４）。そして、ＳＣヘッダを取り除いた残りの部分をデータとしてＡＳへ通知する（Ｓ４００５）。ＩＷＦ２１０とＳＣＳ３００の間で送受信されるメッセージは秘匿性や完全性などのセキュリティ用件を満たすメッセージ（制御メッセージ）であるため、ＳＣＳ３００は、ＩＷＦ２１０から受信するトリガレポートに含まれているＩＰアドレスがＵＥ１００のＩＰアドレスであることを信用することができる。ＵＥ１００がユーザプレーンを用いてＩＰアドレスをＳＣＳ３００へ通知する場合にはＩＰＳｅｃなどのセキュリティメカニズムを用いてセキュリティを確保する必要があるため、ＵＥ１００とＳＣＳ３００の処理負荷が増すが、制御メッセージを用いてＩＰアドレスを通知することでその処理負荷を軽減することができる。

【0036】

ステップＳ４００３において、ＩＰアドレスを含むＳＣヘッダがない場合はトリガペイロードの中の全ての情報をデータとしてＡＳへ通知する（Ｓ４００５）。一方、ＳＣヘッダからＵＥ１００のＩＰアドレスの取得をした後は、ＳＣヘッダを取り除いた残りの情報をデータとしてＡＳへ通知する（Ｓ４００５）。なお、Ｓ４００３において、ＳＣヘッダは存在しているが、ＩＰアドレスが含まれていない場合も同様に、ＳＣヘッダを取り除いた残りの部分をデータとしてＡＳへ通知する。図２に戻り、ＵＥ１００は、データを含むＩＰパケットをＳＣＳ３００へ送信する（Ｓ２０１１）。

【0037】

ＩＰパケットを受信したＳＣＳ３００は、ＩＰパケットの送信元アドレスの確認を行い（Ｓ２０１２）、送信元のＩＰアドレスを保持している場合は、ＩＰペイロードに含まれているデータをＡＳ４００へ通知する（Ｓ２０１３）。一方、送信元アドレスに対応するＩＰアドレスを保持していない場合は、送信元のＵＥを特定できないため、ＩＰパケットを破棄する。送信元のＩＰアドレスを保持している場合とは、送信元のＩＰアドレスが、ステップＳ２００９のトリガレポートで通知されたＩＰアドレスに一致する場合であり、そのＩＰアドレス対応するＵＥを特定できる場合である。なお、ＩＰペイロードの中のデータにＳＣＳ３００が処理するべきヘッダが付加されている場合は、それらのヘッダを取り除いた残りの部分のデータをＡＳ４００へ通知する。

【0038】

図６は、本開示技術の第１の実施の形態におけるＳＣＳ３００及びＵＥ１００の動作の第２の例を示すシーケンス図である。図２を用いて説明した第１の例との違いは、トリガを受けたＵＥ１００が、ステップＳ６００６においてコネクションの有無を確認する前に、ステップＳ６００５において、ＡＳ４００へ送信するアプリケーションデータを確認するところである。その他のステップについては、図２と同じであるため説明を省略する。

【0039】

図７は、デバイストリガを受けたＵＥ１００が行う処理（ステップＳ６００４〜Ｓ６００７）の一例を示すフローチャートである。図３を用いて説明した第１の例におけるＵＥ１００の動作との違いは、ステップＳ７００２において、ＵＥ１００のアプリケーションからＡＳ４００へ通知するデータをＩＰパケットで送信する必要があるか否かを確認するところである。デバイストリガを受けたＵＥ１００は（Ｓ７００１）、デバイストリガに含まれているトリガペイロードをアプリケーションへ通知する（Ｓ７００２）。もしアプリケーションが起動されていない場合は、デバイストリガの対象となるアプリケーションを起動した後にデータを通知する。なお、ＵＥ１００のＮＡＳレイヤがデバイストリガを受信し、トリガペイロードを適切なアプリケーション又はアプリケーションを制御するレイヤ（以下、ＳＣ（Service Capability）レイヤ）へ通知する。ＳＣレイヤはトリガペイロードの処理を行い、必要に応じてトリガペイロードに含まれているデータを適切なアプリケーションへ通知する役割を持つ。

【0040】

例えば、ＳＣヘッダに含まれているアプリケーションＩＤから対象となるアプリケーションを特定（起動）し、そのアプリケーションに対してＳＣヘッダを取り除いた残りの情報をデータとして通知する。つまり、ＵＥ１００のＮＡＳレイヤは、受信したデバイストリガに対するトリガ応答を送信する前に、ＳＣレイヤ及びアプリケーションによるトリガペイロード及びデータの処理結果が通知されるまで待機する。なお、これらのＳＣレイヤの機能は、ＮＡＳレイヤとアプリケーションレイヤの間に位置するレイヤによって提供されてもよいし、アプリケーションレイヤで動作する１つのアプリケーションとして提供されてもよいし、ＮＡＳレイヤによって提供されてもよい。

【0041】

トリガペイロードを処理した結果、ＡＳ４００へ送信するアプリケーションデータがある場合は、そのデータはＩＰパケットを用いて送信する必要があるデータか否かを確認する（Ｓ７００３）。データをＩＰパケットで送信する必要がある場合とは、データのサイズがトリガ応答に含められるデータサイズ（トリガペイロードのサイズ）よりも大きい場合などである。また、ＡＳ４００へ送信するデータの生成に時間を要する場合（ＳＣレイヤ又はアプリケーションへトリガペイロードを通知してから一定時間経過した場合）は、ＮＡＳレイヤは、ＩＰパケットを用いてデータを送信する必要があると判断してもよい。なお、ＩＰパケットでデータを送る必要があるか否かの判断は、ＵＥ１００のＮＡＳレイヤだけで行ってもよい。例えば、デバイストリガに含まれているＳＣＳ３００の識別情報や、データを生成したＡＳ４００の識別情報に基づいて、ＩＰパケットを用いたデータ通信が必要であるか否かを確認する。

【0042】

データをＩＰパケットで送信する必要がある場合は、ＡＳ４００とデータ通信をするためのコネクションがあるか否かを確認する（Ｓ７００４）。ステップＳ７００４以降の動作は図３のステップＳ３００２以降の動作と同じであるため説明を省略する。一方、ＵＥ１００のアプリケーションからＡＳ４００へ通知するデータをＩＰパケットで送信する必要がない場合は、データのみを含むトリガペイロードを挿入したトリガ応答を送信する（Ｓ７００７）。なお、ＵＥ１００は、ＩＰアドレスを含まないＳＣヘッダをデータに付加したものをトリガペイロードに挿入し、そのトリガペイロードを含むトリガ応答を送信してもよい。

【0043】

次に、本開示技術の第１の実施の形態におけるＵＥ１００の構成例について説明する。図８は、本開示技術の第１の実施の形態におけるＵＥ１００の構成の一例を示すブロック図である。図８に図示されているＵＥ１００は、インタフェース１０１、デバイストリガ処理部１０２、コネクション管理部１０３、アプリケーション部１０４、トリガ応答送信部１０５、ＩＰパケット送信部１０６を有している。

【0044】

インタフェース１０１は、ＵＥ１００がネットワークに接続して制御メッセージやＩＰパケットを送受信するための機能を有している。インタフェース１０１には、他の通信装置（例えば、ネットワーク上に配置されているネットワークノードや他のＵＥ１００など）と通信を行うために、情報を電気的な信号に変調及び復調するハードウェアも含まれる。デバイストリガ受信部１０２は、デバイストリガを受信し、デバイストリガに含まれているトリガペイロードをアプリケーション部１０４へ渡す。また、コネクション管理部１０３に対して、コネクションの確立を行うよう指示する。

【0045】

コネクション管理部１０３は、デバイストリガ受信部１０２又はトリガ応答送信部１０５の指示を受け、コネクションの確立を行う。ＡＳ４００との通信に使用できるコネクションが既にある場合は、そのコネクションに割り当てられているＩＰアドレスをトリガ応答送信部１０５へ通知する。なお、コネクション管理部１０３が行う処理は、新たなコネクションの確立に限らず、確立済みコネクションの変更なども含む。アプリケーション部１０４は、デバイストリガ受信部１０２から通知されたトリガペイロードをチェックし、ＡＳ４００に対して送信するデータを生成し、トリガ応答送信部１０５へ通知する。トリガ応答送信部１０５は、アプリケーション部１０４から通知されたデータをＩＰパケットで送る必要がある場合は、コネクション管理部１０３からＩＰアドレスを取得し、ＩＰアドレスを含むトリガ応答を送信する。また、トリガ応答を送信した後、ＩＰパケット送信部に対してデータをＩＰパケットで送信するよう指示する。ＩＰパケット送信部１０６は、トリガ応答送信部１０５から受けたＡＳ４００へ通知するデータを含むＩＰパケットをＳＣＳ３００宛に送信する。

【0046】

次に、本開示技術の第１の実施の形態におけるＳＣＳ３００の構成例について説明する。図９は、本開示技術の第１の実施の形態におけるＳＣＳ３００の構成の一例を示すブロック図である。図９に図示されているＳＣＳ３００は、インタフェース４００、トリガ要求送信部３０２、送信手段判断部３０３、ＩＰパケット受信部３０４、アプリケーション部３０５、ＵＥ情報保持部３０６、トリガ応答受信部３０７を有している。

【0047】

インタフェース１０１は、ＵＥ１００がネットワークに接続して制御メッセージやＩＰパケットを送受信するための機能を有している。インタフェース１０１には、他の通信装置（例えば、ネットワーク上に配置されているネットワークノードや他のＵＥ１００など）と通信を行うために、情報を電気的な信号に変調及び復調するハードウェアも含まれる。トリガ要求送信部３０２は、送信手段判断部３０３の指示を受け、ＵＥ１００に対するデバイストリガの送信を要求するためのトリガ要求をＩＷＦ２１０へ送信する。トリガ要求のトリガペイロードにはアプリケーション部３０５から通知されたデータを含める。送信手段判断部３０３は、アプリケーション部３０５から通知されたデータをＵＥ１００へ送信するための手段を選択する。

【0048】

トリガ要求を送信手段として選択した場合は、トリガ要求送信部３０２に対してトリガ要求を送信するよう指示する。ＩＰパケット受信部３０４は、ＵＥ情報保持部３０６に保持されているＵＥのＩＤとＩＰアドレスの対応関係を参照し、受信したＩＰパケットの送信元アドレスを持つＵＥを特定する。送信元のＵＥを特定できた場合は、ＩＰパケットに含まれているデータをアプリケーション部３０５へ通知する。アプリケーション部３０５は、ＡＳ４００からデータを受け、送信手段判断部３０３に対してＵＥ１００へ送信するよう指示する。

【0049】

また、ＩＰパケット受信部３０４及びトリガ応答受信部３０７から受けたデータをＡＳ４００へ通知する。なお、アプリケーション部３０５は、ＡＳ４００の機能を含んでいてもよい。ＵＥ情報保持部３０６は、ＵＥのＩＤとＩＰアドレスの対応関係を保持している。トリガレポート受信部３０７は、トリガレポートを受信し、トリガレポートに含まれているトリガペイロードの中のＳＣヘッダに設定されているＩＰアドレスを取得し、ＵＥ情報保持部３０６へ保持するよう指示する。さらに、ＳＣヘッダを取り除いた残りのトリガペイロードをアプリケーション部３０５へ通知する。

【0050】

以上説明したように、本開示技術の第１の実施の形態によれば、ＵＥ１００は、受信したデバイストリガに対する応答を返す前に、ＡＳ４００と通信をするためのコネクションの確立を行い、割り当てられたＩＰアドレスをＳＣＳ３００が解釈できるフォーマットでトリガ応答に含めることができるため、ＳＣＳ３００は、コアネットワーク２００から受信した信頼できるトリガレポートメッセージに含まれるＵＥ１００のＩＰアドレスを保持することができる。また、ＵＥ１００からＩＰパケットを受信する前に、ＵＥ１００のＩＰアドレスを知ることができるため、受信したＩＰパケットの送信元アドレスを確認できた場合にデータをＡＳ４００へ通知する。これにより、ＵＥ１００のＩＰアドレスは信頼できるメッセージでＳＣＳ３００へ通知されるため、ＳＣＳ３００は、信頼できるＩＰアドレスから送られたＩＰパケットだけを受信し、そのＩＰパケットに含まれるデータをＡＳ４００へ通知することができる。

【0051】

（第２の実施の形態）
次に、本開示技術の第２の実施の形態において、デバイストリガの中のアプリケーションペイロードに含まれているアプリケーションデータに基づいて、ＩＰアドレスをＳＣＳへ通知する方法について説明する。

【0052】

図１０は、本開示技術の第２の実施の形態におけるＳＣＳ３００及びＵＥ１００の動作の第１の例を示すシーケンス図である。図２を用いて説明した本開示技術の第１の実施の形態の第１の例との違いは、トリガを受けたＵＥ１００が、ステップＳ１０００５において受信したアプリケーションデータを確認するところである。その他のステップについては、図２と同じであるため説明を省略する。図１１は、デバイストリガを受けたＵＥ１００が行う処理（ステップＳ１０００４〜Ｓ１０００７）の第１の例を示すフローチャートである。図３を用いて説明した本開示技術の第１の実施の形態の第１の例におけるＵＥ１００の動作との違いは、ステップＳ１１００３において、トリガペイロードの中にデータが含まれているか否かを確認するところである。

【0053】

デバイストリガを受けたＵＥ１００は（Ｓ１１００１）、デバイストリガに含まれているトリガペイロードを取得する（Ｓ１１００２）。トリガペイロードにデータが含まれているか否かを確認し（Ｓ１１００３）、含まれていない場合は、ＳＣＳ３００はＡＳ４００から通知されたデータをＩＰパケットで送信するために、ＵＥ１００からＩＰアドレスが通知されるのを待っていると解釈する。そのため、ステップＳ１１００４及びステップＳ１１００５の処理を経た後、最終的にＵＥ１００はトリガ応答の中にＩＰアドレスを含むＳＣヘッダをトリガペイロードに挿入して送信する（Ｓ１１００６、Ｓ１１００７）。ステップＳ１１００４以降の処理は図２と同じであるため説明を省略する。

【0054】

一方、トリガペイロードにデータが含まれている場合は、ＳＣＳ３００はＡＳ４００から通知されたデータをトリガペイロードに含めていると解釈し、ＳＣＳ３００はＡＳ４００から通知されたデータをＩＰパケットで送信する必要がないかもしれないと解釈する。そのため、ＵＥ１００は、ＩＰアドレスを含まないトリガ応答を送信する（Ｓ１１００７）。なお、ＵＥ１００は、データのみを含むトリガペイロードを挿入したトリガ応答を送信してもよいし、ＩＰアドレスを含まないＳＣヘッダを付加したデータを含むトリガペイロードを挿入したトリガ応答を送信してもよい。なお、ステップＳ１１００３において、トリガペイロードの中にＳＣヘッダが含まれている場合には、ＳＣヘッダを取り除いた残りの部分にデータが含まれているか否かを確認し、データが含まれていた場合にはステップＳ１１００７へ進み、含まれていない場合にはステップＳ１１００４へ進む。ＳＣヘッダに基づいてＩＰアドレスを通知するべきか否かを判断する方法については後述する。

【0055】

図１０に戻り、ＵＥ１００は、データを含むＩＰパケットをＳＣＳ３００へ送信する（Ｓ１００１２）。ＩＰパケットを受信したＳＣＳ３００は、ＩＰパケットの送信元アドレスの確認を行い（Ｓ１００１３）、送信元のＵＥを特定できた場合は、データをＡＳ４００へ通知する（Ｓ１００１４）。一方、送信元アドレスに対応するＵＥを特定できなかった場合は、データをＡＳ４００へ通知せずにＩＰパケットを破棄する。

【0056】

図１２は、デバイストリガを受けたＵＥ１００が行う処理（ステップＳ１０００４〜Ｓ１０００７）の第２の例を示すフローチャートである。図１１を用いて説明した本開示技術の第２の実施の形態の第１の例におけるＵＥ１００の動作との違いは、ステップＳ１２００２においてコネクションがない場合に、トリガペイロードを取得し（Ｓ１２００３）、そのトリガペイロードにデータが含まれているか否かを確認する。データが含まれていない場合は、ＳＣＳ３００はＡＳ４００から通知されたデータをＩＰパケットで送信するために、ＵＥ１００からＩＰアドレスが通知されるのを待っていると解釈する。そのため、ＵＥ１００はコネクション確立処理を実行し（Ｓ１２００７）、ＩＰアドレスを含むＳＣヘッダをトリガペイロードに挿入し、そのトリガペイロードを含むトリガ応答を送信する（Ｓ１２００８、Ｓ１２００９）。

【0057】

一方、データが含まれている場合には、ＩＰアドレスの遅延通知情報をＳＣヘッダに含め、そのＳＣヘッダをトリガペイロードに挿入し（Ｓ１２００５）、そのトリガペイロードを含むトリガ応答を送信する（Ｓ１２００６）。そして、平行してコネクションの確立処理を実行し（Ｓ１２００７）、確立したコネクションに割り当てられたＩＰアドレスを含むＳＣヘッダをトリガペイロードに挿入し（Ｓ１２００８）、そのトリガペイロードを含むトリガ応答を再度送信する（Ｓ１２００９）。ＳＣＳ３００は、ＩＰアドレスの遅延通知を含むトリガレポートを受信した場合、その遅延通知をＵＥ１００のＩＤと関連付けて保持する。そして、ＡＳ４００からＵＥ１００に対して通知するデータを受けたときに、ＵＥ１００のＩＰアドレスを保持していない場合であってもトリガ要求を送信するのではなく、ＵＥ１００からＩＰアドレスが通知されるのを待つべきと判断する。そしてＵＥ１００からＩＰアドレスが通知されたら、ＡＳ４００から受けたデータをＩＰパケットを用いてＵＥ１００へ送信する。

【0058】

また、本開示技術の第２の実施の形態におけるＳＣＳ３００及びＵＥ１００の動作の第２の例として、ＳＣＳ３００はＩＷＦ２１０へ送信するトリガ要求のトリガペイロードの中にＳＣヘッダを含める。この場合、ＳＣＳ３００は、ＡＳ４００から受けたデータの先頭にＳＣヘッダを付加したものをトリガペイロードに挿入する。このＳＣヘッダのＩＰアドレスを含めるフィールドにはＳＣＳ３００のＩＰアドレスが含まれていてもよい。またこのＳＣヘッダのアプリケーションＩＤを含めるフィールドにはＡＳ４００の識別子、又はＡＳ４００で動作しているアプリケーションの識別子が含まれていてもよい。

【0059】

また、ＳＣＳ３００は、ＡＳ４００から取得したデータのサイズがトリガペイロードのサイズよりも大きい場合は、ＵＥ１００に対してＩＰアドレスの通知を要求するために、トリガペイロードにＳＣヘッダを含めてもよい。この場合、ＳＣＳ３００は、ＡＳ４００から通知されたデータの一部に対してＳＣヘッダを付加したものをトリガペイロードに挿入してもよいし、ＳＣヘッダのみをトリガペイロードに挿入してもよい。ＳＣＳ３００は、ＵＥ１００からＩＰアドレスの通知を受けるまで、トリガペイロードに入れられなかったデータを保持し、ＵＥ１００のＩＰアドレスを取得した後に、ＩＰパケットとしてＵＥ１００へ送信する。

【0060】

なお、ＳＣＳ３００は、ＵＥ１００のＩＰアドレスの通知を要求していることを示す情報をＳＣヘッダの中に明示的に含めてもよい。例えば、ＩＰアドレスの通知を要求していることを示すフラグをＳＣヘッダにセットすることや、ＵＥ１００のＩＰアドレスを含めるフィールドを空（ゼロ値）又は任意の値にすることで、ＵＥ１００のＩＰアドレスの通知を要求していることを示してもよい。また、これとは反対に、ＵＥ１００のＩＰアドレスの通知が不要であることを示す情報をＳＣヘッダの中に明示的に含めてもよい。

【0061】

デバイストリガを受けたＵＥ１００のＮＡＳレイヤは、デバイストリガに含まれているトリガペイロードをＳＣレイヤへ渡す。ＳＣレイヤは、トリガペイロードにＳＣヘッダが含まれていた場合や、ＳＣヘッダにＩＰアドレスの通知を要求する情報が含まれていた場合には、ＳＣＳ３００へＩＰアドレスを通知する必要があると判断し、ＩＰアドレスが設定されたＳＣヘッダを含むトリガペイロードをトリガ応答に挿入して送信する。またＳＣレイヤは、ＳＣヘッダに含まれているアプリケーションＩＤから対象となるアプリケーションを特定（起動）し、そのアプリケーションに対してＳＣヘッダを取り除いた残りの情報をデータとして通知する。またＳＣレイヤは、ＳＣヘッダにＳＣＳ３００のＩＰアドレスが含まれている場合、そのＩＰアドレスを取得し、ＳＣＳ３００へＩＰパケットを送信する際に宛先アドレスとして使用する。

【0062】

このように、ＵＥ１００は、受信したデバイストリガのトリガペイロードの中にＳＣヘッダがあるか否か、又はＳＣヘッダの内容を確認し、ＳＣＳ３００へＩＰアドレスを通知する必要があるか否かを判断する。

【0063】

以上説明したように、本開示技術の第２の実施の形態によれば、ＵＥ１００は、受信したデバイストリガのトリガペイロードを確認することで、ＳＣＳ３００に対してＩＰアドレスの通知をするべきか否かを判断することができる。さらに、ＳＣＳ３００に対してＩＰアドレスを直ぐに通知する必要はないが、コネクションを確立した後にＩＰアドレスを通知することを事前に通知しておくことで、ＳＣＳ３００は、ＵＥ１００に対してＩＰパケットを用いて送信するべきデータがあったとしても、直ぐにデバイストリガ要求を送信するのではなく、ＵＥ１００からのＩＰアドレスの通知を待つべきであると判断することができる。これにより、不要なデバイストリガ要求の送信をなくすことができる。

【0064】

本開示技術の一態様では、通信端末において、前記コネクション管理部が、前記ＩＰアドレスを取得する際、前記ＩＰコネクションが確立されていない場合に新たにＩＰコネクションを確立してもよい。

【0065】

また、本開示技術の一態様では、通信端末において、前記応答メッセージ送信部が、前記ＩＰアドレスを、前記応答メッセージの中のアプリケーション情報を入れるためのフィールドに挿入してもよい。

【0066】

また、本開示技術の一態様では、通信端末において、前記応答メッセージ送信部が、前記制御メッセージの中にアプリケーションデータが含まれていない場合に、ＩＰパケットを使って前記通信をすると判断してもよい。

【0067】

また、本開示技術の一態様では、通信端末において、前記応答メッセージ送信部が、前記所定の通信装置へ送信すべきアプリケーションデータを前記通信端末が有する場合に、ＩＰパケットを使って前記通信をすると判断してもよい。

【0068】

また、本開示技術の一態様は、通信端末とアプリケーションサーバとの通信を仲介するサーバであって、前記アプリケーションサーバからデータを取得した際、制御メッセージを前記通信端末へ送信することを要求するトリガ要求をネットワークノードへ送信するトリガ要求送信部と、前記トリガ要求に基づいて前記ネットワークから前記通信端末へ送信された前記制御メッセージに対する応答メッセージであって、前記通信端末のＩＰアドレスを含む応答メッセージを受信した前記ネットワークノードから前記ＩＰアドレスを含むレポートメッセージを受信し、前記レポートメッセージの中に含まれる前記通信端末のＩＰアドレスを取得するレポート受信部と、前記ＩＰアドレスと前記通信端末の識別情報を関連付けて保持する通信端末情報保持部とを有するサーバを含むことができる。

【0069】

また、本開示技術の一態様では、サーバにおいて、前記ＩＰアドレスが、前記レポートメッセージのアプリケーション情報を入れるためのフィールドに挿入されていてもよい。

【0070】

また、本開示技術の一態様では、サーバにおいて、受信したＩＰパケットの送信元アドレスが、前記通信端末情報保持部に保持されているＩＰアドレスと一致する場合に、前記ＩＰパケットに含まれているペイロードを前記アプリケーションサーバへ通知するＩＰパケット受信部を更に有してもよい。

【0071】

なお、例えば、上記本開示内容の各態様は適宜組み合わせることが可能である。また、本開示技術の一態様は、通信端末、サーバに加えて、通信端末などによって実現される方法、この方法をコンピュータに実行させるためのプログラム、及びこのプログラムを記録した記録媒体などによって実現されてもよい。

【0072】

また、上記実施の形態の説明に用いた各機能ブロックは、ハードウェア、ソフトウェア、あるいはこれらの組み合わせによって実現されてもよい。例えば、ブロック図などに図示されている各装置に含まれる機能ブロック、あるいは、同等の機能を有する各処理部は、任意のコンピュータのＣＰＵ、メモリ、通信インタフェースを含む各種インタフェースなどのハードウェアによって実現されてもよい。また、各機能に係る動作が記述されたプログラムをコンピュータによって実行させることで、各機能ブロックや各処理部が実現されてもよい。また、上記実施の形態におけるフローチャートやシーケンスチャートは、ＣＰＵやメモリなどのハードウェアによって実現されてもよい。

【0073】

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

【産業上の利用可能性】

【0074】

本開示技術は、ＳＣＳと通信を開始する前に、ＵＥのＩＰアドレスを制御メッセージであるトリガ応答に含めてＳＣＳへ通知することができるという効果を有しており、セルラー通信機能を利用した通信技術（特に、Ｍ２Ｍ通信の技術）に適用可能である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】