Definition
Card Diagnostics is a feature provided by ICMP that offers SIM card connection quality testing, fault localization, remote diagnostics, and real-time status monitoring. Based on identifiers such as ICCID and IMEI, it tracks the connection status of individual or multiple cards, analyzes signal strength, checks network attachment, outputs a Card Health assessment, and assists operation and maintenance as well as customer self-service troubleshooting.
Diagnostic Capabilities
Card Diagnostics includes: Signal Quality—LTE indicators such as RSRP, RSRQ, SINR, and 2G/3G indicators such as RSSI; Network Attachment—current attachment status, PLMN, APN, HPLMN/VPLMN; Usage and Billing—real-time traffic, remaining data plan, and overage status; Fault Localization—analysis of common issues such as no signal, no data, roaming anomalies, and APN misconfigurations; Historical Trends—connection stability, frequency of disconnections, and abnormal period statistics.
Use Cases
Applicable to scenarios such as abnormal connections after device deployment, bulk SIM card quality monitoring, fault ticket handling, and customer self-service troubleshooting. In cross-border scenarios, devices may connect to Multi-Operator networks, requiring analysis of roaming behavior in conjunction with PLMN Selection and Roaming Policy. Card Health scores can drive optimization of Carrier Fallback or Failover strategies.
Implementation in ICMP
SimtoLink ICMP supports querying card diagnostic information by ICCID, IMEI, customer, batch, and other dimensions; provides both API and console access; supports bulk diagnostics, scheduled inspections, and alarm linkage. Diagnostic data comes from operators or platform-built probes, combined with CDR and usage data for comprehensive analysis, producing readable diagnostic reports and recommendations.
Whether diagnostics read session records or radio metrics
Card diagnostics have to start from where the data comes from. What the core network and the platform can provide reliably is usually whether the SIM is attached, which network it is attached to, which access point it used, whether the latest data session was established, and whether usage is still inside the plan. Radio metrics such as reference signal received power and signal quality exist only after the device or module reports them. Empty values for those two numbers on a platform page do not mean there is no signal on site. They mean this check did not collect radio-side data.
A diagnostic conclusion must therefore name its observation point. “SIM fault” should be able to point to a rejected subscription, a rejected session, or radio quality that the device itself reported as poor for a sustained period. Only the last of those is a reason to look at the antenna and the installation first. Read the SIM identifier, the device identifier, and the number together. A SIM that is on the network while the device identifier changes often looks more like the SIM moving between modules than like a network outage.
The observation window a remote conclusion needs
One query represents only the state near the moment of the query. A device that sits in a warehouse by day and powers on at night cannot be judged damaged from a daytime “not attached.” To judge a stable dropout, look at a stretch of history that includes normal business hours: attach counts, session failure reasons, and whether failures cluster in one country or one network. Bulk diagnostics must use the same time window. Otherwise results from different batches cannot be compared.
The window for a cross-border device must include the visited network. Home-network test records alone cannot explain a failure after the device reaches another country. Usage that suddenly falls to zero may mean the application stopped, or that the session failed to establish. Session records distinguish the two. A traffic curve alone cannot. When comparing with detail records, remember that detail records can arrive late. Real-time usage on the diagnostic page and usage already invoiced can disagree for a while. That lag is not a SIM fault.
Treating a roaming-policy problem as a faulty card
A SIM that attaches at home and fails in a visited country often fails because roaming is not allowed, the preferred-network list does not include the current network, or the visited network does not accept the access point. Those are policy and configuration problems. A replacement SIM with the same configuration fails the same way. If the diagnosis says only “signal abnormal,” the field team keeps swapping hardware. Another misread is treating a fair-usage throttle as a radio fault. The session is still up, only the rate has dropped, and the radio metrics need not have worsened.
After a multi-operator SIM switches, a diagnosis that still shows the old visited network may mean the session has not been released, not that the new network refused it. Wait for the device to attach again before concluding. Do not replace hardware on a single failure. If the attach cause code says the requested service is not provisioned, go back to the roaming policy and the plan, rather than scrapping the SIM. A diagnostic report should give the identifier, network, access point, cause code, and time together. An “unhealthy” score with no cause code cannot by itself justify suspending the SIM. Historical trend is for finding repeated failure. It does not replace the reason for this session.
Bulk diagnostic output should be grouped by cause code, not reduced to one health score. A score that collapses “not provisioned,” “access point rejected,” and “poor radio quality” into the same color leaves the field unable to decide whether to change configuration or installation. After grouping, sample the raw fields: SIM identifier, network, access point, and time. A row missing any of those columns should not enter the statistics. When radio metrics reported by the device and attach records from the core do not share a time, show both timestamps side by side. Do not interpolate them into one smooth curve. A smooth curve does not mean there was a sample in that minute. A period with no sample should be marked unknown. It should not be marked as normal signal, and it should not be marked as zero signal. Unknown and a measured zero are different results in later statistics. Mixing them counts devices that never reported as if coverage were good.