D Platform state-of-the-art review

Transcription

1 D Platform state-of-the-art review Work package: 3.1 Version number: Dissemination level: PU Date: 06/10/2014 7th RTD Framework Programme Directorate General for Communications Networks, Content & Technology Cooperative Systems for energy efficient and sustainable mobility (FP7-ICT ) Contract Type: Collaborative project Grant agreement no.:

2 Version Control Version history Version Date Main author Summary of changes /04/2013 Francesco Alesiani (NEC) FI-WARE analysis and document structure Francesco Alesiani (NEC) New chapter structure Tobias Schlauch (DLR) Analysis of Instant Mobility project Igor Passchier (TNO) Analysis of SPITS and GOOGLE/APPLE Application store Francesco Alesiani (NEC) Integrated version Francesco Alesiani (NEC) Concluding chapter Francesco Alesiani (NEC) Edited according to the EC review comments Name Date Prepared Francesco Alesiani (NEC) 19/09/2014 Reviewed Yanying Li (ERTICO) 03/10/2014 Authorised Yanying Li (ERTICO) 06/10/2014 Circulation Recipient Date of submission European Commission 06/10/2014 Project partners 06/10/2014 Authors Francesco Alesiani (NEC) Tobias Schlauch (DLR) Dirk Beckmann (DLR) Igor Passchier (TNO) Eelco Cramer (TNO) Page 2 of 104

3 Table of contents Version Control... 2 Table of contents... 3 Abbreviations and definitions... 6 Executive Summary Introduction Document Scope Document Objectives Overview of Relevant Project/Platform Introduction and Method Platforms/Products Overview FI-WARE Architecture and Outcomes Introduction FI-WARE Project Future Internet PPP and FI-WARE Platform FI-WARE test bed Cloud Hosting (CH) Architecture and components Data Center Resource Management (DCRM) Open Cloud Computing Interface (OCCI) Service Manager (SM) GE Cloud Edge (CE) GE Object Storage (OS) GE Data/Context Management Architecture Context Broker (Publish/Subscribe Broker) GE Complex Event Processing (CEP) Location GE Metadata Preprocessing GE Compressed Domain Video Analysis GE Media-enhanced Query Broker GE Semantic Annotation GE Semantic Support GE Internet of Things (IoT) Services Enablement Architecture Backend IoT Broker GE Backend Discovery Engine GE Backend Device Management GE Gateway Device Management GE Page 3 of 104

4 Gateway Data Handling GE Gateway Protocol Adapter GE Architecture of Applications and Services Ecosystem and Delivery Framework USDL (Unified Service Description Language) Security Architecture Overview Interface to Networks and Devices (I2ND) Architecture Architecture Overview Developer Community and Tools Architecture Architecture Overview Outcome Analysis and Conclusions SPITS Project Architecture and outcomes Introduction Platform Architecture and Outcomes Description SPITS platform context System Scenario System Design The On-board Unit The Road Side Unit Integrated Subsystem Design Outcome Analysis and Conclusions Android and ios eco-systems features Introduction Platform Architecture and Outcomes Description Installing apps How apps can detect other apps installed How apps can communicate with other apps How apps can unlock / install new features Outcome Analysis and Conclusions Instant Mobility Architecture and outcomes Introduction Platform Architecture and Outcomes Description Scenarios Personal travel companion Smart city logistics Transport infrastructure as a service Platform Architecture Architectural Vision Conceptual Architecture Page 4 of 104

5 6.2.3 Overview of the implemented Prototypes Scenario 1 Personal Travel Companion Scenario 2 Smart City Logistics Scenario 3 Transport Infrastructure as a Service Outcome Analysis and Conclusions ANNEX: Analysis Table Page 5 of 104

6 Abbreviations and definitions Abbreviation AGPS AoE CE GE CEP CH DCRM DCT FI-PPP GE I2ND IaaS IoT iscsi MLP NaaS OCCI OMA OS GE PaaS REST S&D SaaS SM SMI VDC Definition Assisted Global Positioning System ATA over Ethernet Cloud Edge GE Complex Event Processing Cloud Hosting Data Center Resource Management Developer Community and Tools Future Internet Public-Private Partnership Generic Enabler Interface to Networks and Devices Infrastructure as a Service Internet of Things Internet Small Computer System Interface Mobile Location Protocol Network as a service Open Cloud Computing Interface Open Mobile Alliance Object Storage GE Platform as a Service Representational State Transfer Security and Dependability Software as a service Service Management Service Manager Interface Virtual Data Center Page 6 of 104

7 Executive Summary The current report provides a panorama of selected projects and products that are relevant to the MOBiNET platform. Each project or product is first described with the aim of highlight the potential interaction with the MOBiNET concept. The components that can be potentially integrated in the MOBiNET platform are then presented and analysed. Page 7 of 104

8 1 Introduction 1.1 Document Scope The deliverable is to review existing European projects or initiative and product that are relevant to the MOBiNET project and concept, focusing on those who also develop platforms which can be used to support the development of the MOBiNET platform and services. 1.2 Document Objectives The current report aims at presenting the main outcome of relevant projects that can provide expertise or components to the MOBiNET platform development. The main objective is to ensure that innovative technologies such as Future Internet are considered in the MOBiNET platform architecture and development. Especially the outcome of the FI-PPP projects including FI-WARE1 is studied. In order to create a concrete output for the MOBiNET architecture and development innovative and relevant components are identified and analyzed. Existing components can then be used for the development of platform and potential integrated into the architecture. 1 FIREWARE project: Page 8 of 104

9 2 Overview of Relevant Project/Platform 2.1 Introduction and Method The deliverable D31.1 represents the first deliverable in the Architecture and Specification WP of MOBiNET. The aim of the document is to present major results that can be potentially used or which represent a reference for the actual specification and development of the MOBiNET platform. The document has been created following the following method. First a list of major project or platform has been identified. Among the potential projects and platforms the most relevant went through the actual analysis. The analysis consists on the presentation of the platform / product, the identification of the main component relevant to MOBiNET, the description of the components and finally the analysis of the relevance of the components. Relevance of components can be of two types: 1) components that can be direct used; 2) the specification and architecture of the component for the actual platform specification. Among applicable components it is possible to identify component which actually implements some function. Alternatively a component is a specification or standard that is applicable to the MOBiNET platform. These difference component types are reported in the description of the components themselves. In order to present the result, two outputs are provided: 1) the deliverable with the project/platform description and analysis; 2) a summary table with the list of components. The table is also included in the current deliverable in the ANNEX, but an extended version is provided separately. 2.2 Platforms/Products Overview The current deliverable contains the analysis of the following items: 1) FI-WARE Project and outputs: this project represents a major effort in providing technologies for Internet of Things Platform. This project represents the largest part of the deliverable since internally the project is organized in Generic Enablers that can be considered separate project/platform functionalities. The project analysis has produced a list of components and a list of applicable pre-existing technologies that can be applicable to MOBiNET Platform 2) SPITS Project 2 and outputs: this Dutch National Project provide different interesting aspect to the MOBiNET platform which range from the central platform to the on-board device, including billing and application deployment; 3) The Android and ios eco-systems: these two platforms represent the most widely used application deployment platform; this chapter presents an overview on the application deployment process. 2 SPITS project: Page 9 of 104

10 4) Instant Mobility Project 3 and outputs: Instant Mobility is one of the FI-PPP Project focusing on mobility. The chapter allow so understand the choice of the project and the relationship with MOBiNET. In the ANNEX, 29 components are listed and analyzed. Some of them include multiple components that are related to the same function group. Among the other, it is possible to mention the Cloud Hosting, Data/Content Management, Device Management component areas. The actual use and applicability of the component will be analyzed in the architecture tasks.. 3 Instant Mobility Project: Page 10 of 104

11 3 FI-WARE Architecture and Outcomes 3.1 Introduction 3.2 FI-WARE Project FI-WARE is the Platform Project in the Future Internet Public Private Partnership (PPP) Program, a joint action by the European Industry and the European Commission. The project aims at developing public and royalty-free Open Specifications of Generic Enablers, together with a reference implementation of them available for testing. This way, it is aimed to develop working specifications that influence Future Internet standards. FI-WARE aims at delivering a novel service infrastructure, building upon elements (called Generic Enablers) which offer reusable and commonly shared functions making it easier to develop Future Internet Applications in multiple sectors building a true foundation for the Future Internet. 3.3 Future Internet PPP and FI-WARE Platform The FI-WARE platform is the Core Platform whose development is being targeted within the Future Internet PPP4 initiative launched by the European Commission in collaboration with the Industry. More information about Future Internet PPP initiative can be found at [4]. The FI-WARE platform is being developed following some of the principles of the Agile methodology. FI-WARE is one of the Project in the PPP Program [Future Internet PPP]. The following figures give information on the PPP Program Call Plan and an overview of the relationship of the Projects. 4 Future Internet PPP: Page 11 of 104

12 Figure 1 - PPP Call Plan Figure 2 - PPP Projects Page 12 of 104

13 3.4 FI-WARE test bed FI-WARE has defined and implemented a test bed for the FI-WARE platform. This test bed extends to the Open Innovation Lab. The test bed host the various implemented GE and is used for testing / integrating. It also allows to install application defined by PPP partners. Figure 3 - FI-WARE test bed Generic Enabler (GE) is a fundamental concept for FI-WARE and in order structuring the functions these have been grouped in Chapters. FI-WARE defines the following GE Chapters: Cloud Hosting Data/Context Management Internet of Things (IoT) Services Enablement Applications/Services Ecosystem and Delivery Framework Security Interface to Networks and Devices (I2ND) Each GE Chapter has its own Architecture and each Chapter is defined by multiple GEs. Every GE Chapter or GE is supposed to be implementable in multiple instances. Application can be developed using the API defined in the specific GE. APIs are defined as Open Specification WARE_Open_Specifications Page 13 of 104

14 FI-WARE provides the Developer Community and Tools (DCT), which wants to offer a comprehensive environment enabling the FI-PPP program developers to use in the more efficient, easy and effective way the FI-WARE outcomes (i.e. GE Implementations and FI-WARE Instances) and exploiting collaboration means to benefit the support of the community. 3.5 Cloud Hosting (CH) Architecture and components FI-WARE Cloud Hosting focuses on fundamental cloud capabilities enabling provisioning and life cycle management of virtual machines and associated resources (compute, storage, network, images, etc) hosting FI applications and services, as well as object storage capabilities which can be used directly by FI applications and services via a REST API. In future releases, additional capabilities will be added, notably the support for complex services comprising multiple virtual machines, including monitoring, policy-based elasticity. The Roadmap of Cloud Hosting describes the plan for feature deployments in FI-WARE 6 Figure 4 - CH Architecture Figure 4 shows the CH architecture. The GEs in the above diagram are grouped into Core GEs, providing the core hosting capabilities at different abstraction levels (resources, services, objects, etc) and Ecosystem GEs, addressing various specific needs across the Core GEs, and establishing the ecosystem that enables the end-to-end capabilities provided by a cloud offering. The Core GEs include: 6 Page 14 of 104

15 Data Center Resource Management (DCRM) GE, offering provisioning and life cycle management of virtualized resources (compute, storage and network) associated with virtual machines. Object Storage GE, offering provisioning and life cycle management of object-based storage containers and elements Service Management (SM) GE, offering provisioning and life cycle management of composite services comprising several resources provided by the above GEs. In the first release of FI-WARE, Service Management GE will consume resources provided by Data Center Resource Management GE, via the corresponding APIs. In the next releases of FI-WARE, the following additional Core GEs will be considered: Cloud Edge Resource Management GE, enabling end-to-end provisioning and life cycle management of cloud applications which comprise run-time components designed to run on Cloud Edge devices. The hosting capabilities on such Cloud Edge devices are provided by Cloud Proxy GE, developed across Cloud Chapter and I2ND Chapter. PaaS Management GE, offering provisioning and life cycle management of middlewarelevel containers, such as Web, Database, etc. Other GEs include: Monitoring GE, collecting metrics associated with each of the Core GEs, and offering them to GEs which are interested to consume such metrics. For example, Service Management GE consumes metrics associated with KPIs of the various service components in order to drive auto-scaling decisions. In the future, more advanced metrics-related capabilities will be provided, such as processing (before it is delivered to the consumer), archival and analysis of metrics. Identity Management GE, providing a unified management of users, roles and tokens, that can be used by other GEs for authentication and authorization purposes. This GE will be provided by the Security Chapter. In the next releases of FI-WARE, the following additional Ecosystem GEs will be considered: Accounting GE, allowing to keep records about resource usage, which can be then used for billing purposes Audit GE, allowing to keep track of all the activities in the cloud for auditing purposes Cloud Broker GE, allowing to leverage GEs deployed in another Cloud in a federated or hybrid fashion 3.6 Data Center Resource Management (DCRM) Figure 5 shows the internal architecture of the DCRM. Open Cloud Computing Interface (OCCI) describes the API provided by DCRM. Page 15 of 104

16 The key component visible to the cloud user are: Figure 5 - DCRM Virtual server, comprising a virtualized container that can host an arbitrary Operating System and an arbitrary software stack on top, installed within the virtual server. DCRM GE supports provisioning and life cycle management of Virtual Servers. Virtual disk, representing a persistent virtual disk that can be potentially attached to an arbitrary virtual server. DCRM GE supports provisioning of virtual disks, as well as their attachment to virtual servers. Virtual network, representing a logical network abstraction that would typically represent a L2 segment. DCRM GE supports provisioning of virtual networks, as well as attachment of virtual NICs of virtual servers to them. Virtual image -- a pre-packaged virtual server image. DCRM GE supports life cycle of virtual images, as well as provisioning of virtual servers based on virtual images. Policies -- a mechanism to control access to, and behavior of, operations on the above entities, in a given context (see more details below). 3.7 Open Cloud Computing Interface (OCCI) OCCI is a RESTful protocol and API for the management of cloud service resources. It comprises a set of open community-lead specifications delivered through the Open Grid Forum. OCCI was originally initiated to create a remote management API for IaaS model based Services. It has since evolved into a flexible API with a strong focus on integration, portability, interoperability and innovation while still offering a high degree of extensibility. Page 16 of 104

17 OCCI aims to leverage existing Standards Developing Organization (SDO) specifications and integrate those such that where an OCCI specified feature may not be rich enough a more capable one can be brought into play. An excellent example of this is the integration of both Cloud Data Management Interface (CDMI) and Open Virtualization Format (OVF). In particular to these two previously mentioned standards, when combined together provide a profile for open and interoperable infrastructural cloud services. The main design foci of OCCI are: Flexibility: enabling a dynamic, adaptable model, Simplicity: do not mandate a large number of requirements for compliance with the specification. Look to provide the lowest common denominator in terms of features and then allow providers supply their own differentiating features that are discoverable and compliant with the OCCI core model, Extensibility: enable providers to specify and expose their own service features that are discoverable and commonly understood (via core model). The specification itself currently comprises of three modular parts: Core: This specifies the basic types and presents them through a meta-model. It is this specification that dictates the common functionality and behavior that all specializations of it must respect. It specifies how extensions may be defined. Infrastructure: This specification is an extension of Core (provides a good example of how other parties can create extensions). It defines the types necessary to provide a basic infrastructure as a service offering. HTTP Rendering: this document specifies how the OCCI model is communicated both semantically and syntactically using the RESTful architectural-style. From an architectural point of view OCCI sits on the boundary of a service provider. It does not seek to replace the proprietary protocols/apis that a service provider may have as legacy. Figure 6 - OCCI based Service The main capabilities of OCCI are: Basic type definitions (attributes, actions, relationships): o Compute: defines an entity that processes data, typically implemented as a virtual machine. Page 17 of 104

18 o o Storage: defines an entity that stores information and data, typically block-level devices, implemented with technologies like Internet Small Computer System Interface (iscsi) and ATA over Ethernet (AoE). Network: defines both client (network interface) and service (L2/L3 switch) networking entities, typically implemented with software defined networking frameworks. Discovery system: Types and their instances URL schema (provider can dictate their own) is discovered. Extensions are also discoverable through this system. Extension Mechanism: allows service providers expose their differentiating features. Those features are comprehended by clients through the discovery system. Resource (REST) handling (CRUD) of individual and groups of resource instances Tagging & Grouping of Resources Dynamic Composition that allows for the runtime addition of new attributes and functional capabilities Template support for both operating systems and resource types Independent of provisioning system (e.g. OpenStack, OpenNebula, vcloud etc.) 3.8 Service Manager (SM) GE SM is copyrighted by Telefónica I+D. Page 18 of 104

19 Figure 7 - IaaS Service Manager Interface Logical Architecture The Service Manager Interface (SMI) is the front-end of the IaaS SM GE, providing an Openstack Compute API compliant interface. SMI dispatches the requests received from the cloud user or cloud portal to components handling each of the services management operations/tasks-- deploy servers, deploy services, management of scalability rules. At the back-end, different aspects of service management are handled by the corresponding internal service components, such as elasticity, service management, Virtual Data Center (VDC) management, Organization management. A detailed description of these operations is shown in the next sections. Note that additional service management functionality and components will be added in future releases of IaaS SM GE. The IaaS Service Manager Interface (SMI) is based on the following concepts: Server. A server is a virtual machine instance in the computing system. Images and flavors are required elements in order to create a server (also including the name to identify it). Virtual Appliances or Services (vapp). This entity represents virtual infrastructure designed to run on a virtualization platform. Typically a vapp or Service is considered as a server or set of servers running on top of a hypervisor, but the bounds of vapp or service Page 19 of 104

20 concept is open to the cloud user. Anyway the concept of service here is totally different from the concept of server defined in the Data Center Resource Management (DCRM) GE. Here a Service involves the definition of one or several virtual machines with or without its own elasticity rule. Last but not least, services could be connected themselves through the same virtual data center in which they are running. Virtual Data Centers (VDC). vapps/services and/or servers reside in a VDC context. A VDC is a container of virtual infrastructure that has a set of virtual resources (e.g., computing capacities, storage capacities) to support the former. In other words, a VDC is a pool of virtual resources that supports the virtual infrastructure it contains. Organizations (Org). VDCs are owned by organizations. An organization represents any kind of independent unit, which manages its own cloud resources (e.g. enterprises, divisions, groups...). Virtual Infrastructure. Any kind of IaaS resource offered to cloud consumers as part of a cloud service that may be managed through SMI. E.g., vapps/services, servers, volumes, firewalls, load balancers... Flavor. A flavor is a hardware configuration that could be applied to a server. Each flavor has a unique combination of disk space and memory capacity. An example of this combination could be for example 8 virtual CPUs, 16 Gb RAM memory, 10 Gb HDD and 160 Gb of ephemeral disk (a disk that is stored locally on the hypervisor host). It must be available previously in order to allow creating servers. Each flavor has a unique combination of disk space, memory capacity and priority for CPU time. Image. An image is a collection of files used to create or rebuild a server. FIWARE will provide a number of pre-built OS images but the cloud user may also create his own images using the appropriate functionality (see Main Interactions). These custom images are useful for backup purposes or for producing "gold" server images if you plan to deploy a particular server configuration frequently. Figure 8 CH SM Concepts class diagram 3.9 Cloud Edge (CE) GE This specification describes the Cloud Edge GE, which is located beside the cloud, acting as the cloud agent in the end consumer s private network. The Cloud Edge consists of equipment called "Cloud Proxy". Its main function is to offer local Services hosting capabilities as a complement of the standard Service hosting capabilities provided by traditional Cloud infrastructure. Services hosted in such Cloud Proxy can benefit of this privileged position inside the private network area of a consumer to provide new enhanced Services. It can leverage on the proximity between the consumer and the Service itself to offer Services that require strong connectivity. It can also offer access to private capabilities that are hosted or accessible via the cloud proxy (for example sensors or private home network storage). Page 20 of 104

21 The following diagram shows the main components of the Cloud Proxy and the interactions with the different potential actors. Figure 9 - CH - CE The Cloud Proxy offers a single public interface to manage the local service hosting capabilities: the Service Platform Management Interface (SPMI) Object Storage (OS) GE Object Storage is one of the Generic Enablers within the FI-WARE Project. It offers persistent storage for digital objects, important cloud-based functionality that has been specifically requested by Use Cases. Objects can be files, databases or other datasets which need to be archived. These objects can be structured into a hierarchical way. The idea here is too have different objects sorted into groups. Within the context of Object Storage those are referred to as containers. Containers and objects can have Metadata attached which give a more detailed overview of what the data represents. Similar to files a filesystem - objects in a Object storage belong to certain users (accounts). The following sections will give more details on these topics and will introduce the CDMI standard which is used within this Generic Enabler. The users of the Object Storage Generic Enabler will be both the FI-WARE Cloud Instance Provider and the FI-WARE Cloud Instance User. Provider usage: The Provider can assume two roles: one as consumer of the service and another as its manager. From a consumer perspective, the Provider will use this system in order to store certain types of data. A good example of this is in the storage of monitoring, reporting and auditing data. That data could then be made available to the Users or not depending on the wants of the Provider. The Object storage service could also be used as a virtual machine staging area. This has two aspects, the Provider and User aspects. In the Page 21 of 104

22 case of the Provider, a User will upload a virtual machine image to the object storage service and once received, the Provider will make this virtual machine image available for instantiation in order to satisfy a particular customized virtual machine request (the case here is that the virtual machine images that the Provider offers are not sufficient and the User wishes to supply their own). From a management perspective, the Provider will expect that the system will require as little maintenance as is possible. This entails that any: o o o o o o stale data be purged, deactivated accounts be removed, corrupt data is replaced with a valid replica, Issues are escalated to an automated service that will attempt to resolve them (if they cannot be resolved then notifications to the Provider should be sent), relevant statistics should be available to support inspection of the system and the User's utilization of the system, additional requirements for hardware (storage capability) can be easily added to the system without any drop in service. This will allow the storage capacity to grow over time. User usage: The User will use the object storage service as a means to distribute static content rather than incur the additional load of serving static content from an application. Taking this approach allows the Provider to optimize the distribution of those files. The Provider can also use this as a building block to offer further content distribution network capabilities. The User could also use the object storage service as a means to supply a customized virtual machine that only they have access to (the storage is isolated by user). This would follow in a similar fashion to how customized virtual machine images are supplied on Amazon EC2. The Object Storage GE adopts the Cloud Data Management Interface (CDMI) specification. Figure 10 - CDMI At the core of CDMI are the basic management operations of Create, Retrieve, Update and Delete. This functionality is exposed via a RESTful API that: Enables clients to discover capabilities of the object storage offering Manage containers and the objects that are placed within them Page 22 of 104

23 Assigns and manipulates metadata to containers and objects 3.11 Data/Context Management Architecture The Data/Context Management FI-WARE chapter aims at providing outperforming and platformlike GEs that will ease development and provision of innovative Applications that require management, processing and exploitation of context information as well as data streams in realtime and at massive scale. Combined with enablers coming from the Apps Chapters, Application Providers will be able to build innovative business models such as the ones described above and beyond. The following diagram shows the main components (Generic Enablers) that comprises the first release of FI-WARE Data/Context chapter architecture. Main components are Figure 11 - Data/Context Management Architecture BigData: discontinued, currently under analysis and the specifications PubSub: Context Broker CEP Location MetadataPreprocessing CompressedDomainVideoAnalysis QueryBroker SemanticAnnotation SemanticSupport Page 23 of 104

24 Context Broker (Publish/Subscribe Broker) GE The Context Broker GE will enable publication of context information by entities, referred as Context Producers, so that published context information becomes available to other entities, referred as Context Consumers, which are interested in processing the published context information. Applications or even other GEs in the FI-WARE platform may play the role of Context Producers, Context Consumers or both. Events in FI-WARE based systems refers to something that has happened, or is contemplated as having happened. As such, they provide context information that can be handled by applications or FI-WARE GEs. Figure 12 Content Broker visual presentation Complex Event Processing (CEP) CEP analyses event data in real-time, generates immediate insight and enables instant response to changing conditions. Some functional requirements this technology addresses include eventbased routing, observation, monitoring and event correlation. The technology and implementations of CEP provide means to expressively and flexibly define and maintain the event processing logic of the application, and in runtime it is designed to meet all the functional and nonfunctional requirements without taking a toll on the application performance, removing one issue from the application developer s and system managers concerns. Page 24 of 104

25 Figure 13 - Complex Event Process Logical Architecture Location GE The Location Platform provides location-based services for two types of users: Third-party location clients o Third-party location clients can interact with the location platform using the Mobile Location Protocol (MLP) interface or RESTful Network API for Terminal Location both standardized by Open Mobile Alliance (OMA). o These interfaces facilitate many services to retrieve the position of a compatible target mobile terminal for various types of applications, ranging from single shot location retrieval to area event retrieval (geo-fencing). o The target mobile terminal position is retrieved using Assisted Global Positioning System (AGPS), WiFi and Cell-Id positioning technologies intelligently triggered depending on end-user environment and location request content (age of location, accuracy, etc.). Mobile end-users o When an end-user searches for its position using a compatible terminal via any kind of application requiring location information, the terminal connects to the location platform to exchange assistance data in order to compute or retrieve its position, as negotiated between the terminal and the platform. o Moreover, some applications on the compatible terminal may include the sharing of location information with external third-parties, including other end-users. o Such service relies on another OMA standard, called Secure User Plane (SUPL). Page 25 of 104

26 Figure 14 - Location Platform GE Logical Architecture The following services are the grounds of the Location GE: MLP service: made of an HTTP stack, it processes MLP compliant requests and after authorization of such request, it triggers the SUPL service to establish communication with the target handset (SMS) to retrieve location or events depending on the content of the request. Such request is encoded in XML format fully specified in MLP standard. NetAPI Terminal Location service: similar to MLP agent, it decodes HTTP requests using RESTful procedures and once authenticated triggers the establishment of a SUPL connection with the target handset (SMS) for similar services to MLP. SUPL service: made of a TCP stack, this server is used both to establish communication with a target handset (SMS) and receive connection from the handset. The SUPL service implements SUPL standardized procedures based on ASN1. Such procedures include single shot location retrieval and triggers used for periodic and area event tracking. Such interface is also used to exchange GPS assistance data via the 3GPP RRLP protocol encapsulated in the SUPL payload Metadata Preprocessing GE Target users are all stakeholders that need to convert metadata formats or need to generate objects (as instantiation of classes) that carry metadata information. The requirements to transform metadata typically stem from the fact that in real life various components implementing different metadata formats need to inter-work. However, typically products from different vendors are plugged together. In this case, the Metadata Preprocessing GE acts as a mediator between the various products. Page 26 of 104

27 Figure 15 - Metadata Preprocessing GE Logical Architecture The functionality of the components is described in the followings. Control Interface: The control interface is the entity for configuring and controlling the metadata processing engine. The algorithms used for transformation and filtering as well as the metadata source are configured(connected using the configureinstance method. Sinks receiving the outbound streams are connected and disconnected via the addsink and removesink methods, respectively. More details on the APIs are described in the Section "Main Interactions". Metadata Interface (for inbound streams): Different interchange formats (such as the ones for streaming or for file access) can be realized (i.e., configured or programmed into this interface at a later stage). An example format is the Real-time Transport Protocol (RTP) as standardized in RFC Different packetization formats for the contained payload data (i.e., the metadata) depending on the application might be used. Metadata Transformation: The Metadata Transformation component is the core component of this Generic Enabler. Based on an XML Stylesheet Language for Transformations (XSLT 7 ) and a related stylesheet, the processing of the metadata is performed. In principle, other kind of transformations (other than XSLT) can also be applied. The output of this step is a new encapsulation/formatting of the metadata received. This could also be an instantiation of a class (e.g., JAVA, C++, C#, etc.) Metadata Filtering: Metadata Filtering is an optional step in the processing chain. The filtering can be used, e.g., for thinning and aggregating the metadata, or simple fact 7 [XSLT] W3C / M. Kay (editor), "XSL Transformations (XSLT) Version 2.0", Jan Page 27 of 104

28 generation (i.e., simple reasoning on the transformed metadata). Depending on the configuration of the GE, filtering can happen before, after, or even during transformation. Metadata Interface (for outbound streams): Through this interface, the transformed (and possibly filtered) metadata or metadata stream is accessed Compressed Domain Video Analysis GE The target users of the Compressed Domain Video Analysis GE are all applications that want to extract meaningful information from video content and that need to automatically find characteristics in video data. The GE can work for previously stored video data as well as for video data streams (e.g., received from a camera in real time). In the media era of the web, much content is user-generated (UGC) and spans over any possible kind, from amateur to professional, nature, parties, etc. In such context, video content analysis can provide several advantages for classifying content and later search, or to provide additional information about the content itself. Example applications in different industries addressed by this Generic Enabler are: Telecom industry: Identify characteristics in video content recorded by single mobile users; identify communalities in the recordings across several mobile users (e.g., within the same cell). Mobile users: (Semi-)automated annotation of recorded video content, point of interest recognition and tourist information in augmented reality scenarios, social services (e.g., facial recognition). IT companies: Automated processing of video content in databases. Surveillance industry: Automated detection of relevant events (e.g., alarms, etc.). Marketing industry: Object/brand recognition and sales information offered (shops near user, similar products, etc.). Page 28 of 104

29 Figure 16 - Compressed Domain Video Analysis GE Logical Flow A hybrid video coder can be divided in several generic components: Coder Control: Controls all other components to fulfill pre-defined stream properties, like a certain bit rate or quality. (Indicated by colored block corners) Intra-Frame Encoder: This component usually performs a transform to the frequency domain, followed by quantization and scaling of the transform coefficients. Intra-Frame Decoder: To avoid a drift between encoder and decoder, the encoder includes a decoder. Therefore, this component reverses the previous encoding step. In-Loop Filter: This filter component could be a set of consecutive filters. The most common filter operation here is deblocking. Motion Estimator: Comparing blocks of the current frame with regions in previous and/or subsequent frames permits modeling the motion between these frames. Motion Compensator: According to the results of the Motion Estimator, this component compensates the estimated motion by creating a predictor for the current block. Intra-Frame Predictor: If the control decides to use intra-frame coding techniques, this component creates a predictor for the current block by just using neighboring blocks of the current frame. Entropy Encoder: The information gathered during the encoding process is entropy encoded in this component. Usually, a resource-efficient variable length coding technique (e.g., CAVLC in H.264/AVC) or even an arithmetic coder (e.g., CABAC in H.264/AVC) is used. During the encoding process, the predicted video data p[x,y,k] (where x and y are the Cartesian coordinates of the k-th sample, i.e., frame) gets subtracted from the raw video data r[x,y,k]. The resulting prediction error signal e[x,y,k] then gets intra-frame and entropy encoded. The decoder within the encoder sums up the en- and decoded error signal e'[x,y,k] and the predicted video data p[x,y,k] to get the reconstructed video data r'[x,y,k]. These reconstructed Page 29 of 104

30 frames are stored in the Frame Buffer. During the motion compensation process, previous and/or subsequent frames of the current frame ( r'[x,y,k+i], i Z \ {0} ) are extracted from the buffer Media-enhanced Query Broker GE Multimedia data is produced at an immense rate. By investigating solutions and approaches for storing and archiving the produced data, one rapidly ends up in a highly heterogeneous environment of data stores. Usually, the involved domains feature individual sets of metadata formats for describing content, technical or structural information of multimedia data [Stegmaier 09a]. Furthermore, depending on the management and retrieval requirements, these data sets are accessible in different systems supporting a multiple set of retrieval models and query languages. By summing up all these obstacles, easy and efficient access and retrieval across those system borders is a very cumbersome task [Smith 08]. Standards are one way to introduce interoperability among different peers. Recent developments and achievements in the domain of multimedia retrieval concentrated on the establishment of a multimedia query language (MPEG Query Format (MPQF)) [Döller 08a], standardized image retrieval (JPEG) and the heterogeneity problem between metadata formats (JPEG) [Döller 10]. Another approach for interoperable media retrieval is the introduction of a mediator or middleware system abstracting the communication: a Mediaenhanced Query Broker. Acting as middleware and mediator between multimedia clients and retrieval systems, collaboration can be remarkably improved. A Media-enhanced Query Broker accepts complex multi-part and multimodal queries from one or more clients and maps/distributes those to multiple connected Multimedia Retrieval Systems (MMRS). Consequently, implementation complexity is reduced at the client side as only one communication partner needs to be addressed. Result aggregation and query distribution is also accommodated, further easing client development. However, the actual retrieval process of the multimedia data is performed inside the connected data stores. Figure 17 - Query Broker : (a) Local/autonomous processing (b) Distributed processing Page 30 of 104

31 Semantic Annotation GE The principle standing behind Semantic Web is to evolve the "link" concept from an unspecified element describing the relationship between two element into a "named relationship" in order to clarify which is(are) the relationship(s) between those elements. That is the main reason why RDF, the language of Linked Open Data was invented. RDF is based on Triples, in the form of<subject><predicate><object>. The predicate (and sometimes the object) can describe objects and their relationships. Semantic Annotator is basically a tool which tries to identify important entities(places,persons,organization) a text and describe them with Linked Open Data. This GE provides a general purpose text analyzer to identify and disambiguate LOD (Linked Open Data) resources related to the entities in the text. It is build following a modular approach to optimize and distribute text processing & LOD sources (plug-in). Also it allows RDF triple generation that easily links to LOD resources. The main conceptual idea of the SA GE is shown in the Figure below. Figure 18- Semantic Annotation GE Logical Flow Semantic Support GE The Semantic Web Application Support enabler aims at providing an effective environment for developers to implement and deploy high quality Semantic Web-based applications. The Semantic Web was first envisioned more than a decade ago by Tim Berners-Lee, as a way of turning the Web into a set of resources understandable not only for humans, but also by machines (software agents or programs), increasing its exploitation capabilities. The Semantic Web has focused the efforts of many researchers, institutions and IT practitioners, and received a fair amount of Page 31 of 104

32 investment from European and other governmental bodies. As a result of these efforts, a large amount of mark-up languages, techniques and applications, ranging from semantic search engines to query answering system, have been developed. Nevertheless the adoption of Semantic Web from the IT industry is still following a slow and painful process. In recent years, several discussions had taken place to find out the reasons preventing Semantic Web paradigm adoption. There is a general agreement that those reasons range from technical (lack of infrastructure to meet industry requirements in terms of scalability, performance. distribution, security, etc.) to engineering (not general uptake of methodologies, lack of best practices and supporting tools), and finally commercial aspects (difficulties to penetrate in the market, lack of understanding of the main strengths and weaknesses of the semantic technologies by company managers, no good sales strategies, etc.). The Semantic Application Support enabler addresses part of the abovementioned problems (engineering and technical) from a data management point of view, by providing: An infrastructure for metadata publishing, retrieving and subscription that meets industry requirements like scalability, distribution and security. From now and so on, we will refer to this infrastructure as SWAS Infrastructure. A set of tools for infrastructure and data management, supporting most adopted methodologies and best practices. From now and so on, we will refer to this tools as SWAS Engineering Environment. Figure 19 - SWAS-3: SWAS Infrastructure architecture 3.12 Internet of Things (IoT) Services Enablement Architecture FI-WARE will build the relevant Generic Enablers for Internet of Things Service Enablement, in order for things to become citizens of the Internet available, searchable, accessible, and usable Page 32 of 104

33 and for FI services to create value from real-world interaction enabled by the ubiquity of heterogeneous and resource-constrained devices. The deployment of the architecture of the IoT Service Enablement chapter is typically distributed across a large number of Devices, several Gateways and the Backend. The Generic Enablers described in this chapter, shown in the figure below, implement functionalities distributed across IoT resources hosted by devices, IoT Gateways and in the IoT Backend. The architecture is composed of these elements: Figure 20 - IoT Architecture Device and IoT Resource o A device is a hardware entity, component or system that either measures properties of a thing/group of things or influences the properties of a thing/group of things or both measures/influences. Sensors and actuators are devices. Devices can further be categorized into IoT compliant (i.e., devices with the full-blown FI-WARE capabilities and supporting the standard ETSI M2M interface) and non-compliant (legacy devices with propietary protocols). o IoT Resources are computational elements (software) that provide the technical means to perform sensing and/or actuation on the device. The resource is usually hosted on the device. Gateway Page 33 of 104

34 o A gateway is providing inter-networking and protocol conversion functionalities between devices and the IoT backend. It is usually located at proximity of the devices to be connected. An example of an IoT gateway is a home gateway that may represent an aggregation point for all the sensors/actuators inside a smart home. The IoT gateway will support all the IoT backend features, taking into consideration the local constraints of gateway devices such as the available computing, power, storage and energy consumption. Gateways are connected northbound to the backend via IP connectivity and southbound to IoT compliant devices without IP connectivity Legacy devices that needs protocol conversion o As IP devices will now appear on the market, the gateway will also be able to manage some of them using IETF Core CoaP protocol but one of the main role of the gateway is to bridge different technologies with IP connectivity. The second main role is deployment of smart services as close as possible of the things to enphazise smart applications development. Backend o The backend provides management functionalities for the devices and IoT domainspecific support for the applications. It supports access at both IoT resource and thing-level. The backend can be connected southbound to gateways and/or IoT compliant devices (devices that will implement the standardised interface i.e. ETSI M2M) Backend IoT Broker GE The IoT Broker GE is a component for retrieving and aggregating information from the Internet of Things. The underlying data model of this GE is based on the OMA NGSI (Next Generation Service Interface) Context Management Information Model, which is centered around on the concept of context entities. Context entities represent arbitrary objects of the real world, and the state of such objects is described in terms of the values of attributes. In addition, metadata can be associated to attribute values. In the context of IoT, context entities are used for representing devices like sensors and the values they measure, but also - and more importantly - arbitrary physical objects (Things) like rooms, persons, etc. and their attributes like temperature, geolocation, etc. Page 34 of 104

35 Figure 21 - Backend IoT Broker GE Logical Structure The OMA NGSI context management interface distinguishes between two types of information. This first type is so-called context information and consists of attribute values and associated metadata as described above. This kind of information is exchanged using the operations defined in OMA NGSI 10. The second type of information is information on where certain context information can be retrieved by OMA NGSI 10 operations. This kind of information is referred to as context availability information; it is exchanged using the operations defined in OMA NGSI Backend Discovery Engine GE The IoT Discovery Engine (IoT-DE) GE addresses the discovery of Internet of Things (IoT) Concepts. Its aim is to provide a platform for the semantic annotation and discovery of the IoT Concepts defined in FIWARE, i.e. the Thing, Resource, and Device. It also provides semantic annotation for Context Producers (e.g. IoT Agents, Service Endpoints) - or what is generically termed as the 'Providing Application' in the current specification of the FIWARE NGSI Interface. In contrast to NGSI, it aims to apply formal naming and relational conventions to the description of an IoT Concept. The IoT-DE GE is built upon two modules. The first is the Sense2Web IoT Linked Data Platform baseline asset, which provides a repository for the CRUD (Create, Read, Update and Delete) management of IoT descriptions, that complies with the IoT-A ontology models. These descriptions are termed as Advanced IoT Descriptions. Sense2Web also associates different IoT concept ontologies to domain data and other resources on the Web. The second module is the NGSI support module for the storage of NGSI Entities, whereby these Entities could hold a URI link to the Advanced Description. Page 35 of 104

36 This GE is targeted for: Figure 22 - Backend Discovery Engine GE Logical Architecture Context Producers using IoT-A ontologies or NGSI9 Entity Description for IoT Description CRUD management o IoT Agents o Device Gateways Context Consumers using SPARQL or NGSI9 for discovering IoT Concepts. o PubSub Broker GE (Data/Context Chapter) o Applications requiring Semantic Discovery of IoT Concepts Backend Device Management GE The Backend Device Management GE is the central component for the IoT backend. It provides the resource-level management of remote assets (devices with sensors and/or actuators) as well as core communication capabilities such as basic IP connectivity and management of disconnected devices. Page 36 of 104

37 Figure 23 - Backend Device Management GE Interface overview Gateway Device Management GE The Gateway Device Management GE is contains much of the "core" gateway functionality. It is responsible for the communication with the Backend and IoT and non-iot devices. The Gateway Device Management GE includes the functional components to handle the registration/connection phases towards the Backend/Platform, to translate the incoming data or messages in an internal format and to send the outgoing data or messages in the ETSI M2M format (marshall/unmarshall). It is also capable of managing the communication with the IoT Resources, i.e. the devices connected to the IoT Gateway (that may be online or offline), and resources hosted by the gateway. The GE also contains Resource Management capabilities, i.e. to keep track of IoT Resource descriptions that reflect those resources that are reachable via the gateway. These can be both IoT Resources, or resources hosted by legacy devices that are exposed as abstracted IoT Resources. In addition, any IoT resource that is hosted on the gateway itself if also managed by this GE. The GE makes it possible to publish resources in the gateway, and also for the backend to discover what resources are actually available from the gateway. Page 37 of 104

38 Figure 24 - Gateway Device Management GE Structure Overview Gateway Data Handling GE The IoT world mainly consists of a huge amount of resources, creating a lot of events to be processed. The Data Handling GE addresses the need of filtering, aggregating and merging data from different sources; merging data is considered to be the main value-added feature. Applications should receive value-added data that are relevant to their needs thanks to the Complex Event Processing technology (CEP). This is also referred to as event stream analysis, or real time event correlation. Events are published by Event Producers and subscribed to by Event Consumers. Events are subscribed to by an event consuming application, depending on the access rights that have been granted. The application is then able to receive published events. The Data Handling GE can be configured either for mobile and fixed gateways or for constrained environments. In the first case, its complex event processing core is based on Esper4FastData. For constrained environments, as light deployment can be chosen with SOL/CEP as the core for the complex event processing. Typical applications that require Data Handling GE are sensor network applications, RFID reading, supply chains, scheduling and control of fabrication lines, air traffic and so on. What these applications have in common is the requirement to process events (or messages) in real time or Page 38 of 104

39 near real time. Key considerations for these types of applications are throughput, latency and the complexity of the logic required. The CEP component of the Data Handling GE typically processes input data in order to generate a smaller set of output data that avoids backend and network flooding. The Data Handling GE also provides support for IoT hosting devices that for various reasons cannot be continuously online. The main reason is that the devices work under resource constraints such as being battery operated. This typically requires asynchronous communication with the IoT resources and for this purpose, local storage is required. To this aim, the Local Storage component provides two support functions. The first is to store cached IoT resource requests from the backend that cannot be processed due to the relevant IoT device being off-line. The second is to locally store retrieved data from IoT resources for subsequent retrieval by the backend and ultimately the applications. It is essential to handle the data and events from the IoT Resources (i.e. the devices connected to the IoT Gateway) or from the Backend/Platform (i.e. the IoT Services Enablement Platform) in a store. In particular the Data Handling GE deals with the Things Management GE events that are propagated from and to the Backend/Platform. It also deals with the Gateway Device Management GE events that are propagated from and to the IoT Resources. For that purpose, the Data Pooling component provides functionality to discover what is stored in the data store, to retrieve, to create, to delete, to update the data and events of the data store. For privacy and security concerns, access and storage rights are defined at the closer level of data production, to devices or to IoT resources. The Data Access Policy component is a dedicated additional component to the Security, Privacy and Trust which is providing features for authentication and centralized anonymization mechanisms. The Data Handling GE comes in two configurations. One that supports anonymization, local data support and another one that is aimed at constrained environments, which lack the resources for storage or anonymization mechanism. Both are equipped with a Complex Event Processor, but they are configured and operate in distinct ways. This distinction reflects the different resource requirements of the hardware on which the Data Handling GE is deployed. The CEP provided by Orange is aimed at a smart phone and the one by Atos is aimed at small, embedded sensor gateways that can be installed at various points in a sensor network infrastructure, e.g. a Smart City. Page 39 of 104

40 Figure 25 - Gateway Data Handling GE Interface Overview Gateway Protocol Adapter GE The Protocol Adapter GE deals with the incoming and outgoing traffic and messages between the Gateway and Devices registered to be served by the gateway. There may be multiple instances of Protocol Adapter GEs capable of serving non-iot devices, i.e. devices that do not support ETSI M2M. These devices can be IP-based devices, that communicates using the IP stack (IPv4 or IPv6), or "legacy devices", meaning devices communicating using non-ip based protocols, for instance ZigBee, or Z-Wave. Page 40 of 104

41 Figure 26 - Gateway Protocol Adapter GE Interface Overview The Protocol Adapter GE terminates these device specific protocols and translates them to a uniform internal API. The API exposed handle capabilities to read and write to the resources, as well as IoT specific management and configuration services such as resource discovery consisting of both look-up and publication. In particular the ZigBee Protocol Adapter provides a communication conduit into a ZigBee PAN(s) (Personal Area Network). It supports a mechanism whereby gateway can interact with individual ZigBee nodes to exert control over or to obtain data from those nodes or conversely a mechanism whereby the nodes can communicate some information to the gateway Architecture of Applications and Services Ecosystem and Delivery Framework The Generic Enablers for the Apps Chapter together build an ecosystem of applications and services that is sustainable and fosters innovation as well as cross-fertilization. In particular the Apps Generic Enablers supports managing services in a business framework across the whole service live cycle from creation and composition of services to monetization and revenue sharing. A couple of basic enablers are important to realize the vision of such a service business framework which enables new business models in an agile and flexible way: Page 41 of 104

42 A Store, which allows to offer services for consumers as well as developers of future internet applications. A Marketplace, which allows to find and compare offerings from different stores and provides further functionality to foster the market for future internet applications and services in a specific domain. An SLA Support, which monitors and evaluates runtime data according to the agreements of service levels. A Revenue Sharing System (RSS Engine), which allows the calculation and distribution of revenues according to the agreed business models. A set of Service Composition enablers, which allow to compose existing services to value added composite services and applications, which can be monetized in the Business Framework. A set of Mediator enablers, which can be used to achieve interoperability between future internet services and applications and also allow interface to existing enterprise systems. This set of self-contained enablers represents only an initial starting point for a future business framework. It is expected that supplemental enablers (e.g. for contracting, quotation...) will be developed outside of the FI-Ware projects. The Business Framework is heavily relying on USDL as common uniform description format for services which does not only focus on technical aspects of service, but also on business aspects as well as functional and non-functional service attributes.. USDL itself is not a Generic Enabler, since it is a data format and vocabulary specification. It will be introduced as an Open Specification, which is used by different enablers in their provided and consumed APIs. The Applications and Services Generic Enablers are named according to their main functionality which is different from the role names introduced in the FI-Ware Vision. While the role names (Aggregator, Broker, Gateway...) are used to describe the stakeholders of the service ecosystem in an abstract way, the enablers names are referring to software components. Page 42 of 104

43 The chapter consists of Figure 27 - Services Ecosystem and Delivery Framework Logical Architecture USDL is the Unified Service Description Language, which is used to share information about services and apps between the different GE Application Repository Application Marketplace Application Registry Application RSS Application Mediator Application Store Application Service Composition Application Service Mashup Application Mashup Application Light-weighted Semantic-enabled Composition 3.14 USDL (Unified Service Description Language) USDL (Unified Service Description Language) is a platform-neutral language for describing services. USDL is building a layer on top of technical service descriptions such as WSDL, which captures the information necessary to manage services in the business framework across the whole service lifecycle. Since USDL is just a data format and a set of vocabulary definition, we introduce it into FI-WARE as an Open Specification. Because of the fundamental role for the business framework, we will outline the rationale and concepts of USDL in this page as part of the architecture description of the Application and Services Ecosystem chapter. The FI-Ware approach will allow comprehensive service descriptions by employing the Unified Service Description Language (USDL) in its registry and repository. USDL builds on standards for Page 43 of 104

44 the technical description of services, such as WSDL, but adds business and operational information on top. With its ability to describe both human and IT-supported services that not only implement business processes, but also tie in assets linked to contents and the Internet of Things, USDL is set apart from many of the related approaches mentioned above. Figure 28 - USDL (Unified Service Description Language) Entity Model USDL is modularized to describe various aspects of services: Foundational Module: This module provides a common set of concepts and properties, such as time, location, organization, etc. that are used in all modules. Service Module: Describes the general information about the service type, nature, titles, taxonomy and descriptions. Participant Module: This module describes the participating organizations, contact persons and their role within the service fulfilment. Functional Module: This module contains information about the specific capabilities of a service, input/output parameters and constraints. Interaction Module: A module that describes the points of interaction and the responsible participants or participant roles in course of the service fulfilment. Technical Module: Describes how functions (capabilities) of a service are mapped to technical realizations of the service (e.g. WSDL operations, parameters, faults, etc.) Pricing Module: Contains information about price plans, price components, fences, etc. for a service. Service Level Module: The module which specifies service level agreements, such as time schedules, locations, and other constraints. Page 44 of 104

45 3.15 Security The internet and digital technologies are transforming our society by driving economic growth, reduces barriers to trade, connecting people across the world and providing new ways to communicate and co-operate. Our dependence on cyberspace is increasing and while cyberspace fosters open markets and open societies, unfortunately this very openness can also make us more vulnerable to a growing number of criminals, hackers, activists, foreign intelligence services, who want to exploit children and the vulnerable, to harm individuals, enterprises, public and private organizations by compromising or damaging revenues, reputations, privacy, business, critical infrastructures, sensitive data Cyber criminals demonstrate their ability to adjust quickly to new developments like mobile phone, PlayStations... The collective impact of this threat now has the potential to cause significant damage to online economies, affecting individuals and societies. For the first time in 2012, in its Global Risks report (Seventh Edition), the World Economic Forum put cyber attacks fourth in the Top 5 Global Risks in terms of Likelihood (page 12). In this report, we read (page 11 The Dark Side of Connectivity ): The impacts of crime, terrorism and war in the virtual world have yet to equal that of the physical world, but there is fear that this could change. Hyper connectivity is a reality. With over five billion mobile phones coupled with internet connectivity and cloud-based applications, daily life is more vulnerable to cyber threats and digital disruptions. Also Future Internet services will always be exposed to different types of threats that can lead to severe misuse and damage. Creating secured and trusted services without sacrificing much of the desired functionality, usability, performance and cost efficiency is a great challenge, especially in a dynamic environment where new threats and attack methods emerge on a daily basis. FI-WARE will provide an environment in which a diverse range of services are offered by a diverse range of suppliers, and users are likely to unknowingly invoke underlying services in a more dynamic and ad hoc manner. Moving from today s static services, we will see service consumers that transparently mix and match service components depending on service availability, quality, price and security attributes. Consequently, the applications seen by the end-users may be composed of multiple services emanating from many different providers, and the end user cannot really know if the security solutions implemented by a service provider are compliant with security policy claimed. In this context it becomes essential to have means of security monitoring extremely efficient and respond quickly to attacks. Of course, the Security monitoring covers more common threats, like toll-fraud, impersonation, service high jacking etc. To defend ourselves, Future Internet services need more intelligent early attack detection and support for decision and rapid action making faced with constantly evolving threats. This is one of the challenges of FI-WARE. The current landscapes of service delivery ecosystems do not fully address principals such as openness, usability and simplicity. FI-WARE aims to balance between simplified service usage and end user trust (including underlying security) in the service. FI-WARE will be designed in a flexible manner in order to reflect generic as well individual requirements. By that FI-WARE will be easily adaptable to upcoming needs. Furthermore this also is supported by including social interactions being part of the working community, e.g. by offering a security market place where anyone interested could contribute. A typical example of such a marketplace can be the sharing of Page 45 of 104

46 vulnerable configuration descriptions within a community of users, allowing faster reactions and even prevention from potential attacks exploiting these vulnerabilities Architecture Overview The overall ambition of the Security Architecture of FI-WARE is to demonstrate that the Vision of an Internet that is "secure by design" is becoming reality. Based on achievements to date and/or to come in the short-term (both from a technological but also a standardization perspective) we will show that "secure by design" is possible for the most important core (basic) and shared (generic) security functionalities as anticipated by the FI-WARE project and in accordance with the requirements of external stakeholders and users. The secure by design concept will, therefore, address both the security properties of the FI-WARE platform itself and the applications that will be built on top of it. As such, the Security Architecture will focus on key security functionalities such as identity management or security monitoring to be delivered as so-called generic security enablers that will be integrated with the design and implementation of the FI-WARE. Figure 29 - Overall FI-WARE Architecture Overview Security, Privacy and Trust in FI-WARE is mainly focusing on delivering tools and techniques to have the above-mentioned security needs properly met. Furthermore a decision making support and the automation of countermeasures allow alleviating the workload of users and administrators while raising their security awareness. The high-level Reference Architecture sketched in Figure below is formed by four main modules: Page 46 of 104

47 1. Security monitoring, 2. Generic Security Services: Identity Management, Privacy, Data Handling, 3. Context-Based Security and Compliance, 4. Optional Generic Security Services: Secure Storage Service, Morphus antivirus, DB Anonymiser. These services will be instantiated at runtime Interface to Networks and Devices (I2ND) Architecture I2ND defines an enabler space for providing Generic Enablers (GEs) to run an open and standardised network infrastructure. The infrastructure will have to deal with highly sophisticated terminals, as well as with highly sophisticated proxies, on one side, and with the network operator infrastructure on the other side. This latter will be implemented by physical network nodes, which typically are under direct control of an operator, or the node functionality will be virtualised in this case the I2ND functionality can be accessed by further potential providers, like virtual operators Architecture Overview The I2ND architecture covers four Generic Enablers (GEs). The four GEs have interfaces and APIs according to their underlying technologies: CDI (Connected Device Interface) towards the Connected Devices. These devices include, but are not limited to, mobile terminals, tablets, set top boxes and media phones, and have features such as remote access from a control environment, exposure of own functionality (device status, sensors, etc). CE (Cloud Edge) towards the Cloud Proxies. Cloud Proxies are gateways, which connect and control a set-up of nodes towards the Internet or/and an operator network. The nodes might be either accessible or not accessible from the outside networks. NETIC (NETwork Information and Control) towards Open Networks. Open Networks are following the idea of flow based controlled networks, and can be used for virtualisation of networks. S3C (Service Capability, Connectivity and Control) towards Underlying Networks. The underlying networks are following standards such as Next Generation Networks (NGNs) or Next Generation Mobile Networks (NGMNs). In the case of the S3C specified in I2ND the baseline underlying network is the Evolved Packet Core (EPC) by 3GPP. Page 47 of 104

48 Figure 30 - Interface to Networks and Devices (I2ND) Architecture Each of the GEs of I2ND has specific interfaces towards Application Developers, Cloud Services, FI-WARE and other Use Case GEs and projects. The respective interfaces are described in the GE sections. The GE S3C is the central point of the I2ND architecture. I2ND develops an enabling environment which can be used by network operators. Together with NetIC, both GEs will build the environment of an operator, which might even be a virtual operator. S3C can be seen as the GE to run and steer the network infrastructure. A special role in I2ND is devoted to the interface towards other operators. Since the Future Internet infrastructure will follow the Internet philosophy of a multi domain/end-to-end path through different network operators, it is necessary to interface with other operators. In I2ND the interface description provided by the ETICS project is adopted. The interface between NetIC and other operators promotes to the future of network interface virtualisation down to the network layer. This interface might be restricted by the owner of the network infrastructure, thus offering a sub-set of whole interactions. The interfacing between S3C and CDI provides status and control information exchange of the device and remote control capabilities. A respective interface template is used. Cloud proxies might be part of an operator infrastructure. Therefore it is necessary to have access to these network nodes through a standardised interface Developer Community and Tools Architecture FI-WARE will provide various strategic and fundamental means enabling the development of Page 48 of 104

49 Future Intenet Applications (FIApp). It is expected that around FI-WARE a community of developers will grown both to further work on the FI-WARE results (e.g. providing new Open Specification or improve the existing ones, to code new GE implementation, or set-up new FI- WARE Instances) and to develop new applications or doing business according to an open paradigm Architecture Overview The primary goal of the Developer Community and Tools (DCT) is to offer a multi-functional development environment - FI-CoDE - enabling the development and management of the Future Internet Applications (FIApp) built to address the needs of the Future Internet and based on the adoption and integration of the Generic Enablers Implementations. The FI-CoDE Architecture figure represents in a single diagram the main components provided to the Future Internet developer. Page 49 of 104

50 Figure 31 - Developer Community and Tools (DCT) Component overview All the functionalities are grouped by major aspects: IDE-CDE: interaction between the IDE and the Collaborative Development Environment API and Catalogue: the Catalogue provides the API of the GEs to the development environment Page 50 of 104

51 Deploy, Test and Validation: Future Internet Application deployment for testing and validation activities. For the first version of the FI-CoDE it has been decided to restrict the target development environment to the Java language (version 1.6 and later). Additional languages will be added later according to the available effort Outcome Analysis and Conclusions FI-WARE is composed of Generic Enablers that are grouped in Chapters. The analysis of the Chapter and their applicability to MOBiNET is presented in the table in the ANNEX. Beside the single Chapter and GE, FI-WARE uses basic technology that can be adopted also without the full adoption of the Generic Enabler. The table in ANNEX includes the analysis of some of these technologies. Page 51 of 104

52 4 SPITS Project Architecture and outcomes 4.1 Introduction SPITS 8 is a Dutch collaborative project executed by its 13 partners and funded by the SPITS partners and the Dutch Ministry of Economic affairs. SPITS is tasked with creating Intelligent Traffic Systems (ITS) concepts that can improve mobility and safety. The SPITS project focuses on three main areas: traffic management, in-vehicle solutions, and service download and management solutions. Intelligent Traffic Systems have the potential to utilize the existing road network more effectively as well as increase its total throughput. Better information can also improve safety on the roads, for instance when approaching sharp corners or alerting to other road users on imminent danger ahead. The SPITS project is defining an open and scalable platform for future systems and exploring new techniques in cooperative driving and mobility, to contribute to a more efficient and sustainable mobility solution. In the SPITS project, we examine an open and upgradeable in-vehicle platform on which these systems could be deployed, to ensure the latest products can always be deployed over the lifetime of the vehicle. The pace of modern innovation means that several technology generations are released during the normal lifetime of a vehicle, so an upgradeable approach is essential to keeping in-vehicle traffic systems relevant. SPITS is exploring concepts to create a service download and management solution for in-vehicle services that will cover consumer, fleet and traffic applications. In addition to hardware upgradeability, the services that are run on these systems will also evolve, as will the information they use. Adopting a simplified and open approach to services ensures that innovation and speed can be increased, allowing exciting new services to be developed for the future of traffic management and driver safety. SPITS platform specifications should enable ITS and infotainment application designers to create applications and services. An ITS or Infotainment software designer must be able to develop a SPITS compliant application or service based on the information in these specifications. The specifications define functions which can be used by applications. The platform consists of three main components: a back office environment (BO), an in-vehicle platform (OBU), and a road-side platform (RSU). Applications run on top of these three main components. Throughout this document, aspects related to applications are indicated in green, to the platform in yellow, and to sensors and actuators in purple. 8 Spits architecture group, Spits Architecture V1.1, Page 52 of 104

53 Figure 32 SPITS platform 4.2 Platform Architecture and Outcomes Description SPITS platform context The SPITS platform context view describes the relevant actors that interact with the platform. In the context view the system is modeled as a black box. At the borders of the box 'Actors' are connected through interfaces. Actors can be both man and machines. The main objective of the context view is to make clear for whom the functionality of the system is meant to be. The functionality itself will be defined through other Views. The figure below shows the context view of the SPITS platform. Figure 33: SPITS context view, showing the SPITS platform and the actors interacting with the platform. Application Software is considered an external Actor to the platform. The Application User and Administrative User use and manage the application software, respectively, indicated by the dashed arrows. However, as will be made clear in the Scenario Views, they also interact with the platform itself and are therefore included in the context view. SPITS Application Software Page 53 of 104

54 SPITS Application software offers functionality/services to Application Users. Applications can be based on the functionality offered by the SPITS platform and can be executed on the same hardware used by the platform. Application User Application users are using SPITS compliant applications on the SPITS platform. Users can be operators like traffic control, toll or parking operators, the driver, co-driver, passenger, fleet managers, traffic center operator and others. Physical interaction of the Application User is via the SPITS Platform (buttons, screen, speakers). Logically, the Application User interacts with SPITS Application Software that receives the stimuli from and sends responses to the hardware of the SPITS Platform. Administrative User This is a user that manages the SPITS applications, their configuration and settings. An Administrative User typically is a provider of SPITS applications, and configures SPITS platform related settings, e.g. for applications, users, devices, operational services. Owners are supported to install new or remove old applications, and to (re)configure their devices. Owners are enabled as Administrative Users to do system maintenance, such as user management, system management, etc. Maintainer Person that develops, repairs, maintains, deploys, certifies and validates or queries software or hardware modules in the SPITS Platform. The Maintainers interact directly with the SPITS platform. Vehicle The vehicle provides sensory information from SPITS equipped vehicles of its surroundings and own status to the SPITS platform and allows control by its actuators. This actor is described in more detail in the OBU subsystem architecture. Roadside device Roadside devices are equipment along the road that are not part of the SPITS platform. This can include legacy systems, like VRI's (traffic lights), VMS (text panels along the road), or loop detectors. Roadside devices can be used by the SPITS platform to obtain information, or to communicate with Drivers. Non SPITS service A service provided to the SPITS platform or Application software by a third party. For example: Radio Broadcaster, GPS satellites and GPS signals, but also RWS (traffic management center/service(s)) System Scenario The system scenario view describes a set of use case scenario's that are representative for the use of the SPITS platform. The system scenarios have been divided in two sets: platform scenarios and application scenarios. The application scenarios describe the use of Application Software. Application software uses the platform to realize its functionality. In this way, the Application scenarios also describe the (indirect) functionality of the platform. The platform scenarios describe the direct interaction of actors with the platform. The figure below summarizes both sets of scenarios. The platform scenarios describe the scenarios related to the platform directly, i.e. not the interaction of users with SPITS Application Software. An overview of all scenarios is given in the Page 54 of 104

55 figure below, and shows the interaction of the actors with these scenarios. Figure 34: Overview of all platform scenarios. The application scenarios describe the usage of applications that are running on top of the platform. The majority of the applications are used by the Application User inside the Vehicle, where the Application Software interacts, via the Platform with the Actor Vehicle (i.e. with the sensors and actuators in the vehicle). Some of the applications (also) interact with roadside equipment. The Application scenarios are further categorized loosely based on whether the roadside equipment is involved (Road side supported scenarios) or only the vehicle (Vehicle based scenarios) and a category of scenarios that does not fit either category (Other scenarios). The figures below show these categories of scenarios and how they interact with each other and with the actors. Page 55 of 104

56 Figure 35: Roadside device supported system scenarios. Figure 36: Vehicle based system scenarios. Page 56 of 104

57 Figure 37: Other system scenarios System Design The SPITS open and upgradeable platform ensures innovation can continue after first deployment. Proven, industry standard architecture and interfaces increase speed of application, reduce cost, and enable upgradeability. The SPITS architecture supports ITS applications by providing services as communication, navigation, application and user-interface management, sensor virtualization, and payment & billing. The SPITS platform consists of 3 types of subsystems: On-board Units (OBU) built into vehicles, Road Side Units (RSU) monitoring and controlling road infrastructure, and Back Offices (BOs) providing services to the other subsystems. Each subsystem has its own, cost effective architecture optimized for its specific role. Together, they provide an application platform for innovative traffic services that enhance mobility & safety. The subsystems are designed to run (certified) applications developed by 3rd parties and enable new business models for fast deployment. Figure 38: The system design view of the SPITS platform, showing also all the Actors. The Actors that are connected to the platform can interact with all three individual subsystems. Page 57 of 104

58 The On-board Unit The OBU subsystem is the SPITS subsystem which is inside a vehicle. It enables the execution of SPITS applications on the On-board Unit. The OBU collects information from the vehicle sensors, from other OBUs, from the BO, and from RSUs. The applications can use vehicle information and communicate with the application user. The main features of the OBU are: 1. The OBU support the possibility to add or remove functionality though a modular approach. 2. The OBU support the execution both of ITS and entertainment functionality on an single architecture. 3. The OBU can include optional services like navigation. 4. The OBU supports the possibility to add and remove temporarily (example: location specific) and permanent applications and platform related basic functions and services. 5. The OBU includes an HMI method dealing with safety related priority handling and variation of look and feel defined by vehicle manufacturers. 6. The OBU can communicate with nearby RSUs, nearby OBUs, BOs. 7. The functionality of the OBU can be managed remotely by a BO. 8. The OBU can be maintained locally by a system maintainer (e.g. a garage mechanic). OBU concept Today, the entertainment and navigation systems that are integrated in a vehicle have the same life span as the vehicle. The development of these systems starts years ahead of the market introduction of these vehicles, similar to other automotive vehicle systems. The functionality of these systems remains similar to the functionality that was offered when the vehicle is bought, which might be 10 years ago. In consumer (navigation) systems the time to market is shorter, the innovation speed is higher, and the product prices are lower. The architecture described in this document aims to bring these consumer benefits into the automotive entertainment, navigation, and ITS systems. Electrical perspective Integrated entertainment, navigation, and ITS systems in a vehicle are typically connected to onboard equipment. They are normally connected to on board speakers for audible entertainment, hand free telephone calls, or spoken navigation instructions. They might be connected to vehicle busses to obtain the vehicle speed, information from a steering wheel control, or the status of the head lights (to adjust display colors at night). They might verify the vehicle s identity to prevent that a stolen system is used in another vehicle or they might interact with a tachograph in a truck. These systems provide diagnostic functionality to vehicle service centers to aid vehicle repair. The vehicle integration has mechanical, electrical, and communication protocols aspects. The integration with the vehicle typically does not change over the life span of the vehicle as the vehicle does not change. In the architecture, the vehicle integration is separated from the other entertainment and navigation functionality and they are decoupled. The vehicle integrated part offers standard mechanical and electrically interfaces and communication protocols. Page 58 of 104

59 Figure 39: Example On-board Unit Figure 39 shows an example entertainment and navigation system, called On-board Unit (OBU). At the top elements are shown that are typically integrated for the vehicle s life span. At the bottom two kinds of elements are shown, nomadic devices (mass storage, ipod) and modules. Modules are introduced as replaceable units used to allow faster in vehicle innovation, independent of the vehicle integration. In the center of the figure is a head-unit, the head-unit is part of the vehicle and it is the bridge between the modules and nomadic devices and the vehicle integration. The head unit typically includes a graphical display. To allow modules and nomadic devices to be added later, and to allow them to be exchanged between vehicles, their interfaces should be agreed. The modules are connected via a standard USB connection. This consumer bus is introduced in automotive to reduce the cost and increase the flexibility, e.g. to interact with consumer devices. The modules can interact via standard USB device classes with the head-unit. For example, a module can present itself as a USB camera to send images to the head-unit s display while retrieving user actions back via USB keyboard or mouse messages. For more complex interaction, additional software interfaces are needed. For example, interfaces to provide data for a unified HMI or interfaces to obtain wheel sensor or other vehicle bus information. These software interfaces use USB as well. From functional point of view USB is just a transport channel allowing addition and removal of nodes, from architectural point of view some systems might also export a part of the functionality via another medium like Bluetooth. For commercial applications of the On-board Unit, some modules might also be integrated in a head-unit, limiting USB to the real plugable modules. Figure 39 shows direct audio connections from a head-unit to the speakers, and a vehicle bus between the head-unit and the wheel sensors. This is only an example; the head-unit s physical connections and peripherals will be vehicle model specific. Also the modules shown in the figure might be included in a head-unit, for example in a high-end radio-navigation head-unit. A low cost head-unit could rely on a module to offer such functionality. By supporting the module based extension, the head-unit can be upgraded later when a new feature is developed that doesn t fit with the previous hardware generation. Software perspective An increasing amount of on board entertainment and navigation systems is equipped with wireless connectivity. This enables value added services like finding an empty parking place, or informing a vehicle on the access restriction for an area. These services typically need an off-board part to provide the information and an on-board part to use the information or present it to the vehicle s Page 59 of 104

60 driver. The off-board part could be done by a Road Side Unit (RSU) with local (traffic related) information or a back office (BO) with location independent information. In addition to communicating with an RSU and BO, the software might also use communication with On-board Units of near-by vehicles. The services will not only change in the life span of the vehicle, some will also change in the life span of the modules. The set of 3rd party services offered for consumer devices in, for example, Apple s AppStore changes monthly. The software of the On-board Unit needs to be upgradeable for the individual services that are offered. More specifically, upgrading is a service itself. To allow software to be upgraded, the software interfaces available to the new software should be known and also the context should be known. Some software might need a real-time guarantee, other software might need a secure environment, and so on. This influences where the software can be executed. Deployment of the software over the electrical modules or the head-unit depends on these characteristics. In order to have commercial interesting systems, these contextual constraints like the secure environment and real-time guarantee are not valid for each part of the OBU. They are only valid in that part of the OBU which needs these constraints, e.g. a road-tollingmodule. For software without such constraints the software is be agnostic of where it s executed or which (wireless) communication channel is used. Electrically the system can be extended with functional modules. If a module with a wireless connection is added to a head-unit then it might replace or be used in addition to a wireless connection from the head-unit. The same holds if a more advanced navigation module is added. In general, 3rd party software on the On-board Unit does not care, if a hardware or software update is done, it depends only on the software interfaces for the functionality it needs. OBU SW deployment in SPITS On the various OBU hardware parts various processing environments exist that can execute software. An OBU head-unit can execute software and OBU modules can execute software. The software on the head-unit and the modules might be upgradeable and one or more of them might also support an OBU execution environment for SPITS applications. Figure 40: Example SPITS application deployment Figure 40 shows an example SPITS application deployed on a back office (BO), Road Side Unit Page 60 of 104

61 (RSU) and On-board Unit (OBU). Within the OBU this application is split into a head-unit part and a module part. Whether or not a SPITS application requires a BO, RSU and OBU and how many of those is application specific. An example of a SPITS application could be a traffic management system where a central Back Office application part provides a Road Side Unit with a requested traffic throughput to prevent traffic jams. Based on this, the road-side application part determines a speed advice for a specific vehicle and sends this advice to the On-board Unit on that vehicle. A module of the On-board Unit runs an application to receive speed advices and the head-unit of the On-board Unit runs the user interface to present this advice to the driver. The deployment in the OBU is configuration specific. All application parts might run on a single module or on the head-unit, or the different applications might be distributed. An OBU module could be able to run SPITS application parts or it could come with software that has to run on another node of the OBU in order to use the module. Figure 40 shows an example with two OBU nodes capable of running SPITS OBU application parts and one module which does not. The latter module might be a standard USB peripheral or module providing a wireless connection to Road Side Units. The application parts that run on a module or head-unit can use a SPITS OBU application interface. This software interface offers functionality which could be located on the same module or head-unit or on another one. The OBU SW deployment section contains diagrams showing an application/platform interface for the OBU. It shows that multiple interfaces exist. This section contains the interface definitions. The OBU architecture distinguishes two types of interfaces: execution environment and SPITS functions. The execution environment interfaces consist of the standard APIs that are provided by the native and virtual operating environments. Although the execution environment on an OBU can vary per module and head-unit, and different execution environments can co-exist in parallel, the OBU has selected one execution environment as its main execution environment; Linux/Android is used as main execution environment. Android is selected because it offers a more cost efficient and commercially successful open software ecosystem than the alternatives. It already offers a significant collection of applications and the Android platform is open source. The following figure provides an overview of the Android execution environment and the SPITS extensions. Page 61 of 104

62 Figure 41: SPITS extensions to the Android Execution Environment On the left side of the picture, the following SPITS extensions are depicted: Applications SPITS Applications are not part of the SPITS platform. The OBU part of applications can be deployed on the open SPITS system. Frameworks This is a placeholder for the functional ITS specific interfaces and frameworks that have been defined and developed for SPITS. Among others, SPITS frameworks supporting navigation, (digital) radio, and ad-hoc communication to other vehicles and Road Side Units are available for use by SPITS applications. Frameworks can have partial native implementations, but the interfaces are always offered inside the virtual execution platform. Management Agent The Management Agent is the part of the SPITS OBU Platform that provides support for remote management. It implements the remote management interfaces defined by the OSGi alliance. The remote management interface/protocol with the Back Office has not been defined by SPITS, but has to be defined by the specific owner or builder of the SPITS platform instance. Remote management supports the installation and management of OBU applications. Libraries Libraries is a placeholder for the native, Linux userspace support libraries in the SPITS OBU platform. These will be typically implementation dependent for a specific OBU realization. Reflection Reflection is the SPITS component technology that provides location transparent access to functions implemented on external USB modules. It implements the 'broker' functionality from the OBU SW deployment diagrams. Platform drivers SPITS platform drivers is the placeholder for OBU/ITS specific Linux kernel device drivers. Similar as for the libraries, these are implementation dependent and not standardized by SPITS. Page 62 of 104

63 The Road Side Unit The RSU platform enables the execution of SPITS applications on the Road Side Unit. Furthermore, the RSU enables the communication from OBUs to the BO and Non SPITS services. The platform is maintained either remotely or locally by the Maintainer. The RSU collects information from its Road Side Devices (camera's, loops, etc.), from Vehicles via their OBUs, from the BO, and from neighboring RSUs. All information is made available to applications via Information sources. The main features of the RSU are: 1. The RSU can communicate with other RSUs, with the BOs, and with nearby OBUs. 2. The RSU enables the communication from the nearby OBUs to the BOs. 3. The RSU can be maintained locally or remotely by a Maintainer. 4. The RSU collects information from all kinds of sources (Road Side Devices, Non-SPITS services, OBUs) and makes this information available for Application on the RSU. 5. The RSU can communicate with the nearby OBUs, with the BO, and optionally with nearby RSUs. The road side equipment plays an important role in ITS, and thus in the SPITS project. This equipment has four main components or functions: 1. Sensors observing the roads, vehicles, and/or other environmental parameters, e.g. cameras, loop detectors, etc. 2. A communication node for (wireless) communication with vehicles. 3. A service platform for the execution of SPITS applications and platform services that are localized at the road side, e.g. for scalability or delay requirements. 4. The applications & services being executed on the platform. In terms of the SPITS architecture and context (see RSU Context View), 1 is implemented by the actor Road Side device, 2 and 3 by the Road Side Unit (RSU), and 4 by the RSU Application software. Figure 42: Functional decomposition of the RSU, including both the SPITS RSU platform and the RSU Application Software Page 63 of 104

64 RSU platform functions OSGi Framework Part of the RSU Platform, responsible for providing class loading facilities, life cycle management and for maintaining a (local) Service Registry. The OSGi framework is represented as the System Bundle. The OSGi framework is the service platform on which RSU Application Software can be deployed. SPITS uses OSGi Release 4, version 4.3. An important part of the OSGi Framework is the support for IPv4 and IPv6, which is used for communication between the RSU and the BO and optionally between the RSU and the OBU. Standard OSGi Services These are standard functionalities that are part of the OSGi platform and are standardized by the OSGi Alliance. All mandatory services are included. Other services are optional, but if present, they should conform to the OSGi standards. Communication Provider The communication provider is responsible for transmitting messages to the vehicles and for receiving them. All incoming messages are collected and forwarded to the appropriate Message Manager. Outgoing messages can be send to a specific region, specific vehicle, or to all vehicles within range. For communication with OBU's CALM Fast over p is supported. Message Manager The message manager is responsible for encoding and decoding the (standardized) messages, exchanged with vehicles via the ad-how wireless network. These messages are partly standardized by ETSI, but for SPITS limited versions have been implemented. CAM Message Handler This message handler is responsible for transmission of the RSU Cooperative Awareness Messages (CAM), and for interpreting the incoming CAM messages from the vehicles. The incoming messages are forwarded to the RSU Sensor Platform for fusion with the road side information. Dynamic Map The Dynamic Map provides a real time view on all vehicles in the area covered by the RSU. The RSU Sensor Platform provides (asynchronous) information on the vehicles. The dynamic map extrapolates this information and can provide a full view on request by an application, or periodically. Management Agent Part of the SPITS RSU Platform that provides support for remote management. The interface with the OSGi environment is specified by the OSGi alliance. The remote management interface/protocol with the Back Office has not been defined by SPITS, but has to be defined by the specific owner or builder of the SPITS platform instance. Remote management includes both the Installation process (install, update, remove applications) and Execution management process (start, stop). ITS Gateways The ITS Gateways provide the actual p based communication to vehicles, i.e. the link to part of the Wireless Network (see Fig 5.1 in the SPITS Network architecture). Every ITS gateway covers a defined geographical area. It still has to be decided how to define this area, as exact boundaries for wireless communication cannot be specified. For cost and scalability reasons, a single RSU platform can contain multiple ITS Gateways as further illustrated in the RSU deployment section. SPITS RSU Application Software and Road Side Device functions The functions specified below are not part of the SPITS RSU platform. However, these functions are using the SPITS Platform, or provide information to the SPITS platform. RSU Sensor Platform The sensor platform provides real time information on the vehicles on the road covered by the RSU. The information can be obtained from road side sensors (e.g. cameras), Page 64 of 104

65 or from vehicle information. The vehicle information is provided by the CAM Message handler and forwarded to the RSU Sensor platform, where road side and car data is merged into a consistent view on all vehicles. The link between the RSU Sensor Platform and the Dynamic Map follows the Information Source design pattern as described in the system dataflow view Information Source. Shockwave Damping Shockwaves occur on highly occupied roads when drivers react on spontaneous maneuvers, resulting in a slow down or stopping of the traffic. The location where the vehicles stop can move backward, causing a shockwave in the traffic flow. This application will prevent or dissolves shockwaves by detecting when they arise and control the speed of the vehicles. Traffic Management This visualization application enables a traffic management center to have a detailed view of the situation on the road. Merging Assistant The merging assistant application detects gaps in the stream of vehicles on the main road and advises merging vehicles on how to smoothly merge into this gap. Page 65 of 104

66 RSU Information source data flow The picture below shows the data flow for Information Source related data. This means, that e.g. the data flow towards the OBUs not is indicated in the figure below. Figure 43: Data flow view of the Roadside equipment for Information source related data. Note, that additional data flows exist, e.g. for transmitting messages to the OBU's. RSU deployment As an example of RSU deployment, the SPITS Testsite Helmond is used. Below is a sketch of the deployment view. Page 66 of 104

67 Figure 44: Implementation view of the Roadside equipment for Testsite Helmond 9. The cameras will be connected via fiber links to a central Ethernet switch. Also the ITS Gateways are connected via this fiber network. The number of service platform devices for the test site is still under discussion. An OSGi platform is not required on the ITS Gateways for SPITS application software. However, it is still under consideration whether it is useful to implement an OSGi platform for remote management functions on the ITS Gateways. The Back Office The BO enables the hosting of SPITS applications on the Back Office Unit. The BO is maintained by local or remote System Maintenance. The main features of the BO are: 1. Infrastructure Management: Manages the SPITS network. 2. Application browsing, deployment of applications. 3. Services: Provides services by running service daemons. 4. Back-end: reporting, billing, portal to o the BOs and non SPITS services. 5. The BO can communicate with OBUs and RSUs Integrated Subsystem Design The three subsystems are described in detail separately in their respective sections. The figure below shows the interaction of the components of the subsystems. 9 Note, that the multiplicities are indicated correctly, but the absolute number of devices is not. The colors correspond to the color usage in the previous figures. Page 67 of 104

68 Figure 45: Interaction of the 3 Subsystems 4.3 Outcome Analysis and Conclusions The SPITS architecture supports the same type of applications as MOBiNET. The Focus of the SPITS architecture is mainly on the functionalities of the applications, whereas the focus of MOBiNET is mainly on supporting the business interaction required to enable the applications. The Page 68 of 104

69 architecture is a good basis for the applications, to be supported by MOBiNET. The implementations of the On board Unit can be used as a basis for the Mobiagent. The Roadside Unit will be used on the DITCM Testsite in Helmond. Furthermore, the Service Platform of the Roadside Unit can also be integrated in the mobiagent end-user devices. Page 69 of 104

70 5 Android and ios eco-systems features 5.1 Introduction To be able to install MOBiNET apps on a wide variety of devices it is needed to have some background information on how apps can be installed on these devices. For this we look at the 2 dominant mobile operating eco-systems: Android and ios. It is not intended to thoroughly describe the architecture of both eco-systems but to focus on the features that a most relevant for MOBiNET. The following features will be focused upon: How apps are installed on a device How apps can detect other apps installed on a device How apps can communicate with other apps installed on the device How apps can unlock / install new features on the device 5.2 Platform Architecture and Outcomes Description Installing apps On an Android device App developers are free to choose how they distribute apps to users. From publishing an app in a market place to mailing an app directly to users, anything is possible 10. However users have to opt-in their device to be able to install apps from unknown sources. The only known source for an Android device is the Google Play market place. Apps that are installed from other sources than the Google Play market place will not be able to use Google Play's in-app billing and licensing services. The Google Play licensing service can be used to apply licensing policies on apps. For example an app can restrict the use of the app to a specific device or to any other constrains a developer finds appropriate 11. To be able to reach the majority of Android users, and to be able to use Google Play services, the Google Play market place is the best way to distribute apps. The Google Play market place is available as a website and as a native Android app. From the website it is possible to browse through the apps, purchase an app and have it installed on one of your devices. The native Android app installs apps directly on the device itself Page 70 of 104

71 It is possible to deep link directly to apps that are in the Google Play market place but Google does not offer an official API to access the market place. However there are several unofficial libraries that can be used to search the Google Play store and retrieve information meta-data of an app. On an ios device The ios App Store is the only way for ios users to install apps on their devices (users willing to jailbreak their device excluded 12 ). The App Store is available from within itunes (available on both Windows and OS X) and as a dedicated ios app. It is possible to have an ios device install application purchased from within itunes automatically but there is no way to push applications towards a specific device, like there is in the Google Play market place website. Apps that are purchased (paid or for free) and installed from the App Store are linked to the Apple ID of the user. Apps are valid on all devices that are owned by the user for an unlimited time. For websites and apps it is possible to deep link 13 directly to apps that are in the App Store. Clicking a link will select the app in itunes, when used on a PC, or in the App Store app, when used on an ios device. itunes has a search API 14 than can be used by third parties to search the App Store and retrieve information meta-data of an app How apps can detect other apps installed On an Android device Via the PackageManager API developers can retrieve information on all apps that are installed on a device. On an ios device On ios there is no way to get a list of apps that are installed on the device. However under some circumstances it is possible to check whether or not an app is present on the device. ios apps can support custom URL schemes that reference these apps. Other apps can check if the custom URL scheme is supported on the device to see if an app is installed. There is a pitfall though: if more than one app registers the same URL scheme there is no process to determine which app is actually installed and will be started though the custom URL How apps can communicate with other apps On an Android device On Android, apps run in a sandboxed environment. There are different ways apps can communicate with other apps (or processes). The first way is called Intents 15. An app can send out an Intent to do something. The Android OS looks for candidate to execute the Intent and sees that Page 71 of 104

72 an app that implements the Intent is started. When there are multiple candidates that implement an Intent, the user is asked what apps to use. Arbitrary data, necessary to handle the Intent, can be added to the Intent by the app that is sending the Intent. Another way to interact with other apps is via a ContentProvider 16. A content provider manages access to a structured set of data and provides a mechanism to query and update that data. Finally, it is possible to interact with another apps is through Services via either Android Interface Definition Language 17 or a Messenger 18 depending if the service needs to perform concurrent interprocess communication or not. On an ios device On ios, apps also run in a sandboxed environment. There is no equivalent of an Android Service or Content Provider on ios but there is something similar to the Intent mechanism. ios devices can communicate with other apps 19 using custom URL schemas. An app creates a URL request, using the custom URL schema, and adds arbitrary data to it. When the app opens the URL the receiving app is moved to the foreground to open the URL and receive the data How apps can unlock / install new features On an Android device It is not mandatory that all executable code must be available in the app's binary distribution; although downloading and adding executable code from within a running app is tricky 20. Additional features can be unlocked via Google Play in-app billing 21 or another form of billing implemented by the developer. Google Play's in-app billing can be used for one-time billing (standard in-app products) and recurring, automated billing (subscriptions). All in-app purchases made via Google Play on Android are consumables. If and how a consumable is consumed is up to the developer. For example a premium upgrade of an app would typically not implement product consumption. On an ios device All executable code must be available in the app's binary distribution. Additional functions can be unlocked via in-app purchases different types of goods can be purchased via in-app purchases: consumables, non-consumables and (auto-renewable) subscriptions. Consumables can be bought more than once and can be used up. Non-consumables are bought only once and are valid on all devices that are owned by the user. Subscriptions allow the user to ancedapptricks/advancedapptricks.html#//apple_ref/doc/uid/tp ch7-sw e/13_managingin-apppurchases/managingin-apppurchases.html#//apple_ref/doc/uid/tp ch4- SW1 Page 72 of 104

73 purchase access to services or content for a set duration of time. Subscriptions renew automatically unless the user opts out. Non-renewing subscriptions can also be offered. Subscriptions must be available on all devices that are owned by the user. The developer has to make sure that, when an in-app purchase is made, the feature that is purchased by the user is unlocked and / or additional resources are downloaded from a server. 5.3 Outcome Analysis and Conclusions From the analysis it becomes clear that both eco-systems behave somewhat similar on the investigated features. Android gives the app developer the most flexibility in how to use the Google Play services but all investigated features are also possible to implement, to a certain extent, on ios and the Apple App Store. It will be possible to create a similar end-user experience for installing and using MOBiNET apps on both platforms if the platform is willing to compromise on how MOBiNET apps interact with each other. Both the Google Play Store (see paragraph 4.5 of the distribution agreement and the Apple App Store have a non-competition paragraph in their distribution agreements. This forbids the distribution of apps whose purpose it is to distribute apps outside of the stores. Page 73 of 104

74 6 Instant Mobility Architecture and outcomes 6.1 Introduction The Instant Mobility project was the Use Case project in the area of mobility of the Future Internet Public-Private Partnerships (FI PPP) programme. The project defined scenarios and services for multimodal travellers, drivers & passengers, passenger transport operators, goods vehicle operator s, road operators & traffic managers. A particular aspect of Instant Mobility was the definition of requirements for Future Internet technology tools and enablers, so that all these services will be available to any Internet-connected user, whether using a portable, vehicle-based or fixed terminal. In the Instant Mobility vision, every journey and every transport movement is part of a fully connected and self-optimising ecosystem in which travellers, goods and collective transport will benefit from personalised and real-time information delivered by next generation Internet technologies. Future Internet technologies will offer accurate positioning, continuous connectivity and a host of personalised online mobility services. The Instant Mobility project provided three parallel scenarios for multimodal mobility for people and goods in urban areas with a user and business-centred focus, namely: Personal travel companion; Smart city logistics; Transport infrastructure as a service. Each scenario comprises a set of applications addressing the needs of the different actors involved and describes a number of Future Internet-supported services that are likely to be used by and to benefit a particular group of stakeholders. As the final output of Instant Mobility, these scenarios have been demonstrated by conceptual software prototypes. Instant Mobility and MOBiNET are quite complementary to each other. The focus of Instant Mobility was to provide better mobility services on the basis of the Future Internet technologies. The focus of MOBiNET is making the combination of existing mobility services easier by providing a minimum set of infrastructure components. However, Instant Mobility offers good insights into the FI-WARE GEs which are relevant to MOBiNET. 6.2 Platform Architecture and Outcomes Description This section provides an overview about the Instant Mobility platform. We present Instant Mobility`s leading use case scenarios, a high-level overview about the general platform architecture, and an overview of the implemented prototypes Scenarios Personal travel companion The personal travel companion offers services for transport operators and human traveller`s to provide and receive up-to-date information and to be guided in consequence. The scenario is aimed at multi-modal travel, mainly in urban and inter-urban areas. Long distance journeys are also taken into account but as a more straightforward case. Travellers, drivers and transport operators will benefit from dynamic planning and follow-up during multimodal journeys: Travellers will be able plan and adjust in real time a multi-modal journey from door to door; Vehicle drivers will be able to easily book and execute ride sharing on their way to their own Page 74 of 104

75 destination; Transport operators will get the complete information necessary to initiate demand driven transportation. The foreseen services are: Dynamic multi-modal journey; Dynamic ride sharing; Optimized public transport usage Smart city logistics Smart city logistics are aimed improving city logistics operations with respect to safety, efficiency, environmental performance, and quality of service. It considers pick-up and distribution operations mainly relying on the use of trucks or delivery vans. The smart city logistics scenario considers the optimising of vehicle utilization, increasing consignee convenience by for instance flexible good drop off and eco-optimised driving. The foreseen services are: Load sharing and optimising; Dynamic time/place drop point; Itinerary booking and real-time optimized route navigation; Eco-optimised driving, vehicle and driveline control Transport infrastructure as a service The transport infrastructure as a service provides online traffic and infrastructure management. Dynamic traffic management and integrated urban space management will be virtualized and based on Future Internet technologies such as cloud data storage, cloud computing and virtualization or services in the cloud. Transport infrastructure as a service defines the online traffic and urban management generic enablers to improve the levels of mobility on the roads by acting as B2B services (e.g., provision of accurate real-time traffic information for mobility services such as routing information). The foreseen services contain both information collection and service provision: Real-time traffic and route information; Floating passenger data collection; Virtualized intersection intelligence; Cooperative traffic signal control; Area wide optimization strategies Platform Architecture Page 75 of 104

76 Architectural Vision From a technical point of view the vision of the Instant Mobility platform is described best by the following properties: Data-centric: Within the Instant Mobility system a continuous stream of data and events has to be processed in an efficient and safe manner. The data originates from various origins like travellers, floating cars, the road network or public transport officials. Real-time: Data and events have to be processed in real-time. E.g., this is an important system property for the navigation and routing applications. Another example is the traffic operator who needs to be immediately informed about critical traffic situations to undertake concrete compensation actions. In this context, the term real-time means that the usefulness of a result degrades after a deadline is missed. This is also referred to as soft real-time in the area of real-time computing. Distributed: Not only processing nodes of the system are distributed over the network to create a robust and scalable system. In addition, the data producers (like road side units, floating cars) and the potential service consumers (like travellers) are distributed over the network as well. In this context, a number of different nomadic devices like in-vehicle systems or mobile phones are part of the system as well. They might act as both data producers and consumers. Thus, the Instant Mobility system can be considered as a heavily distributed mobile system. Open: The Instant Mobility services have to be provided using open, common, widely-used standards to facilitate usage of the platform. In addition, this is required for efficient and easy integration with external systems. Federated: The provided functionalities of the different scenarios focus on metropolitan areas. This also needs to be reflected by the system architecture to be able to meet the real-time constraints. Particularly, this is required to achieve the geographically scalability of the system. The basic idea is to deploy a metropolitan-specific set of Instant Mobility services on a metropolitan-near located cloud infrastructure. Thus, it is ensured that data is efficiently processed next to its production. Figure 46 summaries the basic assumptions and shows a high-level view of a metropolitan-specific Instant Mobility instance. Page 76 of 104

77 Figure 46: High-Level View on the Instant Mobility System Basically, the functionalities of the Instant Mobility ecosystem are offered by a RESTful (Representational State Transfer) Web Service interface layer. These services form the basis to build the scenario-specific applications of the different scenarios (e.g., Web portals, mobile applications, etc.). For efficient distribution of data between data producers and data processing components, an efficient real-time enabled data distribution middleware is required. However, these systems introduce a relative tight coupling between components with regard to the exchanged data. E.g., a major change of the data model could force a re-deployment of all involved components. Thus, a complementary communication middleware system is required as well which supports flexible, context-based publication of and subscription to data events. The major use case is to provide context-aware information to external systems. This approach results in a great flexibility when adaptions of the interaction patterns or the system architecture are required. Finally, to achieve an elastic scalability of the overall system, the components run on a cloud infrastructure. Figure 47 sketches the idea of an Instant Mobility federated system. Page 77 of 104

78 Figure 47: Instant Mobility Federation The basic idea is to deploy the required Instant Mobility components on a cloud infrastructure which is located next to a metropolitan area. In particular, the different Instant Mobility clouds have to be able to communicate, for instance, to transparently hand-over a traveller`s itinerary in case of an inter-metropolitan journey. Another use case might be the quick dissemination of traffic events which have the potential to sustainably influence the traffic situation in another metropolitan area Conceptual Architecture Figure 48 shows the foreseen conceptual architecture of the Instant Mobility system. The following sub-sections describe the specific layers of the multi-tiered architecture in more detail. Page 78 of 104

79 Figure 48: High-level conceptual architecture Application Layer The application layer contains the different end user applications and administrative user interfaces which are developed in context of the specific scenarios. The basic idea is that the end user applications are built on top of the API which is provided by the underlying service layer. For instance, the traveller companion application calls the RESTful Web Service for planning a future journey which is provided by the Multi-Modal Mobility sub-system. The target platforms vary from scenario to scenario. Basically, the different scenarios require the development of Web-based applications or applications which run on mobile devices or even on invehicle devices Service Layer The service layer exports the functionalities of service components in a standardized manner using RESTful Web Services. Thus, it functions as the dedicated facade to the Instant Mobility ecosystem. Primary, this layer provides the functionality which is used to implement the various end user and management applications. In addition, it serves as an open, standardized integration layer and entry point for third-parties like data providers. Additionally, the service layer allows the re-use of the Instant Mobility functionality. Page 79 of 104

80 By applying the REST principles to the service layer, the service API is provided as a scalable facade which is able to guarantee the same level of Quality of Service even with a largely increasing number of client requests. In addition, REST provides the foundation to ensure interoperability with a heterogeneous client environment and to safely evolve the service API Service Component Layer This layer contains the server-side components, which implement the business logic of the Instant Mobility ecosystem. Every component exposes its public API through RESTful Web Services. Thus, the APIs of all components effectively build the service layer. Figure 48 shows the high-level components of the different scenarios and example interactions. Additionally, Figure 49 and Table 1 provide a summary of the different subsystems and their dependencies. Page 80 of 104

81 Figure 49: High-Level overview of the Instant Mobility Subsystems Table 1: Summary of identified subsystems Subsystem Multi-Modal Mobility Description - Provides the core real-time navigation and routing functionality - Covers aspects like multi-modal journey planning, itinerary monitoring, and notification of travellers - Provides services to include pricing offerings of different transport providers Payment - Handles seamlessly all payment issues of the traveller by means of virtual tickets - Functions as a kind of payment broker to connect all involved stakeholders - Provides the traveller`s front-end to plan and execute a multimodal journey Personal Companion Travel o o Provides location-aware and situation-aware information to the traveller Provides the traveller`s front-end to make use of the payment services - Focuses on seamless usage of all devices to achieve the best possible journey experience Public Transport - Provides a front-end to enable public transport planners to advertise their transport offerings and to operate and optimise their offerings in accordance to the demand - Enables a complete supervision of an area on the basis of collected traffic information Traffic Manager - Implementation of virtual road side units - Provides front-ends to different stakeholders for optimised presentation of traffic information Goods Transport - Supports sharing and optimisation of transport resources Page 81 of 104

82 Manager - Supports dynamic drop point negotiation between consignee and haulier - Enables the optimisation of transport itineraries on a basis of transport mission and current traffic situation Backend Layer The backend layer separates the business logic from access to external system (e.g., for data storage or information retrieval) by dedicated abstract interfaces. From an analysis of the foreseen scenario-specific components, the following backend interface types have been identified: Data Storage and Backup: Reliable data persistence is relevant for every scenario. In this context, statistical or operational data has to be stored. However, there is also the need to process structured and semi-structured data across the scenarios. Real-time Traffic Data: Traffic-related data is relevant for the scenarios transport infrastructure as a service and personal travel companion. One shared requirement is that data events have to be distributed to data processors in real-time as soon as they occur. In this context, collection of location-based data and data originating from traffic infrastructure components is required. Traffic Control: This interface enables a service component to interact and send commands to a traffic infrastructure component like a road side unit or a traffic sign. Thus, it requires interaction on a thing level. This interface is particularly relevant for the transport infrastructure as a service Communication Figure 50 sketches the foreseen communication architecture by showing the interactions between selected components. Components are assigned to a specific architectural layer. Additionally, communication flows, communication middleware components and provided interfaces are illustrated. In the following we summarise the foreseen communication options: Point-to-point communication: In this context, the involved components directly interact with each other in a synchronous request-response manner. For that purpose the corresponding service components expose Page 82 of 104

83 specific RESTful Web Services. An example is a request of the Transport Exchange Portal to the Multi-Modal Mobility subsystem to provide alternative itineraries for transportation route optimisation. Another example is the request of the Personal Traveller Companion application to plan a journey. Context-based publish-subscribe communication: This communication option supports flexible, context-based provision of data to the world of final consumers (e.g., other platforms, components, end user applications). I.e., data consumers can take into account the situation in which a specific data element has been produced. This results in a great flexibility when adaptions of the interaction patterns are required. The required middleware should be provided by the Context Broker GE 23. The Context Broker GE exposes a RESTful Web Service interface which can be used for publication of context-aware data and to allow context-based subscription to data events. An example is that the Personal Traveller Companion mobile application which only takes specific itinerary events into account (e.g., changed route notification) while ignoring other events (e.g., advertisement events). Real-time, data-centric publish-subscribe communication: This communication option supports real-time data sharing between data producer and data consumer components. In this context, the data model should be quite mature (at best following established standards) because major changes might require a re-deployment of the involved components. In this context, the communicating components are required to implement IDL-based interfaces which fit to the published data format. The required middleware should be provided by the Advanced Middleware GE 24. This GE addresses a maximum level of system performance and scalability. Real-time data sharing is particularly required by the data collection and data processing components of the Multi-Modal Mobility and Traffic Manager subsystems. In this context, formats of exchanged data are often compliant to established standards. Thus, we do not expect major changes of resulting data models Page 83 of 104

84 Figure 50: Communication Architecture Page 84 of 104

85 D Platform state-of-the-art review Security Communication between components is basically performed on basis of RESTful Web Services which utilise the HTTP protocol. Securing HTTP communication is well investigated topic. Thus, basically we can rely on well-established authentication like TLS (Transport Layer Security). TLS is standardised by the IETF 25 and utilises different cryptography mechanisms in a flexible manner (e.g., asymmetric cryptography for key exchange, symmetric encryption to ensure privacy, message authentication codes to ensure message integrity). Thus, TLS provides secure point-to-point communication Federated Authentication For authentication the use of federated authentication mechanisms rather than providing an own, dedicated system is valuable. The OpenID 2.0 standard has been considered in order to provide a federated authentication infrastructure and to enable single sign-on Delegated Authorisation As Instant Mobility provides a RESTful Web Service API, there are also use cases in which point-to-point secured connection are not sufficient. Particularly, the user`s application might invoke a service which inturn needs to make another service call on behalf of the user. Thus, a mechanism for authorisation delegation is required. For RESTful APIs, OAuth 2.0 is the mean of choice and is already widely adopted. Instead of transferring user credentials from one communication endpoint to another, a security token of restricted lifetime is used to indicate that an application acts on behalf of the user. OAuth introduces an authorisation server which is in charge of issuing security tokens and authenticating end users. The application request the security token from the authorisation server and sends the authorisation code for that purpose. For further technical details, we refer to DraftOAuthV2 27 and OAuth2Introduction Privacy The collection of location information, both real-time locations and permanent locations (e.g., home address), requires special considerations because: The disclosure of this information might cause consequences for privacy and physical safety of the user. The simple transmission of a location may allow near-perfect personal tracking. Location tracking can reveal a user`s home address and employer by looking for typical night and day-time locations, even without identifying information. Figure 51 shows the identified security data flow. The basic idea is to make use of pseudonym certificates to establish the trust between the Instant Mobility services and the traveller. The pseudonym certificate holds some verified attributes which allow services to make certain assertions about the traveller but still hides his/her identity. 25 RFC524: 26 OpenIDWiki: 27 DraftOAuthV2: 28 OAuth2Introduction: 19/09/14 Page 85 of 104

86 (Traveler) Pseudonym Certicate (Step 2) TRAVELLER TRUSTED AUTHORITY Pseudonym Certicate Request (Step 1) PAYMENT AUTHORITY (i.e. Bank) Payment Certicate Request (Step 3) Payment Certicate (Step 4) Roadmap for agreement (Step 10) Security alert Traveller or Diver Pseudonym Certificate Identification Request Identification data Traveller or Diver identity Multi-modal Transport Request + Location + Traveler preferences + (Traveler) Pseudonym Certificate + (Traveler) Payment Certificate (Step 5) Roadmap + e_ticket(s) + (Driver) Pseudonym Certificate(s) (Step 14) Location + Traveler Identity + (Driver) Pseudonym Certificate POLICE Roadmap agreement (Step 11) Location + Driver Identity + (Traveller) Pseudonym Certificate Secure Ticketing Payment Secure Drivers Payment with Payment Certificates Security alert Police Car Routes and Timetables Request (Step 6) INSTANT MOBILITY SERVICES PLATFORM Carpooling Request (Step 8) (Traveler) Pseudonym Certicate (Step 15) DRIVER(s) Buying e_tickets with Payment Certificate (Step 12) VPN Carpooling agreement (Step 9) VPN e_tickets (Step 13) PUBLIC TRANSPORTATIONS Sensitive Data base Routes and Timetables (Step 7) Traveller data Drivers data, Payment data. K-Anonymization & Data Transfer Location data (regularely) + (Driver) Pseudonym Certificate (Driver) Pseudonym Certicate DRIVER Pseudonym Certicate Request TRUSTED AUTHORITY Public Traffic Optimization Centre Figure 51: Security data flow However, the free availability of fine-granular location information might still allow re-identification of anonymised users. For that purpose Instant Mobility requested the extension of FI-WARE`s current privacy concept by a location monitoring component. This component should monitor the real-time location of anonymised users. Particularly, it is the only component which obtains this kind of information. The user might explicitly allow or disallow which events (e.g., planned itinerary delay, proximity alert) might be received by whom. Thus, only authorised parties can subscribe to this information and are notified. The component might also publish anonymised information about traveller`s movements. However, to publish location data without compromising privacy, either a spatial-domain or a time-domain approach has to be used. I.e., the traces are either at coarse granularity levels so that the anonymity sets are large enough to preserve privacy (e.g., the location granularity is at city level or above) or too short to make it difficult/impossible to infer locations correctly Overview of the implemented Prototypes The following sections describe the developed prototypes. The description of every prototype includes the implementation scope and an overview about integrated FI-WARE GEs Scenario 1 Personal Travel Companion Instant Mobility scenario 1 prototype simulates in a realistic way, the urban and suburban trips in a city, based on the population's movement statistics. The city map displays the live positions of buses, travellers and cars and the journey details of each traveller could be obtained in real time. A statistics Page 86 of 104

87 D Platform state-of-the-art review panel provides key figures of the simulation. The prototype also includes the dialog between a traveller and a car driver involved in a common-ride. Figure 52: Scenario 1 - Ride sharing prototype layout Implementation Scope The following figure shows the logical view of the multi-modal system main prototype. 19/09/14 Page 87 of 104

88 Figure 53: Scenario 1 Prototype logical architecture As shown above, there are three core components: Route Determination Engine: This component provides itineraries for travellers and drivers (multi-modal solutions for travellers and the fastest routes for drivers). Multi-modality requires to efficiently mixing multiple means of transportation in a single consistent and optimal journey proposal. This component takes into account all the means of transportation (private cars, buses, metro) in a consistent manner making it easy to add new transportation modes. Situation Display: The situation display shows the position of travellers and mean of transportation. It calculates and shows the mobility metrics (e.g. percentage of multi-modal itineraries). It allows for the selection of the traveller/driver pair whose itinerary (and initial hand-shake dialog) can be shown on the mobile phones. The display interface authorizes new events to be injected to the simulation (e.g. car broken) leading to automatic rerouting of the potential travellers when required. Simulator: The simulator has multiple purposes. First, the simulation of the travellers/drivers by performing itinerary requests to the route determination engines. These requests are based on the actual statistical data of source-destination needs of the users. Second, the simulation moves the cars, buses and other mean of transport taking into account historical flow speed at the time of travel. The simulator is also responsible of the temporal coherence of the movements and of the Page 88 of 104

89 D Platform state-of-the-art review matchmaking between travellers and means of transport. Third, the simulator provides an interface (REST) to the mobile applications to show itineraries of selected travellers (selection being done by the situation display). The mobile applications (which include the on-board unit) are pure Javascript implementations calling the simulator REST services. The system uses an OMG (Object Management Group) Data Distribution Service middleware to achieve linear scalability (application can scale by adding more processing units). There can be as many instances of the core components as required. For example, the demonstration used four instances of the Route Determination Engine all of them could be running on separate machines interconnected through a local network. All potential points of contentions have been identified and removed through data distribution, aggregation and filtering (e.g. situation displays). One of the key benefits is that all components are entirely decoupled. The application is fully distributed and most of the modules are pluggable. Additionally, the Ride Sharing mobile application has been developed to show the possible user experience. It was developed in HTML/CSS/Javascript and can thus be accessed by any standard web browser. There are two users involved: a pedestrian (rider) looking for a ride and a driver that potentially is able and willing to offer a ride. There is a single application which is thus twofold; the first splash screen has the task to determine the user s role. Table 2 Ride Sharing mobile app Initial Splash Screen that allows to choose between driver and traveller interface Here the user can choose the start and the destination (both driver and rider case) The system provides an itinerary to the rider. The itinerary has a ride sharing segment, indicated by the multimodal icon in the top-right corner of the screen. After clicking on multimodal icon the application asks the rider if he wants to accept the proposed driver 19/09/14 Page 89 of 104

90 If rider accepts, also the driver is asked to accept the proposed rider. When the driver accepts the rider, the system notifies it to the driver and vice versa Here the two users can see their respective positions FI-WARE integration The prototype integrates with the Data Handling GE 29 to allow/disallow diffusion of travellers/drivers pictures based on users predefined policies. If the Data Handling GE is disabled or if the policy does not allow for picture diffusion, generic pictures (male or female) are shown on the traveller mobiles and onboard units. In addition, the prototype integration with Identity Management GE [22] 30 that provides user management capabilities has been tested (registration, login, etc.). A Java server that interacts with the Identity Management GE has been developed, and now it s ready to be integrated into the existing Personal Traveller Companion server. As the Advanced Middleware GE [16] was not ready at the time of the prototype implementation, the OpenSplice Data Distribution middleware 31 has been used instead Scenario 2 Smart City Logistics The purpose of the smart city logistics scenario is to increase the sustainability of city logistics by optimizing the vehicle utilization, in order not to use more vehicles than necessary and also to optimize the way the vehicles are driven. A purpose specific to the dynamic drop point application, on which this prototype is focused, is to increase the convenience for the consignee, by offering flexibility in choosing a 29 ng 30 Enabler 31 Page 90 of 104

91 D Platform state-of-the-art review suitable time and location for dropping off goods, in order to avoid unnecessary transports, both by the transporter, who can avoid trying to deliver goods to someone who is not at home, but also by the consignee, who can avoid make an additional trip in order to pick up goods. The pre-condition of the smart city logistics prototype is that a transport need has been detected and transport resources have been registered in the system; that is, a set of transport bookings have been submitted to the transport exchange portal via the Web service interface. Based on available transport resources and submitted transport bookings, itineraries are planned by the system. By using the Consignee App, the goods receiver can select calendar events to upload, which are then used by the system as input when planning itineraries. Using the vehicle simulation web application, itineraries can be downloaded to a simulated vehicle, which executes them on a map and reports back to the transport exchange portal Implemented Scope Figure 54: Smart City Logistics prototype architecture The Smart City Logistics prototype consists of three main nodes; the vehicle, the server-side and the consignee s mobile device. The main components of the server side are the Web services, which implement the vehicle transport management interface, the transport resource manager and the consignee API. There are several clients to these Web services; the itinerary processor develops itineraries based on the transport need and available resources, the transport exchange portal provides an overview of the transport bookings and itineraries, the consignee app provides the dynamic drop point service to the end user and the simulated vehicle executes the itineraries. The simulated vehicle is a client to the vehicle transport management interface. It is implemented as a Google Web Toolkit application running inside a Web browser, which lets the user select a vehicle itinerary and follow the execution of the itinerary on a map. 19/09/14 Page 91 of 104