170
Internet of Things (IoT)
filtering and processing and controls message delivery based on a uniform device naming
and addressing convention in NAPS. The goal is to have applications access devices across
different platforms without knowing their languages in detail, but focusing on the development logic only. The position of NAPS extends the functionality comparable to DNS in the
Internet, to the profile services such as storage and query. We next present three assumptions
of this work. First is service discovery. As the scope of NAPS is a middleware component at
the back-end data center to hide the heterogeneous protocols and standards, here we assume
that service discovery has already been successfully performed by each platform individually, and stored in our NAPS repository. Examples are service discovery server enhanced
from ETSI M2M service architecture by Inter-Digital [8], discovery service set in OPC-UA
standard, and protocols like Universal Plug and Play (UPnP) [10]. Second is the authentication, authorization, and accounting (AAA). Although it is not the focus of this work, the
design can largely leverage the network security capability (NSEC) SC in ETSI M2M service
architecture. It uses a key hierarchy, composed of root key, service key, and application keys.
Root key is used to derive service keys through authentication, and key agreement between
the device or gateway and the M2M SCs at the M2M Core. The application key, derived from
service key, is unique as per M2M application.
Finally, we assume that wireless imperfection like packet errors and interference have
been handled by the communication stack of each access networks. Solutions from PHY
layer techniques (e.g., antenna techniques, modulation, and coding) and MAC/network
layer protocols (e.g., scheduling and routing) are a few examples. Therefore, any wireless
issues are completely transparent to the service layer operations, or the NAPS middleware
considered in this paper.
EU FP7 project IoT-Architecture (IoT-A) extensively discussed the existing architectures,
protocols, and platforms [11]. Besides, Castellani et al. [12] propose a framework to interconnect sensors running 6LoWPAN [13], where IEEE 802.15.4 and IPv6 were considered to connect wireless devices to the Internet. Silverajan and Harju [14] provide an XML schema to
encode device profile information including its local name. Web-of-things (WoT [15]) make
use of popular Web languages for building applications involving smart things and users.
As for industrial standards, based on DNS, the pure IP solution [16] is favored due to the
recent development of IPv6 to connect “things” for IoT. EPCglobal [3] specializes in use of
RFID in the information-rich and trading networks, especially for logistics. In it, similar
to DNS, an ONS is designed to translate a 96-bit binary sequence to a uniform resource
identifier (URI), which directs the query to a (set of) database(s) called EPC information
service for information retrieval and update. OPC-UA [4] defines an address space where
devices are interconnected to form a mesh topology. The connectivity represents the production line sequence, where the directional edge called “reference” links the next stage of
behavior. ETSI M2M service architecture [5] assumes each M2M device is IP addressable.
In 3GPP MTC [6], they propose to use the IMSI as the internal identifier for signaling and
charging, while providing external identifiers to include domain information under the
control of a network operator, and flexibly allocated descriptions as the customer-friendly
local identifier. On the other hand, naming and addressing for wireless sensor networks
have been extensively investigated [17–20]. The first kind of approaches rely on the efficient address allocation among nodes, where in [21,22] the assigned addresses are reused
spatially and represented by variable length of code words. This was later extended by
Kronewitter [23] who used the prefix-free Huffman encoding of node addresses based on
the energy map, where nodes with little battery life left will have the advantage of a short
address and check period. Elson and Estrin [24] proposed the “attribute-based naming.”
In the work by Heidemann et al. [25], clients use an intentional name to request a service
Internet of Things (IoT)
filtering and processing and controls message delivery based on a uniform device naming
and addressing convention in NAPS. The goal is to have applications access devices across
different platforms without knowing their languages in detail, but focusing on the development logic only. The position of NAPS extends the functionality comparable to DNS in the
Internet, to the profile services such as storage and query. We next present three assumptions
of this work. First is service discovery. As the scope of NAPS is a middleware component at
the back-end data center to hide the heterogeneous protocols and standards, here we assume
that service discovery has already been successfully performed by each platform individually, and stored in our NAPS repository. Examples are service discovery server enhanced
from ETSI M2M service architecture by Inter-Digital [8], discovery service set in OPC-UA
standard, and protocols like Universal Plug and Play (UPnP) [10]. Second is the authentication, authorization, and accounting (AAA). Although it is not the focus of this work, the
design can largely leverage the network security capability (NSEC) SC in ETSI M2M service
architecture. It uses a key hierarchy, composed of root key, service key, and application keys.
Root key is used to derive service keys through authentication, and key agreement between
the device or gateway and the M2M SCs at the M2M Core. The application key, derived from
service key, is unique as per M2M application.
Finally, we assume that wireless imperfection like packet errors and interference have
been handled by the communication stack of each access networks. Solutions from PHY
layer techniques (e.g., antenna techniques, modulation, and coding) and MAC/network
layer protocols (e.g., scheduling and routing) are a few examples. Therefore, any wireless
issues are completely transparent to the service layer operations, or the NAPS middleware
considered in this paper.
EU FP7 project IoT-Architecture (IoT-A) extensively discussed the existing architectures,
protocols, and platforms [11]. Besides, Castellani et al. [12] propose a framework to interconnect sensors running 6LoWPAN [13], where IEEE 802.15.4 and IPv6 were considered to connect wireless devices to the Internet. Silverajan and Harju [14] provide an XML schema to
encode device profile information including its local name. Web-of-things (WoT [15]) make
use of popular Web languages for building applications involving smart things and users.
As for industrial standards, based on DNS, the pure IP solution [16] is favored due to the
recent development of IPv6 to connect “things” for IoT. EPCglobal [3] specializes in use of
RFID in the information-rich and trading networks, especially for logistics. In it, similar
to DNS, an ONS is designed to translate a 96-bit binary sequence to a uniform resource
identifier (URI), which directs the query to a (set of) database(s) called EPC information
service for information retrieval and update. OPC-UA [4] defines an address space where
devices are interconnected to form a mesh topology. The connectivity represents the production line sequence, where the directional edge called “reference” links the next stage of
behavior. ETSI M2M service architecture [5] assumes each M2M device is IP addressable.
In 3GPP MTC [6], they propose to use the IMSI as the internal identifier for signaling and
charging, while providing external identifiers to include domain information under the
control of a network operator, and flexibly allocated descriptions as the customer-friendly
local identifier. On the other hand, naming and addressing for wireless sensor networks
have been extensively investigated [17–20]. The first kind of approaches rely on the efficient address allocation among nodes, where in [21,22] the assigned addresses are reused
spatially and represented by variable length of code words. This was later extended by
Kronewitter [23] who used the prefix-free Huffman encoding of node addresses based on
the energy map, where nodes with little battery life left will have the advantage of a short
address and check period. Elson and Estrin [24] proposed the “attribute-based naming.”
In the work by Heidemann et al. [25], clients use an intentional name to request a service