(57)【要約】      （修正有）【課題】ＭＴＣ（Ｍａｃｈｉｎｅ−Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）において生じるグループ変更のための方法を提供する。【解決手段】ゲートウェイ(ＧＷ)は、グループメンバのＭＴＣデバイスがグループを変更する場合に、セキュリティ管理のために最適化される。ゲートウェイは、アクセス制御を行って、ＭＴＣデバイスがターゲットグループへ移動可能か否かを判定する。変更が首尾良く完了した場合、ゲートウェイは、ターゲットグループのグループキーをＭＴＣデバイスへ割り当てる。【選択図】図１
2014161096.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも２つのグループにグループ分けされて、ネットワークと通信するＭＴＣ（Ｍａｃｈｉｎｅ−Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイスであって、
自ＭＴＣデバイスが属する一のグループから他のグループへ変更する旨の要求を、ゲートウェイへ送信する手段を備え、
前記要求が前記ゲートウェイにより受け付けられた場合に、前記一のグループから前記他のグループへ変更されて、前記ネットワークと通信を行うことを特徴とするＭＴＣデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＭＴＣ(Ｍａｃｈｉｎｅ−Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ)デバイス及びネットワーク主導でＭＴＣデバイスがグループを変更するための方法、並びにこれに関連するセキュリティ事項を提供する。
【背景技術】
【０００２】
ＭＴＣデバイスは、グループ化されてネットワークと通信することが可能である(非特許文献１参照)。契約変更、サービス要件の変更或いは物理的エリアの変更等に起因して、ＭＴＣデバイスを、同一ゲートウェイ配下で他のグループへ変更できるべきである。これをどのように実現すべきか、３ＧＰＰ(３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)規格では未だ取り扱われていない。
【０００３】
グループ変更が同一ゲートウェイ配下である場合、その手順は、ネットワークを巻き込むべきでは無く、更新されるべきである。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】３ＧＰＰ ＴＳ ２３．８８８、"Ｓｙｓｔｅｍ Ｉｍｐｒｏｖｅｍｅｎｔｓ ｆｏｒＭａｃｈｉｎｅ−Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ (Ｒｅｌｅａｓｅ １０)"、Ｖ０．５．１、２０１０年７月、５．１章、８〜９頁
【発明の概要】
【０００５】
４つの実際的な場面を考慮する。第１の場面は、ＭＴＣデバイスが、ユーザ要求に応じて同一ゲートウェイ配下でのグループ変更を要求することである。この場面は、ケースＩにおいて示されるであろう。
【０００６】
第２の場面は、ゲートウェイが、ＭＴＣデバイスのために自ゲートウェイ配下の他のグループを割り当て、ＭＴＣデバイスに対して変更の決定を指示することである。この場面は、ケースＩＩにおいて示されるであろう。
【０００７】
第３及び第４の場面は、ターゲットグループが他のゲートウェイ配下の場合である。これらの場面は、ケースＩＩＩ及びＩＶにおいて個別に示されるであろう。
【０００８】
注１：ゲートウェイは、ＭＴＣデバイスに統合されるか或いは単独のデバイスであり得る。
【発明の効果】
【０００９】
グループ変更手順においてネットワークを巻き込まないことは、ネットワークとＭＴＣデバイスとの間のシグナリングを低減でき、性能を向上させる。
【００１０】
グループ変更手順におけるセキュリティ管理にゲートウェイを用いることは、ネットワークへの更なる攻撃を防止する。
【００１１】
例えば、ＭＴＣデバイスのための契約が変更された場合に、ＭＴＣデバイスがグループへ加入することの柔軟性を提供する。
【図面の簡単な説明】
【００１２】
【図１】ケースＩにおける動作を示したブロック図である。
【図２】ケースＩＩにおける動作を示したブロック図である。
【図３】ケースＩＩＩにおける動作を示したブロック図である。
【図４】ケースＩＶにおける動作を示したブロック図である。
【図５】ケースＩ〜ＩＶに共通のゲートウェイの構成例を示したブロック図である。
【発明を実施するための形態】
【００１３】
ケースＩ：
本発明の目的は、ゲートウェイ(ＧＷ：ｇａｔｅｗａｙ)を、グループメンバのＭＴＣデバイスがそのグループを変更する要求を送信する場合におけるセキュリティ管理用に最適化することによって達成される。ゲートウェイは、アクセス制御を行って、ＭＴＣデバイスがターゲットグループへ移動可能か否かを判定することができる。変更が首尾良く完了した場合、ゲートウェイは、ターゲットグループのグループキーをＭＴＣデバイスへ割り当てる。
【００１４】
次のように、幾つかの仮定を立てる。
１．ＧＷ及びコアネットワーク(ＣＮ：ｃｏｒｅ ＮＥＴＷＯＲＫ)は、セキュアな通信を確立している。
２．ＭＴＣデバイスは、ＧＷ及びコアネットワークとセキュアな通信を確立している。
３．ＧＷは、１以上のグループに関連付けられている。
４．ゲートウェイは、自身がサポートするグループ用の全てのグループＩＤを記憶すべきである。
【００１５】
本発明は、以下のステップから成る。
【００１６】
１．ＭＴＣデバイスは、自身の特徴(ｆｅａｔｕｒｅ)及び現在のグループＩＤを含むグループ変更要求を送出する(図１に示すステップＳ１０１)。なお、３ＧＰＰで定義される通り、これらの特徴(ＭＴＣ Ｆｅａｔｕｒｅｓ)とは、ネットワークをＭ２Ｍ(Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ)アプリケーションが使えるように最適化するネットワーク機能である。具体的には、ＭＴＣデバイスは、下記ＭＴＣ Ｆｅａｔｕｒｅｓの１以上を有する。
−Ｌｏｗ Ｍｏｂｉｌｉｔｙ(移動しない、稀に移動する或いは特定エリア内でのみ移動することが可能なＭＴＣデバイスを意図している)
−Ｔｉｍｅ Ｃｏｎｔｒｏｌｌｅｄ(規定の時間間隔でのみデータの送信又は受信を許容可能であり、規定の時間間隔外での不要なシグナリングを回避可能なＭＴＣデバイスを意図している)
−Ｐａｃｋｅｔ Ｓｗｉｔｃｈｅｄ (ＰＳ) Ｏｎｌｙ(パケット交換サービスのみを要求するＭＴＣデバイスを意図している)
−Ｓｍａｌｌ Ｄａｔａ Ｔｒａｎｓｍｉｓｓｉｏｎ(少量のデータを送信又は受信するＭＴＣデバイスを意図している)
−Ｍｏｂｉｌｅ Ｏｒｉｇｉｎａｔｅｄ Ｏｎｌｙ(モバイル発信の通信のみを利用するＭＴＣデバイスを意図している)
−Ｉｎｆｒｅｑｕｅｎｔ Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｔｅｄ(主としてモバイル発信の通信を利用するＭＴＣデバイスを意図している)
−ＭＴＣ ｍｏｎｉｔｏｒｉｎｇ(イベントに関連するＭＴＣデバイスの監視を意図している)
−Ｐｒｉｏｒｉｔｙ Ａｌａｒｍ(窃盗、破壊行為或いは他の緊急対応の必要性等のイベントにおいてプライオリティ・アラームを発するＭＴＣデバイスを意図している)
−Ｓｅｃｕｒｅ Ｃｏｎｎｅｃｔｉｏｎ(ＭＴＣデバイスとＭＴＣサーバとの間にセキュアなコネクションを要求するＭＴＣデバイスを意図している)
−Ｌｏｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｔｒｉｇｇｅｒ(特定エリアに存在すべきＭＴＣアプリケーションによって既知のＭＴＣデバイスをトリガする用途である)
−Ｎｅｔｗｏｒｋ Ｐｒｏｖｉｄｅｄ Ｄｅｓｔｉｎａｔｉｏｎ ｆｏｒ Ｕｐｌｉｎｋ Ｄａｔａ(ＭＴＣデバイスからの全データを、宛先ＩＰアドレスによって提供されるネットワークへ導くことを要求するＭＴＣアプリケーションを意図している)
−Ｉｎｆｒｅｑｕｅｎｔ Ｔｒａｎｓｍｉｓｓｉｏｎ(稀にデータを送信又は受信する(すなわち、データ伝送同士間の期間が長い)ことが期待されるＭＴＣデバイスを意図している)
−Ｇｒｏｕｐ Ｂａｓｅｄ ＭＴＣ Ｆｅａｔｕｒｅｓ(ＭＴＣグループ向けのＭＴＣＦｅａｔｕｒｅｓの集合である)
−Ｇｒｏｕｐ Ｂａｓｅｄ Ｐｏｌｉｃｉｎｇ(ネットワーク事業者が複合的なＱｏＳポリシを強行したいＭＴＣグループを意図している)
−Ｇｒｏｕｐ Ｂａｓｅｄ Ａｄｄｒｅｓｓｉｎｇ(多くのＭＴＣデバイスが同一メッセージを受信する必要がある場合に、ネットワーク事業者がメッセージ良を最適化したいＭＴＣグループを意図している)
【００１７】
２．ゲートウェイは、ＭＴＣデバイスの特徴をターゲットグループがサポートする特徴と比較して、グループ変更の受付可否を判定すべきである。
【００１８】
３．ゲートウェイは、ＭＴＣデバイス用のテンポラリＩＤを作成して、ターゲットグループのキーと共に割り当てるべきである(ステップＳ１０２)。このテンポラリＩＤは、ＭＴＣデバイスをターゲットグループ内で識別するために割り当てられ、以てＭＴＣデバイスの固有ＩＤが漏洩してしまうのを防止できる。キーは、ターゲットグループのメンバとゲートウェイとの間で安全に通信を行うために割り当てられる。このようなキーの例としては、ＭＴＣデバイスとゲートウェイとの間で伝送されるデータを暗号化するための暗号鍵や、受信データを復号化するための復号鍵が挙げられる。
【００１９】
４．グループ変更に成功した後、その結果がコアネットワークへ知らされる。
【００２０】
５．ソースグループに関する機密情報は、ターゲットグループへ開示／提示しないべきである。このため、ＭＴＣデバイスは、自身の古いテンポラリＩＤ、古いグループＩＤ及びキーを削除する、位置を更新すること等を行うべきである。
【００２１】
６．ゲートウェイ及びネットワークは、当該ＭＴＣデバイスに対する結果に従って、関連データを更新すべきである(ステップＳ１０３)。具体的には、ゲートウェイは、テンポラリＩＤ及びターゲットグループＩＤをコアネットワークへ送信し、以てコアネットワークにＭＴＣデバイスがターゲットグループへ移動した旨を通知する。これにより、ＭＴＣデバイスに関連するデータを、コアネットワークにおいて更新且つ同期させることができる。
【００２２】
ケースＩＩ：
本発明の目的は、ネットワークが、自身のサービス要件を達するために、ＧＷを介してＭＴＣデバイスへターゲットグループへの移動を要求するといった方法によって達成される。ケースＩにおける仮定を本ケースに適用する。
【００２３】
本発明は、以下のステップから成る。
【００２４】
１．グループ変更インジケーションが、コアネットワークからＧＷを介してＭＴＣデバイスへ送信される(図２に示すステップＳ２０１)。このインジケーションは、ターゲットグループＩＤと、ターゲットグループによってサポートされる特徴(以下、"ターゲットグループ・フィーチャ(ｆｅａｔｕｒｅｓ)"と呼称することがある)とを含む。
【００２５】
２．ＭＴＣデバイスは、受付メッセージをＧＷへ送信するであろう(ステップＳ２０２)。ここでは、ケースＩにおけるステップ２〜５を適用する。具体的には、ゲートウェイと同様、ＭＴＣデバイスは、自身の特徴とターゲットグループ・フィーチャとを比較する。ＭＴＣデバイスがターゲットグループ・フィーチャをサポート可能である場合、ＭＴＣデバイスは、グループ変更が受け付けられた旨を示す受付メッセージを送出する。この受付メッセージを受信したゲートウェイは、ＭＴＣデバイス用の新たなテンポラリＩＤを作成して、ターゲットグループのキーと共に割り当てる。
【００２６】
３．ＭＴＣデバイスが変更を拒否する場合、ＧＷは、以後のＭＴＣデバイスを拒絶し、後に何度か要求を再送可能なべきである。
【００２７】
４．ＭＴＣデバイスが全ての要求を拒絶する場合、ＧＷは、ＭＴＣデバイスをデタッチさせ、当該ＭＴＣデバイスの加入者データを削除可能なべきである。
【００２８】
ケースＩＩＩ：
本発明の目的は、ネットワークが、他のＧＷにおいてＭＴＣデバイスをターゲットグループへ移動させるよう制御するといった方法によって達成される。ケースＩにおける仮定を本ケースに適用する。
【００２９】
本発明は、以下のステップから成る。
【００３０】
１．グループ変更要求が、ＭＴＣデバイスからソースＧＷを介してコアネットワークへ送信される(図３に示すステップＳ３０１)。
【００３１】
２．ネットワークは、ＭＴＣデバイス及びターゲットグループの特徴同士を比較することによって、グループ変更が許可されているか否かを判定するであろう。
【００３２】
３．両特徴が一致する場合、ネットワークは、ソースゲートウェイへ受付メッセージを送信するであろう(ステップＳ３０２)。
【００３３】
４．ソースゲートウェイは、ターゲットゲートウェイに対し、セキュリティキーとＭＴＣデバイスの現在のテンポラリＩＤとを含むグループ変更要求を送信する(ステップＳ３０３)。
【００３４】
５．ターゲットゲートウェイは、アクセス制御を行い、アクセス制御に成功した場合には受付メッセージをＭＴＣデバイスへ送信するであろう。
【００３５】
６．ターゲットゲートウェイは、ＭＴＣデバイスから確認応答(ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ)を受信すると、ＭＴＣデバイス用に新たなキー及びテンポラリＩＤを生成して割り当てる(ステップＳ３０４)。
【００３６】
７．一方、ターゲットゲートウェイは、ネットワークへグループ変更について知らせるであろう。ターゲットウェイ及びネットワークは、当該ＭＴＣデバイスに対する結果に従って、関連データを更新すべきである(ステップＳ３０５)
【００３７】
ケースＩＶ：
本発明の目的は、ネットワークが、他のＧＷにおいてＭＴＣデバイスをターゲットグループへ移動させるよう制御するといった方法によって達成される。ケースＩにおける仮定を本ケースに適用する。
【００３８】
本発明は、以下のステップから成る。
【００３９】
１．グループ変更インジケーションが、コアネットワークからＧＷを介してＭＴＣデバイスへ送信される(図４に示すステップＳ４０１)。
【００４０】
２．ＭＴＣデバイスは、自身のソースゲートウェイへ応答する(ステップＳ４０２)。
【００４１】
３．ターゲットゲートウェイが肯定的な応答を受信した場合、ここでは、ケースＩＩＩにおけるステップ３〜７を適用する。
【００４２】
４．ターゲットゲートウェイが否定的な応答を受信した場合、ここでは、ケースＩＩにおけるステップ３、４を適用する。
【００４３】
次に、ゲートウェイの構成例を、図５を参照して説明する。
【００４４】
図５に示すように、上記の実施の形態に係るゲートウェイ１０は、受信部１１と、判定部１２と、割当部１３と、通知部１４とを含む。ケースＩにおいて、受信部１１は、ＭＴＣデバイスからグループ変更要求を受信する。判定部１２は、グループ変更要求に含まれるＭＴＣデバイスの特徴をターゲットグループ・フィーチャと比較して、グループ変更要求の受付可否を判定する。グループ変更要求を受け付けると判定された場合、割当部１３は、ターゲットグループのキーをＭＴＣデバイスへ割り当てる。また、割当部１３は、テンポラリＩＤをＭＴＣデバイスへ割り当てる。割当に際して、通知部１４は、コアネットワークへ、ＭＴＣデバイスがターゲットグループへ移動した旨を知らせる。
【００４５】
ケースＩＩにおいて、受信部１１は、コアネットワークからグループ変更インジケーションを受信する。この時、判定部１２は、グループ変更インジケーションをＭＴＣデバイスへ転送する。受付メッセージがＭＴＣデバイスから受信されると、割当部１３は、ＭＴＣデバイスに対してターゲットグループのキーとテンポラリＩＤとを割り当てる。
【００４６】
ケースＩＩＩにおいて、判定部１２は、ターゲットグループが他のゲートウェイ配下である場合、グループ変更要求をＭＴＣデバイスからコアネットワークへ転送する。受付メッセージがコアネットワークから受信された場合、割当部１３は、他のゲートウェイへ、ＭＴＣデバイスに対してターゲットグループのキーとテンポラリＩＤとを割り当てるように要求する。
【００４７】
ケースＩＶにおいて、受信部１１は、グループ変更インジケーションをコアネットワークから受信する。この時、判定部１２は、グループ変更インジケーションをＭＴＣデバイスへ転送する。受付メッセージがＭＴＣデバイスから受信され、且つターゲットグループが他のゲートウェイ配下である場合、割当部１３は、他のゲートウェイへ、ＭＴＣデバイスに対してターゲットグループのキーとテンポラリＩＤとを割り当てるように要求する。
【００４８】
これらのユニット１１〜１４は、例えば、ＭＴＣデバイス及びコアネットワークとの通信をそれぞれ行うトランシーバと、これらのトランシーバを制御して、図１〜図４に示した処理或いはこれらと同等の処理を実行するコントローラとで構成することができる。
【００４９】
なお、本発明は、上記の実施の形態によって限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。
【００５０】
この出願は、２０１０年８月１７日に出願された日本出願特願２０１０−１８２３８４を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【００５１】
上記の実施の形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
【００５２】
(付記１)
変更制御：
ＧＷは、グループ要求中で受信したＭＴＣデバイスの特徴と、ターゲットグループでサポートされる特徴とを比較するであろう。このことは、変更手順においてコアネットワークを巻き込む必要が無い。
【００５３】
(付記２)
機密データ管理：
ＭＴＣデバイスにおけるソースグループの機密データは、ターゲットグループへ提示しないべきであり、以て削除される。同様にして、ＧＷは、ＭＴＣデバイス及びソースグループに関連するデータを削除する。
【００５４】
(付記３)
識別子及びキーのハンドリング
ＧＷは、ターゲットグループに関連する新たなテンポラリＩＤを割り当て、ターゲットグループキーをＭＴＣデバイスへ送信する。
【００５５】
(付記４)
ＧＷ及びコアネットワークにおけるＭＴＣデバイス状態の更新
ＧＷは、ＭＴＣデバイスの関連データを更新し、ローカルでの変更が完了した後にグループ変更の結果をネットワークへ送信する。この結果、ＭＴＣデバイスの関連データが、ネットワークにおいて同期される。
【符号の説明】
【００５６】
１０  ＧＷ
１１  受信部
１２  判定部
１３  割当部
１４  通知部
【図１】
2014161096.tif 000003
【図２】
2014161096.tif 000004
【図３】
2014161096.tif 000005
【図４】
2014161096.tif 000006
【図５】
2014161096.tif 000007