Docs / dflux TinyCore
ContactGet started

Provision subscribers

Get subscribers into the DPF — using the built-in test vectors, or a persistent SQLite/Postgres store.

Where subscribers live

The DPF (AUSF + UDM + UDR + PCF) holds subscriber identity, authentication keys, and per-subscriber slice/DNN data. It backs that store with one of three backends, chosen by -store: memory (default), sqlite, or postgres. How you provision depends on which you pick.

Option 1 — Seed the test vectors

The fastest path. -seed installs the canonical lab fixture on startup, into whichever backend is active. With the default in-memory store this is a one-flag core:

Bash

The seeder is idempotent, so restarting with -seed is safe. This is what the Docker lab and the native run use.

The seeded vectors

The fixture installs five subscribers using the well-known open5gs test key and OPc. Every subscriber shares the same K and OPc; only the SUPI differs:

text
SUPI string format

The DPF seeds the SUPIs in the compact imsi-00101… form shown above (no separators after the MCC/MNC). Some lab tooling and the bundled lab-subscribers.yaml display the same identities in the dashed form imsi-001-01-0000000001. They refer to the same subscribers — the IMSI digits are identical — but if you query the DPF directly, use the compact string.

Subscribers 1–4 authenticate with 5G-AKA; subscriber 5 is provisioned for EAP-AKA′ so the non-3GPP auth path has a fixture. Use one of the first four for a standard registration.

Option 2 — A persistent store

To keep subscribers across restarts, point the DPF at SQLite or Postgres. Pass -db-migrate on first run so the schema is created; without it the DPF probes the schema at startup and aborts with a clear error if migrations have not been run.

Bash

You can combine a persistent backend with -seed to pre-load the test vectors into the database on first boot. See Persistent storage for the broader story across NFs.

Provisioning your own subscribers

No admin REST API yet
dflux TinyCore does not currently expose an administrative REST endpoint for creating subscribers. Provisioning your own subscribers means writing rows into the DPF's database schema directly (with the DPF stopped, or before its first start), then starting the DPF against that database. The seeded fixture is the supported turnkey path; custom provisioning is a manual, schema-level operation.

A subscriber spans several tables — authentication material plus subscription data. The key tables in the DPF schema are:

  • udm_auth_subscriptions — the authentication record: permanent key (K), OPc, AMF (authentication management field), SQN (sequence number), auth method, and algorithm.
  • udm_am_data / udm_nssai — access-and-mobility data and the allowed S-NSSAIs (slice).
  • udm_smf_sel / udm_sm_data — SMF selection and per-DNN session management data (which DNNs the subscriber may use, and their AMBR).
  • udm_am_policy_data / udm_sm_policy_data — the PCF policy records.

The fields a registerable subscriber needs:

  • SUPI — the subscriber identity (imsi-<mcc><mnc><msin>).
  • K and OPc — the 128-bit Milenage key material.
  • AMF (authentication management field) and SQN (sequence number) — used by the authentication vector generation.
  • NSSAI / S-NSSAI — the slice(s) the subscriber is allowed on (the fixture uses SST 1).
  • DNN configuration — the data networks the subscriber may reach (the fixture uses internet).

Where to go next