I’ve been working for a couple months now to create the software infrastructure for allocating wireless data network resources based upon the product purchased by the subscriber. This means granting them access to the purchased resources, and denying access to other resources. This is one of the functions of the PDSN, in cooperation with the AAA server.
I post trouble reports and questions as they arise to the TeleTips Message Board for the Starent PDSN. Here is a step-by-step procedure for testing on the PDSN.
- Login to the PDSN to monitor the test data session
- Turn-on screen logging in putty or whatever terminal emulator you use.
- Initiate a monitor command
- Make a data call from the test handset.
- After the test completes turn off logging in your terminal emulator.
- Dump handset and PDSN configuration data.
- Depending on the nature of the failure, increased logging might be helpful
Give the log file a helpful name, as you might want to refer back to it later. There might be many test attempts so consider using a file naming convention that describes what the test was for, when it was done, and whether or not is was successful. Success or failure of the test could be added to the filename after the test completed, of course.
[local]pdsn1# monitor subscriber msid 000003036995136
This command uses the MIN of the test handset, preceded by 5 zeros. The monitor command has many options, so investigate for yourself what works best. Increase the verbosity of output from the monitor command by entering from 1 to 4 “+” signs (plus symbol) on the command line.
If you are making frequent changes to the PDSN ACL or the AAA profile for this handset it is a good idea to power-cycle the handset before every test call to clear any previous data session. Failure to do so can lead to unpredictable and probably confusing test results.
If the test was successful note that in the name of the log file according to your naming convention. Then archive the log file. This procedure is completed. If the test was not successful, read on.
For the test handset use this command or a variation:
show subscriber full username <username>
where <username> is frequently of the form <MDN>@<yourdomain.com>. Your network will have its own form of username. This command prints various statistics about the test handset. This outpu, too, could be logged for later reference or analysis.
This is not commonly done, but might help. First a log rule must be put into the ACL being tested. See NN20000-197 page 276, or the Starent documentation as appropriate. This can be quite verbose so evaluate if it appropriate to use this command at all in your network, or consider to do this testing at a period of low data traffic.
After the log rule has been added, enable logging:
logging filter active facility acl-log level debug
Then to start logging:
logging active
To stop logging:
no logging active
That concludes the basic test procedure. Now comes the heavy lifting of analyzing all the data to determine what might be causing the error. Make a change trying to correct it, then repeat this test. I recommend logging every test call, and saving all log files until testing is 100% completed and the products being developed are in service before deleting them. Good luck!