BMDD: a novel approach for IoT platform (broker-less and microservice architecture, decentralized identity, and dynamic transmission messages)

Industrial internet of things

The Industrial Internet of Things (IIoT) is a network of sense, management, and communication devices collaborating to attain common goals while satisfying the industrial environment’s requirements (Panda et al., 2020). To increase the safety and effectiveness of industrial processes, IIoT integrates several technical types of equipment (e.g., sensors, communication equipment) (Tran, Yu & Riedl, 2020). Also, IIoT is commonly used to collect, process, and transmit data from industrial environments for both centralized (Lewandowski et al., 2020) and decentralized (Luchian et al., 2021) architectures.

Research in Quirós, Cao & Canedo (2020) designed a dynamic reprogramming about IIoT-applied devices based on distributed automation. This paper allowed the allocation of computational tasks on the channel based on each node’s specific role and context. Some Coaty solutions’ applications for collaborative IIoT were presented in the studies of Seitz et al. (2018a, 2018b). These modules introduce augmented reality (AR) and blockchain-based application markets in an industrial circumstance. Edge devices were categorized by their available resources, the apps and the services they could access. Blockchain acts as a technology that allows application traceability validation to ensure transparency for the whole system. Chenaru et al. (2015) debated the integration of wireless sensor networks with cloud systems as back-end infrastructure supporting complex monitoring. Meanwhile, the fog computing model have been used to exploit on-node computing resources to efficiently utilize the restricted radio communication channels (Mihai et al., 2018). The work in Stamatescu, Stamatescu & Popescu (2017) presented the consensus algorithms that might represent a possible solution for distributed computing. Localization models could be built on the gathered data for online inference in numerous process summaries such as energy management (Stamatescu et al., 2019).

These proposed approach provided a real-time, deterministic, and re-programmable network behavior that the system used to leverage device capabilities and to schedule the computation workloads in the network while providing real-time guarantees. The novel runtime systems also made them possible to execute dis-persible code in existing off-the-shelf devices leveraging currently evolving technologies.

However, in the above approaches, the connections between the actors were loosely coupled, and it did not need an entity to manage the communication among them. This potential affects the entire system if a malicious user might take over a device and led to a collusion attack (Yassein et al., 2017). For instance, IoT devices are very vulnerable to malicious users or hardware devices such as node detection, corruption, eavesdropping, denial of service attacks, and routing attacks such as sinkholes and wormholes (Fang et al., 2020). Therefore, a decentralized identity mechanism is essential in the current IIoT environment.

Cyber-physical systems

Edward Lee proposed cyber-physical systems (CPS) to link virtual space and physical reality via the combination of networks, computers, and storage in National Science Foundation 2006 (Lee, 2006). In particular, CPS is an automated distribution system that integrated physical devices with a communication network based on a computer infrastructure platform (Wang, Törngren & Onori, 2015). The main focus of this protocol is on networking different devices in an IoT environment (Hermann, Pentek & Otto, 2016). It, therefore, includes a control unit that can regulate sensors and actuators, connect with the physical world, process the data obtained and swap them with other systems and/or cloud services by means of the communication interface (der Technikwissenschaften, 2011).

An important feature of CPS is its ability to obtain information and services in real-time (Boyes et al., 2018). Hence, CPSs have been applied to several areas, such as Healthcare (Liu et al., 2018), Smart Home (Shih et al., 2016), Transportation (Möller & Vakilzadian, 2016), and at most popular in Computers’ Network (Khan et al., 2016; Zanni, 2015). In other words, CPS could be thought of as a system that sent and received data from devices over a single network (Bagheri et al., 2015).

However, in addition to the listed advantages, CPS needs to consider its stability, trustworthiness, effectiveness, and security in operations (Cheng et al., 2016). With this in mind, one of the top priorities of CPS is to accommodate a high level of security supporting in all layers of the CPS architecture, guarding private data while also providing acute anonymity of data (Alguliyev, Imamverdiyev & Sukhostat, 2018). Besides, for the reliability of the CSP, the requests to send and receive data are also very important, where very small vulnerabilities can have huge consequences (Thanh et al., 2021c).

Microservice framework

Amazon offers AWS IoT Greengrass (OSGi Event Admin Service, https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.event.html) as a solution to migrate analytics capabilities directly to edge devices (e.g., smartphones). Essentially, it is a program that permits running AWS Lambda features locally once installed on an edge gadget. AWS Lambda allows the device to run code without provisioning or controlling servers. Microsoft Azure provides similar functionality to Azure Stream Analytics on IoT Edge (Maven, https://maven.apache.org/), enabling users to use near-real-time analytic functionalities by using Azure Stream Analytics on IoT-applied devices. Besides, Micro-Mu (https://micro.mu/) is an open-source microservices toolset, giving a full stack for building and managing small services. Micro-Mu supports APIs to query microservices used as gateways for external access using Transport Layer Security (TLS). Azure Stream Analytics is a complex event processing and real-time analytics engine. Like AWS IoT Greengrass, the working principle allows edge devices to locally perform Azure Stream Analytics rules. In addition, Google Cloud IoT (Ops4j pax url, https://ops4j1.jira.com/wiki/spaces/paxurl/overview) integrated the Apache Beam SDK (Senseioty, https://flairbit.com/senseioty-iiot-solution/), providing a rich set of session and windowing analysis primitives. It presented a united advancement pattern for defining and implementing data processing pipelines across various stream handling engines, including Apache Flink, Apache Samza, Apache Spark, etc.

For the limitation of these platforms, AWS IoT Greengrass neither provide any functionality to move Lambda calculation to and fro between cloud edge devices nor mix with exterior stream processing engines. Again, a limitation of the Azure Stream Analytics tool is that there is no mechanism for dynamically converting rules between the edge and the cloud. For the Apache Beam, this platform only supported core/cloud-appropriate extensible engines and it is not designed to support edge analytics.

Microservice application

Maia and associates (Simeoni et al., 2021) presented IRRISENS, which is designed based on microservices architectures used in agricultural environments to sense soil, crop, and atmospheric parameters. IRRISENS interacted with third-party cloud services to schedule irrigation and could control automatic irrigation. For their results, the proposed framework could add new devices (IoT) to the existing system. It also was possible to successfully expose the interaction model to clients’ applications. Moreover, security metadata was added to the description, stating what is needed for secure access to a thing. In this case, the Security schema (JSON Web Token Bearer) to be used in order to access to specific content that exposes how to access and interact with the Smart House resources. In addition, Pratama et al. (2019) introduced a smart collar based on microservices backend design for dairy cow behavior monitoring. The platform’s backend is created using the Microservices architecture idea, where each progress is isolated into services independent from one to another. Each service has specific tasks conveyed through the Rest API. This platform supports five services, namely Auth, Sensor, Monitoring, Learning, Front-end services. To a greater extent, Badii et al. (2019) have implemented a specific set of Microservices for IoT Applications in the Smart City context. Specifically, they carried out a Microservices set for Node-RED, enabling the formation of a great variety of new IoT applications for smart cities, including dashboards, IoT Devices, data analytics, discovery, and the corresponding Lifecycle. It has enabled the creation of a wide range of innovative IoT Applications for Smart Cities, involving Dashboards, IoT Devices, GDPR-compliant personal storage, geographical routing, geo-utilities, data analytics. The proposed solution has been validated against a large number of IoT Applications for the cities of Firenze, Antwerp and Helsinki. Therefore, to exploit these benefits, we apply the microservice architecture to design our proposed framework in IoT platform.

Encrypted data approaches

Research in Di Crescenzo et al. (2013) proposed PICADOR, a secure topic-based pub/sub-system through the proxy re-encryption scheme. Brokers re-encrypted the publications, the authorized subscribers then restore these publications’ plaintext in their systems. However, this re-encoding increases the computational cost dramatically at the broker point. The subject matter of each publication is shipped off the agent in plaintext, which could not fulfil the confidentiality assurance conditions of the participants.

A high-level study project on Content Centralized Networks (called CCNx or Named Data Network – NDN) based on the pub/sub system was introduced in Saadallah, Lahmadi & Festor (2012). CCNx uses a hierarchical naming approach (Jacobson et al., 2009) to organize data content. Unlike the traditional MQTT system relying on end-to-end delivery, CCNx exploits a broadcast-based to convey information rather than broker-based. However, this issue might not apply to malicious publishers; for instance, if a malicious publisher uses the fake labels or re-uses another publisher’s public key, the subscribers in CCNx may get the faulty publication.

To address this issue, Trinity (Ramachandran, Wright & Krishnamachari, 2018) was introduced as a blockchain-based distributed pub/sub broker. Specifically, Trinity checks the immutability of transactions in the same system by integrating the broker system in the same blockchain network. Trinity also addresses the ordering problems by using a blockchain-based system. However, authentication problems can seriously affect the security of the entire system, since a malicious device (e.g., malicious code, controlled by an attacker) could replace one benign device of the users that might seriously affect the security of the whole system (Tariq et al., 2010).

Lu et al. (2017) introduced a resolution to gather data while conserving the confidentiality of fog computing-enhanced IoT devices. Authors used a one-way hash string to authenticate IoT devices, then applied the Chinese Remainder Theorem to aggregate data generated by different IoT devices. They also took advantage of Uniform Paired Encryption to provide data security. However, their resolution applied a common privacy rule, differential privacy, to all IoT devices causing unintentional amounts of sensitive data to be accepted. Applying the access control model can solve this drawback, where only authorized objects can accessed data (Son, Dang & Massacci, 2017; Xuan et al., 2016).

Besides, Anusree & Sreedhar (2015) proposed a secure broker-less sub/pub system. In particular, this approach was proposed to use the Elliptic curve-based identification mark encoding algorithm; thereby, they effectively reduce the cost of encryption and decryption on the respective parties. In other words, thanks to the Elliptic curve-based encryption algorithm, the costs related to computation and communication costs no longer affect the whole system. However, the key privacy issues still existed and had not been addressed in such a mechanism (Thanh et al., 2021; Nguyen et al., 2021). Furthermore, complete encryption of the data generated by IoT devices is not strictly necessary since not all data is sensitive, depending on the usage context; for example, privacy-preserving in a healthcare environment (Duong-Trung et al., 2020a, 2020b) and cash-on-delivery (Ha et al., 2020a, 2020b).

In this article, to balance the above problems, we only apply Blockchain to build a DID model for authentication purposes. To protect the IoT data, we apply a decentralized mechanism based on a role-based access control model instead of encrypting all data.

MQTT protocol

MQTT (Message Queuing Telemetry Transport) is a small network protocol operating under the publish-subscribe mechanism according to ISO and OASIS standards (https://mqtt.org/). The main concepts of MQTT include MQTT broker, MQTT client (publisher and subscriber), MQTT topic.

MQTT Broker is the junction of all incoming connections from the client and is the center of systems that uses the MQTT protocol. The principal responsibility of the Broker is to receive messages from publishers, queue them, and then forward them to subscribers based on topics.

MQTT client is classified into two groups: publishers and subscribers, in which the prior is the message sender to the Broker and the latter is the message receiver from the Broker. A client can act as both a publisher and a subscriber on one or more specific topics.

The topic is a logical concept that MQTT uses to route messages sent from publisher to subscriber; for example, when the publisher sends a message to topic A, only topic A subscribers can receive the message. The model has the advantage that every user who subscribes to the topic receives a message from the publisher. However, sensitive data is considered an enormous weakness in terms of security.

Another concept of MQTT is Quality of Service (QoS). The MQTT protocol has three QoS levels including QoS-0, QoS-1, and QoS-2 which are defined as follows (Archana et al., 2020):

• QoS-0 (maximum one time): one packet is transfered to a destination up to once.

• QoS-1 (minimum one time): each packet is emitted to the destination at least once, expecting packet iteration to occur.

• QoS-2 (precisely one time): each packet is shipped to its target sole one time.

The transmission process of MQTT according to each QoS level (https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/) is shown as in Fig. 1:

Figure 1 indicates that transmitting a message with the highest accuracy (QoS-2) using the MQTT protocol requires at least four steps, which reduce the transmission speed, increase the number of connections as well as increase the energy usage. Although the article (Thanh et al., 2021) proposed a model combination between MQTT and message queue to make use of the quick transmission rate, the tiny energy consumption of QoS-0, as well as ensure the reliability of QoS-2, however, there is still a weakness that the publisher does not receive any notification to ensure the message reception. In addition, when the subscribers receive the messages, the MQTT protocol also does not support sorting them in order (Soni & Makwana, 2017), which can seriously affect the accuracy of the data.

In addition, MQTT has another noticeable concept, “keep-alive” (https://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over/), which is a function of the MQTT broker that allows maintaining the connection so that communication is available between the broker and the client. When the keep-alive time exceeds, and the client does not send any messages to the broker, the broker will disconnect from the client. At this point, the client must send a “PINGREQ” packet to notify the broker that it is still operating, requesting to reconnect, then the client can send the message to the broker. In a practical scenario with thousands of clients, the broker has to handle many PINGREQ packets that can overload the broker. The keep-alive feature allows optional maintenance of a constant connection between the client and the broker to reduce energy consumption. However, this feature also has the weakness of not ensuring system availability, especially in emergencies.

gRPC protocol

gRPC (general-purpose Remote Procedure Calls) protocol (https://grpc.io/) is an open-source system of superior effectiveness of the Remote Procedure Call (RPC) protocol improved by Google in 2016. The gRPC is constructed on top of the http/2 protocol, which contains multiple advancements over earlier forms to permit greater and more productive HTTP connections. The gRPC provides machine-to-machine (M2M) communication. One of the most important aspects of http/2 is multiplexing, allowing us to deliver and gain many packages in a sole connection in comparison with http/1.1 as illustrated in Fig. 2. This feature is one of the main advantages that make us choose gRPC as it allows the client to open a single connection and transmit a collection of different data to the server, which saves energy during data transmission. In addition, gRPC carries a wide variety of programming languages and is perfectly suitable for embedded devices (Karcher et al., 2020).

The gRPC protocol provides for four types of machine-to-machine communication (Indrasiri & Kuruppu, 2020) as in Fig. 3:

• Unary: This type is similar to conventional client-server communication. The client sends a request to the server; afterwards, the server processes and transfers the outcome to the client.

• Server streaming: In this type, the server receives a request from the client, after processing, sends back a stream of data to the client. The client will be notified when they reach the end of the data stream. The sequence of messages of every stream is ensured to be identical between client and server.

• Client streaming: Like server streaming, in this type, the client will be the side sending the data stream to the server. After reading and operating the required processes, the server delivers the response to the client.

• Bi-directional streaming: In this approach, data will be sent from both directions, client and server, independent from each other. Also, the client and server can deal with the data stream independently, meaning that when the client delivers information to the server, the server can conduct a particular task (while still accepting the messages coming from the client) and transfer the response back to the client (while the client is still conveying other messages).

There are some features that MQTT does not provide. Regarding the first benefit compared to the MQTT protocol, gRPC offers four types of machine-to-machine communication, which make it highly appreciated due to its suitability with the diversity of IoT applications. For example, when applying IoT in agriculture, the unary communication type is suitable to collect temperature data, similar to the ability provided by MQTT. However, considering the application of IoT for the medical field with many sensors working simultaneously, and each sensor may stream a bunch of data in a different period, the client streaming communication type is a better option than MQTT. Apart from that, with the ambition of building BMDD towards adaptation with many areas of IoT application, gRPC is the optimal choice since it provides a variety of communication forms. Moreover, a prominent advantage of gRPC over MQTT is that it guarantees message ordering in streaming data cases; both the sender and the receiver get notifications when the transmission is successful, which is probably a superiority.

Sidetree

Sidetree is a protocol that allows users to init, manage the global and unique PKI metadata controlled by their user. Thanks to the connection to the existing decentralized system such as Bitcoin, Ethereum, …, Sidetree protocol also has open, public, and permissionless and other properties.

Figure 6 elucidates the structure of Sidetree-based DID overlay network:

• Existing decentralized networks, such as Bitcoin, Ethereum, e.g., will be connected to SideTree via DID operations. The operations of DID consist of four main functions: creating, updating, recovering, and deactivating, responsible for querying, initializing, and updating data in the decentralized system.

• Sidetree protocol is organized into nodes located between the decentralized system and the CAS network, interacting with the decentralized network via operations according to predefined rules.

• CAS (Content-addressable storage) stores and distributes operation files having an obligation to define and store DID operations. Expressly, the Core Index File declare the create, recover and deactivate operators; meanwhile, Provisional Index File contains operator updates. Besides, Core Proof File and Provisional Proof File contain necessary cryptographic proofs of operators like signatures, hashes, etc. Finally, SideTree uses COMPRESSION_ALGORITHM to generate a Chunk Files file which contains the operation source data.

Figure 7 elucidates the file structures of the side tree protocol: The protocol comprises of three file constructions, which keep DID administration information and are meant to support principal functionality to facilitate light node configurations, minimize forever the reserved data, and guarantee resolution effectiveness of DID.

DID URI Composition: The SideTree protocol uses a unique identifier segment to identify a DID method called DID Suffix; when a Sidetree-based DID is generated, the unique identifier corresponding to it is also generated. These DID URIs are used to identify a corresponding method correctly and can be self-certifying. DID URI can be presented in two primary forms: short-form and long-form.

Short-form URI: Short-form URI: The SideTree protocol uses a hashing algorithm to generate a Short-Form DID URI from JSON_CANONICALIZATION_SCHEME; the short-form of the DID URI has the format:

did:METHOD:<did-suffix>

Long-form URI: Long-form URI: The formation of Long-Form DID URIs is to prevent endless time situations between DID’s generation and anchor, propagate and process of DID operation by self-certifying and self-resolving capabilities. Structurally, Sidetree Long-Form DID URIs are the Short-Form DID URIs but appended with a new segment called long-form-suffix-data; the value of this segment is calculated from Operation Suffix, and Operation Delta then encoded via DATA_ENCODING_SCHEME function. Long-Form DID URI has format:

did:METHOD:<did-suffix>:<long-form-suffix-data>

JSON web signatures

Generally, the authentication mechanism of DID operations is implemented based on JSON Web Signatures and represented by two actions Signing and Verifying, consisting of four primary functions: create, recover, deactivate and update. Except for the create method, the others require key materials for verifying and authenticating the transactions. When a transaction is required to sign, that transaction must contain two parameters kid and alg.; while the alg is a required parameter and cannot be null, the kid can be declared and assigned a value or not. The format of the authentication string is:

{

 "kid": "did:example:example_kid_value",

 "alg": "example_alg_value"

}

The authentication process on DID is the same for each transaction if that transaction is required to perform Verification. In the first step, the kid is extracted and traversed to find an authentication method with the same id and kid pair. Then the found authentication method is converted to JWK to perform the JWS Verification process in the final step.

Proof of fee

The mechanism of the Sidetree network is designed to resist low-cost tampering, mainly for permissionless and open implementations, by leveraging public blockchains with two key characteristics: Base Fee Variable and Per-Operation Fee. Base Fee Variable is calculated from a set of variables belonging to a particular anchor system using defined functions. In addition, it can be used to set the lowest transaction cost corresponding to the number of DID operations calculate the costs of other economic setups effectively. Per-Operation Fee has the main purpose to validate the user’s transaction by performing the following processes sequentially:

1. Determine the Base Fee Variable of the transaction or block.

2. Use Operation Count from Anchor String to Multiply the Base Fee Variable.

3. Validate the transaction anchored in the anchoring system.

4. Analysis and execute transaction if the transaction uses required fee.

User organization

There are two main groups in BMDD: root users and normal users. The root user is the group that manages the BMDD platform, having full rights to the BMDD participants except for reading the user’s data. The group of normal users use the BMDD service, divided into two subgroups, parent and child users, supposing that the user group is an enterprise and wants to organize the user rights hierarchy. The child user connects to the parent user through the “user_parentid” attribute, which means that the child user’s “user_parentid” field is equivalent to the parent user’s “user_name” field. Every normal user is a child user of the root user. User information is stored in NoSQL format, allowing flexibility to add additional attributes for the user apart from the specified ones. The above user management model is called the model tree and is illustrated in Fig. 8.

The parent user structure in JSON format is as follows:

{

  "userid":"76579b0e-e899-4fc9-a839-607c371b9585",

  "username":"organization1",

  "usermail":"representation@ organization1.vn",

  "userstatus":"ACTIVE",

  "userparentid":"root",

  "usertype":"representation"

}

And the child user structure in JSON format is as follows:

{

  "userid":"37389774-98a6-4dc2-a8b1-22fc29d321ba",

  "username":"thanhlam",

  "usermail":"thanhlam@organization1.vn",

  "userstatus":"ACTIVE",

  "userparentid":"organization1",

  "usertype":"normal"

}

The implemented model trees have two primary purposes. Firstly, BMDD can manage user hierarchy, suitable for enterprise deployment environments and individual customers. Secondly, the users have the right to build coherence and stricter management thanks to hierarchy management. For example, BMDD provides an API enabling the parent user to disable all child users through the status field. When the user status is “DISABLE”, the users and their devices will be isolated and cannot interact with the BMDD, which allows to quickly isolate a group of users when a hacker attacks the BMDD system from one user point. For the root user, this is to isolate an entire organization from the BMDD. Restoring can easily be done by changing the status to “ACTIVE”. The API also ensures that only the high-level user can change the low-level status being its child user.

User role

BMDD user role involves two concepts, including user role for the organization of users following the model tree (described in the user organization section) and role related to IoT service.

User roles related to IoT services include the following capabilities. First, the user has full authority to create logical information to manage his devices and communication channels. The communication channels are equivalent to the Kafka topic concept presented in the background. This information will be embedded into the device and used for checking the permissions when the device interacts with BMDD. This embedded process is beyond the scope of this article; thus will not discuss in detail. Besides, the user can assign device information to a communication channel, allowing users to strictly manage device and channel, only devices that have been authorized and assigned to a specific channel are allowed to send and receive messages on that channel. This approach also helps to reduce security risks caused by the careless behavior of users. Finally, the users also have control over sharing their devices with other users; for instance, a patient can give their doctor permission to access the device and receive heart rate data from a sensor, etc.

Requesting and resolving DID token process

Through this process, the user can get the DID token. Before the user can send data and control the device, the DID token must be resolved to authenticate the user.

The process of requesting a DID token is presented in Fig. 12. The user sends his information to the DID service and receives the DID token in return.

The process of user registering has the following input and output in JSON format.

The input is

{

  "userName": "thanhlam",

  "serviceId": "vnptit",

  "serviceEndpoint": "vnptit"

}

And the out put is:

{

  "longFormURI": "did:ion:EiDQx4R6z…FRaWFdETXcifX0"

}

The resolving DID token process is as the Fig. 13 below. The user sends DID token information to DID service. DID service will resolve the DID token and return the user information if the authentication is successful.

The process of resolving DID token has the following input and output in JSON format.

The input is:

{

  "longFormURI": "did:ion:EiDQx4R6z…FRaWFdETXcifX0"

}

And the out put is:

{

  "didDocument": {

   "id": "did:ion:EiDQx4R6z…FRaWFdETXcifX0",

   "service": [

    {

     "id": "#vnptit",

     "type": "LinkedDomains",

     "serviceEndpoint": "vnptit"

    }

   ],

   "authentication": [

     "#thanhlam"

   ]

  }

}

Creating device, channels management information and mapping devices to channels process

Users can interact with OMS via this process to create management information of devices, channels and map devices to channels. This process helps users control their devices and communication channels. Users will clearly know where they share their data, which helps reduce security risk by user’s behaviors.

The process of creating Things management information is as the Fig. 14. The user sends information, including his DID token, along with device information to the OMS service. The OMS service will forward the user’s DID token to the DID service for authentication. If the authentication process is successful, OMS will generate Things info.

The process of creating Things information has the following input and output in JSON format.

The input is

{

  "token":"user_did_token",

  "thing_name":"thing_name"

}

And the output is

{

  "thing_id":"thing_id",

  "thing_name":"thing_name",

  "thing_status":"thing_status",

  "assign_user":"user_id",

  "user_parent_id":"user_id"

}

OMS will automatically generate thing_id, thing_status values, where thing_id conforms to the UUID standard (https://www.ietf.org/rfc/rfc4122.txt) and is a unique value. The thing_status is used for determining the device state, whose default value is “ENABLE”. If the status is “ENABLE”, this means the Things will work properly; by contrast, it can not interact with the BMDD, if the status is “DISABLE”. The thing_status value can only be changed by the user that owns the Things. Moreover, the user_id value of the user who created the Things, obtained through the token resolution process, is equal to user_parent_id value. The “assign_user” attribute is also automatically generated with the initial value of user_id. When the users assign their device to some other users, this field will be added with the user_id of these assigned users, for example, when User-A assigns device control to Dr-B, the field assign_user has the value as an array “assign_user”: “[User_A_id, Dr_B_id]”.

The process of creating channel management information is as in the Fig. 15. The user sends information, including his DID token, and channel information to the OMS service through which the user’s DID token is transferred to the DID service for authentication. If the authentication is successful, OMS will create channel info.

The process of creating channels information has the following input and output in JSON format.

The input is

{

  "token":"user_did_token",

  "channel_name":" channel_name"

}

And the output is

{

  "channel_name":"channel_name",

  "channel_id":"channel_id",

  "channel_status":"channel_status",

  "user_parent_id":"user_id"

}

OMS will automatically generate channel_id, channel_status values, where channel_id conforms to the UUID standard and is unique. The channel_status is used to determine the channel state, and the default value is “ENABLE”. If the status is “ENABLE”, the channel can transport data; by contrast, when the status is “DISABLE”, the channel can not transmit messages to BMDD. The channel_status value can only be changed by the user who owns the channel. In addition, the user_id value of the user who created the channel, obtained through the token resolution process, is equal to user_parent_id value.

The process of mapping the Things into the channel is as in the Fig. 16.

The user sends information to the OMS service, including his DID token and thing_id and channel_id information. The OMS service will forward the user’s DID token to the DID service for authentication. If the authentication is successful, OMS will map the Things information to the channel information.

The process of mapping Things information to channels has the following input and output in JSON format.

The input is

{

  "token":"user_did_token",

  "thing_id":"thing_id",

  "chanel_id":"chanel_id"

}

And the output is

{

  "map_id":"map_id",

  "thing_id":"thing_id",

  "chanel_id":"chanel_id",

  "user_parent_id":"user_id"

}

OMS will automatically generate map_id values, which conform to the UUID standard and are unique. The user_id value of the user who maps the Things to the channel, obtained through the token resolution process, is equal to user_parent_id value. Note that it is possible to map multiple things on a channel.

Authentication and authorization process

The DID service is responsible for authenticating users through the DID token. The RBAC is accountable for checking the roles that the user has pre-configured through the OMS service. DID and RBAC mainly support data collection and control device processes. Therefore, we will present this process combined with two processes of collecting data (interacting with CDS) and control service (interacting with CSS). The process of interaction is as in the Fig. 17. Before sending data or commands to MQ, CDS and CSS must undergo authentication and check-role processes. CDS/CSS sends the user’s DID token to DID authentication service; if successful, CDS/CSS will receive user_id information. Then, CDS/CSS sends information (user_id, thing_id, and channel_id) to the RBAC service to check if the user has permission to access the Things or the user has permission to the channel, or the Things is assigned to the channel. If the authentication and permission checking is successful, CDS/CSS can send data or control commands to the MQ. Otherwise, all data and control commands will be dropped.

Data collection process

The data collection is the data-sending process from CDC to CDS, going through user authentication and permission checks. Finally, data will be sent to MQ, distributed to other services, depending on the application purpose. The interaction process is as the Fig. 18.

CDC streams data with the users DID token, thing_id, and channel_id to CDS. CDS service receives the data stream and interacts with the DID service and RBAC service to authenticate users and check roles. When the authentication and permission checking is successful, the CDS will stream the data stream to the MQ and return the status to the CDC. The data collection proceeds on the gRPC protocol.

Control device process

The control process sends control commands from CSC to CSS, going through user authentication and permission checking. Finally, the command will be sent to the MQ, distributed to the receiving CSC to control the device. The interaction process is as the Fig. 19.

The CSC sends control commands with the user’s DID token, thing_id, and channel_id to CSS. The CSS service receives control commands and interacts with the DID service and RBAC service to authenticate users and check roles. When the authentication and permission checking is successful, the CSS sends control commands to the MQ and returns the status to the CSC. The control device proceeds on the gRPC protocol.