|
|
|
Last updated: October 28, 2004
One of the most important and difficult aspects of synchronizing the external controller, test set and DUT is synchronizing the movement between call processing states. There are several specialized commands available to help you determine the state of the call processing, and verify that call processing events were successful.
| Query | Suggested Usage | |
|---|---|---|
| CALL:STATus[:STATe][:VOICe]? |
Queries the current call processing state. Immediately returns the state: IDLE|PAG|CALL|CONN|APR|REL|HAND|REG. See Call Processing States Description . |
Use after a handoff to verify the call processing state is still "connected". |
| CALL:CONNected[:STATe]? |
Queries whether the call state is idle or connected. Immediately returns 1 or 0, or waits for a state change if the Call State Change Detector is armed. See Connected/Idle Query . |
Use with the Call State Change Detector to verify that your attempt to establish a call was successful. |
| CALL:DCONnected[:STATe] |
Queries whether the test data connection (with service option set to SOFS32 or SOS32, see CALL:SOPTion ) is in idle or connected state. Immediately returns 1 or 0, or waits for a state change if the Call State Change Detector is armed. See Connected/Idle Query . |
Use with the Call State Change Detector to verify that your attempt to establish a call with service option 32 was successful. |
The CALL:STATus[:STATe][:VOICe]? query returns the current call processing states. These states may also be displayed on the front panel screen (see Instrument Status Area ). The possible states include transitory states and terminal states.
The following call processing states are transitory states that the test set remain in momentarily during transitions to a terminal state.
The following call processing states are terminal states that the test set is stabilized in for a substantial length of time.
The CALL:CONNected[:STATe]? query is used to verify which terminal call state (idle or connected) that the test set is in. It's most useful in conjunction with the Call State Change Detector . See Example 1: Mobile Station Originated Call - Arming the Change Detector .
For test data connection (with service option set to SOS32 or SOFS32, see CALL:SOPTion ), use CALL:DCONnected[:STATe] to verify whehter the test data connection is in connected state.
The call state change detector is useful when you expect a change in the call processing state, and want to know when it is complete. The change detector is used in conjunction with the Connected/Idle Query .
The call state change detector is automatically armed by the test set when call processing operations originating from the test set are requested by CALL:ORIGinate , CALL:REGister and CALL:END . You do not need to explicitly arm the call state change detector. See Example 2: Base Station Originated Call - Using the Connected/Idle Query .
| NOTE |
|
During SMS operation, the CALL:ORIGinate may affect both call state change detector and SMS Status Change Detector . Moreover, the call state change detector will be rearmed immediately after the call status change detector is disarmed. See Arming the SMS State Change Detector .
You only need to arm the change detector (using CALL:CONNected:ARM[:IMMediate] ) to hold off the call terminal state queries when you are originating a call or disconnecting a call from the mobile station. See Example 1: Mobile Station Originated Call - Arming the Change Detector .
For mobile originated test data connection (with service option set to SOS32 or SOFS32, see CALL:SOPTion ), use CALL:DCONnected:ARM[:IMMediate] to arm the data connection status change detector.
The call state change detector becomes disarmed when any of the following conditions have been met:
the call processing state has changed to either connected or idle, or
the attempt to connect or disconnect a call has failed, and one of the test set's Fixed Timers has timed out, or
no call processing state changes occurred within the time period specified by the Call State Change Detector Timeout .
The call state change detector includes a timeout to limit the amount of time that the test set will wait for a change in the call processing state. This can prevent the call processing state from staying in a transitory state forever. The timer begins when the change detector is armed or rearmed when already armed. The duration of this timeout is user-settable, but the user setting (using the CALL:CONNected:TIMeout ) is only applied during mobile station originated call processing operations and should be greater than the maximum amount of time the control program needs to wait between arming the call state change detector and the call processing operation starting. If the timer expires, the change detector is disarmed, and the CALL:CONNected[:STATe]? query return a 1 for connected or a 0 for idle. For test set originated call processing operations, the timeout is automatically set to 60 seconds by the test set.
For mobile originated test data connection (with service option set to SOS32 or SOFS32, see CALL:SOPTion ), use CALL:DCONnected:TIMeout to set the timeout of the data connection status change detector.
The following example illustrates the use of the call state change detector along with the connected/idle query to synchronize a controlling application with a call processing state change during a mobile station originated call.
When the CALL:CONNECTED:ARM command is received by the test set, the detector becomes armed and configures the test set to hold off on returning a result for the CALL:CONNECTED:STATE? query until the detector is disarmed by one of the three events described above.
10 OUTPUT 714;"CALL:CONNECTED:TIMEOUT 10S" ! Sets the time out 20 ! time to 10 seconds. 30 OUTPUT 714;"CALL:CONNECTED:ARM" ! Arm the change detector. 40 DISP "Make a mobile station orginated call. Continue when done." 50 PAUSE 60 OUTPUT 714;"CALL:CONNECTED:STATE?" ! The connected/idle query. 70 ENTER 714;Call_connected 80 IF Call_connected=1 THEN 90 DISP "Call is connected." 100 WAIT 2 110 ELSE 120 DISP "Call is not connected." 130 WAIT 2 140 END IF 150 END
The following example illustrates the use of the connected/idle query for a base station originated call. This code originates a call, then waits for the connected/idle query to return a result.
Note that this code does not include the CALL:CONNECTED:TIME (timeout timer) or the CALL:CONNECTED:ARM (change detector arm) commands. These commands are unnecessary since the change detector is armed automatically by the CALL:ORIGINATE command, and the timeout timer value is never applicable since a base station originated call guarantees a state change.
10 OUTPUT 714;"CALL:ORIGINATE" ! Begin the BS originated call. 20 OUTPUT 714;"CALL:CONNECTED:STATE?" ! The connect/idle query. 30 ENTER 714;Call_connected ! Program will hang here until state 40 ! change or protocol timer expires. 50 !************************************************************ 60 ! If mobile is not set to auto-answer, answer the call. 70 !************************************************************ 80 IF NOT Call_connected THEN 90 DISP "CALL NOT CONNECTED." 100 ELSE 110 DISP "CALL IS CONNECTED." 120 END IF 130 END
|
|
|
|
|