Patent Application
20070281684
Although the invention will be described in terms of a specific embodiment, it will be readily apparent to those skilled in this art that various modifications, rearrangements and substitutions can be made without departing from the spirit of the invention. The scope of the invention is defined by the claims appended hereto
System acquisition testing of the instant invention centers on the testing the Preferred Roaming List (PRL), System Acquisition algorithm, and device performance. Of these three areas, the central part is the PRL file. This file contains all the information that the algorithm needs to select the correct system from the available ones. Because carriers provide services in varying geographic regions e.g. US, Brazil, Korea, etc, each carrier creates its own PRL file that reflects the systems used by their customers. Thus any test solution must be able to use a PRL file specific to the carrier and device type e.g. 1X or 1xEV-DO device type, or hybrid devices which do both 1X and EV-DO.
Although the specific entry in a PRL will vary from carrier to carrier, the format of the entry is specific to the PRL type. The Telephone Industry Association/Electronics Industry Association (TIA/EIA) has a standard that describes a data format to be used for system table records in a PRL entitled “Over-The-Air Service Programming Of Mobile Stations in Spread Spectrum Systems”, (“IS-683-A Standard”), the contents of which is hereby incorporated by reference in its entirety. The IS-683-A Standard provides that each system record in the PRL will have the following eight fields:
1. SID field: a 15 bit field that includes a numerical value that is the System Identification number of the system associated with the system record;
2. NID_INCL field: a 2 bit field, the least significant bit of this field indicates whether there is a Network Identification (NID) number associated with the system record and stored in the NID field described below; the most significant bit of this record is used to specify an assumed value for the NID if no value is stored in the NID field described below; the value 11 is a reserved value;
3. NID field a 16 bit field that contains a numerical value that is the Network Identification number of the system associated with the system record;
4. PREF_NEG field: a 1 bit field indicating whether the system associated with the system record is a preferred system or a negative system.
5. GEO field: a 1 bit field that indicates whether the system associated with the system record is within the geographic region of the previous system record in the PRL (if GEO=1) or, alternatively, whether the system is in a new geographic region (if GEO=0);
6. PRI field: a 1 bit field that indicates whether the current system record has a higher priority than that of the next system record in the PRL. This field is omitted from the system record if the PREF_NEG field indicates that the system associated with system record is a negative system;
7. ACQ_INDEX field: a 9 bit field that contains an index to the acquisition parameters required for the mobile phone to access the system associated with the system record;
8. ROAM_IND field: an 8 bit field that indicates the roaming status of the associated system record; this field is omitted from the system record if the PREF_NEG field indicates that the system associated with system record is a negative system.
The PRL is stored in the mobile phone's non-volatile memory and, during system initialization, the entire PRL is moved and stored in the unit's RAM for later access during a System Selection and Preferred Roaming operation. Thus, a generic test plan can be created that will load a specific PRL into the test device, read and categorize the entries in the file and then use the information to set the parameters on the emulation hardware needed for each test case. The Generic System Acquisition test suite will use base station emulation (BSE) hardware to create the required RF conditions of each test scenario. The settings will be taken directly from the test PRL file. The following is a step by step example of adaptive testing of system acquisition and roaming characteristics for CDMA wireless communication systems.
The generic system determination test suite will work with IS683A, IS683C and IS683D formatted PRL files. The user will specify the PRL file to be used for testing and the application will automatically load it into the device being tested. It is recognized that while the stated PRL files are current format, the automated testing program of the instant invention is readily adapted to any future changes in the PRL file formatting.
Based on the PRL entry, the automated system determination test suite will determine the relationships between different PRL entries in the test file. This includes:
Once the entries are categorized the test script will then select the entries need to create the required test conditions on the base station emulation hardware.
The Generic System Acquisition test plan has a number of scenarios which need to be testing for both 1X and 1xEV-DO based devices. The next section, Test Scenarios, provides a full detail of all the test scenarios which will be included in the product. When the test is executed, the user will select the areas to be tested through the applications GUI. Based on the select, the application will control the required number of emulators and set the needed RF conditions.
The test suite will use base station emulation hardware to create the RF conditions stipulated in the test case. The exact RF conditions will be based on the entries in the test PRL.
Once all the system parameter information is extracted from the PRL file and all the combinations of systems is created as per the requirements of each test case, the test is executed, with the automation scripts setting the parameters on the BSE and managing the test device as it is programmatically controlled through the test procedures.
Example: The following illustrate how the process will work for sample PRL 12345.
1) Test PRL
2) Test Case—Rescan
This test verifies the rescan functionality. Rescan tests that once a device acquires a system and a more preferred system is presented, the device will acquire the more preferred system during the rescan process. This test only evaluates systems in the same GEO.
3) Create RF/System Pairs
The test plan calls for pairs which are in the same GEO and where the second set of RF parameters is of higher priority than the first. In this PRL indices 0-3 are in the same GEO. Indices 0, and 1 are of the same priority. Index 2 and 3 are of the same priority to each other, but both are of lesser priority than indices 0 and 1. Index 4 is of a different GEO. From these relationships we get the following pairs of RF parameters for the test.
4) Test Execution
Each of the test pair created in step 3 will be set on the BSE and the performance of the device under test will be measured according to the procedures and expected results in the test procedure document.
From this example it should be clear that as the entries in the test PRL change, the pairs used for testing will also change. The unique feature of our testing approach is that the test software will automatically adapt to the different PRL files and modify each test scenario that is executed for each test case based on the differences.
APIs are used to create dynamically all the possible test scenarios that can be found in a PRL for any given test case. The test employs the appropriate APIs for automation.
Test Scenarios:
The following outlines test cases for 1X and 1xEV-DO System Determination. These tests are executed on the 1X mode for the device being tested.
Acquisition—This test verifies the device's ability to acquire any non-negative system listed in the test PRL. The procedure tests all entries independent of priority or GEO. Once the device acquires the system, MO and MT call processing is tested.
Available System—This test verifies the device's ability to acquire a system that is not explicitly listed in the PRL. The test picks a unique channel from the acquisition table and associates it with a SID not in the PRL.
Negative System—This test verifies the device's ability to not acquire a system designated with negative priority in the PRL. The test will also cover E911 call processing where the system should be acquired and the call should be processed.
Rescan—This test verifies the rescan functionality. Rescan tests that once a device acquires a system and a more preferred system is presented, the device will acquire the more preferred system during the rescan process. This test only evaluates systems in the same GEO.
Silent Redial—This test verifies the device's ability to call process using the Silent Redial algorithm. This test verifies the device's ability to redial on systems with the same, lower or higher priority in the same GEO.
PRL Uploading Test—This test verifies the device can receive and update the PRL on the phone when a PRL of size less than maximum, at maximum, greater than maximum size is uploaded. An IS-683A formatted PRL is tested. Upload using OTASP and PST is verified.
Global Service Redirect—This test verifies if the device can be re-directed to a second base station using the GSRM protocol. The redirection should be to a system that is of equal, lesser or greater priority. Also it verifies redirection using the SRM and EGSRM protocol
Custom Channel Test—This test verifies the device's ability to acquire a custom cellular channel from a standard preferred cellular channel, if any are listed in the PRL. It then tests if the handset can move back to a more preferred standard Preferred Cellular Channel.
Registration Lost During Idle State—This test verifies the device's ability to acquire a system that is of equal, lower or higher priority after the losing the current system in idle state.
Registration Lost During Traffic State—This test verifies the device's ability to acquire a system that is of equal, lower or higher priority after the losing the current system in traffic state.
Deep Sleep—This test verifies the device's ability to go into deep sleep after 15 minutes once the current system is switched off. While in deep sleep, the device wakes up every 3 minutes to scan for an available system. This test is conducted for one entry in each GEO in the PRL.
Most Recently Used—This test verifies the device's ability to acquire a system that is listed at the bottom of the GEO and the channel is listed in the MRU table.
Wildcard System ID—This test verifies the device's ability to acquire a wildcard system listed in the PRL, if any are listed in the PRL.
Rescan to Different GEO—This test verifies the device's ability to rescan to a system on a different GEO.
Max Access Probes—This test verifies the device's ability to register on a new system after receiving Max Access Probes exit from the current system. It verifies the device can register on a system with the same, lower, higher priority or available system in the same GEO.
Idle Handoff—This test verifies the device's ability to hand off to a new system from a current system.
Emergency Call on Negative System—This test verifies the device's ability complete an E911 call when no service is available and only a negative system is preset, when the device is registered on a most preferred system but fails to connect and a negative system is preset.
OTASP Dialing—This test verifies the device's ability to complete an OTASP call on the appropriate system when a particular number is dialed (e.g.*22800, *22801 etc.,), with the SPC set to either all zeros or non-zeros and MRU being either empty or not empty.
Acquisition Match Only—This test verifies the device ability to acquire a system with a channel of the same band class with the SID listed in the PRL but no system table match. The test also verify the device ability to do a proper rescan exit.
Call Release Scan—This test verifies the device's call release behavior from a most preferred system, a less preferred redirected system, and after HHO.
NDSS Behavior—This test verifies the device's behavior during Network Driven System Selection to a different type system and band class.
Cam Behavior—This test verifies the device's behavior during Channel Assignment Messaging to different channels and band classes.
Hashing Behavior—This test verifies the device's behavior during hashing on a valid and invalid channel.
Enhanced PRL Testing—This test verifies registration and international roaming based on MCC, MNC fields in the PRL.
Adversarial Conditions—This test verifies the handset behavior during adverse conditions such as handoffs, re-direction, max access probes, E911 etc.
1XEV-DO Testing—The test cases in this section should be run on 1xEV-DO devices set to the hybrid mode.
Hybrid Mode Acquision—This test verifies the device's ability to register on a 1X system and open session on all collocated EVDO systems. If an entry has no collocated system, the test evaluates only the registration, voice call and data call on the 1X system. However an EVDO system is available, voice calls are verified on 1X system and data call on the EVDO system.
Negative Systems—This test verifies the device's behaviors on negative systems when operating in Hybrid mode. If applicable the following scenarios are verified from the PRL:
Available System—Available System tests the device's ability to acquire a system that is not explicitly listed in the PRL. The test picks a unique channel from the acquisition table and associates it with a SID not in the PRL.
Rescan—This test verifies the rescan functionality. Rescan tests that once a device acquires a system (1X and or EVDO) and a more preferred system (1X and or EVDO) is presented, the device will acquire the more preferred system during the rescan process. This test only evaluates systems in the same GEO.
Silent Redial—This verifies the device's ability to call process using the Silent Redial algorithm. This test verifies the device's ability to redial on systems with the same, lower or higher priority in the same GEO.
Receiving a Call during a Data Session—This test verifies the device's ability to monitor the 1X paging channel and receives a phone call, while in a data call with the EVDO system.
System Acquisition During Traffic State—This test verifies the devices' ability to satisfy the following hybrid mode system access requirements:
PRL Upload Test—The test verifies if the device can receive and update the PRL on the phone when a PRL of size less than maximum, at maximum, greater than maximum allowed size is uploaded. The test uses an IS 683C formatted PRL. Upload using OTASP and PST is verified.
Global Redirect in hybrid mode—This test verifies the device's ability to be re-directed to a second 1X base station using the GSRM protocol. After re-directing the 1X mode, the EVDO registration also moves to a collocated system with the new 1X signal. The testing is conducted for all collocated systems for a given 1X system to all collocated systems associated with the redirected system. The redirection is to a system of equal, lesser or greater priority.
Custom Channel—This test verifies the device's ability to acquire a custom cellular channel from a standard preferred cellular channel, if any listed in the PRL. It then tests if the device can move to back to a more preferred standard Preferred Cellular Channel.
Registration Lost During Idle State—This test verifies if either the 1X or collocated EVDO signal is lost, the device can:
Registration Lost During Traffic State—This test verifies the devices ability to re-acquire either a 1X or EVDO signal if either the 1X or EVDO signal is lost during a traffic state. If the EVDO signal is lost, the procedure expects the device to re-acquire a collocated system. If the 1X system is lost and a higher or lower 1X signal is provided, the device should register on the new 1X system along with its new collocated EVDO system.
Deep Sleep—This test verifies the device's ability to go into deep sleep after 15 minutes once the current system is switched off. While in deep sleep, the device wakes up every 3 minutes to scan for an available system. This test is conducted for one entry in each GEO in the PRL. The test covers the following scenarios:
Most Recently Used—This test verifies the device's ability to acquire a 1X system along with its collocated EVDO system that is listed at the bottom of the GEO and the channel is listed in the MRU table.
Wildcard System ID—This test verifies the device's ability to acquire a wildcard system listed in the PRL, if any in the PRL.
Rescan to Different GEO—This test verifies the device's ability to rescan to systems on a different GEO.
Max Access Probes—This test verifies the device's ability to register on a new system after receiving Max Access Probes exit from the current system. It verifies the device can register on systems with the same, lower, higher priority or available system in the same GEO.
Idle Handoff—This test verifies the device's ability to hand off to a new system from a current system.
Emergency Call on Negative System—This test verifies the device's ability complete E911 call when no service is available and only a negative system is preset, when the device is registered on a most preferred system but fails to connect and a negative system is preset. If applicable the following scenarios are verified from the PRL:
OTASP Dialing—This test verifies the device's ability to complete an OTASP call on the appropriate system when particular number is dialed for (*22800, *22801 etc.,), with SPC set to either all zeros or non-zeros and MRU being empty or not empty.
Acquisition Match Only—This test verifies the device ability to acquire a system with a channel of the same band class with the SID listed in the PRL but no system table match. The test also verify the device ability to do a proper rescan exit.
Call Release Scan—This test verifies the device's call release behavior from most preferred system, less preferred redirected system, and after HHO.
NDSS Behavior—This test verifies the device's behavior during Network Driven System Selection to different type system and band class.
Cam Behavior—This test verifies the device's behavior during Channel Assignment Message to different channels and band class.
Hashing Behavior—This test verifies the device's behavior during hashing on a valid and invalid channel.
Enhanced PRL Testing—This test verifies registration and international roaming based on MCC, MNC fields in the PRL.
It is to be understood that while we have illustrated and described certain forms of my invention, it is not to be limited to the specific forms or arrangement of parts herein described and shown. It will be apparent to those skilled in the art that various changes may be made without departing from the scope of the invention and the invention is not to be considered limited to what is shown in the drawings and described in the specification.
