Lab setup
Prepare account access, a hosted core, radio connectivity, and SIM settings for an independent lab test.
Before you start
The lab supplies:
- gNB vendor, model, and software version.
- UE vendor, model, and software version.
- Confirmation that the gNB and UE support 5G Standalone (SA).
- Programmable test SIMs or matching test subscription data.
The lab network operator supplies:
- Radio source IPv4 CIDR.
- Reachable gNB N3 address and return route.
- Confirmation that the network permits SCTP and UDP.
- Any NAT or VPN constraints.
Agree with 1sc on:
- Named account operators.
- Core implementation and exact runtime version.
- Test window.
- Data-network mode and test server address.
- A secure method to exchange SIM material and certificates. Keep these values out of reports and public docs.
An account provides dashboard access. It does not establish a radio network path or provision a physical SIM. Complete those steps before the test window.
Account and deployment
Use your own account. If access is missing, ask the evaluation contact to arrange it. Do not use a shared employee login.
In Dashboard, select Deploy 5G core. Use the following settings for the agreed test. Creating a deployment starts billable infrastructure.
| Field | Selection |
|---|---|
| Deployment name | A name that identifies the lab test. |
| Core implementation | 1SC Core when evaluating the proprietary Rust core. |
| Radio source CIDR | The lab radio source address or narrow address range. Automatic detection from your laptop can select the wrong source. |
| Data network | Lab ICMP responder for the baseline tunnel test. External IPv4 network with NAT for external-server traffic tests. |
| Radio transport | Direct N2 and N3 when the lab has a working direct route. Use Certificate-authenticated IPsec only with an agreed certificate and routing plan. |
Radio connection checklist
| Setting | Check |
|---|---|
| Core endpoints | Use the AMF N2 and UPF N3 endpoints from this deployment. Do not reuse an endpoint from a previous run. |
| Direct transport | Permit SCTP 38412 and UDP 2152 between the agreed radio source and core. Do not use 0.0.0.0/0 as the source. |
| Return route | The core must reach the gNB GTP-U address that the gNB advertises. Opening ingress alone does not establish this route. |
| PLMN and TAC | Match the radio package. Preserve leading zeroes in MCC/MNC and confirm the MNC length. |
| Slice and DNN | Match SST, SD, and DNN in the radio, UE, and subscription. |
| SIM and subscription | Match IMSI/SUPI and authentication data. Confirm whether the equipment expects OP or OPc; they are not interchangeable. |
| IP addressing | Check that the UE subnet does not overlap a lab, VPN, or test-server subnet. |
| Physical radio | Use the equipment vendor instructions for radio and SIM configuration. Record every setting that differs from the agreed profile. |
Start and verify
First complete the hosted UERANSIM procedure in Radio attach. Then run the physical equipment tests agreed with your lab. A passing simulator result does not complete physical equipment acceptance.
Keep the runtime version and configuration fixed during a run. If either changes, start a new run record. Ask the evaluation contact for the runtime identifier if it is not available in the deployment evidence.
Find a connection failure
| Last successful step | Check next |
|---|---|
| Core running; no NG setup | Radio source CIDR, SCTP route, AMF endpoint, and gNB configuration. |
| NG setup; registration fails | PLMN, subscriber identity, SIM authentication data, and the NAS reject cause. |
| Registration; session fails | DNN, slice, requested session type, and session reject cause. |
| Session established; no packets | N3 return route, advertised gNB address, UE address, selected data-network mode, and target-server reachability. |
| Traffic works; performance is low | Measure radio, cloud, and inter-site network effects separately. Record load and core resources. |
End the test
Save the result record and approved logs before stopping the core. Record failures and blocked tests as well as passes.
The distributed CLI provides deployments stop and deployments destroy. Stop pauses compute; destroy removes the deployment resources. Confirm the intended action and check the resulting state. Do not assume that a stopped deployment has no retained-resource costs.