The main objective of this project is based on developing a platform that deploys a homogeneous OSGi-UPnP environment. This platform will allow to implement applications in an OSGi environment and to hide the complexity related to the device control and information obtaining. In this way, the car gateway provides an open platform capable of auto-registering all devices located in the VAN, as well as their services and events, and it converts them into OSGi services accessible by any applications developed over this platform. In the same way, it allows to connect with any device or server located at the external network, so that it can register them as local services, like in the previous case.
Furthermore, this platform will implement the required routines, so that any application installed over the OSGi framework can publish its services as UPnP services towards the VAN and external network in order to make them accessible by any UPnP client.
The platform has been designed to be a fully modular system capable of deploying each of its functionality in blocks that are totally disjoint. In this way, the design option provides the ability to replace any block without any inconsistency in the system, so that the platform can be updated continuously.
The modular structure proposed can be seen in Figure 3. In the following subsections each layer of the system will be presented and exhaustively described.
3.1. Transparent Connectivity
Transparent connectivity is in charge of managing the communication between the vehicle and the external servers, as well as any device or sensor located within the vehicle environment. To this end, this module analyzes and selects the best communication technology possible or available (GPRS, UMTS, Wifi, Bluetooth. Zigbee, Ethernet, etc.) for the given service requirements and user preferences (always best connected (ABC)). This layer tries to adapt the networking process to the vehicular environment. To do this, its architecture is based on the CALM proposal (continuous air interface for long and medium range) .
Based on TCP/IP stack, this layer is formed by two sub-modules, as it can be seen in Figure 3. Firstly, the "CALM" module, which is formed by the next three coordinated entities: "interface manager entity" (IME), "network manager entity" (NME), and "CALM manager entity" (CME). IME entity is in charge of asking about the communication medium status, find the available resources at each moment considering the signal properties (signal strength, data rate, etc.) and maintain updated the stored information about the interface status. On the other hand, NME is responsible for considering the quality of service requirements for each application and compares them with each communication interface status. So, NME entity determines the optimum network selection, based on certain selection rules. Finally, CME entity acts as this module brain, supervising and managing the process execution and offering towards the upper layer the API to interact with this system.
Secondly, the "addressing" module is in charge of implementing the addressing of all the connected devices. This layer acts as an "access point" for any device located in the VAN, providing private IP addresses to all of them. Therefore, any connected device is going to be addressed in the same way.
All these modules have been developed as kernel modules, which act directly over the operative system routines in charge of carrying out the connectivity tasks.
3.2. Data Exchange and Service Access: Functionality Description
This subsystem defines the main part of the platform, which manages the heterogeneity of the connected car gateway devices and it provides a homogeneous environment to higher levels so that they can access in a transparent way to all the services offered. This is possible thanks to the routines implemented in order to publish and control all services provided by each device that is located both in the VAN and in any other external network.
Based on UPnP and OSGi, this allows incorporating, removing, and configuring new devices in a dynamic way without any human intervention.
Since not all connected devices will be compliant to the UPnP specification, this subsystem is responsible for implementing all required routines allowing the final platform to be abstracted from any proprietary protocols provided by these sensors and devices. In this way, this layer will emulate the UPnP behavior of each device that does not support this technology, and thus acting as a driver for non-UPnP compliant components. Additionally, an SIP agent has been developed in this layer, providing all required routines to interconnect the car gateway to external devices. This feature supports mobility of the platform in different networks.
Additionally, several modules are deployed to provide local and external car gateway communication. These management tasks include the following duties.
Check for services offered by the connected devices and publish them as an OSGi services.
Publish OSGi services implemented over the framework as UPnP services towards local or external networks.
Manage events belonging to the connected devices.
Manage quality of service in the connections between the car gateway and each device, located in both foreign or local networks.
Manage traffic security generated between components.
Manage AV connections between all AV components.
Each module implements an interface so that any other entity can configure it or access to its functionality. All of them will be described in more detail in the next section.
3.3. Data Exchange and Service Access: Layer Modules Description
The "data exchange and access service" layer (see Figure 3) is described in this sub-section. It is important to note that since the platform is based on OSGi framework, each module is implemented as a bundle installed and initialized in the OSGi framework. The communication methods, employed to connect the different modules and the upper layers (applications installed over this platform), are based on the mechanisms the bundles have in order to publish their services. Concretely, while the interaction between modules is going to be based on the Java libraries published by them; the interfaces offered by each module towards the upper levels will be based on OSGi services they publish and install over the framework.
UPnP Protocol Stack
This module is an implementation of the UPnP protocol stack. Apart from the protocols within the UPnP specification, this module implementation provides with higher abstraction Java libraries for developing generic UPnP devices and control points.
UPnP technology has been developed to be suitable in local domains. This is due to the mechanisms used to carry out the devices auto-discovery stage, because it is based on broadcasting. The UPnP stack implemented within this module tries to solve this constraint, extending such discovery mechanism. This extension is based on an on demand registration, sending unicast discovery messages (SSDP) towards the devices located at external networks. Therefore, this allows our platform to register and use the services implemented by any device, anywhere it is located.
This module implements the UPnP client, the "control point." This one is in charge of registering automatically all devices and services located inside the VAN. It sends this information to the correspondent module in charge of storing and publishing it ("devices/services inventory"). This one is based on the services the "UPnP Protocol Stack" module publishes internally.
This module consists of a repository where the descriptions of all the devices connected to the platform are stored, containing all the information about the services and data published by them. In order to reach this target, it publishes an interface that is used by the "configuration manager" in order to add and remove all detected services descriptions, once a determinate device has been registered. Specifically, the information is stored in this module is:
device/service capabilities (video, audio, data, etc.)
device/service services interfaces
device/service configuration interfaces
data formats supported by the device (XML, codec, streaming, etc.).
The persistence mechanism that uses this module is based on a lightweight database where a simple relational model has been defined. Once all information has been stored, this module is in charge of publishing it towards the other modules, so that they can use it to carry out their objectives.
This module is in charge of converting all the UPnP services, registered by the UPnP control point, into OSGi services. It defines the presentation layer of the services offered by the platform to the upper layer. Its functioning is based on the information retrieved from the previous module. Therefore, each OSGi service implemented is based on the UPnP description that each UPnP device has published.
Once the conversion has been done, this module registers the new services within the OSGi framework, where they will be able to be accessed by any application that runs over our platform.
This will publish services that allow upper layer applications to subscribe to asynchronous events coming from the device network. This module will offer the following services.
Subscribe and unsubscribe to certain notifications coming from the sensor and device network. This service will permit to realize a subscription according to several criteria such as device family, device type, specific capacity, and so forth.
Subscribe and unsubscribe to events published when certain new devices are attached to the network (e.g., camera, specify sensor).
Query the system about the ontology of devices (families, types), provides capacities the callback channel on which the application wants to be notified.
This module use the asynchronous communication mechanism implemented by UPnP protocol to define high-level functionalities mentioned above. Furthermore, it is also in charge of managing the keep-alive messages sent by the devices. In case this module notices a possible drop of a node, it tries to contact the device, but in case it is not possible, it proceeds to notify this event to the "configuration manager" which will proceed to eliminate the stored references to this device.
Events and Notifications
Based on the services published by the previous module, it completes the asynchronous communication mechanism of the platform. This module defines a confluence point responsible for centralizing the management of all events produced within the devices and sensors network. It acts as events router, in charge of receiving the events published by any connected device and routing them to the correspondent interested parties (platform modules or upper applications).
Its functioning is based on the eventualization mechanism implemented by Java. Each interested party registers its listener in this module, so when an UPnP event is received it is converted into a Java event by this module and notified to the interested entities.
Module in charge of managing the platform communications QoS. It is based on the QoS specification done by UPnP forum  (see Figure 4). This module implements the quality of service manager (QoS manager) and the policy manager (QoS policy Holder), offering the interface that allows the upper applications and platform modules (i.e., AV Subsystem) to invoke the VAN QoS control routines. In this way, before realizing a data transfer, the quality of service requirements are tested on the transmission channel, so if the quality is not ensured the connection will not be established.
To carry out this operation, this module makes use of a service published by any UPnP device that supports quality of service control (QoS device service). Such service provides the "QoS manager" with the necessary information about the device status as well as its connected networks.
The functioning of this module is independent of the connection typology (local domain or external network). While in the local domain case this module ensure by itself the quality within the communication, this system makes use of the routines implemented by the "transparent connectivity" layer in the connection with external devices to carry out the quality ensuring between networks.
This module is in charge of providing the necessary routines to ensure the confidentiality and integrity in the platform communications. It works over the UPnP protocol stack, encrypting the messages exchanged into the UPnP control phase. The discovery and the description phases are intended to be public phases so they will not be encrypted.
Its objective is filtering the communications between the UPnP client that resides into this platform ("configuration manager") and any connected device, using an encryption system based on public key cryptography algorithms. Thus, the information delivered trough the network cannot be unencrypted by any other UPnP peer but the invoking client and the receiver device.
This module introduces a little overhead in the communication process. This is due to the necessary key negotiation in order to prepare the system to do the encryption process. Once this negotiation is done, the module is ready to encrypt any message.
Platform Virtual Device
This module contains the required routines to publish on demand any functionality implemented into a certain application (implemented over the platform) as an UPnP service. According with the (model view controller MVC) paradigm, while the business logic is implemented by each application, this module will define the presentation logic of these published services.
This procedure allows any UPnP client located within the VAN coverage to register and make use of these services implemented by such applications in a transparent way.
This module, based on the UPnP AV specification mentioned above, is in charge of handling all A/V communication. It implements the AV control point functionalities, extending the capabilities of the UPnP client deployed in the "configuration manager." This module offers a range of services to the upper layer that allows controlling the AV flows between media servers and renders. Thus, applications installed in the framework only have to determine which devices want to communicate to, and what action they want to execute (run, stop, rewind). As a result, the control point will provide the functionality required.
Additionally, this makes use of the "QoS" module functionality in order to ensure the quality of service of all the flows it manages.
This module justification is mainly due to the platform mobile nature, and the local character of the UPnP technology. UPnP is oriented towards local networks, so it does not implement any mechanism that allows a client to register services published in external networks. Besides that, the platform will be located in a mobile environment, so it is necessary to take this into account. The reason is that the connectivity to the platform needs to be maintained always.
To solve both two problems, the SIP module implements an agent in charge of maintaining the connectivity between devices residing in an external server and in the car gateway, using an external SIP server (SIP proxy). As long as a connection between the car gateway and a device located in an external network is active, an SIP session will be established between both, using the external SIP server to manage the platform mobility feature. Once the SIP session has been established, a dialogue between both devices is possible.
Finally, it is necessary to clarify that the SIP agent always maintains updated the information within the SIP server about the vehicle location, which allows any external client to retrieve the network level address of the vehicle, enabling to access to the platform.
This module is responsible for implementing a virtualization of each non-UPnP device located in the platform's VAN. It acts as a concentrator for the information received from the different non-UPnP sensors and devices attached to the vehicle. It defines the interfaces towards them, using the IEEE 1451.X smart transducer standards . Specifically, it makes use of IEEE 1451.5 protocol that covers the wireless communication protocol standards such as 802.15.1 (Bluetooth), 802.15.4 (Zigbee) and 802.11b/g (Wifi). On the other hand, it use the IEEE 1451.6 protocol to implement the interface towards the CAN Bus.
Over the previous interfaces, it implements the IEEE 1451.0 protocol to provide a uniform set of commands to access any sensors or device in the 1451-based networks. This protocol will act as a concentrator of all the other ones, redirecting the request done to a determinate device towards the correspondent IEEE 1451.X module.
Finally, this module makes use of the services published by "UPnP protocol stack" module to implement a generic UPnP server. This UPnP device publishes a set of generic services which maps all the commands offered by the IEEE 1451.0 protocol. Furthermore, this device is characterized by a set of state variables that store the value of each sensor at any time and publish UPnP events when this value changes. In this way, all the iteration with non-UPnP devices is done using this module, which virtualizes the UPnP behavior.