# An Automatic Embedded Device Registration Procedure Based on the OGC SensorThings API
## 3 Methodology
### Device Description Data Model and Encoding
#### 3.1.3 Description File  
In terms of the proposed IoT-PNP, to automatically register embedded devices to the service layer, embedded devices need to be self-describing, which means metadata, sensing and tasking capabilities, and device communication protocols should be introduced by the devices themselves. Therefore, the first component of the IoT-PNP is to define a description file to explain the details of embedded devices. Since this research aims at proposing a plug-and-play solution based on the  
Figure 3: The data model of tasking capability [4]. SensorThings API, we can directly follow the SensorThings API data model to design the description file. The following subsections explain three sections of the description file, which are Thing's metadata, sensing capabilities, and tasking capabilities. Description File--Thing Metadata  
This section introduces the metadata of an embedded device, such as name, properties, and locations. Figure 4 shows an example of the Thing metadata section. According to the SensorThings API definition, the properties of a Thing are key-value pairs for developers to describe any information related to this Thing. For this research, to support the automatic registration procedure, we define a new property called UID that indicates a unique identifier of a device. This identifier should be unique at least among all devices in a single service. In the automatic registration procedure, the UID is applied to identify the registration status of a device. Please note that the name property of a Thing entity could also serve the same purpose if the name property is defined as unique in a service. Description File--Sensing Capability  
By following the SensorThings API data model, sensing capabilities can be directly modeled as Datastream entities. According to the SensorThings API definition, one Datastream links to a Sensor and an ObservedProperty. Therefore, the information of the corresponding Sensor and ObservedProperty should also be described in the description file along with other necessary attributes, such as the unitOfMeasurement. After registering a Datastream to a service, Observations of this Datastream will be created and linked to this Datastream entity. Figure 5 shows an example description file where one device has two Datastreams measuring air temperature and humidity. Figure 4: Thing metadata of an example description file. Description File--Tasking Capability  
As mentioned earlier, this research applies the data model defined in the Extended SensorThings API (Figure 3) to support the tasking capability. However, since the Extended SensorThings API was designed as a service interface, this description file is mainly for embedded devices to introduce themselves to gateways. Therefore, instead of specifying the HTTPProtocol, this description file should explain the device protocol on local wireless communication protocols, such as ZigBee, Bluetooth, or Low Power WANs. To be specific, the HTTPProtocol should be replaced by classes like ZigBeeProtocol or BluetoothProtocol, etc. As this research chooses ZigBee as the local wireless communication protocol for implementation, the description file with the proposed ZigBeeProtocol is shown in Figure 6.  
In the ZigBeeProtocol, extendedAddressHigh and extendedAddressLow are the high and low 32 bits of unique IEEE 64-bit Extended Address of a device's ZigBee module to establish a connection between gateways and devices. The messageBody is a device's tasking request template, as messageDataType describes the data type of messageBody. The tasking capability in this research also adopts the keyword replacement strategy proposed by [PERSON] and [PERSON] [4] to describe the device protocol and acceptable parameters. The content of messageBody can be defined by device developers as long as it follows the rule of keyword replacement, which will be explained in detail in Section 3.2.2.3. Figure 5: Sensing capability of an example description file.