168
Internet of Things (IoT)
things in IoT are communicating and how the name service will translate the meaningful names to a machine-understandable form. Name services means to translate humanunderstandable names into network identifiers that can be used for communications in the
computer networks. Mainly we are using Internet Protocol (IP) address for the communication of hosts over the network. But it will be very difficult for humans to memorize the
IP address, which is a 32-bit number and type it in the URL field to access the web pages.
This difficulty raised the need of using memorable words (for example, www.google.com)
to access the web pages. Li et al. introduced a naming, addressing, and profile (NAPS)
server for the naming and addressing in IoT.
One of the main issues in the existing methods is the lack of de facto standard in the
NAPS server, as a middleware [1] interoperable with heterogeneous platforms [2]. So if there
exists a homogenous naming and addressing convention, then the application developers can easily retrieve data from sensors and control the actuators of different networks.
Otherwise the application developers need to spend much time to learn about different protocols and standards. So a higher layer of device naming–addressing mapping should be
provided to integrate with legacy systems and different platforms. For the device naming,
the convention should contain key elements of meta-data, such as device type and domain
information, while for addressing its format allows the granularity of efficient accessibility and addressability to the physical world. Profile services are also needed to aid the
application query and system configurations, like device status and presence. Furthermore,
sensing tasks are always achieved by a group of devices with similar sensing capabilities,
and thus NAPS should provide device group management functionalities, such as to create, update, read, and delete groups. As we can create groups, only a device group name
is needed to share the information. In this way, application development logic is greatly
simplified where only a device group name is needed and NAPS handles the internal mapping. As a middleware, it should extend its usability by providing abundant external interfaces. IPv4, IPv6, and Domain Name System (DNS) are usually considered as the candidate
standard for naming and addressing; however, due to the lack of communication and processing capabilities of many small and cheap devices (like Radio Frequency Identification
(RFID) tags), it is quite challenging to connect every “thing” with an IP. Furthermore, with
the increasing amount of end devices, even IPv6’s address space may not be enough. On the
other hand, industry standards have put much effort in each application domain. EPCglobal
[3] uses a 96-bit binary sequence to identify each RFID tag, and the object naming service
(ONS) for URL translation. OPC- Unified Architecture [4] defines client-server-based models for industrial production line solutions, where an abstract address space is formed by
a mesh topology. In it, each node represents a sensor in the production stage and the edge
between two nodes represents the stage-by-stage relationship during the production. As an
overall service architecture, European Telecommunications Standards Institute (ETSI) [5]
proposed a solution interworking with 3GPP machine-type communication (MTC) standard [6], to support machine-to-machine (M2M) communications when upgrading from
traditional cellular networks where each device is with a unique international mobile subscriber identity (IMSI) and is IP addressable. Furthermore, as a service layer architecture, it
defines a variety of service capabilities (SCs) including a network reachability, addressing,
and repository (NRAR) SC. Our goal in this work is to work with any service platforms as
a middleware at the back-end data center. Therefore, all these efforts pay attention only to
a specific network or application domain, however, not applicable as a common platform
managing different technologies and standards.
Figure 9.1 shows an overall architecture from the physical phenomenon all the way up
to the data center, considered in this chapter. Devices such as sensors and actuators sense/
Internet of Things (IoT)
things in IoT are communicating and how the name service will translate the meaningful names to a machine-understandable form. Name services means to translate humanunderstandable names into network identifiers that can be used for communications in the
computer networks. Mainly we are using Internet Protocol (IP) address for the communication of hosts over the network. But it will be very difficult for humans to memorize the
IP address, which is a 32-bit number and type it in the URL field to access the web pages.
This difficulty raised the need of using memorable words (for example, www.google.com)
to access the web pages. Li et al. introduced a naming, addressing, and profile (NAPS)
server for the naming and addressing in IoT.
One of the main issues in the existing methods is the lack of de facto standard in the
NAPS server, as a middleware [1] interoperable with heterogeneous platforms [2]. So if there
exists a homogenous naming and addressing convention, then the application developers can easily retrieve data from sensors and control the actuators of different networks.
Otherwise the application developers need to spend much time to learn about different protocols and standards. So a higher layer of device naming–addressing mapping should be
provided to integrate with legacy systems and different platforms. For the device naming,
the convention should contain key elements of meta-data, such as device type and domain
information, while for addressing its format allows the granularity of efficient accessibility and addressability to the physical world. Profile services are also needed to aid the
application query and system configurations, like device status and presence. Furthermore,
sensing tasks are always achieved by a group of devices with similar sensing capabilities,
and thus NAPS should provide device group management functionalities, such as to create, update, read, and delete groups. As we can create groups, only a device group name
is needed to share the information. In this way, application development logic is greatly
simplified where only a device group name is needed and NAPS handles the internal mapping. As a middleware, it should extend its usability by providing abundant external interfaces. IPv4, IPv6, and Domain Name System (DNS) are usually considered as the candidate
standard for naming and addressing; however, due to the lack of communication and processing capabilities of many small and cheap devices (like Radio Frequency Identification
(RFID) tags), it is quite challenging to connect every “thing” with an IP. Furthermore, with
the increasing amount of end devices, even IPv6’s address space may not be enough. On the
other hand, industry standards have put much effort in each application domain. EPCglobal
[3] uses a 96-bit binary sequence to identify each RFID tag, and the object naming service
(ONS) for URL translation. OPC- Unified Architecture [4] defines client-server-based models for industrial production line solutions, where an abstract address space is formed by
a mesh topology. In it, each node represents a sensor in the production stage and the edge
between two nodes represents the stage-by-stage relationship during the production. As an
overall service architecture, European Telecommunications Standards Institute (ETSI) [5]
proposed a solution interworking with 3GPP machine-type communication (MTC) standard [6], to support machine-to-machine (M2M) communications when upgrading from
traditional cellular networks where each device is with a unique international mobile subscriber identity (IMSI) and is IP addressable. Furthermore, as a service layer architecture, it
defines a variety of service capabilities (SCs) including a network reachability, addressing,
and repository (NRAR) SC. Our goal in this work is to work with any service platforms as
a middleware at the back-end data center. Therefore, all these efforts pay attention only to
a specific network or application domain, however, not applicable as a common platform
managing different technologies and standards.
Figure 9.1 shows an overall architecture from the physical phenomenon all the way up
to the data center, considered in this chapter. Devices such as sensors and actuators sense/