184
Internet of Things (IoT)
9.4.1.2 Upstream Data Collection
As shown in Figure 9.5a, when the raw data are received from an IoT platform, AG-BEP
translates the devID to the corresponding device name (devName) as more friendly to the
application. Meanwhile, AG-BEP makes use of devID to perform efficient content-based data
filtering and matching. For example, one application configures a topic on MQ to aggregate
and average the room humidity data in a smart building environment. Then, as the designed
devID contains key elements of device metadata such as associated domain information and
device type, it helps to categorize, filter, and select the exact set of raw data from the massive data pool. This can be achieved by masking certain encoded profile parameters. To save
the overhead, we can use devID as the unique identifier in the transport, e.g., through the
carrier public network and IoT private network as shown in Figure 9.1, while using devName
containing a set of human-readable properties for applications.
9.4.1.3 Downstream Command Delivery
Figure 9.5b shows the downstream system flow when control messages are initialized
by the application to specific device groups. First, device (group) name is passed to the
AG-CC, and the latter retrieves the list of devID(s) from NAPS over the RESTful interface. Then, AG-FEP translates the devID(s) to the corresponding device address(es) from
NAPS, in which it specifies how to address the command(s) to the exact device or group of
devices. In this way, similar to the functionality of DNS in the Internet, NAPS performs the
name-to-address resolution. Here the main aim is to define a thin layer for address resolution, as a uniform convention to unify and cooperate different platforms. In our addressing convention (see Section 4.2), it specifies the way to route the command to the Internet
gateway, which is IP addressable, such as the M2M gateway in ETSI M2M service architecture, OPC-UA server, or WiMax base station. In a hierarchy, these gateways further route
the command to the next level gateway (e.g., the ZigBee coordinator), which maintains its
own addressing mechanism to the device.
9.4.1.4 Application Query
Application developers may be same as, or different from, the device owners. Therefore,
their development logic entirely relies on identifying the right set of devices from the physical world, which may eventually belong to different network domains/platforms. Toward
this end, as the device, device type, and device group profiles are registered and stored in
NAPS repository, we allow search services to retrieve a list of devices and device groups
with certain geographical, domain, and device name information. Furthermore, this process can be coupled with downstream command delivery procedure where a retrieved
list of device and device group names are used to issue commands to the physical world.
9.4.1.5 Integration with Different IoT Platforms
Nearly all third-party device vendors and platform operators have their own naming
mechanism, and it is likely that they also have already developed their own applications.
NAPS provides the translation between our uniform naming convention and the legacy
naming, offering shared services to different vendors and applications. We thus provide
two RESTful interfaces, getDevOldNamebyDevName() and getDevNamebyDevOldName(), where the former is used when the upstream data are received by the application
attached with our device name, and thus to be translated to the legacy name, and the
Internet of Things (IoT)
9.4.1.2 Upstream Data Collection
As shown in Figure 9.5a, when the raw data are received from an IoT platform, AG-BEP
translates the devID to the corresponding device name (devName) as more friendly to the
application. Meanwhile, AG-BEP makes use of devID to perform efficient content-based data
filtering and matching. For example, one application configures a topic on MQ to aggregate
and average the room humidity data in a smart building environment. Then, as the designed
devID contains key elements of device metadata such as associated domain information and
device type, it helps to categorize, filter, and select the exact set of raw data from the massive data pool. This can be achieved by masking certain encoded profile parameters. To save
the overhead, we can use devID as the unique identifier in the transport, e.g., through the
carrier public network and IoT private network as shown in Figure 9.1, while using devName
containing a set of human-readable properties for applications.
9.4.1.3 Downstream Command Delivery
Figure 9.5b shows the downstream system flow when control messages are initialized
by the application to specific device groups. First, device (group) name is passed to the
AG-CC, and the latter retrieves the list of devID(s) from NAPS over the RESTful interface. Then, AG-FEP translates the devID(s) to the corresponding device address(es) from
NAPS, in which it specifies how to address the command(s) to the exact device or group of
devices. In this way, similar to the functionality of DNS in the Internet, NAPS performs the
name-to-address resolution. Here the main aim is to define a thin layer for address resolution, as a uniform convention to unify and cooperate different platforms. In our addressing convention (see Section 4.2), it specifies the way to route the command to the Internet
gateway, which is IP addressable, such as the M2M gateway in ETSI M2M service architecture, OPC-UA server, or WiMax base station. In a hierarchy, these gateways further route
the command to the next level gateway (e.g., the ZigBee coordinator), which maintains its
own addressing mechanism to the device.
9.4.1.4 Application Query
Application developers may be same as, or different from, the device owners. Therefore,
their development logic entirely relies on identifying the right set of devices from the physical world, which may eventually belong to different network domains/platforms. Toward
this end, as the device, device type, and device group profiles are registered and stored in
NAPS repository, we allow search services to retrieve a list of devices and device groups
with certain geographical, domain, and device name information. Furthermore, this process can be coupled with downstream command delivery procedure where a retrieved
list of device and device group names are used to issue commands to the physical world.
9.4.1.5 Integration with Different IoT Platforms
Nearly all third-party device vendors and platform operators have their own naming
mechanism, and it is likely that they also have already developed their own applications.
NAPS provides the translation between our uniform naming convention and the legacy
naming, offering shared services to different vendors and applications. We thus provide
two RESTful interfaces, getDevOldNamebyDevName() and getDevNamebyDevOldName(), where the former is used when the upstream data are received by the application
attached with our device name, and thus to be translated to the legacy name, and the