In this chapter
Seeing what the network is doing
Monitoring helps me connect a reported problem with the part of the network that needs attention, then check whether the change helped.
- Host and transport
CPU, memory, links and tunnel state
- Protocol and service
SIP, media, mobile core and gateway metrics
- Customer experience
Data, calls, messages and connection quality
Machines and services
Prometheus collects host and service measurements. Our monitoring covers voice signalling, media handling, mobile forwarding, databases and operations APIs, with radio information adding a site-level view.
Follow the customer path
Protocol checks and handset tests connect component health with everyday use. We also run an Ookla Speedtest server, giving people another way to measure their connection to a test endpoint on our network. Our other public and private speedtests measure download, upload, ping and jitter.
Read the measurements together
Device capabilities, radio conditions, routes and competing traffic all affect results. A speed test measures the path between that device and the selected server at that time. I bring those details together to reproduce faults, understand their causes and compare the outcome after a change.
Turning an account into a connection
Provisioning is the work that connects an account, a plan and the network settings needed to deliver a service. It is easy to overlook until something stops lining up.
Keep the right records together
A customer account, a reserved public address and an active tunnel session are different things. Our portal and provisioning integration relate them so that the network can apply the intended service. Credentials, transport choice and entitlement also need to agree when a connection is first created or later changes.
Look after the whole lifecycle
A service continues changing after setup. It may reconnect, expire, be renewed, switch connection method or be retired. Workers and timers handle repeated tasks, while reconciliation checks bring related records back into agreement. This is especially important for me as a solo operator: consistent automation gives me more time to investigate the problems that need attention.
Give each tool the access it needs
Public account journeys and internal administration have different responsibilities. Our systems use service accounts, restricted interfaces, role checks and process isolation to keep those responsibilities clear. I also want future community operators to understand the reasoning behind this. A good provisioning process makes its result visible, reports a failed change clearly and gives the operator a practical route to recovery.
Making reliability part of the build
Affordable connectivity still has to be dependable. Improving reliability is part of the everyday work, and our next stage includes extra servers and additional mobile cores.
Build on the foundations
We now run three servers in London, a long way from the home PC that ran the first AzurePCS core. Our platform brings together monitoring, service supervision, persistent records and recovery tools. These help me spot problems and restore useful service. A fourth server is coming soon as we keep adding capacity and practical recovery options.
Put the new capacity to work
We are preparing extra servers and mobile cores to strengthen the network as it grows. Their placement matters, along with the connections between them, the handling of subscriber information and the routes radio sites can use. I want each addition to solve a practical problem and make the whole service easier to keep running.
Measure reliability in ordinary terms
The useful questions are simple. Can a phone reconnect after an interruption? How long does Internet access take to return? Does a customer need to change anything? Can I maintain one part of the platform with less disruption elsewhere? Those are the outcomes I care about. More equipment gives us room to improve them, alongside careful changes, good documentation and regular recovery exercises.
How extra cores strengthen the network
Our next deployment adds servers and mobile cores, giving the network more capacity and more ways to recover when something needs attention.
A usable route to the serving platform
- Existing platform
- Our current core and service functionsCurrent platform
- Extra cores
- Planned capacity and recovery pathsPlanned
Radio sites
A site needs a protected transport path to the core functions that serve its phones. Alternative destinations become useful when the site can reach them during a problem.
Additional core capacity
Extra instances create options for distributing work, planned maintenance and recovery. Subscriber records, routing and available processing capacity connect those options into a usable design.
The outcome for people
I want fewer interruptions, quicker restoration and clearer maintenance choices as we expand. The deployment work includes checking what phones and sessions do when service moves or restarts.
The months behind the network
I have spent months learning, debugging and joining systems together. Seeing that work become a real network means a great deal to me.
Making the pieces work together
I have spent many months building Lodestar myself. The platform brings together Linux, Open5GS, Kamailio, FreeSWITCH, BIRD, strongSwan, WireGuard, FreeRADIUS, Accel-PPP, Prometheus, Grafana and GenieACS, alongside my VectorCore work. Learning each component is only the beginning. The hard part is making their identities, routes, timing and state agree.
A lot happens between the milestones
There is real work behind a phone registering, a call keeping its audio or a tunnel reconnecting with the right public address. I have spent time on voicemail branches, stale registrations, uncertain SMS outcomes, browser behaviour and the tools that let me see what is happening. These details rarely make a headline, but people notice when they are wrong.
Why I keep going
It is hard doing this on my own, but I am finally seeing the dream succeed. I want people to have affordable connectivity they can rely on, and I will keep working every day towards that. I also want the knowledge to travel. If this work helps another person build a mobile network for their community, it becomes something bigger than my own network.
Test, learn and make it better
Progress often comes from finding a small fault, understanding it properly and making the next attempt better. That has been a large part of building Lodestar.
Follow a problem through
Our speedtest work has covered connection handling, browser memory behaviour, worker distribution, parallel transfers and recovery when the server is busy. A short successful download answers one question. A longer session, background browser tab or group of simultaneous users can expose a different problem. Changing the conditions carefully helps explain the difference.
Check a site as a complete path
For a radio deployment, I need to follow the whole connection: protected backhaul, core registration, subscriber authentication and traffic in both directions. Voice has its own checks where offered. Monitoring should show the same story as the device, so a fault has a recognisable starting point when it happens again.
Carry the lessons into the next stage
Our upcoming servers, additional cores and Nuneaton site give us more opportunities to improve. I want to check recovery as carefully as everyday operation, including what a handset does after a component restarts. Keeping clear notes makes the next deployment easier and gives future community builders something useful to learn from. Every improvement should make the service easier to operate and more dependable to use.