5G技术详解系列-PDU会话签约数据（6）

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

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

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

 

1.3.2.3.4 Subscription retrieval/ Subscription for updates

（1）签约数据下载

此处SMF获取的是会话管理签约数据，涉及到的请求消息为：Nudm_SDM_Get Request和Nudm_SDM_Get Response。

该步骤的基本原理和AMF获取签约数据一样，先是下载签约数据，之后订阅签约数据变化。如果UDM中数据发生变化了，会调用SMF订阅时发送的回调URI通知SMF。不同点就是SMF下载的是用户承载相关的会话管理签约数据，而AMF下载的是接入和移动性管理相关的签约数据。下面进行相关内容详解。

SMF下载签约数据的HTTP方法为：GET，调用的资源URI为：

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

该请求不包含消息体，但包含查询参数。

查询参数中包含选择的S-NSSAI、DNN和PLMN ID信息。这个三个查询参数都是可选的。如果不包含S-NSSAI和DNN查询参数，UDM会返回所有切片的所有DNN；如果只包含DNN，UDM会返回该DNN下可用的所有切片的DNN配置。如果只包含S-NSSAI，不包含DNN，UDM会返回该切片的所有DNN配置。如果不携带PLMN ID信息的话，UDM只返回S-NSSAI或者DNN关联的HPLMN的配置。

需要注意的是S-NSSAI和DNN。如果S-NSSAI只包含SST不包含SD部分，UDM会认为任何的SD值都会匹配这个切片查询参数。另外，查询参数的DNN必须是UE签约的DNN，否则该查询请求会失败，UDM直接回复："404 Not Found"。如果SMF收到AMF的PDU会话建立请求中DNN选择模式是通配DNN，SMF也需要在查询参数中包含通配DNN，这样SMF下载签约数据时也会下载通配DNN的会话签约数据。

从上面这段话里，我们就会更深入的理解AM签约数据中为什么包含签约DNN列表：subscribedDnnList，如下图。其作用除了在注册时AMF判断是否有LADN可用之外，另一个作用就是AMF还要验证UE请求的DNN是否是签约DNN，以便于设置Nsmf_PDUSession_CreateSMContext Request请求的selMode字段。另外一点，通配DNN（星号“*”）是可以作为签约DNN保存在subscribedDnnList中。

响应消息：

如果UDM查询UE会话签约数据成功，返回：200 OK，消息体中携带UE的会话签约数据：SessionManagementSubscriptionData。数据以切片为单位返回，即：每个切片返回一套SessionManagementSubscriptionData。

下面我们看一下会话签约数据有哪些，SessionManagementSubscriptionData定义如下：

从上面的数据定义可以看出来，S-NSSAI是必选参数，其下可以有一个或者多个DNN，每个DNN下会包含PDU会话的关键参数：PDU会话的类型、SSC模式、是否允许4/5G切换、sessionAMBR等等非常重要的参数。这些参数我们知道从哪里得到的，对于后面理解QoS Flow非常有帮助。

重点IE介绍：

- dnnConfigurations

该字段下包含PDU会话的关键参数，下面详细介绍各个签约数据的作用：

- pduSessionTypes

包含缺省的和允许的PDU会话类型。5G中共定义了5种PDU会话类型："IPV4"、"IPV6"、"IPV4V6"、"UNSTRUCTURED"、"ETHERNET"。

- sscModes

PDU会话的SSC Mode，共三种：SSC Mode 1、SSC Mode 2、SSC Mode 3.

- iwkEpsInd

指示PDU会话是否允许与4G进行互操作。如果没有该值，表示不允许与4G互操作。

- 5gQosProfile

PDU会话关联的5G QoS参数，包含缺省的5QI、缺省的ARP、及5QI优先级。5QI的优先级取值范围为1～127，1的优先级最高，127优先级最低。

- sessionAmbr

每个PDU会话中所有的非GBR QoS流共享的最大聚合上行链路和下行链路比特率，也就是上行和下行比特率取和不能超过该值。

- 3gppChargingCharacteristics

该参数在切片一级和DNN一级均有相应的计费特性参数，他们的有效范围不一样，需要注意。

- staticIpAddress

用户签约的静态IPv4或者IPv6地址，也可以同时签约IPv4和IPv6地址。

- upSecurity

指示PDU会话的用户面数据加密和完整性保护安全策略。该参数是在PDU会话级别生效的，即：如果启用了安全策略，PDU会话中的所有业务都会完整性保护或者加密。是否启用安全策略的选项共有三个："REQUIRED"、"PREFERRED"、"NOT_NEEDED"。

- pduSessionContinuityInd

指示UE进出NB-IoT网络时PDU会话的处理方法。共有三个取值："MAINTAIN_PDUSESSION"、"RECONNECT_PDUSESSION"、"RELEASE_PDUSESSION"。如果没有签约该信息，网元会使用本地定义的策略执行相关操作

- niddNefId

该DNN下提供NIDD服务的NEF ID。

- niddInfo

用于SMF-NEF Connection的信息。

- redundantSessionAllowed

指示该PDU会话是否允许存在冗余PDU会话。如果没有签约，表示不允许。冗余PDU会话用于可靠通信的场景。

- atsssAllowed

指示该DNN是否支持ATSSS功能，即：该DNN建立的会话是否允许多接入。

- secondaryAuth

指示该DNN建立的PDU会话是否需要进行二次鉴权。如果没有签约二次鉴权，默认不进行二次鉴权，但是具体是否需要鉴权最终由SMF决定。

- dnAaaIpAddressAllocation

该字段说明SMF在为UE建立PDU会话的时候是否需要从DN-AAA server请求IP地址。

- dnAaaAddress

用于二次鉴权和授权的DN-AAA server的IP地址。

- odbPacketServices

运营商定义的分组服务限制（Operator Determined Barring for Packet Oriented Services）。该参数在AM签约数据和SM会话管理签约数据中都存在，区别是：AM签约数据中odbPacketServices改变时，AMF会执行相关的PDU会话动作，如释放现存的PDU会话（existing PDU session）；而SM签约数据中OdbPacketService的改变不会触发SMF释放PDU会话。

- expectedUeBehaviourList

UE行为相关的信息，如：识别UE静止或者移动状态；指示UE处于CM-CONNECTED状态用于数据发送的时长等等。

- 3gppChargingCharacteristics

计费特性，详见TS 32.255。

（2）签约数据订阅

SMF签约数据的订阅（）和1.1.2.14c章节一样，所不同的只是订阅的签约数据不一样。

签约数据订阅Nudm_SDM_Subscribe Request消息中体中包含的数据类型为：SdmSubscription，其中两个关键信息是callbackReference、monitoredResourceUris。

- callbackReference字段包含的信息SMF用于接收订阅通知的URI，也就是如果用户的会话签约数据发生变化了，UDM调用的就是callbackReference包含的地址。

- monitoredResourceUris字段包含的信息是SMF想订阅的签约数据的资源URI，比如：SMF订阅会话管理的签约数据，该字段包含的内容就是：{apiRoot}/nudm-sdm/<apiVersion>/{supi}/sm-data，其内容和SMF下载的签约数据的资源URI是一样的。

响应消息：

UDM发送给SMF的响应消息为：Nudm_SDM_Subscribe Response。如果订阅信息正常创建，会返回：201 Created，其中包含UDM接受的SdmSubscription数据类型。

另一个需要注意的是该响应消息包含Location消息头，其中包含UDM创建的订阅资源URI，也就是UDM中使用该资源URI来标识该UE的订阅，格式如下：

http://[2409:8000:5003:104:5::2001]:80/nudm-sdm/v1/imsi-460000000000000/sdm-subscriptions/55fd3b00a6941d28

下图是响应消息的内容：

SMF获取签约数据和AMF一样，如果SMF和UDM都支持在订阅中获取签约数据的功能特性的话，SMF可以直接通过订阅数据来下载签约数据。

SMF收到签约数据后，会根据签约数据对的UE的请求进行处理：

（1）如果UE的PDU会话建立请求中Request Type为"existing PDU Session"，此时，SMF不会为UE创建新的SM Context，只是把原来的会话上下文进行更新。

（2）如果Request Type为" Initial request"，并且在Nsmf_PDUSession_ CreateSMContext Request消息中包含Old PDU Session ID，SMF根据Old PDU Session ID来识别现存的PDU Session（existing PDU Session）并进行释放。

（3）SMF会检查UE请求的有效性，如：UE的请求是否是签约数据允许；UE的请求是否违反SMF本地配置的策略；如果网络为UE选择的DNN是LADN，SMF需要判断UE处于LADN的服务区（AMF不直接判断，而是根据AMF发送的请求中包含的"UE presence in LADN service area"标记），如果AMF没有提供该信息，SMF会默认UE不在LADN的服务区中；

（4）SMF根据签约数据决定能否某个PDU会话创建冗余PDU会话，或者SMF根据自身能力判断是否支持冗余PDU会话。如果SMF不能创建冗余PDU会话，会根据本地数据配置决定建立没有冗余的PDU会话，还是直接拒绝UE的会话建立请求。

经过一系列处理后，SMF最终决定是否接受UE的PDU会话创建请求。