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

深度解析 3GPP TS 28.552：5.14 ECS Measurements (5G边缘智能的“调度中心”)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.14 Performance measurements for ECS”的核心章节，旨在为读者提供一个关于5G边缘计算支持功能（ECS）性能测量的全景解析。

引言：AR购物应用的“后台总指挥”

在解读EES测量时，我们解决了AR购物应用“找不到游戏”和“游戏未上架”的问题。现在，我们面临一个新的挑战。一位用户反馈，他在“魔方大厦”里成功发现了“AR寻宝”游戏，点击“开始体验”后，应用却长时间加载，最终提示“服务开通失败”。

“王哥，这次EES的测量数据完全正常，”小林汇报道，“DIS.EasDisSucc（发现成功）计数正常，说明‘应用商店’已经成功地为用户匹配到了最近的边缘服务器（EAS）。但为什么用户还是用不了呢？”

老王在核心网架构图上，将AMF、SMF、PCF与EES连接的中心点——ECS (Edge Computing Support Function, 边缘计算支持功能)——高亮了出来。“小林，EES是‘本地市场’，它只负责‘牵线搭桥’。但最终要让用户和边缘应用‘成功牵手’，需要核心网这位‘大家长’的批准和调度。ECS，就是这位‘大家长’派驻在边缘计算领域的‘总指挥’。”

“当用户决定使用一个边缘服务时，请求会送到ECS这里。ECS需要协调AMF、SMF、PCF等多个部门，为这次边缘会话办理一系列复杂的手续：检查用户策略、选择边缘UPF、下发流量路由规则……任何一个环节出错，都会导致‘服务开通失败’。用户看到的加载转圈，背后可能就是ECS在核心网内部的‘公文旅行’遇到了阻碍。”

他将TS 28.552切换到5.14节。“‘Performance measurements for ECS’，这一节就是对这位‘后台总指挥’工作效率的审计报告。它监控着边缘生态系统的两大核心后台流程：EES的注册管理和服务的最终开通。今天，我们就来学习如何通过这些测量，确保边缘应用的‘最后一公里’——服务开通流程，能够畅通无阻。”

1. “分店”的备案管理：EES Registration (5.14.1)

在一个大型网络中，可能会部署多个EES，每个EES负责一个地理区域的边缘应用。这些EES“分店”要想被核心网这位“总公司”所认可和调度，就必须先到ECS这里进行“备案”。

5.14.1.1 Number of registration requests (RM.EesRegReq) a) This measurement provides the number of EES registration requests … received by the ECS. c) On receipt by the ECS from the EES of EES Registration Request.

5.14.1.2 Number of successful registrations (RM.EesRegSucc) c) On transmission of EES Registration Response … by the ECS to the EES that sent the registration request.

1.1 深度解析

RM.EesReg... (Registration Management) 这组测量监控的是EES向ECS的注册流程。

• 测量对象: EES实例向ECS发起的注册事件。
• Req (请求数): ECS收到了多少次来自EES的注册请求。
• Succ (成功数): ECS成功为EES建立档案并返回成功的响应次数。
• 物理意义: EES注册成功率 = Succ / Req，是衡量整个边缘计算生态系统可管理性的基础。如果一个新上线的EES无法成功在ECS注册，那么核心网将完全“看不见”这个“应用商店”以及它所管理的所有应用，导致整个区域的边缘服务瘫痪。

1.2 场景化应用：确保边缘生态的完整性

在“魔方大厦”所在的CBD区域，运营商新部署了一个EES实例，专门服务该区域的商业楼宇。 通过监控ECS上的RM.EesRegReq和RM.EesRegSucc，运维团队可以实时确认这个新的EES是否成功地被纳入了核心网的统一管理视图。如果注册失败，就需要立刻排查ECS与EES之间的网络连通性、安全证书或配置参数问题。

2. “服务下单”的最终裁决：Service Provisioning (5.14.2)

这是ECS最核心的职能，也是解决用户“服务开通失败”问题的关键。当EEC（用户客户端）通过一系列流程，最终向核心网发起一个使用特定边缘服务的请求后，这个请求最终会落到ECS这里进行处理。

5.14.2.1 Number of service provisionig requests (SP.SerProvReq) a) This measurement provides the number of Service provisioning requests … received by the ECS. c) On receipt by the ECS from the EEC of Service provisioning request.

5.14.2.2 Number of successful discovery (SP.SerProvSucc) a) This measurement provides the number of successful Service provisioning request at the ECS. c) On transmission of Service provisioning response … by the ECS to the EEC that sent the provisioning request.

2.1 深度解析

SP.SerProv... (Service Provisioning) 这组测量监控的是边缘服务的开通流程。

• Req (请求数): ECS收到了多少次来自用户（逻辑上通过EEC）的服务开通请求。这是边缘业务实际使用意图的总量。
• Succ (成功数): ECS成功地完成了所有后台协调工作，并向用户返回成功响应的次数。
• 物理意义: 服务开通成功率 = Succ / Req，是衡量用户从“发现应用”到“真正用上应用”这一关键转化漏斗的最终效率。它是评估端到端边缘业务可用性的核心KPI。

2.2 场景化诊断：“服务开通失败”的根因分析

小林调取了“魔方大厦”区域ECS的服务开通测量数据，发现SP.SerProvSucc的成功率在高峰时段下降到了85%，与用户的投诉情况吻合。

“王哥，ECS的服务开通确实出了问题。但这只是‘结果’，我们怎么知道具体是哪个‘后台部门’的‘手续’没办下来呢？”

老王解释道：“ECS的失败，本身没有cause码。但ECS的失败，必然是由于它与其他NF交互失败导致的。所以，我们需要进行关联分析。”

ECS在服务开通过程中，主要会与以下几个NF交互：

1. PCF: 获取该用户的边缘业务策略，确认其是否有权限使用该服务。
2. SMF: 指示SMF为该PDU会话选择一个靠近EAS的边缘UPF，并下发相应的流量路由规则（PDR）。
3. AMF: 可能需要通过AMF获取UE的最新位置或状态信息。

小林立刻关联了同一时间段，PCF和SMF的性能数据：

• PCF: PA.PolicySMAssoSucc（SM策略关联成功率）正常。
• SMF: SM.PduSessionModSmfSucc（SMF发起的会话修改成功率）出现了明显的下降，失败原因主要是UPF_SELECTION_FAILURE。

“真相大白！”小林将故障链条拼接完整，“1. 用户请求开通AR服务，请求到达ECS。2. ECS向PCF查询策略，成功。3. ECS指示SMF修改PDU会话，以将流量路由到边缘。4. SMF在执行修改时，无法找到一个合适的边缘UPF，导致会话修改失败。5. SMF向ECS返回失败。6. ECS最终向用户返回‘服务开通失败’。”

最终结论： 问题根源在于SMF的边缘UPF选择策略或边缘UPF自身的资源/状态。可能是该区域的边缘UPF过载，或者SMF的配置中没有正确包含这个边缘UPF作为可选资源。优化方向立刻变得清晰：检查SMF的UPF选择配置和边缘UPF的负载情况。

结论：ECS测量——串联边缘生态的“神经中枢”

通过对ECS性能测量的学习，我们深入了5G边缘计算架构的“后台总指挥部”。ECS虽然不直接处理用户数据，但它在控制面的“运筹帷幄”，决定了整个边缘业务流程能否顺畅地运转。

1. 生态系统的“根目录” (EES Registration): ECS通过管理EES的注册，确保了核心网能够“看到”并“管理”所有的边缘“应用商店”，这是整个边缘生态可管可控的基础。
2. 端到端业务的“闭环者” (Service Provisioning): ECS负责协调核心网的多个NF，完成从业务请求到数据面路径建立的“最后一公里”。服务开通成功率，是衡量边缘业务端到端可用性的最终、也是最全面的指标。
3. 故障定界的“中枢”: ECS的性能测量（特别是失败计数），是进行核心网内部故障关联分析的起点。通过将ECS的失败与PCF、SMF、AMF等相关NF的失败原因进行关联，可以精准地定位出复杂业务流程中的故障环节。

如果说EES是面向用户和应用的“前台”，那么ECS就是连接这个前台与核心网强大后台的“神经中枢”。对ECS进行有效的性能监控，是确保5G边缘智能生态从一个个孤立的“应用岛屿”，真正融合成一个协同工作、高效运转的“数字大陆”的关键。

---

FAQ 环节

Q1：ECS (Edge Computing Support Function) 和 EES (Edge Enabler Server) 必须部署在一起吗？ A1：不一定。它们是逻辑上独立的网络功能，可以根据网络规划进行灵活部署。通常，EES会更靠近网络边缘，可能与边缘UPF和EAS部署在同一个边缘数据中心（EDC），因为它需要管理该区域的本地应用。而ECS作为核心网的一部分，通常会部署在更中心化的位置，以便与核心网的其他NF（AMF, SMF, PCF等）进行高效的交互。一个ECS可以同时管理多个分布在不同区域的EES。

Q2：Service Provisioning的成功指标为什么叫successful discovery？ A2：这是一个很好的细节问题，反映了规范定义的严谨性。一次完整的服务开通，涉及非常复杂的后台交互。从ECS的视角来看，它向外（如向PCF、SMF）发出的请求，本质上也是一种“服务发现”——“我需要一个策略服务来处理这个请求”、“我需要一个会话管理服务来修改这个PDU会话”。当所有这些依赖的服务都被成功地“发现”并调用完成后，整个服务开通流程才能被视为成功。因此，用successful discovery来命名，更能体现其作为“协调员”，成功地发现了并利用了所有必需的后端服务来完成任务的本质。

Q3：ECS测量中为什么没有像EES那样，对EEC（用户客户端）的注册进行测量？ A3：因为在3GPP架构中，EEC的注册是直接与EES交互的，这个过程对于ECS来说是透明的。ECS关心的是更高层级的实体注册，即EES作为服务提供方，如何向ECS进行注册和备案。可以这样理解：ECS是“商场管理办公室”，它只需要管理好每个“店铺”（EES）的入驻手续。而每个“顾客”（EEC）进入哪个“店铺”登记会员，是店铺自己的事，管理办公室不直接干预。

Q4：如果SP.SerProvSucc（服务开通成功率）很低，我应该从哪里开始排查？ A4：排查应该遵循ECS的交互链条，由近及远：

1. 检查ECS自身: 查看ECS的日志，确认它收到了请求，并看它是因为什么原因判定失败的。
2. 检查ECS → PCF链路: 查看PCF侧的PA.PolicySMAsso...（SM策略关联）或PAU.Sm...（SM策略授权）等测量项，看是否存在策略请求失败。
3. 检查ECS → SMF链路: 这是最常见的故障点。查看SMF侧的SM.PduSessionModSmf...（会话修改）测量项，特别是Fail.cause，看是否因为UPF选择失败、与PCF交互失败等原因导致修改不成功。
4. 检查ECS → AMF链路: 查看AMF的测量，确认UE是否处于正常的连接状态，位置信息是否准确。 通过这样逐环节的关联分析，通常可以快速定位到故障根源。

Q5：这些ECS/EES测量，和我们之前学的NEF（网络能力开放功能）有什么关系？ A5：它们在能力开放的生态中扮演着不同但可能重叠的角色。NEF是一个通用的能力开放网关，它可以开放各种网络能力（位置、QoS、监控等）给外部的AF。而ECS/EES是专门为边缘计算这个特定场景设计的一套更完整、更体系化的解决方案。 在实际部署中，AF（如AR应用后台）与边缘网络的交互，可能既会用到NEF，也会用到ECS/EES。例如，AF可能通过NEF向PCF请求影响流量路由（这是通用能力），而这个策略的最终执行，可能需要ECS协调SMF选择一个边缘UPF来完成（这是边缘计算的特定流程）。它们的测量项也是互补的：NEF的测量关注的是API调用的成功率，而ECS/EES的测量更关注端到端边缘业务流程的成功率。