SIM steps

All the actions available in SIM tests, from USSD codes and SMS to calls and mobile data checks, with what each one measures.

SIM tests run on real SIM cards in your cellular agents. Some actions use the SIM the way a phone does (USSD codes, SMS, calls), others use its mobile data connection (ping, downloads, speedtest). The groups below match the action palette in the product.

USSD

ActionWhat it measures
USSD CommandSend a code, verify the response, session state, response time
Wait USSD PushNetwork-initiated USSD: content and reception delay

SMS

ActionWhat it measures
Wait SMSIncoming SMS: sender, content, parts, reception delay
Send SMSSend time, parts, retries, optional delivery report

DATA

ActionWhat it measures
PDP ActivationData session activation time, assigned IP configuration
PingRound-trip time, jitter, packet loss
TCP PingConnection latency at the TCP layer
HTTP PingResponse latency of a web endpoint
DNS LookupResolution time and resolved addresses
Download FileDownload throughput with the full timing waterfall
HTTP UploadUplink throughput over HTTP
FTP DownloadDownload throughput over FTP
FTP UploadUplink throughput over FTP
Send MailEmail sending (SMTP) from the mobile network
API CallFull HTTP request: status, body, timing waterfall
Ookla SpeedtestDownload, upload, latency, jitter, packet loss
TraceroutePer-hop response times and loss
Check SSL/TLS CertificateCertificate validity and time before expiry
YoutubeVideo streaming quality: buffering, dropped frames
Web ScriptA scripted web journey over the cellular connection

CALL

ActionWhat it measures
Wait CallIncoming call: answer delay, duration, audio quality score (MOS)
Place CallConnect time, post-dial delay, call hold

Other

ActionWhat it measures
Reboot simModem restart and network re-registration time

Common options

Every SIM action accepts these options:

  • Owner (owner): which SIM runs the action. Owners are assigned per test and can be overridden per campaign.
  • Assertions (assertions): compare any field of the action's report against an expected value (status, response time, packet loss, status code...). A failing assertion fails the action. Some actions ship with a default, like packet_loss == 0 on Ping.
  • Stored variables (store): copy a report field (duration, extracted text, RTT...) into a test variable for later actions, with an optional default when the source is absent.
  • Should fail (expect_failure): invert the verdict, to verify that something is blocked (a barred number, a filtered domain).
  • Skip (skip): keep the action in the scenario without running it.
  • Artifacts (command.options.artifacts): capture network traces, TCP dumps, modem command logs (AT commands), or call audio with the result.

Connection settings

DATA actions also share the connection setup:

  • Access technology (command.access_technology): force 2G/3G/4G or specific profiles; empty means automatic.
  • APN (command.default_apn, command.apn, command.login, command.password): the access point the SIM goes through to reach mobile data (Access Point Name). Use the SIM's default APN or custom credentials.
  • Keep pdp context (command.keep_alive): leave the data session (PDP context) open for the next actions instead of tearing it down.
  • Check internet connection (command.check_network.active): verify connectivity before measuring.

From results to analytics

Every action records a report: its status, its duration, and the measurements specific to the action (round-trip time or RTT, throughput, audio MOS, expiry time...). Kapptivate turns each report into a measurement tagged with the test, the SIM, the antenna (the cell the SIM was attached to, identified by MCC, MNC, LAC and cell ID), and the access technology. That's what you chart and alert on in Analytics. Each action page lists its exact fields.

What's next?

Cellular tests

The authoring workflow: owners, variables, campaigns, runs

Analytics

Chart and alert on the metrics these actions produce

Last updated on