Primary Objection: Verify the Diameter Routing Agent (DRA/DSC) support of a specific set of performance parameters.
Secondary Objective: Verify the functionality/performance of the other Diameter nodes as needed.
This scenario verifies that a Diameter network element, such as the DRA/DSC, is engineered for, and is capable of, handling and sustaining “normal” expected network traffic levels. The DRA is a critical component of the LTE core network. Among its many responsibilities is that of balancing Diameter signaling in the Evolved Packet Core (EPC) between clients and the available destination servers. Not only does a DRA balance the load but it must maintain session state when interacting with certain servers to ensure that subscriber activity is properly tracked.
This procedures in this dsTest Use Case allows customers to verify these features of the DRA and its ability to support the elements they are deploying meet the stated performance specifications. This Use Case also provides Diameter network simulation by allowing each node and its interfaces to be tested, allowing the test equipment to verify that actions generated on one application interface of the node will result in the generation of an appropriate action on another interface on that node within acceptable timing.
In order to verify a stated reliability goal, such as “three 9s”, the resources (e.g., memory, CPU, buffers) of each node and the links between them must be monitored during the test to ascertain if one or more of the resources are close to a undesirable limit that might be hit if an unusual event occurs. Refer to our EPC Network Node Failure Use Case for an example Use Case when a Diameter node fails.
Additional test runs are required with modified parameters to ascertain the limitations of the DRA/DSC performance. It is not uncommon that devices need to be iteratively tested and tuned to meet the advertised performance limits by using provisioning changes and often with software enhancements or upgrades.
In one instance of this Use Case, we tested the objective with these specific parameters:
- All nodes required for support of the Gx, Ro, and Sy interfaces;
- 10 million active subscribers;
- Each subscriber executing 11 transactions per cycle;
- Average rate of 135,000 transactions per second;
- Each subscriber active for 14 minutes – 7 minutes before update, 7 minutes afterward;
- Subscribers added at 12,500 per second;
- One cycle of 11 million subscribers, resulting in a peak of 30 Million stateful transactions.
The message flow (without the DRA) is shown in Figure 2.
This instance the Diameter Network Simulation Use Case was used to verify the specific capabilities of the DRA/DSC as the device under test. A similar version of the case can be used to verify the performance of the other network nodes as needed.
A key component of building a fast and reliable network includes extensive testing of the network elements that make up that network. Multiple testing methodologies exist and using multiple methodologies provides the best possible coverage so it is vital to include multiple methodologies in any comprehensive test plan.
It is possible to create a hybrid test environment in which a test Diameter network using real network elements is supplemented with emulators of additional network elements. By using a combination of real and emulated network elements, you can create a baseline level of load while also using real network equipment for certain aspects of the test.
Selecting flexible and full featured test tool such as dsTest enhances test coverage and ensures that the needed (and expected) performance, capacity, features, and stability in the equipment that it deploys in its network are predictable and maintainable. With its proven performance capabilities, dsTest provides the ability to identify potential bottlenecks in a test environment before they show up in the network, helping carriers and equipment manufacturers avoid costly downtime by easily scaling an environment to simulate hundreds of millions of subscribers to test capacity, scalability and redundancy.