31.3 Call completion supplementary services
3GPP51.010-1Mobile Station (MS) conformance specificationPart 1: Conformance specificationTS
NOTE: In this subclause, Subscriber B is the MS under test, and subscribers A, C and D are distant parties to the calls made during the tests.
31.3.1 Call Waiting
31.3.1.1 Waiting call indication and confirmation
Conformance requirement
3GPP TS 04.83 subclause 1.1.
Test purpose
With an active call, an MS receiving an MT call shall include Cause #17 "user busy" in the CALL CONFIRMED message sent to the SS, and indicate the waiting call to the subscriber.
Method of test
Specific PICS Statements
– Supported MT circuit switched basic services (TSPC_AddInfo_MTsvc)
PIXIT Statements
– Method of indicating a waiting call to the user.
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
The MS has a call ("Call A-B") of a basic service supported by the MS and applicable to Call Waiting as described in 3GPP TS 02.04 table A.1 in the active state. The SIM in the MS under test has Call Waiting enabled.
Foreseen final state of the MS
Call A-B, state U10. Call C-B, state U7.
Maximum duration of test
30 s.
Procedure
The SS shall initiate Call C-B by sending a SETUP message to the MS. The MS shall respond with a CALL CONFIRMED message including cause #17 "user busy", followed by an ALERTING message.
The MS shall remain in state U10 in respect of the Call A-B, and enter state U7 "Call received" in respect of Call C-B. The MS shall indicate the existence of the waiting call to the user by a method defined by the manufacturer. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.
Expected sequence
Step |
Direction |
Message |
Comments |
1 |
SS -> MS |
SETUP |
Transaction identifier different from that of Call A-B |
2 |
MS -> SS |
CALL CONFIRMED |
cause #17 "user busy". |
3 |
MS -> SS |
ALERTING |
|
4 |
MS |
A waiting call indication as defined in a PICS/PIXIT statement is given by the MS. |
|
5 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier of Call A-B |
6 |
MS -> SS |
STATUS |
Transaction identifier of Call A-B, state U10 |
7 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier of Call C-B |
8 |
MS -> SS |
STATUS |
Transaction identifier of Call C-B, state U7 |
31.3.1.2 Normal operation with successful outcome
31.3.1.2.1 Waiting call accepted; existing call released
Conformance requirement
3GPP TS 04.83 subclause 1.2.1.
Test purpose
The MS shall release the active call using the call clearing procedures of 3GPP TS 04.08 / 3GPP TS 24.008, and then accept the waiting call.
Method of test
Specific PICS Statements
– Supported MT circuit switched basic services (TSPC_AddInfo_MTsvc)
PIXIT Statements
– Method of clearing an active call and answering a waiting call.
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
The MS has Call A-B of a basic service supported by the MS and applicable to Call Waiting as described in 3GPP TS 02.04 table A.1 in the state U10 "Active" and Call C-B in the state U7 "Call Received".
Foreseen final state of the MS
Call A-B, state U0. Call C-B, state U10.
Maximum duration of test
30 s.
Procedure
Using suitable MMI commands, the MS shall clear Call A-B, and then answer Call C-B.
The MS shall send a DISCONNECT message with the transaction identifier Call A-B, and then respond to a RELEASE message from the SS with a RELEASE COMPLETE message, and then enter state U0 "Null" in respect of this call.
The MS shall then send a CONNECT in respect of Call C-B, and enter state U10 "Active" on receipt of a CONNECT ACKNOWLEDGE message. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for Call A-B and a STATUS message indicating the appropriate call state for Call C-B.
Expected sequence
Step |
Direction |
Message |
Comments |
1 |
MS |
Call A-B is cleared using MMI commands |
|
2 |
MS -> SS |
DISCONNECT |
Transaction identifier of Call A-B |
3 |
SS -> MS |
RELEASE |
Transaction identifier of Call A-B |
4 |
MS -> SS |
RELEASE COMPLETE |
Transaction identifier of Call A-B |
5 |
MS |
Call C-B is answered using MMI commands |
|
6 |
MS -> SS |
CONNECT |
Transaction identifier of Call C-B |
7 |
SS -> MS |
CONNECT ACKNOWLEDGE |
Transaction identifier of Call C-B |
8 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier of Call A-B |
9 |
MS -> SS |
RELEASE COMPLETE |
Transaction identifier of Call A-B, with cause #81 "invalid transaction identifier value" |
10 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier of Call C-B |
11 |
MS -> SS |
STATUS |
Transaction identifier of Call C-B, state U10 |
31.3.1.2.2 Waiting call accepted; existing call on hold
31.3.1.2.2.1 Waiting call accepted; existing call on hold, no additional calls
Conformance requirement
3GPP TS 04.83 subclause 1.2.2.
Test purpose
With one active call and one waiting call, the MS shall place the active call on hold, and then accept the waiting call.
Method of test
Specific PICS Statements
–
PIXIT Statements
– Method of placing an active call on hold and answering a waiting call.
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
– The MS has Call A-B of a basic service supported by the MS and applicable to Call Waiting as described in 3GPP TS 02.04 table A.1 in the state U10 "Active" and Call C-B in the state U7 "Call Received".
Foreseen final state of the MS
Call A-B, state U10, auxiliary state "Call held". Call C-B, state U10.
Maximum duration of test
30 s.
Procedure
Using suitable MMI commands, the MS shall place Call A-B on hold, and then answer Call C-B.
The MS shall send a HOLD message to the SS using the transaction identifier of Call A-B and enter state U10 "Active" with auxiliary state "Call held". On receipt of a HOLD ACKNOWLEDGE from the SS the MS shall enter state U10 "Active" with auxiliary state "Call held".
The MS shall then send a CONNECT message to the SS, using the transaction identifier of Call C-B, and on receipt of a CONNECT ACKNOWLEDGE message, shall enter state U10 "Active". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.
Expected sequence
Step |
Direction |
Message |
Comments |
1 |
MS |
Call A-B is placed on hold using MMI commands |
|
2 |
MS -> SS |
HOLD |
Transaction identifier of Call A-B |
3 |
SS -> MS |
HOLD ACKNOWLEDGE |
Transaction identifier of Call A-B |
4 |
MS |
Call C-B is answered using MMI commands |
|
5 |
MS -> SS |
CONNECT |
Transaction identifier of Call C-B |
6 |
SS -> MS |
CONNECT ACKNOWLEDGE |
Transaction identifier of Call C-B |
7 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier of Call A-B |
8 |
MS -> SS |
STATUS |
Transaction identifier of Call A-B, state U10, auxiliary state "Call Held" |
9 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier of Call C-B |
10 |
MS -> SS |
STATUS |
Transaction identifier of Call C-B, state U10 |
31.3.1.2.3 Existing call released by user A; waiting call accepted
Conformance requirement
3GPP TS 04.83 subclause 1.2.3.
Test purpose
The MS, on receipt of a DISCONNECT message from the active call, shall complete the clearance of the active call, and accept the waiting call.
Method of test
Specific PICS Statements
– Supported MT circuit switched basic services (TSPC_AddInfo_MTsvc)
PIXIT Statements
– Method of clearing an active call and answering a waiting call.
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
The MS has Call A-B of a basic service supported by the MS and applicable to Call Waiting as described in 3GPP TS 02.04 table A.1 in the state U10 "Active" and Call C-B in the state U7 "Call Received".
Foreseen final state of the MS
Call A-B, state U0. Call C-B, state U10.
Maximum duration of test
30 s.
Procedure
On receipt of a DISCONNECT message using the transaction identifier of Call A-B, the MS shall respond with a RELEASE message. On receipt of a RELEASE COMPLETE message, the MS shall enter state U0 "Null". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state.
If necessary, MMI commands shall be entered to accept call C-B. The MS shall then send a CONNECT message using the transaction identifier of Call C-B, and on receipt of a CONNECT ACKNOWLEDGE message, shall enter state U10 "Active". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for Call A-B and a STATUS message indicating the appropriate call state for Call C-B.
Expected sequence
Step |
Direction |
Message |
Comments |
1 |
SS -> MS |
DISCONNECT |
Transaction identifier of Call A-B |
2 |
MS -> SS |
RELEASE |
Transaction identifier of Call A-B |
3 |
SS -> MS |
RELEASE COMPLETE |
Transaction identifier of Call A-B |
4 |
MS |
If necessary, call C-B is answered using MMI commands |
|
5 |
MS -> SS |
CONNECT |
Transaction identifier of Call C-B |
6 |
SS -> MS |
CONNECT ACKNOWLEDGE |
Transaction identifier of Call C-B |
7 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier of Call A-B |
8 |
MS -> SS |
RELEASE COMPLETE |
Transaction identifier of Call A-B, with cause #81 "invalid transaction identifier value" |
9 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier of Call C-B |
10 |
MS -> SS |
STATUS |
Transaction identifier of Call C-B, state U10 |
31.3.1.3 Normal operation with unsuccessful outcome
31.3.1.3.1 Waiting call released by subscriber B
Conformance requirement
3GPP TS 04.83 subclause 1.3.1.
Test purpose
To test that, using MMI commands, the MS shall clear the waiting call.
Method of test
Specific PICS Statements
– Supported MT circuit switched basic services (TSPC_AddInfo_MTsvc)
PIXIT Statements
– Method of clearing a waiting call.
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
The MS has Call A-B of a basic service supported by the MS and applicable to Call Waiting as described in 3GPP TS 02.04 table A.1 in the state U10 "Active" and Call C-B in the state U7 "Call Received".
Foreseen final state of the MS
Call A-B, state U10. Call C-B, state U0.
Maximum duration of test
30 s.
Procedure
Using appropriate MMI commands, the MS shall clear Call C-B.
The MS shall send a DISCONNECT message with the transaction identifier of Call B, and on receipt of a RELEASE message from the network, shall send a RELEASE COMPLETE and enter state U0 "Null". The call states shall be verified by the SS sending a a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for Call C-B and STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for Call C-B and a STATUS message indicating the appropriate call state for Call A-B.
Expected sequence
Step |
Direction |
Message |
Comments |
1 |
MS |
Call C-B is cleared using MMI commands |
|
2 |
MS -> SS |
DISCONNECT |
Transaction identifier of Call C-B |
3 |
SS -> MS |
RELEASE |
Transaction identifier of Call C-B |
4 |
MS -> SS |
RELEASE COMPLETE |
Transaction identifier of Call C-B |
5 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier of Call A-B |
6 |
MS -> SS |
STATUS |
Transaction identifier of Call A-B, state U10 |
7 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier of Call C-B |
8 |
MS -> SS |
RELEASE COMPLETE |
Transaction identifier of Call C-B, with cause #81 "invalid transaction identifier value" |
31.3.1.3.2 Waiting call released by calling user C
Conformance requirement
3GPP TS 04.83 subclause 1.3.2.
Test purpose
To test that the MS responds correctly to the receipt of a clearing message from the waiting call.
Method of test
Specific PICS Statements
– Supported MT circuit switched basic services (TSPC_AddInfo_MTsvc)
PIXIT Statements
–
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
The MS has Call A-B of a basic service supported by the MS and applicable to Call Waiting as described in 3GPP TS 02.04 table A.1 in the state U10 "Active" and Call C-B in the state U7 "Call Received".
Foreseen final state of the MS
Call A-B, state U10. Call C-B, state U0.
Maximum duration of test
30 s.
Procedure
On receipt of a DISCONNECT message using the transaction identifier of Call C-B, the MS shall respond with a RELEASE message. On receipt of a RELEASE COMPLETE message, the MS shall enter state U0 "Null". Call A-B shall remain in state U10. The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" for Call C-B and STATUS message indicating the appropriate call state for Call A-B.
Expected sequence
Step |
Direction |
Message |
Comments |
1 |
SS -> MS |
DISCONNECT |
Transaction identifier of Call C-B |
2 |
MS -> SS |
RELEASE |
Transaction identifier of Call C-B |
3 |
SS -> MS |
RELEASE COMPLETE |
Transaction identifier of Call C-B |
4 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier of Call A-B |
5 |
MS -> SS |
STATUS |
Transaction identifier of Call A-B, state U10 |
6 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier of Call C-B |
7 |
MS -> SS |
RELEASE COMPLETE |
Transaction identifier of Call C-B, with cause #81 "invalid transaction identifier value" |
31.3.1.4 Activation
Conformance requirement
3GPP TS 04.83 subclause 1.4.
Test purpose
To test the correct operation of the activation procedure, and correctly display of the response from the SS in the following cases.
1) Successful activation.
2) Error response (reject).
3) Activation reject (Invoke problem).
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
The MS is "idle updated".
Specific PICS Statements
–
PIXIT Statements
– Description of the user’s commands and of display of the answers from the network for activation of call waiting.
Foreseen final state of the MS
The MS is "idle updated".
Test procedure
By means of appropriate MMI functions (using either 3GPP TS 02.30 or manufacturer defined MMI), the user requests activation of CW for a basic service group supported by the MS.
Upon receipt of the operation (in a REGISTER message), the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing the return result of the ActivateSS operation.
The SS transaction is released and the dedicated channel is released.
Then again, by means of appropriate MMI functions as defined by the basic public MMI described in 3GPP TS 02.30, the user requests activation of CW for all basic service groups.
Upon receipt of the REGISTER message, the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing the return result of the ActivateSS operation.
The SS transaction is released and the dedicated channel is released.
By means of appropriate MMI functions (using either 3GPP TS 02.30 or manufacturer defined MMI), the user requests activation of CW for a basic service group supported by the MS.
Upon receipt of the operation (in a REGISTER message), the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing a Return Error component with Error code:SS not available.
The SS transaction is released and the dedicated channel is released.
Then again, by means of appropriate MMI functions as defined by the basic public MMI described in 3GPP TS 02.30, the user requests activation of CW for all basic service groups.
Upon receipt of the operation (in a REGISTER message), the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing a Return Error component with Error code:SS not available.
The SS transaction is released and the dedicated channel is released.
By means of appropriate MMI functions (using either 3GPP TS 02.30 or manufacturer defined MMI), the user requests activation of CW for a basic service group supported by the MS.
Upon receipt of the REGISTER message, the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing a Reject component with Invoke problem (Resource limitation).
The SS transaction is released and the dedicated channel is released.
Then again, by means of appropriate MMI functions as defined by the basic public MMI described in 3GPP TS 02.30, the user requests activation of CW for all basic service groups.
Upon receipt of the REGISTER message, the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing A Reject component with Invoke problem (Resource limitation).
Maximum duration of test
9 minutes
Expected sequence
Step |
Direction |
Message |
Comments |
---|---|---|---|
1 |
MS |
The MS is made to initiate activation of CW for a basic service group supported by the MS |
|
2 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
3 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
4 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
5 |
SS -> MS |
CM SERVICE ACCEPT |
|
6 |
MS -> SS |
REGISTER |
|
7 |
SS -> MS |
RELEASE COMPLETE |
ActivateSS operation Return_result |
8 |
SS -> MS |
CHANNEL RELEASE |
|
9 |
MS |
Provide correct MMI user indication after step 7 |
|
10 |
MS |
The MS is made to initiate a activation of CW (all basic service groups) |
|
11 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
12 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
13 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
14 |
SS -> MS |
CM SERVICE ACCEPT |
|
15 |
MS -> SS |
REGISTER |
|
16 |
SS -> MS |
RELEASE COMPLETE |
ActivateSS operation Return result |
17 |
SS -> MS |
CHANNEL RELEASE |
|
18 |
MS |
Provide correct MMI user indication after step 16 |
|
19 |
MS |
The MS is made to initiate activation of CW for a basic service group supported by the MS |
|
20 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
21 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
22 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
23 |
SS -> MS |
CM SERVICE ACCEPT |
|
24 |
MS -> SS |
REGISTER |
|
25 |
SS -> MS |
RELEASE COMPLETE |
ActivateSS operation Return Error |
26 |
SS -> MS |
CHANNEL RELEASE |
|
27 |
MS |
Provide correct MMI user indication after step 25 |
|
28 |
MS |
The MS is made to initiate a activation of CW (all basic service groups) |
|
29 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
30 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
31 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
32 |
SS -> MS |
CM SERVICE ACCEPT |
|
33 |
MS -> SS |
REGISTER |
|
34 |
SS -> MS |
RELEASE COMPLETE |
ActivateSS operation Return Error |
35 |
SS -> MS |
CHANNEL RELEASE |
|
36 |
MS |
Provide correct MMI user indication after step 34 |
|
37 |
MS |
The MS is made to initiate activation of CW for a basic service group supported by the MS |
|
38 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
39 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
40 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
41 |
SS -> MS |
CM SERVICE ACCEPT |
|
42 |
MS -> SS |
REGISTER |
|
43 |
SS -> MS |
RELEASE COMPLETE |
ActivateSS operation Reject |
44 |
SS -> MS |
CHANNEL RELEASE |
|
45 |
MS |
Provide correct MMI user indication after step 43 |
|
46 |
MS |
The MS is made to initiate a activation of CW (all basic service groups) |
|
47 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
48 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
49 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
50 |
SS -> MS |
CM SERVICE ACCEPT |
|
51 |
MS -> SS |
REGISTER |
|
52 |
SS -> MS |
RELEASE COMPLETE |
ActivateSS operation Reject |
53 |
SS -> MS |
CHANNEL RELEASE |
Specific message contents:
step 6, 24, 42 – CW
– protocol discriminator: non call related SS message.
– message type: REGISTER.
– facility:
invoke = Activation:
Supplementary service code = CW.
Basic service code: the selected basic service group.
step 15, 33, 51 – CW
– protocol discriminator: non call related SS message.
– message type: REGISTER.
– facility:
invoke = Activation:
Supplementary service code = CW.
Basic service code: no bearer service present, no teleservice present.
31.3.1.5 Deactivation
Conformance requirement
3GPP TS 04.83 subclause 1.5.
Test purpose
To test the correct operation of the deactivation procedure, and correct display of the response from the SS in the following cases.
1) Successful deactivation.
2) Error response (reject).
3) Activation reject (Invoke problem).
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
The MS is "idle updated".
Specific PICS Statements
–
PIXIT Statements
– Description of the user’s commands and of display of the answers from the network for deactivation of call waiting.
Foreseen final state of the MS
The MS is "idle updated".
Test procedure
By means of appropriate MMI functions (using either 3GPP TS 02.30 or manufacturer defined MMI), the user requests deactivation of CW for a basic service group supported by the MS.
Upon receipt of the operation (in a REGISTER message), the system simulator answers with a RELEASE COMPLETE message with the Facility information element containing the return result of the DeactivateSS operation.
The SS transaction is released and the dedicated channel is released.
Then again, by means of appropriate MMI functions as defined by the basic public MMI described in 3GPP TS 02.30, the user requests deactivation of CW for all basic service groups.
Upon receipt of the REGISTER message, the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing the return result of the DeactivateSS operation.
The SS transaction is released and the dedicated channel is released.
By means of appropriate MMI functions (using either 3GPP TS 02.30 or manufacturer defined MMI), the user requests deactivation of CW for a basic service group supported by the MS.
Upon receipt of the operation (in a REGISTER message), the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing a Return Error component with Error code:SS not available.
The SS transaction is released and the dedicated channel is released.
Then again, by means of appropriate MMI functions as defined by the basic public MMI described in 3GPP TS 02.30, the user requests deactivation of CW for all basic service groups.
Upon receipt of the operation (in a REGISTER message), the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing a Return Error component with Error code:SS not available.
The SS transaction is released and the dedicated channel is released.
By means of appropriate MMI functions (using either 3GPP TS 02.30 or manufacturer defined MMI), the user requests deactivation of CW for a basic service group supported by the MS.
Upon receipt of the REGISTER message, the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing A Reject component with Invoke problem (Resource limitation).
The SS transaction is released and the dedicated channel is released.
Then again, by means of appropriate MMI functions as defined by the basic public MMI described in 3GPP TS 02.30, the user requests deactivation of CW for all basic service groups.
Upon receipt of the REGISTER message, the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing A Reject component with Invoke problem (Resource limitation).
Maximum duration of test
9 minutes.
Expected sequence
Step |
Direction |
Message |
Comments |
---|---|---|---|
1 |
MS |
The MS is made to initiate a deactivation of CW for a basic service group supported by the MS |
|
2 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
3 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
4 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
5 |
SS -> MS |
CM SERVICE ACCEPT |
|
6 |
MS -> SS |
REGISTER |
|
7 |
SS -> MS |
RELEASE COMPLETE |
DeactivateSS operation Return_result |
8 |
SS -> MS |
CHANNEL RELEASE |
|
9 |
MS |
Provide correct MMI user indication after step 7 |
|
10 |
MS |
The MS is made to initiate a deactivation of CW (all basic services) |
|
11 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
12 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
13 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
14 |
SS -> MS |
CM SERVICE ACCEPT |
|
15 |
MS -> SS |
REGISTER |
|
16 |
SS -> MS |
RELEASE COMPLETE |
DeactivateSS operation Return result |
17 |
SS -> MS |
CHANNEL RELEASE |
|
19 |
MS |
TThe MS is made to initiate a deactivation of CW for a basic service group supported by the MShe MS is made to initiate a deactivation of call forwarding service for CW for the selected basic service group |
|
20 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
21 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
22 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
23 |
SS -> MS |
CM SERVICE ACCEPT |
|
24 |
MS -> SS |
REGISTER |
|
25 |
SS -> MS |
RELEASE COMPLETE |
DeactivateSS operation Return Error |
26 |
SS -> MS |
CHANNEL RELEASE |
|
27 |
MS |
Provide correct MMI user indication after step 25 |
|
28 |
MS |
The MS is made to initiate a deactivation of CW (all basic service groups) |
|
29 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
30 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
31 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
32 |
SS -> MS |
CM SERVICE ACCEPT |
|
33 |
MS -> SS |
REGISTER |
|
34 |
SS -> MS |
RELEASE COMPLETE |
DeactivateSS operation Return Error |
35 |
SS -> MS |
CHANNEL RELEASE |
|
36 |
MS |
Provide correct MMI user indication after step 34 |
|
37 |
MS |
The MS is made to initiate a deactivation of CW for a basic service group supported by the MS |
|
38 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
39 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
40 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
41 |
SS -> MS |
CM SERVICE ACCEPT |
|
42 |
MS -> SS |
REGISTER |
|
43 |
SS -> MS |
RELEASE COMPLETE |
DeactivateSS operation Reject |
44 |
SS -> MS |
CHANNEL RELEASE |
|
45 |
MS |
Provide correct MMI user indication after step 43 |
|
46 |
MS |
The MS is made to initiate a deactivation of CW (all basic service groups) |
|
47 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
48 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
49 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
50 |
SS -> MS |
CM SERVICE ACCEPT |
|
51 |
MS -> SS |
REGISTER |
|
52 |
SS -> MS |
RELEASE COMPLETE |
DeactivateSS operation Reject |
53 |
SS -> MS |
CHANNEL RELEASE |
|
54 |
MS |
Provide correct MMI user indication after step 52 |
Specific message content
step 6, 24, 42 – CW
– protocol discriminator: non call related SS message.
– message type: REGISTER.
– facility:
invoke = Deactivation:
Supplementary service code = CW.
Basic service code: the selected basic service group.
step 15, 33, 51 – CW
– protocol discriminator: non call related SS message.
– message type: REGISTER.
– facility:
invoke = Deactivation:
Supplementary service code = CW.
Basic service code: no bearer service present
31.3.1.6 Interrogation
31.3.1.6.1 Interrogation accepted
Conformance requirement
3GPP TS 04.83 subclause 1.6.
Test purpose
To test the correct operation of the interrogation procedure, and correct display of the response from the SS in the case of successful interrogation.
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
The MS is "idle updated".
Specific PICS Statements
–
PIXIT Statements
– Description of the user’s commands and of display of the answers from the network for interrogation of call waiting.
Foreseen final state of the MS
The MS is "idle updated".
Test procedure
By means of appropriate MMI functions (using either 3GPP TS 02.30 or manufacturer defined MMI), the user requests interrogation of CW for all basic service groups.
Upon receipt of the operation (in a REGISTER message), the system simulator answers with a RELEASE COMPLETE message with the Facility information element containing the return result of the InterrogateSS (BasicServiceCode(s)) operation.
The SS transaction is released and the dedicated channel is released.
Then again, by means of appropriate MMI functions as defined by the basic public MMI described in 3GPP TS 02.30, the user requests interrogation of CW for all basic service groups.
Upon receipt of the REGISTER message, the system simulator answers with the RELEASE COMPLETE message with the Facility information element containing the return result of the InterrogateSS (SS-Status) operation.
The dedicated channel is released.
Maximum duration of test
3 minutes.
Expected sequence
Step |
Direction |
Message |
Comments |
1 |
MS |
The MS is made to initiate an interrogation of CW (all) |
|
2 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
3 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
4 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
5 |
SS -> MS |
CM SERVICE ACCEPT |
|
6 |
MS -> SS |
REGISTER |
|
7 |
SS -> MS |
RELEASE COMPLETE |
InterrogateSS (BasicServiceCode(s)) operation Return_result |
8 |
SS -> MS |
CHANNEL RELEASE |
|
10 |
MS |
The MS is made to initiate an interrogation of CW (all) |
|
11 |
MS -> SS |
CHANNEL REQUEST |
with establishment cause "Other procedures which can be completed with an SDCCH" |
12 |
SS -> MS |
IMMEDIATE ASSIGNMENT |
|
13 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
14 |
SS -> MS |
CM SERVICE ACCEPT |
|
15 |
MS -> SS |
REGISTER |
|
16 |
SS -> MS |
RELEASE COMPLETE |
InterrogateSS (SS-Status) operation Return result |
17 |
SS -> MS |
CHANNEL RELEASE |
|
18 |
MS |
Provide correct MMI user indication after step 16 |
Specific message content
step 6, 15 – CW
– protocol discriminator: non call related SS message.
– message type: REGISTER.
– facility:
invoke = Interrogation:
Supplementary service code = CW.
Basic service code: no Bearer Service present, no teleservice present.
31.3.1.6.2 Interrogation rejected
Conformance requirement
3GPP TS 04.83 subclause 1.6.
Test purpose
To test the correct operation of the interrogation procedure, and correct display of the response from the SS in the case of an error response and an invoke problem
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
The MS is in CC state U10.
Specific PICS Statements
–
PIXIT Statements
– Description of the user’s commands and of display of the answers from the network for call waiting.
Foreseen final state of the MS
The MS is in CC state U10.
Test procedure
By means of appropriate MMI functions (using either 3GPP TS 02.30 or manufacturer defined MMI), the user requests interrogation of CW for all basic service groups.
Upon receipt of the operation (in a REGISTER message),the system simulator answers with a RELEASE COMPLETE message with the Facility information element containing a Return_error(error: SS not available) of the InterrogateSS operation.
The system simulator sends STATUS ENQUIRY, the MS responds with STATUS message indicating CC state U10.
Then again, by means of appropriate MMI functions as defined by the basic public MMI described in 3GPP TS 02.30, the user requests interrogation of CW for all basic service groups.
Upon receipt of the REGISTER message, the system simulator answers with the RELEASE COMPLETE message (same PD and TI that in the REGISTER message) with the Facility information element containing a reject(invoke_problem: resource limitation) of the InterrogateSS operation.
The system simulator sends STATUS ENQUIRY, the MS responds with STATUS message indicating CC state U10.
Maximum duration of test
3 minutes.
Expected sequence
Step |
Direction |
Message |
Comments |
1 |
MS |
The MS is made to initiate an interrogation of CW (all) |
|
2 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
3 |
SS -> MS |
CM SERVICE ACCEPT |
|
4 |
MS -> SS |
REGISTER |
|
5 |
SS -> MS |
RELEASE COMPLETE |
InterrogateSS operation Return_error |
6 |
SS -> MS |
STATUS ENQUIRY |
|
7 |
MS -> SS |
STATUS |
CC state U10 |
8 |
MS |
The MS is made to initiate an interrogation of CW for (all) |
|
9 |
MS -> SS |
CM SERVICE REQUEST |
cause: "supplementary service activation" |
10 |
SS -> MS |
CM SERVICE ACCEPT |
|
11 |
MS -> SS |
REGISTER |
|
12 |
SS -> MS |
RELEASE COMPLETE |
InterrogateSS operation Reject |
13 |
MS |
provide correct MMI user indication |
|
14 |
SS -> MS |
STATUS ENQUIRY |
|
15 |
MS -> SS |
STATUS |
CC state U10 |
Specific message content
step 4, 11 – CW
– protocol discriminator: non call related SS message.
– message type: REGISTER.
– facility:
invoke = Interrogation:
Supplementary service code = CW.
Basic service code:no Bearer Service present, no teleservice present.
step 5 –
– protocol discriminator: non call related SS message.
– transaction identifier: same TI as previous REGISTER message.
– message type: RELEASE COMPLETE.
– facility:
return error code: SS not available.
For the return error the invoke ID must be the same as in the invoke of the InterrogateSS operation.
step 12 –
– protocol discriminator: non call related SS message.
– transaction identifier: same TI as previous REGISTER message.
– message type: RELEASE COMPLETE.
– facility:
reject code: resource limitation.
For the reject the invoke ID must be the same as in the invoke of the InterrogateSS operation.
31.3.2 Call Hold
31.3.2.1 Hold invocation
Conformance requirement
3GPP TS 04.83 subclause 2.1.2.
Test purpose
To test the correct operation of the Hold procedure, and the MS reaction to the following messages sent in response to the HOLD message.
1. HOLD REJECT.
2. HOLD ACKNOWLEDGE.
Method of test
Specific PICS Statements
–
PIXIT Statements
– Method of placing a call on hold.
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
The MS shall have a call of a basic service supported by the MS and applicable to Call Hold as described in 3GPP TS 02.04 table A.1 in state U10 "Active"
Foreseen final state of the MS
State U10, Auxiliary state "Call Held".
Maximum duration of test
30 s.
Procedure
Using suitable MMI commands, the MS shall request that the call is placed on hold. The MS shall send a HOLD message and enter auxiliary state "hold request". On receipt of a HOLD REJECT message from the SS shall return to state U10 "Active". The call state shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of the call, and receiving a STATUS message indicating the appropriate call state and auxiliary state.
Using suitable MMI commands, the MS shall again request that the call is placed on hold. The MS shall send a HOLD message and enter auxiliary state "hold request". On receipt of a HOLD ACKNOWLEDGE message from the SS shall enter to state U10 "Active " with auxiliary state "Call held". The call state shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of call, and receiving a STATUS message indicating the appropriate call state and auxiliary state.
Expected sequence
Step |
Direction |
Message |
Comments |
1 |
MS |
Using MMI commands, the MS places the call on hold |
|
2 |
MS -> SS |
HOLD |
|
3 |
SS -> MS |
STATUS ENQUIRY |
|
4 |
MS -> SS |
STATUS |
State U10, auxiliary state "Hold request" |
5 |
SS -> MS |
HOLD REJECT |
|
6 |
SS -> MS |
STATUS ENQUIRY |
|
7 |
MS -> SS |
STATUS |
State U10, no auxiliary state |
8 |
SS |
Check that the TCH is through-connected |
|
9 |
MS |
Using MMI commands, the MS places the call on hold |
|
10 |
MS -> SS |
HOLD |
|
11 |
SS -> MS |
STATUS ENQUIRY |
|
12 |
MS -> SS |
STATUS |
State U10, auxiliary state "Hold request" |
13 |
SS -> MS |
HOLD ACKNOWLEDGE |
|
14 |
SS -> MS |
STATUS ENQUIRY |
|
15 |
MS -> SS |
STATUS |
State U10, auxiliary state "Call held" |
31.3.2.2 Retrieve procedure
Conformance requirement
3GPP TS 04.83 subclause 2.1.3.
Applicability
MS supporting the Call Hold supplementary service.
Test purpose
To test the correct operation of the retrieve procedure, and the MS reaction to the following messages sent in response to the RETRIEVE message.
1) RETRIEVE REJECT.
2) RETRIEVE ACKNOWLEDGE.
Method of test
Specific PICS Statements
–
PIXIT Statements
– Method of retrieving a held call.
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
The MS shall have a call of a basic service supported by the MS and applicable to Call Hold as described in 3GPP TS 02.04 table A.1 in state U10 "Active" with auxiliary state "Call held".
Foreseen final state of the MS
State U10, no auxiliary state.
Maximum duration of test
30 s.
Procedure
Using suitable MMI commands, the MS shall request that the call is placed on RETRIEVE. The MS shall send a RETRIEVE message and enter auxiliary state "retrieve request". On receipt of a RETRIEVE REJECT message from the SS, the MS shall return to state U10 "Active" with auxiliary state "Call held". The call state shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of call, and receiving a STATUS message indicating the appropriate call state and auxiliary state.
Using suitable MMI commands, the MS shall again request that the call is placed on RETRIEVE. The MS shall send a RETRIEVE message and enter auxiliary state "retrieve request". On receipt of a RETRIEVE ACKNOWLEDGE message from the SS, the MS shall enter state U10 "Active".The call state shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of call, and receiving a STATUS message indicating the appropriate call state and auxiliary state.
Expected sequence
Step |
Direction |
Message |
Comments |
1 |
MS |
Using MMI commands, the MS retrieves the held call |
|
2 |
MS -> SS |
RETRIEVE |
|
3 |
SS -> MS |
STATUS ENQUIRY |
|
4 |
MS -> SS |
STATUS |
State U10, auxiliary state "Retrieve request" |
5 |
SS -> MS |
RETRIEVE REJECT |
|
6 |
SS -> MS |
STATUS ENQUIRY |
|
7 |
MS -> SS |
STATUS |
State U10, auxiliary state "Call held" |
8 |
MS |
Using MMI commands, the MS retrieves the held call |
|
9 |
MS -> SS |
RETRIEVE |
|
10 |
SS -> MS |
STATUS ENQUIRY |
|
11 |
MS -> SS |
STATUS |
State U10, auxiliary state "Retrieve request" |
12 |
SS -> MS |
RETRIEVE ACKNOWLEDGE |
|
13 |
SS -> MS |
STATUS ENQUIRY |
|
14 |
MS -> SS |
STATUS |
State U10, no auxiliary state |
15 |
SS |
Check that the TCH is through-connected |
31.3.2.3 Alternate from one call to the other
Conformance requirement
3GPP TS 04.83 subclause 2.1.4.
Test purpose
To test that the MS correctly alternates between one call and the other, by placing the active call on hold, and retrieving the previously held call.
To test that the MS correctly returns to the original call states in the event of receipt of a HOLD REJECT or RETRIEVE REJECT.
Method of test
Specific PICS Statements
–
PIXIT Statements
– Method of alternating between an active call and a held call.
Initial conditions
System Simulator:
1 cell, default parameters.
Mobile Station:
The MS shall have Call A-B in state U10 "Active", and Call C-B in state U10 "Active" with auxiliary state "Call held". Both calls shall be of a basic service supported by the MS and applicable to Call Hold as described in 3GPP TS 02.04 table A.1.
Foreseen final state of the MS
Call A-B: State U10, Auxiliary State "Call Held".
Call C-B: State U10, No Auxiliary State.
Maximum duration of test
30 s.
Procedure
Using suitable MMI commands, the MS shall alternate between Call A-B and Call C-B. The MS shall send a HOLD message with the transaction identifier for Call A-B and enter auxiliary state "hold request", and send a RETRIEVE message with the transaction identifier for Call C-B and enter auxiliary state "retrieve request". On receipt of a HOLD ACKNOWLEDGE and RETRIEVE ACKNOWLEDGE message, the MS shall have Call A-B in state U10 "Active" with auxiliary state "Call held", and Call C-B in state U10 "Active". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state and auxiliary state.
Using suitable MMI commands, the MS shall alternate between Call A-B and Call C-B. The MS shall send a HOLD message with the transaction identifier for Call C-B and enter auxiliary state "hold request", and send a RETRIEVE message with the transaction identifier for Call A-B and enter auxiliary state "retrieve request". On receipt of a HOLD REJECT and RETRIEVE REJECT message, the MS shall have Call A-B remain in state U10 "Active" with auxiliary state "Call held", and Call C-B in state U10 "Active". The call states shall be verified by the SS sending a STATUS ENQUIRY message in respect of the transaction identifier of each call, and receiving a STATUS message indicating the appropriate call state and auxiliary state.
Expected sequence
Step |
Direction |
Message |
Comments |
1 |
MS |
Using MMI commands, the MS changes from call A-B to call C-B |
|
2 |
MS -> SS |
HOLD |
Transaction identifier for call A-B |
3 |
MS -> SS |
RETRIEVE |
Transaction identifier for call C-B |
4 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier for call A-B |
5 |
MS -> SS |
STATUS |
Transaction identifier for call A-B, State U10, auxiliary state "Hold request" |
6 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier for call C-B |
7 |
MS -> SS |
STATUS |
Transaction identifier for call C-B, State U10, auxiliary state "Retrieve request" |
8 |
SS -> MS |
HOLD ACKNOWLEDGE |
Transaction identifier for call A-B |
9 |
SS -> MS |
RETRIEVE ACKNOWLEDGE |
Transaction identifier for call C-B |
10 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier for call A-B |
11 |
MS -> SS |
STATUS |
Transaction identifier for call A-B, state U10, auxiliary state "Call Held" |
12 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier for call C-B |
13 |
MS -> SS |
STATUS |
Transaction identifier for call C-B, state U10, no auxiliary state |
14 |
SS |
Check that the TCH is through-connected |
|
15 |
MS |
Using MMI commands, the MS changes from call C-B to call A-B |
|
16 |
MS -> SS |
HOLD |
Transaction identifier for call C-B |
17 |
MS -> SS |
RETRIEVE |
Transaction identifier for call A-B |
18 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier for call C-B |
19 |
MS -> SS |
STATUS |
Transaction identifier for call C-B, State U10, auxiliary state "Hold request" |
20 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier for call A-B |
21 |
MS -> SS |
STATUS |
Transaction identifier for call A-B, State U10, auxiliary state "Retrieve request" |
22 |
SS -> MS |
HOLD REJECT |
Transaction identifier for call C-B |
23 |
SS -> MS |
RETRIEVE REJECT |
Transaction identifier for call A-B |
24 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier for call C-B |
25 |
MS -> SS |
STATUS |
Transaction identifier for call C-B, state U10, no auxiliary state |
26 |
SS -> MS |
STATUS ENQUIRY |
Transaction identifier for call A-B |
27 |
MS -> SS |
STATUS |
Transaction identifier for call A-B, state U10, auxiliary state "Call Held" |
28 |
SS |
Check that the TCH is through-connected |