Keep the network secure and reliable

Create a private build record

Keep an inventory of the PC, radio, switch, power supply, serial numbers, firmware, package versions, licence expiry, site address, antenna settings and named people responsible. Separate public learning notes from private operational information. The latter includes subscriber identities, credentials, VPN keys, activation codes and administration addresses.

Record one change at a time with a reason, test and rollback plan. A useful record says what the symptom was, what changed, what proved the result and which backup contains the previous version. Screenshots alone can miss a hidden setting, so keep supported configuration exports too.

Back up the things that let you rebuild

For the small Open5GS lab, MongoDB's official tools provide a logical backup. A coherent backup is easiest during a planned quiet window with subscriber editing stopped. This example saves secrets locally in a root-only directory; encrypt the archive before moving it off the PC.

sudo install -d -m 700 /root/private-lte-backups/database
sudo mongodump --db open5gs   --archive=/root/private-lte-backups/database/open5gs.archive --gzip
sudo chmod 600 /root/private-lte-backups/database/open5gs.archive
sudo cp -a /etc/nftables.conf /root/private-lte-backups/nftables-working.conf
sudo cp -a /etc/open5gs /root/private-lte-backups/open5gs-working

The mongodump documentation explains backup limitations, authentication and consistency for larger systems. A successful backup command is not proof of a usable restore. Restore onto an isolated spare system, check the expected record count privately and prevent that spare from transmitting or advertising the same live network accidentally.

Watch health without collecting everything

Start with service status, CPU and memory, free disk space, correct time, radio timing alarms, eNodeB S1 status and a simple test phone. Add measurements for attach failures, established sessions, packet loss, tunnel health and certificate expiry as the network grows. A monitor should tell you something actionable, such as a service that stopped or a licence renewal that is due.

systemctl --failed
systemctl is-active mongod open5gs-mmed open5gs-hssd open5gs-smfd open5gs-upfd
df -h
free -h
timedatectl status
ip -s link show ogstun
sudo journalctl -u open5gs-mmed --since '15 minutes ago' --no-pager

Use the relevant VectorCore service names if you selected that branch. Logs can contain IMSIs, session addresses, telephone numbers and sensitive payload details. Retain only what you need, rotate it, restrict access and remove private data before asking for help. Subscriber packet captures should be exceptional, targeted and lawful.

Update with a route back

1. Read the release notes for the OS, core, database and radio firmware. Check configuration migrations and runtime requirements.
2. Make a backup and verify that you know how to restore it. Keep the previous working package/build information.
3. Use a maintenance window and tell affected users through your normal service process.
4. Change one layer, restart only what is needed and rerun attachment, data, isolation and recovery tests.
5. If the result fails, use the documented rollback rather than making several unrelated changes.

Automatic OS security updates can be useful, but a core, database major version or radio firmware upgrade deserves deliberate compatibility testing. Keep a supported runtime. Do not leave an old Go or Node version forever simply because it built once.

Plan for power and physical faults

Include the PC, switch, PoE injector, radio, router and upstream modem in your power plan. A UPS protecting only the server will not keep a radio online when its injector loses power. Measure real power draw and test shutdown and restart behaviour. Keep spare Ethernet cables and a correctly specified power supply.

Check ventilation, mounting, moisture and cable strain. Outdoor installations bring additional permissions, electrical and installation requirements and are outside the ordinary indoor 2.3 GHz Shared Access build described here. Do not turn an indoor tutorial into an outdoor mast by increasing power or moving an antenna through a wall.

Before offering service to other people

A working lab is a learning milestone. Running a service for the public also requires appropriate spectrum authority, a dependable operating plan, privacy arrangements, support, security response and the applicable communications obligations. Public voice and numbering add further requirements, including emergency communications design and tested supplier arrangements.

Review the current Ofcom General Conditions and the ICO guidance for organisations for the service you intend to provide. The exact duties depend on that service. Keep an experimental network clearly described and do not advertise emergency calling or nationwide roaming because ordinary data browsing works.

A useful handover test

Ask another trusted administrator to rebuild or explain the system using your private documentation. Can they find the licence, identify each cable, restore the core, add an authorised test SIM, revoke a lost device and tell whether the fault is radio, authentication or Internet routing? Improve the instructions where they get stuck. That is how a one-person experiment becomes maintainable knowledge.