186
Internet of Things (IoT)
9.4.2.2 Generating the devID
As mentioned earlier, when device profile information is registered either manually
or automatically from each IoT platform, a devID is automatically generated. We use a
64-bit-long integer. It is used when the data and control messages transfer between the
access network, carrier public network, and IoT private network, to save the communication overhead over any character-based naming. However, one cannot randomly generate this sequence to avoid potential collision when a cluster of NAPS are deployed in
a cloud environment. Meanwhile, the allocation of these 64 bits should have to support
other components. For instance, AG will deploy its policy-based rule engine like MQ topic
according to the device domain information, where one example is that applications may
efficiently query all devices with mobility for their connectivity and presence at runtime
by simply masking a portion of this devID. Toward this end, we propose the following
design, as shown in Table 9.2.
The category field identifies the type of sequence in the database (for devID this field
equals to 1), followed by the device type, controllable flag, read/write access flag, and
mobility indicator. The last part is a series of domain information, starting from the domain
rule sequence r and back trace from the leaf to the root domain nodes of that domain rule.
9.5 Conclusions
In this chapter, we briefly discussed the role of naming service and the high-level requirements of the name service. Also we discussed NAPS, which is a middleware to support
device naming, application addressing, and profile storage and lookup services in IoT
environments. Earlier approaches were only focusing on specific standard/protocol, but
the NAPS works in any platform. Here we briefly discussed its complete design including
its functionalities, system flows, interfaces, etc.
References
1. K. Gama, L. Touseau, D. Donsez. Combining heterogeneous service technologies for building
an internet of things middleware. Computer Communications 2012; 35(4): 405–417.
2. L. Roalter, M. Kranz, A. Moller. A middleware for intelligent environments and the internet
of things. In: ACM UIC’10, Springer, Berlin, 2010.
3. EPCglobal. www.epcglobalinc.org/ (accessed January 3, 2017).
4. OPC Unified Architecture (UA). www.opcfoundation.org/ua/ (accessed January 5, 2017).
TABLE 9.2
Bit allocation for devID
ID
Category
Device
Type
Control
Flag
r/w Flag
Mobile
Flag
Domain
Rule
Domain
Series
Sequence
5 bits
6 bits
1 bit
2 bits
1 bit
5 bits
34 bits
10 bits
Internet of Things (IoT)
9.4.2.2 Generating the devID
As mentioned earlier, when device profile information is registered either manually
or automatically from each IoT platform, a devID is automatically generated. We use a
64-bit-long integer. It is used when the data and control messages transfer between the
access network, carrier public network, and IoT private network, to save the communication overhead over any character-based naming. However, one cannot randomly generate this sequence to avoid potential collision when a cluster of NAPS are deployed in
a cloud environment. Meanwhile, the allocation of these 64 bits should have to support
other components. For instance, AG will deploy its policy-based rule engine like MQ topic
according to the device domain information, where one example is that applications may
efficiently query all devices with mobility for their connectivity and presence at runtime
by simply masking a portion of this devID. Toward this end, we propose the following
design, as shown in Table 9.2.
The category field identifies the type of sequence in the database (for devID this field
equals to 1), followed by the device type, controllable flag, read/write access flag, and
mobility indicator. The last part is a series of domain information, starting from the domain
rule sequence r and back trace from the leaf to the root domain nodes of that domain rule.
9.5 Conclusions
In this chapter, we briefly discussed the role of naming service and the high-level requirements of the name service. Also we discussed NAPS, which is a middleware to support
device naming, application addressing, and profile storage and lookup services in IoT
environments. Earlier approaches were only focusing on specific standard/protocol, but
the NAPS works in any platform. Here we briefly discussed its complete design including
its functionalities, system flows, interfaces, etc.
References
1. K. Gama, L. Touseau, D. Donsez. Combining heterogeneous service technologies for building
an internet of things middleware. Computer Communications 2012; 35(4): 405–417.
2. L. Roalter, M. Kranz, A. Moller. A middleware for intelligent environments and the internet
of things. In: ACM UIC’10, Springer, Berlin, 2010.
3. EPCglobal. www.epcglobalinc.org/ (accessed January 3, 2017).
4. OPC Unified Architecture (UA). www.opcfoundation.org/ua/ (accessed January 5, 2017).
TABLE 9.2
Bit allocation for devID
ID
Category
Device
Type
Control
Flag
r/w Flag
Mobile
Flag
Domain
Rule
Domain
Series
Sequence
5 bits
6 bits
1 bit
2 bits
1 bit
5 bits
34 bits
10 bits