51. Cellular Network Traffic Simulator

1. General Information

In this document, we will present a model of a Cellular Network Traffic Simulator (CNTS) that would be used to generate traffic in network to test mobile telephony features.

2. Marketing Analysis

This system could be used by

·        Cellular network operator

·        Telecom system provider

3. Product Analysis

3.1 Cellular Network Traffic Simulator

Figure 1. Network diagram of CTNS with other components

3.2 Implementation Proposal

CTNS could be connected to an MSC, HLR, or other nodes under network tests via a Message Routing Center. CTNS could provide the following

·        Emulating an MSC, a HLR, or a Service Provision Node, e.g. voice mail machine, and authentication center, or a message center.

·        Generating traffic load to other “real” nodes such as MSC, HLR, etc.

·        Allowing tests of new features in an emulated environment.

3.3 Graphical user interface

CTNS will provide a friendly user interface that allows users specifying or developing signals, messages with data in windows.

3.4 Message Routing Center

This is a special node or router to route message from the CNTS toward an MSC or HLR under tests. This is to save work in implementation of numbering plan on all components in network.

4. Ericsson’s existing products

Ericsson has developed a product called CTSIM to simulate phone calls from a mobile phone. CTSIM could also provide many calls from different mobile phone numbers that used in traffic mix tests.

Ericsson also has emulated APZ (not APY) to load mobile phone software in order to perform simulated function test by developers before real equipment tests.

In this case we could use emulated APY as CNTS and connecting CTSIM to a real MSC to generate some mobile call traffic.

The CTNS would generate heavy traffic toward real HLR and MSC while network testers performed their test cases. The CNTS could be another MSC in this case.

If users wanted they could develop a platform to load Message Center (MC) sending many SMS toward CTSIM or mobile users on a real MSC. Ericsson has a product called UBSIM, which sends SS7 messages to HLR to test HLR’s functionality. UBSIM could be modified or provided a suite of SS7 messages to generate traffic loads on real MSC and HLR as a MC.

To emulate voice machine such as Octel, we probably have to use emulated CNTS (APY) to generate heavy voice calls, i.e. seizing voice trunks, because there was no ISUP emulator as I knew of.

To make testers life easier, developers should provide a suite of messages in good format. Testers only need to load those templates and modify the messages for each test case. They could create a program or a loop to send numerous messages to a node under test.

It is assumed that usual function tests and system integration test had been done. The main goal of this network test is to create high load and many combination of call traffic in system in parallel. Hopefully a weird combination of calls would come up to fail the system. Each test scenario in this activity would expect successful or failure calls. Thus network tester would load after-test result database including log files on a super computer to crunch data to ensure that successful calls were completed as expected AND some key failure cases failed AND checking a few spots in database to ensure data were not corrupted. There would be many call cases to crunch, thus we must narrow down to check key scenarios.