(57)【特許請求の範囲】
【請求項１】
バックホールの接続無しで無線アクセスネットワークに接続可能なユーザ装置であって、
ＩＯＰＳ（Isolated E-UTRAN Operations for Public Safety）用のキーと、
ＩＯＰＳ用の識別子と、を備え、
前記ＩＯＰＳ用のキーと前記ＩＯＰＳ用の識別子とを含む認証情報（Credential）を用いて認証されることを特徴とするユーザ装置。
【請求項２】
請求項１に記載のユーザ装置であって、
前記ユーザ装置は、前記ＩＯＰＳに係るサービスにアクセスすることを特徴とするユーザ装置。
【請求項３】
バックホールの接続無しで無線アクセスネットワークに接続可能なユーザ装置のためにＩＯＰＳ（Isolated E-UTRAN Operations for Public Safety）を確立する方法であって、
前記ユーザ装置が、ＩＯＰＳ用のキーとＩＯＰＳ用の識別子とを備え、
前記ユーザ装置が、前記ＩＯＰＳ用のキーと前記ＩＯＰＳ用の識別子とを含む認証情報（Credential）を用いて認証されることを特徴とする方法。
【請求項４】
請求項３に記載の前記ＩＯＰＳを確立する方法であって、さらに
前記ユーザ装置は、前記ＩＯＰＳに係るサービスにアクセスすることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モバイル通信システム及びモバイル通信方法に関し、特に、バックホールの接続が無いセキュリティに関する。
【背景技術】
【０００２】
現在のアーキテクチャでは、例えば、非特許文献１，２に開示されているように、Ｉｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）は、ＥＰＣ（Evolved Packet Core）との接続が無い、又は、ＥＰＣとの制限されたバックホール接続がある（with none or limited backhaul connection to EPC）、１以上の（Ｎ）ｅＮＢ（（Nomadic） Evolved Node B）を含む。（Ｎ）ｅＮＢは互いに接続されてＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮを形成する。
【０００３】
ユーザデータ通信は、Ｉｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮにおける１つのｅＮＢを介して、ローカルにルーティング（routed locally）される。ＵＥ（User Equipment：ユーザ装置）は、ｅＮＢ配下の他のＵＥに通知されても良い。制限されたバックホールで他のｅＮＢへのＵＥの移動が発生しても良い。ＰＳ（Public Safety）可能なＵＥ（PS enabled UE）（以下、適宜“ＰＳ ＵＥ”と称す）は、Ｉｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮのエリアに参加／離脱（join/leave）することができる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】3GPP TS 22.346, "Isolated Evolved Universal Terrestrial Radio Access Network (E-UTRAN) operation for public safety; Stage 1 (Release 13)", V13.0.0, 2014-09
【非特許文献２】3GPP TR 22.897, "Study on Isolated Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Operation for Public Safety (Release 13)", V13.0.0, 2014-06
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、この出願の発明者等は、Ｉｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮがＥＰＣへのバックホール無しで動作するケースでは、例えば、以下の脅威（ａ）〜（ｆ）の可能性があることを見出した。
（ａ）認証されていないＵＥ（Un-authenticated UE）がＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮに参加する
（ｂ）認可されていないＵＥ（Un-authorized UE）がＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮの用法（usage）を使用して、同じエリアの他のＵＥと通信する
（ｃ）過負荷、ｅＮＢへのＤｏＳ（Denial of Service）攻撃
（ｄ）傍受、ＵＥと（Ｎ）ｅＮＢとの間の通信へのＭｉｔＭ（Man in the Middle）攻撃
（ｅ）セッションハイジャック
（ｆ）ＵＥが盗用（盗み見）される（UE being stolen）
【０００６】
バックホールの接続が無いため、現在のセキュリティメカニズムは適用されない。
【０００７】
そこで、本発明の目的は、バックホールの接続が無いセキュリティを改良する解決法を提供することにある。
【課題を解決するための手段】
【０００８】
上述の目的を達成するために、本発明の態様は、ＵＥがバックホールの接続無しでＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮに参加及び離脱するときに、ＵＥの認証（authentication）及び認可（authorization）を行うためのモバイル通信システム及びモバイル通信方法の詳細を提供する。ＭＭＥ（Mobility Management Entity）の代わりに、ｅＮＢがＵＥの認証及び認可を行っても良い。（Ｎ）ｅＮＢは、認可されたＰＳ ＵＥのリストをローカルに管理しても良い。
【発明の効果】
【０００９】
本発明によれば、バックホールの接続が無いセキュリティを改良する解決法を提供し、それにより、例えば、上述の脅威の少なくとも１つを解決することが可能となる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施の形態に係るモバイル通信システムの構成例を示すブロック図である。
【図２】実施の形態に係るモバイル通信システムにおける第１の動作例を示すシーケンス図である。
【図３】実施の形態に係るモバイル通信システムにおける第２の動作例を示すシーケンス図である。
【図４】実施の形態に係るモバイル通信システムにおける第３の動作例を示すシーケンス図である。
【発明を実施するための形態】
【００１１】
以下、本発明に係るモバイル通信システム及びモバイル通信方法の実施の形態について、添付図面を参照して説明する。
【００１２】
図１に示されるように、この実施の形態に係るモバイル通信システムは、ＥＰＣ（不図示）へのバックホール無しで動作するケースに対処するものである。このモバイル通信システムは、１つ以上のＵＥ１０＿１〜１０＿３（以下、適宜、まとめて符号１０で示す）と、１つ以上のｅＮＢ２０＿１及び２０＿２（以下、適宜、まとめて符号２０で示す）と、を含む。なお、図１には３つのＵＥ及び２つのｅＮＢが示されているが、モバイル通信システムは、３つよりも少ない又は多い数のＵＥと、２つよりも少ない又は多い数のｅＮＢと、を備えても良い。このようなケースでも、以下の説明は、同様に適用可能である。
【００１３】
ｅＮＢ２０＿１及び２０＿２は、互いに接続されて、Ｉｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮ１を形成する。ｅＮＢ２０＿１及び２０＿２の各々は、ＵＥ１０＿１〜１０＿３の少なくとも１つのためのＮｅＮＢとしての役割を持つことが可能であり、ＵＥ１０＿１〜１０＿３の間のユーザデータ通信をローカルにルーティングする。
【００１４】
次に、この実施の形態の動作例について、図２〜図４を参照して説明する。
【００１５】
１．準備（Preparation）
（Ｎ）ｅＮＢ２０及びＵＥ１０は、ＵＥの認証用の必要情報（necessary information）が必要であり、これを以下の方法の内の１つを用いることで取得することが可能である。
１）ＮｅＮＢ２０は、ＮｅＮＢ２０がＥＰＣに接続されたときに、必要情報を予め設定したり、（例えば、ＭＭＥから）必要情報を受信したりすることが可能である。ＵＥ１０は、ＮｅＮＢ２０と同様に、必要情報を予め設定することが可能である。
２）ＵＥ１０がアタッチしていた以前のｅＮＢがＮｅＮＢ２０の近隣に位置し、そのｅＮＢがＮｅＮＢ２０に接続可能であれば、ＮｅＮＢ２０は、そのｅＮＢからのＵＥセキュリティコンテキストをリクエストする。
３）誰もが検証（verify）可能なキーで参加することができるようにする。この共有されたキーは、ＵＥ１０及び（Ｎ）ｅＮＢ２０の双方に提供される必要がある。
【００１６】
２．ＰＳ ＵＥがＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮに参加する
ＵＥ１０がＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮ１に参加するときに、（Ｎ）ｅＮＢ２０は、まず、ＵＥ１０がパブリックセーフティ（public safety）可能なＵＥであるかどうかを検証し、ＵＥ１０がパブリックセーフティ可能でなければ、参加リクエストを拒否（reject）する。（Ｎ）ｅＮＢ２０は、リクエストをしてきたＵＥ１０がパブリックセーフティ可能なＵＥである場合にのみ、認証プロシージャを開始する。ＵＥ１０が認証されれば、（Ｎ）ｅＮＢ２０は、ＡＳ（Access Stratum）セキュリティセットアッププロシージャ等で、ＵＥ１０とのセキュアな接続をセットアップする。
【００１７】
２．１．ＰＳ ＵＥがＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮに最初に参加する
ＵＥ１０及びＮｅＮＢ２０には、ＩＯＰＳ（Isolated E-UTRAN Operations for Public Safety）グループＩＤ（identifier：識別子）及び関連するグループキーが予め設定されていると仮定する。また、ＮｅＮＢ２０は、許可されたＩＯＰＳグループ（allowed IOPS group）のリストを格納する。
【００１８】
具体的には、図２に示されるステップＳ１０において、パブリックセーフティ可能なＵＥ１０には、Ｉｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮ１への認証用の認証情報（credential）が予め設定されている。（Ｎ）ｅＮＢ２０は、この（Ｎ）ｅＮＢ２０が属するＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮ１にアクセス可能なＵＥの許可されたＩＯＰＳグループのリストを格納する。ＵＥ１０及び（Ｎ）ｅＮＢ２０の双方は、このＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮ１用のグループＩＤに関連するＩＯＰＳグループキーを格納する。
【００１９】
ステップＳ１１において、ＮｅＮＢ２０は、自身の“Ｉｓｏｌａｔｅｄ Ｍｏｄｅ”というステータスを、ＮｅＮＢ ＩＤと共にブロードキャストする。ＮｅＮＢ２０は、ＵＥ１０が検証可能な署名（signature）と共に、ブロードキャストすることが可能である。ブロードキャストはオプションである。
【００２０】
ステップＳ１２において、ＵＥ１０は、アタッチリクエストメッセージ（Attach Request message）を（Ｎ）ｅＮＢ２０に送信する。
【００２１】
ＵＥ１０が“Ｉｓｏｌａｔｅｄ Ｍｏｄｅ”のブロードキャストを受信しなければ、ＵＥ１０は、１）保護されていないＩＭＳＩ（International Mobile Subscriber Identity）を含むアタッチリクエストを、又は、２）ＮＡＳ（Non-Access Stratum）で保護されたＧＵＴＩ（Globally Unique Temporary Identity）を含むアタッチリクエストを、送信する。その後、以下のステップＳ１３ａ及びＳ１３ｂが実行される。
【００２２】
ＵＥ１０が“Ｉｓｏｌａｔｅｄ Ｍｏｄｅ”のブロードキャストを受信すれば、ＵＥ１０は、自身のＩＯＰＳ ＩＤ及びグループＩＤと共に、アタッチリクエストメッセージを送信する。このメッセージは、ＩＯＰＳグループキーで保護されている。
【００２３】
ステップＳ１３ａにおいて、（Ｎ）ｅＮＢ２０は、ＮＡＳメッセージを読み取ることができないため、ＩＯＰＳ識別子リクエストメッセージ（IOPS Identity Request message）をＵＥ１０に送信することにより、ＩＯＰＳ識別子をリクエストする。ステップＳ１３ｂにおいて、ＵＥ１０は、ＩＯＰＳ識別子レスポンスメッセージ（IOPS Identity Response message）でＩＯＰＳグループＩＤを送信する。このメッセージは、ＩＯＰＳグループキーで保護されている。
【００２４】
ステップＳ１４において、（Ｎ）ｅＮＢ２０は、ＵＥ１０がパブリックセーフティ可能なＵＥでありかつＩＯＰＳサービスへのアクセスが許可されているかどうかを検証する。この検証は、１）許可されたＵＥリスト（allowed UE list）に対するＩＯＰＳグループＩＤのチェック、２）ＩＯＰＳグループキーを使用することによるメッセージの完全性検証（integrity verification）によって、行われる。
【００２５】
検証が成功すれば、（Ｎ）ｅＮＢ２０は、フレッシュ値、そのフレッシュ値からのセッションキー、及びＩＯＰＳグループキーを生成し、現在のＵＥリストをアップデートする。
【００２６】
ステップＳ１５において、（Ｎ）ｅＮＢ２０は、セッションキー導出用のアルゴリズムＩＤ（alg-ID）及びフレッシュ値と現在のＵＥリストと共に、アタッチアクセプトメッセージ（Attach Accept message）を、ＵＥ１０へ送信する。アタッチアクセプトメッセージは、セッションキーで完全性保護がなされている。
【００２７】
ステップＳ１６において、ＵＥ１０は、受信されたａｌｇ−ＩＤ及びフレッシュ値を使用して、セッションキーを生成する。このようにして、ＵＥ１０は、メッセージの完全性及びＮｅＮＢの信頼性（authenticity）を検証することができる。
【００２８】
ステップＳ１７において、ＵＥ１０及び（Ｎ）ｅＮＢ２０は、セキュアな通信を開始する。
【００２９】
２．２．ＰＳ ＵＥが以前にＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮに参加していた
ＵＥ１０が、ある（Ｎ）ｅＮＢに以前にアタッチしていたと仮定する。以前のＮｅＮＢ ＩＤ又はその（Ｎ）ｅＮＢにより割り当てられたトークン（token）は、新規の（Ｎ）ｅＮＢへのアタッチリクエストメッセージに挿入することが可能である。
【００３０】
具体的には、図３に示されるステップＳ２０において、ＵＥ１０は、以前の（Ｎ）ｅＮＢ２０＿１にアタッチする。
【００３１】
ステップＳ２１において、ＵＥ１０は、新規のＮｅＮＢ２０＿２にアタッチリクエストメッセージを送信する。ＵＥ１０は、このメッセージに、以前のＮｅＮＢ ＩＤ又は以前のＮｅＮＢ２０＿１に割り当てられたトークンを、挿入することが可能である。
【００３２】
ステップＳ２２ａにおいて、新規の（Ｎ）ｅＮＢ２０＿２が十分な（sufficient）ＵＥ情報を持っていなければ、（Ｎ）ｅＮＢ２０＿２は、ＵＥ１０が以前にアタッチしていた（Ｎ）ｅＮＢ２０＿１にＵＥコンテキストリクエストメッセージ（UE Context Request message）を送信することにより、以前の（Ｎ）ｅＮＢ２０＿１とコンタクトを取り、ステップＳ２２ｂにおいて、以前の（Ｎ）ｅＮＢ２０＿１が近隣に位置していれば、（Ｎ）ｅＮＢ２０＿１から受信されたＵＥコンテキストレスポンスメッセージ（UE Context Response message）で必要なＵＥ情報を取り出す（retrieve）。
【００３３】
アタッチリクエストメッセージにトークンが挿入されていれば、新規の（Ｎ）ｅＮＢ２０＿２は、そのトークンを検証して、ＵＥ１０を認証することができる。
【００３４】
ステップＳ２３において、ＵＥ１０及び新規のＮｅＮＢ２０＿２はセキュリティを確立する。
【００３５】
ステップＳ２４において、新規のＮｅＮＢ２０＿２は、ａｌｇ−ＩＤ、フレッシュ値、及び現在のＵＥリストと共に、アタッチアクセプトメッセージを、ＵＥ１０に送信する。
【００３６】
３．ＰＳ ＵＥがＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮを離脱する
ＵＥ１０がＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮ１を離脱していれば、（Ｎ）ｅＮＢ２０は、ＰＳ ＵＥリストをアップデートし、このアップデートされたリストを最新のリストとして使用して、その最新のリストに応じたＵＥ認可を実行する。
【００３７】
具体的には、図４に示されるステップＳ３１において、ＵＥ１０は、デタッチリクエストメッセージ（Detach Request message）を（Ｎ）ｅＮＢ２０に送信する。
【００３８】
ステップＳ３２において、（Ｎ）ｅＮＢ２０は、上述のキーを除去（remove）し、ＰＳ ＵＥリストをアップデートする。
【００３９】
ステップＳ３３において、（Ｎ）ｅＮＢ２０は、デタッチアクセプトメッセージ（Detach Accept message）をＵＥ１０に送信する。
【００４０】
なお、本発明は、上述の実施の形態に限られたものではなく、請求項の記述に基づいて当業者が様々な変更をすることができることは明らかである。
【００４１】
上述の実施の形態の全部又は一部は、以下の付記のようにも記載されうるが、以下には限られない。
【００４２】
（付記１）
メッセージフロー自体は新規である。
（付記２）
（Ｎ）ｅＮＢは、認可されたＰＳ ＵＥがＩｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮに参加又は離脱するときに、ＰＳ ＵＥリストをアップデートする。
（付記３）
（Ｎ）ｅＮＢは、予め設定された認証情報に基づいて、ＵＥの認証を実行する。
（付記４）
（Ｎ）ｅＮＢは、ＵＥが以前にアタッチしていた（Ｎ）ｅＮＢから情報を取り出す。
（付記５）
（Ｎ）ｅＮＢは、予め設定されたＩＯＰＳグループキーに基づいて、ＵＥとのセキュアな接続を確立する。
【００４３】
この出願は、２０１４年１２月２２日に出願された日本特許出願２０１４−２５９１４１を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【００４４】
１  Ｉｓｏｌａｔｅｄ Ｅ−ＵＴＲＡＮ
１０，１０＿１〜１０＿３  ＵＥ
２０，２０＿１，２０＿２  （Ｎ）ｅＮＢ
【図１】
0006372622.tif 000002
【図２】
0006372622.tif 000003
【図３】
0006372622.tif 000004
【図４】
0006372622.tif 000005