OmniSCP 操作
本指南涵盖了SCP的3GPP角色、它所暴露的接口和端点、其请求路由和发现行为，以及关键的运行时程序和序列图。有关每个可调设置，请参见配置；有关指标，请参见指标；有关故障处理，请参见故障排除。
3GPP角色和规范参考
SCP提供间接通信，如TS 23.501中所定义。在模型C中，消费者自行执行发现（通过NRF），但将请求转发委托给SCP。在模型D中，消费者将发现和转发都委托给SCP：它使用3gpp-Sbi-Discovery-*参数发送请求，SCP代表其执行NRF发现。OmniSCP支持这两种模型，以及当消费者已经知道目标时的直接转发。
| 规范 | 节 | 相关性 |
|---|---|---|
| TS 23.501 | §6.3.1, 附录E | SCP角色和5G SBA中的间接通信模型（C和D）。 |
| TS 23.501 | §7.3 | SCP在SBA中的请求处理行为。 |
| TS 29.500 | §6.10 | 通过SCP的SBI��由；3gpp-Sbi-*路由/发现头。 |
| TS 29.500 | §6.10.3 | 在委托发现请求中携带的3gpp-Sbi-Discovery-*头集。 |
| TS 29.500 | §6.10.3.2 | 3gpp-Sbi-Target-apiRoot头（直接路由目标）；主要服务名称选择。 |
| TS 29.500 | §6.10.3.3 | 3gpp-Sbi-Producer-Id响应头（消费者与生产者绑定）。 |
| TS 29.500 | §5.2.2.2 | User-Agent头传达请求者的NF类型。 |
| TS 29.510 | §6.2 | Nnrf_NFDiscovery，SCP使用的NRF发现服务。 |
| TS 29.510 | §6.1 | Nnrf_NFManagement，SCP自注册和NF状态通知。 |
参考：TS 23.501，TS 29.500，TS 29.510。
接口和监听器
OmniSCP是一个通用的HTTP反向代理。NF消费者将其SBI流量指向SCP的SBI监听器，而不是直接指向生产者。对于每个请求，SCP解析目标生产者（从请求头、缓存的NRF发现结果或通过查询NRF），通过配置的负载均衡策略选择一个实例，转发请求，并在失败时重试不同的实例。
| 监听器 | 默认端口 | 协议 | 目的 |
|---|---|---|---|
| SBI代理 | 7777 (sbi_port) | HTTP / HTTPS (sbi_scheme) | 接受来自消费者的SBI请求并接收NRF状态通知。所有非通知路径都被代理到生产者。设置sbi_scheme=https与sbi_certfile/sbi_keyfile以在监听器上终止TLS。 |
| Prometheus指标 | 9568 (prometheus_metrics_port) | HTTP | 提供/metrics抓取端点。请参见指标。 |
| 管理/OAM API | 8443 | HTTPS | 只读状态和OAM控制端点。请参见配置 → 管理API。 |
SBI监听器通过HTTP/2提供，具有每连接流限制和固定的接收池；这些传输调优值在配置 → SBI监听器调优中描述。
SBI端点表
OmniSCP是透明的：确切地说，只有一个路径在本地处理，所有其他请求都被代理。
| 方法 | 路径 | 本地处理 | 描述 |
|---|---|---|---|
POST | /nnrf-nfm/v1/nf-status-notify | 是 | 接收NRF NF状态通知。在NF_DEREGISTERED或NF_PROFILE_CHANGED时，发现缓存会因其nfInstanceId标识的单个受影响实例而失效（如果没有实例ID，则回退到仅驱逐一个NF类型，如果两者都不存在则不执行任何操作）。整个缓存不会被清除。返回204 No Content。 |
* | 所有其他路径 | 否（代理） | 根据活动路由模式转发到解析的生产者。 |
路由和发现
在每个传入请求中，SCP检查请求头和路径以决定如何解析目标生产者���按优先顺序评估三种路由模式：
模式1：直接转发
当消费者发送3gpp-Sbi-Target-apiRoot时，它已经知道生产者的API根。SCP剥离SCP特定的头并直接将请求转发到该基本URI，不进行NRF查找、缓存或负载均衡。
模式2：委托发现（模型C/D）
当消费者发送3gpp-Sbi-Discovery-target-nf-type和3gpp-Sbi-Discovery-service-names时，SCP自行解析生产者集：
- 缓存查找：以
{target NF type, primary service name}为键。如果在TTL内命中，使用缓存的实例列表，不进行NRF查询。 - NRF发现：在未命中时，SCP查询NRF（Nnrf_NFDiscovery），传递其接收到的发现参数：请求者NF���型、目标PLMN列表、请求者S-NSSAI列表、NF集ID和目标NF实例ID。结果在
discovery_cache_ttl下使用相同的键缓存。 - 排水过滤：在选择之前，任何其
nfInstanceId被行政排水的实例（请参见配置 → 管理API）会从候选集中移除。 - 过载控制剔除：任何当前通过其
3gpp-Sbi-Oci（过载控制信息）响应头信号过载的实例，其有效期内达到或超过oci_reduction_threshold，会从候选集中移除（TS 29.500 §6.3）。这是尽力而为：如果每个候选都过载，则保持完整集合，而不是丢弃请求。 - 负载均衡器选择：从剩余候选中使用
lb_strategy选择一个实例。 - 转发并重试：请求被转发；在失败时尝试不同的实例，最多重试
max_retries。在每个响应中，记录生产者广告的3gpp-Sbi-Oci，以便后续请求可以从中剔除负载。
模式3：基于路径的推断
当没有路由头时，SCP从请求路径的服务名称前缀推断目标NF类型（路径格式/<service-name>/<version>/...），然后完全按照模式2进行处理。
| 路径前缀 | NF类型 |
|---|---|
nudm- | UDM |
nausf- | AUSF |
namf- | AMF |
nsmf- | SMF |
npcf- | PCF |
nudr- | UDR |
nnssf- | NSSF |
nbsf- | BSF |
nnrf- | NRF |
nchf- | CHF |
nnef- | NEF |
naf- | AF |
如果路径前缀不在此表中，SCP返回400 Bad Request，原因是MANDATORY_IE_MISSING。
负载均衡策略
选择策略由lb_strategy设置，适用于模式2/3（发现的实例集）：
| 策略 | 选择逻辑 |
|---|---|
round_robin | 按顺序循环通过健康的候选实例。每个{nfType, serviceName}组保持一个单独的轮换计数器，以便不同服务不会相互干扰。这是默认值。 |
weighted | 从其NRF配置中选择具有最佳（最低）load - capacity分数的实例，优先选择高容量、低负载的生产者。缺失的load默认为50，缺失的capacity默认为100。 |
priority | 从其NRF配置中选择具有最低priority值（最高优先级）的实例。缺失的priority默认为65535。适合主动/备用部署。 |
权重来源。
weighted和priority策略从每个生产者自己的NRF配置中读取load、capacity和priority；SCP没有自己的每个生产者权重配置。要偏向选择，您需要在生产者（或NRF）上调整这些值，而不是在SCP上。SCP的nf_capacity/nf_priority设置（配置 → NRF配置容量/优先级）是��个单独的概念：它们描述SCP本身在其自己的配置中，以便对等方可以对SCP进行加权，而对SCP如何加权生产者没有影响。
基于故障的健康跟踪。 不论策略如何，负载均衡器跟踪每个实例的结果。一个实例在连续3次失败后被标记为不健康，并从选择中排除；每15秒运行一次后台健康扫描，一旦自上次失败以来经过30秒冷却时间，该实例将恢复服务。如果每个候选都不健康，SCP将回退到完整列表，而不是直接失败（优先考虑可用性而不是严格排除）。这种自动健康跟踪与运营商驱动的排水状态不同。
这三个阈值（失败计数、扫描间隔和冷却时间）未作为环境变量暴露，默认为上述值，但它们是实时读取的真实:omniscp应用程序配置键（failure_threshold、health_check_interval、recovery_cooldown_ms）。没有OAM端点在运行时更改它们。请参见配置 → 负载均衡器和过载可调设置。要按计划将生产者排除在轮换之外（而不是等待失败阈值），请使用行政排水。此目的的失败是5xx响应或连接/超时错误；任何状态低于500的响应（包括4xx）都计为成功并重置实例的失败计数。
SBI / 代理行为
消耗的头（并在转发前剥离）
这些控制路由，永远不会转发给生产者。
| 头 | 目的 |
|---|---|
3gpp-Sbi-Target-apiRoot | 模式1直接路由目标。 |
3gpp-Sbi-Discovery-target-nf-type | 要发现的NF类型（例如UDM）。 |
3gpp-Sbi-Discovery-service-names | 以逗号分隔的服务名称；第一个是主要服务（用作缓存键和NRF查询服务）。 |
3gpp-Sbi-Discovery-requester-nf-type | 请求者NF类型；限制NRF查询的范围。 |
3gpp-Sbi-Discovery-target-plmn-list | 目标PLMN列表；传递给NRF查询。 |
3gpp-Sbi-Discovery-requester-snssai-list | 请求者S-NSSAI列表；传递给NRF查询。 |
3gpp-Sbi-Discovery-nf-set-id | NF集ID过滤器；传递给NRF查询。 |
3gpp-Sbi-Discovery-target-nf-instance-id | 特定目标NF实例ID；传递给NRF查询。 |
3gpp-Sbi-Discovery-requester-nf-instance-id | 请求者实例ID。被消耗和剥离，但当前不包含在NRF发现查询中。 |
User-Agent头也会被检查：根据TS 29.500 §5.2.2.2，它以请求者的NF类型（例如AMF-...）开头，如果没有显式的发现头提供，则用作请求者NF类型。如果两者都不存在，SCP将请求者NF类型默认为SCP以进行NRF查询。
生成的头
| 头 | 目的 |
|---|---|
3gpp-Sbi-Producer-Id | 添加到响应中，携带服务请求的生产者的nfInstanceId，以便消费者可以将后续请求绑定到同一生产者（TS 29.500 §6.10.3.3）。 |
3gpp-Sbi-Lci | 生产者负载控制信息，从生产者的响应中端到端转发，以便消费者通过SCP接收其负载提示（TS 29.500 §6.3）。SCP转发生产者值，而不合成自己的值。 |
3gpp-Sbi-Load | 3gpp-Sbi-Lci负载伴随头，从生产者的响应中端到端转发，连同3gpp-Sbi-Lci一起（TS 29.500 §6.3）。 |
逐跳响应头（transfer-encoding、connection、content-length）不会转发回消费者。
代理错误响应
当SCP无法完成操作时，它会根据TS 29.500返回RFC 7807 ProblemDetails主体。
| HTTP状态 | 原因 | 条件 |
|---|---|---|
400 Bad Request | MANDATORY_IE_MISSING | 没有路由信息：没有目标-apiRoot，没有发现头，并且路径前缀映射到没有已知服务。 |
502 Bad Gateway | TARGET_NF_NOT_REACHABLE | 无法从发现的NF配置中解析出SBI URI。 |
504 Gateway Timeout | NF_DISCOVERY_FAILURE | 发现（NRF + 缓存）未产生可用的NF实例，包括当每个服务的候选实例都被行政排水时。 |
500 Internal Server Error | SYSTEM_FAILURE | 实际上未预期的内部代���错误，未被上述更具体的原因覆盖。 |
关于所有排水情况的说明。 如果服务的每个候选都被排水，代理没有可用的下一跳，返回
504 NF_DISCOVERY_FAILURE（而不是500）。至少排水一个实例以恢复服务。请参见故障排除。
重试语义。 生产者响应状态**< 500**（包括4xx）被视为有效答案，并原样返回给消费者。5xx响应或连接/超时错误计为失败：失败的实例报告给负载均衡器并从候选集中移除，尝试不同的实例。重试继续，直到获得非失败响应、达到max_retries或候选列表耗尽，此时返回最后的响应（或错误）。
关键程序
代理的、负载均衡的请求与重试（模式2/3）
下面的序列显示了委托发现、负载均衡器选择、第一次尝试失败（返回5xx）以及对第二个实例的成功重试。
直接转发（模式1）
NRF状态通知（缓存失效）
NRF自注册和心跳
SCP在启动时作为SCP NF向NRF注册，并通过定期心跳保持注册。广告的配置携带SBI地址/端口/协议、PLMN（mcc/mnc）和NF capacity/priority。可以通过OAM API强制立即注册。
行政上游排水
排水是行政状态，与基于故障的自动健康跟踪分开。排水的实例在负载均衡器选择之前从候选列表中过滤，因此排水的生产者永远不会接收转发流量。使用它可以优雅地将生产者从轮换中移除（进行维护），而无需将其从NRF中注销。
维护工作流。 从NRF获取目标生产者的nfInstanceId（生产者注册的值），然后使用该ID和可选的reason执行POST /api/oam/upstream/drain。已经转发到生产者的在途请求不会被中断；只有新选择会跳过它，因此请允许现有请求完成后再为生产者提供服务。通过GET /api/oam/upstream/drain确认它已被排除在轮换之外，当维护完成时，使用DELETE /api/oam/upstream/drain/{id}将其恢复为服务。
排水状态在内存中。 排水条目保存在ETS表中，并且不会在SCP重启时持久化：如果在生产者被排水时SCP进程重启，该生产者会再次变为可选择，您必须重新发出排水。相应地计划维护窗口，并在任何SCP重启后重新检查
GET /api/oam/upstream/drain。