JP5950244B2

JP5950244B2 - デバイストリガメッセージを効率的に送信するための装置及び方法

Info

Publication number: JP5950244B2
Application number: JP2015520298A
Authority: JP
Inventors: ジャイン、プニート; ラオ、ヴァルン; ホンシャン、チャン; ヴェンカタチャラン、ムタイアー
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2012-07-02
Filing date: 2013-06-19
Publication date: 2016-07-13
Anticipated expiration: 2033-06-19
Also published as: BR112014030156A2; ES2447340A2; FI20185380A; EP2868009A1; TW201410051A; TWI568291B; HUE043858T2; TW201528845A; US9432150B2; CN107493159A; TWI489893B; ITMI20131103A1; EP2868009A4; NL2011078C2; ES2733753T3; CA2874475A1; NL2011078A; WO2014007990A1; TWI610582B; KR20160036091A

Description

本願は、２０１２年７月２日に出願された米国仮特許出願６１／６６７，３２５に対する優先権の利益を主張する、２０１３年１月３１日に出願された米国特許出願１３／７５５，１６６に対する優先権の利益を主張し、それらの全体における参照によってここで全て組み込まれる。

複数の実施形態は、無線通信に関する。いくつかの実施形態は、ロングタームエボリューション（ＬＴＥ）ネットワークにおいて用いられる無線通信に関する。

デバイストリガは、サービス能力サーバ（ＳＣＳ）が、ＵＥが複数のアプリケーション固有動作を実行することをトリガするために、ネットワークを介してユーザ機器（ＵＥ）の要素に情報を送信するための手段である。

少ないデータリクエストを伴う多数のデバイストリガメッセージは、ネットワークにおけるシグナリングサージの原因になり得、ＵＥがアイドル状態と接続状態との間を切り替える場合に、ＵＥの電池寿命に影響を与える。これは、少量のデータを有する複数のデバイストリガメッセージを頻繁に送信する複数のモバイルデータアプリケーションに特に当てはまる。

本発明の実施形態の概略を示す。

本発明の実施形態の動作を示すフローチャートである。

本発明の他の実施形態の動作を示すフローチャートである。

以下の説明及び図面は、特定の実施形態を十分に示し、当業者がそれらを実施することを可能にする。他の複数の実施形態は、構造上の、論理的な、電気的な、処理、及び他の変化を組み込んでよい。複数の例は、可能性があるバリエーションの代表例に過ぎない。個別のコンポーネント及び機能は、明示的に要求されない限り、任意選択的であり、一連の動作は、変化してよい。いくつかの実施形態の部分及び特徴は、他の複数の実施形態のものに含まれ又は置き換えられてよい。請求項に記載された複数の実施形態は、これらの請求項の全ての利用可能な均等物を包含する。

以下の詳細な説明において、本発明の深い理解を提供するために、多数の特定の詳細が記載される。しかし、本発明がこれらの特定の詳細なしに実施されてよいことが、当業者によって理解されるだろう。他の例において、既知の方法、手順、コンポーネント、及び回路は、本発明をわかりにくくしないように、詳述されない。

本発明の複数の実施形態は、この点で限定されないが、ここで用いられる用語「複数（plurality）」及び「多数（a plurality）」は、例えば「複数の（multiple）」又は「２又は３以上の（two or more）」を含んでよい。用語「複数（plurality）」又は「多数（a plurality）」は、２又は３以上のコンポーネント、デバイス、素子、ユニット、パラメータ、及びその類のものを説明するために、明細書を通して用いられてよい。例えば、「複数の局」は、２又は３以上の局を含んでよい。

第３世代パートナシッププロジェクト（３ＧＰＰ）は、「組織パートナ（Organizational Partners）」として知られる多数の電気通信の標準化団体をまとめるために、１９９８年１２月に制定された提携契約であり、現在、社団法人電波産業会（ＡＲＩＢ）、中国通信規格協会（ＣＣＳＡ）、欧州電気通信標準化機構（ＥＴＳＩ）、電気通信標準化連合（ＡＴＩＳ）、通信技術協会（ＴＴＡ）、及び情報通信技術委員会（ＴＴＣ）を含む。３ＧＰＰの制定は、「第３世代パートナシッププロジェクト合意」の調印によって、１９９８年１２月に正式なものにされた。

３ＧＰＰは、サポートする進化型ＧＳＭ（登録商標）コアネットワーク及び無線アクセス技術（例えば、周波数分割複信（ＦＤＤ）及び時分割複信（ＴＤＤ）のモードの両方のためのユニバーサル地上波無線アクセス（ＵＴＲＡ））に基づく第３世代モバイルシステムのための技術仕様及び技術レポートとして、世界的に適用可能な規格を提供する。３ＧＰＰは、進化型無線アクセス技術（例えば、汎用パケット無線サービス（ＧＰＲＳ）及びＧＳＭ（登録商標）進化型データレート（ＥＤＧＥ））を含む技術仕様及び技術レポートとして、ＧＳＭ（登録商標）（Global System for Mobile communication）の維持及び開発のための規格も提供する。携帯電話通信のための現行の規格のための技術仕様は、ほとんどの場合、３ＧＰＰ団体から一般に公開されている。

３ＧＰＰは、現在、３Ｇモバイルシステムの進化を研究しており、ＵＴＲＡネットワーク（ＵＴＲＡＮ）の進化に向けた貢献（見解及び提案）を検討する。ビット毎の低減されたコスト、増大したサービスプロビジョニング（すなわち、より良い品質のより低いコストのより多くのサービス）、既存の及び新しい周波数バンドの使用のフレキシビリティ、オープンインタフェースの単純化されたアーキテクチャ、及び低減された／合理的な端末の電力消費を含む高レベルの要件のセットが、３ＧＰＰ研究会によって特定された。ＵＴＲＡ及びＵＴＲＡＮロングタームエボリューション（ＵＴＲＡＮ−ＬＴＥ、また３ＧＰＰ−ＬＴＥ及びＥ−ＵＴＲＡとしても知られる）に関する研究は、高データレート、低レイテンシ、及びパケット最適化無線アクセス技術に向けて、３ＧＰＰ無線アクセス技術の進化のためのフレームワークを開発する目的で２００４年１２月に開始された。その研究は、２０ＭＨｚまでのフレキシブルな送信帯域幅をサポートする手段、新しい送信スキームの採用、及び高度マルチアンテナ技術のような無線インタフェース物理層（ダウンリンク及びアップリンク）の修正を考慮した。

３ＧＰＰ−ＬＴＥは、直交周波数分割多重（ＯＦＤＭ）技術を組み込む無線インタフェースに基づく。ＯＦＤＭは、それぞれのユーザのデータチャネルを搬送するための多数の密集した直交サブキャリアを使用するデジタルマルチキャリア変調方式である。各サブキャリアは、無線周波数（ＲＦ）送信レートに比べて（比較的）低い符号レートで、直交振幅変変調（ＱＡＭ）のような従来の変調スキームで変調される。実際には、ＯＦＤＭ信号は、高速フーリエ変換（ＦＦＴ）アルゴリズムを用いて生成される。

機械は、少しの又は全くの人間の介入なしで、他の機械と通信する必要がよくある。従来、そのような通信は、ワイヤを介して行われた。時間が経つにつれて、無線通信が用いられ始めた。モバイルブロードバンドの増大した有用性により、ブロードバンドを介するマシンタイプ通信（ＭＴＣ）が、ますます人気になっている。ＭＴＣは、人間の介入の必要なしに情報を交換してコマンドを操作する遠隔の機械の間の通信を可能にする。マシンタイプ通信の使用の例は、遠隔のセンサ、Ｅヘルス、遠隔制御需要計器、監視カメラ、通行料金支払い、生産チェーン自動化、及びその類のものを含む。例えば、デバイスは、他のデバイスの動作ステータスをモニタし、ステータスを中央サーバにレポートできる。又は、デバイスは、需要計器を読み取り、データを毎月の公共料金の準備のための経理部門に提供できる。

サーバが特定のＭＴＣデバイスをアクティブにする又はトリガすることを望むときに、それは、サービスネットワークを通じてデバイストリガメッセージを送信してよい。デバイストリガメッセージは、ＭＴＣデバイスとサーバとの間の通信を開始するように構成されてよい。

複数のデバイストリガメッセージを送信することは、サービス能力サーバ（ＳＣＳ）が、ユーザ機器（ＵＥ）が複数のアプリケーション固有動作を実行することをトリガするために、３ＧＰＰネットワークを介してＵＥに情報を送信する手段である。これらの動作は、インダイレクトモデルのＳＣＳ、又はハイブリッドモデルのネットワークにおけるアプリケーションサーバ（ＡＳ）との通信を開始することを含んでよい。デバイストリガは、ＵＥのＩＰアドレスがＳＣＳ／ＡＳによって利用可能又は到達可能でないときに要求されてよい。

デバイストリガメッセージは、典型的に、ネットワークがメッセージを適切なＵＥにルーティングすること及びＵＥのためにメッセージを適切なアプリケーションにルーティングすることを許可する情報（例えば、ＩＭＳＩ、アプリケーションポートＩＤ、及びその類のもの）を含む。アプリケーションを宛先とする情報は、デバイストリガペイロードと呼ばれる。ＵＥは、デバイストリガ情報を含むメッセージを任意の他のタイプのメッセージと区別できるように構成される。

ＵＥによって受信されると、デバイストリガペイロードは、アプリケーション関連の複数の動作をトリガする情報を判断するために調べられる。ＵＥにおけるアプリケーションは、トリガペイロードの中の情報に基づいて、即時の接続を開始する又はＳＣＳ又はＡＳとの後の通信を生成するためのような、特定の示された複数の動作を実行してよい。

課金データ記録（ＣＤＲ）は、デバイストリガに対して収集されてよい。つまり、プロバイダは、将来の請求の目的のために、データ送信のコストを記録してよい。

図１を参照して、３ＧＰＰに従うマシンタイプ通信（ＭＴＣ）のためのアーキテクチャを示すブロック図が示される。

ＵＥ１０２は、ＭＴＣＵＥアプリケーション１０４を実行するように示される。ＵＥは、無線アクセスネットワーク（ＲＡＮ）１０６に結合される。ＲＡＮ１０６を介して、ＵＥは、モバイルスイッチングセンタ（ＭＳＣ）１０８、モバイル管理エンティティ（ＭＭＥ）１１０、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１１１、及びサービングゲートウェイ（Ｓ−ＧＷ）１１２のような、進化型パケットコアの様々なコンポーネントに結合される。複数のコンポーネントは、共に、ＶＰＬＭＮ（Visited Public Land Mobile Network）を備える。ＨＰＬＭＮ（Home Public Land Mobile Network）における複数のコンポーネントは、いくつかの基準点を介して上記の複数のコンポーネントに結合される。

ＭＭＥ１１０は、ＳＧＳＮ１１１と共に存在し、以下の機能性を実行するように構成されてよく、デバイストリガメッセージをＭＴＣ‐ＩＷＦから受信し、ＭＴＣのために用いられるＵＥに送信されたＮＡＳメッセージの中のデバイストリガ情報をカプセル化し、デバイストリガ肯定応答をトリガしているＵＥから受信し、デバイストリガ配信成功／失敗ステータスをＭＴＣ‐ＩＷＦにレポートし、ＳＧＳＮ／ＭＭＥ輻輳／ロード情報をＭＴＣ‐ＩＷＦに提供する。

基準点Ｔｓｐ（１２０）は、ＭＴＣ‐ＩＷＦ（MTC Interworking Function）１３０と通信するために、サービス能力サーバによって用いられる。基準点Ｔ５ａ（１２２）は、ＭＴＣ‐ＩＷＦとＳＧＳＮ１１１とを結合するために用いられる。基準点Ｔ５ｂ（１２４）は、ＭＴＣ‐ＩＷＦとサービングＭＭＥとを結合するために用いられる。基準点Ｔ５ｃ（１２６）は、ＭＴＣ‐ＩＷＦとサービングＭＳＣとを結合するために用いられる。基準点Ｓ６ｍ（１２８）は、ＭＴＣ‐ＩＷＦとホーム加入者サーバとを結合するために用いられる。

ＭＴＣ‐ＩＷＦ１３０は、他のネットワークエンティティ内に位置付けられた機能エンティティ又はスタンドアローンエンティティであってよい。ＭＴＣ‐ＩＷＦは、ＨＰＬＭＮ（Home Public Land Mobile Network）の中に存在してよい。ＭＴＣ‐ＩＷＦは、多くの異なる機能を有してよく、これらに限定されるものではないが、Ｔｓｐ、Ｓ６ｍ、及びＲｆ／Ｇａ基準点の終端、Ｔ４、Ｔ５ａ、Ｔ５ｂ、及びＴ５ｃの中の１又は複数の基準点の終端、３ＧＰＰネットワークとの通信確立の前にＳＣＳに権限を与える能力、ＳＣＳからの複数の制御プレーンリクエストに権限を与える能力を含む。

ＭＴＣ‐ＩＷＦ１３０は、以下のデバイストリガの複数の機能性をサポートしてもよく、デバイストリガリクエストをＳＣＳから受信し、ＳＣＳにデバイストリガリクエストの承諾又は不承諾をレポートし、ＳＣＳにデバイストリガ配信の成功又は失敗をレポートし、複数のトリガリクエストへの応答の一部として、ＭＴＣ‐ＩＷＦ及び／又はＳＧＳＮ／ＭＭＥ誘導輻輳／ロード制御を適用してよく、ＵＥがデバイストリガ情報を搬送するＭＴメッセージを任意の他のタイプのメッセージと区別するために標準識別子（例えば、アプリケーションポートＩＤ）を使用する。

ＭＴＣ‐ＩＷＦ１３０は、複数の及び別々にアドレス可能なＨＳＳがネットワークオペレータによって配備されているときに使用するためのホーム加入者サーバ（ＨＳＳ）解決メカニズム、ａ）Ｅ．１６４ＭＳＩＳＤＮ又は外部識別子をＩＭＳＩにマッピングし、ｂ）ＵＥに対するサービングノード情報（例えば、サービングＳＧＳＮ／ＭＭＥ／ＭＳＣ識別子）を取得し、ｃ）ＳＣＳがデバイストリガを特定のＵＥに送信することを許可されているか否かを判断するために、デバイストリガに対して必要とされるときの適切なＨＳＳのインタロゲーションをサポートしてもよい。

ＭＴＣ‐ＩＷＦ１３０は、ＨＳＳ／ＨＬＲからの現行のＵＥのサービングノード情報（例えば、サービングＭＭＥ／ＳＧＳＮ／ＭＳＣ／識別子）、ＵＥによってサポートされる複数のデバイストリガ配信メカニズム、ＨＰＬＭＮによってサポートされる複数の可能なデバイストリガ配信サービス及びローミングのときのＶＰＬＭＮ、もしあれば複数のオペレータ定義デバイストリガ配信ポリシ、及び／又は、任意選択的に、ＳＣＳから受信した任意の情報、もし必要であればプロトコル変換及び選択されたトリガ配信メカニズムを合致させるためのデバイストリガリクエストの関連のネットワークエンティティ（例えば、ＨＰＬＭＮドメインの内部のサービングＳＧＳＮ／ＭＭＥ／ＭＳＣ又はＳＭＳ−ＳＣ）への転送、外部識別子及びＳＣＳ識別子を有するデバイストリガの複数のＣＤＲの生成及びＲｆ／ＧａのインスタンスをわたるＣＤＦ／ＣＧＦへの転送、及び３ＧＰＰネットワークとＳＣＳとの間のセキュアな通信に対する能力に基づいて、最も効率的で効果的なデバイストリガ配信メカニズムの選択及びＳＣＳからのこの詳細の遮蔽をサポートしてもよい。

単一のＭＴＣ−ＩＷＦだけが図１に示されるが、当然のことながら、複数のＭＴＣ−ＩＷＦが単一のＨＰＬＭＮ内で動作してよい。

ホーム加入者サーバ（ＨＳＳ）１５０は、以下の複数の機能性をサポートするように構成されてよく、複数のＭＴＣ−ＩＷＦがＨＬＲ（Home Location Register）／ＨＳＳに接続するＳ６ｍ基準点の終端であり、ＩＭＳＩ（International Mobile Subscriber Identify）に対するＭＳＩＳＤＮ（Mobile Station International Subscriber Data Number）又は（複数の）外部識別子のマッピング／ルックアップ及びデバイストリガに対してＭＴＣ‐ＩＷＦによって用いられるサブスクリプション情報を格納してＭＴＣ‐ＩＷＦ（及び任意選択的にＭＴＣＡＡＡ）に提供し、ＩＭＳＩに対してＭＳＩＳＤＮ又は複数の外部識別子をマッピングし、任意選択的に、複数の外部識別子からＭＳＩＳＤＮがないＳＭＳをサポートしていないレガシーＳＭＳインフラストラクチャにも提供されるＭＳＩＳＤＮへマッピングし、ＵＥに対して利用可能な場合にサービングノード情報（例えば、サービングＳＧＳＮ／ＭＭＥ／ＭＳＣ識別子）を含む「ルーティング情報」をＨＳＳが保存し、ＳＣＳがデバイストリガを特定のＵＥに送信することを許可されているか否かを判断し、Ｓ６ｎ基準点の終端であり、ＭＴＣ−ＡＡＡにＩＭＳＩと（複数の）外部識別子との間のマッピングを提供する。

サービス能力サーバ１３２は、インダイレクトモデルにおいて、アプリケーションサーバ１３４をＭＴＣ‐ＩＷＦ１３０に結合するように構成される。ダイレクトモデルにおいて、アプリケーションサーバ１３６は、外部のＳＣＳを使用することなく、ＵＥとのダイレクトユーザプレーン通信を実行するために、オペレータネットワークに直接結合される。

上記の説明のように、少ないデータリクエストを伴う多数のデバイストリガは、ネットワークにおけるシグナリングサージの原因になり得る。ＵＥは、要求されるより頻繁に、アイドル状態と接続状態との間を切り替えなければならない可能性があるので、これは、ユーザ機器（ＵＥ）の要素の電池寿命に対する否定的な影響につながり得る。いくつかの可能な解決策がある。

図２を参照して、実施形態を提示するフローチャートが示される。本実施形態において、ＭＴＣ‐ＩＷＦ（MTC Interworking Function）は、インダイレクトモデルを用いて、ホーム加入者サービス（ＨＳＳ）からＵＥの状態を取得する。

サービス能力サーバ（ＳＣＳ）は、デバイスをトリガする必要性を判断する（２０２）。ＳＣＳがＭＴＣ‐ＩＷＦに対するコンタクトの詳細情報を有しない場合、それは、第１に、外部識別子を用いて又はローカル構成ＭＴＣ−ＩＷＦ識別子を用いて、ＤＮＳクエリを実行することによって、ＭＴＣ‐ＩＷＦの（複数の）ＩＰアドレス／（複数の）ポートを判断してよい（２０４）。

その後、ＳＣＳは、デバイストリガリクエストメッセージをＭＴＣ‐ＩＷＦに送信する（２０６）。そのメッセージは、外部識別子又はＭＳＩＳＤＮのような情報、ＳＣＳ識別子、トリガ参照番号、有効期間、優先度、アプリケーションポートＩＤ、トリガペイロード、及びその類のものを含んでよい。ＳＣＳは、ＭＴＣアプリケーションにそれをルーティングするための情報と共に、ＭＴＣアプリケーションを宛先とする情報を含んでよいトリガペイロードを含む。アプリケーションポートＩＤは、ＵＥ内のトリガ機能をアドレスするものである。

「デバイストリガリクエスト」メッセージのような用語は、説明のために用いられるにすぎないことに留意するべきである。用いられるメッセージの実際の名前は、異なってよい。

ＭＴＣ‐ＩＷＦは、ＳＣＳが複数のトリガリクエストを送信することが許可されていること、及びＳＣＳがＴｓｐをわたるトリガ提示のそれの割当量又は割合を超えていないことをチェックする（２０８）。このチェックが失敗した場合、ＭＴＣ‐ＩＷＦは、失敗状態の理由を示す原因値を有するデバイストリガ確認メッセージを送信し、フローはこのステップで終了する。

ＭＴＣ‐ＩＷＦは、ＳＣＳがＵＥをトリガすることが許可されているか否かを判断するために、加入者情報リクエスト（ＳＩＲ）メッセージをＨＳＳに送信する。（外部識別子又はＭＳＩＳＤＮ及びＳＣＳ識別子、ＵＥ状態情報リクエスト）外部識別子又はＭＳＩＳＤＮをＩＭＳＩに変換するために、ＵＥの（複数の）サービングＣＮノードの複数のアイデンティティを取得する（２１０）。ＵＥ状態情報リクエストフラグは、ＨＳＳからの（アイドル、接続、及び登録のような）ＵＥ状態情報をリクエストするものである（２１２）。この情報は、また、ＵＥが到達可能でない場合、到達可能性通知を登録することをＨＳＳに伝える。

ＭＴＣ‐ＩＷＦは、キャッシュ許可及びＵＥに対するルーティング情報を実行するように構成されてよい。しかし、キャッシュされたサービングノード情報が古いとき、これは、トリガ配信の試みの失敗の可能性を高める可能性がある。

ＨＳＳは、加入者情報回答（ＩＭＳＩ及び（複数の）サービングノードの複数のアイデンティティ、ＵＥ状態情報）メッセージを送信する（２１４）。ＨＳＳポリシは、どのサービングノードアイデンティティが戻されるかに影響し得る。ＳＣＳがトリガメッセージをこのＵＥに送信することが許可されていないことを原因値が示す、又は有効なサブスクリプション情報がＨＳＳによって戻されなかった場合、ＭＴＣ‐ＩＷＦは、失敗状態の理由を示す原因値を有するデバイストリガ確認メッセージを送信し、フローは終了する。そうでなければ、このフローは継続する。

ＵＥが到達可能でない場合、ＨＳＳは、ＵＥが到達可能でないという黙示的な指標を提供する複数のサービングノードアイデンティティ又は状態情報を送信しなくてよく、ＭＴＣ‐ＩＷＦは、この場合、有効期間が単一の試み配信を示さない場合、トリガを格納する。

その後、ＭＴＣ‐ＩＷＦは、加入者情報回答メッセージの中のＵＥの状態を取得し、トリガメッセージをバッファするかそれを配信するかを決定する（２１６）。この処理は、いくつかの異なるやり方のうちの１つで行われてよい。１つの例は、図３に関連してさらに詳述される。ＭＴＣ‐ＩＷＦがデバイストリガメッセージを送信することを決定するとき、それは、ＨＳＳから受信した情報及びローカルポリシに基づいて、トリガ配信手順を選択する。配信手順が選択され、ＭＴＣ‐ＩＷＦは、トリガ配信手順を試みる（２１８）。

ＭＴＣ‐ＩＷＦは、トリガ配信が成功したか失敗したかを示す原因値及び失敗の理由と共に、デバイストリガレポート（外部識別子又はＭＳＩＳＤＮ及びトリガ参照番号）メッセージをＳＣＳに送信する（２２０）。ＭＴＣ‐ＩＷＦは、外部識別子又はＭＳＩＳＤＮ及びＳＣＳ識別子を含む必要なＣＤＲ情報を生成する（２２２）。

受信されたデバイストリガに応答して、ＵＥは、トリガペイロードのコンテンツを考慮に入れる特定の複数の動作を行う（２２４）。この応答は、典型的には、ＳＣＳ又はＡＳとの即時の又は後の通信の開始を伴う。この動作は、タスクが課されているＵＥの特質によって決まる。

図３を参照すると、フローチャートは、ＵＥ状態情報を受信した場合のＭＴＣ‐ＩＷＦの挙動を提示する。加入者情報回答メッセージを受信した（３０２）後、ＭＴＣ‐ＩＷＦは、その加入者を有効にし、ＵＥの状態をチェックする（３０４）。そして、デバイストリガの優先度がチェックされる（３０６）。優先度が高い場合（３０８）、その後、デバイストリガが配信される（３１０）。優先度が低い場合（３１２）、その後、ＵＥの状態がチェックされる（３１４）。ＵＥが接続されている場合（３１６）、その後、デバイストリガが配信される（３１０）。ＵＥがアイドルの場合（３１８）、その後、デバイストリガがバッファされる（３２０）。そして、カウンタがインクリメントされる（３２２）。カウンタが最大量に達している場合、デバイストリガが配信される（３１０）。そうでなければ、ＵＥの状態をチェックする処理が繰り返えされる（３１４）。カウンタは、複数のデバイストリガメッセージの効果的な送信を可能にする任意の数に設定されることができる。このような手順に従って、ＵＥにデバイストリガメッセージを受信するために接続状態に入らせる前に、デバイストリガメッセージの宛先ＵＥが単独でアイドル状態から接続状態に変化することを待つ。

上で提供された解決策に基づいて、ＵＥ状態情報リクエストフラグは、ＳＩＲ（加入者情報リクエスト）にも新しいＵＳＩＲ（ユーザ状態情報リクエスト）メッセージにも含まれることができる。それに応じて、ＳＩＡ（加入者情報回答）又は新しいＵＳＩＡ（ユーザ状態情報回答）は、現在のＵＥ状態情報回答を含む。

ＳＩＲ及びＳＩＡは、３ＧＰＰ規格のリリース１１のＴＳ２９．３３６で定義された既存の複数のメッセージである。これらのメッセージは、以下のように、ＵＥ状態情報を反映するために強化される。ＳＩＲは、ＵＥ状態情報リクエストフラグに対する新しい属性値ペア（ＡＶＰ）を有し、ＳＩＡは、ＵＥ状態情報回答に対する新しいＡＶＰを有する。ＵＳＩＲ及びＵＳＩＡは、将来の文書で定義される新しい複数のメッセージである。

ユーザ状態情報は、ＵＥの以下の複数の状態の１つであり得る。

DETACHED

ATTACHED_NOT_REACHABLE_FOR_PAGING

ATTACHED_REACHABLE_FOR_PAGING

CONNECTED_NOT_REACHABLE_FOR_PAGING

CONNECTED_REACHABLE_FOR_PAGING

NETWORK_DETERMINED_NOT_REACHABLE

新しい状態情報は、必要に応じて追加されることもできる。例えば、EMM_IDLE及びEMM_CONNECTED。ＨＳＳは、ＵＥＭＭ状態情報を知らない可能性がある。そのような場合、ＨＳＳ通知手順は、ＵＥＭＭ、ＳＭ状態、及びその類のもののような、他のＵＥ状態情報を格納するために強化されることができる。

図４を参照すると、フローチャートは、ＭＴＣ‐ＩＷＦがＵＥの状態をモビリティ管理エンティティ（ＭＭＥ）から取得する実施形態の動作を提示する。

サービス能力サーバ（ＳＣＳ）は、デバイスをトリガする必要性を判断する（４０２）。ＳＣＳがＭＴＣ‐ＩＷＦに対するコンタクトの詳細情報を有しない場合、それは、第１に、外部識別子を用いて又はローカル構成ＭＴＣ−ＩＷＦ識別子を用いて、ＤＮＳクエリを実行することによって、ＭＴＣ‐ＩＷＦの（複数の）ＩＰアドレス／（複数の）ポートを判断してよい（４０４）。

その後、ＳＣＳは、デバイストリガリクエストメッセージをＭＴＣ‐ＩＷＦに送信する（４０６）。そのメッセージは、外部識別子又はＭＳＩＳＤＮのような情報、ＳＣＳ識別子、トリガ参照番号、有効期間、優先度、トリガペイロード、及びその類のものを含んでよい。ＳＣＳは、ＭＴＣアプリケーションにそれをルーティングするための情報と共に、ＭＴＣアプリケーションを宛先とする情報を含んでよいトリガペイロードを含む。

ＭＴＣ‐ＩＷＦは、ＳＣＳが複数のトリガリクエストを送信することが許可されていること、及びＳＣＳがＴｓｐをわたるトリガ提示のそれの割当量又は割合を超えていないことをチェックする（４０８）。このチェックが失敗した場合、ＭＴＣ‐ＩＷＦは、失敗状態の理由を示す原因値を有するデバイストリガ確認メッセージを送信し、フローはこのステップで終了する。

ＭＴＣ‐ＩＷＦは、外部識別子又はＭＳＩＳＤＮをＩＭＳＩに変換し、関連するＨＳＳが保存するＵＥの（複数の）サービングＣＮノードの複数のアイデンティティを含む「ルーティング情報」を取得するために、ＳＣＳがＵＥをトリガすることが許可されているか否かを判断すべく、加入者情報リクエスト（外部識別子又はＭＳＩＳＤＮ及びＳＣＳ識別子）メッセージをＨＳＳ／ＨＬＲに送信する（４１０）。

ＨＳＳ／ＨＬＲは、加入者情報レスポンス（ＩＭＳＩ及び／又はＭＳＩＳＤＮ及び（複数の）サービングノードの複数のアイデンティティを含む関連する「ルーティング情報」、原因）メッセージを送信する（４１２）。（場合によりＶＰＬＭＮＩＤによって決まる）ＨＳＳ／ＨＬＲポリシは、どのサービングノードアイデンティティが戻されるかに影響し得る。ＳＣＳがトリガメッセージをこのＵＥに送信することが許可されていないことを原因値が示す、又は有効なサブスクリプション情報がない場合、ＭＴＣ‐ＩＷＦは、失敗状態の理由を示す原因値を有するデバイストリガ確認メッセージを送信し、フローはこのステップで終了する。

ユーザ状態情報リクエストメッセージは、ＭＴＣ‐ＩＷＦからＭＭＥに送信され、ＵＥの状態をリクエストする（４１４）。このメッセージに含まれる情報は、図２に関して上で説明されたとおりである。

ユーザ状態情報回答メッセージは、ＭＭＥからのリクエストに対する返信として送信され、ＵＥの状態をそれに通知する（４１６）。このメッセージに含まれる情報は、同様に、図２に関して上で説明されたとおりである。

ＭＴＣ‐ＩＷＦは、ここで、図３に関して上で説明された方法を用いて、トリガメッセージをバッファするかそれを配信するかを決定する（４１８）。ＭＴＣ‐ＩＷＦがトリガを送信することを決定した後、それは、ＨＳＳから受信した情報及びローカルポリシに基づいて、トリガ配信手順を選択する。Ｔ５配信手順が選択され、ＭＴＣ‐ＩＷＦは、Ｔ５トリガ配信手順を試みる。

図５を参照すると、フローチャートは、ＭＴＣ‐ＩＷＦがＵＥの状態をプレゼンスサーバから取得する実施形態の動作を提示する。

サービス能力サーバ（ＳＣＳ）は、デバイスをトリガする必要性を判断する（５０２）。ＳＣＳがＭＴＣ‐ＩＷＦに対するコンタクトの詳細情報を有しない場合、それは、第１に、外部識別子を用いて又はローカル構成ＭＴＣ−ＩＷＦ識別子を用いて、ＤＮＳクエリを実行することによって、ＭＴＣ‐ＩＷＦの（複数の）ＩＰアドレス／（複数の）ポートを判断してよい（５０４）。

その後、ＳＣＳは、デバイストリガリクエストメッセージをＭＴＣ‐ＩＷＦに送信する（５０６）。そのメッセージは、外部識別子又はＭＳＩＳＤＮのような情報、ＳＣＳ識別子、トリガ参照番号、有効期間、優先度、トリガペイロード、及びその類のものを含んでよい。ＳＣＳは、ＭＴＣアプリケーションにそれをルーティングするための情報と共に、ＭＴＣアプリケーションを宛先とする情報を含んでよいトリガペイロードを含む。

ＭＴＣ‐ＩＷＦは、ＳＣＳが複数のトリガリクエストを送信することが許可されていること、及びＳＣＳがＴｓｐをわたるトリガ提示のそれの割当量又は割合を超えていないことをチェックする（５０８）。このチェックが失敗した場合、ＭＴＣ‐ＩＷＦは、失敗状態の理由を示す原因値を有するデバイストリガ確認メッセージを送信し、フローはこのステップで終了する。

ＭＴＣ‐ＩＷＦは、外部識別子又はＭＳＩＳＤＮをＩＭＳＩに変換し、関連するＨＳＳが保存するＵＥの（複数の）サービングＣＮノードの複数のアイデンティティを含む「ルーティング情報」を取得するために、ＳＣＳがＵＥをトリガすることが許可されているか否かを判断すべく、加入者情報リクエスト（外部識別子又はＭＳＩＳＤＮ及びＳＣＳ識別子）メッセージをＨＳＳ／ＨＬＲに送信する（５１０）。

ＨＳＳ／ＨＬＲは、加入者情報レスポンス（ＩＭＳＩ及び／又はＭＳＩＳＤＮ及び（複数の）サービングノードの複数のアイデンティティを含む関連する「ルーティング情報」、原因）メッセージを送信する（５１２）。（場合によりＶＰＬＭＮＩＤによって決まる）ＨＳＳ／ＨＬＲポリシは、どのサービングノードアイデンティティが戻されるかに影響し得る。ＳＣＳがトリガメッセージをこのＵＥに送信することが許可されていないことを原因値が示す、又は有効なサブスクリプション情報がない場合、ＭＴＣ‐ＩＷＦは、失敗状態の理由を示す原因値を有するデバイストリガ確認メッセージを送信し、フローはこのステップで終了する。

ユーザ状態情報リクエストメッセージは、ＭＴＣ‐ＩＷＦからプレゼンスサーバに送信され、ＵＥの状態をリクエストする（５１４）。このメッセージに含まれる情報は、上で説明されたとおりである。ＭＴＣ‐ＩＷＦは、プレゼンスサーバのアドレスを事前に設定されることができる。このステップは、５１０と並行に行われることができる。

ユーザ状態情報回答メッセージは、プレゼンスサーバからのリクエストに対する返信として送信され、ＵＥの状態をそれに通知する（５１６）。このメッセージに含まれる情報は、上で説明されたとおりである。

ＭＴＣ‐ＩＷＦは、ここで、トリガメッセージをバッファするかそれを配信するかを決定する（５１８）。これは、図３に関して上述された以下の方法でなされてよい。ＭＴＣ‐ＩＷＦがトリガを送信することを決定した後、ＭＴＣ−ＩＷＦは、Ｔ５トリガ配信手順を試みる（５２０）。

いくつかの実施形態において、ＭＴＣ‐ＩＷＦは、ＵＥと直接に通信し、ＵＥ状態情報を格納するように構成されてよい。この場合、ＵＥは、状態情報をＭＴＣ‐ＩＷＦに直接に送信し、ＵＥによるＭＴＣ‐ＩＷＦ発見メカニズムは、ＵＥによるプレゼンスサーバ発見メカニズムと同一であり得る。いくつかの実施形態において、ＭＴＣ‐ＩＷＦ及びプレゼンスサーバは、同じ場所に配置され、又は同一のボックスの中に実装されることができる。そのような実施形態において、すべての機能性が同一のボックスの中に実装されることが必要とは限らない。言い換えると、ＭＴＣ‐ＩＷＦの中にプレゼンスサーバの機能性の部分を実装することが可能であってよい。

図６を参照すると、フローチャートは、ＭＴＣ‐ＩＷＦがトリガをＭＭＥにバッファする実施形態の動作を提示する。ＭＭＥは例にすぎないことに留意するべきである。バッファリングノードは、ＳＧＳＮ又はＭＳＣでもあり得る。

サービス能力サーバ（ＳＣＳ）は、デバイスをトリガする必要性を判断する（６０２）。ＳＣＳがＭＴＣ‐ＩＷＦに対するコンタクトの詳細情報を有しない場合、それは、第１に、外部識別子を用いて又はローカル構成ＭＴＣ−ＩＷＦ識別子を用いて、ＤＮＳクエリを実行することによって、ＭＴＣ‐ＩＷＦの（複数の）ＩＰアドレス／（複数の）ポートを判断してよい（６０４）。

その後、ＳＣＳは、デバイストリガリクエストメッセージをＭＴＣ‐ＩＷＦに送信する（６０６）。そのメッセージは、外部識別子又はＭＳＩＳＤＮのような情報、ＳＣＳ識別子、トリガ参照番号、有効期間、優先度、トリガペイロード、及びその類のものを含んでよい。ＳＣＳは、ＭＴＣアプリケーションにそれをルーティングするための情報と共に、ＭＴＣアプリケーションを宛先とする情報を含んでよいトリガペイロードを含む。

ＭＴＣ‐ＩＷＦは、ＳＣＳが複数のトリガリクエストを送信することが許可されていること、及びＳＣＳがＴｓｐをわたるトリガ提示のそれの割当量又は割合を超えていないことをチェックする（６０８）。このチェックが失敗した場合、ＭＴＣ‐ＩＷＦは、失敗状態の理由を示す原因値を有するデバイストリガ確認メッセージを送信し、フローはこのステップで終了する。

ＭＴＣ‐ＩＷＦは、外部識別子又はＭＳＩＳＤＮをＩＭＳＩに変換し、関連するＨＳＳが保存するＵＥの（複数の）サービングＣＮノードの複数のアイデンティティを含む「ルーティング情報」を取得するために、ＳＣＳがＵＥをトリガすることが許可されているか否かを判断すべく、加入者情報リクエスト（外部識別子又はＭＳＩＳＤＮ及びＳＣＳ識別子）メッセージをＨＳＳ／ＨＬＲに送信する（６１０）。

ＨＳＳ／ＨＬＲは、加入者情報レスポンス（ＩＭＳＩ及び／又はＭＳＩＳＤＮ及び（複数の）サービングノードの複数のアイデンティティを含む関連する「ルーティング情報」、原因）メッセージを送信する（６１２）。（場合によりＶＰＬＭＮＩＤによって決まる）ＨＳＳ／ＨＬＲポリシは、どのサービングノードアイデンティティが戻されるかに影響し得る。ＳＣＳがトリガメッセージをこのＵＥに送信することが許可されていないことを原因値が示す、又は有効なサブスクリプション情報がない場合、ＭＴＣ‐ＩＷＦは、失敗状態の理由を示す原因値を有するデバイストリガ確認メッセージを送信し、フローはこのステップで終了する。

ＭＴＣ‐ＩＷＦは、ＵＥの複数の機能、ＨＳＳから取得されたサービングコアネットワーク（ＣＮ）の（複数の）ノードの複数の機能を使用し、Ｔ５トリガが可能な適したサービングＣＮノードを選択する（６１４）。ＭＴＣ‐ＩＷＦは、提示リクエストをサービングＣＮノードに送信する。提示リクエストは、ＩＭＳＩ、メッセージ優先度、ＭＴＣ‐ＩＷＦＩＤ、参照番号、単一の配信試みフラグ（任意選択的）、有効時間（任意選択的）、リクエストタイプ（トリガアプリケーション）、アプリケーションＰＤＵを含んでよい。１より多いサービングＣＮノードがある場合、ＭＴＣ‐ＩＷＦは、ＵＥが現在キャンプしている可能性が最も高いサービングＣＮノードにメッセージを送信すべきである。これは、例えば、ＨＳＳから受信した情報又は前の複数のトリガ試みからのキャッシュされた情報に基づいてよい。

サービングＣＮノードは、リクエストタイプ（トリガアプリケーション）、アプリケーションＰＤＵ、ＭＴＣ‐ＩＷＦＩＤ、ＮＡＳメッセージ内の参照番号を示し、それをＵＥに配信する（６１６）。サービングＣＮノードは、必要なＣＤＲ情報を生成する（６１８）。ＵＥは、トリガコンテンツ及びトリガタイプを対応するアプリケーションに提供する（６２０）。

ＵＥがアイドルモードにある場合、サービングＣＮノードは、トリガを配信するためにＮＡＳメッセージを送信する前に、ＵＥを呼び出してよい（６２２）。ＵＥがアイドルモードにない場合、それは、トリガを配信する（６２４）。

ＵＥがアイドルモードにある場合、ＭＭＥは、トリガメッセージをバッファするかそれを配信するかを決定する。これは、図７において後で詳述される方法に従って、又は様々な他の異なる手法で達成されてよい。

サービングＣＮノードは、配信レポートメッセージをＭＴＣ‐ＩＷＦに送信する（６２６）。配信レポートは、ＩＭＳＩ、原因、参照番号、ＣＮノードによって配信されたもの、レスポンスタイプ（トリガアプリケーション）、及びもし受信すれば、アプリケーションＰＤＵ、ＭＭＥにおけるバッファについての情報を含む情報のいくつかの要素を含んでよい。原因は、トリガメッセージが成功裏にＵＥに配信されたかどうか、又はそれがバッファされたか否か、又は失敗した場合には失敗の理由を示す。

そして、ＭＴＣ‐ＩＷＦは、行われた複数の動作をそれに通知するＳＣＳにレポートを送信する（６２８）。

図７を参照すると、フローチャートは、ＵＥのステータスに応じたＭＭＥの挙動を示す。トリガを受信した（７０２）後、ＭＭＥは、ＵＥの状態をチェックする（７０４）。そして、デバイストリガの優先度がチェックされる（７０６）。優先度が高い場合（７０８）、その後、デバイストリガが配信される（７１０）。優先度が低い場合（７１２）、その後、ＵＥの状態がチェックされる（７１４）。ＵＥが接続されている場合（７１６）、その後、デバイストリガが配信される（７１０）。ＵＥがアイドルの場合（７１８）、その後、デバイストリガがＭＭＥにバッファされる（７２０）。そして、カウンタがインクリメントされる（７２２）。カウンタが最大量に達している場合、デバイストリガが配信される（７１０）。そうでなければ、ＵＥの状態をチェックする処理が繰り返えされる（７１４）。カウンタは、複数のデバイストリガメッセージの効果的な送信を可能にする任意の数に設定されることができる。以下のような手順は、ＵＥにデバイストリガメッセージを受信するために接続状態に入らせる前に、デバイストリガメッセージの宛先ＵＥが単独でアイドル状態から接続状態に変化することを待つ。

以下の複数の例は、さらなる実施形態に関する。

ＬＴＥネットワークにおけるＭＴＣ‐ＩＷＦ（Machine Type Communication Interworking Function）は、ＬＴＥネットワークを介してデバイストリガリクエストを受信し、デバイストリガリクエストを有効にし、デバイストリガが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストし、ＵＥのステータス情報を受信し、ステータス情報に基づいてデバイストリガを送信するように構成されたプロセッサを備えてよく、ステータス情報は、ＵＥの接続ステータスについての情報を備える。ステータス情報は、ＵＥがアイドル状態にあるか接続状態にあるかを示してよい。ＭＴＣ‐ＩＷＦは、デバイストリガリクエストの優先度を判断し、デバイストリガリクエストの優先度が高いときにデバイストリガメッセージを送信するようにさらに構成されてよい。ＭＴＣ‐ＩＷＦは、デバイストリガリクエストの優先度を判断し、デバイストリガリクエストの優先度が低いときには、ＵＥが接続状態にあるときにデバイストリガリクエストを送信し、ＵＥがアイドル状態にあるときにデバイストリガリクエストをバッファするようにさらに構成されてよい。

他の実施形態において、ＬＴＥネットワークにおいてデバイストリガメッセージを宛先ユーザ機器（ＵＥ）に送信する方法は、デバイストリガメッセージを送信するリクエストを受信する段階と、デバイストリガメッセージの優先度を判断する段階と、デバイストリガメッセージの優先度が高い場合にデバイストリガメッセージを送信する段階と、デバイストリガメッセージの優先度が低い場合にデバイストリガメッセージの宛先ＵＥが接続状態にあるか否かをチェックする段階と、宛先ＵＥが接続状態にあるときにデバイストリガメッセージを送信する段階と、さもなければ宛先ＵＥが接続状態になるまでデバイストリガメッセージをバッファする段階とを備えてよい。

一実施形態において、方法は、ＭＴＣ‐ＩＷＦ（Machine Type Communications Interworking Function）によって実行される。一実施形態において、方法は、モバイル管理エンティティ（ＭＭＥ）によって実行される。

他の実施形態において、ＬＴＥネットワークにおいてデバイストリガメッセージを送信する方法は、デバイストリガリクエストを受信する段階と、デバイストリガリクエストを有効にする段階と、デバイストリガが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストする段階と、ＵＥのステータス情報を受信する段階と、ステータス情報に基づいてデバイストリガを送信する段階とを備えてよく、ステータス情報は、ＵＥの接続ステータスについての情報を備える。

一実施形態において、ステータス情報は、ＵＥがアイドル状態にあるか接続状態にあるかを示す。

一実施形態において、ステータス情報に基づいてデバイストリガを送信する段階は、デバイストリガリクエストの優先度を判断する段階と、デバイストリガリクエストの優先度が高いときにデバイストリガメッセージを送信する段階とを備える。

一実施形態において、ステータス情報に基づいてデバイストリガを送信する段階は、デバイストリガリクエストの優先度を判断する段階と、デバイストリガリクエストの優先度が低いときには、ＵＥが接続状態にあるときにデバイストリガリクエストを送信する段階と、ＵＥがアイドル状態にあるときにデバイストリガリクエストをバッファする段階とを備える。一実施形態において、デバイストリガリクエストをバッファする段階は、モバイル管理エンティティ（ＭＭＥ）によって実行される。

一実施形態において、方法は、デバイストリガの送信を詳述するレポートを生成する段階と、デバイストリガの送信に基づいて課金データ記録（ＣＤＲ）を生成する段階とをさらに備えてよい。

一実施形態において、方法は、ＭＴＣ‐ＩＷＦ（Machine Type Communication Interworking Function）によって実行される。

一実施形態において、デバイストリガが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストする段階は、加入者情報リクエスト（ＳＩＲ）メッセージをホーム加入者サーバ（ＨＳＳ）に送信する段階を備えてよく、ＵＥのステータス情報を受信する段階は、加入者情報回答（ＳＩＡ）メッセージをＨＳＳから受信する段階を備えてよい。

一実施形態において、ＳＩＲメッセージは、ＵＥの状態情報リクエストを備え、ＳＩＡメッセージは、ＵＥの状態情報を備えてよい。

一実施形態において、状態情報は、ＵＥがアイドル状態にあるか接続状態にあるかに関する情報を備える。

一実施形態において、状態情報は、detached、Attached_Not_Reachable_For_Paging、Attached_Reachable_For_Paging、Connected_Not_Reachable_For_Paging、Connected_Reachable_For_Paging、及びNetwork_Determined_Not_Reachableから選択される。

一実施形態において、デバイストリガが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストする段階は、加入者情報リクエスト（ＳＩＲ）メッセージをモバイル管理エンティティ（ＭＭＥ）に送信する段階を備えてよく、ＵＥのステータス情報を受信する段階は、加入者情報回答（ＳＩＡ）メッセージをＭＭＥから受信する段階を備える。

一実施形態において、デバイストリガが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストする段階は、加入者情報リクエスト（ＳＩＲ）メッセージをプレゼンスサーバに送信する段階を備え、ＵＥのステータス情報を受信する段階は、加入者情報回答（ＳＩＡ）メッセージをプレゼンスサーバから受信する段階を備える。

一実施形態において、デバイストリガが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストする段階は、加入者情報リクエスト（ＳＩＲ）メッセージをホーム加入者サーバ（ＨＳＳ）に送信する段階を備えてよく、ＵＥのステータス情報を受信する段階は、加入者情報回答（ＳＩＡ）メッセージをＨＳＳから受信する段階を備える。

他の実施形態において、方法は、デバイストリガリクエストを受信する段階と、デバイストリガリクエストを有効にする段階と、デバイストリガが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストする段階と、ＵＥのステータス情報を受信する段階と、デバイストリガリクエストを処理するようにモバイル管理エンティティにリクエストを提示する段階とを備えてよい。

本発明の特定の特徴がここで示されて説明されたが、多くの修正、置き換え、変化、及び均等物が当業者に想定される。したがって、添付の請求項は、本発明の範囲内に含まれる全てのそのような修正及び変化をカバーすることが意図されていることが理解される。

Claims

ロングタームエボリューションネットワーク（ＬＴＥネットワーク）におけるＭＴＣ‐ＩＷＦ（Machine Type Communication Interworking Function）であって、
前記ＬＴＥネットワークを介してデバイストリガメッセージを送信するリクエストを受信し、
デバイストリガメッセージを送信する前記リクエストを有効にし、
前記デバイストリガメッセージが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストし、
前記ＵＥの前記ステータス情報を受信し、
デバイストリガメッセージを送信する前記リクエストの優先度を判断し、
前記デバイストリガメッセージを送信する前記リクエストの前記優先度が高いときに、前記ステータス情報に基づいて前記デバイストリガメッセージを送信するように構成されたプロセッサを備え、
前記ステータス情報は、前記ＵＥの接続ステータスについての情報を備えるＭＴＣ‐ＩＷＦ。
前記ＭＴＣ‐ＩＷＦは、
前記リクエストの優先度を判断し、
前記リクエストの前記優先度が低いときには、
前記ＵＥが接続状態にあるときに前記デバイストリガメッセージを送信し、
前記ＵＥがアイドル状態にあるときに前記デバイストリガメッセージをバッファする
ようにさらに構成された請求項１に記載のＭＴＣ‐ＩＷＦ。
ロングタームエボリューションネットワーク（ＬＴＥネットワーク）におけるＭＴＣ‐ＩＷＦ（Machine Type Communication Interworking Function）であって、
前記ＬＴＥネットワークを介してデバイストリガメッセージを送信するリクエストを受信し、
デバイストリガメッセージを送信する前記リクエストを有効にし、
前記デバイストリガメッセージが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストし、
前記ＵＥの前記ステータス情報を受信し、
前記リクエストの優先度を判断し、
前記リクエストの前記優先度が低いときには、
前記ＵＥが接続状態にあるときに前記デバイストリガメッセージを送信し、
前記ＵＥがアイドル状態にあるときに前記デバイストリガメッセージをバッファする
ように構成されたプロセッサを備える、ＭＴＣ‐ＩＷＦ。
前記ステータス情報は、前記ＵＥがアイドル状態にあるか接続状態にあるかを示す請求項１から３のいずれか一項に記載のＭＴＣ‐ＩＷＦ。
ＬＴＥネットワークにおいてデバイストリガメッセージを宛先ユーザ機器（宛先ＵＥ）に送信する方法であって、
デバイストリガメッセージを送信するリクエストを受信する段階と、
前記デバイストリガメッセージの優先度を判断する段階と、
前記デバイストリガメッセージの前記優先度が高い場合に、前記デバイストリガメッセージを送信する段階と、
前記デバイストリガメッセージの前記優先度が低い場合に、前記デバイストリガメッセージの前記宛先ＵＥが接続状態にあるか否かをチェックする段階と、
前記宛先ＵＥが接続状態にあるときに前記デバイストリガメッセージを送信する段階と、
前記宛先ＵＥが接続状態にないときに、前記宛先ＵＥが接続状態になるまで前記デバイストリガメッセージをバッファする段階と
を備える方法。
ＬＴＥネットワークにおいてデバイストリガメッセージを宛先ユーザ機器（宛先ＵＥ）に送信する方法であって、
デバイストリガメッセージを送信するリクエストを受信する段階と、
前記デバイストリガメッセージの優先度を判断する段階と、
前記デバイストリガメッセージの前記優先度が高い場合に、前記デバイストリガメッセージを送信する段階と
を備える方法。
ＬＴＥネットワークにおいてデバイストリガメッセージを宛先ユーザ機器（宛先ＵＥ）に送信する方法であって、
デバイストリガメッセージを送信するリクエストを受信する段階と、
前記デバイストリガメッセージの優先度を判断する段階と、
前記デバイストリガメッセージの前記優先度が低い場合に、前記デバイストリガメッセージの前記宛先ＵＥが接続状態にあるか否かをチェックする段階と、
前記宛先ＵＥが接続状態にあるときに前記デバイストリガメッセージを送信する段階と、
前記宛先ＵＥが接続状態にないときに、前記宛先ＵＥが接続状態になるまで前記デバイストリガメッセージをバッファする段階と
を備える方法。
前記方法は、ＭＴＣ‐ＩＷＦ（Machine Type Communications Interworking Function）によって実行される請求項５から７のいずれか一項に記載の方法。
前記方法は、モバイル管理エンティティ（ＭＭＥ）によって実行される請求項５から８のいずれか一項に記載の方法。
ロングタームエボリューション（ＬＴＥ）ネットワークにおいてデバイストリガメッセージを送信する方法であって、
デバイストリガメッセージを送信するリクエストを受信する段階と、
前記デバイストリガメッセージを送信する前記リクエストを有効にする段階と、
前記デバイストリガメッセージが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストする段階と、
前記デバイストリガメッセージが送信されるべき前記ＵＥの前記ステータス情報を受信する段階と、
前記デバイストリガメッセージを送信する前記リクエストの優先度を判断する段階と、
デバイストリガメッセージを送信する前記リクエストの前記優先度が高いときに、前記ステータス情報に基づいて前記デバイストリガメッセージを送信する段階と
を備え、
前記ステータス情報は、前記ＵＥの接続ステータスについての情報を備える方法。
前記ステータス情報に基づいて前記デバイストリガメッセージを送信する段階は、
デバイストリガメッセージを送信する前記リクエストの優先度を判断する段階と、
デバイストリガメッセージを送信する前記リクエストの前記優先度が低いときには、
前記ＵＥが接続状態にあるときに前記デバイストリガメッセージを送信する段階と、
前記ＵＥがアイドル状態にあるときに前記デバイストリガメッセージをバッファする段階と
を備える請求項１０に記載の方法。
ロングタームエボリューション（ＬＴＥ）ネットワークにおいてデバイストリガメッセージを送信する方法であって、
デバイストリガメッセージを送信するリクエストを受信する段階と、
前記デバイストリガメッセージを送信する前記リクエストを有効にする段階と、
前記デバイストリガメッセージが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストする段階と、
前記デバイストリガメッセージが送信されるべき前記ＵＥの前記ステータス情報を受信する段階と、
デバイストリガメッセージを送信する前記リクエストの優先度を判断する段階と、
デバイストリガメッセージを送信する前記リクエストの前記優先度が低いときには、
前記ＵＥが接続状態にあるときに前記デバイストリガメッセージを送信する段階と、
前記ＵＥがアイドル状態にあるときに前記デバイストリガメッセージをバッファする段階と
を備える、方法。
前記デバイストリガメッセージをバッファする段階は、モバイル管理エンティティ（ＭＭＥ）によって実行される請求項１１又は１２に記載の方法。
前記ステータス情報は、前記ＵＥがアイドル状態にあるか接続状態にあるかを示す請求項１０から１３のいずれか一項に記載の方法。
前記デバイストリガメッセージの前記送信を詳述するレポートを生成する段階と、
前記デバイストリガメッセージの前記送信に基づいて課金データ記録（ＣＤＲ）を生成する段階と
をさらに備える請求項１０から１４のいずれか一項に記載の方法。
前記方法は、ＭＴＣ‐ＩＷＦ（Machine Type Communication Interworking Function）によって実行される請求項１０から１５のいずれか一項に記載の方法。
前記デバイストリガメッセージが送信されるべき前記ユーザ機器（ＵＥ）のステータス情報をリクエストする段階は、加入者情報リクエストメッセージ（ＳＩＲメッセージ）をホーム加入者サーバ（ＨＳＳ）に送信する段階を備え、
前記デバイストリガメッセージが送信されるべき前記ＵＥの前記ステータス情報を受信する段階は、加入者情報回答メッセージ（ＳＩＡメッセージ）を前記ＨＳＳから受信する段階を備える請求項１６に記載の方法。
前記ＳＩＲメッセージは、前記ＵＥの状態情報リクエストを備え、さらに、前記ＳＩＡメッセージは、前記ＵＥの状態情報を備える請求項１７に記載の方法。
前記状態情報は、前記ＵＥがアイドル状態にあるか接続状態にあるかに関する情報を備える請求項１８に記載の方法。
前記状態情報は、detached、Attached_Not_Reachable_For_Paging、Attached_Reachable_For_Paging、Connected_Not_Reachable_For_Paging、Connected_Reachable_For_Paging、及びNetwork_Determined_Not_Reachableから選択される請求項１９に記載の方法。
前記ＳＩＲメッセージは、ユーザ状態情報リクエスト（ＵＳＩＲ）メッセージであり、
前記ＳＩＡメッセージは、ユーザ状態情報回答（ＵＳＩＡ）メッセージである請求項１７から２０のいずれか一項に記載の方法。
前記デバイストリガメッセージが送信されるべき前記ユーザ機器（ＵＥ）のステータス情報をリクエストする段階は、加入者情報リクエスト（ＳＩＲ）メッセージをモバイル管理エンティティ（ＭＭＥ）に送信する段階を備え、
前記ＵＥの前記ステータス情報を受信する段階は、加入者情報回答（ＳＩＡ）メッセージを前記ＭＭＥから受信する段階を備える請求項１６に記載の方法。
前記デバイストリガメッセージが送信されるべき前記ユーザ機器（ＵＥ）のステータス情報をリクエストする段階は、加入者情報リクエスト（ＳＩＲ）メッセージをプレゼンスサーバに送信する段階を備え、
前記ＵＥの前記ステータス情報を受信する段階は、加入者情報回答（ＳＩＡ）メッセージを前記プレゼンスサーバから受信する段階を備える請求項１６に記載の方法。
前記デバイストリガメッセージが送信されるべき前記ユーザ機器（ＵＥ）のステータス情報をリクエストする段階は、加入者情報リクエスト（ＳＩＲ）メッセージをホーム加入者サーバ（ＨＳＳ）に送信する段階を備え、
前記ＵＥの前記ステータス情報を受信する段階は、加入者情報回答（ＳＩＡ）メッセージを前記ＨＳＳから受信する段階を備える請求項１６に記載の方法。
デバイストリガメッセージを送信する第１のリクエストを受信する段階と、
デバイストリガメッセージを送信する前記第１のリクエストを有効にする段階と、
前記デバイストリガメッセージが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストする段階と、
前記ＵＥの前記ステータス情報を受信する段階と、
前記デバイストリガメッセージを送信する前記第１のリクエストの優先度を判断する段階と、
前記デバイストリガメッセージを送信する前記第１のリクエストの前記優先度が高いときに、デバイストリガメッセージを送信する前記第１のリクエストを処理するようにモバイル管理エンティティに第２のリクエストを提示する段階と
を備える方法。
デバイストリガメッセージを送信する第１のリクエストを受信する段階と、
デバイストリガメッセージを送信する前記第１のリクエストを有効にする段階と、
前記デバイストリガメッセージが送信されるべきユーザ機器（ＵＥ）のステータス情報をリクエストする段階と、
前記ＵＥの前記ステータス情報を受信する段階と、
前記デバイストリガメッセージを送信する前記第１のリクエストの優先度を判断する段階と、
前記第１のリクエストの前記優先度が低いときには、
前記ＵＥが接続状態にあるときに前記デバイストリガメッセージを送信する段階と、
前記ＵＥがアイドル状態にあるときに前記デバイストリガメッセージをバッファする段階と
を備える方法。
前記方法は、ＭＴＣ‐ＩＷＦ（Machine Type Communication Interworking Function）によって実行される請求項２５又は２６に記載の方法。