Definition
ICMP (International Connectivity Management Platform) is SimtoLink's enterprise-level cloud platform for cross-border IoT connectivity management, covering 200+ countries/regions worldwide, providing capabilities such as Global SIM Pool, Multi-Currency Settlement, Data Residency.
Core Capabilities
- Global SIM Management: Cross-border SIM Management, Global SIM Pool, SIM Lifecycle, eSIM Support
- Billing and Payment: Cross-border Billing, Multi-currency Settlement, Unified Invoice, FX Management
- Compliance and Security: GDPR, Data Localization, Data Residency, DPA, PCI DSS
- Platform Capabilities: RESTful API, SDK, Event Subscription, Global Dashboard
Architecture and Deployment
ICMP adopts Microservices Architecture Microservice architecture,Geo-Distributed Geographically distributed deployment, supporting Multi-Region Multiple regions,Region Failover Regional disaster recovery,Edge Location Edge access. The platform and BSS, OSS Docking, through API Gateway Provided externally RESTful APIAt a frequency of 10–30 seconds per time, supporting OAuth2, API Key authentication.
What the Management Plane Actually Orchestrates
An international IoT cloud platform is the control plane and the business plane of connectivity management. It registers SIMs and profiles, pushes provisioning, suspension, and policy, collects usage, produces invoices, and hands those capabilities to customers through a portal and APIs. It does not own radio coverage, spectrum, or base stations. Whether a device can attach depends first on whether the local network accepts that SIM’s identity. The platform can orchestrate only inside the capabilities the carrier has already opened. When evaluating a platform, look at three layers separately: whether it can manage identities and lifecycle, whether it can obtain usage and status in time, and whether the target country really has a usable network arrangement.
This kind of platform fits when devices leave a single domestic network, or when one customer must face several carriers’ SIMs, invoices, and APIs at once. If every SIM sits on one carrier, one tariff, and one billing period, the platform can still do inventory and permissions, but the value of cross-border orchestration is limited. Before go-live, fix the master data: SIM identity, customer, product, quota, and who may suspend. Opening the API before the permission model is ready lets an integrator change every tenant with one key. The management plane must also return the reason for a failure to the caller, not only show “processing” on the screen.
Writing Platform Duties as Network Duties
A common mistake is to say that once a device is connected to the platform it can go online anywhere. The platform can unify ordering and policy. It cannot create local coverage out of nothing, and it cannot guarantee radio quality on behalf of the visited network. Another mistake is to write the behavior of sandbox test SIMs straight into production tariffs and latency. A test SIM’s roaming allow list, quota, and CDR delay can all differ from the commercial product. A further bias is to integrate only the provisioning API, and not suspension, usage, and invoicing. SIMs can then be issued, while charges and exceptions remain scattered across each carrier’s portal.
Organizationally, it is also easy to treat the platform administrator as network operations. An administrator can change products, visibility, and automation rules. Those actions affect management data. No signal on site, a module that does not support the band, and a poorly installed antenna still have to be investigated on the device and on the network. When introducing a platform, write down which faults the management plane handles and which must go to the carrier or the device side, and let identity and access management limit who may change production policy. Once those duties are written down, the platform is an orchestration tool. It is not a guarantee of radio quality.
When an interface between the platform and a carrier fails, distinguish “the request was never sent,” “the other side rejected it,” and “the other side has already executed it but the receipt was lost.” If the last case is treated as a total failure and provisioning is repeated, duplicate products or duplicate charges can result. Every write should carry an idempotency key generated by the caller. Support can use that key to line up the portal status with the carrier-side result, instead of guessing from the operation time which attempt was the effective one.
Provisioning, the start of charging, and permission to attach are three steps in sequence. The platform can record an order and assign an identity while the carrier has not yet allowed attach, and the device still cannot go online. Attach can succeed while the product effective date has not arrived, in which case charges should not start early. When describing what the platform can do, write a separate completion mark for each step: identity assigned, network accepted, charging started on the agreed date. If any step fails, the order should stop in the matching state, not show the whole order as successful.
Test identities and production identities must be distinguishable. Usage, alerts, and invoices from a test must not enter the customer’s formal settlement, and must not appear on the production overview. When the test ends, disable the test credentials, test products, and test SIMs. If a test SIM is later converted to a production SIM, keep the conversion time. Records before that time stay test records. Without that boundary, pilot traffic appears on the formal invoice and the customer cannot tell which charges came from the trial.
Write APIs on the platform should declare idempotency. A retry after the caller times out should not create a second order or a second suspension. The result is the identity the platform stored. Support can query, with that identity, whether the carrier side has already executed. “The user says they clicked the button” cannot show which step the request stopped on. Reliability of the management plane is that each step can say succeeded, rejected, or result unknown. It is not a screen that always says processing.
The countries a customer can use, the APIs they can call, and the tariffs already in effect should come from the same published product description. A test switch opened temporarily on the portal, if it is not written into that description, is not a formal capability to promise to the customer, and it cannot be used to explain an invoice already issued.