# An Automatic Embedded Device Registration Procedure Based on the OGC SensorThings API
## 3 Methodology
### Automatic Registration Procedure
#### 3.3.3 Registration Procedure for the Tasking Capability  
The proposed tasking capability procedure requires gateways to have static IP addresses, which is more realistic than requiring each device to have a static IP address. In our design, gateways receive tasks from services and deliver the tasks to corresponding devices through local communication protocols. Therefore, when a gateway registers a device to a service, the IP address of the gateway and the httpProtocol should be uploaded to the services. However, considering the mobile device scenario, a device could connect to different gateways, which means that the currently-connected gateway should dynamically update the IP address and the httpProtocol on the service. Figure 8 shows the proposed tasking capability registration procedure.  
1. First of all, if a device supports any tasking capability, the device should periodically send an UpdateStatus operation (Arrow 1) to the currently-connected gateway.  
Figure 7: The workflow of the sensing capability registration procedure.  
2. The gateway will first check its lookup table. If the tasking capability of the device has been recorded in the lookup table, which means that this device has been registered to this gateway before, the gateway will directly update the gateway's IP address and its httpProtocol on the service (Arrow 2) and send a Confirm operation (Arrow 3) to the device to confirm the end of the procedure. The reason of updating the gateway IP address and its httpProtocol even if the device is known to the gateway is that if the device has connected with other gateways (e.g., a mobile device or nearby gateways), the gateway IP address and httpProtocol on the service could have been changed. Therefore, this seen-to-be redundant procedure is to ensure that the service can successfully forward tasks to the gateway.
3. If the gateway cannot find the tasking capability of the device in the lookup table, all three scenarios are possible (i.e., a new device, a new gateway, or a mobile device). However, unlike that gateways can collect devices' sensing capabilities by querying the service, device protocols (e.g., the zigbeeProtocol) are not stored in the service because of security concerns. Therefore, the gateway needs to send a GetServURLandDesc operation (Arrow 4) to the device to ask for both the service URL and the description file. The device then responds with the SendServURLandDesc operation (Arrow 5).
4. Afterward, the gateway checks if the device has been registered to the service. If the device has been registered (i.e., a new gateway or a mobile device), the gateway will update the gateway's IP address and its httpProtocol to the service (Arrow 6) and record the device's sensing and tasking capability in its lookup table (Arrow 10), and finally send a Confirm operation (Arrow 11) to the device to confirm the end of the procedure.
5. If the device has not been registered to the service (i.e., a new device), the gateway will help the device register its sensing and tasking capability to the service (Arrow 7, 8) and its lookup table (Arrow 9), and finally send a Confirm operation (Arrow 11) to the device to confirm the end of the procedure.  
Finally, to be specific, all static information required to support the proposed registration procedures could be pre-configured in factories, such as the URL of a SensorThings API service and the description file. However, if manufacturers or applications choose to grant users the ability  
Figure 8: The workflow of the tasking capability registration procedure.  
to modify any information, some application-driven design should be made for users to access and modify the device content via local wireless communication, the SensorThings API service, or other potential means.