(57)【要約】通信方式の異なる通信方式を用いてDual connectivityを実現する際に、高度なセキュリティを提供することができる通信システムを提供することを目的とする。本発明にかかる通信システムは、通信端末（３０）と第２の通信方式を用いて通信する基地局（２０）を備える通信システムであって、基地局（２０）にアクセスするための端末能力に関する情報を有する通信端末（３０）と、通信端末（３０）と第１の通信方式を用いて通信する基地局（１０）であって、端末能力に関する情報および通信端末（３０）が与えられた基地局（２０）へのアクセス権限に関する情報を受信する受信部と、端末能力に関する情報およびアクセス権限に関する情報に基づいて、通信端末（３０）への接続を要求するメッセージを基地局（２０）に送信する送信部と、を含む基地局（１０）と、を備える
2018079692.tif 000002
【特許請求の範囲】
【請求項１】
通信端末と第２の通信方式を用いて通信する第２の基地局を備える通信システムであって、
前記第２の基地局にアクセスするための端末能力に関する情報を有する前記通信端末と、
前記通信端末と第１の通信方式を用いて通信する第１の基地局であって、前記端末能力に関する情報および前記通信端末が与えられた前記第２の基地局へのアクセス権限に関する情報を受信する受信部と、前記端末能力に関する情報および前記アクセス権限に関する情報に基づいて、前記通信端末への接続を要求するメッセージを前記第２の基地局に送信する送信部と、を含む前記第１の基地局と、を備える、通信システム。
【請求項２】
前記アクセス権限に関する情報を前記第１の基地局に送信するコアネットワークをさらに備える、請求項１に記載の通信システム。
【請求項３】
前記第２の基地局は、５ＧのＮＲ（New Radio）である、請求項１又は２に記載の通信システム。
【請求項４】
前記端末能力は、セキュリティに関する能力を含む、請求項１乃至３のいずれか１項に記載の通信システム。
【請求項５】
通信端末と第１の通信方式を用いて通信する基地局であって、
前記通信端末が第２の通信方式を用いて通信する第２の基地局にアクセスするための端末能力に関する情報および前記通信端末が与えられた前記第２の基地局へのアクセス権限に関する情報を受信する受信部と、
前記端末能力に関する情報および前記アクセス権限に関する情報に基づいて、前記通信端末への接続を要求するメッセージを前記第２の基地局に送信する送信部と、を備える基地局。
【請求項６】
前記受信部は、前記アクセス権限に関する情報をコアネットワークから受信する、請求項５に記載の基地局。
【請求項７】
前記第２の基地局は、５ＧのＮＲ（New Radio）である、請求項５又は６に記載の基地局。
【請求項８】
前記端末能力は、セキュリティに関する能力を含む、請求項５乃至７のいずれか１項に記載の基地局。
【請求項９】
通信端末と第１の通信方式を用いて通信する基地局の制御方法であって、
前記通信端末が第２の通信方式を用いて通信する第２の基地局にアクセスするための端末能力に関する情報および前記通信端末が与えられた前記第２の基地局へのアクセス権限に関する情報を受信し、
前記端末能力に関する情報および前記アクセス権限に関する情報に基づいて、前記通信端末への接続を要求するメッセージを前記第２の基地局に送信する、基地局の制御方法。
【請求項１０】
前記アクセス権限に関する情報は、コアネットワークから送信される、請求項９に記載の基地局の制御方法。
【請求項１１】
前記第２の基地局は、５ＧのＮＲ（New Radio）である、請求項９又は１０に記載の基地局の制御方法。
【請求項１２】
前記端末能力は、セキュリティに関する能力を含む、請求項９乃至１１のいずれか１項に記載の基地局の制御方法。
【請求項１３】
通信端末と第１の通信方式を用いて通信するコンピュータに実行させるプログラムが格納された非一時的なコンピュータ可読媒体であって、
前記通信端末が第２の通信方式を用いて通信する第２の基地局にアクセスするための端末能力に関する情報および前記通信端末が与えられた前記第２の基地局へのアクセス権限に関する情報を受信し、
前記端末能力に関する情報および前記アクセス権限に関する情報に基づいて、前記通信端末への接続を要求するメッセージを前記第２の基地局に送信することをコンピュータに実行させるプログラムが格納された非一時的なコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信システム、基地局、制御方法、及びコンピュータ可読媒体に関する。
【背景技術】
【０００２】
現在、通信端末と基地局との間において用いられる無線通信方式として、３ＧＰＰ（3rd Generation Partnership Project）において規定された規格であるＬＴＥ（Long Term Evolution）が普及している。ＬＴＥは、高速及び大容量の無線通信を実現するために用いられる無線通信方式である。また、ＬＴＥを用いる無線ネットワークを収容するコアネットワークとして、３ＧＰＰにおいて、ＳＡＥ（System Architecture Evolution）もしくはＥＰＣ（Evolved Packet Core）等と称されるパケットネットワークが規定されている。【０００３】
通信端末は、ＬＴＥを用いた通信サービスを利用するために、コアネットワークへの登録が必要とされる。通信端末をコアネットワークへ登録する手順として、３ＧＰＰにおいてAttach Procedureが規定されている。コアネットワーク内に配置されているＭＭＥ（Mobility Management Entity）は、Attach Procedureにおいて通信端末の識別情報を用いて通信端末の認証処理等を実行する。ＭＭＥは、加入者情報を管理するＨＳＳ（Home Subscriber Server）等と連携し、通信端末の認証処理を行う。通信端末の識別情報として、例えば、IMEISV（International Mobile Equipment Identity）もしくはIMSI（International Mobile Subscriber Identity）等が用いられる。【０００４】
近年、３ＧＰＰにおいて、ＩｏＴ（Internet of Things）サービスに関する検討が進められている。ＩｏＴサービスには、ユーザの操作を必要とせず、自律的に通信を実行する端末（以下、ＩｏＴ端末とする）が数多く用いられる。そこで、サービス事業者が多くのＩｏＴ端末を用いてＩｏＴサービスを提供するために、通信事業者等が管理するモバイルネットワークにおいて、多くのＩｏＴ端末を効率的に収容することが望まれている。モバイルネットワークは、無線ネットワーク及びコアネットワークを含むネットワークである。【０００５】
非特許文献１のAnnex Bにおいて、ネットワークスライシングを適用したコアネットワークの構成が記載されている。ネットワークスライシングは、多くのＩｏＴ端末を効率的に収容するために、提供するサービス毎にコアネットワークを分割する技術である。また、5.1節において、分割されたそれぞれのネットワーク（ネットワークスライスシステム）には、カスタマイズや最適化が必要になることが記載されている。【０００６】
ネットワークスライシングを適用したシステムは、例えば、NextGen（Next Generation） Systemとも称される。また、NextGen Systemにおいて用いられる無線ネットワークは、NG（Next Generation） RAN（Radio Access Network）と称されてもよい。【０００７】
また、非特許文献１のAnnex Jにおいて、E-UTRA（Evolved Universal Terrestrial Radio Access）とNR（New Radio）とを用いたDual connectivityに関する構成が開示されている。例えば、NRは、E-UTRA以降の次世代の無線ネットワークに用いられる基地局に相当する装置である。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】3GPP TR23.799 V1.0.2 (2016-9)
【非特許文献２】3GPP TR33.899 V0.5.0 (2016-10)
【発明の概要】
【発明が解決しようとする課題】
【０００９】
E-UTRAとNRとを用いてDual connectivityを実現する場合に、二つのE-UTRAを用いた場合と同様に、高度なセキュリティを実現する必要がある。しかし、NRを含むNextGen Systemにおいては、セキュリティ処理に関連する様々な機能が導入されており、現在３ＧＰＰに規定されているセキュリティ処理手順を、NextGen Systemにそのまま適用することができないという問題がある。具体的に、非特許文献２において、ＡＲＰＦ（Authentication Credential Repository and Processing Function）、ＡＵＳＦ（Authentication Server Function）、ＳＥＡＦ（Security Anchor Function）、及びＳＣＭＦ（Security Context Management Function）等をNextGen Systemに導入することが検討されている。【００１０】
本発明の目的は、異なる通信方式を用いてDual connectivityを実現する際に、高度なセキュリティを提供することができる通信システム、基地局、制御方法、及びプログラムに関するを提供することにある。
【課題を解決するための手段】
【００１１】
本発明の第１の態様にかかる通信システムは、通信端末と第２の通信方式を用いて通信する第２の基地局を備える通信システムであって、前記第２の基地局にアクセスするための端末能力に関する情報を有する前記通信端末と、前記通信端末と第１の通信方式を用いて通信する第１の基地局であって、前記端末能力に関する情報および前記通信端末が与えられた前記第２の基地局へのアクセス権限に関する情報を受信する受信部と、前記端末能力に関する情報および前記アクセス権限に関する情報に基づいて、前記通信端末への接続を要求するメッセージを前記第２の基地局に送信する送信部と、を含む前記第１の基地局と、を備える。【００１２】
本発明の第２の態様にかかる基地局は、通信端末と第１の通信方式を用いて通信する基地局であって、前記通信端末が第２の通信方式を用いて通信する第２の基地局にアクセスするための端末能力に関する情報および前記通信端末が与えられた前記第２の基地局へのアクセス権限に関する情報を受信する受信部と、前記端末能力に関する情報および前記アクセス権限に関する情報に基づいて、前記通信端末への接続を要求するメッセージを前記第２の基地局に送信する送信部と、を備える。【００１３】
本発明の第３の態様にかかる制御方法は、通信端末と第１の通信方式を用いて通信する基地局の制御方法であって、前記通信端末が第２の通信方式を用いて通信する第２の基地局にアクセスするための端末能力に関する情報および前記通信端末が与えられた前記第２の基地局へのアクセス権限に関する情報を受信し、前記端末能力に関する情報および前記アクセス権限に関する情報に基づいて、前記通信端末への接続を要求するメッセージを前記第２の基地局に送信する。【００１４】
本発明の第４の態様にかかるプログラムは、通信端末と第１の通信方式を用いて通信するコンピュータに実行させるプログラムであって、前記通信端末が第２の通信方式を用いて通信する第２の基地局にアクセスするための端末能力に関する情報および前記通信端末が与えられた前記第２の基地局へのアクセス権限に関する情報を受信し、前記端末能力に関する情報および前記アクセス権限に関する情報に基づいて、前記通信端末への接続を要求するメッセージを前記第２の基地局に送信することをコンピュータに実行させる。
【発明の効果】
【００１５】
本発明により、異なる通信方式を用いてDual connectivityを実現する際に、高度なセキュリティを提供することができる通信システム、基地局、制御方法、及びプログラムに関するを提供することができる。
【図面の簡単な説明】
【００１６】
【図１】実施の形態１にかかる通信システムの構成図である。
【図２】実施の形態２にかかる通信システムの構成図である。
【図３】実施の形態２にかかる通信システムの構成図である。
【図４】実施の形態２にかかるてＮＲを介して送信されるユーザデータに適用されるセキュリティ鍵を示す図である。
【図５】実施の形態２にかかるセキュリティ鍵の階層構成を示す図である。
【図６】実施の形態２にかかるInitial attach procedureを説明する図である。
【図７】実施の形態２にかかるDual connectivity procedureを説明する図である。
【図８】実施の形態２にかかるDual connectivity procedureを説明する図である。
【図９】実施の形態２にかかるDual connectivity procedureを説明する図である。
【図１０】実施の形態２にかかるDual connectivity procedureを説明する図である。
【図１１】実施の形態３にかかるDual connectivity procedureを説明する図である。
【図１２】実施の形態３にかかるDual connectivity procedureを説明する図である。
【図１３】実施の形態３にかかるDual connectivity procedureを説明する図である。
【図１４】実施の形態３にかかるDual connectivity procedureを説明する図である。
【図１５】実施の形態３にかかるDual connectivity procedureを説明する図である。
【図１６】実施の形態４にかかるUE network capabilityのフォーマットを説明する図である。
【図１７】実施の形態４にかかるＭＭＥ及びＨＳＳに格納されている情報リストを説明する図である。
【図１８】実施の形態４にかかるUE security capabilityのフォーマットを説明する図である。
【図１９】実施の形態４にかかるInitial Context setup requestメッセージのフォーマットを説明する図である。
【図２０】実施の形態４にかかるHandover Resticrion List IEを説明する図である。
【図２１】実施の形態４にかかるDual connectivity procedureを説明する図である。
【図２２】実施の形態４にかかるUE’s capability及びNR Subscriptionを要求する方法を説明する図である。
【図２３】実施の形態４にかかるUE’s capability及びNR Subscriptionを要求する方法を説明する図である。
【図２４】実施の形態１乃至３にかかるセキュリティ鍵の導出を説明する図である。
【図２５】実施の形態１乃至３にかかるセキュリティ鍵の導出を説明する図である。
【発明を実施するための形態】
【００１７】
（実施の形態１）
以下、図面を参照して本発明の実施の形態について説明する。図１を用いて実施の形態１にかかる通信システムの構成例について説明する。図１の通信システムは、基地局１０、基地局２０、及び通信端末３０を有している。
【００１８】
基地局１０、基地局２０、及び通信端末３０は、プロセッサがメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。プロセッサは、例えば、マイクロプロセッサ、ＭＰＵ（Micro Processing Unit）、もしくはＣＰＵ（Central Processing Unit）であってもよい。メモリは、揮発性メモリもしくは不揮発性メモリであってもよく、揮発性メモリ及び不揮発性メモリの組み合わせによって構成されてもよい。プロセッサは、以降の図面を用いて説明されるアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。
【００１９】
通信端末３０は、携帯電話端末、スマートフォン端末、ＩｏＴ端末等であってもよい。通信端末３０は、基地局２０にアクセスするための端末能力（UE NR capability）に関する情報を有していてもよい。端末能力は、セキュリティに関する能力を含んでいてもよい。
【００２０】
基地局１０は、第１の通信方式を用いて通信端末３０と通信する。第１の通信方式は、例えば、３ＧＰＰにおいて規格が定められている無線通信方式であってもよく、他の標準化団体において規格が定められている無線通信方式であってもよい。もしくは、第１の通信方式は、無線ＬＡＮ通信であってもよい。基地局１０は、コアネットワークに接続される。コアネットワークは、通信端末３０が与えられた基地局２０へのアクセス権限に関する情報を、基地局１０に送信してもよい。
【００２１】
基地局２０は、第２の通信方式を用いて通信端末３０と通信する。第２の通信方式は、第１の通信方式と異なる通信方式である。第２の通信方式は、例えば、３ＧＰＰにおいて規格が定められているE-UTRAもしくはLTE（Long Term Evolution）以降の、次世代の通信方式であってもよい。基地局２０は、５Ｇ（Generation）（NextGen（Next Generation）と称されても良い。）のＮＲ（New Radio）であってもよい。例えば、通信端末３０は、基地局１０との通信を継続しながら、さらに、基地局２０とも通信する。通信端末３０が、基地局１０及び基地局２０と実質的に同じタイミングに通信する通信方式を、Dual connectivityと称してもよい。
【００２２】
基地局１０は、通信端末３０から送信されたUE（User Equipment） capabilityを含む第１のメッセージを受信する。例えば、基地局１０は、UE capabilityを用いて通信端末３０が基地局２０と通信することができるか否かを判定する。つまり、基地局１０は、通信端末３０が基地局２０を用いてDual connectivityを行うことができるか否かを判定する。基地局１０は、UE capabilityを含む第２のメッセージを送信し、UE capabilityに基づいて決定された、通信端末３０と基地局２０との通信に用いられるセキュリティ鍵に関する情報を通信端末３０に送信する。
【００２３】
UE capabilitiesは、例えば、通信端末３０がサポートしている通信方式を示す識別情報であってもよい。UE capabilitiesは、少なくとも１つの通信方式を示す識別情報を含んでもよい。UE capabilitiesは、通信端末３０が基地局２０にアクセスするための端末能力に関する情報を含んでいても良い。端末能力は、セキュリティに関する能力を含んでいてもよい。
【００２４】
基地局１０において、通信端末３０が基地局２０と通信することができると判定された場合、基地局２０は、基地局１０が通信端末３０との通信に用いる第１のセキュリティ鍵とは異なる第２のセキュリティ鍵を用いて通信端末３０と通信する。第２のセキュリティ鍵は、UE capabilitiesに基づいて導出される。
【００２５】
セキュリティ鍵は、例えば、基地局１０もしくは基地局２０と通信端末３０との間において伝送されるデータの暗号化及び完全性保証に用いられる鍵であってもよい。
【００２６】
以上説明したように、図１の通信システムは、基地局１０が通信端末３０と通信中に、通信端末３０が基地局２０を用いてDual connectivityを行えるかを、UE capabilitiesに基づいて判定することができる。さらに、基地局２０は、基地局１０が通信端末３０との通信に用いるセキュリティ鍵とは異なるセキュリティ鍵を用いて、通信端末３０と通信することができる。言い換えると、通信端末３０は、基地局１０との間の通信には第１のセキュリティ鍵を用い、基地局２０との間の通信には第２のセキュリティ鍵を用いてDual connectivityを行うことができる。その結果、通信端末３０は、それぞれの基地局との通信においてセキュリティを確保した状態でDual connectivityを行うことができる。
【００２７】
（実施の形態２）
続いて、図２を用いて実施の形態２にかかる通信システムの構成例について説明する。図２の通信システムは、ＵＥ３１、ｅＮＢ（Evolved Packet Core）１２、ＮＲ２１、及びＥＰＣ４０を有している。図２のＵＥ３１は、図１の通信端末３０に相当する。ｅＮＢ（evolved Node B）１２は、図１の基地局１０に相当する。ＮＲ２１は、図１の基地局２０に相当する。ＵＥ３１は、３ＧＰＰにおいて用いられる通信端末の総称である。ｅＮＢ１２は、無線通信方式としてＬＴＥをサポートする基地局である。ＮＲ２１は、ＬＴＥ以降の無線通信方式をサポートする基地局に相当する。ＬＴＥ以降の無線通信方式をサポートする基地局は、例えば、５ＧのＮＲである、ｇＮＢ２２であってもよい。
【００２８】
図２は、ＵＥ３１が、ｅＮＢ１２及びＮＲ２１との間においてDual connectivityを行うことを示している。ＵＥ３１とｅＮＢ１２との間のリファレンスポイントは、3GPPにおいてLTE Uuと定められている。リファレンスポイントは、インタフェースと称されてもよい。
【００２９】
また、図２においては、ＵＥ３１がDual connectivityを行う際に、ｅＮＢ１２が、ＮＲ２１を追加するか否かを判定する。言い換えると、ｅＮＢ１２は、ＵＥ３１と通信を行っている最中に、ＵＥ３１に関するDual connectivityを実現するために、ＮＲ２１をＵＥ３１の二つ目の接続先として追加するか否かを判定する。
【００３０】
ｅＮＢ１２は、ＮＲ２１を追加するか否かの判定を行うために、ＥＰＣ４０を構成するノード装置と通信を行う。すなわち、ｅＮＢ１２は、コアネットワークであるＥＰＣ４０に接続される。ＥＰＣ４０を構成するノード装置は、例えば、３ＧＰＰにおいて定められているＭＭＥ（Mobility Management Entity）であってもよい。ＵＥ３１は、ＥＰＣ４０を構成するＭＭＥとの間において、NAS（Non Access Stratum） Signallingを実行する。NAS Signallingは、ＵＥ３１とＭＭＥとの間において伝送される制御メッセージである。ｅＮＢ１２とＥＰＣ４０との間において制御メッセージを伝送するために用いられるリファレンスポイントは、３ＧＰＰにおいて、S1-MMEと定められている。
【００３１】
また、ｅＮＢ１２は、ＵＥ３１からLTE Uuリファレンスポイントを介して送信されたユーザデータ（U（User） Planeデータ）をＥＰＣ４０へ送信するとともに、ＮＲ２１を介してＵＥ３１から送信されたユーザデータをＥＰＣ４０へ送信する。また、ｅＮＢ１２は、ＥＰＣ４０から送信されたＵＥ３１を宛先とするユーザデータをLTE Uuリファレンスポイントを介してＵＥ３１へ送信するとともに、ＮＲ２１を介してＵＥ３１へ送信する。ＥＰＣ４０においてユーザデータを中継するノード装置は、例えば、Ｓ−ＧＷ（Serving-Gateway）であってもよい。ユーザデータを伝送するために、ｅＮＢ１２とＥＰＣ４０との間においてユーザデータを伝送するために用いられるリファレンスポイントは、３ＧＰＰにおいてS1-Uと定められている。
【００３２】
続いて、図３を用いて、図２と異なる通信システムの構成例について説明する。図３は、ＮＲ２１とＥＰＣ４０との間においてユーザデータを伝送するために用いられるリファレンスポイントとして、S1−Uが定められている点において、図２と異なる。図３において、ＮＲ２１は、ＵＥ３１から送信されたユーザデータを、ＥＰＣ４０との間において定められているS1-Uリファレンスポイントを介してＥＰＣ４０へ送信する。また、ＥＰＣ４０は、ＵＥ３１を宛先とするユーザデータを、ｅＮＢ１２及びＮＲ２１へ振り分けて送信する。ＮＲ２１は、ＥＰＣ４０から送信されたユーザデータをＵＥ３１へ送信する。
【００３３】
続いて、図４を用いてＮＲ２１を介して送信されるユーザデータに適用されるセキュリティ鍵について説明する。図４においては、ＮＲ２１として、ｇＮＢ２２を用いて説明する。ｇＮＢ２２は、ＮＲ２１において用いられる基地局に相当する。
【００３４】
図４において、ＵＥ３１とｅＮＢ１２との間、ｅＮＢ１２とＭＭＥ４１との間、ＭＭＥ４１とＳ−ＧＷ４２との間、及びｅＮＢ１２とｇＮＢ２２との間に示されている点線は、制御メッセージ（C（Control）-Planeデータ）が伝送されることを示している。また、ＵＥ３１とｅＮＢ１２との間、ＵＥ３１とｇＮＢ２２との間、ｅＮＢ１２とＳ−ＧＷ４２との間、ｇＮＢ２２とＳ−ＧＷ４２との間に示されている実線は、ユーザデータ（U-Planeデータ）が伝送されることを示している。
【００３５】
また、セキュリティアンカー（security anchor）としてｇＮＢ２２が用いられる場合、ＵＥ３１とｇＮＢ２２との間において送信されるユーザデータには、セキュリティ鍵ＫＡＮが用いられる。さらに、セキュリティアンカーとしてＳ−ＧＷ４２が用いられる場合、ＵＥ３１とＳ−ＧＷ４２との間において送信されるユーザデータには、セキュリティ鍵ＫＵＰが用いられる。セキュリティアンカーは、例えば、無線区間において伝送されないセキュリティ鍵を有し、無線区間において伝送されるデータの暗号化もしくは完全性保証に用いられるセキュリティ鍵を導出するノード装置であってもよい。
【００３６】
続いて、図５を用いて、図２もしくは図３に示す構成を含む通信システムにおいて用いられるセキュリティ鍵の階層構成について説明する。
【００３７】
ＵＳＩＭ（Universal Subscriber identification Module）は、ＵＥ３１に関する加入者情報を格納するモジュールであってもよい。ＡｕＣ（Authentication Center）は、コアネットワーク内に配置され、セキュリティに関する処理を実行するノード装置である。ＵＳＩＭ及びＡｕＣは、それぞれセキュリティ鍵Ｋを有する。
【００３８】
ＵＳＩＭ及びＡｕＣは、セキュリティ鍵Ｋから暗号化鍵ＣＫ（Cipher Key）及び完全性保証鍵ＩＫ（Integrity Key）を導出する。ＵＳＩＭは、暗号化鍵ＣＫ及び完全性保証鍵ＩＫをＵＥ３１へ出力し、ＡｕＣは、暗号化鍵ＣＫ及び完全性保証鍵ＩＫをＨＳＳ（Home Subscriber Server）へ送信する。ＨＳＳは、ＵＥに関する加入者情報を管理するノード装置である。
【００３９】
ＵＥ３１及びＨＳＳは、暗号化鍵ＣＫ及び完全性保証鍵ＩＫからセキュリティ鍵ＫＡＳＭＥを導出する。ＨＳＳは、セキュリティ鍵ＫＡＳＭＥをＭＭＥ４１へ送信する。ＵＥ３１及びＭＭＥ４１は、セキュリティ鍵ＫＡＳＭＥからセキュリティ鍵ＫＮＡＳｅｎｃ、セキュリティ鍵ＫＮＡＳｉｎｔ、セキュリティ鍵ＫｅＮＢ／ＮＨ、及びセキュリティ鍵ＫＵＰを生成する。
【００４０】
セキュリティ鍵ＫＮＡＳｅｎｃは、ＵＥ３１とＭＭＥ４１との間において伝送されるＮＡＳメッセージの暗号化に用いられる。セキュリティ鍵ＫＮＡＳｉｎｔは、ＵＥ３１とＭＭＥ４１との間において伝送されるＮＡＳメッセージの完全性保証に用いられる。
【００４１】
ＭＭＥ４１は、セキュリティ鍵ＫｅＮＢ／ＮＨをｅＮＢ１２へ送信し、セキュリティ鍵ＫＵＰをＳ−ＧＷ４２へ送信する。
【００４２】
ＵＥ３１及びｅＮＢ１２は、セキュリティ鍵ＫｅＮＢ／ＮＨからセキュリティ鍵ＫＵＰｉｎｔ、セキュリティ鍵ＫＵＰｅｎｃ、セキュリティ鍵ＫＲＲＣｉｎｔ、及びセキュリティ鍵ＫＲＲＣｅｎｃを導出する。セキュリティ鍵ＫＵＰｉｎｔは、ユーザデータの暗号化に用いられる。セキュリティ鍵ＫＵＰｅｎｃは、ユーザデータの完全性保証に用いられる。セキュリティ鍵ＫＲＲＣｅｎｃは、ＲＲＣ（Radio Resource Control）メッセージの暗号化に用いられる。セキュリティ鍵ＫＲＲＣｉｎｔは、ＲＲＣメッセージの完全性保証に用いられる。
【００４３】
セキュリティ鍵ＫＵＰｅｎｃ及びセキュリティ鍵ＫＵＰｉｎｔは、セキュリティアンカーとしてＳ−ＧＷ４２が用いられる場合、Ｓ−ＧＷ４２において導出されてもよい。言い換えると、セキュリティアンカーとしてＳ−ＧＷ４２が用いられる場合、Ｓ−ＧＷ４２が、セキュリティ鍵ＫＵＰからセキュリティ鍵ＫＵＰｅｎｃ及びセキュリティ鍵ＫＵＰｉｎｔを導出してもよい。
【００４４】
セキュリティ鍵ＫＵＰｅｎｃ及びセキュリティ鍵ＫＵＰｉｎｔは、セキュリティアンカーとしてｇＮＢ２２が用いられる場合、ｇＮＢ２２において導出されてもよい。言い換えると、セキュリティアンカーとしてｇＮＢ２２が用いられる場合、ｇＮＢ２２が、セキュリティ鍵ＫＡＮからセキュリティ鍵ＫＵＰｅｎｃ及びセキュリティ鍵ＫＵＰｉｎｔを導出してもよい。ｅＮＢ１２は、セキュリティ鍵ＫｅＮＢ／ＮＨからセキュリティ鍵ＫＡＮを導出し、セキュリティ鍵ＫＡＮをｇＮＢ２２へ送信してもよい。
【００４５】
もしくは、セキュリティ鍵ＫＡＮは、セキュリティ鍵ＫＮＧから導出されてもよい。セキュリティ鍵ＫＮＧは、セキュリティ鍵Ｋから導出されてもよい。また、セキュリティ鍵ＫＮＧは、暗号化鍵ＣＫ及び完全性保証鍵ＩＫから導出されてもよく、セキュリティ鍵ＫＡＳＭＥから導出されてもよい。セキュリティ鍵ＫＮＧは、NextGen Systemにおいて用いられるセキュリティ鍵である。
【００４６】
また、セキュリティ鍵ＫＵＰは、セキュリティ鍵ＫｅＮＢ／ＮＨから導出されてもよい。さらに、セキュリティ鍵ＫＡＮは、セキュリティ鍵ＫＡＳＭＥから導出されてもよい。
【００４７】
また、ｅＮＢ１２において用いられるセキュリティ鍵ＫＵＰｅｎｃ及びセキュリティ鍵ＫＵＰｉｎｔは、ｇＮＢ２２において用いられるセキュリティ鍵ＫＵＰｅｎｃ及びセキュリティ鍵ＫＵＰｉｎｔと異なる。さらに、ｅＮＢ１２において用いられるセキュリティ鍵ＫＵＰｅｎｃ及びセキュリティ鍵ＫＵＰｉｎｔは、Ｓ−ＧＷ４２において用いられるセキュリティ鍵ＫＵＰｅｎｃ及びセキュリティ鍵ＫＵＰｉｎｔと異なる。例えば、ｅＮＢ１２において用いられるセキュリティ鍵ＫＵＰｅｎｃ及びセキュリティ鍵ＫＵＰｉｎｔは、ｇＮＢ２２もしくはＳ−ＧＷ４２において用いられるセキュリティ鍵ＫＵＰｅｎｃ及びセキュリティ鍵ＫＵＰｉｎｔを導出する際に用いるパラメータと異なるパラメータを用いて導出されてもよい。パラメータは、例えば、ネットワークスライスを識別するＮＳ（Network Slice） ＩＤ等であってもよい。
【００４８】
続いて、図６を用いて実施の形態２にかかるInitial attach procedureについて説明する。はじめに、ＵＥ３１は、UE capabilitiesを含むAttach requestメッセージをｅＮＢ１２へ送信する（Ｓ１１）。また、Attach requestメッセージは、ｇＮＢ２２において用いられる、NRに関する能力及びセキュリティアルゴリズムを含んでもよい。次に、ｅＮＢ１２は、UE capability check requestを含むAttach requestメッセージをＭＭＥ４１へ送信する（Ｓ１２）。ｅＮＢ１２からＭＭＥ４１へ送信されるAttach requestメッセージは、ｇＮＢ２２において用いられる、NRに関する能力及びセキュリティアルゴリズムを含んでもよい。
【００４９】
次に、ＵＥ３１とＭＭＥ４１との間において、AKA（Authentication and Key Agreement） & NAS security establishmentが実行される（Ｓ１３）。AKA & NAS security establishmentが実行されることによって、ＵＥ３１及びＭＭＥ４１において、セキュリティ鍵が共有される。また、AKA & NAS security establishmentは、以前に既に実施されている場合には、省略されてもよい。
【００５０】
次に、ＭＭＥ４１は、UE capabilities and NR subscription checkを実施する（Ｓ１４）。例えば、ＭＭＥ４１は、ＨＳＳもしくは他のネットワークノードから、ＵＥに関する加入者情報を取得及び保持し、取得した加入者情報を用いて、UE capabilities and NR subscription checkを実施してもよい。
【００５１】
UE capabilities check and NR subscription checkは、例えば、ＵＥ３１において、ＵＥ３１がサポートしている通信方式を利用することが認められているか否かを判定することであってもよい。例えば、ＭＭＥ４１は、ＵＥ３１がサポートしている複数の通信方式のうち、一部の通信方式の利用が認められていると判定してもよい。具体的には、ＭＭＥ４１は、ＵＥ３１がNRへのアクセス権限を与えられているか否か、さらに、ＵＥ３１のユーザが、NRが提供するサービスに登録しているか否かを判定してもよい。
【００５２】
次に、ＭＭＥ４１は、ｅＮＢ１２へAttach response with UE capability check responseを送信し、ｅＮＢ１２は、ＵＥ３１へAttach response with UE capability check responseを送信する（Ｓ１５）。Attach response with UE capability check responseは、ＵＥ３１において利用することが認められている通信方式を示す情報を含んでもよい。ＭＭＥ４１は、Attach response with UE capability check responseを含むInitial Context setup requestメッセージをｅＮＢ１２へ送信してもよい。さらに、ｅＮＢ１２は、ＵＥ３１へ、Attach response with UE capability check responseを含むRRC connection reconfigurationメッセージを送信してもよい。
【００５３】
次に、ｅＮＢ１２は、ＵＥ３１がＮＲにアクセスするための端末能力（UE capabilities）及びＵＥ３１が与えられたＮＲへのアクセス権限に関する情報をメモリ等へ格納する（Ｓ１６）。ｅＮＢ１２がメモリへ格納するUE capabilitiesは、例えば、ステップＳ１１においてＵＥ３１から送信された１以上の通信方式のうち、利用可能と認められた一部の通信方式を含む情報であってもよい。このように、Initial Attachのフェーズにおいて、ＵＥ３１に近い距離にあるノード（例えばｅＮＢ１２）が、ＮＲにアクセスするための端末能力（UE capabilities）及びＮＲへのアクセス権限に関する情報を格納することによって、セキュリティ処理を簡易にさらに素早く実行することができる。
【００５４】
続いて、図７を用いてDual connectivity procedureについて説明する。はじめに、ＵＥ３１、ｅＮＢ１２、及びＭＭＥ４１において、図６において説明したInitial attach procedureが実行されているとする（Ｓ２１）。次に、ＵＥ３１は、RRC connection establishmentメッセージをｅＮＢ１２へ送信する（Ｓ２２）。RRC connection establishmentメッセージは、UE req.algo./KDF IDｓ及びUE capabilityを含む。UE req.algo./KDF IDｓは、ＵＥ３１が要求する、暗号化及び完全性保証に用いるアルゴリズム及び使用するＫＤＦ（Key Derivation Function）の識別情報である。ＵＥ３１が要求する暗号化及び完全性保証に用いるアルゴリズム等の識別情報は、ＵＥ３１が指定する暗号化及び完全性保証に用いるアルゴリズム等の識別情報と言い換えられてもよい。UE req.algo./KDF IDｓは、複数のアルゴリズム及びＫＤＦの識別情報を含んでもよい。UE capabilityは、ＵＥ３１がｇＮＢ２２との通信に用いる通信方式を示す情報であってもよい。
【００５５】
次に、ｅＮＢ１２は、ｇＮＢ２２を用いたDual connectivityの使用を決定するために、ＵＥ３１が、ＮＲへアクセスするための端末能力を持っているか及びＮＲへのアクセス権限を与えられているかを確認する。ｅＮＢ１２は、ＵＥ３１から送信されたUE capabilityが、図６のステップＳ１６において格納したUE capabilitiesに含まれるか否かを判定する（Ｓ２３）。つまり、ｅＮＢ１２は、ｇＮＢ２２のために適切なセキュリティアルゴリズムを選択するためのセキュリティ処理を開始する前に、ＵＥ３１がＮＲへアクセスするための端末能力を持っているかを判定する。さらに、ＵＥ３１がNRへアクセスするための権限を与えられているかを確認することによって、アクセスする権限のないＵＥによるNRへのアクセスを回避することができる。
【００５６】
ｅＮＢ１２は、ＵＥ３１から送信されたUE capabilityが、図６のステップＳ１６において格納したUE capabilitiesに含まれると判定した場合、セキュリティ鍵ＫＡＮを導出する（Ｓ２４）。
【００５７】
次に、ｅＮＢ１２は、ｇＮＢ２２へgNB addition requestメッセージを送信する（Ｓ２５）。gNB addition requestメッセージは、セキュリティ鍵ＫＡＮ、UE req.algo./KDF IDｓ及びUE capabilityを含む。ｅＮＢ１２は、UE capabilityに基づいて、Dual Connectivityを行うことが可能なｇＮＢ２２を選択し、選択したｇＮＢ２２へgNB addition requestメッセージを送信してもよい。
【００５８】
次に、ｇＮＢ２２は、複数のアルゴリズム及びＫＤＦの中から、UE capabilityに基づいて、ＵＥ３１との通信に用いるアルゴリズム及びＫＤＦを決定する（Ｓ２６）。ｇＮＢ２２において決定されたアルゴリズム及びＫＤＦが、ＵＥ３１によって要求されたアルゴリズム及びＫＤＦと異なる場合、ｅＮＢ１２は、ｇＮＢ２２において決定されたアルゴリズム及びＫＤＦを用いてＫＡＮを導出する。さらに、ｇＮＢ２２は、導出したＫＡＮをｇＮＢ２２へ送信する。次に、ｇＮＢ２２は、ｅＮＢ１２へgNB addition responseメッセージを送信する（Ｓ２７）。gNB addition responseメッセージは、決定されたアルゴリズム及びＫＤＦの識別情報（decided.algo./KDF IDs）を含む。
【００５９】
次に、ｅＮＢ１２は、ＵＥ３１へRRC connection reconfig requestメッセージを送信する（Ｓ２８）。RRC connection reconfig requestメッセージは、gNB addition responseメッセージに含まれていたアルゴリズム及びＫＤＦの識別情報を含む。このようにＫＤＦの識別情報（KDF ID）がＵＥ３１へ送信されることによって、ＵＥ３１とｅＮＢ１２との間において、セキュリティ鍵を直接伝送することなく、ＵＥ３１及びｅＮＢ１２、もしくは、ＵＥ３１及びＭＭＥ４１等において、セキュリティ鍵を導出することができる。
【００６０】
次に、ＵＥ３１は、ｅＮＢ１２へRRC connection reconfig responseメッセージを送信する（Ｓ２９）。次に、ｅＮＢ１２は、ｇＮＢ２２へ、gNB Reconfiguration completeメッセージを送信する（Ｓ３０）。
【００６１】
また、ＵＥ３１は、ステップＳ２９において、RRC connection reconfig responseメッセージを送信した後に、セキュリティ鍵ＫＡＮを導出する（Ｓ３１）。また、ＵＥ３１及びｇＮＢ２２は、セキュリティ鍵ＫＡＮから、ＫＵＰｉｎｔ及びＫＵＰｅｎｃを導出する。その後、ＵＥ３１及びｇＮＢ２２は、暗号化（encryption）及び復号化（decryption）を実行（activation）する（Ｓ３２、Ｓ３３）。
【００６２】
続いて、図８を用いて、図７とは異なるDual connectivity procedureについて説明する。図８について、図７とは異なる内容について主に説明する。
【００６３】
図８のステップＳ４２においては、ＵＥ３１は、UE req.algo./KDF IDsを含まず、UE capabilityを含むRRC connection establishmentメッセージをｅＮＢ１２へ送信する。また、ｅＮＢ１２は、ステップＳ４５において、UE req.algo./KDF IDｓではなく、eNB req.algo./KDF IDsを含むgNB addition requestメッセージをｇＮＢ２２へ送信する。つまり、図８においては、ｅＮＢ１２が要求もしくは指定する、暗号化及び完全性保証に用いるアルゴリズム及び使用するＫＤＦ（Key Derivation Function）の識別情報がgNB addition requestメッセージに含まれる。
【００６４】
その他の処理は、図７の処理と同様であるため詳細な説明を省略する。
【００６５】
続いて、図９を用いて、図７及び図８とは異なるDual connectivity procedureについて説明する。図９について、図７及び図８とは異なる内容について主に説明する。
【００６６】
ステップＳ６１〜Ｓ６３は、図８のステップＳ４１〜Ｓ４３と同様であるため詳細な説明を省略する。
【００６７】
次に、ｅＮＢ１２は、UE req.algo./KDF IDs及びeNB req.algo./KDF IDsを含まず、UE capabilityを含むgNB addition requestメッセージをｇＮＢ２２へ送信する（Ｓ６４）。
【００６８】
次に、ｇＮＢ２２は、複数のアルゴリズム及びＫＤＦの中から、UE capabilityに基づいて、ＵＥ３１との通信に用いるアルゴリズム及びＫＤＦを決定する（Ｓ６５）。次に、ｇＮＢ２２は、ｅＮＢ１２へgNB addition responseメッセージを送信する（Ｓ２７）。gNB addition responseメッセージは、決定されたアルゴリズム及びＫＤＦの識別情報を含む。
【００６９】
次に、ｅＮＢ１２は、セキュリティ鍵ＫＡＮを導出する（Ｓ６７）。次に、ｅＮＢ１２は、導出したセキュリティ鍵ＫＡＮをｇＮＢ２２へ送信する（Ｓ６８）。ステップＳ６９〜Ｓ７４は、図７のステップＳ２８〜Ｓ３３と同様であるため詳細な説明を省略する。
【００７０】
次に、図１０を用いて、図７〜図９とは異なるDual connectivity procedureについて説明する。図１０について、図７〜図９とは異なる内容について主に説明する。
【００７１】
ステップＳ８１〜Ｓ８３は、図８のステップＳ４１〜Ｓ４３と同様であるため詳細な説明を省略する。
【００７２】
次に、ｅＮＢ１２は、gNB addition requestメッセージをｇＮＢ２２へ送信する（Ｓ８４）。gNB addition requestメッセージは、UE capability及びセキュリティ鍵ＫｅＮＢを含む。セキュリティ鍵ＫｅＮＢは、例えばＭＭＥ４１において導出されたセキュリティ鍵ＫｅＮＢであって、ステップＳ８４より前の任意のタイミングにおいて、ＭＭＥ４１からｅＮＢ１２へ送信されていてもよい。
【００７３】
次に、ｇＮＢ２２は、複数のアルゴリズム及びＫＤＦの中から、UE capabilityに基づいて、ＵＥ３１との通信に用いるアルゴリズム及びＫＤＦを決定し、さらに、セキュリティ鍵ＫｅＮＢからセキュリティ鍵ＫＡＮを導出する（Ｓ８５）。
【００７４】
ステップＳ８６〜Ｓ９２は、図７のステップＳ２７〜Ｓ３３と同様であるため詳細な説明を省略する。
【００７５】
以上説明したように、実施の形態２にかかるDual connectivity procedureが実行されることによって、Dual connectivityを実行するために追加されたｇＮＢ２２は、ＵＥ３１とセキュリティ鍵ＫＡＮを共有することができる。これにより、ＵＥ３１が、Dual connectivityを実行する場合に、ＵＥ３１は、ｅＮＢ１２及びｇＮＢ２２のそれぞれとセキュリティ状態を確立して通信を行うことができる。
【００７６】
（実施の形態３）
続いて、図１１を用いて、実施の形態３にかかるDual connectivity procedureについて説明する。実施の形態３においては、コアネットワークに配置されているＭＭＥ４１が、セキュリティ鍵ＫＡＮを導出する処理を説明する。
【００７７】
はじめに、ＵＥ３１、ｅＮＢ１２、及びＭＭＥ４１において、図６において説明したInitial attach procedureが実行されているとする（Ｓ１０１）。次に、ＵＥ３１は、RRC connection establishmentメッセージをｅＮＢ１２へ送信する（Ｓ１０２）。RRC connection establishmentメッセージは、UE req.algo./KDF IDｓ及びUE capabilityを含む。
【００７８】
次に、ｅＮＢ１２は、ＵＥ３１から送信されたUE capabilityが、図６のステップＳ１６において格納したUE capabilitiesに含まれるか否かを判定する（Ｓ１０３）。
【００７９】
次に、ｅＮＢ１２は、ｇＮＢ２２へgNB addition requestメッセージを送信する（Ｓ１０４）。gNB addition requestメッセージは、UE req.algo./KDF IDｓ及びUE capabilityを含む。
【００８０】
次に、ｇＮＢ２２は、複数のアルゴリズム及びＫＤＦの中から、UE capabilityに基づいて、ＵＥ３１との通信に用いるアルゴリズム及びＫＤＦを決定する（Ｓ１０５）。次に、ｇＮＢ２２は、ｅＮＢ１２へgNB addition responseメッセージを送信する（Ｓ１０６）。gNB addition responseメッセージは、決定されたアルゴリズム及びＫＤＦの識別情報（decided.algo./KDF IDs）を含む。
【００８１】
次に、ｅＮＢ１２は、セキュリティ鍵ＫＡＮの導出を要求するために、ＭＭＥ４１へKey requestメッセージを送信する（Ｓ１０７）。Key requestメッセージは、セキュリティ鍵ＫｅＮＢ、決定されたアルゴリズム及びＫＤＦの識別情報（decided.algo./KDF IDs）、及びUE capabilityを含む。次に、ＭＭＥ４１は、ステップＳ１０３においてｅＮＢ１２が行ったように、Key requestメッセージに含まれるUE capabilityが、UE capabilitiesに含まれるか否かを判定する（Ｓ１０８）。なお、ステップＳ１０８の処理は省略されてもよい。ＭＭＥ４１は、UE capabilitiesを、例えば、ＨＳＳから取得してもよい。また、ＭＭＥ４１は、ステップＳ１０８を行うことなく、次のステップＳ１０９に進んでもよい。
【００８２】
次に、ＭＭＥ４１は、Key requestメッセージに含まれるセキュリティ鍵ＫｅＮＢからセキュリティ鍵ＫＡＮを導出する（Ｓ１０９）。ここで、セキュリティ鍵ＫＡＮが、セキュリティ鍵ＫＡＳＭＥから導出される場合、ｅＮＢ１２は、ステップＳ１０７において、Key requestメッセージにセキュリティ鍵ＫｅＮＢを含めなくてもよい。
【００８３】
ｅＮＢ１２は、ステップＳ１０７においてＵＥ３１へKey requestメッセージを送信した後に、ＵＥ３１へRRC connection reconfig requestメッセージを送信する（Ｓ１１０）。RRC connection reconfig requestメッセージは、gNB addition responseメッセージに含まれていたアルゴリズム及びＫＤＦの識別情報を含む。
【００８４】
ここで、ＭＭＥ４１は、セキュリティ鍵ＫＡＮを導出した後に、セキュリティ鍵ＫＡＮをｅＮＢ１２へ送信する（Ｓ１１１）。次に、ｅＮＢ１２は、受信したセキュリティ鍵ＫＡＮをｇＮＢ２２へ送信する（Ｓ１１２）。もし、ＭＭＥ４１とｇＮＢ２２間で直接通信が可能であれば、ＭＭＥ４１は直接セキュリティ鍵ＫＡＮをｇＮＢ２２に送信しても良い。
【００８５】
ステップＳ１１３〜Ｓ１１７は、図７のステップＳ２９〜Ｓ３３と同様であるため詳細な説明を省略する。
【００８６】
続いて、図１２を用いて図１１とは異なるDual connectivity procedureについて説明する。図１２について、図１１とは異なる内容について主に説明する。
【００８７】
図１２のステップＳ１１２においては、ＵＥ３１は、UE req.algo./KDF IDsを含まず、UE capabilityを含むRRC connection establishmentメッセージをｅＮＢ１２へ送信する。また、ｅＮＢ１２は、ステップＳ１１４において、UE req.algo./KDF IDｓではなく、eNB req.algo./KDF IDsを含むgNB addition requestメッセージをｇＮＢ２２へ送信する。つまり、図１２においては、ｅＮＢ１２が要求もしくは指定する、暗号化及び完全性保証に用いるアルゴリズム及び使用するＫＤＦ（Key Derivation Function）の識別情報がgNB addition requestメッセージに含まれる。
【００８８】
その他の処理は、図１１の処理と同様であるため詳細な説明を省略する。
【００８９】
続いて、図１３を用いて図１１及び図１２とは異なるDual connectivity procedureについて説明する。図１３について、図１１及び図１２とは異なる内容について主に説明する。
【００９０】
ステップＳ１３１〜Ｓ１３３は、図１２のステップＳ１１１〜Ｓ１１３と同様であるため詳細な説明を省略する。
【００９１】
次に、ｅＮＢ１２は、UE req.algo./KDF IDs及びeNB req.algo./KDF IDsを含まず、UE capabilityを含むgNB addition requestメッセージをｇＮＢ２２へ送信する（Ｓ１３４）。
【００９２】
次に、ｇＮＢ２２は、複数のアルゴリズム及びＫＤＦの中から、UE capabilityに基づいて、ＵＥ３１との通信に用いるアルゴリズム及びＫＤＦを決定する（Ｓ１３５）。次に、ｇＮＢ２２は、ｅＮＢ１２へgNB addition responseメッセージを送信する（Ｓ１３６）。gNB addition responseメッセージは、決定されたアルゴリズム及びＫＤＦの識別情報を含む。ステップＳ１３７〜Ｓ１４７は、図１２のステップＳ１１７〜Ｓ１２７と同様であるため詳細な説明を省略する。
【００９３】
続いて、図１４を用いて図１１〜図１３とは異なるDual connectivity procedureについて説明する。図１４について、図１１〜図１３とは異なる内容について主に説明する。
【００９４】
ステップＳ１５１〜Ｓ１５３は、図１２のステップＳ１１１〜Ｓ１１３と同様であるため詳細な説明を省略する。
【００９５】
次に、ｅＮＢ１２は、ＭＭＥ４１へgNB addition requestメッセージを送信する（Ｓ１５４）。gNB addition requestメッセージは、セキュリティ鍵ＫｅＮＢ及びUE capabilityを含む。
【００９６】
ステップＳ１５５は、図１１のステップＳ１０８と同様であるため詳細な説明を省略する。次に、ＭＭＥ４１は、複数のアルゴリズム及びＫＤＦの中から、UE capabilityに基づいて、ＵＥ３１との通信に用いるアルゴリズム及びＫＤＦを決定する。さらに、ＭＭＥ４１は、Key requestメッセージに含まれるセキュリティ鍵ＫｅＮＢからセキュリティ鍵ＫＡＮを導出する（Ｓ１５６）。ここで、セキュリティ鍵ＫＡＮが、セキュリティ鍵ＫＡＳＭＥから導出される場合、ｅＮＢ１２は、ステップＳ１５４において、Key requestメッセージにセキュリティ鍵ＫｅＮＢを含めなくてもよい。
【００９７】
次に、ＭＭＥ４１は、セキュリティ鍵ＫＡＮ、決定されたアルゴリズム及びＫＤＦの識別情報（decided.algo./KDF IDs）をｅＮＢ１２へ送信する（Ｓ１５７）。次に、ｅＮＢ１２は、セキュリティ鍵ＫＡＮをｇＮＢ２２へ送信する（Ｓ１５８）。
【００９８】
次に、ｅＮＢ１２は、RRC connection reconfig requestメッセージをＵＥ３１へ送信する。RRC connection reconfi requestメッセージは、決定されたアルゴリズム及びＫＤＦの識別情報（decided.algo./KDF IDs）を含む。ステップＳ１６０〜Ｓ１６４は、図１のステップＳ１１３〜Ｓ１１７と同様であるため詳細な説明を省略する。
【００９９】
続いて、図１５を用いて、セキュリティアンカーとしてＳ−ＧＷ４２が用いられる場合におけるDual connectivity procedureについて説明する。図１５においては、コアネットワークに配置されているＳ−ＧＷ４２が、セキュリティ鍵ＫＵＰを導出する処理を説明する。
【０１００】
ステップＳ１７１〜Ｓ１７４は、図１１のステップＳ１０１〜Ｓ１０４と同様であるため詳細な説明を省略する。
【０１０１】
次に、ｇＮＢ２２は、ｅＮＢ１２から受信したUE req.algo./KDF IDｓの識別情報及びUE capability、さらに、ＫＡＳＭＥをＳ−ＧＷ４２へ送信する（Ｓ１７５）。ＫＡＳＭＥは、ＭＭＥ４１からＳ−ＧＷ４２へ送信されてもよい。
【０１０２】
次に、Ｓ−ＧＷ４２は、複数のアルゴリズムの中から、UE capabilityに基づいて、ＵＥ３１との通信に用いるアルゴリズム及びＫＤＦを決定する（Ｓ１７６）。さらに、ステップＳ１７６において、Ｓ−ＧＷ４２は、セキュリティ鍵ＫＡＳＭＥからセキュリティ鍵ＫＵＰを導出する。
【０１０３】
次に、Ｓ−ＧＷ４２は、決定されたアルゴリズム及びＫＤＦの識別情報（decided.algo./KDF IDs）をＭＭＥ４１へ送信する（Ｓ１７７）。さらに、ＭＭＥ４１は、決定されたアルゴリズム及びＫＤＦの識別情報を、ｇＮＢ２２及びｅＮＢ１２へ送信する（Ｓ１７８、Ｓ１７９）。
【０１０４】
ステップＳ１８０〜Ｓ１８５は、図１１のステップＳ１１０及び１１３〜１１７と同様であるため詳細な説明を省略する。なお、図１１のステップＳ１１７においては、ｇＮＢ２２が暗号化及び完全性保証を実行しているが、図１５のステップＳ１８５においては、Ｓ−ＧＷ４２が暗号化及び完全性保証を実行（activation）する（Ｓ３２、Ｓ３３）。
【０１０５】
以上説明したように、実施の形態３にかかるDual connectivity procedureが実行されることによって、Dual connectivityを実行するために追加されたｇＮＢ２２は、ＭＭＥ４１において生成されたセキュリティ鍵ＫＡＮを取得することができる。これにより、ｇＮＢ２２は、ＵＥ３１とセキュリティ鍵ＫＡＮを共有することができる。その結果、ＵＥ３１が、Dual connectivityを実行する場合に、ＵＥ３１は、ｅＮＢ１２及びｇＮＢ２２のそれぞれとセキュリティ状態を確立して通信を行うことができる。
【０１０６】
（実施の形態４）
続いて、図１６を用いて、実施の形態４にかかるUE network capabilityのフォーマットについて説明する。UE network capabilityは、Initial attach procedureにおいて、ＵＥ３１から送信されるAttach requestメッセージに含まれる。UE network capabilityは、例えば、NRにおいて用いられる暗号化に関するアルゴリズム及び完全性保証に関するアルゴリズムを含む。言い換えると、NRのための新しいアルゴリズムが、Attach requestで当該アルゴリズムを送信するために、UE network capability IEに追加される。例えば、暗号化に関するアルゴリズム及び完全性保証に関するアルゴリズムは、2進数で表される4桁の数字及びアルゴリズム名称によって識別される。具体的には、暗号化に関するアルゴリズムは、“００００２”：NEA0、“０００１２”：NEA1、“００１０２”：NEA2、“００１１２”：NEA3、とあらわされてもよい。さらに、完全性保証に関するアルゴリズムは、“００００２”：NIA0、“０００１２”：NIA1、“００１０２”：NIA2、“００１１２”：NIA3、とあらわされてもよい。
【０１０７】
図１６に示されるフォーマットは、例えば、ocetet 9及びbit 3に、ＵＥ３１がNR（もしくはNG-RAN）へアクセスすることができる能力（NR capability）を有しているかを示す情報が設定される。さらに、octet 10及びbit 1-8には、ＵＥ３１がサポートしている暗号化に関するアルゴリズム（NEA0-NEA7）が示される。さらに、octet 11及びbit 1-8には、ＵＥ３１がサポートしている完全性保証に関するアルゴリズム（NIA0-NIA7）が示される。octet 10に示される暗号化に関するアルゴリズム及びoctet 11に示される完全性保証に関するアルゴリズムは、NRもしくは5GS（5G System）において用いられるアルゴリズムである。例えば、それぞれのbitに1が設定された場合、ＵＥ３１が、当該bitに関連付けられているアルゴリズムをサポートしていることを示し、0が設定された場合、ＵＥ３１が、当該bitに関連付けられているアルゴリズムをサポートしていないことを示す。
【０１０８】
続いて、図１７を用いて、ＭＭＥ４１及びＨＳＳに格納されている情報リストについて説明する。ここでは、主に、ＭＭＥ４１及びＨＳＳに格納されているNR capability及びNRに関する加入者情報（Subscription information）について説明する。
【０１０９】
図１７においては、ＭＭＥ４１及びＨＳＳが、NR capability及びNRに関する加入者情報として、NR Subscription、UE NR Capability、Selected NR Security Algorithm、及び、UE NR Security Algorithm Preferenceを保持していることを示している。言い換えると、NR subscription IEは、ＭＭＥ４１及びＨＳＳが当該NR subscription IEを格納するために追加される。
【０１１０】
NR Subscriptionは、ＵＥ３１のユーザが、NRへのアクセスを伴うサービスに登録しているか否かに関する情報を示している。UE NR Capabilityは、ＵＥ３１においてサポートされているセキュリティアルゴリズム及び鍵導出機能（key derivation functions）を含む。Selected NR Security Algorithmは、選択されたNR security algorithmを示している。UE NR Security Algorithm Preferenceは、NR security algorithm及び鍵導出機能（key derivation functions）に関するPreference情報を示している。
【０１１１】
UE NR Capabilityは、ＭＭＥ４１及びＨＳＳに格納されている他のFieldに含められてもよく、例えば、UE Radio Access Capability、UE Network Capability、もしくは、MS Network Capabilityに含められてもよい。
【０１１２】
また、NR Subscriptionも、ＭＭＥ４１及びＨＳＳに格納されている他のFieldに含められてもよく、例えば、Access RestrictionもしくはEPS Subscribed Charging Characteristicsに含められてもよい。NR SubscriptionがAccess Restrictionに含められる場合、ＵＥ３１がNRを用いることが許可されているか否かを示すために、NRもしくはNG-RANのようなRATs（Radio Access Technologies）を示す情報がAccess Restrictionに追加される。
【０１１３】
続いて、図１８を用いて、実施の形態４にかかるUE security capabilityのフォーマットについて説明する。UE security capabilityは、Initial attach procedureにおいて、ＭＭＥ４１から送信されるInitial Context setup requestメッセージに含まれる。図１８は、octet 8及びbit 1-8には、ＵＥ３１がサポートしている暗号化に関するアルゴリズム（NEA0-NEA7）が示される。さらに、octet 9及びbit 1-8には、ＵＥ３１がサポートしている完全性保証に関するアルゴリズム（NIA0-NIA7）が示される。octet 8に示される暗号化に関するアルゴリズム及びoctet 9に示される完全性保証に関するアルゴリズムは、NRもしくは5GS（5G System）において用いられるアルゴリズムである。言い換えると、NRのための新しいアルゴリズムが、当該NRのための新しいアルゴリズムをInitial context setup requestで送信するために、UE security capability IEに追加される。
【０１１４】
続いて、図１９を用いて、実施の形態４にかかるInitial Context setup requestメッセージのフォーマットについて説明する。図１９に示すように、Initial Context setup requestメッセージには、UE NR capabilities及びNR subscriptionが含まれている。また、NR Subscriptionは、図２０に示す、Handover Resticrion List IEに含められてもよい。NR SubscriptionがHandover Resticrion List IEに含められる場合、ＵＥ３１がNRを用いることが許可されているか否かを示すために、NRもしくはNG-RANのようなRATs（Radio Access Technologies）を示す情報がHandover Resticrion List IEに追加される。
【０１１５】
続いて、図２１を用いて実施の形態４にかかるDual connectivity procedureについて説明する。以下の記載において、ｅＮＢ１２は、Master eNBとして動作し、また、ｇＮＢ２２は、Secondary gNBとして動作する。はじめに、ＵＥ３１は、ｅＮＢ１２との間において、RRC connectionを確立する（RRC connection establishment）（Ｓ２０１）。
【０１１６】
次に、ｅＮＢ１２は、UE’s capability及びNR Subscriptionを保持していない場合、UE’s capability及びNR Subscriptionを要求する（Ｓ２０２）。ステップＳ２０２は、ｅＮＢ１２が、ＵＥ３１へUE’s capability及びNR Subscriptionを要求するMethod 1と、ＭＭＥ４１へUE’s capability及びNR Subscriptionを要求するMethod 2と、のいずれかを実施する。Method 1及びMethod 2については後に詳述する。UE’s capabilityは、例えば、UE NR Capabilityであってもよい。
【０１１７】
次に、ｅＮＢ１２は、UE NR capability及びNR subscriptionをチェックする（Ｓ２０３）。ｅＮＢ１２は、ＵＥ３１が、NRへアクセスするための能力を有しており、さらに、ＮＲへのアクセス権限を有していると判定した場合、次のステップへ進む。それ以外の場合、ｅＮＢ１２は、ｇＮＢ２２ではなく、他のｅＮＢが利用可能であれば、そのｅＮＢとDual connectivityを形成する処理を実行する。以下に、ｅＮＢ１２は、ＵＥ３１が、NRへアクセスするための能力を有しており、さらに、ＮＲへのアクセス権限を有していると判定した場合の処理について説明する。
【０１１８】
次に、ｅＮＢ１２は、セキュリティ鍵ＫｅＮＢから、セキュリティ鍵Ｓ−ＫｇＮＢを導出する（Ｓ２０４）。セキュリティ鍵Ｓ−ＫｇＮＢは、ｇＮＢ２２において、完全性保証及び暗号化（Integrity and Confidentiality protection）のために用いられる。セキュリティ鍵Ｓ−ＫｇＮＢは、例えば、図５におけるセキュリティ鍵ＫＡＮに相当する。次に、ｅＮＢ１２は、SgNB addition requestメッセージをｇＮＢ２２へ送信する（Ｓ２０５）。SgNB addition requestメッセージは、セキュリティ鍵Ｓ−ＫｇＮＢ、及びセキュリティアルゴリズムを含むUE NR Capabilityを含む。
【０１１９】
次に、ｇＮＢ２２は、UE NR Capabilityに基づいて、完全性保証及び暗号化のために用いられるセキュリティアルゴリズムを決定する（Ｓ２０６）。次に、ｅＮＢ１２は、セキュリティ鍵Ｓ−ＫｇＮＢから、完全性保証及び暗号化のために用いられるセキュリティ鍵を導出する。ｅＮＢ１２が導出するセキュリティ鍵は、例えば、ＳＲＢ（Signalling Radio Bearer）に関する完全性保証及び暗号化を行うための鍵（例えば、ＫＲＲＣｉｎｔ及びＫＲＲＣｅｎｃ）及びＤＲＢ（Data Radio Bearer）に関する完全性保証及び暗号化を行うための鍵（例えば、ＫＵＰｉｎｔ及びＫＵＰｅｎｃ）を含む。
【０１２０】
次に、ｇＮＢ２２は、SgNB addition request AcknowledgeメッセージをｅＮＢ１２へ送信する（Ｓ２０８）。SgNB addition request Acknowledgeメッセージは、ｇＮＢ２２において決定されたセキュリティアルゴリズムを含む。
【０１２１】
次に、ｅＮＢ１２は、ＵＥ３１へRRC connection reconfig requestメッセージを送信する（Ｓ２０９）。RRC connection reconfig requestメッセージは、ｇＮＢ２２において決定されたセキュリティアルゴリズムを含む。次に、ＵＥ３１は、RRC connection reconfig responseメッセージをｅＮＢ１２へ送信する（Ｓ２１０）。次に、ｅＮＢ１２は、SgNB Reconfiguration completeメッセージをｇＮＢ２２へ送信する（Ｓ２１１）。その後、ＵＥ３１及びｇＮＢ２２において、暗号化及復号化を実行（activation）する（Ｓ２１２、Ｓ２１３）。
【０１２２】
続いて、図２２を用いて、図２１のステップＳ２０２におけるMethod 1について説明する。ｅＮＢ１２は、ＵＥ３１へUE’s capability（UE NR capability）を要求するために、UECapabilityEnquiryメッセージをＵＥ３１へ送信する（Ｓ２２１）。次に、ＵＥ３１は、UECapabilityInformationメッセージをｅＮＢ１２へ送信する（Ｓ２２２）。UECapabilityEnquiryメッセージ及びUECapabilityInformationメッセージには、SecurityAlgorithmConfigIEが含められている。ＵＥ３１は、SecurityAlgorithmConfigIEに、UE’s capability、言い換えるとセキュリティアルゴリズムを追加する。
【０１２３】
続いて、図２３を用いて、図２１のステップＳ２０２におけるMethod 2について説明する。ｅＮＢ１２は、ＭＭＥ４１へUE’s capability（UE NR capability）を要求するために、UE Capability RequestメッセージをＭＭＥ４１へ送信する（Ｓ２３１）。次に、ＭＭＥ４１は、UE Capability ResponseメッセージをｅＮＢ１２へ送信する（Ｓ２３２）。ｅＮＢ１２は、UE network capability、UE security capability、NR Subscriotion、UE NR Capability、Selected NR Security Algorithm、及び、UE NR Security Algorithm Preferenceのうち、取得することが必要な情報に関するIEをUE Capability Requestメッセージに含ませる。ＭＭＥ４１は、ｅＮＢ１２が要求する情報をUE Capability Responseメッセージに含ませる。
【０１２４】
ここで、図２４及び図２５を用いて、実施の形態１乃至３におけるＫＤＦを用いたセキュリティ鍵の導出について説明する。ＫＤＦは、例えば、HMAC-SHA-256等の導出関数が用いられる。図２４は、ＫＤＦを用いたセキュリティ鍵ＫＡＮの導出を示している。具体的には、ＫＤＦへパラメータとしてセキュリティ鍵ＫｅＮＢ（ＫＡＳＭＥ）、SCG Counter、KDF ID、NR ID、Slice ID、Session IDを入力し、セキュリティ鍵ＫＡＮを得る。さらに、ＫＤＦへパラメータとしてセキュリティ鍵ＫＡＮ、KDF ID、NR ID、Slice ID、Session IDを入力し、ＫＵＰｉｎｔ、ＫＵＰｅｎｃを得る。NR IDは、ＵＥ３１利用することがができる通信方式を示す識別情報である。例えば、NR IDは、UE capabilityに含まれる。また、Slice ID、Session IDも、UE capabilityに含まれてもよい。
【０１２５】
図２５は、ＫＤＦを用いたセキュリティ鍵ＫＵＰの導出を示している。具体的には、ＫＤＦへパラメータとしてセキュリティ鍵ＫｅＮＢ（ＫＡＳＭＥ）、SCG Counter、KDF ID、NR ID、Slice ID、Session IDを入力し、セキュリティ鍵ＫＵＰを得る。さらに、ＫＤＦへパラメータとしてセキュリティ鍵ＫＵＰ、KDF ID、NR ID、Slice ID、Session IDを入力し、ＫＵＰｉｎｔ、ＫＵＰｅｎｃを得る。
【０１２６】
上述の実施の形態は、ハードウェアで構成される例として説明したが、これに限定されるものではない。本開示は、ＵＥ及び各装置における処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。
【０１２７】
上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【０１２８】
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本開示は、それぞれの実施の形態を適宜組み合わせて実施されてもよい。
【０１２９】
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【０１３０】
この出願は、２０１６年１０月２６日に出願されたインド出願201611036776及び２０１７年４月２６日に出願されたインド出願201711014793を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【０１３１】
１０  基地局
１２  ｅＮＢ
２０  基地局
２１  ＮＲ
２２  ｇＮＢ
３０  通信端末
３１  ＵＥ
４０  ＥＰＣ
４１  ＭＭＥ
４２  Ｓ−ＧＷ
【図１】
2018079692.tif 000003
【図２】
2018079692.tif 000004
【図３】
2018079692.tif 000005
【図４】
2018079692.tif 000006
【図５】
2018079692.tif 000007
【図６】
2018079692.tif 000008
【図７】
2018079692.tif 000009
【図８】
2018079692.tif 000010
【図９】
2018079692.tif 000011
【図１０】
2018079692.tif 000012
【図１１】
2018079692.tif 000013
【図１２】
2018079692.tif 000014
【図１３】
2018079692.tif 000015
【図１４】
2018079692.tif 000016
【図１５】
2018079692.tif 000017
【図１６】
2018079692.tif 000018
【図１７】
2018079692.tif 000019
【図１８】
2018079692.tif 000020
【図１９】
2018079692.tif 000021
【図２０】
2018079692.tif 000022
【図２１】
2018079692.tif 000023
【図２２】
2018079692.tif 000024
【図２３】
2018079692.tif 000025
【図２４】
2018079692.tif 000026
【図２５】
2018079692.tif 000027
【手続補正書】
【提出日】平成31年4月22日(2019.4.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第1の基地局と、
第2の基地局と、
コアネットワークノードと、
を備え、
前記第1の基地局と前記第2の基地局は、
それぞれ異なる通信方式を用いて通信する基地局であり、
前記コアネットワークノードは、
端末の前記第2の基地局へのアクセス可否を示す情報を、前記第1の基地局に、送信し、
前記第1の基地局は、
前記情報を使用して、前記端末が前記第2の基地局にアクセスするための能力を有していることと、前記端末が前記第2の基地局へのアクセス権限を有していることと、をチェックすることで、前記端末の前記第2の基地局とのDual Connectivityを使用するか否かを決定する、
システム。
【請求項２】
第1の基地局であって、
端末の第2の基地局へのアクセス可否を示す情報を、コアネットワークノードから、受信し、
前記情報を使用して、前記端末が前記第2の基地局にアクセスするための能力を有していることと、前記端末が前記第2の基地局へのアクセス権限を有していることと、をチェックすることで、前記端末の前記第2の基地局とのDual Connectivityを使用するか否かを決定し、
前記第2の基地局は、
前記第1の基地局と異なる通信方式を用いて通信する基地局である、
第1の基地局。
【請求項３】
端末の第2の基地局へのアクセス可否を示す情報を、第1の基地局に、送信する、
コアネットワークノードであって、
前記第1の基地局と前記第2の基地局は、
それぞれ異なる通信方式を用いて通信する基地局であり、
前記第1の基地局は、
前記情報を使用して、前記端末が前記第2の基地局にアクセスするための能力を有していることと、前記端末が前記第2の基地局へのアクセス権限を有していることと、をチェックすることで、前記端末の前記第2の基地局とのDual Connectivityを使用するか否かを決定する、
コアネットワークノード。
【請求項４】
端末の基地局へのアクセス可否を示す情報を、コアネットワークノードから、受信し、
前記情報を使用して、前記端末が前記基地局にアクセスするための能力を有していることと、前記端末が前記基地局へのアクセス権限を有していることと、をチェックすることで、前記端末の前記基地局とのDual Connectivityを使用するか否かを決定する、
方法。
【請求項５】
第2の基地局と異なる通信方式を用いて通信する基地局である第1の基地局が、端末の前記第2の基地局へのアクセス可否を示す情報を使用して、前記端末が前記第2の基地局にアクセスするための能力を有していることと、前記端末が前記第2の基地局へのアクセス権限を有していることと、をチェックすることで、前記端末の前記第2の基地局とのDual Connectivityを使用するか否かを決定するために、前記情報を、前記第1の基地局に、送信する、
方法。
【請求項６】
前記第2の基地局は、
5ＧのNR (New Radio) である、
請求項1に記載のシステム。
【請求項７】
前記第2の基地局は、
5ＧのNR (New Radio) である、
請求項2に記載の第1の基地局。
【請求項８】
前記第2の基地局は、
5ＧのNR (New Radio) である、
請求項3に記載のコアネットワークノード。
【請求項９】
前記基地局は、
5ＧのNR (New Radio) である、
請求項4に記載の方法。
【請求項１０】
前記第2の基地局は、
5ＧのNR (New Radio) である、
請求項5に記載の方法。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００４２
【補正方法】変更
【補正の内容】
【００４２】
ＵＥ３１及びｅＮＢ１２は、セキュリティ鍵ＫｅＮＢ／ＮＨからセキュリティ鍵ＫＵＰｉｎｔ、セキュリティ鍵ＫＵＰｅｎｃ、セキュリティ鍵ＫＲＲＣｉｎｔ、及びセキュリティ鍵ＫＲＲＣｅｎｃを導出する。セキュリティ鍵ＫＵＰｉｎｔは、ユーザデータの完全性保証に用いられる。セキュリティ鍵ＫＵＰｅｎｃは、ユーザデータの暗号化に用いられる。セキュリティ鍵ＫＲＲＣｅｎｃは、ＲＲＣ（Radio Resource Control）メッセージの暗号化に用いられる。セキュリティ鍵ＫＲＲＣｉｎｔは、ＲＲＣメッセージの完全性保証に用いられる。
【国際調査報告】
2018079692.tif 000028
2018079692.tif 000029
2018079692.tif 000030
2018079692.tif 000031