Semantic Network Monitoring and Control over Heterogeneous Network Models and Protocols Christopher J. Matheus1 , Aidan Boran1 , Dominic Carr2 , Rem Collier2 , Barnard Kroon2 , Olga Murdoch2 , Gregory M. P. O’Hare2 , and Michael O’Grady2 1
2
Bell Labs, Blanchardstown, Ireland,? ? ?
[email protected] CLARITY: Centre for Sensor Web Technologies, School of Computer Science & Informatics, University College Dublin, Dublin, Ireland†
[email protected]
Abstract. To accommodate the proliferation of heterogeneous network models and protocols we propose the use of semantic technologies to enable an abstract treatment of networks. Network adapters are employed to lift network specific data into a semantic representation that is grounded in an upper level “NetCore” ontology. Semantic reasoning integrates the disparate network models and protocols into a common RDFbased data model that network applications can be written against without requiring intimate knowledge of the various low level-network details. The system permits the automatic discovery of new devices, the monitoring of device state and the invocation of device actions in a generic fashion that works across network types, including non-telecommunication networks such as social networks. A prototype system called SNoMAC is described that employs the proposed approach operating over UPnP, TR-069 and SIXTH network models and protocols. A major benefit of this approach is that the addition of new models/protocols requires relatively little effort and merely involves the development of a new network adapter based on an ontology grounded in NetCore. Keywords: semantic computing, sensing web, network monitoring, home area networks
1
Introduction
The Internet of Things (IoT) is expected to encompass over 15 billion devices by 2015. In addition to shear volume, there is the added complexity of dealing with the unchecked proliferation of new network data models and protocols. To deal with these issues network and active media applications will not only require high performance and scalability but will also need the means for quickly and ??? †
This work was partly funded by the Industrial Development Authority of Ireland. This work was partly funded by Science Foundation Ireland (SFI) under grant 07/CE/I1147.
2
dynamically evolving to accommodate the changing universe of devices. Doing this effectively necessitates a new approach for integrating network models and protocols that facilitates the management of devices and does so at various levels of abstraction so they can be handled generically as collections of devices while maintaining the specifics necessary to monitor and control them. This paper advocates an approach to solving this problem that leverages the benefits afforded by semantic web technologies. Semantic web technologies enable the definition of formal data models called “ontologies” that provide a number of conceptual and computational benefits, including: data model alignment, heterogenous data integration, built-in data abstraction mechanisms, basic forms of automated inferencing, dynamic metamodeling and automatic consistency checking. With recent advancements in formal reasoning and querying capabilities (e.g., OWL 2 [8], SPARQL 1.1 [6]), semantic technologies are ready to be taken seriously in production environments, including those involving heterogeneous network monitoring and control. The Bell Labs’ SNoMAC (Semantic Network Monitoring, Analysis and Control) research effort is implementing a semantic-based approach to the dynamic monitoring, analysis and control of heterogenous telecommunication networks. The SNoMAC solution formally describes networked devices based on a layered collection of extensible ontologies grounded in an upper-level ontology called NetCore. Together these ontologies make it possible to hide or indeed expose device details to the extent necessary for the problem at hand. In this way device- and protocol-specific information can be semantically encapsulated at the lowest levels, with higher layers focusing on more generic networked device characteristics. As a result, applications can be written against SNoMAC’s formal semantic API, ignoring lower-level details that may change as standards evolve and new ones are added. To demonstrate this concept in practice, Bell Labs is working with CLARITY: Centre for Sensor Web Technologies3 at University College Dublin (UCD) to integrate SNoMAC with their SIXTH sensor middleware [10]. This paper provides an overview of the SNoMAC approach and describes a functioning prototype that detects, monitors and controls devices in a home area network involving UPnP [5], TR-069 [4] and SIXTH-based devices.
2
SNoMAC Overview
SNoMAC is designed specifically for 1) the auto-discovery of new network devices, 2) the remote setting of state variables to configure device functionality, 3) the execution of commands on the devices and 4) basic network analysis. An overview of the SNoMAC concept and prototype architecture is depicted in Figure 1. Network Adapters (one for each supported protocol) interface with the network both to “lift” device data into a semantic representation before sending it to the server and to invoke device-specific commands coming from the client via the server. Such adapters interface with the SNoMAC server through two simple 3
http://www.clarity-centre.org/
3
REST-based Web service APIs supported by the server’s Listener-Controller Interface; the API implemented by the network adapter is for processing requests issued by the server (e.g., get/set state variables, invoke commands) and the other is implemented by the server to receive pushed updates from the adapters as the devices in the network change. The information that is exchanged is in the form of RDF annotations based on a network-specific ontology that is aligned with the NetCore ontology (i.e., all network ontology classes and properties are sub-classes or sub-properties of entities defined in NetCore).
Fig. 1. Conceptual Overview of SNoMAC.
The SNoMAC server initiates connections with available network adapters by requesting information for all known devices and issuing a request to be informed of subsequent device changes (i.e., node additions, deletions and state updates). Information about devices is stored in the Semantic Engine, which includes an RDF data store plus the means by which to automatically infer new information about the devices based upon meta data stored in their corresponding ontologies. Web-based clients connect to the SNoMAC server through the Client Manager. Communication from the server to the client includes device information, action results and event notifications triggered by changes in the network. The clients communicate back to the server using “action requests” representing device specific commands that are propagated to the designated device where it is executed. Users interact with devices by clicking on their graphical representa-
4
tions to bring up a menu of available commands; these commands include getting and setting device variables (e.g., volume) and device-appropriate actions (e.g., “increase volume”).
Fig. 2. Base Classes and Properties of the NetCore OWL Ontology.
2.1
Ontologies
In Computer Science “an ontology is a specification of a conceptualization” [7]. We use the term more specifically here to refer to RDFS [2] and OWL [8] data models that formally define the classes, properties, individuals and their interrelationships relevant to a particular problem domain (e.g. networks). SNoMAC is built around the NetCore ontology shown in Figure 2. This formal OWL 2 ontology is designed to describe arbitrary networks at the highest level of abstraction, and as such consists of a relatively small number of primary classes: Network, Node, Link, State and Action. The N ode and Link classes make up the essential core of the ontology and are used to represent individuals that constitute network nodes and connections between them, respectively. Individual N ode and Link instances are identified as members of one or more N etworks through the networkN ode and networkLink properties. While links can be represented as instances of the Link class, which allows them to be annotated with additional information (e.g., bandwidth, isActive), they can also (or alternatively) be represented using the symmetric property linkedT o, which allows them to be treated as OWL properties and thus can leverage optional property characteristics (e.g., symmetry,
5
propertyChains). linkedT o is defined as a sub-property of connectedT o, which means that a node that is linkedT o another node is also connectedT o that node. connectedT o, unlike linkedT o, is a transitive property, meaning that if n1 is connectedT o n2 and n2 is connectedT o n3 then it can be inferred that n1 is connectedT o n3. To go beyond basic network topology the ontology includes State and Action classes that represent state variables (for N odes or Links) and executable actions (for N odes), respectively. State variables may be read-only or read and writable (i.e., configuration variables). Actions represent parameterized functions that can be executed on a node, with the actionTemplate representing the functions call signature. The NetCore ontology is intended to be extended and specialized to encompass various telecommunication networks. It is the inheritance afforded by the alignment of the upper-level NetCore ontology and the lower level telco ontologies that permits applications to deal with specific telecommunication devices in a generic fashion, ignoring low-level details until they are required to invoke some action. The details of of the low level models/protocols are handled by the specific network adapters that employ their own ontologies. As an example, the base classes and properties for the partial TR-069 ontology developed at Bell Labs for SNoMAC is shown in Figure 3. The UPnP ontology used in SNoMAC comes from [11], which has been align with the NetCore ontology. A similar ontology for SIXTH has been developed by UCD. 2.2
Semantic Benefits
Formal ontologies are used in SNoMAC to provide the following benefits: – a formal API that can help ensure programers interpret the model consistently through automated consistency checking and a precise definition of what can be inferred from data; – hierarchical abstractions that can more easily hide or reveal low level modeling and implementation details; – automated inferencing of class and property membership that makes it trivial to inherit higher abstractions; – ability to encode certain types of axioms that automatically detect specific conditions; The following examples illustrate some of these benefits. Abstraction and Specialization. Inheritance is the cornerstone of semantic reasoning and is heavily leveraged in SNoMAC. Simply put, it involves automatically inferring an individual’s class or property membership based on an ontology’s class and property hierarchies. For example, if an ontology states that F emtoCell is a subclass of TR069:Device and TR069:Device is a subclass of NetCore:Node and we state that f emtocell1 is a member of the class of F emtoCell then it can automatically be inferred that f emtocell1 is both a TR069:Device and a NetCore:Node, even if this information isn’t explicitly stated in our data
6
Fig. 3. Base Classes and Properties of the TR-069 Ontology.
description of f emtocell1. This kind of subsumption reasoning can also be used to infer property membership as in the example described above of how all linkedT o relationships imply a similar connectedT o relationship. This form of inheritance reasoning provides the primary mechanism for supporting abstraction and data integration in SNoMAC. By aligning the NetCore class and property hierarchies with those of the network protocol specific ontologies, we can treat all devices as NetCore devices regardless of which network protocol they use. The fact that a low-level device is in fact an abstract NetCore device is automatically inferred by the system through the alignment of NetCore with the specified network ontologies. Transitivity. As described above in the connectedT o example, a transitive property allows a reasoner to infer a property relationship between two entities (e.g., connectedT o) if they can be related through intermediary entities using the same property. The transitive characteristic of the connectedT o property allows for minimal specification of node connectivity in the data – specifically only the direct linkedT o connections need be provided – while permitting the automatic inferencing of total network connectivity if and when needed. Property Chaining. Similar to transitive properties, property chains allow properties to be defined by defining a path of property connections chained from one entity to another. The classic example of this is the definition of the relationship uncleOf as the chaining of the brotherOf and parentOf properties: if Bob
7
is the brotherOf John and John is the parent of Sue then Bob is the uncleOf Sue. In NetCore, a property chain is used to relate the property linkedT o to the chained properties nodeT oLink and linkT oN ode4 . Accordingly, two nodes n1 and n2 are automatically inferred to be linkedT o each other whenever there is a link instance l that connects the two by the relationships n1 nodeT oLink l and l linkT oN ode n2. Because linkedT o is a sub-property of conncetedT o, this property chain also allows the automatic inferencing of full network connectivity (as defined by connectedT o) without even mentioning either linkedT o or connectedT o in the data representation of the network. Complex Axioms. It is possible to define complex axioms in OWL from which we can automatically infer more interesting and useful relationships. In the following example a technique referred to as “man-man” [13] is used to automatically infer actual functional connectivity (as opposed to the logically stated connectivity of the network design); such a relationship could be instrumental in identifying and isolating network faults. The axioms below specify that two nodes are activelyConnected (line 7) if all of the intervening nodes along the logical path that connects them (i.e., the connectedT o path) are actually active (line 3). This is accomplished by creating a property called isActiveSelf that takes on the value of an individual node in the event that the node is an ActiveT hing (line2). An ActiveT hing is any thing (such as a node) that has the property isActive equal to true (line 1). This isActiveSelf property is an ObjectP roperty and as such can be used in a property chain with connectedT o to define what it means for two nodes to be activelyConnected (line 3). Then, whenever a node n2 is know to be active (line 4) and the logical connections between n1 & n2 and n2 & n3 are declared (lines 5 and 6) it can be inferred that n1 and n3 are activelyConnected: ActiveT hing ≡ isActive some true
(1)
ActiveT hing ⊆ isActiveSelf some self
(2)
connectedT o ◦ isActiveSelf ◦ connectedT o ⊆ activelyConnected (3)
3
n2 isActive true
(4)
n1 connectedT o n2
(5)
n2 connectedT o n3 n1 activelyConnectedT o n3
(6) (7)
The SNoMAC Prototype
A SNoMAC prototype has been developed that targets the task of monitoring and controlling a Home Area Network that includes UPnP devices, TR-069 devices and and an array of sensors managed by SIXTH. Specific use cases that 4
Although not graphically depicted in Figure 2 this property chain is defined in the NetCore OWL ontology.
8
Fig. 4. SNoMAC Web Interface with JSON-LD RDF Objects shown in the Console.
the system can handle include discovering when new devices are added or removed, remotely getting and setting device state variables, issuing commands to specific devices followed by processing their results and seamlessly handling the addition of new network types through the introduction of additional network adapters. The core of the prototype has been implemented as a node.js 5 application that connects to independent network adapters through a Web service API using JSON-LD6 to exchange serialized RDF data about the networked devices. Clients connect to the server via websockets and pass event-driven messages using JSON-LD. An RDF datastore and SPARQL [6] engine (based on the node.js module rdfstore 7 ) has been installed in the prototype and loaded with the NetCore ontology. OWL 2 inference rules have been implemented as SPARQL to enable the basic reasoning required to support semantics built into NetCore. A desktop Web interface for the prototype has been implemented using HTML5/JavaScript. The interface has been designed to provide four views on the network (Home, Device, Network and People), although only the Home View is fully implemented. The Home View, which is shown in 4, depicts the devices distributed across the rooms of a house. The set of devices depicted by the interface currently includes temperature sensors, lamps, femtocells, WiFi router, a media server, computers and printers. Mousing over a device brings up a menu 5 6 7
http://nodejs.org http://json-ld.org https://github.com/antoniogarrote/rdfstore-js
9
that permits the viewing and setting of state variables as well as the invocation of device specific actions. For example, when a user mouses over a Lamp and the pop up menu displays one of the state variables as “on/off: on”, the user can select the submenu next to the variable and opt to turn the device off, resulting in a command being sent back to the server where it is forwarded on to the appropriate network adapter to turn the device off; when the state of the device changes the network adapter pushes the updated state back to the server and it is passed on to the client where the state of the lamp changes accordingly (i.e. it turns the state variable to “off” and the icon goes dark). 3.1
SIXTH Integration
SIXTH [10] is an extensible, scalable and intelligent Sensor Middleware based upon the Open Services Gateway initiative framework (OSGi) 8 which has been developed by the CLARITY team at UCD. As illustrated in Figure 5, the primary SIXTH components include: – a propertiesbased sensor model for control of, and access to, sensing devices; – adaptors that provide sensor specific implementations to a standardised interface; – higherlevel APIs for access to SIXTH’s core functionality covering data access; – retasking, notification, security and discovery; – data processing service layers which build upon the APIs; – integrated multiagent system to support insitu reasoning and WSN management; SIXTH provisions extensibility by accommodating the dynamic addition of new functionality at runtime. Connection mechanisms to heterogeneous Sensor Networks are implemented as plug and play components termed Adaptors, and such functionality may be injected into an already running SIXTH instance in order to connect into the associated network. This scheme can also be used to incorporate dynamic service level behaviour such as a custom data retention policy or a sensor data aggregator function to supplant or complaint existing functionality. Within SIXTH we encompass sensing of data from web resources (cybersensing) as a first-class citizen alongside direct sensing of physical world phenomena. SIXTH can dynamically configure data streams, referred to as CyberSensors, that can be both public and personalised (e.g., RSS, Twitter, Gowalla, Facebook and FourSquare). We thereby move toward a unified view of the Sensor Web. SIXTH is targeted at adaptive sensor networks and focused on runtime (re)tasking of sensor nodes. Cyber-sensing streams can be dynamically configured and the details and differences between these are hidden from the end user. SIXTH is primarily a gateway side middleware effort (software resides on the host machine) this decision was made so as to facilitate support for heterogeneous 8
http://http://www.osgi.org/
10
Fig. 5. The SIXTH Sensor Middleware System Architecture
hardware, even in the case where we have no involvement in the programming of the network, within the SIXTH system an adaptor can be defined for any network. Despite this, efforts have been invested in developing an intelligent, agent driven, sensor network deployment running Agent Factory Micro Edition has been developed to run alongside the SIXTH gateway [14]. The SIXTH system architecture can be seen in Figure 5. Within this high level architecture several important concepts are evident. The Data Broker module is collectively responsible for distribution and management of sensor data. The discovery sub-system provides notification of resource status i.e. node timeout, adaptor creation etc) and management notice dissemination base upon credentialed security policies. The service registry in turn provides access to service modules e.g. sensor transformation services, aggregation services etc. To create a communication bridge between SIXTH and SNoMAC, a software component was developed conforming to the SNoMAC Network Adapter API.
11
The Restlet9 engine for Java 5 was used to enable RESTful communication. A SIXTH sensor device ontology was developed in alignment with NetCore. The initial development effort took less than three days and resulted in a complete working system capable of passing the entire suite of API tests except action commands. While this work represents just one case study, it does provide support for the claim that the addition of new network models/protocols to SNoMAC – and thereby enabling the semantic benefits that may accrue – is relatively simple and striaght forward.
4
Related Work
Br¨ oring et al [3] has undertaken similar work from the perspective of the Sensor Web Enablement initiative, and present a framework that uses semantically enabled matchmaking to allow Plug & Play usage of Sensors within a network using SensorML standards. Similarly, Aloulou et al [1] present an OSGi based framework, also focussed on enabling plug & play sensor integration with a semantic reasoning engine, within an Ambient Assisted Living scenario. Liu and Zhao [9] identify and describe how multiple sensors can be combined and used to fulfil various end user needs using semantic matchmaking, and further expanded this concept with Semantic Streams [15]. Similar work has been undertaken by Tran [12]. Although SNoMAC leverages a similar semantic approach, what sets it apart and marks it as novel is the aim to present the relevant semantic information to the end user through the interface as per Figure 4. This allows the end user to navigate the network at the appropriate level of abstraction, and allows them to make well informed changes at the best possible level.
5
Conclusion
The rapid evolution of communication networks presents challenges that require a new approach to network monitoring and control. Semantic technologies offer the means to encapsulate network details at various levels of abstraction making it easier to develop solutions that can adapt to changing data models and protocols. SNoMAC, and the NetCore ontology on which it is predicated, provide an example of how this can be effectively achieved today, at least in the domain of home area networks. We plan to continue developing the UPnP and TR-069 ontologies to increase the level of coverage over the functionality of the devices based on those models/protocols. We also intend to further explore the extent to which the SNoMAC approach can be seamlessly applied to other network models/protocols, e.g., ZigBe, Bluetooth, Bonjour and OMA-D. This future work will include experiments to help quantify the level of effort required to add new network adapters to SNoMAC. Network analysis using semantic techniques will also be explored more deeply. 9
http://www.restlet.org/
12
References 1. Hamdi Aloulou, Mounir Mokhtari, Thibaut Tiberghien, Jit Biswas, and Lin Kenneth. A semantic plug&play based framework for ambient assisted living. In Mark Donnelly, Cristiano Paggetti, Chris Nugent, and Mounir Mokhtari, editors, Impact Analysis of Solutions for Chronic Disease Prevention and Management, volume 7251 of Lecture Notes in Computer Science, pages 165–172. Springer Berlin / Heidelberg, 2012. 10.1007/978-3-642-30779-9 21. 2. Dan Brickley and R.V. Guha. Rdf vocabulary description language 1.0: Rdf schema, February 2004. 3. Arne Br¨ oring, Patrick Mau, Krzysztof Janowicz, Daniel Nst, and Christian Malewski. Semantically-enabled sensor plug and play for the sensor web. Sensors, 11(8):7568–7605, 2011. 4. Tiago Cruz, Cruz, Paulo Simoes, Simoes, Patricio Batista, Batista, Joao Almeida, Almeida, Edmundo Monteiro, Monteiro, and Fernando Bastos, Bastos. CWMP extensions for enhanced management of domestic network services. In Proceedings of the 2010 IEEE 35th Conference on Local Computer Networks, LCN ’10, pages 180–183, Washington, DC, USA, 2010. IEEE Computer Society. 5. UPnP Forum. UPnP Device Architecture 1.0. urlhttp://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf, April 2008. 6. Steve H. Garlik, Andy Seaborne, and Eric Prud’hommeaux. SPARQL 1.1 Query Language. http://www.w3.org/TR/sparql11-query/. 7. Thomas R. Gruber. A translation approach to portable ontology specifications. KNOWLEDGE ACQUISITION, 5:199–220, 1993. 8. Pascal Hitzler, Markus Krtzsch, Bijan Parsia, Peter F. Patel-Schneider, and Sebastian Rudolph. OWL 2 Web Ontology Language Primer. W3C Recommendation, World Wide Web Consortium, October 2009. 9. Jie Liu and Feng Zhao. Towards semantic services for sensor-rich information systems. In Broadband Networks, 2005. BroadNets 2005. 2nd International Conference on, pages 967 –974 Vol. 2, oct. 2005. 10. G.M.P. O’HARE, C. MULDOON, M.J. O’GRADY, R.E.M.W. COLLIER, O. MURDOCH, and D. CARR. Sensor web interaction. International Journal on Artificial Intelligence Tools, 21(2):1240006, 2012. 11. Konstantinos Togias, Christos Goumopoulos, and Achilles Kameas. Ontologybased representation of upnp devices and services for dynamic context-aware ubiquitous computing applications. International Conference on Communication Theory, Reliability, and Quality of Service, 0:220–225, 2010. 12. Khoi-Nguyen Tran, Michael Compton, Jemma Wu, and Rajeev Gore. Short paper: Semantic sensor composition. In Proceedings of the 3rd International Workshop on Semantic Sensor Networks, 2010. 13. Dmitry Tsarkov, Ulrike Sattler, and Robert Stevens. A solution for the man-man problem in the family history knowledge base. In Rinke Hoekstra and Peter F. Patel-Schneider, editors, OWLED, volume 529 of CEUR Workshop Proceedings. CEUR-WS.org, 2009. 14. Richard Tynan, Conor Muldoon, Gregory M. P. O’Hare, and Michael J. O’Grady. Coordinated intelligent power management and the heterogeneous sensing coverage problem. Comput. J., 54(3):490–502, 2011. 15. Kamin Whitehouse, Feng Zhao, and Jie Liu. Semantic streams: A framework for declarative queries and automatic data interpretation. Technical report, 2005.
