知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-12-23
(45)【発行日】2025-01-07
(54)【発明の名称】通信装置及び通信装置の方法
(51)【国際特許分類】
H04W 12/06 20210101AFI20241224BHJP
H04W 36/14 20090101ALI20241224BHJP
H04W 12/69 20210101ALI20241224BHJP
【ＦＩ】
H04W12/06
H04W36/14
H04W12/69
【請求項の数】
4
(21)【出願番号】P 2023524394
(86)(22)【出願日】2021-10-28
(65)【公表番号】
(43)【公表日】2023-11-09
(86)【国際出願番号】 JP2021039913
(87)【国際公開番号】W WO2022092238
(87)【国際公開日】2022-05-05
【審査請求日】2023-04-20
(31)【優先権主張番号】202011047284
(32)【優先日】2020-10-29
(33)【優先権主張国・地域又は機関】IN
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100103894
【弁理士】
【氏名又は名称】家入 健
(72)【発明者】
【氏名】ティワリ クンダン
(72)【発明者】
【氏名】田村 利之
【審査官】小林 正明
(56)【参考文献】
【文献】特表２０２１－５２０６６０（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１９／０００７５００（ＵＳ，Ａ１）
【文献】NEC，DISC Authentication procedure during Xn handover procedure[online]，3GPP TSG SA WG3 #101e S3-203005，Internet:<URL:https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_101e/Docs/S3-203005.zip>，2020年10月30日，［検索日 2024.05.31］
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４－７／２６
Ｈ０４Ｗ ４／００－９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１，４
(57)【特許請求の範囲】
【請求項1】
第１のPublic Land Mobile Network (PLMN)に対する、ユーザ装置のための登録手順を実行する手段と、前記第１のPLMNの識別子を含む、前記ユーザ装置の認証を実行するための第１のメッセージをAUSF (Authentication Server Function)へ送信する手段と、
前記第１のPLMNから第２のPLMNへの変更を伴う前記ユーザ装置のハンドオーバー手順を実行する手段と、
前記第１のPLMNの識別子を含む第２のメッセージを受信する手段と、
前記ユーザ装置に、前記第１のPLMNの識別子を含む認証要求メッセージを送信する手段と
を備える通信装置。
【請求項2】
前記認証が完了したことを示す第３のメッセージを受信する手段と、前記第１のPLMNの識別子を更新するために、Unified Data Management (UDM)に、前記第２のPLMNの識別子を送信する手段と
を備える請求項１に記載の通信装置。
【請求項3】
前記第２のPLMNの識別子を含む第３のメッセージを受信する手段と、前記通信装置が5G Globally Unique Temporary Identifier (5G-GUTI)を保持している場合に、前記第２のPLMNの識別子に含まれるMobile Country Code (MCC)およびMobile Network Code (MNC)が前記5G-GUTIに含まれるMCCおよびMNCと同じか否かを確認する手段と、
前記第２のPLMNの識別子に含まれるMCCおよびMNCが前記5G-GUTIに含まれるMCCおよびMNCと同じでない場合に、前記第２のPLMNの識別子を含む、前記ユーザ装置を認証するための第４のメッセージを前記AUSFへ送信する手段と
を備える請求項１に記載の通信装置。
【請求項4】
第１のPublic Land Mobile Network (PLMN)に対する、ユーザ装置のための登録手順を実行し、前記第１のPLMNの識別子を含む、前記ユーザ装置の認証を実行するための第１のメッセージをAUSF (Authentication Server Function)へ送信し、
前記第１のPLMNから第２のPLMNへの変更を伴う前記ユーザ装置のハンドオーバー手順を実行し、
前記第１のPLMNの識別子を含む第２のメッセージを受信し、
前記ユーザ装置に、前記第１のPLMNの識別子を含む認証要求メッセージを送信する
通信装置の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、一般的に、無線通信に関するものであり、特に、実施の形態では、認証手順中にサービングPLMNから他のサービングPLMNへXnハンドオーバーが行われるときの認証手順（authentication procedure）の処理に関する。
【背景技術】
【0002】
primary authentication and key agreement手順の目的は、3GPP TS 33.501 [5] で規定されているように、UEとネットワークとの間の相互認証を可能にし、その後のセキュリティ手順でUEとネットワークとの間で使用できる鍵材料（keying material）を提供することである。鍵KAUSF、KSEAF、およびKAMFは、認証手順の成功後に生成される。
【0003】
2つのメソッドが定義されている。
a)EAP based primary authentication and key agreement手順 (procedure)。
b)5G AKA based primary authentication and key agreement手順 (procedure)。
a)EAP based primary authentication and key agreement手順 (procedure)。
b)5G AKA based primary authentication and key agreement手順 (procedure)。
【0004】
UEとAMFは、EAP based primary authentication and key agreement手順と5G AKA based primary authentication and key agreement手順をサポートする必要がある。認証手順がネットワークで失敗した場合、AMFはAuthentication RejectメッセージをUEに返す。サービングネットワーク名は、UEとUDMのそれぞれにおいてRES*とXRES*を計算するために使用される。AUSFでRES*とHRES*の検証（verification）が成功した場合、AUSFは認証手順を成功と見なす。サービングネットワーク名は、アンカーキー (KAUSF) の導出で使用される。これは、serving network identifier (SN Id) を含めることによって、アンカーキーをサービングネットワークに結び付ける（bind）。これは、「5G」に設定されたサービスコードを含めることによって、アンカーキーが5GコアネットワークとUEとの間の認証に固有であることを確実にする。5G AKAでは、サービングネットワーク名には、RES*とXRES*をサービングネットワークに結び付けるという同様の目的がある。SN Idは、サービングPLMNを識別する。UEの観点からは、ネットワークが認証しているサービングネットワークである。UDMの場合は、AUSFによって送信されるサービングネットワークである。
【0005】
図1に、認証手順の開始と認証方法の選択を示す。SEAFは、SEAFのポリシーに従って、UEとのシグナリング接続を確立する手順の間に、UEとの認証を開始してもよい。SUPIに基づいて、UDM/ARPFは、認証方法を選択する必要がある。
【0006】
図2に5G AKAの認証手順を示す。
【0007】
一方、図3にXnハンドオーバー手順を示す。ネットワーク展開シナリオでは、Registration Area (RA) は、PLMN ID=Aによってサービスされる1つまたは複数の第１のTracking Area (TA) と、PLMN ID=Bによってサービスされる1つまたは複数の第２のTracking Area (TA) で構成できる。コネクテッドモード（connected mode）のUEが、第１のTAに属するRANから第２のTAに属するRANに移動した場合、Xnハンドオーバー手順が行われる。Xnハンドオーバー手順後、UEとネットワークとでは、サービングネットワークがPLMN ID=AからPLMN ID=Bに変更されるが、AMFはXnハンドオーバー手順後も同じままである。
【先行技術文献】
【非特許文献】
【0008】
【文献】3GPP TR 21.905: "Vocabulary for 3GPP Specifications". V16.0.0 (2019-06)
【文献】3GPP TS 23.501: "System architecture for the 5G System (5GS)". V16.6.0 (2020-09)
【文献】3GPP TS 23.502: "Procedures for the 5G System (5G”S)" V16.6.0 (2020-09)
【文献】GPP TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3" V16.6.0 (2020-09)
【文献】3GPP TS 33.501: "Security architecture and procedures for 5G system" V16.4.0 (2020-09)
【文献】3GPP TS 33.102: "3G Security; Security architecture" V16.0.0 (2020-07)
【文献】3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)" V16.6.0 (2020-09)
【文献】3GPP TS 29.272: "Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol" V16.4.0 (2020-09)
【発明の概要】
【発明が解決しようとする課題】
【0009】
AMFは、ローカルポリシーに基づいていつでも認証手順を開始できる。進行中の認証手順中に、あるサービングPLMNから他のサービングPLMNにXnハンドオーバーが行われるというシナリオが考えられる。このシナリオでは、UEと5Gコアネットワーク(例:AUSF、UDM)は、現在のサービングPLMNに関して同期していない。すなわち、UEはXnハンドオーバー手順が行われた後のPLMNを維持する一方、5GコアネットワークはXnハンドオーバー手順が行われる前のPLMNを維持してもよい。このUEと5G コアネットワークの不一致は、認証手順の失敗につながる可能性があるため、ユーザはサービスにアクセスできなくなる。
【課題を解決するための手段】
【0010】
本開示の第１の側面では、通信装置の方法が提供され、その方法は、第１のPublic Land Mobile Network (PLMN)に対する、ユーザ装置（UE）のための登録手順を実行し、前記UEの認証を実行するための第１のメッセージを送信し、前記第１のメッセージは、前記第１のPLMNの識別子を含み、前記第１のPLMNから第２のPLMNへの変更を伴う前記UEのハンドオーバー手順を実行し、第２のメッセージを受信し、前記第２のメッセージは、前記第１のPLMNの識別子を含み、前記ユーザ装置に、認証要求メッセージを送信し、前記認証要求メッセージは、前記第１のPLMNの識別子を含む。
【0011】
本開示の第２の側面では、ユーザ装置 (UE) の方法が提供され、その方法は、第１のPublic Land Mobile Network (PLMN)に対する、登録手順を実行し、前記第１のPLMNから第２のPLMNへの変更を伴うハンドオーバー手順を実行し、認証要求メッセージを受信し、前記認証要求メッセージは、前記第１のPLMNの識別子を含み、前記第１のPLMNの識別子に基づいて認証手順を実行する。
【0012】
本開示の第３の側面では、通信装置は、第１のPublic Land Mobile Network (PLMN)に対する、ユーザ装置（UE）のための登録手順を実行する手段と、前記UEの認証を実行するための第１のメッセージを送信する手段と、前記第１のメッセージは、前記第１のPLMNの識別子を含み、前記第１のPLMNから第２のPLMNへの変更を伴う前記UEのハンドオーバー手順を実行する手段と、第２のメッセージを受信する手段と、前記第２のメッセージは、前記第１のPLMNの識別子を含み、前記ユーザ装置に、認証要求メッセージを送信する手段と、を備え、前記認証要求メッセージは、前記第１のPLMNの識別子を含む。
【0013】
本開示の第４の側面において、ユーザ装置 (UE) は、第１のPublic Land Mobile Network (PLMN)に対する、登録手順を実行する手段と、前記第１のPLMNから第２のPLMNへの変更を伴うハンドオーバー手順を実行する手段と、認証要求メッセージを受信する手段と、前記認証要求メッセージは、前記第１のPLMNの識別子を含み、前記第１のPLMNの識別子に基づいて認証手順を実行する手段と、を備える。
【0014】
本開示の第５の側面では、通信装置の方法が提供され、その方法は、第１のPublic Land Mobile Network (PLMN)に対する、ユーザ装置（UE）のための登録手順を実行し、前記UEの認証を実行するための第１のメッセージを送信し、前記第１のメッセージは、前記第１のPLMNの識別子を含み、前記第１のPLMNから第２のPLMNへの変更を伴う前記UEのハンドオーバー手順を実行し、第２のメッセージを受信し、前記第２のメッセージは、第２のPLMNの識別子を含み、前記第１のPLMNの識別子を用いた認証が進行中に前記ハンドオーバー手順が発生したかどうかを判定し、前記第１のPLMNの識別子を用いた認証が進行中に前記ハンドオーバー手順が発生した場合、前記UEへ認証要求メッセージを送信し、前記認証要求メッセージは、前記第１のPLMNの識別子を含む。
【0015】
本開示の第６の側面において、通信装置は、第１のPublic Land Mobile Network (PLMN)に対する、ユーザ装置（UE）のための登録手順を実行する手段と、前記UEの認証を実行するための第１のメッセージを送信する手段と、前記第１のメッセージは、前記第１のPLMNの識別子を含み、前記第１のPLMNから第２のPLMNへの変更を伴う前記UEのハンドオーバー手順を実行する手段と、第２のメッセージを受信する手段と、前記第２のメッセージは、第２のPLMNの識別子を含み、前記第１のPLMNの識別子を用いた認証が進行中に前記ハンドオーバー手順が発生したかどうかを判定する手段と、前記第１のPLMNの識別子を用いた認証が進行中に前記ハンドオーバー手順が発生した場合、前記UEへ認証要求メッセージを送信する手段と、を備え、前記認証要求メッセージは、前記第１のPLMNの識別子を含む。
【0016】
本開示の第７の側面では、通信装置の方法が提供され、その方法は、Public Land Mobile Network (PLMN)に対する、ユーザ装置（UE）のための登録手順を実行し、前記PLMNの識別子を保存し、前記UEの認証手順のために前記識別子を用いる。
【0017】
本開示の第８の側面では、ユーザ装置 (UE) の方法が提供され、その方法は、Public Land Mobile Network (PLMN)に対する登録手順を実行し、前記PLMNの識別子を保存し、UEの認証手順のために前記識別子を用いる。
【0018】
本開示の第９の側面において、通信装置は、Public Land Mobile Network (PLMN)に対する、ユーザ装置（UE）のための登録手順を実行する手段と、前記PLMNの識別子を保存する手段と、前記UEの認証手順のために前記識別子を用いる手段と、を備える。
【0019】
本開示の第１０の側面において、ユーザ装置 (UE) は、Public Land Mobile Network (PLMN)に対する登録手順を実行する手段と、前記PLMNの識別子を保存する手段と、UEの認証手順のために前記識別子を用いる手段と、を備える。
【0020】
本開示の第１１の側面では、通信装置の方法が提供され、その方法は、第１のPublic Land Mobile Network (PLMN)に対する、ユーザ装置（UE）のための登録手順を実行し、第１のPLMNから第２のPLMNへの変更を伴うハンドオーバー手順の間に第１のメッセージを受信し、前記第１のメッセージは、前記第２のPLMNの識別子を含み、Unified Data Management （UDM）へ第２のメッセージを送信し、前記第２のメッセージは、前記第２のPLMNの識別子を含む。
【0021】
本開示の第１２の側面において、通信装置は、第１のPublic Land Mobile Network (PLMN)に対する、ユーザ装置（UE）のための登録手順を実行する手段と、第１のPLMNから第２のPLMNへの変更を伴うハンドオーバー手順の間に第１のメッセージを受信する手段と、前記第１のメッセージは、前記第２のPLMNの識別子を含み、Unified Data Management （UDM）へ第２のメッセージを送信する手段と、を備え、前記第２のメッセージは、前記第２のPLMNの識別子を含む。
【0022】
本開示の第１３の側面では、通信装置の方法が提供され、その方法は、第１のPublic Land Mobile Network (PLMN)に対する、ユーザ装置（UE）のための登録手順を実行し、前記UEを認証するための第１のメッセージを送信し、前記第１のメッセージは、前記第１のPLMNの識別子を含み、前記第１のPLMNから第２のPLMNへの変更を伴うハンドオーバー手順を実行し、認証が進行中に前記ハンドオーバーが実行されたかどうかを判定し、前記UEを認証するために第２のメッセージを送信し、前記第２のメッセージは、前記第２のPLMNの識別子を含む。
【0023】
本開示の第１４の側面において、通信装置は、第１のPublic Land Mobile Network (PLMN)に対する、ユーザ装置（UE）のための登録手順を実行する手段と、前記UEを認証するための第１のメッセージを送信する手段と、前記第１のメッセージは、前記第１のPLMNの識別子を含み、前記第１のPLMNから第２のPLMNへの変更を伴うハンドオーバー手順を実行する手段と、認証が進行中に前記ハンドオーバーが実行されたかどうかを判定する手段と、前記UEを認証するために第２のメッセージを送信する手段と、を備え、前記第２のメッセージは、前記第２のPLMNの識別子を含む。
【0024】
本開示の第１５の側面では、通信装置の方法が提供され、その方法は、Public Land Mobile Network (PLMN)に対する、ユーザ装置（UE）のための登録手順を実行し、第１のPLMNから第２のPLMNへの変更を伴うハンドオーバー手順の間に第１のメッセージを受信し、前記第１のメッセージは前記第２のPLMNの識別子を含み、前記第１のメッセージが受信された場合に前記第２のPLMNの識別子に基づいて5G Globally Unique Temporary Identifier (5G-GUTI)を割り当て、前記UEへ前記5G-GUTIを送信する。
【0025】
本開示の第１６の側面において、通信装置は、Public Land Mobile Network (PLMN)に対する、ユーザ装置（UE）のための登録手順を実行する手段と、第１のPLMNから第２のPLMNへの変更を伴うハンドオーバー手順の間に第１のメッセージを受信する手段と、前記第１のメッセージは前記第２のPLMNの識別子を含み、前記第１のメッセージが受信された場合に前記第２のPLMNの識別子に基づいて5G Globally Unique Temporary Identifier (5G-GUTI)を割り当てる手段と、前記UEへ前記5G-GUTIを送信する手段と、を備える。
【図面の簡単な説明】
【0026】
【発明を実施するための形態】
【0027】
本開示は、Xnハンドオーバー中に認証手順を処理する手順を提供する。より具体的には、認証手順中にあるサービングPLMNから他のサービングPLMNへXnハンドオーバーが行われるときの認証手順の処理を定義する。
【0028】
本開示の利点と特徴をさらに明確にするために、添付の図に示されているその具体的な実施の形態を参照して、本開示のより具体的な説明を行う。これらの図は、本開示の典型的な実施の形態のみを示しており、したがって、範囲を限定するものとは考えられないことを理解されたい。
【0029】
本開示は、添付の図を用いて、更なる具体化と詳細について説明される。
【0030】
さらに、当業者は、図の要素が単純に図示されており、必ずしも縮尺どおりに描かれていない可能性があることを理解するであろう。さらに、装置の構成に関しては、装置の1つ以上の構成要素が一般的な記号によって図に表されていてもよく、図は、本開示の実施の形態を理解するのに適切な特定の詳細のみを示すことができるため、ここでの説明の利点を有する当業者には容易に明らかになる詳細を伴う図を不明瞭にすることはない。
【0031】
本開示の原則の理解を促進する目的で、ここで図に示された実施の形態を参照し、それらを記述するために特定の言語を使用する。それにもかかわらず、開示の範囲の制限はそれによって意図されていないことが理解される。例示されたシステムにおけるそのような変更及び更なる変更、並びに当業者に通常発生する開示の原則の更なる適用は、本開示の範囲内であると解釈されるべきである。
【0032】
概要
ここでは、サービスネットワークについて説明する。
ここでは、サービスネットワークについて説明する。
【0033】
サービングネットワーク名
サービングネットワーク名は、アンカーキーの導出に使用される。これは、一般的に、次の2つの目的を果たす。
-serving network identifier (SN Id) を含めることによって、アンカーキーをサービングネットワークに結び付ける。
-「5G」に設定されたサービスコードを含めることによって、アンカーキーが5GコアネットワークとUEとの間の認証に固有であることを明確にする。
サービングネットワーク名は、アンカーキーの導出に使用される。これは、一般的に、次の2つの目的を果たす。
-serving network identifier (SN Id) を含めることによって、アンカーキーをサービングネットワークに結び付ける。
-「5G」に設定されたサービスコードを含めることによって、アンカーキーが5GコアネットワークとUEとの間の認証に固有であることを明確にする。
【0034】
5G AKA based primary authentication and key agreement手順では、サービングネットワーク名は、RES*とXRES*とをサービングネットワークに結び付けるという同様の目的を持っている。サービングネットワーク名は、サービスコードとSN Idとを区切り文字「:」で連結したもので、サービスコードがSN Idの前に付くようにする。
【0035】
NOTE:「アクセスネットワークタイプ」のようなパラメータは、アクセスネットワークに依存しない5Gコア手順に関連するため、サービングネットワーク名には使用されない。SN Idは、サービングPLMNを識別し、スタンドアロン非パブリックネットワークを除き、3GPP TS 24.501 [4] でSNN-network-identifierとして定義されている。
【0036】
UEによるサービングネットワーク名（Serving network name）の構築
UEは、以下のようにサービングネットワーク名を構築する。
-サービスコードを「5G」とする。
-ネットワーク識別子を認証しているネットワークのSN Idとする。
-サービスコードとSN Idとを区切り文字「:」で連結する。
UEは、以下のようにサービングネットワーク名を構築する。
-サービスコードを「5G」とする。
-ネットワーク識別子を認証しているネットワークのSN Idとする。
-サービスコードとSN Idとを区切り文字「:」で連結する。
【0037】
SEAFによるサービングネットワーク名の構築
SEAFは、以下のようにサービングネットワーク名を構築する。
-サービスコードを「5G」とする。
-ネットワーク識別子をAUSFが認証データを送信するサービングネットワークのSN Idとする。
-サービスコードとSN Idとを区切り文字「:」で連結する。
SEAFは、以下のようにサービングネットワーク名を構築する。
-サービスコードを「5G」とする。
-ネットワーク識別子をAUSFが認証データを送信するサービングネットワークのSN Idとする。
-サービスコードとSN Idとを区切り文字「:」で連結する。
【0038】
なお、AUSFはSEAFからサービングネットワーク名を取得する。サービングネットワーク名を使用する前に、AUSFはSEAFがサービングネットワーク名の使用を許可されていることを確認する。
【0039】
すべての実施の形態は、EAP based primary authentication and agreement手順にも適用できる。
【0040】
本開示では、特に断りのない限り、primary "authentication and key agreement procedure"は、"EAP based primary authentication and agreement手順"または"5G AKA based primary authentication and key agreement手順"のいずれかを意味する。
【0041】
本開示における「認証手順」という用語は、特に明記されていない限り、"EAP based primary authentication and agreement手順"または"5G AKA based primary authentication and key agreement手順"のいずれかを意味する。
【0042】
本開示におけるAMFという用語は、SEAFと解釈することができる。KAUSFという用語は、KausfまたはKAUSFと解釈することができる。KSEAFという用語は、KSEAFと解釈することができる。KAMFという用語は、KAMFと解釈することができる。以下の実施例は5GSに限定されず、EPS AKAなど5GS以外の通信システムにも適用できる。
【0043】
以下の実施の形態がEPSに適用される場合、以下の置き換えが必要である。
【0044】
手順の置き換え
-"5G AKA based primary authentication and key agreement手順"を"EPS AKA手順"に置き換える。
-「Xnハンドオーバー手順」を「X2ベースのハンドオーバー（X2-based handover）手順」に置き換える。
-"5G AKA based primary authentication and key agreement手順"を"EPS AKA手順"に置き換える。
-「Xnハンドオーバー手順」を「X2ベースのハンドオーバー（X2-based handover）手順」に置き換える。
【0045】
ノード名の置き換え
-AMFとSEAFをMMEに置き換える。
-UDMとARPFをHSSに置き換える。
-AUSFをHSSに置き換える。
-AMFとSEAFをMMEに置き換える。
-UDMとARPFをHSSに置き換える。
-AUSFをHSSに置き換える。
【0046】
メッセージの置き換え
-Registration Requestメッセージを、Attach RequestメッセージまたはTracking Area Updateメッセージのいずれかに置き換える。
-N2 Path Switch RequestをPath Switch Requestメッセージに置き換える。
-Nausf_UEAuthentication_Authenticate Requestメッセージを、3GPP TS 29.272 [8] で定義されているAuthentication Information Requestメッセージに置き換える。
-Nudm_UEAuthentication_Get Requestメッセージを、3GPP TS 29.272 [8] で定義されているAuthentication Information Requestメッセージに置き換える。
-Nausf_UEAuthentication_Authenticate RequestメッセージとNudm_UEAuthentication_Get Requestメッセージの組み合わせを3GPP TS 29.272 [8] で定義されているAuthentication Information Requestメッセージに置き換える。
-Nudm_Authentication_Get Responseメッセージを、3GPP TS 29.272 [8] で定義されているAuthentication Information Answerメッセージに置き換える。
-Nausf_UEAuthentication_Authenticate Responseを、3GPP TS 29.272 [8] で定義されているAuthentication Information Answerメッセージに置き換える。
-Nudm_Authentication_Get ResponseメッセージとNausf_UEAuthentication_Authenticate Responseの組み合わせを、3GPP TS 29.272 [8] で定義されているAuthentication Information Answerメッセージに置き換える。
-Registration Requestメッセージを、Attach RequestメッセージまたはTracking Area Updateメッセージのいずれかに置き換える。
-N2 Path Switch RequestをPath Switch Requestメッセージに置き換える。
-Nausf_UEAuthentication_Authenticate Requestメッセージを、3GPP TS 29.272 [8] で定義されているAuthentication Information Requestメッセージに置き換える。
-Nudm_UEAuthentication_Get Requestメッセージを、3GPP TS 29.272 [8] で定義されているAuthentication Information Requestメッセージに置き換える。
-Nausf_UEAuthentication_Authenticate RequestメッセージとNudm_UEAuthentication_Get Requestメッセージの組み合わせを3GPP TS 29.272 [8] で定義されているAuthentication Information Requestメッセージに置き換える。
-Nudm_Authentication_Get Responseメッセージを、3GPP TS 29.272 [8] で定義されているAuthentication Information Answerメッセージに置き換える。
-Nausf_UEAuthentication_Authenticate Responseを、3GPP TS 29.272 [8] で定義されているAuthentication Information Answerメッセージに置き換える。
-Nudm_Authentication_Get ResponseメッセージとNausf_UEAuthentication_Authenticate Responseの組み合わせを、3GPP TS 29.272 [8] で定義されているAuthentication Information Answerメッセージに置き換える。
【0047】
パラメータの置き換え
-SUCIとSUPIをIMSIに置き換える。
-5G-GUTIをGUTIまたは4G-GUTIに置き換える。
-ngKSIをKSIに置き換える。
-Serving Network Nameを図４に示されているServing Network Identityに置き換える。Serving Network identity(SN-Id)は、UEおよびMMEにおいてKASMEを導出するために使用される。MCCおよびMNCの数字のコーディングは、3GPP TS 24.301 [7] で定義されている。
-SUCIとSUPIをIMSIに置き換える。
-5G-GUTIをGUTIまたは4G-GUTIに置き換える。
-ngKSIをKSIに置き換える。
-Serving Network Nameを図４に示されているServing Network Identityに置き換える。Serving Network identity(SN-Id)は、UEおよびMMEにおいてKASMEを導出するために使用される。MCCおよびMNCの数字のコーディングは、3GPP TS 24.301 [7] で定義されている。
【0048】
なお、上記の例以外では、5GSの手順、ノード名、メッセージ、およびパラメータも、EPSにおいてそれぞれ対応する手順、対応するノード名、対応するメッセージ、および対応するパラメータに置き換えることができる。
【0049】
以下の実施の形態では、UEは、PLMN ID=Aに基づく第１のKAUSFとPLMN ID=Bに基づく第２のKAUSFの2つのKAUSFを計算する。UEはセキュリティ手順で第１のKAUSFを使用し、第１のKAUSFを使用したセキュリティ手順が失敗した場合は、UEはセキュリティ手順で第２のKAUSFを使用し、第１のKAUSFを削除し、それ以外の場合は、UEは第２のKAUSFを削除する。EPSの場合も同じ方法を適用して、KASMEを計算して使用する。
【0050】
特に定義されていない限り、ここで使用されるすべての技術的および科学的用語は、本開示が属する技術分野の当業者が一般的に理解しているのと同じ意味を持つ。ここで提供されるシステム、方法、および例は例示のみであり、限定することを意図していない。
【0051】
"comprises"、"comprising"という用語、またはその他のバリエーションは、非排他的包含をカバーすることを目的としており、ステップのリストを構成するプロセスまたは方法は、それらのステップのみを含まず、そのようなプロセスまたは方法に明示的にリストされていない他のステップを含んでもよい。同様に、"comprises～a"に続く1つ以上のデバイスまたはエンティティまたはサブシステムまたはエレメントまたは構造またはコンポーネントは、より多くの制約がない限り、他のデバイス、サブシステム、エレメント、構造、コンポーネント、追加のデバイス、追加のサブシステム、追加のエレメント、追加の構造または追加のコンポーネントの存在を妨げるものではない。この明細書全体を通してのフレーズ「実施の形態」、「他の実施の形態」および類似の用語の出現は、必ずしもそうではないが、すべて同じ実施の形態を指す場合がある。
【0052】
以下の明細書およびクレームでは、多数の用語を参照し、それらは以下の意味を持つように定義されるものとする。単数形の「a」、「an」および「the」は、文脈が明確にそうでないと指示しない限り、複数の参照を含む。
【0053】
ここで使用されるように、データは意味のある情報であり、パラメータに起因する値を表すため、情報はデータおよび知識（knowledge）と関連付けられる。さらに、知識は、抽象的または具体的な概念の理解を意味する。この例示システムは、開示された主題の説明を容易にするために簡素化されており、この開示の範囲を制限することを意図していないことに注意されたい。他の装置、システム、および構成は、システムに加えて、またはシステムの代わりに、ここに開示された実施の形態を実装するために使用されてもよく、すべてのそのような実施の形態は、本開示の範囲内として企図される。
【0054】
実施の形態１（解決策１）
【0055】
ネットワークは、サービングネットワーク名をAuthentication Request（認証要求）メッセージでUEに送信し、サービングネットワーク名を使用してセキュリティパラメータ(例:RES*やAnchor Key (例:KAUSF))を計算する。
【0056】
図５及び６は、PLMN変更を伴うXnハンドオーバーが認証手順中に行われる場合の認証手順の処理について説明している。5G AKA based primary authentication and key agreement手順では、サービングネットワーク名は、RES*とXRES*をサービングネットワークに結び付けるという同様の目的を持っている。
【0057】
【0058】
以下に、実施の形態の詳細な処理を説明する。
【0059】
0.UEとネットワーク(例:RAN、AMFなど)が登録手順（registration procedure）を実行する。そして、UEは、PLMN ID=Aを持つPLMNに登録される。PLMN IDは、PLMNを識別する識別子 (identifierまたはidentity) である。「PLMN ID=A」はPLMN IDが「A」であるか、PLMN IDが「A」に設定されていることを意味する。つまり、UEは、「A」であるPLMN IDで識別されるPLMNに登録される。登録エリアは、少なくとも2つのTracking Area (PLMN ID=Aで提供されるTA1とPLMN ID=Bで提供されるTA2)を含む。「PLMN ID=B」とは、PLMN IDが 「B」であるか、またはPLMN IDが「B」に設定されていることを意味する。この登録エリアは、登録手順中にUEに割り当てられる。
【0060】
1.UEはサービス要求（service request）手順を開始する。UEは、PLMN ID=AのセルでRRC接続を確立する。RRC接続確立後、UEは、AMFにService requestメッセージを送信する。
【0061】
なお、ステップ1のService requestメッセージは、任意のNASメッセージにすることができる。
【0062】
2.AMFはUEからService requestメッセージを受信する。次に、AMFは、Nausf_UEAuthentication_Authenticate Request (SUPI、SN name=PLMN ID=A)をAUSFに送信することによって、UEの認証手順を開始してもよい(例えばローカルポリシーに基づいて)。「SN name =PLMN ID=A」は、SN nameが、「A」であるPLMN IDであること、またはSN nameが、「A」に設定されたPLMN IDであることを意味する。言い換えると、「SN name =PLMN ID=A」は、SN nameが、「A」であるPLMN IDによって識別されるPLMN、または 「A」であるPLMN IDを持つPLMNを識別することを意味する。つまり、AMFは、SN nameが、「A」であるPLMN IDであることをAUSFに通知する。
【0063】
3.AUSFは、Nausf_UEAuthentication_Authenticate Requestメッセージを受信すると、Nudm_UEAuthentication_Get Request (SUCIまたはSUPI、SN name =PLMN ID=A)をUDMに送信する。つまり、AUSFは、SN nameが、「A」であるPLMN IDであることをUDMに通知する。
【0064】
4.Xnハンドオーバー手順がネットワークでトリガーされ、TA2のPLMN ID=Bによって提供（serve）されるセルにUEがハンドオーバーされる。たとえば、UEがTA1からTA2に移動したときにXnハンドオーバーがトリガーされてもよい。
【0065】
4-1.Xnハンドオーバー手順中に、UEは選択されたPLMN-IdentityとしてPLMN ID=Bを含むRRCメッセージ(例えば、RRC Reconfiguration Completeメッセージ)をターゲットRANに送信する。例えば、UEは、RRCメッセージ(例えば、RRC Reconfiguration Completeメッセージ)を送信する前に、選択されたPLMN-IdentityとしてPLMN ID=Bを選択する。
【0066】
4-2.Xnハンドオーバー手順中に、ターゲットRAN (例えば、Target gNB)は、AMFへ、PLMN ID=Bを含む（includeもしくはcontain）N2 Path switch request メッセージ(つまり、「B」であるPLMN IDを含むN2 Path switch request)を送信する。たとえば、PLMN IDは、User Location Informationパラメータに含まれているE-UTRA CGIパラメータに含まれている。
【0067】
5.UDMは、Nudm_UEAuthentication_Get Requestメッセージを受信すると、サービングPLMN name PLMN ID=Aに基づいてXRES*を生成(または計算)する。つまり、UDMは、「A」 であるPLMN IDに基づいてXRES*を生成する。
【0068】
6.UDMは、サービングPLMN name PLMN ID=Aに基づいてKAUSFを導出(または計算) する。つまり、UDMは、「A」 であるPLMN IDに基づいてKAUSFを導出する。
【0069】
7.UDMは、Nudm_Authentication_Get Response (SUPI、5G HE AV、SN for authentication=PLMN ID=A)をAUSFに送信する。authentication=PLMN ID=AのServing Network (SN) はオプションのパラメータである。「SN for authentication =PLMN ID=A」 は、SN for authenticationが、「A」のPLMN IDであること、またはSN for authenticationが、「A」に設定されたPLMN IDであることを意味する。つまり、SN for authenticationは、認証手順で使用されるPLMN IDであることを示す(例えば、SN for authenticationは、UEによるRES*の計算およびUEによるKAUSFの導出に使用されるPLMN IDを示す)。
【0070】
8.AUSFはXRES*を格納する。AUSFは5GHE AVから5G AV、XRES*からHXRES、KAUSFからKSEAFを生成する。
【0071】
9.AUSFは、Nausf_UEAuthentication_Authenticate Response (5G SE AV (RAND, AUTN, HXRES*, SN for authentication=PLMN ID=A)をAMFに送信する。Serving Network (SN) for authenticationはオプションのパラメータである。AUSFは、Serving Network (SN) for authentication をUDMから受信したときにServing Network (SN) for authenticationを送信してもよい。
【0072】
10.Nausf_UEAuthentication_Authenticate Responseを受信すると、AMFは(ngKSI, ABBA, RAND, AUTN and SN for authentication=PLMN ID=A)を含むAuthentication Requestメッセージを送信する。SN for authenticationは、ステップ2でAMFからAUSFに送信されるSN nameである。一例では、SN for authenticationは、ステップ9でNausf_UEAuthentication_Authenticate ResponseメッセージでAUSFから受信したものと同じである。
【0073】
11.UEがAuthentication Requestメッセージを受信すると、UEはAUTNを検証（verify）する。AUTN検証が成功した後、UEはSN for authentication=PLMN ID=Aを使用してRES*を計算 (または生成)する。つまり、UEは、「A」であるPLMN IDに基づいてRES*を計算する。
【0074】
12.UEはSN for authentication=PLMN ID=Aを使用してKAUSFを導出(または生成)する。つまり、UEは、「A」であるPLMN IDに基づいてKAUSFを導出する。UEは、KAUSFを格納し、セキュリティ手順(例:セキュリティキーKSEAFの導出)で必要な場合に、KAUSFを使用する。
【0075】
13.UEは、RES*を含むauthentication response（認証応答）メッセージをAMFに送信する。
【0076】
14.AMFは、UEからauthentication responseメッセージを受信すると、RES*からHRES*を導出し、HRES*とHXRES*を比較する。
【0077】
15.比較が正常（successful comparison）である場合、AMFは、RES*を含むNausf_UEAuthentication_Authenticate RequestメッセージをAUSFに送信する。
【0078】
16.AUSFは、RES*を含むNausf_UEAuthentication_Authenticate Requestメッセージを受信すると、RES*とXRES*を比較する。
【0079】
17.比較が正常（successful comparison）である場合、AUSFで、KSEAFがKAUSFから計算される。
【0080】
18.AUSFは、Result、SUPI、およびKSEAFを含むNausf_UEAuthentication_Authenticate ResponseメッセージをAMFに送信する。Resultには、AUSFにおけるRES*とXRES*の比較に基づく認証手順の結果が含まれる。つまり、Resultは、AUSFにおけるRES*とXRES*の比較に基づく認証手順の結果を示す情報であってもよい。
【0081】
19.Nausf_UEAuthentication_Authenticate Responseメッセージを受信すると、AMFはResultをチェックする(例えば、AMFはResultを示す情報要素(IE)をチェックする)。Resultが認証が成功したことを示している場合、AMFはステップ1によってトリガーされたサービス要求手順を続行する。
【0082】
20.AMFは、3GPP TS 33.501 [5] で説明されている手順に従って、Nausf_UEAuthentication_Authenticate ResponseメッセージでPLMN ID=Bを送信することによって、AUSFに対する新しい認証手順を開始してもよい。認証手順が正常に完了した後、UEとUDM/AUSFは、新しい認証手順中に作成された同じKAUSFと同期される。例えば、UEとUDM/AUSFは、PLMN ID=B (つまり、「B」であるPLMN ID)に基づいて作成された同じKAUSFと同期される。
【0083】
1つの例では、ステップ1でUEはコネクテッドモード（connected mode）であり、少なくともユーザプレーンベアラ (Dedicated Radio Bearer) が確立されている。AMFは、ローカルポリシーに従って認証手順を実行することを決定する。この場合、認証手順は、UEからのNASメッセージの受信と独立して開始される。
【0084】
解決策1の変形例1
【0085】
一例として、AMFは、PLMN ID=BのターゲットRANからN2 Path switch requestメッセージを受信した場合、最新のPLMN ID=Bである一方、ステップ2で開始された認証手順がPLMN ID=Aに関連付けられていることを理解できる。たとえば、AMFは、ステップ2でNausf_UEAuthentication_Authenticate Requestを送信し、ステップ4-2でPLMN ID=BのターゲットRANからN2 Path switch requestメッセージを受信したことに基づいて、認証手順の進行中にPLMN変更を伴うXnハンドオーバーが発生したかどうかを判断および理解できる。すなわち、AMFは、PLMN IDの不一致 (1つは最新のもので、もう1つは認証手順に使用されるもの) を理解する。この場合、AMFはこの不一致を記憶し、ステップ10でAMFがAuthentication RequestメッセージをUEに送信する場合、PLMN ID=AをSN for authenticationに設定する。そして、AMFは、「A」に設定されたPLMN IDを示すSN for authenticationを含むAuthentication Requestメッセージを送信する。この例では、UDMもAUSFもSN for authenticationを処理する必要はない。
【0086】
解決策1の変形例2
【0087】
ステップ0で、UEがAMFに初めて登録されると、UEとAMFは、UEが登録されたサービングPLMN IDを格納する。このサービングPLMN IDは、UEがAMFに登録されている間、UEとAMFにSN for authenticationとして格納される。UEが異なる登録エリアに登録されているが、同じAMFでサービスされている場合、UEとAMFはSN for authenticationを更新してもよい。UEとAMFは、AMFによってトリガーされる後続の認証手順でのこのSN for authenticationに基づくSN nameを使用する。本実施の形態では、SN for authenticationは、ステップ2からステップ18までの認証手順でUEとAMFが使用するPLMN ID=Aである。なお、この変形例2では、ステップ7、9、10のSN for authenticationパラメータは必要ない。
【0088】
解決策1の変形例3
【0089】
1つの例では、UE認証手順が進行中かどうかに関係なく、AMFは、PLMN変更を伴うXnハンドオーバー手順中、またはPLMN変更を伴うXnハンドオーバー手順が成功した後に、新しいサービングPLMN ID=Bを含むメッセージをUDMに送信する。たとえば、AMFは、PLMN変更を伴うXnハンドオーバー手順中に「B」に設定されたPLMN IDを含むN2 Path switch requestメッセージをAMFが受信したときに、新しいサービングPLMN IDが「B」であることを示す情報を含むメッセージをUDMに送信してもよい。さらに、たとえば、AMFは、「B」に設定されたPLMN IDを含むN2 Path switch requestメッセージの受信に応答してAMFがN2 Path switch request ack (acknowledgement) メッセージを送信した後に、新しいサービングPLMN IDが「B」であることを示す情報を含むメッセージをUDMに送信してもよい。UDMは、メッセージを受信すると、UEの現在のサービングPLMNをPLMN ID=Bに更新する。UDMは、UEのサービングPLMNがPLMN ID=Bに変更されたときに何らかのアクションを取ってもよい。つまり、UDMは、UEのサービングPLMN IDを 「B」 であるPLMN IDに更新する。たとえば、UDMは、Steering of Roaming (SoR) 手順をUEに対してトリガーして、新しいpreferred PLMNリストをUEに送信し、またはUE Parameter Update (UPU) 手順をトリガーしてもよい。
【0090】
解決策1の変形例4
【0091】
一例では、認証手順が正常に完了した後(ステップ18の後)、UDMをUEの新しいサービングPLMNで更新するために、AMFはUDMにPLMN ID=Bを含むメッセージ(例:Nudm_UECM_Registration service)を送信する。つまり、AMFはUDMに、新しいサービングPLMN IDが「B」であることを示す情報を含むメッセージを送信する。UDMはこのメッセージを受信すると、UEのサービングPLMN IDをPLMN ID=Bに更新する。つまり、UDMはUEのサービングPLMN IDを「B」であるPLMN IDに更新する。
【0092】
解決策1の変形例5
【0093】
一例として、UEがステップ10でAMFからAuthentication Requestメッセージを受信した場合、UEが有効な5G-GUTIを持っている場合、ステップ4-1でRRCメッセージ(たとえば、RRC Reconfiguration Completeメッセージ)でターゲットRANに送信される最新のPLMN ID (例:PLMN ID=B)のMCCおよびMNC部分が、5G-GUTIのMCCおよびMNC部分と同じかどうかをチェックする。MCCおよびMNC部分が同じでない場合、UEは、3GPP TS 33.501 [5] に従って、5G-GUTIのMCCおよびMNC部分を使用してServingネットワーク名(つまり、SN for authentication)を構築し、5G-GUTIのMCCおよびMNC部分に基づいて構築されたServingネットワーク名を使用して、ステップ11でRES*の計算(または生成) を実行し、5G-GUTIのMCCおよびMNC部分に基づいて構築されたServingネットワーク名を使用して、ステップ12でKAUSFの導出(または生成)を実行する。
【0094】
解決策1の変形例6
【0095】
一例として、UEがEPSにおけるEPS AKA 手順に対して、ステップ10でMMEからAuthentication Requestメッセージを受信した場合、UEは、有効な4G-GUTIがあれば、ステップ4-1においてRRCメッセージ(たとえば、RRC Connection Reconfiguration Completeメッセージ)でターゲットRANに送信される最新のPLMN ID(例:PLMN ID=B)のMCCおよびMNC部分が、4G-GUTIのMCCおよびMNC部分と同じであるかどうかを確認する。MCCおよびMNC部分が同じでない場合、UEは、図4に示すように、4G-GUTIのMCCおよびMNC部分を使用してServing Network Identity (つまり、SN for authentication)を構築し、4G-GUTIのMCCおよびMNC部分に基づいて構築されたServing Network Identityを使用して、ステップ11でRES*の計算(または生成)を行い、4G-GUTIのMCCおよびMNC部分に基づいて構築されたServing Network Identityを使用して、ステップ12でKASMEの導出(または生成)を実行する。
【0096】
解決策1の変形例7
【0097】
1つの例では、AMFがステップ9でAUSFからNausf_UEAuthentication_Authenticate Responseメッセージを受信した場合、AMFは、有効な5G-GUTIがある場合、ステップ4-2でN2 Path switch requestメッセージで受信した最新のPLMN ID (例:PLMN ID=B)のMCCおよびMNC部分が、5G-GUTIのMCCおよびMNC部分と同じであるかどうかを確認する。MCCおよびMNC部分が同じでない場合、AMFは、Nausf_UEAuthentication_Authenticate Requestメッセージ(SUCIまたはSUPI、SN name=PLMN ID=B)をSN name=PLMN ID=Bで新しい認証手順を開始するためにAUSFに送信する。「SN name=PLMN ID=B」は、SN nameが、「B」であるPLMN IDであること、またはSN nameが、「B」に設定されているPLMN IDであることを意味する。言い換えると、「SN name=PLMN ID=B」とは、SN nameが、「B」であるPLMN IDによって識別されるPLMNを識別すること、または、「B」であるPLMNを有するPLMNを識別すること、を意味する。つまり、AMFは、SN nameが「B」であるPLMN IDであることをAUSFに通知する。
【0098】
AMFは、ステップ2で開始した認証手順を進めない。すなわち、AMFは、ステップ2で開始した認証手順を中止する。
【0099】
解決策1の変形例8
【0100】
1つの例では、MMEがステップ9もしくはステップ7及び9の組み合わせでHSSからAuthentication Information Answerメッセージを受信した場合、MMEは、有効な4G-GUTIがある場合、ステップ4-2のPath switch requestメッセージで受信した最新のPLMN IDのMCCおよびMNC部分が4G-GUTIのMCCおよびMNC部分と同じかどうかを確認する。MCCおよびMNC部分が同じでない場合、MMEは、SN id=PLMN ID=Bで新しい認証手順を開始するために、Authentication Information Requestメッセージ(IMSI、SN id=PLMN ID=B)をHSSに送信する。「SN id=PLMN ID=B」は、SN idが、「B」であるPLMN IDであること、またはSN idが、「B」に設定されているPLMN IDであることを意味する。言い換えると、「SN id=PLMN ID=B」は、SN idが、「B」であるPLMN IDによって識別されるPLMN、または「B」であるPLMN IDを持つPLMNを識別することを意味する。つまり、MMEは、SN idが、「B」であるPLMN IDであることをHSSに通知する。
【0101】
MMEは、ステップ2で開始した認証を進めない。すなわち、MMEは、ステップ2で開始した認証手順を中止する。
【0102】
実施の形態２（解決策２）
【0103】
AMFが、1) 認証（Authentication）が進行中であること、2) PLMN変更を伴うXnハンドオーバーが行われたことを検出した場合、AMFは認証手順を開始する。
【0104】
Xnハンドオーバーの間の認証手順の処理を図7に示す。
【0105】
実施の形態の詳細な処理を以下に説明する。
【0106】
0.UEとネットワーク(例:RAN、AMFなど)は、登録手順を実行する。そして、UEは、PLMN ID=Aを持つPLMNに登録されている。「PLMN ID=A」は、PLMN IDが「A」であるか、PLMN IDが「A」に設定されていることを意味する。つまり、UEは、「A」であるPLMN IDで識別されるPLMNに登録される。登録エリアは、少なくとも2つのTracking Area(PLMN ID=Aで提供されるTA1とPLMN ID=Bで提供されるTA2)を含む。「PLMN ID=B」は、PLMN IDが「B」であること、またはPLMN IDが「B」に設定されていることを意味する。この登録エリアは、登録手順の間にUEに割り当てられる。
【0107】
1.UEはサービス要求手順を開始する。UEは、PLMN ID=AのセルでRRC接続を確立する。RRC接続確立後、UEは、Service requestメッセージをAMFに送信する。
【0108】
なお、ステップ1のService requestメッセージは、任意のNASメッセージにすることができる。
【0109】
2.AMFは、UEからService requestメッセージを受信する。次に、AMFは、Nausf_UEAuthentication_Authenticate Request (SUPI、SN name=PLMN ID=A)をAUSFに送信することによって、UEの認証手順 (例えばローカルポリシーによるもの)を開始してもよい。「SN name=PLMN ID=A」は、SN nameが「A」であるPLMN IDであること、またはSN nameが「A」に設定されたPLMN IDであることを意味する。つまり、AMFは、SN nameが「A」であるPLMN IDであることをAUSFに通知する。
【0110】
3.AUSFは、Nausf_UEAuthentication_Authenticate Requestメッセージを受信すると、UDMにNudm_UEAuthentication_Get Request (SUCIまたはSUPI、SN name=PLMN ID=A)を送信する。つまり、AUSFは、SN nameが「A」であるPLMN IDであることをUDMに通知する。
【0111】
4.Xnハンドオーバー手順がネットワークでトリガーされ、UEは、TA2においてPLMN ID=Bでサービスするセルへハンドオーバーされる。たとえば、UEがTA1からTA2に移動したときにXnハンドオーバーがトリガーされてもよい。
【0112】
4-1.Xnハンドオーバー手順中に、UEは選択されたPLMN-IdentityとしてPLMN ID=Bを含むRRCメッセージ(例えば、RRC Reconfiguration Completeメッセージ)をターゲットRANに送信する。例えば、UEはRRCメッセージ(例えば、RRC Reconfiguration Completeメッセージ)を送信する前に、選択されたPLMN-IdentityとしてPLMN ID=Bを選択する。
【0113】
4-2.Xnハンドオーバー手順中に、ターゲットRAN(例えば、Target gNB)は、PLMN ID=Bを含む（including又はcontaining）N2 Path switch requestメッセージ(つまり、N2 Path switch requestメッセージが、「B」であるPLMN IDを含む。)をAMFに送信する。たとえば、PLMN IDは、User Location Informationパラメータに含まれているE-UTRA CGIパラメータに含まれている。
【0114】
5.AMFは、認証手順の進行中に、PLMN変更を伴うXnハンドオーバーによってUEがPLMN ID=Bで識別されるPLMNに移動したことを検出した場合、SN name=PLMN ID=Bを使用して、AUSF/UDMに向けて新しい認証手順を開始する。たとえば、AMFは、ステップ2で開始された認証手順中に、ステップ4-2で「B」に設定されたPLMN IDを含むN2 Path switch requestメッセージを受信することによって、UEが「B」であるPLMN IDで識別されるPLMNに移動したことを検出(または判断)してもよい。また、例えば、AMFは、ステップ2で開始された認証手順中に、ステップ4-2で「B」に設定されたPLMN IDを含むN2 Path switch requestメッセージを受信したことに応答して、N2 Path switch request ack (acknowledgement)メッセージを送信することによって、UEが「B」であるPLMN IDで識別されるPLMNに移動したことを検出(または判断)してもよい。さらに、例えば、AMFは、ステップ2でNausf_UEAuthentication_Authenticate Requestを送信し、ステップ4-2でPLMN ID=BのターゲットRANからN2 Path switch requestメッセージを受信したことに基づいて、認証手順の進行中にPLMN変更を伴うXnハンドオーバーが発生したことを検出(または判断)し、その後、AMFは、SN name=PLMN ID=Bを使用して、AUSF/UDMに対して新しい認証手順を開始してもよい。
【0115】
6.AMFは、Nausf_UEAuthentication_Authenticate Requestメッセージ(SUCIまたはSUPI、SN name=PLMN ID=B)をAUSFに送信して、SN name=PLMN ID=Bで新しい認証手順を開始する。「SN name=PLMN ID=B」は、SN nameが「B」であるPLMN IDであること、またはSN nameが「B」に設定されているPLMN IDであることを意味する。言い換えると、「SN name=PLMN ID=B」は、SN nameが、「B」であるPLMN IDによって識別されるPLMN、または「B」であるPLMN IDを有するPLMNを識別することを意味する。つまり、AMFは、SN nameが「B」であるPLMN IDであることをAUSFに通知する。AMFは、ステップ2で開始した手順の認証を進めない。すなわち、AMFは、ステップ2で開始した認証手順を中止する。
【0116】
一例では、AMFは、ステップ2のNausf_UEAuthentication_Authenticate Requestメッセージ(SUCIまたはSUPI、SN name=PLMN ID=A)への応答として、AUSFから応答メッセージ(例:Nausf_UEAuthentication_Authenticate Response)を受信したときに、新しい認証手順を開始する。この場合、AMFは、ステップ2のNausf_UEAuthentication_Authenticate Requestメッセージ(SUCIまたはSUPI、SN name=PLMN ID=A)への応答としてのNausf_UEAuthentication_Authenticate Responseメッセージを無視して破棄する。
【0117】
ステップ6以降、UEとネットワークの間で、SN name=PLMN ID=B(つまり、「B」であるPLMN ID)に基づく新しい認証手順が進行する。
【0118】
解決策2の変形例1
【0119】
1つの例では、ステップ5で、AMFがN2 PATH SWITCH REQUESTメッセージを受信したときにサービングPLMNがPLMN ID=Bに変更されたと判断したとき、Xnハンドオーバー手順の完了後、AMFはPLMN ID=Bに基づいて新しい5G-GUTIを割り当てる(すなわち、PLMN ID=BのMCCとMNCの部分は、5G-GUTIのMCCとMNCに割り当てられる。)。たとえば、AMFはN2 Path switch request ack (acknowledgement) メッセージを送信した後、PLMN ID=Bに基づいて新しい5G-GUTIを割り当てる。次に、AMFは新しい5G-GUTIをCONFIGURATION UPDATE COMMANDメッセージでUEに送信し、CONFIGURATION UPDATE COMPLETEメッセージを受信した後、AMFはNausf_UEAuthentication_Authenticate Requestメッセージ(SUCIまたはSUPI、SN name=PLMN ID=B)をAUSFに送信して新しい認証手順を開始する。汎用UE設定更新コマンド手順 (generic UE configuration update command procedure) の完了後にUEがAuthentication Requestメッセージを受信した場合、UEはGUTIのMCCおよびMNC部分を使用して、KAUSFおよびRES*の計算のためのSN nameを計算する。
【0120】
解決策2の変形例2
【0121】
1つの例では、ステップ5で、MMEはPATH SWITCH REQUESTメッセージを受信したときにサービングPLMNがPLMN ID=Bに変更したと判断したとき、X2ハンドオーバー手順が完了した後に、MMEはPLMN ID=Bに基づいて新しい4G-GUTIを割り当てる(すなわち、PLMN ID=BのMCCとMNCの部分が4G-GUTIのMCCとMNCに割り当てられている)。例えば、MMEはPath switch request ack (acknowledgement)メッセージを送信した後、PLMN ID=Bに基づいて新しい4G-GUTIを割り当てる。次に、MMEは新しい4G-GUTIをGUTI reallocation commandメッセージでUEに送信し、GUTI reallocation completeメッセージを受信した後、AMFはPLMN ID=Bに基づくSN IDを含む認証データ要求（authentication data request）をHSSに送信することで、新しい認証手順を開始する。UEは、GUTI-reallocation手順の完了後にAuthentication Requestメッセージを受信した場合、4G-GUTIのMCCとMNCの部分を使用して、KASMEの計算のためのSN IDを計算する。
【0122】
解決策2の変形例3
【0123】
1つの例では、UE認証手順が進行中かどうかに関係なく、AMFがN2 PATH SWITCH REQUESTメッセージを受信したときに、サービングPLMNがPLMN ID=Bに変更されたと判断した場合、Xnハンドオーバー手順の完了後、AMFはPLMN ID=Bに基づいて新しい5G-GUTIを割り当てる(すなわち、PLMN ID=BのMCCとMNCの部分は、5G-GUTIのMCCとMNCに割り当てられる)。たとえば、AMFはN2 Path switch request ack (acknowledgement)メッセージを送信した後、PLMN ID=Bに基づいて新しい5G-GUTIを割り当てる。次に、AMFは、最新のPLMN IDと最新のPLMN IDに関連付けられた5G-GUTIを同期させるために、CONFIGURATION UPDATE COMMANDメッセージで新しい5G-GUTIをUEに送信する。
【0124】
解決策2の変形例4
【0125】
1つの例では、UE認証手順が進行中かどうかに関係なく、MMEがPATH SWITCH REQUESTメッセージを受信したときに、サービングPLMNがPLMN ID=Bに変更されたと判断した場合、X2ハンドオーバー手順の完了後、MMEはPLMN ID=Bに基づいて新しい4 G-GUTIを割り当てる(すなわち、PLMN ID=BのMCCとMNCの部分が4G-GUTIのMCCとMNCに割り当てられている)。たとえば、MMEはPath switch request ack (acknowledgement)メッセージを送信した後、PLMN ID=Bに基づいて新しい4G-GUTIを割り当てる。次に、MMEは最新のPLMN IDと最新のPLMN IDに関連付けられた4G-GUTIを同期させるために、新しい4G-GUTIをGUTI reallocation commandメッセージでUEに送信する。
【0126】
User equipment (UE)
【0127】
図１０は、ＵＥ（８００）の主要構成要素を示すブロック図である。図示されるように、ＵＥ（８００）は、１つまたは複数のアンテナ（８０１）を介して、接続されたノードへ信号を送信し、接続されたノードから信号を受信するように動作可能である送受信機回路（８０２）を含む。図１０に必ずしも示されているとは限らないが、ＵＥは、当然ながら、従来のモバイルデバイスの（ユーザインターフェースなどの）あらゆる通常の機能性を有しており、これは、必要に応じて、ハードウェア、ソフトウェアおよびファームウェアのうちのいずれか１つ、または、これらの任意の組み合わせによって提供され得る。ソフトウェアは、メモリにプリインストールされていてもよく、および／または、例えば、電気通信ネットワークを介して、もしくは取外し可能なデータストレージデバイス（ＲＭＤ：ｒｅｍｏｖａｂｌｅ ｄａｔａ ｓｔｏｒａｇｅ ｄｅｖｉｃｅ）から、ダウンロードされてもよい。
【0128】
コントローラ（８０４）は、メモリ（８０５）に記憶されたソフトウェアに従って、ＵＥの動作を制御する。ソフトウェアは、とりわけ、オペレーティングシステムと、少なくとも送受信機制御モジュールを有する通信制御モジュールとを含む。通信制御モジュールは（その送受信機制御サブモジュールを使用して）、ＵＥと他のノード、例えば、基地局／（Ｒ）ＡＮノード、ＭＭＥ、ＡＭＦ（および他のコアネットワークノード）などとの間のシグナリングおよびアップリンク／ダウンリンクデータパケットを処理する（生成する／送る／受信する）役割を負う。そのようなシグナリングは、例えば、接続確立およびメンテナンスに関連する、適切にフォーマットされたシグナリングメッセージ（例えばRRC connection establishment及びＲＲＣメッセージ）、周期的位置更新に関連するメッセージ（例えば、追跡エリア更新（tracking area update）、ページングエリア更新（paging area updates）、位置エリア更新（location area update））などのメッセージ等を含み得る。そのようなシグナリングは、また、例えば、受信ケースにおいて、ブロードキャスト情報（例えばマスター情報（Master Information）及びシステム情報（System Information））を含んでもよい。
【0129】
(R)ANノード
【0130】
図９は、例示的な（Ｒ）ＡＮノード（９００）、例えば基地局（ＬＴＥにおける「ｅＮＢ」、５Ｇにおける「ｇＮＢ」）の主要な構成要素を示すブロック図である。図示されるように、（Ｒ）ＡＮノードは、１つまたは複数のアンテナ（９０１）を介して、接続されたＵＥへ信号を送信し、接続されたＵＥから信号を受信し、ネットワークインターフェース（９０３）を介して、（直接的にまたは間接的に）他のネットワークノードへ信号を送信し、他のネットワークノードから信号を受信するように動作可能である送受信機回路（９０２）を含む。コントローラ（９０４）は、メモリ（９０５）に記憶されたソフトウェアに従って、（Ｒ）ＡＮノードの動作を制御する。ソフトウェアは、メモリにプリインストールされていてもよく、および／または、例えば、電気通信ネットワークを介して、もしくは取外し可能なデータストレージデバイス（ＲＭＤ）から、ダウンロードされてもよい。ソフトウェアは、とりわけ、オペレーティングシステムと、少なくとも送受信機制御モジュールを有する通信制御モジュールとを含む。
【0131】
通信制御モジュールは（その送受信機制御サブモジュールを使用して）、（Ｒ）ＡＮノードと他のノード、例えば、ＵＥ、ＭＭＥ、ＡＭＦなどとの間のシグナリングを（例えば、直接的にまたは間接的に）処理する（生成する／送る／受信する）役割を負う。シグナリングは、例えば、（特定のＵＥについての）無線接続および位置手続きに関する、特に、接続確立およびメンテナンス（例えば、ＲＲＣ接続確立および他のＲＲＣメッセージ）に関する、適切にフォーマットされたシグナリングメッセージ、周期的位置更新に関連するメッセージ（例えば、追跡エリア更新、ページングエリア更新、位置エリア更新）、Ｓ１ ＡＰメッセージおよびＮＧ ＡＰメッセージ（すなわち、Ｎ２基準点によるメッセージ）等を含んでもよい。そのようなシグナリングは、例えば、送る場合にはブロードキャスト情報（例えば、マスター情報およびシステム情報）も含んでもよい。
【0132】
コントローラ（９０４）は、実装される場合、ＵＥモビリティ推定（UE mobility estimate）および／または移動軌跡推定（moving trajectory estimation）などの関連するタスクを処理するように（ソフトウェアまたはハードウェアによって）も構成される。
【0133】
AMF
【0134】
図１０は、ＡＭＦ（１０００）の主要な構成要素を示すブロック図である。ＡＭＦ（１０００）は、５ＧＣに含まれる。図示されるように、ＡＭＦ（１０００）は、ネットワークインターフェース（１００４）を介して、他のノード（ＵＥを含む）へ信号を送信し、他のノードから信号を受信するように動作可能である送受信機回路（１００１）を含む。コントローラ（１００２）は、メモリ（１００３）に記憶されたソフトウェアに従って、ＡＭＦ（１０００）の動作を制御する。ソフトウェアは、メモリ（１００３）にプリインストールされていてもよく、および／または、例えば、電気通信ネットワークを介して、もしくは取外し可能なデータストレージデバイス（ＲＭＤ）から、ダウンロードされてもよい。ソフトウェアは、とりわけ、オペレーティングシステムと、少なくとも送受信機制御モジュールを有する通信制御モジュールとを含む。
【0135】
通信制御モジュールは（その送受信機制御サブモジュールを使用して）、ＡＭＦと他のノード、例えば、ＵＥ、基地局／（Ｒ）ＡＮノード（例えば、「ｇＮＢ」または「ｅＮＢ」）などとの間のシグナリングを（直接的にまたは間接的に）処理する（生成する／送る／受信する）役割を負う。そのようなシグナリングは、例えば、本明細書において説明される手順に関連する、適切にフォーマットされたシグナリングメッセージ、例えば、ＵＥからおよびＵＥへＮＡＳメッセージを伝達するためのＮＧ ＡＰメッセージ（すなわち、Ｎ２基準点によるメッセージ）等を含んでもよい。
【0136】
本開示におけるユーザ装置（User Equipment）（または「UE」、「移動局（mobile station）」、「モバイル装置（mobile device）」、「無線装置（wireless device）」）は、無線インターフェースを介してネットワークに接続されたエンティティである。本明細書のUEは、専用の通信装置に限定されるものではなく、本明細書中に記載されたUEとしての通信機能を有する次のような任意の機器であっても良い。
【0137】
用語として「（3GPPで使われる単語としての）ユーザ装置（User Equipment、UE）」、「移動局」、「モバイル装置」、「無線装置」のそれぞれは、一般的に互いに同義であることを意図しており、ターミナル、携帯電話、スマートフォン、タブレット、セルラIoT端末、IoTデバイス、などのスタンドアローン移動局であってもよい。なお用語としての「UE」「無線端末」は、長期間にわたって静止している装置も包含することが理解されよう。
【0138】
UEは、例えば、生産または製造のための機器および/またはエネルギー関連機械(例えば、次のような機器や機械:ボイラー;エンジン;タービン;ソーラーパネル;風力タービン;水力発電機;火力発電所;原子力発電所;電池;原子力システムおよび/または関連機器;重電機器;真空ポンプを含むポンプ;コンプレッサー;ファン;ブロワー;油圧機器;空気圧機器;金属加工機械;マニピュレーター;ロボットとそのアプリケーションシステム;ツール;金型または金型;ロール;搬送装置;昇降装置;マテリアルハンドリング装置;繊維機械;ミシン;印刷および/または関連する機械;紙加工機械;化学機械;鉱業および/または建設機械および/または関連機器;農林漁業用機械器具;安全および/または環境保全機器;トラクター;精密軸受;チェーン;ギア;送電設備;潤滑装置;バルブ;パイプフィッティング;および/または前述の機器または機械などのアプリケーションシステム。)であっても良い。
【0139】
またUEは、例えば、輸送用装置（一例として、車両、自動車、二輪自動車、自転車、列車、バス、カート（carts）、人力車、船舶（ship and other watercraft）、飛行機、ロケット、人工衛星、ドローン、気球など）であっても良い。
【0140】
またUEは、例えば、情報通信用装置（一例として、電子計算機及び関連装置、通信装置及び関連装置、電子部品など）であっても良い。
【0141】
またUEは、例えば、冷凍機、冷凍機応用製品および装置、商業およびサービス用機器、自動販売機、自動サービス機、事務用機械及び装置、民生用電気・電子機械器具（一例として音声機器、ビデオ機器、スピーカー、ラジオ、テレビ、オーブンレンジ、炊飯器、コーヒーメーカー、食洗機、洗濯機、乾燥機、扇風機、換気扇及び関連製品、掃除機など）であっても良い。
【0142】
またUEは、例えば、電子応用システムまたは電子応用装置（一例として、X線システム、粒子加速装置、放射性物質応用装置、音波装置、電磁応用装置、電力応用装置など）であっても良い。
【0143】
またUEは、例えば、電子ランプ、照明器具、測定器、分析器、試験器、または測量または感知機器(例えば、次のような測量機器や感知機器:煙感知器;人感センサー;モーションセンサー;無線タグ、など。)、時計（watch又はclock）、実験器具、光学機器、医療機器および/またはシステム、武器、刃物のアイテム、手工具などであっても良い。
【0144】
またUEは、例えば、無線通信機能を備えたパーソナルデジタルアシスタントまたは関連装置（他の電子機器（例えば、パーソナル・コンピュータ、電気測定機）に取り付けるため、または挿入するために設計された無線カードまたはモジュールなど）であっても良い。
【0145】
またUEは、例えば、有線や無線通信技術を使用した「モノのインターネット（IoT：Internet of Things）」において、以下のアプリケーション、サービス、ソリューションを提供する装置またはシステムの一部であっても良い。IoTデバイス（もしくはモノ）は、デバイスが互いに、および他の通信デバイスとの間で、データ収集およびデータ交換することを可能にする適切な電子機器、ソフトウェア、センサー、ネットワーク接続、などを備える。またIoTデバイスは、内部メモリの格納されたソフトウェア指令に従う自動化された機器を含んでも良い。またIoTデバイスは、人間による監督または対応を必要とすることなく動作しても良い。またIoTデバイスは、長期間にわたって備え付けられている装置および／または、長期間に渡って非活性状態（inactive）状態のままであっても良い。またIoTデバイスは、（一般に）据え置き型な装置の一部として実装され得る。IoTデバイスは、非据え置き型の装置（例えば車両など）に埋め込まれ得る、または監視される／追跡される動物や人に取り付けられ得る。
【0146】
人間の入力による制御またはメモリに格納されるソフトウェア命令に関係なくデータを送受信する通信ネットワークに接続することができる、任意の通信デバイス上に、IoT技術が実装できることは理解されよう。
【0147】
IoTデバイスが、機械型通信（Machine Type Communication、MTC）デバイス、またはマシンツーマシン（Machine to Machine、M2M）通信デバイス、NB-IoT(Narrow Band-IoT) UEと呼ばれることもあるのは理解されよう。またUEが、１つまたは複数のIoTまたはMTCアプリケーションをサポートすることができることが理解されよう。MTCアプリケーションのいくつかの例は、以下の表３（出典：３ＧＰＰ ＴＳ ２２．３６８ Annex B、その内容は参照により本明細書に組み込まれる）に列挙されている。このリストは、網羅的ではなく、一例としてのmachine type communicationアプリケーションを示すものである。
【0148】
表1:マシンタイプの通信アプリケーションのいくつかの例。
【表1】
【0149】
アプリケーション、サービス、ソリューションは、一例として、MVNO（Mobile Virtual Network Operator：仮想移動体通信事業者）サービス、緊急無線通信システム、PBX（Private Branch eXchange：構内交換機）システム、PHS/デジタルコードレス電話システム、POS（Point of sale）システム、広告発信システム、MBMS（Multimedia Broadcast and Multicast Service）、V2X（Vehicle to Everything）システム、列車無線システム、位置情報関連サービス、災害/緊急時無線通信サービス、コミュニティサービス、映像配信サービス、Femtoセル応用サービス、VoLTE（Voice over LTE）サービス、課金サービス、ラジオオンデマンドサービス、ローミングサービス、行動監視サービス、通信キャリア/通信NW選択サービス、機能制限サービス、PoC（Proof of Concept）サービス、個人情報管理サービス、アドホックネットワーク/DTN（Delay Tolerant Networking）サービスなどであっても良い。
【0150】
なお、上述したUEのカテゴリは、本明細書に記載された技術思想及び例示的な実施の形態の応用例に過ぎない。これらの技術思想及び実施の形態は、上述のUEに限定されるものではなく、これに対して様々な変更を加えることができることは言うまでもない。
【0151】
上記で開示した実施の形態の全体または一部は、以下のように記述することができるが、これに限定されない。
【0152】
6.1.3 認証手順
6.1.3.1 EAP-AKA'の認証手順
EAP-AKA'はRFC5448[12]で指定されている。EAP-AKA'の3GPP 5Gプロファイルは、標準のAnnex Fに記載されている。
Editor’Note: RFC 5448への参照は、RFCになるときに[67]で参照されているインターネットドラフトによって置き換えられる予定である。
EAP-AKA'の使用の選択については、本文書の6.1.2項に記載されている。
図6.1.3.1-1: EAP-AKA'の認証手順(本出願の図11を参照のこと。)
EAP-AKA'の認証手順は次のように動作する。また、図6.1.3.1-1参照(本出願の図11参照):
1. UDM/ARPFは、はじめに、TS33.102[9]で定義されているように、Authentication Management Field (AMF) separation bit = 1の認証ベクトルを生成するものとする。次に、UDM/ARPFは、標準のAnnex Aに従ってCK'とIK'を計算し、CKとIKをCK'とIK'で置き換えるものとする。
2. その後、UDMは、この変換された認証ベクトルAV'(RAND、AUTN、XRES、CK'、IK')を、Nudm_UEAuthentication_Get Responseメッセージを使用して、AV'がEAP-AKA'に使用されることを示すとともに、Nudm_UEAuthentication_Get Requestを受信したAUSFに送信するものとする。
NOTE: 前項で説明したAUSFとUDM/ARPFの間のNudm_UEAuthentication_Get RequestメッセージとNudm_UEAuthentication_Get Responseメッセージの交換は、<network name>の値であるkey derivationへの入力パラメータを除いて、TS 33.402 [11]、6.2項、ステップ10で説明したEAP-AKA'を使用した信頼できるアクセスの場合と同じである。「network name」は、RFC 5448[12]の概念であり;EAP-AKA'のAT_KDF_INPUT attributeで伝達される。<network name>パラメータの値は、RFC 5448 [12]では定義されておらず、3GPP仕様で定義されている。EPSの場合はTS 24.302 [71]で 「access network identity」と定義され、5Gの場合は本文書の6.1.1.4項で「serving network name」 と定義されている。
SUCIがNudm_UEAuthentication_Get Requestに含まれていた場合、UDMはNudm_UEAuthentication_Get ResponseにSUPIを含める。
その後、AUSFとUEは、AUSFがEAP-Successを送信する準備が整うまで、RFC 5448 [12]に記載されている手順を実行する。
サブスクライバーがAKMAサブスクリプションを持っている場合、UDMはNudm_UEAuthentication_Get ResponseにAKMA indicationを含めるものとする。
3. AUSFは、EAP-Request/AKA'-ChallengeメッセージをNausf_UEAuthentication_Authenticate ResponseメッセージでSEAFに送信するものとする。
4. SEAFは、EAP-Request/AKA'-ChallengeメッセージをNASメッセージAuthentication RequestメッセージでUEに透過的に転送するものとする。MEは、EAP-Request/AKA'-Challengeメッセージで受信したRANDおよびAUTNをUSIMに転送するものとする。このメッセージには、ngKSIおよびABBAパラメータを含めるものとする。実際、SEAFは、すべてのEAP-Authentication requestメッセージにngKSIおよびABBAパラメータを含めるものとする。ngKSIは、認証が成功した場合に作成される部分的なネイティブセキュリティコンテキストを識別するために、UEおよびAMFによって使用される。SEAFは、Annex A.7.1に定義されているABBAパラメータを設定するものとする。EAP認証中、SEAFがUEに送信するngKSIとABBAパラメータの値は変更されないものとする。認証手順中に新しいサービングネットワークへのXnハンドオーバーが正常に完了した場合、AMFはNausf_UEAuthentication_Authenticate Requestメッセージで送信されたSN nameをAuthentication Requestメッセージに含めるものとする。
NOTE1: SEAFは、Nausf_UEAuthentication_Authenticate Responseメッセージに基づいて認証方式のタイプを評価することにより、使用される認証方式がEAP方式であることを理解する必要がある。
5. USIMは、RANDとAUTNを受信すると、TS 33.102 [9]に記載されているようにAUTNを受け入れることができるかどうかを確認することによって、AV'の鮮度（freshness）を検証するものとする。その場合、USIMは応答RESを計算する。USIMはRES、CK、IKをMEに返すものとする。USIMがTS 33.102 [9] に記載されているように、変換関数（conversion function）c3を使用してCKとIKからKc(すなわち、GPRS Kc)を計算してMEに送信する場合、MEはそのようなGPRS Kcを無視し、USIMまたはMEにGPRS Kcを保存しないものとする。MEは、Annex A.3に従ってCK'とIK'を導出するものとする。UEがauthentication requestメッセージでSN nameを受信した場合、UEはそのSN nameを使用してRESとKAUSFを計算するものとする。
USIMでAUTNの検証が失敗した場合、USIMとMEは6.1.3.3項に記載されているとおりに処理を進めるものとする。
6. UEは、EAP-Response/AKA'-ChallengeメッセージをNASメッセージAuth-RespメッセージでSEAFに送信するものとする。
7. SEAFは、EAP-Response/AKA'-ChallengeメッセージをNausf_UEAuthentication_Authenticate Requestメッセージで透過的にAUSFに転送するものとする。
8. AUSFは、メッセージを検証するものとし、AUSFがこのメッセージの検証に成功した場合は、次のように続行するものとし、それ以外の場合はSEAFにエラーを返すものとする。AUSFは、UDMに認証結果を通知するものとする(リンク認証確認（linking authentication confirmation）の詳細については、本文書の6.1.4項を参照)。
9. AUSFとUEは、SEAFを介してEAP-Request/AKA'-NotificationおよびEAP-Response/AKA'-Notificationメッセージを交換してもよい。SEAFは、これらのメッセージを透過的に転送するものとする。
NOTE2: RFC 3748 [27] に記載されているEAP NotificationとRFC 4187 [21]に記載されているEAP-AKA Notificationは、EAP-AKA交換でいつでも使用され得る。これらの通知は、保護された結果の表示や、EAPサーバが受信したEAP-AKA応答（response）でエラーを検出した場合などに使用できる。
10. AUSFは、RFC 5448 [12]およびAnnex Fに記載されているように、CK'とIK'からEMSKを導出する。AUSFは、EMSKの最上位256ビットをKAUSFとして使用し、次にA.6.項に記載されているように、KAUSFからKSEAFを計算する。AUSFは、EAP SuccessメッセージをNausf_UEAuthentication_Authenticate Response内でSEAFに送信し、SEAFはそれをUEに透過的に転送するものとする。Nausf_UEAuthentication_Authenticate Responseメッセージは、KSEAFを含む。認証が開始されたときにAUSFがSEAFからSUCIを受信した場合 (本文書の6.1.2項を参照)、AUSFはNausf_UEAuthentication_Authenticate ResponseメッセージにSUPIも含めるものとする。
NOTE 3: 合法的な傍受のためには、AUSFがSEAFにSUPIを送ることは必要であるが十分ではない。KSEAFからのKAMFのkey derivationへの入力パラメータとしてSUPIを含めることにより、ホームネットワークとUE側の両方からサービングネットワークによって、SUPIの正確性に関する追加の保証が達成される。
11. SEAFは、N1メッセージでEAP SuccessメッセージをUEに送信するものとする。このメッセージには、ngKSIおよびABBAパラメータも含まれるものとする。SEAFは、Annex A.7.1に定義されているABBAパラメータを設定するものとする。
NOTE 4: ステップ11は、NAS Security Mode CommandまたはAuthentication Resultである可能性がある。
NOTE 5: ABBAパラメータは、後で導入されてもよいセキュリティ機能のビッドダウン保護（bidding down protection）を有効にするために含まれている。
Nausf_UEAuthentication_Authenticate Responseメッセージで受信したキーは、本文書の6.2項のキー階層の意味におけるアンカーキー、KSEAFになるものとする。その後、SEAFは、Annex A.7に従って、KSEAF、ABBAパラメータおよびSUPIから、KAMFを導出し、AMFに送信するものとする。EAP-Successメッセージを受信した場合、UEは、RFC 5448およびAnnex Fに記載されているように、CK'およびIK'からEMSKを導出する。MEは、EMSKの最上位256ビットをKAUSFとして使用し、その後、AUSFと同じ方法でKSEAFを計算する。UEは、Annex A.7に従って、KSEAF、ABBAパラメータ、およびSUPIからKAMFを導出するものとする。
NOTE 6: 実装オプションとして、UEは、EMSKの計算を可能にするEAPメッセージを受信した後、ステップ11で説明されているように一時的なセキュリティコンテキストを作成する。UEは、EAP Successを受信した場合、この一時的なセキュリティコンテキストを部分的なセキュリティコンテキストに変換する。EAP認証が失敗した場合、UEは一時的なセキュリティコンテキストを削除する。
正常に検証されたEAP-Response/AKA'-Challengeメッセージを受信したときにAUSFが実行する更なる手順については、本文書の6.1.4項に記載されている。
EAP-Response/AKA'-Challengeメッセージが正常に検証されなかった場合、その後のAUSFの動作はホームネットワークのポリシーに従って決定される。
AUSFとSEAFが認証に成功したと判断した場合、SEAFはngKSIとKAMFをAMFに提供する。
6.1.3.2 5G AKAの認証手順
6.1.3.2.0 5G AKA
5G AKAは、ホームネットワークに、visitedネットワークからのUEの認証に成功した証明を提供することで、EPS AKA [10]を強化する。証明は、visitedネットワークからAuthentication Confirmationメッセージで送信される。
5G AKAの使用の選択については、本文書の6.1.2項に記載されている。
NOTE 1: 5G AKAは、複数の5G AVの要求をサポートしておらず、SEAFも将来の使用のためにホームネットワークから5G AVをプリフェッチ（pre-fetching）していない。
図6.1.3.2-1:5G AKAの認証手順 (本出願の図12を参照)
5G AKAの認証手順は次のように動作する。また、図6.1.3.2-1参照(本出願の図12を参照):
1. 各Nudm_Authenticate_Get Requestに対して、UDM/ARPFは5G HE AVを作成するものとする。UDM/ARPFは、TS 33.102 [9] で定義されているように、Authentication Management Field (AMF) separation bitが「1」に設定されたAVを生成することによってこれを行う。次に、UDM/ARPFは、KAUSF (Annex A.2による)を導出し、XRES*(Annex A.4による)を計算する。最後に、UDM/ARPFは、RAND、AUTN、XRES*、およびKAUSFから5G HE AVを作成するものとする。
2. その後、UDMは、5G HE AVがNudm_UEAuthentication_Get Responseで5G AKAに使用されることを示すとともに、5G HE AVをAUSFに返すものとする。SUCIがNudm_UEAuthentication_Get Requestに含まれていた場合、UDMはSIDFによるSUCIの秘匿解除後に、SUPIをNudm_UEAuthentication_Get Responseに含める。サブスクライバーがAKMAサブスクリプションを持っている場合、UDMはNudm_UEAuthentication_Get ResponseにAKMA表示（AKMA indication）を含める。
3. AUSFは、受信したSUCIまたはSUPIと共にXRES*を一時的に保存するものとする。
4. その後、AUSFは、XRES*からHXRES*を計算し（Annex A.5に応じて）、KAUSFからKSEAFを計算し(Annex A .6に応じて)、XRES*をHXRES*に、KAUSFを5G HE AVのKSEAFに置き換えることによって、UDM/ARPFから受信した5G HE AVから5G AVを生成するものとする。
5. その後、AUSFはKSEAFを削除し、Nausf_UEAuthentication_Authenticate Responseで5G SE AV(RAND、AUTN、HXRES*)をSEAFに返すものとする。
6. SEAFは、NASメッセージAuthentication RequestでRAND、AUTNをUEに送信するものとする。このメッセージには、UEとAMFがKAMFを識別するために使用するngKSIと、認証が成功した場合に作成される部分的なネイティブセキュリティコンテキストも含まれるものとする。このメッセージには、ABBAパラメータも含まれるものとする。SEAFは、Annex A.7.1に定義されたABBAパラメータを設定するものとする。認証手順中に新しいサービングネットワークへのXnハンドオーバーが正常に完了した場合、AMFは、Authentication Requestメッセージに、Nausf_UEAuthentication_Authenticate Requestメッセージで送信されたSN nameを含めるものとする。MEは、NASメッセージAuthentication Requestで受信したRANDおよびAUTNをUSIMに転送するものとする。
NOTE 2:ABBAパラメータは、セキュリティ機能のビッドダウン保護を有効にするために含まれている。
7. USIMは、RANDとAUTNを受信すると、TS 33.102 [9]に記述されているようにAUTNを受け付けられるかどうかをチェックすることで、受信した値の鮮度を検証する。その場合、USIMは応答RESを計算する。USIMはRES、CK、IKをMEに返すものとする。USIMがTS 33.102 [9] に記述されているように、変換関数c3を使用してCKとIKからKc(すなわち、GPRS Kc)を計算し、MEに送信する場合、MEはそのようなGPRS Kcを無視し、USIMまたはMEにGPRS Kcを保存しないものとする。その後、MEは、Annex A.4に従ってRESからRES*を計算するものとする。MEは、A.2項に従ってCK||IKからKAUSFを計算するものとする。MEは、A.6項に従ってKAUSFからKSEAFを計算するものとする。5GにアクセスするMEは、認証中にAUTNのAMFフィールドの「separation bit」が1に設定されていることを確認するものとする。「separation bit」はAUTNのAMFフィールドのビット0である。UEがauthentication requestメッセージでSN nameを受信した場合、UEはそのSN nameを使用してRESとKAUSFを計算する。
NOTE 3:AUTNのAMFフィールドのこのseparation bitは、TS 33.102 [9]、Annex Fで説明されているように、オペレータ固有の目的には使用できない。
8. UEは、NASメッセージAuthentication ResponseでRES*をSEAFに返すものとする。
9. その後、SEAFはAnnex A.5に従ってRES*からHRES*を計算し、SEAFはHRES*とHXRES*を比較する。これらが一致する場合、SEAFはサービングネットワークの観点から認証が成功したとみなす。一致しない場合、SEAFは6.1.3.2.2項に記載されているように処理を進める。UEに到達せず、RES*がSEAFによって受信されない場合、SEAFは認証失敗と見なし、AUSFに失敗を示す。
10. SEAFは、UEから受信したRES*をNausf_UEAuthentication_Authenticate RequestメッセージでAUSFに送信する。
11. AUSFは、認証確認（authentication confirmation）として、RES*を含むNausf_UEAuthentication_Authenticate Requestメッセージを受信した場合、5G AVが満了したかどうかを確認してもよい。5G AVが満了した場合、AUSFはホームネットワークの観点から認証が失敗したと見なしてもよい。認証が成功すると、AUSFはKAUSFを保存するものとする。AUSFは、受信したRES*と保存されたXRES*を比較するものとする。RES*とXRES*が等しい場合、AUSFはホームネットワークの観点から認証が成功したとみなすものとする。AUSFは、UDMに認証結果を通知するものとする(認証確認とのリンク（linking with the authentication confirmation）については、本文書の6.1.4項を参照)。
12. AUSFは、ホームネットワークの観点から、認証が成功したかどうかをNausf_UEAuthentication_Authenticate ResponseでSEAFに示すものとする。認証が成功した場合、KSEAFはNausf_UEAuthentication_Authenticate ResponseでSEAFに送信されるものとする。AUSFがauthentication requestでSEAFからSUCIを受信した場合(本文書の6.1.2項を参照)であって、認証が成功した場合、AUSFはNausf_UEAuthentication_Authenticate ResponseメッセージにSUPIも含めるものとする。
認証が成功した場合、Nausf_UEAuthentication_Authenticate Responseメッセージで受信したキーKSEAFは、本文書の6.2項で指定されているキー階層の意味においてアンカーキーになるものとする。その後、SEAFは、KSEAF、ABBAパラメータ、およびSUPIから、Annex A.7に従ってKAMFを導出するものとする。SEAFは、ngKSIとKAMFをAMFに提供するものとする。
SUCIがこの認証に使用された場合、SEAFは、KSEAFとSUPIを含むNausf_UEAuthentication_Authenticate Responseメッセージを受信した後に、AMFにngKSIとKAMFのみを提供するものとする;SUPIがサービスネットワークに認識されるまで、UEに通信サービスは提供されない。
認証手順後にAUSFによって行われるその後の手順は、本文書の6.1.4項に記載されている。
6.1.3 認証手順
6.1.3.1 EAP-AKA'の認証手順
EAP-AKA'はRFC5448[12]で指定されている。EAP-AKA'の3GPP 5Gプロファイルは、標準のAnnex Fに記載されている。
Editor’Note: RFC 5448への参照は、RFCになるときに[67]で参照されているインターネットドラフトによって置き換えられる予定である。
EAP-AKA'の使用の選択については、本文書の6.1.2項に記載されている。
図6.1.3.1-1: EAP-AKA'の認証手順(本出願の図13を参照のこと。)
EAP-AKA'の認証手順は次のように動作する。また、図6.1.3.1-1参照(本出願の図13参照):
1. UDM/ARPFは、はじめに、TS33.102[9]で定義されているように、Authentication Management Field (AMF) separation bit = 1の認証ベクトルを生成するものとする。次に、UDM/ARPFは、標準のAnnex Aに従ってCK'とIK'を計算し、CKとIKをCK'とIK'で置き換えるものとする。
2. その後、UDMは、この変換された認証ベクトルAV'(RAND、AUTN、XRES、CK'、IK')を、Nudm_UEAuthentication_Get Responseメッセージを使用して、AV'がEAP-AKA'に使用されることを示すとともに、Nudm_UEAuthentication_Get Requestを受信したAUSFに送信するものとする。
NOTE: 前項で説明したAUSFとUDM/ARPFの間のNudm_UEAuthentication_Get RequestメッセージとNudm_UEAuthentication_Get Responseメッセージの交換は、<network name>の値であるkey derivationへの入力パラメータを除いて、TS 33.402 [11]、6.2項、ステップ10で説明したEAP-AKA'を使用した信頼できるアクセスの場合と同じである。「network name」は、RFC 5448[12]の概念であり;EAP-AKA'のAT_KDF_INPUT attributeで伝達される。<network name>パラメータの値は、RFC 5448 [12]では定義されておらず、3GPP仕様で定義されている。EPSの場合はTS 24.302 [71]で 「access network identity」と定義され、5Gの場合は本文書の6.1.1.4項で「serving network name」 と定義されている。
SUCIがNudm_UEAuthentication_Get Requestに含まれていた場合、UDMはNudm_UEAuthentication_Get ResponseにSUPIを含める。
その後、AUSFとUEは、AUSFがEAP-Successを送信する準備が整うまで、RFC 5448 [12]に記載されている手順を実行する。
サブスクライバーがAKMAサブスクリプションを持っている場合、UDMはNudm_UEAuthentication_Get ResponseにAKMA indicationを含めるものとする。
3. AUSFは、EAP-Request/AKA'-ChallengeメッセージをNausf_UEAuthentication_Authenticate ResponseメッセージでSEAFに送信するものとする。
4. SEAFは、EAP-Request/AKA'-ChallengeメッセージをNASメッセージAuthentication RequestメッセージでUEに透過的に転送するものとする。MEは、EAP-Request/AKA'-Challengeメッセージで受信したRANDおよびAUTNをUSIMに転送するものとする。このメッセージには、ngKSIおよびABBAパラメータを含めるものとする。実際、SEAFは、すべてのEAP-Authentication requestメッセージにngKSIおよびABBAパラメータを含めるものとする。ngKSIは、認証が成功した場合に作成される部分的なネイティブセキュリティコンテキストを識別するために、UEおよびAMFによって使用される。SEAFは、Annex A.7.1に定義されているABBAパラメータを設定するものとする。EAP認証中、SEAFがUEに送信するngKSIとABBAパラメータの値は変更されないものとする。認証手順中に新しいサービングネットワークへのXnハンドオーバーが正常に完了した場合、AMFはAuthentication Requestメッセージに、現在のサービングネットワークに対応するSN nameを含めるものとする。SEAFは、認証手順が進行中の間に新しいサービングネットワークへのXnハンドオーバーが正常に行われたと判定すると、AMFは、現在の進行中の認証手順を中止し、新しい認証手順を開始し、新しい認証手順において新しいサービングネットワーク名を使用する。
NOTE1: SEAFは、Nausf_UEAuthentication_Authenticate Responseメッセージに基づいて認証方式のタイプを評価することにより、使用される認証方式がEAP方式であることを理解する必要がある。
5. USIMは、RANDとAUTNを受信すると、TS 33.102 [9]に記載されているようにAUTNを受け入れることができるかどうかを確認することによって、AV'の鮮度を検証するものとする。その場合、USIMは応答RESを計算する。USIMはRES、CK、IKをMEに返すものとする。USIMがTS 33.102 [9] に記載されているように、変換関数（conversion function）c3を使用してCKとIKからKc(すなわち、GPRS Kc)を計算してMEに送信する場合、MEはそのようなGPRS Kcを無視し、USIMまたはMEにGPRS Kcを保存しないものとする。MEは、Annex A.3に従ってCK'とIK'を導出するものとする。UEがauthentication requestメッセージでSN nameを受信すると、UEはそのSN nameを使用してRESとKAUSFを計算するものとする。
USIMでAUTNの検証が失敗した場合、USIMとMEは6.1.3.3項に記載されているとおりに処理を進めるものとする。
6. UEは、EAP-Response/AKA'-ChallengeメッセージをNASメッセージAuth-RespメッセージでSEAFに送信するものとする。
7. SEAFは、EAP-Response/AKA'-ChallengeメッセージをNausf_UEAuthentication_Authenticate Requestメッセージで透過的にAUSFに転送するものとする。
8. AUSFは、メッセージを検証するものとし、AUSFがこのメッセージの検証に成功した場合は、次のように続行するものとし、それ以外の場合はSEAFにエラーを返すものとする。AUSFは、UDMに認証結果を通知するものとする(リンク認証確認の詳細については、本文書の6.1.4項を参照)。
9. AUSFとUEは、SEAFを介してEAP-Request/AKA'-NotificationおよびEAP-Response/AKA'-Notificationメッセージを交換してもよい。SEAFは、これらのメッセージを透過的に転送するものとする。
NOTE2: RFC 3748 [27] に記載されているEAP NotificationとRFC 4187 [21]に記載されているEAP-AKA Notificationは、EAP-AKA交換でいつでも使用され得る。これらの通知は、保護された結果の表示や、EAPサーバが受信したEAP-AKA応答でエラーを検出した場合などに使用できる。
10. AUSFは、RFC 5448 [12]およびAnnex Fに記載されているように、CK'とIK'からEMSKを導出する。AUSFは、EMSKの最上位256ビットをKAUSFとして使用し、次にA.6.に記載されているように、KAUSFからKSEAFを計算する。AUSFは、EAP SuccessメッセージをNausf_UEAuthentication_Authenticate Response内でSEAFに送信し、SEAFはそれをUEに透過的に転送するものとする。Nausf_UEAuthentication_Authenticate Responseメッセージは、KSEAFを含む。認証が開始されたときにAUSFがSEAFからSUCIを受信した場合 (本文書の6.1.2項を参照)、AUSFはNausf_UEAuthentication_Authenticate ResponseメッセージにSUPIも含めるものとする。
NOTE 3: 合法的な傍受のためには、AUSFがSEAFにSUPIを送ることは必要であるが十分ではない。KSEAFからのKAMFのkey derivationへの入力パラメータとしてSUPIを含めることにより、ホームネットワークとUE側の両方からサービングネットワークによって、SUPIの正確性に関する追加の保証が達成される。
11. SEAFは、N1メッセージでEAP SuccessメッセージをUEに送信するものとする。このメッセージには、ngKSIおよびABBAパラメータも含まれるものとする。SEAFは、Annex A.7.1に定義されているABBAパラメータを設定するものとする。
NOTE 4: ステップ11は、NAS Security Mode CommandまたはAuthentication Resultである可能性がある。
NOTE 5: ABBAパラメータは、後で導入されてもよいセキュリティ機能のビッドダウン保護を有効にするために含まれている。
Nausf_UEAuthentication_Authenticate Responseメッセージで受信したキーは、本文書の6.2項のキー階層の意味におけるアンカーキー、KSEAFになるものとする。その後、SEAFは、Annex A.7に従って、KSEAF、ABBAパラメータおよびSUPIから、KAMFを導出し、AMFに送信するものとする。EAP-Successメッセージを受信すると、UEは、RFC 5448およびAnnex Fに記載されているように、CK'およびIK'からEMSKを導出する。MEは、EMSKの最上位256ビットをKAUSFとして使用し、その後、AUSFと同じ方法でKSEAFを計算する。UEは、Annex A.7に従って、KSEAF、ABBAパラメータ、およびSUPIからKAMFを導出するものとする。
NOTE 6: 実装オプションとして、UEは、EMSKの計算を可能にするEAPメッセージを受信した後、ステップ11で説明されているように一時的なセキュリティコンテキストを作成する。UEは、EAP Successを受信した場合、この一時的なセキュリティコンテキストを部分的なセキュリティコンテキストに変換する。EAP認証が失敗した場合、UEは一時的なセキュリティコンテキストを削除する。
正常に検証されたEAP-Response/AKA'-Challengeメッセージを受信したときにAUSFが実行する更なる手順については、本文書の6.1.4項に記載されている。
EAP-Response/AKA'-Challengeメッセージが正常に検証されなかった場合、その後のAUSFの動作はホームネットワークのポリシーに従って決定される。
AUSFとSEAFが認証に成功したと判断した場合、SEAFはngKSIとKAMFをAMFに提供する。
6.1.3.2 5G AKAの認証手順
6.1.3.2.0 5G AKA
5G AKAは、ホームネットワークに、visitedネットワークからのUEの認証に成功した証明を提供することで、EPS AKA [10]を強化する。証明は、visitedネットワークからAuthentication Confirmationメッセージで送信される。
5G AKAの使用の選択については、本文書の6.1.2項に記載されている。
NOTE 1: 5G AKAは、複数の5G AVの要求をサポートしておらず、SEAFも将来の使用のためにホームネットワークから5G AVをプリフェッチしていない。
図6.1.3.2-1:5G AKAの認証手順 (本出願の図14を参照)
5G AKAの認証手順は次のように動作する。また、図6.1.3.2-1参照(本出願の図14を参照):
1. 各Nudm_Authenticate_Get Requestに対して、UDM/ARPFは5G HE AVを作成するものとする。UDM/ARPFは、TS 33.102 [9] で定義されているように、Authentication Management Field (AMF) separation bitが「1」に設定されたAVを生成することによってこれを行う。次に、UDM/ARPFは、KAUSF (Annex A.2による)を導出し、XRES*(Annex A.4による)を計算する。最後に、UDM/ARPFは、RAND、AUTN、XRES*、およびKAUSFから5G HE AVを作成するものとする。
2. その後、UDMは、5G HE AVがNudm_UEAuthentication_Get Responseで5G AKAに使用されることを示すとともに、5G HE AVをAUSFに返すものとする。SUCIがNudm_UEAuthentication_Get Requestに含まれていた場合、UDMはSIDFによるSUCIの秘匿解除後に、SUPIをNudm_UEAuthentication_Get Responseに含める。サブスクライバーがAKMAサブスクリプションを持っている場合、UDMはNudm_UEAuthentication_Get ResponseにAKMA表示（AKMA indication）を含める。
3. AUSFは、受信したSUCIまたはSUPIと共にXRES*を一時的に保存するものとする。
4. その後、AUSFは、XRES*からHXRES*を計算し（Annex A.5に応じて）、KAUSFからKSEAFを計算し(Annex A .6に応じて)、XRES*をHXRES*に、KAUSFを5G HE AVのKSEAFに置き換えることによって、UDM/ARPFから受信した5G HE AVから5G AVを生成するものとする。
5. その後、AUSFはKSEAFを削除し、Nausf_UEAuthentication_Authenticate Responseで5G SE AV(RAND、AUTN、HXRES*)をSEAFに返すものとする。
6. SEAFは、NASメッセージAuthentication RequestでRAND、AUTNをUEに送信するものとする。このメッセージには、UEとAMFがKAMFを識別するために使用するngKSIと、認証が成功した場合に作成される部分的なネイティブセキュリティコンテキストも含まれるものとする。このメッセージには、ABBAパラメータも含まれるものとする。SEAFは、Annex A.7.1に定義されたABBAパラメータを設定するものとする。認証手順中に新しいサービングネットワークへのXnハンドオーバーが正常に完了した場合、AMFはAuthentication Requestメッセージに、現在のサービングネットワークに対応するSN nameを含めるものとする。MEは、NAS message Authentication Requestで受信したRAND及びAUTNをUSIMへ転送するものとする。SEAFは、認証手順が進行中の間に新しいサービングネットワークへのXnハンドオーバーが正常に行われたと判定すると、AMFは、現在の進行中の認証手順を中止し、新しい認証手順を開始し、新しい認証手順において新しいサービングネットワーク名を使用する。
NOTE 2:ABBAパラメータは、セキュリティ機能のビッドダウン保護を有効にするために含まれている。
7. USIMは、RANDとAUTNを受信すると、TS 33.102 [9]に記述されているようにAUTNを受け付けられるかどうかをチェックすることで、受信した値の鮮度を検証する。その場合、USIMは応答RESを計算する。USIMはRES、CK、IKをMEに返すものとする。USIMがTS 33.102 [9] に記述されているように、変換関数c3を使用してCKとIKからKc(すなわち、GPRS Kc)を計算し、MEに送信する場合、MEはそのようなGPRS Kcを無視し、USIMまたはMEにGPRS Kcを保存しないものとする。その後、MEは、Annex A.4に従ってRESからRES*を計算するものとする。MEは、A.2項に従ってCK||IKからKAUSFを計算するものとする。MEは、A.6項に従ってKAUSFからKSEAFを計算するものとする。5GにアクセスするMEは、認証中にAUTNのAMFフィールドの「separation bit」が1に設定されていることを確認するものとする。「separation bit」はAUTNのAMFフィールドのビット0である。UEがauthentication requestメッセージでSN nameを受信した場合、UEはそのSN nameを使用してRESとKAUSFを計算する。
NOTE 3:AUTNのAMFフィールドのこのseparation bitは、TS 33.102 [9]、Annex Fで説明されているように、オペレータ固有の目的には使用できない。
8. UEは、NASメッセージAuthentication ResponseでRES*をSEAFに返すものとする。
9. その後、SEAFはAnnex A.5に従ってRES*からHRES*を計算し、SEAFはHRES*とHXRES*を比較する。これらが一致する場合、SEAFはサービングネットワークの観点から認証が成功したとみなす。一致しない場合、SEAFは6.1.3.2.2項に記載されているように処理を進める。UEに到達せず、RES*がSEAFによって受信されない場合、SEAFは認証失敗と見なし、AUSFに失敗を示す。
10. SEAFは、UEから受信したRES*をNausf_UEAuthentication_Authenticate RequestメッセージでAUSFに送信する。
11. AUSFは、認証確認（authentication confirmation）として、RES*を含むNausf_UEAuthentication_Authenticate Requestメッセージを受信した場合、5G AVが満了したかどうかを確認してもよい。5G AVが満了した場合、AUSFはホームネットワークの観点から認証が失敗したと見なしてもよい。認証が成功すると、AUSFはKAUSFを保存するものとする。AUSFは、受信したRES*と保存されたXRES*を比較するものとする。RES*とXRES*が等しい場合、AUSFはホームネットワークの観点から認証が成功したとみなすものとする。AUSFは、UDMに認証結果を通知するものとする(認証確認とのリンクについては、本文書の6.1.4項を参照)。
12. AUSFは、ホームネットワークの観点から、認証が成功したかどうかをNausf_UEAuthentication_Authenticate ResponseでSEAFに示すものとする。認証が成功した場合、KSEAFはNausf_UEAuthentication_Authenticate ResponseでSEAFに送信されるものとする。AUSFがauthentication requestでSEAFからSUCIを受信した場合(本文書の6.1.2項を参照)であって、認証が成功した場合、AUSFはNausf_UEAuthentication_Authenticate ResponseメッセージにSUPIも含めるものとする。
認証が成功した場合、Nausf_UEAuthentication_Authenticate Responseメッセージで受信したキーKSEAFは、本文書の6.2項で指定されているキー階層の意味においてアンカーキーになるものとする。その後、SEAFは、KSEAF、ABBAパラメータ、およびSUPIから、Annex A.7に従ってKAMFを導出するものとする。SEAFは、ngKSIとKAMFをAMFに提供するものとする。
SUCIがこの認証に使用された場合、SEAFは、KSEAFとSUPIを含むNausf_UEAuthentication_Authenticate Responseメッセージを受信した後に、AMFにngKSIとKAMFのみを提供するものとする;SUPIがサービスネットワークに認識されるまで、UEに通信サービスは提供されない。
認証手順後にAUSFによって行われるその後の手順は、本文書の6.1.4項に記載されている。
6.1.3.1 EAP-AKA'の認証手順
EAP-AKA'はRFC5448[12]で指定されている。EAP-AKA'の3GPP 5Gプロファイルは、標準のAnnex Fに記載されている。
Editor’Note: RFC 5448への参照は、RFCになるときに[67]で参照されているインターネットドラフトによって置き換えられる予定である。
EAP-AKA'の使用の選択については、本文書の6.1.2項に記載されている。
図6.1.3.1-1: EAP-AKA'の認証手順(本出願の図11を参照のこと。)
EAP-AKA'の認証手順は次のように動作する。また、図6.1.3.1-1参照(本出願の図11参照):
1. UDM/ARPFは、はじめに、TS33.102[9]で定義されているように、Authentication Management Field (AMF) separation bit = 1の認証ベクトルを生成するものとする。次に、UDM/ARPFは、標準のAnnex Aに従ってCK'とIK'を計算し、CKとIKをCK'とIK'で置き換えるものとする。
2. その後、UDMは、この変換された認証ベクトルAV'(RAND、AUTN、XRES、CK'、IK')を、Nudm_UEAuthentication_Get Responseメッセージを使用して、AV'がEAP-AKA'に使用されることを示すとともに、Nudm_UEAuthentication_Get Requestを受信したAUSFに送信するものとする。
NOTE: 前項で説明したAUSFとUDM/ARPFの間のNudm_UEAuthentication_Get RequestメッセージとNudm_UEAuthentication_Get Responseメッセージの交換は、<network name>の値であるkey derivationへの入力パラメータを除いて、TS 33.402 [11]、6.2項、ステップ10で説明したEAP-AKA'を使用した信頼できるアクセスの場合と同じである。「network name」は、RFC 5448[12]の概念であり;EAP-AKA'のAT_KDF_INPUT attributeで伝達される。<network name>パラメータの値は、RFC 5448 [12]では定義されておらず、3GPP仕様で定義されている。EPSの場合はTS 24.302 [71]で 「access network identity」と定義され、5Gの場合は本文書の6.1.1.4項で「serving network name」 と定義されている。
SUCIがNudm_UEAuthentication_Get Requestに含まれていた場合、UDMはNudm_UEAuthentication_Get ResponseにSUPIを含める。
その後、AUSFとUEは、AUSFがEAP-Successを送信する準備が整うまで、RFC 5448 [12]に記載されている手順を実行する。
サブスクライバーがAKMAサブスクリプションを持っている場合、UDMはNudm_UEAuthentication_Get ResponseにAKMA indicationを含めるものとする。
3. AUSFは、EAP-Request/AKA'-ChallengeメッセージをNausf_UEAuthentication_Authenticate ResponseメッセージでSEAFに送信するものとする。
4. SEAFは、EAP-Request/AKA'-ChallengeメッセージをNASメッセージAuthentication RequestメッセージでUEに透過的に転送するものとする。MEは、EAP-Request/AKA'-Challengeメッセージで受信したRANDおよびAUTNをUSIMに転送するものとする。このメッセージには、ngKSIおよびABBAパラメータを含めるものとする。実際、SEAFは、すべてのEAP-Authentication requestメッセージにngKSIおよびABBAパラメータを含めるものとする。ngKSIは、認証が成功した場合に作成される部分的なネイティブセキュリティコンテキストを識別するために、UEおよびAMFによって使用される。SEAFは、Annex A.7.1に定義されているABBAパラメータを設定するものとする。EAP認証中、SEAFがUEに送信するngKSIとABBAパラメータの値は変更されないものとする。認証手順中に新しいサービングネットワークへのXnハンドオーバーが正常に完了した場合、AMFはNausf_UEAuthentication_Authenticate Requestメッセージで送信されたSN nameをAuthentication Requestメッセージに含めるものとする。
NOTE1: SEAFは、Nausf_UEAuthentication_Authenticate Responseメッセージに基づいて認証方式のタイプを評価することにより、使用される認証方式がEAP方式であることを理解する必要がある。
5. USIMは、RANDとAUTNを受信すると、TS 33.102 [9]に記載されているようにAUTNを受け入れることができるかどうかを確認することによって、AV'の鮮度（freshness）を検証するものとする。その場合、USIMは応答RESを計算する。USIMはRES、CK、IKをMEに返すものとする。USIMがTS 33.102 [9] に記載されているように、変換関数（conversion function）c3を使用してCKとIKからKc(すなわち、GPRS Kc)を計算してMEに送信する場合、MEはそのようなGPRS Kcを無視し、USIMまたはMEにGPRS Kcを保存しないものとする。MEは、Annex A.3に従ってCK'とIK'を導出するものとする。UEがauthentication requestメッセージでSN nameを受信した場合、UEはそのSN nameを使用してRESとKAUSFを計算するものとする。
USIMでAUTNの検証が失敗した場合、USIMとMEは6.1.3.3項に記載されているとおりに処理を進めるものとする。
6. UEは、EAP-Response/AKA'-ChallengeメッセージをNASメッセージAuth-RespメッセージでSEAFに送信するものとする。
7. SEAFは、EAP-Response/AKA'-ChallengeメッセージをNausf_UEAuthentication_Authenticate Requestメッセージで透過的にAUSFに転送するものとする。
8. AUSFは、メッセージを検証するものとし、AUSFがこのメッセージの検証に成功した場合は、次のように続行するものとし、それ以外の場合はSEAFにエラーを返すものとする。AUSFは、UDMに認証結果を通知するものとする(リンク認証確認（linking authentication confirmation）の詳細については、本文書の6.1.4項を参照)。
9. AUSFとUEは、SEAFを介してEAP-Request/AKA'-NotificationおよびEAP-Response/AKA'-Notificationメッセージを交換してもよい。SEAFは、これらのメッセージを透過的に転送するものとする。
NOTE2: RFC 3748 [27] に記載されているEAP NotificationとRFC 4187 [21]に記載されているEAP-AKA Notificationは、EAP-AKA交換でいつでも使用され得る。これらの通知は、保護された結果の表示や、EAPサーバが受信したEAP-AKA応答（response）でエラーを検出した場合などに使用できる。
10. AUSFは、RFC 5448 [12]およびAnnex Fに記載されているように、CK'とIK'からEMSKを導出する。AUSFは、EMSKの最上位256ビットをKAUSFとして使用し、次にA.6.項に記載されているように、KAUSFからKSEAFを計算する。AUSFは、EAP SuccessメッセージをNausf_UEAuthentication_Authenticate Response内でSEAFに送信し、SEAFはそれをUEに透過的に転送するものとする。Nausf_UEAuthentication_Authenticate Responseメッセージは、KSEAFを含む。認証が開始されたときにAUSFがSEAFからSUCIを受信した場合 (本文書の6.1.2項を参照)、AUSFはNausf_UEAuthentication_Authenticate ResponseメッセージにSUPIも含めるものとする。
NOTE 3: 合法的な傍受のためには、AUSFがSEAFにSUPIを送ることは必要であるが十分ではない。KSEAFからのKAMFのkey derivationへの入力パラメータとしてSUPIを含めることにより、ホームネットワークとUE側の両方からサービングネットワークによって、SUPIの正確性に関する追加の保証が達成される。
11. SEAFは、N1メッセージでEAP SuccessメッセージをUEに送信するものとする。このメッセージには、ngKSIおよびABBAパラメータも含まれるものとする。SEAFは、Annex A.7.1に定義されているABBAパラメータを設定するものとする。
NOTE 4: ステップ11は、NAS Security Mode CommandまたはAuthentication Resultである可能性がある。
NOTE 5: ABBAパラメータは、後で導入されてもよいセキュリティ機能のビッドダウン保護（bidding down protection）を有効にするために含まれている。
Nausf_UEAuthentication_Authenticate Responseメッセージで受信したキーは、本文書の6.2項のキー階層の意味におけるアンカーキー、KSEAFになるものとする。その後、SEAFは、Annex A.7に従って、KSEAF、ABBAパラメータおよびSUPIから、KAMFを導出し、AMFに送信するものとする。EAP-Successメッセージを受信した場合、UEは、RFC 5448およびAnnex Fに記載されているように、CK'およびIK'からEMSKを導出する。MEは、EMSKの最上位256ビットをKAUSFとして使用し、その後、AUSFと同じ方法でKSEAFを計算する。UEは、Annex A.7に従って、KSEAF、ABBAパラメータ、およびSUPIからKAMFを導出するものとする。
NOTE 6: 実装オプションとして、UEは、EMSKの計算を可能にするEAPメッセージを受信した後、ステップ11で説明されているように一時的なセキュリティコンテキストを作成する。UEは、EAP Successを受信した場合、この一時的なセキュリティコンテキストを部分的なセキュリティコンテキストに変換する。EAP認証が失敗した場合、UEは一時的なセキュリティコンテキストを削除する。
正常に検証されたEAP-Response/AKA'-Challengeメッセージを受信したときにAUSFが実行する更なる手順については、本文書の6.1.4項に記載されている。
EAP-Response/AKA'-Challengeメッセージが正常に検証されなかった場合、その後のAUSFの動作はホームネットワークのポリシーに従って決定される。
AUSFとSEAFが認証に成功したと判断した場合、SEAFはngKSIとKAMFをAMFに提供する。
6.1.3.2 5G AKAの認証手順
6.1.3.2.0 5G AKA
5G AKAは、ホームネットワークに、visitedネットワークからのUEの認証に成功した証明を提供することで、EPS AKA [10]を強化する。証明は、visitedネットワークからAuthentication Confirmationメッセージで送信される。
5G AKAの使用の選択については、本文書の6.1.2項に記載されている。
NOTE 1: 5G AKAは、複数の5G AVの要求をサポートしておらず、SEAFも将来の使用のためにホームネットワークから5G AVをプリフェッチ（pre-fetching）していない。
図6.1.3.2-1:5G AKAの認証手順 (本出願の図12を参照)
5G AKAの認証手順は次のように動作する。また、図6.1.3.2-1参照(本出願の図12を参照):
1. 各Nudm_Authenticate_Get Requestに対して、UDM/ARPFは5G HE AVを作成するものとする。UDM/ARPFは、TS 33.102 [9] で定義されているように、Authentication Management Field (AMF) separation bitが「1」に設定されたAVを生成することによってこれを行う。次に、UDM/ARPFは、KAUSF (Annex A.2による)を導出し、XRES*(Annex A.4による)を計算する。最後に、UDM/ARPFは、RAND、AUTN、XRES*、およびKAUSFから5G HE AVを作成するものとする。
2. その後、UDMは、5G HE AVがNudm_UEAuthentication_Get Responseで5G AKAに使用されることを示すとともに、5G HE AVをAUSFに返すものとする。SUCIがNudm_UEAuthentication_Get Requestに含まれていた場合、UDMはSIDFによるSUCIの秘匿解除後に、SUPIをNudm_UEAuthentication_Get Responseに含める。サブスクライバーがAKMAサブスクリプションを持っている場合、UDMはNudm_UEAuthentication_Get ResponseにAKMA表示（AKMA indication）を含める。
3. AUSFは、受信したSUCIまたはSUPIと共にXRES*を一時的に保存するものとする。
4. その後、AUSFは、XRES*からHXRES*を計算し（Annex A.5に応じて）、KAUSFからKSEAFを計算し(Annex A .6に応じて)、XRES*をHXRES*に、KAUSFを5G HE AVのKSEAFに置き換えることによって、UDM/ARPFから受信した5G HE AVから5G AVを生成するものとする。
5. その後、AUSFはKSEAFを削除し、Nausf_UEAuthentication_Authenticate Responseで5G SE AV(RAND、AUTN、HXRES*)をSEAFに返すものとする。
6. SEAFは、NASメッセージAuthentication RequestでRAND、AUTNをUEに送信するものとする。このメッセージには、UEとAMFがKAMFを識別するために使用するngKSIと、認証が成功した場合に作成される部分的なネイティブセキュリティコンテキストも含まれるものとする。このメッセージには、ABBAパラメータも含まれるものとする。SEAFは、Annex A.7.1に定義されたABBAパラメータを設定するものとする。認証手順中に新しいサービングネットワークへのXnハンドオーバーが正常に完了した場合、AMFは、Authentication Requestメッセージに、Nausf_UEAuthentication_Authenticate Requestメッセージで送信されたSN nameを含めるものとする。MEは、NASメッセージAuthentication Requestで受信したRANDおよびAUTNをUSIMに転送するものとする。
NOTE 2:ABBAパラメータは、セキュリティ機能のビッドダウン保護を有効にするために含まれている。
7. USIMは、RANDとAUTNを受信すると、TS 33.102 [9]に記述されているようにAUTNを受け付けられるかどうかをチェックすることで、受信した値の鮮度を検証する。その場合、USIMは応答RESを計算する。USIMはRES、CK、IKをMEに返すものとする。USIMがTS 33.102 [9] に記述されているように、変換関数c3を使用してCKとIKからKc(すなわち、GPRS Kc)を計算し、MEに送信する場合、MEはそのようなGPRS Kcを無視し、USIMまたはMEにGPRS Kcを保存しないものとする。その後、MEは、Annex A.4に従ってRESからRES*を計算するものとする。MEは、A.2項に従ってCK||IKからKAUSFを計算するものとする。MEは、A.6項に従ってKAUSFからKSEAFを計算するものとする。5GにアクセスするMEは、認証中にAUTNのAMFフィールドの「separation bit」が1に設定されていることを確認するものとする。「separation bit」はAUTNのAMFフィールドのビット0である。UEがauthentication requestメッセージでSN nameを受信した場合、UEはそのSN nameを使用してRESとKAUSFを計算する。
NOTE 3:AUTNのAMFフィールドのこのseparation bitは、TS 33.102 [9]、Annex Fで説明されているように、オペレータ固有の目的には使用できない。
8. UEは、NASメッセージAuthentication ResponseでRES*をSEAFに返すものとする。
9. その後、SEAFはAnnex A.5に従ってRES*からHRES*を計算し、SEAFはHRES*とHXRES*を比較する。これらが一致する場合、SEAFはサービングネットワークの観点から認証が成功したとみなす。一致しない場合、SEAFは6.1.3.2.2項に記載されているように処理を進める。UEに到達せず、RES*がSEAFによって受信されない場合、SEAFは認証失敗と見なし、AUSFに失敗を示す。
10. SEAFは、UEから受信したRES*をNausf_UEAuthentication_Authenticate RequestメッセージでAUSFに送信する。
11. AUSFは、認証確認（authentication confirmation）として、RES*を含むNausf_UEAuthentication_Authenticate Requestメッセージを受信した場合、5G AVが満了したかどうかを確認してもよい。5G AVが満了した場合、AUSFはホームネットワークの観点から認証が失敗したと見なしてもよい。認証が成功すると、AUSFはKAUSFを保存するものとする。AUSFは、受信したRES*と保存されたXRES*を比較するものとする。RES*とXRES*が等しい場合、AUSFはホームネットワークの観点から認証が成功したとみなすものとする。AUSFは、UDMに認証結果を通知するものとする(認証確認とのリンク（linking with the authentication confirmation）については、本文書の6.1.4項を参照)。
12. AUSFは、ホームネットワークの観点から、認証が成功したかどうかをNausf_UEAuthentication_Authenticate ResponseでSEAFに示すものとする。認証が成功した場合、KSEAFはNausf_UEAuthentication_Authenticate ResponseでSEAFに送信されるものとする。AUSFがauthentication requestでSEAFからSUCIを受信した場合(本文書の6.1.2項を参照)であって、認証が成功した場合、AUSFはNausf_UEAuthentication_Authenticate ResponseメッセージにSUPIも含めるものとする。
認証が成功した場合、Nausf_UEAuthentication_Authenticate Responseメッセージで受信したキーKSEAFは、本文書の6.2項で指定されているキー階層の意味においてアンカーキーになるものとする。その後、SEAFは、KSEAF、ABBAパラメータ、およびSUPIから、Annex A.7に従ってKAMFを導出するものとする。SEAFは、ngKSIとKAMFをAMFに提供するものとする。
SUCIがこの認証に使用された場合、SEAFは、KSEAFとSUPIを含むNausf_UEAuthentication_Authenticate Responseメッセージを受信した後に、AMFにngKSIとKAMFのみを提供するものとする;SUPIがサービスネットワークに認識されるまで、UEに通信サービスは提供されない。
認証手順後にAUSFによって行われるその後の手順は、本文書の6.1.4項に記載されている。
6.1.3 認証手順
6.1.3.1 EAP-AKA'の認証手順
EAP-AKA'はRFC5448[12]で指定されている。EAP-AKA'の3GPP 5Gプロファイルは、標準のAnnex Fに記載されている。
Editor’Note: RFC 5448への参照は、RFCになるときに[67]で参照されているインターネットドラフトによって置き換えられる予定である。
EAP-AKA'の使用の選択については、本文書の6.1.2項に記載されている。
図6.1.3.1-1: EAP-AKA'の認証手順(本出願の図13を参照のこと。)
EAP-AKA'の認証手順は次のように動作する。また、図6.1.3.1-1参照(本出願の図13参照):
1. UDM/ARPFは、はじめに、TS33.102[9]で定義されているように、Authentication Management Field (AMF) separation bit = 1の認証ベクトルを生成するものとする。次に、UDM/ARPFは、標準のAnnex Aに従ってCK'とIK'を計算し、CKとIKをCK'とIK'で置き換えるものとする。
2. その後、UDMは、この変換された認証ベクトルAV'(RAND、AUTN、XRES、CK'、IK')を、Nudm_UEAuthentication_Get Responseメッセージを使用して、AV'がEAP-AKA'に使用されることを示すとともに、Nudm_UEAuthentication_Get Requestを受信したAUSFに送信するものとする。
NOTE: 前項で説明したAUSFとUDM/ARPFの間のNudm_UEAuthentication_Get RequestメッセージとNudm_UEAuthentication_Get Responseメッセージの交換は、<network name>の値であるkey derivationへの入力パラメータを除いて、TS 33.402 [11]、6.2項、ステップ10で説明したEAP-AKA'を使用した信頼できるアクセスの場合と同じである。「network name」は、RFC 5448[12]の概念であり;EAP-AKA'のAT_KDF_INPUT attributeで伝達される。<network name>パラメータの値は、RFC 5448 [12]では定義されておらず、3GPP仕様で定義されている。EPSの場合はTS 24.302 [71]で 「access network identity」と定義され、5Gの場合は本文書の6.1.1.4項で「serving network name」 と定義されている。
SUCIがNudm_UEAuthentication_Get Requestに含まれていた場合、UDMはNudm_UEAuthentication_Get ResponseにSUPIを含める。
その後、AUSFとUEは、AUSFがEAP-Successを送信する準備が整うまで、RFC 5448 [12]に記載されている手順を実行する。
サブスクライバーがAKMAサブスクリプションを持っている場合、UDMはNudm_UEAuthentication_Get ResponseにAKMA indicationを含めるものとする。
3. AUSFは、EAP-Request/AKA'-ChallengeメッセージをNausf_UEAuthentication_Authenticate ResponseメッセージでSEAFに送信するものとする。
4. SEAFは、EAP-Request/AKA'-ChallengeメッセージをNASメッセージAuthentication RequestメッセージでUEに透過的に転送するものとする。MEは、EAP-Request/AKA'-Challengeメッセージで受信したRANDおよびAUTNをUSIMに転送するものとする。このメッセージには、ngKSIおよびABBAパラメータを含めるものとする。実際、SEAFは、すべてのEAP-Authentication requestメッセージにngKSIおよびABBAパラメータを含めるものとする。ngKSIは、認証が成功した場合に作成される部分的なネイティブセキュリティコンテキストを識別するために、UEおよびAMFによって使用される。SEAFは、Annex A.7.1に定義されているABBAパラメータを設定するものとする。EAP認証中、SEAFがUEに送信するngKSIとABBAパラメータの値は変更されないものとする。認証手順中に新しいサービングネットワークへのXnハンドオーバーが正常に完了した場合、AMFはAuthentication Requestメッセージに、現在のサービングネットワークに対応するSN nameを含めるものとする。SEAFは、認証手順が進行中の間に新しいサービングネットワークへのXnハンドオーバーが正常に行われたと判定すると、AMFは、現在の進行中の認証手順を中止し、新しい認証手順を開始し、新しい認証手順において新しいサービングネットワーク名を使用する。
NOTE1: SEAFは、Nausf_UEAuthentication_Authenticate Responseメッセージに基づいて認証方式のタイプを評価することにより、使用される認証方式がEAP方式であることを理解する必要がある。
5. USIMは、RANDとAUTNを受信すると、TS 33.102 [9]に記載されているようにAUTNを受け入れることができるかどうかを確認することによって、AV'の鮮度を検証するものとする。その場合、USIMは応答RESを計算する。USIMはRES、CK、IKをMEに返すものとする。USIMがTS 33.102 [9] に記載されているように、変換関数（conversion function）c3を使用してCKとIKからKc(すなわち、GPRS Kc)を計算してMEに送信する場合、MEはそのようなGPRS Kcを無視し、USIMまたはMEにGPRS Kcを保存しないものとする。MEは、Annex A.3に従ってCK'とIK'を導出するものとする。UEがauthentication requestメッセージでSN nameを受信すると、UEはそのSN nameを使用してRESとKAUSFを計算するものとする。
USIMでAUTNの検証が失敗した場合、USIMとMEは6.1.3.3項に記載されているとおりに処理を進めるものとする。
6. UEは、EAP-Response/AKA'-ChallengeメッセージをNASメッセージAuth-RespメッセージでSEAFに送信するものとする。
7. SEAFは、EAP-Response/AKA'-ChallengeメッセージをNausf_UEAuthentication_Authenticate Requestメッセージで透過的にAUSFに転送するものとする。
8. AUSFは、メッセージを検証するものとし、AUSFがこのメッセージの検証に成功した場合は、次のように続行するものとし、それ以外の場合はSEAFにエラーを返すものとする。AUSFは、UDMに認証結果を通知するものとする(リンク認証確認の詳細については、本文書の6.1.4項を参照)。
9. AUSFとUEは、SEAFを介してEAP-Request/AKA'-NotificationおよびEAP-Response/AKA'-Notificationメッセージを交換してもよい。SEAFは、これらのメッセージを透過的に転送するものとする。
NOTE2: RFC 3748 [27] に記載されているEAP NotificationとRFC 4187 [21]に記載されているEAP-AKA Notificationは、EAP-AKA交換でいつでも使用され得る。これらの通知は、保護された結果の表示や、EAPサーバが受信したEAP-AKA応答でエラーを検出した場合などに使用できる。
10. AUSFは、RFC 5448 [12]およびAnnex Fに記載されているように、CK'とIK'からEMSKを導出する。AUSFは、EMSKの最上位256ビットをKAUSFとして使用し、次にA.6.に記載されているように、KAUSFからKSEAFを計算する。AUSFは、EAP SuccessメッセージをNausf_UEAuthentication_Authenticate Response内でSEAFに送信し、SEAFはそれをUEに透過的に転送するものとする。Nausf_UEAuthentication_Authenticate Responseメッセージは、KSEAFを含む。認証が開始されたときにAUSFがSEAFからSUCIを受信した場合 (本文書の6.1.2項を参照)、AUSFはNausf_UEAuthentication_Authenticate ResponseメッセージにSUPIも含めるものとする。
NOTE 3: 合法的な傍受のためには、AUSFがSEAFにSUPIを送ることは必要であるが十分ではない。KSEAFからのKAMFのkey derivationへの入力パラメータとしてSUPIを含めることにより、ホームネットワークとUE側の両方からサービングネットワークによって、SUPIの正確性に関する追加の保証が達成される。
11. SEAFは、N1メッセージでEAP SuccessメッセージをUEに送信するものとする。このメッセージには、ngKSIおよびABBAパラメータも含まれるものとする。SEAFは、Annex A.7.1に定義されているABBAパラメータを設定するものとする。
NOTE 4: ステップ11は、NAS Security Mode CommandまたはAuthentication Resultである可能性がある。
NOTE 5: ABBAパラメータは、後で導入されてもよいセキュリティ機能のビッドダウン保護を有効にするために含まれている。
Nausf_UEAuthentication_Authenticate Responseメッセージで受信したキーは、本文書の6.2項のキー階層の意味におけるアンカーキー、KSEAFになるものとする。その後、SEAFは、Annex A.7に従って、KSEAF、ABBAパラメータおよびSUPIから、KAMFを導出し、AMFに送信するものとする。EAP-Successメッセージを受信すると、UEは、RFC 5448およびAnnex Fに記載されているように、CK'およびIK'からEMSKを導出する。MEは、EMSKの最上位256ビットをKAUSFとして使用し、その後、AUSFと同じ方法でKSEAFを計算する。UEは、Annex A.7に従って、KSEAF、ABBAパラメータ、およびSUPIからKAMFを導出するものとする。
NOTE 6: 実装オプションとして、UEは、EMSKの計算を可能にするEAPメッセージを受信した後、ステップ11で説明されているように一時的なセキュリティコンテキストを作成する。UEは、EAP Successを受信した場合、この一時的なセキュリティコンテキストを部分的なセキュリティコンテキストに変換する。EAP認証が失敗した場合、UEは一時的なセキュリティコンテキストを削除する。
正常に検証されたEAP-Response/AKA'-Challengeメッセージを受信したときにAUSFが実行する更なる手順については、本文書の6.1.4項に記載されている。
EAP-Response/AKA'-Challengeメッセージが正常に検証されなかった場合、その後のAUSFの動作はホームネットワークのポリシーに従って決定される。
AUSFとSEAFが認証に成功したと判断した場合、SEAFはngKSIとKAMFをAMFに提供する。
6.1.3.2 5G AKAの認証手順
6.1.3.2.0 5G AKA
5G AKAは、ホームネットワークに、visitedネットワークからのUEの認証に成功した証明を提供することで、EPS AKA [10]を強化する。証明は、visitedネットワークからAuthentication Confirmationメッセージで送信される。
5G AKAの使用の選択については、本文書の6.1.2項に記載されている。
NOTE 1: 5G AKAは、複数の5G AVの要求をサポートしておらず、SEAFも将来の使用のためにホームネットワークから5G AVをプリフェッチしていない。
図6.1.3.2-1:5G AKAの認証手順 (本出願の図14を参照)
5G AKAの認証手順は次のように動作する。また、図6.1.3.2-1参照(本出願の図14を参照):
1. 各Nudm_Authenticate_Get Requestに対して、UDM/ARPFは5G HE AVを作成するものとする。UDM/ARPFは、TS 33.102 [9] で定義されているように、Authentication Management Field (AMF) separation bitが「1」に設定されたAVを生成することによってこれを行う。次に、UDM/ARPFは、KAUSF (Annex A.2による)を導出し、XRES*(Annex A.4による)を計算する。最後に、UDM/ARPFは、RAND、AUTN、XRES*、およびKAUSFから5G HE AVを作成するものとする。
2. その後、UDMは、5G HE AVがNudm_UEAuthentication_Get Responseで5G AKAに使用されることを示すとともに、5G HE AVをAUSFに返すものとする。SUCIがNudm_UEAuthentication_Get Requestに含まれていた場合、UDMはSIDFによるSUCIの秘匿解除後に、SUPIをNudm_UEAuthentication_Get Responseに含める。サブスクライバーがAKMAサブスクリプションを持っている場合、UDMはNudm_UEAuthentication_Get ResponseにAKMA表示（AKMA indication）を含める。
3. AUSFは、受信したSUCIまたはSUPIと共にXRES*を一時的に保存するものとする。
4. その後、AUSFは、XRES*からHXRES*を計算し（Annex A.5に応じて）、KAUSFからKSEAFを計算し(Annex A .6に応じて)、XRES*をHXRES*に、KAUSFを5G HE AVのKSEAFに置き換えることによって、UDM/ARPFから受信した5G HE AVから5G AVを生成するものとする。
5. その後、AUSFはKSEAFを削除し、Nausf_UEAuthentication_Authenticate Responseで5G SE AV(RAND、AUTN、HXRES*)をSEAFに返すものとする。
6. SEAFは、NASメッセージAuthentication RequestでRAND、AUTNをUEに送信するものとする。このメッセージには、UEとAMFがKAMFを識別するために使用するngKSIと、認証が成功した場合に作成される部分的なネイティブセキュリティコンテキストも含まれるものとする。このメッセージには、ABBAパラメータも含まれるものとする。SEAFは、Annex A.7.1に定義されたABBAパラメータを設定するものとする。認証手順中に新しいサービングネットワークへのXnハンドオーバーが正常に完了した場合、AMFはAuthentication Requestメッセージに、現在のサービングネットワークに対応するSN nameを含めるものとする。MEは、NAS message Authentication Requestで受信したRAND及びAUTNをUSIMへ転送するものとする。SEAFは、認証手順が進行中の間に新しいサービングネットワークへのXnハンドオーバーが正常に行われたと判定すると、AMFは、現在の進行中の認証手順を中止し、新しい認証手順を開始し、新しい認証手順において新しいサービングネットワーク名を使用する。
NOTE 2:ABBAパラメータは、セキュリティ機能のビッドダウン保護を有効にするために含まれている。
7. USIMは、RANDとAUTNを受信すると、TS 33.102 [9]に記述されているようにAUTNを受け付けられるかどうかをチェックすることで、受信した値の鮮度を検証する。その場合、USIMは応答RESを計算する。USIMはRES、CK、IKをMEに返すものとする。USIMがTS 33.102 [9] に記述されているように、変換関数c3を使用してCKとIKからKc(すなわち、GPRS Kc)を計算し、MEに送信する場合、MEはそのようなGPRS Kcを無視し、USIMまたはMEにGPRS Kcを保存しないものとする。その後、MEは、Annex A.4に従ってRESからRES*を計算するものとする。MEは、A.2項に従ってCK||IKからKAUSFを計算するものとする。MEは、A.6項に従ってKAUSFからKSEAFを計算するものとする。5GにアクセスするMEは、認証中にAUTNのAMFフィールドの「separation bit」が1に設定されていることを確認するものとする。「separation bit」はAUTNのAMFフィールドのビット0である。UEがauthentication requestメッセージでSN nameを受信した場合、UEはそのSN nameを使用してRESとKAUSFを計算する。
NOTE 3:AUTNのAMFフィールドのこのseparation bitは、TS 33.102 [9]、Annex Fで説明されているように、オペレータ固有の目的には使用できない。
8. UEは、NASメッセージAuthentication ResponseでRES*をSEAFに返すものとする。
9. その後、SEAFはAnnex A.5に従ってRES*からHRES*を計算し、SEAFはHRES*とHXRES*を比較する。これらが一致する場合、SEAFはサービングネットワークの観点から認証が成功したとみなす。一致しない場合、SEAFは6.1.3.2.2項に記載されているように処理を進める。UEに到達せず、RES*がSEAFによって受信されない場合、SEAFは認証失敗と見なし、AUSFに失敗を示す。
10. SEAFは、UEから受信したRES*をNausf_UEAuthentication_Authenticate RequestメッセージでAUSFに送信する。
11. AUSFは、認証確認（authentication confirmation）として、RES*を含むNausf_UEAuthentication_Authenticate Requestメッセージを受信した場合、5G AVが満了したかどうかを確認してもよい。5G AVが満了した場合、AUSFはホームネットワークの観点から認証が失敗したと見なしてもよい。認証が成功すると、AUSFはKAUSFを保存するものとする。AUSFは、受信したRES*と保存されたXRES*を比較するものとする。RES*とXRES*が等しい場合、AUSFはホームネットワークの観点から認証が成功したとみなすものとする。AUSFは、UDMに認証結果を通知するものとする(認証確認とのリンクについては、本文書の6.1.4項を参照)。
12. AUSFは、ホームネットワークの観点から、認証が成功したかどうかをNausf_UEAuthentication_Authenticate ResponseでSEAFに示すものとする。認証が成功した場合、KSEAFはNausf_UEAuthentication_Authenticate ResponseでSEAFに送信されるものとする。AUSFがauthentication requestでSEAFからSUCIを受信した場合(本文書の6.1.2項を参照)であって、認証が成功した場合、AUSFはNausf_UEAuthentication_Authenticate ResponseメッセージにSUPIも含めるものとする。
認証が成功した場合、Nausf_UEAuthentication_Authenticate Responseメッセージで受信したキーKSEAFは、本文書の6.2項で指定されているキー階層の意味においてアンカーキーになるものとする。その後、SEAFは、KSEAF、ABBAパラメータ、およびSUPIから、Annex A.7に従ってKAMFを導出するものとする。SEAFは、ngKSIとKAMFをAMFに提供するものとする。
SUCIがこの認証に使用された場合、SEAFは、KSEAFとSUPIを含むNausf_UEAuthentication_Authenticate Responseメッセージを受信した後に、AMFにngKSIとKAMFのみを提供するものとする;SUPIがサービスネットワークに認識されるまで、UEに通信サービスは提供されない。
認証手順後にAUSFによって行われるその後の手順は、本文書の6.1.4項に記載されている。
【0153】
略語
本文書の目的上、TR 21.905 [1]および以下に示す略語が適用される。本文書で定義された略語は、TR 21.905 [1] において同じ略語がある場合、その定義よりも優先される。
4G-GUTI 4G Globally Unique Temporary UE Identity
5GC 5G Core Network
5GLAN 5G Local Area Network
5GS 5G System
5G-AN 5G Access Network
5G-AN PDB 5G Access Network Packet Delay Budget
5G-EIR 5G-Equipment Identity Register
5G-GUTI 5G Globally Unique Temporary Identifier
5G-BRG 5G Broadband Residential Gateway
5G-CRG 5G Cable Residential Gateway
5G GM 5G Grand Master
5G-RG 5G Residential Gateway
5G-S-TMSI 5G S-Temporary Mobile Subscription Identifier
5G VN 5G Virtual Network
5QI 5G QoS Identifier
AF Application Function
AMF Access and Mobility Management Function
AS Access Stratum
ATSSS Access Traffic Steering, Switching, Splitting
ATSSS-LL ATSSS Low-Layer
AUSF Authentication Server Function
AUTN Authentication token
BMCA Best Master Clock Algorithm
BSF Binding Support Function
CAG Closed Access Group
CAPIF Common API Framework for 3GPP northbound APIs
CHF Charging Function
CN PDB Core Network Packet Delay Budget
CP Control Plane
DAPS Dual Active Protocol Stacks
DL Downlink
DN Data Network
DNAI DN Access Identifier
DNN Data Network Name
DRX Discontinuous Reception
DS-TT Device-side TSN translator
ePDG evolved Packet Data Gateway
EBI EPS Bearer Identity
EPS Evolved Packet System
EUI Extended Unique Identifier
FAR Forwarding Action Rule
FN-BRG Fixed Network Broadband RG
FN-CRG Fixed Network Cable RG
FN-RG Fixed Network RG
FQDN Fully Qualified Domain Name
GFBR Guaranteed Flow Bit Rate
GMLC Gateway Mobile Location Centre
GPSI Generic Public Subscription Identifier
GUAMI Globally Unique AMF Identifier
GUTI Globally Unique Temporary UE Identity
HR Home Routed (roaming)
IAB Integrated access and backhaul
IMEI/TAC IMEI Type Allocation Code
IPUPS Inter PLMN UP Security
I-SMF Intermediate SMF
I-UPF Intermediate UPF
LADN Local Area Data Network
LBO Local Break Out (roaming)
LMF Location Management Function
LoA Level of Automation
LPP LTE Positioning Protocol
LRF Location Retrieval Function
MCC Mobile country code
MCX Mission Critical Service
MDBV Maximum Data Burst Volume
MFBR Maximum Flow Bit Rate
MICO Mobile Initiated Connection Only
MNC Mobile Network Code
MPS Multimedia Priority Service
MPTCP Multi-Path TCP Protocol
N3IWF Non-3GPP InterWorking Function
N5CW Non-5G-Capable over WLAN
NAI Network Access Identifier
NEF Network Exposure Function
NF Network Function
NGAP Next Generation Application Protocol
NID Network identifier
NPN Non-Public Network
NR New Radio
NRF Network Repository Function
NSI ID Network Slice Instance Identifier
NSSAA Network Slice-Specific Authentication and Authorization
NSSAAF Network Slice-Specific Authentication and Authorization Function
NSSAI Network Slice Selection Assistance Information
NSSF Network Slice Selection Function
NSSP Network Slice Selection Policy
NW-TT Network-side TSN translator
NWDAF Network Data Analytics Function
PCF Policy Control Function
PDB Packet Delay Budget
PDR Packet Detection Rule
PDU Protocol Data Unit
PEI Permanent Equipment Identifier
PER Packet Error Rate
PFD Packet Flow Description
PNI-NPN Public Network Integrated Non-Public Network
PPD Paging Policy Differentiation
PPF Paging Proceed Flag
PPI Paging Policy Indicator
PSA PDU Session Anchor
PTP Precision Time Protocol
QFI QoS Flow Identifier
QoE Quality of Experience
RACS Radio Capabilities Signalling optimisation
(R)AN (Radio) Access Network
RG Residential Gateway
RIM Remote Interference Management
RQA Reflective QoS Attribute
RQI Reflective QoS Indication
RSN Redundancy Sequence Number
SA NR Standalone New Radio
SBA Service Based Architecture
SBI Service Based Interface
SCP Service Communication Proxy
SD Slice Differentiator
SEAF Security Anchor Functionality
SEPP Security Edge Protection Proxy
SMF Session Management Function
SMSF Short Message Service Function
SN Sequence Number
SN name Serving Network Name
SNPN Stand-alone Non-Public Network
S-NSSAI Single Network Slice Selection Assistance Information
SSC Session and Service Continuity
SSCMSP Session and Service Continuity Mode Selection Policy
SST Slice/Service Type
SUCI Subscription Concealed Identifier
SUPI Subscription Permanent Identifier
SV Software Version
TNAN Trusted Non-3GPP Access Network
TNAP Trusted Non-3GPP Access Point
TNGF Trusted Non-3GPP Gateway Function
TNL Transport Network Layer
TNLA Transport Network Layer Association
TSC Time Sensitive Communication
TSCAI TSC Assistance Information
TSN Time Sensitive Networking
TSN GM TSN Grand Master
TSP Traffic Steering Policy
TT TSN Translator
TWIF Trusted WLAN Interworking Function
UCMF UE radio Capability Management Function
UDM Unified Data Management
UDR Unified Data Repository
UDSF Unstructured Data Storage Function
UL Uplink
UL CL Uplink Classifier
UPF User Plane Function
URLLC Ultra Reliable Low Latency Communication
URRP-AMF UE Reachability Request Parameter for AMF
URSP UE Route Selection Policy
VID VLAN Identifier
VLAN Virtual Local Area Network
W-5GAN Wireline 5G Access Network
W-5GBAN Wireline BBF Access Network
W-5GCAN Wireline 5G Cable Access Network
W-AGF Wireline Access Gateway Function
本文書の目的上、TR 21.905 [1]および以下に示す略語が適用される。本文書で定義された略語は、TR 21.905 [1] において同じ略語がある場合、その定義よりも優先される。
4G-GUTI 4G Globally Unique Temporary UE Identity
5GC 5G Core Network
5GLAN 5G Local Area Network
5GS 5G System
5G-AN 5G Access Network
5G-AN PDB 5G Access Network Packet Delay Budget
5G-EIR 5G-Equipment Identity Register
5G-GUTI 5G Globally Unique Temporary Identifier
5G-BRG 5G Broadband Residential Gateway
5G-CRG 5G Cable Residential Gateway
5G GM 5G Grand Master
5G-RG 5G Residential Gateway
5G-S-TMSI 5G S-Temporary Mobile Subscription Identifier
5G VN 5G Virtual Network
5QI 5G QoS Identifier
AF Application Function
AMF Access and Mobility Management Function
AS Access Stratum
ATSSS Access Traffic Steering, Switching, Splitting
ATSSS-LL ATSSS Low-Layer
AUSF Authentication Server Function
AUTN Authentication token
BMCA Best Master Clock Algorithm
BSF Binding Support Function
CAG Closed Access Group
CAPIF Common API Framework for 3GPP northbound APIs
CHF Charging Function
CN PDB Core Network Packet Delay Budget
CP Control Plane
DAPS Dual Active Protocol Stacks
DL Downlink
DN Data Network
DNAI DN Access Identifier
DNN Data Network Name
DRX Discontinuous Reception
DS-TT Device-side TSN translator
ePDG evolved Packet Data Gateway
EBI EPS Bearer Identity
EPS Evolved Packet System
EUI Extended Unique Identifier
FAR Forwarding Action Rule
FN-BRG Fixed Network Broadband RG
FN-CRG Fixed Network Cable RG
FN-RG Fixed Network RG
FQDN Fully Qualified Domain Name
GFBR Guaranteed Flow Bit Rate
GMLC Gateway Mobile Location Centre
GPSI Generic Public Subscription Identifier
GUAMI Globally Unique AMF Identifier
GUTI Globally Unique Temporary UE Identity
HR Home Routed (roaming)
IAB Integrated access and backhaul
IMEI/TAC IMEI Type Allocation Code
IPUPS Inter PLMN UP Security
I-SMF Intermediate SMF
I-UPF Intermediate UPF
LADN Local Area Data Network
LBO Local Break Out (roaming)
LMF Location Management Function
LoA Level of Automation
LPP LTE Positioning Protocol
LRF Location Retrieval Function
MCC Mobile country code
MCX Mission Critical Service
MDBV Maximum Data Burst Volume
MFBR Maximum Flow Bit Rate
MICO Mobile Initiated Connection Only
MNC Mobile Network Code
MPS Multimedia Priority Service
MPTCP Multi-Path TCP Protocol
N3IWF Non-3GPP InterWorking Function
N5CW Non-5G-Capable over WLAN
NAI Network Access Identifier
NEF Network Exposure Function
NF Network Function
NGAP Next Generation Application Protocol
NID Network identifier
NPN Non-Public Network
NR New Radio
NRF Network Repository Function
NSI ID Network Slice Instance Identifier
NSSAA Network Slice-Specific Authentication and Authorization
NSSAAF Network Slice-Specific Authentication and Authorization Function
NSSAI Network Slice Selection Assistance Information
NSSF Network Slice Selection Function
NSSP Network Slice Selection Policy
NW-TT Network-side TSN translator
NWDAF Network Data Analytics Function
PCF Policy Control Function
PDB Packet Delay Budget
PDR Packet Detection Rule
PDU Protocol Data Unit
PEI Permanent Equipment Identifier
PER Packet Error Rate
PFD Packet Flow Description
PNI-NPN Public Network Integrated Non-Public Network
PPD Paging Policy Differentiation
PPF Paging Proceed Flag
PPI Paging Policy Indicator
PSA PDU Session Anchor
PTP Precision Time Protocol
QFI QoS Flow Identifier
QoE Quality of Experience
RACS Radio Capabilities Signalling optimisation
(R)AN (Radio) Access Network
RG Residential Gateway
RIM Remote Interference Management
RQA Reflective QoS Attribute
RQI Reflective QoS Indication
RSN Redundancy Sequence Number
SA NR Standalone New Radio
SBA Service Based Architecture
SBI Service Based Interface
SCP Service Communication Proxy
SD Slice Differentiator
SEAF Security Anchor Functionality
SEPP Security Edge Protection Proxy
SMF Session Management Function
SMSF Short Message Service Function
SN Sequence Number
SN name Serving Network Name
SNPN Stand-alone Non-Public Network
S-NSSAI Single Network Slice Selection Assistance Information
SSC Session and Service Continuity
SSCMSP Session and Service Continuity Mode Selection Policy
SST Slice/Service Type
SUCI Subscription Concealed Identifier
SUPI Subscription Permanent Identifier
SV Software Version
TNAN Trusted Non-3GPP Access Network
TNAP Trusted Non-3GPP Access Point
TNGF Trusted Non-3GPP Gateway Function
TNL Transport Network Layer
TNLA Transport Network Layer Association
TSC Time Sensitive Communication
TSCAI TSC Assistance Information
TSN Time Sensitive Networking
TSN GM TSN Grand Master
TSP Traffic Steering Policy
TT TSN Translator
TWIF Trusted WLAN Interworking Function
UCMF UE radio Capability Management Function
UDM Unified Data Management
UDR Unified Data Repository
UDSF Unstructured Data Storage Function
UL Uplink
UL CL Uplink Classifier
UPF User Plane Function
URLLC Ultra Reliable Low Latency Communication
URRP-AMF UE Reachability Request Parameter for AMF
URSP UE Route Selection Policy
VID VLAN Identifier
VLAN Virtual Local Area Network
W-5GAN Wireline 5G Access Network
W-5GBAN Wireline BBF Access Network
W-5GCAN Wireline 5G Cable Access Network
W-AGF Wireline Access Gateway Function
【0154】
定義
本文書の目的上、3GPP TR 21.905 [1] および以下に示す用語および定義が適用される。本文書で定義された用語は、3GPP TR 21.905 [1] に同じ用語がある場合、その定義よりも優先される。
本文書の目的上、3GPP TR 21.905 [1] および以下に示す用語および定義が適用される。本文書で定義された用語は、3GPP TR 21.905 [1] に同じ用語がある場合、その定義よりも優先される。
【0155】
本発明は、実施の形態を参照して特に示され説明されているが、本発明はこれらの実施の形態に限定されない。請求項に定義された本発明の精神および範囲から逸脱することなく、形態および詳細に様々な変更を加えることができることは、当業者には理解されるであろう。
【0156】
本出願は、2020年10月29日に出願されたインド特許出願第202011047284号に基づいており、優先権の利益を主張しており、その開示は参照によりその全体が本出願に組み込まれている。
【符号の説明】
【0157】
800 UE
801 アンテナ
802 送受信機回路
803 ユーザインターフェース
804 コントローラ
805 メモリ
900 (R)ANノード
901 アンテナ
902 送受信機回路
903 ネットワークインターフェース
904 コントローラ
905 メモリ
1000 AMF
1001 送受信機回路
1002 コントローラ
1003 メモリ
1004 ネットワークインターフェース
801 アンテナ
802 送受信機回路
803 ユーザインターフェース
804 コントローラ
805 メモリ
900 (R)ANノード
901 アンテナ
902 送受信機回路
903 ネットワークインターフェース
904 コントローラ
905 メモリ
1000 AMF
1001 送受信機回路
1002 コントローラ
1003 メモリ
1004 ネットワークインターフェース
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】