好的，我们继续进行系列的下一篇深度解读。
深度解析 3GPP TS 28.552：5.15 EES & 5.14 ECS Measurements (5G边缘智能的“前哨站”与“调度中心”)
本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.15 Performance measurements for EES”和“5.14 Performance measurements for ECS”的核心章节，旨在为读者提供一个关于5G边缘计算生态系统中，应用注册、发现与服务开通流程的性能测量全景解析。
引言：AR购物应用的“寻路”之旅
在“魔方大厦”的AR导航应用大获成功后，商场决定进一步推出“AR寻宝购物”活动。用户打开App，就能看到虚拟的宝箱和商品优惠券悬浮在商场的各个角落。为了实现最低时延、最具沉浸感的体验，所有的AR渲染和内容分发，都由部署在大厦内部机房的边缘应用服务器 (EAS) 来完成。
“王哥，新活动上线后，我们收到了两类完全相反的投诉，”小林指着数据报告，一脸困惑，“一部分用户抱怨说，App启动后一直在转圈，根本‘找不到’AR寻宝游戏。另一部分开发者（为商场提供AR应用的ISV）则投诉说，他们昨天下午新上线的一个‘限时宝箱’活动，根本没有被用户发现，后台访问量为零。”
老王画了一张MEC（多接入边缘计算）的生态图：“小林，边缘计算是一个复杂的生态系统，参与者众多。有提供应用的开发者（EAS），有使用应用的用户（EEC），还有负责撮合他们的‘**应用商店’**和‘服务调度中心’。用户‘找不到’游戏，和游戏‘不被发现’，看似是同一个问题，但病根可能完全不同。”
他将TS 28.552切换到5.15和5.14节。“今天，我们要扮演的就是这个生态系统的‘市场管理员’。5.15节的EES (Edge Enabler Server) 测量，就是对边缘‘应用商店’的绩效考核。我们要检查，开发者的‘商品’（EAS）是否成功‘上架’（注册）？用户的‘逛店’请求（发现）是否得到了及时响应？”
“而5.14节的ECS (Edge Computing Support Function) 测量，则是对核心网‘服务调度中心’的效率审计。我们要看，当用户决定‘购买’（使用）一个边缘服务时，ECS能否成功地为他办理好所有的‘手续’（服务开通）。”
“通过这两套测量体系，我们就能精准定位AR购物应用的‘寻路’之旅，究竟是在‘应用商店’里迷了路，还是在‘服务调度中心’被卡住了。”
1. 边缘“应用商店”的绩效考核：EES Measurements (5.15)
EES是边缘生态的“前哨站”，所有边缘世界的交互，都始于这里。它负责两大核心职能：让应用能被找到，让用户能被识别。
1.1 应用的“上架”流程：EAS Registration (5.15.3)
一个新开发的“限时宝箱”AR应用（EAS）要想被用户发现，必须先到EES进行注册。
5.15.3.1
Number of registration requests(RM.EasRegReq) c) On receipt by the EES from the EAS of EAS Registration Request.
5.15.3.2
Number of successful registrations(RM.EasRegSucc) c) On transmission of EAS Registration Response … by the EES to the EAS that sent the registration request.
-
深度解析: 这组测量
RM.Eas...(Registration Management) 监控的是EAS的注册流程。Req(请求数): 统计EES收到了多少次来自边缘应用服务器的“上架申请”。Succ(成功数): 统计EES成功处理并确认了多少次“上架”。 EAS注册成功率 = Succ / Req，是衡量边缘生态应用供给侧健康度的基础。如果这个成功率低，意味着开发者无法顺利地将他们的创新应用发布到网络中。
-
场景化诊断：揭秘“限时宝箱”失踪之谜 小林查看了昨天下午EES的
RM.EasRegReq计数，发现确实有来自“限时宝箱”服务器的注册请求。但RM.EasRegSucc的计数却没有相应增加！这说明EES拒绝了这次注册请求。通过查询日志，发现原因是开发者提交的应用Profile中，服务区域的地理位置信息格式不正确，被EES校验为无效请求。问题定位成功：开发者配置错误。
1.2 用户的“进店”流程：EEC Registration (5.15.2)
当用户打开AR寻宝App时，其手机上的客户端（EEC）也需要向EES“报到”，进行注册，以便EES了解这个用户的身份和能力。
5.15.2.1
Number of registration requests(RM.EecRegReq) 5.15.2.2Number of successful registrations(RM.EecRegSucc) (此外还包括更新和去注册的测量)
- 深度解析: 这组测量监控的是EEC的注册流程。EEC注册成功率是衡量用户侧能否成功接入边缘生态的基础。如果用户连“进店报到”都失败了，后续的服务发现和使用就无从谈起。
1.3 “逛店寻宝”的核心：EAS Discovery (5.15.1)
用户注册成功后，App会向EES发起最关键的请求：“我当前在商场三楼中庭，请告诉我附近有哪些可用的AR寻宝游戏服务器？”
5.15.1.1
Number of discovery requests(DIS.EasDisReq) 5.15.1.2Number of successful discovery request(DIS.EasDisSucc) 5.15.1.3EAS discovery failure(DIS.EasDisFail.Cause)
-
深度解析: 这组测量
DIS.Eas...(Discovery) 监控的是EAS的发现流程。Req(请求数): EES收到的用户发现请求总数。Succ(成功数): EES成功地为用户匹配并返回了至少一个可用的EAS。Fail.Cause(失败数及原因): EES未能为用户找到任何合适的EAS。失败原因Cause的细分至关重要，规范（TS 23.558）中定义了多种Filter，例如：UeLocation: 因用户当前位置没有可用的EAS而失败。EasType: 因没有匹配用户请求的应用类型而失败。provider: 因没有匹配用户指定的应用提供商而失败。
-
场景化诊断：揭秘用户“转圈圈”之谜 小林查看了抱怨“找不到游戏”的那批用户的记录，发现他们的
DIS.EasDisReq请求，最终都导致了DIS.EasDisFail.Cause_UeLocation计数器的增加。 “王哥，问题清楚了，”小林分析道，“这批用户‘找不到游戏’，不是因为游戏没上架，也不是因为他们自己注册失败，而是因为在他们所在的那个特定位置，EES的‘应用地图’里，确实没有任何一个EAS能为他们服务！” 经过现场勘查，发现那是一个新建的VIP休息室，信号由一个新的室内微站覆盖，但网络规划时，忘记将这个新小区的Cell ID更新到EES的服务区数据库中。因此，EES错误地认为该区域是“服务盲区”。
2. 核心网“调度中心”的效率审计：ECS Measurements (5.14)
当EES成功地为用户找到了一个合适的EAS后，连接并不会直接建立。EES会将结果返回给核心网的ECS，由ECS来完成最终的服务开通（Service Provisioning）流程，包括与PCF、SMF等交互，确保用户的PDU会话能够被正确地路由到所选的边缘UPF和EAS。
5.14.1
EES Registration procedure related measurements(EES注册流程测量)
RM.EesRegReqRM.EesRegSucc
- 深度解析: 是的，你没看错，ECS的测量中也包含了对EES注册的监控。这是因为EES也需要向核心网（通过ECS）注册自己，让核心网知道“我在哪里，我负责哪个区域的应用商店”。ECS对EES的注册进行监控，是确保整个边缘生态系统能够被核心网正确发现和纳管的基础。
5.14.2
Service provisioning procedure related measurements(服务开通流程测量)
- 5.14.2.1
Number of service provisionig requests(SP.SerProvReq)- 5.14.2.2
Number of successful discovery(SP.SerProvSucc)
- 深度解析:
这组测量
SP.SerProv...(Service Provisioning) 是对ECS核心职能的考核。Req(请求数): 统计ECS收到了多少次来自EEC（经由核心网其他NF）的服务开通请求。Succ(成功数): 统计ECS成功协调各方，完成了服务开通过程的次数。这里的“成功”，在规范中的描述是“successful discovery”，暗示了服务开通过程中一个关键的成功标志是成功发现了所有需要的组件和服务。 服务开通成功率 = Succ / Req，衡量了从用户“选中商品”到“成功下单”这一关键转化步骤的效率。如果这个成功率低，即使EAS发现100%成功，用户依然无法使用边缘业务。失败可能的原因包括PCF策略拒绝、SMF无法建立到边缘UPF的路径等。
结论：为边缘智能生态的繁荣保驾护航
通过对“AR寻宝”应用故障的层层剖析，我们看到，5G边缘计算的性能保障，是一个涉及多方、多环节的复杂系统工程。TS 28.552为这个生态系统中的两大核心“中枢”——EES和ECS——提供了清晰的考核标准。
- EES测量体系 (5.15节)：像一个**“应用商店运营仪表盘”，它从应用侧（EAS）和用户侧（EEC）两个维度，监控了注册和发现流程的健康度。它是保障边缘生态“供给”与“需求”能够成功匹配**的基础。
- ECS测量体系 (5.14节)：像一个**“核心网调度中心效率报告”，它监控着边缘服务最终落地执行**的成功率。它是连接“边缘世界”与“核心网络”的桥梁，确保边缘的业务请求能够被核心网正确理解和实现。
这两套测量体系，共同为5G边缘智能生态的繁荣发展提供了标准化的性能保障框架。它们确保了无论是开发者还是用户，都能在这个生态中获得流畅、可靠的体验，推动着5G从一个“连接”的网络，真正走向一个“赋能”应用的平台。
FAQ 环节
Q1：EES和ECS是什么关系？它们都是必须部署的吗？ A1：EES和ECS在3GPP定义的边缘计算架构中扮演着不同但互补的角色。EES（边缘使能服务器）更靠近边缘，负责具体的边缘应用服务器（EAS）的注册和发现，可以理解为“本地市场的管理者”。而ECS（边缘计算支持功能）则更靠近核心网，负责从核心网层面协调和支持边缘服务的开通，可以理解为“中央市场的总协调员”。它们都是可选的功能实体。在一些简单的部署中，它们的功能可能被合并或由其他网元（如PCF、NEF）兼职实现。但对于大规模、跨区域的复杂MEC部署，独立的EES和ECS能够提供更清晰、更可扩展的架构。
Q2：EAS discovery failure的Cause_UeLocation失败，具体是什么原因导致的？
A2：这个失败原因意味着，EES根据UE上报的位置信息，在其数据库中找不到任何能够为该位置提供服务的EAS。具体原因可能包括：1）覆盖盲区： 该位置确实没有任何边缘服务器覆盖。2）数据库错误/过时： 如本文案例所示，新的小区或覆盖区域已经部署，但其标识（如Cell ID, TAI）没有被及时更新到EES的服务区列表中。3）UE定位不准： UE上报的位置信息本身有误，导致EES在错误的地方进行查找。4. 策略限制： 运营商或应用提供商可能配置了策略，禁止在该位置提供此项服务。
Q3：用户在进行EAS发现时，是如何告知EES自己的位置的？ A3：UE的位置信息可以有多种来源。在EEC向EES发起发现请求时，这个请求会途径核心网的AMF。AMF精确地知道UE当前的TAI（跟踪区标识）和Cell ID（小区ID）。AMF可以将这些信息提供给PCF，PCF再将其传递给ECS，最终到达EES。此外，UE自身也可以通过GNSS等定位能力，将更精确的地理坐标（如经纬度）作为请求参数的一部分，提供给EES。EES会综合利用这些不同精度的位置信息，来进行最精准的EAS匹配。
Q4：为什么需要一个单独的Service Provisioning（服务开通）测量？EAS发现成功了，不就代表能用了吗？
A4：不代表。EAS发现成功，仅仅意味着EES为用户找到了一个**“合适”的应用服务器。但这只是“匹配”阶段的成功。后续，网络还需要为用户建立一条能够真正通往这个应用服务器的数据路径。这个“建路”的过程，就是服务开通**。它可能涉及到：1）PCF检查用户的策略，确认该用户是否有权限使用该边缘服务。2）SMF重新选择或更新UPF，将用户的PDU会话“锚定”到离EAS最近的边缘UPF上。3）UPF修改路由，将发往特定应用的数据流，从原来的互联网出口，重定向到本地的EAS。这个过程中任何一个环节失败，都会导致用户最终无法使用服务。因此，Service Provisioning成功率是衡量边缘业务端到端落地能力的更全面的指标。
Q5：这些ECS/EES测量项，对于排查AR/VR等低时延业务问题有什么特别的帮助？ A5：帮助巨大。AR/VR等业务对时延极其敏感。它们的低时延，不仅仅依赖于数据传输路径（由UPF决定），还依赖于能否在第一时间就找到“最近”的EAS。如果EAS的发现和注册流程本身就有很高的时延或很低的成功率，那么“计算下沉”带来的时延优势就无从谈起。通过监控这些信令流程的性能，我们可以：1）确保用户总能被引导至物理上最近、网络质量最优的边缘节点。2）量化评估“应用上架”、“服务发现”等控制面流程自身的时延，并对其进行优化，从而缩短业务的初始加载时间。3）在发生故障时，快速判断问题是出在“找不到服务器”，还是“通往服务器的路不通”。