核心观点
本文件旨在为 OP 架构中服务 API 的实现创建一个基线，涵盖计费、联盟、差距和填充服务差距的建议使能器等方面，作为运营商和合作伙伴参考的实现指南。
关键数据
- 文件基于 GSMA 非机密官方文件 OPG.09 - NBI APIs Realisation in the SBI V5.0 版本。
- 文件日期为 2026 年 2 月 19 日。
- 文件包含 17 个 NBI API 的分析，涵盖 UE 识别、授权和认证、通用错误代码、CarrierBilling API、Device Location APIs、Number Verification API、QualityOnDemand APIs、Traffic Influence API、KYC Match API、KYC Fill-in API、OTP SMS API、Device Status APIs、Edge Cloud Discovery APIs、Call Forwarding Signal API、Connectivity Insights、SIM Swap APIs 和 Device Swap API。
研究结论
- OP 应解释 CarrierBilling API 请求并将其转换为运营商业务支持系统 (BSS) 的专有请求。
- OP 应将 Number Verification API 请求重定向到 SBI，并根据网络实现进行网络或 SIM 认证。
- OP 应将 QoD API 请求重定向到 SCEF 或 NEF，并通过 SBI-NR 实现它。
- OP 应将 TI API 请求重定向到 NEF，并通过 SBI-NR 实现它。
- OP 应将 KYC Match API 和 KYC Fill-in API 请求转换为专有请求，并将其发送到资源服务器。
- OP 应将 OTP SMS API 请求转换为专有请求，并将其发送到资源服务器的专用端点。
- OP 应将 Device Status APIs 请求重定向到 SBI，并根据网络实现进行网络或 SMS 使用情况检查。
- OP 应将 SED API 请求重定向到负责处理运营商网络内请求的网络元素，并通过 SBI-NR 实现。
- OP 应将 Call Forwarding Signal API 请求转换为专有请求，并将其发送到运营商的后端系统。
- OP 应将 Connectivity Insights API、Connectivity Insights Subscriptions API、SIM Swap APIs 和 Device Swap APIs 请求重定向到 SBI，并根据网络实现进行相应的操作。
实现方式
- OP 应使用 3GPP 监控事件 (monitoringType: LOCATION_REPORTING) 来实现 Location Retrieval API、Location Verification API 和 Device Geofencing API。
- OP 应使用 3GPP 监控事件 (monitoringType: UE_REACHABILITY) 来实现 Device Reachability Status API。
- OP 应使用 3GPP 监控事件 (monitoringType: ROAMING_STATUS) 来实现 Device Roaming Status API。
- OP 应使用 NWDAF “DN Performance” Analytics ID 来实现 Application Profiles API 和 Connectivity Insights API。
- OP 应使用 NEF API 来实现 SED API 和 SIM Swap APIs。
- OP 应使用 Transformation Function 来将 CAMARA API 请求映射到 NEF 或 SCEF/NEF 的请求。
其他要点
- OP 应确保所有 API 请求都经过身份验证和授权。
- OP 应确保所有 API 请求都符合用户隐私偏好和监管义务。
- OP 应确保所有 API 请求都符合服务水平要求 (SLR)。
- OP 应确保所有 API 请求都符合联盟要求。
