183
Naming Services in the Internet of Things
and matching and downstream efficient control by applications. The main difference
between the existing approach and the Li’s approach is the introduction of a middleware
component. The earlier approaches focused on a specific protocol, while the approach
by Liu et al. [36] gives more focus on the middleware component, which serves dynamic
application needs, sensors/actuators deployment, and configurations across different
platforms.
In the following sections, we discuss the design of NAPS, including its key
functionalities, system flows, interfaces, and individual module design. We discuss also
a unique device naming and addressing convention and show its applicability to a few
widely used standards and protocols. We deal with also an efficient identifier generation scheme.
In this section, our contributions are summarized fourfold. First, we propose a complete
and detailed design of NAPS, including its key system flows, interfaces, and individual
module designs. Second, we propose a unique device naming and addressing convention
interworking with different platforms, and we show its applicability to a few widely used
standards and protocols. Third, we propose an efficient identifier generation scheme, not
only used during data transportation, but also to facilitate the data filtering and matching.
Fourth, we provide CURD operations on device, device type, and device group profiles, in
the RESTful design style [37] over HTTP at runtime.
9.4.1 System Flows
To support the high scalability requirement, Li et al. further decomposed AG into four
modules, front-end processor (FEP), command controller (CC), back-end processor (BEP),
and message queue (MQ). FEP is used for data collection and format transformation, CC
for application command parsing and translation from NAPS, BEP for rule-based data
filtering and matching, and MQ for publish-subscribe-based topic services [38].
Then, users can identify its bottleneck and scale up/out the corresponding component,
for example, to deploy MQs for large number of applications in a cloud. The list of components that interact with NAPS either off-line or at runtime are AG-FEP, AG-CC, AG-BEP,
applications, portal, and RODB, as shown in Figure 9.4 for system context and associated
interfaces. It is worth noting that the overall IoT-AI platform is only used as an example to
demonstrate the system flow of NAPS, whereas its applicability can extend to any external
component with similar interfaces.
We next present system flows, service registration and configurations, upstream data
collection, and downstream command delivery. In all aspects, an AAA server interacts
with NAPS for security authentication and authorization.
9.4.1.1 Device Registration and Configurations
Service discovery is performed at individual platform beneath the data center service layer,
and NAPS only provides a set of interfaces to facilitate the device registration, either automatic or off-line. The registered capabilities include the ones offered by devices, device
types, and device groups, and thus the repository stores the corresponding profile information. The provided interfaces are based on the RESTful design style, where standard
HTTP request/response is used to transport the data. It is worth nothing that before the
response is returned to the client, we generate a unique device identifier, or “devID.” It contains key elements of the device metadata. This devID generation process is also applicable
when device type and device group are registered.
Naming Services in the Internet of Things
and matching and downstream efficient control by applications. The main difference
between the existing approach and the Li’s approach is the introduction of a middleware
component. The earlier approaches focused on a specific protocol, while the approach
by Liu et al. [36] gives more focus on the middleware component, which serves dynamic
application needs, sensors/actuators deployment, and configurations across different
platforms.
In the following sections, we discuss the design of NAPS, including its key
functionalities, system flows, interfaces, and individual module design. We discuss also
a unique device naming and addressing convention and show its applicability to a few
widely used standards and protocols. We deal with also an efficient identifier generation scheme.
In this section, our contributions are summarized fourfold. First, we propose a complete
and detailed design of NAPS, including its key system flows, interfaces, and individual
module designs. Second, we propose a unique device naming and addressing convention
interworking with different platforms, and we show its applicability to a few widely used
standards and protocols. Third, we propose an efficient identifier generation scheme, not
only used during data transportation, but also to facilitate the data filtering and matching.
Fourth, we provide CURD operations on device, device type, and device group profiles, in
the RESTful design style [37] over HTTP at runtime.
9.4.1 System Flows
To support the high scalability requirement, Li et al. further decomposed AG into four
modules, front-end processor (FEP), command controller (CC), back-end processor (BEP),
and message queue (MQ). FEP is used for data collection and format transformation, CC
for application command parsing and translation from NAPS, BEP for rule-based data
filtering and matching, and MQ for publish-subscribe-based topic services [38].
Then, users can identify its bottleneck and scale up/out the corresponding component,
for example, to deploy MQs for large number of applications in a cloud. The list of components that interact with NAPS either off-line or at runtime are AG-FEP, AG-CC, AG-BEP,
applications, portal, and RODB, as shown in Figure 9.4 for system context and associated
interfaces. It is worth noting that the overall IoT-AI platform is only used as an example to
demonstrate the system flow of NAPS, whereas its applicability can extend to any external
component with similar interfaces.
We next present system flows, service registration and configurations, upstream data
collection, and downstream command delivery. In all aspects, an AAA server interacts
with NAPS for security authentication and authorization.
9.4.1.1 Device Registration and Configurations
Service discovery is performed at individual platform beneath the data center service layer,
and NAPS only provides a set of interfaces to facilitate the device registration, either automatic or off-line. The registered capabilities include the ones offered by devices, device
types, and device groups, and thus the repository stores the corresponding profile information. The provided interfaces are based on the RESTful design style, where standard
HTTP request/response is used to transport the data. It is worth nothing that before the
response is returned to the client, we generate a unique device identifier, or “devID.” It contains key elements of the device metadata. This devID generation process is also applicable
when device type and device group are registered.