Components and tools

Marketplace Platform

MOBiNET is an internet-based network linking travellers, transport users, transport system operators, service providers, content providers and transport infrastructure. It connects users (people, businesses, objects) with suppliers (operators, providers, systems), and brokers (or help to broker thier interactions). At its core is a "platform" providing components and tools that enable those interactions.




Components and tools

Components and tools come in several consecutive releases according the Agile methodology. All components and tools come integrated in one platform in the different releases.
 
MOBiNET focuses on the development of the following components and tools:

MOBiCENTRE is a cloud-based platform that constitutes the central facility of MOBiNET. The Dashboard is the interface for data and service providers. Thanks to this component, the users can access the MOBiCENTRE.
The MOBiCENTRE links external data storages, App stores, payment facilities and external services. It communicates with end users (i.e. travellers) through MOBiAGENT. In turn, data and service providers use MOBiCENTRE through the Dashboard. The MOBiCENTRE consists of six key components:

 
What does this component do (contribution to the platform, how does it use the platform, how does it interact with other components)
The Service Directory is a database for descriptions of transport and mobility data and services. It is the central registry of machine to machine (M2M) services in MOBiNET.
The Service Directory stores structured descriptions of data and services, that can be searched via a web service interface (REST-API) based on their geographical location, their input / output or their keywords/tags, and many more.

In this sense, it works as the yellow pages of transport and mobility data and services.
A data/content owner or service provider can access the Service Directory through the Dashboard, where interaction with the Identity Manager enforces the rights to modify service descriptions. He can register his service by simply providing a description, which can be updated or deleted by the user anytime.

Another main aspect of the Service Directory is that services can use the Service Directory to automatically discover other services to interact with. This discovery can be done based on different filters such as data format, service type or category, service coverage area, and other.

Which ITS stakeholders does this component target

The Service Directory is aimed for the developers and owners of ITS services, who want to make their services more dynamic and adaptable.

How does this component compare to the state of art

The Service Directory supports the description of all aspects of any service, e.g. in form of USDL, description of input/output, endpoint, interaction, pricing, etc.
For the management of the service descriptions, the Service Directory supports all functionalities necessary.

Furthermore, the automated service discovery capabilities allow the creation of services that particular aim migration.

Evolution / improvement of component with regard to the MOBiNET platform upgrades

Initially the Service Directory supported very basic add, remove, and search functionalities of basic service descriptions. Through several platform releases, the Service Directory now supports a service description that covers the most relevant aspects of services, along with advanced performance optimized M2M service discovery functionalities, and also supporting credential checking.

The MOBiNET billing component handles all financial transactions and provides a neutral instance which monitors those transactions between different parties. The design of the billing component supports a plurality of business models and administrator configurations, and depicts a general purpose e-market place, addressing B2B and B2B2C scenarios.

Main functions are:
- configuration of parameters relevant for billing and clearing purposes
- real time log of all events relevant for billing and clearing purposes - tracking takes place with web services invoked by MOBiNET components and external Apps and services
- end of period (e.g. monthly) processing. Includes: data verification of real time log , calculation of the amounts due, generation of invoices for MOBiNET services, generation of all data necessary for the creation of invoices, payment.

MOBiNET billing component combines :
- fees due to MOBiNET for its services: e.g. MOBiNET subscription fee, monthly fee for publication of a billable product on the service directory, one-off charge for each product sold through MOBiNET service directory, monthly fee paid by a Service Provider for each subscription/renewal of one of its products, etc.
- a one-off product sale with postpaid: payment takes place with a direct debit at the end of the period; MOBiNET billing component generates SEPA file
- a one-off product sale with payment to MOBiNET virtual store: amount buyer pays to MOBiNET - MOBiNET collects at sale from buyer with its virtual store
- a subscription scheme with monthly fee: buyer shall pay to Service Provider the amount due for each subscription renewal. Payment takes place with a direct debit; MOBiNET billing component generates SEPA file
- amount due among Service providers in B2B and B2B2C scenarios.

All fees due to MOBiNET are determined and configured by MOBiNET administrator (for subscription, for clearing services in B2B2C, etc.). Each Service Provider determines the price and the fare rules for its services; the amount is distributed to the MOBiNET billing component at each event relevant for billing purposes. Granted user can search and download invoices of the company he/she belongs through MOBiNET web portal (dashboard).
The Billing component interacts with the Identity Manager to import all relevant users’ details, with the Dashboard and the Service Directory.
As a relevant business case, MOBiNET Billing component paves the way for the implementation of a B2B2C scenario where a Service Provider of mobile payment app (parking, bus mobile tickets, ecc) may extend the area covered by its App/product involving other Service Providers. This enables Pan-European interoperability of mobility services: end user keeps on using its own app, account and payment system, but on a wider area.

What does this component do (contribution to the platform, how does it use the platform, how does it interact with other components)

The Identity Manager (IDM) is the module responsible for handling the identity for all the entities in MOBiNET. In particular, it manages users authentication and clients authorisation in MOBiNET, enabling users and service providers to login to MOBiNET (also using the OpenID protocol) and its services to be accessed in a secure way (using the 0Auth2.0 protocol). For basic session management, a Single Single On (SSO) solution is also supported in order to avoid the need for the user to provide again his credentials when navigating from the dashboard to the other MOBiNET sites (e.g. User Management site, Client Authorization site)

The IM provides the user interfaces to configure the platform and to register both the business and end users, assigning for each entity its role and associating the relevant attributes. Several Rest services are provided in order to let every MOBiNET module get all the needed profile's information.

How does this component compare to the state of art

The IDM was developed to solve platform requirements, taking into account that they could change and therefore making it highly configurable. When available, standard protocols were used and needed services were provided.

Evolution / improvement of component with regard to the MOBiNET platform upgrades

While at the beginning the main role of the IDM was the user management and their authentication, more and more features were added in order to support all the requests coming from other MOBiNET modules. The definition of the involved actors, their roles and the relations among them, the entities attributed, the exposed services were defined and improved in order to support all the MOBiNET modules for the defined use cases.

1. What does this component do
The TSP Manager (TSPM) is responsible for the following:
• All the communications between Telematics Service Providers (TSPs) and Insurance Providers (IPs);
• Communication between Insurance Providers and TSPs when there is a change of Insurance Providers;
• Communication between different TSPs for delivering data from a vehicle to the selected IP.
The new IP, chosen by the end customer, will notify MOBiNET. At this point MOBiNET will do the following:
• Inform the previous IP that it will not receive any more the data from the TSP in charge of the previous customer’s on-board device.
• Notify the two TSPs involved, the one of the previous IP and the one the current IP.
This will allow the correct handling of the UBI data flow, with information retrieved from the TSP of the previous IP arriving, passing through MOBiNET first and through the new IP TSP afterwards, to the new IP.
Main use cases can be divided in two categories, the ones belonging to data provisioning on IP switch, and the ones belonging to Telematics data transfer (when the switch is done).
2. Which ITS or project stakeholders does it address
Telematics Service Providers (TSP) collect telematics data using various methods described above. They can offer this data to others using B2B or B2C services which can be registered in the MOBiCENTRE Service Directory.
Insurance Providers (IP) offer insurance products based on telematics data provided by TSPs. They can register their insurance products for specific telematics data sets.
MOBiCENTRE is the hosted platform behind MOBiNET which offers various services for business and for end-users. Among others the following MOBiCENTRE-components are involved in the UBI use case:
• The Identity Manager is responsible for authenticating and authorizing any MOBiCENTRE users.
• The Dashboard offers a user interface for any service providers to register their services or search for services offered by other service providers.
• The Service Directory stores all information on services which are registered in MOBiNET.
• The Service Discovery component offers end-users a user interface for searching end-user services (like insurance products)
• The TSP Manager is responsible for all communication between TSPs and Insurance Providers. It can link the telematics data from a vehicle with the selected insurance product.
The Service Discovery component and the TSP Manager component are both MOBiCENTRE components which are part of the “extended” MOBiCENTRE platform.
3. How does it compare to the state of art
The TSP Manager is unique to MOBiNET. There is no other platform that provides a method for routing data from multiple embedded or aftermarket hardware devices installed in vehicles to service providers that are not specifically contracted by the supplier of the hardware device, or the vehicle OEM that has installed the hardware device in the vehicle.
4. Description of the evolution / improvent of component / tool with regard to MOBiNET platform upgrades
Not applicable
5. Cross reference with deliverable xyz
There is no specific, dedicated deliverable for the TSP Manager since it was introduced during the course of the project. However, it is part of the IR_Architecture refinement and integration_MOBiNET_Platform Release 3.0 document.
What does this component do (contribution to the platform, how does it use the platform, how does it interact with other components)

The Communication Agent (CA) is a centralised component that resides in the MOBiCENTRE. It is responsible for periodically receiving and processing information over the cellular network from end user devices (e.g., on-board unit, smartphone, tablets) equipped with the CM which is part of the MOBiAGENT. The periodic updates from the CM contain, but are not limited to, information about the current position of the device, its speed, heading, applications installed, and its communication capabilities. It exposes APIs which can be used by service providers to disseminate information using different communication technologies. The CA builds a connectivity bird-eye view and identifies opportunities for multi-technology information communication and dissemination.

Which ITS or project stakeholders does it address

ITS Transport users , ITS Transport System Operators, Service Provider and Transport Infrastructure

How does this component compare to the state of art

The current state of art is primarily based on data delivered over cellular network for specific application such as maps. In contrast, CA uses multiple complimentary technologies such as ITS G5 and cellular to deliver standardized content to users until last mile. It enables operators to intelligently disseminate data for users in specific geographical area. It provides convenient interfaces to Service Providers for collecting floating car data , enabling data aggregation which can be used to deliver intelligent services based on data analytics and prediction.

Evolution / improvement of component with regard to the MOBiNET platform upgrades

Provide additional mode of data delivery from SP to CM via unicast. Providing an Authentication and Security strategy for usage of CAs REST API and authenticating CMs data. Providing and improving CM-CA roaming functionality. Optimizing geocast data dissemination over cellular network.

1. What does this component do (contribution to platform, how does it use the platform, how does it (potentially) interact with other components)
The DQA component aims to assess the quality of traffic data from fix sensors and floating car datasets (FCD) by calculating quality indicators. For FCD it provides granularity, missing data, reliability and accuracy, while for fix sensor measures it provides four types: zero occupancy, non-zero occupancy with zero flow, high occupancy and constant measure.
This functionality is increasingly important since traffic data, as floating car data, is becoming more and more abundant and can be used for different purposes (e.g. analytics, optimization). Consequently, it is of interest to assess the quality of a particular dataset from a provider before acquiring it or even on regular basis during operation. The DQA component includes a widget in the MOBiNET platform, through which users can upload and evaluate the quality of their floating car datasets. The widget interacts with identity manager component in order to authorize users.
2. Which ITS or project stakeholders does it address
With the high availability of GPS measurements and data collection systems, many ITS stakeholders can take interest in the DQA component. For instance, data providers can assess the quality of their datasets before approaching potential clients. The latter can do the same before acquiring the data. Such potential clients may include transport operators who seek to develop and/or validate analytics and optimisation techniques that would considerably improve their services.
Data providers could benefit from the server by first evaluating the data they provide and to show compliance with the MOBINET platform.
3. How does it compare to the state of art
Traffic service platform for service developer are now become available (e.g. opentraffic.io) or companies develop services for specific customer (closed Platform/Systems). Quality benchmark methods such as QKZ and QBENCH provide way to validate separate source of information, but there is not currently available a service as the DQA of MOBiNET. The service is provided to 3rd party to validate the quality of their data. Most services indeed provide only simple descriptive information about a dataset, which is not sufficient to assess the quality of different datasets from different providers as these results aren't comparable nor insightful.
4. Description of the evolution / improvent of component / tool with regard to MOBiNET platform upgrades
The first version of the service provided quality indicator for fix sensor measurements, but with the more recent version the DQA provide a widget and the ability to validate floating car data.
1. What does this component do (contribution to platform, how does it use the platform, how does it (potentially) interact with other components)
The Analytics Server has two main aspects. It provides tools and interfaces which allow MOBiNET app and service developers to store various usage related information, such as where has the app or service been used, which user used the app or how long hast it been used.
On top of that the Analytic Server provides a set of analytics providing better insights to the app and service developers on how their apps are used allowing them improve their apps or services.
Additionally the Analytics Server provides methods to record analyze and partially predict the Quality of Service of mobile networks in specific areas. In a first step smartphones are used to record periodically the QoS of the mobile network. These measurements are GPS and time tagged and reported to the Analytic Server.
In order to provide more usable data the Analytic Server matches these records to a coarse grained grid and provides QoS information about the different tiles in the grid. On top of this grid, interpolation techniques are used to predict the network quality in grid tiles which do not have actual measurements.
This allows the app and service developer to optimize the data usage when the end users passes through different areas.

2. Which ITS or project stakeholders does it address
The Analytics Server aims for the developers of MOBiNET apps and services. Since the provided features, QoS prediction and analysis for mobile networks and service usage analytics, are independent from the actual apps or services it can be used by basically all developers to optimize their applications or services.
These optimizations can be done either offline, using the insights to produce a new version of an app or service, or on the fly if the developer decides to integrate the Analytics Server interface into their app, e.g. optimized data loading based on the QoS of the mobile network.

3. How does it compare to the state of art
Currently used methods to predict the QoS of mobile networks are basically relying on averaging different measurements within one antenna and are using this average as prediction for the entire area. This approach ignores the effects location and time based circumstances like reflection from buildings or number of people at an area at a specific time.
Recording GPS locations and time of measurements as well as continuous measurement using smartphones allows us to do predictions of geographically close areas with a higher accuracy and in general give a higher level of detail than averaging over one antenna.

4. Description of the evolution / improvement of component / tool with regard to MOBiNET platform upgrades
The Analytics Server initially started off with a basic service usage analysis for R2.0. In the subsequent releases widgets, visualizing results in graphs, tables and maps (when applicable), were added. In R3.1 the Quality of Service for mobile networks analysis was added as well as a widget visualizing the measurement grid.

What does this component do (contribution to the platform, how does it use the platform, how does it interact with other components)

The MOBiAGENT is an Android application which provides end users with a way to interact with the MOBiNET platform. Via the MOBiAGENT application, end users are able to login-to the MOBiNET platform with respectively their MOBiNET or Google account. To provide this login functionality, the MOBiAGENT interacts with the Identity Manager within the MOBiNET platform. Once an end user is logged in, they can search for applications and end-user services that are available via the Service Directory of the MOBiNET platform. This is made possible via the integrated interface to the Service Directory component of the MOBiNET platform. Next to this, the MOBiAGENT also implements multiple communication channels (cellular and ITS-G5) to receive ITS related service information and application developers are provided with REST-API’s to be used with native Android applications in order to interact with the MOBiAGENT and MOBiCENTRE components.

The APIs of the MOBiAGENT are currently used by GLOSA, Ad-Hoc Priority Route and RTTI Services.
How does this component compare to the state of art
The MOBiAGENT is a state of art application.
Evolution / improvement of component with regard to the MOBiNET platform upgrades
The first release of the MOBiAGENT was focused on a technical perspective, meaning that less effort was put into the graphical user-interface and more effort into the functional implementation. Thereby the first release contained the basic functionality that provided the interface to the Service Directory and as also the basic functionality for the Communication Manager (implementation of the Cellular and ITS-G5 communication).

The second release of the MOBiAGENT significantly improved this functionality, as it also focussed on providing a more user-friendly interface for end-users and REST-API's for application developers.

The third release of the MOBiAGENT will be focussing on improving the available functionality.

SDK
What does this tool do (contribution to the platform, how does it use the platform, how does it (potentially) interact with other tools)
- Documentation / Tutorials to start service development; provide an introduction how to use platform components
- Service Description Editor to support service description generation, which are needed to register services in the Service Directory.
- Some small libraries to make access to components (SD, IDM) easier

Which ITS stakeholders does this tool target
The SDK addresses service developers or companies/people, who want to register their services in MOBiNET or develop new services for MOBiNET.
How does this tool compare to the state of art
The SDK is a state of the art tool to support development activities.
Evolution / improvement of component / tool with regard to the MOBiNET platform upgrade
- Documentation: Added new components through MOBiNET evolution and enhanced descriptions to represent latest state of the platform
- Service Description Editor: Adaptions to support latest service description format and enhanced usability
- Libraries: Support for SD and IDM were introduced over the releases

What does this tool do
MOBiNET Privacy Framework (MPF) is a toolset to dynamically associate a Privacy Manager module with potentially any MOBiNET service. Current limitations are: target service must be implemented in Java for an easy coupling.

Which ITS stakeholders does this tool target
MOBiNET service provider uses MPF for developing a privacy by default policy to be associated with its service. MOBiNET service user, or any actor taking the responsibility, may write policies to grant access to private information managed by an access control policy based on exposed purposes and roles. MOBiNET instance administrator may control privacy management compliance with local regulatory constraints. MOBiNET business team may define privacy charter to be respected by service providers if considered as key business differentiation.

How does this tool compare to the state of art
The MPF represents a complete new approach, inspired by PrivacyByDesign methodology principles but adapted to new agility requirements.

Evolution / improvement of component / tool with regard to the MOBiNET platform upgrade
The MPF represents a toolkit that is quite independent from MOBiNET implementation. MPF lifecycle is clearly separated since integration at runtime.