# An Automatic Embedded Device Registration Procedure Based on the OGC SensorThings API
## 1 Introduction
These systems form many SW-IoT silos that cannot communicate with  
Figure 1: A high-level Sensor Web and Internet of Things (SW-IoT) architecture [4]. each other directly. This heterogeneity issue has been identified as one of the most critical issues severely obstructing the development of SW-IoT [3]. An ultimate solution for this issue is to unify the communication protocols between different layers by following mutually agreed standards. Among the standards related to the SW-IoT, the Sensor Web Enablement (SWE) standards defined by the OGC (Open Geospatial Consortium) have been widely adopted [8; 9; 10; 11]. The SWE mainly defines web service interface standards, such as SOS (Sensor Observation Service) [12], SPS (Sensor Planning Service) [13], SensorThings API [14], and data model standards, such as O&M (Observations and Measurements) [15], SensorML (Sensor Model Language) [16]. By following the SWE standards, sensor metadata and observations can be described with a unified framework, and sensing and tasking capabilities can be accessed in an interoperable manner. In addition, among the SWE standards, the SensorThings API (Application Programming Interface) is the newest RESTful service interface standard for SW-IoT data services. This standard has two main advantages. Firstly, this standard defines a comprehensive SW-IoT data model based on the O&M standard. Secondly, its service interface is inspired by the OASIS (Organization for the Advancement of Structured Information Standards) Open Data Protocol (OData) [17], which supports intuitive and flexible query functions based on the Representational State Transfer (RESTful) style and JavaScript Object Notation (JSON) encoding. Therefore, we believe that the SensorThings API is one of the most complete SW-IoT data service interfaces. However, while the SWE standards mainly focus on the service layer, communication between devices and gateways did not receive enough attention in the SWE ecosystem. To be specific, the communication between the device layer and the gateway layer is important for device registration, observation uploading, and task forwarding. Although there have been some efforts proposed to address this issue in the SWE ecosystem, such as PUCK [18] and SID (Sensor Interface Descriptors) [19], these approaches are either not open standards or are not designed to integrate with the SensorThings API. Therefore, the main goal of this research is to fill in the missing components in the current SensorThings API architecture, which allows embedded devices to automatically register themselves and their sensing and tasking capabilities to a SensorThings API service through local gateways. This solution is designed to support various scenarios. The scenarios can be summarized into four general types, including the registration of sensing capabilities of in-situ and mobile devices, and the registration of tasking capability of in-situ and mobile devices. To be specific, in-situ and mobile devices can automatically register themselves to a SensorThings API service, continuously upload sensor observations or new locations, and update web addresses of connected-gateways for services to task devices. These scenarios should be able to cover most SW-IoT use cases via the integration of sensing and tasking capabilities [20]. In general, this research tries to construct a coherent architecture that can seamlessly integrate the device layer, the gateway layer, and the service layer based on the SensorThings API ecosystem. To be specific, we propose a solution called SW-IoT Plug and Play (IoT-PNP) to achieve an automatic registration procedure from embedded devices to SensorThings API services. There are three main parts in the IoT-PNP. Firstly, this research defines a description file format for device metadata and capabilities, in order that the devices become self-describing. Secondly, the IoT-PNP defines a default configuration of a local wireless communication protocol to automatically establish connections between devices and gateways.