Free tool · TS 102 225 table 5
Every status code a card can return in a PoR, with what it means, what normally causes it in production, and whether retrying can possibly help. Reference tables give you the first; campaigns fail because of the second and third.
Lookup
Type the hex value a card returned, with or without the 0x prefix.
Reference
Usual cause. The card accepted the command packet: security checks passed, the counter was accepted and the application processed the message. Any additional response data carries the application-level result.
What to do. Note that "PoR OK" is transport-level success only. An RFM UPDATE that returned 00 can still carry an APDU status word reporting that the update itself failed — check the additional response data before recording the card as done.
TS 102 225 §5.2
Usual cause. The card recomputed the cryptographic checksum or redundancy check and got a different value. Either the key is wrong, or the checksum was computed over the wrong byte range. In live estates a frequent operational cause is the wrong key for that subscriber: MSISDN and IMSI in inventory no longer match. The other common cause is the checksum byte range: whether CPI, CPL and CHL are included in the CC calculation is implementation-dependent for SMS, so a server that includes the wrong prefix produces a valid-looking packet that every card rejects.
What to do. If inventory is stale, update the MSISDN–IMSI mapping and try again. Also confirm the KID key value and key version, the algorithm and checksum length on the card, and the byte range: for SMS-PP, compute over CPL onward and compare against a known-good packet from the card vendor.
TS 102 225 §5.1.3, table 2 note 2 and note 3
Usual cause. The counter in your command packet was not higher than the counter the card holds, so replay protection rejected it. Your server is behind the card. Typical origins: a database restore, a parallel sending entity using its own counter, a campaign replayed from an old export, or a previous command that the card accepted and counted while your server recorded it as failed.
What to do. Recover by moving the counter up — it can only increase — then retry. MoreOTA ships add 1 and send again; you can add your own step per network or SIM code in the retry CSV. Repeating the same counter fails identically. Read the card-side value where the card allows it. If more than one sending entity shares a key version they share one counter and must be serialised; that is a design fault, not a transient error.
TS 102 225 §5.1.4
Usual cause. The card is configured for strict sequencing — SPI1 b5b4 = 11, "process if and only if the counter is exactly one higher" — and your counter jumped by more than one. Any gap, including one caused by a command that never arrived, produces this permanently until the gap is closed.
What to do. Send the missing value, or relax the card to b5b4 = 10 ("higher than") if the security policy allows it. Strict mode is rarely worth the operational cost on a large estate: on a bearer that loses messages, it converts a lost SMS into a stuck card.
TS 102 225 §5.1.1 note 4
Usual cause. The counter for this key version reached its maximum and is blocked. The card will not accept another command under that key version, no matter what you send.
What to do. Not retryable. Each key version has its own counter, so provisioning a new key set under a new key version number gives you a fresh counter — which requires the DEK/KIK and a PUT KEY operation. On a large estate, plan the key rotation as a campaign of its own.
TS 102 225 annex A.1
Usual cause. The card could not decipher the secured data. Wrong KIc key value or key version, an algorithm mismatch (the card expects AES-CBC and got triple DES, or the reverse), a key length the card does not hold, or ciphered data whose length is not a multiple of the block size.
What to do. Check KIc algorithm bits and key version against the card, and check padding: the padding counter must match the padding you actually added. If you recently moved from DES to AES, note that AES requires counter settings 10 or 11 in SPI1 — a stale counter setting fails here rather than in the counter codes.
TS 102 225 §5.1.2
Usual cause. A catch-all for a header the card cannot make sense of. Three specific causes are worth knowing: the KIc and KID key version numbers differ and are both non-zero; the PoR security settings violate the rules (PoR checksum type must match the command, and a ciphered PoR is only allowed if the command was authenticated and ciphered); or the header is structurally malformed — usually a wrong CHL.
What to do. Because this response is deliberately sent in the clear with no checksum, it is the one code you can always read, which makes it the best diagnostic you have. Check key version equality first, then the two PoR rules, then CHL: it must count from the SPI to the end of the RC/CC/DS, which is 13 octets plus the checksum length.
TS 102 225 §5.1.1 rules 1–2, annex A.2
Usual cause. The card does not have the memory to handle the message — most often a RAM operation loading a package into a card whose free non-volatile memory is exhausted, or a large secured payload on a card with little working memory.
What to do. Not fixable by retrying the same command. Reduce the payload, split the load into smaller blocks, or delete a retired package first. On a mixed estate this code usually clusters on one card profile, which tells you the segmentation was wrong rather than the campaign.
Usual cause. Not a failure. The card is telling you it accepted the work and will answer later — common for operations that take real time on card, such as installing or personalising an applet.
What to do. Do not retry on this code, and do not count it as failed. Retrying is actively harmful: the original command was accepted and counted, so the retry arrives with a stale counter and produces a spurious CNTR low. Hold the card in a pending state and wait for the follow-up PoR.
Usual cause. The card has no application registered against the Toolkit Application Reference you addressed. Either the TAR is wrong, or the application is genuinely not on that card, or it is present but not registered for the toolkit event you are using.
What to do. Verify the TAR against TS 101 220 annex D and the card vendor manual — vendor TARs vary and the manual wins. On a migration this code is usually informative rather than an error: it is how you discover which cards do not yet carry your applet, so treat it as a segmentation result and route those cards to the install campaign instead of retrying.
TS 101 220 annex D
Usual cause. The command was cryptographically valid but did not meet the Minimum Security Level the card requires for that application. For example the card demands ciphering plus a cryptographic checksum (MSL 0x06) and you sent a checksum only.
What to do. Raise the SPI to match the MSL configured for the target application, not the MSL you use elsewhere: the ISD and an RFM application on the same card commonly require different levels. Retrying at the same security level will fail identically.
TS 102 225 §5.1.1
Usual cause. Allocated to 3GPP for SMS-specific use; the meaning is defined in TS 31.115 rather than TS 102 225.
What to do. Interpret against TS 31.115 for the bearer in use.
3GPP TS 31.115
Usual cause. Allocated to 3GPP for SMS-specific use; the meaning is defined in TS 31.115 rather than TS 102 225.
What to do. Interpret against TS 31.115 for the bearer in use.
3GPP TS 31.115
Reserved
| 0D–BF | Reserved for future use by ETSI. A card returning one of these is almost certainly non-compliant; treat it as a vendor question. |
|---|---|
| C0–FE | Reserved for proprietary use. The meaning is card-specific and only the vendor documentation can tell you — this range is where vendor-specific applet errors surface. |
| FF | Reserved for future use. |
The important one
On a real campaign the largest single group is usually the cards that returned nothing at all, and there is no status code for that. Silence has several distinct causes that need different handling: a card that was unreachable and should be retried later; a card that received the command and answered into a lost SMS, which has already counted the command and will now reject the retry as CNTR low; and a card that is correctly configured never to reply.
Separating those three is most of the work in getting a campaign from the high eighties to the mid nineties, and none of it is visible in a status code.
To read the packet itself — SPI settings, key versions, counter, lengths — use the OTA secured packet decoder.
Why this exists
Deciding what a campaign should do about ten thousand of them is a CSV in MoreOTA: we ship a retry, and you can add your own action per network or SIM code.