The BONVOYAGE system entails a pervasive degree of interactions among travellers, tools, databases, multimodal transportation systems, sensor networks, and forecasting models. All these actors can be physically placed in and/or logically belong to various organizations, which enforce different and not necessarily interoperable policies on data access and management.
In addition, the provisioning of a sophisticated door-to-door journey planner system is highly likely to require a high-level service orchestration of simpler services provided by entities and organizations that were not initially designed to interoperate with each other. Also, the traveller, along the trip, can migrate from one access network and Internet Service Provider (ISP) to the next, all the time needing to maintain a consistent status and connectivity with the networking infrastructure.
A preliminary architecture of the BONVOYAGE platform is shown below. The figure shows the main architectural blocks and their relationships to the technological Workpackages.
As regards the networking infrastructure, it is necessary to achieve efficient interoperability among different network realms and to make them flexible and adaptable to different environments. To this end, the BONVOYAGE system will define a novel Internames Communication System in charge of: (i) ensuring seamless connectivity across different existing network realms; (ii) natively supporting mobility and security issues; (iii) providing travel-centric primitives for push/pull based services; (iv) guaranteeing high efficiency in communication and processing operations; (v) enforcing graceful deployability and interoperability with existing systems. Our network, called Internames, allows communications among entities identified by names, without a static binding of end-points or users to their current location. This change of perspective is recognized as the angular stone of Future Internet architectures and will be leveraged in Internames to move a significant step forward to satisfy requirements (i)-(v).
The Multimodal Integrated Interfaces are in charge of (i) forwarding End-user information (contained in the user request) through the Internames Communication System, (ii) gathering Transport Operator Information coming from the Transport Operators in terms of available transportation resources and related schedule, the ticketing information, the current congestion status and all other environment data, including data from sensors, possibly affecting the transportation resources, following the indications provided by the Internames Communication System. The Multimodal Integrated Interfaces are implemented through a set of distributed agents transparently embedded in strategic network nodes (e.g., in users’ smart phones, in transport operator control centers, etc.). Such agents are technology-dependent in the sense that they are tailored to the technologies adopted by the specific transport operator for data acquisition/storage, for database organization, for data format, etc.
The Metadata Handling Tool will handle heterogeneous data in real time. It will be in charge of (i) discovering the heterogeneous data relevant to the user requests, (ii) preliminary filtering of the data, (iii) converting them into homogeneous technology-independent metadata by using ad hoc ontologies, (iv) properly aggregating the metadata while semantically enriching them. The resulting personalized, aggregated, semantically enriched metadata form a so called Dynamic Present Context. This Context will be stored in a dedicated database: the Multi-Modal Mobility Database. The Context will be the valuable input information for the User Profiler Tool, for the Multi-Objective Optimization Tool and for the Tariff Scheme Design Tool. The Database Services will provide the necessary interfaces for accessing and updating the Context in the database, providing an abstraction layer to hide the concrete technologies used to implement the actual database.
The User Profiler Tool will be in charge of a non-real time analysis of the metadata stored in the Multi-Modal Mobility database, by adopting ad hoc machine learning techniques suitable for dealing with big data and extracting useful information from data in terms of recurrent and interesting mobility patterns. Such analysis is expected to identify a set of data-driven user profiles and to map each user to the right profile automatically. Each profile is associated with a set of parameters which will indicate the Quality of Experience (QoE) expected by the user for the trip.
The Multi-Objective Optimization Tool is a key component of Bonvoyage. Whenever triggered by a user request, the tool retrieves the corresponding Dynamic Present Context stored in the Multi-Modal Mobility Database and the corresponding User Profile from the User Profiler Tool. The Multi-Objective Optimization Tool provides Personalized Control Decisions tailored on the requesting user (e.g. the optimal multi-modal travel, possible multi-modal tariff schemes, ….). These decisions will be optimal in the Present Context with respect to his/her User Profile and personalized on the characteristics of the user device.
The Tariff Scheme Design Tool will be able to gather detailed data on the demand of any mobility service operator from the Internames Communication System, such as, for instance, those derived from tracking every single end user’s entry into the operator’s vehicles. Access to such data will be provided by an operator through the use of suitable web services, so as to simplify the interoperability between the platform internal software modules and each operator’s legacy system. Therefore, the platform will allow any transport operator to define and make available to end users several multi-part tariff schemes associated with the optimal multi-modal travel solution provided by the Multi-Objective Optimization Tool.
Multi-Objective Optimization Tool and the Tariff Scheme Design Tool collaborate to determine Personalized Control decision, including optimal personalized tariffs/prices and the associated optimal travel parameters.
The Personalized Control Decisions are transmitted through the Internames Communication System to the Service Adaptation module which, on the basis of these decisions, elaborates one or more Personalized Services (e.g., personalized travel solution, personalized tariff schemes, ticket reservation, ….) tailored for the requesting user.
Finally, some last considerations regard the Internames Communication System that will have to support communications among all components, in a scenario characterised by the increasing presence of sensors/identifiers in transportation systems and in the environment, facing several challenges, including: “(1) mobility: a smart transportation system must deal with a large number of mobile nodes; (2) real-time and reliability: a smart transportation system must be able to operate on real-time and remain resilient in the presence of failures; (3) in-network computing/filtering: a smart transportation system will benefit from in-network computing/filtering as such operations can reduce the end-to-end latency; (4) inter-operability: a smart transportation system must operate with heterogeneous device and protocols; (5) security: a smart transportation system must be resilient to all kinds of malicious attacks.”. From an ICT specific point of view, our unified Internet of Thing/Transport Platform will address the following issues:
- Naming. The first step towards realizing a unified IoT/transport platform is the ability to assign names that are unique within the scope/lifetime of each device, the data items generated by these devices, or a group of devices
- Resource Constraints. IoT devices, such as sensors, are often resource-constrained in power, computing, storage, and bandwidth. Power constraints of IoT devices, just like bandwidth, also limit how much data these devices can communicate.
- Publish/subscribe capability. A basic feature that is highly desirable to have is a publish/subscribe capability. The IoT/transport platform can set up subscriptions so that it can be notified when a particular event is observed by an IoT device/sensor (e.g., congestion may be based on reduced speeds). Similarly, at a higher layer, commuters may be notified (without their having to constantly check) about the status through a publish/subscribe capability.
- Contextual Association. Many IoT applications seek to take advantage of contextual information such as grouping, location, of devices and data to initiate dynamic associations for communication. The grouping may be formed by temporal proximity or through subscriptions. For example, this could be to find taxis within a short distance of a customer (or even vice-versa where a customer may seek to be notified when a taxi is available in the vicinity within the next few minutes).
- Mobility. Mobility in the platform can mean 1) data producer mobility (i.e., location change); 2) data consumer mobility, 3) network mobility; and 4) disconnection between the data source and destination (e.g., due to unreliable wireless links).
- Storage and Caching. Storage and caching play a very significant role, especially in an ICN platform. Critical information can be cached at service authorized points, including in the network, thus greatly reducing content access latencies.
- Security and Privacy. The unified platform makes physical objects accessible to applications across organizations and domains. Thus, security and privacy become serious concerns. Security includes data integrity, authentication, trust management, and access control at different layers of the platform. Privacy means that both the content and the context around data need to be protected.
The basic Application Programming Interface (API) of Internames will accept names as identifiers of all requested content or services (see figure below).
