MoreOTA Discuss a project

Platform

On-prem SCP80

RFM, RAM, SMS, per-card state, retry from a CSV. Installed next to the operator SMSC.

Tools · Discuss a project

  • RFM · RAM
  • SCP80 · SMS
  • On-premise
  • Retry from a CSV

Where it sits

MoreOTA sends secured packets through the operator SMSC to the SIM estate, and receives proof of receipt back Operator network — on-premise MoreOTA Campaign targeting and batching Secured packet creation (SCP80) Per-card state store Response handling (PoR) Retry policy by failure cause operator keys · applet-aware · headless SMSC existing messaging SIM estate UICC / eUICC SIM profile and files Card applications Custom applets Keys and counters mixed vendors · generations · key sets SCP80 SMS-PP RFM / RAM command, secured packet proof of receipt and status code one card, one tracked outcome
Figure 1. MoreOTA is headless by design, so the product view is the flow it controls: secured packets out through the operator's own SMSC, per-card responses back, and a retry decision taken per card rather than per campaign.

As deployed today

Capabilities

Baseline first. Extra features and unique behaviour are added per project — see Custom add-ons.

Workflows RFM (remote file management), RAM (remote applet management)
Bearer SMS. Additional bearers on a project basis.
Security SCP80 secured packets, with operator key handling
Estate Mixed card vendors, generations, profiles and key sets in one campaign
Campaign control Targeting and segmentation, batching, throttling, response handling, per-card status
Retry engine We ship a retry; you can add your own. CSV per network or SIM code. Examples we ship: counter low → add 1; PoR 01 → fix inventory; absent subscriber → try in a day.
Applet interface Drives custom on-card applets, including migration applets, through application-specific command hooks
Deployment On-premise, next to the operator's SMSC. OPC/Ki and OTA keys never leave the site.
Custom add-ons Per project: SCP81, a GUI built for your operators, local DB or SMTP integration, custom OTA packet generation, AI-assisted retry — discuss what the estate needs.

Retry

We ship a retry. You can add your own.

The mechanism is a CSV: what to do for each network or SIM code. Use the rows we ship, or add your own retry plan in the same file. Reading the codes takes experience — these three are examples, not the whole catalogue.

A card that went quiet after a security error is not a row to hammer. That silence can be correct.

PoR 01 — cipher error

Wrong key. Often the MSISDN and IMSI in inventory no longer match. Update the inventory, try again.

PoR 01 guide

PoR 06 — unidentified security

Sent in the clear. Check key versions, PoR rules, then CHL.

PoR 06 guide

PoR 08 — more time

Not a failure. Do not retry — wait for the follow-up PoR.

PoR 08 guide

Error **:** — network

Usually absent subscriber. Try in a day. Best: align the send to VLR registration so fewer are absent.

Got an error?

Decode it here.

Paste the PoR or the command. Status, SPI, TAR, counter. Nothing uploaded. Guides if you already know the code.

Paste a packet, or load one of the examples above.

Hex, with or without 0x

Work

Programmes

Migration without swap

IMSI, MSISDN, PLMN and brand moves on a live UICC estate — counters, half-applied updates and unreachable cards.

Details →

Campaign rescue & PoR triage

01/02/03/06 clusters need inventory, byte-range and SPI forensics — not a blind retry.

Details →

Pre-production validation

Test harness, sample cards and the SMSC path before a million-card send.

Details →

Custom applets & key architecture

Multi-IMSI, polling, DEK/KIK rotation — RAM install and MSL alignment per card profile.

Details →

FAQ

Platform questions

What is an OTA campaign?
An OTA (over-the-air) campaign sends a set of commands to many SIMs at once to change what is on the card. File changes use RFM (remote file management). Applet install or update uses RAM (remote applet management).
Is SIM OTA secure over SMS and HTTP?
Yes, when a Secure Channel Protocol wraps the commands. Over SMS the common protocol is SCP80. Over HTTP it is SCP81. MoreOTA’s deployed baseline today is SCP80 over SMS; SCP81 can be added per project.
What does the MoreOTA platform include?
Baseline today: RFM and RAM over SMS with SCP80 secured packets, mixed estates, campaign control, retry from a CSV per network or SIM code, and an applet interface. Per project you can add SCP81, an operator GUI, local DB or SMTP integration, custom OTA packet generation, or an AI-assisted retry layer.
How does MoreOTA retry a failed OTA campaign?
Orchestration scripts plus a CSV: what to do for each network or SIM code. Use a shipped template, or write your own rows from the error codes. Examples: counter low → add 1 and try again; PoR 01 → often stale MSISDN/IMSI inventory; absent subscriber → try in a day, aligned to network registration when possible.
Where are OTA keys stored with MoreOTA?
On the operator site. MoreOTA runs on-premise next to the SMSC (SMS centre). OPC/Ki and OTA keys do not leave the operator.

Contact

Technical call

Remote worldwide. On-site Israel only.

Email direct: contact@moreota.com

Include the network or estate, the SIM vendors, and what the campaign needs to do. A technical call is 30 minutes, engineering to engineering.

Enquiries are handled as in the privacy notice. Do not paste production keys.

LinkedIn