JP2013239837A - ネットワークノード及びサーバ - Google Patents

Abstract

【課題】トリガリクエストのロードコントロールの結果とともにＵＥ情報の確認結果を通知できるようにする。
【解決手段】通信端末に対して動作の開始を指示するデバイストリガを送信するネットワークノードであって、通信端末へデバイストリガを送信することを要求するトリガ要求をサーバから受信するトリガ要求受信部と、デバイストリガを通信端末に送信できるか否かを確認するＵＥ情報確認部と、ロードコントロールに問題があるか否かを確認するロードコントロール確認部と、ＵＥ情報確認部によるＵＥ情報の確認と、ロードコントロール確認部によるロードコントロールの確認の後、トリガ応答をサーバへ送信するトリガ応答送信部とを有する。
【選択図】図７

Description

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

セルラー通信機能は、携帯電話やスマートフォンなどの音声通話やデータ通信で利用されるだけでなく、Ｍ２Ｍ通信向けの機器（ＭＴＣデバイスとも呼ばれる）でも広く利用されており、ＭＴＣデバイスを含むセルラー通信端末（以下、ＵＥ（User Equipment）又は通信端末と記載する）の数は今後も増加の一途を辿っている。ユーザ及びユーザが操作するアプリケーション（以下、アプリケーションサーバと呼ぶ）がＵＥと通信を開始するためには、ＵＥに対して通信の開始を要求するメッセージを送信する必要がある。このメッセージとしてアプリケーションサーバはＵＥに対してデバイストリガ（Device Trigger）と呼ばれるメッセージを送信することができる。

デバイストリガを受けたＵＥは、ＵＥとセルラーネットワークの間にデータ通信のためのコネクション（ユーザプレーン、ＰＤＰコンテキスト、ＰＤＮコネクションなどと呼ぶ）がまだ利用可能でない場合、適切なプロシージャ（接続、コネクション確立、コネクション有効化、ベアラ確立、ベアラ有効化、ベアラ変更）を実行する。これらのプロシージャは、コネクション確立要求やサービスリクエスト、ベアラ確立要求などの制御メッセージを送信することで開始される。

アプリケーションサーバは任意のＵＥに対してデバイストリガを送信し、一方、デバイストリガを受信したＵＥは、アプリケーションサーバと通信するために必要なコネクションを利用可能にするためのプロシージャを開始する。図１６は、デバイストリガを送信する際のＳＣＳ３００及びセルラーネットワークのエンティティの動作に関する背景技術を示すシーケンス図である。アプリケーションサーバ４００は、ＳＣＳ（Service Capability Server、ＭＴＣサーバとも呼ぶ）３００に対してデバイストリガリクエスト（Device Trigger Request、以下、トリガリクエストとも呼ぶ）の送信を要求し（ステップＳ１６０００）、その要求を受けたＳＣＳ３００はＭＴＣ−ＩＷＦ（Interworking Function、以下ＩＷＦと呼ぶ）２１０に対してデバイストリガリクエストを送信する（ステップＳ１６００１）。

デバイストリガリクエストを受けたＩＷＦ２１０は必要なチェックを実行した後（ステップＳ１６００３、Ｓ１６００４、Ｓ１６００５）、ＵＥ１００に対してデバイストリガを送信するための処理を行う（ステップＳ１６００７、Ｓ１６００９）。デバイストリガとしては、セルラーネットワーク内のエンティティがＵＥへ送信する制御メッセージ（ＮＡＳ（Network Access Stratum）メッセージ）やＳＭＳ（ショートメッセージ）、ＣＢＳ（Cell Broadcast Service）、ＭＢＭＳ（Multicast Broadcast Message Service）、さらにはデータパケット（ＩＰパケット）などの様々な種類のメッセージを用いることができる。

トリガリクエストを受けたＩＷＦ２１０は、送信元のＳＣＳ３００の確認（Authorization）を行う（ステップＳ１６００３）。さらに、ＩＷＦは、ＳＣＳから受信したトリガリクエストのロードコントロールに関するチェック（送信回数（Submission Quota）が規定値を超えていないか、トリガリクエストの送信頻度（Submission Rate）が規定値を超えていないか、ＩＷＦの処理負荷が過負荷（Overload）になっていないかなど）を行う（ステップＳ１６００３）。仮に、トリガリクエストの送信頻度が規定値を超えていた場合、ＩＷＦは、ロードコントロールの問題でデバイストリガの送信ができなかったこと（Reason of Failure）を示す値（Cause Value）を含むデバイストリガ応答（又はデバイストリガ確認メッセージ（Device Trigger Confirmation Message）、以下トリガ応答と呼ぶ）をＳＣＳへ送信する（ステップＳ１６０１２）。一方、これらのチェックに問題がない場合は、ＨＬＲ／ＨＳＳ（Home Location Register/Home Subscription Server、以下ＨＳＳ）に問合せをし、応答にエラーが示されていないか、応答に含まれるＵＥのサブスクリプション情報（加入者情報、以下、ＵＥの情報）を取得し、内容を確認する（ステップＳ１６００４、Ｓ１６００５）。ここでも、仮に、ＵＥの情報を確認した結果、ＵＥがデバイストリガの受信資格がなかった場合、ＵＥ情報の問題でデバイストリガの送信ができなかった(認められなかった)ことを示す値を含むトリガ応答をＳＣＳへ送信する（ステップＳ１６０１３）。

"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. "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. "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.0.0, March 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.1.0, March 2012.

ＩＷＦは、ロードコントロールのチェックで問題（送信頻度の超過など）を検出した後すぐにトリガ応答をＳＣＳへ送信してデバイストリガの送信ができなかったことを通知した場合、ＳＣＳはＩＷＦに対してトリガリクエストを再送する。再送されたトリガリクエストを受けたＩＷＦは、再度ＳＣＳの確認（Authorization）やロードコントロールのチェックをする。このチェックに問題がなかった場合、ＩＷＦはＨＳＳへＵＥ情報の問合せをする。ＨＳＳへの問合せの結果に問題があった場合（ＵＥに対するデバイストリガの送信が認められなかった場合は）は、再送されたトリガリクエストに対して再びデバイストリガの送信ができなかったことを示すトリガ応答をＳＣＳへ返す。つまり、そもそもトリガリクエストのターゲットであるＵＥへデバイストリガの送信が認められていないにも関わらず、ＳＣＳによってトリガリクエストが再送されてしまうため、ＳＣＳとＩＷＦ間に不要なトラフィックが発生し、デバイストリガの送受信に伴いＳＣＳやＩＷＦに不要な処理負荷も発生する。不要なトラフィックはネットワークに輻輳を引き起こし、不要な処理はＳＣＳやＩＷＦの過負荷や消費電力の増加を引き起こす。上記の問題を解決するため、本開示技術の一態様によれば、例えば、トリガリクエストに関する適切なチェックを行った後にトリガ応答を返すことができるようにする技術が提供される。

上記の目的を達成するため、例えば、本開示技術の一態様は、通信端末に対して動作の開始を指示するためのデバイストリガを送信するネットワークノードであって、前記通信端末へデバイストリガを送信することを要求するトリガ要求をサーバから受信するトリガ要求受信部と、前記通信端末の情報に問題があるか否かを確認するＵＥ情報確認部と、前記トリガ要求のロードコントロールに問題があるか否かを確認するロードコントロール判断部と、ＵＥ情報問合せの結果を受けた後にロードコントロールに問題があることを示すトリガ応答を前記サーバへ送信するトリガ応答送信部とを有するネットワークノードを含む。上記の構成により、例えば、データ通信のために利用されるコネクションに対してゲートウェイの切り替えを実行できるようになるという効果が実現される。

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

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

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

本開示技術の第１の実施の形態におけるネットワーク構成の一例を示す図 本開示技術の第１の実施の形態におけるＳＣＳ３００及びセルラーネットワーク２００内の主要なエンティティの動作の第1の例を示すシーケンス図 本開示技術の第１の実施の形態において、ＨＳＳ２６０への問合せの結果に問題があった場合の動作の一例を示すシーケンス図 本開示技術の第１の実施の形態におけるＳＣＳ３００及びセルラーネットワーク２００内の主要なエンティティの動作の第２の例を示すシーケンス図 本開示技術の第１の実施の形態において、トリガリクエストの送信元の確認をした後にＵＥ情報の確認を行う場合の動作の一例を示すシーケンス図 本開示技術の第１の実施の形態において、ＵＥ情報に問題があった場合でもロードコントロールの確認を行う場合の動作の一例を示すシーケンス図 本開示技術の第１の実施の形態において、図４、図５及び図６で説明した動作に基づくＩＷＦ２１０の処理の一例を示すフローチャート 本開示技術の第１の実施の形態におけるＩＷＦ２１０の構成の一例を示すブロック図 本開示技術の第２の実施の形態におけるＳＣＳ３００及びネットワーク２００内の主要なエンティティの動作の一例を示すシーケンス図 本開示技術の第２の実施の形態におけるＳＣＳ３００がＵＥ１００とＵＥ１０１に対するトリガリクエストをそれぞれ送信する場合の第１の例を示すシーケンス図 本開示技術の第２の実施の形態におけるＳＣＳ３００が、ＵＥ１００に対するトリガリクエストを送信する場合のシーケンス図 本開示技術の第２の実施の形態におけるＳＣＳ３００がＵＥ１００とＵＥ１０１に対するトリガリクエストをそれぞれ送信する場合の第２の例を示すシーケンス図 本開示技術の第２の実施の形態におけるＳＣＳ３００の構成の一例を示すブロック図 本開示技術の第２の実施の形態におけるＳＣＳ３００がロードコントロールによる問題を示すトリガ応答を受信した際のＳＣＳ３００の処理を示すフローチャート 本開示技術の第１の実施の形態において、図２と図３で説明した動作に基づくＩＷＦ２１０の処理の一例を示すフローチャート デバイストリガを送信する際のＳＣＳ３００及びセルラーネットワークのエンティティの動作に関する背景技術を示すシーケンス図

以下、図面を参照しながら、本開示技術の第１〜第２の実施の形態について説明する。
本開示技術の第１の実施の形態では、ＩＷＦはトリガリクエストを受信した際に、ＨＳＳに対してユーザ情報の問合せを行った後にロードコントロールの問題を示すトリガ応答を送信する。また、本開示技術の第２の実施の形態では、ロードコントロールによりトリガ送信ができないことを示すトリガ応答を受けたＳＣＳが、送信できなかったトリガリクエスト及び未送信のトリガリクエストの送信先となるＩＷＦを選択する。

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

また、図１には、セルラーネットワーク２００の構成要素として、セルラーネットワーク２００とＳＣＳ３００を繋ぐＩＷＦ（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）などを用いてもよいが、その場合の各種エンティティの名称はその仕様に準ずる。

図２は、本開示技術の第１の実施の形態におけるＳＣＳ３００及びセルラーネットワーク２００内の主要なエンティティの動作の第1の例を示すシーケンス図である。ＳＣＳ３００は、トリガリクエストの送信先であるＩＷＦ２１０のＩＰアドレスをＤＮＳ２８０へ問い合わせる（ステップＳ２００１）。すでにＩＷＦ２１０のＩＰアドレスを保持している場合は、ＤＮＳ２１０への問合せは省略される。ＳＣＳ３００はＩＷＦ２１０に対してＵＥ１００のＩＤを含むトリガリクエストを送信する（ステップＳ２００２）。トリガリクエストにＵＥ１００のＩＤが含まれているということは、ＩＷＦ２１０及びＭＭＥ２２０が送信するデバイストリガの送信先（ターゲット）がＵＥ１００であるということを意味する。トリガリクエストを受けたＩＷＦ２１０は、トリガリクエストの送信元のＳＣＳ３００の確認を行う（ステップＳ２００３）。ＳＣＳ３００の確認とは、ＳＣＳ３００から受信したトリガリクエストを受け入れてもよいか否かのチェックであり、例えば、デバイストリガの送信を許可（Authorize）されたＳＣＳであるか否か、ＳＣＳ３００がトリガリクエストの送信が制限されているＳＣＳでないか、受信したトリガリクエストのメッセージにフォーマットエラーがないか、などの確認である。

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

次に、ロードコントロールのチェックの結果に問題（送信頻度が規定値を超過している）があることを確認した後、ＨＳＳ２６０へＵＥ１００の情報を問い合わせ、ＵＥ１００の情報を確認する（ステップＳ２００５）。ＵＥの情報の確認とは、デバイストリガをＵＥへ送信できるか否かの確認であり、例えば、ＨＳＳ２６０から受信した応答メッセージのステータスが正常であるか否かの確認、又は応答に含まれるＵＥの情報（サブスクリプション情報）の内容の確認である。例えば、ＵＥの情報を確認した結果、ＵＥがデバイストリガの受信資格がなかった場合や、ＵＥがデバイストリガを受信できる状態にない場合は、ＵＥの情報に問題があると判断する。

取得したＵＥの情報に問題がない（Valid Subscription Information）ことを確認（ステップＳ２００７）した後、ＩＷＦ２１０は、ロードコントロールに関する問題によってデバイストリガの送信ができなかったことを示す値を含むトリガ応答をＳＣＳ３００へ送信する（ステップＳ２００８）。このトリガ応答を受信したＳＣＳ３００は、ロードコントロールに問題が起きないタイミングでトリガリクエストの再送を行う（ステップＳ２００９）。例えば、ＩＷＦ２１０から受信したトリガ応答の中にバックオフタイマが含まれていた場合には、ＳＣＳ３００はトリガ応答を受信した際にタイマをスタートし、バックオフタイマで示された時間が経過してからトリガリクエストを再送する。バックオフタイマの値は事前設定された値を用いてもよい。再送されたトリガリクエストを受信したＩＷＦ２１０は、送信元のＳＣＳ３００の確認を行う（ステップＳ２０１０）。

次に、ロードコントロールに問題がないことを確認する（ステップＳ２０１１）。さらに、ＵＥ１００の情報の確認を行う（ステップＳ２０１２）。この場合、ＩＷＦ２１０は、以前に行ったＨＳＳ２６０への問合せの結果を保持（キャッシュ）しているため、そのキャッシュを確認することでＨＳＳ２６０への問合せを省略することができる（ステップＳ２０１２）。ＵＥの情報に問題がない場合、デバイストリガの送信処理を開始する（ステップＳ２０１３）。なお、ステップＳ２００８において、ロードコントロールに関する問題を示す値と共に、ＵＥ情報に問題がなかったことを示す値を含めてもよい。これにより、ＳＣＳ３００は、ＵＥ１００の情報がＩＷＦ２１０にキャッシュされていることを認識することができる。

図３は、本開示技術の第１の実施の形態において、ＨＳＳ２６０への問合せの結果に問題があった場合の動作の一例を示すシーケンス図である。ＨＳＳ２６０への問合せの結果に問題があった場合（ステップＳ３００７）、ＵＥ情報（subscription）に関する問題によってデバイストリガの送信ができなかったことを示すトリガ応答をＳＣＳ３００へ送信する（ステップＳ３００８）。トリガ応答を受けたＳＣＳ３００は、拒絶されたトリガリクエストの再送を行わない（ステップＳ３００９）。これにより、ＩＷＦ２１０は、ＳＣＳ３００に対して、ＵＥ１００に対するトリガリクエストの送信（再送）ができないことを認識させることができる。なお、ＩＷＦ２１０は、ロードコントロールの問題とＵＥ情報の問題の両方を示す拒絶理由を含むトリガ応答をＳＣＳ３００へ送信してもよい。

この場合、ＳＣＳ３００は、ＵＥ１００に対するトリガリクエストの再送をしないと判断するとともに、以降ＩＷＦ２１０宛てに送信するトリガリクエストを送信する際には、ロードコントロールに問題が起きない適切なタイミングや頻度で送信する必要があること、又はトリガリクエストの送信先を切り替える必要があることを認識することができる。このため、ＳＣＳ３００は、他のＵＥへトリガリクエストを送信する際には、ロードコントロールに問題が起きない適切なタイミングや頻度で送信する。

図１５は、本開示技術の第１の実施の形態において、図２と図３で説明した動作に基づくＩＷＦ２１０の処理の一例を示すフローチャートである。トリガリクエストを受信した際に（ステップＳ１５００１）、送信元のＳＣＳ３００の確認を行い（ステップＳ１５００２）、問題があった場合は、ＳＣＳ３００がトリガリクエストの送信が許可されていないためにトリガの送信ができなかったことを示す値を含むトリガ応答をＳＣＳ３００へ返す（ステップＳ１５００３）。ＳＣＳ３００の確認結果に問題がなかった場合は、トリガリクエストの受信に関するロードコントロールの確認を行う（ステップＳ１５００４）。

ロードコントロールの確認に問題がない場合は、ＨＳＳ２６０へ問い合わせるなどしてＵＥ情報の確認を行い（ステップＳ１５００６、Ｓ１５００８）、問題がない場合はトリガの送信処理を開始する（ステップＳ１５０１１）。ステップＳ１５００８においてＵＥ情報に問題があった場合は、ＵＥ情報の問題を示す値を含むトリガ応答を送信する（ステップＳ１５０１０）。一方、ロードコントロールの確認に問題があった場合は、ＨＳＳ２６０へ問い合わせるなどしてＵＥ情報の確認を行い（ステップＳ１５００５）、ＵＥ情報に問題がない場合は、ロードコントロールの問題を示す値を含むトリガ応答を送信する（ステップＳ１５００９）。ステップＳ１５００７において、ＵＥ情報に問題があった場合は、ＵＥ情報の問題を示す値を含むトリガ応答を送信する（ステップＳ１５０１０）。

図４は、本開示技術の第１の実施の形態におけるＳＣＳ３００及びセルラーネットワーク２００内の主要なエンティティの動作の第２の例を示すシーケンス図である。図２との違いは、ＩＷＦ２１０が、送信元のＳＣＳ３００の確認とＵＥ１００の情報の確認（ステップＳ４００４、Ｓ４００５）を行った後に、ロードコントロールのチェック（ステップＳ４００７）を実行するところである。図４では、ロードコントロールに関して問題があったため、ロードコントロールに関する問題によってトリガの送信ができなかったことを示すトリガ応答をＳＣＳ３００へ送信する（ステップＳ４００８）。トリガ応答を受けたＳＣＳ３００は、ロードコントロールに問題が起きないタイミングでトリガリクエストの再送を行う（ステップＳ４００９）。

例えば、ＩＷＦ２１０から受信したトリガ応答の中にバックオフタイマが含まれていた場合には、ＳＣＳ３００はトリガ応答を受信した際にタイマをスタートし、バックオフタイマで示された時間が経過してからトリガリクエストを再送する。バックオフタイマの値は事前設定された値を用いてもよい。再送されたトリガリクエストを受信したＩＷＦ２１０は、送信元のＳＣＳ３００の確認を行う（ステップＳ４０１０）。次に、ＵＥ１００の情報の確認については、先に行ったＨＳＳ２６０への問合せの結果を保持（キャッシュ）しているため、そのキャッシュを確認することでＨＳＳ２６０への問合せを省略することができる（ステップＳ４０１１）。ＵＥ１００の情報に問題がないことを確認した後、ロードコントロールに問題がないことを確認し（ステップＳ４０１２）、デバイストリガの送信処理を開始する（ステップＳ４０１３）。

図５は、本開示技術の第１の実施の形態において、トリガリクエストの送信元の確認をした後にＵＥ情報の確認を行う場合の動作の一例を示すシーケンス図である。図４と同様に、送信元のＳＣＳ３００の確認をした後にＨＳＳ２６０への問合せを行う（ステップＳ５００４、Ｓ５００５）。ＵＥ情報に問題があった場合は（ステップＳ５００６）、ロードコントロールのチェックをせずにＵＥ情報に関する問題によってトリガの送信ができなかったことを示すトリガ応答をＳＣＳ３００へ送信する（ステップＳ５００７）。

一方、図６は、本開示技術の第１の実施の形態において、ＵＥ情報に問題があった場合でもロードコントロールの確認を行う場合の動作の一例を示すシーケンス図である。ＩＷＦ２１０はＵＥ情報に問題があった場合でも（ステップＳ６００６）、ロードコントロールのチェックを行い（ステップＳ６００７）、ロードコントロールに関する問題があった場合は（ステップＳ６００７）、ＵＥ情報に関する問題とロードコントロールに関する問題の両方を示すトリガ応答をＳＣＳ３００へ送信する。

図７は、本開示技術の第１の実施の形態において、図４、図５及び図６で説明した動作に基づくＩＷＦ２１０の処理の一例を示すフローチャートである。トリガリクエストを受信したＩＷＦ２１０は（ステップＳ７００１）、トリガリクエストの送信元のＳＣＳ３００がトリガの送信を許可されたＳＣＳであるか否かを確認し（ステップＳ７００２）、許可されたＳＣＳである場合は、ＨＳＳ２６０への問合せを行う（ステップＳ７００４）。さらに、ＵＥ情報に問題がない場合はロードコントロールのチェックを行い（ステップＳ７００６）、問題がない場合はトリガの送信処理を開始する（ステップＳ７００７）。一方、ロードコントロールのチェックに問題があった場合は、トリガの送信ができなかったことを示すトリガ応答を送信する（ステップＳ７００８）。ＵＥ情報に問題があった場合は、ＵＥ情報に関する問題によってトリガの送信ができなかったことを示すトリガ応答を送信する（ステップＳ７００９）。

次に、本開示技術の第１の実施の形態におけるＩＷＦ２１０の構成例について説明する。図８は、本開示技術の第１の実施の形態におけるＩＷＦ２１０の構成の一例を示すブロック図である。図８に図示されているＵＥ１００は、インタフェース１０１、ＵＥ情報確認部１０２、トリガリクエスト処理部１０３、ロードコントロール判断部１０４、送信元確認部１０５、デバイストリガ送信処理部１０６、トリガ応答送信処理部１０７を有している。

インタフェース１０１は、ＵＥ１００がネットワークに接続してメッセージ（又はパケット）を送受信するための機能を有している。インタフェース１０１には、他の通信装置（例えば、ネットワーク上に配置されているネットワークノードや他のＵＥ１００など）と通信を行うために、情報を電気的な信号に変調及び復調するハードウェアも含まれる。ＵＥ情報問合せ部１０２は、トリガリクエスト受信処理部１０３の指示を受け、ＨＳＳ２６０からトリガリクエストのあて先であるＵＥ１００の情報を取得する。トリガリクエスト受信処理部１０３は、受信したトリガリクエストについて、送信元確認部１０５に対して送信元であるＳＣＳ３００がトリガリクエストの送信を許可（Authorized）されたＳＣＳであるか否かの確認を指示する。

また、送信元確認部１０５の結果に問題がない場合は、ロードコントロール判断部１０４に対してロードコントロールを確認するよう指示する。さらにトリガリクエスト受信処理部１０３は、ＵＥ情報確認部１０２に対してデバイストリガの宛先であるＵＥ１００に関する情報の確認をするよう指示する。ＵＥ１００の情報に問題がない場合で、かつロードコントロール判断部１０４の判断結果にも問題がない場合は、トリガリクエスト受信処理部１０３はデバイストリガ送信処理部１０６に対してデバイストリガを送信するよう指示する。一方、ＵＥ１００の情報に問題はないが、ロードコントロールに問題がある場合は、トリガ応答送信処理部１０７に対してデバイストリガの送信ができないことをＳＣＳへ通知するよう指示する。

デバイストリガ送信処理部１０６は、デバイストリガの送信方法の選択や、選択した送信方法を用いてデバイストリガを送信するための処理を開始する。送信方法としてＳＭＳ（Ｔ４インタフェース）を選択した場合には、ＳＭ−ＳＣ２７０対してＵＥ１００のＩＤなど通知してＳＭＳの送信を要求する。また、ＭＭＥ２２０への直接要求（Ｔ５インタフェース）を選択した場合には、ＭＭＥ２２０に対してＵＥ１００のＩＤなどを通知してＮＡＳメッセージを用いたデバイストリガの送信を要求する。

以上説明したように、本開示技術の第１の実施の形態によれば、ＩＷＦ２１０は、ロードコントロールに問題があることの確認とともに、トリガリクエストのターゲットであるＵＥ１００の情報に問題があることの確認もできるため、ＵＥ情報に問題があるＵＥ１００へのデバイストリガの送信を要求するトリガリクエストの再送を防ぐことができる。これにより、これにより、ＳＣＳ３００とＩＷＦ２１０の間で送受信されるシグナリング数、ネットワーク負荷、及びそれに伴う処理負荷、電力消費を軽減することができる。

（第２の実施の形態）
次に、本開示技術の第２の実施の形態において、ＩＷＦ２１０からトリガ応答を受けた場合のＳＣＳ３００によるトリガリクエスト送信方法について説明する。本開示技術の第２の実施の形態では、ＳＣＳ３００が、トリガリクエストを送信したＩＷＦ２１０とは異なるＩＷＦ２９０のＩＰアドレスも保持している（又は任意のタイミングで取得することができる）場合を想定する。 本開示技術の第１の実施の形態で述べたように、ＳＣＳ３００からトリガリクエストを受けたＩＷＦ２１０は、デバイストリガの送信先であるＵＥ１００の情報に問題がないことを確認してから、ロードコントロールに問題があるためにデバイストリガの送信ができなかったことを示すトリガ応答をＳＣＳ３００へ通知する。このトリガ応答を受けたＳＣＳ３００は、ロードコントロールに問題が起きないタイミングでトリガリクエストをＩＷＦ２１０へ再送する。再送されたトリガリクエストを受信したＩＷＦ２１０は、最初のトリガリクエストを受けた際にＨＳＳへ問合せた結果をキャッシュしているため、そのキャッシュを確認することでＨＳＳへの問合せを省略することができる。

図９は、本開示技術の第２の実施の形態におけるＳＣＳ３００及びネットワーク２００内の主要なエンティティの動作の一例を示すシーケンス図である。ＵＥ１００は、事前設定（Pre-configuration）された情報やＤＮＳサーバへの問合せにより（ステップＳ９００１、Ｓ９００２）、２つのＩＷＦ（ＩＷＦ２１０、ＩＷＦ２９０）のＩＰアドレスを保持している（ステップＳ９００３）。なお、保持しているＩＰアドレスの数は２つに限定されない。

ＵＥ１００がＩＷＦ２１０へ送信したトリガリクエストに対する応答として、ロードコントロールに問題があったためデバイストリガの送信ができなかったことを示すトリガ応答を受信した場合（ステップＳ９００９）、別のＩＷＦ２９０に対してトリガリクエストを再送する（ステップＳ９０１０）。つまり、ＳＣＳ３００は、送信したトリガリクエストが拒絶された場合、トリガリクエストの送信先をＩＷＦ２１０からＩＷＦ２９０へ切り替える。ＩＷＦ２９０は、ＳＣＳ３００からトリガリクエストを受信し、送信元のＳＣＳ３００の確認（ステップＳ９０１１）、ロードコントロールの確認（ステップＳ９０１２）、ＵＥ情報の確認をそれぞれ行い（ステップＳ９０１３、Ｓ９０１４）、それらの確認に問題がない場合は（ステップＳ９０１５）、デバイストリガの送信処理を開始する（ステップＳ９０１６）。

図１０は、本開示技術の第２の実施の形態におけるＳＣＳ３００がＵＥ１００とＵＥ１０１に対するトリガリクエストをそれぞれ送信する場合の第１の例を示すシーケンス図である。ＵＥ１００のＩＤを含むトリガリクエストを受信したＩＷＦ２１０は（ステップＳ１０００４）、ＳＣＳ３００の確認、ロードコントロールの確認（ステップＳ１０００５）、ＵＥ情報の確認（ステップＳ１０００６、Ｓ１０００７）をそれぞれ行い、ロードコントロールに問題があった場合は、その旨を示すトリガ応答を返す（ステップＳ１０００８）。トリガ応答を受信したＳＣＳ３００は、別のＩＷＦ２１０に対してＵＥ１００のＩＤを含むトリガリクエストを再送する（ステップＳ１０００９）。

さらにＳＣＳ３００は、まだ送信していないＵＥ１０１のＩＤを含むトリガリクエストもＩＷＦ２１０へ送信する。つまり、ＳＣＳ３００は、送信したトリガリクエストが拒絶された場合、拒絶されたトリガリクエストとまだ送信していないトリガリクエストの両方の送信先をＩＷＦ２１０からＩＷＦ２９０へ切り替える。ＩＷＦ２９０は、ＳＣＳ３００からＵＥ１００のＩＤを含む再送されたトリガリクエストと（ステップＳ１０００９）、ＵＥ１０１のＩＤを含む未送信のトリガリクエスト（ステップＳ１００１５）をそれぞれ受信し、ＳＣＳ３００の確認、ロードコントロールの確認（ステップＳ１００１０、Ｓ１００１６）、ＨＳＳへ問い合わせ（ステップＳ１００１１、Ｓ１００１２、Ｓ１００１７、Ｓ１００１８）のそれぞれを行い、それらの確認に問題がない場合は（ステップＳ１００１９）デバイストリガの送信処理を開始する（ステップＳ１００２０）。

図１１は、本開示技術の第２の実施の形態におけるＳＣＳ３００が、ＵＥ１００に対するトリガリクエストを送信する場合のシーケンス図である。ＳＣＳ３００はロードコントロールの問題を示すトリガ応答を受信した際（ステップＳ１１００８）、別のＩＷＦ２９０のＩＰアドレスを保持しているが、ＩＷＦ２９０へ切り替えずにＩＷＦ２１０へトリガリクエストを再送する（ステップＳ１１００９）。再送トリガリクエストの送信先をＩＷＦ２９０へ切り替えることによって、ＩＷＦ２１０で発生したようなロードコントロールの制限を受けずに直ぐにトリガリクエストを送信することができるかもしれない。しかし、ＳＣＳ３００はＩＷＦ２９０の存在（ＩＰアドレスやＩＤ）を認識していたとしてもＩＷＦ２１０をトリガリクエストの再送先として選択する。

これにより、ＩＷＦ２１０はＵＥ１００の情報を既に保持しているため、ＵＥ１００の情報をＨＳＳ２６０から取得するためのシグナリングを省くことができる（ステップＳ１１０１１）。なお、ＳＣＳ３００は、ＩＷＦ２１０においてＵＥ情報の確認が行われた後にロードコントロールの問題を示すトリガ応答が送信されていると認識していることが望ましい。この場合、ＳＣＳ３００は、ＩＷＦ２１０にはＵＥ１００の情報がキャッシュされているため、ＨＳＳ２６０に対するＵＥ情報の問い合わせを省略するために、トリガリクエストの再送先としてＩＷＦ２９０ではなくＩＷＦ２１０を選択する必要があると判断する。これにより、ＨＳＳ２６０の処理負荷、及びネットワーク帯域へ与える負荷を軽減することができる。なお、ステップＳ１１００８のトリガ応答の中にＵＥの情報に問題がないことを示す値が含まれている場合は、ＳＣＳ３００は、ＵＥ１００の情報がＩＷＦ２１０にキャッシュされていると認識することができるため、トリガリクエストの再送先としてＩＷＦ２１０が適切であると判断することができる。

図１２、本開示技術の第２の実施の形態におけるＳＣＳ３００がＵＥ１００とＵＥ１０１に対するトリガリクエストをそれぞれ送信する場合の第２の例を示すシーケンス図である。ＳＣＳ３００はロードコントロールの問題を示すトリガ応答を受信した際（ステップＳ１２００８）、ＵＥ１００のＩＤを含むトリガリクエストをＩＷＦ２１０へ送信し、ＵＥ１００とは異なるＵＥ１０１のＩＤを含むトリガリクエスト（未送信のトリガリクエスト）をＩＷＦ２９０へ送信する。つまり、ＳＣＳ３００は、送信したトリガリクエストが拒絶された場合、拒絶されたトリガリクエストの再送先を切り替えずに、未送信のトリガリクエストの送信先をＩＷＦ２１０からＩＷＦ２９０へ切り替える。

ＳＣＳ３００は、ＩＷＦ２１０からロードコントロールの問題を示すトリガ応答を受信したため、別のＩＷＦ２９０へ切り替えることによって、ロードコントロールの制限を受けずにトリガリクエストを送信することができる。図１０で示したように、ＵＥ１００に対するトリガリクエストの再送先とＵＥ１００とは異なるＵＥ１０１に対するトリガリクエストの送信先をＩＷＦ２９０へ切り替えた場合、ＩＷＦ２９０はＵＥ１００とＵＥ１０１の両方の情報についてＨＳＳ２６０へ問い合わせる必要がある。一方、図１１で示したように、ＩＷＦ２１０はすでにＵＥ１００の情報を保持しているため、ＵＥ１００のＩＤを含むトリガリクエストをＩＷＦ１００へ送信することで、ＵＥ１の情報をＨＳＳ２６０へ問い合わせるためのシグナリングの送受信を不要とすることができる。そのため、複数のＵＥに対してトリガリクエストを送信する場合、ＳＣＳ３００は拒絶されたトリガリクエストは同じＩＷＦ２１０に対して再送し、まだ送信していないトリガリクエストは別のＩＷＦ２９０に対して送信するべきと判断する。

これによって、再送トリガリクエストによるネットワークへの負荷を軽減し、かつ未送信のトリガリクエストはロードコントロールの制限を受けずに送信することが可能となる。なお、ＳＣＳ３００は、ＵＥ１０１に対するトリガリクエストをＩＷＦ２１０へ送信してもよい。この場合、ＩＷＦ２９０へ送信した場合と同様に、ＩＷＦ２１０はＵＥ１０１の情報を保持していないため、ＨＳＳ２６０へ問い合わせる必要があるため、ＨＳＳ２６０への問い合わせに伴う負荷はどちらも同じである。

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

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

ＤＮＳ処理部２０２は、トリガリクエストの宛先であるＩＷＦ２１０のＩＰアドレスを取得するためにＤＮＳサーバ２８０に対してクエリーを送信し、ＩＷＦ２１０（及びＩＷＦ２９０）のＩＰアドレスを含むレスポンスを受信し、ＩＰアドレスを保持する。クエリーにはＩＷＦ２１０のＩＤ又はトリガ対象のＵＥのＩＤ（ドメインＩＤとローカルＩＤから構成される）を含めて送信する。トリガリクエスト送信部２０３は、アプリケーション２０５からの要求を受け、ＵＥ１００に対してデバイストリガを送信することを要求するためのトリガリクエストをＩＷＦ２１０へ送信する。

また、トリガ応答受信部２０４からロードコントロールの問題を示すトリガ応答を受信したことの通知を受けた場合、送信済みのトリガリクエストの再送先としてＩＷＦ２１０を選択し、未送信のトリガリクエストの送信先としてＩＷＦ２９０を選択して、それぞれのトリガリクエストを送信する。トリガ応答受信部２０４は、トリガリクエスト送信部２０３が送信したトリガリクエストに対するトリガ応答を受信する。受信したトリガ応答に、ロードコントロールによる失敗を示す値（Cause）が含まれていた場合は、トリガリクエスト送信部２０３に対してトリガリクエストを再送するよう指示する。アプリケーション２０５は、トリガリクエスト送信部２３０に対してＵＥ１００へデバイストリガを送信するよう要求する。

図１４は、本開示技術の第２の実施の形態におけるＳＣＳ３００がロードコントロールによる問題を示すトリガ応答を受信した際のＳＣＳ３００の処理を示すフローチャートである。トリガ応答を受信した際に（ステップＳ１４００１）、拒絶されたトリガリクエストを同じＩＷＦへロードコントロールの問題が起きないよう適切なタイミングで再送する（ステップＳ１４００２）。そして、未送信のトリガリクエストがあるか否かを判断し（ステップＳ１４００３）、未送信のトリガリクエストがある場合はそれを別のＩＷＦへ送信する（ステップＳ１４００４）。未送信のトリガリクエストがない場合は、トリガ応答の受信を待つ（ステップＳ１４００５）。

以上説明したように、本開示技術の第２の実施の形態によれば、ＳＣＳ３００は、ロードコントロールに関する問題でトリガリクエストが拒絶された場合に、既に送信したトリガリクエストは再び同じＩＷＦへ再送し、まだ送信していないトリガリクエストは別のＩＷＦへ送信することができる。これにより、デバイストリガの送信先であるＵＥの情報を取得するためのＨＳＳへ問い合わせる処理を不要とすることができるため、ＨＳＳ２６０とＩＷＦ２９０の間で送受信されるシグナリング数、ネットワーク負荷、及びそれに伴う処理負荷、電力消費を軽減することができる。

また、本開示技術の一態様では、前記トリガ応答送信部は、前記ロードコントロール確認部によって前記ロードコントロールに問題があることが確認され、前記ＵＥ情報確認部によって前記ＵＥ情報に問題がないことを確認した際に、前記ロードコントロールに問題があることを示すトリガ応答を前記サーバへ送信するようにしてもよい。

また、本開示技術の一態様では、前記ロードコントロールは、前記ネットワークノードの処理負荷、または、前記トリガ要求の受信頻度のいずれかであってもよい。

また、本開示技術の一態様は、通信端末に対して動作の開始を指示するデバイストリガを送信することをネットワークノードに要求するトリガ要求であって、複数のネットワークノードの中から前記トリガ要求の送信先となるネットワークノードを選択するトリガ送付先判断部と、選択した前記ネットワークノードに前記トリガ要求を送信するトリガ要求送信部と、前記ネットワークノードへ送信した前記トリガ要求に対するトリガ応答を受信するトリガ応答受信部とを有し、前記トリガ送付先判断部は、前記トリガ応答が前記ロードコントロールに問題があることを示している場合に、前記トリガ要求の再送先として前記ネットワークノードを再び選択するサーバを含むことができる。上記の構成により、例えば、データ通信のために利用されるコネクションに対してゲートウェイの切り替えを実行できるようになるという効果が実現される。

また、本開示技術の一態様では、前記トリガ送付先判断部は、前記通信端末とは異なる通信端末に対するトリガ要求の送信先として、前記トリガ応答が前記ロードコントロールに問題があることを示している場合に、前記ネットワークノードとは異なるネットワークノードを選択するようにしてもよい。

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

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

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

本開示技術は、トリガリクエストの不要な再送を防ぎ、さらにＨＳＳへのＵＥ情報の問合せ処理を省略することができるという効果を有しており、セルラー通信機能を利用した通信技術（特に、Ｍ２Ｍ通信の技術）に適用可能である。

１００、１０１ ＵＥ（通信端末）
１０１、２０１ インタフェース
１０２ ＵＥ情報確認部
１０３、トリガリクエスト受信処理部
１０４ ロードコントロール判断部
１０５ 送信元確認部
１０６ デバイストリガ送信処理部
１０７ トリガ応答送信処理部
２００ セルラーネットワーク（ネットワーク）
２０２ ＤＮＳ処理部
２０３ トリガリクエスト送信部
２０４ トリガ応答受信部
２０５ アプリケーション
２１０、２９０ ＩＷＦ
２２０ ＭＭＥ／ＳＧＳＮ／ＭＳＣ（ＭＭＥ）
２３０ Ｐ−ＧＷ／ＧＧＳＮ／ｅＰＤＧ（Ｐ−ＧＷ）
２４０ Ｓ−ＧＷ
２５０ ｅＮＢ／ＮＢ／ＢＳ
２６０ ＨＳＳ／ＨＬＲ
２７０ ＳＭＳ−ＳＣ／ＧＭＳＣ／ＩＷＭＳＣ
２８０ ＤＮＳ
３００ ＳＣＳ（サーバ）
４００ アプリケーションサーバ（アプリケーション）

Claims (5)

1. 通信端末に対して動作の開始を指示するデバイストリガを送信するネットワークノードであって、
   前記通信端末へ前記デバイストリガを送信することを要求するトリガ要求をサーバから受信するトリガ要求受信部と、
   前記デバイストリガを前記通信端末に送信できるか否かを確認するＵＥ情報確認部と、
   ロードコントロールに問題があるか否かを確認するロードコントロール確認部と、
   前記ＵＥ情報確認部による前記ＵＥ情報の確認と、前記ロードコントロール確認部による前記ロードコントロールの確認の後、トリガ応答を前記サーバへ送信するトリガ応答送信部とを、
   有するネットワークノード。
2. 前記トリガ応答送信部は、前記ロードコントロール確認部によって前記ロードコントロールに問題があることが確認され、前記ＵＥ情報確認部によって前記ＵＥ情報に問題がないことを確認した際に、前記ロードコントロールに問題があることを示すトリガ応答を前記サーバへ送信する請求項１に記載のネットワークノード。
3. 前記ロードコントロールは、前記ネットワークノードの処理負荷、または、前記トリガ要求の受信頻度のいずれかである請求項１に記載のネットワークノード。
4. 通信端末に対して動作の開始を指示するデバイストリガを送信することをネットワークノードに要求するトリガ要求であって、複数のネットワークノードの中から前記トリガ要求の送信先となるネットワークノードを選択するトリガ送付先判断部と、
   選択した前記ネットワークノードに前記トリガ要求を送信するトリガ要求送信部と、
   前記ネットワークノードへ送信した前記トリガ要求に対するトリガ応答を受信するトリガ応答受信部とを有し、
   前記トリガ送付先判断部は、前記トリガ応答が前記ロードコントロールに問題があることを示している場合に、前記トリガ要求の再送先として前記ネットワークノードを再び選択するサーバ。
5. 前記トリガ送付先判断部は、前記通信端末とは異なる通信端末に対するトリガ要求の送信先として、前記トリガ応答が前記ロードコントロールに問題があることを示している場合に、前記ネットワークノードとは異なるネットワークノードを選択する請求項４に記載のサーバ。