185
Naming Services in the Internet of Things
latter is used when applications issue commands to the actuators by translating the legacy
naming to the proposed one. In this way, existing naming platforms like 3GPP MTC and
EPCglobal can be seamlessly integrate with this NAPS middleware.
9.4.2 System Designs and Implementations
Here, we discuss the naming and address convention and the generation of devID.
9.4.2.1 Naming and Addressing Convention
In this section we discuss a novel naming convention for devices and device groups across
different platforms in a form of:
dev://domain-series/devtype/legacy-name,
grp://domain-series/target/policy/grp-name,
where the prefix distinguishes its category (as for devices or device groups), followed by a
series of device domain information. The device domain is organized in a tree structure,
written in the above naming convention back trace from the leaf to the root node of the
domain tree. After the domain series, for devices we use the device type information to
further categorize all devices associated with a domain node on the leaf of the tree, and
finally the legacy naming (e.g., serial number) from the production phase. Meanwhile,
device groups use the monitoring target (e.g., the room temperature) and grouping policy
for detailed classification.
Device domain information refers to either their deployed geographical information,
or logical organization of these devices. In NAPS, we can store multiple device domains,
and each domain indexed r is a tree structure with depth d r and width of each level as
{
}
∀ =
w
i
d
r
i
r
,
1,...,
. In other words, domain r is composed of total
∑
=
=
N
w
r
r
i
i
dr
1
domain
nodes. We call the “partition” of a domain tree by parameters
)
( { }
d w
r
r
i
,
as the “domain
rule,” and the corresponding data structure representation as “rule assignment.” For example, the rule assignment parameters are the number of bits to store the domain nodes in
each level of the tree. The metadata of each node include the name, its parents and children, and other properties (see Figure 9.6). In practice, project managers of an IoT system
will carefully plan the device deployment at a site of interest, where the first step is to plan
an overall device domain, for example, in a smart building environment, how many temperature and humidity sensors of what device type should be deployed at which location,
and this deployment stage eventually specifies a domain tree structure, and is stored in
NAPS repository.
As for device addressing convention, we propose to use the format:
address 1@ protocol 1/.../ address n@ protocol n/ IP
networks
address
non IP
−
−
−
−
−
−
to accommodate heterogenous protocols and standards in use across different platforms.
To allow the granularity of addressing the device in a hierarchy, we repeat the element
“address@protocol” one after the other from the device to the Internet gateway, which is
IP addressable (as the last part of the convention).
Naming Services in the Internet of Things
latter is used when applications issue commands to the actuators by translating the legacy
naming to the proposed one. In this way, existing naming platforms like 3GPP MTC and
EPCglobal can be seamlessly integrate with this NAPS middleware.
9.4.2 System Designs and Implementations
Here, we discuss the naming and address convention and the generation of devID.
9.4.2.1 Naming and Addressing Convention
In this section we discuss a novel naming convention for devices and device groups across
different platforms in a form of:
dev://domain-series/devtype/legacy-name,
grp://domain-series/target/policy/grp-name,
where the prefix distinguishes its category (as for devices or device groups), followed by a
series of device domain information. The device domain is organized in a tree structure,
written in the above naming convention back trace from the leaf to the root node of the
domain tree. After the domain series, for devices we use the device type information to
further categorize all devices associated with a domain node on the leaf of the tree, and
finally the legacy naming (e.g., serial number) from the production phase. Meanwhile,
device groups use the monitoring target (e.g., the room temperature) and grouping policy
for detailed classification.
Device domain information refers to either their deployed geographical information,
or logical organization of these devices. In NAPS, we can store multiple device domains,
and each domain indexed r is a tree structure with depth d r and width of each level as
{
}
∀ =
w
i
d
r
i
r
,
1,...,
. In other words, domain r is composed of total
∑
=
=
N
w
r
r
i
i
dr
1
domain
nodes. We call the “partition” of a domain tree by parameters
)
( { }
d w
r
r
i
,
as the “domain
rule,” and the corresponding data structure representation as “rule assignment.” For example, the rule assignment parameters are the number of bits to store the domain nodes in
each level of the tree. The metadata of each node include the name, its parents and children, and other properties (see Figure 9.6). In practice, project managers of an IoT system
will carefully plan the device deployment at a site of interest, where the first step is to plan
an overall device domain, for example, in a smart building environment, how many temperature and humidity sensors of what device type should be deployed at which location,
and this deployment stage eventually specifies a domain tree structure, and is stored in
NAPS repository.
As for device addressing convention, we propose to use the format:
address 1@ protocol 1/.../ address n@ protocol n/ IP
networks
address
non IP
−
−
−
−
−
−
to accommodate heterogenous protocols and standards in use across different platforms.
To allow the granularity of addressing the device in a hierarchy, we repeat the element
“address@protocol” one after the other from the device to the Internet gateway, which is
IP addressable (as the last part of the convention).