Definition
Device Access (device access) is the entry point of the IoT system, providing a unified access layer. It supports MQTT, CoAP, LwM2M, HTTP, and other protocols, with dual modes of direct connection and Edge Gateway proxy, supporting millions of concurrent connections.
Access modes
Direct Connection Mode: Devices connect directly to the cloud access layer through protocols such as MQTT, CoAP, LwM2M, suitable for scenarios with IP capability and controllable power consumption. Gateway Proxy Mode: Edge gateways or Edge Gateway aggregate sub-devices (such as Modbus, ZigBee, etc.), and after protocol conversion, connect uniformly, suitable for non-IP devices in industrial sites, buildings, etc. Both modes can coexist, and the platform automatically routes based on device type.
Protocols and Extensions
Mainstream protocols include MQTT (low-power, bidirectional communication), LwM2M (lightweight, suitable for NB-IoT), HTTP/HTTPS (simple reporting). Through the Protocol Adaptation layer, industrial protocols such as BACnet, Modbus, OPC UA can be extended. The access layer needs to support TLS/mTLS, Device Authentication to ensure connection security.
High Availability and Scalability
The access layer adopts a distributed architecture, supporting horizontal scaling to handle massive connections. It is necessary to consider connection keep-alive, reconnection after disconnection, message QoS levels, rate limiting, and circuit breaking mechanisms to ensure stability and observability under high concurrency and network jitter scenarios.
Where direct and proxied connections each get stuck
Device access means opening, for a terminal or a gateway, a session that can be authenticated, kept, and rate-limited, and handing the uplink and downlink on that session to the device record behind it. Direct connection requires the device itself to have a routable network and a protocol stack, to finish the handshake, and to keep alive as agreed. With a gateway proxy, the gateway holds the session. Child devices appear only on a field bus or a short-range link. Online as the platform sees it is often the gateway being online. Whether a child device can communicate still depends on the mapping behind the gateway. The two modes can exist together, but a child-device identifier and a gateway identifier must not be written as the same connection object. Otherwise a gateway restart is counted as every child device joining again at the same time.
Choose direct connection when the device can store its own authentication material safely, and when power and traffic allow it to keep a session or to open one on a schedule. Choose a proxy when the child device has no wide-area network of its own, or must keep a bus the site already has. Before access, the product declares the protocol, the port, the keepalive method, and which properties in the thing model travel on this session. Until authentication material has been issued, the device should not be marked as ready to connect. After the session is up, the topic or resource path must be bound to the device identifier, so one device cannot publish data onto another device’s uplink path.
When the protocol is right but the session still will not come up
An open port only means the network is reachable. It does not mean access succeeded. A certificate name that does not match the access address, a clock skew large enough to fail certificate checks, or a device using a product identifier from another environment all disconnect during the handshake. The symptom is connecting again and again and dropping at once. Another class of mistake is a keepalive shorter than the idle reclaim time of the carrier or of an intermediate device. The session still exists on the platform side, and actual messages no longer arrive. Or the keepalive is too long: the device has long since lost power, and the platform waits a long time before marking it offline. If rate limiting counts connection attempts rather than devices, a terminal reconnecting normally is knocked off as an attack.
With a gateway proxy, a child-device address that changes without an updated mapping means the platform still delivers downward to the old address. The command shows as sent, and the site does nothing. If a directly connected device is wrongly registered as a child of some gateway, its own session is ignored. Correct device credentials are not enough if the product has been disabled, or if the device is in a lifecycle stage that does not allow connection. The access layer should refuse, not connect first and drop the traffic in the business layer. The refusal reason must distinguish network, authentication, and policy. Otherwise investigation stays on changing the antenna and changing the card.
A gateway online does not mean its child devices can communicate
With proxied access, the session between the platform and the gateway only proves the gateway is still there. Whether a child device can still answer on the field bus has to be reported separately by the gateway. Copying “gateway online” onto every child device leaves the console showing a whole area as normal after the bus breaks, while delivered commands sit inside the gateway. The reverse is also true. A brief gateway reconnect should not record every child device as joining again, or join counts and alarms are amplified. The child-device identifier, the gateway identifier, and the address on the bus are three different things. When the address changes, the mapping must be updated. The platform must not keep sending commands to the old address. If a directly connected device is wrongly registered as a child of some gateway, the session it opened itself is ignored. The symptom is correct credentials and a device that is never online.
When a connection is refused, separate the reasons. Network unreachable, authentication failed, product disabled, and lifecycle not allowing connection are handled by different people. A single disconnect makes the site replace the antenna again and again. Keepalive should be longer than the normal silent cycle, and not so long that the device still shows online long after power is lost. Rate limiting should count by device, not by every reconnect. A normal retry on a weak network should not be knocked off as abnormal traffic. After the session is up, this device may publish only on its own uplink path. It must not write into another device’s record because the topic spellings are close. The access layer’s job stops at handing over a reliable session. Whether the business is reasonable is still judged by the model and the rules behind it.