Open Service Access Protocol for IoT Smart Devices

Preface With the development of IoT technology, everything is widely interconnected and deeply invole with human-machine interaction. This includes various innovative applications such as autonomous vehicles, telemedicine, smart factories, smart cities, and more. However, as businesses grow, the adoption of different data descriptions and service access methods by mass IoT data, devices, businesses, and services leads to fragmentation issues. These fragmentation issues can be observed in the form of data heterogeneity, device heterogeneity, and application heterogeneity. Unfortunately, these issues hinder the development of the industry. The main challenges that arise from this fragmentation are:

Low value of data: IoT data has the characteristics of multi-source heterogeneity and huge scale, making it difficult for data analysis and sharing. At the same time, the lack of business relevance between massive amounts of data leads to inefficient use of data.
High cost of business replication: different devices use different access standards. The cost of device access is too high and the time is too long. With the growth quantity of applications and devices, new device needs to be customized and developed multiple times for different standards, resulting in increased business replication cost.
Difficulty in industrial chain cooperation: There are different access protocols and data models between different manufacturers. The internal industrial chain has its own system, which makes it difficult for industrial chain to collaborate, for devices to be linked, maintained, for service to be compatible, Which seriously affects the user experience.

In order to solve the problem, this draft proposes the requirements for IoT smart devices to transmit and control, as well as transmission and protocol interfaces. It is for the program design, system testing and acceptance, and related research. Structured, unified, and standardized open service interconnection model reduces business replication cost and removes service barriers to push industrial development.

Requirements for Consistency

Terms and Definitions

Area A set of related functions, which is business independent.

Attribute Used to describe the sustainable state of the devices during operation, which can be read and set.

Operation A method that can be called externally by a device or platform. The operation includes "input parameters" and "output parameters". The input parameters are the instruction information that needed to perform the operation, and the output parameters are the feedback information after the instruction is executed.

Event Information actively reported by the device. This type of information needs to be reported in real time and processed by the platform in time. If the device network is interrupted, it can be cached and reported after recovery.

Resource An entity that is a relatively independent component of the device and can independently handle user requirements. User applications can independently show or manage the resources of the device. For example, the video channel of NVR device.

IoT Device Management Platform A system that connects a large number of diverse and heterogeneous sensing devices and can unify access management of devices, collect, process and store data.

Load Balancing Service Responsible for equipment certification. The device actively authenticates to the load balancing service. After passing the authentication, the device will balance the load to multiple devices to access the service through redirection.

Device Access Service Services for managing, controlling and configing device functions and support attributes, operations, and events.

Picture Service Responsible for image storage services, support upload, download images and other functions.

Video Service Responsible for media data transmission, support real-time preview, video playback, voice intercom and other functions.

Event Service Responsible for receiving and handling events.

IoT Smart Devices Physical entities with video, image, and information perception capabilities, including: video equipment, access control, radar, etc. It can be directly connected to the IoT device management platform, or be a gateway that connects the agent sub-device and the IoT device management platform.

Abbreviations and Acronyms Abbreviations and Acronyms

Abbreviations and Acronyms	Full Name
IP	Internet Protocol
JSON	Java Script Object Notation
MQTT	Message Queuing Telemetry Transport
TLS	Transport Layer Security
UTF-8	8-bit Unicode Transformation Forma
URL	Uniform Resoure Locator

IOT model construction

Model Design Principles

Simple The model is independent of network technology and operator protocol, and focuses on the virtualization description of the device itself, which simplifies the understanding process of the device manufacturer.

Pervasiveness It is compatible with the needs of more manufacturers as much as possible. The model is divided into public attributes and specific attributes. The device can have public attributes or include self-defined features of the device. and Provide industry model templates by industry.

Extensibility Support user-defined services, provide data transparent transmission mechanism, and define basic model capabilities and industry templates separately. Modularity: reduce duplicate resources, extract public services for reuse, and improve utilization efficiency.

Ease of use Provide more easy-to-use interfaces, including DSL language model description for integration.

Framework of Device Communication Protocol The framework of the protocol is shown below:

Interface protocol structure In this draft, the session channel interface adopts MQTT protocol. Structure of MQTT protocol is divided into three sections: fixed header, variable header and payload. Structure of MQTT protocol is shown below.

MQTT protocol structure --------+---------------------------+----------------------------------- | | | Header | Payload Structre|------------+--------------+----------------+------------------ | | | | |Fixedheader |Variableheader|GeneralPayload |ApplicationPayload --------+------------+--------------+-------+--------+------------------ Name |Fixedheader |Variableheader|Length |Content |Content --------+------------+--------------+-------+--------+------------------ Symbol |FixedHEADER |VariableHEADER|LEN |Gernal |Func --------+------------+--------------+-------+--------+------------------ Length |2-5 Bytes |Variable |2 Bytes|Variable|Variable --------+------------+--------------+-------+--------+------------------ Des- |Depending |Different |The |See |The format cription|on the |control |length |defi- |depends on |length of |message has |of |nition |specific |the variable|different |general|for its |transaction |header and |variable |payload|format | |payload, the|headers | | | |length of | | | | |the fixed | | | | |header | | | | |varies | | | | |between 2 | | | | |and 5 bytes | | | | --------+------------+--------------+-------+--------+------------------ General protocols and business protocol bodies need AES (128) encryption during transmission, and UTF-8 encoding is used uniformly for character strings.

Device certification The overall protocol format of the authentication process is shown as follows:

MQTT protocol format --------+--------------------------+------------------------------------ | | | Header | Payload Structre|-----------+--------------+-----------------+------------------ | | | | |Fixedheader|Variableheader|GeneralPayload |ApplicationPayload --------+-----------+--------------+---------+-------+------------------ Name |Fixedheader|Variableheader|Version |Con+ | | | | |tent | --------+-----------+--------------+---------+-------+------------------ Symbol |FixedHEADER|VariableHEADER|PROTOCOL-| |PROTOCOL- | | |VERSION |Func |VERSION | | | | | --------+-----------+--------------+---------+-------+------------------ Length |2|5 Bytes |Variable |3 Bytes |Va- |3 Bytes | | | |riable | | | | | | --------+-----------+--------------+---------+-------+------------------ Des- |Depending |Different |The |See |The cription|on the |control |version |tran- |version |length of |message has |of |saction|of |the |different |protocol |for its|protocol |variable |variable | |format | |header and |headers | | | |payload, | | | | |the | | | | |length of | | | | |the fixed | | | | |header | | | | |varies | | | | |between 2 | | | | |and 5 bytes| | | | --------+-----------+--------------+---------+-------+------------------ The protocol version definition is shown as follows: Protocol version definition

Name	Type	Description
FORM_VERSION	char	version number of protocol form
HIGHTYPEVERSION	char	version number of protocol type(high)
LOWTYPEVERSION	char	version number of protocol type(low)

Device access adopts bidirectional negotiation protocol process. Devices sends the supported type of protocol group to the balance load service, and the server will determine which way to communicate depending on its own situation. After the device being authenticated, it can establish an MQTT connection with the device access service (Das) through the sessionkey to communicate with the bussiness protocol. The specific bidirectional negotiation diagram is as follows:

First Authentication +------+ +-----------+ |Device| |Lbs Service| +------+ +------+----+ | | +-----------------Private key Exchange------------------------+ +-----+ | | |Generate Private Key and Publickey | <-----+ | +-----+ | | |Generate Share Key | <-----+ | |-------Request for Private Key Interaction-------> <-------Reponse for Private Key Interaction-------+ +-----+ | | |Decrypt lbs_publickey from Response | <-----+ | +-----+ | | |Generate Mater Key | <-----+ | +-------------------- Apply DevID----------------------------+ |-------| Request for Applying DevID |------------> <---------Reponse for Applying DevID--------------+ +-----+ | | |Decrypt DevID and Session Key from Response| <-----+ | |---|Request for Getting Das Service Address------> <----Reponse for Getting Das Service Address------+ | | + + b) Re-authentication When the device is disconnected and ask for re-authenticated, it needs to request re-authentication from the platform and update the session key. The specific process is shown as follows:

message direction	control message	name	description
Dev<--->Lbs	0x1	AuthenticationECDHReq	request for ECDH exchange
Dev<--->Lbs	0x2	AuthenticationECDHRsp	response for ECDH exchange
Dev<--->Lbs	0x3	Rsrv	reserve
Dev<--->Lbs	0x4	RefreshSessionKeyReq	refresh SessionKey request
Dev<--->Lbs	0x5	Rsrv	reserve
Dev<--->Lbs	0x6	RefreshSessionKeyRsp	refresh SessionKey response
Dev<--->Lbs	0x7	Authenticationapplydevid_Req	request device ID
Dev<--->Lbs	0x8	Authenticationapplydevid_Rsq	response device ID
Dev<--->Lbs	0x9	Authenticationapplydevid_Cfm	confirm device ID

Get access service As the number of device accesses increases, there will be bottlenecks in the performance of single-node accesses, so the platform needs to support the mode of multiple device accesses. To support this mode, the devices are redirected to multiple access services by a load balancing server. After the device obtains the session key through two-way authentication, it initiates a request for access service within the same TCP connection, and the message in the request is encrypted with the session key.

Registration and Deregistration After the device completes two-way authentication to obtain a specific access service address, the device initiates a request to register online through the MQTT protocol, and the application message body in the request is encrypted using the sessionKey obtained by two-way authentication.

Registration and Deregistration +-------------+ +------------+ | Device | | Platform | |(MQTT Client)| |(MQTT Sever)| +-----+-------+ +------+-----+ | | +------- F1:Device register and login(MQTT CONNECT) -------> | | <-------- F2:Register and respond(MQTT CONNACK) -----------+ | | <---------------- Business interaction --------------------> | | +---- F3:Send request for disconnect(MQTT DISCONNECT) -----> | | + + a) F1: After the device and platform network connection is established, the device sends a online request to the platform via MQTTCONNECT, of which payload contains one or more encoded fields, including: unique identifier of the client, Will subject, Will message, username and password. b) F2: The platform returns the response message to the device via MQTTCONNACK to inform it whether it succeeded or not; c) F3: Before disconnecting, the device sends a DISSCONNECT message to the platform, indicating that it wants to disconnect normally, and the platform will close the TCP/IP connection after receiving the request.

Heartbeat After the device has registered with the platform, it needs to send heartbeat requests periodically according to the heartbeat interval indicated in the registration request. The interval is usually 30s. Used for: a) Inform the platform that the device is alive when no other control messages are sent from the device to the platform. b) Request the platform to send a response confirming that it is alive. c) Use the network to confirm that the network connection is not disconnected.

Security Considerations This entire memo deals with security issues.

IANA Considerations This documents has no IANA actions.