Cloud IoT Core concept

Service Structure

If a message is sent from a user's device to Cloud IoT Core, Cloud IoT Core checks if the user is reliable and then receives the message. The message can be immediately sent (issued) to another device right after being checked in real time. In addition, when a message meeting the conditions defined by the user is sent using the rules of Cloud IoT Core, you can also integrate cordless services such as Cloud Functions in the NAVER Cloud Platform.

Figure 1. Cloud IoT Core service structure

How the service works

How IoT devices work through Cloud IoT Core is as follows:

Figure 2. How IoT devices work

Sensor information collected by an IoT device is transmitted to Cloud IoT Core as JSON-format data using the MQTT protocol. Cloud IoT Core processes the data in real time and transmits the data to the integrated services or executes an action preset by the user.

The server configuration of the Cloud IoT Core is as follows:

Authentication Server: Issues and manages a certificate in the format of the X.509 to be installed on the device of the user, and authenticates the device of the user and supports security communication.

Message Server: Supports the MQTT protocol, receives MQTT messages sent from the user, and forwards them to the real-time processing server. For security reasons, messages are managed in a separate area for each user.

Real-Time Processing Server: Inspects if the sent message meets an operation defined by the user in real time. If the message meets the conditions, the real-time processing server executes the operation defined by the user.

MQTT Protocol

The Message Queue Telemetry Transport (MQTT) protocol is a lightweight message protocol frequently used for building an IoT system since it operates in even underperforming equipment. The message structure is configured by Topic that can classify messages and Payload that can transmit data. A user performs the operation of Publish to transmit a message based on Topic and the operation of Subscribe to receive a message. You can randomly specify and set a topic to send data without additionally registering it. For example, if User A sends data to the message server for a topic named mynews, users (subscribers) who subscribed to the mynews topic can receive the messages sent by User A. You can also use a topic with a hierarchical structure by using a slash (/), such as mynews/sport, mynews/media, mynews/weather.

Virtual Device Mirror

The virtual device mirror is a concept for conveniently managing and operating an IoT device on the cloud. Using the "mirror" feature provided in the virtual device will enable reading and saving virtual device status information from the cloud. To transmit and store IoT device data to the cloud, you need a separate storage space. If you use a virtual device mirror, you can store and import an IoT message in the basic storage space provided for each virtual device. For example, if you create a virtual device named "temperature sensor" and send an MQTT message from the temperature sensor device to the temperature sensor virtual device mirror of Cloud IoT Core and set it to store temperature data, you can access the saved data again in the control system or a smartphone application. In addition, even if the IoT device is disconnected due to a network error or power instability, you can import the saved data in the virtual device mirror when the IoT device is reconnected, so you can easily restore the last status value of the IoT device. For instance, if you store the status of a light bulb being on (On) in a virtual device mirror, you can restore the light bulb into a status of being on (On) by importing the most recently saved status information of the light bulb (On) in the virtual device mirror when the IoT device is reconnected to the cloud.

Exclusive Topics of Virtual Device Mirror for MQTT

To control the virtual device mirror by an MQTT message, exclusive topics for MQTT are used.

'DefaultMirror' topic: A mirror that does not require the user to designate a mirror name separately. It is automatically displayed as "DefaultMirror" on the console of the NAVER Cloud Platform. Only one can be created for each virtual device.

Publish topic: $ncp/device/{virtual device name}/mirror/{action name}
A topic to be subscribed after mirror is published: $ncp/device/{virtual device name}/mirror/{action name}/accepted or rejected

Named mirror topic: It refers to all virtual device mirrors excluding the "DefaultMirror." Used for using several mirrors for the virtual device or managing a mirror with a specific name. You can create up to 10 mirrors for each virtual device, and each mirror works independently.

Publish topic: $ncp/device/{virtual device name}/mirror/name/{mirror name}/{action name}
A topic to be subscribed after mirror is published: $ncp/device/{virtual device name}/mirror/name/{mirror name}/{action name}/accepted or rejected
Action name: The action name includes get (to check content), update (to create and update), and delete (to delete).

Note

If they are not exclusive topics for the virtual device mirror, they are operated as general MQTT messages, not as mirror features. This guide is based on the DefaultMirror topic.