Project

General

Profile

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 SMPP
  • 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
Add picture from clipboard (Maximum size: 48.8 MB)