The Challenges of Mobility Network Software Testing - Considering RAN/Core Testing

Software is in general harder to test than hardware. Hardware testing is relatively pretty much deterministic. Usually we are facing instances where it either works or it doesn't under a predetermined set of operational conditions, such as temperature and humidity. We can drop test, heat test and splash test handset and network hardware. We always have the possibility also test individual hardware components or modules -- passive and active components , DSPs, memory, and and microcontrollers against precise pre-determined or specified performance specifications.
Software by its nature is less deterministic. We cannot always simulate or predict software behavior under all operational conditions. The way or manner in which code has been written and compiled by individual vendors may determine the behavior of the code. We have usually noticed that even with 2G handsets, the majority of product recalls and in-service problems tend to be related to software implementation and defects. Today, given that the 3G to 4G transition certainly implies an order of magnitude increase in handset code footprint (from 100,000 to 1 million lines of code) , it is not unreasonable to expect an order of magnitude increase in software related compatibility and performance issues

Software adaptation, compatibility and performance issues remain a reality as we get into the network scope. Consider, for a basic example, the functions that need to be performed by the software in the Radio Network Controllers (RNC). The RNC receives and manages traffic to and from the Node Bs (base station transceivers) and to and from the core network (CN). In addition, the RNC has to supervise or administer hard and soft handover and internode and inter-RNC load distribution. The RNC is responsible for preserving the properties of the offered traffic going to
and coming from each of the users served by each of the Node Bs under its control.
This includes arbitrating access and policy rights and managing session quality for individual users including the allocation of radio and network resources to meet user application needs that are, potentially, perpetually changing. The RNC has to decide on resource allocation and admission on the basis of interference measurements received from the radio physical layer and congestion measurements received from the network
core. This is a dynamic, decision-intensive, software-intensive process.

Because it is difficult to define all possible loading and operational conditions, it is difficult to define how the RNC software will behave. This makes it hard to agree on consistent inter-vendor rule sets against which RNC performance can be measured. It also makes it hard to define specific performance metrics. As a result if we cannot define specific performance metrics for the RNC, it becomes extremelly difficult and almost impossible to correctly test the RNC software. Given that the RNC substantially defines network performance including the Quality of Service (QoS) metrics that we are using as the basis for billing - we have by implication an intrinsically untestable network. Untestable or hard-to-test networks, or a lack of agreed upon performance metrics against which network performance can be tested, tends to result in performance and payment disputes, which are undesirable for all parties involved.

In a relevant and similar manner, the same can be mentioned about the new radio access and core network nodes software in 4G networks. Let's pick for example the MME (Mobility Management Entity) which software is pretty complex and elaborate based on its functions.

MME is the key control node for LTE access network. It is responsible for tracking and paging procedure including retransmissions, and also for idle mode of User Equipment (UE). MME is also involved in bearer activation and its deactivation procedures, to its task also belongs choosing the SGW for a UE in process of initial attach and when the intra-handover take place which involves Core Network (CN) node relocation.
MME is responsible for authenticating user towards the HSS, if user is roaming MME terminates S6a interface towards user's home HSS. All Non Access Stratum (NAS) signaling terminates at the MME point, which is also responsible for generation and allocation of temporary UE identities (GUTI). Among its duties is also authorization UE to Public Land Mobile Network (PLMN) and enforcing UE roaming restrictions if there are any. MME is also termination point of ciphering and integrity protection for NAS signaling. Lawful Interception (LI) of signaling could be also supported by MME entity. It also provides the control plane function for mobility between LTE and 2G/3G networks by the S3 interface( from SGSN to MME).

As with handset software, the 3G-to-4G transition just as the 2G-to-3G transition on the core network side implies an order of magnitude increase in RNC software component count and complexity. It is not unreasonable to expect an order of magnitude increase in software-related network compatibility and network performance issues.

User login



Syndicate content





Stay Connected

Who's new

  • catalyst_one

Sponsored Links

Volutpat Consequat

Pharetra Sed Tempus


Donec Lorem Interdum