Developing NovaGenesis Architecture for Internet of ... - IEEE Xplore

3 downloads 32093 Views 508KB Size Report
Developing NovaGenesis Architecture for Internet of. Things Services: Observation, Challenges and ITMS. Application. Dhananjay Singh. Department of ...
ICTC 2014 1570018687

Developing NovaGenesis Architecture for Internet of Things Services: Observation, Challenges and ITMS Application Dhananjay Singh

Antônio Marcos Alberti

Department of Electronics Engineering Hankuk University of Foreign Studies Yongin, South Korea [email protected]

ICT Laboratory Instituto Nacional de Telecomunicações, INATEL Minas Gerais, Brazil [email protected]

Abstract— A new concept of Internet technology is fast emerging within the Internet domain as a successful extension to it has now knows to become Internet of Things

heterogeneous devices such as sensors, and actuators coupled with smart devices. Such scenario is described in [3]. Thus, any development framework will need to support the heterogeneous networking. The current technology is evolving to such an extent that IoT will have applications of RFID enabled patient identification and real-time information management [4]. There is also the example of Smart Objects Internet, which is being used for expanding the smart objects by effectively cutting cost and maximizing the output. Despite these advances, we are still witnessing a lack of Intelligent Systems on several areas. One example is the transportation systems in our cities. We are observing a continuous increase in traffic conditions, which results in congestion on roads. The traffic density at various time blocks of the day is different, with some peak hour traffic giving highest results in congestion and some minimum level of congestion [5]. This is becoming a major reason of research and a concern for transportation. We still lack a viable solution for Intelligent Traffic Management System (ITMS), which is efficient in terms of performance, cost, and effort needed for maintenance of the system. There have been various solutions reported in literature, such as sensor installations, like video images processing, usage of radars, laser radar, and passive acoustic arrays. These systems have high installation cost and they have high dependencies on terrain and environment conditions [6]. Notwithstanding, all machines and equipment’s that are part of ITMS will be recognized as objects and thus the Internet of Things for ITMS is born. In this paper, we explore how the IoT domain application of Intelligent Traffic Management System (ITMS) can be combined with a new convergent information architecture called NovaGenesis and its services. The main contributions of this paper are the design, development, and deployment techniques for a real world IoT application and integrated in to an upcoming architecture. We shall also discuss the challenges and the future plan of our approach. The reminder of this paper is organized as follows. First, the high-level NovaGenesis architecture for ITMS is described in Section 2, where the main design challenges and their observations for End-to End IoT applications are discussed in Section 3. Section 4 is dedicated to the most recent solution for ITMS and a brief description of data aggregation using

(IoT). The concept of wireless devices with embedded systems has paved the way for improved Intelligent Systems in the field of IoT. Intelligent Systems life cycle has begun with the advancements in development of IoT. However, the vision of application development on the platform of IoT is still in nascent stages. Our visualization of IoT as billions of “things” connected to each other under normal, as well as smart “things”, will be used in every sphere of our lives. High rise in recorded traffic density, road accidents, and crisis faced in regulating effective management of traffic control in rural areas have concerned us to develop a smart solution in context to Intelligent Traffic Management Systems (ITMS). We adopted this architecture and framework to provide the adequate ecosystem for the design and development of ITMS, which has the capability to overcome the challenges of transportation management system. Keywords— Internet of Things, Smart Devices, Traffic Monitoring, Intelligent System, IoT Applications, NovaGenesis.

I.

INTRODUCTION

Internet-of-Things (IoT) refers to a loosely coupled, a system of many devices, which has the power of sensing, processing, and communicating [1]. Alternatively, the Cluster of European Research Projects on the Internet of Things (CERP-IoT) [2] suggests that IoT is an integrated part of Future Internet (FI) and could be defined as an infrastructure of global machines/objects with capabilities of self-configuration based on standard and interoperable communication protocols, where physical objects and virtual “things” have attributes such as identities, physical attributes, and virtual personalities, as well as use intelligent interfaces, and are seamlessly integrated into the current and evolving information network. Global network infrastructure acts as a link among physical entities and virtual objects through the communication capabilities of existing networks and evolving networks. The relationship and development will be characterized by a high degree of autonomous data capture, event transfer, network connectivity and interoperability. These definitions include homogeneous devices, such as Smartphones, whose ad hoc communications are currently in practice. However, the challenge will be networking of

978-1-4799-6786-5/14/$31.00 ©2014 IEEE

1009

1

ICTC 2014

hierarchical NovaGenesis architecture, smart device request, actuator response and Nova Genesis pervasive systems. II.

(or NBs). With the use of MurmurHash 3 function, it generates SCNs for all entities. Unique SCNs can be used as global IDs in a mapping scheme for devices, software, people and other “things”. • NovaGenesis emphasizes on self-configuration methods. Services can self-organize and self-manage using published/subscribed NBs. • It enables the interoperability issue through proxy/ gateway/controllers (PGS). • Sensor modification in most cases is not required. Only the contracts via PGSs need to be changed. • SCNs can improve security and traceability. Contents can be easily associated to services, as well as with traditional security features. Security and privacy policy are under progress. It employs a Murmur Hash 3 function to generate SCNs that are pretty much unique globally. Here β>128 bits. Thus we have a concept of uniqueness of global identifiers, since they are flat SCNs. The concept of publishing of NBs enables NovaGenesis to discover various other named services. The SCNs can be linked to NLN, therefore approximating machine language from human languages. NLN-bindings enable NovaGenesis to include entire ontologies of names and relate them to SCNs. This approach provides traceability from natural languages up to smart objects [11].

DEVELOPING NOVAGENISES ARCHITECTURE

NovaGenesis (NG) architecture is a set of distributed systems aimed at convergent information processing, storage, and exchanging. Therefore, it includes the scope of the current Internet, as well as cloud computing, Service-Oriented Architecture (SOA), Information-Centric Networking (ICN), and IoT. In NovaGenesis design, every information processor is seen as a service, e.g. networking applications, network protocols implementations, cloud services, peer-to-peer applications, machine-to-machine services, etc.

III.

IOT SERVICES: OBSERVATION AND CHALLENGES

The NovaGenesis architecture provides an ideal environment for the establishment of trustable service networks. Services discover and negotiate with other. Therefore, low reputation services have low probability of contracting, which naturally enables the selection of better peers for trust network formation. NovaGenesis implements a “social devices” paradigm, where “things” are represented by trustable services. These services self-organize using names and contracts to achieve a deep, synergistic, orchestration of heterogeneous devices and their software representatives.

Fig. 1. NovaGenesis Components. These services organize themselves based on names and contracts to meet semantics rich goals, policies, regulations, etc. Therefore, NovaGenesis can be seen as a convergent name-, contract-, service-, semantics-oriented architecture. To support meaning, NovaGenesis adopts natural language names (NLNs) or self-certifying names (SCNs). Name bindings (NBs) relate one name to one or more names or even to information objects, e.g. a file handling system [7]. Namebindings form a web of connected names. These NBs are published and subscribed by services, capturing the relationships among physical or virtual existences. All the communication, processing, and storage are name-oriented [10]. The protocol stacks are built on demand in a contractbased way. The Figure 1 illustrates the NovaGenesis components. The PGS (Proxy/Gateway System) represents non NovaGenesis resources, such as an operational system networking interface (e.g. Ethernet or Wi-Fi) or a set of wireless sensors/actuators. It also acts as a gateway, forwarding NovaGenesis messages to/from these technologies. In other words, NG messages are adapted to be transported over legacy technologies by the PGS. The following points can be considered regarding NovaGenesis architecture, which will help us to identify the integration with the ITMS. • All entities and objects in NovaGenesis are related each other by a special technique called name-based bindings

Intelligent    Services   Advanced  Services  Analysis   Services  at  work   Fig.2. Internet of Things Service Aspects. Let us view the ITMS as a part of NovaGenesis. One such application can be generalized in to various spheres of industries. Let us take first an example of Intelligent Industrial Internet of Things. All industries need to be modernized for effective cost cutting and optimization of output. The world is fast being connected digitally and they are being connected with varying topology. Industries transformation with NovaGenesis design will be more or less digitized. It can change the way we do our jobs at our hand [8].

1010

2

The idea of Intelligent Services is that they will have an array of advanced sensors representative services and that they will facilitate with the communication portion of the sensors. These sensors representative services will be organized in a society of trustable services and operated by a console based or a graphical user interface based software application, depending upon the application utilities. The human operators will provide unambiguous objectives, rules, regulations, etc. to guide the social devices operation. A simple application for a common public may require a simple and self-explanatory user interface so as to assist the service utilities. Figure 2 illustrates that these representative services will probably form hierarchies of trustable services, to support the emergence of Smart Services at the higher levels of the architecture.

for a greater service quality. Quality of service must be defined and easily accessed with a prominent security solution. A. Traffic problem in IoT services The Figure 5 shows the application of the NovaGenesis architecture model for an ITSM. This is a hierarchical structure. The First Level contains the physical entities of the architecture. Each node comprises of internal hardware that are organized in such a manner so as to offer a functional access points, e.g. a computing device, a base station, wireless sensor, and actuator points, etc. Each such machine/computing device can support one or more operating systems (OSs) running upon single or multiple CPUs or programmed FieldProgrammable Gate Arrays (FPGAs). These devices have a software environment offering functionalities as services. These environments have a host of agents’ services running. Some of them are life cycle agents, which help to deal with the complex service orchestration.

Machine   connec7on  and   communica7on:   Service  

NovaGenesis  

Intelligent   Services  

Level  Three:  High  Layer   Sensor   control   applica7ons   Service  

Advanced   Sensors   Service  

Level  Two:  Hybrid  Layer   Level  One:  Fundamental  Layer  

Fig.3. Intelligent Services.

Level  Zero:  Physical  Layer  

The second portion of Intelligent Services is Services at Work (SW). This SW is the actual objects which will be working at the industrial or any generic level of automation, being active part of the IoT.

Fig. 5. Layered Model Approach of NovaGenesis. The above leveled model comprises of four layers that are fundamental of NovaGenesis approach to any problem. Let us describe each level of NovaGenesis architecture: • Level Zero: This level consists of actual sensors and actuators – the physical substrate of IoT sensorial and actuating systems. This is the level where physical links, as well as the wireless links gets established into the architecture. • Level One: This is the most important level in the architecture and is known as Fundamental Level. This level comprises of specialized services streams, which can work in parallel and coordinate the activities of accessing and publishing the information. This includes OS agents1, Life-Cycle agents, Proxy agents, Linking Agents, and most importantly Broker agents. • Level Two: This level is also known as Intermediate level. It has specialized services, which includes Hash-Table Service, Binding Forwarding Service, Publish/Subscribe

Service   quality   Connec7ng   services    at   work  

Intelligent   Design  of   Services  

Services   at  Work   Fig 4 : Intelligent Objects. The idea of Services at Work is that each such service will be connected through sensors and communication channels. Each such object, either, will be a sensor/actuator itself or embedded with the object itself. The service primary aim is to be connected with the other services or the gateways. There should be an intelligent design of services so as to optimize the object use with the generic domain with which it is going to be deployed. Last but not the least these services must be needed

1

1011

3

Agents are implemented as any other service.



Service, Autonomic Service and Searching and Discovery Service. Level Three: This is the application level of the NovaGenesis architecture. It makes the system compatible for various IoT based application [8].

level controls specified by DMS instances. Thus, the PGS besides a proxy is also a gateway for legacy technology.

The service-based application can be extended to administration, surveillance, command, and control, education, weather and air quality, transactions and payment, traffic management systems, etc. These applications are possible because services transactions as well as contract services are made at run time using name-based discovery and contracting. Hence, we are going to utilize the NovaGenesis architecture Model for ITMS design, which supports FI services. This architecture is capable of solving fundamental issues of IoT, such as addressing, mobility, routing scalability, security, and control to support billions of things to connect with Internet. The final aim of any ITMS will be to merge with Internet so as to support thousands of users simultaneously about the traffic conditions, sensing and actuator control, intelligent traffic management, etc. IV.

Fig. 6. Layered Model Approach of NovaGenesis. The sampled readings provided by PGSs are aggregated and processed at ITMS, which also doubles as a server for requests from a RFID CR mounted on a moving vehicle or a Smartphone requests by any user or any web-based query. The ITMS processes the aggregate sensor reading and produces an actuation action, which is then sent to the Alarm/Alert/Traffic Density Lights actuators via their PGSs. Even the moving vehicles can register their preferences through their PGSs for types of alerts/alarms of the type of traffic they want to move ahead at each cross roads. The MS/C samples number of moving vehicles every 30 seconds, and results in required Actuator actions. We identified the following use cases for a feasible solution into the system:

NOVAGENESIS-ITMS: INTELLIGENT TRANSPORTATION MANAGEMENT SYSTEM

The present traffic in global cities is continuously increasing around the world, especially in large urban areas. The resulting traffic congestion has become a major bottleneck to transportation specialists and decision makers. The existing methods for traffic management, surveillance, and control are not meeting the quality standards adequately in terms of cost, maintenance, performance, and support. The generation of ITMS has evolved in to four generations of having different timelines and different characteristics [4]. In the context of ITMS, we are relying on the four layers of NovaGenesis architecture to resolve the issues of congestion and preferential path advice to the user. Figure 6 describes the design of the actual prototype system being developed by us – an ITMS implemented over NovaGenesis architecture and that can be accessed by Smartphone or RFID smart card. At each cross roads, a Motion Sensor/Counter (MS/C) samples the number of vehicles crossing periodically. Moving vehicles have mounted RFID Card Readers (CRs) that can identify every vehicle. Alarm/Alert/Traffic Density Lights actuators provide the feedback controls to the real world. Smartphone devices can be used to obtain traffic information. The MS/Cs, CRs, and Actuators are represented and software-controlled by one or more PGSs. The PGSs exports sensors, actuators, and card reader’s capabilities to the NovaGenesis by publishing their metadata to other NovaGenesis services. Device Control Services (DMSs) generate configuration, optimization, reporting, and several other controlling actions that need to be reflected at distributed PGSs. Thus, the PGSs translate the control actions received from DMSs to specific device technologies messages, encapsulating them according to legacy transport. For example, a ZigBee Motion Sensor will have a PGS (a trustable service) that represents and controls them according to high

A. Data Aggregation using hierarchical NovaGenesis An IoT system carries the unique features having sensing and actuating nodes. The sensors detect a physical/measurable quantity. This is the raw data which is then processed in to meaningful information. The most common approach is by using a hierarchy of data aggregation nodes, here designed as TMSs. • Automatic Traffic Management: When the level of requests is very low or there is a time period of traffic where there is a minimum requests, then the predefined/default value can be displayed. • Traffic Query via Smartphone: The users can query via User Services (USs) the status of the traffic at a desired cross roads or a stretch of an area by using a Smartphone application. The Smartphone is also represented by a PGS inside NovaGenesis cloud. Therefore, the USs needs to establish dynamic Service Level Agreements (SLAs) with Smartphones’ representatives in order to enable Publish/Subscribe in the NovaGenesis architecture. Traffic Query can also be done by moving vehicles using their smart card/RFID readers. In this case, a PGS is also involved.

1012

4

B. Actuation Results by the Processed Sensor Information We can visualize that in any IoT based application system we can have one or more actuators that will work as a results of sensor information processing, correlating, and decision making. Any change in the sensor information can trigger the corresponding changes in the actuator systems. In the TMSs, a change in the density of traffic from any of the Motion Sensors can change the aggregate definition of resultant traffic density or the inferences dependent upon the traffic density. Thus actuator can release any alarms, alerts or traffic condition light according to the management system. This actuator driven systems can be seen in [9]. The PGSs will publish MS/Cs, CRs, and Actuators information using the NovaGenesis Publish/Subscribe Service (PSS). Information processing, correlation, and decision making can be done by distributed Cognitive Services (CSs), which are level three services as shown in Fig. 5. The CSs will subscribe published information according to pre-established SLAs with several PGS instances. After subscribing the information via PSS, the CSs can correlate information to obtain the required background for decision making. Continuing, the CSs will use some artificial intelligence (AI) technique to decide which controls must be published for Actuator’s PGSs. A candidate technique is the combination of rule-based systems and fuzzy logic.

compare our architecture with traditional WSAN [9] and Pervasive system [10] we observe various challenges for integration into this new approach. A. NovaGenesis and WSAN •



C. Smart Device Request and Actuator Response This IoT-based system will entertain all the queries that make the system seamless at all interfaces, will be it Smartphones or web based interfaces. Smartphones and RFID CRs also needed to have PGSs that represent them on NovaGenesis scope. Therefore, these PGSs will establish SLAs with one or more CSs to enable queries for the aggregate traffic conditions at the respective cross roads. User Services at both the Smartphones and the RFID CRs define the traffic preferences of the respective user. This type of behavior is often found in pervasive systems [10], where devices can query data from anywhere in the system. However, in NovaGenesis architecture the security and privacy of these queries is greatly improved, since user representatives (USs), cognitive services, and devices representatives (PGSs) need to establish SLAs before any information transferring. Also, SCNs provide self-verifiable identifiers and locators, which solve security issues of attributed address we have today. After SLAs establishment, one service can subscribe information published by other services via PSS. V.



Interaction Pattern: We have observed that WSANs mostly use one-way communication pattern i.e. the sensors produces data and forwards that to a central processing agency. This central agency processes the information and then, based on some inference, it sends the output command to desired actuator systems. From the observation in [9][10] it is deciphered that a pervasive system ideally needs to support the interaction pattern of request and response. In NovaGenesis, this patter is replaced by a publish/subscribe pattern. The PGSs, TMSs, CSs, and USs establish dynamic SLAs and publish/subscribe information via PSS. While we expect this approach can improve security and privacy, its performance is still an open research topic. GUI support for Devices: WSANs have data processing units. They receive the data, process the data, and deliver some actions. GUI presence is very limited in these systems. All types of pervasive computing essentially thrive on GUIs supporting the computation and user preferences channel. NovaGenesis also needs to incorporate this GUI technique for more successful implementation of ITMS. A possibility is to develop a GUI for USs, PGSs, and CSs. Mobility Analysis: WSANs usually have static linked nodes and static configurations. Pervasive systems are full of mobile devices which are free to move around in to the region. The Smartphone in ITMS is a mobile node. Before being allowed to enter its preferences for traffic of a particular area, the Smartphone user needs to perform authentication procedure. NovaGenesis must be able to support the static, as well as mobile users and fully support the authentication procedures from the Smartphones and web based authentication procedures. NovaGenesis natively support mobility of any entity, including services, devices, and information. Moving entities just need to update published name-bindings to other entities when changing from a physical attachment or substrate hardware/software to another. Mobility is fully supported by name rebinding. However, the procedures for services and devices authentication is already designed, but not implemented yet.

B. Nova Genesis and Pervasive Systems

IOT SERVICES AND CHALLENGES: NOVAGENESIS ARCHITECTURE SOLUTIONS



The present architecture is a novel proposal in which the sensors, actuators interaction, requests are in form of services and is utilized for traffic management system. These services need to go into the layered format of the NovaGenesis architecture, where MS/Cs, CRs, and Actuators are actually at level zero and their control and management are at the layer two. Cognitive and user services are at level three. When we

1013

5

Periodic Generation Pattern: We have observed that pervasive systems operate as event driven systems. Unless an event is generated, these systems perform the required actions. On the other hand, WSAN produces large amount of data which is used for parallel samplings. In the NovaGenesis environment, the motion Sensors for the ITMS will generate the traffic density reading at the rate of one reading per 30 seconds.





Data Aggregation: There will be different types of vehicles and their preferences of traffic on different regions. Thus the data periodically generated needs to get mapped in to fuzzy logic domain [11]. This fuzzy logic computation and aggregation of similar events will further drive the computational power of the NovaGenesis and will result into the Actuator output. Data aggregation will be done by PGSs, TMSs, CSs, and USs. Power Management: In traditional system, it is a challenge to maintain the battery power. The motion sensors in the ITMS sleep if the traffic density is very scarce for few seconds in between the desired periodicity. NovaGenesis will need to adapt to the energy conservation patterns for the system. PGSs, TMSs, CSs, and USs must adopt energy-aware profiles.







C. Novageneis and Network Interoperability The Internet of Things will have host of homogeneous, as well as heterogeneous devices and it will have to support different networks stacks. Common network interfaces will include IEEE 802.11 (WLAN), IEEE 802.15.4, Bluetooth, GPRS, EGDE, UMTS, etc. NovaGenesis must make this effort of uniting these homogeneous, as well as heterogeneous devices into a single system needs to take into account the nature and interoperability of the networks supported by the devices. Adaptation on the part of routing based on type of protocols and type of devices may be applied at the level zero and level one of the NovaGenesis architecture. The approach is to create PGSs for a diversity of devices, representing them at NovaGenesis ecosystem. PGSs act as a proxy for IoT devices, Smartphones, and RFID CRs, exposing them via publishing its names, name-bindings, and metadata. The PGS represents devices for SLA establishment. It is also a gateway to encapsulate information and control to/from devices using the diversity of standardized protocols and technologies. This approach is scalable, flexible, serviceoriented, name-oriented, mobile-friendly, and adequate to deal with specific requirements of IoT sensors/actuators. VI.

NovaGenesis and Adaptation of Existing Software Interface: An existing software framework will naturally help the named-based classification of NovaGenesis, which will thus utilize the power and computation ability of the existing software. The software can be used for suitable GUI development or entity based fusion of information. NovaGenesis and Abstractions Development for Internet of Things System: It is clear that Internet of Things (IoT) has various Internet components, especially Web Services. NovaGenesis specifically being the architecture based on self-services need to adapt/interface to existing web services. NovaGenesis and Dynamic Discovery of Services: NovaGenesis framework should allow for the system to evolve at the run time implementation of the services. Dynamic discovery of services needs to be investigated and more refined in the NovaGenesis architecture. REFERENCES

[1]

Kortuem G., et al., "Smart objects as building blocks for the internet of things," Internet Computing, IEEE, vol. 14, pp. 44-51, 2010. [2] Alberti A. M., Singh D., “Internet of Things: Perspectives, Challenges and Opportunities”, International Workshop on Telecommunications (IWT2013), June 2013. [3] Pathak A., Mottola L., Bakshi A., Prasanna V. K., Picco G. P. "Expressing sensor network interaction patterns using data-driven macroprogramming," Proc. 5th IEEE Int’l Conf. Pervasive Computing and Communications Workshops, 2007, pp.255-260. [4] C. So-In, R. Jain, S. Paul, J. Pan, "Virtual ID: A Technique for Mobility, Multi-Homing, and Location Privacy in Next Generation Wireless Networks", 7th IEEE CCNC 2010, pp. 1-5, 2010. [5] Becker C., Schiele G., Gubbels H., Rothermel K., "BASE - a microbroker-based middleware for pervasive computing," Proc. 1st IEEE Conf. Pervasive Computing and Communication (PERCOM '03), IEEE CS, 2003 pp. 443- 451. [6] Alberti A. M., Singh D. “Developing a NovaGenesis architecture model for service oriented future Internet and IoT: An advanced transportation system scenario”, WF-IOT, Seoul, March 2014, pp 357-364. [7] Tripathi G., Singh D., Loo K. K., "EOI: Entity of Interest Based Network Fusion for Future Internet Services", ICHIT, Korea vol. 206, 2011, pp. 39–45 [8] Lin P., Bi J., Hu H., “Internetworking with SDN using existing BGP” Proceedings of The Ninth International Conference on Future Internet Technologies, Tokyo, Japan, June 18 - 20 2014. [9] Huang D. Y., Yocum K., Snoeren A. C. “High-Fidelity Switch Models for Software-Defined Network Emulation”, Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking, Hong Kong, China, pp. 43-48, 2013. [10] Singh D. "Developing an Architecture: Scalability, Mobility, Control, and Isolation on Future Internet Services", Second International Conference on Advances in Computing, Communications and Informatics (ICACCI-2013), Mysore, India, 2013, pp.1873-1877. [11] V. Kafle and M. Inoue, "HIMALIS: Heterogeneity Inclusion and Mobility Adaptation Through Locator ID Separation," IEICE Trans. Commun., Vol. E93-B, No. 3, 2010. [12] A. A. F. Loureiro, L.B., Ruiz, "Autonomic Wireless Networks in Smart Environments," Communication Networks and Services Research, 2007. CNSR '07. pp.5-7, 14-17 May 2007.

FINAL REMARKS

We believe that in order to achieve the vision of Internet of Things application on NovaGenesis architecture we need to have the interfaces (PGSs) for existing wireless sensor and actuator networks and pervasive computing devices. There are significant challenges to utilize the existing devices from the NovaGenesis architecture point of view. Therefore, there is a strategic need for the creation of an application development kit for such applications, using various adaptation and reusing the existing concepts and components. We believe that development of such a strategic framework can be done as follows: • NovaGenesis Name-Oriented Specific Language for the Internet of Things: We need to model all networked devices into Named Classes as understood by the NovaGenesis architecture. Devices need to be classified and proper names and metadata selected to facilitate SLA establishment as well as negotiation.

1014

6

Suggest Documents