(57)【要約】【課題】ＭＴＣデバイストリガリングのセキュアな配送、ネットワーク及びＭＴＣサーバからＭＴＣデバイスへのトリガリングの再送等の障害処理(ｆａｉｌｕｒｅ ｈａｎｄｌｉｎｇ)を含むＭＴＣデバイスのためのセキュアな手段【解決手段】ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）と、ネットワークノードとを含むモバイル通信システムにおけるサーバは、複数の異なるデバイストリガのトリガ種別を示すトリガメッセージをネットワークノードに送信する送信手段と、サーバがトリガ種別に従ってトリガメッセージを送信することを承認されているかネットワークノードにより検証を受ける検証手段と、検証が成功した場合に、ＵＥにトリガメッセージを配信する配信手段と、を有する。【選択図】図１
2020025304.tif 000002
【特許請求の範囲】
【請求項１】
ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）と、ネットワークノードとを含むモバイル通信システムにおけるサーバであって、
複数の異なるデバイストリガのトリガ種別を示すトリガメッセージを前記ネットワークノードに送信する送信手段と、
前記サーバが前記トリガ種別に従って前記トリガメッセージを送信することを承認されているか前記ネットワークノードにより検証を受ける検証手段と、
前記検証が成功した場合に、前記ＵＥをトリガするトリガ手段と、
を有するサーバ。
【請求項２】
前記トリガメッセージは、前記ＵＥのＩＤと、前記サーバのＩＤとを含む、
請求項１記載のサーバ。
【請求項３】
ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）と、ネットワークノードを含むモバイル通信システムにおけるサーバの通信方法であって、
複数の異なるデバイストリガのトリガ種別を示すトリガメッセージを前記ネットワークノードに送信し、
前記サーバが前記トリガ種別に従って前記トリガメッセージを送信することを承認されているか前記ネットワークノードにより検証を受け、
前記検証が成功した場合に、前記ＵＥをトリガする、
サーバの通信方法。
【請求項４】
前記トリガメッセージは、前記ＵＥのＩＤと、前記サーバのＩＤとを含む、
請求項３記載のサーバの通信方法。
【請求項５】
ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）と、サーバとを含むモバイル通信システムにおけるネットワークノードであって、
複数の異なるデバイストリガのトリガ種別を示すトリガメッセージを前記サーバから受信する受信手段と、
前記サーバが前記トリガ種別に従って前記トリガメッセージを送信することを承認されているか検証する検証手段と、を有し、
前記検証が成功した場合に、前記ＵＥは前記サーバからトリガされる
ネットワークノード。
【請求項６】
前記トリガメッセージは、前記ＵＥのＩＤと、前記サーバのＩＤとを含む、
請求項５記載のネットワークノード。
【請求項７】
ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）と、サーバとを含むモバイル通信システムにおけるネットワークノードの通信方法であって、
複数の異なるデバイストリガのトリガ種別を示すトリガメッセージを前記サーバから受信するステップと、
前記サーバが前記トリガ種別に従って前記トリガメッセージを送信することを承認されているか検証するステップと、を有し、
前記検証が成功した場合に、前記ＵＥは前記サーバからトリガされる、
ネットワークノードの通信方法。
【請求項８】
前記トリガメッセージは、前記ＵＥのＩＤと、前記サーバのＩＤとを含む、
請求項７記載のネットワークノードの通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、承認されたＭＴＣ(Ｍａｃｈｉｎｅ−Ｔｙｐｅ−Ｃｏｍｍｕｎｉｃａｔｉｏｎ)デバイストリガリング(ｔｒｉｇｇｅｒｉｎｇ)のセキュアな配送、ネットワーク及びＭＴＣサーバからＭＴＣデバイスへのトリガリングの再送等の障害処理(ｆａｉｌｕｒｅ ｈａｎｄｌｉｎｇ)を含むＭＴＣデバイスのためのセキュアな手段、並びにデタッチした(所謂、オフラインな)ＭＴＣデバイスをトリガする方法に関する。
【背景技術】
【０００２】
非特許文献１に記載される如く、ＭＴＣデバイストリガリングは、３ＧＰＰ(Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)のＬＴＥ−Ａ(Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ−Ａｄｖａｎｃｅｄ)で定義される特徴の一つである。ＭＴＣデバイストリガリングは、ＭＴＣサーバによりネットワークに対して開始され、ＭＴＣデバイスで終端される。ＭＴＣサーバは、３ＧＰＰネットワークドメインの内部又は外部に存在し得る。悪徳なＭＴＣサーバは、多数のＭＴＣデバイストリガリングメッセージを送信して、ネットワークへ過剰な負荷を掛け得る。また、ＭＴＣデバイスが非承認のトリガリングへ応答した場合、バッテリ消費、悪徳なＭＴＣサーバへのデータ送信、及びＭＴＣデバイスの潜在的な誤動作／誤設定を引き起こすであろう。このため、承認されたＭＴＣサーバからの正当なトリガリングのみがＭＴＣデバイスへ送信されるべきである。よって、ＭＴＣサーバは、３ＧＰＰネットワーク及びＭＴＣデバイスとのセキュアな接続を確立して、これらの間におけるエンド・ツー・エンドなセキュリティを有することが可能でなければならない。一方、悪徳なＵＥ(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔｓ)又はＭＴＣデバイスがトリガリングへ応答することも可能であり、このことは、承認されたデバイスのみにトリガリングへの応答を許可するか、或いはデバイス承認をチェックするためのソリューションを開発することによって防止されるべきである。
【０００３】
また、ＭＴＣデバイストリガリングは、ネットワーク障害等の問題に因り、ターゲットとなるＭＴＣデバイスで受信されない虞もある。トラヒックを低減するために、ＭＴＣサーバ及びネットワークの両者がトリガリングを再送可能なべきである。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】３ＧＰＰ ＴＲ ２３．８８８、“Ｓｙｓｔｅｍ Ｉｍｐｒｏｖｅｍｅｎｔｓ ｆｏｒ Ｍａｃｈｉｎｅ−Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎs； (Ｒｅｌｅａｓｅ １１)”、Ｖ１．４．０、２０１１年８月
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＭＴＣサーバと３ＧＰＰネットワークが相互に認証されるものとすると、上記の背景技術に基づけば、解決すべき課題は以下の１〜７である。
１．ネットワークは、ＭＴＣサーバからのメッセージを承認し、トリガを検証可能なべきである。これは、ＭＴＣサーバの非承認の動作を防止するためである。
２．ネットワークは、異なるトリガの種別を識別可能であり、以てトリガが、承認されたＭＴＣデバイスのみへ、これらの契約に基づいて送信されるようにすべきである。
３．トリガからのネットワーク輻輳インパクトが回避されるべきである。
４．ＭＴＣデバイスは、非承認のＭＴＣサーバ及びメッセージからのアタック又はＭＴＣデバイスへのインパクトを防止するよう、トリガ及びその送信元を検証可能なべきである。
５．トリガの鮮度及びライフタイムに係るソリューションが、リプレイアタック及びトリガの再送に因るネットワーク負荷を防止するように存在すべきである。
６．トリガのアグリゲーション及びセキュリティが、ネットワークにおけるトラヒックを低減するように検討されるべきである。
７．その他の問題を回避するために、ソリューションは、トリガ送信のリトライ及びＭＴＣユーザへの通知を含む障害処理を考慮可能なべきである。
【課題を解決するための手段】
【０００６】
本発明の態様では、ＭＴＣサーバにより３ＧＰＰネットワークを介して示されるＭＴＣデバイストリガリングを検討する。ＭＴＣサーバは３ＧＰＰネットワーク外に存在可能であり、特定且つ承認されたＭＴＣサーバからの承認されたトリガリングのみがＭＴＣデバイスへ示されるであろう。同様にして、認証且つ承認されたＭＴＣデバイスのみが、正当なトリガリングへの応答を許可されるであろう。ネットワーク及びＭＴＣデバイスの両者が、ＭＴＣサーバ及びこれからのトリガを承認可能であろう。
【０００７】
３ＧＰＰネットワークドメイン外のＭＴＣサーバは、例えば３ＧＰＰネットワークとのセキュアな通信が存在する場合であっても、ＭＴＣデバイスとのセキュアな接続を確立することを要求される。トリガリングコンテンツは保護され、ＭＴＣデバイスはトリガを検証可能であろう。ここで、検証手段は、メッセージの完全性、トリガの送信元、メッセージがライフタイム内にリプレイされたか否か、及びトリガがＭＴＣデバイスにとってアクションを起こすべき種別のものであるか否かをチェック可能である。ＭＴＣデバイスは、承認されたＭＴＣサーバのリストを配備しても良く、トリガリングの受信に際し、リストに応じた検証を行うことが可能である。不当に送信されたトリガの受信を防止するため、ネットワークは、トリガ種別を識別可能であろう。
【０００８】
トリガリングメッセージは、アタッカーによって後に単純にコピーされたり再利用されたりしないよう、ライフタイムを有していても良い。ネットワーク障害又はその他に際して、ＭＴＣサーバは、トリガリングメッセージを再送可能である。同様に、ネットワークは、トリガライフタイム内でＭＴＣデバイスへの再送が可能である。ＭＴＣサーバ及びネットワークの両者が、トリガのリプレイアタックを防止するソリューションを提供する。
【０００９】
ＭＴＣデバイスは、エネルギー節約のためにデタッチ状態(所謂、オフライン)に在り得る。ネットワークは、ＭＴＣデバイスへ、アタッチのためのタイマを、ＭＴＣデバイスに対するＤｅｔａｃｈ Ａｃｃｅｐｔ又はＤｅｔａｃｈ Ａｃｃｅｐｔにおいて送信可能である。よって、ネットワークは、ＭＴＣサーバからＭＴＣデバイストリガリングを受信すると、タイマの有効性をチェック可能である。タイマが有効である場合、ネットワークは、トリガリングを保持し、ＭＴＣデバイスのアタッチを待機するであろう。タイマが有効で無い場合、ネットワークは、ＭＴＣデバイスがアタッチしている(所謂、オンラインの)場合と同様にして、トリガリングを送信可能である。タイマは、契約上で定義されるか、或いはＭＴＣサーバによりネットワークへ伝えることも可能である。
【発明の効果】
【００１０】
本発明によれば、無効なトリガリングメッセージの送信を防止することにより、不要なネットワークトラヒックを低減し、ＭＴＣデバイスのバッテリ浪費を低減することが可能である。
【００１１】
トリガリングに係るＭＴＣサーバ及びＭＴＣデバイスの承認は、悪徳なＭＴＣサーバ、若しくはＭＴＣデバイスへトリガすることを承認されていないＭＴＣサーバからの無効なトリガリングメッセージがＭＴＣデバイスへ送信されること、又はトリガリングへの応答を承認されていないＭＴＣデバイスへ送信されることを防止するであろう。
【００１２】
一のソリューションは、ＭＴＣデバイスに周期的なＡｔｔａｃｈ Ｒｅｑｕｅｓｔを行わせて、ＭＴＣデバイスへ送信されるトリガリングが存在するかチェックさせるものであり得る。しかしながら、このソリューションは、不要なバッテリ消費及びトラヒックを招く。ＭＴＣサーバは、ＭＴＣデバイスへいつトリガするか知っているならば、トリガ頻度に応じて、ＭＴＣデバイスにネットワークへアタッチさせるか或いはアイドルに留めさせることが可能である。
【００１３】
ネットワークからＭＴＣデバイスへのトリガリング送信のセキュアなリトライは、ＭＴＣサーバへの干渉及びトリガリングメッセージの悪用を防止するであろう。
【００１４】
デタッチしている(オフライン)ＭＴＣデバイスは、必ずしも、ネットワークがトリガリングメッセージを受信すると直ちにトリガされるべきでは無い。しかしながら、ネットワークは、緊急状態、及びネットワークがＭＴＣデバイスへ割り当てたアタッチ用タイマの有効性に応じて、いつトリガリングメッセージを送信すべきか判定可能である。
【００１５】
トリガは、ＭＴＣサーバ、トリガメッセージの承認、並びにメッセージの完全性及び機密性保護を行うことにより、ＭＴＣデバイスへセキュアに配送される。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施の形態１に係るシステムの構成例を示したブロック図である。
【図２】実施の形態１に係るシステムにおける第１の動作例を示したシーケンス図である。
【図３】実施の形態１に係るシステムにおける第２の動作例を示したシーケンス図である。
【図４】実施の形態１に係るシステムにおける第３の動作例を示したシーケンス図である。
【図５】本発明の実施の形態２に係るシステムの構成例を示したブロック図である。
【図６】実施の形態２に係るシステムにおける第１の動作例を示したシーケンス図である。
【図７】実施の形態２に係るシステムにおける第２の動作例を示したシーケンス図である。
【図８】実施の形態２に係るシステムにおける第３の動作例を示したシーケンス図である。
【図９】実施の形態に係るノードの構成例を示したブロック図である。
【図１０】実施の形態に係るノードの他の構成例を示したブロック図である。
【図１１】実施の形態に係るＭＴＣサーバの構成例を示したブロック図である。
【図１２】実施の形態に係るＭＴＣデバイスの構成例を示したブロック図である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施の形態１及び２を説明する。
【００１８】
[実施の形態１]
図１に示すように、本実施の形態に係るシステムは、３ＧＰＰネットワーク１０と、ＭＴＣサーバ２０と、ＭＴＣデバイス３０とを含む。
【００１９】
本願の発明者らは、このようなシステムにおいて、例えば次の脅威がＭＴＣデバイストリガリングに対して特定されることを見出した。
【００２０】
＜脅威＞
ネットワークは、ＭＴＣサーバから送信されるトリガインジケーション(以下、このインジケーションを“トリガリングメッセージ”と呼称することがある)に基づき、ＭＴＣデバイスをトリガして、ＭＴＣサーバとの通信を開始させる。このことは、特にＭＴＣサーバが図１に示す如くオペレータドメインの外部に存在する場合に、アタッカーにとっての機会を広げるであろう。
【００２１】
アタッカーは、ＭＴＣサーバになりすまして偽りのトリガインジケーションをネットワークへ送信し得て、ネットワークがアタッカーにより対応ＭＴＣデバイスをトリガするために利用される。このことは、多数のＭＴＣデバイスがトリガされて同時に認証が要求される程に、ＭＴＣデバイスの電力浪費に繋がり得るＭＴＣデバイスの誤判定を引き起こし、ネットワークに対するＤＯＳアタックすら引き起こすであろう。よって、アタッカーは、このことを巧みに操って、そのアタック目標を達成し得る。
【００２２】
ＭＴＣサーバは、うかつにも例えばソフトウェアアップデータのためにＭＴＣデバイスをトリガしてＭＴＣデバイスへ重大な被害を及ぼし得るから、ＭＴＣデバイスに対する完全な制御権を有していないであろう。
【００２３】
アタッカーは、外部インタフェース上で、ＭＴＣデバイス識別子等のプライバシーな機密情報を盗聴し得る。
【００２４】
これらの脅威に対処するため、特にＭＴＣサーバが３ＧＰＰオペレータドメインの外部に設定される場合には、次のセキュリティ要件を適用する。
【００２５】
＜セキュリティ要件＞
３ＧＰＰネットワークは、(１)ＭＴＣサーバがＭＴＣデバイスと通信することを承認されているか否か、及び(２)ＭＴＣサーバが特定のＭＴＣデバイスへ特定のトリガを送信することを承認されているか否かを判定可能なべきである。
【００２６】
これらのセキュリティ要件を満たすソリューションを、主要論点として説明する。
【００２７】
＜ソリューション＞
３ＧＰＰネットワークは、特定のＭＴＣデバイスへのトリガ送信を承認されたＭＴＣサーバ、及び当該ＭＴＣサーバが送信を承認されたトリガの種別のリストを維持すべきである。このリストは、ＭＴＣデバイスの識別子、ＭＴＣサーバの識別子、及び関連する許可されたトリガリングを含むべきである。このように、トリガ毎に、３ＧＰＰネットワークは、ＭＴＣサーバがトリガ送信を許可されているか否か及びトリガが承認されているか否かを検証する。
【００２８】
次に、本実施の形態の詳細を説明する。
【００２９】
本実施の形態は、３つの主たる課題を考慮に入れる。
Ｉ．承認されたＭＴＣデバイストリガリングのセキュアな配送
ＩＩ．障害処理：ネットワーク及びＭＴＣサーバからＭＴＣデバイスへのトリガリング送信のリトライ
ＩＩＩ．デタッチした(オフライン)ＭＴＣデバイスをトリガすること
【００３０】
次の通り、幾つかの前提を立てる。
１．ＭＴＣサーバは３ＧＰＰドメインネットワークの内／外に存在する。
２．ＭＴＣデバイス及びネットワークは相互認証を有する。
３．ＭＴＣサーバ及びネットワークは相互認証を有する。
【００３１】
Ｉ(ＭＴＣデバイストリガリングのセキュアな配送)を達成するため、トリガメッセージは、完全性を有するべきであり、機密性が保護され得る。ネットワークは、トリガの完全性及び機密性チェックを行う。
【００３２】
そして、ネットワークは、ＭＴＣサーバの承認を行う。ネットワークは、ＭＴＣデバイスＩＤ(ｉｄｅｎｔｉｔｙ)、ＭＴＣサーバＩＤ及び関連する加入者(契約)情報を含むリストを伴って配備される。ＭＴＣサーバは、ターゲットＭＴＣデバイスＩＤ、ＭＴＣサーバＩＤ、及びオプションとして加入者ＩＤを含むトリガリングを送信するであろう。ネットワークは、トリガリングを受信すると、リストに応じてＭＴＣサーバの承認を行って、ＭＴＣサーバがターゲットＭＴＣデバイスをトリガすることを承認されているか、及びＭＴＣデバイスがトリガリングへの応答を承認されているかを検証するであろう。ＭＴＣサーバ、ＭＴＣデバイス及び(このケースでは登場する)契約に対する承認に成功した場合のみ、ネットワークは、ＭＴＣデバイストリガリングを続行するであろう。
【００３３】
そして、ネットワークは、トリガメッセージの承認を行う。トリガメッセージは、トリガ種別とトリガ本文とを含む。トリガ種別は、緊急レベル、加入者情報、及びアグリゲーション／ブロードキャストトリガ／グループトリガの可用性等から成る。トリガ本文は、期待されるＭＴＣデバイスの動作、例えば、データを返信すること、ソフトウェアをアップデートすること、ネットワークへアタッチすること、ネットワークからデタッチすること等を含む。ネットワークは、トリガ種別をチェックして、トリガメッセージがＭＴＣデバイスへの送信が承認されているか検証する。トリガ種別チェックの成功の後、ネットワークは、トリガメッセージをＭＴＣデバイスへ転送するであろう。
【００３４】
また、トリガインジケーション(メッセージ)を受信したＭＴＣデバイスは、完全性チェック及びトリガ種別チェックを行って、トリガの正当性を検証するであろう。正当性が検証された後にのみ、ＭＴＣデバイスは、ネットワークを介してＭＴＣサーバへ応答するであろう。
【００３５】
また、ネットワークは、ＭＴＣデバイスからＭＴＣサーバへの応答も検証するであろう。ここで、検証とは、特定のＭＴＣデバイスが宛先のＭＴＣサーバとの通信を許可されているか否かチェックすることである。非認証又は誤った通信は、ユーザへ通知されるであろう。
【００３６】
ＩＩ(障害処理：ネットワーク及びＭＴＣサーバからＭＴＣデバイスへのトリガリング送信のリトライ)を達成するため、トリガのＭＴＣデバイスへの配送に失敗し且つこのことがＭＴＣサーバへ通知されると、ＭＴＣサーバは、トリガ送信をリトライすることが可能である。また、ネットワークがＭＴＣデバイスへのトリガ送信をリトライすることも要求される。トリガは、ライフタイムを有しており、このライフタイムが過ぎている場合には、ＭＴＣサーバ又はネットワークから送出されるべきでは無い。また、ライフタイムの過ぎたトリガを受信したＭＴＣデバイスは、トリガを破棄すべきである。頻度、及び何回に亘ってトリガを再送可能であるかの上限は、ＭＴＣサーバとネットワークとの間で定義且つ同期される。
【００３７】
ネットワークは、それをＭＴＣサーバから受信した後に、リトライを開始するであろう。或いは、ＭＴＣサーバは、ネットワークへ、ＭＴＣデバイスへのトリガリングメッセージ送信のリトライが必要かどうかを指示する。
【００３８】
通常、ネットワークは、トリガのライフタイム迄はトリガをＭＴＣデバイスへ再送でき、ＭＴＣサーバは、トリガのライフタイムが終了した後にトリガをネットワークへ再送するであろう。
【００３９】
リプレイアタックを防止するため、トリガリングメッセージのレシーバは、トリガリングメッセージがリトライメッセージであるか或いはオリジナルメッセージであるかを識別可能なべきである。トリガリングメッセージは、その状態(オリジナル又はリトライ)を示すパラメータを含むべきであり、何回リトライされたかのカウンタが、リトライメッセージ中に定義される。
【００４０】
ネットワークは、非承認のトリガリングメッセージが承認されたＭＴＣサーバから受信された場合、ＭＴＣユーザへの通知を送信する。この通知は、ＳＭＳ、Ｅメール又はログへの記録等の何らかの手段によって送信可能である。更なる非承認のトリガは、破棄されるべきであり、ＭＴＣサーバが非承認のトリガを送信し続けるならば、ネットワークは、当該ＭＴＣサーバとの通信を一時停止すべきである。
【００４１】
ＩＩＩ(デタッチした(オフライン)ＭＴＣデバイスをトリガすること)を達成するため、オフラインＭＴＣデバイスは、所定のインターバルの間、通信を必要とせず且つ通信すべきものも有していないから、スタンバイ又はスリープモードへ移行してバッテリ電力を節約する。このインターバルは、ＭＴＣデバイスがインターバルの後に周期的に起床するという意味では固定であり、或いは可変である。オフラインＭＴＣデバイスにとっては、ＭＴＣサーバからのトリガリングがあると直ちに起床する必要が無いかも知れないし、或いはＭＴＣサーバの要求に応じて即時に起床すべきであるかも知れない。
【００４２】
いつトリガをＭＴＣデバイスへ送信すべきか判定するため、まずネットワークは、トリガ種別フィールド中の緊急レベルをチェックするであろう。高い緊急レベルを有するトリガは、即時にＭＴＣデバイスへ送信されるであろう。緊急レベルが低い場合、ネットワークは、オフラインタイマ(又はアタッチのための時間)が有効かチェックするであろう。有効で無い場合、ネットワークは、即時にトリガを送信するであろう。オフラインタイマが有効な場合、ネットワークは、トリガを送信するに先立って、タイマが満了した後に送信されるＭＴＣデバイスからのアタッチ要求を待機するであろう。
【００４３】
アタッチのための時間は、ネットワークからＭＴＣデバイスへ送信され、この時間は、Ｄｅｔａｃｈ Ｒｅｑｕｅｓｔ又はＤｅｔａｃｈ Ａｃｃｅｐｔ(他のメッセージも存在し得る)のいずれかに含まれ得る。このタイマは、ＭＴＣサーバからネットワークへ通知され得るか、或いは契約時に合意され得る。なお、ＭＴＣデバイスが、タイマをネットワーク及びＭＴＣサーバへ通知しても良い。
【００４４】
既存の仕様とは異なり、ＭＴＣデバイスがデタッチしている場合であっても、トリガをＭＴＣデバイスへ送信できる。よって、緊急メッセージのために(或いはオフラインタイマが満了した後に)使用すべきセキュリティコンテキストは、ＭＴＣデバイスがデタッチ状態へ遷移する前に合意されるべきである。セキュリティコンテキストは、デタッチ手順(例えば、Ｄｅｔａｃｈ Ａｃｃｅｐｔメッセージ又はＤｅｔａｃｈ Ｒｅｑｕｅｓｔメッセージ)の間に指示若しくはネゴシエートされ得て、ＭＴＣデバイスは、トリガリングメッセージを解読でき、また将来のメッセージを保護できる。
【００４５】
次に、本実施の形態の動作例を、図２〜図４を参照してより詳細に説明する。
【００４６】
図２は、承認されたＭＴＣデバイストリガのセキュアな配送という第１の課題のための動作例を示している。
【００４７】
ＭＴＣデバイス３０及びネットワーク１０は相互認証を有するものとする(ステップＳ１１)。また、ネットワーク１０及びＭＴＣサーバ２０は相互認証を有するものとする(ステップＳ１２)。
【００４８】
ネットワーク１０は、承認されたＭＴＣサーバのリストを記憶する。このリストは、ＭＴＣサーバＩＤ、許可されたターゲットＭＴＣデバイスＩＤ、加入者情報、ＭＴＣデバイスへの許可されたトリガ種別を含む(ステップＳ１３)。
【００４９】
ＭＴＣサーバ２０は、ＭＴＣデバイストリガをネットワーク１０へ送信する(ステップＳ１４)。
【００５０】
ネットワーク１０は、リストと照合して、ＭＴＣサーバ２０が特定のＭＴＣデバイス３０へのトリガ送信を承認されていか否か、及びＭＴＣデバイス３０が特定のトリガ種別への応答を許可されているかをチェックする(ステップＳ１５)。例えば、ネットワーク１０は、受信したトリガに含まれるＭＴＣサーバ２０のＩＤがリストに含まれるＭＴＣサーバＩＤと一致し、且つトリガに含まれるトリガ種別がリストに含まれる許可されたトリガ種別と一致する場合に、ＭＴＣサーバ２０が特定のトリガ種別を送信することを許可されていると検証しても良い。また、ネットワーク１０は、トリガに含まれるＭＴＣデバイス３０のＩＤがリストに含まれるＭＴＣデバイスＩＤと一致する場合に、ＭＴＣデバイス３０がトリガへの応答を許可されていると検証しても良い。
【００５１】
ネットワーク１０は、ステップＳ１５でのチェックに通過した場合、トリガメッセージをＭＴＣデバイス３０へ転送する(ステップＳ１６)。
【００５２】
ＭＴＣデバイス３０は、トリガメッセージを受信すると、完全性チェックを行うと共に、トリガ種別をチェックする(ステップＳ１７)。
【００５３】
ＭＴＣデバイス３０は、適切な応答をネットワーク１０へ送信する(ステップＳ１８)。
【００５４】
ネットワーク１０は、リストとの照合により、ステップＳ１５と同様にして、ＭＴＣデバイス３０が応答を許可されているか否かをチェックする(ステップＳ１９)。
【００５５】
ネットワーク１０は、トリガ応答をＭＴＣサーバ２０へ転送する(ステップＳ２０)。
【００５６】
図３は、障害処理という第２の課題のための動作例を示している。
【００５７】
ＭＴＣデバイス３０及びネットワーク１０は相互認証を有するものとする(ステップＳ２１)。また、ネットワーク１０及びＭＴＣサーバ２０は相互認証を有するものとする(ステップＳ２２)。
【００５８】
ＭＴＣサーバ２０は、ＭＴＣデバイストリガメッセージを送信する(ステップＳ２３)。但し、トリガメッセージの配送に失敗した際(ステップＳ２４)、ネットワーク１０(ステップＳ２４)又はＭＴＣサーバ２０(ステップＳ２５)の一方が、トリガライフタイムが過ぎているか否か、及び／又はリトライカウンタを超過しているか否かをチェックすることが可能である。
【００５９】
具体的には、ネットワーク１０は、トリガライフタイムが過ぎているか、及び／又はリトライカウンタが制限に達しているかをチェックする(ステップＳ２４ａ)。ステップＳ２４ａのいずれも生じていなければ、ネットワーク１０は、トリガのリトライメッセージをＭＴＣデバイス３０へ転送するであろう(ステップＳ２４ｂ)。
【００６０】
或いは、ＭＴＣサーバ２０が、ネットワーク１０と同様のチェックを行う(ステップＳ２５ａ)。チェックに通過した場合、ＭＴＣサーバ２０は、ネットワーク１０へのトリガメッセージ送信をリトライする(ステップＳ２５ｂ)。ネットワーク１０は、リトライトリガメッセージを転送する(ステップＳ２５ｃ)。
【００６１】
ＭＴＣデバイス３０は、トリガがリトライメッセージであるか検証する(ステップＳ２６)。
【００６２】
ＭＴＣデバイス３０は、そのライフタイムが過ぎているか或いはリトライカウンタを超過しているリトライトリガメッセージを受信した場合、トリガを破棄するであろう(ステップＳ２７)。
【００６３】
図４は、オフラインＭＴＣデバイスをトリガするとの第３の課題のための動作例を示している。
【００６４】
ＭＴＣデバイス３０及びネットワーク１０は相互認証を有するものとする(ステップＳ３１)。また、ネットワーク１０及びＭＴＣサーバ２０は相互認証を有するものとする(ステップＳ３２)。
【００６５】
ＭＴＣデバイス３０がオフラインへ移行した(例えば、Ｄｅｔａｃｈ Ｒｅｑｕｅｓｔ又はＤｅｔａｃｈ Ａｃｃｅｐｔがネットワーク１０からＭＴＣデバイス３０へ送信された)デタッチ手順の間、ネットワーク１０は、ＭＴＣデバイス３０へ、再アタッチタイマ及びセキュリティコンテキストインジケータを送信する(ステップＳ３３ａ)。或いは、ＭＴＣデバイス３０が、ネットワーク１０へ再アタッチタイマを送信して、次回にいつネットワーク１０へアタッチするかを知らせることもできる(ステップＳ３３ｂ)。
【００６６】
ＭＴＣデバイス３０は、オフラインである(ステップＳ３４)。
【００６７】
ＭＴＣサーバ２０は、ＭＴＣデバイストリガメッセージをオフラインＭＴＣデバイス３０へ送信する。このメッセージは、トリガ種別を含む(ステップＳ３５)。
【００６８】
ネットワーク１０は、トリガの緊急レベルをチェックするであろう(ステップＳ３６)。トリガが高い緊急レベルを有している場合(ステップＳ３７)、ネットワーク１０は、トリガメッセージを即時に転送する(ステップＳ３８)。
【００６９】
トリガが低い緊急レベルを有している場合には(ステップＳ３９)、ネットワーク１０は、再アタッチタイマをチェックする(ステップＳ３９ａ)。ネットワーク１０は、再アタッチタイマが満了する迄、ＭＴＣデバイス３０からのｒｅ−Ａｔｔａｃｈ ｒｅｑｕｅｓｔを待機する(ステップＳ３９ｂ)。その後、ネットワーク１０は、トリガメッセージを転送するであろう(ステップＳ３９ｃ)。
【００７０】
[実施の形態２]
図５に示すように、本実施の形態に係るシステムにおいて、ネットワーク１０は、ＭＴＣ−ＩＷＦ(Ｉｎｔｅｒ−Ｗｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ) ４０を含む。ＭＴＣ−ＩＷＦ ４０は、ＭＴＣデバイス３０とＳＣＳ(Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ Ｓｅｒｖｅｒ) ６０との間でメッセージを中継するノードとして機能する。ＳＣＳ ６０は、図１に示したＭＴＣサーバ２０として機能する。ネットワーク１０は、他のノードとして、ＨＳＳ(Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ)、ＭＭＥ(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ)、ＳＧＳＮ(Ｓｅｒｖｉｎｇ ＧＰＲＳ(Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ) Ｓｕｐｐｏｒｔ Ｎｏｄｅ)、ＭＳＣ(Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｒｅ)等を含む。以降の説明においては、ＭＭＥ、ＳＧＳＮ及びＭＳＣを“ＭＭＥ／ＳＧＳＮ／ＭＳＣ”と呼称し、符号５０で総称することがある。ＭＴＣデバイス３０とＭＴＣ−ＩＷＦ ４０の間の通信は、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ５０及びＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)を介して行われる。なお、ＭＴＣデバイス３０は、ＭＴＣ用に装備されたＵＥ(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ)。
【００７１】
次に、本実施の形態の動作例を、図６〜図８を参照して詳細に説明する。
【００７２】
図６は、承認されたＭＴＣデバイストリガのセキュアな配送という第１の課題のための動作例を示している。
【００７３】
ＭＴＣデバイス３０、及びＭＭＥ／ＳＧＳＮ／ＭＳＣ ５０、ＭＴＣ−ＩＷＦ ４０は相互認証を有しているものとする(ステップＳ４１)。また、ＭＴＣ−ＩＷＦ ４０及びＳＣＳ ６０は相互認証を有しているものとする(ステップＳ４２)。
【００７４】
ＭＴＣ−ＩＷＦ ４０は、承認されたＭＴＣサーバ(この例ではＳＣＳ)のリストを記憶する。このリストは、ＭＴＣサーバＩＤ(この例ではＳＣＳ ＩＤ)、許可されたターゲットＭＴＣデバイスのＩＤ、加入者情報、ＭＴＣデバイスへの許可されたトリガ種別を含む(ステップＳ４３)。
【００７５】
ＳＣＳ ６０は、ＭＴＣデバイストリガをＭＴＣ−ＩＷＦ ４０へ送信する(ステップＳ４４)。
【００７６】
ＭＴＣ−ＩＷＦ ４０は、リストとの照合により、ＳＣＳ ６０がターゲットＭＴＣデバイス３０への特定のトリガ種別の送信を承認されていか否か、及びＭＴＣデバイス３０がＳＣＳ ６０からの特定のトリガ種別への応答を許可されているかをチェックする(ステップＳ４５)。
【００７７】
ＭＴＣ−ＩＷＦ ４０は、ステップＳ４５でのチェックに通過した場合、トリガメッセージをＭＴＣデバイス３０へ転送する(ステップＳ４６)。
【００７８】
ＭＴＣデバイス３０は、トリガメッセージを受信すると、完全性チェックを行うと共に、トリガ種別をチェックする(ステップＳ４７)。
【００７９】
ＭＴＣデバイス３０は、適切な応答をＭＴＣ−ＩＷＦ ４０へ送信する(ステップＳ４８)。
【００８０】
ＭＴＣ−ＩＷＦ ４０は、ＭＴＣデバイス３０が応答を許可されているか否かをチェックする(ステップＳ４９)。
【００８１】
ＭＴＣ−ＩＷＦ ４０は、トリガ応答をＳＣＳ ６０へ転送する(ステップＳ５０)。
【００８２】
図７は、障害処理という第２の課題のための動作例を示している。
【００８３】
ＭＴＣデバイス３０、及びＭＭＥ／ＳＧＳＮ／ＭＳＣ ５０、ＭＴＣ−ＩＷＦ ４０は相互認証を有しているものとする(ステップＳ５１)。また、ＭＴＣ−ＩＷＦ ４０及びＳＣＳ ６０は相互認証を有しているものとする(ステップＳ５２)。
【００８４】
ＳＣＳ ６０は、ＭＴＣデバイストリガメッセージをＭＴＣ−ＩＷＦ ４０へ送信する(ステップＳ５３)。そして、ＭＴＣ−ＩＷＦ ４０は、ＭＴＣデバイストリガメッセージを転送する(ステップＳ５４)。但し、トリガメッセージの配送に失敗した際(ステップＳ２４)、ＭＴＣ−ＩＷＦ ４０(ステップＳ５５)又はＳＣＳ ６０(ステップＳ５６)の一方が、トリガライフタイムが過ぎているか否か、及び／又はリトライカウンタを超過しているか否かをチェックすることが可能である。
【００８５】
具体的には、ＭＴＣ−ＩＷＦ ４０は、トリガライフタイムが過ぎているか、及び／又はリトライカウンタが制限に達しているかをチェックする(ステップＳ５５ａ)。ステップＳ５５ａのいずれも生じていなければ、ＭＴＣ−ＩＷＦ ４０は、トリガのリトライメッセージをＭＴＣデバイス３０へ転送するであろう(ステップＳ５５ｂ)。
【００８６】
或いは、ＳＣＳ ６０が、ＭＴＣ−ＩＷＦ ４０と同様のチェックを行う(ステップＳ５６ａ)。チェックに通過した場合、ＳＣＳ ６０は、ＭＴＣ−ＩＷＦ ４０へのトリガメッセージ送信をリトライする(ステップＳ５６ｂ)。ＭＴＣ−ＩＷＦ ４０は、リトライトリガメッセージを転送する(ステップＳ５６ｃ)。
【００８７】
ＭＴＣデバイス３０は、トリガがリトライメッセージであるか検証する(ステップＳ５７)。
【００８８】
ＭＴＣデバイス３０は、そのライフタイムが過ぎているか或いはリトライカウンタを超過しているリトライトリガメッセージを受信した場合、トリガを破棄するであろう(ステップＳ５８)。
【００８９】
図８は、オフラインＭＴＣデバイスをトリガするとの第３の課題のための動作例を示している。
【００９０】
ＭＴＣデバイス３０、及びＭＭＥ／ＳＧＳＮ／ＭＳＣ ５０、ＭＴＣ−ＩＷＦ ４０は相互認証を有しているものとする(ステップＳ６１)。また、ＭＴＣ−ＩＷＦ ４０及びＳＣＳ ６０は相互認証を有しているものとする(ステップＳ６２)。
【００９１】
ＭＴＣデバイス３０がオフラインへ移行した(例えば、Ｄｅｔａｃｈ Ｒｅｑｕｅｓｔ又はＤｅｔａｃｈ Ａｃｃｅｐｔがネットワーク１０からＭＴＣデバイス３０へ送信された)デタッチ手順の間、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ５０は、ＭＴＣデバイス３０へ、再アタッチタイマ及びセキュリティコンテキストインジケータを送信する(ステップＳ６３ａ)。或いは、ＭＴＣデバイス３０が、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ５０へ再アタッチタイマを送信して、次回にいつネットワーク１０へアタッチするかを知らせることもできる(ステップＳ６３ｂ)。
【００９２】
ＭＴＣデバイス３０は、オフラインである(ステップＳ６４)。
【００９３】
ＭＭＥ／ＳＧＳＮ／ＭＳＣ ５０は、再アタッチタイマをＭＴＣ−ＩＷＦ ４０へ送信する(ステップＳ６５)。
【００９４】
ＳＣＳ ６０は、ＭＴＣデバイストリガメッセージをオフラインＭＴＣデバイス３０へ送信する。このメッセージは、トリガ種別を含む(ステップＳ６６)。
【００９５】
ＭＴＣ−ＩＷＦ ４０は、トリガの緊急レベルをチェックするであろう(ステップＳ６７)。トリガが高い緊急レベルを有している場合(ステップＳ６８)、ＭＴＣ−ＩＷＦ ４０は、トリガメッセージを即時に転送する(ステップＳ６８ａ)。
【００９６】
トリガが低い緊急レベルを有している場合には(ステップＳ６９)、ＭＴＣ−ＩＷＦ ４０は、再アタッチタイマをチェックする(ステップＳ６９ａ)。再アタッチタイマが満了するより前にＭＴＣデバイス３０からのｒｅ−Ａｔｔａｃｈ ｒｅｑｕｅｓｔがあったならば、ＭＴＣ−ＩＷＦ ４０は、トリガメッセージを転送するであろう(ステップＳ６９ｃ)。
【００９７】
次に、上述した実施の形態に係る、ＭＴＣ−ＩＷＦ ４０、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ５０、ＭＴＣサーバ２０(ＳＣＳ ６０)及びＭＴＣデバイス３０の構成例を、図９〜図１２を参照して順に説明する。
【００９８】
図９に示すように、ＭＴＣ−ＩＷＦ ４０は、承認されたＭＴＣデバイストリガのセキュアな配送という第１の課題のために、記憶部４１と、検証部４２とを含む。記憶部４１は、上記のリストを記憶する。検証部４２は、リストを照合することによって、ＭＴＣサーバ２０(ＳＣＳ ６０)、ＭＴＣデバイス３０及びトリガメッセージの種別が承認されたものであるか否かを検証する。これらのユニット４１及び４２に代えて或いは加えて、ＭＴＣ−ＩＷＦ ４０は、障害処理という第２の課題のために、チェック部４３と、再送部４４とを含む。チェック部４３は、上記のトリガライフタイム及び／又はリトライカウンタをチェックする。再送部４４は、トリガライフタイムが過ぎていない場合、及び／又はリトライカウンタを超過していない場合に、トリガメッセージを再送する。これらのユニット４１、４２及び４４に代えて或いは加えて、ＭＴＣ−ＩＷＦ ４０は、オフラインＭＴＣデバイスをトリガするとの第３の課題のために、チェック部４３と、判定部４５とを含む。この場合、チェック部４３は、上記の緊急レベルをチェックする。判定部４５は、緊急レベルに従って、トリガメッセージを転送すべきタイミングを判定する。また、ＭＴＣ−ＩＷＦ ４０は、通知部４６を含んでも良い。通知部４６は、ＭＴＣデバイス３０へ上記の再アタッチタイマを通知する。なお、これらのユニット４１〜４６は、バス等を介して相互接続される。これらのユニット４１〜４６は、例えば、ＭＴＣサーバ２０及びＭＴＣデバイス３０とそれぞれ通信するトランシーバと、これらのトランシーバを制御して、図２のステップＳ１１〜Ｓ１６、Ｓ１９及びＳ２０に示した処理、図３のステップＳ２１〜Ｓ２５に示した処理、図４のステップＳ３１〜Ｓ３９に示した処理、図６のステップＳ４１〜Ｓ４６及びＳ４８〜Ｓ５０に示した処理、図７のステップＳ５１〜Ｓ５６に示した処理、図８のステップＳ６１、Ｓ６２及びＳ６２〜Ｓ６９に示した処理、或いはこれらと同等の処理を実行するコントローラと、で構成可能である。
【００９９】
図１０に示すように、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ５０は、指示部５１を含む。指示部５１は、ＭＴＣデバイス３０に対して、上記のセキュリティコンテキストを指示する。このユニット５１は、例えば、ＭＴＣデバイス３０及びＭＴＣ−ＩＷＦ ４０とそれぞれ通信するトランシーバと、これらのトランシーバを制御して、図８のステップＳ６３〜Ｓ６５に示した処理或いはこれと同等の処理を実行するコントローラと、で構成可能である。
【０１００】
また、図１１に示すように、ＭＴＣサーバ２０(ＳＣＳ ６０)は、障害処理という第２の課題のために、チェック部２１と、再送部２２とを含む。チェック部２１は、トリガライフタイム及び／又はリトライカウントをチェックする。再送部２２は、トリガライフタイムが過ぎていない場合、及び／又はリトライカウンタを超過していない場合に、トリガメッセージを再送する。これらのユニット２１及び２２に代えて或いは加えて、ＭＴＣサーバ２０は、オフラインＭＴＣデバイスをトリガするとの第３の課題のために、包含部２３を含む。包含部２３は、トリガメッセージに緊急レベルを含める。なお、これらのユニット２１〜２３は、バス等を介して相互接続される。これらのユニット２１〜２３は、例えば、ＭＴＣ−ＩＷＦ ４０と通信するトランシーバと、このトランシーバを制御して、図３のステップＳ２２、Ｓ２３及びＳ２５に示した処理、図４のステップＳ３２、Ｓ３３及びＳ３５に示した処理、図７のステップＳ５２、Ｓ５３及びＳ５６に示した処理、図８のステップＳ６２及びＳ６６に示した処理、或いはこれらと同等の処理を実行するコントローラと、で構成可能である。
【０１０１】
さらに、図１２に示すように、ＭＴＣデバイス３０は、承認されたＭＴＣデバイストリガのセキュアな配送という第１の課題のために、チェック部３１と、送信部３２とを含む。チェック部３１は、上記の完全性及びトリガ種別チェックを行う。送信部３２は、チェックに通過した場合、ＭＴＣ−ＩＷＦ ４０への応答を送信する。これらのユニット３１及び３２に代えて或いは加えて、ＭＴＣデバイス３０は、障害処理という第２の課題のために、破棄部３３を含む。破棄部３３は、トリガライフタイムが過ぎた場合又はリトライカウンタを超過した場合に、トリガメッセージを破棄する。ＭＴＣデバイス３０は、検証部３４を含んでも良い。検証部３４は、上述したステータス(オリジナル又はリトライ)を参照することによって、トリガメッセージがリトライメッセージか検証する。これらのユニット３１〜３４に代えて或いは加えて、ＭＴＣデバイス３０は、オフラインＭＴＣデバイスをトリガするとの第３の課題のために、通知部３５を含む。通知部３５は、ＭＴＣ−ＩＷＦ ４０へ再アタッチタイマを通知する。なお、これらのユニット３１〜３５は、バス等を介して相互接続される。これらのユニット３１〜３５は、例えば、ＭＴＣ−ＩＷＦ ４０と通信するトランシーバと、このトランシーバを制御して、図２のステップＳ１１及びＳ１６〜Ｓ１８に示した処理、図３のステップＳ２１及びＳ２３〜Ｓ２７に示した処理、図４のステップＳ３１、Ｓ３３、Ｓ３４及びＳ３７〜Ｓ３９に示した処理、図６のステップＳ４１及びＳ４６〜Ｓ４８に示した処理、図７のステップＳ５１及びＳ５４〜Ｓ５８に示した処理、図８のステップＳ６１、Ｓ６３、Ｓ６４、Ｓ６８及びＳ６９に示した処理、或いはこれらと同等の処理を実行するコントローラと、で構成可能である。
【０１０２】
なお、本発明は、上記の実施の形態によって限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。
【０１０３】
この出願は、２０１１年１０月２８日に出願された日本出願特願２０１１−２３６６９９を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【０１０４】
上記の実施の形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
【０１０５】
(付記１)
ネットワークでのトリガの検証
ネットワークは、ＭＴＣサーバ及びトリガの両者に対する承認を行って、トリガが承認されたＭＴＣサーバからのものであるか及び正当なものであるか検証する。
【０１０６】
(付記２)
ＭＴＣデバイスでのトリガの検証
ＭＴＣデバイスは、トリガが承認されたＭＴＣサーバからのものであるか、及びその契約に応じたトリガの正当性の両者を検証する。
【０１０７】
(付記３)
ネットワークでの、ＭＴＣデバイスからＭＴＣサーバへのメッセージの検証。
【０１０８】
(付記４)
ＭＴＣサーバ及びネットワークは、トリガの鮮度を維持しつつ、例えばネットワーク障害に際して、ＭＴＣデバイストリガリングメッセージの送信をリトライする。
【０１０９】
(付記５)
ネットワークは、ＭＴＣユーザへ非承認のトリガ受信について通知すると共に、トリガを送信するＭＴＣサーバとの更なる通信を一時停止することが可能である。通知には、ＳＭＳ、Ｅメールを介して、或いはログに記録すること等、手段を選ばない。
【０１１０】
(付記６)
ネットワークは、緊急レベル及びアタッチ用タイマに応じて、トリガをデタッチした(オフラインの)ＭＴＣデバイスへ送信する。
【０１１１】
(付記７)
ネットワークは、次の通信において用いるべきメッセージのセキュリティコンテキストを指示する。
【符号の説明】
【０１１２】
１０  ネットワーク
２０  ＭＴＣサーバ
２１, ３１, ４３  チェック部
２２  再送部
２３  包含部
３０  ＭＴＣデバイス
３２  送信部
３３  破棄部
３４, ４２  検証部
３５, ４６  通知部
４０  ＭＴＣ−ＩＷＦ
４１  記憶部
４４  再送部
４５  判定部
５０  ＭＭＥ／ＳＧＳＮ／ＭＳＣ
５１  指示部
６０  ＳＣＳ
【図１】
2020025304.tif 000003
【図２】
2020025304.tif 000004
【図３】
2020025304.tif 000005
【図４】
2020025304.tif 000006
【図５】
2020025304.tif 000007
【図６】
2020025304.tif 000008
【図７】
2020025304.tif 000009
【図８】
2020025304.tif 000010
【図９】
2020025304.tif 000011
【図１０】
2020025304.tif 000012
【図１１】
2020025304.tif 000013
【図１２】
2020025304.tif 000014