Automatic Testing » History » Revision 4
Revision 3 (laforge, 01/26/2018 09:24 AM) → Revision 4/6 (laforge, 01/26/2018 09:28 AM)
h1. Automatic Testing This page will describe how we do automatic testing of OsmoMSC. h2. Ideas for Testing A collection of test ideas for osmo-msc h3. Fuzzy M3UA * Restart STP multiple times in a row, then test connectivity (e.g. by executing an A-Interface transaction that requires making an SCCP connection * Silently vanish while performing an operation (e.g. shut down M3UA while doing a location update, call, sms etc...) h3. Fuzzy SCCP * Make an SCCP connection and leave the connection open (Will the MSC close it?) * Make an SCCP connection perform some action (e.g. LU) but do not send a clear command, see if the MSC closes the connection. * Send garbled connectionless SCCP packet * Send garbled connectionless SCCP packet but with correct BSSMAP header * Make SCCP connection, send garbeled packet * Make SCCP connection, Send garbeled packet but with correct BSSMAP header * Make SCCP connection, Send garbeled packet but with correct DTAP header * Make SCCP connection and send an early clear command (this should could be done with all operations to see if this behaviour results in uncleared state) * Make an SCCP connection, perform an action but do not respond to the clear command at the end. Do we still release the connection gracefully? h3. Fuzzy BSSAP * Make an SCCP connection with a CM Service Request, but request a service that does not exist. (TC_cm_serv_req_*_reject) * Perform the same action concurrently (e.g. the same location update for the same subscriber at the same time, try also with calls and SMS). h3. Reset * Send a BSSMAP RESET, check if responded with BSSMAP RESET ACK in time * Repeat Reset procedure multiple times in a row * Send another reset before MSSMAP RESET ACK is received (fast series of BSSMAP RESET) h3. Location update / Common MM Procedures * Perform a normal location update ** with / without authentication ** with / without TMSI allocation ** with / without early classmark sending *** * Perform a location update but leave out TMSI Reallocation Complete message use wrong Ki (should be rejected) *** * Perform a location update that gets rejected, but send a leave out TMSI Reallocation Complete anyway. message ** with / without encryption *** test for cipher algorithm selection based on CM + VTY *** * Perform a location update but use wrong Ki (should be rejected) *** Perform a location update but don't respond to Cipher mode command ** using too long/short IMSI value (5..15 is legal, shorter or longer not) ** using illegal MI type IMEI * check if MM INFO is sent / not sent based on VTY config Perform a location update that gets rejected, but send a TMSI Reallocation Complete anyway. h3. MO-Call * Make a call (normal) * SCCP / outer protocols ** Hard-close the SCCP connection while a call is running by sending a clear command ** See what happens when using wrong KI (call should fail) ** Stop after the Cipher Mode Complete message, do not send Setup. Do we run in a timeout and clear the sccp connection? * L3/CC related ** Make a call, but do not acknowledge the connection (Connect Acknowledge) ** Leave out CALL Proceeding message. ** Leave out Connect message ** CC messages without mandatory IEs ** CSD or CTM calls, i.e. anything beyond normal voice * MGCP ** Do not respond to any MGCP request (MGW down) ** Fail every MGCP request ** Fail one choosen MGCP transaction. Repeat this test until all MGCP transactions have been tried. ** Stop responding to one choosen MGCP transaction. Repeat this test until all MGCP transactions have been tried. ** Respond with garbeled MGCP messages, see what happens when the IP-Address is an empty string or is missing completely. Also check the same with the other parameters. ** Try what happens when the MGW returns the same connection identifier for both connections. * Check if the RTP streams are properly switched, do the RTP parameters issued by the MSC make sense? * codec related bits ** Make a call, but in the ASSIGNMENT COMPLETE message, respond with a choosen codec that was not on the speech codec list in the ASSIGNMENT REQUEST. ** bearer capabilities without codec related octets (e.g. in MO SETUP) * external MNCC side ** check if modification of bearer capabilities on MNCC side (in MO case) works * built-in MNCC handler ** check if codec matching works in case of overlap and no overlap between bearer capabilities etc. h3. MT-Call (Where possible, apply the odd cases from MO-Call) * Place a call via MNCC (normal) * Do not respond to paging * Respond with a wrong IMSI in PAGING RESPONSE * Miss out the ALERTING message h3. MO-SMS * Send an SM (normal) * Stop after the Cipher Mode Complete message, do we run in a timeout and clear the sccp connection? * Skip CP-DATA/RP-DATA, just send an unsoliciated CP-ACK * Send CP-DATA/RP-DATA twice * Leave out TP-Destination-Address in CP-DATA/RP-DATA * Use an invalid TP-PID in CP-DATA/RP-DATA. * Use an invalid TP-DCS in CP-DATA/RP-DATA. * Try coding groups other than GSM 7 bit default alphabet (do we support different ones?) * Can TP-User-Data-Length exceed the allowed 160 chars? If yes we should try what happens when we exceed this limit. * Try with message that has exactly 160 chars (maximum length) h3. MT-SMS * Initiate sending an SM via GSUP * Skip the CP-ACK message. * Skip the CP-DATA/RP-ACK message. * Respond with DTAP/MSMS/CP-ERROR, see if the MSC trys to deliver the SM again. h3. USSD * Execute USSD request (*#100#) normally * Use invalid ussd-DataCodingScheme parameter * Try USSD string that exceeds the maximum permitted length * Try USSD string that has exactly the maximum permitted length * Try coding groups other than GSM 7 bit default alphabet (do we support different ones?) * Try strings that violate the common USSD syntax (*/#) h3. External handover (This case requires two BSC/MGW test components) * Run external handover procedure as normal. * Run the procedure again, stop responding to MSC messages where possible to see if timeout mechanisms (T23) work properly. * For HANDOVER REQUIRED try the procedure with the invalid changes: ** Use invalid cause code in HANDOVER REQUIRED message ** Send an empty Cell Identifier List ** Send no Cell Identifier List ** Choose channel type other than SPEECH (currently we only support SPEECH) ** Send not speech version ** Send no AoIP speech codec. (The MSC should recject the HANDOVER REQUIRED message with an HANDOVER REQUIRED REJECT message, check if the cause code set by the MSC makes sense) * For HANDOVER REQUEST ACKNOWLEDGE try the procedure with the invalid changes: ** Send no Layer 3 information ** Send no AoIP Transport Layer Address ** Send port number = 0 in AoIP Transport Layer Address ** Send IP-Address 0.0.0.0 in AoIP Transport Layer Address ** Send no Codec List ** Send inconsistant Codec List ** Send no Speech Version ** Send no Speech Codec (The MSC should send an HANDOVER REQUIRED REJECT to the source BSC? Does the cause code make sense?) * Answer the HANDOVER REQUEST message directly with an HANDOVER FAILURE message, the MSC should then HANDOVER REQUIRED REJECT to the source BSC (correct?) * Skip HANDOVER DETECT and directly send HANDOVER COMPLETE message
