PDU会话建立流程（4）-SMF选择也有门道儿

相关文章会在公众号同步更新。公众号：5G通信大家学

持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。

在介绍完流程详解后，会整理专题内容，比如切片、服务发现、QoS流端到端的映射等内容，各位同学不仅可以纵向学习知识点，横向也会将知识关联起来，达到深入理解灵活运用的目的。
 

1.3.2.3.2 SMF选择

AMF根据UL NAS TRANSPORT消息的Request Type IE的取值是否为"initial request"来判断是不是需要创建PDU会话，并检查UL NAS TRANSPORT消息中的PDU Session ID是不是已经被别的PDU会话占用了。

从第一步介绍中可以知道，如果UE确定不了会话的S-NSSAI，可以在会话建立消息中不包含切片信息。此时，就需要AMF根据用户注册时构建的UE Context（其中包含Allowed NSSAI）来为UE选择一个S-NSSAI。如果Allowed NSSAI只包含一个S-NSSAI直接使用，就不涉及选择的问题了，根本没得选，只能用这唯一的一个S-NSSAI。如果Allowed NSSAI有多个S-NSSAI，如何选择切片主要看设备的实现方式或者数据配置，可以根据签约中缺省S-NSSAI或者AMF的本地配置选择。

如果会话建立请求只包含S-NSSAI，不包含DNN，且UE签约数据该切片有缺省DNN的情况下，通常AMF会选择缺省DNN来为UE建立PDU会话，否则，AMF会选择本地配置的DNN为UE建立PDU会话。

注：

TS 23.502中明确有说明：When the NAS Message contains an S-NSSAI of the Serving PLMN but it does not contain a DNN, the AMF determines the DNN for the requested PDU Session by selecting the default DNN for this S-NSSAI if the default DNN is present in the UE's Subscription Information。这句话看起来很有道理，但是细推敲起来，还有不少门道儿。因为我在AMF的UE Context定义中（TS 29.518）并没有找到old AMF从UDM下载的DNN签约数据。比较典型的场景是AMF跨POOL移动，新AMF POOL中的AMF从原来AMF POOL中的old AMF得到了UE Context，这个UE Context中不包含DNN签约数据。假如UE移动性注册更新完成之后，此时要发起PDU会话建立流程，消息携带了S-NSSAI，但是没有携带DNN，此时AMF无法根据从old AMF得到的UE Context来为UE选择该切片下的默认DNN。对于已经建立的PDU会话，UE Context都会保留相关的数据，不受影响。

对于UE的初始注册或者移动性注册且从old AMF没有得到UE Context，AMF重新从UDM下载全部签约数据，PDU会话建立不存在这个问题，因为此时AMF不仅下载AM签约数据（其中包含签约的DNN信息），还会下载SMF选择签约数据（其中包含具体切片下支持的DNN数据）等等。这样，如果UE发起PDU会话建立请求，AMF就可以根据SMF选择签约数据（smf-select-data）为UE选择一个该切片下支持的DNN。

那么，对于移动性注册，并且new AMF从old AMF得了可用的UE Context场景，此时new AMF仍然缺少SMF选择数据（smf-select-data）等签约数据，这时就要从UDM下载签约数据了。也就是对于初始注册和移动性注册，AMF从UDM下载签约数据是必须的流程，上面的叙述就是原因。UE Context并不是包含全部UE相关的数据，只是包含UE的动态数据和一部分静态数据。

注意：

UDM的AM签约数据中的DNN信息目前仅用于判断当前TA是否支持LADN服务，不用于PDU会话的创建（后面还会介绍别的用途）。因为它只有DNN信息，而没有关联的切片。5G中DNN的作用域是切片，因为切片是逻辑网络隔离的关键标识。从1.3.1.6章节PDU会话的属性可以知道，5G中的PDU会话都要和切片、DNN关联。没有一招吃遍所有切片的PDU会话。目前3GPP中有“通配DNN”的概念，尚未发现“通配NSSAI”的概念。

我们看一下UDM中的SMF选择数据。

从UDM下载SMF选择数据的资源URI：

{apiRoot}/nudm-sdm/<apiVersion>/{supi}/smf-select-data

数据下载的方法如下：

在200 OK的响应中就包含SMF选择签约数据：

从SMF选择签约数据中可以看到，包括每个切片下支持的DNN信息，及每个DNN属性信息，如：是否是缺省DNN、是否允许LBO模式漫游、是否支持切换到4G、是否DNN被禁止使用等等属性。

注册流程中，AMF不仅需要从UDM中下载SMF选择签约数据，还需要下载SMF中的UE Context数据，对于已经存在的PDU会话，AMF会使用其中的SMF ID（smfInstanceId）进行SMF选择。

UDM中保存的SMF相关UE Context签约数据的资源URI如下：

{apiRoot}/nudm-sdm/<apiVersion>/{supi}/ue-context-in-smf-data

下载的方法如下图：

在200 OK响应中包含UeContextInSmfData数据，详见下图：

从SMF的UE Context数据中可以看出来，其中包含PDU会话的DNN、切片、smfInstanceId（SMF ID）等信息。如果PDU会话支持4/5G切换还会包含PGW的信息。

注册流程中，AMF还会下载"UEC_SMSF"、"SMS_SUB"签约数据，等详解到短信流程中再介绍。

注：

这里会有一个比较细节的问题注明一下供思考。AMF根据注册请求中的什么信息来下载签约数据呢？注册流程中，AM、SMF_SEL基本是必须，SMS_SUB可以根据注册请求中是否支持短信来判断。比较难的是UEC_SMF（即：UeContextInSmfData）和UEC_SMSF（即：UeContextInSmsfData）。在注册流程中，AMF是根据注册请求中的哪些信息来判断UDM中已经存在相关的UE Context，进而下载的，还有其它的LCS等签约信息等。因为这些数据不是UDM推送给AMF的，而需要AMF主动选择获取。

TS 23.502的4.3.2.2.1章节：The case where the Request Type indicates "Existing PDU Session", and either the AMF does not recognize the PDU Session ID or the subscription context that the AMF received from UDM during the Registration or Subscription Profile Update Notification procedure does not contain an SMF ID corresponding to the PDU Session ID constitutes an error case.这句话说明了，UE在SMF中的UE Context是在注册流程中下载下来的。AMF如何判断要获取这部分数据呢？

我个人理解这些签约数据可以随时下载，AMF收到UE的业务请求，如果本地没有相关签约数据，或者相关数据不完整，或者数据损坏了，AMF都可以随时从UDM下载，并不一定非要在注册流程中全部下载完成。

从目前看到的初始注册和移动性注册的信令流程，不同厂家下载的签约数据都不同。有的移动性注册只下载：AM、SMF_SEL，有的下载AM,SMF_SEL,UEC_SMSF,SMS_SUB。

经过上面的步骤，此时AMF选择SMF的选择因子基本就确定了，如：S-NSSAI、DNN、UE的当前位置等。下一步就是AMF向NRF执行服务发现，选择为UE服务的SMF。

AMF的具体处理规则如下：

（1）如果请求类型是"Initial request"，或者PDU会话建立请求的原因是4G或non-3GPP切换，AMF会保存PDU会话的S-NSSAI、DNN、PDU Session ID、SMF ID及接入类型；

（2）如果请求类型是"Initial request"，并且包含Old PDU Session ID，AMF会按照SSC Mode 3的处理方式选择一个SMF，并保存UE新分配的PDU Session ID、S-NSSAI、SMF ID及接入类型；

（3）如果请求类型是"Existing PDU Session"，AMF会根据SMF ID选择SMF，并保存相应的接入类型。SMF ID在UE Context和UDM中都有保存。

如果AMF选择不到为UE提供服务的SMF，如：DNN网络不支持，UE又没有签约通配DNN、DNN替换功能，或者AMF本地没有配置的纠错DNN等补救措施，此时AMF就会拒绝UE的PDU会话建立，携带具体的拒绝原因值返回给UE。