Definition
Push refers to a communication method where the server actively sends messages to the terminal (device or App), as opposed to polling. In push mode, the terminal can receive fault alarms, telemetry signals, remote upgrade commands, out-of-bound pushes, and other content without actively requesting it. Push can be implemented through MQTT, CoAP, HTTP long connections, APNs/FCM (App push), and so on. In IoT scenarios, push is used for Device Management Platform to issue remote lock, firmware upgrades, configuration updates, and so forth.
Compared with polling, push offers higher real-time performance and reduces unnecessary requests; however, it requires the terminal to maintain a long connection or support wake-up. In cross-border scenarios, push needs to consider multi-country networks, one card multi-country connection stability, and compliance requirements such as GDPR (e.g., user consent).
Technical Features and Architecture
The push technology architecture includes: Connection Layer — Establishes a long connection between the terminal and the platform (MQTT, WebSocket, etc.) or through carrier channels (SMS, APNs); Message Layer — The platform generates push messages, supporting event triggers and scheduled pushes; Routing Layer — Routes to the target terminal based on device ID, groups ; Wake-up Layer — Sleeping devices need to be woken up via SMS, Paging, etc., to receive pushes. Combined with cross-border push , scenario-based pushes can be triggered based on location ; combined with telemetry can issue remote control commands. In cross-border scenarios, push channels need to support coverage in multiple countries.
IoT push is often combined with ACK acknowledgment mechanisms to ensure reliable delivery of commands.
Application in IoT and cross-border scenarios
Push notifications are widely used in: Alerts and Notifications——Fault Alerts, Abnormal Alerts, Boundary Alerts real-time push; Remote Control——Remote Device Lock, Telecontrol, Remote Upgrade command issuance; Scenario-based Services——Boundary Push, Charging Station Promotional Push; OTA and Configuration——Firmware Upgrade, Firmware Package Push, configuration issuance. Cross-border charging networks, global logistics, and multinational device management all rely on push notifications to achieve real-time alerts and remote control, One Card Multi Country ensures cross-border push reach.
SimtoLink provides stable connectivity for IoT devices in push scenarios, covering over 200 countries and regions, supporting cross-border device management, charging stations, and other scenarios.
A Push Arrives Through Wakeup, Payload, and a Receipt
A push is the server sending a message to the terminal when something has happened. The terminal does not have to ask first. The message may be an alert, a lock, a parameter, or a notice that new firmware is available. Arrival has three steps. The terminal needs a path that can receive the message, the payload has to fit on that path, and the terminal has to return a receipt after it acts. The path may be a long connection that is still up, or an SMS or page that wakes a sleeping device before the data channel collects the body. On cross-border cellular, a long connection is often torn down by the visited network's idle policy. A design that has only the long connection, and no wakeup, leaves an offline device unable to receive a command.
Separate the notice from the body of the payload. A short command, such as a lock or a change of report period, can sit in the message. A firmware image and a large configuration do not fit a push channel. The message carries only the version number and a fetch address, and the device downloads when power and signal allow. A receipt must say the device has executed the command, not that the platform has handed the message to the operator. Operator acceptance of an SMS only means the SMS entered the message center. A device write-back of locked or refused is what shows the action had a result. A command with no receipt should stay in flight, with a rule for whether timeout means resend or handoff to a person. It must not be changed to success on its own.
Conditions for Sending a Control Push
A control push may be sent when the device identity matches the message target, the wakeup path is open on the current visited network, the payload is shorter than that path's limit, the command has a unique sequence number for deduplication, and the device has a local constraint on dangerous actions. A charger in session, for example, may refuse an immediate reboot. A push the user can see must also stay inside the scope the recipient has already agreed. Do not keep a domestic app-store push token just because the device is abroad. If the device is permanently offline, the push should expire on the platform instead of retrying without limit and accumulating SMS cost. The same business after expiry needs a new sequence number and a fresh approval, so an old command is not executed months later when the device suddenly comes online.
Recording Success When There Is No Receipt
A common mistake is to treat send as success. The device in the field is still running the old parameter, and later bills and alerts are interpreted with the new one. Another is a sleeping device with no wakeup. The command lives only in the queue of the long-connection server, and a queue restart loses the message. A third is a repeated push with no sequence number, so the device starts twice or locks twice. Pushing a large package straight down a roaming link breaks halfway. The device verifies the fragment as an image and then retries. A fourth is a receipt sent before execution. The device only confirms received, and the platform reads that as done. The state machine should at least distinguish submitted, woken, execution confirmed by the device, refused by the device, and expired. Reconciliation uses the device's confirmation of execution. Write the refusal reason back to the ticket instead of pushing the same body again.
The command ledger keeps five results by sequence number: submitted, woken, execution confirmed, refused, and expired. An expired command must not run automatically when the device comes online weeks later. SMS wakeup and the data channel use different arrival tests. Acceptance by the message center is not execution. A large-package task pushes only the version number and the address. The download result is a separate record, not mixed into the notice as one success.