本文已参与「新人创作礼」活动，一起开启掘金创作之路。
相关文章会在公众号同步更新。公众号：5G通信大家学
持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。
///////////
1.1.2.3 gNB转发Registration Request消息给AMF
gNB选择完AMF后，向AMF发送INITIAL UE MESSAGE（初始N2消息）。为该UE分配一个唯一的RAN UE NGAP ID，也包含在INITIAL UE MESSAGE消息中。gNB从选择的AMF，且该AMF可用的TNL associations中，选择一个可以用于发送初始消息的TNL associations（TNL Association的权重因子为0的，不能用于初始N2消息的发送），为该UE创建NGAP UE-TNLA-binding，并通过选定的TNL association转发该UE的消息到AMF。
TNL Association应该就是SCTP层的Association，第一个TNL Association在gNB上电后，根据配置的IP地址和端口号与AMF建立Association，后续如果需要增加TNL Association时，AMF需要向5G-AN发送AMF CONFIGURATION UPDATE消息，该消息中包含增加TNL Association的IP地址和端口号。TNL Association最多可以创建32个。
INITIAL UE MESSAGE只用于发送上行的第一条NAS消息。后续的NAS消息使用UPLINK NAS TRANSPORT。既然两条消息都用于传输上行NAS消息，为什么会有这个区别？我们先来看这两条消息的定义。
INITIAL UE MESSAGE消息的定义：
UPLINK NAS TRANSPORT消息的定义：
从上面两条消息的定义可以看出来INITIAL UE MESSAGE只需要包含gNB本侧的RAN UE NGAP ID，而UPLINK NAS TRANSPORT需要知道gNB和AMF两侧的UE NGAP ID才能进行通信，这个两个字段又都是必选字段。所以3GPP定义了两条消息。在gNB和AMF之间第一回合的交互中，互相知道了对方的UE NGAP ID后才能使用UPLINK NAS TRANSPORT消息传递NAS消息。对于传输下行NAS消息的DOWNLINK NAS TRANSPORT不存在这样的问题，因为gNB发送完第一条INITIAL UE MESSAGE消息后已经将本侧的RAN UE NGAP ID带给了AMF。
注：****
*在INITIAL UE MESSAGE消息中还包含Allowed NSSAI IE，规范的解释：If the Allowed NSSAI IE is included in the INITIAL UE MESSAGE message the AMF shall use the IE as defined in TS 23.502 [10].，但是在TS 23.502中并没有明确指出该IE的使用场景。那么什么情况下会在INITIAL UE MESSAGE消息中包含Allowed NSSAI呢？按正常的逻辑，Allowed NSSAI是在注册请求完成后，AMF下发给UE的Registration Accept才会有Allowed NSSAI，而这里在初始N2消息中就包含Allowed NSSAI，相当奇怪了。
经过仔细查找，发现在注册过程中如果AMF出现重选的场景下，如果需要RAN转发初始注册请求可能会在INITIAL UE MESSAGE中出现Allowed NSSAI。初始AMF和UDM、NSSF已经交互完成得到了切片相关的信息，此时如果初始AMF不能为UE服务，而目标AMF和初始AMF不在同一个AMF Set，此时可能就需要RAN（gNB）转发注册请求。AMF发送Reroute NAS Request消息给gNB，gNB发现在该消息中存在Allowed NSSAI，会在发送给目标AMF的Initial UE Message消息中包含Allowed NSSAI IE和Source to Target AMF Information Reroute IE。*
1.1.2.4 Namf_Communication_UEContextTransfer
new AMF调用old AMF的服务获取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//ue-contexts/{ueContextId}/transfer
调用该服务携带的请求消息内容为：UeContextTransferReqData。
注：
*（1）通用的URI结构为：
*{*apiRoot}///
*（*2）对于SBI接口采用POST方法还是PUT方法的区别
服务的生产者选择资源的标识符和URI，则采用POST方法；服务的消费者选择资源的标识符和URI，则采用PUT方法。*
下面看一下该POST请求的URI参数
- {apiRoot}
该字段和我们日常上网，在IE地址栏中输入的内容一样，以http或者https开头的地址，后面是IP地址和端口号等信息；
- namf-comm
AMF上用于信息传递的API名称。其它API名字为："namf-mt"、"namf-loc"、"namf-evts"
目前在R16版本中全部为“v1”，后续如果有大的功能变更，可能会有更新的版本。
- ue-contexts
请求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]
特性支持相关的字符串。
我们先来看一下new AMF调用该操作的处理过程
（1）对于初始注册和移动性注册，如果有5G-GUTI，第一次向old AMF请求获取UE上下文的输入参数为：5G-GUTI、Access Type、Reason和完整的Registration Request。AMF返回的信息如下：
A． 如果注册原因为"INIT_REG"并且old AMF执行完整性检查成功，则返回不包含PDU Session信息的UE上下文。如果old AMF根据new AMF的PLMN ID判断，不能将N2接口重定位到new AMF，则只返回supi（跨PLMN的情况）；
B． 如果注册类型为"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的消息和第一次请求的消息略有不同，三个不同点如下：
A． 第二次{ueContextId}的取值为SUPI。因为在UE和AUSF的鉴权流程中，new AMF已经得到了SUPI，所以第二次直接携带SUPI请求UE Context；
B． 第二次“reason”的取值为"MOBI_REG_UE_VALIDATED"；
C． 第二次消息中不包含Registration Request消息，也就是不包含[regRequest]参数。
old AMF在处理该请求时会跳过完整性检查，直接回复“200 OK "，并携带完整的UE上下文（包含PDU Session相关的信息）。
