We Built a Private 5G Network From Scratch. Here's What Actually Happened.
This is my first blog post. I wanted to start with something real rather than a generic introduction, so I'm writing about something I actually built.
Most people have used 5G. Very few have built one.
During our final year at Turku University of Applied Sciences, my colleague Onni Rihko and I did exactly that. Together we built a fully operational private 5G Standalone network using real Nokia AirScale hardware and Cumucore 5G Core software, inside a real university research lab. No simulators, no shortcuts. Just real hardware, real configuration, real failures, and eventually real end-to-end connectivity.
Onni handled the physical side: hardware selection, rack assembly, and network architecture. My job was to deploy the 5G Core on top of that foundation, configure every network function, integrate it with the Nokia gNB radio equipment, and validate that the whole thing actually worked.
This is the story of how we built it, what broke, what I learned, and why it matters beyond the grade.
Why this project existed
The Autonomous and Intelligent Systems (AIS) research group at Turku UAS had a straightforward goal: give students and researchers hands-on access to real 5G infrastructure. Not textbooks, not simulations. An actual working system they could configure, study, and build experiments on.
No such environment existed at TUAS. So the AIS group decided to build one, and Onni and I took it on as our parallel bachelor's theses.
Onni's thesis covered the physical design: choosing the Nokia AirScale hardware, assembling the rack, laying out the network topology, and creating the stable infrastructure the whole project would depend on. My thesis built on that foundation by deploying and validating the Cumucore 5G Standalone Core, configuring every network function, and proving end-to-end connectivity in the actual lab environment.
The hardware side had its own surprises too. When Onni was finishing the network in January, the Nokia radio module simply refused to boot. It turned out to be a Power over Ethernet (PoE) problem: the radio module was being starved of power and couldn't start. It had nothing to do with software or configuration, just a physical infrastructure issue. A good reminder that building a real network means dealing with real hardware problems, right down to whether the cables are delivering enough power.
One project. Two theses. One working 5G network.
What I was actually building
A 5G network has two main parts: the Radio Access Network (RAN) and the 5G Core (5GC).
The RAN is the radio side, the gNB (Next Generation NodeB) that communicates wirelessly with devices. The 5G Core is the brain. It handles authentication, session management, subscriber data, and traffic routing.
My job was the 5G Core. Specifically I was responsible for six network functions:
- AMF — Access and Mobility Management Function (device registration, mobility)
- SMF — Session Management Function (session creation, traffic rules)
- UPF — User Plane Function (routes user data traffic)
- AUSF — Authentication Server Function (5G-AKA security)
- UDM — Unified Data Management (subscriber profiles and credentials)
- NRF — Network Repository Function (service discovery between all functions)
The platform was Cumucore 5G Standalone, running on a dedicated Linux server with Ubuntu 24 LTS, integrated with a Nokia AirScale gNB. The same Nokia hardware used in real commercial deployments. The server had three network interfaces: one facing the RAN (enp1s0), one for management (enp2s10), and one internet-facing interface (eno1) for licensing and updates.
This wasn't a toy setup. It was a real 5G Core deployment, and the full documentation is published on Theseus as an open academic resource for future researchers at Finnish universities.
How I approached the deployment
Before touching any configuration I had to understand what I was inheriting. The server, Nokia gNB, cabling, and rack were already assembled by Onni. My starting point was a running Linux server with no 5G software on it and a Nokia gNB waiting to connect to a core that didn't exist yet.
The deployment had four phases:
Phase 1: Environment preparation.
I updated the OS, configured the three network interfaces with correct static IP addresses, and verified routing between segments. The RAN interface (172.24.24.10/24) and management interface (172.24.25.10/24) had to be stable before anything else could work.
Phase 2: Cumucore installation.
Cumucore provides Ansible-based deployment scripts and configuration templates. The installation script handled the runtime environment, dependency checks, and startup of all six core functions. This part was relatively smooth. Within a single session all six functions were running and registered with the NRF, which I confirmed through both command-line log review and the Cumucore GUI.
Phase 3: Core configuration.
This is where the real work was. Every parameter had to match exactly across all components. I configured:
- PLMN identifiers (MCC/MNC) consistently across AMF, SMF, AUSF, and UDM
- Tracking Area Code (TAC) aligned with the Nokia gNB configuration
- Data Network Name (DNN) and UPF routing, including IP pools for user device addressing
- Subscriber profiles in the UDM — IMSI, authentication keys (K and OPc), and slice parameters
Phase 4: Nokia gNB integration.
The gNB needed matching PLMN and TAC values, with its N2 interface pointed at the AMF and its N3 interface pointed at the UPF. I monitored NGAP messages in the Cumucore interface and verified connectivity through AMF registration event logs.
What went wrong (the part nobody writes about)
Every deployment guide describes the happy path. Here's what actually happened on mine.
Problem 1: The gNB wouldn't register with the core.
The AMF was running. The gNB was running. But they weren't establishing an N2 connection. After going through the AMF logs the cause was frustratingly simple: the MCC/MNC values on the gNB didn't match the PLMN configuration on the AMF. The base station and the core were essentially looking for each other on different networks, so neither could see the other.
Correcting the PLMN settings on both sides fixed it immediately. The NGAP Setup Request came through within seconds.
Lesson: In 5G, parameter alignment is not optional. One mismatched value breaks the entire signalling chain and the system fails silently.
Problem 2: User-plane traffic wasn't reaching the UPF.
With N2 signalling working I moved to user-plane testing. N3 traffic, the data path between the gNB and UPF, was not arriving at the UPF at all. The interface was configured correctly, the UPF was running, but the required static routes had simply not been applied to the server's routing tables.
In an isolated research environment with no dynamic routing protocols, every traffic path has to be explicitly defined. The N3 interface was reachable in theory but not in practice because the server had no idea how to get there. Adding the missing static routes fixed it completely.
Lesson: When you're doing static routing you own every path. There's no automatic fallback. You have to know exactly where every packet needs to go.
Problem 3: User authentication kept failing.
The UE was initiating registration through the gNB. The AMF was receiving it. The AUSF was starting the 5G-AKA authentication procedure. But it kept failing. After a lot of log reading the culprit turned out to be the subscriber profile in the UDM. The IMSI, K (authentication key), and OPc (operator code) values stored there didn't match the credentials on the actual test device. The AUSF was running the authentication calculation correctly, just against the wrong keys.
Updating the subscriber profile in the Cumucore GUI with the correct values fixed it. The 5G-AKA procedure completed, the AMF established the UE context, the SMF created a PDU session, and the UPF assigned an IP address.
Lesson: 5G authentication is cryptographically exact. Every single value has to match on both sides.
The moment it worked
After weeks of configuration and troubleshooting, a 5G-capable device connected to the Nokia gNB. The AMF received a valid Registration Request. The AUSF and UDM processed the authentication vectors. The 5G-AKA procedure completed. The SMF created a PDU session. The UPF assigned an IP address. The device reached the internet.
End-to-end. 5G Standalone. In a university lab in Turku. Built by two students from scratch.
I ran ping tests, checked packet captures, and confirmed that traffic was flowing through the N3 interface exactly as designed. All six core functions were running and handling their roles correctly.
The TUAS AIS research group had a fully working 5G Standalone testbed, the first of its kind at the university.
What this testbed can be used for
The environment we built is not just a proof of concept. It's a platform for ongoing research and education.
Future students and researchers can use it to study real 5G signalling flows in a controlled environment, experiment with network slicing, research 5G Core security vulnerabilities safely without regulatory constraints, test IoT device connectivity, integrate additional gNBs for handover testing, and explore edge computing as a next step.
The modular design, Onni's physical architecture combined with my software configuration, means it can grow with future needs. It's a stable, documented, repeatable platform that will be useful for years.
What I learned that no lecture taught me
Parameter alignment is everything in 5G. The Service-Based Architecture gives each network function independence but they all depend on consistent identifiers across the whole system. One wrong value cascades into failure in ways that can take hours to trace.
Real hardware always surprises you. The Nokia gNB's behaviour during initial configuration was not in any guide we were given. Real deployments always have undocumented edge cases. The skill is reading error messages carefully and working through problems systematically rather than guessing.
Log analysis is the most important skill in network engineering. Every problem above was solved by reading logs, not rebooting and hoping. AMF registration logs, AUSF authentication logs, UPF session logs. The system tells you what's wrong if you know how to listen.
Modular architecture makes sense when you live it. I had read about 5G's Service-Based Architecture in papers. Deploying it in a real lab is completely different. Being able to restart the AMF without touching the UPF, update a subscriber profile without restarting the core, monitor each function independently. Now I understand why 3GPP designed it this way, not as an abstract concept but from actual experience.
Documentation is part of the work. My thesis is published openly on Theseus so that any future student building something similar in Finland has a starting point. Good engineering means making sure the next person can build on what you did.
Read the full research
Both theses are published on Theseus, Finland's open academic repository:
Developing and Validating a 5G Core Test Environment Using Cumucore
Ravi Sanghani · Turku University of Applied Sciences · 2025
https://urn.fi/URN:NBN:fi:amk-2025121938580
Creating a Private 5G Test Network for Research and Education
Onni Rihko · Turku University of Applied Sciences · 2026
https://urn.fi/URN:NBN:fi:amk-202602042278
If you're building something similar, a private 5G lab, a Cumucore deployment, a Nokia gNB integration, feel free to reach out. The problems are well documented and I'm happy to share what I learned.
Ravi Sanghani is a cybersecurity and 5G engineer based in Turku, Finland, open to roles in cybersecurity engineering, network security, and 5G infrastructure across Finland and Europe.
hello@ravisanghani.com · ravisanghani.com · linkedin.com/in/ravi-sanghani