51学通信

深度解析 3GPP TS 28.552：5.3 SMF Measurements (5G网络的“会话掌舵人”)

19分钟阅读

好的，我们继续进行系列的下一篇深度解读。

深度解析 3GPP TS 28.552：5.3 SMF Measurements (5G网络的“会话掌舵人”)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.3 Performance measurements for SMF”的核心章节，旨在为读者提供一个关于5G网络会话管理核心（SMF）的性能测量全景解析。

引言：从“入场券”到“专属包厢”

“王哥，上次我们分析AMF的性能，确保了用户能顺利‘买票进场’（完成注册）。但‘未来银行’App的用户又反映了新问题，”小林指着一份报告，“他们说，即使用户成功登录了App（网络已连接），但在进行大额转账时，那个需要更高安全等级和带宽保障的‘专属金融通道’，有时候会建立失败，或者建立过程特别慢。这是为什么？”

老王在核心网架构图上，圈出了AMF旁边的另一个关键网元——SMF (Session Management Function, 会话管理功能)。“小林，AMF卖的是‘入场券’，保证了用户能进入5G这座‘大剧院’。但用户要看什么剧目、坐什么位置，是坐普通座、沙发座，还是需要安保的VIP包厢，这些都不是AMF说了算。负责管理这一切的，是剧院的‘场务总监’——SMF。”

“用户的每一次上网、每一次通话、每一次云游戏，都需要向SMF申请一个PDU会 G话，这就像申请一个‘观影包厢’。SMF会根据用户的‘票种’（签约数据）、剧院的‘规定’（策略）和当前的‘空座情况’（网络资源），为他分配一个合适的‘包厢’（如IP地址、UPF路径），并规定好‘包厢’里的服务标准（QoS Flow）。‘未来银行’的‘专属金融通道’建立失败，问题很可能就出在SMF这位‘场务总监’的调度上。”

他将TS 28.552切换到5.3节。“‘Performance measurements for SMF’，这一节就是对这位‘场务总监’的全面绩效考核。它监控着每一次‘包厢申请’（PDU会话建立）、‘服务升级’（会话修改）和‘离场清扫’（会话释放）的全过程。今天，我们就来学习如何通过这些测量，确保每一位用户，特别是VIP用户，都能快速、准确地进入他们的‘专属包厢’。”

1. “包厢”的占用情况：Session Management (5.3.1 - 整体统计)

在深入具体流程之前，我们首先要了解整个“剧院”的“上座率”。

5.3.1.1 Number of PDU sessions (Mean) (SM.SessionNbrMean.SNSSAI) a) This measurement provides the mean number of PDU sessions. c) The measurement is obtained by sampling at a pre-defined interval, the number of PDU sessions established by SMF, and then taking the arithmetic mean.

5.3.1.2 Number of PDU sessions (Maximum) (SM.SessionNbrMax.SNSSAI) (测量方法为采样取最大值)

  • 深度解析: SM.SessionNbr... (Session Management) 这组测量是评估SMF容量压力的基础，与AMF的用户数测量逻辑完全相同。

    • Mean (平均数): 统计周期内，由该SMF实例管理的、处于激活状态的PDU会话的平均数量。
    • Max (最大数): 统计周期内，并发PDU会话数的峰值。
    • 按S-NSSAI细分: 我们可以精确知道，某个切片（如“专属金融通道”切片）平均/峰值承载了多少个PDU会话，这对于切片级的容量规划和资源监控至关重要。

  • 场景化应用： 如果SM.SessionNbrMax逼近了SMF实例支持的会话容量上限，就可能导致新的PDU会话建立请求被拒绝。这是判断SMF是否需要扩容或进行负载均衡的最直接依据。

2. “包厢”的申请与审批：PDU session creation (5.3.1.3 - 5.3.1.5)

当“未来银行”App需要为大额转账开启“专属金融通道”时，AMF会根据UE的请求，向NRF查询并选择一个合适的SMF，然后向该SMF发送Nsmf_PDUSession_CreateSMContext Request消息。

2.1 申请的接收与分类

5.3.1.3 Number of PDU session creation requests (SM.PduSessionCreationReq.SNSSAI/.ReqType) c) On receipt by the SMF from AMF of Nsmf_PDUSession_CreateSMContext Request… Each PDU session requested to be created is added to the relevant subcounter per S-NSSAI and the relevant subcounter per request type. Where ReqType indicates the request type (e.g., initial request, initial emergency request) for the PDU session.

  • 深度解析: SM.PduSessionCreationReq 统计SMF收到的PDU会话建立请求总数。
    • 触发点: SMF收到来自AMF的CreateSMContext Request。
    • 关键过滤维度:
      • SNSSAI: 按切片统计。
      • ReqType (请求类型): 这是一个新的重要维度，用于区分不同性质的会话请求，如initial request（初始请求）、existing session（切换/移动场景下的会话移交）、emergency request（紧急会话请求）等。

2.2 审批的结果：成功与失败

5.3.1.4 Number of successful PDU session creations (SM.PduSessionCreationSucc.SNSSAI/.ReqType) c) On transmission by the SMF to AMF of Nsmf_PDUSession_CreateSMContext Response that indicates a successful PDU session creation…

5.3.1.5 Number of failed PDU session creations (SM.PduSessionCreationFail.cause) c) On transmission by the SMF to AMF of Nsmf_PDUSession_CreateSMContext Response that indicates a rejected PDU session creation… e) Where cause indicates the rejection cause for the PDU session.

  • 深度解析:
    • Succ (成功数): SMF成功完成了所有内部流程（如与PCF交互获取策略、选择UPF、分配IP地址、向UPF建立N4会话等），并向AMF发送了成功的CreateSMContext Response时，计数器加1。
    • Fail.cause (失败数及原因): SMF在上述任何环节失败，并向AMF发送了拒绝的Response时，按失败原因 (cause) 计数的子计数器加1。失败原因非常关键，例如：
      • USER_AUTHENTICATION_FAILED: 用户鉴权失败。
      • DNN_NOT_SUPPORTED_OR_NOT_SUBSCRIBED: 请求的数据网络名称（DNN）不被支持或用户未签约。
      • INSUFFICIENT_RESOURCES: 资源不足（如IP地址耗尽、UPF容量不足）。

2.3 场景化诊断：“专属金融通道”建立失败之谜

小林调取了金融专网切片的SMF数据，用于排查大额转账通道建立失败的问题。 PDU会话建立成功率 (金融切片) = (SM.PduSessionCreationSucc.SNSSAI_Finance) / (SM.PduSessionCreationReq.SNSSAI_Finance)

他发现成功率仅为90%。进一步查看SM.PduSessionCreationFail.cause的分布：

  • cause_DnnNotSupported: 占失败总数的85%。

“王哥，问题定位了！”小林指着数据，“绝大部分失败，都是因为SMF认为用户请求的DNN（数据网络名称）不被支持。‘未来银行’App在发起大额转账时，可能请求了一个特殊的、指向银行内部数据中心的DNN。我们的SMF或UPF上，很可能没有正确配置这个DNN的路由和策略！”

洞察： SMF的PDU会话建立测量，通过ReqType和cause这两个精细的维度，为我们提供了一个诊断业务接入问题的强大工具。它能清晰地告诉我们，是哪种类型的业务请求、因为什么具体的核心网内部原因而失败。

3. “包厢”服务的变更：PDU session modifications (5.3.1.6)

PDU会话建立后，其属性可能需要被修改。例如，用户从普通网页浏览，切换到高清视频，网络可能需要为其提升QoS。这个流程就是PDU会话修改。

5.3.1.6.1 Number of requested PDU session modifications (UE initiated) (SM.PduSessionModUeInitReq) 5.3.1.6.4 Number of requested PDU session modifications (SMF initiated) (SM.PduSessionModSmfInitReq) (以及它们各自的成功与失败测量)

  • 深度解析: 规范将修改流程清晰地分为两大类：

    1. UE发起的修改 (UeInit): UE主动请求修改QoS等。
    2. 网络发起的修改 (SmfInit): SMF根据PCF的策略变更指令，或核心网内部的其他触发条件，主动向UE下发修改指令。

    对这两种流程分别进行成功/失败的统计，有助于判断问题是出在UE的行为上，还是网络侧的策略执行上。

4. “散场”与“清扫”：PDU session releases (5.3.1.7)

当用户关闭应用或断开连接时，PDU会话需要被释放，以回收网络资源（如IP地址、UPF上的N4会话等）。

5.3.1.7.1 Number of released PDU sessions (AMF initiated) a) This measurement provides the number of released PDU sessions (initiated by AMF) at the SMF. c) …triggers the relevant subcounter per S-NSSAI and the relevant subcounter per cause…

  • 深度解析: 规范在这里重点关注由AMF发起的释放。因为UE或SMF主动发起的释放通常是“正常”流程（如用户主动关机），而由AMF发起的释放，则可能包含**“异常”**情况。
    • 触发原因 (cause): AMF可能因为检测到UE与RAN的连接丢失、用户去注册、切换到非3GPP接入时PDU会话需要重建等原因，而请求SMF释放会话。
    • 测量意义: 通过分析cause码，可以了解PDU会话中断的宏观原因。例如，如果大量会话释放的原因是“与RAN的连接丢失”，则说明无线侧可能存在严重问题。

5. “跨国观影”：Roaming Scenario Measurements (5.3.1.8 - 5.3.1.10 & 5.3.1.14 - 5.3.1.16)

规范还为漫游场景定义了专属的测量。特别是Home-Routed (HR) 漫游场景，即使用户身在海外，其数据流量仍需“绕回”归属地的UPF进行处理。

  • 深度解析:
    • ...in HR roaming scenario: 这组测量的主体是H-SMF（归属地SMF）。它统计的是，由V-SMF（拜访地SMF）代理发来的PDU会话建立请求的成功/失败情况。
    • MA PDU Session… in HR roaming scenario: MA PDU（多接入PDU会话）是ATSSS（接入流量切换、分流与疏导）特性的载体，允许UE同时使用3GPP和非3GPP（如Wi-Fi）接入。这组测量则进一步细化到漫游场景下，对这种更复杂的MA PDU会话的管理性能。

结论：SMF测量——5G业务多样性的“定海神针”

通过对SMF性能测量的全面学习，我们掌握了监控5G网络“会话管理中枢”的核心方法。SMF的测量体系，是保障5G业务多样性、灵活性和可靠性的“定海神针”。

  1. 会话容量监控 (SessionNbr): 是SMF的**“压力表”**，为核心网容量规划提供了最直接的数据。
  2. 会话建立流程 (Creation): 通过ReqType和cause的精细化维度，成为诊断业务接入失败根源的“手术刀”。
  3. 会话修改与释放 (Modification/Release): 监控了PDU会话的动态管理能力和生命周期健康度，确保了QoS的灵活性和资源的有效回收。
  4. 漫游与多接入场景: 专属的测量项，将监控能力延伸到了复杂的漫游和固移融合业务，保障了全球一致的服务体验。

SMF，作为5G核心网的“场务总监”，其每一次精准、高效的调度，都是用户一次流畅业务体验的开始。而SMF的性能测量，正是确保这位总监永远“在线”、永远“高效”的坚实保障。

FAQ 环节

Q1：SMF和AMF在PDU会话建立过程中是如何分工的？ A1：可以把它们比作“前台接待”和“客房经理”。AMF是“前台接待”，负责接待用户（UE），验证其身份，了解其基本需求（想用哪个切片）。然后，AMF会根据UE的需求，为他找到一位合适的**“客房经理”——SMF**，并将用户引荐给SMF。后续所有关于“房间”的具体事宜，如分配哪个房间（UPF和IP地址）、房间里提供什么服务（QoS Flow）、如何收费（PCF策略）等，都由SMF全权负责。

Q2：一个UE可以有多个SMF为它服务吗？ A2：是的。每个PDU会话都会由一个SMF来管理。一个UE可以同时建立多个PDU会话（例如，一个连接到互联网，一个连接到企业内网），而这两个PDU会话可以由不同的SMF实例来管理。这种灵活性，使得网络可以根据不同的DNN（数据网络名称）或S-NSSAI，将业务分发到功能或位置最优的SMF上，实现分布式、专业化的会话管理。

Q3：SM.PduSessionCreationFail.cause中的DNN_NOT_SUPPORTED失败，在实际中如何排查？ A3：这是一个非常具体的核心网配置问题。排查步骤通常是：1）核对UE请求： 首先确认UE或其应用请求的DNN字符串是否正确。2）检查SMF配置： 登录SMF的管理界面，检查其配置中是否包含了对该DNN的支持，包括该DNN允许关联的S-NSSAI、允许选择的UPF范围、IP地址池等。3）检查UPF/DNS配置： SMF在处理DNN时，可能需要通过DNS查询来解析DNN，以找到合适的UPF。需要检查DNS配置是否正确。4）检查用户签约数据： 在UDM/UDR中，检查该用户的签约档案里，是否包含了使用该DNN的权限。

Q4：为什么规范要区分UE发起的和SMF发起的PDU会话修改？ A4：这是为了区分**“用户需求驱动”和“网络策略驱动”的业务变更，从而进行更精准的性能评估和故障诊断。UE发起的修改，其成功率反映了网络对用户动态需求的响应能力**。如果这个成功率低，说明网络可能无法满足用户的QoS提升请求。而SMF发起的修改，其成功率则反映了网络策略执行的有效性。例如，如果PCF下发了策略要求降低某业务的带宽，但SMF执行修改失败，就意味着网络的主动管控能力存在问题。

Q5：Home-Routed（归属地路由）漫游是什么意思？为什么需要单独测量？ A5：Home-Routed漫游是指，即使用户漫游到海外，其所有的数据流量都必须通过拜访地网络，穿过国际链路，回到归属地网络的UPF，再从归属地网络访问互联网或企业专网。这种模式的好处是便于归属地运营商进行统一的计费、策略控制和安全审计。其缺点是路径长，时延大。为它定义专门的测量，是因为HR漫游场景下的PDU会话建立流程更复杂，涉及V-SMF和H-SMF之间的跨国信令交互。单独监控H-SMF的性能，可以帮助运营商评估其作为服务提供方，为漫游伙伴提供服务的能力，并诊断复杂的跨国信令问题。

关系图谱