An OTA platform is a secure system that remotely communicates with SIM cards or eUICC to execute updates such as: 

• Editing SIM files (EF files) 
• Installing/updating/deleting applets 
• Updating IMSI or operator parameters 
• Applying steering logic 
• Rotating keys 
• Activating new features 

OTA is a critical enabler for: 

• MNOs who manage millions of SIMs 
• IoT service providers running multi-market deployments 
• Enterprises operating connected devices at scale 

Even in fully eSIM-enabled ecosystems, OTA plays a vital role: eUICC still rely on OTA mechanisms inside Secure Channels for applet updates, Multi-IMSI control, maintenance, and mobility logic. 

OTA architecture consists of the following core elements: 

Manages campaigns, schedules, applets, file operations, target lists, and success metrics.
Features include: 

• SIM inventory 
• Targeting filters 
• Secure routing 
• Monitoring dashboards 
• Retry logic 
• Reporting and analytics 

OTA messages can be delivered via: 

A) SMS-PP (Short Message Point-to-Point) 

• The most widely supported OTA transport 
• Works across 2G, 3G, 4G, 5G 
• Ensures backward compatibility with legacy SIMs 
• Uses SMS-SUBMIT and SMS-DELIVER structures 

B) BIP (Bearer Independent Protocol) 

• Uses the device’s IP connection (cellular data) instead of SMS
• Higher success rates than SMS in congestion or roaming conditions 
• Lower operating cost 

C) HTTPS / IP-based channels 

Used mostly by modern eUICC/eSIM: 

• Faster 
• More reliable 
• Supports future-proof IP-only networks 

The SIM Toolkit framework and its Card Application Toolkit Transport Protocol (CAT-TP) enable: 

• SIM ↔ Device communication 
• STK applet triggers 
• HTTP/HTTPS exchanges 

STK is foundational for advanced OTA features like Multi-IMSI steering or interactive applets. 

OTA relies on secure cryptographic channels to guarantee: 

• Authentication 
• Message integrity 
• Confidentiality 
• Replay protection 

Examples include SCP80, SCP81 (SMS-based), or SCP03 (IP-based).  

OTA technology supports two fundamental capabilities: 

RFM allows secure updates to SIM/eUICC file structures, including: 

• PLMN lists 
• Preferred networks 
• RAT restrictions 
• APN configurations 
• Steering-of-roaming tables 
• Custom SIM files used by applets 

Operators rely heavily on RFM to: 

• Enforce roaming policies 
• Update outdated PLMNs 
• Enable/disable network features 
• Reconfigure connectivity based on roaming bans or regional optimizations 

RAM allows: 

• Installing new applets 
• Updating existing applets 
• Deleting applets 
• Managing applet lifecycle states 

RAM is increasingly important for: 

• Multi-IMSI applets 
• Security updates 
• Regulatory compliance changes 
• Value-added services (VAS) such as payment, ID, authentication 

In eUICC/eSIMs, RAM operations interact closely with the ISD-P (Issuer Security Domain – Profile) and root domain. 

OTA is used across both consumer and IoT ecosystems. Common use cases include: 

OTA updates: 

• IMSI 
• Authentication keys 
• Operator routing logic 
• Steering rules 

Enables: 

• Seamless roaming optimization 
• Local profile substitution (for compliance) 
• Network resilience across markets 

Examples: 

• Preferred network lists 
• APN configurations 
• Bearer/RAT permissions 
• RF optimizations 

These ensure optimal connectivity as MNO landscapes evolve. 

Use cases: 

• Installing new features 
• Updating roaming logic 
• Removing outdated services 
• Security applet updates 

OTA can: 

• Rotate Ki/OPc 
• Replace sensitive keys 
• Update cryptographic counters 
• Apply certificate updates 

This improves long-term security posture. 

OTA is essential for applying emergency updates such as: 

• Fixing bugs in SIM toolkit applets 
• Correcting provisioning errors 
• Addressing roaming bans 
• Updating faulty PLMN lists 

OTA stays relevant in mixed fleets where: 

• Some devices use SIM 
• Some use eSIM with RSP 
• vSome use eSIM with Multi-IMSI 

OTA becomes the glue connecting both worlds. 

Even with eSIM + Remote SIM Provisioning becoming the industry standard, OTA still plays a crucial role in eUICC lifecycle management. 

OTA complements RSP in the following ways: 

OTA can modify: 

• Applet logic 
• Security parameters 
• File structures 

without affecting operator profiles. 

OTA enables: 

• IMSI switching 
• Routing table updates 
• Regional behavior enforcement 

This works even inside an eSIM with multiple profiles. 

OTA is used to: 

• Patch applets 
• Apply SIM Toolkit fixes 
• Update fallback logic 

RSP does not directly modify the SIM OS or applets, so OTA remains essential. 

Many IoT devices with eSIM still rely partly on: 

• SMS bearers 
• STK interactions 
• OTA-triggered events 

Devices deployed 10+ years will still need OTA for maintenance. 

OTA campaigns define how updates are delivered across large fleets. 

Key elements include: 

OTA enables granular targeting by: 

• ICCID 
• IMSI 
• PLMN 
• Region/country 
• Device model 
• Firmware version 
• Profile type 

Segmentation prevents unnecessary updates and reduces cost. 

Campaigns include configurable parameters: 

• Retry intervals 
• Delivery windows 
• Time-of-day rules 
• Maximum retries 
• Throttling to avoid network congestion 

Important OTA metrics include: 

• Submit success rate 
• Delivery reports (DLRs) 
• Application-level ACK 
• Completion rate 
• Failure modes 
• STK-trigger failures 
• Network rejects 

These KPIs help operators validate fleet health. 

OTA and RSP must be orchestrated coherently, especially when: 

• Updating IMSI in Multi-IMSI setups 
• Switching fallback logic 
• Preparing SIMs for upcoming eSIM transitions 
• Updating devices before provisioning new profiles via SM-DP+ 

Causes: 

• Congestion 
• Device offline 
• Roaming restrictions 

Mitigation: 

• Shift to BIP/HTTPS when possible 
• Increase retry intervals 
• Use regional SMSCs 

Causes: 

• Wrong keys or secure channel desync 
• SIM firmware not supporting certain STK commands 
• ICCIDs not loaded correctly 

Mitigation: 

• Validate SC signatures 
• Synchronize counters 
• Ensure correct ISD configuration 

Causes: 

• No data session 
• Firewall or APN blocks 
• TLS handshake failures 

Mitigation: 

• Validate APN 
• Check DNS resolution 
• Test certificate chains 

Causes: 

• Interrupted update 
• OS/app incompatibility 
• Power loss 

Mitigation: 

• Use phased/staged rollouts 
• Implement atomic file operations 
• Maintain rollback capabilities

Causes: 

• Applet not supporting dynamic rules 
• Counter mismatch 
• Operator table restrictions 

Mitigation: 

• Force SIM refresh 
• Validate applet version 
• Update applet via RAM 

1. Use BIP/HTTPS as the Primary Bearer When Available

Reduces cost and increases success rates. 

2. Plan Regional Rollouts in Phases

Minimizes impact and ensures high stability. 

3. MaintainStrong Key Management 

Rotate keys regularly and ensure secure channels comply with GlobalPlatform. 

4. Define Clear Rollback Paths

Especially for critical applet updates. 

5. Combine OTA with QoS Metrics

QoS insights help identify when: 

• SIMs fail to attach 
• Devices lose signaling 
• Networks change coverage patterns 

OTA then executes corrective actions. 

6. Maintaina Unified Inventory of SIM/EUICC States 

Critical for operators managing millions of devices.