51学通信

深度解析 3GPP TS 28.552：5.9 NEF Measurements (5G网络的“万能接口”与“能力开放引擎”)

16分钟阅读

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

深度解析 3GPP TS 28.552：5.9 NEF Measurements (5G网络的“万能接口”与“能力开放引擎”)

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

引言：打车App的“智能派单”革命

“王哥，你看这个新功能！”小林兴奋地向老王演示着一款打车App的内测版，“它现在能在我下车前30秒，就提前把我的目的地信息告诉商场的停车场系统，为我预留好车位。还能根据我当前的网络情况，动态调整行程分享视频的清晰度。太智能了！它是怎么知道我的网络情况和即将到达目的地的？”

老王指着5G核心网架构图上一个特殊的网元——NEF (Network Exposure Function, 网络能力开放功能)。“小林，你看到的这些‘智能’，背后是5G网络正在发生的一场深刻革命：从一个封闭的通信管道，向一个开放的能力平台的转变。而NEF，就是这场革命的‘震中’和‘总开关’。”

“NEF就像是5G核心网的‘万能API网关’和‘首席外交官’，”老王解释道，“它将网络内部复杂的能力，如位置信息、QoS保障、网络状态监控等，安全、可控地‘翻译’并‘开放’成开发者（如打车App的后台服务器AF）能够理解和调用的标准化API接口。打车App之所以能提前预留车位，正是因为它通过NEF，向网络订阅了你的‘即将到达目的地’事件。”

他将TS 28.552切换到5.9节。“‘Performance measurements for NEF’，这一节就是对这位‘首席外交官’工作绩效的全面考核。它监控着每一次外部应用与网络内部能力之间的交互，从‘信息触发’到‘数据管理’，再到‘策略协商’。今天，我们就来学习如何通过这些测量，确保5G这张开放的大网，能够稳定、高效地赋能千行百业的数字化创新。”

1. “网络听我说”：Application Triggering (应用触发) (5.9.1)

这是NEF最基础也最常用的能力之一。它允许一个经过授权的AF，请求网络向一个或多个UE发送一个“触发信息（Trigger）”。UE收到后，可以被唤醒并发起与AF的通信。

5.9.1.1 Number of application trigger requests (AT.AppTriggerReq) c) Receipt of an Nnef_Trigger_Delivery request by the NEF from AF…

5.9.1.2 Number of application trigger requests accepted for delivery (AT.AppTriggerAcc) c) Transmission of Nnef_Trigger_Delivery response by the NEF to AF indicating the application trigger request has been accepted for delivery to the UE…

5.9.1.3 Number of application trigger requests rejected for delivery (AT.AppTriggerRej.ErrorCode) c) …increments the relevant subcounter per error code…

5.9.1.4 Number of application trigger delivery reports (AT.AppTriggerRej.DeliveryResult)

  • 深度解析: AT.AppTrigger... (Application Triggering) 这组测量监控了应用触发的全流程。

    • Req (请求数): NEF收到了多少次来自AF的触发请求。
    • Acc (接受数): NEF在检查了AF的权限、请求的合法性后，接受了这个请求，并准备将其转发给核心网内部（如SMF/AMF）。
    • Rej.ErrorCode (拒绝数): NEF直接拒绝了AF的请求。按ErrorCode细分，可以知道拒绝的原因，如“AF未授权”、“请求参数错误”等。
    • DeliveryResult (投递报告): 这是最终的闭环。在NEF将触发信息递交给核心网后，核心网会尝试将其送达UE，并将最终的投递结果（成功、失败）返回给NEF。NEF再将这个结果通知给AF。这个测量项就统计了NEF收到的这些最终投递报告的数量，并按DeliveryResult细分。

  • 场景化应用：智能门锁的“远程开锁” 用户在App上点击“远程开锁”，App后台（AF）向NEF发起一次应用触发，请求唤醒家里的智能门锁（UE）以执行开锁指令。

    1. AT.AppTriggerReq +1。
    2. NEF鉴权成功，接受请求，AT.AppTriggerAcc +1，并将触发信息转发给AMF。
    3. AMF通过寻呼唤醒门锁，并将触发信息送达。
    4. 门锁成功开锁，并将执行结果上报。
    5. 最终，NEF收到一个“投递成功”的报告，AT.AppTriggerRej.DeliveryResult_Success +1。 应用触发成功率 = (成功投递报告数) / (接受的请求数)，是衡量这项能力开放可靠性的关键KPI。

2. 应用数据的“户籍警”：PFD Management (5.9.2)

PFD (Packet Flow Description) 是一组规则，用于描述一个应用的数据流特征（如服务器IP地址、端口、协议等）。AF可以通过NEF，将自己应用的PFD“注册”到网络中（最终由PCF管理，SMF使用）。这样，UPF就能识别出这个应用的数据流，并对其执行特殊的策略（如计费、路由、QoS）。

5.9.2.1 PFD creation (PFD创建) 5.9.2.2 PFD update (PFD更新) 5.9.2.3 PFD deletion (PFD删除) 5.9.2.4 PFD fetch (PFD获取) 5.9.2.5 PFD subscription (PFD订阅)

  • 深度解析: PFD...这一整套测量，监控了PFD的增删改查和订阅的全生命周期管理。

    • Create/Update/Delete: 监控AF通过NEF管理其PFD的成功/失败情况。
    • Fetch: 监控SMF等NF通过NEF查询PFD的性能。
    • Subscription: 监控SMF等NF向NEF订阅PFD变更通知的性能。

  • 场景化应用：视频App的“免流”服务 运营商与某视频App（AF）合作推出“定向免流”套餐。

    1. 视频App的AF，通过NEF，将其所有视频服务器的IP地址和端口，以PFD的形式创建 (PFD.CreateReq/Succ) 到网络中。
    2. 当用户打开视频App时，SMF会向NEF订阅 (PFD.SubscribeReq/Succ) 该应用的PFD变更。
    3. SMF获取到PFD后，将其转化为N4规则下发给UPF。
    4. UPF根据这些规则，识别出属于该视频App的流量，并对其执行特殊的计费策略（如不计费）。 PFD Management测量的成功率，直接关系到“定向免流”、“加速包”等精细化运营策略能否成功落地。

3. 更广阔的能力开放：NIDD, AF traffic influence, External parameter provisioning…

除了应用触发和PFD管理，5.9节还为NEF提供的其他多种能力开放定义了测量。

  • NIDD configuration/service related measurements (5.9.3 & 5.9.4): NIDD (Non-IP Data Delivery) 是5G为物联网设计的非IP数据传输能力。这组测量监控AF通过NEF，进行NIDD配置和收发非IP数据的性能。

  • AF traffic influence related measurements (5.9.5): 这是我们之前在PCF章节提到的“智能交通”场景的核心。AF通过NEF，向PCF/SMF请求影响PDU会话的路由（如将流量疏导到边缘UPF）。这组测量监控的就是这类流量影响请求的创建、更新、删除的成功率。

  • External parameter provisioning related measurements (5.9.6): 允许AF向网络提供一些“外部参数”，如预期的UE行为（某车队即将进入某区域）、5G VN（虚拟专网）的用户组信息等。这组测量监控这些“情报”的提供成功率。

  • AF session with QoS (5.9.10): 允许AF为一个应用会话，直接向网络请求特定的QoS保障。这组测量监控这类“QoS预约”请求的创建、修改、撤销的成功率。

结论：NEF测量——5G生态繁荣的“催化剂”与“守护神”

通过对NEF性能测量的学习，我们打开了通往5G应用生态的“上帝视角”，理解了网络是如何从一个封闭的系统，走向一个开放的平台的。

  1. 连接“应用”与“网络”: NEF是AF与5G核心网内部功能之间的标准化、安全的中间件。它屏蔽了核心网内部的复杂性，为上层应用提供了一致的API接口。
  2. 监控“能力开放”的可靠性: NEF的测量体系，全面覆盖了从基础的应用触发，到精细化的PFD管理，再到智能化的流量影响和QoS协商等多种能力开放场景。
  3. 保障“开发者体验”: 这些测量的成功率，直接关系到第三方开发者接入和使用5G网络能力的体验。一个高成功率、低失败率的NEF，是吸引广大开发者、催生杀手级5G应用、繁荣整个5G生态的“催化剂”。
  4. 确保“网络安全”: 通过对请求的来源、权限进行审计（如AppTriggerRej.ErrorCode_Unauthorized），NEF的测量也扮演了保护网络免受非法或恶意访问的“守护神”角色。

NEF及其测量体系，是5G“赋能万业”承诺的技术兑现。它将网络的原子能力，如连接、位置、QoS、策略，重新组合成一个个强大的“乐高积木”，交到千行百业的创新者手中，让他们去构建一个真正万物互联、智能涌现的未来。

FAQ 环节

Q1：NEF和AF是什么关系？NEF是核心网的一部分吗？ A1：NEF是5G核心网的标准网元之一，是3GPP定义的“能力开放接口”。而AF（应用功能）通常不属于核心网，它是指代任何需要与5G网络进行交互的第三方应用服务器或平台，例如打车App的后台、视频网站的服务器、企业的物联网平台等。NEF扮演着AF与5G核心网内部NF（如PCF, SMF, UDM）之间的“安全代理”和“协议翻译官”的角色。

Q2：NEF和PCF在策略控制上如何分工？ A2：它们是“提议者”和“决策者”的关系。AF通过NEF向PCF“提议” 策略。例如，AF可以请求“为我的游戏用户提升网络优先级”。而PCF是最终的“决策者”，它会结合AF的提议、用户的签约数据、当前网络状态等多种信息，做出最终的策略判决，并生成PCC规则下发给SMF去执行。NEF是AF表达意图的通道，PCF是网络实现策略的大脑。

Q3：什么是PFD (Packet Flow Description)？它和QoS Flow有什么关系？ A3：PFD是一组用于识别应用数据流的“指纹信息”，它定义了某个应用的五元组（或三元组）信息，如服务器IP地址、端口号等。PFD的作用是让UPF能够从海量的IP包中，识别出“这是微信的视频流”、“这是抖音的直播流”。而QoS Flow则是网络为已被识别出的数据流所提供的服务承诺。流程是：AF通过NEF提交PFD → PCF制定策略 → SMF将PFD和对应的QoS策略（5QI等）下发给UPF → UPF根据PFD识别出数据流，然后根据QoS策略对其进行调度、限速、计费等处理。PFD负责“看”，QoS Flow负责“办”。

Q4：NIDD (Non-IP Data Delivery) 主要用于什么场景？ A4：NIDD主要用于特定的物联网（IoT）场景。在这些场景中，终端设备可能非常简单、功耗极其敏感，它们不需要完整的IP协议栈。它们上报的数据可能只是几个字节的传感器读数。NIDD允许这些设备将它们的“非IP格式”的数据，通过5G网络，安全地传输到一个指定的AF。这个过程中，UE无需获取IP地址。NEF在其中扮演了核心角色，它为AF提供了接收这些非IP数据的API接口。

Q5：这些NEF的测量对于开发者来说是否可见？ A5：3GPP TS 28.552定义的这些测量项，主要是供运营商内部进行网络性能监控和故障诊断使用的。但是，运营商可以基于这些内部测量，加工和提炼出面向开发者的服务质量报告或API调用仪表盘。例如，运营商可以在其开放能力平台门户上，向开发者展示他所开发的App的“API调用成功率”（基于AppTriggerSucc等计算）、“PFD创建成功率”等。这种数据开放，能帮助开发者更好地优化他们的应用，并提升他们对运营商网络能力的信任。

关系图谱