Docs / dflux EdgeGuard
ContactGet started

NRF and producers

On the SBI side, dflux EdgeGuard integrates with the NRF in two roles: it registers a shadow NF profile for itself so consumers discover the proxy, and it discovers downstream producers so requests can be routed dynamically. The producer pool can also be populated from static config.

Two NRF roles

dflux EdgeGuard plays two roles with respect to the NRF:

  • Registration. At startup, the proxy registers one or more shadow NF profiles with the configured NRF — for example a UDM profile that lists the proxy's listen address. Consumers that discover UDM through the NRF see the proxy as a UDM instance and send their requests to it. The proxy heartbeats the profile at a configurable cadence.
  • Discovery. The proxy queries the NRF for available producers (by NF type and selection criteria), populates a producer pool, and selects from that pool when routing.

Shadow NF profiles

A shadow profile is just an NRF profile the proxy registers on its own behalf. The profile advertises:

  • The NF type the proxy impersonates (UDM, AUSF, PCF, UDR, SMF, AMF, NSSF, …).
  • The proxy's listen address(es) and supported services.
  • PLMN and S-NSSAI scope.
  • Priority and capacity hints used by consumers for selection.

Profiles are configured via d3x-edgectl nrf-profiles or in the config file (bootstrap seed only on a fresh store). See Config schema for the field list.

NRF profile changes re-register live
Changes via d3x-edgectl nrf-profiles persist immediately and re-register with the NRF without a restart: each create, update, or delete triggers the NRF registration component to deregister and re-register the full profile set against the NRF. The same hot-reload guarantee applies to other control-plane changes (policy, rate-limit, transformation, and routing rules, and the producer pool).

Producer discovery

When nrf.discover_producers: true, the proxy periodically issues NF-Discovery requests to the NRF for each producer NF type it needs. Discovered instances populate the producer pool with their advertised addresses, priorities, and capacities.

Discovery is incremental and idempotent — new instances join the pool, drained instances drop out, and existing instances are updated. The pool refresh interval is configurable.

The producer pool

The producer pool is the in-memory list of reachable producers per NF type. The routing engine reads it when no explicit routing rule applies (or when a rule resolves to an NF type rather than a specific address).

The pool combines:

  • NRF-discovered producers — automatically refreshed.
  • Static producers — declared in nrf.producers[] or via /admin/producer-configs. Useful for environments without an NRF, or to pin a particular instance.

Runtime producer ops

The admin API exposes runtime knobs on the pool:

  • Drain / restore — PATCH /admin/peers/sbi/{nf_type} with a JSON body of {address, state}, where state is drained or active. A drained producer stops receiving new requests while in-flight requests complete; setting it back to active returns it to the pool. PATCH to the same state is idempotent.
  • Weight — PUT /admin/peers/sbi/{nf_type}/weight. Shift traffic share without removing the producer.
  • List — GET /admin/peers/sbi and GET /admin/peers/sbi/{nf_type}.

These knobs are hot-reloadable: no restart, decisions take effect on the next request. See Admin API → Producers and profiles.

Deep health

GET /admin/health/deep walks the producer pool and reports each producer's reachability. It is the operator's primary signal for "is this proxy actually able to serve traffic?" — distinct from the cheap liveness check on the SBI listener.