Federation and Orchestration: A Scalable Solution for EU Multimodal Travel Information Services

Abstract

Multimodal travel planning services allow travelers to plan their journey by combining different transport modes: air, rail, waterborne, coach, public transport, demand responsive transport, walking, cycling, etc. The European Union is fostering the development of cross-border multimodal planning services by establishing a regulation framework for their coordinated and coherent deployment across Member States (under the Directive 2010/40/EU). This EU regulation gives precise requirements on travel data formats (DATEX II, SIRI, NeTEx, etc.) and on fundamental and recommended system-level services, such as discovery and linking services. However, it does not (yet) pose constraints on how to implement them. In this paper, we devise and test a system architecture, named Bonvoyage, which proposes an innovative solution implementing such services. For discovery purposes, it federates nation-wide NoSQL databases that contain travel information by exploiting a novel telecommunication paradigm, Information Centric Networking. As regards linking purposes, it orchestrates the use of autonomous monomodal or multimodal routing services provided by small/big stakeholders to compose the best door-to-door journey.

1. Introduction

The ever growing mobility of citizens and goods is making Intelligent Transport Systems (ITSs) a must-have for modern cities and countries. ITSs allow citizens to be better informed about a broad range of transport options, leading to a safer, more coordinated and more efficient use of the overall transport system. It has become clear that improving the transport system of a country not only requires efforts in preserving and enhancing the transport infrastructures and means, but also in implementing ITS technologies. Indeed, many governments and national initiatives, such as US DOT [1], the European Commission [2], and ITS Japan [3], are promoting ITS deployments.

ITSs have a complex architecture that ties transportation, communication and computing worlds together into specific applications. Initially, these applications were mostly focused on making more efficient and safe the use of roads, reducing for instance traffic congestion and accidents [4]. This objective is still central for ITSs, as evidenced by much research and many developments that have brought connected and automated vehicles closer than ever to being part of our everyday life. However, the integration of such road services with other forms of transport (bus, bike, subway, train, etc.), in a unique multimodal framework, is a new challenging ITS goal, especially where public transport is deemed pivotal for a sustainable mobility, like in Europe.

Several studies, such as [5], were already able to observe the major ongoing innovation in the so-called 2nd generation of ITS, surfacing already around year 1998, such as interactive user interfaces, ubiquitous goelocalization of vehicles, directories of points-of-interest, multimodal information and dynamic route guidance. However, the focus was much more on the speculative technologies for adding intelligence to the systems, rather than on key enablers such as standardization of data and interfaces.

Throughout the following years, the idea of Advanced Traveller Information Services (ATIS) became extremely well-defined in the literature, both conceptually and in terms of technical architectures, due to research broadly covering two aspects.

On the one hand the psychology of the traveller was investigated, with the intent of assessing the value of traveller information as one important factor contributing to quality of (public) transport. In particular, by introducing the concept of integrated multimodal traveler information to mixed socio-demographic groups of travellers, in their work [6], the authors inject the seminal idea that presenting several modal options for a journey can overcome habitual and psychological barriers to consideration of alternative modes, and it could persuade a modal change. Years later, by investigating a sample of Dutch travellers with a substantial share of young persons, the authors in [7] cover the gap between arguing that integrated multimodal information provision would make public transport more attractive and actually finding out what kind of multimodal information travellers really need. An excellent example of how complete is the state-of-the-art about perceived characteristics of travel alternatives and the effect of information, the reader is redirected to the very comprehensive review [8]. The authors state that one key finding from generic micro-economic literature, as well as from the travel demand literature, therein extensively surveyed, is the convincing evidence that an individual’s perception of characteristics of travel alternatives might differ greatly from the actual values of those characteristics. That is, individuals mostly overestimate positive features of chosen alternatives, compared with non-chosen ones.

On the other hand, several concrete, albeit prototype, software implementations started to emerge, such as the digital personal travel companion supported by the Austrian Federal Ministry for Transport, Innovation, and Technology [9], or the Norwegian ARKTRANS [10] architecture and the related pilots, which contributed to more focus on data interoperability and standard interfaces, together with several pioneer EU research projects on mobility, such as EU-SPIRIT [11], or INTREST [12].

Given this vast landscape of research in mobility, EU decided to take the initiative for comprehensive regulation and harmonization directives [13].

Hence, all subsequent works are now able to leverage the Europe-wide convergent results and architectures. The authors in [14] develop a framework for comparing existing journey planners in a quantitative way. They extract and group a set of criteria and assign scores and weights to rank the planners by functional, operational and visualization features. They have examined a set of twenty very diverse systems, using multi-criteria analysis, ranging from regional to international planners, encompassing a wide number of features, showing how difficult it is to design a system able to excel on all aspects. The author in [15] contributes one step further to the state of the art, i.e., from extracting features useful in comparing, to identifying requirements useful in design, and she focuses in encouraging travel decisions that could lead to lower energy usage and improved sustainability. The most interesting part of her contribution is the identification of situations that have the potential to change travel patterns and transport choices, including the choice to dismiss the travel altogether in favor of virtual meetings or online shopping. She focuses on nine travel information systems, but only one of those (the former GoogleTransit) has global coverage.

Overall, it is presently clear that forthcoming ITSs are going to support heterogeneous mobility applications, ranging from the journey planner used by citizens to determine the best combination of transport means for going from place A to place B, to the car system that adjusts brake pressure to avoid a collision with an incoming vehicle that the driver cannot see because it is around the corner. Although in many countries such next-generation national ITSs already exist or are being developed, their deployments are often fragmented and uncoordinated, thus preventing, or making it very difficult, to provide a geographical continuity of ITS services. In this regard, the European Community has acknowledged these difficulties and, as a consequence, the Directive 2010/40/EU established a legal framework for developing specifications to make ITSs interoperable across borders [13].

The directive recommends six priority Actions, namely: (A) the provision of EU-wide multimodal travel information services (e.g., the provision of ITS data and routing services); (B) the provision of EU-wide real-time traffic information services; (C) data and procedure for the provision of road safety related minimum universal traffic information, free of charge to users; (D) the harmonized provision for an interoperable EU-wide eCall; (E) the provision of information services for safe and secure parking places for trucks and commercial vehicles; (F) the provision of reservation services for safe and secure parking places for trucks and commercial vehicles. For Action A the Delegated Act 1926/2017 [16] specifies the following (and more):

• Each Member State shall set up a National Access Point (NAP), which shall constitute a single point of access for users for accessing ITS data (static and real-time) of different transport modes. The NAP may take various forms, such as a database, a data warehouse, a register etc.
• A NAP shall provide discovery services making possible to search data or services using the content of corresponding metadata, timely provided by transport authorities, operators, etc.
• Local, regional and national travel (information) providers should expose functionality and metadata of their services though a standard interface, thus making possible the linking of services, in order to allow cross-region door-to-door multimodal journey planning. Metadata includes the handover points, i.e., the location where the results from different routing services can be linked to produce one single door-to-door journey.
• Recommended formats for ITS data are: DATEX II for real-time data on roads; NeTEx for static data (e.g., routes, schedule, fares) of scheduled public transport (metro, bus, train, etc.) and SIRI for dynamic data (e.g., real-time scheduling update).

In this paper we present a federated system, called Bonvoyage, that deals with the provision of multimodal journey planning services. Bonvoyage caters on over fifteen years of research and applications in the field of intelligent transport systems, and tries to enhance the state-of-the-art. The system follows the EU recommendations for the provision of EU-wide multimodal travel information services, but it can be used in other national and international ITS scenarios, too, where either the federation is required because of the presence of multiple actors, or because the federation is convenient from a management point of view.

Differently than centralized systems that use a single resolution process and data repository, the Bonvoyage system combines several routing services (named soloists), each of which is able to provide information about just a segment of the whole door-to-door journey plan, and this segment can be a mono or a multimodal one. For instance, it can be used in a scenario for which every nation provides a multimodal routing service for in-nation travels. To create a cross-border door-to-door journey plan, the Bonvoyage system will integrate, discover and inquiry the necessary national routing services and then link their partial solutions to form the whole door-to-door journey. As another example, we can have in the same city different monomodal routing services for bus, car/bike sharing, metro, etc., offered by existing transport operators. To build a door-to-door plan the Bonvoyage system can inquiry all of them and combine monomodal results to derive multiple multimodal solutions.

The Bonvoyage system is mainly composed of two service layers: a discovey layer, which provides information about sources of travel data and autonomous routing services (i.e., journey planners); and a linking layer which connects these (monomodal or multimodal) autonomous routing services to provide travelers with a door-to-door, cross-region, multimodal and personalized journey plan. A prototypical implementation has been used to assess system effectiveness and feasibility. It federates:

• a heterogeneous set of novel monomodal and multimodal routing services for Norway, Spain (in Bilbao), Italy (in Rome), and continent-wide airplane travels;
• Google Maps car routing service, thus showing the openness of our system to integrate existing routing services through simple adapters;
• a distributed set of sources of travel data.

The paper is organized as follows: in Section 2 we describe the system and our methodology; in Section 3 we report performance assessments of both discovery and linking layers; in Section 4 we discuss and position our work, also contrasting it with existing solutions; finally in Section 5 we draw conclusions.

2. Materials and Methods

In this section we present the Bonvoyage system, which solves multimodal journey plans in a distributed way. It overcomes the fragmentation and non-interoperability of travel information services by introducing two interworking layers, a discovery layer and linking layer, fostering knowledge sharing and computational cooperation, respectively. At both layers we pursue a federation strategy, which combines the routing services offered by a group of distinct, formally disconnected ITS service providers. The technological challenges focused by the system are:

• the design of an efficient, scalable, and federated system able to provide users with personalized multimodal journey plans;
• the devising of a methodology for the distributed computation of multimodal journey plans;
• the devising of a federated spatial database for discovering travel data.

The system architecture has been inspired by Action A of the 2010/40/EU Directive in the sense that it provides: national hubs of travel data (named National Access Points); mono- and multi-modal routing services; services for data discovery; and mechanisms for the planning services to link/orchestrate each other, in order to create an door-to-door cross-border journey plan.

Figure 1 shows the Bonvoyage system. A federation of NAPs forms the discovery layer. Any NAP is a single point of access to the whole federation’s data set, but it only stores information (metadata) related to the geographical zone it is responsible for, e.g., a nation or a cluster of nations. By contacting a NAP, a user can discover which travel data or routing services are available for a given geographical area. Actual travel data or routing services remain in the provider premises, thus simplifying update/consistency procedures and processing/network-load distribution. The data items stored by a NAP are simply spatial metadata, describing travel data or routing services that providers want to make discoverable.

A federated hierarchy of routing services, called soloists and orchestrators, forms the linking layer. At the lowest hierarchy level there are the soloists, which are autonomous routing services, serving a geographical zone (e.g., a city, a region, a nation, the services provided by a transport company, the whole world, etc.) and providing mono or multimodal routing solutions between points belonging to their zone, by means of internal data and algorithms. For instance, currently operating planning systems of train, flight, or bus companies, as well as Google Maps, may become soloists of the Bonvoyage system, merely by adding some web service interfaces. Indeed, a soloist exposes a HTTP REST service interface based on an SPROUTE extended format [17] and register its capability to the discovery layer by sending spatial metadata to the NAP. It may also periodically search for new sources of travel data for its zone, by querying the NAP.

A key feature of the extended format of SPROUTE is the support of multimodality, i.e., the use of multiple modes of transport within a single request or response. Moreover, it offers the possibility to express user preferences in a request through cost parameters, for limiting the search space only to solutions comfortable for the user, without explicitly disclosing any user’s personal data. Soloists covering the same area for the same modality is permitted to exist since they may have different capabilities. There may be for example one soloist for the car modality based on static driving speeds, another taking the real-time traffic congestion into consideration, and a third soloist providing routes that allow stopping by electric car charging stations.

Soloists are linked together by higher level routing services, called orchestrators, which interact with external users/servers. When an orchestrator receives a route request, it uses the spatial metadata from the discovery layer to single out the subset of soloists that can contribute to the requested route, and eventually “links” soloist results to provide the user with one (or more) multimodal journey plan(s). Soloists are linked to each other at the handover points, reported or derived by the soloist metadata. In Figure 1 soloist S1 provides a route from A to the handover point, and soloist S2 from that handover point to B. In general, different soloists can provide different segments of the whole route or overlapped segments with different modality or costs. Multimodality can even be achieved by combining monomodal soloists, thus not requiring the implementation of complex multimodal ones.

An orchestrator exposes to the users the same SPROUTE interface exposed by a soloist and periodically searches for new soloists for its coverage area, by querying its NAP. Optionally, it can expose its services at the discovery layer as if it were a plain soloist but with extended capabilities springing from the union of the capabilities of the soloists that it links. Hence, orchestrators can be stacked recursively to form a routing resolution hierarchy, where soloists are the leafs.

2.1. System Operation

In order to illustrate the operation of our system, let us examine a cross-border, Europe-wide travel request from location A in Oslo to location B in Rome. The involved actors are: user; orchestrator; two federated NAPs (Italy, Norway); a multimodal soloist for Rome; a multimodal soloist for Oslo; a long-range monomodal Airplane soloist; travel data sources publishing scheduled service times of public transport in Oslo, in Rome, and of flights. In Figure 2 we describe the main discovery and linking procedures in this use case.

2.1.1. Discovery

Soloists and travel data sources need to register their spatial metadata to their reference NAPs (Figure 2a). In case of data sources or soloists spanning multiple countries (e.g., the Airplane soloist, named Flight SOL in figure), registration is sent to and stored by only one NAP (e.g., the one of the country of the transport company). Registration is repeated by an entity when its metadata changes (e.g., change of URL or of coverage area). Periodically (see middle box of Figure 2a), soloists and orchestrators query a NAP to discover, in a specified area of interest, new or updated data sources or soloists, respectively. Query responses (not shown in the figure) contain the spatial metadata of the entities available in the area. Through a single NAP it is possible to query all the federation’s data set. Consequently, the Airplane soloist and the orchestrator can contact the Norway NAP (named NO NAP in figure) to discover data sources and soloists available both in Norway and in Italy. In this case, the Norway NAP takes care of query forwarding and result aggregation. When a new or updated data source is discovered (bottom box of Figure 2a), the soloist (e.g., the Rome one, Rome SOL) directly interacts with the source (Rome DS) to fetch the new information: travel data and services never leave the owner’s premises.

2.1.2. Linking

A user, or an application server, sends a door-to-door route request (Figure 2b) to an orchestrator (many competing orchestrators are possible). By using metadata about the soloists, which were fetched during discovery, the orchestrator decomposes the whole route in segments, where each segment starts and ends either at a handover point or at the start/end point of the door-to-door route. The orchestrator identifies the involved soloists by performing a shortest path search in this graph of segment and points, and where the length of each segment is computed based on cost parameters specific to the route request. Subsequently, it sends a route request for each segment to the involved soloist, which sends back the solved route for the requested segment. From Figure 3 we see that the chosen handover points are the airports of Oslo and Rome. The orchestrator requests travel solutions: to the Oslo soloist (Oslo SOL) to go from A to the airport; to the flight soloist (Flight SOL) to go between the two airports; to the Rome soloist (Rome SOL) to go from the airport to B. Finally, it assembles the many solutions proposed by the soloists in a single door-to-door solution (or a set of them) and sends back the result to the user.

We have implemented a slightly more complex version of the described use case, where we have also included a soloist that wraps Google Maps services, to show that current major players can be part of the federation. Again, Figure 3 shows the GUI where one multimodal plan from Oslo to Rome is displayed and whose segments include airplane, bus, train, car-sharing. Other suggested solutions involve bicycle and private cars.

The following sub sections report some technical details of the discovery and linking layers, while the next section will report performance evaluation.

2.2. Discovery Layer

The discovery layer is a NoSQL federated spatial database, where NAPs are sites of the federation.

As shown in Figure 4, a site is formed by a front-end server interfacing a local back-end NoSQL database (or database cluster) with the rest of the federation, and with external users. The stored items are spatial objects, which contain metadata describing either a travel data source or a soloist. The object geometry (polygon, point, multi-points, etc.) represents the spatial coverage of the entity, while other object properties describe specific attributes of the entity. We have defined specific metadata schemas for travel data sources (such as GTFS, NeTEx, etc.) and soloists. For travel data sources, the geometry is usually multi-point and each point is located where a stop of the related transport service is; other embedded properties are the URL to fetch the data from, the format of the data, transport modalities, etc. For soloists, the geometry is the polygon the soloist can compute routes between any internal points of; other embedded properties are the handover (transition) points, the URL to be contacted, the supported transport modalities, etc.

For the sake of a simple implementation we have used GeoJSON to encode spatial metadata, even though the architecture can work with other formats, such as forthcoming DCAT/GeoDCAT standards. For instance, in our system, the soloist for the city of Rome is described in Listing 1.

	Listing 1: GeoJSON of Rome soloist.
1	{
2	"type":"Feature",
3	"id":"Rome Soloist",
4	"geometry": {
5	"type":"Polygon",
6	"coordinates":[…]
7	},
8	"modalities":["Walking","Biking","Car Sharing",…],
9	"transitions": [{
10	"description":"Rome Airport - FCO",
11	"modalities":["Walking","Flying" ],
12	"geometry": {"type":"Point","coordinates":[…]}
13	}],
14	"properties": {
15	"url":"http://...", "type":"SERVICE",
16	"sub-type":"SOLOIST"
17	}
18	}

A NAP stores spatial metadata coming from travel data or soloists of providers of the countries it is responsible for. A spatial discovery query submitted to a NAP enables a requester to search, across the whole federation, for travel data sources or soloists whose geometry intersects the geographical area (box, polygon, etc.) expressed in the query.

The design of the federated database posed many challenges, concerning: interoperability, interworking, and security. Our choice of the NoSQL model coped with the former issue. Indeed, interoperability of heterogeneous NoSQL databases (e.g., CouchDB, MongoDB and Cassandra) has been already demonstrated in literature, showing that it is possible to translate query, delete, insertion, and other operations among different databases, as well as to migrate objects among different storage models (document, key/value, graph, etc.) [18,19].

Regarding the interworking and security challenges, we exploited a new networking technology named Information Centric Networking [20]. An Information Centric Network (ICN) can be considered as a Content Delivery Network, but with a packet-level granularity. The network addresses named-data rather than end-hosts, where a named-data is any data item (a file, the response of a query, etc.) with a unique name. The network is formed of ICN nodes, each of which can have the role of consumer of information, producer of information, and simple router of information requests (Interest packets) and responses (Data packet). In Figure 5 we show an ICN router with its internal elements, which is connected to a consumer, to a producer, and to another ICN router. Connections are named faces, and could be TCP/IP sockets, Ethernet raw sockets, etc. Consumers request named-data by name, by issuing an Interest packet which contains the name of the requested data item. For instance in Figure 5, a consumer sends an Interest packet for a data item named db1/POI/objID=123. The Interest is routed-by-name by intermediate network routers towards a data producer, by using name-based forwarding information bases (FIBs) and using a prefix matching strategy. For instance in Figure 5, the Interest is forwarded to face 2 because of the matching with the db1 prefix in the FIB. Information about the forwarded Interests is temporarily left into a Pending Information Table (PIT) of nodes along the path as breadcrumbs, together with their incoming (downstream) face. When a node of the path (producer or network router) which possesses the named-data receives the Interest, it sends back the content in a Data packet. Network nodes consume the status information previously left in the PIT to send back the Data packet to the requesting user, along the same path followed by the Interest, but in the opposite direction. For instance, in Figure 5, when the router receives the Data packet db1/POI/objID=123 sent back by the producer, the router forwards the Data packet to face 0 as indicated in the PIT entry and then cancels (consumes) the PIT entry. The usage of the PIT enables also multicast forwarding, indeed in case of multiple Interests requesting the same named-data only the first one is forwarded, but all the incoming downstream faces are registered in the related PIT entry. When the Data packet comes back, it will be sent to all the downstream faces registered in the PIT entry, thus making one-to-many data distribution efficient. During reverse forwarding of Data packets, routers opportunistically store (in-network caching) them before they downstream forwarding, to accelerate delivery of popular data items, reducing network load. Data packets and, optionally, Interest ones, contain a digital signature and a reference to the related digital certificate. Thus, ICN provides data-centric security for which the security bits are packaged with the exchanged information for enabling secure delivery even from untrusted sources.

We exploited ICN multicast, caching and data-centric security to efficiently support NAP-to-NAP database operations; HTTPs/REST is used for User-to-NAP, instead (Figure 4). We deployed ICN software [21] as a middleware layer on top of TCP/IP, to be compatible with current solutions. A NAP is actually an ICN node (producer/consumer) connected with each other NAP/node through an ICN network. NAP-to-NAP database operations (query, insert, delete) are supported by Interest/Data packet exchanges. Objects (spatial metadata) stored in the database have a unique name and are signed by the object owner, thus alleviating the NAP owner from being responsible for data validity. To support query routing, the geographical space is divided into a grid of tiles, which are square areas with a longitude and latitude size of 1 degree. Through a distributed mechanism that exploits ICN multicast forwarding, the NAPs periodically exchange information about the set of tiles intersecting the spatial metadata locally stored. When a NAP receives a spatial query, it intersects the query area with the geographical tiles advertised by itself and by other NAPs, thus understanding which of them must be involved in the query process. Consequently, the query is routed only towards these interested NAPs and not flooded over the whole federation. Finally, results are collected and sent back to the requesting user. For instance in Figure 2a, the orchestrator carries out a discovery query whose area intersects both Italy and Norway; the receiving Norway (NO) NAP forwards the query to the Italy (IT) NAP too, then collects internal Norwegian and external Italian results, validates them through embedded security bits, and sends the result back to the orchestrator (not shown). As in [22], ICN caching is used to directly reply to queries of popular objects, reducing query latency and offloading the back-end NoSQL base.

2.3. Linking Services

At the linking layer, an orchestrator coordinates the services of a set of distinct soloists [23]. Actually, it maintains the association between soloists in an orchestrator graph consisting of a node for each handover point of soloists and two types of edges: External edges, which are edges connecting handover points of neighbor soloists and whose traversal does not incur any time-delay or costs; Internal edges, which are edges connecting the different handover points within a single soloist.

Each internal edge is associated with a single modality, and a lower bound for the cost incurred by traversing the edge is maintained as a multi-dimensional Pareto set. When the orchestrator receives a routing request from an origin A to a destination B (Figure 6), it first assigns A and B to one or more soloists, according to the coordinates and possibly other information (as the preferred modalities). Consequently, the orchestrator searches for a subset of promising shortest paths from A to B in the orchestrator graph. The internal edges of this path identifies the subset of soloists to be concurrently involved, and each soloist returns information about the internal route with its related cost. To speed up the computation, internal route results can be cached by the orchestrator for a specific amount of time, thus reducing the number of queries to the soloists. The geographical position of the handover points can either be pre-defined in the soloist metadata or, more ambitiously, computed on the basis of the area where two soloists are overlapping. Indeed, there may be soloists not declaring their handover points because the service pickup points are not in fixed positions, as in the case of a soloist for city taxi service. When handover points are not available, the orchestrator computes the shared area between the soloists, divides that area into sub areas (e.g., 3 in case of Figure 6), and deploys a handover point for each sub-area. The number of sub-areas to generate is a trade-off between complexity and path stretch: the more the sub-areas the more the complexity but the less the path stretch.

3. Results

We report some selected performance evaluations for the discovery and linking services, aimed at showing the effectiveness of horizontally distributing the computation among different servers, and the ability to build multimodal plans combining different soloists.

For testing the discovery services, we compared three possible federation configurations formed by 1, 2 or 3 NAPs, respectively. Each NAP is responsible for a chosen number of European countries, so that NAP coverage areas are similar in each configuration. The NAP federation manages discovery information of about 1000 GTFS travel data sources coming from free Internet web servers that allow downloading GTFS files. The metadata of each data source is stored in the NAP of the provider country. Each NAP is formed by a front-end server running in a Java Spring STS environment, a MongoDB NoSQL back-end database, and the NDN software [21] for ICN functionality. The test application evenly dispatches discovery queries with Poisson inter-arrival to the NAPs of the federation, thus simulating users access from different countries. Each query aims at finding travel data sources whose GTFS has at least a stop located in a squared discovery area, randomly centered in Europe, and not related to the area covered by the NAP, to simulate that each NAP provides access to the whole data set.

Figure 7a reports on the max discovery rate vs. the discovery area. The max rate is the highest rate for which the delay to process a discovery has a stable behavior versus time; for higher rates the discovery delay grows to infinite. We observe that the configuration with the biggest number of NAPs supports the highest rate, thus confirming the capability of the federated system to horizontally scale, i.e., to improve its performance by adding NAPs. This result is also confirmed by Figure 7b showing that the 3-NAPs configuration supports higher rates, before becoming unstable.

With regard to linking services, we have investigated the orchestrator response times for a Norway car trip planning service by comparing two configurations: (1) a single soloist covering the entire Norway road network, i.e., a single graph with 1.659.821 vertices and 1.789.444 edges; (2) a distributed set of 426 soloists, where each soloist covers only the road network within one of the 426 Norway’s counties. The two configurations were loaded with the same set of random trip requests, with corresponding route lengths ranging from 3 to 2768 km, and provided the same optimal routes. Figure 7c reports on the response times of each experiment with related trend lines. Response times with a single centralized soloist ranged from 2 to 19 s, whereas response times for the (extreme) case of 426 soloists range from 0.3 to 1.6 s. Average speedup for the shorter routes is approximately 5 times, while for the longer routes the speedup is 15 times. The observed speedup is mainly due to two reasons, the first being that the orchestrator graph for the 426 soloists is able to limit the search only to soloists contributing to the optimal route. The second reason is that several soloists could process sub-routes concurrently. Overall, this result confirms the capability of the linking services to scale horizontally.

We have also conducted a set of system-level tests concerning cross-border door-to-door journey plans, to evaluate the ability of the orchestrator to setup multimodal solutions by linking either monomodal or multimodal routes coming from five different soloists. In particular, we used: a Bilbao multimodal soloist supporting FOOT, CAR (including taxy, Uber, etc.), BUS and BICYCLE modalities; an Oslo multimodal soloist that in addition to those also supports TRAIN, SHIP and TRAM; a Rome multimodal soloist supporting in addition also CAR SHARING, LIGHTRAIL; a monomodal Google soloist that only supports CAR modality; a monomodal Airplane soloist.

Departure and destination location of each test journey are set at random coordinates within Oslo, Bilbao, or Rome. Furthermore, departure time was randomly chosen throughout the day. A set of 300 journey plan requests has been issued to the orchestrator, which opportunistically used the five available soloists to build the results. User profile has been simulated by the setting of SPROUTE costs as to prefer shorter travel duration [24] and only the top-rank solutions have been taken into account. The same requests have been submitted to the Rome2Rio Internet service (www.rome2rio.com) for comparing Bonvoyage with an actual centralized system. Figure 7d reports on the occurrence of a given modality in the obtained route plans. Both systems properly provide multimodal solutions and the average number of modalities per journey was 4.7 for Bonvoyage and 4.4 for Rome2Rio. Bonvoyage prefers more the use of CAR, due to the shortest time preference that is not configured for Rome2Rio. By taking into account the preliminary and experimental nature of the Bonvoyage implementation, we argue that the similarity of results is a promising indication about the possibility of a federated system to achieve performance comparable (or even better) to traditional centralized ones, but reducing costs and increasing market opportunities for small companies.

4. Discussion

In this section, we initially position the proposed system in the framework of the EU regulation. Then, we discuss the differences with respect to literature and similar public services in other countries.

The study in [25] widely describes possible deployments of EU-wide multimodal travel information services compliant with EU regulation. Regarding linking services they consider three approaches: centralized, where every data is stored in a central server that also provides routing services; distributed, where a network of journey planners (like our soloists) “sequentially” collaborate to compute a door-to-door journey; a first planner computes the journeys from the origin to several handover points, then asks a second journey planner to compute journeys on from those handover points to the destination point and the second planner decomposes the computation as the first one, and so forth; hybrid, where a high-level multimodal journey planner supports planning between trunk destinations such as stations, airports or town centres, and then provides further access to low-level multimodal journey planners, to provide the path from the trunk destinations to initial/final destinations.

The Bonvoyage system is close to the hybrid approach described in the study, but it goes beyond the geographical and multimodality constraints of low-level planners, by allowing superposition of mono and/or multimodal soloists covering the same areas, thus making the environment more open and competitive. Our soloists are not necessarily geographically bounded and must not be necessarily able to include all modalities or transport services of an area, but only a subset of them. This creates the opportunity to exploit, as soloists, the planning services of transport operators that are already available, just by wrapping their API to Bonvoyage one.

Regarding the NAP system, the study [25] identifies several solutions for implementing the access points, including: (1) separate databases per nation, each exposed through a data portal; (2) a data warehouse where all information of different nations are collected; (3) a data marketplace (similar to e-bay) for connecting data providers and consumers; (4) a data register website that centrally lists different services offered by a nation with links to where they can be accessed. The Bonvoyage system offers many of the advantages of each solution and, moreover, tackles the problem of data certification by using data-centric security. We offer the programming power of a spatial database API (as for 1); we have a single federated database rather than small different ones, thus making it possible to access all of the data from any access point (as for 2); access points provide discovery services for letting consumers contact producers by using web links (as for 3 and 4).

The database we designed for the NAP system is the first one that uses ICN technology for federation purposes. In [22,26] we presented a “distributed” database based on ICN; here we have a new federated version of it that best fits the NAP scenario; specifically: stakeholders (rather than an uncontrolled global “sharding” function) decide where to store data (i.e., which NAP is trusted); there are different administrators (e.g., one per member state) rather than a single one; the new query routing approach is much more efficient, making it possible to submit just a single query per database site in order to solve spatial queries of any size, and more. With respect to other stand-alone NoSQL databases, e.g., MongoDB,

Table 1. Database Comparison.

Bonvoyage DB	Existing NoSQL
User defined storage location	Hash-based sharing
Spatial query sent only to sites with data in query region	Query flooded to any site
Data owners (stakeholders) are responsible for data validity	Administrator of a site is responsible for data validity
Federated deployment	Distributed deployment

reports on some features of the Bonvoyage DB that make it tailored for NAP applications.

The technique used by the orchestrator to combine different soloists resembles the overlay graphs approach in [27]. It uses an implicit and possibly recursive decomposition of the overall multimodal graph into a collection of separate (multi and monomodal graphs) equipped with a specialized trip planner. The technique is inspired by some recent developments in decomposition approaches. In particular, in [28] the authors advocate the use of separator-based methods to compute optimal paths in large networks. Separator-based methods can tackle multiple metrics and include real-time information, such as delays and road closures. They can also tackle time-dependent edge costs, i.e., when the travel duration and cost associated with an edge depends on the time when the edge is traversed.

With respect to similar available/public services in other countries, the Bonvoyage system integrates functionality, including the distributed routing service for computing a multimodal journey plan and the personalizing system able to learn from users’ choices, which are not found, to the best of our knowledge, in an integrated fashion, in other public services.

The system is able to quickly compute multimodal solutions considering several different transportation modalities (i.e., car, bus, tram, subway, bicycle, train, airplane, car-sharing, foot, ship, lightrail) which are properly linked obtaining nearly optimal trip plans.

Further enhancement of the multimodal solutions is obtained by considering a set of users’ preferences and by collecting associated users’ choices over time. We have followed a data-centric approach to intelligent travel planning, and we have applied machine-learning techniques, in order to try to capture some of psychological insights (see above cited [6,7]) that drive users when they choose their preferred travel modality. Being this trip personalizing techniques we have implemented out of the scope of this paper, the reader is redirected to [24] for a deeper analysis on our results.

Other public services integrate the set of Bonvoyage features just partially, in terms of both multimodal and personalizing capabilities. For example, Google Maps is not able to link the private car with other modalities (e.g., subway, tram, bus). It does not learn from past user choices when computing the solution according to users’ preferences. Rome2Rio, another recently available system, even if it is able to provide multi-modal and door-to-door solutions, does not include a personalizing sub-system. Its journey planner is not able to generate solutions considering fine-grained distributed data sources (real-time car-sharing vehicle position, for instance) nor it is able to integrate heterogeneous sub-planners (like our soloists) from heterogeneous operators. Other services such as GoEuro and RouteRank can compute multimodal solutions, but they are not door-to-door, nor, once again, personalized or federated.

5. Conclusions

Cross-border multimodal trip planners require the availability of travel data and big computing power, due to the complexity of the problem. Both requirements may slow down innovation: on the one hand small/medium stakeholders usually cannot afford high expenditures for computing platforms; on the other hand, transport operators might not like to open their data to them, either because they want to control how their customers travel within their network, or because they want to be extremely sure of correct usage of their data, thus trusting only Internet top-players. To tackle these problems, the Bonvoyage system proposes a federated system where any company can play a role, ranging from big, multimodal, cross-border travel service providers, to small, monomodal, local providers. Indeed, their services are linked together to effectively single out and offer the best travel choices to citizens.

Even though inspired by EU requirements, the proposed architecture can be reused in every use-case where having a federated system for solving cross-border multimodal journey plans, rather than a centralized one, is more convenient. Convenience may be related to different aspects, such as administrative advantages in spreading service responsibility to local administrations, deployment advantages gained by creating multi-modal planning service out of the mono modal ones already offered by existing transport operators, technical advantages in reducing data consistency problems in a decentralized solution, etc. For instance, as a closing remark, we would like to point out how perfectly our system supports the typical scenario of nations structurally delegating many responsibilities to the regional level (e.g., USA states’ level, or Japan districts’ level): in this case, each region can deploy its own NAP, existing transport operators of the region can expose their routing services to the system, and the national level can seamlessly offer orchestration services.