(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-11
(45)【発行日】2023-12-19
(54)【発明の名称】通信端末、及び通信端末の方法
(51)【国際特許分類】
H04W 12/04 20210101AFI20231212BHJP
H04W 76/16 20180101ALI20231212BHJP
H04W 88/06 20090101ALI20231212BHJP
【FI】
H04W12/04
H04W76/16
H04W88/06
(21)【出願番号】P 2022074610
(22)【出願日】2022-04-28
(62)【分割の表示】P 2021000757の分割
【原出願日】2018-09-27
【審査請求日】2022-04-28
(31)【優先権主張番号】201711034337
(32)【優先日】2017-09-27
(33)【優先権主張国・地域又は機関】IN
【前置審査】
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100103894
【氏名又は名称】家入 健
(72)【発明者】
【氏名】伊藤 博紀
(72)【発明者】
【氏名】ラクシュミナラヤナン シバカミー
(72)【発明者】
【氏名】プラサド アナンド ラガワ
(72)【発明者】
【氏名】アルムガム シババラン
(72)【発明者】
【氏名】バスカラン シーバ バッキア メーリ
【審査官】深津 始
(56)【参考文献】
【文献】Ericsson,New solution for the protection of multiple NAS connections (KI #1.7)[online],3GPP TSG SA WG3 #87 S3-171594,2017年06月05日,Internet<URL:http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_87_Ljubljana/Docs/S3-171594.zip>
(58)【調査した分野】(Int.Cl.,DB名)
H04B 7/24 -H04B 7/26
H04W 4/00 -H04W 99/00
3GPP TSG RAN WG1-4
SA WG1-4
CT WG1、4
(57)【特許請求の範囲】
【請求項1】
3GPPアクセス及びNon-3GPPアクセスを介してネットワークに登録処理を実行する手段と、
前記ネットワークとの前記3GPPアクセスのための第1のNAS (Non-Access-Stratum) connectionを確立する手段と、
前記ネットワークとの前記Non-3GPPアクセスのための第2のNAS (Non-Access-Stratum) connectionを確立する手段と、
前記第1のNAS connectionに固有であり、
前記3GPPアクセスに対応する第1の固定値と、前記第2のNAS connectionに固有であり、
前記Non-3GPPアクセスに対応する第2の固定値と、のいずれか一方に設定されたパラメータを用いて、セキュリティ鍵を生成する手段
と、を備える、
通信端末。
【請求項2】
3GPPアクセス及びNon-3GPPアクセスを介してネットワークに登録処理を実行し、
前記ネットワークとの前記3GPPアクセスのための第1のNAS (Non-Access-Stratum) connectionを確立し、
前記ネットワークとの前記Non-3GPPアクセスのための第2のNAS (Non-Access-Stratum) connectionを確立し、
前記第1のNAS connectionに固有であり、
前記3GPPアクセスに対応する第1の固定値と、前記第2のNAS connectionに固有であり、
前記Non-3GPPアクセスに対応する第2の固定値と、のいずれか一方に設定されたパラメータを用いて、セキュリティ鍵を生成する、
通信端末の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、通信端末、コアネットワーク装置、コアネットワークノード、ネットワークノード及び鍵導出方法に関する。
【背景技術】
【0002】
3GPP(3rd Generation Partnership Project)において、5Gと称される通信システム(以下、5GS(5G System)とする)の仕様が検討されている。5GSは、アクセスネットワークとして3GPP Access及びNon-3GPP Accessを含む。また、Non-3GPP Accessは、Trusted Non-3GPP Access及びUntrusted Non-3GPP Accessを含む。3GPP Accessは、3GPPにおいて機能もしくは仕様等が規定された装置を有するネットワークである。Non-3GPP Accessは、3GPPにおいて機能もしくは仕様等が規定されていない装置を有するネットワークである。また、Trusted Non-3GPP Accessは、通信事業者等において信頼性のあるアクセスネットワークであると認識されているネットワークである。Untrusted Non-3GPP Accessは、通信事業者等において信頼性のあるアクセスネットワークであると認識されていないネットワークである。
【0003】
非特許文献1には、3GPP AccessとNon-3GPP Accessとの間のハンドオーバ処理が開示されている。
【先行技術文献】
【非特許文献】
【0004】
【文献】3GPP TR 23.799 V2.0.0 (2016-11)
【発明の概要】
【発明が解決しようとする課題】
【0005】
非特許文献1には、3GPP AccessとNon-3GPP Accessとの間のハンドオーバ処理が開示されているが、通信端末であるUEが、3GPP Access及びNon-3GPP Accessを介してmultiple connectionsを確立する際のセキュリティメカニズムが規定されていない。そのため、3GPP Access及びNon-3GPP Accessを用いたmultiple connectionsにおいては、セキュリティレベルの低下等が生じるという問題がある。
【0006】
本開示の目的は、上述した課題に鑑み、3GPP Access及びNon-3GPP Accessを介してmultiple connectionsを確立する際に生じるセキュリティレベルの低下を防止することができる通信端末、コアネットワーク装置、及び鍵導出方法を提供することにある。
【課題を解決するための手段】
【0007】
本開示の第1の態様にかかる通信端末は、Untrusted Non-3GPP Accessを介してコアネットワーク装置の前段に配置されているゲートウェイ装置と通信する通信部と、前記コアネットワーク装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第1のセキュリティ鍵から、前記ゲートウェイ装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第2のセキュリティ鍵を導出する鍵導出部と、を備える。
【0008】
本開示の第2の態様にかかるコアネットワーク装置は、コアネットワーク装置の前段に配置されているゲートウェイ装置及びUntrusted Non-3GPP Accessを介して通信端末と通信する通信部と、前記通信端末との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第1のセキュリティ鍵から、前記通信端末と前記ゲートウェイ装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第2のセキュリティ鍵を導出する鍵導出部と、を備える。
【0009】
本開示の第3の態様にかかる鍵導出方法は、Untrusted Non-3GPP Accessを介してコアネットワーク装置の前段に配置されているゲートウェイ装置と通信し、前記コアネットワーク装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第1のセキュリティ鍵から、前記ゲートウェイ装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第2のセキュリティ鍵を導出する。
【発明の効果】
【0010】
本開示により、3GPP Access及びNon-3GPP Accessを介してmultiple connectionsを確立する際に生じるセキュリティレベルの低下を防止することができる通信端末、コアネットワーク装置、コアネットワークノード、ネットワークノード及び鍵導出方法を提供することができる。
【図面の簡単な説明】
【0011】
【
図1】実施の形態1にかかる通信端末の構成図である。
【
図2】実施の形態1にかかるコアネットワーク装置の構成図である。
【
図3】実施の形態2にかかる通信システムの構成図である。
【
図4】実施の形態2にかかるKey hierarchyを示す図である。
【
図5】実施の形態2にかかるKey hierarchyを示す図である。
【
図6】実施の形態2にかかる通信システムの構成図である。
【
図7】実施の形態2にかかるKey hierarchyを示す図である。
【
図8】実施の形態2にかかるKey hierarchyを示す図である。
【
図9】実施の形態2にかかるKey hierarchyを示す図である。
【
図10】実施の形態2にかかる通信システムの構成図である。
【
図11】実施の形態2にかかるKey hierarchyを示す図である。
【
図12】実施の形態2にかかるKey hierarchyを示す図である。
【
図13】実施の形態2にかかるセキュリティ鍵の導出を示す図である。
【
図14】実施の形態2にかかるセキュリティ鍵の導出を示す図である。
【
図15】実施の形態2にかかるUEが利用しているアクセスネットワークに関する情報の送信処理の流れを示す図である。
【
図16】実施の形態2にかかるUEが利用しているアクセスネットワークに関する情報の送信処理の流れを示す図である。
【
図17】実施の形態2にかかるセキュリティ鍵KSEAFの導出過程を示す図である。
【
図18】実施の形態2にかかるセキュリティ鍵KSEAFの導出過程を示す図である。
【
図19】実施の形態2にかかるセキュリティ鍵KSEAFの導出過程を示す図である。
【
図20】実施の形態2にかかるセキュリティ鍵KSEAFの導出過程を示す図である。
【
図21】実施の形態2にかかるセキュリティ鍵KSEAFの導出過程を示す図である。
【
図22】実施の形態2にかかるセキュリティ鍵KSEAFの導出過程を示す図である。
【
図23】実施の形態2にかかるセキュリティ鍵KSEAFの導出過程を示す図である。
【
図24】実施の形態3にかかるUE30に関する認証処理の流れを示す図である。
【
図25】実施の形態3にかかるUE30に関する認証処理の流れを示す図である。
【
図26】実施の形態3にかかるUE30に関する認証処理の流れを示す図である。
【
図27】実施の形態3にかかるUE30に関する認証処理の流れを示す図である。
【
図28】実施の形態3にかかるハンドオーバ最中のセキュリティ鍵KAMF*の導出手順を示す図である。
【
図29】実施の形態3にかかるセキュリティ鍵の導出を示す図である。
【
図30】実施の形態3にかかるハンドオーバ最中のセキュリティ鍵KAMF*の導出手順を示す図である。
【
図31】実施の形態3にかかるセキュリティ鍵の導出を示す図である。
【
図32】実施の形態3にかかるハンドオーバ最中のセキュリティ鍵KAMF*の導出手順を示す図である。
【
図33】実施の形態3にかかるセキュリティ鍵の導出を示す図である。
【
図34】実施の形態3にかかるハンドオーバ最中のセキュリティ鍵KAMF*の導出手順を示す図である。
【
図35】実施の形態3にかかるセキュリティ鍵の導出を示す図である。
【
図36】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図37】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図38】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図39】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図40】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図41】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図42】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図43】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図44】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図45】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図46】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図47】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図48】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図49】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図50】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図51】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図52】実施の形態3にかかるハンドオーバ処理の流れを示す図である。
【
図53】実施の形態4にかかるハンドオーバ処理の流れを示す図である。
【
図54】実施の形態4にかかるハンドオーバ処理の流れを示す図である。
【
図55】実施の形態4にかかるハンドオーバ処理の流れを示す図である。
【
図56】実施の形態4にかかるハンドオーバ処理の流れを示す図である。
【
図57】実施の形態4にかかるハンドオーバ処理の流れを示す図である。
【
図58】実施の形態4にかかるハンドオーバ処理の流れを示す図である。
【
図59】実施の形態4にかかるハンドオーバ処理の流れを示す図である。
【
図60】実施の形態4にかかるハンドオーバ処理の流れを示す図である。
【
図61】それぞれの実施の形態にかかる通信端末の構成図である。
【
図62】それぞれの実施の形態にかかるコアネットワーク装置の構成図である。
【0012】
(実施の形態1)
以下、図面を参照して本開示の実施の形態について説明する。はじめに、
図1を用いて実施の形態1にかかる通信端末10の構成例について説明する。通信端末10は、プロセッサがメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。通信端末10は、携帯電話端末、スマートフォン端末、もしくはタブレット型端末であってもよい。または、通信端末10は、IoT(Internet Of Things)端末もしくはMTC(Machine Type Communication)端末であってもよい。または、通信端末10は、3GPPにおいて通信端末の総称として用いられるUE(User Equipment)であってもよい。
【0013】
通信端末10は、通信部11及び鍵導出部12を有している。通信部11及び鍵導出部12は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、通信部11及び鍵導出部12は、回路もしくはチップ等のハードウェアであってもよい。
【0014】
通信部11は、Untrusted Non-3GPP Accessを介してコアネットワーク装置20の前段に配置されているゲートウェイ装置と通信する。コアネットワーク装置20は、コアネットワークに配置されている装置である。ゲートウェイ装置は、コアネットワークに配置されており、Untrusted Non-3GPP Accessとの間にインスタンス、インタフェースもしくはリファレンスポイントを有する装置である。また、通信部11は、3GPP Accessを介してコアネットワーク装置20と通信することも可能である。
【0015】
鍵導出部12は、ゲートウェイ装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられるゲートウェイ装置用セキュリティ鍵を導出する。鍵導出部12は、コアネットワーク装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられるコアネットワーク装置用セキュリティ鍵からゲートウェイ装置用セキュリティ鍵を導出する。
【0016】
続いて、
図2を用いて実施の形態1にかかるコアネットワーク装置20の構成例について説明する。コアネットワーク装置20は、プロセッサがメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。コアネットワーク装置20は、例えば、サーバ装置であってもよい。
【0017】
コアネットワーク装置20は、通信部21及び鍵導出部22を有している。通信部21及び鍵導出部22は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、通信部21及び鍵導出部22は、回路もしくはチップ等のハードウェアであってもよい。
【0018】
通信部21は、ゲートウェイ装置及びUntrusted Non-3GPP Accessを介して通信端末10と通信する。鍵導出部22は、鍵導出部12と同様であるため詳細な説明を省略する。
【0019】
以上説明したように、実施の形態1にかかる通信端末10及びコアネットワーク装置20は、それぞれ、Untrusted Non-3GPP Accessを介した通信を行う際に、ゲートウェイ装置用セキュリティ鍵を導出することができる。具体的には、通信端末10及びコアネットワーク装置20は、コアネットワーク装置用セキュリティ鍵を用いて、ゲートウェイ装置用セキュリティ鍵を導出することができる。これにより、Untrusted Non-3GPP Accessにおいて伝送されるメッセージに、ゲートウェイ装置用セキュリティ鍵を適用することができる。その結果、Untrusted Non-3GPP Accessを含むmultiple connectionsを確立する際においても、セキュリティレベルの低下を防止することができる。
【0020】
(実施の形態2)
続いて、
図3を用いて実施の形態2にかかる通信システムの構成例について説明する。
図3の通信システムは、HPLMN(Home Public Land Mobile Network)もしくはVPLMN(Visited Public Land Mobile Network)と、Non-3GPPネットワークとを有することを示している。UE30は、HPLMNもしくはVPLMNと、Non-3GPP Accessとの両方を介してHPLMNもしくはVPLMNのAMF33と通信することができる。
【0021】
HPLMNもしくはVPLMNは、3GPP Access32、AMF(Access and Mobility management Function)エンティティ33(以下、AMF33とする)、SMF(Session Management Function)エンティティ34(以下、SMF34とする)、UPF(User Plane Function)エンティティ35(以下、UPF35とする)、AUSF(Authentication Server Function)エンティティ36(以下、AUSF36とする)、UDM(Unified Data Management)エンティティ37(以下、UDM37とする)、N3IWF(Non-3GPP Inter Working Function)エンティティ38(以下、N3IWF38とする)、及びData Network39を有している。
【0022】
また、3GPP Access32には、gNB(g Node B)31が配置されている。gNB31は、基地局に相当する。
【0023】
AMF33、SMF34、UPF35、AUSF36、UDM37、及びN3IWF38は、コアネットワークを構成する。AMF33、SMF34、UPF35、AUSF36、UDM37、及びN3IWF38が構成するコアネットワークは、例えば、5GC(5G Core)と称されてもよい。
【0024】
AMF33は、UE30に関するモビリティ管理を行う。さらに、AMF33は、AUSF36及びUDM37と連携してUE30に関する認証処理を行う。SMF34は、UE30に関するセッション管理を行う。UPF35は、UE30とData Network39との間において伝送されるU(User)-Planeデータを中継する。U-Planeデータは、ユーザデータと称されてもよい。
【0025】
N3IWF38は、Untrusted Non-3GPP Access40を介してUE30と通信する。N3IWF38は、異なるネットワーク間を相互に接続し、UE30とAMF33との間において伝送されるUE30に関する制御データもしくはC(Control)-Planeデータを中継する。異なるネットワークは、例えば、HPLMとNon-3GPP Networkであってもよく、VPLMNとNon-3GPP Networkであってもよい。
【0026】
UE30とAMF33との間には、N1インタフェースが規定されている。3GPP Access32とAMF33との間には、N2インタフェースが規定されている。AMF33とN3IWF38との間にも、N2インタフェースが規定されている。N3IWF38とUPF35との間には、N3インタフェースが規定されている。gNB31とUPF35との間にも、N3インタフェースが規定されている。SMF34とUPF35との間には、N4インタフェースが規定されている。UPF35とData Network39との間には、N6インタフェースが規定されている。AMF33とSMF34との間には、N11インタフェースが規定されている。AMF33とAUSF36との間には、N12インタフェースが規定されている。AUSF36とUDM37との間には、N13インタフェースが規定されている。UE30とUntrusted Non-3GPP Access40との間には、Y1インタフェースが規定されている。UE30とN3IWF38との間には、NWuインタフェースが規定されている。インタフェースとの用語は、インスタンス、もしくはリファレンスポイントと言い換えられてもよい。
【0027】
UE30とgNB31との間において伝送されるメッセージに関するセキュリティ処理には、セキュリティ鍵KgNBが用いられる。UE30とN3IWF38との間において伝送されるメッセージに関するセキュリティ処理には、セキュリティ鍵Knon-3gppが用いられる。UE30とAMF33との間において伝送されるメッセージに関するセキュリティ処理には、セキュリティ鍵KAMFが用いられる。
【0028】
続いて、
図4を用いて実施の形態2にかかるKey hierarchyについて説明する。
図4のKey hierarchyは、UE30が複数のアクセスネットワークを介してAMF33との通信を可能とするmultiple NAS(Non-Access Stratum)に適用される。また、
図4のKey hierarchyは、UE30及び5GCにおいて生成されるセキュリティ鍵を示している。
【0029】
セキュリティ鍵KSEAFは、UE30とAUSF36との間において相互認証が行われたセキュリティ鍵Kから導出される。セキュリティ鍵Kは、long-term keyと称されてもよい。セキュリティ鍵KSEAFは、AMF33へ送信される。セキュリティ鍵KAMFは、セキュリティ鍵KSEAFから導出される。完全性保護に用いられるセキュリティ鍵KNASint及び暗号化に用いられるセキュリティ鍵KNASencは、セキュリティ鍵KAMFから導出される。セキュリティ鍵KNASint及びセキュリティ鍵KNASencは、NAS security keyと称されてもよい。
【0030】
セキュリティ鍵KgNBは、セキュリティ鍵KAMFから導出される。セキュリティ鍵KRRCint、セキュリティ鍵KRRCenc、セキュリティ鍵KUPint、及びセキュリティ鍵KUPencは、セキュリティ鍵KgNBから導出される。セキュリティ鍵KRRCint及びセキュリティ鍵KRRCencは、UE30と3GPP Access 32との間において伝送されるRRCメッセージの保護に用いられる。セキュリティ鍵KUPint及びセキュリティ鍵KUPencは、UE30と3GPP Access 32との間において伝送されるU-Planeデータの保護に用いられる。
【0031】
セキュリティ鍵Knon-3gppは、セキュリティ鍵KAMFから導出される。セキュリティ鍵Knon-3gppは、UE30とN3IWF38との間において伝送されるメッセージの保護に用いられる。セキュリティ鍵KAMF及びKgNBは、ハンドオーバにおいて更新されてもよい。また、セキュリティ鍵Knon-3gppは、セキュリティ鍵KSEAFから導出されてもよい。
【0032】
続いて、
図5を用いて
図4とは異なるKey hierarchyについて説明する。
図5のKey hierarchyは、セキュリティ鍵KNAS_N3Gint及びKNAS_N3Gencがセキュリティ鍵KAMFから導出される点において
図4のKey hierarchyと異なる。
【0033】
LTE(Long Term Evolution)のような既存のネットワークにおいては、UE30とコアネットワークとの間において一つのNAS connectionが確立しているのみである。一方、5Gにおいては、UE30と5GCとの間において、multiple connectionsが確立される。具体的には、AMF33は、3GPP Access32を介して通信を行うUE30と、Untrusted Non-3GPP Access40を介して通信を行うUE30と、それぞれ独立してNAS connectionを確立する。
【0034】
図4のKey hierarchyにおいては、3GPP Access32を介して確立されるNAS connectionとUntrusted Non-3GPP Access40を介して確立されるNAS connectionとの両方において、同じNAS security keyが用いられる。
【0035】
一方、
図5のKey hierarchyにおいては、セキュリティ鍵KNAS_N3Gint及びKNAS_N3Gencが導出される。そのため、3GPP Access32を介して確立されるNAS connectionにおいて用いられるNAS security keyは、Untrusted Non-3GPP Access40を介して確立されるNAS connectionにおいて用いられるNAS security keyと異なる。
【0036】
続いて、
図6を用いて
図3とは異なる通信システムの構成例について説明する。
図6は、UE30が、VPLMN1と、VPLMN2もしくはHPLMNとの間においてmultiple connectionsを確立していることを示している。VPLMN1は、gNB31、3GPP Access32、AMF33、SMF34、UPF35、及びData Network39を含む。VPLMN2は、AMF51、SMF52、UPF53、N3IWF54、及びData Network55を含む。また、AUSF36及びUDM37は、HPLMNに含まれてもよい。
【0037】
図6は、UE30が、3GPP Access32を介してNAS connectionを確立するAMF33と、Untrusted Non-3GPP Access40を介してNAS connectionを確立するAMF51とが異なることを示している。
【0038】
次に、
図7を用いて
図6の通信システムにおいて適用されるKey hierarchyについて説明する。
図7は、
図6の通信システムにおいて、UE30が、Untrusted Non-3GPP Access40を介して、HPLMNに配置されているAMF51とNAS connectionを確立することを前提とする。
【0039】
セキュリティ鍵KSEAF_Hとセキュリティ鍵KSEAF_Vとがセキュリティ鍵Kから導出される。セキュリティ鍵KSEAF_Hは、AMF51へ送信される。セキュリティ鍵KSEAF_Vは、AMF33へ送信される。セキュリティ鍵KSEAF_H及びセキュリティ鍵KSEAF_Vのそれぞれから導出されるセキュリティ鍵は、
図4と同様であるため詳細な説明を省略する。
【0040】
図8は、
図6の通信システムにおいて適用されるKey hierarchyであって、
図7とは異なるKey hierarchyを示している。
図8のKey hierarchyは、セキュリティ鍵KSEAF_H及びセキュリティ鍵KSEAF_Vのそれぞれから導出されるセキュリティ鍵が、
図5と同様である点において、
図7のKey hierarchyと異なる。
【0041】
また、
図9は、UE30が、multiple connectionsを確立するVPLMNが複数存在する場合のKey hierarchyを示している。セキュリティ鍵KSEAF_V1及びKSEAF_V2以降に導出されるセキュリティ鍵は、
図5と同様であるため詳細な説明を省略する。
【0042】
続いて、
図10を用いて
図3とは異なる通信システムの構成例について説明する。
図10は、HPLMN内において、UE30が複数のN3IWFを介してmultiple connectionsを確立していることを示している。さらに、
図10は、UE30が、VPLMN1との間においてもmultiple connectionsを確立し、VPLMN2との間においてconnectionを確立していることを示している。
【0043】
UE30は、HPLMNにおいて、N3IWF38_1を介してAMF33_1とNAS connectionを確立する。さらに、UE30は、HPLMNにおいてN3IWF38_2を介してAMF33_2とNAS connectionを確立する。さらに、UE30は、HPLMNにおいて3GPP Access32を介してAMF33_1及びAMF33_2とNAS connectionを確立する。
【0044】
また、VPLMN1は、3GPP Access62、AMF63、N3IWF64、及びNon-3GPP Access65を有している。3GPP Access62は、gNB61を有している。VPLMN2は、Non-3GPP Access72及びAMF73を有している。Non-3GPP Access72は、N3IWF71を有している。UE30は、3GPP Access62を介してAMF63とNAS connectionを確立する。さらに、UE30は、N3IWF64を介してAMF63とNAS connectionを確立する。さらに、UE30は、N3IWF71を介してAMF73とNAS connectionを確立する。
【0045】
続いて、
図11を用いて
図10の通信システムにおいて適用されるKey hierarchyについて説明する。セキュリティ鍵Kから導出されたセキュリティ鍵KSEAFが、AMF33_1、AMF33_2、AMF63、及びAMF73へ送信される。AMF33_1、AMF33_2、AMF63、及びAMF73のそれぞれは、セキュリティ鍵KAMF_1、セキュリティ鍵KAMF_2のように、異なるセキュリティ鍵KAMFを導出する。
【0046】
以降のセキュリティ鍵の導出は、
図5と同様であるため詳細な説明を省略する。
【0047】
これまでに説明したKey hierarchyは、
図12に示す3つのタイプに分けられる。タイプ1は、
図4において説明したKey hierarchyである。タイプ2は、
図5において説明したKey hierarchyである。タイプ3は、UE30が、同じ種類の複数のアクセスネットワークを介してAMF33とmultiple connectionsを確立する際に用いられるKey hierarchyである。同じ種類の複数のアクセスネットワークは、例えば、AMF33に接続している複数のN3IWF等であってもよい。具体的には、タイプ3は、
図5において説明したKey hierarchyにおいて、セキュリティ鍵KAMFから、複数のN3IWF毎に異なるセキュリティ鍵KNAS、KgNB、及びKnon-3gppが導出されるKey hierarchyである。
【0048】
続いて、
図13を用いてセキュリティ鍵KNAS_N3Gencの導出について説明する。セキュリティ鍵KNAS_N3Gencは、KDF(Key Derivation Function)から出力される。また、KDFには、セキュリティ鍵KAMF、暗号化アルゴリズム識別情報(Enc.Algo ID)、及びAN Identityが入力される。AN Identityの代わりにAN TypeがKDFに入力されてもよい。
【0049】
AN Typeは、例えば、2bitの値が用いられてもよい。具体的には、00が3GPP Accessを示し、01が、Untrusted Non-3GPP Accessを示し、10がtrusted Non-3GPP Accessを示してもよい。もしくは、AN Typeは、1bitの値が用いられてもよい。具体的には、0が3GPP Accessを示し、1がNon-3GPP Accessを示してもよい。
【0050】
図14は、セキュリティ鍵KNAS_N3Gintの導出を示している。
図14は、
図13における暗号化アルゴリズムID(Enc.Algo ID)の代わりに、完全性保証アルゴリズムID(Int.Algo ID)が用いられている。その他の入力パラメータは、
図13と同様である。
【0051】
図13及び
図14において、一つのPLMN(HPLMNもしくはVPLMN)においてUE30が複数のNon-3GPP Accessを介してAMF33とmultiple connectionsを確立する場合、KDFに対する入力パラメータとしてN3G_Countが用いられてもよい。言い換えると、AMF33が、UE30との間に、複数のN1インタフェースを設定する場合、N3G_Countが用いられてもよい。
【0052】
N3G_Countは、一つのconnectionが確立される度、つまり、一つのN1インタフェースが設定される度に、インクリメントされてもよい。
【0053】
さらに、保護されたNAS SMC(Security Mode Command) messageの一部としてAMF33からUE30へ送信されるNONCEn3gppが入力パラメータとして用いられてもよい。
【0054】
さらに、RANDが入力パラメータとして用いられてもよい。RANDは、例えば、UE30とAMF33とにおいて同じPRNG(Pseudo Random Number Generator)に対する入力として用いられるSalt”s”であってもよい。RANDは、保護されたNAS SMC messageの一部としてAMF33からUE30へ送信されてもよい。
【0055】
ここで、UE30とAMF33とにおいてN3G_Countを同期する手法について以下に説明する。
【0056】
N3G_Countは、完全性保護が行われ、かつ、暗号化が行われたNASメッセージに含められて、UE30とAMF33との間において送信されてもよい。もしくは、N3G_Countは、完全性保護のみが行われたNASメッセージに含められて、UE30とAMF33との間において送信されてもよい。N3G_Countが含められるNASメッセージは、例えば、NAS SMC messageであってもよく、N1 message for optimized NASであってもよい。
【0057】
もしくは、UE30とAMF33との間において、N3G_Countを直接伝送しない以下の手法が用いられてもよい。
【0058】
UE30とAMF33とは、それぞれN3G_Count valueを保持していることを前提とする。このような状態において、AMF33は、任意の値(random number)Nを選択する。さらに、AMF33は、d=N3G_Count value + Nを算出する。もしくは、AMF33は、d=N3G_Count value - Nもしくはd=N3G_Count value xor Nを算出してもよい。値dは、任意の演算手法を用いて算出されればよい。
【0059】
次に、AMF33は、N及びdの少なくとも一方と、dを算出する際に使用した演算手法とを示すindicatorとをUE30へ送信する。演算手法を示すindicatorは、例えば、加算、減算、もしくはxor演算、等を示す。AMF33は、N及びdの少なくとも一方と、indicatorとを、完全性保護が行われ、かつ、暗号化が行われたNASメッセージに含めてUE30へ送信してもよい。もしくは、AMF33は、N及びdの少なくとも一方と、indicatorとを、完全性保護のみが行われたNASメッセージに含めてUE30へ送信してもよい。
【0060】
次に、UE30は、AMF33から受信した値を用いてN3G_Count valueを同期する。さらに、UE30は、同期したN3G_Count valueをKDFの入力パラメータとして用いることによって、セキュリティ鍵を導出する。
【0061】
続いて、
図15を用いて、UE30が利用しているアクセスネットワークに関する情報の送信処理の流れについて説明する。はじめに、AMF33は、UE30へNAS SMC messageを送信する(S11)。NAS SMC messageは、KSI(Key Set Identifier)、Replayed UE Security capabilities、Allowed NSSAI(Network Slice Selection Assistance Information)、NAS Algorithms、N1-instance-indicator、Parameters to derive NAS integrity and encryption keys、及びNAS-MAC(NAS-Message Authentication Code)を含む。
【0062】
N1-instance-indicatorにおけるN1は、N1インスタンスもしくはN1インタフェースを意味している。つまり、N1-instance-indicatorは、UE30が利用しているアクセスネットワークを示している。もしくは、N1-instance-indicatorは、UE30が利用可能なアクセスネットワークを示してもよい。
【0063】
Parameters to derive NAS integrity and encryption keysは、AN Identity、AN type、N3G_Count、NONCEn3gpp、及びRANDを含んでもよい。
【0064】
次に、UE30は、受信したパラメータを用いて、セキュリティ鍵KAMF、KNASint、及びKNASencを導出する(S12)。次に、UE30は、AMF33へ、NAS Security Mode Complete messageを送信する(S13)。NAS Security Mode Complete messageは、NAS-MAC、Replayed allowed NSSAIを含む。
【0065】
UE30が、複数のNon-3GPP accessを利用することが可能である場合、NAS SMC messageは、特定のN1インスタンスを示すindicatorを含んでもよい。
【0066】
続いて、
図16を用いて、
図15とは異なる、UE30が利用しているアクセスネットワークに関する情報の送信処理の流れについて説明する。
図16においては、ステップS21及びS23において、
図15のNAS SMC message及びNAS Security Mode Complete messageの代わりに、N1 messageが用いられる。ステップS21において送信されるN1 messageは、5G KSI、N1-instance-indicator、Parameters to derive NAS integrity and encryption keys、及びN1-MACを含む。
【0067】
また、ステップS21において送信されるN1 messageは、AMF33が有するNAS integrity keys及びNAS encryption keysを用いて保護されてもよい。また、ステップS23において送信されるN1 messageは、ステップS22において導出されたNAS integrity keys及びNAS encryption keysを用いて保護されてもよい。
【0068】
続いて、
図17乃至
図23を用いてセキュリティ鍵KSEAFの導出過程の変形例について説明する。
図17乃至
図23においては、主に、5G AKAにおける変形例について説明する。
図17乃至
図23は、コアネットワーク側及びUEのそれぞれにおけるセキュリティ鍵の導出過程を示している。
【0069】
はじめに、
図17を用いてセキュリティ鍵KSEAFの導出過程について説明する。UDM37において、セキュリティ鍵Kから完全性保護鍵IK(Integrity Key)及び暗号鍵CK(Cipher Key)が導出される。次に、UDM37において、5G-AKAが実行されることによって、完全性保護鍵IK及び暗号鍵CKから、セキュリティ鍵KAUSFが導出される。また、UDM37において、完全性保護鍵IK及び暗号鍵CKから、KSEAFが導出される。
【0070】
図18においては、UDM37において、5G-AKAが実行されることなく、完全性保護鍵IK及び暗号鍵CKから、セキュリティ鍵KAUSF及びKSEAFが導出される。
【0071】
図19においては、UDM37において、5G-AKAが実行されることなく、完全性保護鍵IK及び暗号鍵CKから、セキュリティ鍵KAUSFが導出される。さらに、AUSF36において、セキュリティ鍵KAUSFから、セキュリティ鍵KSEAFが導出される。
【0072】
図20においては、UDM37において、セキュリティ鍵Kからセキュリティ鍵KAUSFが導出される。次に、セキュリティ鍵KAUSFから完全性保護鍵IK(Integrity Key)及び暗号鍵CK(Cipher Key)が導出される。次に、UDM37において、5G-AKAが実行されることなく、完全性保護鍵IK及び暗号鍵CKから、セキュリティ鍵KSEAFが導出される。
【0073】
図21においては、UDM37において、セキュリティ鍵Kから5G Master Keyが導出される。次に、UDM37において、5G Master Keyから、5G-AKAが実行されることによって、セキュリティ鍵KAUSF及びセキュリティ鍵EKAUSF(Extended KAUSF)が導出される。次に、AUSF36において、セキュリティ鍵KAUSFからセキュリティ鍵KSEAFが導出される。
【0074】
図22においては、UDM37において、完全性保護鍵IK(Integrity Key)及び暗号鍵CK(Cipher Key)から、5G-AKAが実行されることによって、完全性保護鍵5G-IK及び暗号鍵5G-CKから、セキュリティ鍵KAUSFが導出される。次に、AUSF36において、完全性保護鍵5G-IK及び暗号鍵5G-CKから、セキュリティ鍵KASME及びEKASMEが導出される。次に、AUSF36において、セキュリティ鍵KASMEからセキュリティ鍵KSEAFが導出される。
【0075】
図23は、Key Hierarchyが、EAP-TLS(Extensible Authentication Protocol-Transport Layer Security)をサポートしていることを示している。セキュリティ鍵Kから、EAP-TLS based on PSK(Pre-Shared Key)を実行することによって鍵PMK(Pre Master Key)が導出される。次に鍵PMKから、EAP-TLS based on Certificatesを実行することによって鍵MSK及びEMSKが導出される。次に、UDM37は、鍵MSKからセキュリティ鍵KSEAFを導出し、さらに、鍵MSKからセキュリティ鍵KAUSFを導出する。セキュリティ鍵Kから、EAP-TLS based on PSKを実行することによって鍵MSK及びEMSKが導出されてもよい。EAP-TLS based on PSKにおいては、PSK IDは、registration requestにおいてUE Security Capabilitiesの一部として、UEから送信される。セキュリティ鍵Kは、PSKであってもよい。
【0076】
以上説明したように、AMF33は、Untrusted Non-3GPP AccessのようなNon-3GPP Accessを介して接続してきたUE30と、セキュリティ鍵を共有することができる。
【0077】
(実施の形態3)
続いて、
図24を用いてUE30に関する認証処理の流れについて説明する。
図24において、AUSF36は、認証処理に用いられるAVs(Authentication Vectors)を保持しているとする(S30)。また、SEAF/AMF33は、AMF33がSEAF(Security Anchor Function)を有することを示している。また、ARPF/UDM37は、UDM37がARPF(Authentication credential Repository and Processing Function)を有することを示している。
【0078】
はじめに、AMF33は、AUSF36へ5G-AIR(5G-Authentication Identifier Request)を送信する(S31)。5G-AIRは、UE30に関するSUCI(Subscription Concealed Identifier)を含む。次に、AUSF36は、UDM37との間において、SUPI(Subscription Permanent Identifier)を得るために、SUCIのde-concealmentを実行する。具体的には、AUSF36は、SUCIをUDM37へ送信する。さらに、UDM37は、SUCIからSUPIを抽出する。その後、UDM37は、SUPIをAUSF36へ送信する。
【0079】
次に、AUSF36は、transformed AVもしくはAV*を抽出(retrieve)する(S33)。transformed AVは、RAND、AUTN、及びXRES*を含む。AV*は、RAND、AUTN、XRES*、及びセキュリティ鍵KSEAFを含む。次に、AUSF36は、HXRES*(Hash XRES)を算出する(S34)。例えば、AUSF36は、ハッシュ関数としてSHA-256を用いて、XRES*に関するHXRES*を算出する。
【0080】
次に、AUSF36は、AMF33へ5G-AIA(5G-Authentication Identifier Answer)を送信する(S35)。5G-AIAは、AV*もしくはtransformed AVと、AV IDと,HXRES*とを含む。AV IDは、AV*もしくはtransformed AVを識別する識別情報である。
【0081】
次に、AMF33は、UE30へAuth-Reqを送信する(S36)。Auth-Reqは、RAND AUTN、及びAV IDを含む。次に、UE30は、USIM(Universal Subscriber Identity Module)からRES、CK、及びIDを取得する(S37)。言い換えると、USIMから、UE30の本体であるME(Mobile Equipment)へ、RES、CK、及びIDが出力される。
【0082】
次に、UE30のMEは、RES*を算出する(S38)。
【0083】
次に、UE30は、AMF33へAuth-Resを送信する(S39)。Auth-Resは、RES*及びAV IDを含む。次に、AMF33は、HRES*を算出する(S40)。例えば、AMF33は、ハッシュ関数としてSHA-256を用いて、RES*に関するHRES*を算出する。
【0084】
次に、AMF33は、HRES*とHXRES*とが一致しているか否かを判定するために、HREX*とHXRES*とを比較する(S41)。HRES*とHXRES*とが一致している場合、AMF33は、UE30を正当なUEと判定する。次に、AMF33は、AUSF36へ5G-AC(5G-Authentication Complete)を送信する(S42)。5G-ACは、RES*及びAV IDを含む。
【0085】
UE30が、一つのAVのみを供給された場合、ステップS35、S36、S39、及びS42において、AV IDは含まれなくてもよい。
【0086】
続いて、
図25を用いて、
図24とは異なるUE30に関する認証処理の流れについて説明する。
図25においては、AMF33が、認証処理に用いられるAVs(Authentication Vectors)を保持しているとする(S50)。
【0087】
ステップS51及びS52は、
図24におけるステップS33及びS34と同様であるため詳細な説明を省略する。ステップS51及びS52においては、AMF33が、ステップS33及びS34において説明した処理を実行する。
【0088】
ステップS53乃至S59は、
図24のステップS36乃至S42と同様であるため詳細な説明を省略する。
【0089】
続いて、
図26を用いて、
図24及び
図25とは異なるUE30に関する認証処理の流れについて説明する。ステップS61及びS62は、
図24のステップS31及びS32と同様であるため詳細な説明を省略する。
【0090】
次に、AUSF36は、UE30に対応するセキュリティ鍵KAUSFを抽出する(S63)。次に、AUSF36は、セキュリティ鍵KAUSF、PLMN ID、PLMN countもしくはSN(Serving Network) count、及びSN nameを用いて新たなセキュリティ鍵KSEAFを導出する(S64)。次に、AUSF36は、セキュリティ鍵KAUSF及びRANDを用いてXRESを算出し、さらに、HXRESを算出する(S65)。
【0091】
次に、AUSF36は、AMF33へ5G-AIAを送信する(S66)。5G-AIAは、HXRES、RAND、indicator for use of KAUSFを含む。次に、AMF33は、UE30へAuth-Reqを送信する(S67)。Auth-Reqは、RAND、Indicator for use of KAUSFを含む。
【0092】
次に、UE30は、セキュリティ鍵KAUSF、PLMN ID、PLMN countもしくはSN count、及びSN nameを用いて新たなセキュリティ鍵KSEAFを算出する(S68)。次に、UE30は、セキュリティ鍵KAUSF及びRANDを用いてRESを算出する(S69)。次に、UE30は、AMF33へAuth-Resを送信する(S70)。Auth-Resは、RESを含む。
【0093】
次に、AMF33は、HRESとHXRESとが一致しているか否かを判定するために、HREXとHXRESとを比較する(S72)。AMF33は、HRESとHXRESとが一致している場合、UE30を正当なUEと判定する。次に、AMF33は、AUSF36へ5G-ACを送信する(S73)。5G-ACはRESを含む。
【0094】
ステップS64及びS68は省略されてもよい。また、ステップS65及びS69は、AUSF36が、ARPF(Authentication Credential Repository and Processing Function)エンティティへXRESを要求する場合、省略されてもよい。また、セキュリティ鍵KAUSFは、SNに依存しない場合、PLMN間において用いられることが可能である。セキュリティ鍵KAUSFがSNに依存する場合、セキュリティ鍵KAUSF、PLMN ID、PLMN countもしくはSN count、及びSN nameを用いることなく、PLMN内においてセキュリティ鍵KAUSFが用いられることが可能である。
【0095】
続いて、
図27を用いて、
図24乃至
図26とは異なるUE30に関する認証処理の流れについて説明する。はじめに、UE30は、AMF33へRegistration Requestを送信する(S81)。Registration Requestは、UE ID、UE Security Capabilities with PRF IDsもしくはPMK ID、Auth-method、AN type、Authentication restrictions、Auth-type、Re-auth type、AV ID、及び5G KSIを含む。UE Security Capabilitiesは、Ciphersuites、PFR IDs、及びPSK IDsを含む。
【0096】
次に、AMF33は、Re-auth type、AN type、及びauthentication restrictionsに基づいて、re-authentication optionを選択する(S82)。Re-auth typeは、transformed AVもしくはAV*を用いてauthenticationを実施するか、セキュリティ鍵KAUSFを用いて導出されたセキュリティ鍵KSEAFを用いてauthenticationを実施するか、もしくは、古いセキュリティ鍵KSEAFを用いて導出された新たなセキュリティ鍵KSEAFを用いてauthenticationを実施するか、を示す情報である。
【0097】
AN typeは、アクセスネットワークを示す情報である。authentication restrictionsは、UE30においてサポートされている認証方法もしくはUE30に許可されている認証方法に関する情報である。例えば、UE30においてサポートされている認証方法は、EAP-TLS based on certificatesであってもよい。
【0098】
次に、AMF33は、UE30へAuth-Reqを送信する(S83)。Auth-Reqは、RAND、AUTN、AV-ID、及びRe-auth typeを含む。次に、UE30は、Network authenticationを実施する(S84)。次に、UE30は、AMF33へAuth-Resを送信する(S85)。Auth-Resは、RES*を含む。RES*は、ステップS84において算出される。
【0099】
次に、AMF33は、UE authenticationを実施する(S86)。次に、AMF33は、AUSF36へ5G-ACを送信する(S87)。5G-ACは、RES*及びAV IDを含む。
【0100】
続いて、
図28を用いて、ハンドオーバ最中のセキュリティ鍵KAMF*の導出手順について説明する。また、以下の説明においては、ハンドオーバ元のAMFをSource AMF33_1とし、ハンドオーバ先のAMFを、Target AMF33_2とする。
【0101】
はじめに、Source AMF33_1は、古いセキュリティ鍵KAMF及びCountを用いてセキュリティ鍵KAMF*を導出する(S91)。例えば、
図29に示すように、古いセキュリティ鍵KAMF及びCountをKDFへ入力することによって、セキュリティ鍵KAMF*が導出される。
【0102】
次に、Source AMF33_1は、Forward Relocation RequestをTarget AMF33_2へ送信する(S92)。Forward Relocation Requestは、5G-GUTI(Globally Unique Temporary Identifier)、AUSF ID、セキュリティ鍵KAMF*、UE security capabilities、及びCountを含む。
【0103】
続いて、
図30を用いて、ハンドオーバ最中のセキュリティ鍵KSEAF*の導出手順について説明する。
【0104】
はじめに、Source AMF33_1は、古いセキュリティ鍵KSEAF及びCountを用いてセキュリティ鍵KSEAF*を導出する(S101)。例えば、
図31に示すように、古いセキュリティ鍵KSEAF及びCountをKDFへ入力することによって、セキュリティ鍵KSEAF*が導出される。
【0105】
次に、Source AMF33_1は、Forward Relocation RequestをTarget AMF33_2へ送信する(S102)。Forward Relocation Requestは、5G-GUTI、AUSF ID、セキュリティ鍵KSEAF*、UE security capabilities、及びCountを含む。
【0106】
続いて、
図32を用いて、
図30とは異なるハンドオーバ最中のセキュリティ鍵KSEAF*の導出手順について説明する。
【0107】
はじめに、Source AMF33_1は、Relocation RequestをAUSF36へ送信する(S111)。Relocation Requestは、5G-GUTI、UE security capabilities、及び古いセキュリティ鍵KSEAFを含む。次に、AUSF36は、古いセキュリティ鍵KSEAF、PLMN ID、PLMN countもしくはSN count、及びSN nameを用いてセキュリティ鍵KSEAF*を導出する(S112)。例えば、
図33に示すように、古いセキュリティ鍵KSEAF、PLMN ID、PLMN countもしくはSN count、及びSN nameをKDFへ入力することによって、セキュリティ鍵KSEAF*が導出される。
【0108】
次に、AUSF36は、Forward Relocation RequestをTarget AMF33_2へ送信する(S113)。Forward Relocation Requestは、5G-GUTI、セキュリティ鍵KSEAF*、UE security capabilities、及びCountを含む。
【0109】
続いて、
図34を用いて、
図32とは異なるハンドオーバ最中のセキュリティ鍵KSEAF*の導出手順について説明する。
【0110】
はじめに、Source AMF33_1は、Relocation RequestをAUSF36へ送信する(S121)。Relocation Requestは、5G-GUTI及びUE security capabilitiesを含む。次に、AUSF36は、古いセキュリティ鍵KAUSF、PLMN ID、PLMN countもしくはSN count、及びSN nameを用いてセキュリティ鍵KSEAF*を導出する(S122)。例えば、
図35に示すように、古いセキュリティ鍵KAUSF、PLMN ID、PLMN countもしくはSN count、及びSN nameをKDFへ入力することによって、セキュリティ鍵KSEAF*が導出される。
【0111】
次に、AUSF36は、Forward Relocation RequestをTarget AMF33_2へ送信する(S123)。Forward Relocation Requestは、5G-GUTI、セキュリティ鍵KSEAF*、UE security capabilities、及びCountを含む。
【0112】
続いて、
図36を用いてHandover intra PLMN from 3GPP to non-3GPP accessの処理の流れについて説明する。はじめに、gNB31は、HO(Handover)を開始することを決定すると、HO required messageを生成する(S131a)。HO required messageは、GUTIのようなUE's identity及びUE’s capabilitiesを含む。ここで、UE30がHOを開始することを決定した場合、UE30が、gNB31へHO required messageを送信してもよい(S131b)。この場合のHO required messageにも、GUTIのようなUE's identity及びUE’s capabilitiesを含む。また、UE30が送信するHO required messageは、3GPP Accessにおいて確立されたNAS securityによって保護される。さらに、HO required messageは、UE30が接続する、もしくは、過去に接続したN3IWFの識別情報を含む。
【0113】
次に、gNB31は、AMF33へHO required messageを送信する(S132)。AMF relocationが、通常のHO procedureに基づいて実行されてもよい。次に、AMF33は、UE's capabilitiesが、HO requestを送信するかどうかを決定するために有効であるか否かをチェックする(S133)。UE's capabilitiesは、security capabilities及びN3IWF38へのaccess rightを含む。
【0114】
次に、AMF33は、Source SMF34_1へ、SM(Session Management) contextを提供することを要求し、Source SMF34_1は、AMF33へSM contextを提供する(S134)。UE30がmultiple sessionsを有している場合、AMF33は、複数のSMFへSM contextの提供を要求する。
【0115】
次に、AMF33は、Non-3GPP Accessに関するセキュリティ鍵KN3IWFを導出する(S135)。セキュリティ鍵KN3IWFは、N3IWF38へ送信される。次に、AMF33は、受け取ったSM contextに基づいて、Target SMF34_2へCreate session requestを送信する。さらに、Target SMF34_2は、セッションのためのリソースを割り当て、AMF33へCreate session responseを送信する(S136)。
【0116】
次に、AMF33は、N3IWF38へHO requestを送信する(S137)。AMF33は、UE30から送信された識別情報に基づいてN3IWF38を選択してもよい。HO requestは、セッション及びベアラ確立に関する情報を含んでもよい。また、HO requestは、security context、セキュリティ鍵の識別情報(KSIもしくはKSI Set Identifier)、要求されたsecurity configurationsが必要か否かを示す情報、及び用いられるアルゴリズムを含んでもよい。security configurationsは、完全性保護及び暗号化に関する情報であってもよい。
【0117】
次に、N3IWF38は、relocation requestを受け入れることができるかどうかを決定するためにUE’s capabilities及びaccess rightが有効か否かをチェックしてもよい(S138)。
【0118】
次に、N3IWF38は、ベアラ確立のために必要なリソースを割り当て、HO request ACKをAMF33へ送信する(S139)。次に、AMF33は、gNB31へHO commandを送信する(S140)。HO commandは、security configurationsを含む。gNB31は、UE30へHO commandを送信する(S141)。gNB31は、3GPP Accessにおいて用いられるsecurity contextを削除する。
【0119】
次に、UE30とN3IWF38との間においてIPsecが確立される(S142)。次に、UE30は、N3IWF38へHO completeを送信する(S143)。次に、N3IWF38は、AMF33へHO notifyを送信する(S144)。次に、AMF33、Target SMF34_2及びTarget UPFとの間において、Bearer and session modificationが実行される(S145)。
【0120】
次に、
図37を用いて、
図36とは異なるHandover intra PLMN from 3GPP to non-3GPP accessの処理の流れについて説明する。
図37においては、
図36のgNB31において実行される処理と、N3IWF38において実行される処理とが入れ替わっている。その他の処理については、
図36と同様なので、詳細な説明を省略する。
【0121】
続いて、
図38を用いてPLMN2においてactive connectionが存在しない場合における、PLMN1における3GPP AccessからPLMN2におけるNon-3GPP Accessへの登録処理の流れについて説明する。PLMN1及びPLMN2は、それぞれが、異なるPLMNであることを示している。PLMN1及びPLMN2は、HPLMNもしくはVPLMNであってもよい。
【0122】
はじめに、UE30は、N3IWF38を介してTarget AMF33_2へRegistration Requestを送信する(S171)。Registration Requestは、5G-GUTI、SUCIもしくはSUPIを含む。さらに、Registration Requestは、UE security capabilities、Auth-method、AN type、Authentication restrictions、Re-auth type、AV ID、及び5G KSIを含む。
【0123】
次に、Target AMF33_2は、AUSF36へ5G-AIRを送信する(S172)。5G-AIRは、5G-GUTI、SUCIもしくはSUPIを含む。さらに、5G-AIRは、AV ID及びSN nameを含む。次に、AUSF36は、UDM37との間において、SUPI(Subscription Permanent Identifier)を得るために、SUCIのde-concealmentを実行する(S173)。
【0124】
次に、AUSF36は、十分な数の未使用AVが利用可能か否かを判定する(S174)。AUSF36は、十分な数の未使用AVが利用可能であると判定した場合、ステップS176の処理を実行する。AUSF36は、十分な数の未使用AVが利用可能ではないと判定した場合、ステップS175aもしくはS175bの処理を実行する。
【0125】
ステップS175aは、セキュリティ鍵KSEAFとして直接的に用いられるセキュリティ鍵KAUSFもしくはセキュリティ鍵KAUSFから導出されるセキュリティ鍵KSEAFを用いてFast re-authを実行する。ステップS175bは、AUSF36が、UDM37とFull authenticationを実行する。ステップS176は、Target AMF33_2へ、5G-AIAを送信する(S176)。5G-AIAは、SUPI、SN name、及びAVsを含む。
【0126】
次に、Target AMF33_2は、Authentication RequestをUE30へ送信する(S177)。Authentication Requestは、RAND及びAUTNを含む。次に、UE30は、セキュリティ鍵KSEAFを導出する(S178)。次に、UE30は、Authentication ResponseをTarget AMF33_2へ送信する(S179)。Authentication Responseは、RES*を含む。
【0127】
続いて、
図39を用いて、
図38とは異なる、PLMN2においてactive connectionが存在しない場合における、PLMN1における3GPP AccessからPLMN2におけるNon-3GPP Accessへの登録処理の流れについて説明する。
【0128】
ステップS181は、
図38のステップS171と同様であるため詳細な説明を省略する。次に、Target AMF33_2は、UE identityをチェックする(S182)。次に、Target AMF33_2は、Source AMF 33_1へUE identification Requestを送信する(S183)。UE identification Requestは、5G-GUTI、SUCI、もしくはSUPIを含む。次に、Source AMF33_1は、UE identification ResponseをTarget AMF33_2へ送信する(S184)。UE identification Responseは、5G-GUTI、SUCI、もしくはSUPI、さらに、AUSF IDを含む。以降の処理は、
図38のステップS172以降の処理と同様であるため詳細な説明を省略する。
【0129】
続いて、
図40を用いて、PLMN2においてactive connectionが存在しない場合における、PLMN1における3GPP AccessからPLMN2におけるNon-3GPP Accessへのハンドオーバの流れについて説明する。
図40は、PLMN1における処理と、PLMN2における処理を示している。
【0130】
はじめに、UE30は、gNB31へMeasurement Reportを送信する(S191)。次に、gNB31は、UE mobility restrictionsをチェックした後に、HOを実行することを決定する(S192)。次に、gNB31は、Source AMF33_1へHandover Requiredを送信する(S193)。次に、Source AMF33_1は、セキュリティ鍵KSEAF*を導出する(S194)。次に、Source AMF33_1は、Forward Relocation RequestをTarget AMF33_2へ送信する(S195)。Forward Relocation Requestは、5G-GUTI、AUSF I、セキュリティ鍵KSEAF*、UE security capabilitiesを含む。
【0131】
次に、Target AMF33_2は、セキュリティ鍵KAMFを導出する(S196)。次に、Target AMF33_2は、N3IWF38へHandover Requestを送信する(S197)。Handover Requestは、UE security capabilities及びNSSAIを含む。
【0132】
次に、N3IWF38は、UE30において、NSSAIがサポートされているか否かをチェックする(S198)。次に、N3IWF38は、セキュリティ鍵Knon-3gppを導出する(S199)。次に、N3IWF38は、Handover Request AckをTarget AMF33_2へ送信する(S200)。次に、Target AMF33_2は、Source AMF33_1へForward Relocation Responseを送信する(S201)。次に、Source AMF33_1は、gNB31へHandover Commandを送信する(S202)。次に、gNB31は、UE30へHandover Commandを送信する(S203)。
【0133】
次に、UE30は、セキュリティ鍵KSEAF*、KAMF、及びKnon-3gppを導出する(S204)。次に、UE30は、N3IWF38へHandover Completeを送信する(S205)。
【0134】
続いて、
図41及び
図42を用いて、
図40とは異なるPLMN2においてactive connectionが存在しない場合における、PLMN1における3GPP AccessからPLMN2におけるNon-3GPP Accessへのハンドオーバの流れについて説明する。
図41は、PLMN1における処理と、PLMN2における処理を示している。
【0135】
ステップS211乃至S213は、
図40のステップS191乃至S193と同様であるため詳細な説明を省略する。次に、Source AMF33_1は、AUSF36へRelocation Requestを送信する(S214)。Relocation Requestは、5G-GUTI、UE security capabilities、及びセキュリティ鍵KSEAFを含む。
【0136】
次に、ステップS215においてAUSF36は、セキュリティ鍵KSEAFを導出する。ここで、AUSF36は、処理aとして、セキュリティ鍵KSEAFをrefreshする。もしくは、AUSF36は、処理b以降を実行する。ステップS215における処理b及びcと、ステップS216a及びS216bとは、
図38のステップS174における処理a及びbと、ステップS175a及びS175bと同様であるため詳細な説明を省略する。また、ステップS216bにおいては、Full authenticationの代わりに、セキュリティ鍵KSEAFを導出する。
【0137】
ステップ215の処理bの後、及び、ステップS216aもしくはS216bの後に、AUSF36は、Forward Relocation RequestをTarget AMF33_2へ送信する(S217)。Forward Relocation Requestは、セキュリティ鍵KSEAFと、SUCIもしくはSUPIと、UE security capabilitiesとを含む。
【0138】
次に、Target AMF33_2は、セキュリティ鍵KAMFを導出する。次に、Target AMF33_2は、Handover RequestをN3IWF38へ送信する(S219)。
【0139】
図42に移り、ステップS220乃至S222は、
図40のステップS198乃至S200と同様であるため詳細な説明を省略する。次に、Target AMF33_2は、AUSF36へForward Relocation Requestを送信する(S223)。次に、AUSF36は、Source AMF33_1へRelocation Responseを送信する(S224)。
【0140】
ステップS225乃至S228は、
図40のステップS202乃至205と同様であるため詳細な説明を省略する。
【0141】
続いて、
図43を用いてPLMN2においてactive connectionが存在する場合における、PLMN1における3GPP AccessからPLMN2におけるNon-3GPP Accessへのハンドオーバの流れについて説明する。また、PLMN1におけるgNBをgNB31_1とし、PLMN2におけるgNBをgNB31_2とする。
【0142】
ステップS231乃至S234は、
図41のステップS211乃至S214と同様であるため詳細な説明を省略する。ただし、ステップS234においては、Relocation Requestは、5G-GUTI、SUCI、もしくはSUPIと、UE security capabilities、と、セキュリティ鍵KSEAFとを含む。
【0143】
次に、AUSF36は、SUPI(Subscription Permanent Identifier)を得るために、SUCIのde-concealmentを実行する(S235)。次に、AUSF36は、セキュリティ鍵KSEAFを抽出するか、もしくは、新たなセキュリティ鍵KSEAFとして用いるためにセキュリティ鍵KSEAF*を導出する(S236)。
【0144】
次に、AUSF36は、Target AMF33_2へForward Relocation Requestを送信する(S237)。Forward Relocation Requestは、新たなセキュリティ鍵KSEAFと、SUCIもしくはSUPIと、UE security capabilitiesとを含む。
【0145】
次に、Target AMF33_2は、セキュリティ鍵KAMFを導出する(S238)。次に、Target AMF33_2は、セキュリティ鍵Knon-3gppを導出する(S239)。ステップS240乃至S248は、
図41のステップS219、
図42のステップS220、ステップS222乃至S228と同様であるため詳細な説明を省略する。
【0146】
続いて、
図44を用いて、
図43とは異なる、PLMN2においてactive connectionが存在する場合における、PLMN1における3GPP AccessからPLMN2におけるNon-3GPP Accessへのハンドオーバの流れについて説明する。
【0147】
ステップS251乃至S255は、
図40のステップS191乃至S195と同様であるため詳細な説明を省略する。ただし、ステップS255においては、Forward Relocation Requestは、5G-GUTI、SUCI、もしくはSUPIと、AUSF IDと、UE security capabilities、と、セキュリティ鍵KSEAF*とを含む。
【0148】
次に、Target AMF33_2は、SUPIもしくはSUCIに対応するsecurity contextを抽出する(S256)。次に、Target AMF33_2は、セキュリティ鍵Knon-3gppを導出する(S257)。
【0149】
ステップS258乃至S265は、
図40のステップS197、S198、S200乃至S205と同様であるため詳細な説明を省略する。
【0150】
続いて、
図45を用いて、PLMN2においてactive connectionが存在しない場合における、PLMN1におけるNon-3GPP AccessからPLMN2における3GPP Accessへの登録処理の流れについて説明する。
【0151】
図38においては、UE30が、N3IWF38を介してTarget AMF33_2へRegistration Requestを送信する。これに対して、
図45においては、ステップS271において、UE30が、gNB31を介してTarget AMF33_2へRegistration Requestを送信する。ステップS272乃至ステップS279は、
図38のステップS172乃至S179と同様であるため詳細な説明を省略する。
【0152】
続いて、
図46を用いて、
図45と異なる、PLMN2においてactive connectionが存在しない場合における、PLMN1におけるNon-3GPP AccessからPLMN2における3GPP Accessへの登録処理の流れについて説明する。
【0153】
図39においては、UE30が、N3IWF38を介してTarget AMF33_2へRegistration Requestを送信する。これに対して、
図46においては、ステップS281において、UE30が、gNB31を介してTarget AMF33_2へRegistration Requestを送信する。次に、Target AMF33_2は、5G-GUTIをチェックする(S282)。ステップS283以降の処理は、
図39のステップS183以降の処理と同様であるため詳細な説明を省略する。
【0154】
続いて、
図47を用いて、PLMN2においてactive connectionが存在しない場合における、PLMN1におけるNon-3GPP AccessからPLMN2における3GPP Accessへのハンドオーバの流れについて説明する。
【0155】
ステップS291乃至S295は、
図40のステップS251乃至S255と同様であるため詳細な説明を省略する。ただし、
図40におけるgNB31は、
図47においてはN3IWF38へ入れ替わっており、
図40におけるN3IWF38は、
図47においてはgNB31に入れ替わっている。また、ステップS295において送信されるForward Relocation Requestは、5G-GUTI、AUSF ID、セキュリティ鍵KSEAF*、UE security capabilitiesを含む。
【0156】
次に、Target AMF33_2は、セキュリティ鍵KAMFを導出する(S296)。次に、Target AMF33_2は、セキュリティ鍵KgNBを導出する(S297)。ステップS298乃至S305は、
図40のステップS197、S198、S200乃至S205と同様であるため詳細な説明を省略する。
【0157】
続いて、
図48及び
図49を用いて、
図47とは異なる、PLMN2においてactive connectionが存在しない場合における、PLMN1におけるNon-3GPP AccessからPLMN2における3GPP Accessへのハンドオーバの流れについて説明する。
【0158】
ステップS311乃至S318は、
図41のステップS211乃至S218と同様であるため詳細な説明を省略する。ただし、
図41におけるgNB31は、
図48においてはN3IWF38へ入れ替わっており、
図41におけるN3IWF38は、
図48においてはgNB31に入れ替わっている。
【0159】
次に、Target AMF33_2は、セキュリティ鍵KgNBを導出する(S319)。次に、
図49に移り、ステップS320乃至S328は、
図41のステップS219及び
図42のステップS220、さらに、
図42のステップS222乃至S228と同様であるため詳細な説明を省略する。
【0160】
続いて、
図50を用いて、PLMN2においてactive connectionが存在する場合における、PLMN1におけるNon-3GPP AccessからPLMN2における3GPP Accessへの登録処理の流れについて説明する。
【0161】
ステップS331乃至S348は、
図43のステップS231乃至S248と同様であるため詳細な説明を省略する。ただし、
図43におけるgNB31_1及びgNB31_2は、
図50においてはN3IWF38_1及びN3IWF38_2へ入れ替わっている。さらに、
図43におけるN3IWF38は、
図50においてはgNB31に入れ替わっている。また、ステップS339においては、
図43のステップS239とは異なり、Target AMF33_2は、セキュリティ鍵KgNBを導出する。
【0162】
続いて、
図51を用いて、
図50とは異なる、PLMN2においてactive connectionが存在する場合における、PLMN1におけるNon-3GPP AccessからPLMN2における3GPP Accessへの登録処理の流れについて説明する。
【0163】
ステップS351乃至S365は、
図44におけるステップS251乃至S265と同様であるため詳細な説明を省略する。ただし、
図44におけるgNB31_1及びgNB31_2は、
図51においてはN3IWF38_1及びN3IWF38_2へ入れ替わっている。さらに、
図44におけるN3IWF38は、
図51においてはgNB31に入れ替わっている。また、ステップS357においては、
図44のステップS257とは異なり、Target AMF33_2は、セキュリティ鍵KgNBを導出する。
【0164】
以上説明したように、実施の形態3にかかる認証処理を実行することによって、異なるPLMN間におけるハンドオーバを実行することができる。
【0165】
(実施の形態4)
続いて、
図52を用いてUE initiated HO intra PLMN, intra AMF from 3GPP to non-3GPP Accessの処理の流れについて説明する。
【0166】
はじめに、UE30は、N3IWF38を介してAMF33へRegistration request via non-3GPP accessを送信する(S371)。AMF33は、UE30が、3GPP accessを経由して接続するAMFでもある。Registration request via non-3GPP accessは、GUTIのようなUE’s identity及びUE’s capabilitiesを含む。
【0167】
ここで、3GPP accessにおいて用いられるNAS security keysが、Non-3GPP accessにおいて用いられるNAS security keysと異なる場合について説明する。この場合、Registration request via non-3GPP accessは、Non-3GPP accessにおいて用いられるNAS security keysによって保護される。NAS security keysは、UE30とAMF33とにおいて、既に導出されている。
【0168】
また、3GPP accessにおいて用いられるNAS security keysが、Non-3GPP accessにおいて用いられるNAS security keysと同じ場合もある。この場合、Registration request via non-3GPP accessは、3GPP accessにおいて既に用いられているNAS security keysによって保護される。
【0169】
次に、AMF33は、security capabilitiesを含むUE’s capabilitiesが有効かどうか、さらに、UE30がN3IWF38を介してコアネットワークへアクセスする権利を有しているかどうかをチェックする(S372)。AMF33は、AUSF36に対して、UE’s capabilities及びアクセスする権利に関する情報を要求してもよい。
【0170】
次に、AMF33は、Non-3GPP accessにおいて用いられるセキュリティ鍵Knon-3gppを導出する(S373)。
【0171】
次に、AMF33は、N3IWF38を介してUE30へRegistration request responseを送信する(S374)。Registration request responseは、セキュリティ鍵Knon-3gpp、KSI(Key Set Identifier)のようなセキュリティ鍵の識別情報、暗号化及び完全性保護のセキュリティconfigurationsが必要かどうかを示す情報、及び用いられたアルゴリズムを含む。
【0172】
次に、UE30とN3IWF38との間において、セキュリティ鍵Knon-3gppを用いることによって、IPsecが確立される(S375)。UE30は、セキュリティ鍵KAMFからセキュリティ鍵Knon-3gppを導出する。さらに、UE30は、N3IWF38を介してAMF33へRegistration completeを送信する(S376)。次に、UE30とUPF35との間において、Non-3GPP accessのためのPDU sessionが確立する(S377)。セキュリティは、セキュリティ鍵Knon-3gppを用いるIPsecを用いてUE30とN3IWF38との間において確立される。
【0173】
次に、UE30とgNB31との間において用いられるセキュリティ鍵を含むSecurity contextが削除される(S378)。UE30もしくはAMF33は、Security contextを削除するためにgNB31へrequest messageを送信してもよい。
【0174】
続いて、
図53を用いて、
図52とは異なるUE initiated HO intra PLMN, intra AMF from 3GPP to non-3GPP Accessの処理の流れについて説明する。
【0175】
はじめに、UE30は、gNB31を介してAMF33へHO requestを送信する(S381)。HO requestは、N3IWF IDを含む。ステップS382乃至S388は、
図52のステップS372乃至S378と同様であるため詳細な説明を省略する。但し、ステップS384においては、
図52のステップS374におけるRegistration request responsen代わりに、HO responseが送信される。また、ステップS386においては、
図52のステップS376におけるRegistration completeの代わりに、HO completeが送信される。
【0176】
続いて、
図54を用いて、UE initiated HO intra PLMN, inter AMF from 3GPP to non-3GPP Accessの処理の流れについて説明する。
【0177】
はじめに、UE30は、Registration request via non-3GPP accessをN3IWF38を介してTarget AMF33_2へ送信する(S391)。次に、Target AMF33_2は、Source AMF33_1へUE context requestを送信する(S392)。次に、Source AMF33_1は、UE30に関するUE’s security capabilitiesを含むUE context responseをTarget AMF33_2へ送信する(S393)。ステップS394乃至S400は、
図52のステップS372乃至S378と同様であるため詳細な説明を省略する。
【0178】
続いて、
図55を用いて、Network initiated HO intra PLMN, inter AMF, from 3GPP to non-3GPP accessの処理の流れについて説明する。ステップS411乃至S414は、
図37のステップS151乃至S154と同様であるため詳細な説明を省略する。
【0179】
次に、Source AMF33_1は、セキュリティ鍵KAMFを更新する(S415)。次に、Source AMF33_1は、Target AMF33_2へRelocation requestを送信する(S416)。次にTarget AMF33_2は、UE30に関するUE's capabilitiesが、HO requestを送信するかどうかを決定するために有効であるか否かをチェックする(S417)。UE's capabilitiesは、security capabilities及びN3IWF38へのaccess rightを含む。次に、Target AMF33_2は、セキュリティ鍵を導出する(S418)。
【0180】
ステップS419乃至S422は、
図37のステップS156乃至159と同様であるため詳細な説明を省略する。次に、Target AMF33_2は、Source AMF33_1へ、Relocation responseを送信する(S423)。ステップS424乃至S428は、
図37のステップS160乃至S164と同様であるため詳細な説明を省略する。
【0181】
続いて、
図56を用いて、UE initiated HO intra PLMN, intra AMF from non-3GPP to 3GPP accessの処理の流れについて説明する。ステップS431乃至S437は、
図54のステップS391、S394乃至S396、S398乃至S400と同様であるため詳細な説明を省略する。ただし、
図56においては、UE30とAMF33との間のメッセージは、N3IWF38ではなくgNB31を介して伝送される。また、ステップS435において、UE30は、セキュリティ鍵KAMFからセキュリティ鍵KgNBを導出する。また、UE30とgNB31との間のセキュリティが確立される。
【0182】
続いて、
図57を用いて
図56とは異なる、UE initiated HO intra PLMN, intra AMF from non-3GPP to 3GPP accessの処理の流れについて説明する。はじめに、UE30は、N3IWF38を介してAMF33へHO requestを送信する(S441)。HO requestは、gNB IDを含む。ステップS442及びS443は、
図56のステップS432及びS433と同様であるため詳細な説明を省略する。
【0183】
次に、AMF33は、gNB31を介してUE30へHO responseを送信する(S444)。次に、UE30は、gNB31を介してAMF33へHO completeを送信する(S445)。ステップS446及びS447は、
図56のステップS436及びS437と同様であるため詳細な説明を省略する。
【0184】
続いて、
図58を用いて、UE initiated HO intra PLMN, intra AMF from non-3GPP to 3GPP accessの処理の流れについて説明する。ステップS451乃至S459は、
図54のステップS397の処理が省略されている以外は、
図54において実行される処理と同様であるため、詳細な説明を省略する。
【0185】
続いて、
図59を用いて、Network Initiated HO intra PLMN, intra AMF from non-3GPP to 3GPP accessの処理の流れについて説明する。ステップS461乃至S474は、
図37のステップS151乃至S164と同様であるため詳細な説明を省略する。ただし、ステップS465においては、AMF33は、ステップS155においてセキュリティ鍵KgNBを導出していたのと異なり、セキュリティ鍵Knon-3gppを導出する。
【0186】
続いて、
図60を用いて、Network Initiated HO intra PLMN, intra AMF from non-3GPP to 3GPP accessの処理の流れについて説明する。
図60においては、
図55のgNB31において実行される処理と、N3IWF38において実行される処理とが入れ替わっている。その他の処理については、
図55と同様なので、詳細な説明を省略する。
【0187】
以上説明したように、実施の形態4においては、同一PLMN間におけるハンドオーバを実行することができる。
【0188】
続いて以下では、上述の複数の実施形態で説明された通信端末10及びコアネットワーク装置20の構成例について説明する。
【0189】
図61は、通信端末10の構成例を示すブロック図である。Radio Frequency(RF)トランシーバ1101は、AN50と通信するためにアナログRF信号処理を行う。RFトランシーバ1101により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ1101は、アンテナ1102及びベースバンドプロセッサ1103と結合される。すなわち、RFトランシーバ1101は、変調シンボルデータをベースバンドプロセッサ1103から受信し、送信RF信号を生成し、送信RF信号をアンテナ1102に供給する。変調シンボルデータは、OFDM(Orthogonal Frequency Division Multiplexing)シンボルデータであってもよい。また、RFトランシーバ1101は、アンテナ1102によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ1103に供給する。
【0190】
ベースバンドプロセッサ1103は、無線通信のためのデジタルベースバンド信号処理(データプレーン処理)とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮/復元、(b) データのセグメンテーション/コンカテネーション、及び(c) 伝送フォーマット(伝送フレーム)の生成/分解を含む。さらに、デジタルベースバンド信号処理は、(d) 伝送路符号化/復号化、及び(e) 変調(シンボルマッピング)/復調を含む。さらに、デジタルベースバンド信号処理は、(f) Inverse Fast Fourier Transform(IFFT)によるOFDMシンボルデータ(ベースバンドOFDM信号)の生成などを含む。一方、コントロールプレーン処理は、レイヤ1、レイヤ2、及びレイヤ3の通信管理を含む。レイヤ1は、例えば、送信電力制御である。レイヤ2は、例えば、無線リソース管理、及びhybrid automatic repeat request(HARQ)処理である。レイヤ3は、例えば、アタッチ、モビリティ、及び通話管理に関するシグナリングである。
【0191】
例えば、LTEおよびLTE-Advancedの場合、ベースバンドプロセッサ1103によるデジタルベースバンド信号処理は、Packet Data Convergence Protocol(PDCP)レイヤ、Radio Link Control(RLC)レイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ1103によるコントロールプレーン処理は、Non-Access Stratum(NAS)プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。
【0192】
ベースバンドプロセッサ1103は、デジタルベースバンド信号処理を行うモデム・プロセッサとコントロールプレーン処理を行うプロトコルスタック・プロセッサを含んでもよい。モデム・プロセッサは、例えば、Digital Signal Processor(DSP)である。コントロールプレーン処理を行うプロトコルスタック・プロセッサは、例えば、Central Processing Unit(CPU)、又はMicro Processing Unit(MPU)である。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ1104と共通化されてもよい。
【0193】
アプリケーションプロセッサ1104は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ1104は、複数のプロセッサ(複数のプロセッサコア)を含んでもよい。アプリケーションプロセッサ1104は、メモリ1106又は図示されていないメモリから読み出されたシステムソフトウェアプログラム及び様々なアプリケーションプログラムを実行することによって、通信端末10の各種機能を実現する。システムソフトウェアプログラムは、例えば、Operating System(OS)であってもよい。アプリケーションプログラムは、例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーションであってもよい。
【0194】
いくつかの実装において、
図61に破線(1105)で示されているように、ベースバンドプロセッサ1103及びアプリケーションプロセッサ1104は、1つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ1103及びアプリケーションプロセッサ1104は、1つのSystem on Chip(SoC)デバイス1105として実装されてもよい。SoCデバイスは、システムLarge Scale Integration(LSI)またはチップセットと呼ばれることもある。
【0195】
メモリ1106は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ1106は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory(SRAM)若しくはDynamic RAM(DRAM)又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory(MROM)、Electrically Erasable Programmable ROM(EEPROM)、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ1106は、ベースバンドプロセッサ1103、アプリケーションプロセッサ1104、及びSoC1105からアクセス可能な外部メモリデバイスを含んでもよい。メモリ1106は、ベースバンドプロセッサ1103内、アプリケーションプロセッサ1104内、又はSoC1105内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ1106は、Universal Integrated Circuit Card(UICC)内のメモリを含んでもよい。
【0196】
メモリ1106は、上述の複数の実施形態で説明された通信端末10による処理を行うための命令群およびデータを含むソフトウェアモジュール(コンピュータプログラム)を格納してもよい。いくつかの実装において、ベースバンドプロセッサ1103又はアプリケーションプロセッサ1104は、当該ソフトウェアモジュールをメモリ1106から読み出して実行することで、上述の実施形態で説明された通信端末10の処理を行うよう構成されてもよい。
【0197】
図62は、コアネットワーク装置20の構成例を示すブロック図である。
図62を参照すると、コアネットワーク装置20は、ネットワークインターフェース1201、プロセッサ1202、及びメモリ1203を含む。ネットワークインターフェース1201は、ネットワークノード(e.g., AN50、SMF30等)と通信するために使用される。ネットワークインターフェース1201は、例えば、IEEE(Insititute of Electrical and Electronics Engineers) 802.3 seriesに準拠したネットワークインタフェースカード(NIC)を含んでもよい。
【0198】
プロセッサ1202は、メモリ1203からソフトウェア(コンピュータプログラム)を読み出して実行することで、上述の実施形態においてシーケンス図及びフローチャートを用いて説明されたAMF20の処理を行う。プロセッサ1202は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ1202は、複数のプロセッサを含んでもよい。
【0199】
メモリ1203は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ1203は、プロセッサ1202から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1202は、図示されていないI/Oインタフェースを介してメモリ1203にアクセスしてもよい。
【0200】
図62の例では、メモリ1203は、ソフトウェアモジュール群を格納するために使用される。プロセッサ1202は、これらのソフトウェアモジュール群をメモリ1203から読み出して実行することで、上述の実施形態において説明されたAMF20の処理を行うことができる。
【0201】
図61及び
図62を用いて説明したように、上述の実施形態に通信端末10及びコアネットワーク装置20が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む1又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体(Non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体、光磁気記録媒体(例えば光磁気ディスク)、Compact Disc Read Only Memory(CD-ROM)、CD-R、CD-R/W、半導体メモリを含む。磁気記録媒体は、フレキシブルディスク、磁気テープ、ハードディスクドライブであってもよい。半導体メモリは、例えば、マスクROM、Programmable ROM(PROM)、Erasable PROM(EPROM)、フラッシュROM、Random Access Memory(RAM)であってもよい。例えば、また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【0202】
なお、本開示は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本開示は、それぞれの実施の形態を適宜組み合わせて実施されてもよい。
【0203】
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【0204】
この出願は、2017年9月27日に出願されたインド出願201711034337を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【0205】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
(付記1)
Untrusted Non-3GPP Accessを介してコアネットワーク装置の前段に配置されているゲートウェイ装置と通信する通信部と、
前記コアネットワーク装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第1のセキュリティ鍵から、前記ゲートウェイ装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第2のセキュリティ鍵を導出する鍵導出部と、を備える通信端末。
(付記2)
前記通信部は、
前記Untrusted Non-3GPP Accessを介して前記コアネットワーク装置の前段に配置されている第1のゲートウェイ装置と通信し、前記Untrusted Non-3GPP Accessもしくは前記Untrusted Non-3GPP Accessとは異なるUntrusted Non-3GPP Accessを介して前記コアネットワーク装置の前段に配置されている第2のゲートウェイ装置と通信し、
前記鍵導出部は、
ゲートウェイ装置毎に異なる前記第2のセキュリティ鍵を導出する、付記1に記載の通信端末。
(付記3)
前記鍵導出部は、
アクセスネットワークの識別情報を用いて前記第2のセキュリティ鍵を導出する、付記1又は2に記載の通信端末。
(付記4)
前記鍵導出部は、
前記Untrusted Non-3GPP Access及び前記ゲートウェイ装置を介して前記コアネットワーク装置との間において伝送されるNASメッセージのセキュリティ処理に用いられる第3のセキュリティ鍵を、前記第1のセキュリティ鍵から導出する、付記1乃至3のいずれか1項に記載の通信端末。
(付記5)
前記通信部は、
前記Untrusted Non-3GPP Accessを介して前記コアネットワーク装置の前段に配置されている第1のゲートウェイ装置と通信し、前記Untrusted Non-3GPP Accessもしくは前記Untrusted Non-3GPP Accessとは異なるUntrusted Non-3GPP Accessを介して前記コアネットワーク装置の前段に配置されている第2のゲートウェイ装置と通信し、
前記鍵導出部は、
前記ゲートウェイ装置毎に異なる前記第3のセキュリティ鍵を導出する、付記4に記載の通信端末。
(付記6)
前記鍵導出部は、
アクセスネットワークの識別情報を用いて前記第3のセキュリティ鍵を導出する、付記4又は5に記載の通信端末。
(付記7)
コアネットワーク装置の前段に配置されているゲートウェイ装置及びUntrusted Non-3GPP Accessを介して通信端末と通信する通信部と、
前記通信端末との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第1のセキュリティ鍵から、前記通信端末と前記ゲートウェイ装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第2のセキュリティ鍵を導出する鍵導出部と、を備えるコアネットワーク装置。
(付記8)
前記通信部は、
第1のゲートウェイ装置及び前記Untrusted Non-3GPP Accessを介して前記通信端末と通信し、さらに、第2のゲートウェイ装置及び前記Untrusted Non-3GPP Accessもしくは前記Untrusted Non-3GPP Accessとは異なるUntrusted Non-3GPP Accessを介して前記通信端末と通信し、
前記鍵導出部は、
ゲートウェイ装置毎に異なる前記第2のセキュリティ鍵を導出する、付記7に記載のコアネットワーク装置。
(付記9)
前記鍵導出部は、
アクセスネットワークの識別情報を用いて前記第2のセキュリティ鍵を導出する、付記7又は8に記載のコアネットワーク装置。
(付記10)
前記鍵導出部は、
前記ゲートウェイ装置及び前記Untrusted Non-3GPP Accessを介して前記通信端末との間において伝送されるNASメッセージのセキュリティ処理に用いられる第3のセキュリティ鍵を、前記第1のセキュリティ鍵から導出する、付記7乃至9のいずれか1項に記載のコアネットワーク装置。
(付記11)
前記通信部は、
第1のゲートウェイ装置及び前記Untrusted Non-3GPP Accessを介して前記通信端末と通信し、さらに、第2のゲートウェイ装置及び前記Untrusted Non-3GPP Accessもしくは前記Untrusted Non-3GPP Accessとは異なるUntrusted Non-3GPP Accessを介して前記通信端末と通信し、
前記鍵導出部は、
前記ゲートウェイ装置毎に異なる前記第3のセキュリティ鍵を導出する、付記10に記載のコアネットワーク装置。
(付記12)
前記鍵導出部は、
アクセスネットワークの識別情報を用いて前記第3のセキュリティ鍵を導出する、付記10又は11に記載のコアネットワーク装置。
(付記13)
Untrusted Non-3GPP Accessを介してコアネットワーク装置の前段に配置されているゲートウェイ装置と通信し、
前記コアネットワーク装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第1のセキュリティ鍵から、前記ゲートウェイ装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第2のセキュリティ鍵を導出する、鍵導出方法。
(付記14)
コアネットワーク装置の前段に配置されているゲートウェイ装置及びUntrusted Non-3GPP Accessを介して通信端末と通信し、
前記通信端末との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第1のセキュリティ鍵から、前記通信端末と前記ゲートウェイ装置との間において定められたプロトコルを用いて伝送されるメッセージのセキュリティ処理に用いられる第2のセキュリティ鍵を導出する、鍵導出方法。
(付記15)
第1タイプのアクセス及び第2タイプのアクセスを介してネットワークノードにアクセスする通信部と、
前記第1タイプのアクセスのための第1NAS connection及び前記第2タイプのアクセスのための第2NAS connectionを、ネットワーク内の前記ネットワークノードと確立する制御部と、を備え、
独立したNASセキュリティを実現するために各々のNAS connectionに特有のパラメータが使用され、
前記パラメータは、前記第1タイプのアクセス及び前記第2タイプのアクセスのための固有のNAS connection識別子に関連する値を含んでいる、通信端末。
(付記16)
第1タイプのアクセス及び第2タイプのアクセスを介して通信端末を登録する登録部と、
前記第1タイプのアクセスのための第1NAS connection及び前記第2タイプのアクセスのための第2NAS connectionを有する通信部と、
前記第2タイプのアクセスを介してNAS SMC(Security Mode Command)処理を発動させる制御部と、
前記NAS SMC処理の間にインジケータを含むメッセージを前記通信端末に送信する送信部と、を備える、コアネットワークノード。
(付記17)
EAP-TLS(Extended Master Session Key)認証処理の間にEMSK(Extended Master Session Key)を導出する鍵導出部と、
セキュリティ鍵の導出のために前記EMSKを使用する制御部と、を備える、通信端末。
(付記18)
EAP-TLS(Extended Master Session Key)認証処理の間にEMSK(Extended Master Session Key)を取得する取得部と、
セキュリティ鍵の導出のために前記EMSKを使用する制御部と、を備える、コアネットワークノード。
(付記19)
第1タイプのアクセスを介して第1ネットワークノードにアクセスし、第2タイプのアクセスを介して第2ネットワークノードにアクセスする通信部と、
前記第1タイプのアクセスのための第1NAS connection及び前記第2タイプのアクセスのための第2NAS connectionを、前記第1及び前記第2ネットワークノードと確立する接続確立部と、
ネットワークノード毎に異なるsecurity contextを使用し、各々のsecurity contextは別々に確立される制御部と、を備える、通信端末。
(付記20)
前記第1及び前記第2ネットワークノードは、異なるネットワークに属している、付記19に記載の通信端末。
(付記21)
前記第1タイプのアクセスは、3GPP accessであり、
前記第2タイプのアクセスは、non-3GPP accessである、付記15または19に記載の通信端末。
(付記22)
登録要求メッセージをネットワークノードに送信する通信部と、
前記登録要求メッセージの送信後に、アクセスタイプに関するパラメータを使ってセキュリティ鍵を導出する鍵導出部と、を備える、通信端末。
(付記23)
前記セキュリティ鍵は、前記アクセスタイプに関するパラメータが入力されるKDF(Key Derivation Function)を使って導出される、付記22に記載の通信端末。
(付記24)
登録要求メッセージを通信端末から受信する通信部と、
前記登録要求メッセージの受信後に、アクセスタイプに関するパラメータを使ってセキュリティ鍵を導出する鍵導出部と、を備える、ネットワークノード。
(付記25)
前記セキュリティ鍵は、前記アクセスタイプに関するパラメータが入力されるKDF(Key Derivation Function)を使って導出される、付記24に記載のネットワークノード。
【0206】
10 通信端末
11 通信部
12 鍵導出部
20 コアネットワーク装置
21 通信部
22 鍵導出部
30 UE
31 gNB
31_1 gNB
31_2 gNB
32 3GPP Access
33 AMF
33_1 Source AMF
33_2 Target AMF
34 SMF
34_1 Source SMF
34_2 Target SMF
35 UPF
36 AUSF
37 UDM
38 N3IWF
39 Data Network
40 Untrusted Non-3GPP Access
51 AMF
52 SMF
53 UPF
54 N3IWF
55 Data Network
61 gNB
62 3GPP Access
63 AMF
64 N3IWF
65 Non-3GPP Access
71 N3IWF
72 Non-3GPP Access
73 AMF