Actions
Automatic Testing » History » Revision 5
« Previous |
Revision 5/6
(diff)
| Next »
laforge, 01/26/2018 09:31 AM
Automatic Testing¶
This page will describe how we do automatic testing of OsmoMSC.
Ideas for Testing¶
A collection of test ideas for osmo-msc
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...)
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?
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).
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)
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
- Perform a location update that gets rejected, but send a TMSI Reallocation Complete anyway.
- 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
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.
MT-Call including Paging¶
(Where possible, apply the odd cases from MO-Call)
- Place a call via MNCC (normal)
- check for missing informatio nlements
- Miss out the ALERTING message
- Paging
- by TMSI and by IMSI (if TMSI allocation disabled)
- Do not respond to paging
- Respond with a wrong IMSI/TMSI in PAGING RESPONSE (never paged)
- verify if paging is done in correct LA (that of last LU)
- double response to single paging (cloned IMSI behavior)
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)
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.
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 (*/#)
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
Updated by laforge over 6 years ago · 5 revisions