SIM steps

Every action available in SIM tests, organized like the action palette, with the metrics each one produces.

SIM tests run on real SIM cards in your cellular agents. Each action drives the modem (USSD, SMS, calls) or the data connection (ping, downloads, speedtest) and produces network metrics that feed Analytics. 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
PingICMP round-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 MailSMTP delivery 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 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 shares the same envelope:

  • 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, AT command logs, 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): use the SIM's default APN or custom credentials.
  • Keep pdp context (command.keep_alive): leave the data session 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 typed report: its status, duration, and the measurements specific to the action (RTT, throughput, MOS, expiry time...). The KPI processor turns each report into a measurement tagged with the test, the SIM, the antenna (MCC, MNC, LAC, cell ID), and the access technology, which is 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