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.