
IPX test, validation, and active monitoring 2: Systems
IPX test, validation, and active monitoring 2: Systems
In the second of our five-part series on IPX roaming test and assurance we highlight some of the specialised capabilities and functionality of Emblasoft Evolver – and how it adapts to the complex IPX architecture and systems.
Welcome to the second of our five-part series of articles on assuring and validating IPX roaming. In this instalment, we will be focusing on the systems that are essential for IPX roaming.
Continuous assurance and validation of your IPX systems is a necessity. It’s not just that roaming is a significant revenue generator, it’s also that it’s a significant target for attack. So, while your customers take IPX services for granted, bad actors are also trying to use IPX infrastructure to mount attacks on your network or introduce threats to your customers – at home and abroad.
All of which means that this is a constantly shifting domain. Essentially, IPX consists of a series of interconnected entities that serve the different networks and services you run. It’s a complex infrastructure, built on layers of evolution as we have moved from 2G to full 5G SA roaming, with the introduction of data exchange and VoLTE services along the way.
So, you’ll have some legacy components, like SS7 STPs, alongside Diameter elements, like the DRA and firewall – and so on. If you take all of this together, you probably have something that looks, from a functional perspective, a lot like this:

As you can see, there are multiple layers to consider (vertical axis) and related peers (horizontal axis). With such a complex system assembly and the need to ensure consistent, secure performance, you face multiple challenges.
Not only are there multiple interfaces that need to be maintained with the requisite level of performance, but there may also be frequent updates to the deployed system entities that have to be managed and passed through quality assurance procedures.
These updates may be due to regular release programmes from your vendors, but they may also be in response to your security monitoring – patching vulnerabilities detected through following GSMA guidelines, like FS.19 or FS.11, for example. In addition, you may detect performance issues through your assurance processes that mean interim updates are required.
So, all of these different systems need to be managed, controlled, secured, and optimised throughout their lifecycles – which may be many years. After all, your SS7 infrastructure may have evolved through time to cloud-native versions, but it still adheres to the same functional requirements that were demanded when it was introduced, more than 20 years ago now.
To illustrate this complexity, let’s deep dive into a handful of those systems and the specialised testing that needs to be performed – and how Emblasoft Evolver helps.
STP
STPs route legacy SS7 traffic, which in a roaming context remains a high-volume element of the overall traffic mix. Not only do you need to maintain throughput, but you also need to ensure service consistency. So, for example, you need to:
- Load test and measure MSU throughput
- Measure GTT translation rates
- Stress test systems to discover fall-over points
- Understand congestion handling
- Model SCCP functions
- Validate SMS routing
And much more – covering the higher layer protocols involved in roaming, like CAMEL and MAP, as well as all other related layers in the SS7 stack.
SS7 Firewall
This key component is subject to the highest levels of scrutiny, largely through well-publicised and large-scale attacks. You will likely follow GSMA guidelines for testing and validating your SS7 firewalls – both in production and in the lab.
Factors to consider include:
- Inspection Throughput – Deep packet inspection, latency delta, checking for no drops for legitimate traffic at peak periods.
- Rule Evaluation Latency – Including rule evaluation stress tests.
- High-Volume Filter Match
- Logging and SIEM Throughput – Such as audit trail completeness under maximum load and alert storm deduplication and suppression.
- Failopen / failclose – Simulating firewall engine crash at peak load and recovery time and rule resync after restart.
- Soak / Endurance –sustained filtering and blocking testing and false positive baseline testing.
- GT address validation, spoofed Point Code detection, intercept attempt detection, bypass attack scenarios – and much more
Ensuring compliance with best practice is essential to protect your network and customers – which is why continuous testing, based on automated cycles, as well as through delivery pipelines is necessary – and why you also need clear reporting and audit trails so that you can demonstrate compliance when required.
Diameter Firewall
The Diameter Firewall is a similarly vital part of your network and service defences. As a result, testing according to GSMA FS.19 is essential, covering activities like:
- Unauthorised location requests
- Subscriber data exposure attacks
- Checking for advanced Diameter attack patterns
- Command code filtering
- AVP inspection
- Roaming policy enforcement
- Fraud detection
- Load testing
- Deep inspection throughput
- Failopen / failclose
- Soak and endurance testing
All of this – and more – needs to be validated across the system lifecycle, according to automated schedules – with, of course, the requisite reporting and audit trails.
GTP-Hub
GTP Hubs are a vital element in the roaming ecosystem and handle traffic for multiple operators. Some may exclusively use these services, while others may use them alongside their own direct interconnections. The heavy reliance of the roaming community on such Hubs illustrates their vital role in the roaming landscape – and they must be protected as part of critical international infrastructure.
As such, test and validation for continuous assurance programmes is a must, covering factors such as:
- GTP-Cv2 Control Plane for 4G and LTE
- GTP-Cv1 Control Plane for 2G and 3G
- GTP-U User Plane
- Routing and NAT
- Inter-PLMN Connectivity
- QoS and Charging Passthrough
- Load testing
- Throughput and packet loss measurement
- Memory usage at peak session count
- DNS resolution under load
An important consideration is that, since Hubs carry traffic for multiple operators, they must perform at high volume – and will also be subject to more variation as operators change IR.21 service terms for individual interconnections that pass through the Hub infrastructure. As such, there is far more to manage and assure, and far more at stake – because the Hub operator depends entirely on the quality of the service they perform.
Conclusion
We’ve highlighted just a few of the system entities that are likely to be operational in your roaming architecture. Others include:
- DRA – Diameter Routing Agents
- SCP – Service Communication Proxy for 5G
- SEPP – Security Edge Protection Proxy for 5G
- GTP Firewall
- SBC – Session Border Controller
- SIP interconnection paths
This complex array of systems must deliver and is subject to a growing range of threats. To accomplish this, you need a versatile test, validation and assurance solution that is up to the challenge.
And this is a challenge that is going to get increasingly complex, as new, differentiated services based on 5G roaming and new kinds of network roaming partners – like NTNs and NPNs, a subject to which we will return in Part 5 of this series.
Emblasoft Evolver and its integrated active monitoring capabilities ensure that you can verify live traffic streams, while testing your systems and solutions in isolation – providing continuous assurance for your IPX services, whether for direct interconnections or for Hub.
In addition to this and as a complement to active monitoring, Emblasoft also provides passive monitoring solutions that enable IPX to monitor all traffic. Multi-tenant, it also enables the IPX provider to segment traffic and provide visibility to customers – which see only their own traffic.
Contact us to find out more about how we can help you meet your IPX testing and monitoring challenges.