Defining Subscribers

The Subscriber Database contains all of the information that is required for the identification, authentication, authorization, service provisioning, routing, policy and charging decisions, and location tracking of mobile subscribers. In addition, it can control the behavior of those subscribers during your test. All node emulators that handle subscriber data must reference a database. Nodes can, and should, share the same database, ensuring that subscriber data is always current among all of the nodes in your test. Although a Subscriber Database is loaded as part of a node configuration, databases are independent objects within dsTest and as such must be uniquely named if more than one database is present. This separation from node emulators also allows you to replace a database - effectively loading a new test - while the nodes remain connected to their peer(s).

Structurally, the Subscriber Database is partitioned into three major sections:

Global Configuration: settings that apply to the database itself or to all subscribers.

Subscriber Profiles: general network and specific application profiles that are assigned to groups of subscribers.

Subscriber Group: defines unique values for a set of subscribers and associates subscribers with their profiles.

The number of subscribers, which is limited by your license, and the database name are attributes of the root element of the database. The XML below defines a database named "spr_db" consisting of ten thousand subscribers.

<subscriber_database name="spr_db" count="10000">

.

.

</subscriber_database>

Subscriber Profiles

Subscriber Profiles are groups of settings that are related to a network service - authentication, policy and charging control, subscription, etc. Your Subscriber Database must define the profiles associated with the interface applications involved in your test. Where there is common functionality between technologies the same profile is used. For example, the Policy and Charging Control (PCC) Profile and the Subscription Profile would both be used in an 4G Gx test as well as in a 5G Npcf_SmPolicyControl test. Within a profile you may find different structures for different technologies when the composition of those structures varies widely from one technology to another. Within the Subscription Profile, for example, you'll find a PDP Context structure for 3G testing, an APN Configuration structure for 4G testing, and a PDU Configuration for 5G testing. Within the PCC Profile you'll find a Service Profile that is used for both 4G and 5G testing.

Your database can contain multiple instances of the same type of profile, each identified with a unique name, and many of the structures within profiles also support multiple instances. This enables you to define, for example, different Subscription Profiles that mirror tiered services offered in a network and then test the throttling functionality in your 4G gateway or the policy decisions made by your 5G PCF.

Profiles are associated with groups of subscribers in your database and all subscribers in the group will initially use the same profile. You can also change which profile is assigned to an individual subscriber while the test is running, simulating an administrative change, with SmartProfile.

SmartProfile

Unlike other profiles, SmartProfile is not related to a network service. It is the dsTest profile - where you will design the logic of your test. If your test requires more complexity than "attach these subscribers, wait 30 seconds, and then detach these subscribers" you'll be using SmartProfile. Here again, you can define multiple profiles that are assigned to different groups of subscribers, enabling you to define a mix of activities and behaviors that would more closely emulate live network traffic. You cannot, however, change which SmartProfile a subscriber is using.

Within SmartProfile you'll find:

Delayed Response Type: randomly delay responses to the specified event.

SmartWeb: define email and/or HTML content to be used by SmartEvents.

SmartEvents: an event-driven state machine that enables you to design subscriber behavior, coordinate interface applications, add custom measurements, validate incoming message content, and alter outgoing message content. Each subscriber independently travels through the state machine, and you can define branches that will conditionally or randomly cause a subscriber to take a different path and perform different actions. If you use dsClient Desktop you can draw your state machine on a canvas, and use the application's SmartMonitor feature while the test is running to observe SmartEvents statistics and even trace one subscriber's journey through your state machine. Read more about SmartEvents in our solutions pages.

SmartFlow: gives you total control over message content and timing. You define the outgoing message content, including where individual subscriber information will be placed, as well as templates to recognize incoming messages (either requests or responses) and then define the message flow in a simplified state machine. User-defined events allow you to coordinate SmartFlow and SmartEvents state machines. You can see the currently supported SmartFlow protocols here.

Subscriber Groups

The data contained within a Subscriber Group is individually stored for each subscriber. This is due to the nature of said data - subscriber identities and authentication keys that must be unique for each subscriber, and dynamic network data such as server node identities which may vary from subscriber to subscriber as the test advances. Subscribers are typically grouped together because they should share the same profiles, because they will be performing the same actions, or because their identities are contiguous (i.e., the next subscriber's identity is formed by incrementing the previous subscriber's identity).

Subscriber data is organized in the following sections:

Group Profiles: specifies which profile(s) will initially be associated with the group's subscribers.

Subscriber Identities: starting values for the unique identifiers for your subscribers. Numerical identities such as IMSI will automatically increment for each subscriber. Identities that are not numerical by nature present options to insert and increment a decimal or hexadecimal value in a textual identity, and incrementing IP or MAC addresses as well as binary data are also supported. Where contiguous identities are not possible, you can explicitly define each identity and import via CSV file.

Dynamic Information: information that is mainly associated with network data - current serving nodes, VPLMN, area codes, etc. - that may be configured as needed. As the name suggests, this information may change during the course of the test as it is updated through transaction processing.

Fixed Vector Values: starting values for static authentication vectors.

Unless you have configured a dynamic identity, all subscribers must have at least one identity defined, and the identities defined must be unique for every subscriber in the database. Values cannot overlap between groups.

Configuring the Group Size

You can set the size of your subscriber groups using one of several methods. You cannot mix methods within a database.

Range of subscribers: provide the starting and ending subscriber ID for each group. Subscriber ID in this context is the subscriber's one-based index within the database.

Percent of database: each group will consume the defined percentage of the total number of subscribers in the database. The percentages configured for all groups must sum to 100%. Any remainders will be placed in the last group.

Subscriber count: the number of subscribers to include in the group. The sum of all group counts cannot exceed the total number of subscribers in the database.

Unless you have configured the partial initialization flag, all subscribers must be assigned to a subscriber group. No subscriber may belong to more than one group.

Referencing Subscribers

When you need to refer to subscribers in an action command, you can use either of the methods below depending on which is most suitable:

By Subscriber Group name: use this method when referencing an entire group. Giving your groups meaningful names will help to keep your test "readable."

By starting/ending ID: use this method when referencing a single subscriber, a subset of subscribers within a group, or subscribers from more than one group. You can also include a "next" element that defines the first subscriber if you wish to start with a subscriber other than the starting subscriber. In this context Subscriber ID may be the subscriber's index or IMSI.

No matter which method you use, you have the option to randomize the order in which subscribers are used for an action cycle. That order will be maintained through any subsequent cycles.