Licensing

The RIC will not start without a valid licence for the deployment it is running in. The licence is a signed file, checked offline against a key built into the binary, so a running RIC never contacts a licence server.

Getting a licence

airpuls issues you a licence key — a short string. Everything else is done by the deployment tooling in nrtric-ctrl:

./start.sh                      # mints this deployment's CA, then stops
./activate.sh <licence-key>     # binds a licence to it
./start.sh                      # brings the stack up

The first run stops on purpose: the licence is bound to a certificate that does not exist until start.sh has created it, so activation cannot happen any earlier. Both runs are safe to repeat.

Activation is the only step that needs the licence server. After it, the deployment runs disconnected.

Checking a licence

./verify-license.sh

It reports what the RIC would decide, and — when the licence server is reachable — additionally asks whether the licence has been suspended or revoked. That last part matters: a revoked licence keeps a valid signature and an unexpired deadline, so nothing on the deployment itself can reveal it.

What a licence is tied to

The deployment, not the machine. It is bound to the CA in conf/ric-tls/ca.crt, which is created once and travels with the deployment, so VM migration, container recreation and disaster-recovery failover do not invalidate it.

Two consequences worth knowing before they surprise you:

Re-creating conf/ric-tls/ — the documented way to rotate that trust domain — also invalidates the licence. Run ./activate.sh again afterwards.
conf/ric-tls/, conf/license.key, conf/license-key and .env belong in the same backup. Losing the CA means the licence no longer matches.

The two file names differ by one character and are not interchangeable:

File	What it holds
`conf/license.key`	The signed licence itself, mounted into the RIC
`conf/license-key`	The short activation key, kept so `verify-license.sh` can re-check online

While the RIC is running

The licence is re-checked hourly, and a licence that lapses never stops a running RIC — it warns and reports the state. A licence clock must not be able to take down RAN control-plane infrastructure.

The state is on the metrics endpoint, so alert on it rather than watching logs:

airpuls_license_valid            1     # 0 once the licence stops being valid
airpuls_license_expiry_seconds   …     # deadline, for a renewal alert
airpuls_license_host_changed     0     # 1 if the host moved since activation
airpuls_license_info{type="production"} 1

airpuls_license_host_changed is a notice, not a fault: the host a deployment runs on may legitimately change. Re-run ./activate.sh to record the new one.

Renewing

Re-run ./activate.sh <licence-key>, then bring the stack up again with ./start.sh. Alert on airpuls_license_expiry_seconds so this happens on your schedule rather than during an incident.

When the RIC refuses to start

Every refusal names its cause in the log and exits non-zero.

Message	What to do
`the licence file could not be read`	Either it is missing — run `./activate.sh <licence-key>` — or its permissions exclude the RIC. The message says which applies; re-activating does not fix a permissions fault
`the licence was issued for a different deployment`	The licence belongs to another RIC, or `conf/ric-tls/` was re-created. Activate again
`the licence signature does not verify`	The file was altered, or came from a different licence server
`the licence has expired`	Renew, then `./start.sh`
`the licence file is not a readable machine file`	`conf/license.key` is truncated or is not a licence
`the certificate identifying this deployment could not be read`	`conf/ric-tls/ca.crt` is missing — run `./setup-ric-security.sh`
`the licence carries a restriction this build does not implement`	See Restrictions — usually a mistyped key in the licence rather than an outdated RIC

Restrictions

A licence may carry named limits under restrictions. This version implements exactly two names:

Name	Limits
`maxXapps`	Simultaneously connected xApps
`maxE2Nodes`	Connected E2 nodes

The values are not yet enforced — only the names are checked. A licence carrying any other name is refused and the RIC will not start, deliberately: a build that ignored limits it did not recognise would ignore every limit added after it shipped, in every deployment already in the field.

The practical consequence is for whoever issues licences. A misspelling — max_xapps, maxNodes — produces a licence that no current RIC will accept. If a deployment refuses to start on this message, check the licence metadata before upgrading the image.