Testing a mobile core in isolation does not work. A tariff change affects how the network treats subscriber traffic: which apps are counted, what is blocked. Many scenarios only show up when all components interact. Testing on an operator's live infrastructure is also hard: access is temporary, resources are shared and repeated debugging is rarely possible.
So we built our own lab that emulates a mobile operator network. Here is how it is structured and what went wrong.
Architecture: classic EPC with CUPS
The lab follows the classic EPC with Control and User Plane Separation (CUPS). The control plane decides which services a subscriber gets; the user plane moves the traffic.
- MME — subscriber registration and attach procedures
- HSS — subscriber data, SIM profiles, service parameters
- SGW — carries user traffic between the radio network and the PGW
- PGW/PCEF — internet access, IP assignment, charging rules enforcement
- DPI (as UPF) — user plane: classifies applications and protocols, tracks traffic by category, enforces policies in real time
PCRF and OCS come from our technological partner. The PCRF handles service policies (tariffs, restrictions, QoS); the OCS handles online charging and real-time balance deduction. Our PCEF talks to both over Diameter, on the Gx and Gy interfaces.
Radio side: one emulator, one real small cell
- srsRAN runs on a standard server with an SDR module. It is open source, lets you deploy a full eNodeB and change frequency band, bandwidth and power quickly.
- Baicells small cell is industrial equipment with dedicated voice channels. It is less flexible but closer to production. We use it for VoLTE tests with dedicated bearers and QCI=1.
ePDG and VoWiFi in the lab
When a phone connects over Wi-Fi, it establishes an IPsec tunnel to the ePDG, then traffic enters the core as it would over LTE. For the user it feels the same: same number, same voice services, same charging logic. For the network it is a distinct traffic type that must pass DPI and PCEF correctly and be processed by the same rules as LTE sessions. The ePDG also lets us test LTE-to-Wi-Fi handover without session interruption.
Where it hurt
1. Billing integration. Making PCEF work with PCRF and OCS requires many parameters to match exactly:
- subscriber identifier formats
- MCC/MNC encodings
- session parameters
- quota rules
Even small mismatches caused request rejections and errors. Diagnosing them took deep knowledge of 3GPP specifications and analysis of Diameter session logs.
2. srsRAN has no dedicated bearers, and full VoLTE needs them. We adapted the Kamailio IMS server so that, even if the radio network does not create a dedicated bearer, the call continues over the default bearer. For testing purposes this was enough.
What we test
- Quota exhaustion. A subscriber gets a 100 MB package. We check how DPI counts traffic, how precisely PCEF requests a new quota from the OCS, and what happens at the limit. While blocked, a whitelist must keep DNS and operator services reachable.
- Charging exemptions. Unlimited tariffs and prioritization: specific app categories (for example messengers or navigation) must not consume the main data package. DPI identifies the traffic, PCEF decides whether to charge.
- Roaming. A phone with a different MCC/MNC (we load another PLMN on the SIM) must be processed correctly along the whole chain from HSS to OCS.
- Voice and video via IMS. The full VoLTE cycle: SIP registration, media session setup, voice between two subscribers.
- LTE-to-Wi-Fi switching. One subscriber on LTE, one on Wi-Fi, both registered in the same IMS. The call must work, and after one switches from Wi-Fi to LTE the handover must complete without interruption.
Takeaways for your own lab
- Keep a reference list of identifier formats and encodings (MCC/MNC, subscriber IDs) and check it first when Gx/Gy requests are rejected.
- Keep Diameter session logs from day one. They were essential for diagnosing the billing mismatches.
- Use an emulator for flexibility and one real base station for production-like behavior.
- Treat VoWiFi as its own traffic type in your policy tests.
We use this lab to verify new features, reproduce complex network situations and demonstrate solutions to customers. More about our products: PGW and PCEF. Original article: How We Deployed Our Own Mobile Operator Test Lab.
Top comments (0)