15.5 Call waiting
34.123-13GPPPart 1: Protocol conformance specificationRelease 15TSUser Equipment (UE) conformance specification
NOTE: In this subclause Subscriber B is the UE under test, and subscribers A, C and D are distant parties to the calls made during the tests.
15.5.1 Call completion supplementary services, Waiting call indication and confirmation
15.5.1.1 Definition
15.5.1.2 Conformance requirement
When this service is activated for the controlling subscriber B and the B‑subscriber has calls only in states U10 (Active) or U26 (MO Modify) as defined in 3GPP TS 24.008, the arrival of an incoming call from subscriber C shall, if no other call is waiting be signalled to the mobile station B by a normal call indication. In that case the network and the mobile station shall act in accordance with 3GPP TS 24.008. The transaction identifier shall be the transaction identifier (C‑B) allocated to the waiting call and must not be the same as the transaction identifier (A‑B) for the already existing call (see figure 1.1). In the CALL CONFIRMED message sent to the network the Cause information element shall be included with cause #17 "user busy" (see figure 1.1). When the ALERTING message is received by the network the call waiting timer T2 shall be started or if call forwarding on no reply is activated for the B‑subscriber the no reply condition timer T3 shall be started.
If the network received a non‑zero SS Screening indicator from the calling users mobile station the ALERTING/FACILITY message sent to a calling mobile user shall include the Facility information element with an invoke of the Notification operation indicating that the call is waiting (see figure 1.2). If the network did not receive a non‑zero SS Screening indicator from the calling users mobile station it shall not send a notification, i.e. either the ALERTING message does not include the Notification operation or the FACILITY message is omitted.
MS Network
SETUP
<————————————————————————————————————————
…..Transaction identifier(C-B)…..
CALL CONFIRMED
————————————————————————————————————————>
…..Transaction identifier(C-B)…..
…..Cause #17 (user busy)…..
ALERTING
————————————————————————————————————————>
…..Transaction identifier(C-B)….. start T2/T3
NOTE: The SETUP message shall include a "Signal Information" element with value #7 (call waiting tone on). This shall be used by the MS to generate an appropriate call waiting indication.
Figure 1.1: Call indication to the mobile station on arrival of an incoming call
and call confirmation from the mobile station
MS Network
SETUP
————————————————————————————————————————>
CALL PROCEEDING
<————————————————————————————————————————
ALERTING/FACILITY
<————————————————————————————————————————
Facility (Invoke = NotifySS (CW, CallIsWaiting-Indicator))
NOTE: If possible, the ALERTING message shall be used as the carrier message for the Call Waiting notification. Otherwise the FACILITY message shall be used.
Figure 1.2: Notification to a calling mobile station that the call is in the waiting state
Reference(s)
TS 24.083 clause 1.1.
15.5.1.3 Test purpose
1) To check that with an active call and when receiving a Mobile Terminated call, the UE shall include Cause #17 "user busy" in the CALL CONFIRMED message sent to the SS, and indicate the waiting call to the calling subscriber.
15.5.1.4 Method of test
Initial conditions:
– System Simulator:
– one cell, default parameters
– User Equipment:
– the UE is "Circuit Switched Connect" for speech on cell A as per the Generic call set up procedure for mobile terminating circuit switched calls found in TS 34.108 clause 7.2.3.1 (call A-B).
Related ICS/IXIT statement(s)
Support of FDD Yes/No.
Support of CS speech Yes/No.
Support of Call Waiting Yes/No.
Test Procedure
The SS shall initiate a new call C-B by sending a SETUP message to the UE. The UE shall respond with a CALL CONFIRMED message including cause #17 "user busy", followed by an ALERTING message.
The UE 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 UE shall indicate the existence of the waiting call to the user by a method defined by the manufacturer. The SS shall verify the call states by sending a STATUS ENQUIRY message to the UE and checking the transaction identifier and call state of each call in the received STATUS messages.
Expected sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1 |
<- |
SETUP |
Transaction identifier different from that of call A-B. |
|
2 |
-> |
CALL CONFIRMED |
Cause #17 "user busy". |
|
3 |
-> |
ALERTING |
||
4 |
UE |
A waiting call indication is given to the user as defined in a ICS/IXIT statement (Note: new IXIT may be needed). |
||
5 |
<- |
STATUS ENQUIRY |
Transaction identifier of call A-B |
|
6 |
-> |
STATUS |
Transaction identifier of call A-B, state U10 |
|
7 |
<- |
STATUS ENQUIRY |
Transaction identifier of call C-B |
|
8 |
-> |
STATUS |
Transaction identifier of call C-B, state U7 |
Specific message contents
SETUP (Step 1)
Information Element |
Value/remark |
---|---|
Signal |
|
Signal Value |
‘00000111’B (call waiting tone on) |
15.5.1.5 Test requirement
At step 2 the UE shall send CALL CONFIRMED message with cause #17 "user busy".
At step 4 the UE shall give a waiting call indication to the user.
15.5.2 Call completion supplementary services, Waiting call accepted; existing call released
15.5.2.1 Definition
15.5.2.2 Conformance requirement
If the mobile user B before expiry of timer T2 determines to accept the waiting call and release the existing call the mobile station shall release the existing call firstly and accept the waiting call secondly.
For the release of the existing call the mobile station and the network shall act in accordance with 3GPP TS 24.008. The transaction identifier shall be the transaction identifier (A‑B) of the already existing call. The Cause information element in the first clearing message shall indicate cause #16 "normal clearing".
For the acceptance of the waiting call the mobile station and the network shall act in accordance with 3GPP TS 24.008. The transaction identifier shall be the transaction identifier (C‑B) of the waiting call.
When the network receives the CONNECT message the timer T2 or if applicable the timer T3 shall be stopped.
Reference(s)
TS 24.083 clause 1.2.1.
15.5.2.3 Test purpose
1) To check that with an active call and when the user accepts to receive a new Mobile Terminated call, the UE shall first release the existing call and then accept the waiting call.
15.5.2.4 Method of test
Initial conditions:
– System Simulator:
– one cell, default parameters
– User Equipment:
– the UE is "Circuit Switched Connect" for speech on cell A as per the Generic call set up procedure for mobile terminating circuit switched calls found in TS 34.108 clause 7.2.3.1 (call A-B).
Related ICS/IXIT statement(s)
Support of FDD Yes/No.
Support of CS speech Yes/No.
Support of Call Waiting Yes/No.
Test Procedure
The SS shall initiate a new call C-B by sending a SETUP message to the UE. Using suitable user action the UE shall clear call A-B and then answer call C-B.
The UE shall send a DISCONNECT message with the transaction identifier of call A-B, and then respond to a RELEASE message from the SS with a RELEASE COMPLETE message, and then enter state U0 "Null" for call A-B.
The UE shall then send a CONNECT in respect of call C-B, and enter state U10 "Active" on receipt of a CONNECT ACKNOWLEDGE message. The SS shall verify the call states by the sending a STATUS ENQUIRY message to the UE. For call A-B the UE shall respond with a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" and for call C-B with a STATUS message indicating the appropriate call state.
Expected sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1 |
<- |
SETUP |
||
2 |
-> |
CALL CONFIRMED |
||
3 |
-> |
ALERTING |
U7, call received |
|
4 |
UE |
Call A-B is cleared using suitable user action |
||
5 |
-> |
DISCONNECT |
Transaction identifier of call A-B |
|
6 |
<- |
RELEASE |
Transaction identifier of call A-B |
|
7 |
-> |
RELEASE COMPLETE |
Transaction identifier of call A-B |
|
8 |
UE |
Call C-B is answered using suitable user action |
||
9 |
-> |
CONNECT |
Transaction identifier of call C-B |
|
10 |
<- |
CONNECT ACKNOWLEDGE |
Transaction identifier of call C-B |
|
11 |
<- |
STATUS ENQUIRY |
Transaction identifier of call A-B |
|
12 |
-> |
RELEASE COMPLETE |
Transaction identifier of call A-B, with cause #81 "invalid transaction identifier value" |
|
13 |
<- |
STATUS ENQUIRY |
Transaction identifier of call C-B |
|
14 |
-> |
STATUS |
Transaction identifier of call C-B, state U10 |
Specific message contents
SETUP (Step 1)
Information Element |
Value/remark |
---|---|
Signal |
|
Signal Value |
‘00000111’B (call waiting tone on) |
15.5.2.5 Test requirement
At step 5 the UE shall send DISCONNECT message with the transaction identifier of call A-B.
At step 9 the UE shall send CONNECT message with the transaction identifier of call C-B.
At step 12 the UE shall send RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response to the STATUS ENQUIRY message using TI of call A-B.
15.5.3 Call completion supplementary services, Waiting call accepted; existing call on hold, no additional calls
15.5.3.1 Definition
15.5.3.2 Conformance requirement
If the mobile user B before expiry of timer T2 or if applicable timer T3 determines to accept the waiting call and put the existing call on hold the mobile station shall put the existing call on hold firstly and accept the waiting call secondly.
In case there is one active call (A‑B) and another call (D‑B) on hold and call (C‑B) waiting, and the mobile user B wants to accept the waiting call (C‑B) and put the active call (A‑B) on hold, the held call (D‑B) has to be released first, either by user B or user D, in accordance with 3GPP TS 24.008.
To put the existing call on hold the mobile station and the network shall act in accordance with clause 2. The hold function shall be initiated by the mobile station and the transaction identifier shall be the transaction identifier (A‑B) of the existing call (see figure 1.3).
For the acceptance of the waiting call the mobile station and the network shall act in accordance with 3GPP TS 24.008. The transaction identifier shall be the transaction identifier (C‑B) of the waiting call (see figure 1.3).
When the network receives the CONNECT message the timer T2 or if applicable the timer T3 shall be stopped.
MS Network
HOLD
————————————————————————————————————————>
Transaction identifier (A-B)
HOLD ACKNOWLEDGE
<————————————————————————————————————————
Transaction identifier (A-B)
HOLD REJECT
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Transaction identifier (A-B)
Cause #29 (facility rejected)
or #50 (requested facility not subscribed)
or #69 (requested facility not implemented)
CONNECT
————————————————————————————————————————>
Transaction identifier(C-B)….. stop T2/T3
CONNECT ACKNOWLEDGE
<————————————————————————————————————————
Transaction identifier(C-B)
Figure 1.3: Existing call on hold and acceptance of waiting call by the mobile station
…
The hold and retrieve functions are performed on the same MM‑connection.
The hold function is used to put an existing call which is in the active phase in the Call held auxiliary state. By default, it retains the MM‑connection in use and the transaction identifier of the held call for possible subsequent call retrieval.
On receipt of a HOLD message the network shall return a HOLD ACKNOWLEDGE message, provided that the requested function can be performed. The network disconnects any user information path allocated to the active call when putting that call in the Call held auxiliary state. The mobile station disconnects any user information path to the active call and retains the transaction identifier and the MM‑connection when putting that call in the Call held auxiliary state.
The HOLD ACKNOWLEDGE message puts the call in the Call held auxiliary state and indicates that the hold function has been performed. The HOLD REJECT message indicates that the hold request was denied and returns the call to the condition it was in prior to the hold request. The HOLD REJECT message contains the Cause information element with e.g.:
‑ cause #29 "Facility rejected";
‑ cause #50 "Requested facility not subscribed";
‑ cause #69 "Requested facility not implemented".
The retrieve function reconnects the mobile station to the requested user information path. The RETRIEVE message requests that a call be retrieved. The RETRIEVE ACKNOWLEDGE message indicates that the retrieve function has been performed. The RETRIEVE REJECT message indicates that the retrieve request was denied. The RETRIEVE REJECT message contains the Cause information element with e.g.:
‑ cause #34 "No channel available".
Reference(s)
TS 24.083 clause 1.2.2 and clause 2.1.1.
15.5.3.3 Test purpose
1) To check that with an active call and when the user accepts to receive a new Mobile Terminated call, the UE shall place the existing call on hold and then accept the waiting call.
15.5.3.4 Method of test
Initial conditions:
– System Simulator:
– one cell, default parameters
– User Equipment:
– the UE is "Circuit Switched Connect" for speech on cell A as per the Generic call set up procedure for mobile terminating circuit switched calls found in TS 34.108 clause 7.2.3.1 (call A-B).
Related ICS/IXIT statement(s)
Support of FDD Yes/No.
Support of CS speech Yes/No.
Support of Call Waiting Yes/No.
Support of Call Hold Yes/No.
Test Procedure
The SS shall initiate a new call C-B by sending a SETUP message to the UE. Using suitable user action the UE shall place the active call A-B on hold and then answer call C-B.
The UE 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 hold request". The SS shall respond with a HOLD ACKNOWLEDGE message and the UE shall enter state U10 "Active" with auxiliary state "Call held".
The UE 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 SS shall verify the call states by sending a STATUS ENQUIRY message to the UE. For both calls the UE shall respond with a STATUS message indicating the appropriate transaction identifier and call state.
Expected sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1 |
<- |
SETUP |
||
2 |
-> |
CALL CONFIRMED |
||
3 |
-> |
ALERTING |
U7, call received |
|
4 |
UE |
Call A-B is placed on hold using suitable user action |
||
5 |
-> |
HOLD |
Transaction identifier of call A-B |
|
6 |
<- |
HOLD ACKNOWLEDGE |
Transaction identifier of call A-B |
|
7 |
UE |
Call C-B is answered using suitable user action |
||
8 |
-> |
CONNECT |
Transaction identifier of call C-B |
|
9 |
<- |
CONNECT ACKNOWLEDGE |
Transaction identifier of call C-B |
|
10 |
<- |
STATUS ENQUIRY |
Transaction identifier of call A-B |
|
11 |
-> |
STATUS |
Transaction identifier of call A-B, state U10, auxiliary state "Call Held" |
|
12 |
<- |
STATUS ENQUIRY |
Transaction identifier of call C-B |
|
13 |
-> |
STATUS |
Transaction identifier of call C-B, state U10 |
Specific message contents
SETUP (Step 1)
Information Element |
Value/remark |
---|---|
Signal |
|
Signal Value |
‘00000111’B (call waiting tone on) |
15.5.3.5 Test requirement
At step 5 the UE shall send HOLD message with the transaction identifier of call A-B.
At step 8 the UE shall send CONNECT message with the transaction identifier of call C-B.
15.5.4 Call completion supplementary services, Existing call released by user A; waiting call accepted
15.5.4.1 Definition
15.5.4.2 Conformance requirement
If user A before the expiry of timer T2 or if applicable timer T3 determines to release the existing call then the existing call shall be released by the network firstly and the waiting call may be accepted by the mobile station secondly.
For the release of the existing call the network and the mobile station shall act in accordance with 3GPP TS 24.008. The transaction identifier shall be the transaction identifier (A‑B) of the existing call.
For the acceptance of the waiting call the mobile station and the network shall act in accordance with 3GPP TS 24.008. The transaction identifier shall be the transaction identifier (C‑B) of the waiting call.
When the network receives the CONNECT message the timer T2 or if applicable the timer T3 shall be stopped.
Reference(s)
TS 24.083 clause 1.2.3.
15.5.4.3 Test purpose
1) To check that, UE on receipt of the Disconnect message from the active call is able to complete the call clearance procedure and accept the waiting call.
15.5.4.4 Method of test
Initial conditions:
– System Simulator:
– one cell, default parameters
– User Equipment:
– the UE is "Circuit Switched Connect" for speech on cell A as per the Generic call set up procedure for mobile terminating circuit switched calls found in TS 34.108 clause 7.2.3.1 (call A-B).
Related ICS/IXIT statement(s)
Support of FDD Yes/No.
Support of CS speech Yes/No.
Support of Call Waiting Yes/No.
Test Procedure
The SS shall initiate a new call C-B by sending a SETUP message to the UE.
The SS shall initiate the release of the active call A-B and on receipt of a DISCONNECT message using the transaction identifier of call A-B, the UE shall respond with a RELEASE message. On receipt of a RELEASE COMPLETE message, the UE shall enter state U0 "Null".
If necessary, suitable user action shall be made to accept call C-B. The UE shall then send a CONNECT message using the transaction identifier of call C-B, and on receipt of a CONNECT ACKNOWLEDGE message, the UE shall enter state U10 "Active". The SS shall verify the call states by sending a STATUS ENQUIRY message to the UE. For call A-B the UE shall respond with a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" and for call C-B with a STATUS message indicating the appropriate call state.
Expected sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1 |
<- |
SETUP |
||
2 |
-> |
CALL CONFIRMED |
||
3 |
-> |
ALERTING |
U7, call received |
|
4 |
<- |
DISCONNECT |
Transaction identifier of call A-B |
|
5 |
-> |
RELEASE |
Transaction identifier of call A-B |
|
6 |
<- |
RELEASE COMPLETE |
Transaction identifier of call A-B |
|
7 |
UE |
Call C-B is answered using suitable user action |
||
8 |
-> |
CONNECT |
Transaction identifier of call C-B |
|
9 |
<- |
CONNECT ACKNOWLEDGE |
Transaction identifier of call C-B |
|
10 |
<- |
STATUS ENQUIRY |
Transaction identifier of call A-B |
|
11 |
-> |
RELEASE COMPLETE |
Transaction identifier of call A-B, with cause #81 "invalid transaction identifier value" |
|
12 |
<- |
STATUS ENQUIRY |
Transaction identifier of call C-B |
|
13 |
-> |
STATUS |
Transaction identifier of call C-B, state U10 |
Specific message contents
SETUP (Step 1)
Information Element |
Value/remark |
---|---|
Signal |
|
Signal Value |
‘00000111’B (call waiting tone on) |
15.5.4.5 Test requirement
At step 5 the UE shall send RELEASE message with the transaction identifier of call A-B.
At step 8 the UE shall send CONNECT message with the transaction identifier of call C-B.
At step 11 the UE shall send RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response to the STATUS ENQUIRY message using TI of call A-B.
15.5.5 Call completion supplementary services, Waiting call released by subscriber B
15.5.5.1 Definition
15.5.5.2 Conformance requirement
For the release of the waiting call the mobile station and the network shall act in accordance with 3GPP TS 24.008. The transaction identifier shall be the transaction identifier (C‑B) of the waiting call.
* If the B subscriber indicates UDUB by the sending of the first clearing message with cause information element #17 (User Busy), and call forwarding on mobile subscriber busy is activated for the B subscriber the call shall be forwarded by the network. If call forwarding is not active the call will be cleared.
* If any other causes are given in the first clearing message the call will be released.
Reference(s)
TS 24.083 clause 1.3.1.
15.5.5.3 Test purpose
1) To check that the UE, on sending of the Disconnect message for the waiting call, is able to complete the call clearance procedure and continue the ongoing call.
15.5.5.4 Method of test
Initial conditions:
– System Simulator:
– one cell, default parameters
– User Equipment:
– the UE is "Circuit Switched Connect" for speech on cell A as per the Generic call set up procedure for mobile terminating circuit switched calls found in TS 34.108 clause 7.2.3.1 (call A-B).
Related ICS/IXIT statement(s)
Support of FDD Yes/No.
Support of CS speech Yes/No.
Support of Call Waiting Yes/No.
Test Procedure
The SS shall initiate a new call C-B by sending a SETUP message to the UE.
The UE shall initiate the release of the waiting call C-B and on receipt of a RELEASE message using the transaction identifier of call C-B, the UE shall respond with a RELEASE COMPLETE message. The UE shall enter state U0 "Null".
The SS shall verify the call states by sending a STATUS ENQUIRY message to the UE. For call C-B the UE shall respond with a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" and for call A-B with a STATUS message indicating the appropriate call state.
Expected sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1 |
<- |
SETUP |
||
2 |
-> |
CALL CONFIRMED |
||
3 |
-> |
ALERTING |
U7, call received |
|
4 |
UE |
Call C-B is cleared using suitable user action |
||
5 |
-> |
DISCONNECT |
Transaction identifier of call C-B |
|
6 |
<- |
RELEASE |
Transaction identifier of call C-B |
|
7 |
-> |
RELEASE COMPLETE |
Transaction identifier of call C-B |
|
8 |
<- |
STATUS ENQUIRY |
Transaction identifier of call C-B |
|
9 |
-> |
RELEASE COMPLETE |
Transaction identifier of call C-B, with cause #81 "invalid transaction identifier value" |
|
10 |
<- |
STATUS ENQUIRY |
Transaction identifier of call A-B |
|
11 |
-> |
STATUS |
Transaction identifier of call A-B, state U10 |
Specific message contents
SETUP (Step 1)
Information Element |
Value/remark |
---|---|
Signal |
|
Signal Value |
‘00000111’B (call waiting tone on) |
15.5.5.5 Test requirement
At step 5 the UE shall send DISCONNECT message with the transaction identifier of call C-B.
At step 9 the UE shall send RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response to the STATUS ENQUIRY message using TI of call C-B.
15.5.6 Call completion supplementary services, Waiting call released by calling user C
15.5.6.1 Definition
15.5.6.2 Conformance requirement
If the calling user C, before the expiry of timer T2 or timer T3 (if applicable), releases the waiting call then the network shall release the waiting call against the mobile station.
For the release of the waiting call the network and the mobile station shall act in accordance with 3GPP TS 24.008. The transaction identifier shall be the transaction identifier (C‑B) of the waiting call.
When the network initiates clearing by sending a clearing message to the mobile station the timer T2 or, if applicable, the timer T3 shall be stopped.
Reference(s)
TS 24.083 clause 1.3.2.
15.5.6.3 Test purpose
1) To check that when the calling user releases the waiting call, the UE is able to complete the call clearance procedure and continue the ongoing call.
15.5.6.4 Method of test
Initial conditions:
– System Simulator:
– one cell, default parameters
– User Equipment:
– the UE is "Circuit Switched Connect" for speech on cell A as per the Generic call set up procedure for mobile terminating circuit switched calls found in TS 34.108 clause 7.2.3.1 (call A-B).
Related ICS/IXIT statement(s)
Support of FDD Yes/No.
Support of CS speech Yes/No.
Support of Call Waiting Yes/No.
Test Procedure
The SS shall initiate a new call C-B by sending a SETUP message to the UE.
The SS shall initiate the release of the waiting call C-B and on receipt of a DISCONNECT message using the transaction identifier of call C-B, the UE shall respond with a RELEASE message. On receipt of a RELEASE COMPLETE message, the UE shall enter state U0 "Null" for call C-B.
The SS shall verify the call states by sending a STATUS ENQUIRY message to the UE. For call C-B the UE shall respond with a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" and for call A-B with a STATUS message indicating the appropriate call state.
Expected sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1 |
<- |
SETUP |
||
2 |
-> |
CALL CONFIRMED |
||
3 |
-> |
ALERTING |
U7, call received |
|
4 |
<- |
DISCONNECT |
Transaction identifier of call C-B |
|
5 |
-> |
RELEASE |
Transaction identifier of call C-B |
|
6 |
<- |
RELEASE COMPLETE |
Transaction identifier of call C-B |
|
7 |
<- |
STATUS ENQUIRY |
Transaction identifier of call C-B |
|
8 |
-> |
RELEASE COMPLETE |
Transaction identifier of call C-B, with cause #81 "invalid transaction identifier value" |
|
9 |
<- |
STATUS ENQUIRY |
Transaction identifier of call A-B |
|
10 |
-> |
STATUS |
Transaction identifier of call A-B, state U10 |
Specific message contents
SETUP (Step 1)
Information Element |
Value/remark |
---|---|
Signal |
|
Signal Value |
‘00000111’B (call waiting tone on) |
15.5.6.5 Test requirement
At step 5 the UE shall send RELEASE message with the transaction identifier of call C-B.
At step 8 the UE shall send RELEASE COMPLETE message with cause #81 “invalid transaction identifier value” as the response to the STATUS ENQUIRY message using TI of call C-B.
15.5.7 Call completion supplementary services, Activation
15.5.7.1 Definition
15.5.7.2 Conformance requirement
Activation of the supplementary service call waiting will be performed by the subscriber. The network will send a return result indication of acceptance of the request (see figure 1.4).
If the network cannot accept an activation request, an error indication is returned to the served mobile subscriber. Error values are specified in 3GPP TS 24.080 (see figure 1.4).
If the mobile subscriber does not indicate a specific basic service group the activation of call waiting is valid for all applicable basic services (see figure 1.4).
Normal outgoing call procedures apply when this service is activated.
MS Network
REGISTER
————————————————————————————————————————>
Facility (Invoke = ActivateSS (CW, BasicServiceCode))
RELEASE COMPLETE
<————————————————————————————————————————
Facility (Return result = ActivateSS (BasicServiceCode))
RELEASE COMPLETE
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Facility (Return error (Error))
RELEASE COMPLETE
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Facility (Reject (Invoke_problem))
NOTE: If the BasicServiceCode is not included the activation is valid for all applicable basic services.
Figure 1.4: Activation of call waiting
Reference(s)
TS 24.083 clause 1.4.
15.5.7.3 Test purpose
To check the correct operation of the activation procedure and that the UE correctly displays the response from the network in the following cases:
1) Successful activation.
2) Error response (reject).
3) Activation reject (Invoke problem).
15.5.7.4 Method of test
Initial conditions:
– System Simulator:
– one cell, default parameters
– User Equipment:
– The UE is in the MM-state "idle updated".
Related ICS/IXIT statement(s)
Support of FDD Yes/No.
Support of CS speech Yes/No.
Support of Call Waiting Yes/No.
Description of the user’s commands and display of the answers from the network for activation of call waiting.
Test Procedure
Using suitable action, the user requests activation of call waiting for a basic service group speech.
Upon receipt of the operation (in a REGISTER message), the SS shall answer with the RELEASE COMPLETE message with the Facility information element containing the return result of the ActivateSS operation.
Then again, using suitable action, the user requests activation of call waiting for all basic service groups.
Upon receipt of the operation (in a REGISTER message), the SS shall answer with the RELEASE COMPLETE message with the Facility information element containing the return result of the ActivateSS operation.
Using suitable action, the user requests activation of call waiting for a basic service group speech.
Upon receipt of the operation (in a REGISTER message), the SS shall answer with the RELEASE COMPLETE message with the Facility information element containing a Return error component with Error code: shortTermDenial.
Then again, using suitable action, the user requests activation of call waiting for all basic service groups.
Upon receipt of the operation (in a REGISTER message), the SS shall answer with the RELEASE COMPLETE message with the Facility information element containing a Return error component with Error code: longTermDenial.
Using suitable action, the user requests activation of call waiting for a basic service group speech.
Upon receipt of the operation (in a REGISTER message), the SS shall answer with the RELEASE COMPLETE message with the Facility information element containing a Reject component with Invoke problem (Resource limitation).
Then again, using suitable action, the user requests activation of call waiting 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 Reject component with Invoke problem (Initiating Release).
Expected sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1 |
UE |
The UE is made to initiate activation of call waiting for a basic service group speech. |
||
2 |
-> |
CM SERVICE REQUEST |
CM service type: "supplementary service activation" |
|
2A |
<- |
AUTHENTICATION REQUEST |
||
2B |
-> |
AUTHENTICATION RESPONSE |
||
3 |
SS |
The SS starts integrity protection |
||
4 |
-> |
REGISTER |
||
5 |
<- |
RELEASE COMPLETE |
ActivateSS operation Return result. |
|
5A |
SS |
The SS releases the RRC connection. |
||
6 |
UE |
The UE shall provide correct user indication after step 5 |
||
7 |
Void |
|||
8 |
UE |
The UE is made to initiate activation of call waiting for all basic service groups supported by the UE. |
||
9 |
-> |
CM SERVICE REQUEST |
CM service type: "supplementary service activation" |
|
10 |
SS |
The SS starts integrity protection |
||
11 |
-> |
REGISTER |
||
12 |
<- |
RELEASE COMPLETE |
ActivateSS operation Return result. |
|
12A |
SS |
The SS releases the RRC connection. |
||
13 |
UE |
The UE shall provide correct user indication after step 12 |
||
14 |
Void |
|||
15 |
UE |
The UE is made to initiate activation of call waiting for a basic service group speech. |
||
16 |
-> |
CM SERVICE REQUEST |
CM service type: "supplementary service activation" |
|
17 |
SS |
The SS starts integrity protection |
||
18 |
-> |
REGISTER |
||
19 |
<- |
RELEASE COMPLETE |
ActivateSS operation Return error. |
|
19A |
SS |
The SS releases the RRC connection. |
||
20 |
UE |
The UE shall provide correct user indication after step 19 |
||
21 |
Void |
|||
22 |
UE |
The UE is made to initiate activation of call waiting for all basic service groups supported by the UE. |
||
23 |
-> |
CM SERVICE REQUEST |
CM service type: "supplementary service activation" |
|
24 |
SS |
The SS starts integrity protection |
||
25 |
-> |
REGISTER |
||
26 |
<- |
RELEASE COMPLETE |
ActivateSS operation Return error. |
|
26A |
SS |
The SS releases the RRC connection. |
||
27 |
UE |
The UE shall provide correct user indication after step 26 |
||
28 |
Void |
|||
29 |
UE |
The UE is made to initiate activation of call waiting for a basic service group speech. |
||
30 |
-> |
CM SERVICE REQUEST |
CM service type: "supplementary service activation" |
|
31 |
SS |
The SS starts integrity protection |
||
32 |
-> |
REGISTER |
||
33 |
<- |
RELEASE COMPLETE |
ActivateSS operation Reject. |
|
33A |
SS |
The SS releases the RRC connection. |
||
34 |
UE |
The UE shall provide correct user indication after step 33 |
||
35 |
Void |
|||
36 |
UE |
The UE is made to initiate activation of call waiting for all basic service groups supported by the UE. |
||
37 |
-> |
CM SERVICE REQUEST |
CM service type: "supplementary service activation" |
|
38 |
SS |
The SS starts integrity protection |
||
39 |
-> |
REGISTER |
||
40 |
<- |
RELEASE COMPLETE |
ActivateSS operation Reject. |
|
40A |
SS |
The SS releases the RRC connection. |
||
41 |
UE |
The UE shall provide correct user indication after step 40 |
||
42 |
Void |
Specific message contents
RELEASE COMPLETE with Return result component (Step 5)
Information Element |
Value/remark |
---|---|
Operation code |
activateSS |
Parameters |
|
basicService |
Same value as in Step 4 |
RELEASE COMPLETE with Return result component (Step 12)
Information Element |
Value/remark |
---|---|
Operation code |
activateSS |
Parameters |
|
basicService |
Same value as in Step 11 |
RELEASE COMPLETE with Return error component (Step 19)
Information Element |
Value/remark |
---|---|
Facility |
|
Error code |
shortTermDenial |
RELEASE COMPLETE with Return error component (Step 26)
Information Element |
Value/remark |
---|---|
Facility |
|
Error code |
longTermDenial |
RELEASE COMPLETE with Reject component (Step 33)
Information Element |
Value/remark |
---|---|
Facility |
|
Problem code |
Resource Limitation |
RELEASE COMPLETE with Reject component (Step 40)
Information Element |
Value/remark |
---|---|
Facility |
|
Problem code |
Initiating Release |
15.5.7.5 Test requirement
At steps 6, 13, 20, 27, 34 and 41 the UE shall display the correct user indication.
15.5.8 Call completion supplementary services, Deactivation
15.5.8.1 Definition
15.5.8.2 Conformance requirement
Deactivation of the supplementary service call waiting will be performed by the subscriber. The network will send a return result indication of acceptance of the request (see figure 1.5).
If the network cannot accept a deactivation request, an error indication is returned to the served mobile subscriber. Error values are specified in 3GPP TS 24.080 (see figure 1.5).
If the subscriber does not indicate a specific basic service group the deactivation of call waiting is valid for all applicable basic services (see figure 1.5).
MS Network
REGISTER
————————————————————————————————————————>
Facility (Invoke = DeactivateSS (CW, BasicServiceCode))
RELEASE COMPLETE
<————————————————————————————————————————
Facility (Return result = DeactivateSS (BasicServiceCode))
RELEASE COMPLETE
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Facility (Return error (Error))
RELEASE COMPLETE
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Facility (Reject (Invoke_problem))
NOTE: If the BasicServiceCode is not included the deactivation is valid for all applicable basic services.
Figure 1.5: Deactivation of call waiting
Reference(s)
TS 24.083 clause 1.5.
15.5.8.3 Test purpose
To check the correct operation of the deactivation procedure and that the UE correctly displays the response from the network in the following cases:
1) Successful deactivation.
2) Error response (reject).
3) Deactivation reject (Invoke problem).
15.5.8.4 Method of test
Initial conditions:
– System Simulator:
– one cell, default parameters
– User Equipment:
– The UE is in the MM-state "idle updated".
Related ICS/IXIT statement(s)
Support of FDD Yes/No.
Support of CS speech Yes/No.
Support of Call Waiting Yes/No.
Description of the user’s commands and display of the answers from the network for deactivation of call waiting.
Test Procedure
Using suitable action, the user requests deactivation of call waiting for a basic service group speech.
Upon receipt of the operation (in a REGISTER message), the SS shall answer with the RELEASE COMPLETE message with the Facility information element containing the return result of the DeactivateSS operation.
Then again, using suitable action, the user requests deactivation of call waiting for all basic service groups.
Upon receipt of the operation (in a REGISTER message), the SS shall answer with the RELEASE COMPLETE message with the Facility information element containing the return result of the DeactivateSS operation.
Using suitable action, the user requests deactivation of call waiting for a basic service group speech.
Upon receipt of the operation (in a REGISTER message), the SS shall answer with the RELEASE COMPLETE message with the Facility information element containing a Return error component with Error code: shortTermDenial.
Then again, using suitable action, the user requests deactivation of call waiting for all basic service groups.
Upon receipt of the operation (in a REGISTER message), the SS shall answer with the RELEASE COMPLETE message with the Facility information element containing a Return error component with Error code: longTermDenial.
Using suitable action, the user requests deactivation of call waiting for a basic service group speech.
Upon receipt of the operation (in a REGISTER message), the SS shall answer with the RELEASE COMPLETE message with the Facility information element containing a Reject component with Invoke problem (Resource limitation).
Then again, using suitable action, the user requests deactivation of call waiting 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 Reject component with Invoke problem (Initiating Release).
Expected sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1 |
UE |
The UE is made to initiate deactivation of call waiting for a basic service group speech. |
||
2 |
-> |
CM SERVICE REQUEST |
CM service type: "supplementary service activation" |
|
2A |
<- |
AUTHENTICATION REQUEST |
||
2B |
-> |
AUTHENTICATION RESPONSE |
||
3 |
SS |
The SS starts integrity protection |
||
4 |
-> |
REGISTER |
||
5 |
<- |
RELEASE COMPLETE |
DeactivateSS operation Return result. |
|
5A |
SS |
The SS releases the RRC connection. |
||
6 |
UE |
The UE shall provide correct user indication after step 5 |
||
7 |
Void |
|||
8 |
UE |
The UE is made to initiate deactivation of call waiting for all basic service groups supported by the UE. |
||
9 |
-> |
CM SERVICE REQUEST |
CM service type: "supplementary service activation" |
|
10 |
SS |
The SS starts integrity protection |
||
11 |
-> |
REGISTER |
||
12 |
<- |
RELEASE COMPLETE |
DeactivateSS operation Return result. |
|
12A |
SS |
The SS releases the RRC connection. |
||
13 |
UE |
The UE shall provide correct user indication after step 12 |
||
14 |
Void |
|||
15 |
UE |
The UE is made to initiate deactivation of call waiting for a basic service group speech. |
||
16 |
-> |
CM SERVICE REQUEST |
CM service type: "supplementary service activation" |
|
17 |
SS |
The SS starts integrity protection |
||
18 |
-> |
REGISTER |
||
19 |
<- |
RELEASE COMPLETE |
DeactivateSS operation Return error. |
|
19A |
SS |
The SS releases the RRC connection. |
||
20 |
UE |
The UE shall provide correct user indication after step 19 |
||
21 |
Void |
|||
22 |
UE |
The UE is made to initiate deactivation of call waiting for all basic service groups supported by the UE. |
||
23 |
-> |
CM SERVICE REQUEST |
CM service type: "supplementary service activation" |
|
24 |
SS |
The SS starts integrity protection |
||
25 |
-> |
REGISTER |
||
26 |
<- |
RELEASE COMPLETE |
DeactivateSS operation Return error. |
|
26A |
SS |
The SS releases the RRC connection. |
||
27 |
UE |
The UE shall provide correct user indication after step 26 |
||
28 |
Void |
|||
29 |
UE |
The UE is made to initiate deactivation of call waiting for a basic service group speech. |
||
30 |
-> |
CM SERVICE REQUEST |
CM service type: "supplementary service activation" |
|
31 |
SS |
The SS starts integrity protection |
||
32 |
-> |
REGISTER |
||
33 |
<- |
RELEASE COMPLETE |
DeactivateSS operation Reject. |
|
33A |
SS |
The SS releases the RRC connection. |
||
34 |
UE |
The UE shall provide correct user indication after step 33 |
||
35 |
Void |
|||
36 |
UE |
The UE is made to initiate deactivation of call waiting for all basic service groups supported by the UE. |
||
37 |
-> |
CM SERVICE REQUEST |
CM service type: "supplementary service activation" |
|
38 |
SS |
The SS starts integrity protection |
||
39 |
-> |
REGISTER |
||
40 |
<- |
RELEASE COMPLETE |
DeactivateSS operation Reject. |
|
40A |
SS |
The SS releases the RRC connection. |
||
41 |
UE |
The UE shall provide correct user indication after step 40 |
||
42 |
Void |
Specific message contents
RELEASE COMPLETE with Return result component (Step 5)
Information Element |
Value/remark |
---|---|
Operation code |
DeactivateSS |
Parameters |
|
basicService |
Same value as in Step 4 |
RELEASE COMPLETE with Return result component (Step 12)
Information Element |
Value/remark |
---|---|
Operation code |
DeactivateSS |
Parameters |
|
basicService |
Same value as in Step 11 |
RELEASE COMPLETE with Return error component (Step 19)
Information Element |
Value/remark |
---|---|
Facility |
|
Error code |
shortTermDenial |
RELEASE COMPLETE with Return error component (Step 26)
Information Element |
Value/remark |
---|---|
Facility |
|
Error code |
longTermDenial |
RELEASE COMPLETE with Reject component (Step 33)
Information Element |
Value/remark |
---|---|
Facility |
|
Problem code |
Resource Limitation |
RELEASE COMPLETE with Reject component (Step 40)
Information Element |
Value/remark |
---|---|
Facility |
|
Problem code |
Initiating Release |
15.5.8.5 Test requirement
At steps 6, 13, 20, 27, 34 and 41 the UE shall display the correct user indication.