The NSA Architecture

The core components of the NSA architecture (see Fig.13.1) are the UPnP Stack and the Control Point (CP).

The UPnP Stack implements the application layer protocols: SOAP, GENA, SSDP, HTTPU and HTTPMU. Besides the basic UPnP functions, the UPnP Stack module provides an object representation of the generic UPnP elements (CP and devices). Thus, the NSA can build a local representation for each of the active network devices. Once a device announces its attachment to the network, the CP gets the service description (SSDP) from the URL the device has published. The CP parses the SSDP and translates it into its own object model. Finally, the CP stores the local representation of the device in a local inventory.

The CP interface towards the NSA components provides the NSA components with functions for accessing the object representation of the UPnP devices. Spe-cifically, the NSA components access the representation of the services and use them for invoking network services and subscribing their asynchronous events. This can Table 13.1 UPnP architecture and OSGi framework

UPnP OSGi Description

Device Bundle The services containers

Service Service One service of the platform. An interface

Actions Methods The service interface methods

State variable Data types The data types of the action arguments Class attributes The variables describing the state of the service Bundle properties Attributes containing service metadata Events Event admin Asynchronous communication channel Control point Service registry A registry of services

188 Á. Reina et al.

be used also for getting descriptive metadata of the service like the identifier, the name, the device type and other values contained in the service descriptor. Any of the actions invoked for the representing object of an UPnP service are translated by the UPnP stack into an appropriate HTTP message. Thus, additional services of the NSA can interoperate with a remote UPnP services like a local one.

The UPnP specification does not support security or QoS by itself. Thus, the NSA architecture is completed by Security and QoS modules. The security module provides privacy to the UPnP communications. The QoS module supports the CP analyzing the resource consumption before accepting connection requests.

The NSA core enables only the direct synchronous mode. The NSA core is complemented with the Access Modules, namely the Event Manager and the Bridge which enable the asynchronous and the transparent synchronous mode.

13.4.1 The Control Point Behaviour

The control point searches and registers UPnP devices attached to the network. It also subscribes to events announced by the device via a service descriptor. The NSA enriches these two basic functionalities with QoS (via the QoS Manager Service) and security (via the Security Manger). Security is supplied for the UPnP transactions (messages exchanged between the CP and any UPnP devices).

Otherwise the QoS is supplied even for the derived connections. Figure13.2 shows how the control point bundle invokes an UPnP service after enabling QoS and security for this invocation.

The CP receives a service request and tries to forward the petition to the service owner device. In case the invoker supplies a traffic descriptor where the resources

CAR - GATEWAY

Fig. 13.1 The NSA architecture: the NSA core and the Access Modules

13 Secure Gateway Interoperability 189

needed are specified, the control point tries to reserve it along the path from the source (the car-gateway) to the destination. To do this, the control point asks the QoS subsystem for the establishment of a flow described in the traffic descriptor.

Then, the control point receives an action from the object structure representing the UPnP device in the local system and sets the arguments values (setArgu-mentValue). Finally, the control point requests a secure service to the security subsystem and sends the call description to the remote device. When the security subsystem receives a secure service request it repeats the process of setting the argument values into the action, but in this case, the argument values are previ-ously ciphered. Thus, when the control point posts an action no malicious user can decipher the transmitted information.

13.4.2 Access Modules

An additional service enables the direct asynchronous and the transparent synchronous interoperability models. Respectively, the Event Manager and the UPnP-OSGi bridge described below are in charge to provide these functionalities.

Data Exchange & Service Access

SecurityManager

CP Device

postActionControl()

secService(ACTION) getService

SERVICE

getAction()

Service Action

ACTION

setArgumentValue(UNCIPHER_ARGS)

QoSManagerService

requestTraffic()

TRAFFIC_HANDLE

getArgumentValue()

ARGUMENT

setArgumentValue(CIPHER_ARGS) OK

Fig. 13.2 The control point manages the QoS and Security

190 Á. Reina et al.

1. Event Manager: The Event Manager follows the Java event model based on listenersandnotifiersand adapts to the OSGi framework. In other words, the middleware bundles interested in the UPnP events must implement the listener interface that the Event Manager registers into the Services Registry. Then, they subscribe to events through the Subscription Manager interface. This interface allows configuring subscriptions. The Subscription Manager bundle maintains a list of Subscription Profiles where the event listeners and their preferences are configured. The Notification Manager bundle looks up this Subscription Profile list in order to notify events the CP dispatches. The Notification bundle subscribes every event since service initialization. The CP forwards any event from the UPnP network to their subscribers that is, to the Notification bundle. Before the Notification bundle notifies an event, it pres-elects a subset from the Subscription Profile list only containing the listeners of which preferences matches to the event description (eventing device, eventing service, event type, etc.).

2. The Cross-platform Bridge: The Cross-platform Bridge imports UPnP services into the OSGi framework so the CGW middleware can interoperate with them, and exports OSGi services to the UPnP network. Other remote CP in the vehicle network can invoke the CGW public services. The Cross-platform Bridge organizes these two functions in two modules: the Importer and the Exporter. They are joined together by a Service Inventory. The Service Inventory is a registry for both the CGW and the vehicle network services. The Inventory uses the OSGi (org.osgi.service.upnp) standard definition of the UPnP services as a transitional representation of any service. The Importer waits for further UPnP device registration events that the CP of the NSA notifies. When such an event arrives, the Importer extracts the services from the device description. Then, it creates one device in the OSGi representation as a wrapper for each service. The new device is registered within the Inventory.

The Exporter listens to the OSGi Service Registry waiting for a REGISTERED event from the OSGi framework. When such event arrives, the Exporter ana-lyzes the further registration structure that is, the interfaces the new service implements. In case the registered service was compliant to the bridge, the Exporter analyzes its interface declaration and dynamically builds a device in the OSGi representation. This device maps the middleware service’s methods to UPnP actions. Then, the Exporter queries the UPnP stack for the publication of the farther UPnP device and finally registers the further started device in the Inventory.