Inside our mobile network

What the radio actually does

The radio gives a phone its local wireless connection. Everything behind it helps turn that signal into a useful service.

Meet the eNodeB

An LTE base station is called an eNodeB. It manages the radio connection, schedules shared airtime and passes signalling and traffic into the mobile network. The phone needs to support the relevant band and settings. Voice also depends on compatible IMS behaviour.

From the first Band 3 radio to Band 40

AzurePCS began with my BladeRF xA4 using Ofcom Shared Access spectrum in LTE Band 3. The licence provided paired 3.3 MHz blocks, one for the phone to transmit to the base station and one for the base station to transmit back. Band 3 uses Frequency Division Duplex, or FDD: the two directions use separate frequencies.

Today, our femtocells, small cells and macro-style sites use 20 MHz LTE Band 40. Band 40 uses Time Division Duplex, or TDD, so phones and the base station take turns transmitting on the same channel. This is a different radio arrangement from the paired frequencies of the original Band 3 setup.

An earlier 2G experiment

I briefly experimented with 2G using a NanoBTS during the AzurePCS project. I no longer run or use that setup. It was part of the learning that led to the LTE network I am building today.

Why coverage varies

Power, antenna design, height, terrain, buildings and interference all shape the usable area. A strong signal outdoors may become weaker inside a building. Our current mobile footprint consists of small local pockets, including Nuneaton, Burntwood and Great Gransden. Regional coverage is the next ambition.

Sharing the air

With Time Division Duplex, or TDD, uplink and downlink take turns using the same carrier. Airtime is shared between active devices. Backhaul and core capacity also affect the result, so signal strength, signal quality, speed and stability each tell a different part of the story.

The Nuneaton next step

We are preparing our first macro style site in Nuneaton as a free local 4G pilot. I want people to use it, see how it works and help us learn. Public case studies will explain the practical coverage, performance and operating lessons for the community and Ofcom.

Protecting the radio to core path

Backhaul connects a radio site to our core. The security gateway protects that journey across an existing Internet connection.

Two kinds of traffic

Control messages arrange and manage the mobile connection. Subscriber packets carry the applications people use. Both travel behind the radio and need a working backhaul path, separate from the wireless link between phone and base station.

What segw does

IKEv2 authenticates radio endpoints and negotiates protection. IPsec carries permitted traffic through an encrypted tunnel. Inner addressing gives the core a consistent route to each radio, and NAT traversal helps across ordinary access routers. The gateway then forwards permitted traffic towards the private core. For community builders, radio coverage, backhaul and core service are three connected jobs that each need attention.

The work around every connection

A radio tunnel is only one part of the job. I have built tools around setup, changes and recovery to make the network easier to operate.

Making setup repeatable

Our gateway provisioning API manages tunnel inventory, connection creation, setup sheets, reloads and equipment retirement. It chooses available addresses and generates managed settings. This keeps the radio and gateway sides aligned and reduces the repetitive work needed as more sites join the network.

Preparing a controlled change

A candidate configuration is parsed before use. Snapshots preserve the previous state, and a shared lock prevents competing changes. A readiness guard checks the expected service and control socket. After loading, the connection and address-pool inventory is compared with the intended result.

Building a route back

Rollback logic can restore the previous configuration when a change fails. A bounded change window helps keep the operation contained. These details take time to build, but they are important when one change could affect equipment already providing service.

Giving each tool the right access

Read-only inventory access is separate from administrator actions. TLS, request limits, concurrency controls and restricted write paths help protect the service. For anyone building a community network, the lesson is practical: automate the checks around a change as well as the change itself. That makes growth more manageable.

How a phone joins Lodestar

A phone, radio and core arrange identity checks and a packet path before an application can use 4G.

Joining the network

The phone selects a compatible network and establishes a radio connection. The eNodeB passes signalling to the MME, which coordinates authentication using subscriber information from the HSS. The process checks subscription material without sending the long-term secret as an ordinary password.

Creating and maintaining service

The phone requests an APN. Our Internet and IMS APNs have separate service roles and addressing. Gateway control arranges the session, then forwarding functions carry the packets. When the phone becomes idle, paging can bring it back for incoming traffic. Tracking-area updates help maintain reachability as it moves. These background conversations continue while the screen looks quiet.

Inside the mobile core

The mobile core coordinates identity, movement, data sessions and forwarding so a radio connection becomes a useful service.

Knowing who can connect

Our VectorCore MME handles attachment, mobility and paging. The HSS provides subscriber and authentication information. Separating their jobs helps keep the architecture clear and makes troubleshooting more manageable.

Giving traffic a path

VectorCore serving gateway control and user-plane processes connect the radio side to the packet gateway. Open5GS session management and user-plane processes provide the packet-gateway side of our LTE arrangement. Our Internet APN has IPv4 and IPv6 pools; IMS has its own IPv4 pool. Linux routing joins these functions to public space and hosted services. Much of my work is making the interfaces, policy and timing agree.

Decisions and packet forwarding

A mobile core has two different kinds of work: deciding what a connection may do and carrying its packets.

The control plane

The MME and HSS handle identity, attachment and mobility decisions. Serving and packet gateway control functions arrange sessions and policy. They create the instructions that say how an authorised connection should be forwarded.

The user plane

The user-plane functions move the traffic using those instructions. PFCP carries forwarding rules between the separated gateway control and user functions. This approach is called Control and User Plane Separation, or CUPS. It also gives us a useful direction for future expansion: regional forwarding can move closer to radio sites while central functions continue coordinating service.

From the phone to the Internet

Mobile Internet joins radio tunnels, gateway forwarding, routes, addressing and DNS into one complete journey.

Outward and back

Packets leave the mobile tunnels through gateway user-plane functions and enter Linux routing. Internet IPv6 uses Lodestar public space. Private IPv4 uses a public translation pool when leaving transit. Routing policy selects the outward path, while BGP announcements and translation state help replies return to the right session.

Local services and names

More specific routes reach hosted services and gateway addresses. Discard routes cover unused destinations inside our public aggregates, preventing loops. DNS turns names into addresses through our dnsdist frontend and primary and secondary Unbound resolvers, with caching and upstream family filtering. A working connection needs both a usable packet path and the services applications depend on.

Policy and quality of service

Policy connects a subscriber’s authorised service to the way the network handles their traffic.

What a bearer does

An EPS bearer gives LTE a context for carrying a device’s traffic with particular treatment. The default bearer provides basic connectivity. Additional bearers can support specific traffic where the service and network allow it. Radio capacity is still shared between devices using the cell.

Where decisions are made

The Policy and Charging Rules Function, or PCRF, supplies policy decisions in the LTE architecture. Gateway control uses the Gx interface, while IMS can describe session requirements through Rx. Our IMS routing includes call-time Rx handling to connect session information with the policy layer.

From a rule to a packet

A decision has to reach the forwarding functions before it can affect traffic. PFCP carries the instructions for separated gateway control and user-plane functions. SIP arranges a call, Diameter carries policy exchanges and RTP carries the audio itself. These protocols work on different parts of the same service.

Why the whole path matters

Clear speech depends on more than a priority setting. Radio scheduling, backhaul delay, packet loss, media negotiation and gateway forwarding all contribute. Understanding those dependencies is useful for community builders: trace the complete journey and understand which part is responsible for the behaviour you are trying to improve.