***   欢迎转发，转发请注明出处    ***

 

4. AMF调用old AMF的Namf_Communication_UEContextTransfer服务获取UE上下文。

       如果UE的Registration Request消息携带5G-GUTI进行注册，并且AMF发生了变化，此时新的AMF（new AMF）会向UE原来注册的AMF（old AMF）请求UE上下文信息，包含SUPI、GPSI、5GMM Capability等参数（UE上下文的内容详见TS 23.502）。

new AMF采用POST方法调用old AMF的Namf_Communication_UEContextTransfer服务。具体使用的URI格式为：

{apiRoot}/namf-comm/<apiVersion>/ue-contexts/{ueContextId}/transfer

调用该服务携带的请求消息内容为：UeContextTransferReqData。

注：

（1）通用的URI结构为：

{apiRoot}/<apiName>/<apiVersion>/<apiSpecificResourceUriPart>

（2）对于SBI接口采用POST方法还是PUT方法的区别

服务的生产者选择资源的标识符和URI，则采用POST方法；服务的消费者选择资源的标识符和URI，则采用PUT方法。

URI请求的命令行参数

• {apiRoot}

该字段和我们日常上网，在IE地址栏中输入的内容一样，以http或者https开头的地址，后面是IP地址和端口号等信息；

• namfcomm

AMF上用于信息传递的API名称。其它API名字为："namf-mt"、"namf-loc"、"namf-evts"

• <apiVersion>

目前在R16版本中全部为“v1”，后续如果有大的功能变更，可能会有更新的版本。

• uecontexts

请求UE Context的固定值。

• {ueContextId}

请求的UE Context的标识，可以为5G-GUTI、SUPI或者PEI，使用的格式如下：

（1）5G-GUTI：5g-guti-[0-9]{5,6}[0-9a-fA-F]{14}

（2）SUPI：(imsi-[0-9]{5,15}|nai-.+|.+)

（3）(imei-[0-9]{15}|imeisv-[0-9]{16}|.+)

3GPP使用正则表达式进行描述，我们只需要知道对应的标记（5g-guti、imsi、nai、imei、imeisv）加上短横线，再加上具体的值即可。IMEI和IMEISV用于紧急注册，目前在国内不会遇到。我们能够遇到的基本都是5g-guti或者imsi。

• transfer

传递已经存在的UE Context的方法。其它的可能方法有：transfer-update（后续流程中Namf_Communication_RegistrationStatusUpdate消息使用的就是该方法）、release、assign-ebi。

URI请求的内容（UeContextTransferReqData）

SBI接口的消息内容采用JSON编码。Namf_Communication_UEContextTransfer消息的请求内容定义如下：

• reason

可选的取值为："INIT_REG"、"MOBI_REG"、"MOBI_REG_UE_VALIDATED"。

当UE执行初始注册时取值为："INIT_REG"；当UE执行移动性注册时取值为："MOBI_REG"；当首次获取UE Context失败，AMF和AUSF执行UE鉴权成功后，再次获取UE Context时，使用"MOBI_REG_UE_VALIDATED"。

• accessType

可选的取值为："3GPP_ACCESS"或者"NON_3GPP_ACCESS"。

• [plmnId]

即为MCC和MNC。

• [regRequest]

注册流程的完整Registration Request消息，包含在该参数中。

• [supportedFeatures]

特性支持相关的字符串。

AMF的处理过程

1. 对于初始注册和移动性注册，如果有5G-GUTI，第一次向old AMF请求获取UE上下文的输入参数为：5G-GUTI、Access Type、Reason和完整的Registration Request。AMF返回的信息如下：

• 如果注册原因为"INIT_REG"并且old AMF执行完整性检查成功，则返回不包含PDU Session信息的UE上下文。如果old AMF根据new AMF的PLMN ID判断，不能将N2接口重定位到new AMF，则只返回supi；
• 如果注册类型"MOBI_REG"并且old AMF执行完整性检查成功，返回200 OK消息，包含完整的UE Context（含有PDU Session信息）。

2. 如果第一次old AMF完整性检查失败（返回给new AMF的响应为：403 Forbidden，携带原因值：“INTEGRITY_CHECK_FAIL”），UE和AUSF鉴权成功后，再次向old AMF请求UE Context的消息和第一次请求的消息略有不同，三个不同点如下：

• 第二次{ueContextId}的取值为SUPI。因为在UE和AUSF的鉴权流程中，new AMF已经得到了SUPI，所以第二次直接携带SUPI请求UE Context；
• 第二次“reason”的取值为"MOBI_REG_UE_VALIDATED"；
• 第二次消息中不包含Registration Request消息，也就是不包含[regRequest]参数。

old AMF在处理该请求时会跳过完整性检查，直接回复“200 OK "，并携带完整的UE上下文（包含PDU Session相关的信息）。

5. old AMF向new AMF回复Namf_Communication_UEContextTransfer Response消息

• 成功响应

如果old AMF处理成功，在Namf_Communication_UEContextTransfer Response

消息中返回200 OK 响应，并携带UE Context。响应的消息内容如下UeContextTransferRspData：

• 响应失败

    （1） 403 Forbidden

              如果old AMF对请求消息中的Registration Request消息完整性检查失败，则设置原因值：“INTEGRITY_CHECK_FAIL”。

    （2）404 Not Found

             如果old AMF没有找到对应的UE Context则返回该响应，并设置原因值为“CONTEXT_NOT_FOUND”

获取UE Context流程相关注意点

1. 如果在切换流程中，new AMF已经从old AMF中获取到了UE，则在注册流程中就不需要向old AMF重新获取了，即在注册流程中的第4，5，10步骤都不需要执行。
2. 如果old AMF有不同于当前accessType的PDU Session，AMF判断该PDU Session无法重定位到新的AMF，则AMF只返回SUPI，并指示消息已经经过完整性验证，不包含UE Context的其他部分（SUPI包含在UeContext数据类型中）。
3. 跨PLMN移动的时候，UE Context中的信息包含的是HPLMN S-NSSAI的信息（可以对应到Allowed NSSAI的S-NSSAI），而不是old PLMN的Allowed S-NSSAI。
4. UE注册到新的AMF后，不需要重新订阅事件，因为UEContext中包含事件订阅的信息。如下：

6. Identity Request消息向UE获取SUCI

如果在Registration Request中UE没有提供SUCI，则AMF向UE发送Identity Request消息，请求获取UE的SUCI。

注：

在TS 23.502规范中，注册流程该步骤的解释为：If the SUCI is not provided by the UE nor retrieved from the old AMF the Identity Request procedure is initiated by AMF sending an Identity Request message to the UE requesting the SUCI.

“UE从old AMF没有获取到SUCI”，也是发送Identity Request消息的前提。但是我们在UE Context的定义中并没有发现SUCI字段，也就是UE Context并不保存UE的SUCI。另外，从Namf_Communication_UEContextTransfer Request的响应中可以知道，要么成功响应返回SUPI，要么获取失败返回403 Forbidden或者404 Not Found，此时，new AMF什么都不会得到。根据TS 33.501章节6.1.2：The SEAF shall include the SUPI in the Nausf_UEAuthentication_Authenticate Request message in case the SEAF has a valid 5G-GUTI and re-authenticates the UE. Otherwise the SUCI is included in Nausf_UEAuthentication_Authenticate Request. 可以知道，主鉴权流程使用的参数要么是SUCI，要么是SUPI。个人判断，TS 23.502此处编写有误，new AMF从old AMF得到SUCI的场景是不存在的，只能得到SUPI。SUCI是SIM或者ME计算得到的，每次计算的值都不一样，AMF没有必要保存SUCI。

NAS消息Identity Request消息的定义如下：

该消息中重点关注的字段为Identity Type，该字段指明了AMF请求的是哪一个5GS标识。可以请求的5GS标识如下图，最后一句话很重要：所有不能识别的标识都认为是SUCI。

该NAS消息承载在AMF和gNB之间的DOWNLINK NAS TRANSPORT（N2接口消息）消息中发送给gNB，之后gNB将NAS消息承载在RRC层的DLInformationTransfer消息中发送给UE。

DLInformationTransfer消息承载在SRB2（在SRB2未建立时也可以使用SRB1）中（逻辑信道DCCH）。

7. UE向AMF发送Identity Response消息

该NAS消息中的重点字段为：Mobile identity。UE可以发送SUCI、5G-GUTI、IMEI、IMEISV、5G-S-TMSI、MAC地址或者EUI-64作为5GS mobile identity。

该NAS消息在UE和gNB间承载在RRC层的ULInformationTransfer消息中。

ULInformationTransfer消息承载在SRB2（在SRB2未建立时也可以使用SRB1）中（逻辑信道DCCH）。

gNB收到Identity Response消息后，封装在Uplink NAS Transport（N2接口消息）消息中发送给AMF。

RRC层消息DLInformationTransfer和ULInformationTransfer用于在UE处于RRC-CONNECTED状态时传递NAS消息。

8. AUSF选择

在AMF从UE得到SUCI或者old AMF得到SUPI后，选择AUSF执行鉴权流程。

 

后续流程，留待下回分解  ......