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 |