|
1
|
A collection of test scenarios for osmo-msc
|
|
2
|
===========================================
|
|
3
|
|
|
4
|
1) Fuzzy M3UA
|
|
5
|
* Restart STP multiple times in a row, then test connectivity (e.g. by executing
|
|
6
|
an A-Interface transaction that requires making an SCCP connection
|
|
7
|
* Silently vanish while performing an operation (e.g. shut down M3UA while
|
|
8
|
doing a location update, call, sms etc...)
|
|
9
|
|
|
10
|
|
|
11
|
2) Fuzzy SCCP
|
|
12
|
* Make an SCCP connection and leave the connection open (Will the MSC close it?)
|
|
13
|
* Make an SCCP connection perform some action (e.g. LU) but do not send a clear
|
|
14
|
command, see if the MSC closes the connection.
|
|
15
|
* Send garbeled connection less SCCP packet
|
|
16
|
* Send garbeled connection less SCCP packet but with correct BSSMAP header
|
|
17
|
* Make SCCP connection, send garbeled packet
|
|
18
|
* Make SCCP connection, Send garbeled packet but with correct BSSMAP header
|
|
19
|
* Make SCCP connection, Send garbeled packet but with correct DTAP header
|
|
20
|
* Make SCCP connection and send an early clear command (this should could
|
|
21
|
be done with all operations to see if this behaviour results in uncleared
|
|
22
|
state)
|
|
23
|
* Make an SCCP connection, perform an action but do not respond to the clear
|
|
24
|
command at the end. Do we still release the connection gracefully?
|
|
25
|
|
|
26
|
|
|
27
|
3) Fuzzy BSSAP
|
|
28
|
* Make an SCCP connection with a CM Service Request, but request a service that
|
|
29
|
does not exist.
|
|
30
|
* Perform the same action concurrently (e.g. the same location update for the
|
|
31
|
same subscriber at the same time, try also with calls and SMS).
|
|
32
|
|
|
33
|
|
|
34
|
4) Reset
|
|
35
|
* Send a BSSMAP RESET, check if responded with BSSMAP RESET ACK in time
|
|
36
|
* Repeat Reset procedure multiple times in a row
|
|
37
|
* Send another reset before MSSMAP RESET ACK is received (fast series of BSSMAP
|
|
38
|
RESET)
|
|
39
|
|
|
40
|
|
|
41
|
5) Location update
|
|
42
|
* Perform a normal location update
|
|
43
|
* Perform a location update but use wrong Ki (should be rejected)
|
|
44
|
* Perform a location update but leave out TMSI Reallocation Complete message
|
|
45
|
* Perform a location update but don't respond to Cipher mode command
|
|
46
|
* Perform a location update that gets rejected, but send a TMSI Reallocation
|
|
47
|
Complete anyway.
|
|
48
|
|
|
49
|
|
|
50
|
6) MO-Call
|
|
51
|
* Make a call (normal)
|
|
52
|
* Hard-close the SCCP connection while a call is running by sending a clear
|
|
53
|
command
|
|
54
|
* Make a call, but do not acknowledge the connection (Connect Acknowledge)
|
|
55
|
* See what happens when using wrong KI (call should fail)
|
|
56
|
* Stop after the Cipher Mode Complete message, do not send Setup. Do we run in a
|
|
57
|
timeout and clear the sccp connection?
|
|
58
|
* Leave out CALL Proceeding message.
|
|
59
|
* Leave out Connect message
|
|
60
|
* Do not respond to any MGCP request (MGW down)
|
|
61
|
* Fail every MGCP request
|
|
62
|
* Fail one choosen MGCP transaction. Repeat this test until all MGCP
|
|
63
|
transactions have been tried.
|
|
64
|
* Stop responding to one choosen MGCP transaction. Repeat this test until all
|
|
65
|
MGCP transactions have been tried.
|
|
66
|
* Check if the RTP streams are properly switched, do the RTP parameters issued
|
|
67
|
by the MSC make sense?
|
|
68
|
* Respond with garbeled MGCP messages, see what happens when the IP-Address
|
|
69
|
is an empty string or is missing completely. Also check the same with the
|
|
70
|
other parameters.
|
|
71
|
* Try what happens when the MGW returns the same connection identifier for both
|
|
72
|
connections.
|
|
73
|
* Make a call, but in the ASSIGNMENT COMPLETE message, respond with a choosen
|
|
74
|
codec that was not on the speech codec list in the ASSIGNMENT REQUEST.
|
|
75
|
|
|
76
|
|
|
77
|
7) MT-Call
|
|
78
|
(Where possible, apply the odd cases from MO-Call)
|
|
79
|
* Place a call via MNCC (normal)
|
|
80
|
* Do not respond to paging
|
|
81
|
* Respond with a wrong IMSI in PAGING RESPONSE
|
|
82
|
* Miss out the ALERTING message
|
|
83
|
|
|
84
|
|
|
85
|
8) MO-SMS
|
|
86
|
* Send an SM (normal)
|
|
87
|
* Stop after the Cipher Mode Complete message, do we run in a timeout and clear
|
|
88
|
the sccp connection?
|
|
89
|
* Skip CP-DATA/RP-DATA, just send an unsoliciated CP-ACK
|
|
90
|
* Send CP-DATA/RP-DATA twice
|
|
91
|
* Leave out TP-Destination-Address in CP-DATA/RP-DATA
|
|
92
|
* Use an invalid TP-PID in CP-DATA/RP-DATA.
|
|
93
|
* Use an invalid TP-DCS in CP-DATA/RP-DATA.
|
|
94
|
* Try coding groups other than GSM 7 bit default alphabet (do we support
|
|
95
|
different ones?)
|
|
96
|
* Can TP-User-Data-Length exceed the allowed 160 chars? If yes we should try
|
|
97
|
what happens when we exceed this limit.
|
|
98
|
* Try with message that has exactly 160 chars (maximum length)
|
|
99
|
|
|
100
|
|
|
101
|
9) MT-SMS
|
|
102
|
* Initiate sending an SM via GSUP
|
|
103
|
* Skip the CP-ACK message.
|
|
104
|
* Skip the CP-DATA/RP-ACK message.
|
|
105
|
* Respond with DTAP/MSMS/CP-ERROR, see if the MSC trys to deliver the SM again.
|
|
106
|
|
|
107
|
|
|
108
|
10) USSD
|
|
109
|
* Execute USSD request (*#100#) normally
|
|
110
|
* Use invalid ussd-DataCodingScheme parameter
|
|
111
|
* Try USSD string that exceeds the maximum permitted length
|
|
112
|
* Try USSD string that has exactly the maximum permitted length
|
|
113
|
* Try coding groups other than GSM 7 bit default alphabet (do we support
|
|
114
|
different ones?)
|
|
115
|
* Try strings that violate the common USSD syntax (*/#)
|
|
116
|
|
|
117
|
|
|
118
|
11) External handover
|
|
119
|
(This case requires two BSC/MGW test components)
|
|
120
|
* Run external handover procedure as normal.
|
|
121
|
* Run the procedure again, stop responding to MSC messages where possible to
|
|
122
|
see if timeout mechanisms (T23) work properly.
|
|
123
|
* For HANDOVER REQUIRED try the procedure with the invalid changes:
|
|
124
|
* Use invalid cause code in HANDOVER REQUIRED message
|
|
125
|
* Send an empty Cell Identifier List
|
|
126
|
* Send no Cell Identifier List
|
|
127
|
* Choose channel type other than SPEECH (currently we only support SPEECH)
|
|
128
|
* Send not speech version
|
|
129
|
* Send no AoIP speech codec.
|
|
130
|
(The MSC should recject the HANDOVER REQUIRED message with an
|
|
131
|
HANDOVER REQUIRED REJECT message, check if the cause code set by the MSC
|
|
132
|
makes sense)
|
|
133
|
* For HANDOVER REQUEST ACKNOWLEDGE try the procedure with the invalid changes:
|
|
134
|
* Send no Layer 3 information
|
|
135
|
* Send no AoIP Transport Layer Address
|
|
136
|
* Send port number = 0 in AoIP Transport Layer Address
|
|
137
|
* Send IP-Address 0.0.0.0 in AoIP Transport Layer Address
|
|
138
|
* Send no Codec List
|
|
139
|
* Send inconsistant Codec List
|
|
140
|
* Send no Speech Version
|
|
141
|
* Send no Speech Codec
|
|
142
|
(The MSC should send an HANDOVER REQUIRED REJECT to the source BSC? Does the
|
|
143
|
cause code make sense?)
|
|
144
|
* Answer the HANDOVER REQUEST message directly with an HANDOVER FAILURE message,
|
|
145
|
the MSC should then HANDOVER REQUIRED REJECT to the source BSC (correct?)
|
|
146
|
* Skip HANDOVER DETECT and directly send HANDOVER COMPLETE message
|
|
147
|
|
