MVNO SLA正从月度平台可用性，转向租户可观察、主机方可定位的服务成果。关键衡量标准不在于一个 BSS/OSS 环境是否保持可达，而在于用户能否附着、认证并维持可用连接。PDU 会话连续性为 5G 和 NSA 服务承诺提供了更具商业相关性的锚点，并可与附着成功率、时延、事件处置和在 MNO、MVNE及 MVNO 之间分配责任的服务信用补偿模型结合使用。
可用性是控制指标，而非 SLA 成果
平台可用性应继续纳入合同，因为它确认受管环境是否可达且正常运行。但它不能单独成立。面向用户的故障可发生在 RAN、CN、IMS、开通及策略层，而所有受监测应用仍可能名义上可用。因此，合同需要区分基础设施控制指标与 MVNO 对外销售的服务成果。
99.9% 的月度承诺意味着约 43 分钟不可用。这一计算几乎无法说明故障是一次连续事件还是数百次短暂中断、有多少个 IMSIs受到影响，或事件是否恰逢激活活动、薪资发放窗口或企业换班时段。在商业敏感时段发生的短时中断，其收入影响可能大于低使用率期间的较长故障。
运营附表应将管理平面可用性与服务平面成果分开。CRM访问和报表可用性，不能替代成功注册、PDP或 PDU 建立，或计费连续性。核心控制问题各不相同：
哪一服务边界涵盖 MNO 的 RAN 和 CN、MVNE 的 BSS/OSS、HLR、HSS、UDM、AuC、OCS和 eSIM RSP？
每项 KPI采用何种分母：符合条件的附着尝试、活跃 IMSI、尝试建立的数据会话，还是受影响用户分钟数？
适用哪些排除项、由谁验证，以及必须在多长时间内提供支持证据？
在多 IMSI 或以漫游为主导的业务模式中，如何区分归属网络故障、访问网络性能劣化、IPRN故障及传输影响？
若缺少这些边界，SLA 将变成围绕故障域的持续谈判，而非客户影响的记录。总体网络可用性作为分母尤其薄弱，因为在特定租户群体、APN 或地域实际上无法获得服务时，它仍可能维持高位。
在一次涉及 Tier-2 MNO、东南亚、约 1800 万用户的运营审查中，实质问题并非平台可达性丧失。特定租户的开通路径发生故障，而更广泛的环境仍保持可用。该案例说明了合同缺口：即使 MVNO 无法激活或服务一个具有商业重要性的用户群，环境级指标仍可能达标。
在用户交易层面设定 KPI
附着、会话建立和会话保持反映了 MVNO 能够变现并提供支持的交易。附着成功率应定义为成功注册或附着流程除以符合条件的尝试次数。拒绝、超时和重试需要分别处理。排除项应限于已记录的设备、覆盖和用户状态条件，并以允许租户对账的粒度保留证据。
对于 EPC 域，附表应跟踪 PDP 上下文激活成功率和非预期承载释放。对于 5G SA，应明确 PDU 会话建立成功率、修改成功率及异常释放率。初始附着只是第一个控制点。成功附着但反复丢失数据会话的用户，在商业层面仍然受损。
因此，连续性应结合会话掉线率、会话保持时长，以及在移动性、策略或计费事件后重新建立的成功率。由移动性驱动的释放应与网络发起的异常释放分别报告。当策略更新或余额事件中断流量、但接入注册仍保持完整时，同样应作此区分。
- 附着成功率
- 成功的符合条件附着或注册尝试除以符合条件的尝试次数；分别定义被拒绝、超时和重试的尝试。
- PDU 会话建立
- 成功建立的 PDU 会话除以有效请求数，按 DNN/APN、接入类型和地域报告。
- 会话连续性
- 非预期释放率和成功重新建立率，其中移动性驱动的释放须单独报告。
- 时延
- 从约定测量点获得的、基于百分位数的往返时延；避免将月度平均值作为唯一承诺。
- 受影响用户分钟数
- 受影响的唯一 IMSI 数乘以确认的影响时长，作为商业严重程度的输入。
报告应按接入技术、地域、APN、企业与消费级租户画像及时间窗口细分结果。在 5G SA 环境中，对应的 DNN细分应予以明确。混合后的全国结果可能掩盖在启动城市、企业 APN 或近期迁移用户池中出现的严重聚集性问题。
时延和丢包同样需要严格规范。设备探针、GTP接口计数器和合成测试观测的是服务路径的不同部分。SLA 应明确测量点、测试群体、采样间隔和百分位数。月度均值可以吸收短暂但严重的时段；这些时段会实质影响应用，却仍可能得出合规结果。
在服务信用补偿生效前设置基线期是审慎做法，尤其是在 MVNO 正迁移 IMSI、引入 eSIM 激活流程，或在 EPC 与 5GC之间迁移流量时。基线期应验证计数器和排除项，而非无限期暂停责任承担。它需要固定期限、约定的验收流程，以及纠正测量缺陷的路径。
事件时钟需要运营证据和商业后果
仅当交易各方预先就严重程度、通知、证据和升级达成一致时，响应和恢复承诺才会有效。事件时钟可以从 NOC验证、自动阈值违例或 MVNO 工单受理时开始。这些触发条件并不等同。即使用户影响已经可见，人工验证仍可能推迟记录的开始时间；而工单受理则可能使租户面临主机方受理流程延迟。
严重程度应反映受影响 IMSI 数量、无法激活或附着、持续的 PDU 会话故障、监管风险及是否存在可行的临时解决方案。告警数量是糟糕的替代指标。单一策略故障可能以极少告警影响大量租户用户，而嘈杂但具备冗余的组件则可能产生大量告警，却没有可衡量的服务损失。
共享事件记录应记录发现、通知、确认、介入、临时解决和恢复的时间戳。它应识别受影响的 MCC/MNC及 APN 群体、相关的 SS7、Diameter或 GTP 跟踪记录、补救措施及恢复确认。证据不需要暴露无关租户，但必须足以支持归因和服务信用补偿计算。
时间表应区分确认、技术介入、临时解决和恢复。快速确认不能弥补对开通、PCRF/PCF策略或 OCS 行为的延迟修正。租户沟通还需要明确节奏、负责的运营负责人以及高管升级条件。
长期性能劣化需要单独机制。反复发生但低于阈值的故障，可能压低激活转化率、会话时长和使用量，却没有任何单一事件跨越 P1阈值。因此，滚动 KPI 未达标、复发次数和未解决的根本原因，应独立于重大事件分类触发升级。
一家在 EMEA 服务 12+ 租户的 MVNE 所采用的事件框架，说明了这一结构性问题。主机方可以协调一个涉及多个租户的技术故障，但每个租户的 APN、用户规模和商业风险敞口可能不同。共同事件记录必须支持租户级影响计算，同时不能割裂底层技术调查。
信用补偿机制应为实质性故障定价，而非制造逆向激励
服务信用补偿应适用于与受影响租户及服务组件相关的经常性批发费用。将其适用于无关流量、漫游或转付费用，会削弱故障与补救之间的联系。信用补偿基数、计算周期和符合条件的费用类别，应在商业附表中固定，而非在事件发生后重新构建。
分级附表可将严重程度与受影响用户分钟数结合。月度上限应具有商业意义，但不应将 SLA 转化为无上限的间接损失保障。当信用补偿不再足以激励绩效纠正时，可通过单独补救措施处理重复故障、实质性违约、长期 KPI 未达标及终止权。
计划维护仅应在通知期、维护窗口、回退程序和最长持续时间已纳入合同的情况下予以排除。宽泛的排除项会使反复的工程活动脱离服务测量。紧急维护同样需要明确的审批和通知路径，随后还应提供证据，证明该干预确有必要且范围有限。
信用补偿应以经验证的服务故障为前提，但验证不能成为无期限的障碍。证据提交期限、争议窗口和视为接受规则，可降低有效索赔跨越多个计费周期仍未解决的风险。主机方与租户的计数器不一致时，合同应明确权威数据源和对账程序。
根本原因分析是独立交付项。它需要负责人、截止日期、纠正措施和结项证据。若没有纠正措施治理，仅发放信用补偿可能使开通、计费和策略域中的反复缺陷常态化。反之，若信用补偿豁免以未经验证的补救承诺为条件，则会在故障受控前消除商业信号。
MVNO SLA 的商业重心正从环境运行时间转向可观察的用户成果。在上线前界定分母、故障域和信用补偿触发条件的主机方，将减少争议周期，并为租户预测激活、使用量和留存风险提供更清晰的依据。