# An Automatic Embedded Device Registration Procedure Based on the OGC SensorThings API
## 3 Methodology
### Communication Protocol for the Gateway Layer and the Device Layer
#### 3.2.2.3 Tasking Protocol Translation and Task Forwarding  
According to the extended SensorThings API, [PERSON] and [PERSON] [4] propose the keyword replacement solution to automatically translate users' tasks into different device protocols. While [PERSON] and [PERSON] [4] define the interface translation between the service interface and the device protocol, this research applies the same concept to establish automatic protocol translation between the web service and gateway as well as gateway and device. In general, tasking protocol translation can be divided into the registration process and the tasking process. The registration process has the following steps: (1) A device sends a TaskingCapability entity in the description file to a gateway, (2) the gateway follows the content in local wireless communication protocols, e.g., zigbeeProtocol, and generates a corresponding httpProtocol, and (3) the gateway registers the httpProtocol to an extended SensorThings API service. The tasking \begin{table}
\begin{tabular}{p{142.3 pt} p{142.3 pt}} \hline
**Operation** & **GetServURLandDesc** \\ \hline functionality request format & A gateway asks for the service URL and the description file \\ \hline \end{tabular}
\end{table} 
Table 10: GetServURLandDesc operation. \begin{table}
\begin{tabular}{p{142.3 pt} p{142.3 pt}} \hline
**Operation** & **GetServURL** \\ \hline functionality request format & A gateway asks for the service URL that this device should be registered to \\  & \{ & \"operation\": \"GetServURL\", \\  & \"device\_ID\": \"device\_ID\" \\  & \} \\ \hline \end{tabular}
\end{table} 
Table 8: GetServURL operation. \begin{table}
\begin{tabular}{p{142.3 pt} p{142.3 pt}} \hline
**Operation** & **GetServURL** \\ \hline functionality request format & A gateway asks for the service URL that this device should be registered to \\  & \{ & \"operation\": \"GetServURL\", \\  & \"device\_ID\": \"device\_ID\": \"device\_ID\" \\  & \} \\ \hline \end{tabular}
\end{table} 
Table 9: GetDesc operation. process has the following steps: (1) A user creates a Task in the extended SensorThings API service based on the TaskingCapability shown in the service, (2) the service follows the httpProtocol to translate into a gateway request and forward the task to the gateway, (3) the gateway parses the tasking parameters from the service request, (4) the gateway follows the zigbeeProtocol to translate into a device request and forward the task to the device. We use a smart light bulb example in Figure 6 to explain the detail procedure. First of all, the device sends the describe file in Figure 6 to a gateway. Based on the TaskingCapability entity, the gateway can understand there is a task template, i.e., MY_DEVICE00010:LightBulb:{on}, with a placeholder {on}. The on in the placeholder {on} is the parameterID introduced in the TaskingCapability entity of this light bulb, which will be replaced as true or false to turn on or off the light bulb. By following the content in the TaskingCapability entity, the gateway then replaces the zigbeeProtocol to a httpProtocol as the gateway protocol. The absoluteResourcePath is the static IP address of the gateway. Please note that the httpProtocol can be defined by gateway developers as long as the gateway can understand the mapping between the zigbeeProtocol and the httpProtocol. Algorithm 1 shows an example of an httpProtocol created by the gateway, where the gateway still uses {on} as the placeholder in the httpProtocol. ```
\"httpProtocol\":{ \"httpMethod\":\"POST\", \"absoluteResourcePath\":\"[[http://example.com/Gateway](http://example.com/Gateway)]([http://example.com/Gateway](http://example.com/Gateway))\", \"messageDataType\":\"application/json\", \"messageBody\": \"{\"on}\":{on}\"TC_name\":}\"LED\",}\"device_ID\":}\"DEVICE00001\"
```  
**Algorithm 1** An httpProtocol example.