26.5 Handling of unknown, unforeseen, and erroneous protocol data, and of parallel transactions

3GPP51.010-1Mobile Station (MS) conformance specificationPart 1: Conformance specificationTS

26.5.1 Handling of unknown, unforeseen, and erroneous protocol data, and of parallel transactions / unknown protocol discriminator

An MS ignores messages with unknown protocol discriminator. This allows for the introduction of new messages which will be ignored by MS of earlier phases.

26.5.1.1 Conformance requirements

If the mobile station receives a standard L3 message with a protocol discriminator different from those specified in table 9.2/3GPP TS 04.07, the mobile station shall ignore the message.

References

3GPP TS 04.07, subclause 11.2.1.

26.5.1.2 Test purpose

To verify that a MS supporting TCH and the call control protocol ignores a message containing an undefined protocol discriminator in the special case of a message coded otherwise like a CC STATUS ENQUIRY message received by the MS having a mobile terminating call in CC-state U10, "active".

26.5.1.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has been paged and an RR connection has been established.

If the MS supports the call control protocol, the test may alternatively be performed with the MS having a mobile terminating call in the CC-state U10, "active".

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

Same as in the initial conditions.

Test Procedure

The SS sends a message to the MS which is coded like a CC STATUS ENQUIRY message relating to the active call except for the fact that the protocol discriminator of the message is undefined.

Maximum duration of test

11 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

UNKNOWN MESSAGE

2

SS

The SS waits between 5 s and 10 s verifying during this period that the MS does not send a L3 message on the main signalling link.

Specific message contents

UNKNOWN MESSAGE

Information element

Value/remark

Protocol discriminator

0000

TI flag

transaction originated by SS

TI value

TI value of the active call if the test is performed in state U10 otherwise the value is arbitrary.

Message Type

H’34

26.5.2 Handling of unknown, unforeseen, and erroneous protocol data, and of parallel transactions / TI and skip indicator

26.5.2.1 TI and skip indicator / RR

The MS ignores RR messages with skip indicator different to 0. This allows for the introduction of new RR messages which will be ignored by MS of earlier phases, especially on the downlink CCCH and BCCH.

26.5.2.1.1 TI and skip indicator / RR / Idle Mode

26.5.2.1.1.1 Conformance requirements

A radio resource message received with skip indicator different from 0000 shall be ignored.

Reference(s):

3GPP TS 04.08 / 3GPP TS 24.008, subclause 10.3.1.

26.5.2.1.1.2 Test purpose

To verify that the MS ignores an RR message with skip indicator different from H’0 in the special case of a PAGING REQUEST TYPE 1 message received in the MM-state "idle, updated" and in RR-idle mode.

26.5.2.1.1.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" and in RR-idle mode. It has a valid TMSI.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode. It has a valid TMSI.

Test Procedure

For every binary value x in the range 0001 – 0110 (binary) and for binary value x = 1 000, the following procedure is performed: The SS sends a PAGING REQUEST TYPE 1 message to the MS with skip indicator set to x. It is verified that the MS does not answer to the paging request message.

Maximum duration of test

5 s for each execution.

Expected sequence

The sequence is executed for execution counter k = 1, 2, 3, 4, 5, 6, 8.

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

The value of the skip indicator IE is the binary encoding of k.

2

SS

During 3 s the SS verifies that the MS does not send any message on the RACH.

Specific message contents

None.

26.5.2.1.2 TI and skip indicator / RR / RR-Connection established

26.5.2.1.2.1 Conformance requirements

A radio resource message received with skip indicator different from H’0 shall be ignored.

Reference(s):

3GPP TS 04.08 / 3GPP TS 24.008, subclause 10.3.1.

26.5.2.1.2.2 Test purpose

To verify that the MS ignores RR messages with skip indicator different from H’0 in the case of a message being received during the RR-connection establishment in the MM-state "idle, updated" / "wait for network command" and in RR-connected mode.

26.5.2.1.2.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters, max retrans = 2.

Mobile Station:

The MS is in the MM-state "idle, updated" and in RR-idle mode. It has a valid TMSI.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode. It has a valid TMSI.

Test Procedure

The SS sends a PAGING REQUEST TYPE 1 message to the MS with skip indicator set to H’0. The first CHANNEL REQUEST message will be answered with an IMMEDIATE ASSIGNMENT addressing the MS but with skip indicator set to H’1. Transmission of the second CHANNEL REQUEST message verifies that the MS has ignored the IMMEDIATE ASSIGNMENT message.

The second CHANNEL REQUEST message is answered by an IMMEDIATE ASSIGNMENT REJECT message addressing the MS but with skip indicator set to H’2 and a reject time set to 255 s. Transmission of the third CHANNEL REQUEST message verifies that the MS has ignored the IMMEDIATE ASSIGNMENT REJECT message.

The third CHANNEL REQUEST message from the MS will be answered with a correct IMMEDIATE ASSIGNMENT addressing the MS and having skip indicator set to H’0.

In the RR-Connected mode messages such as CIPHERING MODE COMMAND, HANDOVER COMMAND, ASSIGNMENT COMMAND and CHANNEL RELEASE are sent with the skip indicator <> H’0 and it is checked that the MS does not take any action on these commands.

Maximum duration of test

40 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

The value of the skip indicator IE is H’0

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT

skip indicator set to H’1

4

MS -> SS

CHANNEL REQUEST

5

SS -> MS

IMMEDIATE ASSIGNMENT REJECT

skip indicator = H’2, reject time = 255 s

6

MS -> SS

CHANNEL REQUEST

Cause, answer to paging

7

SS -> MS

IMMEDIATE ASSIGNMENT

skip indicator = H’0

8

MS -> SS

PAGING RESPONSE

RR connection established

9

SS -> MS

AUTHENTICATION REQUEST

10

MS -> SS

AUTHENTICATION RESPONSE

11

SS -> MS

CIPHERING MODE COMMAND

skip indicator = H’3

12

SS

the SS neither starts ciphering nor deciphering

13

SS -> MS

IDENTITY REQUEST

with IMSI requested

14

MS -> SS

IDENTITY RESPONSE

to check the MS still uses unciphered mode

15

SS -> MS

ASSIGNMENT COMMAND

skip indicator = H’4

16

SS

SS checks no SABM is sent by the MS on the new channel

17

SS -> MS

HANDOVER COMMAND

skip indicator = H’5

18

SS

During 3 s the SS verifies that the MS does not send a handover failure or RR STATUS message on the old channel

19

SS -> MS

CHANNEL RELEASE

skip indicator = H’6

20

SS -> MS

IDENTITY REQUEST

with IMSI requested

21

MS -> SS

IDENTITY RESPONSE

to check the RR connection is still established

22

SS -> MS

CHANNEL RELEASE

skip indicator = H’0

23

SS

The SS checks that the layer 2 connection is released

Specific message contents

None.

26.5.2.2 TI and skip indicator / MM

The MS ignores MM messages with skip indicator different to 0. This allows for the introduction of new MM messages which will be ignored by MS of earlier phases.

26.5.2.2.1 Conformance requirements

A mobility management message received with skip indicator different from 0000 shall be ignored.

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 10.3.1.

26.5.2.2.2 Test purpose

To verify that the MS ignores an MM message with skip indicator different from H’0 in the special case of an IDENTITY REQUEST message received.

26.5.2.2.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has a mobile terminating call in CC-state U10, "active", or alternatively, the MS has been paged and an RR connection has been established.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

Same as in the initial conditions.

Test Procedure

For every binary value x in the range 0001 – 0110 and for the binary value x = 1 000, the following procedure is performed: The SS sends an IDENTITY REQUEST message to the MS with skip indicator set to x. It is verified during 5 s that the MS does not answer to the IDENTITY REQUEST message.

Maximum duration of test

15 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

IDENTITY REQUEST

Skip indicator IE has value H’1.

2

SS

The SS starts verifying that the MS does not send any L3 message on the main signalling link. This verification continues until step 16 of this test sequence.

3

SS

The SS waits 1 second.

4

SS -> MS

IDENTITY REQUEST

Skip indicator IE has value H’2.

5

SS

The SS waits 1 second.

6

SS -> MS

IDENTITY REQUEST

Skip indicator IE has value H’3.

7

SS

The SS waits 1 second.

8

SS -> MS

IDENTITY REQUEST

Skip indicator IE has value H’4.

9

SS

The SS waits 1 second.

10

SS -> MS

IDENTITY REQUEST

Skip indicator IE has value H’5.

11

SS

The SS waits 1 second.

12

SS -> MS

IDENTITY REQUEST

Skip indicator IE has value H’6.

13

SS

The SS waits 1 second.

14

SS -> MS

IDENTITY REQUEST

Skip indicator IE has value H’8.

15

SS

The SS waits 5 s.

16

SS

The SS stops verifying that the MS does not send any L3 message on the main signalling link.

Specific message contents

None.

26.5.2.3 TI and skip indicator / CC

26.5.2.3.1 Conformance requirements

a) Whenever any call control message except SETUP or RELEASE COMPLETE is received specifying a transaction identifier with a value different from 111, which is not recognized as relating to an active call or to a call in progress, the receiving entity shall send a RELEASE COMPLETE message with cause value #81 "invalid transaction identifier value" using the received transaction identifier value and remain in the Null state.

b1) When a RELEASE COMPLETE message is received specifying a transaction identifier with a value different from 111, which is not recognized as relating to an active call or to a call in progress, the MM-connection associated with that transaction identifier shall be released.

b2) When a SETUP message is received with a transaction identifier flag set to "1", this message shall be ignored.

b3) When a SETUP message is received specifying a transaction identifier which is recognized as relating to an active call or to a call in progress, this SETUP message shall be ignored.

c) When a CC message with a TI value = 111 is received, this message shall be ignored.

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.3.

26.5.2.3.2 Test purpose

a) To verify that the MS having a mobile terminating call in CC-state U10, "active", on receipt of a DISCONNECT message which includes a transaction identifier with a value different from 111, which is not recognized as relating to an active call or a call in progress, sends a RELEASE COMPLETE message with cause value #81 and referring to the latter TI without changing the state of the active call (this is verified by use of the status enquiry procedure).

b) To verify that the MS having a mobile terminating call in CC-state U10, "active", on receipt of a:

b1) RELEASE COMPLETE message which includes a transaction identifier with a value different from 111, which is not recognized as relating to an active call or a call in progress, or a

b2) SETUP message with TI flag referring to a transaction originated by the MS (in the special case where the TI value is equal to the TI value relating to the active call), or a

b3) SETUP message with TI referring to the active call, ignores that message without changing the state of the active call (this is verified by use of the status enquiry procedure).

c) To verify that the MS ignores a CC message with a TI value of 111.

26.5.2.3.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has a mobile terminating call in CC-state U10, "active". No other call is active or in progress.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS has a mobile terminating call in CC-state U10, "active". No other call is active or in progress.

Test Procedure

The SS sends a DISCONNECT message to the MS with a TI not relating to the active call. The MS shall respond with a RELEASE COMPLETE message including cause value #81 and specifying the same transaction. By means of the status enquiry procedure the SS checks that the CC-state of the active call did not change.

Then the SS sends the following call control messages to the MS:

– a RELEASE COMPLETE message, where the TI does not refer to the active call;

– a SETUP message with TI flag set to 1;

– a SETUP message with TI referring to the active call;

– a DISCONNECT message with a TI value of 111.

Each time the SS verifies that the MS does not respond to the message and each time the SS verifies by means of the status enquiry procedure that the CC-state of the active call has not been changed.

Maximum duration of test

40 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

DISCONNECT

TI flag = 0; TI does not refer to the active call.

2

MS -> SS

RELEASE COMPLETE

TI flag = 1; TI value is equal to TI value received in step 1; Cause IE indicates cause value #81.

3

SS -> MS

STATUS ENQUIRY

TI refers to the active call.

4

MS -> SS

STATUS

TI refers to the active call; Cause IE indicates cause value #30. Call state IE indicates state U10

5

SS -> MS

RELEASE COMPLETE

TI flag = 0; TI does not refer to the active call.

6

SS

The SS verifies during 5 s that the MS does not send any L3 message on the main signalling link.

7

SS -> MS

STATUS ENQUIRY

TI refers to the active call.

8

MS -> SS

STATUS

TI refers to the active call; Cause IE indicates cause value #30. Call state IE indicates state U10

9

SS -> MS

SETUP

TI flag = 1; TI value is equal to TI value of the active call.

10

SS

The SS verifies during 5 s that the MS does not send any L3 message on the main signalling link.

11

SS -> MS

STATUS ENQUIRY

TI refers to the active call.

12

MS -> SS

STATUS

TI refers to the active call; Cause IE indicates cause value #30. Call state IE indicates state U10

13

SS -> MS

SETUP

TI flag = 0; TI refers to the active call.

14

SS

The SS verifies during 5 s that the MS does not send any L3 message on the main signalling link.

15

SS -> MS

STATUS ENQUIRY

TI refers to the active call.

16

MS -> SS

STATUS

TI refers to the active call; Cause IE indicates cause value #30. Call state IE indicates state U10

17

SS -> MS

DISCONNECT

TI flag = 0; TI value is 111.

18

SS

The SS verifies during 5 s that the MS does not send any L3 message on the main signalling link.

19

SS -> MS

STATUS ENQUIRY

TI refers to the active call.

20

MS -> SS

STATUS

TI refers to the active call; Cause IE indicates cause value #30. Call state IE indicates state U10

Specific message contents

None.

26.5.3 Handling of unknown, unforeseen, and erroneous protocol data, and of parallel transactions / undefined or unexpected message type

26.5.3.1 Undefined or unexpected message type / undefined message type / CC

26.5.3.1.1 Conformance requirements

If the Mobile Station receives a message with message type not defined for the PD, it shall ignore the message except for the fact that, if an RR-connection exists, it returns a status message (STATUS, RR STATUS or MM STATUS depending on the protocol discriminator) with cause value #97 "message type non-existent or not implemented".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.4; 3GPP TS 04.07, subclause 11.2.4.

26.5.3.1.2 Test purpose

To verify that a MS supporting the call control protocol for at least one BC, having a mobile terminating call in CC‑state U10, "active", on receipt of a message with CC protocol discriminator and an arbitrary undefined message type, returns a STATUS message with cause value #97 to the peer CC entity without changing the state of the active call (this is verified by use of the status enquiry procedure).

26.5.3.1.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has a mobile terminating call in CC-state U10, "active".

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS has a mobile terminating call in CC-state U10, "active".

Test Procedure

The SS sends a message to the MS the PD of which refers to call control, the TI of which refers to the active call, and the message type of which is undefined in the call control protocol (however bit 7 of the message type is "0"). The SS then checks that the MS responds with a STATUS message specifying cause value #97. The SS then sends a STATUS ENQUIRY message to the MS and verifies that the MS responds with a STATUS message specifying cause value #30 and call state U10, "active".

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

see comments

PD = "call control; call related SS messages" TI is that of the active call Message type is undefined for call control, bit 7 of the message type is "0"

2

MS -> SS

STATUS

Cause IE indicates cause value #97.

3

SS -> MS

STATUS ENQUIRY

4

MS -> SS

STATUS

TI refers to the active call; Cause IE indicates cause value #30. Call state IE indicates state U10

Specific message contents

None.

26.5.3.2 Undefined or unexpected message type / undefined message type / MM

26.5.3.2.1 Conformance requirements

If the Mobile Station receives a message with message type not defined for the PD, it shall ignore the message except for the fact that, if an RR-connection exists, it returns a status message (STATUS, RR STATUS or MM STATUS depending on the protocol discriminator) with cause value #97 "message type non-existent or not implemented".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.4.

26.5.3.2.2 Test purpose

To verify that a MS supporting the call control protocol for at least one BC, having a mobile terminating call in CC‑state U10, "active", on receipt of a message with MM protocol discriminator and message type undefined for the mobility management protocol, returns an MM STATUS message with reject cause value #97 without changing the state of the active call (this is verified by use of the status enquiry procedure.) This is tested in the special case where the CC TI has value 0 (so that it has the same encoding as the skip indicator when sent from the SS) and where the message type has the same encoding as DISCONNECT in CC.

26.5.3.2.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has a mobile terminating call in CC-state U10, "active". The TI of that mobile terminating call has value 0.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS has a mobile terminating call in CC-state U10, "active".

Test Procedure

The SS sends a message to the MS the PD of which refers to mobility management, the skip indicator of which is "0000", and the message type of which is "0000 0000". The SS then checks that the MS responds with an MM STATUS message specifying reject cause value #97. The SS then sends a STATUS ENQUIRY message to the MS and verifies that the MS responds with a STATUS message specifying cause #30 and call state U10, "active".

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

see comments

PD = "mobility management messages" Skip indicator = "0000" Message type = "0000 0000" rest of the message is H’02 H’E0 H’90

2

MS -> SS

MM STATUS

Reject cause IE indicates reject cause value #97.

3

SS -> MS

STATUS ENQUIRY

4

MS -> SS

STATUS

TI refers to the active call; Cause IE indicates cause value #30. Call state IE indicates state U10

Specific message contents

None.

26.5.3.3 Undefined or unexpected message type / undefined message type / RR

26.5.3.3.1 Conformance requirements

If the Mobile Station receives a message with message type not defined for the PD, it shall ignore the message except for the fact that, if an RR-connection exists, it returns a status message (STATUS, RR STATUS or MM STATUS depending on the protocol discriminator) with cause value #97 "message type non-existent or not implemented".

Reference(s)

3GPP TS 04.08 / 3GPP TS 44.018, subclause 8.4.

26.5.3.3.2 Test purpose

To verify that an MS in RR connected mode on receipt of a message with RR protocol discriminator and message type undefined for the RR protocol, returns an RR STATUS message with reject cause value #97 without changing its state (this is checked by observing that the MS does not send L3 messages).

26.5.3.3.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has been paged and an RR connection has been established.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in "idle updated" state.

Test Procedure

The SS sends a message to the MS the PD of which refers to radio resources management, the skip indicator of which is "0000", and the message type of which is "0010 1010". The SS then checks that the MS responds with an RR STATUS message specifying reject cause value #97. The SS then verifies during 5 s that the MS does not send a L3 message on the main signalling link but continues sending L2 fill frames on the main signalling link. Then the SS sends a SETUP message to the MS. This message specifies a BC that is supported by the MS, if there exists any; if the MS does not support any BC, the SETUP message specifies an arbitrary BC. The SS then verifies that the MS responds with a CALL CONFIRMED message if the SETUP had specified a BC supported by the MS, and that the MMS responds with a RELEASE COMPLETE message otherwise. Then the SS sends a CHANNEL RELEASE to the MS and waits for the disconnection of the main signalling link.

Maximum duration of test

15 s.

Expected sequence

Step

Direction

Message

Comments

1

SS->MS

see comments

PD = "radio resources management messages" Skip indicator = "0000" Message type = "0010 0101" rest of the message is H’02 H’E0 H’90

2

MS->SS

RR STATUS

RR cause IE indicates RR cause value #97.

3

SS

During 5 s the SS verifies that the MS does not send a L3 message on the main signalling link but still continues to send L2 fill frames on the main signalling link.

4

SS->MS

SETUP

If the MS supports at least one BC (p = Y), the SETUP specifies a bearer capability supported by the MS. Otherwise (p = N) the SETUP message specifies any bearer capability.

A5

MS->SS

CALL CONFIRMED

This message shall be sent by the MS if p = Y.

B5

MS->SS

RELEASE COMPLETE

This message shall be sent by the MS if p = N.

6

SS->MS

CHANNEL RELEASE

The SS waits for disconnection of the main signalling link.

Specific message contents

None.

26.5.3.4 Undefined or unexpected message type / unexpected message type / CC

26.5.3.4.1 Conformance requirements

If the Mobile Station receives a message not consistent with the protocol state, the Mobile Station shall ignore the message except for the fact that, if an RR-connection exists, it returns a status message (STATUS, RR STATUS or MM STATUS depending on the protocol discriminator) with cause value #98 "Message type not compatible with protocol state".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.4.

26.5.3.4.2 Test purpose

To verify that a MS supporting the call control protocol for at least one BC, having a call in CC-state U10, "active", on receipt of an inopportune CC message, returns a STATUS message with reject cause value #98 without changing the state of the active call (this is verified by use of the status enquiry procedure.) This is tested in the special case where the inopportune CC message is a CALL PROCEEDING message relating to the active call.

26.5.3.4.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has a call in CC-state U10, "active".

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS has a call in CC-state U10, "active".

Test Procedure

The SS sends a CALL PROCEEDING message to the MS. The SS then checks that the MS responds with a STATUS message specifying reject cause value #98. The SS then sends a STATUS ENQUIRY message to the MS and verifies that the MS responds with a STATUS message specifying cause #30 and call state U10, "active".

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

CALL PROCEEDING

2

MS -> SS

STATUS

Cause IE indicates cause value #98.

3

SS -> MS

STATUS ENQUIRY

4

MS -> SS

STATUS

TI refers to the active call; Cause IE indicates cause value #30. Call state IE indicates state U10

Specific message contents

None.

26.5.4 Handling of unknown, unforeseen, and erroneous protocol data, and of parallel transactions / unforeseen information elements in the non-imperative message part

26.5.4.1 Unforeseen information elements in the non-imperative message part / duplicated information elements

26.5.4.1.1 Conformance requirements

If an information element with format T, TV, or TLV is repeated in a message in which repetition of the information element is not specified, only the contents of the information element appearing first shall be handled and all subsequent repetitions of the information element shall be ignored.

References

3GPP TS 04.08 / 3GPP TS 24.008 / 3GPP TS 44.018, subclause 8.6.3.

26.5.4.1.2 Test purpose

To verify that the MS ignores an unforeseen second occurrence of an information element with format T, TV, or TLV in the special case of the mobile identity IE which has format TLV in the LOCATION UPDATING ACCEPT message.

26.5.4.1.3 Method of test

Initial conditions

System Simulator:

2 cells A and B belonging to different location areas, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" and in RR-idle mode, listening to the BCCH/CCCH of cell A. It has a valid TMSI.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode, listening to the BCCH/CCCH of cell B. It does not have a valid TMSI.

Test Procedure

The RF level of cell A is lowered until the MS selects cell B (according to the cell-reselection procedures of 3GPP TS 05.08). The MS shall establish an RR connection and initiate the normal location updating procedure (using TMSI). The SS responds to the location update request with the LOCATION UPDATING ACCEPT message containing the mobile identity IE specifying the IMSI of the MS followed by an additional mobile identity IE specifying the TMSI that was assigned to the MS in the initial conditions (i.e. duplication of information element).

The SS then pages the MS using the PAGING REQUEST TYPE 1 message including the TMSI which was previously used in the LOCATION UPDATE ACCEPT message. The SS then verifies during 5 s that the MS does not answer to paging. The SS then pages the MS with its IMSI. The SS verifies that the MS responds on cell B by initiating the immediate assignment procedure using the CHANNEL REQUEST message.

Maximum duration of test

20 s.

Expected sequence

During 3 s the SS verifies that the MS does not send any message on the RACH.

Step

Direction

Message

Comments

1

SS

The RF level of cell A is lowered until the MS selects cell B.

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

LOCATION UPDATING REQUEST

Mobile identity IE specifies the TMSI of the MS.

5

SS -> MS

LOCATION UPDATING ACCEPT

(see below)

6

SS -> MS

CHANNEL RELEASE

7

SS

The SS waits at least 5 s to give the MS time to become pageable

8

SS -> MS

PAGING REQUEST TYPE 1

Mobile identity 1 IE specifies the TMSI of the MS. Mobile identity 2 is omitted.

9

SS

The SS waits at least 5 s During that period the SS verifies that the MS does not send any message on the RACH.

10

SS -> MS

PAGING REQUEST TYPE 1

Mobile identity 1 IE specifies the IMSI of the MS. Mobile identity 2 is omitted.

11

MS -> SS

CHANNEL REQUEST

Establishment cause = answer to paging.

12

SS -> MS

IMMEDIATE ASSIGNMENT REJECT

Specific message contents

LOCATION UPDATING ACCEPT

Information element

value/remark

location area identification

LAI of cell B

Mobile identity

coded TLV, specifies the IMSI of the MS

Type of identity

IMSI

Odd/even indication

corresponding to IMSI

Identity digit 1 etc.

corresponding to IMSI

Mobile identity (duplication)

coded TLV

Type of identity

TMSI of the MS

Odd/even indication

corresponding to TMSI

Identity digit 1 etc.

corresponding to TMSI

26.5.5 Handling of unknown, unforeseen, and erroneous protocol data, and of parallel transactions / non-semantical mandatory IE errors

26.5.5.1 Non-semantical mandatory IE errors / RR

26.5.5.1.1 Non-semantical mandatory IE errors / RR / missing mandatory IE error

26.5.5.1.1.1 Non-semantical mandatory IE errors / RR / missing mandatory IE error / special case

The MS shall accept a CHANNEL RELEASE message whether it contains an RR cause or not. This allows for the shortening of the message in the future.

26.5.5.1.1.1.1 Conformance requirements

When on receipt of a message a "missing mandatory IE" error is diagnosed the MS shall proceed as follows: If the message is a CHANNEL RELEASE message, the actions taken shall be the same as specified for a normal RR-connection release.

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.5.

26.5.5.1.1.1.2 Test purpose

To verify that the MS in RR connected mode releases the connection upon receipt of a CHANNEL RELEASE message with missing RR cause (which is "mandatory" in that message).

26.5.5.1.1.1.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" and in RR-idle mode. It has a valid TMSI.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode. It has a valid TMSI.

Test Procedure

A mobile terminating RR connection is established. Then the SS sends a CHANNEL RELEASE message in which the RR cause IE is missing. It is verified that the MS releases the main signalling link by sending a L2 DISC frame. The main signalling link release is then completed.

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

PAGING RESPONSE

5

SS -> MS

CHANNEL RELEASE

The mandatory RR cause IE is missing (the message consists only of protocol discriminator, skip indicator, and message type).

6

MS -> SS

The main signalling link is released (this is observed by a L2 DISC frame sent from the MS to the SS).

Specific message contents

None.

26.5.5.1.1.2 Non-semantical mandatory IE errors / RR / missing mandatory IE error / general case

In the general case, the MS has to report an RR message with missing mandatory IE by the use of an RR STATUS message, but otherwise to ignore it. This is a recovery mechanism for unforeseen states.

26.5.5.1.1.2.1 Conformance requirements

When on receipt of a message a "missing mandatory IE" error is diagnosed the MS shall proceed as follows: If the message is not one of the messages listed in subclauses 8.5.1, 8.5.2, and 8.5.3 of 3GPP TS 04.08 / 3GPP TS 24.008, the Mobile Station shall ignore the message except for the fact that, if an RR-connection exists, it returns a status message (STATUS, RR STATUS or MM STATUS depending on the protocol discriminator) with cause value #96 "invalid mandatory information".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.5.

26.5.5.1.1.2.2 Test purpose

To verify that the MS in RR connected mode ignores a ciphering mode command message in which the ciphering mode setting IE and cipher response IE are missing except for the fact that it returns a RR STATUS message.

26.5.5.1.1.2.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" and in RR-idle mode. It has a valid TMSI.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in RR-connected mode.

Test Procedure

A mobile terminating RR connection is established. Then the SS sends a ciphering mode command message in which the ciphering mode setting IE and cipher response IE are messing. The SS verifies that the MS does not start ciphering and returns a RR STATUS message.

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

PAGING RESPONSE

5

SS -> MS

CIPHERING MODE COMMAND

The mandatory ciphering mode setting IE and cipher response IE are missing.

6

MS -> SS

RR STATUS

RR cause IE specifies RR cause value #96.

Specific message contents

None.

26.5.5.1.2 Non-semantical mandatory IE errors / RR / comprehension required

26.5.5.1.2.1 Conformance requirements

When an RR message containing an IE unknown in the message, but encoded as "comprehension required" (see subclause 10.5 of 3GPP TS 04.08 / 3GPP TS 24.008) is received, the MS shall proceed as follows: When the message is not one of the messages listed in 3GPP TS 04.08 subclauses 8.5.1, 8.5.2 and 8.5.3, the Mobile Station shall ignore the message except for the fact that, if an RR-connection exists, it returns a RR STATUS message with cause value #96 "invalid mandatory information".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.5.

26.5.5.1.2.2 Test purpose

To verify that the MS having an RR-connection established ignores a HANDOVER COMMAND message containing in the non-imperative part an IE encoded as comprehension required except for the fact that it returns a RR STATUS message with cause # 96 "invalid mandatory information".

26.5.5.1.2.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has an MT call in state U10, "active"; or alternatively, the MS has been paged and an RR-connection has been established.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

As in the initial conditions.

Test Procedure

The SS sends a HANDOVER command message containing in the non-imperative part an IE encoded as comprehension required. The SS verifies that the MS returns a RR STATUS message with cause value #96 without changing the dedicated channel.

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

HANDOVER COMMAND

See below.

2

MS -> SS

RR STATUS

Sent on the old channel. RR cause IE specifies RR cause value #96.

Specific message contents

HANDOVER COMMAND

Information element

value/remark

cell description

as required

channel description

as required

handover reference

as required

power command

as required

comprehension required IEI

0000 0000

length

0000 0001

unrecognized IE contents

xxxx xxxx

26.5.5.2 Non-semantical mandatory IE errors / MM

The MS shall ignore MM messages with syntactically incorrect mandatory IE. This allows to use reserved values in later phases.

26.5.5.2.1 Non-semantical mandatory IE errors / MM / syntactically incorrect mandatory IE

26.5.5.2.1.1 Conformance requirements

When an MM message containing a syntactically incorrect mandatory IE is received, the Mobile Station shall ignore the message except for the fact that, if an RR-connection exists, it returns a MM STATUS message with cause value #96 "invalid mandatory information".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.5.

26.5.5.2.1.2 Test purpose

To verify that an MS supporting at least one BC, having a CC entity in state U10, "active", ignores an MM message with syntactically incorrect IE except for the fact that it sends an MM STATUS message with reject cause #96. This is tested in the special case of an IDENTITY REQUEST message in which the (mandatory) identity type IE specifies a reserved value for the type of identity; that the MS otherwise ignores the message is checked by means of the status enquiry procedure.

26.5.5.2.1.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has a mobile terminating call in the CC-state U10, "active".

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS has a mobile terminating call in the CC-state U10, "active".

Test Procedure

The SS sends an IDENTITY REQUEST message in which the (mandatory) identity type IE specifies a reserved value for the type of identity. The SS verifies that the MS returns an MM STATUS message specifying cause value #96 but does not change its state (this is verified by use of the status enquiry procedure).

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

IDENTITY REQUEST

The identity type IE is encoded as "1111" (so that the type of identity contains the reserved value "111").

2

MS -> SS

MM STATUS

Reject cause IE indicates reject cause value #96.

3

SS -> MS

STATUS ENQUIRY

TI refers to the active call.

4

MS -> SS

STATUS

TI refers to the active call; Cause IE indicates cause value #30. Call state IE indicates state U10.

Specific message contents

None.

26.5.5.2.2 Non-semantical mandatory IE errors / MM / syntactically incorrect mandatory IE

26.5.5.2.2.1 Conformance requirement(s)

When an MM message containing a syntactically incorrect mandatory IE is received, the Mobile Station shall ignore the message except for the fact that, if an RR-connection exists, it returns an MM STATUS message with cause value #96 "invalid mandatory information".

Reference(s)

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.5.

26.5.5.2.2.2 Test purpose

To verify that an MS having been paged and having an RR connection established ignores an MM message with syntactically incorrect IE except for the fact that it sends an MM STATUS message with reject cause #96. This is tested in the special case of an IDENTITY REQUEST message in which the (mandatory) identity type IE specifies a reserved value for the type of identity; the fact that the MS otherwise ignores the message is checked by testing that it answers as usual to an incoming SETUP message.

26.5.5.2.2.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has been paged; an RR connection has been established.

The MS has a valid TMSI.

Specific PICS statements:

PIXIT Statements:

Foreseen final state of the MS

The MS is in the MM-state "idle updated" listening to the BCCH/CCCH of the cell. It has a valid TMSI.

Test Procedure

The SS sends an IDENTITY REQUEST message in which the (mandatory) identity type IE specifies a reserved value for the type of identity. The SS verifies that the MS returns an MM STATUS message specifying cause value #96 but does not change its state; this is verified as follows:

The SS sends a SETUP message to the MS. This message specifies a BC that is supported by the MS, if there exists any; if the MS does not support any BC, the SETUP message specifies an arbitrary BC. The SS then verifies that the MS responds with a CALL CONFIRMED message if the SETUP had specified a BC supported by the MS, and that the MS responds with a RELEASE COMPLETE message otherwise.

Then the SS sends a CHANNEL RELEASE to the MS and waits for the disconnection of the main signalling link.

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

IDENTITY REQUEST

The identity type IE is encoded as "1111" (so that the type of identity contains the reserved value "111").

2

MS -> SS

MM STATUS

Reject cause IE indicates reject cause value #96.

3

SS -> MS

SETUP

If the MS supports at least one BC (p = Y), the SETUP specifies a bearer capability supported by the MS. Otherwise (p = N) the SETUP message specifies any bearer capability.

A4

MS -> SS

CALL CONFIRMED

This message shall be sent by the MS if p = Y.

B4

MS -> SS

RELEASE COMPLETE

This message shall be sent by the MS if p = N.

5

SS -> MS

CHANNEL RELEASE

The SS waits for disconnection of the main signalling link.

Specific message contents

None.

26.5.5.2.3 Non-semantical mandatory IE errors / MM / comprehension required

The "comprehension required" mechanism allows for the introduction of essential new information elements into messages, such that a message is ignored and a report is sent if the new information element is not understood.

26.5.5.2.3.1 Conformance requirements

When an MM message containing an IE unknown in the message, but encoded as "comprehension required" (see subclause 10.5 of 3GPP TS 04.08 / 3GPP TS 24.008) is received, the MS shall ignore the message except for the fact that, if an RR-connection exists, it returns an MM STATUS message with cause value #96 "invalid mandatory information".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.5.

26.5.5.2.3.2 Test purpose

To verify that the MS on receipt of an MM message containing an IE unknown in the message, but encoded as "comprehension required" ignores the message except for the fact that it returns an MM STATUS message with cause value #96 "invalid mandatory information"; this in the special case of the MM message being a LOCATION UPDATING ACCEPT responding to a LOCATION UPDATING REQUEST from the MS.

26.5.5.2.3.3 Method of test

Initial conditions

System Simulator:

The SS simulates two cells, A and B, belonging to different location areas, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" listening to the BCCH/CCCH of cell A. It has a valid TMSI.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" listening to the BCCH/CCCH of cell B. It has a valid TMSI.

Test Procedure

The Rf level of cell A is lowered until the MS selects cell B. The SS verifies that the MS establishes an RR connection and performs the normal location updating procedure using its TMSI. The SS responds to the location updating request with the LOCATION UPDATING ACCEPT message containing an optional information element coded as "comprehension required". The SS verifies that the MS returns the MM STATUS message with cause #96 in response to the LOCATION UPDATING ACCEPT. The SS then waits for the MS to abort the RR-connection. The SS verifies that the MS establishes a new RR connection and starts a new location updating procedure.

On receipt of the new LOCATION UPDATING REQUEST, the SS sends a correctly coded LOCATION UPDATING ACCEPT allocating a new TMSI.

The SS verifies that the MS sends a TMSI REALLOCATION COMPLETE message. The SS then initiates the RR connection release.

Maximum duration of test

30 s.

Expected sequence

Step

Direction

Message

Comments

1

SS

The RF level of cell A is lowered until the MS selects cell B.

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

LOCATION UPDATING REQUEST

The mobile identity IE specifies the TMSI of the MS.

5

SS -> MS

LOCATION UPDATING ACCEPT

See below.

6

MS -> SS

MM STATUS

Reject cause IE specifies reject cause value #96.

7

MS

The MS aborts the RR connection (it initiates release of L2 on SAPI 0) using the L2 DISC / UA exchange.

8

MS -> SS

CHANNEL REQUEST

9

SS -> MS

IMMEDIATE ASSIGNMENT

10

MS -> SS

LOCATION UPDATING REQUEST

The mobile identity IE specifies the IMSI of the MS.

11

SS -> MS

LOCATION UPDATING ACCEPT

see below

12

MS -> SS

TMSI REALLOCATION COMPLETE

13

SS -> MS

CHANNEL RELEASE

The RR connection is released.

Specific message contents

LOCATION UPDATING ACCEPT – first occurrence

Information element

value/remark

Location area identification

LAI of cell B

Comprehension required IEI

0000 0000

length

1

unrecognized IE contents

xxxx xxxx (arbitrary octet)

LOCATION UPDATING ACCEPT – second occurrence

Information element

value/remark

Location area identification

specifies LAI of cell B

Mobile Identity

specifies a TMSI

26.5.5.3 Non-semantical mandatory IE errors / CC

26.5.5.3.1 Non-semantical mandatory IE errors / CC / missing mandatory IE

26.5.5.3.1.1 Non-semantical mandatory IE errors / CC / missing mandatory IE / disconnect message

26.5.5.3.1.1.1 Conformance requirements

When on receipt of a message a "missing mandatory IE" error is diagnosed, the MS shall proceed as follows: If the message is a DISCONNECT message, a RELEASE message shall be returned with cause value # 96 "invalid mandatory information" and normal call clearing applies.

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.5.

26.5.5.3.1.1.2 Test purpose

To verify that the MS having an MT call in state U10, "active", on receipt of a DISCONNECT message in which the mandatory cause IE is missing shall return a RELEASE message with cause value #96 "invalid mandatory information".

26.5.5.3.1.1.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has an MT call in the CC-state U10, "active".

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Test Procedure

The SS sends a DISCONNECT message in which the (mandatory) cause IE is missing. The SS verifies that the MS returns a RELEASE message specifying cause value #96. The SS then sends a RELEASE COMPLETE message and performs the RR connection release.

Maximum duration of test

15 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

DISCONNECT

The mandatory cause IE is missing.

2

MS -> SS

RELEASE

The cause IE indicates cause value #96

3

SS -> MS

RELEASE COMPLETE

4

SS -> MS

CHANNEL RELEASE

The RR connection is released.

Specific message contents

None.

26.5.5.3.1.2 Non-semantical mandatory IE errors / CC / missing mandatory IE / general case

26.5.5.3.1.2.1 Conformance requirements

When on receipt of a message a "missing mandatory IE" error is diagnosed, the MS shall proceed as follows: If the message is not a SETUP, RELEASE, DISCONNECT, RELEASE COMPLETE, HOLD REJECT or RETRIEVE REJECT message, it shall ignore the message except for the fact that it returns a STATUS message specifying cause value #96.

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.5.

26.5.5.3.1.2.2 Test purpose

To verify that the MS having an MT call in state U10, "active", on receipt of a STATUS message in which the mandatory cause IE and call state IE are missing shall ignore the message except for the fact that it return a STATUS message with cause value #96 "invalid mandatory information" (that the MS does not change state is checked by use of the status enquiry procedure).

26.5.5.3.1.2.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has an MT call in the CC-state U10, "active".

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS has an MT call in the CC-state U10, "active".

Test Procedure

The SS sends a STATUS message in which the mandatory cause IE and call state IE are missing. The SS verifies that the MS returns a STATUS message with cause value #96 "invalid mandatory information". Then the SS sends a STATUS ENQUIRY message and checks that the MS returns a STATUS message indicating cause value #30 and call state U10, "active".

Maximum duration of test

15 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

STATUS

The mandatory cause IE and call state IE are missing.

2

MS -> SS

STATUS

The cause IE indicates cause value #96

3

SS -> MS

STATUS ENQUIRY

TI refers to the active call.

4

MS -> SS

STATUS

TI refers to the active call; Cause IE indicates cause value #30. Call state IE indicates state U10

Specific message contents

None.

26.5.5.3.2 Non-semantical mandatory IE errors / CC / comprehension required

26.5.5.3.2.1 Conformance requirements

When a CC message containing an IE unknown in the message, but encoded as "comprehension required" (see 3GPP TS 04.08 / 3GPP TS 24.008, subclause 10.5) is received, the MS shall proceed as follows: When the message is not one of the messages listed in 3GPP TS 04.08 / 3GPP TS 24.008 subclauses 8.5.1, 8.5.2 and 8.5.3, the Mobile Station shall ignore the message except for the fact that, if an RR-connection exists, it returns a STATUS message with cause value #96 "invalid mandatory information".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclauses 8.5 and 10.5.

26.5.5.3.2.2 Test purpose

To verify that an MS supporting the call control protocol for at least one BC having a call control entity in state U3 ignores a CONNECT message containing in the non-imperative part an IE encoded as comprehension required except for the fact that it returns a STATUS message with cause value #96 "invalid mandatory information".

26.5.5.3.2.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has a call control entity in CC state U3.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS has a call control entity in CC state U3.

Test Procedure

The SS sends a CONNECT message containing an optional information element coded as "comprehension required". The SS verifies that the MS returns a STATUS message specifying cause value #96 "invalid mandatory information". The SS checks by use of the status enquiry procedure that the MS did not change the state.

Maximum duration of test

5 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

CONNECT

See below.

2

MS -> SS

STATUS

TI refers to the call in progress; cause IE indicates cause value #96.

3

SS -> MS

STATUS ENQUIRY

TI refers to the call in progress.

4

MS -> SS

STATUS

TI refers to the call in progress; Cause IE indicates cause value #30. Call state IE indicates state U3.

Specific message contents

CONNECT

Information element

value/remark

Unknown IEI

0000 0000

length

1

unknown IE contents

xxxx xxxx (arbitrary octet)

26.5.6 Handling of unknown, unforeseen, and erroneous protocol data, and of parallel transactions / unknown IE, comprehension not required

26.5.6.1 Unknown information elements in the non-imperative message part / MM

26.5.6.1.1 Unknown IE, comprehension not required / MM / IE unknown in the protocol

26.5.6.1.1.1 Conformance requirements

The MS shall ignore all IEs unknown in a message which are not encoded as "comprehension required".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclauses 8.6.1, 8.6.2 and 10.5.

26.5.6.1.1.2 Test purpose

To verify that the MS on receipt of an MM message containing an IE unknown in the message and unknown in the MM protocol which is not encoded as "comprehension required" ignores that IE; this in the special case of the MM message being a LOCATION UPDATING ACCEPT responding to a LOCATION UPDATING REQUEST from the MS.

26.5.6.1.1.3 Method of test

Initial conditions

System Simulator:

The SS simulates two cells, A and B, belonging to different location areas, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" listening to the BCCH/CCCH of cell B. It has a valid TMSI.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" listening to the BCCH/CCCH of cell A. It has a valid TMSI.

Test Procedure

The RF level of cell B is lowered until the MS selects cell A. The SS verifies that the MS establishes an RR connection and performs the normal location updating procedure using its TMSI. The SS responds to the location updating request with the LOCATION UPDATING ACCEPT message containing an optional information element not coded as "comprehension required" the IE of which is unknown in the MM protocol. The LOCATION UPDATING ACCEPT message contains a new TMSI in the mobile identity IE which is placed after the unknown IE. The MS shall send the TMSI REALLOCATION COMPLETE message.

Maximum duration of test

20 s.

Expected sequence

Step

Direction

Message

Comments

1

SS

The RF level of cell B is lowered until the MS selects cell A.

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

LOCATION UPDATING REQUEST

The mobile identity IE specifies the TMSI of the MS.

5

SS -> MS

LOCATION UPDATING ACCEPT

See below.

6

MS -> SS

TMSI REALLOCATION COMPLETE

7

SS -> MS

CHANNEL RELEASE

The main signalling link is released.

Specific message contents

LOCATION UPDATING ACCEPT

Information element

value/remark

Location area identification

LAI of cell A

Unknown IEI

1010 xxx0 (where x is arbitrary)

Mobile Identity IEI

length

5

Type of identity

TMSI

Identity

4 octets of "new" TMSI

26.5.6.1.2 Unknown IE, comprehension not required / MM / IE unknown in the message

26.5.6.1.2.1 Conformance requirements

The MS shall ignore all IEs unknown in a message which are not encoded as "comprehension required".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclauses 8.6.1, 8.6.2 and 10.5.

26.5.6.1.2.2 Test purpose

To verify that the MS on receipt of an MM message containing an IE unknown in the message, but known in the MM protocol, which is not encoded as "comprehension required" ignores that IE; this in the special case of the MM message being a LOCATION UPDATING ACCEPT responding to a LOCATION UPDATING REQUEST from the MS.

26.5.6.1.2.3 Method of test

Initial conditions

System Simulator:

The SS simulates two cells, A and B, belonging to different location areas, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" listening to the BCCH/CCCH of cell B. It has a valid TMSI.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" listening to the BCCH/CCCH of cell A. It has a valid TMSI.

Test Procedure

The RF level of cell B is lowered until the MS selects cell A. The SS verifies that the MS establishes an RR connection and performs the normal location updating procedure using its TMSI. The SS responds to the location updating request with the LOCATION UPDATING ACCEPT message containing an optional information element not coded as "comprehension required" the IEI of which is unknown in the message but is used as the location area identification IEI in other messages of the MM protocol. The LOCATION UPDATING ACCEPT message contains a new TMSI in the mobile identity IE which is placed after the unknown IE. The MS shall send the TMSI REALLOCATION COMPLETE message.

Maximum duration of test

20 s.

Expected sequence

Step

Direction

Message

Comments

1

SS

The RF level of cell B is lowered until the MS selects cell A.

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

LOCATION UPDATING REQUEST

The mobile identity IE specifies the TMSI of the MS.

5

SS -> MS

LOCATION UPDATING ACCEPT

See below.

6

MS -> SS

TMSI REALLOCATION COMPLETE

7

SS -> MS

CHANNEL RELEASE

The main signalling link is released.

Specific message contents

LOCATION UPDATING ACCEPT

Information element

value/remark

Location area identification

LAI of cell A

Unknown IEI

0001 0011

length

2

unknown IE contents

xxxx xxxx xxxx xxxx (2 arbitrary octets)

Mobile Identity IEI

length

5

Type of identity

TMSI

Identity

4 octets of "new" TMSI

26.5.6.2 Unknown information elements in the non-imperative message part / CC

26.5.6.2.1 Unknown information elements in the non-imperative message part / CC / Call establishment

26.5.6.2.1.1 Conformance requirements

The MS shall ignore all IEs unknown in a message which are not encoded as "comprehension required".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.6.1.

26.5.6.2.1.2 Test purpose

To verify that an MS supporting the CC protocol for at least one BC receiving a CC message containing an IE unknown in the message which is not encoded as "comprehension required" ignores that IE; this in the special case of the CC message being a CALL PROCEEDING message received by the MS in state U1.

26.5.6.2.1.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has a call control entity in CC state U1.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS has a call control entity in CC state U3.

Test Procedure

The SS sends a CALL PROCEEDING message containing an optional information element not coded as "comprehension required" the IEI of which is unknown in the message, but used for a called party BCD number IE in other messages of the protocol. The SS verifies by use of the status enquiry procedure that the MS did not change the state.

Maximum duration of test

30 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

CALL PROCEEDING

See below.

2

SS -> MS

STATUS ENQUIRY

TI refers to the call in progress.

3

MS -> SS

STATUS

TI refers to the active call; Cause IE indicates cause value #30. Call state IE indicates state U3.

Specific message contents

CALL PROCEEDING

Information element

value/remark

Unknown IEI

0101 1110

length

1

unknown IE contents

xxxx xxxx (arbitrary octet)

26.5.6.2.2 Unknown information elements in the non-imperative message part / CC / disconnect

26.5.6.2.2.1 Conformance requirements

The MS shall ignore all IEs unknown in a message which are not encoded as "comprehension required".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.6.1.

26.5.6.2.2.2 Test purpose

To verify that an MS supporting the CC protocol for at least one BC receiving a CC message containing an IE unknown in the message which is not encoded as "comprehension required" ignores that IE; this in the special case of a DISCONNECT message received by the MS in state U10.

26.5.6.2.2.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has a call control entity in CC state U10.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS has a call control entity in CC state U19.

Test Procedure

The SS sends a DISCONNECT message containing an optional information element not coded as "comprehension required" the IEI of which is unknown in the message, but used for a connected number IE in other messages of the protocol. The SS verifies that the MS responds with a RELEASE message; the SS verifies by use of the status enquiry procedure that the MS has entered state U19.

Maximum duration of test

5 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

DISCONNECT

See below.

2

MS -> SS

RELEASE

3

SS -> MS

STATUS ENQUIRY

4

MS -> SS

STATUS

Cause IE indicates cause value #30. Call state IE indicates state U19.

Specific message contents

DISCONNECT

Information element

value/remark

Unknown IEI

0100 1100

length

1

unknown IE contents

xxxx xxxx (arbitrary octet)

26.5.6.2.3 Unknown information elements in the non-imperative message part / CC / release

26.5.6.2.3.1 Conformance requirements

The MS shall ignore all IEs unknown in a message which are not encoded as "comprehension required".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.6.1.

26.5.6.2.3.2 Test purpose

To verify that an MS supporting the CC protocol for at least one BC receiving a CC message containing an IE unknown in the message which is not encoded as "comprehension required" ignores that IE; this in the special case of a RELEASE message received by the MS having sent in state U10 a DISCONNECT message.

26.5.6.2.3.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has a call control entity in CC state U10.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Test Procedure

The MS is made to send a DISCONNECT message. The SS responds with a RELEASE message containing an optional information element not coded as "comprehension required" the IEI of which is unknown in the message, but used for a high layer compatibility IE in other messages of the protocol. The SS verifies that the MS responds with a RELEASE COMPLETE message; the SS then releases the RR connection.

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

MS

The MS is made to initiate call clearing.

2

MS -> SS

DISCONNECT

3

SS -> MS

RELEASE

See below.

4

MS -> SS

RELEASE COMPLETE

5

SS -> MS

CHANNEL RELEASE

The RR connection is released.

Specific message contents

RELEASE

Information element

value/remark

Unknown IEI

0111 1101

length

1

unknown IE contents

1 arbitrary octet

26.5.6.2.4 Unknown information elements in the non-imperative message part / CC / release complete

26.5.6.2.4.1 Conformance requirements

The MS shall ignore all IEs unknown in a message which are not encoded as "comprehension required".

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 8.6.1.

26.5.6.2.4.2 Test purpose

To verify that an MS supporting the CC protocol for at least one BC receiving a CC message containing an IE unknown in the message which is not encoded as "comprehension required" ignores that IE; this in the special case of a RELEASE COMPLETE message received by the MS in state U19.

26.5.6.2.4.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS has a call control entity in CC state U10.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Test Procedure

The SS sends a DISCONNECT message. The SS verifies that the MS responds with a RELEASE message. The SS answers with a RELEASE COMPLETE message containing an optional information element not coded as "comprehension required" the IEI of which is unknown in the message, but used for an auxiliary states IE in other messages of the protocol. The SS verifies that the MS releases the link after some time.

Maximum duration of test

20 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

DISCONNECT

2

MS -> SS

RELEASE

3

SS -> MS

RELEASE COMPLETE

See below.

4

MS

The MS aborts the RR connection (it initiates release of L2 on SAPI 0)

Specific message contents

RELEASE COMPLETE

Information element

value/remark

Unknown IEI

0010 0100

length

1

unknown IE contents

1 arbitrary octet

26.5.6.3 Unknown IE in the non-imperative message part, comprehension not required / RR

26.5.6.3.1 Conformance requirements

The MS shall ignore all IEs unknown in a message which are not encoded as "comprehension required".

References

3GPP TS 04.08 / 3GPP TS 44.018, subclauses 8.6.1, 8.6.2 and 10.5.

26.5.6.3.2 Test purpose

To verify that the MS ignores an IE which is unknown in a message for Radio Resource Management in the special cases of CIPHERING MODE COMMAND, ASSIGNMENT COMMAND and CHANNEL RELEASE.

26.5.6.3.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" and in the RR-idle mode. It has a valid TMSI.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in the RR-idle mode. It has a valid TMSI.

Test Procedure

In the normal call establishment the CIPHERING MODE COMMAND and ASSIGNMENT COMMAND contain additional IEs unknown in the message which are not encoded as "comprehension required", and therefore should be ignored by the MS. After sending an ASSIGNMENT COMPLETE, the subsequent CHANNEL RELEASE received by the MS also contains an IE unknown in a message which is not encoded as "comprehension required". The MS should ignore this IE.

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

PAGING RESPONSE

5

SS -> MS

CIPHERING MODE COMMAND

See specific message contents

6

MS -> SS

CIPHERING MODE COMPLETE

7

SS -> MS

ASSIGNMENT COMMAND

See specific message contents

8

MS -> SS

ASSIGNMENT COMPLETE

On the dedicated channel

9

SS -> MS

CHANNEL RELEASE

See specific message contents

10

SS

The SS checks the release of the main signalling link at layer 2 level.

Specific message contents

None.

Step 5: CIPHERING MODE COMMAND

Cipher mode setting

– algorithm identifier

cipher with A5/1

– SC

start ciphering

Cipher Response

IMEI shall not be included

Unknown IE (type 2)

1001 0010

Step 7: ASSIGNMENT COMMAND

Channel Description

Channel Type

TCH/F + ACCHs

Timeslot number

arbitrarily selected, but not zero

Training sequence code

arbitrarily selected

Hopping

RF hopping channel

MAIO

0

HSN

0

Power Command

arbitrarily selected

First Unknown IE (Type 2)

1101 1010

Cell Channel Description

For GSM 450 mobiles, range 128 encodes ARFCNs 267 and 275.

For GSM 480 mobiles, range 128 encodes ARFCNs 315 and 322.

For GSM 710 mobiles, range 128 encodes ARFCNs 470 and 490.

For GSM 750 mobiles, range 128 encodes ARFCNs 470 and 490.

For T-GSM 810 mobiles, range 128 encodes ARFCNs 470 and 490.

For GSM 850 mobiles, range 128 encodes ARFCNs 160 and 180.

For PGSM and EGSM mobiles, bit map 0 encodes ARFCNs 30 and 50.

For DCS 1 800 and PCS 1 900 mobiles, the variable bit map format encodes ARFCNs 650 and 750.

Second Unknown IE (Type 4)

– IEI

0110 1001

– length

2

– contents

xxxx xxxx xxxx xxxx, where x is arbitrarily coded.

Mobile Allocation

For GSM450 mobiles, indicates ARFCN 275 only.

For GSM 480 mobiles, indicates ARFCN 322 only.

For GSM 710 mobiles, indicates ARFCN 490 only.

For GSM 750 mobiles, indicates ARFCN 490 only.

For T-GSM 810 mobiles, indicates ARFCN 490 only.

For GSM 850 mobiles, indicates ARFCN 180 only.

For PGSM and EGSM mobiles, indicates ARFCN 50, only.

For DCS 1 800 and PCS 1 900 mobiles, indicates ARFCN 750, only.

Step 9: CHANNEL RELEASE

RR Cause

normal event

Unknown IE (type 4)

– IEI

0111 0010

– length

5

– contents

xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx, where x is arbitrarily coded.

26.5.7 Handling of unknown, unforeseen, and erroneous protocol data, and of parallel transactions / spare bits

26.5.7.1 Spare bits / RR

26.5.7.1.1 Spare bits / RR / paging channel

26.5.7.1.1.1 Conformance requirements

The MS shall ignore the value of spare bits.

References

3GPP TS 04.08 / 3GPP TS 44.018, subclause 10.5.

26.5.7.1.1.2 Test purpose

To verify that the MS in the MM-state "idle, updated" and in RR-idle mode ignores the value of spare bits in the special case of the spare bits occurring in the P1 Rest Octets IE of a PAGING REQUEST TYPE 1 message. That the spare bits are ignored is checked by addressing the MS in that PAGING REQUEST message and verifying that the MS responds to that paging.

26.5.7.1.1.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Test Procedure

The SS sends a PAGING REQUEST TYPE 1 message containing at least one octet in the P1 rest octets IE that is different from 0010 1011.

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

See below.

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT REJECT

Specific message contents

PAGING REQUEST TYPE 1

Information element

Value/remark

L2 pseudo length

k+3 where k is the sum of the length of the mobile identity 1 IE

Page Mode

Normal paging

Channels needed for Mobiles 1 and 2

Channel (first)

Any channel

Channel (second)

(spare)

Mobile identity 1

IMSI or TMSI of MS under test

Mobile identity 2

Omitted

P1 rest octets

not all octets are "0010 1011"

26.5.7.1.2 Spare bits / RR / BCCH

26.5.7.1.2.1 Conformance requirements

The MS shall ignore the value of spare bits.

References

3GPP TS 04.08 / 3GPP TS 44.018, subclause 10.5.

26.5.7.1.2.2 Test purpose

To verify that the MS in the MM-state "idle, updated" and in RR-idle mode ignores the value of spare bits in the special case where these spare bits are contained in the SI3 and SI4 messages. That the MS ignores the value of the spare bits is checked by changing the LAI in those message and observing the MS initiating a location update though the spare bits do not all have the default value.

26.5.7.1.2.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Test Procedure

The SS simulates a BCCH where continuously for at least 30 s at least one octet of the SI3 Rest Octets IE in all SYSTEM INFORMATION TYPE 3 messages and at least one octet of the SI4 Rest Octets IE in all SYSTEM INFORMATION TYPE 4 messages is different from 0010 1011 and the location area identification IE denotes a location area different from the current location area held by the MS. The SS verifies that the MS sends a CHANNEL REQUEST message on the RACH including the establishment cause "location updating". The SS responds with an IMMEDIATE ASSIGNMENT REJECT message.

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

The SS starts sending modified SYSTEM INFORMATION TYPE 3 and SYSTEM INFORMATION TYPE 4 messages (as defined below) continuously for at least 30 s on the BCCH.

2

MS -> SS

CHANNEL REQUEST

Establishment cause = "location updating (SDCCH needed). This message may be received during the 30 s.

3

SS -> MS

IMMEDIATE ASSIGNMENT REJECT

Specific message contents

SYSTEM INFORMATION TYPE 3

Information element

value/remark

L2 pseudo length

18

cell identity

as required

location area identification

denoting a new location area

control channel description

as required, but with the spare bits arbitrarily selected and at least one spare bit set to 1.

cell options

as required, but with (spare) bit 8 set to 1

cell selection parameters

as required

RACH control parameters

as required

SI3 rest octets

at least one octet is different from "0010 1011"

SYSTEM INFORMATION TYPE 4

Information element

value/remark

L2 pseudo length

12

location area identification

denoting a new location area

cell selection parameters

as required

RACH control parameters

as required

SI4 rest octets

at least one octet is different from "0010 1011"

26.5.7.1.3 Spare bits / RR / AGCH

26.5.7.1.3.1 Conformance requirements

The MS shall ignore the value of spare bits.

References

3GPP TS 04.08 / 3GPP TS 44.018, subclause 10.5.

26.5.7.1.3.2 Test purpose

To verify that the MS in the MM-state "idle, updated" and in RR-idle mode ignores the value of spare bits in the special case of the spare bits occurring in the Page Mode IE, the Spare Half Octet IE, the Channel Description IE, the Timing Advance IE, the IA Rest Octet IE, and in the IAR Rest Octet IE.

26.5.7.1.3.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Test Procedure

The SS sends an IMMEDIATE ASSIGNMENT message containing arbitrary spare bits in the Page Mode IE, in the Spare Half Octet IE, in the Channel Description IE, in the Timing Advance IE, and in the IA Rest Octet IE.

It is checked that the MS answers on the dedicated channel with a PAGING RESPONSE message and releases the main signalling link after a CHANNEL RELEASE message.

After a new paging of the MS an IMMEDIATE ASSIGNMENT REJECT is sent to test the spare bits in the IAR Rest Octet IE.

The MS is then paged again to check the idle state.

Maximum duration of test

20 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

Addressing the MS under test

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT

see below

4

MS -> SS

PAGING RESPONSE

5

SS -> MS

CHANNEL RELEASE

6

SS

The SS checks that the MS releases the main signalling link and waits 10 s for a cell reselection of the MS

7

SS -> MS

PAGING REQUEST TYPE 1

Addressing the MS under test

8

MS -> SS

CHANNEL REQUEST

9

SS -> MS

IMMEDIATE ASSIGNMENT REJECT

normal, waiting time = 0, except the IAR Rest Octet IE (see below)

10

SS

The SS waits six seconds

11

SS -> MS

PAGING REQUEST TYPE 1

Addressing the MS under test

12

MS -> SS

CHANNEL REQUEST

To check that the MS has reached the idle state after the IMMEDIATE ASSIGNMENT REJECT

Specific message contents

IMMEDIATE ASSIGNMENT

Information element

Value/remark

L2 pseudo length

sum of the length of all IE except L2 pseudo length and IA Rest Octets

Protocol Discriminator

RR

Skip Indicator

0000

Message Type

Immediate Assignment

Page mode

xx00 (where "xx" is arbitrary, with at least 1 bit set to 1)

Dedicated mode or TBF

x000 (where "x" is set to 1)

Channel description

normal, no hopping, the two spare bits before ARFCN are chosen arbitrarily with at least one bit set to 1.

Request reference

normal (derived from the CHANNEL REQUEST)

Timing advance

xx00 0000 (where "xx" is arbitrary, with at least 1 bit set to 1)

Mobile allocation

chosen so that, together with the channel description

Length

0

IA rest octets

first octet

00xx xxxx (where "xx xxxx" is arbitrary but different to 10 1011)

other octets

xxxx xxxx (where "xxxx xxxx" is arbitrary but different to 0010 1011)

IMMEDIATE ASSIGNMENT REJECT

Information element

Value/remark

L2 pseudo length

19

Page mode

normal

Spare half octet

xxxx (where "xxxx" is arbitrary, with at least 1 bit is set to 1)

Request reference 1

addressing the MS under test

Wait indication 1

0 s

Other Request References and Wait Indications arbitrary

IAR rest octets

Octet 1 to 3

xxxx xxxx (where "xxxx xxxx" is arbitrary but different to 0010 1011)

26.5.7.1.4 Spare bits / RR / Connected Mode

26.5.7.1.4.1 Conformance requirements

The MS shall ignore the value of spare bits.

References

3GPP TS 04.08 / 3GPP TS 44.018, subclause 10.5.

26.5.7.1.4.2 Test purpose

To verify that the MS in the MM-state "MM-Connection active" and in RR-Connected mode ignores the value of spare bits in the special case of the spare bits occurring in the Cell Channel Description IE and in the Power Command IE.

26.5.7.1.4.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters, except:

GSM 450 mobiles are assigned to ARFCN 293 in step 10.

GSM 480 mobiles are assigned to ARFCN 340 in step 10.

GSM 710, GSM 750 and T-GSM 810 mobiles are assigned to ARFCN 511 in step 10.

GSM 850 mobiles are assigned to ARFCN 251 in step 10.

PGSM and EGSM mobiles are assigned to ARFCN 124 in step 10.

DCS 1 800 and PCS 1 900 mobiles are assigned to ARFCN 801 in step 10.

Mobile Station:

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Test Procedure

In the procedure of a normal call establishment the ASSIGNMENT COMMAND will be modified to test the spare bits in the Cell Channel Description IE and in the Power Command IE.

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

Addressing the MS under test

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

PAGING RESPONSE

5

SS -> MS

CIPHERING MODE COMMAND

6

MS -> SS

CIPHERING MODE COMPLETE

7

SS -> MS

SETUP

8

MS -> SS

CALL CONFIRMED

A9

MS -> SS

ALERTING

B9

MS ->SS

CONNECT

10

SS -> MS

ASSIGNMENT COMMAND

see below

11

MS -> SS

ASSIGNMENT COMPLETE

on the dedicated channel

12

SS -> MS

CHANNEL RELEASE

13

SS

The SS checks that the MS release the main signalling link

Specific message contents

ASSIGNMENT COMMAND

For GSM 450 mobiles

Information element

Value/remark

Channel Description

normal, hopping HSN=63, MAIO=0

Power Command

xxx0 0111 (where "xxx" is arbitrary, with at least 1 bit set to 1)

Cell Channel Description

octet 2

10xx 110? (where "xx" is arbitrary, with at least 1 bit set to 1) Bit 1 of octet 2 and all of octets 3 to 17 (inclusive) indicate ARFCN 293 only (using the Range 128 format).

Mobile Allocation

indicates ARFCN 293 only

For GSM 480 mobiles

Information element

Value/remark

Channel Description

normal, hopping HSN=63, MAIO=0

Power Command

xxx0 0111 (where "xxx" is arbitrary, with at least 1 bit set to 1)

Cell Channel Description

octet 2

10xx 110? (where "xx" is arbitrary, with at least 1 bit set to 1) Bit 1 of octet 2 and all of octets 3 to 17 (inclusive) indicate ARFCN 340 only (using the Range 128 format).

Mobile Allocation

indicates ARFCN 340 only

For GSM 710 or GSM 750 or T-GSM 810 mobiles

Information element

Value/remark

Channel Description

normal, hopping HSN=63, MAIO=0

Power Command

xxx0 0111 (where "xxx" is arbitrary, with at least 1 bit set to 1)

Cell Channel Description

Octet 2

10xx 110? (where "xx" is arbitrary, with at least 1 bit set to 1) Bit 1 of octet 2 and all of octets 3 to 17 (inclusive) indicate ARFCN 511 only (using the Range 128 format).

Mobile Allocation

indicates ARFCN 511 only

For GSM 850 mobiles

Information element

Value/remark

Channel Description

normal, hopping HSN=63, MAIO=0

Power Command

xxx0 0111 (where "xxx" is arbitrary, with at least 1 bit set to 1)

Cell Channel Description

Octet 2

10xx 110? (where "xx" is arbitrary, with at least 1 bit set to 1) Bit 1 of octet 2 and all of octets 3 to 17 (inclusive) indicate ARFCN 251 only (using the Range 128 format).

Mobile Allocation

Indicates ARFCN 251 only

For PGSM and EGSM mobiles

Information element

Value/remark

Channel Description

normal, hopping HSN=63, MAIO=0

Power Command

xxx0 0111 (where "xxx" is arbitrary, with at least 1 bit set to 1)

Cell Channel Description

octet 2

00xx 1000 (where "xx" is arbitrary, with at least 1 bit set to 1)

octet 3 to 17 (inclusive)

all bits set to zero

Mobile Allocation

indicates ARFCN 124 only

For DCS 1 800 or PCS 1 900 mobiles

Information element

Value/remark

Channel Description

normal, hopping, HSN=63, MAIO=0

Power Command

xxx0 0111 (where "xxx" is arbitrary, with at least 1 bit set to 1)

Cell Channel Description

octet 2

10xx 111? (where "xx" is arbitrary, with at least 1 bit set to 1). Bit 1 of octet 2 and all of octets 3 to 17 (inclusive) indicate ARFCN 801 only (using the variable bit map format).

Mobile Allocation

indicates ARFCN 801 only

26.5.7.2 Spare bits / MM

26.5.7.2.1 Conformance requirements

The MS shall ignore the value of spare bits.

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 10.5.

26.5.7.2.2 Test purpose

To verify that the MS in the MM-state "wait net cmd" and in RR-Connected mode ignores the value of spare bits in the special case of the spare bits occurring in the Cipher Key Seq. Number IE or in the Identity Type IE.

26.5.7.2.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Specific PICS statements:

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Test Procedure

After the establishment of the RR-connection, in the AUTHENTICATION REQUEST message the spare bits of the Ciphering Key Sequence Number and of the Spare Half Octet IE will be randomly chosen. The spare bits of the Identity Type IE and the Spare Half Octet IE in the IDENTITY REQUEST message will also be chosen arbitrarily.

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

Addressing the MS under test

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

PAGING RESPONSE

5

SS -> MS

AUTHENTICATION REQUEST

see below

6

MS -> SS

AUTHENTICATION RESPONSE

7

SS -> MS

IDENTITY REQUEST

see below

8

MS -> SS

IDENTITY RESPONSE

with the right TMSI

9

SS -> MS

CHANNEL RELEASE

10

SS

The SS checks that the MS release the main signalling link

Specific message contents

AUTHENTICATION REQUEST

Information element

Value/remark

Ciphering Key Sequence Number

x000 (where "x" is set to 1)

Spare Half Octet

xxxx (where "xxxx" is arbitrary, with at least 1 bit set to 1)

Auth. Parameter RAND

standard value

IDENTITY REQ

Information element

Value/remark

Identity Type

x100 (where "x" is set to 1)

Spare Half Octet

xxxx (where "xxxx" is arbitrary, with at least 1 bit set to 1)

26.5.7.3 Spare bits / CC

26.5.7.3.1 Conformance requirements

The MS shall ignore the value of spare bits.

References

3GPP TS 04.08 / 3GPP TS 24.008, subclause 10.5.

26.5.7.3.2 Test purpose

To verify that the MS in the MM-state "connection established" and in RR-Connected mode ignores the value of spare bits in the special case of the spare bits occurring in the Calling Party BCD Number IE, Calling Party Subaddress IE, Called Party Subaddress IE, Cause IE and Progress Indicator IEs.

26.5.7.3.3 Method of test

Initial conditions

System Simulator:

1 cell, default parameters.

Mobile Station:

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Specific PICS statements:

– Support of speech (TSPC_AddInfo_Full_rate_version_1, TSPC_AddInfo_Half_rate_version_1)

PIXIT Statements:

Foreseen Final State of the MS

The MS is in the MM-state "idle, updated" and in RR-idle mode.

Test Procedure

After the establishment of the MM-connection, in the SETUP message the spare bits of the Calling Party BCD Number, Calling Party Subaddress and Called Party Subaddress will be arbitrarily chosen and also in the DISCONNECT message the spare bits of the Progress Indicator IE and of the Cause IE will be arbitrarily chosen.

Maximum duration of test

10 s.

Expected sequence

Step

Direction

Message

Comments

1

SS -> MS

PAGING REQUEST TYPE 1

Addressing the MS under test

2

MS -> SS

CHANNEL REQUEST

3

SS -> MS

IMMEDIATE ASSIGNMENT

4

MS -> SS

PAGING RESPONSE

5

SS -> MS

AUTHENTICATION REQUEST

6

MS -> SS

AUTHENTICATION RESPONSE

7

SS -> MS

CIPHERING MODE COMMAND

8

MS -> SS

CIPHERING MODE COMPLETE

9

SS -> MS

SETUP

see below

10

MS -> SS

CALL CONFIRMED

A11

MS -> SS

CONNECT

B11

MS -> SS

ALERTING

B12

MS -> SS

CONNECT

13

SS -> MS

ASSIGNMENT COMMAND

14

MS -> SS

ASSIGNMENT COMPLETE

15

SS -> MS

CONNECT ACKNOWLEDGE

16

SS -> MS

DISCONNECT

see below

If PICS TSPC_AddInfo_Full_rate_version_1 OR TSPC_AddInfo_Half_rate_version_1 is set to TRUE, path ‘A’ will be followed else path ‘B’ will be followed.

17A

SS -> MS

STATUS ENQUIRY

18A

MS -> SS

STATUS

with actual call state U12

19A

SS -> MS

RELEASE

20A

MS -> SS

RELEASE COMPLETE

17B

MS -> SS

RELEASE

18B

SS -> MS

RELEASE COMPLETE

After step 18B test will move to step 21.

21

SS -> MS

CHANNEL RELEASE

Specific message contents

SETUP

Information element

Value/remark

Calling Party BCD Number

IEI

length

3

octet 3

0000 0000

octet 3a

100x xx00 (where "x" is chosen arbitrarily, with at least one bit set to 1)

octet 4

0000 0001

Calling Party Subaddress

IEI

length

3

octet 3

1000 0xxx (where "x" is chosen arbitrarily, with at least one bit set to 1)

octet 4

0101 0000 (AFI: request IA5 character)

octet 5

0000 0001

Called Party Subaddress

IEI

length

3

octet 3

1000 0xxx (where "x" is chosen arbitrarily, with at least one bit set to 1)

octet 4

0101 0000 (AFI: request IA5 character)

octet 5

0000 0001

DISCONNECT

Information element

Value/remark

Cause

Length

2

octet 3

111x 0000 (where "x" is set to 1)

octet 4

1000 0001

Progress Indicator

IEI

Length

2

octet 3

111x 0000 (where "x" is set to 1)

progress description

8 (in band info now available)

26.5.8 Default contents of messages

Default requirements for messages that are not mentioned in this subclause are given in subclause 26.8.4.

CHANNEL RELEASE

Information element

Value/remark

RR cause

Normal event

CHANNEL REQUEST

DISCONNECT (SS -> MS)

Information element

Value/remark

Cause

Coding standard

Standard defined for the GSM PLMNS

Location

user

Cause value

#16

IDENTITY REQUEST

Information element

Value/remark

Identity type

Depending on test

Spare half octet

0000

IMMEDIATE ASSIGNMENT

Information element

Value/remark

L2 pseudo length

n, where n is the L2 pseudo length of the message

Page mode

arbitrary

Spare half octet

0000

Channel description

a valid description of an SDCCH + SACCH

Request reference

Corresponding to the last CHANNEL REQUEST received from the MS

Timing advance

arbitrary

Mobile allocation

chosen so that, together with the channel description IE, it describes a valid SDCCH + SACCH

Starting time

Omitted

IA rest octets

m octets, each coded as H’2B, where m = 22 – n

IMMEDIATE ASSIGNMENT REJECT

Information element

Value/remark

L2 pseudo length

19

Page mode

arbitrary

Spare half octet

0000

Request reference 1

corresponding to the last CHANNEL REQUEST received from the MS

Wait indication 1

0 s

Request reference 2

arbitrary

Wait indication 2

0 s

Request reference 3

arbitrary

Wait indication 3

0 s

Request reference 4

arbitrary

Wait indication 4

0 s

IA rest octets

3 octets, each coded as H’2B

PAGING REQUEST TYPE 1

Information element

Value/remark

L2 pseudo length

n where n is the sum of the mobile identity 1 IE and 3

Page Mode

Normal paging

Channels needed for Mobiles 1 and 2

Channel (first)

Any channel

Channel (second)

(spare)

Mobile identity 1

IMSI or TMSI of MS under test

Mobile identity 2

Omitted

P1 rest octets

m octets, each coded as H’2B, where m = 22 – n

PAGING RESPONSE

RELEASE COMPLETE (MS -> SS)

No default requirements defined for this message.

RELEASE COMPLETE (SS -> MS)

Information element

Value/remark

Cause

Coding standard

Standard defined for the GSM PLMNS

Location

user

Cause value

#16

STATUS (MS -> SS)

Information element

Value/remark

Cause

Length

length of cause IE

Coding standard

Standard defined for the GSM PLMNS

Location

user

Cause value

as defined in test

Call state

as defined in test

STATUS ENQUIRY (SS -> MS)

Information element

Value/remark

Transaction identifier

relating to the active call