Replacing Subscribers
Typically when you stop a test you delete the nodes that were created with your test configuration and then load the next test, creating a new set of nodes. When you're working with the same DUT(s) and the same number and types of nodes - in particular when you're working with a large number of nodes or during automated testing - it becomes undesirable to disconnect one set of nodes and then initialize and connect a new set of nodes. In addition to the interruption in testing, this type of activity is not modeling live network behavior. Rather than deleting your nodes at the end of a test, you can replace the subscribers and then start a new test while your nodes remain connected.
This topic will explain how to run any number of tests, while your nodes remain connected, by modifying a subscriber database.
Initial Configuration
First, construct your initial configuration with the functional nodes and interface applications required for your tests. Configure your Subscriber Database in a Subscription Profile Repository (SPR) node that does not run an interface application and configure your other nodes to reference that database. Set the size of your database large enough to accommodate the maximum number of subscribers that will be concurrently provisioned at any given time. If you're running with a floating license those subscribers will be checked out for the entire test cycle. You must set the partial initialization flag if all subscribers will not be provisioned in the initial configuration.
Your database should include the subscriber profiles necessary for the interface applications involved in your tests - authentication, subscription, and PCC profiles, for example. You can provision all of the network-related profiles that will be used in your tests since the memory consumption for those types of profiles is relatively low and they will not consume any licensed resources.
This initial configuration should also include the subscriber group(s) that will be involved in the first test (you must configure at least one) along with the associated SmartProfile configuration. Give meaningful names to your subscriber groups and profiles as this will help you to organize your configurations. If a profile is only used by one subscriber group, give the profile the same name as the group that uses it and load the profile at the same time you load the subscriber group.
Validation rules for subscriber groups apply in this scenario but they apply to groups that are concurrently provisioned - subscriber identities must be unique across all provisioned subscribers and a subscriber may only belong to one group. Since subscriber groups will be dynamic in that they can be provisioned, released, and provisioned again, the size of the group must be specified using the range method, with start and end attributes. The other size methods are not valid for this case. |
Releasing Subscribers and Profiles
When you are ready to replace a subscriber group, follow these steps to release the current subscribers:
1.Ensure that the action command for that group's test has completed or stop the action by setting the rate to 0. (spr:<SPR name> action:<action name> rate::0)
2.Disable the subscribers in that group. (spr:<SPR name> subscriber_database subscriber_group:<group name> enable::false)
3.De-provision the subscribers. (spr:<SPR name> subscriber_database subscriber_group:<group name> provision::false)
Now you can also release any profile that was only used by that group by deleting it:
spr:<SPR name> subscriber_database subscriber_profiles <profile element name>:<profile instance name>;delete:true
At this point the subscribers and their profile(s) have been release and you're ready to load the next test.
Loading New Subscribers
To load your next test, the configuration must include the SPR and the subscriber database that you loaded with your initial configuration. The names of the SPR and the subscriber database must match your initial configuration as must the total number of subscribers. You can include in this configuration any subscriber profiles that will be used by this new group of subscribers along with the subscriber group. The range of subscribers for this group and subscriber identities cannot intersect any group that is still active and the names of the group and profiles cannot match the names of any active groups or profiles.
These subscribers will be disabled when they are loaded and you will need to enable them prior to issuing their action command:
spr:<SPR name> subscriber_database subscriber_group:<group name> enable::true