Monitoring virtualised RAN architectures requires virtual software probes. The network flexibility enabled through cRAN, vRAN and xRAN to dynamically reconfigure RAN on demand means RAN network elements and configurations will change more frequently than non-virtualised RAN networks.
The same Orchestration systems that instantiate and manage the virtualised RAN network will now also have to instantiate and manage virtualised RAN probes, with the same network independence issue mentioned above for the core network probes. Many types of QoS or QoE problems will no longer be visible with virtualised probing. Virtual probe configurations may not match the RAN configuration exactly, or RAN configuration errors may be mirrored in the virtual probing configuration.
Network Equipment Stats
Extracting network or service performance counters from virtualised network elements is in one way easier than collecting from physical elements. Instead of connecting to each physical network element to extract the relevant data, data can be collected from all the virtual elements using instantiated virtualised data collectors.
However, because the 5G network is significantly more complex there are many more instances of network elements to collect data from. Dynamic network slicing requires data collectors to be dynamically instantiated and to adapt to new network element types and instances. Additionally, Load-balancing and dynamic routing of user-plane traffic means that stats collected from specific devices (e.g. gateway traffic routers) can no longer be assumed to be related to specific services. The relationships between specific network elements (physical or virtual) and the services they deliver are now no longer simple nor deterministic. Mobile Edge Computing (MEC) and Control/User Plane Separation (CUPS) also introduce many more network element types and instances to be monitored and many more sets of performance data to be collected.
In summary, an increasingly complex and dynamic network means network equipment stats collection is now significantly more complex and therefore significantly more expensive.
Against a background of increasingly complex and dynamic Core and RAN networks, drive testing has a distinct advantage over network probing. The size, complexity and dynamic nature of Core and RAN doesn’t need to be reflected in the complexity of a drivetest solution measuring QoS or QoE. Drivetest probes generally measure from the device/subscriber’s perspective of a service, and thus treat the underlying network as simply a “black box” delivering the services.
However, drive testing covers only a very small percentage of each network, and requires expensive equipment and/or professional services to be used on a regular basis. So while it is isolated from 5G complexities, drive testing is not scalable to cover the whole network.
Static Test Probes
As with drivetest probes, static test probes also take the device/subscriber’s perspective when measuring QoS. Network complexity, scale and dynamic nature will not impact the complexity of a static test probe-based solution.
However, as with drivetest solutions, static test probes only cover a very small percentage of the network, and are also not scalable to cover the whole network.
From a device’s perspective, the network is simply a “black box” delivering services. Virtualisation, Slicing, MEC, and CUPS will determine exactly how the Core and RAN networks are configured to deliver services, but these network changes do not change how we measure the quality of the service at the end-device. Like drivetest and static test probes, the complexity of any device-based QoS/QoE solutions is not impacted by the complexity of the network used to deliver the measured services.
Key service measures such as latency, throughput and success rate are all likely to be affected by how the network is configured, but the algorithms used to calculate those performance measurements on the device do not change. No matter how complex or dynamic the underlying network is, the measurement methodology on the end device is the same.
QoS and QoE Measurement: The Ideal Solution
In an ideal world, a solution to measure the QoS and QoE for services delivered from a network should have the following attributes:
Excellent geographical coverage, in terms of the % network covered
Matches actual Subscriber Behaviour, where measurements are made while moving around and from locations visited by real subscribers
Delivers enough data for measurements to have statistical significance
Delivers a single set of homogeneous measurements, and not multiple mismatched sets of vendor-specific KPIs
Agnostic to the dynamic and complex configuration of the network being monitored
Measurements are done from actual Subscriber Devices, delivering very accurate QoE and QoS measurements
Provides good value, where enough QoS/QoE visibility is delivered at an acceptable price point