174
Internet of Things (IoT)
9.2.1.1.1 Scalability
The system must be able to work on a global scale. Because it is used for the IOT, it is
probable that S—in the long run—must cope with much more traffic than the usage of
DNS for URL name resolution performed today.
1. High Node Count: S should work with a very large number of participating nodes
(servers).
2. High Client Count: S should work with a very large number of participating clients.
3. Scalability to Medium IoT Adoption: S shall work in scenarios with a medium-level
adoption of the IOT across businesses.
4. Scalability to Large IoT Adoption: Class-Level Lookups: S should work in scenarios with a high-level adoption of the IOT across business and society, serving
class-level queries.
5. Scalability to Large IoT Adoption: Serial-Level Lookups: S should work in scenarios
with a high-level adoption of the IOT, serving also serial-level queries.
9.2.1.1.2 Performance
The IOT name service S must be able to deliver a performance that is suitable for global use
in very heterogeneous applications. This includes:
1. Fast Update Propagation: Information changed by authorized information providers should be propagated fast throughout the system, to avoid stale data.
2. Low Latency: The waiting time for an answer by S to a query shall be short, below
one minute to enable nearly real-time operations.
3. Ultra-Low Latency (optional): The waiting time for an answer to a query should be
very short, e.g., below a few seconds, to enable real-time or interactive applications
with human beings who deem longer waiting times unacceptable.
4. Acceptable Load (Average Node): The network, storage, and processing load of an
average node (server) of S must not be too high, to guarantee its correct and fast
execution of tasks.
5. Acceptable Load (Special Nodes, Root): The network, storage, and processing load
of all special or root nodes (servers) of S must not be too high, to guarantee their
correct and fast execution of tasks.
9.2.1.1.3 Robustness
S should perform reliably in the face of apparently random errors and attacks common
on the Internet. Again, most of the high-level requirements are not precise. Depending
on particular application scenarios, each high-level requirement should be refined and
mapped to several more exact metrics and corresponding tolerance intervals, so that their
fulfillment can be verified. A similar refinement process can be described in a mathematically rigorous way for security, especially confidentiality requirements. During additional
process iterations, additional time and domain-specific requirements—arising from specific application domains—should be combined and reconciled, and again compared to
design options.
Internet of Things (IoT)
9.2.1.1.1 Scalability
The system must be able to work on a global scale. Because it is used for the IOT, it is
probable that S—in the long run—must cope with much more traffic than the usage of
DNS for URL name resolution performed today.
1. High Node Count: S should work with a very large number of participating nodes
(servers).
2. High Client Count: S should work with a very large number of participating clients.
3. Scalability to Medium IoT Adoption: S shall work in scenarios with a medium-level
adoption of the IOT across businesses.
4. Scalability to Large IoT Adoption: Class-Level Lookups: S should work in scenarios with a high-level adoption of the IOT across business and society, serving
class-level queries.
5. Scalability to Large IoT Adoption: Serial-Level Lookups: S should work in scenarios
with a high-level adoption of the IOT, serving also serial-level queries.
9.2.1.1.2 Performance
The IOT name service S must be able to deliver a performance that is suitable for global use
in very heterogeneous applications. This includes:
1. Fast Update Propagation: Information changed by authorized information providers should be propagated fast throughout the system, to avoid stale data.
2. Low Latency: The waiting time for an answer by S to a query shall be short, below
one minute to enable nearly real-time operations.
3. Ultra-Low Latency (optional): The waiting time for an answer to a query should be
very short, e.g., below a few seconds, to enable real-time or interactive applications
with human beings who deem longer waiting times unacceptable.
4. Acceptable Load (Average Node): The network, storage, and processing load of an
average node (server) of S must not be too high, to guarantee its correct and fast
execution of tasks.
5. Acceptable Load (Special Nodes, Root): The network, storage, and processing load
of all special or root nodes (servers) of S must not be too high, to guarantee their
correct and fast execution of tasks.
9.2.1.1.3 Robustness
S should perform reliably in the face of apparently random errors and attacks common
on the Internet. Again, most of the high-level requirements are not precise. Depending
on particular application scenarios, each high-level requirement should be refined and
mapped to several more exact metrics and corresponding tolerance intervals, so that their
fulfillment can be verified. A similar refinement process can be described in a mathematically rigorous way for security, especially confidentiality requirements. During additional
process iterations, additional time and domain-specific requirements—arising from specific application domains—should be combined and reconciled, and again compared to
design options.