SimtoLink: One APN for a fleet of roaming SIMs

Multi-APN failover means two or more access point names (APNs) are preset on the same IoT SIM or the same terminal. When the data bearer on the primary APN fails a probe, stays unresponsive for a long time, returns a specific error code, or hits a policy trigger, the terminal or the application stack automatically switches to a backup APN and starts a packet-data connection again. The aim of link redundancy is that, when a single path fails (private-network gateway down, DNS blackhole, core-network cutover, or a regional routing outage), the service can still recover over the backup path and fewer devices in a batch go offline. Unlike a consumer phone switching to Wi-Fi for internet access, IoT cases often involve device-SIM binding, fixed addresses, allow lists, and split billing, so an APN change is not only a string edit. It also involves address ranges, authentication, and billing items. On the IoT SIM side, the carrier must enable multiple PDP or PDU sessions, or allow different APNs to be activated in sequence. If a card policy allows only a single default APN, so-called multi-APN cannot be realized on the live network. Before a redundancy design, the subscription context in the HSS or UDM and a live-network test report must be requested from the card provider. Failover is not load sharing: the former is a failure-driven switch, the latter is parallel splitting. This article focuses on primary-backup logic in a failure case, and keeps it separate from concurrent multi-path balancing.

Technical points

Implementation falls into three kinds: switching by module AT commands, multi-bearer management in the operating system, and dual sockets with custom probes at the application layer. On LTE, a single default bearer plus dedicated bearers is common. If primary and backup are mutually exclusive, the old bearer must be released before the new one is set up, and there is an interruption of seconds. On radio types with limited concurrent bearers, such as NB-IoT, a multi-APN policy has to fall back to trying APNs in sequence rather than a hot standby in parallel.

Probes should combine ICMP, the TCP handshake, an application heartbeat, and DNS resolution, so a brief jitter is not treated as a link failure and does not cause frequent switchover. Switching too eagerly can surge signaling on the core network and can even be rate-limited by a carrier risk-control policy. Exponential backoff and a minimum stable time window are recommended. After the primary path recovers, a hysteresis delay can be set before switching back, to avoid oscillation.

A private-network APN often connects to the customer's LNS or VPDN, while a public backup APN exits to the internet. The two address spaces differ, so the platform must let a device register the same device ID from different source addresses, or trigger re-registration after the switch. NAT port-mapping changes affect short-connection services. Long connections must be rebuilt after the switch.

IoT SIM and platform configuration

Confirm with the card provider whether the backup APN can be activated under the same IMSI, whether it is billed separately, and whether regional roaming is restricted. If the primary APN assigns a static private address, the backup APN may become a dynamic public address, so the platform firewall and ACL need a plan for both. A connectivity management platform can keep a view of card number, primary and backup APNs, and the bearer currently active, so a ticket system can locate the issue quickly.

For customers in critical industries, the preferred and secondary APN list can be written into the card template and pushed to module NVRAM by remote configuration. After an eUICC profile change, the APN list may be replaced as a whole, so failover logic should be managed with the profile version. Logs should record the switch reason code, duration, and failure count for SLA reports. When this is combined with VPDN, confirm whether the backup path still needs a tunnel, so a half-tunnel state does not create a blackhole route.

Use cases

Connected vehicles, mobile payments, industrial gateways, and remote-care terminals, and other cases that are sensitive to continuity, often use a private network as primary and the public network as backup, or carrier A as primary and carrier B as backup (the latter usually needs dual SIM or eUICC). During a large event, when traffic on a batch of smart-city terminals surges, they can also switch temporarily to a backup APN and split traffic onto a different core-network pool. SimtoLink provides a plan that links SIM provisioning, APN policy orchestration, and the connectivity management platform, so multi-APN failover moves from a scripted attempt to a manageable production capability.

Source: https://www.simtolink.com/support/sim/sim-multi-apn-failover.html