JP5994869B2 - Ｍｔｃデバイス・トリガ配信の最適化 - Google Patents

Description

本発明は、ＭＴＣ(Ｍａｃｈｉｎｅ−Ｔｙｐｅ−Ｃｏｍｍｕｎｉｃａｔｉｏｎ)デバイス・トリガ配信に向けた効率的なメカニズムを提供するための、ＵＥ(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ)／ＭＴＣデバイス及びＭＴＣ−ＩＷＦ(ＭＴＣ−Ｉｎｔｅｒｗｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ)用の新たな機能に関する。

ＭＴＣデバイス・トリガリング(ｔｒｉｇｇｅｒｉｎｇ)は、３ＧＰＰ(Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)のＬＴＥ−Ａ(Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ−Ａｄｖａｎｃｅｄ)で定義される機能(ｆｅａｔｕｒｅ)である(例えば、非特許文献１を参照)。ＭＴＣデバイス・トリガリングは、ＳＣＳ(Ｓｅｒｖｉｃｅｓ Ｃａｐａｂｉｌｉｔｙ Ｓｅｒｖｅｒ)又はＳＭＥ(Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｅｎｔｉｔｉｅｓ)からネットワークへ送信され、ＭＴＣデバイスで終端される。ＭＴＣデバイス・トリガリングメッセージは、ＮＡＳ(Ｎｏｎ−Ａｃｃｅｓｓ−Ｓｔｒａｔｕｍ)メッセージ、ＳＭＳ(Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ)又はユーザプレーン(ｕｓｅｒ ｐｌａｎｅ)メッセージにおいて送信され得る。

ＭＴＣデバイス・トリガは、ＵＥでのセキュリティ保護チェックの失敗に因り、ＭＴＣデバイスへ到達しない虞がある。例えば、非特許文献２には、保護されていない幾つかのＮＡＳメッセージ(例えば、Ｉｄｅｎｔｉｔｙ Ｒｅｑｕｅｓｔ、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ、Ｄｅｔａｃｈ Ｒｅｑｕｅｓｔ等)がＵＥにより処理され得ることが記載されている。このようなＮＡＳメッセージに偽のＭＴＣデバイス・トリガが組み込まれた場合、ＭＴＣデバイスのバッテリ消費、及びＭＴＣデバイスの潜在的な不正動作／誤設定を引き起こし得る。

ＮＡＳメッセージのセキュア交換が確立されていない場合、ＵＥは、完全性チェック(ｉｎｔｅｇｒｉｔｙ ｃｈｅｃｋ)に通らないＮＡＳメッセージを廃棄する(例えば、非特許文献３を参照)。ＭＴＣデバイス・トリガがこのようなＮＡＳメッセージにて伝送され且つ廃棄される場合、ＳＣＳは、その旨を知見しないであろうし、同一のトリガを再送し得る。このことは、１）ネットワークへの過負荷、２）ＭＴＣデバイスのバッテリ消費を引き起こすであろう。他の例は、トリガがユーザプレーン上で送信される場合である。現行の３ＧＰＰのセキュリティメカニズムは、ユーザプレーンへの機密性(ｃｏｎｆｉｄｅｎｔｉａｌ)保護を要求している。トリガを搬送するユーザプレーンメッセージが適切に保護されない場合、同様の問題が検討されるべきである。

ＳＭＳ準拠(ｂａｓｅｄ)のトリガに対する問題も検討される。ＣＳＦＢ(ＣＳ(Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ) Ｆａｌｌ Ｂａｃｋ)が使用され且つＳＭＳトリガがＳＣＳから送信されるＬＴＥにおいて、ＭＴＣデバイスがＩＭＳ(ＩＰ(Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ) Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ)サポートであるか否かについての知見無しでは、ＭＴＣ−ＩＷＦが、メッセージをＭＭＥ(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ)へ転送し得て、そしてＭＭＥが、正しいルートが如何なるものであるか決定するであろう。例えば、ＵＥがＩＭＳサポートで無い場合、ＭＭＥは、ＳＭＳトリガをＭＳＣ(Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｒｅ)へ転送するであろう。

３ＧＰＰ ＴＳ ２３．６８２、"Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ ｆａｃｉｌｉｔａｔｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｗｉｔｈ ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋｓ ａｎｄ ａｐｐｌｉｃａｔｉｏｎｓ (Ｒｅｌｅａｓｅ １１)"、ｖ１１．１．０、２０１２年６月 ３ＧＰＰ ＴＳ ２４．３０１、"Ｎｏｎ−Ａｃｃｅｓｓ−Ｓｔｒａｔｕｍ (ＮＡＳ) ｐｒｏｔｏｃｏｌ ｆｏｒ Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ (ＥＰＳ)；Ｓｔａｇｅ ３ (Ｒｅｌｅａｓｅ １１)"、ｖ１１．２．１、２０１２年３月 ３ＧＰＰ ＴＲ ３３．８６８、"Ｓｅｃｕｒｉｔｙ ａｓｐｅｃｔｓ ｏｆ Ｍａｃｈｉｎｅ−Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ； (Ｒｅｌｅａｓｅ １１)"、ｖ０．８．０

トリガソース(例えば、ＳＣＳ又はＳＭＥ)が、３ＧＰＰネットワークドメインの外部に在るとする。ＭＴＣデバイス・トリガリングは、ＮＡＳメッセージ、ユーザプレーンメッセージ又はＳＭＳメッセージにて送信され得る。上記の背景技術に基づけば、解決すべき課題は下記１〜３を含む。
１．トリガを搬送する適切に保護されていないメッセージ(例えば、ＮＡＳメッセージ)を受信するためのソリューション
２．ネットワーク負荷及びＭＴＣデバイスのバッテリ消費を低減すること
３．ＭＴＣ−ＩＷＦによる、ＭＴＣデバイス・トリガの配信ルートに関する意思決定

現状、ＭＴＣデバイスは、ＮＡＳ保護を伴わないトリガ又はユーザプレーンメッセージを受信した場合、メッセージを廃棄するのみである。

ＭＴＣ−ＩＷＦに対し、ＭＴＣデバイス・ケイパビリティ、ＭＴＣデバイスのサービングノード(ｓｅｒｖｉｎｇ ｎｏｄｅ)情報及びトリガメッセージを記憶するといった要件は存在しない。

ＭＴＣ−ＩＷＦはトリガをサービングノードへ転送するのみであり、パス選択の最適化のためのメカニズムは存在しない。

上述した通り、現状は、ＭＴＣデバイスがＩＭＳをサポートしない場合、ＣＳＦＢをサポートするネットワークのために、ＭＭＥがＳＭＳトリガをＭＳＣへ転送し得る。しかしながら、本願の発明者らは、ＭＴＣ−ＩＷＦが早期段階で知見を有する場合、ＭＴＣ−ＩＷＦがＳＭＳトリガをＭＳＣへ直接転送するというより短いルートを取ることが可能である、ことを見出した。

従って、本発明の目的は、上述した課題に対するソリューションを提供し、以てＭＴＣデバイス・トリガを効率良く配信可能にすることにある。

上記の目的を達成するため、本発明の一態様は、第一に、保護されていないＮＡＳメッセージ又はユーザプレーンメッセージにて搬送されるＭＴＣデバイス・トリガリングを検討する。このようなメッセージがＭＴＣデバイス・トリガを搬送する場合、ＭＴＣデバイスは、トリガを廃棄し、Ｔｒｉｇｇｅｒ ＲｅｊｅｃｔメッセージをＭＴＣ−ＩＷＦ又はＧＧＳＮ(Ｇａｔｅｗａｙ ＧＰＲＳ(Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ) Ｓｕｐｐｏｒｔ Ｎｏｄｅ)／Ｐ−ＧＷ(ＰＤＮ(Ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋ) Ｇａｔｅｗａｙ)へ送信することが可能である。ＭＴＣ−ＩＷＦ又はＧＧＳＮ／Ｐ−ＧＷは、このトリガメッセージを保持し、ＮＡＳメッセージの場合にはＳＧＳＮ(Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ)、或いはユーザプレーンメッセージの場合にはＳ−ＧＷ(Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ)というように異なるパスを介して転送する。ＮＡＳメッセージの場合、ＭＴＣ−ＩＷＦは、代わりにＭＭＥ及びＳＧＳＮへセキュリティ状態を事前に問合せ、ＭＭＥが有効なセキュリティコンテキストを有している場合にのみ、トリガをＮＡＳメッセージに包含させることが可能である。ＭＴＣデバイス・トリガが配信されるルートは、ＭＴＣデバイス・トリガ配信の優先順位リスト(ｐｒｉｏｒｉｔｙ ｌｉｓｔ)によって決定することが可能である。優先順位は、ＵＥケイパビリティ及びサービングノード情報にとって決定できる。リストは、ＨＳＳ(Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ)又はＭＴＣ−ＩＷＦによって作成可能である。

ＳＭＳトリガが使用され且つＭＴＣデバイスがＩＭＳをサポートしない場合、ＭＴＣデバイス・ケイパビリティについての知見無しでは、ＭＭＥがＨＳＳにより現在のサービングノードであると示されているならば、ＭＴＣ−ＩＷＦは、依然としてＳＭＳトリガをＭＭＥへ転送し得る。ＭＭＥは、ＭＴＣデバイスがＩＭＳをサポートしない旨を見出した場合、トリガを、ＭＴＣデバイスへ到達させるべくＭＳＣへ転送するであろう。このことは、トリガ配信に遅延をもたらすであろう。ＭＴＣ−ＩＷＦが、幾つかのＭＴＣデバイス情報のためにＨＳＳへアクセス可能である一方で、ＩＭＳサポート可否のＭＴＣデバイス・ケイパビリティも要求することが提案される。ＭＴＣ−ＩＷＦは、ＳＭＳトリガを受信すると、自身のローカル記憶したＭＴＣデバイス・ケイパビリティをチェックし、ＭＴＣデバイスがＩＭＳをサポートしない場合、トリガをＭＳＣへ直接転送することが可能である。

本発明によれば、上述した課題の１以上を解決することが可能である。例えば、下記の効果１〜３の少なくとも一部又は一つを達成可能である。

１．トリガを転送するネットワークノード(ＭＴＣ−ＩＷＦ若しくはＧＧＳＮ／Ｐ−ＧＷ)又はトリガソースが、トリガ廃棄を知見することができる。ネットワークノード又はトリガソースはトリガを配信するための他のパスを発見でき、この結果、１）トリガがＭＴＣデバイスへ到達可能であり、２）トリガが同一パス上で再送されず、以て不要なネットワークトラヒックを低減可能であり、ＭＴＣデバイスのバッテリ消費は浪費されないであろう。
２．ＭＴＣ−ＩＷＦが早期段階でＭＴＣデバイス・トリガ配信のための正しいパスを決定でき、この結果、トリガ配信時間を短縮可能であり、ネットワークトラヒックは浪費されないであろう。
３．ＭＴＣデバイス・トリガ配信パスの優先順位リストがルート選択の最適化を提供し、この結果、ＭＴＣ−ＩＷＦは、早期段階で適切なルートを選択可能であろうし、トリガを異常パス(ｆａｉｌｅｄ ｐａｔｈ)へは送信しないであろう。

本発明の実施の形態に係るシステムアーキテクチャの例を示したブロック図である。 本発明の実施の形態に係るシステムにおけるメッセージシーケンス(ＮＡＳメッセージにて搬送されるトリガ)の例を示したシーケンス図である。 本発明の実施の形態に係るシステムにおいてコアネットワーク内に設置されるネットワークノードの構成例を示したブロック図である。 本発明の実施の形態に係るシステムにおけるＭＴＣデバイスの構成例を示したブロック図である。 本発明の実施の形態に係るシステムにおいてコアネットワーク外に設置されるネットワークノードの構成例を示したブロック図である。

以下、本発明の実施の形態を、図１〜図５を参照して説明する。

上述した通り、トリガメッセージがＮＡＳ上で送信される場合、非特許文献３には、ＮＡＳセキュリティ保護を伴わないトリガがＭＴＣデバイスにより廃棄されるべきと記載されている。トリガソース又はＭＴＣ−ＩＷＦ等のネットワークノードは、当該廃棄を知見しないであろうし、ＭＴＣデバイスにより再び廃棄され得る同一のトリガを、繰り返し再送するであろう。このことは、１）トリガがＭＴＣデバイスへ到達しない、２）ＭＴＣデバイス(ｐｏｗｅｒ ｓｅｎｓｉｔｉｖｅ)がバッテリを消費／浪費する、３）ネットワークトラヒックの浪費、といった幾つかの問題を引き起こし得る。

これらの問題に対処するため、図１に示すように、本実施の形態に係るシステムは、コアネットワーク(３ＧＰＰネットワーク)と、ＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)を介してコアネットワークへ接続する１以上のＭＴＣデバイス１０と、その各々がコアネットワーク外に設置されて、トリガメッセージの送信元として機能するＳＣＳ ３０及びＳＭＥ ４０と、を含む。

この内、各ＭＴＣデバイス１０は、Ｕｍ／Ｕｕ／ＬＴＥ−Ｕｕインタフェースを介したコアネットワークとのＭＴＣ通信のためのＵＥである。ＵＥは、１又は複数のＭＴＣアプリケーションをホスト(ｈｏｓｔ)することが可能である。対応する外部ネットワークにおけるＭＴＣアプリケーションは、１又は複数のＡＳ(Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒｓ)によりホストされる。

また、ＳＣＳ ３０及びＳＭＥ ４０は、コアネットワークへ接続して、ＭＴＣデバイス１０と通信する。

さらに、コアネットワークは、ＨＰＬＭＮ(Ｈｏｍｅ Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ)において、ＭＴＣ−ＩＷＦ ２１と、ＨＳＳ ２２と、ＧＧＳＮ／Ｐ−ＧＷ ２３とを含み、ＶＰＬＭＮ(Ｖｉｓｉｔｅｄ ＰＬＭＮ)において、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４と、Ｓ−ＧＷ ２５とを含む。コアネットワークにおいては、ＭＴＣ−ＩＷＦ ２１及びＧＧＳＮ／Ｐ−ＧＷ ２３の各々が、トリガメッセージをその送信元から受信するネットワークノードとして機能し、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４及びＳ−ＧＷ ２５の各々が、トリガメッセージをＭＴＣデバイス１０へ転送するネットワーク構成要素として機能し、ＨＳＳ ２２(又は、例えばＨＬＲ(Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ))が、ネットワークノードへ各種情報を提供するサーバとして機能する。大略、ＮＡＳメッセージの場合は、ＭＴＣ−ＩＷＦ ２１が、トリガメッセージを、Ｔｓｐインタフェースを介してＳＣＳ ３０から受信し、そしてＴ５ｂインタフェースを介してＭＭＥへ転送する。一方、ＳＭＳメッセージの場合には、ＭＴＣ−ＩＷＦ ２１が、トリガメッセージを、Ｔ４及びＴｓｍｓインタフェースを介して(すなわち、ＳＭＳ−ＳＣ／ＧＭＳＣ／ＩＷＭＳＣを介して)ＳＭＥ ３０から、或いはＴｓｐインタフェースを介してＳＣＳ ３０から受信し、そしてＴ５ｂ／Ｔ５ａ／Ｔ５ｃインタフェースを介してＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４へ転送する。よって、トリガメッセージは、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４によりＭＴＣデバイス１０へルーティングされ得る。ＨＳＳ ２２は、後述するＭＴＣデバイス・ケイパビリティ及びサービングノード情報を記憶し、これらをＳ６ｍインタフェースを介してＭＴＣ−ＩＷＦ ２１へ通知する。ＧＧＳＮ／Ｐ−ＧＷ ２３は、トリガメッセージを、ＳＣＳ ３０から或いはＧｉ／ＳＧｉインタフェースを介して直接ＡＳから受信し、そしてユーザプレーンを介してＳＧＳＮ又はＳ−ＧＷ ２５へ転送し、この結果、トリガメッセージがＭＴＣデバイス１０へルーティングされ得る。

次に、本実施の形態の動作例を、図２を参照して詳細に説明する。

本実施の形態においては、トリガソース(すなわち、ＳＣＳ ３０又はＳＭＥ ４０)がネットワークに対して適切に認証されているものとする(ステップＳ１)。ＭＴＣデバイス１０とネットワークとの間の相互認証も行われる。

（１）ＭＴＣデバイス・トリガ配信の最適化
１）ＭＴＣ−ＩＷＦ ２１は、ＵＥケイパビリティを、インタフェースＳ６ｍを介してＨＳＳ ２２からダウンロードする(ステップＳ２)。これは、新たなメッセージ、或いはＭＴＣ−ＩＷＦ ２１がＨＳＳ ２２からサービングノード情報を検索するのと同一のメッセージであり得る。ＵＥケイパビリティは、例えば、ＭＴＣデバイス１０がどの通信システム(例えば、ＳＡＥ(Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ)／ＬＴＥ又は３Ｇ)をサポートするかに関する情報を含み得る。好ましくは、下記（２）で後述される如く、ＵＥケイパビリティは、ＭＴＣデバイス１０がＩＭＳをサポートするか否かについての情報を含んでも良い。一方、サービングノード情報は、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４の使用率(ｕｓａｇｅ ｒａｔｅｓ)を含む。加えて、ルーティング情報が、ＨＳＳ ２２又はＨＬＲからダウンロードされ得る。ルーティング情報、サービングノード情報のデータは、ＨＳＳ／ＨＬＲからプッシュされるか若しくはダウンロードされ、ＳＭＳＣ／ＳＭＳ−ＧＭＳＣにローカル保存され得る。

ダウンロードは、下記（Ａ）、（Ｂ）の場合に生じ得る。
（Ａ）ＭＴＣ−ＩＷＦ ２１が最初のトリガを受信した場合、又は
（Ｂ）ＭＴＣデバイス１０がネットワークへアタッチし、ＨＳＳ ２２が情報をＭＴＣ−ＩＷＦ ２１へプッシュする場合

２）ＭＴＣ−ＩＷＦ ２１は、一定期間に亘り、ＵＥケイパビリティ及びサービングノード情報をローカルに記憶する(ステップＳ３)。

３）ＨＳＳ ２２又はＭＴＣ−ＩＷＦ ２１は、タイマ満了を以て、ＭＴＣデバイス・トリガ配信ルートの優先順位リストを作成する(ステップＳ４)。優先順位は、簡易なランダム選択であるか、又はネットワーク利用のオペレータポリシによって若しくはサービングノード情報及びＵＥケイパビリティに基づき決定され得る。サービングノード情報が使用率を含む場合を例に取ると、優先順位リストは、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４がその各々の使用率と対応付けて記憶されるレコードを含む。また、リストがＨＳＳ ２２により作成される場合、ＭＴＣ−ＩＷＦ ２１は、リストをＨＳＳ ２２からダウンロードする。ダウンロード及び／又は作成は、ＭＴＣ−ＩＷＦ ２１がトリガをＳＣＳ ３０から受信するより前に行われる。なお、リストは、ＭＴＣ−ＩＷＦ ２１がＭＴＣデバイス１０のデタッチを知らされた場合、又はその有効期限が切れた場合に削除されるべきである。

４）ＭＴＣ−ＩＷＦ ２１は、トリガをＳＣＳ ３０から受信する(ステップＳ５)。

５）ＭＴＣ−ＩＷＦ ２１は、ＳＣＳ ３０に対する認証を行って、ＳＣＳ ３０がトリガメッセージを送信可能か否か確かめる。

６）ＭＴＣ−ＩＷＦ ２１は、特定のネットワーク構成要素、例えばＭＭＥにおけるセキュリティコンテキストをチェックする(ステップＳ６及びＳ７)。このチェックは、次の（Ａ）、（Ｂ）によって成される。
（Ａ）情報のために特定のネットワーク構成要素の接続を確認すること(Ｐｉｎｇｉｎｇ)、若しくはＨＳＳから受信した情報を分析すること、又は
（Ｂ）ＭＴＣ−ＩＷＦ ２１がサービングノード情報をダウンロードした際にＨＳＳ ２２により提供された情報、又は例えばＵＥがその位置を変更した際にＨＳＳ ２２からプッシュされる情報を調べること

７）ＭＭＥがＵＥに対する有効なセキュリティコンテキストを有していない旨応答した場合、ＭＴＣ−ＩＷＦ ２１は、トリガメッセージを、優先順位リスト中の次のサービングノード、例えばＳＧＳＮへ送信するであろう(ステップＳ８及びＳ９)。そして、ＳＧＳＮが、トリガメッセージをＭＴＣデバイス１０へ転送する(ステップＳ１０)。ＭＴＣ−ＩＷＦ ２１は、同一ルートを選択しないことを保証すべきである。これにより、トリガメッセージが異常パスを介して冗長に再転送されることを防止でき、以てトリガメッセージをより迅速にＭＴＣデバイス１０へ到達させることが可能である。ルートは、ＭＴＣ−ＩＷＦ ２１が、ＨＳＳ ２２又はＭＭＥからセキュリティコンテキストが確立された旨の情報を受信した場合に有効化され得る。

このように、本実施の形態においては、リストに基づきトリガメッセージを転送すべきネットワーク構成要素を決定することによって、トリガメッセージをセキュアにＭＴＣデバイス１０へ到達可能にすることを保証できる。ＭＴＣ−ＩＷＦ ２１がリストを作成する場合には、有効パスを迅速に選択可能である。これは、ＭＴＣ−ＩＷＦ ２１がコアネットワークへのエントランス(ｅｎｔｒａｎｃｅ)として動作するためである。

また、リストが、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４がその各々の使用率と対応付けて記憶されるレコードを含む場合、ＭＴＣ−ＩＷＦ ２１は、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４を使用率の低い順に選択可能である。このため、コアネットワークの輻輳を低減できる。

８）ＵＥ(ＭＴＣデバイス１０)は、トリガを搬送するメッセージの妥当性をチェックする(これは、現行の３ＧＰＰ仕様のセキュリティ要件に従っている) (ステップＳ１１)。

９）メッセージが正しく検証されなかった場合、ＭＴＣデバイス１０は、トリガメッセージを廃棄し(ステップＳ１２)、拒否要因(ｒｅｊｅｃｔ ｃａｕｓｅ) (例えば、適切なセキュリティ保護無し)を示すＲｅｊｅｃｔメッセージを、ＭＴＣ−ＩＷＦ ２１へ送信する(ステップＳ１３)。それ以外の場合、ＭＴＣデバイス１０は、トリガを受け入れる。

１０）Ｒｅｊｅｃｔメッセージを受信した後、ＭＴＣ−ＩＷＦ ２１は、次のように動作する。
（Ａ）優先順位リストから無効とマークされていない次のパスを選択し、そして選択したパスを介してトリガを転送する(ステップＳ１４)
（Ｂ）利用可能なコントロールプレーンのパスが存在しない場合、ＭＴＣ−ＩＷＦ ２１は、ＲｅｊｅｃｔメッセージをＳＣＳ ３０へ転送し、以てＳＣＳ ３０がトリガをユーザプレーンを介して転送可能であるようにする(ステップＳ１５及びＳ１６)
（Ｃ）ＭＭＥへＡＫＡ(Ａｕｔｈｅｎｔｉｃａｔｉｏn ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ)及びＳＭＣ(Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｃｏｎｔｒｏｌ)手順の開始を要求して、ＭＭＥがトリガメッセージを転送可能なようにセキュリティコンテキストを確立する

このように、本実施の形態においては、Ｒｅｊｅｃｔメッセージを用いて、トリガメッセージが冗長に再転送されることも防止可能である。このため、コアネットワークの輻輳及びＭＴＣデバイス１０のバッテリ消費を低減可能である。例えば、緊急のトリガメッセージ等がＭＴＣデバイス１０へ到達することを保証できる。

図示を省略するが、ユーザプレーンに関しては、ＧＧＳＮ／Ｐ−ＧＷ ２３がＭＴＣ−ＩＷＦ ２１と同様の処理を行う。具体的には、ＧＧＳＮ／Ｐ−ＧＷ ２３は、ＭＴＣデバイス１０から、適切なユーザプレーンの機密性保護(ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ ｐｒｏｔｅｃｔｉｏｎ)が存在しない旨を示す要因を伴うＲｅｊｅｃｔメッセージを受信し、トリガを配信するための他のパスを発見する。例えば、ＳＧＳＮを介したパスが保護されていない場合、ＧＧＳＮ／Ｐ−ＧＷ ２３は、Ｓ−ＧＷ ２５を介した保護されたパスを選択して、トリガメッセージを転送する。

（２）非ＩＭＳサポートのＭＴＣデバイスのためのＳＭＳ準拠のトリガの検討
トリガメッセージがＳＭＳとして送信される場合、ＩＭＳをサポートしないＭＴＣデバイスも検討されるべきである。ＩＭＳをサポートしないＭＴＣデバイスに対するＮＡＳメッセージにて搬送されるＳＭＳトリガメッセージは、ＭＭＥがメッセージをＭＳＣへ転送するようにＣＳＦＢが開始され得る。このことは、不要なトラヒックを引き起こし、トリガ配信を遅延させる。

これらを回避するため、本実施の形態の動作は次のように行われる。

１）ＭＴＣ−ＩＷＦ ２１は、（１）で説明したように、ＨＳＳ ２２からＩＭＳサポートのＭＴＣデバイス・ケイパビリティをダウンロード可能である。ＳＭＳトリガを転送すべき場合、ＭＴＣ−ＩＷＦ ２１は、ローカル記憶した情報をチェックして、ＭＴＣデバイス１０がＩＭＳをサポートするか否かを確かめるべきである。

２）ＭＴＣデバイス１０がＩＭＳをサポートしない場合、ＭＴＣ−ＩＷＦ ２１は、トリガを、ＭＭＥでは無く、ＭＳＣへ直接転送すべきである。

このように、ＳＭＳトリガは、ＭＭＥを介さずにＭＭＣへ直接転送される。このため、ＭＭＥからＭＳＣへの不要なトラヒックが発生することを回避可能であり、以てＳＭＳトリガがＭＭＥ及びＭＳＣの両者を介した冗長なルーティングに因り遅延してしまうことを防止できる。

図３に示すように、ＭＴＣ−ＩＷＦ ２１は、記憶部２１１、選択部２１２、転送部２１３、受信部２１４、スイッチ部２１５、チェック部２１６、除外部２１７、及びダウンロード部２１８の少なくとも一部又は全てを含む。これらのユニット２１１〜２１８は、バス等を介して相互接続される。記憶部２１１は、優先順位リストを記憶する。選択部２１２は、優先順位リストに基づき、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４の一つを選択する。転送部２１３は、選択されたＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４の一つを介して、トリガメッセージをＭＴＣデバイス１０へ転送する。受信部２１４は、トリガメッセージをＳＣＳ ３０又はＳＭＥ ４０から受信し、選択されたＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４の一つを介して、ＲｅｊｅｃｔメッセージをＭＴＣデバイス１０から受信する。スイッチ部２１５は、Ｒｅｊｅｃｔメッセージが受信部２１４により受信された場合、転送部２１３に、トリガメッセージを、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４の他の一つを介して転送させる。チェック部２１６は、選択されたＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４の一つがトリガメッセージをＭＴＣデバイス１０へセキュアに転送可能か否かをチェックする。除外部２１７は、チェック部２１６により選択されたＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４の一つがトリガメッセージをセキュアに転送可能で無いと判定された場合、転送部２１３に対し、以降の転送に際して選択されたＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４の一つを除外するよう指示する。ダウンロード部２１８は、ＨＳＳ ２２から優先順位リストをダウンロードして、記憶部２１１に記憶させることが可能である。また、ダウンロード部２１８は、ＨＳＳ ２２から、ＭＴＣデバイス・ケイパビリティをダウンロードする。ＭＴＣデバイス・ケイパビリティが、ＭＴＣデバイス１０がＩＭＳをサポートしない旨を示す場合、転送部２１３は、トリガメッセージをＭＳＣへ直接転送する。

これらのユニット２１１〜２１８は、例えば、ＨＳＳ ２２、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ２４、ＳＣＳ ３０及びＳＭＥ ４０とそれぞれ通信するトランシーバと、これらのトランシーバを制御して、図２のステップＳ１〜Ｓ９及びＳ１３〜Ｓ１５に示した処理或いはこれと同等の処理を実行するコントローラと、で構成することが可能である。また、ＧＧＳＮ／Ｐ−ＧＷ ２３は、ユーザプレーンを介してＳＧＳＮ、Ｓ−ＧＷ ２５、ＳＣＳ ３０及びＡＳと通信する点を除き、ＭＴＣ−ＩＷＦ ２１と同様に構成することが可能である。

また、図４に示すように、ＭＴＣデバイス１０は、少なくとも、受信部１０１、検証部１０２及び伝送部１０３を含む。これらのユニット１０１〜１０３は、バス等を介して相互接続される。受信部１０２は、トリガメッセージをコアネットワークから受信する。検証部１０２は、トリガメッセージを検証する。伝送部１０３は、トリガメッセージが検証部１０２により検証されない場合、Ｒｅｊｅｃｔメッセージをコアネットワークへ送信する。これらのユニット１０１〜１０３は、例えば、ＲＡＮを介してコアネットワークと無線通信するトランシーバと、このトランシーバを制御して、図２のステップＳ１０〜Ｓ１３及びＳ１６に示した処理或いはこれと同等の処理を実行するコントローラと、で構成することが可能である。

さらに、図５に示すように、ＳＣＳ ３０は、少なくとも、伝送部３０１、受信部３０２及び送信部３０３を含む。これらのユニット３０１〜３０３は、バス等を介して相互接続される。伝送部３０１は、トリガメッセージを、コントロールプレーンを介してコアネットワークへ送信する(すなわち、トリガメッセージを、Ｔｓｐインタフェースを介してＭＴＣ−ＩＷＦ ２１へ送信する)。受信部３０２は、ＭＴＣ−ＩＷＦ ２１から、Ｒｅｊｅｃｔメッセージを受信する。送信部３０３は、Ｒｅｊｅｃｔメッセージが受信部３０２により受信された場合、トリガメッセージを、ユーザプレーンを介して送信する(すなわち、トリガメッセージを、Ｇｉ／ＳＧｉインタフェースを介してＧＧＳＮ／Ｐ−ＧＷ ２３へ送信する)。これらのユニット３０１〜３０３は、例えば、ＭＴＣ−ＩＷＦ ２１及びＧＧＳＮ／Ｐ−ＧＷ ２３とそれぞれ通信するトランシーバと、これらのトランシーバを制御して、図２のステップＳ１、Ｓ５、Ｓ１５及びＳ１６に示した処理或いはこれと同等の処理を実行するコントローラと、で構成することが可能である。また、ＳＭＥ ４０は、ＳＭＳ−ＳＣ／ＧＭＳＣ／ＩＷＭＳＣを介してトリガメッセージをＭＴＣ−ＩＷＦ ２１へ送信する点を除き、ＳＣＳ ３０と同様に構成することが可能である。

なお、本発明は、上記の実施の形態によって限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。

例えば、ＭＴＣ−ＩＷＦ ２１又はＧＧＳＮ／Ｐ−ＧＷ ２３は、トリガメッセージへの応答が所定期間内に受信されない場合に、トリガメッセージを他のネットワーク構成要素を介して転送しても良い。具体的には、受信部２１４が、ＭＴＣデバイス１０から応答を受信する。応答が受信部２１４により期間内に受信されない場合、スイッチ部２１５が、転送部２１３に、トリガメッセージを、選択されたネットワーク構成要素とは異なるネットワーク構成要素を介して転送させる。なお、期間は、タイマ、カウンタ等を用いて計測することが可能である。これにより、トリガメッセージがＭＴＣデバイス１０へ到達することも保証可能である。この場合には、ＭＴＣデバイス１０がＲｅｊｅｃｔメッセージを送信する必要が無いであろうから、上記の実施の形態と比して、ＭＴＣデバイス１０への改修を低減することが可能である。

上記の実施の形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

(付記１)
ＭＴＣ−ＩＷＦは、インタフェースＳ６ｍを介してＨＳＳから、例えばＭＴＣデバイスがＩＭＳをサポートするか否かを含むＭＴＣデバイス・ケイパビリティをダウンロードする(要求する、又はプッシュされる)。これは、新たなメッセージ、又はＭＴＣ−ＩＷＦがＭＴＣデバイス・サービングノード情報を検索するメッセージ中の新たなフィールドであり得る。

(付記２)
ＭＴＣデバイス・トリガ配信ルートの優先順位リスト。このリストは、ネットワーク利用のオペレータポリシに基づき、及び／又はＵＥケイパビリティによって作成される。リストは、ＨＳＳで作成してＭＴＣ−ＩＷＦへプッシュすること、又はＭＴＣ−ＩＷＦが必要な情報をＨＳＳからダウンロードした後に作成することが可能である。リストは、ＭＴＣ−ＩＷＦにローカル記憶され得る。

(付記３)
ＭＭＥがサービングノードである場合、ＭＴＣ−ＩＷＦは、ＭＭＥへ問合せして、ＭＭＥが有効なセキュリティコンテキストを有するか否かを発見する。ＭＭＥが有効なセキュリティコンテキストを有していない場合、ＭＴＣ−ＩＷＦは、配信ルートの優先順位に応じて、ＳＧＳＮ／ＭＳＣ等の他のエンティティへトリガを転送すべきである。

(付記４)
ＭＴＣデバイスは、保護されていないＮＡＳメッセージ又はユーザプレーンメッセージに組み込まれたトリガを受信した場合、要因インジケーションを伴うＴｒｉｇｇｅｒ Ｒｅｊｅｃｔメッセージを、ネットワークノード：ＭＴＣ−ＩＷＦ又はＧＧＳＮ／Ｐ−ＧＷへ送信する。

(付記５)
適切なＮＡＳ保護が存在しない旨を示す要因を伴うｒｅｊｅｃｔメッセージを受信したＭＴＣ−ＩＷＦは、トリガを配信するための他のパスを発見する。全てのコントロールプレーンのパスが利用可能で無い場合、ＭＴＣ−ＩＷＦは、ＡＫＡ及びＳＭＣ手順を開始し得る。ＭＴＣ−ＩＷＦは、ＲｅｊｅｃｔメッセージをＳＣＳへ転送し、以てＳＣＳがトリガメッセージをユーザプレーンを介して送信可能にし得る。

(付記６)
適切なユーザプレーンの機密性保護が存在しない旨を示す要因を伴うｒｅｊｅｃｔメッセージを受信したＧＧＳＮ／Ｐ−ＧＷは、トリガを配信するための他のパスを発見する。

２．ディスカッション
本書では、２つの問題が議論される。

１つめは、ＳＡ ＴＳ ２３．６８２がアーキテクチャにおけるローミングを検討することである。このケースでは、在圏網(ｖｉｓｉｔｅｄ ｎｅｔｗｏｒｋ)がＭＴＣデバイスにより信頼されていないかもしれないし、このようなネットワークから転送されたトリガは、信頼されるべきで無く且つ有効なものとして扱われるべきで無い。

よって、ＭＴＣデバイスは、次のように動作すべきである。
−ＭＴＣデバイスと通信するＭＴＣ−ＩＷＦが承認されたものであるか否かを検証する。
−トリガが承認されたＭＴＣ−ＩＷＦからのものであるか否かを検証可能である。トリガが無効なＭＴＣ−ＩＷＦからのものである場合、ＭＴＣデバイスは、ＭＭＥがＭＴＣ−ＩＷＦとの通信を中断し且つ更なるアクションを取り得るよう、ＭＭＥへの通知を行うべきである。

２つめは、ＭＴＣデバイスが、ＮＡＳ完全性保護を伴わないトリガを受信した場合に、(ＴＲ ３３．８６８に記載の如く)“トリガを廃棄するか、或いはエンド・トゥ・エンド(ｅｎｄ−ｔｏ−ｅｎｄ)保護が適用されていたならばトリガをより深く検証し得る”ことである。

次の幾つかの事項を検討する。
−トリガが受信不可能であり、ＭＴＣサーバ又はＭＴＣユーザは廃棄について知見しない。
−ＭＭＥが受信されないであろうトリガを送信する場合、ネットワークトラヒック及びＭＴＣデバイスのバッテリを浪費させる。

上述した問題を解決するため、
−ＭＭＥは、そもそも、保護無しでトリガを送信すべきでない
−このようなトリガを受信した場合、ＭＴＣデバイスは、拒否要因を伴うＲｅｊｅｃｔメッセージをＭＭＥ／ＭＴＣ−ＩＷＦ／ＳＣＳへ送信して、ネットワークがこれに応じたアクションを講じられるようにすべきである
−ＭＭＥは、ＡＫＡ手順を開始して、セキュリティコンテキストを確立可能である
−ＭＴＣ−ＩＷＦは、トリガを、例えばＳＧＳＮ等の他のパスから(すなわち、他のネットワークノードを介して)送信可能である。これは、オペレータポリシ及び／又はＭＴＣデバイス・ケイパビリティに応じ得る。

上記の議論に基づき、ＴＲ ３３．８６８に対し以下の変更を提案する。

ソリューション１：ＮＡＳシグナリングを介したトリガリング
現在ＳＡ２ ＴＲ ２３．８８８ [１０]で検討されている主たるデバイス・トリガリングメカニズムは、ＮＡＳシグナリングを介したトリガリング(例えば、既存のＮＡＳメッセージ中の新たな情報要素、若しくは新たなＮＡＳメッセージ)、及びＳＭＳを介したトリガリングである。場合により、ＳＭＳトリガは、ネットワークからＭＴＣデバイスへトランスポート(ｔｒａｎｓｐｏｒｔ)としてのＮＡＳを用いて送信されても良い。この場合、現行のＮＡＳセキュリティメカニズムを、セキィリティ問題を解決するめに利用することが可能である。ＮＡＳ ＳＭＣの後、ＮＡＳセキュリティがアクティブ化される。ＴＳ ３３．４０１ [１３]に従って全てのＮＡＳシグナリングメッセージの完全性が保護されるべきであるため、現行のＬＴＥセキィリティメカニズムは、トリガインジケーションが改ざんされないことを保証する。この場合、ＳＭＳトリガは、ＬＴＥにおけるＮＡＳシグナリングの完全性保護の恩恵を受けるであろう。

ソース検証が検討される必要がある。本コンテキストでは、ＭＴＣデバイスが、トリガのソースが有効なＭＴＣサーバであることを検証可能であることを意味すると考えられる。これは、以下のような方法で達成され得る。

ＭＴＣデバイスは、ＮＡＳ完全性保護されたトリガを送信する３ＧＰＰネットワークを信頼する。この場合、ＭＴＣデバイスは、信頼された３ＧＰＰネットワークの識別子(ｉｄｅｎｔｉｔｉｅｓ)を用いて設定される(信頼された非３ＧＰＰアクセスネットワークに幾分類似したものがＴＳ ３３．４０２におけるＵＥにて設定され得る)。本コンテキストにおいて、信頼された３ＧＰＰネットワークとは、ＭＴＣサーバから３ＧＰＰネットワークへのセキュア化されたインタフェースを有し、且つ承認されたＭＴＣサーバから受信したトリガインジケーションのみが当該ＭＴＣサーバに“属する”ＭＴＣデバイスのトリガリングを引き起こすことを保証すると考えられる、ネットワークを意味し得る。

ネットワークは、例えばＭＴＣデバイスが在圏網に存在する場合や、ＭＴＣに対する厳格なセキュリティ要件が存在する場合には、信頼されないかもしれない。ＭＴＣデバイスは、トリガが有効なＭＴＣ−ＩＷＦから転送されたか否かを検証すべきである。

そして、ＭＴＣデバイスは、ＮＡＳ完全性保護されたトリガを受信すると、ＮＡＳ完全性保護を検証した後に、上述した意味で３ＧＰＰネットワークを検証し得る。両者が検証された場合、トリガが受け入れられ得る。

ＭＭＥは、トリガを、完全性保護を伴わないＮＡＳメッセージにて送信すべきで無い。トリガのＮＡＳ完全性保護が存在しない場合、又は３ＧＧＰネットワークが信頼されない場合、ＭＴＣデバイスは、トリガを廃棄し、適切な要因を伴うＲｅｊｅｃｔメッセージをＭＭＥ及びＭＴＣ−ＩＷＦへ送信するか、或いはエンド・トゥ・エンド保護が適用されていたならばトリガをより深く検証し得る。

ＭＭＥは、ＭＴＣデバイスから、完全性保護が存在しないこと又は完全性チェックが失敗した旨を示すｒｅｊｅｃｔ応答を受信した場合、次のように動作し得る。
−ＭＴＣデバイスに向けた３ＧＰＰ ＡＫＡ手順を開始する。この結果、ＭＭＥとＭＴＣデバイスの間でセキュリティコンテキストが共有される場合には、ＭＭＥは、トリガを転送することが可能である。
−又は、ｒｅｊｅｃｔメッセージをＭＴＣ−ＩＷＦへ転送する。この結果、ＭＴＣ−ＩＷＦは、トリガを送信するための他のルートを選択することが可能である。

この出願は、２０１２年６月２９日に出願された日本出願特願２０１２−１４７９８２、及び２０１２年９月２４日に出願された日本出願特願２０１２−２０９３９３を基礎とする優先権を主張し、これらの開示の全てをここに取り込む。

１０ ＭＴＣデバイス
２１ ＭＴＣ−ＩＷＦ
２２ ＨＳＳ
２３ ＧＧＳＮ／Ｐ−ＧＷ
２４ ＭＭＥ／ＳＧＳＮ／ＭＳＣ
２５ Ｓ−ＧＷ
３０ ＳＣＳ
４０ ＳＭＥ
１０１, ２１４, ３０２ 受信部
１０２ 検証部
１０３, ３０１ 伝送部
２１１ 記憶部
２１２ 選択部
２１３ 転送部
２１５ スイッチ部
２１６ チェック部
２１７ 除外部
２１８ ダウンロード部
３０３ 送信部

Claims (14)

1. コアネットワーク内に設置されるネットワークノードであって、
   前記コアネットワーク外に設置される送信元から受信したトリガメッセージを、前記コアネットワークへアタッチしたＭＴＣ（Ｍａｃｈｉｎｅ−Ｔｙｐｅ−Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイスへ転送することが可能な、ネットワーク構成要素（ｎｅｔｗｏｒｋ ｅｌｅｍｅｎｔｓ）のリストを記憶する記憶手段と、
   前記リストに基づき、パスが無効とマークされていない第一のネットワーク構成要素を選択して、前記トリガメッセージを前記ＭＴＣデバイスへセキュアに転送する選択手段と、
   を備え、
   前記選択手段は、前記ＭＴＣデバイスから、前記トリガメッセージが前記ＭＴＣデバイスにより受け入れられない旨を示すリジェクトメッセージを受信した場合、
   前記リストに基づき、パスが無効とマークされていない第二のネットワーク構成要素を選択して、前記トリガメッセージを前記ＭＴＣデバイスへセキュアに転送する、
   ネットワークノード。
2. 請求項１記載のネットワークノードにおいて、
   前記記憶手段は、前記ネットワーク構成要素の情報をサーバからダウンロードし、前記ダウンロードした情報を用いて前記リストを作成し、
   前記ダウンロード及び作成は、前記トリガメッセージの受信に先立って行われる、
   ことを特徴としたネットワークノード。
3. 請求項１記載のネットワークノードにおいて、
   前記リストは、サーバにより、前記ネットワーク構成要素の情報に基づき作成され、
   前記記憶手段は、前記サーバから前記リストをダウンロードし、
   前記ダウンロードは、前記トリガメッセージの受信に先立って行われる、
   ことを特徴としたネットワークノード。
4. 請求項１〜３のいずれか一項に記載のネットワークノードにおいて、
   前記リストには、前記ネットワーク構成要素が、前記ネットワーク構成要素各々の使用率と対応付けて記憶され、
   前記選択手段は、前記第一のネットワーク構成要素として、前記ネットワーク構成要素を利用率の低い順に選択する、
   ことを特徴としたネットワークノード。
5. 請求項１〜４のいずれか一項に記載のネットワークノードにおいて、
   前記選択手段は、前記第一のネットワーク構成要素が前記トリガメッセージを前記ＭＴＣデバイスへセキュアに転送できるか否かを、前記第一のネットワーク構成要素の接続を確認すること（ｐｉｎｇｉｎｇ）又はサーバから受信した前記第一のネットワーク構成要素に関する情報を分析することにより、チェックする、
   ことを特徴としたネットワークノード。
6. 請求項１〜５のいずれか一項に記載のネットワークノードにおいて、
   ＭＴＣ−ＩＷＦ（ＭＴＣ−Ｉｎｔｅｒｗｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ）、ＧＧＳＮ（Ｇａｔｅｗａｙ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔ Ｎｏｄｅ）、又はＰ−ＧＷ（ＰＤＮ（Ｐａｃｋｅｔ ｄａｔｅ ｎｅｔｗｏｒｋ） Ｇａｔｅｗａｙ）である、
   ことを特徴としたネットワークノード。
7. コアネットワークへアタッチするＭＴＣ（Ｍａｃｈｉｎｅ−Ｔｙｐｅ−Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイスであって、
   請求項１〜６のいずれか一項に記載のネットワークノードにより転送されるトリガメッセージを、受信する、
   ＭＴＣデバイス。
8. コアネットワーク外に設置されるネットワークノードであって、
   トリガメッセージを、請求項１〜６のいずれか一項に記載のネットワークノードへ送信する、
   ネットワークノード。
9. 請求項８記載のネットワークノードにおいて、
   ＳＣＳ（Ｓｅｒｖｉｃｅｓ Ｃａｐａｂｉｌｉｔｙ Ｓｅｒｖｅｒ）、又はＳＭＥ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｅｎｔｉｔｙ）である、
   ことを特徴としたネットワークノード。
10. コアネットワーク内に設置されるネットワークノードであり、且つ前記コアネットワーク外に設置される送信元から受信したトリガメッセージを、前記コアネットワークへアタッチしたＭＴＣ（Ｍａｃｈｉｎｅ−Ｔｙｐｅ−Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイスへ転送するネットワークノードを制御する方法であって、
    前記トリガメッセージを前記ＭＴＣデバイスへ転送することが可能なネットワーク構成要素（ｎｅｔｗｏｒｋ ｅｌｅｍｅｎｔｓ）のリストを記憶し、
    前記リストに基づき、パスが無効とマークされていない第一のネットワーク構成要素を選択して、前記トリガメッセージを前記ＭＴＣデバイスへセキュアに転送し、
    前記ＭＴＣデバイスから、前記トリガメッセージが前記ＭＴＣデバイスにより受け入れられない旨を示すリジェクトメッセージを受信した場合、
    前記リストに基づき、パスが無効とマークされていない第二のネットワーク構成要素を選択して、前記トリガメッセージを前記ＭＴＣデバイスへセキュアに転送する、
    ことを含む方法。
11. 請求項１０記載の方法において、
    前記ネットワーク構成要素の情報をサーバからダウンロードし、
    前記ダウンロードした情報を用いて前記リストを作成する、ことをさらに含み、
    前記ダウンロード及び作成は、前記トリガメッセージの受信に先立って行われる、
    ことを特徴とした方法。
12. 請求項１０記載の方法において、
    サーバから、前記サーバにより前記ネットワーク構成要素の情報に基づき作成された前記リストをダウンロードする、ことをさらに含み、
    前記ダウンロードは、前記トリガメッセージの受信に先立って行われる、
    ことを特徴とした方法。
13. 請求項１０〜１２のいずれか一項に記載の方法において、
    前記リストには、前記ネットワーク構成要素が、前記ネットワーク構成要素各々の使用率と対応付けて記憶され、
    前記選択は、前記第一のネットワーク構成要素として、前記ネットワーク構成要素を利用率の低い順に選択することにより行われる、
    ことを特徴とした方法。
14. 請求項１０〜１３のいずれか一項に記載の方法において、
    前記選択は、前記第一のネットワーク構成要素が前記トリガメッセージを前記ＭＴＣデバイスへセキュアに転送できるか否かを、前記第一のネットワーク構成要素の接続を確認すること（ｐｉｎｇｉｎｇ）又はサーバから受信した前記第一のネットワーク構成要素に関する情報を分析することによりチェックする、ことを含む、
    ことを特徴とした方法。

Images