10.1.4 In call functions
34.123-13GPPPart 1: Protocol conformance specificationRelease 15TSUser Equipment (UE) conformance specification
10.1.4.1 In-call functions / DTMF information transfer
10.1.4.1.1 In-call functions / DTMF information transfer / basic procedures
10.1.4.1.1.1 Definition
Dual Tone Multi Frequency (DTMF) is an inband one out of four plus one out of four signalling system primarily used from terminal instruments in telecommunication networks.
10.1.4.1.1.2 Conformance requirement
1) A user may cause a DTMF tone to be generated e.g. by depression of a key in the UE. The relevant action is interpreted by the UE as a requirement for a DTMF digit to be sent in a START DTMF message on an established FACCH. This message contains the value of the digit to be transmitted (0, 1, …, 9, A, B, C, D, *, #).
Only a single digit will be transferred in each START DTMF message.
2) Upon receiving the START DTMF message the network will reconvert the received digit back into a DTMF tone which is applied toward the remote user and returns a START DTMF ACKNOWLEDGE message to the UE. This acknowledgement may be used in the UE to generate an indication as a feedback for a successful transmission.
3) When the user indicates that the DTMF sending should cease e.g. by releasing the key the UE will send a STOP DTMF message to the network.
References
Conformance requirement 1: TS 24.008 clause 5.5.7.1
Conformance requirement 2 and 4: TS 24.008 clause 5.5.7.2
Conformance requirement 3: TS 24.008 clause 5.5.7.3
10.1.4.1.1.3 Test purpose
1) To verify that an UE supporting the Mobile originating DTMF protocol control procedure, having a CC entity for speech in state U10, "Active": when made to send a DTMF tone, sends a START DTMF message.
2) To verify that an UE supporting the Mobile originating DTMF protocol control procedure, having a CC entity for speech in state U10, "Active": when made to send a DTMF tone (the corresponding IA5 character being selected from among the ones supported), sends a START DTMF message specifying the correct IA5 character in the "keypad information" field of the keypad facility information element and to verify that acknowledgement send by the SS is used in the UE to generate a feedback indication for a successful transmission, if applicable.
3) To verify that the UE will send a STOP DTMF message to the network.
4) To verify that the state U10 of the UE CC entity has remained unchanged throughout the test procedure.
10.1.4.1.1.4 Method of test
Related ICS/IXIT statements
– supported teleservices;
– supported character set (e.g. 0‑9, #, *, A, B, C, D);
– if and how DTMF tone is indicated to the user.
Initial conditions
System Simulator:
1 cell, default parameters.
User Equipment:
The UE is in MM-state "idle, updated" with valid TMSI and CKSN.
The UE is brought into the state U10 "Active" by using table 10.1.2/1.
Test procedure
The UE being in the active state, a user causes a DTMF tone to be generated e.g. by depression of a key in the UE. A DTMF digit corresponding to the digit indicated by the user is sent in a START DTMF message by the UE. The SS will return a START DTMF ACKNOWLEDGE message to the UE. This acknowledgement may be used in the UE to generate an indication as a feedback for a successful transmission. Then the user indicates that the DTMF sending should cease e.g. by releasing the key. The UE will send a STOP DTMF message to the network which is acknowledged with STOP DTMF ACKNOWLEDGE by the SS.
The sequence described above is repeated for each of the applicable characters 0‑9, #, *, A, B, C, and D.
Then a case of rejecting a DTMF tone is tested.
The state of the UE is verified throughout the test procedure.
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
SS |
Request the user to cause a DTMF tone to be generated |
||
-> |
START DTMF |
the SS will verify that the transmitted information corresponds to the digit pressed |
||
2 |
<- |
START DTMF ACKNOWLEDGE |
possible indication of a DTMF tone depending the ICS/IXIT statements |
|
3 |
<- |
STATUS ENQUIRY |
||
4 |
-> |
STATUS |
cause #30, state U10 |
|
5 |
-> |
STOP DTMF |
||
6 |
<- |
STOP DTMF ACKNOWLEDGE |
the DTMF tone indication shall be stopped |
|
7 |
the steps 1‑6 shall be repeated for each of the applicable characters 0‑9, #, *, A, B, C, D. |
|||
8 |
<- |
STATUS ENQUIRY |
||
9 |
-> |
STATUS |
cause #30, state U10 |
|
10 |
SS |
Request the user to cause a DTMF tone to be generated. |
||
11 |
-> |
START DTMF |
||
12 |
<- |
START DTMF REJECT |
||
13 |
<- |
STATUS ENQUIRY |
||
14 |
-> |
STATUS |
cause #30, state U10 |
Specific message contents:
None.
10.1.4.1.1.5 Test requirements
Upon a user making to send a DTMF tone the UE shall send a START DTMF message on the FACCH to SS.
The SS will verify that the transmitted information corresponds to the digit pressed in the UE.
After step s 2 and 7 (successful DTMF transmission) the CC-state U10, "Active", shall remain unchanged.
After step 12 (unsuccessful DTMF transmission) the CC-state U10, "Active", shall remain unchanged.
10.1.4.2 In-call functions / user notification
10.1.4.2.1 In-call functions / User notification / UE terminated
10.1.4.2.1.1 Definition
This is a case for testing user notification procedure terminated by the user equipment.
10.1.4.2.1.2 Conformance requirement
The mobile terminating user notification procedure allows the network to notify a mobile station of any appropriate call-related event during the "active" state of a call. The procedure consists in the network sending a NOTIFY message to the mobile station. No state change occurs at any of the interface sides following the sending or the receipt of this message (but an appropriate indication may optionally be generated in the mobile station).
References
TS 24.008 clause 5.3.1.
10.1.4.2.1.3 Test purpose
To verify that a CC entity of a UE in CC-state U10, "active", upon receiving of a NOTIFY message remains in the active state.
10.1.4.2.1.4 Method of test
Related ICS/IXIT statements
– supported circuit switched basic services.
Initial conditions
System Simulator:
1 cell, default parameters.
User Equipment:
The UE is in MM-state "idle, updated" with valid TMSI and CKSN.
The UE is brought into the state U10 "Active" by using table 10.1.2/1.
Test procedure
The UE being in the active state, the SS will send a NOTIFY message to the UE. The state of the UE is checked after that.
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
<- |
NOTIFY |
||
2 |
<- |
STATUS ENQUIRY |
||
3 |
-> |
STATUS |
cause #30, state U10 |
Specific message contents:
None.
10.1.4.2.1.5 Test requirements
After step 1 the CC-state U10, "active", shall remain unchanged.
10.1.4.3 In-call functions / channel changes
The two following test cases are for testing some elementary radio resource level procedures during an active state of a call to ensure call maintenance also during Hard handover.
10.1.4.3.1 In-call functions / channel changes / a successful channel change in active state/ Hard handover
10.1.4.3.1.1 Definition
This is a case to test a change of the frequency of a physical channel during active state of a call.
10.1.4.3.1.2 Conformance requirement
1) The UE being in the active state after having successful completed a physical channel reconfiguration, shall remain in the active state.
References
TS 24.008 clause 5.3.4.3.2, TS 25.331 clause 8.3.5.
10.1.4.3.1.3 Test purpose
To verify that the UE being in the active state after having successful completed a physical channel reconfiguration remains in the active state.
10.1.4.3.1.4 Method of test
Related ICS/IXIT statements
– supported circuit switched basic services;
Initial conditions
System Simulator:
1 cell, default parameters.
User Equipment:
The UE is in MM-state "idle, updated" with valid TMSI and CKSN.
The UE is brought into the state U10 "Active" by using table 10.1.2/1.
Test procedure
The UE being in the active state, the SS initiated physical channel reconfiguration procedure causing an intracell change of channel by sending a PHYSICAL CHANNEL RECONFIGURATION message to the UE. The UE performs physical channel reconfiguration procedure and after the main signalling link is successfully established, the UE returns a PHYSICAL CHANNEL RECONFIGURATION COMPLETE message on the uplink DCCH using AM RLC. The state of the UE is then checked.
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
<- |
PHYSICAL CHANNEL RECONFIGURATION |
||
2 |
-> |
PHYSICAL CHANNEL RECONFIGURATION COMPLETE |
||
3 |
<- |
STATUS ENQUIRY |
||
4 |
-> |
STATUS |
cause #30, state U10 |
Specific message contents:
None.
10.1.4.3.1.5 Test requirements
After step 2 the UE shall remain in the active state.
10.1.4.3.2 In-call functions / channel changes / an unsuccessful channel change in active mode/Hard handover
10.1.4.3.2.1 Definition
This is a case to test an unsuccessful change of the frequency of a physical channel during active state of a call.
10.1.4.3.2.2 Conformance requirement
1) The UE, when returning to the old channel after physical channel reconfiguration failure, shall remain in the active state.
References
TS 24.008 clause 5.3.4.3.
10.1.4.3.2.3 Test purpose
To verify that the UE, when returning to the old channel after physical channel reconfiguration failure, will remain in the active state.
10.1.4.3.2.4 Method of test
Related ICS/IXIT statements
– supported circuit switched basic services.
Initial conditions
System Simulator:
1 cell, default parameters.
User Equipment:
The UE is in MM-state "idle, updated" with valid TMSI and CKSN.
The UE is brought into the state U10 "Active" by using table 10.1.2/1.
Test procedure
The SS sends a PHYSICAL CHANNEL RECONFIGURATION message, but does not activate the assigned physical channel. The UE shall attempt try to activate the new channel (this is not verified) and shall then reactivate the "old" channel. The UE shall send a PHYSICAL CHANNEL RECONFIGURATION FAILURE message on the DCCH using AM RLC and shall set the cause value in IE "failure cause" to "physical channel failure". The state of the UE is then checked.
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
<- |
PHYSICAL CHANNEL RECONFIGURATION |
The UE attempts and fails to re-configure the physical channel. |
|
2 |
-> |
PHYSICAL CHANNEL RECONFIGURATION FAILURE |
NOTE |
|
3 |
<- |
STATUS ENQUIRY |
||
4 |
-> |
STATUS |
cause #30, state U10 |
|
Specific message contents:
NOTE: With the cause value "physical channel failure".
10.1.4.3.2.5 Test requirements
After step 2 the UE shall remain in the active state.
10.1.4.4 In-call functions / UE terminated in-call modification
10.1.4.4.1 In-call functions / UE terminated in-call modification / modify when new mode is not supported
This test is not applicable for R99.
10.1.4.5 In-call functions / UE originated in-call modification
10.1.4.5.1 In-call functions / UE originated in-call modification / a successful case of modifying
This test is not applicable for R99.
10.1.4.5.2 In-call functions / UE originated in-call modification / modify rejected
This test is not applicable for R99.
10.1.4.5.3 In-call functions / UE originated in-call modification / an abnormal case of acceptance
This test is not applicable for R99.
10.1.4.5.4 In-call functions / UE originated in-call modification / an abnormal case of rejection
This test is not applicable for R99.
10.1.4.5.5 In-call functions / UE originated in-call modification / time-out of timer T323
This test is not applicable for R99.
10.1.4.5.6 In-call functions / UE originated in-call modification / a successful channel change in state mobile originating modify
This test is not applicable for R99.
10.1.4.5.7 In-call functions / UE originated in-call modification / an unsuccessful channel change in state mobile originating modify
This test is not applicable for R99.
10.1.4.5.8 In-call functions / UE originated in-call modification / unknown message received
This test is not applicable for R99.
10.1.4.5.9 In-call functions / UE originated in-call modification / a release complete received
This test is not applicable for R99.